industrial//industrial data layer//fault semantics

2026-09-06

Fault semantics is the part of a communication protocol that reports how data failed (a device that fell off the bus, a stale value, a lost connection) as information the receiver can act on, and it is one of three properties a control link needs that a request-response web API does not offer. The other two are determinism and physical state, and together they are why industrial control does not run on a REST API.

REST is excellent at requests such as give me order 1234, create this user or fetch this report: stateless requests, one answer each, at IT speeds (REST). Control needs cyclic updates, a watchdog, data quality, timeouts, connection state, change-of-value notification, alarms, precise timestamps and a predictable time behavior (determinism).

The failure model is the core difference. An HTTP 500 cannot say that the physical transmitter lost power and the last valid measurement is 3.8 seconds old: a control loop needs to tell no answer yet, a device that is gone and a value that is stale apart, and a status code collapses all three. Control protocols carry that: a tag has a quality and an age, a fieldbus knows a device fell off the bus, an OPC UA subscription reports a lost connection as data, not as an exception.

The receiver of a control link has a defined reaction to silence. A drive that stops hearing its PLC within a watchdog time ramps the motor down; a remote I/O module that loses its network sets its outputs to a configured safe value; a web client that times out simply retries. Retrying is harmless for a read and dangerous for a command that already took effect, which is why commands on the plant floor are written as states to reach rather than increments (MQTT QoS).

REST is perfectly valid above the control layer, between business applications and toward the cloud; it is the wrong tool as a substitute for PROFINET, EtherCAT or OPC UA at the bottom (HTTPS).