In a session at this week's ABB Automation and Power World in Orlando, Luis Duran, ABB's development manager for safety instrumented systems for the Americas, led a panel of experts in trying to answer the perennial question, "What is the truth about the separation of safety and process automation?" The panelists included Duran, exida principal partner Bill Goble and two functional safety experts from ABB UK, Neil Wright and Stuart Nunns.
Although the panelists had much to say, the real action didn't start until the audience, which was composed of several senior controls engineers, most with SIS experience, started interacting with the panel.
The definition of an integrated system and that of an interfaced system was established early on. An interfaced system is one in which the operation of the separate SIS shall not be dangerously affected by failure, maintenance or other events within the basic process control system (BPCS). Conversely, an integrated system is one in which the SIS controller(s) sit on the same network as the BPCS. According to ARC, integration of plant control and safety systems provide lower training costs, lower engineering costs, improved asset management and maintenance, and easier synchronization between redundant systems, especially at fail-over.
But do they really?
Goble noted that the concept of independent layers of protection does not have to be compromised by an integrated system and isn't guaranteed by an interfaced system either. "You have to ensure that there is no common-cause failure," he said.
"Most commonly, engineers take a credit in a LOPA (layers of protection analysis) for a single box that does control, alarms, shutdown—with no redundancy," Goble said. "There are many ways to implement independency in protection layers, but if you don't do it at all, you are in trouble. Just having a box for control and a box for safety—even if they are each from different vendors—doesn't guarantee increased safety."
The revised IEC 61508 and 61511 standards and ISA84 require that there be "effective" separation between the BPCS and the SIS functions. But what does "effective" mean? Goble tried to answer that question, saying that effectiveness can be achieved only if the LOPA is done properly, and the layers of protection are truly independent.
Nunns described the legal situation in Europe, the U.K. and the rest of the world, and several of the end users in the audience pointed out that the legal requirements in the U.S. are not as prescriptive or as strict as in the EU, the U.K. or Australia. OSHA does do inspections and determines compliance with IEC, NFPA and ISA safety standards, but the enforcement is considerably looser than anywhere else.
Goble noted that lately OSHA and insurance company inspections have increased in frequency, so the asset owners are being pressured to properly design and maintain their safety systems.
Duran posed some questions: "What is the main concern with integrated safety systems, since many people believe they are not as safe as the interfaced systems?" One of the end users responded that it is a function of education. People have to be educated to the benefits of integrated safety systems, he said, and also need to be educated in how to perform a proper LOPA and SIF analysis with an integrated system.
Another of the end users pointed out the difficulties of deciding between process and safety interlocks, and whether you can use the same sensor, logic solver and final element for both. Most end users in the audience said they believe that you cannot.
It is all about risk management, one of the end users said. "If you don't know how much risk you have, you don't have the ability to design good systems."
"I want all of my inputs and outputs completely separated between the two systems," contended another end user.
Another end user pointed out how quickly safety technology is moving forward. He offered examples such as Profisafe and Foundation Fieldbus Safety protocols for implementing SIS. "It all comes down to how you handle the probabilities of failure," he said. "I can make any system safe, but I may not be able to make it reliable."
And then there is the issue of cyber security. Many functional safety engineers and security specialists are becoming convinced that cyber security, and even physical security, are intrinsic components of any safety analysis. "Most of the time," one end user said, "nobody has completely wrestled with cyber security."
Goble said that originally he thought that integrated systems would be less secure than interfaced systems, but, he said, he appears to have been wrong. "It takes about the same amount of time for our testing engineers to penetrate either an integrated system or an interfaced one, shut the safety system down and spoof the BPCS into thinking everything is okay," Goble said.
He was asked how long it took, on average. "Half an hour to an hour," he replied. "We don't issue press releases about which automation systems do not pass our testing. We haven't issued any releases about systems that have passed. What do you think that means?"
"The real problem," Goble said, "is the vector into the engineering workstations. Once you penetrate them, you are into the control system as well as the safety system." There's no way to proactively protect against all cyber threats, he said. exida uses the ISASecure threat list, but there are certain to be many more threats over the average life of a safety system or a BPCS.
How do you protect an engineering workstation, then? "You have to have clear and firm policies about what you can do, who can use them, what kinds of devices you can connect to them, and you have to enforce those policies."
Several of the end users insisted that integrated systems do better over the long term because of the integrated engineering and diagnostic testing that is built into the system. The integrated systems protect you better, one end user said, from "version trauma," because they have automatic update facilities that update everything, and "you don't have to remember to manually update a logic solver running version 1.2 differently from a new one you just bought that is running version 2.3."
Duran pointed out that the common engineering and operating window can be obtained either way, but is easier to do without custom interface programming in an integrated system.
"You have to design to avoid common-cause failures," summarized one user. "And design your systems for independent layers of protection, and you have to make sure that you test and re-test for failure modes."
