7.2 Industrial Ethernet & Open Protocols (EtherNet/IP, PROFINET, OPC UA, MQTT)

7.2 Industrial Ethernet & Open Protocols (EtherNet/IP, PROFINET, OPC UA, MQTT)

Over the past two decades, standard commercial Ethernet (IEEE 802.3) has evolved from an office-bound local area network into the dominant backbone of modern industrial automation. However, deploying Ethernet on the plant floor required overcoming severe inherent limitations in commercial networking—specifically non-deterministic packet collisions, physical environmental vulnerabilities, and lack of standardized real-time application profiles.

Today, industrial automation architectures rely on standardized Industrial Ethernet protocols (EtherNet/IP and PROFINET) for deterministic I/O and motion control, paired with modern open protocols (OPC UA and MQTT) for vertical enterprise integration, edge-to-cloud telemetry, and Industrial Internet of Things (IIoT) pipelines.

---

The Determinism Challenge: CSMA/CD vs. Switched Ethernet

In industrial control, determinism is defined as the mathematical guarantee that a message will be transmitted and processed within a predictable, bounded maximum time window ($t_{latency} \le t_{max}$) with minimal packet jitter:

$$\Delta J = t_{arrival\_max} - t_{arrival\_min}$$

For high-speed robotic coordination or turbine overspeed trips, high bandwidth (e.g., 1 Gbps) is useless if message arrival times vary unpredictably.

The Failure of Half-Duplex CSMA/CD

Legacy standard Ethernet operated on shared coaxial or hub-based media using Carrier Sense Multiple Access with Collision Detection (CSMA/CD):

1. A station listens to the physical line; if idle, it transmits.
2. If two stations transmit simultaneously, an electrical collision occurs.
3. Both stations abort transmission, transmit a high-frequency jam signal, and wait a pseudo-random duration calculated by the Truncated Binary Exponential Backoff algorithm: $$r = \text{random integer in } [0, 2^k - 1] \quad \text{where } k = \min(n, 10)$$ $$t_{wait} = r \times 51.2\;\mu\text{s} \quad (\text{for } 10\text{ Mbps})$$

Under heavy network traffic (channel utilization $>40\%$), repeated collisions trigger cascading backoff delays. Message delivery latency becomes statistically unbounded, destroying control loop stability.

Switched Full-Duplex Industrial Ethernet

Modern Industrial Ethernet eliminates CSMA/CD entirely through two architectural features:

• Microsegmentation via Active Switches: Every field device connects to a dedicated switch port via separate transmit ($Tx$) and receive ($Rx$) twisted pairs (full-duplex mode). Because each port represents an isolated collision domain with independent transmit buffers, collisions are physically impossible.
• Quality of Service (QoS) & Prioritization (IEEE 802.1p/Q): While collisions are eliminated, switches can still drop or delay frames during traffic bursts (buffer queuing latency). Industrial switches inspect the 3-bit Priority Code Point (PCP) in the IEEE 802.1Q frame header:
  • Strict Priority Queuing ensures that real-time I/O control frames (PCP 6) bypass background TCP web or file transfer traffic (PCP 0) instantly.

---

EtherNet/IP: The Common Industrial Protocol (CIP)

Governed by ODVA (Open DeviceNet Vendors Association), EtherNet/IP (Ethernet Industrial Protocol) adapts the Common Industrial Protocol (CIP) to standard IEEE 802.3 Ethernet and TCP/IP.

+-------------------------------------------------------------------------+
|                        ETHERNET/IP PROTOCOL STACK                       |
+-------------------------------------------------------------------------+
| Application Layer: Common Industrial Protocol (CIP)                     |
| - Object Modeling, Identity, Connection Manager, CIP Sync, CIP Safety   |
+-------------------------------------------------------------------------+
| Transport Layer:     TCP (Port 44818)      | UDP (Port 2222)            |
|                     Explicit Messaging    | Implicit / Cyclic I/O      |
+-------------------------------------------------------------------------+
| Network Layer:       Internet Protocol (IPv4 / ICMP / IGMP)             |
+-------------------------------------------------------------------------+
| Data Link / Phys:    Standard Switched Full-Duplex IEEE 802.3 Ethernet   |
+-------------------------------------------------------------------------+

Explicit vs. Implicit Messaging

EtherNet/IP bifurcates communications across two distinct transport layer protocols:

1. Explicit Messaging (TCP/IP Port 44818):
   • Point-to-point, request/response client-server transactions.
   • Transports non-time-critical data: controller programming, variable configuration, diagnostic queries, recipe management.
   • High protocol overhead (TCP 3-way handshakes, sequencing, windowing acknowledgments). Unbounded latency.
2. Implicit Messaging (UDP/IP Port 2222):
   • Connection-oriented, cyclic I/O data streams.
   • Transports time-critical inputs and outputs between controllers and remote I/O chassis, VFDs, and sensors.
   • Uses lightweight User Datagram Protocol (UDP) without acknowledgment handshakes to minimize stack processing latency.
   • Operates on a configured Requested Packet Interval (RPI) (e.g., $2\text{ ms}$, $10\text{ ms}$, $50\text{ ms}$). If a single packet is dropped, the controller simply utilizes the next cyclic update rather than stalling execution for TCP retransmission.

The Producer/Consumer Multicast Model & IGMP Snooping

EtherNet/IP implicit I/O utilizes a Producer/Consumer communication model. An input module produces its status once onto the network using an IPv4 multicast address (Class D: 239.x.x.x). Multiple controllers or safety devices consume that same packet simultaneously.

To prevent multicast flooding, industrial networks require managed switches with two mandatory features:

• IGMP Snooping (Internet Group Management Protocol): The managed switch analyzes IGMP membership join/leave requests sent between consuming controllers and devices, dynamically opening and pruning switch ports so that multicast packets are directed only to ports with subscribed consumers.
• IGMP Querier: At least one managed switch or router on the subnet must act as the active IGMP Querier, periodically broadcasting query frames to keep device multicast group memberships alive in the switch lookup tables.

CIP Sync & CIP Safety

• CIP Sync (IEEE 1588 PTP): Implements the IEEE 1588 Precision Time Protocol over CIP. Specialized boundary or transparent clock switches insert hardware timestamps into Ethernet frames, achieving sub-microsecond ($<100\text{ ns}$) clock synchronization across distributed servo drive axes for multi-axis coordinated motion.
• CIP Safety (IEC 61508 SIL 3): Employs the "Black Channel" principle. Functional safety integrity is guaranteed entirely within the CIP application layer payload through safety timestamps, sequence numbers, cross-comparison IDs, and 32-bit safety CRCs. The underlying physical switches, cables, and routers require no safety certification because any network transmission error (corruption, loss, delay, wrong routing) is instantly detected by the receiving safety device, driving the system to a safe state.

---

PROFINET: CBA vs. IO (RT and IRT Architectures)

Maintained by PROFIBUS & PROFINET International (PI), PROFINET is the Ethernet standard of European automation architectures. While PROFINET Component Based Automation (CBA) was designed for distributed modular plant engineering, modern implementations focus exclusively on PROFINET IO (Decentralized Periphery).

PROFINET IO defines three device roles:

• IO-Controller: The primary PLC managing the automation program.
• IO-Device: Distributed field devices (remote I/O racks, drives, valves, sensors).
• IO-Supervisor: Programming software, engineering workstations, or HMIs used for commissioning and diagnostics.

+-------------------------------------------------------------------------+
|                        PROFINET COMMUNICATION CHANNELS                  |
+-------------------------------------------------------------------------+
| Standard TCP/IP Channel     | Real-Time (RT) Channel | Isochronous (IRT)|
| - Port 34964 / Standard IP  | - EtherType 0x8892     | - Specialized    |
| - Commissioning, HMI, Web   | - Bypasses Layer 3/4   |   ASIC (ERTEC)   |
| - Cycle time: 100 ms        | - Cycle time: 1-10 ms  | - Hardware Sync  |
| - Standard Commercial Stack | - IEEE 802.1Q Priority | - Cycle: < 1 ms  |
+-------------------------------------------------------------------------+

PROFINET Communication Performance Classes

1. PROFINET NRT (Non-Real-Time): Operates over standard TCP/IP or UDP/IP stacks for engineering configuration, device parameterization, and diagnostic extraction. Cycle times $\approx 100\text{ ms}$.
2. PROFINET RT (Real-Time - Software Solution):
   • Designed for standard process and factory automation I/O where update cycles between $1\text{ ms}$ and $10\text{ ms}$ are required.
   • Architecture: Bypasses the transport (TCP/UDP) and network (IP) layers entirely. Frames are packaged directly into the Ethernet Data Link Layer with EtherType 0x8892.
   • Utilizes IEEE 802.1Q Priority 6 tagging.
   • Runs on standard commercial off-the-shelf (COTS) Ethernet controllers and switches.
3. PROFINET IRT (Isochronous Real-Time - Hardware Solution):
   • Designed for high-speed synchronized motion control (e.g., printing presses, multi-axis robots, flying shears) requiring cycle times down to $31.25\;\mu\text{s}$ with jitter $<1\;\mu\text{s}$.
   • Architecture: Standard software stacks cannot eliminate microsecond-level switch buffering delays. PROFINET IRT mandates specialized switch hardware ASICs (such as the Siemens ERTEC chip).
   • Time Slicing: The IRT hardware synchronizes all network ports using PROFINET's Precision Transparent Clock Protocol (PTCP)—PROFINET over TSN uses IEEE 802.1AS instead—and divides every transmission cycle into two strict phases:
     • Red Phase (Isochronous): Reserved exclusively for deterministic motion frames. Switches forward IRT frames based on pre-calculated scheduling tables without buffering or queue contention.
     • Green Phase (Open): Normal PROFINET RT, TCP/IP, and diagnostic frames are transmitted during this remaining window.

---

OPC Unified Architecture (OPC UA - IEC 62541)

In early industrial automation, the Open Platform Communications (OPC Classic: DA, HDA, A&E) standard enabled HMIs to read data from different PLC brands. However, OPC Classic was inextricably bound to Microsoft's proprietary OLE/COM and DCOM (Distributed Component Object Model) architecture.

DCOM created severe operational failures:

• It was locked to the Windows operating system, preventing execution on Linux, mobile devices, or embedded PLC firmware.
• DCOM dynamic port allocation (ports 1024-65535) was notoriously hostile to corporate IT firewalls, creating massive cybersecurity vulnerabilities.

OPC UA Architectural Features

Standardized under IEC 62541, OPC Unified Architecture (OPC UA) completely rebuilt industrial interoperability from the ground up:

• Platform Independence: Implemented in standard C/C++, Java, .NET, and Python. Executes natively inside Linux microcontrollers, cloud gateways, and bare-metal RTOS.
• Firewall-Friendly Transport: Consolidates all communications onto a single configurable TCP port (default: 4840, using the binary protocol opc.tcp://) or WebSockets over HTTPS (opc.wss://).
• Comprehensive Security Architecture:
  • Mutual endpoint authentication using X.509 digital certificates.
  • Message encryption via AES-128 or AES-256.
  • Digital signature verification via SHA-256 to prevent message tampering or replay attacks.
  • Granular user authentication (Anonymous, Username/Password, X.509 User Certificate, JSON Web Tokens).
• Object-Oriented Semantic Information Modeling: Unlike legacy protocols that expose raw flat register tables (e.g., Modbus address 40001 = integer 1842), OPC UA organizes data into an interconnected network of Nodes within an Address Space:
  • Nodes possess Attributes (NodeID, BrowseName, Value) and are interconnected by References (Organizes, HasComponent, HasProperty).
  • An automation engineer can model an entire complex machine (e.g., a multi-stage pump) with child variables (suction pressure, bearing temperature), engineering units (deg C), operating ranges, calibration dates, and callable executable Methods (StartPump(), CalibrateSensor()).
  • Companion Specifications: Industry consortia publish standardized OPC UA models for specific domains, including PackML (packaging machinery), Euromap (injection molding), and AutoID (RFID/barcode systems).

OPC UA PubSub & Time-Sensitive Networking (TSN)

To expand beyond client-server request/response polling, OPC UA Part 14 defines a Publish/Subscribe (PubSub) architecture. Operating over UDP multicast or the emerging IEEE 802.1 Time-Sensitive Networking (TSN) standard (specifically IEEE 802.1Qbv time-aware shapers), OPC UA PubSub enables deterministic controller-to-controller and field-level communications without proprietary protocol gateways.

---

MQTT & Sparkplug B: Industrial Edge-to-Cloud Telemetry

While OPC UA excels at structured machine-level information modeling, the Message Queuing Telemetry Transport (MQTT) protocol has emerged as the dominant standard for lightweight, low-bandwidth, high-latency industrial IoT and SCADA telemetry.

MQTT Architecture: Broker-Client Pub/Sub

Standardized under ISO/IEC 20922, MQTT uses an event-driven Publish/Subscribe architecture centered around a central Broker:

+-------------------------------------------------------------------------+
|                        MQTT PUB/SUB TOPOLOGY                            |
|                                                                         |
|   [ Publisher: Edge PLC ] ====> (Topic: 'plant/tank1/temp')            |
|                                        |                                |
|                                        v                                |
|                             +--------------------+                      |
|                             |    MQTT BROKER     |                      |
|                             +--------------------+                      |
|                                  /              \                       |
|                                 v                v                      |
|                     [ Subscriber: SCADA ]    [ Subscriber: Cloud Lake ] |
+-------------------------------------------------------------------------+

• Client Decoupling: Publishers (field PLCs) and Subscribers (SCADA, cloud databases) never communicate directly. They are decoupled in space (they do not know each other's IP addresses), time (they do not need to be online simultaneously), and synchronization (data publishing does not block execution).
• Minimal Overhead: The MQTT fixed header is only 2 bytes, making it exceptionally well-suited for cellular, satellite, and constrained radio telemetry.
• Quality of Service (QoS) Levels:
  • QoS 0 (At most once): Best-effort "fire-and-forget". No acknowledgment or retransmission. Minimal latency.
  • QoS 1 (At least once): Acknowledged delivery (PUBACK). Guarantees receipt, but messages can arrive duplicated if acknowledgments are delayed.
  • QoS 2 (Exactly once): Four-step handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP). Guarantees exactly one delivery without duplication, but incurs significant protocol round-trip delay.
• Last Will and Testament (LWT): When a client connects, it registers a designated LWT topic and payload with the broker. If the client disconnects abnormally (e.g., power loss, cut cable), the broker immediately publishes the LWT message to inform all subscribers of the failure.

The Need for Sparkplug B in Industrial OT

Despite its strengths, vanilla MQTT presents severe architectural problems in operational technology (OT):

1. Unstructured Payloads: MQTT treats payloads as opaque byte arrays. One vendor publishes text strings ("72.4"), another publishes raw binary, and another publishes JSON ({"temp": 72.4}). There is no standard data typing.
2. Arbitrary Topic Namespaces: Different developers invent inconsistent topic trees (line1/temp vs plantA/unitB/temperature).
3. No Native State Awareness: Subscribers cannot determine whether an edge device is operational or dormant without custom application code.

Sparkplug B is an open-source standard maintained by the Eclipse Foundation that superimposes an industrial framework on top of MQTT:

+-------------------------------------------------------------------------+
|                        SPARKPLUG B SPECIFICATION                        |
+-------------------------------------------------------------------------+
| 1. Standardized Topic Namespace:                                        |
|    spBv1.0 / Group_ID / Message_Type / Edge_Node_ID / [Device_ID]       |
+-------------------------------------------------------------------------+
| 2. Standardized Message Types:                                          |
|    - NBIRTH / NDEATH : Edge Node Birth and Death (State Management)     |
|    - DBIRTH / DDEATH : Attached Device Birth and Death                  |
|    - NDATA / DDATA   : Real-time Data (Report by Exception)             |
|    - NCMD / DCMD     : Write Commands from SCADA to Field Device        |
+-------------------------------------------------------------------------+
| 3. Highly Compressed Binary Payload:                                    |
|    - Encoded using Google Protocol Buffers (Protobuf)                   |
|    - Explicit data typing, timestamps, engineering units, quality flags |
+-------------------------------------------------------------------------+
| 4. Report by Exception (RBE):                                           |
|    - Data published only upon deadband excursion, saving much bandwidth |
+-------------------------------------------------------------------------+

When a Sparkplug B edge node connects, it publishes an NBIRTH packet detailing every metric it contains (tag names, data types, current values). Subsequently, it publishes DDATA packets only when a value changes beyond its deadband (Report by Exception - RBE). If the network breaks, the MQTT Broker detects the session drop and publishes the node's pre-registered NDEATH message, immediately flagging all associated SCADA tags with BAD quality.

Selecting the Physical Media

The protocol is chosen from the data requirements (cycle time, determinism and volume), but the physical medium is chosen from distance, electrical environment and grounding.

Use fiber between buildings, along routes near VFDs and switchgear, and wherever lightning or ground potential differences are a concern. Use industrial connectors (such as M12) in wet or vibrating areas, and route redundant network paths separately so that one cable tray fire or cut cannot take out both.

---

Industrial Ethernet Topology and Redundancy

Switched Ethernet removes collisions, but the design must also survive a broken cable or a failed switch. Common topologies and recovery mechanisms are:

Choose the mechanism from the process requirement: if an I/O connection times out faster than the network recovers, a single cable break will still trip the process. Star topologies are simple to troubleshoot but make the core switch a single point of failure; redundant cores, dual power supplies and ring designs remove it.

Building Automation Networks (BACnet)

Utility and facility systems—HVAC, chilled water, lighting and life-safety interfaces—often use BACnet (ANSI/ASHRAE Standard 135, also published as ISO 16484-5). Its object model (analog inputs, binary outputs, schedules and so on) runs over BACnet/IP or over the RS-485 MS/TP data link. Process plants commonly integrate the building automation system through a gateway so that critical utilities, such as control-room HVAC and clean-room pressurization, can be monitored from the plant control system.

---

Realistic Industrial Scenario: High-Speed Beverage Bottling Line

A high-speed beverage bottling line fills and caps 1,200 bottles per minute ($20\text{ bottles/sec}$). The automation system must integrate high-speed multi-axis motion, distributed discrete sensors, line-level recipe management, and corporate cloud OEE analytics.

+-------------------------------------------------------------------------+
|                   BOTTLING LINE INTEGRATED ARCHITECTURE                 |
|                                                                         |
| [ Enterprise Cloud Analytics ] <==== (MQTT Sparkplug B via Edge Gateway)|
|               ^                                                         |
|               | (OPC UA / IEC 62541 - PackML Machine State Model)       |
|               v                                                         |
| [ Central Line PLC / SCADA ]                                            |
|       ||                  \\                                            |
|       || (PROFINET IRT)    \\ (EtherNet/IP CIP Implicit UDP / IGMP)     |
|       v                     v                                           |
| [ 8-Axis Capper Servo ]   [ Distributed Pneumatics & Inspection I/O ]   |
+-------------------------------------------------------------------------+

Network Deployment Strategy

1. Motion Control Tier (PROFINET IRT): The rotary capping carousel coordinates eight servo motors that press and torque caps within $\pm 1\text{ mm}$ position tolerances. PROFINET IRT hardware ASICs enforce a $500\;\mu\text{s}$ isochronous red phase, eliminating packet jitter.
2. Conveyor & Pneumatic Valve Tier (EtherNet/IP): Distributed valve manifolds and photoelectric sensors connect over EtherNet/IP implicit I/O at a $5\text{ ms}$ RPI. Managed switches with active IGMP Snooping prevent multicast I/O frames from saturating the capping servos.
3. Machine-to-Supervisory Tier (OPC UA): The filler PLC hosts an OPC UA server conforming to the PackML (ISA-TR88.00.02) companion standard. The supervisory SCADA queries machine states (EXECUTE, HOLDING, SUSPENDED) and initiates clean-in-place (CIP) recipes over secure, encrypted TCP port 4840.
4. Edge Telemetry Tier (MQTT Sparkplug B): An edge IoT gateway connected to the PLC converts production counters and motor power metrics into Sparkplug B Protobuf payloads. Telemetry is streamed over cellular to an enterprise cloud data lake on an RBE basis, reducing cellular data bandwidth consumption by $88\%$ compared to continuous polling.

---

Common Exam Traps

1. Deploying Unmanaged Switches for EtherNet/IP Implicit I/O: Unmanaged switches cannot perform IGMP snooping. In an EtherNet/IP network with multiple producing devices, multicast I/O packets flood all ports like broadcast traffic, overwhelming low-cost field devices and causing intermittent disconnects.
2. Assuming PROFINET RT Requires Proprietary Hardware ASICs: Only PROFINET IRT (Isochronous Real-Time) requires specialized switch hardware ASICs (e.g., ERTEC) for microsecond time slicing. Standard PROFINET RT is entirely software-based, running on standard commercial Ethernet controllers and switches.
3. Confusing MQTT QoS 2 with Low Latency: MQTT Quality of Service Level 2 guarantees "exactly once" delivery, but its mandatory four-step request/response handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP) introduces substantial network round-trip latency. It must not be used for real-time closed-loop control.
4. Assuming OPC UA is Simply a Firewall-Friendly DCOM: OPC UA is not a wrapper around Microsoft DCOM. It is a completely redesigned, platform-independent, object-oriented binary/web communication architecture built on open standards (IEC 62541) with native X.509 cryptographic security.