---
title: "Keep machine integration behind an application contract"
description: "MES software should model the state it needs from machines without letting PLC-specific details leak across the rest of the application."
publishedAt: "2026-05-30"
draft: false
featured: false
category: "Architecture"
readingMinutes: 5
tags: ["MES", "PLC", "architecture", "contracts"]
---

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.