Process control and process safety have worked closely together for a long time. But, as with people’s relationships in the workplace, some would counsel against them getting too close, arguing a respectful and necessary distance. However, what the critics don’t realize is that simplified systems and software are allowing process control and safety to maintain their functional independence and diversity, but still combine for a very harmonious, long-term relationship.
“Combining safety and process control can be a pretty taboo subject sometimes, and so it needs to be discussed and demystified,” says Luis Duran, safety business development manager for control systems in ABB’s process automation division. “This includes understanding how to use the applicable safety standards and how integration truly works.”
"The main question to answer is do they have enough functional diversity to avoid a common-cause failure.” ABB's Luis Duran explained how to reap the benefits of process control and safety integration―without compromising either one.
“For instance, ABB has been installing and operating integrated safety systems for 25 years without incidents, including the first fully integrated Safeguard system installed at the Gullfaks A platform in 1984. So, though these technologies have been available for a long time, they’ve also been changing to give users additional benefits. ABB’s latest safety system, System 800xA High Integrity, can provide the independence, embedded diversity, I/O diagnostics and SIL3 certification needed to function as a safety instrumented system (SIS).”
Duran presented “Combining Process Control and Safety in System 800xA” this week at the ABB Automation and Power World 2009 in Orlando.
Getting back to basics, Duran explained that combining process control and safety first means maintaining the independent protection layers (IPLs) that were established when safety and control were separated in the first place. “This means establishing defense-in-depth by having each IPL independently protect against the hazard it’s designed to safeguard,” said Duran. “Hazard occurs when a layer fails to respond to the process demand, and so the objective of SIS IPLs must be maintained.”
Because keeping IPLs functionally independent begins with understanding their related safety standards, Duran explained that IEC 61511-1’s essential clause 11.2.4 advises users that their “BPCS [basic process control system] be designed to be independent to the extent that Functional Integrity of the SIS is not compromised,” while clause 9.5.2 on assessment says they should consider, “independence between protection layers, diversity between IPLs, physical separation between IPLs and common cause between IPLs.”
Duran reported that, “In an integrated, but still independent safety system, you have a controller for process automation and a controller for safety, and they’re on the same network, but each one is dedicated and configured to function separately. One supplier can provide both because their independence is maintained by the fact that they act separately. The main question to answer is do they have enough functional diversity to avoid a common-cause failure.”
For example, System 800xA High Integrity combines safety and control boxes, but maintains independent safety measures with its software-based, embedded firewalls, memory partitioning, separate execution contexts and stack management. “The way they execute their programs provides the diversity they need. In the AC 800M HI controller, the smaller SM811 safety module checks on the larger PM865 process module to make sure the right messages are being sent, and if those messages aren’t sent, it will take a safe action,” said Duran. “Also, embedded diversity comes from software diversity in the logic solvers in PM865 and SM811. They have different operating systems, different base software layers and different unpacking procedures.
“Meanwhile, S800 High Integrity I/O modules achieve hardware diversity by having each card have two diverse execution paths based on different hardware technology—MCU [microprocessor control units] and FPGA [field-programmable gate arrays], respectively. Also, MCUs and FPGAs perform the same logic, but they do it in diverse ways. Results are compared before being transferred to the logic solver, and discrepancies between the results from the MCU and the FPGA are detected and appropriate action is taken, for example, by switching to a redundant I/O module if needed.”
In addition, ABB’s simplex System 800xA controller has diverse technology―parallel processing paths, in which the integrity voting between paths compliments the built-in, active diagnostics. Its controller and supervision modules were developed by different teams—in Vasteras and Malmo, Sweden, respectively—and tested by a third team in Oslo, Norway, by personnel with different backgrounds. As a result, simplex System 800xA’s two-channel architecture meets SIL3 requirements for hardware fault detection and reaction.
“To summarize, common tools, such as sequence-of-events or alarm management, reduce time to decision and action, while improving plant operations. They reduce risk more quickly and allow safe start-up after shutdown because root causes can be quickly identified,” concluded Duran. “Similarly, having a common HMI increases operator familiarity with systems, and this reduces training needed. Likewise, seamless integration on all levels reduces complexity and simplifies system design, spare parts and maintenance procedures. In addition, having one engineering environment reduces the engineering required, and this enables simplified application programming, upgrades and modifications to be managed through that one engineering environment. Also, having one supplier means users only need one support organization and lets them have a common life-cycle policy.”