100 Industrial Protocols: Families and Timing

100.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.

100.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.

100.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

100.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

100.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.

100.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.

100.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.

100.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.

100.9 Protocol Requirements

100.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:

Inspect Figure 100.2 before this decision: Industrial Protocol Evolution must be judged beside 1979 Modbus. Together Industrial Protocol Evolution and 1979 Modbus bound this claim.

Industrial Protocol Evolution begins the diagram in Figure 100.2; locate Industrial Protocol Evolution, compare 1979 Modbus, and verify Serial polling for PLCs, meters. Industrial Protocol Evolution states the starting condition; 1979 Modbus supplies its counterpart; Serial polling for PLCs, meters limits the conclusion; retain its labelled boundary.

Inspect Figure 100.3 before this decision: Industrial Protocol Architecture Comparison must be judged beside Modbus, PROFINET, EtherCAT, OPC-UA — Topology and. Together Industrial Protocol Architecture Comparison and Modbus, PROFINET, EtherCAT, OPC-UA — Topology and bound this claim.

Industrial Protocol Architecture Comparison begins the diagram in Figure 100.3; locate Industrial Protocol Architecture Comparison, compare Modbus, PROFINET, EtherCAT, OPC-UA — Topology and, and verify Modbus — Master-Slave Star. Industrial Protocol Architecture Comparison states the starting condition; Modbus, PROFINET, EtherCAT, OPC-UA — Topology and supplies its counterpart; Modbus — Master-Slave Star limits the conclusion; retain its labelled boundary.

100.11 Legacy Industrial Protocols

100.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

Pause at Figure 100.4 before carrying modbus (1979) forward. Its visual vocabulary joins Modbus Master-Slave Architecture to Polling-based communication: master initiates all, which frames modbus keeps the communication model simple: one master polls register data from slave devices, which makes it easy to bridge but limited for rich.

Within the diagram, Modbus Master-Slave Architecture opens Figure 100.4; Polling-based communication: master initiates all provides the counterpoint, and Master (PLC) closes the inspection. This reading constrains modbus keeps the communication model simple: one master polls register data from slave devices, which makes it easy to bridge but limited for rich and supplies the visual evidence for modbus (1979). Typical applications: Building automation, energy management, simple machine control

100.12 Modern Industrial Ethernet

100.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

Pause at Figure 100.5 before carrying profinet (2003) forward. Its visual vocabulary joins PROFINET Network Tiers to Real-Time and Non-Real-Time Layers, which frames profinet separates deterministic cyclic i/o traffic from non-real-time configuration, diagnostics, and it-style traffic.

Figure 100.5 places PROFINET Network Tiers alongside Real-Time and Non-Real-Time Layers. Treat SHARED INDUSTRIAL ETHERNET BACKBONE as the diagram qualifier for profinet separates deterministic cyclic i/o traffic from non-real-time configuration, diagnostics, and it-style traffic. That labelled limit reconnects the visual to profinet (2003). 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

100.12.3 EtherCAT (2003)

Ethernet for Control Automation Technology, ultra-low latency:

Architecture:

To test ethercat (2003), open the diagram in Figure 100.6. EtherCAT Network Architecture supplies one named condition; Master-slave daisy-chain topology with on-the-fly frame supplies the necessary comparison for ethercat network architecture showing master-slave topology: the ethercat master sends a single frame through each slave in sequence, and each device.

Trace the visual from EtherCAT Network Architecture to Master-slave daisy-chain topology with on-the-fly frame in Figure 100.6; verify EtherCAT before concluding. Together those labels make ethercat network architecture showing master-slave topology: the ethercat master sends a single frame through each slave in sequence, and each device testable. Apply their boundary when working through ethercat (2003). 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 100.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 100.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.

100.13 Continue to Part 2

Continue with Industrial Protocols: Selection and Security.