Functional safety, as an integrated part of the network architecture, is standard in modern communication systems. Thus, the question is not if, but in what manner, this integration will be realised. Uncertainty amongst users 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 architecture for coupling machine modules of different manufacturers, as is often the case in modern product lines.
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 standardised 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 along 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.
This circumstance is defined more accurately in IEC 61784-3, which describes the basic requirements for a safe communication system. Based on these, different safety protocol technologies are defined within this standard.
On one hand, certain errors that 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, the standard demands that on the transmission channel, less than one out of a hundred bits 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.
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 minimum 68 bytes = 544 bits. Thus, each frame would be disturbed and reliable 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 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 that consistently use an Ethernet-based communication system: backplane buses, internal serial interfaces in the devices, or active standard components, e.g. controls or switches that distribute or forward the safety messages. These must be consistently included 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 centralised and decentralised safety controls. The transmission path is arbitrary and is not restricted to EtherCAT. For the transmission on electrical cables, fibre optics, or even radio transmission, classical 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 simplification of the implementation. The communication interface can perform 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 stop 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 realise 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 pre-processed, filtered information – it is lean and can be standardised via an open interface profile.
Compiling results from discussions with numerous users, together with OMAC (Organisation 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.
For more information contact EtherCAT Technology Group, +49 911 540 56 226, press@ethercat.org, www.ethercat.org
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version