Industrial automation systems increasingly rely on standard Ethernet-based communication networks and require that safety-critical and standard operational data share the same Ethernet infrastructure. This article examines how communications protocols – PROFINET with ProfiSafe, Ethernet Industrial Protocol (Ethernet/IP) with Common Industrial Protocol (CIP) Safety and Ethernet for Control Automation Technology (EtherCAT) with FSoE (Fail-Safe over EtherCAT) address the fundamental challenge of transmitting safety messages reliably over networks that offer no inherent safety guarantees through the Black Channel principle defined in IEC 61784-3. A structured comparison highlights architectural and performance differences. A structured comparison of protocol architectures, frame structures, state machines, and performance characteristics follows, with focused attention on FSoE and the architectural properties of EtherCAT that make it particularly well positioned across multiple industries. The article concludes with an outlook on emerging directions including OPC UA Safety, TSN and the convergence of functional safety with cybersecurity.

Introduction

Industrial communication has undergone a profound transformation from hardwired relay logic through PLC-based control and serial fieldbuses (such as Profibus, CANopen and Modbus) to modern Industrial Ethernet protocols. This shift enabled higher bandwidth, better diagnostics, and IT/OT convergence, but also raised a critical question:

How can safety-critical messages be transmitted reliably over networks that provide no inherent safety guarantees?

The answer reflects a fundamental principle equally applicable to industrial communication: no network operates without faults, disturbances or uncertainty.  Instead of assuming ideal conditions, modern systems must be designed to detect, isolate and safely handle inevitable communication errors. The three Industrial Ethernet protocols that together cover the vast majority of global deployments each answer this question differently.

PROFINET, developed by Siemens and standardized through PROFIBUS&PROFINET International (PI), defines multiple communication classes: RT (Real-Time) for standard process data and IRT (Isochronous Real-Time), enabling the precise and deterministic communication required by motion control and time-critical applications. Integration with the wider Siemens engineering ecosystem makes it natural choice for large European installations.

Ethernet/IP, based on the CIP and managed by ODVA, is widely adopted in North American manufacturing. It supports both real-time I/O messaging (implicit messaging) and configuration/diagnostics traffic (explicit messaging) over standard UDP/TCP/IP. Its architecture abstracts the physical network from the application layer, making it vendor-neutral.

EtherCAT, developed by Beckhoff and now managed by the EtherCAT Technology Group (ETG), stands out for its unique "on-the-fly" frame processing: each SubDevice node reads and writes data directly to the passing Ethernet telegram without first storing and forwarding the entire frame. This approach results in extremely low latency (sub-100 µs cycle times are achievable), high synchronization accuracy, and outstanding network efficiency, making EtherCAT particularly suitable for high-performance motion control, robotics and distributed I/O systems.

Figure 1. Communication architecture comparison: star topology with store-and-forward switching (PROFINET, Ethernet/IP) vs. EtherCAT linear daisy-chain with “on-the-fly” frame processing

Figure 2. Industrial network market shares 2025 (source: HMS Networks)

Standards such as IEC 61508 and ISO 13849 define rigorous requirements for safety-related systems, introducing the concepts of Safety Integrity Levels (SIL) and Performance Levels (Pla/PLe). Traditionally, safety functions like Emergency Stop (E-Stop) and Safe Torque Off (STO) relied on separate hardwired circuits, reliable but inflexible and costly to modify. Any topology change requires physical rewiring, safety re-validation and significant engineering effort. Safety protocols over Industrial Ethernet allow safety and standard data to coexist on the same infrastructure, eliminating dedicated safety wiring while supporting systems that can be certified up to SIL3 / PLe.

IEC 61784-3 Error Model

Standard industrial networks are not inherently safe, which means that standard Ethernet-based protocols provide no guarantees against the classes of errors that safety-critical systems must be resilient against. IEC 61784-3 governs Safety Communication Profiles (SCPs) for industrial networks. Its foundational concept is the Black Channel: the underlying network is treated as completely untrusted and all safety guarantees are provided exclusively by the safety layer running above it. This standard defines a comprehensive error model that identifies the specific failure modes a safety protocol must address. The error model defines 8 failure types that a safety protocol must detect or prevent.

Figure 3. IEC 61784-3 error model: 8 error types (left) and the protocol fields that detect each one (right) - all three safety protocols address the complete error set

IEC 61784-3 defines a family of SCPs, each specifying how a particular safety protocol addresses the error model described above. The three protocols examined in this article each have their own dedicated SCP within this standard:

• IEC 61784-3-3 defines the Safety Communication Profile for ProfiSafe.
• IEC 61784-3-2 defines the Safety Communication Profile for CIP Safety.
• IEC 61784-3-12 defines the Safety Communication Profile for FSoE.

All 3 profiles share the Black Channel principle and the same underlying error model but differ in their specific implementation of the safety frame structure.

It is also important to say few more words about Black Channel principle, as it is the foundational concept. The Black Channel approach treats the underlying communication network, whether PROFINET, Ethernet/IP, EtherCAT or any other as a completely untrusted "pipe" that simply transports bytes from sender to receiver. The safety protocol makes no assumptions about the reliability or safety properties of this channel. All safety guarantees are instead provided exclusively by the safety layer implemented on top of the standard network stack. This safety layer adds protective fields, such as sequence numbers, connection identifiers, time stamps, and cryptographically strong CRCs, to each safety message. The receiver then independently validates these fields and only accepts a message as valid safety data if all checks pass. CRC mechanisms are designed for error detection, not cryptographic security. If any check fails, the receiver transitions to a safe state (typically deactivating outputs) and reports a communication error.

This elegant separation means that the same safety protocol can operate over multiple different underlying networks without modification, and that upgrading or changing the physical network infrastructure does not invalidate the safety certification. It also means that standard and safety-critical data can coexist on the same physical wiring, dramatically simplifying system architecture compared to the traditional approach of running separate safety bus cables.

Profisafe Over Profinet

ProfiSafe (IEC 61784-3-3) embeds safety data within standard PROFINET I/O data frames. From the PROFINET network's perspective, a ProfiSafe device is an ordinary I/O device; the safety content is invisible to the network infrastructure. The ProfiSafe F-PDU (Fail-safe Protocol Data Unit) structure consists of the following fields: Safety Data (F-Data), Status/Control byte, Consecutive Number, CRC.

The F-Address is a virtual address, not transmitted explicitly but baked into the CRC polynomial seed. This means that even if a frame is physically routed to the wrong device, the CRC at the receiver will fail because it was computed for a different F-Address. This elegantly handles masquerading and addressing errors without any extra frame bytes.

ProfiSafe supports two device classes: F-Modules (safety I/O terminals) and F-Drives (safety-enabled drive systems). Safety cycle time is configurable, typically 4-32 ms, with SIL3 achievable for cycle times up to 32 ms.

Figure 4. ProfiSafe F-PDU structure

Cip Safety Over Ethernet/IP

CIP Safety (IEC 61784-3-2) extends the CIP connection model with a dedicated safety transport type. Because Ethernet/IP operates over standard, non-time-synchronized Ethernet, CIP Safety cannot rely on the network for timing guarantees. Its solution is the Time Coordination message (T_C) mechanism.

The T_C mechanism establishes a shared time base between the Safety Originator (controller) and the Safety Target (device) through a dedicated handshake exchange. Once calibrated, the time base allows the receiver to independently verify that each arriving safety message is within its allowed time window, providing detection of unacceptable delays without relying on the network's own timing.

Figure 5. CIP Safety Time Coordination

CIP Safety is deeply integrated with Rockwell Automation's GuardLogix safety PLC platform and configured through the Studio 5000 Logix Designer environment. The ODVA organization maintains an open certification program, meaning multiple third-party vendors produce CIP Safety-compatible devices.

FSoE Over Ethercat

FSoE (ETG.5100/IEC 61784-3-12) transports safety data as part of regular EtherCAT process data. The FSoE frame sits inside the EtherCAT process data image, completely transparent to the EtherCAT network layer. The FSoE frame structure is deliberately minimal.

Figure 6. FSoE frame structure

Every FSoE safety communication relationship is governed by a defined state machine that must complete successfully before any process data is exchanged. This state machine is the mechanism by which FSoE detects and recovers from communication faults.

Figure 7. FSoE state machine – per safety communication relationship

The watchdog timer is reset on every successfully validated FSoE frame received. If the watchdog expires, because a frame was lost, corrupted, or delayed beyond the timeout, the SubDevice immediately deactivates its outputs and returns to a predefined safe state (e.g., STO or equivalent safe output state), regardless of the last commanded value. This provides the core protection against frame loss and unacceptable delays.

A defining characteristic of FSoE is its reliance on the deterministic timing model provided by EtherCAT’s Distributed Clocks (DC) mechanism. In contrast to conventional Ethernet-based systems that depend on software-level synchronization, EtherCAT implements a hardware-assisted synchronization scheme in which all SubDevices maintain a common time base with typically achieving sub-microsecond synchronization accuracy in well-designed systems.

Each EtherCAT SubDevice contains an internal clock that is continuously synchronized to a reference clock, typically located in the MainDevice or a designated reference SubDevice. The synchronization error between nodes is typically below 1 µs, enabling tightly coordinated cyclic communication across the network.

This global time coherence directly impacts FSoE safety performance. Specifically, watchdog timers used in FSoE communication are evaluated against a consistent and deterministic time base across all devices. As a result, timing-related faults such as excessive delay or jitter can be detected with high precision and without ambiguity. This eliminates the need for conservative timing margins that are otherwise required in software-synchronized systems.

Consequently, FSoE systems can achieve safety cycle times in the range of 1–4 ms in optimized configurations, supporting applications that require fast reaction times and high dynamic performance.

A common real-world application of FSoE is the implementation of STO functionality in servo drive systems. In this configuration, FSoE master (typically a safety PLC) establishes a safety communication channel with one or more FSoE-enabled drives. During normal operation, the FSoE master cyclically transmits a safety control word indicating that torque generation is permitted. Each message includes the Connection ID and CRC, ensuring both addressing integrity and data correctness. Upon successful validation, the SubDevice maintains its operational state and allows torque production.

If a safety event occurs, such as an emergency stop (E-stop) activation, the FSoE master immediately changes the commanded state. The SubDevice, upon receiving a valid FSoE frame reflecting this change, transitions to the STO state, disabling power to the motor drive stage within a defined reaction time, typically on the order of a few milliseconds.

Importantly, the STO function does not rely solely on the correctness of the received command. The absence of valid communication is treated equivalently to a faulty condition. If no valid FSoE frame is received within the configured watchdog timeout, the drive autonomously transitions to the STO state, ensuring fail-safe behavior even in the presence of communication loss.

FSoE achieves its SIL3/PLe safety integrity by systematically detecting and responding to all relevant communication fault conditions defined in IEC 61784-3. The protocol’s behavior can be illustrated through several representative failure scenarios.

• Frame Loss 
  If a cyclic FSoE frame is lost due to network disturbance or hardware failure, the receiving SubDevice does not attempt to extrapolate or reuse the last valid command. Instead, the watchdog timer, reset upon each valid frame, continues to decrement.
  If the timeout expires before a new valid frame is received, the SubDevice immediately transitions to the predefined safe state (e.g., STO). This ensures that loss of communication cannot result in uncontrolled or unsafe actuator behavior.
• Frame Delay or Excessive Jitter
  In systems without deterministic timing, delayed frames may arrive too late to be meaningful but still be accepted as valid. FSoE avoids this ambiguity through its reliance on EtherCAT Distributed Clocks.
  Because all devices share a synchronized time base, the watchdog timeout represents an absolute and consistent limit. A frame arriving after this deadline is effectively treated as lost, even if it is physically received. The system therefore guarantees that safety decisions are not influenced by timing uncertainty.
• Incorrect Addressing or Masquerading
  A critical safety concern in networked systems is the possibility of a frame being incorrectly routed or maliciously injected. FSoE mitigates this risk using the Connection ID mechanism.
  Each safety connection is uniquely identified by a randomly generated 16-bit Connection ID established during initialization. This identifier is included in the CRC calculation of every frame. If a frame arrives with an incorrect Connection ID, whether due to misrouting, duplication from a previous session or unintended insertion, the CRC validation fails.
  Upon detection of such an inconsistency, the SubDevice immediately discards the frame and transitions to the safe state if the condition persists, thereby preventing unintended actuation due to addressing errors or masquerading.

Comparative Analysis

Table below provides a full side-by-side comparison of the three protocols across the most relevant technical and practical criteria.

Table 1. Comparative summary of ProfiSafe, FSoE, and CIP Safety across key technical and practical criteria

The following table maps each IEC 61784-3 error type to the specific protocol field that detects it in each of the three protocols:

Table 2. IEC 61784-3 error type mapping to the one of the three protocols fields

All three protocols achieve functional equivalence at the SIL/PL certification level, each is capable of SIL3/PLe certification when properly implemented and validated. The meaningful differences lie in performance, architecture and ecosystem fit.

Figure 8. Typical end-to-end safety reaction time ranges for each protocol and Safety frame overhead (bytes added per message beyond standard process data)

From a performance perspective, FSoE has a clear advantage in applications that require fast safety reaction times. The ability to run safety cycles at 1-2 ms, enabled by EtherCAT's deterministic hardware-synchronized architecture, translates directly to shorter safety response times and allows higher machine dynamics while maintaining safety guarantees. ProfiSafe, operating over PROFINET IRT, can achieve relatively short cycle times in the 4-8 ms range, though this requires IRT-capable hardware. CIP Safety, constrained by Ethernet/IP's lack of hardware synchronization, typically targets safety cycle times of 10 ms or more.

In terms of frame efficiency, FSoE adds the least overhead per safety frame (6 bytes of Connection ID and CRC), which is meaningful in EtherCAT systems where small distributed I/O nodes have tight data constraints. ProfiSafe's 12-byte overhead is manageable, and CIP Safety's overhead, while slightly higher, is offset by Ethernet/IP's inherently larger frame capacity.

Regarding ecosystem and vendor lock-in, all three protocols are closely associated with a dominant vendor or vendor consortium. ProfiSafe is the natural choice for PROFINET/Siemens environments; CIP Safety for Ethernet/IP/Rockwell environments and FSoE for EtherCAT/Beckhoff environments. That said, FSoE benefits from the open nature of the EtherCAT Technology Group, with multiple third-party stacks available (including open-source master stacks such as SOEM and EtherLab) which gives system integrators and OEMs more flexibility.

For new project selection, the practical recommendation is straightforward: align the safety protocol with the chosen industrial Ethernet infrastructure. Mixing protocols across vendor boundaries is technically possible but introduces unnecessary integration complexity. When performance is the primary driver – particularly in high-speed motion control, collaborative robotics or any application where safety reaction time is a design constraint, FSoE over EtherCAT provides the most competitive combination of speed, determinism and overhead efficiency.

Conclusion And Future Directions

ProfiSafe, FSoE, and CIP Safety all implement the Black Channel principle defined in IEC 61784-3, achieving SIL3/PLe capability through a dedicated safety layer that treats the underlying network as untrusted. The choice between them should follow the installed infrastructure: FSoE where fast reaction times are a design constraint, ProfiSafe in Siemens/PROFINET environments, CIP Safety in Rockwell/Ethernet/IP environments.

Rather than being displaced by emerging approaches, all three protocols are actively evolving and the directions they are heading in are worth tracking closely.

FSoE and EtherCAT are expanding well beyond their industrial automation origins. In collaborative and surgical robotics, FSoE's sub-2 ms safety cycle times directly enable tighter safety-rated monitored stop zones, a critical parameter for human-robot collaboration in both factory floors and operating theatres. Medical device manufacturers developing robotic surgery platforms (such as those based on da Vinci-class architectures or next-generation orthopedic systems) increasingly evaluate EtherCAT/FSoE precisely because its Distributed Clocks synchronization and low-latency safety response match the requirements of IEC 62304 (medical device software) and IEC 60601-1 (medical electrical equipment) workflows. Similarly, in semiconductor manufacturing, where wafer-handling robots demand sub-millimeter repeatability and fast interlock response, FSoE's deterministic timing profile is a natural fit. The EtherCAT Technology Group has reported tens of millions of EtherCAT nodes deployed worldwide, with growth increasingly concentrated outside traditional machine automation, confirming this cross-domain trajectory.

On the protocol specification side, the 2024 amendment to IEC 61784-3 (IEC 61784-3:2021+AMD1:2024) introduced normative requirements for residual error rate calculations covering not only data integrity but also authenticity, timeliness, and masquerade errors, areas where FSoE's Connection ID mechanism provides a natural and already-compliant response. All three protocols are aligning their implementations to this updated standard, and device manufacturers will need to formally demonstrate compliance with the extended residual error probability model in new product certifications.

ProfiSafe is evolving through the PROFINET over TSN initiative (IEC 60802, currently in advanced standardization). TSN adds IEEE 802.1 hardware-level time synchronization to standard Ethernet, potentially narrowing the cycle time gap between PROFINET IRT and EtherCAT.  If PROFINET over TSN achieves widespread adoption, ProfiSafe safety cycle times in the 1–2 ms range may become more widely achievable in TSN-enabled deployments, reducing one of the current architectural advantages of FSoE without requiring a change of safety protocol.

CIP Safety is similarly tracking the TSN wave through the ODVA's engagement with IEEE 802.1 working groups. Additionally, the broader CIP architecture is being extended for Industrial Internet of Things (IIoT) integration, which will bring CIP Safety data into cloud-connected architectures for remote monitoring and predictive safety diagnostics. That’s the area where Rockwell's FactoryTalk ecosystem is already active.

Across all three protocols, the convergence of functional safety (IEC 61508) and cybersecurity (IEC 62443) is the most pressing shared challenge. The 2024 update to IEC 62443-2-1 strengthened requirements for cybersecurity management in industrial systems, and the revised IEC 61508 series currently in draft explicitly addresses the interface between safety and security requirements. A cyber-attack that suppresses an FSoE watchdog, replays a ProfiSafe safe-state command, or impersonates a CIP Safety originator represents a combined safety-security threat that neither standard, taken alone, fully addresses. Future revisions of all three safety protocol specifications are expected to increasingly incorporate cryptographic authentication mechanisms that satisfie both IEC 61508 SIL requirements and IEC 62443 Security Level requirements simultaneously, a technically demanding but increasingly non-negotiable design requirement.