Originally issued: September 14, 2021
Author
Shaun Williamson, P.L.(Eng.), CFSE
Director of Engineering
Watchmen Instrumented Safety Experts Ltd.
Abstract
The Basic Process Control System (BPCS) is one of the most relied upon and credited safeguards in a Process Hazard Assessment (PHA) and Layer of Protection Analysis (LOPA) study. How much credit can reasonably be applied for this protection layer is a commonly debated topic. With the updates made to international standard IEC 61511 in 2016, the requirements clearly limit how much reliance can be placed on the BPCS category of safeguards including the level of independence needed. Part 1 of this series will discuss the BPCS independence requirements and Part 2 will review practical solutions to maximize independence and achieve IEC 61511 compliance. There will also be some discussion on how to handle reviews of existing facilities built under less stringent requirements.
History of the Dual BPCS Credits Debate
The level of independence required for dual BPCS credits has been a subject of debate for many years in the industry. The IEC 61511 international standard specifies the requirement for this topic, however the details on how to comply have been an area left with different interpretations.
IEC 61511 limits the reliance upon the BPCS to no more than two orders of magnitude when they are sufficiently independent from each other and the initiating event, unless designed as an SIS.
Early versions of IEC 61511 were considered by some to be vague when it comes to independence requirements and industry publications were relied upon to fill in some of the gaps. The 2001 CCPS book Layer of Protection Analysis – Simplified Process Risk Assessment described a process making use of dual BPCS credits within the same logic solver (Approach B), but with limited guidance under what circumstances this should be permitted.
As the IEC 61511 standard was being updated, CCPS released an updated publication in 2015 titled Guidelines for Initiating Events and Independent Protection Layers in LOPA. This update provided additional guidance necessary when taking dual BPCS credits from the same logic solver following Approach B. The updates highlight the necessity of performing engineering analysis and lifecycle management techniques to ensure the BPCS is properly designed and managed to support an estimated failure rate of ≤0.01/yr (reliability calculations, proof testing etc.). These activities are not unlike those required to manage an SIS. Based on current industry data not available at the time of the 2001 CCPS publication release, the new CCPS book points out that when properly implemented, it is unlikely that typical BPCS hardware (PLC, DCS) would meet the reliability requirements. Therefore, this approach would be appropriate primarily for use with SIL certified logic solvers and therefore inappropriate for the vast majority of BPCS applications. This CCPS publication also cautions readers that this process may be superseded with coming updates to IEC 61511, which occurred in the 2016 release of that standard.
The path for dual BPCS credit within a common logic solver described by these two CCPS publications has since been superseded with the release of the 2016 version of IEC 61511 which provided more clarity on BPCS requirements for independence. The IEC 61511 standard allows for up to two BPCS protection layers to be credited either as safeguards or as part of the initiating event only when fully independent (sensor, logic solver and final element). The details of these independence requirements will be described in more detail below.
Follow the Industry Publication or the Industry Standard?
The 2001 CCPS publication is now over 20 years old and was a key publication providing guidance on important concepts that led to international adoption of the LOPA process. The 2015 CCPS LOPA publication builds off the great content provided within the 2001 LOPA publication supporting users in becoming more proficient and improving the quality of analysis being performed. These and other books provide guidance based on requirements listed in industry standards at the time of their publication. Our industry knowledge continues to evolve and with this knowledge, so do our standards. This needs to be considered when relying upon publications that remain static.
It is also important to keep in mind that these industry publications are guidance documents only and their intent is to support implementation of industry standards or provide guidance where no standards exist. IEC 61511 is an international standard adopted in many jurisdictions around the globe. It has been labelled as Recognized and Generally Accepted Good Practice (RAGAGEP) with the U.S. and adopted by CSA within Canada as a National Standard of Canada. This standard will almost certainly be used as the bar for due diligence in any legal proceeding in North America and other jurisdictions in the event of an accident.
IEC 61511 Requirements for multiple BPCS credits
There are two ways to recognize two BPCS layers:
a) Two independent safeguards when the failure cause is not associated with the BPCS; or
b) One BPCS has failed as part of the initiating event and one BPCS safeguard is credited as a layer of protection.
For either case above to apply, both BPCS functions must be fully independent as per section 9.3.4 of IEC 61511. To ensure this independence requirement is very clear, the 2016 version of IEC 61511 included two figures in Part 2, section A.9.3.4 and A.9.3.5 (see below). These figures show a requirement for full independence of the sensing elements, logic solvers and final elements.
IEC 61511-1 Section 9.3.5 notes that “A hot backup controller is not considered to be independent of the primary controller because it is subject to common cause failures.” IEC 61511 goes on to explain the reason that hot backup controller is not considered to be independent of the primary controller is that it contains common components that are subject to common cause failures. These components include the backplane, firmware, diagnostics, transfer mechanisms and undetected dangerous failures. The same would be true if one were to try to take credit for multiple protection layers out of the same BPCS. This leaves the system susceptible to failure of multiple protection layers from a single cause.
Summary
It could be said that the BPCS independence requirements in IEC 61511 have not necessarily changed. What is different is that the intent of the independence requirements was not necessarily clear in the previous versions of the standard. 3rd party guidance documents were published detailing an approach that could be considered less restrictive than the current requirements. With more clear direction on the intent of BPCS independence requirements with IEC 61511, there should be less confusion what is, and is not compliant. That being said, what do we do with existing facilities built under less stringent requirements or at a time where the requirements were less clear? Since IEC 61511 does not allow for grandfathering, theoretically this would mean that compliance should be pursued at the earliest opportunity. While this standard likely would be used as a test for due diligence, it seems reasonable that some alternatives providing the needed risk reduction may be considered when the costs of a full upgrade are grossly disproportionate to the benefits. As with other risk mitigation efforts you can significantly reduce the risks with little effort when compared against doing nothing. Advancing towards full compliance in the future can be planned and budgeted for while the low hanging fruit can be picked in the short term.
An alternate approach to full compliance would require detailed engineering analysis and justification prior to formalizing the decision. This likely would require owners take all reasonable measures to mitigate risk and move towards compliance when reasonably practical. It is also reasonable to assume full compliance should be pursued for all new installations and modifications to existing facilities. This decision is one that deserves some consideration and should be documented properly for proof of due diligence. A decision not to upgrade to the latest requirements without any documented may leave the owner and responsible decision makers at risk of legal liability in the event of an accident. Since the level of risk tolerance is determined by the owner, ultimately the process that will be followed is chosen by the owner. The risk assessment team is tasked with participating and supporting the path that was selected. It is recommended that this discussion take place prior to any PHA efforts.
Contact an experienced and competent risk management professional with a background in automation to consult on the options regarding how best to approach these types of situations including alternative approaches that may be considered.
For more discussion on practical guidance on implementation of these BPCS independence requirements, look out for Part 2 in this BPCS Independence Requirements series (PHA-BLG-103).
References:
IEC 61511-1:16: Functional safety - Safety instrumented systems for the Process industry sector
CCPS Layer of Protection Analysis - Simplified Process Risk Assessment published in 2001
CCPS Guidelines for Initiating Events and Independent Protection Layers in LOPA published in 2015
Originally issued: January 19, 2022
Author
Shaun Williamson, P.L.(Eng.), CFSE
Director of Engineering
Watchmen Instrumented Safety Experts Ltd.
Abstract
Part 2 of this article is intended to build off the BPCS independence requirements described in Part 1 by discussing some best practices and practical design options for compliance with the IEC 61511 BPCS independence requirements. In this article, we will discuss some of the options available including benefits and detractors of each. Historically, segregation of control from safety systems has been considered a costly endeavor that has been shunned by smaller operating companies or on smaller scale facilities. With updates to technology, the cost of segregation is becoming more reasonable and there are many ways of achieving these standards requirements.
Best Practices for Allowing Multiple BPCS Credits in LOPA
Attempting to apply dual credit for the BPCS category of protection layers in LOPA requires and understanding of the requirements. IEC 61511-2 Section 9.3.4 and 9.3.5 recommend that analysis be performed to ensure common cause and common mode failures are minimized. When practical, it is recommended that the independent BPCS platforms used be diverse to the greatest level practical including hardware, software, engineering tools and programming language. The level of diversity considered appropriate may depend on the level of risk associated with the application with greater levels of diversity being applied to high-risk applications.
System Independence
Establishing a strong corporate standard for SIS and BPCS implementation at the start of the project will prevent costly changes late in the project during the HAZOP and LOPA assessments which in some cases may occur after the controls system has been purchased. A common practice that can be taken is to implement control and safety interlocks using independent systems. Implementing safety interlocks in a SIL certified logic solver will provide a high degree of flexibility for handling high risk scenarios as the risk analysis progresses during the project. Safety certified systems have come down in price and are becoming more affordable and practical to work with. In some cases, the LOPA team may identify a benefit to implementing an additional independent BPCS system to avoid the need for a SIF or to reduce the SIL target. This decision may be one best left to the LOPA team rather than at the start of the project.
A design standard that requires two independent systems for control and shutdown is now quite common for larger scale and higher risk projects, however this has traditionally been less common on smaller, lower risk facilities. Many smaller applications such as wellsites, compressor stations and oil batteries have traditionally used either a common RTU or PLC for all control and shutdown functionality. The standards however apply the same for these types of facilities. Therefore, they would also benefit from the same standardized approach of separating control from shutdown using two independent systems. As SIS applications have now been around for many years, cost effective SIS systems are becoming more readily available. In some cases, a small SIS can be implemented for similar pricing as a general use PLC. SIL certified relays making use of a hard-wired approach may also be applied when there are only a couple of SIF applications identified. Local pneumatic and hydraulic protection loops can also be considered when necessary assuming reliability requirements can be met. For these local electric or mechanical loops, the sensing and final elements may be monitored by the BPCS, activating an alarm in the event of a local shutdown.
BPCS and SIS Architecture Options
There are a few different options available for implementing BPCS and SIS systems with the line between how independent they are becoming more blurred as technology advances. Control system vendors are developing innovative ways to establish independence using a common platform while attempting to minimize common cause and common mode failures. Greater care is required when implementing BPCS and SIS systems that are more closely integrated with the standards calling for quantitative analysis when common elements are used. The BPCS/SIS architecture types in use include:
- Air Gapped
- Interfaced
- Integrated
- Common
The Air-Gapped system has the greatest level of independence and was the most common method of implementation in the early days of SIS. This system is physically separate and therefore has very little possibility of common cause or common mode failures. This often requires different suppliers and therefore can be a more costly option.
The Interfaced System is also physically separated and allows for communication between the BPCS and SIS systems. In this system a communications failure in one system does not cause the other system to fail. This system is still considered to have a high level of independence between systems. This option also typically makes use of different suppliers.
The Integrated system is commonly provided by the same supplier and both systems make use of the same network while retaining separate logic solvers and I/O. There is often increased commonality of components including in some cases engineering workstations and tools and therefore an increased opportunity for common cause and common mode failures. This system is typically simpler and therefore cheaper to implement due to the commonality of the platform.
The Common System combines the BPCS and SIS into a common logic solver while retaining separate I/O and in some cases separate safety communications. To ensure sufficient independence, it may also be necessary to segregate the BPCS and SIS I/O into separate I/O networks and separate racks. This approach should only be considered if certified as compliant with the latest version of the IEC 61508 standards. This system has the lowest level of independence and the greatest opportunity for common cause, common mode and systematic failures.
No matter the system that is selected, all SIS applications must be certified to IEC 61508. Higher risk applications may wish to consider selecting a system with a higher level of independence. Additionally, the user is responsible to ensure to implemented system meet the requirements of IEC 61511.
What to do When Independence is Not Sufficient
While strict adherence to the most rigorous standards should be the ultimate goal, getting there can be a tough sell due to the potential price tag. Many industrial facilities were built at a time when these standards either did not exist or were considered a nice to have. The reality is that many facilities are still being built that still do not comply with the latest independence requirements for varying reasons. The following are some ideas on how to move towards compliance in a staged approach.
Rome wasn’t built in a day, but brick by brick it was completed. With future full compliance in mind, we can move toward that reality using a staged approach. Intermediary measure may include implementing diverse technologies and wiring practices, and independent I/O cards which in many cases can be completed for a reasonable cost. While this does not meet the intent of a fully compliant approach, it shows the issue of BPCS independence is taken seriously and shows some form of due diligence if a hazardous scenario arises.
In situations where strict adherence to the latest version of these standards is considered cost prohibitive, consider taking some short term proactive and affordable measures focused on a select few safety critical I/O. Consult your PHA and other documentation to determine which I/O is safety critical and prioritize upgrades based on the largest risk gaps. The highest risk functions can be re-wired into a fully independent logic solver, wired to remote I/O cards, make use of relays or loop splitters, among other solutions. Having your highest criticality safety functions managed under IEC 61511 can be an effective and affordable first step with lower criticality functions following suit at a later time. When considering migration plans to address obsolescence issues, this offers a great opportunity to move towards full compliance.
Benefits of Standards Compliance
There are many benefits that come with the investment of complying with the IEC 61511 standard (including the rigorous BPCS independence requirements) including:
a) Safer work environment for staff, environmental and asset protection, reduced risk of regulatory penalties or damaged reputation
b) Management of liability risk with standards compliance and risk mitigation
c) The analysis required to increase the reliability of SIS hardware reveals and corrects not only dangerous failures, but also safe failures leading to increased availability and plant up-time.
d) Flexibility when taking a system offline for maintenance (i.e. Fire & Gas System can still provide protection when the BPCS is down for maintenance).
e) Enhanced access controls and cyber security measures.
f) Simplify the analysis required on the BPCS and SIS that should occur if combined.
With some forethought and good engineering practices adopted at the start of the project, these requirements can be implemented at a reasonable cost and can come with many benefits. For brownfield applications, this has the potential to be a costly effort depending on the age of the existing system and standards they were implemented under. For this reason, it is highly recommended to engage a highly competent specialist prior to starting any updates.
References:
IEC 61511: Functional safety - Safety instrumented systems for the Process industry sector
IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems
