I remember the days of hardwired emergency stops (e-stops) and master-control-relay (MCR) circuitry and the litany of devices that were deemed to be critical in the operation of the process. I’m sure that you’ve seen that line in the electrical schematics that take up inches of paper with the devices wired all in series. The amount of effort that was put into the troubleshooting of those devices was crazy.
Remembering that the MCR system was to provide L1/L2 power to the control system, one of the most used strategies was to wire in an input to the control system from the powered side of the device. The input light would be on for the devices that had power, and the first one that didn’t is the device that caused the MCR to drop out. The main question would be: Where is this device, and what does it do? These devices were normal control devices and not safety-rated as such.
Downtime was huge when this event occurred. Normally there was a handwritten list indicating the location and function since electricians didn’t have access to the programmable-logic-controller (PLC) software, I’m assuming.
The main issue here was the reliability of the MCR. If the relay was stuck then an e-stop would not shut down the system. While improbable, it happened.
With the advent of PLCs, the safety relay was born. It replaced the MCR by providing power to the system based on redundant input wiring. Two wires from each device, which was also safety-rated (fail safe) come from redundant contact blocks. The thinking here is that if one wire or contact fails the other one will still function. The standards surrounding safety are broad and deep. If the e-stop head gets knocked off, it trips. With certain devices, if the contact block falls off, it trips. That’s solid.
We want centralized monitoring however, don’t we? Supervisory control and data acquisition (SCADA) applications want access to it all. Most if not all SCADA or human-machine interface (HMI) can use OPC UA to communicate with any device. But a safety relay typically interfaces with the local process. The PLC will only know that it has tripped, which can be flagged.
This data-anywhere requirement was understood by the safety community. The safety PLC has evolved to become a required component in all controlled processes. Machine control has been a bit slow to the party to implement to this level.
Safety networking also has been evolving over the past 20 years due to the integration of Ethernet into plants and machines. CIP Safety is one protocol that can exist on an Ethernet network, wired or wireless.
The safety PLC requires the devices to be direct-connected to the I/O, whereas a safety-networked system can connect various devices on the same cable. Because CIP Safety is a protocol, devices can reside anywhere in the plant.
Communication is key in the interpretation of all safety systems. While some HMI systems may not be able to integrate all safety systems, SCADA systems should have no issue in getting the status of the connected devices and the health of the safety systems.
One installation I developed was integrating five safety PLCs with three PLCs, and the process had various touch points. Should one area experience a safety issue, the event is rippled through the system based on what the event was. At the time there was only a networked module that allowed the devices to talk with each other. The PLCs had the ability to monitor the state of the controllers but had no way of accessing the data. We had to hardwire status and control to and from the safety PLC and the control PLC, which was not ideal at the time, and that was less than 10 years ago.
If I had to redo this application, a true networked safety PLC would be used, which would allow for a distributed safety system. This would be much easier to implement and interface with. I had also developed an interface using Visual Studio that would have been able to display the status of the complete system. There were many e-stops that were wired into the control PLCs so they could be reported on.
There are many standards and protocols to consider when dealing with safety devices and systems. Cost is for sure an issue, but the abilities of modern safety implementations are impressive.
With Industry 4.0, the Industrial Internet of Things (IIoT) and of course cybersecurity coming to our future, and the continued integration of systems, communications and devices from different vendors including robotics, a distributed-safety strategy is paramount.
With wireless connectivity available, as well, one can only imagine how engineers can design safe and functional systems to protect machines, processes and people. We are in good hands.
