Integrated safety has a lengthy past as determined as its untold future.
Like pretty much everything else in our world of controls and automation, technology is always marching forward. I’ve found myself on the leading edge of the wave many times in my career when it comes to emerging technologies, and, while I might have enjoyed the rush of diving into a new product, the more mature—slower, older—version of me is a little less thrilled with the prospect.
Moving into a management role many years ago, the consideration of cost is certainly more in view than it was in my younger, let’s-give-it-a-go years. For these reasons, the prospect of combining safety and control into a single package was something I wasn’t quite ready to jump onboard with. Where does integrated safety stand? And where might it be headed?
The concept of safety controllers as a separate entity from a programmable logic or automation controller has been around for a long time. I remember working with early versions of a safety controller as far back as 2005. In those days, the focus was on having supervisory control over the safety devices on a machine or process that was physically and electrically isolated from the programmable controller that operated the equipment, so that a failure of the PLC/PAC would not incapacitate the ability of the machine or process to safely cease operation.
When I think of combining control and safety, I immediately think of process systems, rather than automation or machine control. The integration of the two concepts, however, is not new. As early as 2015, Institute of Electrical and Electronics Engineers (IEEE) had published a report out of its 10th IET System Safety and Cyber-Security Conference, identifying the economics and manageability of an integrated control and safety system (ICSS) over an isolated basic process control system (BPCS) with a safety implemented system (SIS), particularly in the oil and gas industry.
ndividual vendors had been promoting the use of ICSS for years prior. In fact, I’ve seen references as far back as 2011.
So, some of you are now wondering, what has taken me so long to get onboard? I would admit that it’s probably more about the philosophy of “don’t fix it if it’s not broken.” Though I hate to admit it, I have become complacent in my march through time. I submit that I’m probably not the only road warrior to get caught up in this comfortable position. Let’s lay out some pros and cons of separate vs. integrated systems.
[javascriptSnippet ]
In keeping safety and control separate, we encounter the following:
- The PLC/PAC is interested only in the control of the process or machine.
- Code is smaller, easier to navigate.
- Hardware is simple and familiar.
- Safety controller provides a signal (usually dual-redundant) to the PLC to not only drop out the power to the outputs, but also to bring the control system to a software stop.
- Negatively, there is more physical space required in a control panel to contain the separate components for control and safety.
The features listed above were part of the early advantages of a separate SIS. The programming structure of a safety controller has always been pictorial and resembling bit logic.
Most vendors provided an interface that was drag-and-drop in nature. One can quickly build up the structure of the safety circuit by identifying the zones of the machine or process and then declaring the interaction between the zones. Finally, the individual safety devices within each zone are defined and the desired functions are programmed.
In an ICSS, the control and safety controllers are in one package. The features of this unified system are as follows:
- The panel footprint is smaller.
- A common software platform means only one programming package is required to configure control and safety.
- A common package also means intrinsic interlocks between the two systems.
- Vendors offer hardware packages now that include both traditional and safety-rated I/O on the same base platform.
- A negative aspect is that the unified platform tends to be much more expensive than the separate systems. If there is a failure of the base control/safety processor, then the cost of repair/replacement is a significant consideration.
[pullquote]One-stop shopping for safety and control certainly has merit. A challenge of separate systems is bringing together functions into a unified, safe, dependable control solution.
Product offerings continue to evolve. One supplier representative has been gently poking at me for a couple of years to look at this technology, and, again, the old man in me has resisted the urge to look at the new candy on the shelf.
Moving into this hardware platform isn’t nearly as uncomfortable as I thought it might be. The conventional PAC is still there and functions as it always has. To that system, hardware is added for safety, and a separate safety task is added to the base architecture. PACs are after all multi-tasking processors. My particular hardware vendor has both a SIL-2 (Category 3) and a SIL-3 version, based on one-out-of-two (1oo2) architecture.
For clarification, there is a 1oo1, or single-channel, architecture and a 1oo2, or dual-channel, architecture.
A 1oo1 architecture is the simplest safety circuit, commonly referred to as a SIL-1, SIL-2, PL/a, PL/b, PL/c, PL/d or Category 2 system. It has limited ability to detect faults in bits or values, memory faults or problems introduced by electrical noise. Diagnostics usually run on a single processor, using the same paths and connections as the main controller and I/O and, for that reason, are not as reliable. For this reason, 1oo1 architecture may not be desired for processes where safety is a primary concern.
A 1oo2 architecture has dual paths through the safety system (sensors, logic, outputs and field devices) with either path capable of interacting with and controlling the safety function independent of each other to bring the system to a safe state. This system is considered fail-to-safe and gains a SIL-3, PL/d, PL/e, Cat 3 or Cat 4 rating.
Another advantage of the integrated control and safety system is the ability of the control processor to read the status of the safety memory but not write to it. In this regard, there is shared information with no possibility of a programming error causing the safety function to be impacted by the control function. One can even limit the ability of some users from gaining access to the area of the safety functions on the combined control/safety controller, further protecting the possibility of accidental compromise of the safety functions.
These combination controllers are able to host both conventional and safety I/O on the same backplane. Presence of the two types of I/O is automatically detected by the processor, and separate communication channels are used to interact with the modules, based on base function or safety function. These controllers also interact with integrated motion controllers and tie the safety functions into the control architecture. Safety I/O can be located on the host controller but can also be remotely located via dual-IP, linear or device-level-ring (DLR) topology.
Ultimately, the choice to continue using separate control and safety systems or unify them into an ICSS architecture is up to the designer, but any decision in this regard should involve some sort of dialog with the stakeholders in the project.
Safety, especially when the machine or process is in close physical proximity to people, must be the primary consideration when designing a control system. There might still be some hesitation to employ this rather sophisticated solution to a small machine where the safety is all in one zone and opening a door shuts down the whole machine, but this technology has advanced to a point where integrating it into a design is no longer a burden and should be a serious consideration in your next automation project.
