A new standard for networked safety
The openSAFETY standard eliminates the "Fieldbus wars" of years past and creates a singular standard that provides both safety and versatility for industrial network users.
In the mid-1990s, the automation world faced a situation it called “fieldbus wars.” In the absence of a single, internationally recognized industrial network standard, various automation suppliers filled the void with their own digital networks, which we live with today: EtherNet/IP, DeviceNet, Modbus, Profibus, Profinet, Ethernet Powerlink, and there are more. Then, there appeared to be hope for standardization with the rise of industrial Ethernet around the turn of this century. Unfortunately, all that happened was the migration of the surviving fieldbus application layer protocols to Ethernet cables.
Today’s major network development is safety. Even now, safety circuits on packaging machines are still largely hardwired devices, which are complex to install and troubleshoot and have limited functionality. Then came the safety PLC, but cost largely kept builders of individual, isolated machines from adopting this programmable technology.
Now, the same network that controls the machine—or even the entire line—can provide communications for safety processors, safety devices, safety I/O modules, and safe drives. So this time around, there’s no need for “fieldbus wars.” There is a single IEC-approved standard in the public domain that can run as an open protocol on the application layer of your network of choice. The advantages are huge and benefit the entire manufacturing community—users of machinery, device manufacturers, and machine builders—all of whom must otherwise learn and support multiple safety networks (Figure 2).
The standard, which is called openSAFETY (www.open-safety.org), is available from the Ethernet Powerlink Standardization Group (EPSG) (www.ethernet-powerlink.org). In addition to Ethernet Powerlink, EPSG has implemented fully functional openSAFETY solutions based on (and compatible with) Modbus TCP, EtherNet/IP, Profinet, and SERCOS III, which will likely lead to rapid growth of this SIL3-certified safety protocol.
Benefits of specifying modern safety technology
In the past, an e-stop meant dropping out the power, which generates wear and tear on both the electrical and mechanical systems. It also meant the machine stopped at whatever point in the cycle it was in when the power went out.
With integrated safety systems now available, drives can come to a stop under control without a full machine shutdown. Integrated safety allows various kinds of stops to be made, ranging from completion of the last cycle to a fast but gentle idle. In short, the machine is placed into a safe state. The machine or production line does not need to be re-homed, thereby avoiding jams and sequencing errors.
With intelligent, decentralized, and integrated safety technology, it is also possible to respond more quickly to unexpected situations and to provide safety without necessarily stopping the production process. Various safety processors may also perform safe configuration management, safe parameter management, and safe application processing functions, all of which are central to the range of machine safety concepts.
What should specifiers do?
Early adopters who want to integrate an openSAFETY-based safety solution with their existing data communication system should incorporate a request for conformance language in their electrical specification. The request for conformance states that priority consideration will be given to accepted suppliers that:
- Integrate the openSAFETY protocol on the application layer of their bus system
- Direct their device supply divisions and third-party suppliers to develop compliant networked safety devices.
When these requests start coming from a growing number of automation specifiers, the commercial equation becomes simple.
It’s also advisable to join EPSG and publicly support openSAFETY as a number of European companies—including Airbus parent EADS and the French National Railway System—have already done. Typically, the faster, louder, and more prevalent the support for standards, the faster they are realized.
How openSAFETY works
Generally, openSAFETY provides data transfer definitions, high-level configuration services, and encapsulation of safety-relevant data in an extremely flexible telegram format.
To communicate, openSAFETY uses a frame with a uniform format for payload data transfer, configuration, and time synchronization. Frame length is simply contingent on the amount of data to be transferred. The safety nodes on the network automatically recognize the content, so frame types and lengths do not have to be configured.
Automatic safe parameter distribution: One highlight of openSAFETY is the automatic safe distribution of parameters. The protocol enables storing of all configuration details for safety applications, such as light curtains, in the safety controller. If a device is exchanged, the safety controller automatically and safely loads the stored configuration onto the swapped application. Users do not need to manually configure the new node when they replace a safety device.
Fault detection: For fault detection, openSAFETY uses checksum procedures to perpetually examine whether transferred data content is incomplete. It constantly monitors the data transfer rate. Due to extremely short cycle times, failures are detected almost immediately.
Structure of an openSAFETY frame: Essentially, openSAFETY duplicates the frame to be transferred and conjoins the two identical frames into one openSAFETY frame. Hence, the openSAFETY frame consists of two subframes with identical content.
Each subframe is provided with an individual checksum as a safeguard. The receiver compares the identical content of the two subframes. The probability that the same data are changed or destroyed in two such subframes is extremely low, and even lower as the frame length increases.
Even in such an extremely unlikely case, the checksums still serve as a corrective action. The special format of openSAFETY frames, with their two subframes and their own individual checksums, also makes “masquerades” extremely unlikely to occur, and precludes any erroneous processing of a masked standard message.
The openSAFETY network: An openSAFETY network may contain up to 1,023 safety domains, with up to 1,023 nodes or devices permitted within each domain. Safety domains can extend over different and non-homogeneous networks, and can integrate safety nodes that are scattered throughout these into one domain. Safe and unsafe devices can be operated within one domain.
Gateways allow communication among different safety domains. Also, openSAFETY enables users to enforce hierarchical separations as well as to establish separate safety zones on a network. Therefore, service can be performed in one zone while production in other zones continues uninterrupted. In every domain, a safety configuration manager is responsible for continuous monitoring of all safety nodes.
Stefan Schoenegger is the managing director of EPSG and open automation business unit manager for B&R Industrial Automation.
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.