Integrating control and safety — where to draw the line

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. This makes it critically important for process industry users to understand where to draw the line. 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 arguably provide some cost savings. However, it is widely acknowledged that utilising separate, independent and diverse hardware and 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. So where do users draw the line?

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

In the same survey, only 8% indicated that ‘diversity’ was not a concern, while 89% of users said that their ability to choose best in class for both safety and control was important.
The results of this survey, combined with in-depth discussions with a much larger population of process industry end users around the world, clearly indicate that the majority of end users draw the line at maintaining independent layers of protection and diversity between their safety instrumented and process control systems.

The importance of independent layers of protection

The whole basis for the concept of ‘defence in depth (D3)’ and ‘independent protection layers (IPL)’ at the heart of all the international safety standards (including IEC 61508 and IEC 61511) is that every layer of protection, including both control and safety, should be completely independent. Some of the reasons for this basic requirement are to avoid common cause faults, minimise systematic errors and provide security against unintentional access, sabotage and cyber-attacks. Merging two layers of protection is a safety incident waiting to happen.

A recent University of California, Berkeley civil engineering study reported that the US Army Engineers Corp in charge of building and supervising hurricane levees started to change their culture from safety to efficiency in the mid 1970s. Hurricane Katrina uncovered the systematic engineering design problems 30 years later. In the processing industry, the ramifications of the current temptation to ‘cross the line’ by merging the IPLs may be only revealed by a major chemical disaster in the future.

Those process industry users who currently find themselves at a crucial fork in the road should thoroughly understand the potential ramifications of compromising safety and security by merging independent layers of protection. Keeping these layers independent is clearly the path of zero compromise; the path that will reduce risk to a level as low as reasonably practicable (ALARP).

Interpreting the safety standards

Performance-based standards, such as IEC 61508, IEC 61511 and ANSI ISA-S84.00.01-2004, are intended to open the doors to creative engineering implementation. Rather than dictating a specific configuration, these standards set performance criteria goals. The problem arises when the performance criteria are taken selectively or out of context.

Some control systems vendors seem to have been stung by the ‘creativity’ bug. However, rather than having process safety being driven by technology, we should be using new digital technology to integrate at the information, predictive maintenance and HMI level.

IEC 61511-1 clause 11.2.4 states that the BPCS (basic process control system) 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 paragraph to mean that the standard does not require physical separation or diversity.

However, another section of the same standard IEC 61511-1, clause 9.5, addresses the requirements for preventing common cause, common mode and dependent failures. Clause 9.5.2 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.

The question is, how do you conform to clause 11.2.4 without physical and diverse separation? IEC 61508 and IEC 61511 acknowledge that it is virtually impossible to assess the failure rate of software and furthermore cannot quantify a target criteria goal for systematic failures.

Attempting to overcome the problem of separation and diversity with increased reliability and self diagnostics is definitely not the right approach. Focusing only on the PFD reduces the criteria to reliability engineering, which cannot accomplish safety on its own. Systematic errors, common cause errors and software errors form an integral component of the overall safety assessment.

ISA TR84.00.04 part 1 is designed to be a guideline for the interpretation and implementation of IEC 61511. This technical report has many good recommendations, including Annex F section F.4 where it addresses physically separate and diverse SISs as a way to virtually eliminate common mode failures. Although no one really challenges the advantage of physical separation and diversity, the issue, for some, seems to have come down to “how far can I push the interpretation of the standard?” Designing your systems down to selective paragraphs while ignoring the intent of the standards is not conducive to providing a safe working environment through good engineering practices. The difference between ‘risk-based’ and ‘risk-informed’ decision making is that the numbers should only be used as one input to the decision making, rather than an absolute measure. ‘Defence in depth’ should be a cornerstone of any safety system design.

As a user with responsibility over process safety, one should not get blinded by new marketing terminology such as ‘integrated functionally separate safety and control’. Physical separation and diversity are the only ways to guarantee complete independence of layers of protection. Co-mingling control and safety only exacerbates the problem — and the risk. Compromising safety for design flexibility or a lower price is unconscionable.

Other prescriptive application standards on separation

In addition to the performance-based standards discussed above, a number of application-specific prescriptive standards will also apply. For example:

• NFPA 85: Boiler and Combustion Systems Hazards Code 2001, clause 1.9.3.2.3 Requirements for Independence. “The logic system performing the safety function for burner management shall not be combined with any other logic.”
• API RP 14C — Recommended Practice for Analysis, Design, Installation, and Testing of Basic Surface Systems for Offshore Production Platforms, Paragraph 3.3 and 3.4. “Two levels of protection should be independent of and in addition to the control devices used in normal operation.”
• API RP 554 (1995) — Process Instrumentation and Control. “The shutdown and control functions should be in separate and independent hardware.”
• IEEE 7-4.3.2 (1993) — Standard for Digital Computers in Safety Systems of Nuclear Power Generating Stations. “Isolation needs to be considered in order to prevent fault propagation between safety channels and from a non-safety computer.”
• IEEE 384 (1992) — Standard Criteria for Independence of Class 1E Equipment. “Class 1E circuits shall be physically separated from the safety system equipment to the degree necessary to retain the safety systems’ capability to accomplish their safety functions in the event of a failure of non-safety equipment.”

If process safety is your concern, physical and diverse separation or isolation between the SIS and the BPCS is good engineering practice, conducive to a safe working environment.

Effect of integration on the SIL requirement

The level of control-safety integration may affect your SIL requirement. For example, if you used LOPA or another SIL assignment method that incorporates credits for external layers of protection, and credit was taken for the control system’s integrity and reduction of demands on the SIS, you may need to reassess the study.

An integrated control-safety system which has crossed the line of separation of independent layers, by either embedding a same technology SIS logic solver in the control system or using the same operating system, may have systematic design and common cause errors that invalidate any credit taken for the independence of the BPCS layer. The bottom line is that the safety integrity of the safety instrumented function may have been compromised.

If the HAZOP/SIL assignment process determined that a certain safety function required a SIL2, and now no credit can be taken for the BPCS as an IPL, then the new assessment will most likely determine an increased requirement (ie, a SIL3) for that safety function.

Any cost savings of the integrated control-safety system would, in this case, be wiped out. As a matter of fact, the costs would increase if additional field redundancy and proof testing is required to meet the new target SIL.

Cyber-security concerns

We are all well aware of how hackers, viruses, trojans and worms can penetrate firewalls, break password securities and in general create havoc in a computer network system.

The vulnerability of a safety system ‘integrated’ with a control system that in turn is connected to a site LAN or corporate WAN is increased exponentially.

Remote process monitoring as well as remote diagnostics, maintenance and asset management through web connectivity have become an efficient tool. However, firewalls and passwords are only another challenge to hackers. In time and with focus they are routinely broken. The safety system, as a last line of defence, needs to be secured.

Insiders, disgruntled employees, web hackers and terrorists are all real threats to the process industry. Media Corp/News Asia reported on 4 October 2005 that 500 computer hackers in North Korea were given a five-year military university training program with the objective of penetrating computer systems in South Korea, USA and Japan.

Even multiple firewalls and intrusion detector systems are not enough. All systems are vulnerable. There is no such thing as absolute security, only layers of protection.

The question

How do we provide an integrated solution with advanced functionality and productivity without compromising safety and security?

Most plant operators in the chemical, oil and gas industry (as shown by the survey conducted by Invensys, referenced earlier) believe that the answer is to maintain strict physical separation and diversity between the process control and safety instrumented functions, while facilitating secure integration at the information, diagnostics, configuration and HMI levels. This is where the line should be drawn. Process industry users should demand this level of integration from their automation vendors.

Solutions that advocate functional integration with the SIS ‘embedded’ in the control system and based on the same technology are prone to systematic, common-cause and cyber-security issues. It is not enough to dedicate separate mission-specific modified DCS modules for the SIS logic solver within the control system.

Furthermore, any level of integration that merges layers of protection will have a detrimental effect on the target SIL of the safety instrumented functions.

Users are not about to compromise safety and security of their plant. The bottom line is that the independent layers of protection need to be just that. Independent.

*Robin McCrea-Steele is a senior safety consultant and director of PCS business development at Invensys-Premier Consulting Services. He is a certified TÜV Functional Safety Expert and approved instructor for the TÜV ASI Rheinland Functional Safety Program, an AIChE Member, ISA Senior Member and SP84 committee member working on the safety fieldbus task force. Robin has specialised in process safety consulting and risk assessments, has presented multiple technical papers at industry symposiums and has been published in various safety-related magazines, such as InTech, Control Solutions International, Hydrocarbon Engineering, and Control Magazine.

Invensys Process Systems (Australia) Pty Ltd
www.ips.invensys.com