The following discussion is part of an occasional series, "Ask the Automation Pros," authored by Greg McMillan, industry consultant, author of numerous process control books, and 2010 ISA Life Achievement Award recipient. Program administrators will collect submitted questions and solicits responses from automation professionals. Past Q&A videos are available on the ISA YouTube channel. View the playlist here. You can read all posts from this series here.

Looking for additional career guidance, or to offer support to those new to automation? Sign up for the ISA Mentor Program.

Jorge Mirabal’s Question 

What should be the approach to upgrading a legacy control system combining process control and safety systems within the same controllers?

Hunter Vegas’ Answer 

I’m always very leery to mix control and safety in the same controller assuming we are discussing safety integrated level (SIL) rated loops and not general process interlocks that require no SIL designation. There are some vendors who sell a combined “Safety/Process” controller that purports to be a fully independent system, but I would definitely push back on those vendors to prove those systems are in fact fully independent. Typical places where they fail include: 

1. How do they separate the safety processing from the process control processing? Do they use common communication backplanes, power supplies, or networking components that could impact both systems? 
2. The configuration software itself – does it use one piece of software to configure both? If so, how do they guarantee that a common cause failure can’t impact both?  (e.g., software bug, software patch, etc.) 
3. Data transfer between systems is always a source of problems. If the safety and process controllers are trading information back and forth, what happens when those communications fail? Does the safety processor just run on the last good value? Do the values go to zero? Does the safety processor trip if it cannot communicate? What communication watchdog logic does it employ? 
4. Input/output (I/O) cards – Can either process use/access both safety and non-safety cards? Can standard I/O be utilized in safety interlock logic? 

There are so many opportunities for common cause error and unfortunately it can be impossible to really understand how those items are addressed (if at all) without simply taking the vendor’s word for it and hoping you aren’t being misled. When you have two separate systems, at least the failure modes are relatively straight forward and understood, and common cause failures are significantly reduced. Data communication between systems can still be a challenge, but in this case the communication paths are well defined and easy to understand so you can control what happens when communications fail.

Nicholas Sands' Answer 

This may fall into the category of “just because you can, doesn’t mean you should.” As Hunter mentions, there are a lot of considerations. There is a separation requirement between the basic process control system (BPCS) and the safety instrumented system (SIS), but it can be functional and not physical. There is also the option of treating the whole system as a SIS.  

Often there is the marketing message that a system is certified to perform both safety and control. Then there is the safety manual that supports that certification, and it has all the rules you have to follow. There can be a lot of rules, from I/O card types to I/O segregation to function block limitations. A functionally separate system may have separate programs with strict rules on communication between the programs. The rules can change significantly based on safety integrity level (SIL), from SIL1 to SIL3. The devil is in the details. Review the safety manual before you make the decision and not just the marketing messages. 

Cybersecurity is another important consideration. The engineering station should be in a secure zone, and the SIS engineering station should be in the most secure zone. This is often overlooked, and a combined engineering station is in the control system security zone and not the SIS security zone. There are other security measures that can be used if the issue is recognized. Design security into your system. 

Bart Propst's Answer 

Pros of combined system 

• Cost for single system for hardware, communication, engineering 
• Device sharing is easier 
• Single programming interface 

Cons of combined system 

• Independence requirements more difficult to document   
• Common cause errors due to human error. The weak link is the human interaction in all phases of system design, installation, commissioning, operations, maintenance and testing.   
• Lack of independent programming environments 
• Process control functions probably cost more to implement in SIS hardware compliant system 

Common considerations 

• Certification standards – IEC 61508 – for software and hardware  
• Fundamental programming and diagnostics of BCPS functions versus SIS programmable logic controller (PLC) functions 
• Cybersecurity considerations 
• Personnel technical competency 
• Human error, which scares me the most 

Other thoughts: 

Perhaps AI will help reduce and test for errors in hardware and programming. I believe that overall, the cons outweigh the pros at this time. I would not recommend combined systems. 

Len Laskowski's Answer 

Batting cleanup after three heavy hitters like Hunter, Nick and Bart is tough. They have given some very compelling reasons not to do SIS and BPCS in the same logic solver. I agree with the points they have provided above. Outside some very specialized applications, like compressor surge control, I have not seen anyone attempt this in my 48-year career. If it is initial capital cost you are trying to save, I am confident the burden of safety life cycle details will create additional issues and cost way above traditional separate SIS and BPCS systems. The combination of the SIS and BPCS will open numerous problems that will compromise the security and safety of the system. At least one SIS vendor does not even offer a traditional analog output for just that reason. 

Nick said, “Just because you can, doesn’t mean you should,” and these are very strong words of wisdom. 

Peter Morgan's Answer 

Separation and diversity has been the guiding rule behind designing reliable safety or shutdown systems for several decades. Fortunately, with a number of contemporary control systems, this design criteria can be met with fewer integration issues than existed in the past.

The projected achievable SIL for contemporary safety rated systems does give pause for thought (and a temptation) regarding the implementation of basic regulatory controls and safety/shutdown logic in the safety rated controller, but the benefits of separation cannot be overlooked. Separation does of course reduce the probability of common mode failure, but can also reduce the demand rate for the SIS by a factor of 10 for a shutdown initiator when the initiating process variable is controlled by the BPCS.

Another incentive to separate the BPCS and SIS related to access and change management when the strategies implemented in the BPCS can be improved without being subject to the controls imposed on the SIS, although appropriate change management procedures are required for any change to the BPCS. There are exceptions to the separation and diversity rule where the regulatory controls can (and should) be implemented in a safety rated system, these include turbine governing systems and compressor controls that are commonly referred to as "specialty controls" employing proven machine specific applications. 

Greg McMillan’s Answer 

I agree with and greatly appreciate the responses. I can understand the need of exceptionally fast responding equipment (e.g., compressors and turbines) for the control system and safety system to be on the same page. My remaining words of advice are to minimize the need for activation of the safety system and shutdowns, by the use of measurements and control valves that have good 5Rs (repeatability, resolution, reliability, rangeability, and response time) and by procedure automation.  

For critical measurements, the use of three separate sensors and middle signal selection helps provide much better 5Rs. The specialty chemical company I spent most of my career (33 years) at used three electrodes and middle signal selection (MSS) for nearly all pH control applications. MSS can inherently ignore a single failure of any type, even the most difficult one where the failed measurement matches pH setpoint (common case for broken glass electrode and 7 pH setpoint). MSS also reduces the effect of a slow, noisy, or erratic measurement. For one large difficult plant with a lot of recycle streams, the use of MSS greatly reduced the number of shutdowns per year. Starting up a plant can be the most challenging and potentially unsafe situation. 

Procedure automation in the BPCS has been shown to be able to automatically startup a plant more safely and quickly. I have used this numerous times especially for compressor control prior to the ISA Standards and Practices technical report on procedure automation (ISA-TR106).  When operators would say it was not possible to automate a startup, it turned out that this was more of a motivation for me to do it. It meant they often had several failed attempts and had taken far from the best actions – wasting time and raw materials, as well as possibly activating safety systems. The analysis of the best operator actions and the use dynamic simulation can find and confirm the best sequencing of PID modes and outputs. Procedure automation can also help deal with transitions to different product grades and abnormal conditions, in which case it may be termed “state-based control.”