openSAFETY over OPC UA
On a conventional factory floor, machines from different vendors work away at their respective tasks in relative isolation. Any safety events that occur are handled locally on whichever machine is directly affected, while the rest of the line either continues with production or is simply halted. This lack of cross-machine communication has made it impossible to coordinate safety reactions across entire manufacturing lines. In the worst case, a single defective safety door could cripple an entire assembly line. It is certainly not impossible to join machines from different vendors in a single safety network – it's just that doing so requires an extensive amount of factory-floor programming. Then, once the line is up and running, you would need to reprogram and revalidate the safety application any time you add, remove or modify equipment. That's just not a viable solution in real-world conditions. If sufficiently detailed information about an event is shared safely across the line, then the various machines can orchestrate very robust reactions to safety events. By triggering coordinated responses – such as throttling the overall rate of production – integrated safety solutions help avoid outright stoppages and keep unscheduled downtime to a minimum. The ultimate goal in most Industrial IoT scenarios is to create autonomous, self-organizing lines that enable implementation of modular, responsive manufacturing concepts. While these concepts are already being implemented successfully at the level of functional control, achieving a comparable degree of flexibility in line-level safety technology has so far seemed an insurmountable hurdle. Self-organizing safety networks will make it possible to add or remove entire machines or individual components from the machine network without having to reprogram the safety application. It would even be conceivable to create a self-validating line. The combination of OPC UA and openSAFETY make it possible.
Solutions based on OPC UA and the open-source safety protocol openSAFETY open up entirely new potential for self-organizing safety networks. A number of fully automated processes based on these communication technologies make it possible to implement such networks without any compromises in terms of safety and security. When a machine, assembly or robot is connected to an existing machine network, OPC UA is the first to come into play. OPC UA mechanisms establish a secure connection and the discovery service and server capability identifier allow the newly added device to establish a secure connection and search for other servers that offer safety functions. Then, the newly added machine uses OPC UA browsing services to determine which functions and attributes these servers provide. This process – already possible using OPC UA – allows any OPC UA server to get a complete map of the network on its own without requiring a single line of code to be written. Once these initial steps have been completed, openSAFETY enters the scene. If the safety application recognizes that the new components are already known, or if all safety-related characteristics are comparable to a previously validated configuration, then the line quickly resumes operation with no further actions required on the part of the machine operator. If significant differences are identified, the user is asked to confirm on the HMI screen whether the new configuration is correct. This input is saved, so the next time the same configuration will be recognized automatically. Via openSAFETY, every safety controller in the network also tests whether the necessary response times and cycle times are plausible on the OPC UA communication channels to ensure that required safety reactions can be triggered reliably. Once this testing is complete, communication of safety-related process data begins and the line can resume normal operation.