A machine could run on ordinary office Ethernet — until the moment it has to stop on time. Fieldbuses and industrial Ethernet protocols exist because a production line needs guarantees that a network built for email never had to give.
Every few months a buyer asks us a fair question: why does a machine need PROFINET, EtherNet/IP or EtherCAT at all, when the plant already has a perfectly good Ethernet network and every device on the market has an RJ45 socket? The cables look the same, the connectors often look the same, and the price of an industrial switch compared with an office one invites the suspicion that someone is being charged for a label. The honest answer is that the cable is the least important part of the story. What an industrial protocol sells is not speed and not bandwidth. It is a promise about time, and a set of rules about what happens when something goes wrong.
Before networks: one pair of wires per signal
To see why the protocols exist, start with what they replaced. Until the late 1980s a machine was wired in parallel: every limit switch, every valve coil and every analogue sensor had its own pair of conductors running back to the controller, a 24 V signal for on and off, a 4–20 mA loop for a measurement. It was simple and utterly deterministic — a signal was there the instant the switch closed — but it did not scale. A mid-size line could carry thousands of conductors, each a termination to make, a label to maintain and a fault to find when a core broke inside a cable carrier. The wiring cost more than the controller, and the documentation was always one modification behind.
Fieldbuses such as PROFIBUS, which dates from the late 1980s, DeviceNet, and Modbus, which is older still, collapsed those bundles into a single cable. Remote I/O stations sat next to the sensors, and the controller exchanged all of their data over one twisted pair in a fixed cycle. That was the first promise an industrial network made: every device would be read and written within a known, repeatable time. Office networks never had to make that promise, because a web page that loads forty milliseconds late does not crush anybody’s hand.
Why ordinary Ethernet is not enough
Ethernet eventually won on the plant floor for the same reasons it won everywhere else: it is fast, cheap, universal, and every engineer already understands it. But standard Ethernet with TCP/IP is built on best effort. A frame is delivered when the switches have room for it, a lost packet is retransmitted when the stack notices, and the operating system at each end schedules the work when it gets around to it. On average that is fast. At the worst moment it is unpredictable, and a motion axis or a safety function is judged by its worst moment, not its average. A drive that receives its setpoint two milliseconds late on one cycle in ten thousand will leave a mark on the part, and nobody will be able to reproduce it.
Industrial Ethernet protocols keep the physical layer and replace the part that was never designed for the job. PROFINET, maintained by PROFIBUS & PROFINET International and standardised in IEC 61158 and IEC 61784, is a good example because it shows the layering openly. Configuration, parameter access and diagnostics travel over ordinary TCP/IP, where a few milliseconds of uncertainty do not matter. Cyclic process data travels as PROFINET RT: frames with their own EtherType that bypass the TCP/IP stack entirely, are prioritised in the switches, and arrive with update times of a few milliseconds. For motion control there is IRT, isochronous real-time, in which the network hardware reserves a time slot in every cycle, so cycle times well below a millisecond are held with jitter in the microsecond range, regardless of what other traffic shares the wire.
What a protocol actually defines
Timing is only half of it. The larger value of a protocol like PROFINET is that it defines how devices describe themselves, how they are found, and how they report trouble. Every device ships with a GSDML file, an XML description of its modules, parameters and diagnostic messages, which the engineering tool imports so that the controller knows exactly what it is talking to. Devices are addressed by a name rather than by a number someone set on a front panel, and the controller assigns the IP address to that name at start-up. From conformance class B upwards, each device also learns who its neighbours are, so the controller holds a map of the real topology. The practical result is one of the most underrated features in automation: an electrician can replace a failed I/O module with a new one straight out of the box, and the controller recognises the port it is plugged into and configures it — with no laptop and no programmer on the night shift.
Diagnostics follow the same logic. A broken wire, a short circuit on an output, a module pulled under power or a cable with too many transmission errors is reported as a structured alarm tied to a device, a slot and a channel. The HMI can say which sensor on which station has failed, instead of the machine simply stopping and leaving someone to walk the line with a multimeter. For a plant manager this is the real return on the protocol. PROFINET did not make machines dramatically faster than the fieldbuses before it. It made them answerable.
The same layering carries safety. PROFIsafe runs on top of the standard PROFINET channel and treats that channel as untrusted: every safety telegram carries its own sequence number, watchdog time and checksum, so a delayed, repeated, corrupted or misrouted message is detected by the receiver and the machine goes to a safe state. That black-channel principle is what allows an emergency stop, a light curtain and a guard door switch to share a cable with ordinary I/O and still reach SIL 3 to IEC 61508 and PL e to ISO 13849. The alternative — a separate hard-wired safety circuit threaded through every station — is exactly the kind of wiring the protocols were invented to remove.
Why there is more than one
If the problem is shared, the obvious next question is why the industry never settled on one answer. Part of it is engineering. EtherCAT, developed by Beckhoff and now managed by the EtherCAT Technology Group, processes a single frame on the fly as it passes through every device, which makes it exceptionally fast for tightly synchronised motion. EtherNet/IP, supported by ODVA, carries the CIP object model over standard TCP and UDP and fits naturally into networks that IT already manages. CC-Link IE, POWERLINK and Modbus TCP each made different trade-offs between speed, cost and simplicity. Most of it, though, is history and geography. A protocol travels with its controller platform: PROFINET dominates where Siemens controllers dominate, which includes much of Europe and Türkiye; EtherNet/IP is the default in plants built around Rockwell equipment in North America; CC-Link is common in supply chains led from Japan.
For a machine builder, that means the protocol is rarely a free choice. It follows the end customer’s plant standard, and a machine shipped to a German automotive plant and its sister machine for a North American one may need different networks around identical mechanics. It is also why OPC UA, often described as a replacement, is better understood as a different layer. OPC UA is excellent at carrying structured information from the machine to MES and cloud systems, and the work under the OPC UA FX name, together with time-sensitive networking, aims to bring it down to the field level. Today the fast cyclic loop inside a machine is still run by a fieldbus protocol, and OPC UA sits above it.
What this means when a panel is built
A network protocol lives or dies in the control cabinet, which is where most of the problems we are later asked to find actually begin. PROFINET runs at 100 Mbit/s over four-core shielded cable, with RJ45 connectors inside the cabinet and D-coded M12 connectors in the field, and copper segments are limited to 100 metres. The rules are unglamorous and they matter: shields terminated at both ends and bonded to a clean equipotential bar, network cables routed away from motor cables, line topologies kept short enough that one failed device does not isolate half the machine, and a ring with the Media Redundancy Protocol wherever the machine cannot afford to stop for a single broken cable.
We treat the network as a drawn part of the machine rather than an afterthought. Device names, IP ranges, port-to-port connections and switch locations belong in the EPLAN model next to the power distribution, and the test at the end of a panel build includes the network: every device found under its planned name, the topology matching the drawing, and no transmission errors under load. When the machine is commissioned on site, that record is what turns a vague communication fault into a specific port on a specific switch.
So the short answer to the buyer’s question is this. Ordinary Ethernet moves data. An industrial protocol moves data on time, knows what every device on the network is, tells you precisely what has failed, and carries safety over the same cable without trusting it. That is what the extra cost of an industrial switch and a green cable pays for — and on a line that loses money every minute it stands still, it is usually the cheapest part of the machine.
— GANI Engineering engineering team