24 Industrial Protocols: Families and Timing

24.1 Overview

This first route distinguishes industrial communication duties, then traces legacy and Ethernet families through timing, bandwidth, and cycle-time evidence.

This is part 1 of 2. Continue with Industrial Protocols: Selection and Security for the second focused route.

24.2 Start With the Story

A protocol is a shared set of rules for how two machines exchange data. The rule set must fit the job and the harm caused by delay or loss.

Imagine a bottle conveyor that must stop before a jam damages the machine. A status report for next week’s maintenance plan can arrive later. The two messages share a factory, but they do not share the same time limit or failure cost.

Start with the control job. Write who sends, who acts, how fast the action must happen, and what safe state is required when the link fails. Then check update rate, distance, device support, and who can diagnose the network. Use those facts to remove protocol choices that cannot fit.

Prove the short list on the real path. Add busy traffic, a broken cable, and a device restart. Measure the worst result, not only the average. No industrial protocol is best for every loop. A fast cycle does not by itself prove safe timing, and a familiar office network does not by itself fit machine control.

Go deeper in two steps. The Practitioner sections match protocols to control loops and build a selection record. Under the Hood explains scheduling, cycle time, and the boundary between plant and business networks.

Split the plant jobs before naming a protocol. Use one card for a safe stop. Use one for a motion loop. Use one for a machine state. Use one for a trend. Use one for an update. Each card needs its own time, loss, load, and recovery rule.

For each card, name the source and final actor. Mark each control unit, switch, gateway, and service on the path. Put the owner and clock at each step. State the safe state if that step is late or gone. This keeps a plant action tied to a real path.

Make the timing claim exact. State the cycle, worst allowed delay, spread, and clock need. Measure at the end that acts, not only at the sender. Keep the worst valid cycle. A low mean does not prove that every stop arrives on time.

Add the real traffic. Include normal reads, alarms, start-up bursts, tool access, logs, and updates. Run them with the control job. Check that a large file or scan cannot starve the time-critical path. If jobs must be split, record how and where.

Test loss and repair. Break one cable. Turn off one switch. Restart one controller. Fill one queue. Change one device. Record the safe action and the time to return. A second path helps only when the system can move to it in the allowed time.

Keep old plant facts visible. Name the installed devices, supported speeds, wire, connectors, and vendor tools. A new link may add a clean data path while an old controller still sets the real limit. Replacement cost and plant stop time belong in the choice.

Separate plant control from business data. State which values may cross the boundary and who may send a change back. Test a lost outside link and a blocked user. Keep local safety work alive. A shared network must not turn office trouble into an unsafe machine state.

End with a bounded release record. Name the job, path, load, settings, measured worst case, safe failure, owner, and next test. Reopen the choice after a new machine, switch, traffic class, safety need, or plant layout.

Start on a plant floor where machines already speak protocols chosen for timing, reliability, vendor ecosystems, and decades of installed equipment. The story here is how industrial communication choices carry operational meaning, not just packets, across controllers, gateways, historians, and analytics systems.

24.3 Learning Objectives

After completing this chapter, you will be able to:

• Compare industrial protocols (Modbus, PROFINET, EtherCAT, OPC-UA) by latency, throughput, and use case
• Evaluate protocol requirements for different industrial applications based on ISA-95 levels
• Justify protocol selection based on latency, determinism, and security constraints
• Distinguish between legacy serial protocols and modern industrial Ethernet protocols
• Design industrial communication architectures for specific brownfield and greenfield use cases

24.4 Prerequisites

Before diving into this chapter, you should be familiar with:

• Industry 4.0 Fundamentals: Core concepts of Industry 4.0 and ISA-95 automation levels
• Networking Basics: Latency, bandwidth, and reliability fundamentals
• Transport Protocols: TCP/IP and UDP fundamentals

24.5 Protocols Need Timing Fit

An industrial protocol is not selected because it is newer or more fashionable. It is selected because a machine, line, or plant system has a specific timing requirement, failure consequence, installation constraint, and vendor ecosystem. A conveyor status light, a servo axis, a safety interlock, and an ERP production report should not all use the same communication pattern. The right question is what happens if a message is late, duplicated, stale, missing, or accepted by the wrong system.

The first distinction is between monitoring, automation, motion, safety, and integration. Modbus TCP may be acceptable for simple register reads. PROFINET IO or EtherNet/IP may fit distributed I/O and drives. EtherCAT may be needed for tightly synchronized motion. OPC UA may be the right layer for semantic IT/OT integration once the real-time control boundary is protected. MQTT Sparkplug B may help publish normalized telemetry upward, but it should not be confused with a deterministic fieldbus for closed-loop control.

Industrial protocol decisions also have long memory. Plants may run equipment for 20 or 30 years, with spare parts, electrician skills, PLC programming tools, vendor support contracts, cable trays, and downtime windows already fixed. A greenfield packaging line can optimize around a modern motion network. A brownfield water plant may need to preserve Modbus RTU instruments and add gateways, diagnostics, and security segmentation around them.

• Monitoring: Read values for dashboards, historians, alerts, or maintenance without directly controlling the machine.
• Automation: Exchange I/O and commands between PLCs, drives, remote I/O, and machine controllers within a bounded cycle time.
• Integration: Move contextualized plant data toward SCADA, MES, CMMS, historian, analytics, or cloud systems.

A defensible selection records the loop type, timing budget, safety role, ownership boundary, installed base, security zone, and lifecycle plan before naming a protocol. That keeps teams from using a cloud-friendly protocol where determinism is needed, or using a high-speed motion bus where the real problem is semantic integration and asset context.

24.6 Match Protocol to Control Loop

Start by writing the required cycle time, jitter tolerance, distance, topology, safety role, and ownership boundary. A 100 ms tank-level trend can tolerate retry and buffering. A 1 ms drive loop cannot wait for a broker, VPN, or cloud API. A brownfield Modbus RTU segment may be left in place and bridged, while a new motion cell may justify EtherCAT or PROFINET IRT. The same plant can therefore use several protocols at once, each with a different responsibility.

Protocol choice also follows vendor and tooling realities. Siemens-heavy plants often standardize on PROFINET and TIA Portal. Rockwell/Allen-Bradley plants often use EtherNet/IP with CIP objects and Studio 5000. Beckhoff and many motion-control systems use EtherCAT. Legacy panels may expose Modbus RTU over RS-485 or Modbus TCP. Integration layers may use OPC UA, MQTT Sparkplug B, or historian connectors. Maintenance teams must be able to diagnose the chosen stack at 2 a.m., not only during a vendor demo.

The selection tree in the linked figure in Part 2 turns these constraints into an inspection order: start with cycle time, then account for determinism, safety, installed assets, and the boundary where plant data moves into integration systems.

1. Classify the loop. Separate human-visible monitoring, PLC I/O, motion control, safety, and enterprise integration.
2. Set timing numbers. Capture update interval, maximum jitter, timeout behavior, and stale-data action before naming a protocol.
3. Respect installed assets. List PLC family, drives, remote I/O, gateways, cable plant, maintenance tools, and available downtime windows.
4. Plan the boundary. Keep real-time protocols inside the cell or line, then publish cleaned context upward through OPC UA, Sparkplug B, a historian, or MES interface.

For a practical selection review, ask for an example message path. A temperature trend might move from a Modbus RTU transmitter to a gateway, then to OPC UA, then to a historian and dashboard. A robot-axis command might stay inside EtherCAT or PROFINET IRT and never cross the enterprise boundary. A plant KPI might be aggregated by an edge node and published through MQTT after quality checks. These paths reveal where latency, safety, cybersecurity, and ownership actually sit.

24.7 Determinism Needs Scheduling

Industrial Ethernet does not automatically make a network deterministic. PROFINET RT prioritizes cyclic I/O on Ethernet, PROFINET IRT adds reserved time windows for tighter synchronization, EtherNet/IP uses CIP objects and can use CIP Sync with IEEE 1588 PTP, and EtherCAT processes frames as they pass through each slave. These details explain why two protocols with similar cable connectors can behave very differently under load. Determinism comes from scheduling, clocking, frame handling, switch behavior, and device implementation, not from the word Ethernet alone.

Legacy protocols have different tradeoffs. Modbus RTU over RS-485 is simple and widely deployed, but it is request-response, usually single-master, and carries registers rather than rich semantics. PROFIBUS DP and DeviceNet solved many fieldbus needs before Ethernet became common. IO-Link often connects smart sensors and actuators to a master that then speaks PROFINET, EtherNet/IP, or another higher-level protocol. These protocols can still be correct when downtime, replacement cost, or certification risk makes wholesale migration unattractive.

Modern designs increasingly combine protocol layers. A drive network may stay on EtherCAT, an I/O island may use PROFINET, a gateway may expose an OPC UA server, and a DMZ broker may publish Sparkplug B topics to analytics systems. Time synchronization, VLANs, QoS, firewall rules, certificate management, firmware compatibility, and spare-part availability become part of the protocol decision. IEC 62443 zones and conduits help decide which messages can cross from cell, area, site operations, and enterprise networks.

• Timing machinery: Look for cyclic scheduling, PTP/IEEE 1588 clocking, time-aware shaping such as TSN IEEE 802.1Qbv, and device-rated update times.
• Data machinery: Distinguish raw coils/registers, CIP objects, PROFINET GSDML descriptions, EtherCAT ESI files, IO-Link IODD files, and OPC UA information models.
• Operations machinery: Check diagnostics, packet capture support, replacement-device commissioning, firmware policy, and who can troubleshoot the network at 2 a.m.

Testing should match the consequence. A monitoring gateway may need stale-data flags, retry behavior, and historian gap handling. A motion cell needs cycle-time and jitter tests under worst-case load. A safety-related network needs certified devices, validated safety functions, and a change-control process. A cloud integration path needs proof that no inbound enterprise connection is exposing a control system. The selected protocol is only credible when those evidence paths are defined.

24.8 Introduction

Industrial environments require specialized communication protocols that differ fundamentally from consumer IoT protocols. Where consumer IoT can often tolerate delayed or retried status updates, industrial control loops may need bounded cycle times, predictable jitter, and explicit stale-data behavior. This chapter explores the protocols that make modern manufacturing and plant integration possible.

24.9 Protocol Requirements

24.10 Industrial Protocol Evolution

The following diagram shows how industrial communication protocols evolved from simple serial protocols toward fieldbus, Ethernet-based control, and IT/OT convergence standards:

Figure 24.2 answers why one modern plant still runs protocols that were designed forty years apart.

Read Figure 24.2 downward and watch the problem being solved change twice. The early entries, from Modbus in 1979 through the fieldbuses, answer a physical question: how to get rugged, predictable access to a shared bus. The middle block moves onto Ethernet without giving up determinism, which is why 2003 produces two different answers in one year, one dividing time into slots and one passing a single frame through every device. The last entry changes the question again, because OPC-UA is not competing on speed. It adds security and a described data model so plant information can safely leave the plant floor.

Inspect Figure 24.3 to compare the data-motion pattern each industrial protocol family is built to serve.

Read Figure 24.3 across four different jobs. Modbus has one master poll registers, which suits simple monitoring and brownfield links. PROFINET organizes controller-device exchange as cyclic I/O, with IRT tightening the timing for motion. EtherCAT passes one frame through each device and back, enabling sub-millisecond cycles across flexible topologies. OPC UA instead gives SCADA, MES, and IT clients structured plant information. The comparison is not a speed ranking: control timing, topology, and semantic integration determine where each pattern belongs.

24.11 Legacy Industrial Protocols

24.11.1 Modbus (1979)

Modbus is one of the oldest and most widespread industrial protocols:

Characteristics:

• Simple: Easy to implement, minimal overhead
• Master-slave: Single master polls multiple slaves
• Serial or TCP/IP: Modbus RTU (serial) or Modbus TCP (Ethernet)
• Limited: 247 devices per network, no built-in security
• Still widely used: Large installed base in utilities, building systems, and brownfield industrial sites

Figure 24.4 answers both halves of the Modbus reputation: why it is so easy to bridge, and what it cannot do.

One box in Figure 24.4 holds the initiative. The master sends a request, a single device answers, and the numbered sequence beneath shows the cycle repeating around the bus. Nothing on the lower row can speak on its own, so a sensor with urgent news waits its turn, and that is the cost of the design. The benefit is in the same picture. Every device is just an address holding registers, which is why the protocol maps onto serial wiring or Ethernet with equal ease and why bridges to newer systems are simple to build. The address limit printed at the foot caps one network at a few hundred devices. Together these explain the long installed base and the modern gateway sitting in front of it. Typical applications: Building automation, energy management, simple machine control

24.12 Modern Industrial Ethernet

24.12.1 PROFINET (2003)

Siemens’ industrial Ethernet successor to PROFIBUS:

Performance tiers:

• PROFINET IO: Standard I/O, <100 ms cycle time
• PROFINET IRT (Isochronous Real-Time): <1 ms, deterministic, motion control
• PROFINET CBA: Component-based automation

Inspect Figure 24.5 to see how cyclic control and ordinary configuration traffic share Ethernet without receiving the same timing treatment.

Begin Figure 24.5 at the shared Ethernet hardware, then separate the traffic classes above it. Standard PROFINET RT gives cyclic I/O priority over ordinary traffic. IRT reserves time windows for tighter synchronization and motion workloads below one millisecond. Configuration, diagnostics, and IT-style exchanges remain in the non-real-time layer on the same backbone. The key distinction is scheduling, not the cable: industrial Ethernet does not become deterministic merely because control devices use it. A design must select the timing class and configure the network that enforces it. Key features:

• Uses standard Ethernet hardware
• Backward compatible with PROFIBUS via proxies
• Supports web services and IT integration
• Large installed base in Siemens-centered automation ecosystems

24.12.3 EtherCAT (2003)

Ethernet for Control Automation Technology, ultra-low latency:

Architecture:

Figure 24.6 answers how EtherCAT reaches such short cycles on ordinary Ethernet hardware.

Follow the single frame across Figure 24.6. The master sends one Ethernet frame into a chain of devices, passing a drive, an input module, a sensor and a robot. Each marker along the way carries the key idea, because a node reads its own inputs and writes its own outputs while the frame is still moving past, in hardware, rather than receiving it and sending it on. The return path then brings the whole set of answers back in one piece. Compare that with a scheme where the controller addresses each device in turn. Here the cost of adding another node is a few nanoseconds of delay, not another round trip, which is how one pass can serve a thousand points. Performance:

• Cycle time: Can be engineered into sub-millisecond ranges for suitable motion and I/O systems
• Jitter: Controlled jitter is critical for synchronized motion
• Topology: Line, tree, star, or any combination
• Data processing: Each slave processes data as frame passes through

Putting Numbers to It

EtherCAT can achieve short cycle times through its “processing on-the-fly” architecture. The example below is illustrative; always verify device-level timing with vendor data and load tests.

$\text{Per-node delay} = 25 \text{ ns (ASIC hardware processing)}$ $\text{Total propagation delay} = 1,000 \times 25 \text{ ns} = 25 \mu\text{s}$

Adding Ethernet frame transmission time for 1,500 bytes at 100 Mbps:

$\text{Frame transmission} = \frac{1,500 \times 8}{100 \times 10^6} = 120 \mu\text{s}$

Total cycle time in this simplified model is $25 \mu\text{s} + 120 \mu\text{s} = 145 \mu\text{s}$. Real results depend on frame size, node count, device implementation, topology, synchronization settings, and other traffic on the network.

Use cases: High-speed motion control, packaging machines, robotics

EtherCAT Cycle Time

Calculate total EtherCAT cycle time based on number of nodes and frame size.

Understanding the calculation:

• Per-node delay: 25 nanoseconds (EtherCAT ASIC hardware processing)
• Propagation delay: Time for frame to pass through all nodes
• Frame transmission: Time to send frame on wire at link speed
• Total cycle time: Sum of propagation + transmission

Performance targets:

• < 100 μs: High-speed motion control, synchronized robotics
• < 1 ms: General factory automation, synchronized drives
• < 10 ms: Process control, monitoring applications

Figure 24.7 grounds the protocol discussion in a closed-loop industrial decision: measure residual chlorine downstream, compare it with the allowed band, and adjust the dosing pump while preserving mixing and contact time.

Follow Figure 24.7 from inlet flow and chlorine dose through mixing to the residual sensor. The PLC compares the measured 0.68 mg/L with the 0.5–1.0 mg/L target band; the decision remains hold unless a bounded adjustment is justified. The evidence ledger must preserve sensor calibration, sample time, command, alarm state, and operator ownership, because a fast protocol cannot repair an untrustworthy measurement or an unsafe fallback.

Water treatment automation demonstrates critical infrastructure IoT where precise control directly impacts public health. Chlorination systems maintain safe disinfection levels while optimizing chemical consumption through real-time feedback control.

24.13 Continue to Part 2

Continue with Industrial Protocols: Selection and Security.