What is safety in industrial automation?

March 9, 2020
Being safe means different things to different people and to different processes — be sure to have a proper safety design that is fail-safe

I remember back in the good old days that an e-stop wired into a master control relay (MCR) was the only way to go to take power away from the controlled outputs in an automated process. There were always 200 devices in series—an exaggeration, maybe—so that any one of these devices could take the system down.

Have fun troubleshooting that mess.

Anti-tiedown pushbuttons on presses were all the rage until someone decided to see if they could tie wrap one of the buttons in the closed position and see if the press would still work. Imagine their surprise when it did. Pushbuttons were replaced by finger sensing, so that the operator had to use both hands for safety.

Therein lies the rub. The safety is for what or whom—the operator or the press? Well, it’s the operator.

Modern-day safety systems have morphed into something unrecognizable from the early days of simply protecting the operator. Safety devices, controllers and networks are all part of the puzzle that falls under the safety umbrella. This umbrella suggests that there is protection for all things automation, and it can do it with the same flexibility and software that we have come to take for granted in standard control systems.

Today there are different safety integrity levels (SILs). As per “A Guide to the Automation Body of Knowledge” from ISA, a SIL is not directly a measure of process risk, but rather a measure of the safety system performance of a single safety instrumented function (SIF) required to control the individual hazardous event down to an acceptable level.

Imagine an e-stop button that is required to stop a pallet wrapper in its tracks when hit. The reasons for this need can vary and needs to be defined by operations. Remember it is an emergency-stop function.

Let’s say it is wrapping tires, and the top course of tires shifts on the first wrap and needs to be repositioned. A normal stop function may be OK for this. However should someone open a gate that has not been identified as part of the safety system performance review, and approaches the wrapper, the wrapper has to stop 100%.

With a normal stop button, the contact block may have fallen off, and pressing the button does nothing. I have seen that happen.
With an e-stop, however, it has to work. Back to the old MCR system, an e-stop button was a mushroom-head button, red in color, with a single NC contact block—no different from a normal stop button, and it can suffer from the same issues.

In today’s 100% world, the e-stop now has two contact blocks and is normally wired into a safety relay or controller. This system detects a contact failure and wiring malfunctions. Also, when this e-stop is hit, it stays locked in, and the user has to twist it to release—all positive actions.

Some safety relays cannot tell you which e-stop has been pressed, but I would submit that a safety relay should only be used in a closed system, such as a small machine skid. For larger processes and processes that are distributed, the risk management system has to adjust.

The safety controller is software-driven and can report to the control system when the e-stop has been pressed. A safety network can be employed to connect multiple safety controllers together to create a homogenized system to protect all aspects of the operation.

Safety-device application determines the level of SIL. Level 1 is the old MCR system where the systems employ standard control elements.

Level 2 is entry level for a true safety system. Redundancy is the word of the day here. You could use a standard e-stop with two contact blocks with two MCR relays, and you would create a better safety system. But you would normally want to use fail-safe devices with a safety-rated relay system.

Level 3 is fully fault-tolerant. This is the level in which true safety-rated devices, relays and controllers would be used, along with the connectivity component where needed.

One application I was involved in was to detect a person who has entered an area in between moving carts. We used a Pilz eye-in-the-sky device, which detected movement within a configurable area.

There were two issues. The first was personnel safety. The company didn’t want to have anyone hurt from being in the wrong place. Secondly, a cart could twist and get trapped causing a pileup, which could harm the overall process.

There were times where an operator had to be in that area to perform his duties, which would shut the process down, which could not be disabled. The need to run the process became more important than the safety aspect, so it came down to training.

Being safe means different things to different people and to different processes. Be sure you have a proper safety design and that it is fail-safe.

The future depends on it.

About the author: Jeremy Pollard
About the Author

Jeremy Pollard | CET

Jeremy Pollard, CET, has been writing about technology and software issues for many years. Pollard has been involved in control system programming and training for more than 25 years.