Multivendor Ethernet Safety Protocol - Noble Goal

April 292011
Multivendor Ethernet Safety Protocol - Noble Goal
April 2011
 
By Bill Lydon, Editor
 
B&R Automation brings multivendor safety issue into focus.
 
The openSAFETY standard supporters are posing an interesting idea to the industry - use a single Ethernet-based safety protocol, openSAFETY, on all automation applications regardless of industrial Ethernet protocol used for controls. The noble goal is to have uniformity and interoperability for seamlessly safeguarding entire production facilities across all industrial networks with one safety protocol.  The openSAFETY protocol is being promoted by the Ethernet POWERLINK Standardization Group (EPSG).
 
Characteristics of openSAFETY
 
The group characterizes openSAFETY by these measures: definition of data transport using an extremely flexible telegram format, integrated services for configuration and automatic parameter distribution, and in particular by a communication structure that achieves optimum machine productivity.
 
The openSAFETY Protocol makes safety-related data exchange possible over various industrial networks.  It is suitable for communication cycles in the µs range and allows implementation of safe systems up to SIL-3 (Safety Integrity Level) in accordance with IEC61508. The openSAFETY specification is certified by the TÜV Rheinland.   The openSAFETY concept has been demonstrated at trade shows working with SERCOS III, Modbus TCP, EtherNet/IP and POWERLINK.   The openSAFETY website also illustrates communications over PROFINET.
 
 
Black Channel
 
The EPSG group describes the use of the “black channel principle” as the basis for interoperability with various transport protocols for openSAFETY. In simple terms, the openSAFETY messages are tunneled through other protocols as closed application data packages traveling in safety frames, and integrated into the rest of the data traffic, guaranteeing independence from the transport protocol.   openSAFETY uses guarding mechanisms including protection of data content by using CRC codes. A time-based monitoring of communication is carried out independently from the host transmission protocol.  openSAFETY thus enables safe transmission of data over a range of networks.   
 
 
The openSAFETY logic continually monitors all transferred data content to ensure that it is complete, that it has the correct transfer sequence, that the transfer duration is maintained and that all transfer errors are immediately recorded.
 
Open Source
 
The protocol is available for free download as open source software. The openSAFETY protocol stack is licensed by B&R Automation under the BSD license and can be downloaded from the IXXAT webpage free of charge.
 
openSAFETY protocol
 
A safety protocol's task is to ensure data transfer integrity. At any given moment, it must confirm that data is transferred in full and on time. No data duplications, nor data losses, nor data manipulations, nor data insertions must occur in the course of the transfer. A safety protocol also has to recognize faulty data sequences or excessive delays in the transfer. The system therefore has to perform cyclic checks for error-free operation of all safety-related network segments, and of the functions of devices on them. In case of interruptions or incomplete data transfer, it activates proper safety functions in response to that or initiates the safe shutdown of the system/plant.
 
Key characteristics of the openSAFETY protocol include its extremely flexible telegram format, and the encapsulation of safety-related data. Safety nodes on the network automatically recognize the content, i.e. the frame type and length does not have to be configured. The protocol unifies all safety-related functions in the openSAFETY layer. The functions and services encapsulated in it include the Configuration Manager, Network Management, Object Dictionary, management of Objects and Service Data Objects, and time synchronization. Since openSAFETY only uses the application-oriented layers of the OSI model, it is independent from the bus protocol in use.
 
openSAFETY divides the data format into two subframes with identical content, and safeguards their integrity via checksums derived from different calculations.  During readout, the protocol first uses these checksums to verify that the frames are complete. Subsequently, it compares the actual data content of the subframes. In addition, the protocol takes signal run times and processing times into account, since bus-based systems can generally not compete with the transfer speeds achievable for components with dedicated connections.  Similar to the closed-circuit principle in separately wired systems, emergency stop disconnecting devices continuously send data to a safety relay via the safety-oriented bus in order to ensure an intact connection. Since all data traffic irregularities will thus be recognized, even non-safety networks do not compromise safety functionality.
 
An openSAFETY network may contain up to 1023 safety domains, with up to 1023 nodes within each of these. Safety domains can extend over different and inhomogeneous networks, and can integrate the safety nodes that are scattered throughout these into one domain. Communication between different safety domains passes through gateways. openSAFETY enables users to make hierarchical separations as well as to establish separate safety zones on a network. Therefore, service technicians may work in one zone, while production in other zones carries on unimpeded. In every domain, a Safety Configuration Manager (SCM) continuously monitors all safety nodes. The SCMs are in charge of permanently storing specific parameters that cannot be stored in the safety nodes themselves. Their tasks also include assigning and confirming addresses (specific safety addresses – SADR) that give all nodes unique identities. In addition, an SCM broadcasts the Life Guard signal, which is used to ensure that every node configuration works as expected. As long as they receive the Life Guard signal, safety nodes remain operational. If they cannot receive the signal, they switch to pre-operational state.
 
Performance
 
The end to end communications times of openSAFETY messages being transported or tunneled are dependant on the response characteristics and loading of the particular industrial Ethernet network (Examples: SERCOS III, Modbus TCP, EtherNet/IP, POWERLINK). This needs to be considered in project design and to be fair is an application engineering consideration in any industrial network that shares control and safety communications. The EPSG group states that the performance of well-known Industrial Ethernet systems is sufficient for most applications.
 
Ethernet POWERLINK Standardization Group Background
 
The Ethernet POWERLINK Standardization Group (EPSG) based in Switzerland is an independent registered association with a democratic charter, founded in 2003 by leading companies from the drives and automation industry.
 
Thoughts & Observations
 
The openSAFETY protocol is an interesting idea that allows customers to have various industrial control networks and a single safety network.
 
Achieving the full benefit requires a user to make a commitment to using all openSAFETY compliant safety devices. This is offset by the fact that the openSAFETY protocol is open source with no licensing fees.
 
Having safety running over networks has advantages but does create a dependency on performance that is related to system design and network loading. Adding things to these networks over time may also have an impact on performance. The big fact to remember on all networked safety systems is that if communications fails the node will go to “safe” mode, which may shut down a process or machine.
 
This openSAFETY concept could be simply an interesting idea but the openSAFETY group has published a number of testimonials from users:
 
“Reliability, availability, interoperability, fast reaction times, deterministic behavior and open architecture are all key factors for power generation control. POWERLINK communication technology fulfills these requirements for distributed control systems and machine control, and with openSAFETY we are guaranteed full data integrity when exchanging data over multiple networks. openSAFETY is the only safety standard that is fully open and independent, thus ensuring safe data exchange and complete interoperability in a multi-vendor network environment. openSAFETY is the ideal solution for critical automation processes, today and in the future!” Christian Kervenec, Vice President Technology, Alstom Power Automation & Controls
 
“Nestlé uses automation and safety components from many different suppliers. Having a single safety communication standard will allow us to reliably exchange safety information across the entire factory floor, regardless of the brand of components. Such a standard also facilitates engineering in terms of system design and commissioning, and operations in regards to maintenance and troubleshooting of safety systems.” Bryan Griffen, Head of Electrical & Automation Engineering, Nestlé Corporate Engineering
 
"What today's fieldbus systems have not been able to achieve - a uniform standard in protocol structure - is essential for safety technology. openSAFETY is the key that unlocks this independent safety protocol." Horst Jacob, Technical Manager, Rügenwalder Mühle Carl Müller, GmbH & Co. KG (Food Company)
 
“ZAT is one of the leading suppliers for energy providers in the Czech Republic as well as abroad. The complexity of these tasks requires a highly sophisticated safety solution. That is why we trust in openSAFETY.” Jirˇí Vacátko, Control Systems Development and Production Executive Manager, ZAT
 
My initial thoughts after reviewing openSAFETY are that it is novel and clever. The idea has merit and maybe this is the beginning of an open source protocol trend.
 
Reader Feedback
 
Comments from Carlos Vieira, Control and Automation Engineer at Chemtech...
 
"My first criticism is directed to Ethernet protocols in general: they won't go to classified (potentially explosive) areas. This leaves a lot of potential applications of such protocols out of the question."
 
"The second criticism is the implied use of control and safety data on the same medium. It's bad practice. When you''re going to maintain/replace a control device that sits in the safety infrastructure, your plant is likely to shutdown. Likewise, as the article points out, network loading issues might affect both the control network and the safety network - thus becoming a common mode of failure."
 
"These do not invalidate the proposal, but they make it less attractive. If I'm going to build a separate safety network (using COTS hardware or not), having a super-compatible protocol or a very restricted one won't make a difference. I'd be much more pleased if somehow I could reach both my regular and my classified areas with the same configuration and maintenance tools."

MORE ARTICLES

VIEW ALL

RELATED