Integration with plant systems is often checked last, during commissioning. That is the first time a running line meets the system meant to direct it. An error in the interface then holds up not only the system tests but the ramp-up as well.
A process model makes it possible to separate the two. The higher-level system can talk to a model that behaves like the line: it takes an order, runs cycles, rejects defective parts and reports stops.
The system layers
The split into layers is described by the ISA-95 standard (IEC 62264). System names and responsibilities differ between plants, so the first step is to agree which system is the source of which information.
| Layer | Typical responsibility | Time horizon |
|---|---|---|
| ERP | Production orders, materials, schedules, costs | Days and weeks |
| MES | Running orders on the line, product genealogy, OEE | Minutes and hours |
| PLCs and robots | Sequences, interlocks, signals, recipes | Milliseconds and seconds |
ERP does not usually talk directly to a controller. An order passes through MES or an intermediate layer, and the line sees only what it needs in order to work.
What data flows
| Information | Direction | Example |
|---|---|---|
| Order and recipe | System to line | Product variant, quantity |
| Part identity | Both ways | Lamp serial number |
| Part history | Line to system | The stations that worked on the lamp |
| Test result | Line to system | Result of the S70 functional test, good or reject lane at S90 |
| Counters and times | Line to system | Good and rejected parts, takt, work, waiting and fault time of each station |
| Stock levels | Line to system | Use per lamp, refill requests |
The signal list is created in stage 2 together with the programs, so the interface can be described with the same names and addresses the control logic uses.
What a test on the model looks like
The model sees the plant through the process image, as a controller does. The interface to the higher-level system can therefore run against the model, and move to the line once the equipment is delivered. Communication with controllers uses standard protocols such as OPC UA and S7.
The events most worth checking on the model are those that are hard to trigger on demand on a line:
- Order start and end: whether the line accepts the order, counts parts and finishes in the right state.
- Variant change: whether the recipe reaches the right stations, including while parts from the previous order are still on the line.
- Reject: whether a defect found in the test goes into the history of the right part.
- Fault and restart: whether a station stop is reported with the right cause, and whether the counter is correct after the restart.
- Material shortage: whether the refill request appears in time.
- Lost connection: what the line does when the higher-level system does not respond, and whether data is filled in when the connection returns.
Each of these cases can be repeated as often as a fix requires, without stopping production and without scrap.
What the plant gets from this
- The MES supplier can start earlier. It tests its configuration against the behavior of the line, not against mock signals.
- Definitions are agreed before ramp-up. It is clear what counts as a good part, a stop and the end of a cycle, and OEE counters work the same way from the start.
- Commissioning is about the line. Less time on site goes into working out which side of the interface an error is on.
Limits
A test on the model checks the logic of the data exchange. It does not replace the configuration of the MES or ERP itself, load testing, a check of the plant network or a cybersecurity assessment, for example to IEC 62443. The connector to a specific system and the scope of the exchange are agreed in the project, together with that system’s supplier and the plant’s IT department.
