Systems Architecture
MES, ERP and SCADA Boundaries: Draw Lines by Object Ownership, Not Department
The direct answer for dividing MES, ERP and SCADA boundaries is to confirm, object by object, who creates, modifies, executes, retains and reconciles. ERP typically owns enterprise resources and business planning; MES owns shop-floor execution and process coordination; SCADA owns equipment-process monitoring, alarms and history; PLC and safety-related control remain in validated control systems. Boundaries are designed around objects, states, time and accountability, not guessed from software names.
The Three System Layers Answer Different Questions
ERP concerns what to produce, which resources are needed and how business results are posted. MES concerns how a work order executes on specific lines and workstations and how current progress and abnormalities are coordinated. SCADA concerns current equipment state, changing process values, and how alarms and history can be replayed.
These responsibilities overlap, but overlap does not mean storing the same state repeatedly. A work order can be planned and owned by ERP, decomposed and executed with shop-floor status in MES, and shown only as equipment-related task context in SCADA. The fields and states stored by each system must be explicit, with no arbitrary bidirectional rewriting of the same field.
| Layer | Typical primary responsibility | Should not be assumed to own | Key time scale |
|---|---|---|---|
| ERP and other enterprise systems | Planning, orders, materials and finance-related master data | Millisecond equipment control and raw process acquisition | Orders, shifts, days and accounting periods |
| MES shop-floor execution | Work-order execution, station transactions, error-proofing, traceability and shop-floor coordination | Replacing all business planning or low-level safety control | Work orders, lots, workstations and events |
| SCADA process supervision | Real-time status, process trends, alarms and operator displays | Enterprise costing and all execution workflows | Real-time signals, process events and historical trends |
| PLC and equipment control | Equipment logic, motion and validated control interlocks | Enterprise master data and cross-shop business coordination | Control cycles and immediate interlocks |
Use an Object-ownership Matrix to Eliminate ‘Everyone Owns It’
The ownership matrix should cover at least work orders, materials, products or lots, process versions, equipment, quality results and planning calendars. For every object, list its creator, unique identifier, modifiable states, downstream subscribers and deletion or voiding rules.
For example, ERP may maintain material codes, MES may retain the snapshots needed for execution and lot consumption, and SCADA may use only the necessary equipment context. If temporary material substitution is permitted on the shop floor, an explicit business process must approve and return it; operators must not be able to edit master data directly at any arbitrary layer.
| Business object | Common ownership example | Downstream use | Exception that must be agreed |
|---|---|---|---|
| Work order | Created by ERP and decomposed for execution by MES | SCADA obtains current task context | Cancellation, rush insertion, quantity change and failed completion feedback |
| Materials and lots | Enterprise master-data and warehouse ownership determined by the current landscape | MES records error-proofing, issue and lot relationships | Substitution, returns, splits, merges and missing identity |
| Process version | Process-owned system or controlled workflow | MES validates the execution version; equipment receives approved parameters | Version effectiveness, rollback and temporary shop-floor adjustment |
| Product quality | Quality-disposition ownership determined by the workflow | MES links the creating process and disposition | Rework, reinspection, concession and result withdrawal |
| Equipment status | SCADA or the acquisition layer records the raw facts | OEE and MES use mapped business states | Disconnection, clock drift, manual revision and state conflicts |
APS, WMS and QMS Should Not Be Assumed to Belong Inside MES
APS focuses on constraint-based planning and scheduling, WMS on inventory, locations and warehouse operations, and QMS on quality planning, inspection and quality workflows. They can work closely with MES, but whether they should be independent systems depends on the existing landscape, business complexity and responsibility boundaries. MES does not inherently include every capability.
ORPAON can undertake project-specific production-scheduling algorithms, WMS interfaces, quality traceability and related integration or customization. This does not imply that mature standalone APS, WMS or QMS products already exist. Every proposal should state item by item whether the customer's existing system, a third-party system or project-specific customization provides the capability, rather than using ‘all-in-one’ to conceal gaps.
- Planning boundary: who considers capacity and material constraints, who approves the plan, and who handles rush orders on the shop floor.
- Warehouse boundary: who manages locations and inventory records, and who executes material calls, delivery and returns.
- Quality boundary: who maintains inspection specifications, who makes disposition and release decisions, and who records the creating process.
- Maintenance boundary: who owns the preventive-maintenance and repair workflows; Andon and OEE provide only the necessary events.
- Analytics boundary: who retains raw process data, who calculates business metrics, and who owns definition versions.
Interface Design Needs Contracts, Recovery and Reconciliation
An interface is more than a field list. It needs trigger timing, unique message or call identifiers, idempotency rules, timeout, retry, sequencing, permissions, error codes and a manual recovery entry point. Work-order release and completion feedback in particular must prevent duplicate execution and lost states.
Reconciliation is part of the interface loop. Systems should compare quantities, states and versions of critical objects on both sides and display differences. Which side may continue during a network outage and the backfill sequence after recovery must be decided jointly from business and control risks.
| Contract item | What must be defined | Correct handling on failure |
|---|---|---|
| Triggers and idempotency | When to send and how to prevent duplicates | Query using a unique business key or retry safely |
| State and sequence | Permitted state transitions and whether messages are ordered | Reject invalid transitions and retain a pending queue |
| Timeout and retry | The project defines failure timeout and retry count | Distinguish unknown outcomes from confirmed failures to avoid blind repetition |
| Version and effectiveness | When master data and process versions become usable | Block versions that are not yet effective or have been withdrawn |
| Reconciliation and recovery | Who detects differences and who is authorized to resolve them | Retain discrepancy records, approvals and a complete audit trail |
Validate Boundaries Through One End-to-end Business Chain
Do not draw every architecture diagram before looking for a use. Choose a representative business chain, such as work-order release, material verification, equipment execution, quality disposition and completion feedback. Mark object ownership, state changes and exception handling step by step to reveal the real boundaries.
Testing should cover not only the normal path but also interface timeouts, duplicate messages, master-data withdrawal, shop-floor rework, equipment disconnection and manual backfill. Boundaries are implemented only when abnormal paths also have ownership and recovery methods.
- Inventory the current landscape: existing systems, versions, interfaces, data owners and operating constraints.
- Build the object matrix: confirm ownership item by item instead of substituting department names for system responsibility.
- Define minimal interfaces: support the selected business chain first and avoid synchronizing all data at once.
- Rehearse abnormal paths: validate retry, recovery, reconciliation, disconnection and manual authorization.
- Establish an operating contract: include monitoring, support coverage, change and version management in acceptance and operations.
Avoid the All-in-one, Real-time-everything and Bidirectional-synchronization Fallacies
An ‘all-in-one platform’ does not mean one system must perform every function, and ‘real-time synchronization’ does not mean every datum requires millisecond transmission. Business orders, lot execution and fast process signals have different time scales and consistency requirements; mixing them creates unnecessary complexity.
Bidirectional synchronization is not the default optimum. Allowing multiple systems to modify the same object freely encourages update loops and unclear accountability. A safer pattern is explicit ownership, one-way publication and controlled write-back, with approval and audit records for every exception.
- Do not substitute software names for responsibility definitions.
- Do not measure interface completeness by field count.
- Do not make SCADA directly handle unassessed enterprise business transactions.
- Do not let MES bypass established control and safety boundaries to issue high-risk actions directly.
- Do not describe undetermined APS, WMS, QMS or TPM capabilities as standard existing products.
Clear Boundaries Make Integration Maintainable
Sound boundaries among ERP, MES and SCADA arise from object and state ownership, not software market labels. Establishing who creates, modifies, executes and reconciles before designing screens and interfaces reduces duplicate construction and mutual overwriting.
During implementation, validate normal and abnormal paths through one end-to-end business chain and identify the provider of each adjacent APS, WMS and QMS capability. The resulting multi-system collaboration is easier to accept, operate and evolve than a vague all-in-one promise.
Frequently asked questions
If both MES and ERP store work orders, is that duplicate construction?
Not necessarily. ERP can retain the planning and business view, while MES retains execution decomposition, workstation progress and shop-floor status. The key is to define their respective fields, states and synchronization directions rather than allowing both sides to modify the same object without rules.
Can SCADA directly replace MES?
Usually not as a simple substitution. SCADA excels at equipment-process supervision and history, while MES excels at work orders, station transactions, error-proofing, lots and business coordination. Small scenarios may combine selected functions, but ownership of execution transactions and data consistency must still be explicit.
Does ERP also need to receive all real-time equipment data?
Usually not. ERP needs business-defined completion, consumption or status results. Raw high-speed process data can remain in the acquisition or historian layer, with MES or data services providing the necessary summaries.
Must an existing WMS or QMS be replaced by MES modules?
Replacement should not be the default. First assess whether the existing system meets ownership and interface requirements. If stable interfaces support collaboration, rebuilding merely for visual uniformity is unnecessary. Any replacement requires a separate assessment of migration, process and operational risks.
