ERP-MES Data Flow: ISA-95 Integration Contract

To answer directly: the data that should flow between an ERP and an MES under a practical ISA-95 integration contract is the set of information needed to plan, execute, and track production—primarily production orders, material requirements, resource availability, and actual consumption/production results. This article explains what that means in concrete terms, what to include in your integration contract, and what to leave out.

Background: Why ISA-95 Exists

ISA-95 (officially IEC 62264) is an international standard for integrating enterprise and control systems. It was developed because ERP and MES systems speak different languages: ERP thinks in orders, costs, and inventory; MES thinks in batches, equipment states, and process parameters. Without a common model, integrations become point-to-point spaghetti that breaks every time either system is upgraded.

The standard defines a hierarchy of levels, from Level 0 (physical process) up to Level 4 (business planning). ERP sits at Level 4; MES sits at Level 3. The integration contract we are discussing is the interface between these two levels. ISA-95 provides a set of object models—like ProductionOrder, MaterialLot, and Equipment—that both systems can map to, making the contract stable and understandable.

The Core Data Objects in a Practical Contract

Based on ISA-95’s models, a practical integration contract should cover these data flows:

• Production orders (from ERP to MES): order ID, product ID, quantity, due date, priority, and any customer or lot-specific requirements. This is the trigger for MES execution.
• Material requirements (from ERP to MES): what raw materials, components, and packaging are needed for each order, with quantities and expected availability. MES uses this to stage materials and check availability.
• Resource availability (from MES to ERP): which equipment, tools, and labor are available or down, with time windows. This helps ERP adjust schedules realistically.
• Production results (from MES to ERP): actual quantities produced, consumed materials, labor hours, machine time, and scrap/rework amounts. This is the feedback that closes the loop for inventory and costing.
• Status updates (both directions): order status (released, started, completed, on hold), material lot status, and equipment status. These are lightweight but essential for real-time visibility.

Optionally, you may include quality test results (from MES to ERP) if ERP needs them for batch records or regulatory compliance, and maintenance work orders (from ERP to MES) if maintenance is scheduled based on production load.

How to Structure the Contract: Messages and Timing

A practical contract defines not just what data, but how it is exchanged. The most common pattern is asynchronous messaging using XML or JSON over a service bus (e.g., MQTT, REST, or SOAP). Each message has a defined schema, a trigger event, and a response expectation.

For example:

1. ERP sends a ProductionOrderRelease message when a work order is released.
2. MES acknowledges receipt and returns a ProductionOrderStatus message with the order’s state.
3. When production starts, MES sends MaterialConsumed and EquipmentUsed messages in real time or at shift end.
4. At completion, MES sends ProductionResponse with actual quantities and quality data.

Timing depends on business needs: real-time for critical statuses (e.g., down events), batch (e.g., every 5 minutes) for consumption, and daily for financial reports. The contract should specify the frequency, the maximum latency, and the retry/error handling policy.

How to Choose What to Include (and What to Exclude)

The biggest mistake in integration is trying to send everything. A practical contract follows the principle of minimum necessary data. Ask for each data element: does the receiving system need it to perform its function, or is it just nice-to-have? If it is not needed, leave it out.

For example, ERP does not need every sensor reading from the MES; it needs aggregated consumption and production. MES does not need the full bill of materials with engineering revisions; it needs the production version that is currently active. Keep the contract focused on what drives decisions.

Also consider data ownership: who is the system of record for each field? Typically, ERP owns the order header and planned quantities; MES owns actuals and equipment states. Avoid duplicating data that can be derived from one source.

Common Problems and How to Avoid Them

• Data duplication and inconsistency: When both systems store the same field (e.g., quantity), they drift apart. Solution: define a single source of truth and make the other system read-only for that field.
• Message size and frequency overload: Sending every transaction in real time can overwhelm the ERP. Solution: batch non-critical data and use delta updates.
• Unit mismatches: ERP might use kilograms, MES might use pieces. The contract must specify the unit for every quantity, and both sides must convert correctly.
• Lack of error handling: When a message fails, does the system retry, alert, or silently drop? Define retry policies and dead-letter queues.
• Versioning: When the contract changes, both systems must be updated in sync. Use versioned schemas and support backward compatibility.

Comparing Approaches: Direct vs. Middleware vs. Data Lake

There are three common architectural patterns for ERP-MES integration, each with trade-offs:

• Direct point-to-point: The MES calls ERP APIs directly. Simple, but couples the systems and makes upgrades harder.
• Middleware/ESB: A message broker or integration platform (like MuleSoft, Azure Service Bus, or Kafka) decouples the systems. More robust, but adds complexity and cost.
• Data lake with batch sync: Both systems write to a shared data store (e.g., SQL database or cloud storage) and read from it. Great for analytics, but not for real-time operations.

For most manufacturers, middleware is the sweet spot: it provides reliability, scalability, and auditability. Data lakes are useful as a complement for reporting, not as the primary integration path.

Costs and Effort of Implementing the Contract

The cost of an ERP-MES integration varies widely based on the systems, the number of plants, and the complexity of the data model. Typical cost drivers include:

• Mapping and transformation logic (the bulk of the work)
• Middleware licensing and infrastructure
• Testing and validation (often 30-40% of the project)
• Change management and training

For a single plant with a standard ERP and MES, expect a project of several months and a budget in the tens of thousands of dollars (excluding the systems themselves). For a global rollout, costs can reach millions. The key to controlling cost is to keep the contract minimal and reuse existing mappings.

Safety and Compliance Considerations

In regulated industries (pharmaceutical, food, aerospace), the integration contract must support traceability and audit trails. The MES should send quality data (e.g., batch test results) to ERP for batch records, and the contract must ensure data integrity (e.g., using digital signatures, versioning, and secure transmission).

For safety-critical processes, the contract must never allow the ERP to directly control equipment; that is the MES’s role. The ERP should only send planned orders and receive results. Also, consider data privacy: if the integration involves customer or employee data, ensure compliance with applicable regulations (like GDPR).

Frequently Asked Questions

Should I send the entire bill of materials from ERP to MES?

No, not necessarily. Send only the production-relevant BOM (the version that will be used for this order), with quantities and material IDs. The MES does not need engineering revisions or alternative BOMs unless it must handle substitutions. Keep the contract lean.

How do I handle scrap and rework in the data flow?

Define separate messages or fields for scrap and rework quantities. The MES should track scrap at each operation and send the total scrap to ERP at order completion. Rework can be modeled as an additional operation or a separate order, depending on your process.

What if the MES and ERP have different product codes?

You need a mapping table. The contract should use a common identifier (e.g., the ERP material number) and the MES should map its internal code to that. Avoid sending both codes in every message; instead, maintain a master data sync.

Is it better to use REST APIs or message queues for integration?

REST is simpler and good for request-response (e.g., checking order status). Message queues (like MQTT or AMQP) are better for event-driven flows (e.g., production results). Many integrations use both: REST for queries, queues for events. Choose based on your latency and reliability needs.

How often should I sync master data (products, materials, equipment)?

Master data should be synced whenever it changes, but you can batch it (e.g., hourly or daily) if changes are infrequent. The key is to have a trigger-based sync for critical fields (like product recipe) and a periodic full sync for reference data. Avoid real-time for everything.

Related

• Show Values as Percentage in PivotTable: Excel Guide
• Wi-Fi Access Point: What It Is and How It Works
• LoL Worlds Scores & Team Status: Where to Find Them

in t | Finish time | min | 50 | 0
in d | Distance | km | 10 | 0
out pace | Average pace | min/km | t / d | 2
out speed | Average speed | km/h | d / (t / 60) | 2