The Question of Integration

While there are undoubted benefits from integrating control and safety on the same platform, this approach can also create some adverse consequences, cautions Robin McCrea-Steele.

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. Cyber security and sabotage vulnerability further accentuate the need for securing the safety instrumented system (SIS). 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 utilizing 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.

Drawing the line

There is undoubtedly a very good case to be made for tight integration of control and safety from an operations and productivity point of view. 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.

However, merging control and safety too far could outweigh the advantages. What are the side effects of using a common platform? How is the integrity of each independent protection layer guaranteed? Does a DCS-embedded safety logic solver pose concerns of side effects and hidden costs? Potential benefits can at times become a liability if they are at the expense of safety and security, and increasing lifecycle costs. Regardless of the technology implemented, maintaining the basic principle of independent layers of protection is the responsibility of the operating company. Providing functionality and productivity, without compromising safety and security is the responsibility of the end user. So where do plant operators draw the line?

The answer may lie in a recent survey of chemical, oil, and gas process plant operating companies conducted by Invensys, which revealed that 78 percent of the over 200 respondents adhered to strict separation of safety and control for safety protection. Additionally, 74 percent indicated that independent protection layers (IPL) were critical and 66 percent gave common cause as a major concern.

Results of this survey, which included 23 of the top 25 petroleum companies, combined with in-depth discussions with a larger population of process industry end-users around the world, clearly indicate that the majority of operating companies draw the line at maintaining independent layers of protection and diversity between their safety instrumented and process control systems.

Setting standards

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. Merging two layers of protection is a safety incident waiting to happen. Process safety is based on D3 and the separation of the control and safety systems operating independently. Each IPL is designed to independently protect against the hazard for which they are designed to safeguard. One of the main duties of the DCS is to reduce the number of demands on the SIS. A demand on the SIS implies that the control system has failed to keep the process within the safety range and the process is now relying on the SIS to protect against the hazard.

If the BPCS (basic process control system) and SIS are embedded in a way that they might both fail simultaneously due to common cause or systematic failures, the operation is effectively in “continuous mode”, with the DCS/SIS combination functioning as a critical control system. In this case, the whole objective of the SIS layer of protection is lost. IEC 61511-1 clause 11.2.4 states that the BPCS shall be designed to be separate and independent to the extent that the functional integrity of the SIS is not compromised. Several automation vendors seem to have selectively interpreted this to indicate that the standard does not require physical separation or diversity.

Another section of the same standard IEC 61511-1, clause 9.5, addresses the requirements for preventing common cause, common mode, and dependent failures. It states that the assessment shall consider (a) independency between protection layers, (b) diversity between protection layers, (c) physical separation between protection layers, and (d) common cause failures between protection layers and BPCS.

As for TÜV, although a TÜV certificate for a certain SIL capability limit for the SIS logic solver validates the use of a functionally separate, but common platform DCS-SIS, great caution must be taken in the overall implementation of the plant risk reduction requirements.

TÜV certification does nothing to avoid the common cause failures of the SIS and DCS, which are based on the same hardware/software platform. Neither does it say anything about the systematic errors inherent in using the same platform for SIS and DCS. The certification validates the “functional separation” and non-interference of control system failures on the SIS, firewalls, and password-based access protection.

“Integrated functionally separate safety and control” is a marketing terminology that requires an in depth assessment of its implications. A safety logic solver that is embedded within the same platform as the control system, using separate modules, does not meet the requirements of an independent layer of protection.

Losing credit

In the initial stages of the SIS design, hazards are identified and safety integrity requirements are assigned to each layer of protection. Layers of protection analysis (LOPA) is one of the most popular methodologies used in the assignment of the SIL requirements for each safety-instrumented function (SIF). LOPA takes credit for all available independent protection layers (IPL) that qualify per the IEC 61511 requirements. During the LOPA evaluation, the DCS is considered many times as an IPL and a credit up to the maximum allowable by the standards taken (10-1 or RRF=10).

Taking a risk reduction factor (RRF) of 10 for the DCS as an IPL has considerable weight in the final SIL requirement for the SIF. A control system that qualifies as an IPL will substantially reduce the demand rate on the SIS. Actually, the SIL of the SIF will be one whole order of magnitude higher if the DCS does not qualify as an IPL. During the detail design phase of a SIS, it is very important to verify the assumptions made during the SIL assignment phase. For example, when a LOPA study determines the need for a SIL 2 safety instrumented function, based on credit taken for all IPLs’ including a RRF of 10 for the control system, the verification phase should verify that all assumptions are still valid.

If, however, the SIS logic solver is embedded in the same hardware/software platform as the DCS, then the control system will no longer qualify as an IPL and the RRF credit taken will need to be nullified. Consequently, the resulting SIF requirement will be increased by one order of magnitude to a SIL 3. A plant with requirements for SIL 1 and SIL 2 safety instrumented functions will mostly have SIL 2 and SIL 3 requirements. This means incremental costs in field redundancy, installation, maintenance, and testing. Unfortunately, if a SIL 3 requirement was determined during the LOPA with credit for the DCS as an IPL, using a SIS logic solver embedded in the DCS will render a requirement for a SIL 4, which means going back to the drawing board.

Solution: smart integration

The supposed advantages of seamless integration, elimination of data mapping and lower hardware and training costs for using a common embedded platform come at the expense of safety and security. Actually, lifecycle costs are higher, both economically and in safety of personnel, the environment, and the community.

An additional concern is the long-term management of an embedded SIS, where day-to-day activities become more prescriptive and less flexible than with independent and diverse systems. Management of change validations will encompass much larger and complicated processes. This approach has too many downsides.

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.

Robin McCrea-Steele is TÜV FSExpert, Invensys-Premier Safety Consulting (www.ips.invensys.com).