industrial//industrial communication
Industrial communication is the family of signals, buses and protocols that carry measurements and commands between field devices, controllers and the systems above them in a plant, and it exists because a machine's data must arrive on time, with a known meaning, and fail in a known way. Every member answers the same three questions: who may speak and when, what the bytes mean, and what happens when the link breaks. Office networking answers only the first, and only on average; a valve that opens late because a backup copied files over the same switch is the failure this family was built to prevent (determinism, fault semantics).
Industrial communication is the family of signals, buses and protocols that carry measurements and commands between field devices, controllers and the systems above them in a plant, and it exists because a machine's data must arrive on time, with a known meaning, and fail in a known way. Every member answers the same three questions: who may speak and when, what the bytes mean, and what happens when the link breaks. Office networking answers only the first, and only on average; a valve that opens late because a backup copied files over the same switch is the failure this family was built to prevent (determinism, fault semantics).
The members form a ladder that every plant still contains, each rung born when the one below ran out.
1Analog signalone variable per pair, 4-20 mA2Fieldbusmany devices on one serial line3Industrial Ethernetcontrol traffic on Ethernet with a time bound4Integration layermeaning and distribution, OPC UA and MQTT
At the bottom, a 4-20 mA loop carries one number per pair of wires and reports a cut wire by itself; HART rides digital data on the same loop, and IO-Link replaces the last metres to a sensor with a point-to-point digital link.
One step up, a fieldbus puts many devices on one cable: Modbus on an RS-485 pair, where a master polls each device in turn, and CAN, where every node announces and priority is settled on the wire. Both run over differential signaling and both need bus termination at the two ends, the first thing to check when a serial bus misbehaves.
Industrial Ethernet moves control traffic to Ethernet frames and adds what the office never needed: scheduling, clock synchronization, fast recovery. Reach for EtherCAT when dozens of servo axes move in lockstep, PROFINET or EtherNet/IP when the plant already belongs to one vendor's world, Modbus TCP when a meter only needs reading.
Above control sit the protocols that describe and distribute: OPC UA gives a value its name, unit, quality and timestamp; MQTT hands it to every subscriber without the producer knowing them. Neither closes a fast loop.
Each rung trades simplicity for something the rung below could not give, and none is retired.
A plant of 2026 reads a 1990s HART transmitter, a Modbus meter and an EtherCAT motion line through one edge gateway, and the integration job is translating between rungs, rarely replacing one.
Two traffic shapes run through the whole family. Polling (Modbus, REST) gives the master full control of the timing and wastes the line asking devices that have nothing new; announcing (CAN, MQTT) sends only what changed and needs a rule for who wins when two speak at once.
The physical layer and the protocol are separate standards: RS-485 defines voltages and wiring, Modbus RTU defines the frames on it, and the same Modbus registers travel unchanged over TCP (protocol stack). Most field confusions start by naming one layer and meaning another.
Why not simply REST over the plant network: request-response over a best-effort network offers no bound on the worst case, carries no notion of the physical state a command leaves behind, and treats a timeout as something to retry, while a controller that loses its link must go to a defined safe state.