Safety over EtherCAT

  • July 30, 2014
  • Feature

By Guido Beckmann

Functional safety, as an integrated part of the network architecture, is a standard in modern communication systems. Thus, the question is not if, but in what manner will this integration be realized. Uncertainty among users still remains regarding the requirements of the system, and the possibilities of coupling different machine modules. This article highlights possible pitfalls stemming from implementation, as well as the usage of a safe fieldbus. Additionally, the article will introduce system architectures for coupling machine modules of different manufacturers, as is often the case in modern production lines.   A plant structure consists of many individual modules. The Safety over EtherCAT (FSoE) protocol enables safety-relevant data transmission, in parallel to the standard data on the same network. FSoE is a technology certified by TÜV, developed according to IEC 61508, and internationally standardized in adherence to IEC 61784-3. The protocol can be used in applications requiring a Safety Integrity level as high as SIL3. Device manufacturers especially appreciate the lean specification which comes with this simple, high performance implementation. End users are thrilled by the robustness of the protocol, as it does not make demands on the subordinated transport system, and thus can be used plant-wide. How independent is the transport channel? Usage of a safe protocol on a standard communication system is based on the so-called “Black Channel” approach. This means that – due to the type and quality of the safety measurements – the transport mechanism and the transport medium do not have to be included in the safety assessment. Theoretically, any transmission channel can be used.   An open interface profile enables standardized data exchange between the machine modules. This circumstance is defined more accurately in IEC 61784-3. The standard describes the basic requirements for a safe communication system. Based on these requirements, different safety protocol technologies are defined within this standard. On one hand, certain errors which can occur during the transmission via a communication system must be controlled by the safety protocol, e.g. corruption, loss, commutation or forbidden delay of messages. On the other hand, the standard demands that on the transmission channel, less than 1 out of 100 bits (Bit error rate < BER = 10-2) may be disturbed. This also assumes that this is a black channel, unless other proof is provided. The bit error rate is directly adopted in the calculation of the residual error probability, that is to say, the ability of the safety protocol to detect errors.   The Black Channel covers the complete communication path between the safe protocol layers of the devices. In most cases, a communication system with a BER = 10-2 can no longer be used for standard communication. Assuming an Ethernet-based transmission, for instance, an Ethernet frame needs at minimum 68 Byte = 544 Bit. Thus, each frame would be disturbed and feasible communication would not be possible. As result of this approach, some safety protocols use a BER of 10-3 (“only” every 1000th Bit is disturbed) as a basis for the calculation of the residual error probability. This is allowed, but requires close observation of the whole system or plant by the user. There are often subordinated communication technologies, even in systems which consistently use an Ethernet-based communication system: backplane buses, internal serial interfaces in the devices, or active standard components, e.g. controls or switches which distribute or forward the safety messages. These must be included consistently in the bit error rate of the transmission channel. The residual error probability of Safety over EtherCAT is based on the higher bit error rate, BER = 10-2. Thus the protocol is independent of the transmission path; it is suitable for both centralized and decentralized safety controls. The transmission path is arbitrary and is not restricted to EtherCAT. For the transmission on electrical cables, fiber optics, or even via radio transmission, traditional fieldbus systems, Ethernet or similar paths can be used. No further limitations or proofs are required from the user. For the device manufacturer, this means the implementation is simplified. The communication interface can perform in a single-channel, as it is part of the Black Channel, so internal communication interfaces in devices or backplanes in modular I/O systems can be used unaltered. Plant-wide safety architecture Production plants are normally built out of several different process steps, with each conducted by separate machine modules. The interaction of those machine modules, conducted by a main control, is enabled via plant-wide networking. The machine modules themselves can be provided from different manufacturers, and therefore internally use different communication systems. The local safety functions of the machine modules are normally solved within the module. If, for example, a stopping function has to be activated by opening a protective cap, the dangerous motions within the module are stopped safely. Additionally, the machine modules must exchange safety information plant-wide, e.g. to realize global emergency stop functions or inform the previous or successive modules about the activation of stopping functions. The interface to each machine module normally consists of preprocessed, filtered information – it is lean and can be standardized via an open interface profile. Compiling results from discussions with numerous users, and as a result of work with OMAC (Organization for Machine Automation and Control), such a Safety Interface Profile has been developed. It is an extremely lean interface that activates the safety functions in a machine module by defining a safe control byte. The latter contains possibilities to activate stopping functions or safe motion functions within the module. A status byte then enables feedback from the machine module about its safety-relevant status to enable, for example, the approval functions in the plant. The interface is independent from the used safety protocol and, if needed, feasible without safety bus in the form of a wired I/O interface. Due to the independence from the transport medium, Safety over EtherCAT is perfectly suitable to transport this profile between the machine modules, as the modules’ gateway functions can be used to implement the module-specific safety protocol. Guido Beckmann is an expert on functional safety at the ETG. Additionally, he is part of the IEC Working Group SC65C/WG12 which works on the standardization of safe transmission protocols.

Learn More

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..