Safety with FSoE (FailSafe over EtherCAT)

What is FSoE and where is it used?

Functional safety is an integral part of modern network architectures and communication systems. EtherCAT offers the possibility of safety-related data transmission in parallel with standard data on the same network with the help of the Safety over EtherCAT protocol “FSOE” (= FailSafe over EtherCAT). With Safety over EtherCAT, the communication system is defined as part of a Black Channel, which is not considered to be part of the safeguarding of the data but allows to tunnel safe data via a non-safe communication channel. Safety over EtherCAT is a TÜV-certified technology developed according to IEC 61508 and standardized internationally in IEC 61784-3. FSoE is an open technology within the EtherCAT Technology Group (ETG).

Safety over EtherCAT is used in various applications requiring functional safety in industrial automation:

• Protection against malfunction of machines
• Protection of the machine operator against dangerous movements

Typical safety functions are:

• Monitoring of the workspace of a machine, e.g., door guarding, protection with light curtain or laser scanner
• Safe feeding of material
• Safe movement with manual intervention, e.g., Tow-Hand control, Emergency Stop, Safely limited speed

Overall, FSoE is suitable where safety-rated data needs to be transmitted, and actions must be taken in a guaranteed safe manner in the event of a communication failure. FSoE's flexibility means it can be applied across varied functional safety applications from I/O devices to multi-axis drive systems.

Typical safety device hard- and software architecture

Depending on the target application and thus the related possible risk for equipment, environment and humans – a combination of the possibility of a failure with the effects of a failure, the required SIL (Safety Integrity Level) can be defined for the system. To meet the requirements of targeted SIL, the hardware must provide highest availability and reliability. Therefore, typical safety hardware must be redundant (dual-channel) for the safety-relevant part of the software and hardware. Depending on the implementation, the FSoE protocol stack is executed, in whole or partly, on two independent controllers. However, due to the "black channel principle" the communication interface is single-channel and therefore a standard EtherCAT SubDevice Controller can be used. The underlying fieldbus is not included in safety considerations.

• Redundant hardware for safety protocol and safety-related application
• Thanks to the Black Channel principle, the standard communication interface (1-channel) can be used

FSoE basics and frame structure

The safety data is embedded in the standard cyclic process data as a container combined with additional data for its integrity. The safety connection between the FSoE MainInstance and an FSoE SubInstance is fully monitored in each safety cycle. The checksum of the safety frames, the connection ID and also a watchdog time for each FSoE frame transmission are all checked.

FSoE Frame Structure: The FSoE Frame is embedded as a container in the process data of the device. Each device detects a new FSoE Frame if at least one bit in the frame has changed. The minimum FSoE frame length is 6 bytes. The FSoE frame includes a command (CMD), Safe Data, CRC_0, CRC_1 and connection ID.
Each2 Byte Safe Data are checked by a 2 Byte CRC. The maximum number of Safe Data is therefore not restricted by the protocol.

A detailed guideline for implementing an FSoE device can be found in the ETG document ETG.2200 SubDevice Implementation Guide, Section IV.

 

Network Topologies with FSoE Devices

FSoE supports both centralized and decentralized safety logic systems.

Decentralized Safety Logic

The following topology shows an EtherCAT network with multiple FSoE devices. The safety logic (FSoE MainInstance) is implemented in an EtherCAT SubDevice. This has the advantage that the controller (EtherCAT MainDevice) can be implemented as a non-safe device. Furthermore, the network contains safe inputs, outputs, and drives that also implement FSoE. These are referred to as FSoE SubInstances.

The FSoE MainInstance maintains its own Logical Safety Connection to each FSoE SubInstance. Connection means that FSoE frames are exchanged between the EtherCAT SubDevices via the process data with the help of the MainDevice software. The FSoE MainInstance (Safety Logic) is sending a FSoE MainInstance Frame to every FSoE SubInstance within the standard EtherCAT data frame. The FSoE SubInstances are sending a FSoE SubInstance Frame to the FSoE MainInstance via the standard EtherCAT data frame. To enable such direct communication between the FSoE devices, the EtherCAT MainDevice must support direct SubDevice to SubDevice communication, as described in ETG.1500 Master Classes Directive.
The FSoE Cycle consists of an FSoE MainInstance Frame that is confirmed by the FSoE SubInstance Frame. The FSoE cycle time is always bigger than the EtherCAT cycle time.

In step 1, the input-data of all FSoE devices (MainInstance as well as SubInstances) are transmitted via the EtherCAT data frame and stored in the process data inputs memory of the EtherCAT MainDevice.

In step 2, the MainDevice software copies the relevant input data blocks from the process data inputs memory into the output data blocks for perform the SubDevice-to-SubDevice communication. According to the document “ETG.1500 Master Classes Directive”, SubDevice-to-SubDevice communication is necessary to enable FSoE MainInstance and SubInstances to communicate with each other within the EtherCAT segment. The definition, which data blocks need to be copied between the EtherCAT SubDevices which are FSOE devices is included in the ENI (EtherCAT Network Information) file within the element Cyclic/Frame/Cmd/CopyInfos. All relevant details of the relevant ENI-file elements are specified in the document „ETG.2100 EtherCAT Network Information“ in the section CopyInfos: Copy information for SubDevice to SubDevice communication. The MainDevice has to copy valid input data of this command from the source offset (bit offs in the complete process image) to a destination offset.

 

 

In step 3, the output data is transferred to the FSoE devices as part of the normal cyclic process data.

Centralized Safety Logic

The following topology shows a MainDevice controller with integrated safety logic (FSoE MainInstance). Some of the connected EtherCAT SubDevices are safe devices with FSoE and are referred to as FSoE SubInstances. A central safety logic simplifies configuration, the data-transfer and programming: As the FSOE MainInstance is within the MainDevice, the MainDevice does not need to enable SubDevice to SubDevice communication for safety data, which also reduces the additional cycle-times needed for safety-data.

However combining the EtherCAT MainDevice and the FSOE MainInstance has the drawback that the usually quite complex controller controller must be safety certified.

Configuration of FSoE devices

For the configuration of the safety controller, the manufacturer's own configuration tool is necessary: E.g. when using a Beckhoff TwinSAFE Controller, the Beckhoff TwinCAT software is required to create the safety configuration. The creation of the safety configuration (logic for the FSoE MainInstance) requires several steps and must be carried out according to the manufacturer's specifications. This screenshot shows the linking of an emergency stop button to a signal lamp.

The safety configuration also is the basis for the derived logical connections between the FSoE MainInstance and the FSoE SubInstances. In this example project, there is one bidirectional connection each between the TwinSafe Controller EL6900 and the safe inputs/outputs Beckhoff EL1904 and EL2904. To realise these these connections within EtherCAT, the above mentioned non-safe SubDevice-to-SubDevice communication is required. This therefore requires that several data blocks must be copied cyclically from the Process Data Input Image to the Process Data Output Image by the EtherCAT MainDevice.

 

 

The SubDevice-to-SubDevice communication is defined in the EtherCAT Network Information (ENI) file via the CopyInfos.
The configuration of safety controllers from other manufacturers also always results in an ENI file with CopyInfos, as the SubDevice to SubDevice communication is required. Therefore, it is necessary for the EtherCAT MainDevice software to be able to process this file in order to ensure systematic and efficient support of FSoE Devices.

MainDevice Software

The MainDevice software is part of the "black channel" of FSoE and therefore does neither require safe implementation nor certification. The Safety over EtherCAT messages (FSoE frames) are transmitted within the normal EtherCAT process data (inputs and outputs) between the different FSoE Instances. Since, usually all FSoE Instances are implemented as EtherCAT SubDevices, and SubDevices cannot communicate directly with each other, the MainDevice software must establish the cross-communication, which is also referred to as SubDevice-to-SubDevice communication. Which data needs to be transferred between the devices is defined in the CopyInfos entries in the ENI file. The MainDevice software EC-Master from acontis fully processes these entries and performs the necessary recopying of the inputs to the outputs either directly after receiving the cyclic frame or before sending the next cyclic frame.

Conclusion

In conclusion, Safety over EtherCAT (FSoE) provides a robust and flexible solution for integrating functional safety into industrial automation systems leveraging the EtherCAT network. By operating on the principle of a "black channel," FSoE allows for the transmission of safety-critical data alongside standard communication without requiring safety certification of the underlying network infrastructure, enabling faster and more flexible realization of any machinery that requires safety-communication.
Its application across diverse safety functions and network topologies, including both centralized and decentralized safety logic, underscores its adaptability. The configuration of FSoE devices, facilitated by manufacturer-specific tools and the crucial SubDevice-to-SubDevice communication managed by the MainDevice software – like the proven acontis EC-Master – ensures the reliable exchange of safety data.
Ultimately, FSoE stands as a well-established and internationally standardized technology, empowering the development of safer and more efficient industrial machinery and processes.