Safety systems are valuable. We’ve gone from a single master control relay to a dedicated “safety” relay and on to an actual safety relay and then to where we are with sophisticated safety controllers. Since the introduction of the safety controller, the product and method of deployment has expanded greatly.
The safety relay was a huge step forward. Built in to the function of the safety relay is the ability to attach various types of devices to a single relay that have specific behaviors. For example, a safety relay may have one channel that is specifically used for non-smart devices like an e-stop. Multiple e-stops or door switches will have two channels of safety and can be daisy-chained together but are powered externally from a power supply in the system.
The safety relay automatically monitors the two legs of the safety channel, and, if one has a different state from the other, even for a short segment of time, the safety relay will fault the channel and the device will be rendered off/faulted, until both legs can be cycled off and then on again. Some safety relays require the safety relay itself to be power-cycled to clear this fault condition.
Another safety relay channel might have smarter devices using output switching signal device (OSSD) technology. The safety device, even in an untripped state, generates a periodic low on the outputs—two legs of the safety channel. The protective device—the safety relay, in this case—monitors this brief lapse to ensure that the device does, in fact, go low when commanded. For these devices, the safety relay provides the power to the channel devices and monitors its own status back at the input points on the channel in question.
Safety relays may have multiple channels and a variety of combinations of normal and OSSD device channels. Some safety relays will have a means to change the relationship between the various channels to make some simple logic choices. For example, a rotary switch might be used to tell the relay that Channel A and Channel B must both be active for the safety relay to allow outputs.
Another might be configured that Channel A or Channel B will allow output from the safety relay or it might require A OR B AND C or it might allow A AND B OR C. There are a limited number of combinations in these circumstances, so what do you do if you need more? That is where the safety controller comes into play.
The primary difference between a safety relay and a safety controller is a safety controller has actual logic capabilities.
One of the aspects that has always fascinated me is the decision—it seems like a decision—to employ gate logic to program a safety controller. Let’s look at this for a moment.
You might have noticed that the logic choices on the safety relay above sounded similar to gate logic. Channel A AND Channel B OR Channel C might represent a situation where each side of a machine guarding might have a channel assigned to the safety relay—channels A and B—but a key switch might be connected to Channel C. That scenario will provide an override of the normal guarding to allow for jogging a machine with a door open. The associated A or B channel would normally turn off in this situation. Gate logic is well-suited for safety controllers because there is less chance of an error in programming to produce an unsafe state.
Another key feature of the safety controller is the use of multiple inputs, or channels, and outputs. This allows each safety device to have its own channel that is separately monitored from the others on its own merits. These inputs can also be specifically defined as a certain type. For example, an e-stop button, with dual contacts, has a different behavior from an OSSD non-contact gate switch or the monitoring relay from a light curtain.
Once the safety controller has been programmed and deployed, the switching out of inputs for something other than the programmed profile would result in an error and prevent the safety controller from allowing outputs.
Further extending on the last point, the inputs and outputs can be further defined to be part of a zone. This is very helpful when the safety controller is used on a larger machine or process where it might be possible to interrupt, or disable, one zone while others continue to operate.
A safety controller when tied to a machine-level network can allow status of individual inputs or outputs to be available for interrogation in the controlling programmable logic controller (PLC) or programmable automation controller (PAC).
Further, the results of gate logic within the safety algorithm can be interrogated to prompt action in the PLC or PAC. This is helpful when relaying information to the operator/user that can be displayed on the control screen without needing parallel wiring to have status in both the safety controller and the PLC/PAC. For example, one zone might have two guard switch circuits and a light curtain. The status of logic in the safety controller night indicate the guard circuits as closed and reset, but the light curtain is still tripped.
One of the main considerations for both safety relays and safety controllers is to have an independent device with the sole purpose of performing the function of safety. The only inputs are safety-related devices. The outputs only go to safety-related devices. The safety relay has only safety-related functions built in, like channel monitoring, and for some safety relays a few selectable choices for output logic.
The safety controller takes all this much further.
Paramount to all of this, the safety controller has an independent processor that is dedicated to interacting with the safety devices only. The one and only purpose in life is monitoring and controlling safety devices. This adds a layer of confidence to our control circuits because the PLC/PAC could totally fail to function, but the safety controller will continue to respond to the presence/absence of safety input devices and make decisions that affect the safety outputs from the control.
As control designers, we have our focus on the design function in front of us. A big part of our perhaps less conscious activity is looking at the bottom line, the price of the project. PLCs have evolved over time. The price of a brick PLC back in the 1980s was nowhere near the price of even the smallest PACs now available. Just the other day I had a quote for a project I am working on, and the processor, all by itself, was more expensive than the whole PLC of similar I/O points with rack and power supply from even 10 years ago.
The same holds true for safety relays and safety controllers. Safety relays are clearly more expensive than a normal mechanical relay, but, as we know, they perform a safety function and perhaps that allows us to gloss over this needed expense.
Safety controllers, on the other hand, are a far jump from the cost of a safety relay. Without going into much detail, the internals of a safety relay are not that much different from the PLC/PAC processor, though the differences are significant. Both are high-speed processors, perhaps even dual-core. Technology comes at a cost, and this sure follows that path. Making the jump from a PLC with a safety relay to a PAC with a safety controller is a huge jump. You are basically buying two controllers. To the accounting team, this is doubling the cost of core elements of the project.
To help with this difficult decision, some manufacturers have started offering PACs that have a completely independent safety controller onboard. A common term for this is primary and safety partner controllers in a single hardware package.
There are safety I/O modules that are completely separate from the conventional I/O modules. Since safety normally takes up far less I/O than conventional I/O, the combo hardware can usually be configured to have two or four safety I/O modules and 16 to 30 conventional I/O modules.
In such a way, these dual controllers can achieve safety integrity level (SIL) 2 on the primary controller and up to SIL 3 on the safety partner controller.
Safety partner controllers can use produce-consume methodology to share tags between like controllers. Extra protocol settings are required to specifically point at the receiving safety controller by use of safety network number (SNN) or similar defining method of identifying each safety controller on a network.
One thing we know for sure, prices do tend to go up, but, with the ability to combine both primary and safety partner in a single hardware module, the costs can be offset somewhat.
The evolution from master control relay to safety relay to safety controller has sure been a significant process, and, at least for me, confidence is growing that we can employ safety circuits that have a high degree of success for all involved.
