Safety over EtherCAT (FSoE)
- Introduction
- Safety Fieldbus System
- Technology Requirements
- Implementation Aspects
- Application Example
Introduction
The open protocol Safety over EtherCAT (abbreviated with FSoE "FailSafe over EtherCAT") defines a safety related communication layer for EtherCAT. Safety over EtherCAT meets the requirements of IEC 61508 SIL 3 and enables the transfer of safe and standard information on the same communication system without limitations with regard to transfer speed and cycle time.
The following features were crucial in the development of the Safety over EtherCAT protocol:
- Compliance with Safety Integrity Level SIL 3 of IEC 61508
- Safe and non-safe information on the same communication system
- Independence of the protocol from the transfer system and medium
- The length of the safe process data is not restricted by the protocol
- Very short frame lengths are possible
- No limitations with regard to transfer speed and cycle time
- Lean specification leads to small implementation efforts, high performance and short reaction times
Numerous companies use Safety over EtherCAT already in their machines and plants. The growth of the EtherCAT Technology Group shows the growing spread of the EtherCAT technology – and thus of the Safety over EtherCAT technology.
Since the beginning in 2005 Safety over EtherCAT was open and independent of the underlying bus system. The submission of the protocol to the international standard IEC 61784-3 "Functional safety fieldbuses" underlines the open technology. Furthermore the ETG Working Group Safety specified a Safety-Drive-Profile for the common handling and parameterization of drive integrated safety functions. The ETG strives to enable this profile for other organizations, too.
Safety Fieldbus System
Intelligent safety solutions in the automation components and communication systems enable integration of safety technology into the machine design. One of the key factors enabling this kind of integration is the transfer of safety-related and standard communication on the same fieldbus. The solution for EtherCAT is the Safety over EtherCAT protocol.
The benefits:
|
 |
Technology Requirements
The basic principles for testing and certification of bus systems for transferring safety-related messages are specified in the international IEC 61784-3 standard.
The following errors for such a network have to be assumed: corruption, repetition, interchanging, loss, delay, insertion, masquerading and invalid addressing of messages.
For controlling these errors, the Safety over EtherCAT protocol includes:
|
 |
The Safety over EtherCAT protocol has been assessed by German Technical Inspection Agency (TÜV Süd). It is certified as a protocol for transferring process data between Safety over EtherCAT devices up to SIL 3 according to IEC 61508. The implementation of the Safety over EtherCAT protocol in a device must meet the requirements of the safety target. The associated product-specific requirements must be taken into account.
The calculation of the residual error probability for the Safety over EtherCAT protocol takes no credit from the error detection mechanisms of the communication system - the transport medium is regarded as a "black channel". This means that the protocol can also be transferred via other communication systems. Any communication path can be used, including fieldbus systems, Ethernet or similar transfer systems, optical fiber cables, copper cables, or even radio links. This is utilized, for example, in internal sub-bus systems for modular I/O system components or for routing the Safety message via a standard PLC between the Safety Master and the Safety Slave.
Implementation Aspects
"Simple is Safety" – this was the central principle for the specification of Safety over EtherCAT. Therefore the specification is very lean and simple mechanisms ensure the required safety integrity level. Implementation of the technology becomes quite easy. Details for implementation are shown in the FSoE Implementation Guide.
EtherCAT is used as a single-channel communication system for transferring safe and standard information. A safety frame is included in the EtherCAT process data. This "container" is analyzed in the devices at the safety application level.
| The communication remains single-channel. Via suitable procedures, the frame is designed such that a minimum container length of 6 bytes is sufficient for transferring all error detection information, including one byte of safe process data. On the other hand, the protocol does not impose any limits regarding the length of safe process data. This means that safety components with a large amount of safe process data are also supported just by adding as many SafeData/CRC_x parts as needed for the safety device application. |  |
Safety over EtherCAT uses a master/slave relationship between two devices, the Safety over EtherCAT connection. It is ensured that each device only returns its own new message once a new and valid message has been received. The complete transfer path between master and slave is thus monitored in each cycle; accumulation of delay times is eliminated or detected. This enables very "lean" implementation of the protocol , with moderate requirements in terms of communication system access, since no hard timings for time synchronization is needed, in contrast to Publisher/Subscribe technologies that need time synchronization on the safety level.
| During start-up of a Safety over EtherCAT connection, a state machine is processed both in the master and in the slave. Here again, the focus was on a simple structure in order to make implementation as simple as possible. State transitions are initiated by the master and acknowledged by the slave. The "data”" state is the normal operating state for exchanging safety input and output data. If one of the devices detects a communication error, it changes to reset state, thereby resetting the connection. |  |
Application Example
The safety and functionality of a safety communication protocol can only be proven through implementation in a product. Devices with Safety over EtherCAT have been available since 2005. EtherCAT is therefore one of the first Industrial Ethernet real-time communication systems supporting a safe protocol. Many ETG Members integrate the technology in their device architecture. Today, the usage in numerous applications emphasizes the acceptance by users and vendors.
Scalable safety-related input and output components can be used in the system; additional inputs or outputs can be extended flexibly using safety and non-safety devices as required.
| Even the safety logic can be embedded within the network. The control PLC then remains a standard device without safety extension and the safety logic is processed within a safety device in the network segment. This saves costs and enables scaling of the safety logic within the system. Only the messages between the Safety over EtherCAT master and the corresponding safety slave devices are routed via the standard PLC. Of course the classical safety PLC architecture is supported by Safety over EtherCAT as well. |  |
| With the black channel approach even the concatenation of machine parts is possible. The Safety over EtherCAT Frames are routed via the standard communication path on the Process Control level , for example via the EtherCAT Automation Protocol (EAP). |  |
