Why Manufacturing Agents Fail Despite MES/ERP Integration: Data Alignment Pitfalls

The article opens with a typical shop‑floor question: “Does the increased dimensional deviation in this batch relate to yesterday’s maintenance?” Although the team has integrated MES, ERP, and equipment management systems, and the agent successfully retrieves inspection results, work orders, and maintenance records, the combined data still leads to wrong conclusions.

Workstation unchanged, equipment changed: don’t let the model guess the mapping

In manufacturing, “equipment” can mean a physical asset‑numbered machine, a workstation that performs a machining task, or a collection of sensor tags in a data acquisition system. These layers are related but not naturally one‑to‑one. A machine can move to a different workstation; a workstation can use different machines over time. Sensors may be replaced while tag names stay the same, changing the actual data source. If the mapping table only reflects “who maps to whom now,” historical investigations will link to the wrong object.

Concrete example: yesterday the suspect batch was processed on machine B at a given workstation; today machine A runs at the same workstation. Tracing the batch requires following yesterday’s relationship to machine B. Using today’s mapping points to machine A, so even perfect maintenance records would be attached to the wrong equipment. The same problem applies to batches — incoming, production, inspection, and shipping batches may be at different levels, and split/merge/rework operations break simple name‑and‑time associations.

The article recommends using the model to suggest possible mappings as a starting point, but the actual historical mappings — when they became effective, where they came from — must be verified by the responsible business personnel.

Five core objects that must be aligned for the investigation

Physical equipment — confirm asset number, control system ID, and maintenance target refer to the same machine; responsibility: equipment management & system maintenance.

Workstation & operation — confirm which machine performed which operation in each time window, including line/machine changes; responsibility: production & process engineering.

Production order — confirm which order ran in which period under which process version; responsibility: production management & MES owner.

Material & batch — confirm traceability after split, merge, or rework, and whether impact scope can be determined; responsibility: production, warehousing & quality.

Inspection results — confirm what characteristic was measured, which sample and batch, and what judgment criteria were used; responsibility: quality & inspection system owner.

Interface staff can trace where identifiers originate, but only the relevant business roles can confirm whether two codes mean the same thing on the shop floor.

Prepare only what the task needs

Data preparation often turns into a plant‑wide governance project that never answers the original quality question. Instead, start by decomposing the investigation: which inspection characteristic shows the deviation? Which machining periods and batches are involved? What equipment and process version were used? Did relevant maintenance occur before or after machining? Which records are missing or never collected? Scope the integration to only the data needed to test candidate causes.

Maintenance records are especially prone to misuse. Example: maintenance on machine B completed at 08:00, the batch ran at 10:00, but the record was entered at 20:00. Treating entry time as event time would wrongly place maintenance after machining and exclude it from the investigation. Restoring the correct sequence (“maintenance first”) still does not prove causation — temporal order is investigation evidence, not a causal conclusion . Therefore, both event time and system record time must be stored, along with precision and source. If the true sequence cannot be reconstructed, mark “temporal relationship pending” and hand off to the responsible person.

Business ontologies or semantic models can unify object meanings, association rules, and applicability conditions, but actual identifiers, historical relationships, and data quality must come from source systems and their owners. Drawing an edge “equipment‑production‑batch” does not mean the historical mapping has been validated.

OPC UA is not just a data pipe

Industrial integration veterans may ask whether OPC UA and ISA‑95 already solve these object and relationship issues. They help, but you must first check what the standards and their on‑site implementations already cover. OPC UA’s official scope includes information modeling, semantic browsing, current and historical data access, methods, and events — it is more than a value‑transport pipe. If the site already uses suitable information models and companion specifications, reuse them to avoid re‑defining already clear objects. The real gap is usually the mapping between those standard objects and the factory’s own work orders, batches, and quality records.

ISA‑95 discusses enterprise‑manufacturing information exchange and object models, which helps clarify business boundaries. However, it does not imply every logical layer needs a separate deployed system, nor does adopting a standard automatically correct all local coding practices. The pragmatic approach: check what existing standards and models can be reused, then fill in the factory‑specific mappings. There is no need to deploy a whole new stack just to investigate one dimensional deviation.

Investigate yesterday’s anomaly — don’t use today’s “latest status” as evidence

Reading a numeric value requires at least its unit, operating condition, timestamp, and quality. Two fields with the same dimension name may use millimeters vs. micrometers; after confirming the measured characteristic matches, programmatic conversion rules can apply. But a temperature setpoint and an actual temperature reading cannot be interchanged even if units match. A model may appear to explain such differences, but it cannot replace explicit field definitions and conversion rules.

Equipment status “available” raises questions: when did this status become effective? When was it collected? Is it from a cache? For a historical anomaly, you need historical records reflecting the machining window. For a current operation prerequisite, you must verify the current status is still within its allowed validity window, possibly re‑querying. Freshness requirements are driven by task consequences, not a plant‑wide pursuit of “absolute real‑time.”

Records from different systems must be checked for consistency. The inspection system may have logged a rework batch while MES has not yet synchronized the batch‑split relationship; even though both interfaces return successfully, the results may not align. Verify common batch, event, or version identifiers and how far each source has synchronized; temporarily mismatched parts should be flagged as pending rather than forced into a complete conclusion.

Missing records need explicit reasons: sensor didn’t capture, system hasn’t synced, or current account lacks read permission. These three cases require different handling. Agree in advance when to re‑query, wait, escalate to human, or suspend judgment — don’t let the model fill missing values with zero or treat “not found” as “did not happen.”

Checklist: agree on “what data can be used for what”

Embedding the above agreements into interface documentation yields a data‑preparation checklist for this investigation:

Business question — which judgment this data supports; which causal or release conclusions it cannot support.

Objects & associations — identifiers, association basis, historical validity periods; who resolves one‑to‑many or conflicts.

Authoritative source — which source is the truth for each key fact; who reconciles when sources conflict; no single system is authoritative for all fields by default.

Values & conditions — units, measured characteristics, process versions, required operating conditions; who maintains conversion rules.

Time & quality — event time, collection/ingestion time, historical validity, quality flags; acceptable latency, missing‑data tolerance, cross‑source sync status.

Permissions & usage — which roles may read; whether data can be used for diagnosis, training, or pre‑execution checks — authorized separately.

Update & interface responsibility — who maintains the interface, who maintains business mappings; how changes are notified, how failures are escalated.

Degradation & acceptance — how to handle missing, stale, or contradictory data; which use cases prove the mechanism works.

Source system owners must explain how records are provided; business owners must confirm what judgments these records can support. The agent team then enforces usage restrictions in calls and outputs. For example, permission to query maintenance records does not automatically include using personnel data from those records for model training; permission to view batch status does not include modifying release status. Read and action permissions must be implemented separately.

Seven validation tests to prove data alignment works

Running a normal sample once does not prove the agreements hold. Business and interface staff should prepare the following scenarios in an isolated test environment or via historical replay, and verify system behavior:

Machine change without cross‑number — same workstation, different machine: can the system find the correct asset by machining period?

Batch split without broken trace — one batch splits into two, one reworked: can traceability be preserved without mixing inspection results?

Values not messed up — different units, unqualified tag quality: does the system convert by rule or reject, rather than silently concatenate?

Late records can correct — maintenance record arrives late: can affected judgments be revised while preserving the original evidence version?

Sync gaps identified — inspection updated, batch relationship not yet synced: does the system expose the gap instead of forcing a link?

Expired status not used — current status expired: does the system re‑query or pause dependent actions?

No permission ≠ didn’t happen — critical record invisible due to permissions: does the system report incomplete evidence rather than a negative conclusion?

Each test must record input sample, expected handling, actual result, and reviewer. Answering “yes” to all seven is not enough — you must produce the corresponding replay or test records.

When an erroneous mapping is discovered, you must also trace which reports or pending actions used it. Correcting a mapping table while old recommendations continue to circulate does not eliminate business risk.

If the scenario involves only a single machine, a single data source, and stable fields, a clear data contract may suffice. When cross‑system objects multiply, meanings repeatedly conflict, and multiple tasks need to reuse the same definitions, then gradually build a business semantic model. Do not let “build a complete ontology first” become the excuse for never starting.

Summary

Returning to the opening investigation, the first step is to determine exactly which machine processed the batch yesterday. If that relationship is wrong, even complete maintenance records are useless. Verify one batch, one machining window, and its associated records first; then expand to the next task — this gives data preparation a concrete scope.

The next article, “The veteran says ‘I know by the sound’ — what should the agent actually learn?” will discuss the harder material beyond data: how to capture the evidence behind expert judgments, not just their conclusions.

References

[1] OPC Foundation: OPC Unified Architecture. Cited for its information modeling and information access capabilities; the scenario checklist is an engineering synthesis. https://opcfoundation.org/about/opc-technologies/opc-ua/

[2] ISA: ISA‑95 Standard. Used only to understand enterprise‑manufacturing information exchange boundaries; the public overview is not equated with the full paid standard. https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard