The question of integration with respect to safety instrumented systems (SIS) and basic process control systems (BPCS) continues unabated. Emerson’s Mike Boudreaux alerted me to a great article, The Question of Integration, in the June issue of Control Engineering Asia magazine. It was written by a TÜV FSExpert with one of the automation suppliers.
He frames the source of the debate:
New digital technology now makes it feasible to integrate process control and safety instrumented functions within a common automation infrastructure. While this can provide productivity and asset management benefits, if not done correctly, it can also compromise the safety and security of an industrial operation….
Certainly, a “common platform” approach, using similar hardware and software dedicated for control and safety functions, respectively, can provide the potential for cost savings. However, it is widely acknowledged that using separate, independent, and diverse hardware/software for safety and control is the optimal way to protect against potentially catastrophic common cause and systematic design and application errors. Different vendors offer varied degrees of integration and solutions. The question is how to provide an integrated control and safety solution with advanced functionality and productivity, without compromising safety and security.
He also enumerates the advantages of an integrated approach:
Some of the major potential benefits include: seamless integration; time synchronization; elimination of data mapping duplication; common HMI; compatible configuration tools; minimize spare parts; and single operator and maintenance training requirements.
He cites the issue with a “common platform” approach:
The basis for the concept of “defense in depth (D3)” and “independent protection layers (IPL)” at the heart of all international safety standards (including IEC 61508 and IEC 61511), is every layer of protection, including both control and safety, should be unambiguously independent. Some of the reasons for this basic requirement are to avoid common cause faults, minimize systematic errors, and provide security against unintentional access, sabotage, and cyber attacks.
Mike agrees with both the benefits and concerns, but points to an ARC whitepaper, Business Issues Driving Safety Systems, that distinguishes a “common platform” from an “integrated platform.” The problems cited are relevant with the common architecture approach, where the hardware and software used to deliver functional integrity are shared between the BPCS and the SIS.
With DeltaV SIS, the logic solver components have physical separation, diverse components, and independent SIS logic solver hardware with a different operating system from the DeltaV BPCS. DeltaV SIS safety communications are on a physically separate bus and network from the DeltaV BPCS communications.
The physical separation, diversity, independence, and common cause elimination required by IEC 61511-1 clauses 9.5 and 11.2.4 are inherently addressed by the DeltaV SIS integrated yet separate architecture. The integration of DeltaV and DeltaV SIS is at the operation, engineering, and maintenance layer where it makes sense from the advantages described in the article.
The author sums up the article:
It is safer, renders a lower SIL requirement, and less expensive to implement physically separate and diverse, independent safety and control systems, with smart integration at the information, configuration, asset management, and HMI levels. All the capabilities of field diagnostics, asset management, including partial stroke testing, can be implemented effectively through smart integration.
On this point and in most cases throughout the article, the author and Mike are in complete agreement as demonstrated in a previous post.
Update: Fixed top quote by adding second paragraph inside quote box.
Update 2: I didn’t have my recording equipment when originally posted, so I’ve now added the podcast below.