Industrial software sits next to hardware, but that does not mean the entire application should speak in hardware-specific vocabulary.
When an MES consumes machine state, I prefer to define an application-layer contract first: the states, events, timestamps, identifiers and quality guarantees the software actually needs. The PLC or infrastructure provider can then map device-specific signals into that contract.
Why the boundary matters
Without a contract, low-level details spread quickly. Screens start depending on individual signals. Planning logic learns device naming conventions. Tests require hardware-shaped fixtures. A future PLC change becomes an application rewrite.
A stable contract reverses that dependency.
The MES can reason about concepts such as availability, active operation, counters or alarms while the integration layer owns the translation from physical infrastructure.
Specify uncertainty too
A useful machine-state contract should describe more than field names. It should also define:
- timestamp semantics;
- stale-data behaviour;
- reconnect behaviour;
- unknown or partial state;
- idempotency expectations;
- ordering guarantees where relevant.
Those edge conditions usually matter more in production than the happy-path payload.
The practical rule
Integrate with the machine boundary, not with every machine detail. Keep the operational model stable and make infrastructure-specific translation replaceable.