Signed in as:
filler@godaddy.com
Originally issued: June 01, 2024
Author
Shaun Williamson, P.L.(Eng.), CFSE
Director of Engineering
Watchmen Instrumented Safety Experts Ltd.
Many Safety Instrumented Functions (SIFs) installed early in the adoption of IEC 61511 have either reached their mission time or are soon to expire. Companies now face decisions on how to handle this. The primary question is often, "Do we need to replace the SIF hardware, and what is the risk if we don't?" This article delves into why mission time is crucial for achieving high reliability and the consequences of ignoring expired SIF mission time.
Importance of SIF Mission Time
SIF Mission Time is vital when designing a Safety Instrumented Function. Failure to bring SIF elements to an 'as new' condition when their mission time expires can result in the SIF no longer meeting its designed integrity. This can lead to regulatory non-compliance when a specific Safety Integrity Level (SIL) is required for regulatory reasons. It can also mean operating outside the acceptable risk threshold if the SIF is meant to mitigate a specific risk. Thus, mission time is a key factor in achieving the target reliability.
The Relationship Between Mission Time and Useful Life
Mission Time refers to the period between when the SIF (or device) is put into service and when it is replaced or refurbished to "as-new" condition. When selecting a Mission Time for SIF elements as part of reliability modeling, it is essential to consider its relationship to Useful Life.
Useful Life and the Bathtub Curve
The following image of a bathtub curve is used to illustrate the importance of considering useful life. This graph and others like it below show the calculated failure rates over time for typical equipment.
The bathtub curve illustrates what the typical Useful Life curve looks like for most equipment. Hardware components typically have two periods of high failure rates: at the start of their life (infant mortality) and at the wear-out phase. Effective quality control, such as burn-in tests and commissioning checks, can address infant mortality. Wear-out failures can be managed by removing hardware from service before they occur. The relatively flat failure rate in the middle of the curve represents useful life, during which failure rate data used in reliability calculations are valid. SIF hardware must be maintained within this useful life for accurate SIF modeling. Exceeding useful life risks exponential increases in failure rates, entering the wear-out phase. Therefore, mission time must not exceed useful life for IEC 61511 compliance. It's also important to note that useful life can be application-specific, considering process and atmospheric conditions, as vendor literature might be based on ideal conditions, not harsh environments.
Mission Time Considerations
Mission Time is a calculated value to determine when SIF hardware should be restored to 'as new' condition. This value can be reduced to achieve a higher SIL due to a lower probability of failure. Useful Life is the maximum value that can be used for Mission Time.
Probability of Failure Over Time
Although the graphs of PFDavg over time are useful to visualize how the reliability degrades with time, you never know what the actual PFD or potential of failure of a specific SIF element. The first time you know that it’s not working correctly is a failed proof test (and proof testing never catches 100% of failure modes), or when it fails to prevent an incident. If your equipment is past its Mission Time, you have no idea what risk you’re operating at – but it’s certainly higher risk than you planned for!
The image above represents equipment probability of failure over time without considering SIF Proof Testing which can reveal hidden failures before they occur, or an established Mission Time which allows the PFDavg to reset to zero. This graph shows that all equipment will eventually fail, and this probability increases over time. The red line represent the probability of failure on demand, while the dashed black line represents an average probability on demand (PFDavg). A lower PFDavg is represents a higher overall reliability.
Benefit of Regular Proof Testing
In contrast to the i above, the following image shows the benefit of regular proof testing with a significantly lower average Probability of Failure on Demand (PFDavg). The sawtooth pattern shows failure probability dropping at each test. How much it drops is a function of test coverage. Since no test is perfect, there will remain a certain portion of potential failures that remain undetected. Once the test is complete, the failure probability continues to climb until the next test. This pattern continues until the SIF is removed from service, replaced or repaired to 'as new condition' at the end of the mission time. Regular proof testing keeps the PFDavg low. More frequent testing or higher test coverage can further reduce PFDavg, enhancing the SIF reliability.
Reducing Mission Time for Better SIL Performance
The image below highlights the benefits of reduced mission time to lower PFDavg for a higher achieved SIL. The intent is to bring SIF components to 'as new' condition. For non-repairable equipment, this means replacement; for repairable equipment, it requires rebuilding all wearable components. The remaining components must also be in 'as new' condition. If achieved, the PFD resets to zero, starting a new cycle. This approach can reduce proof test requirements or avoid the need for additional redundant hardware.
Consequences of Exceeding Mission Time and Useful Life
If SIF hardware is not restored to 'as new' condition when its mission time expires, its reliability degrades, and it fails to meet the SIL target. This non-compliance with IEC 61511 poses a regulatory risk, especially if the SIF was implemented for regulatory reasons. As time passes and the useful life is exceeded, the risk of failure increases exponentially. Safety Instrumented Functions are typically implemented to prevent severe consequences, such as toxic releases or explosions. Failure to maintain the SIL increases the risk of these events occurring without the intended protection.
Proactive Replacement of SIF Hardware
Replacing SIF hardware before the end of useful life avoids running the SIF in the wear-out phase. Safety Instrumented Functions are not intended to use a run-to-failure philosophy, unlike normal process control loops. Safety functions must work when all other protection layers have failed, making their availability crucial. Therefore, bringing SIF hardware to 'as new' condition at mission time expiry is necessary to ensure reliability.
Examples from Everyday Safety Equipment
Other critical safety equipment, like smoke detectors and fire extinguishers, are replaced before their expiry to ensure functionality. Smoke detectors, for instance, are replaced every 10 years to guarantee reliability. Fire extinguishers are also replaced upon expiry to ensure effectiveness. Similarly, Safety Instrumented Systems, designed to protect people and the public, must adhere to established mission times to provide the intended protection.
Managing Delayed Upgrades
While immediate rebuild or replacement is ideal, practical constraints such as budget and resource availability may delay this process. In such cases, prioritizing which SIFs to address first based on risk is essential. SIF modeling can be used to help evaluate the status of all existing SIFs, prioritizing upgrades based on the highest risk. This approach helps in staging upgrades and managing budgets effectively.
For SIF hardware that is not prioritized for immediate upgrade, several interim measures can be taken to maximize reliability and mitigate risk:
- Increasing Proof Test Frequency: Implement options for online testing between regular maintenance turnarounds to detect potential failures earlier.
- Updating Proof Test Procedures: Enhance proof test procedures to include more comprehensive testing, thereby increasing proof test coverage.
- Partial Stroke Testing and Diagnostics: Implement additional partial stroke testing or other diagnostic methods to monitor equipment performance.
- Alternative Protection Layers: Consider alternate non-SIL protection layers and other options to reduce the SIL load on existing SIFs.
These actions aim to maintain reliability as close to the needed SIL as possible until full upgrades can be accomplished. Utilizing SIL modeling can also help communicate the impact of delaying replacements, providing clarity to management on how delays affect reliability.
Summary
Adhering to mission time requirements is essential for maintaining the reliability and safety of Safety Instrumented Functions. Failing to address these requirements can lead to regulatory non-compliance and increased risks, undermining the safety measures intended to protect people and processes. A staged approach based on a risk assessment is a good way to prioritize the work, and alternate measures can be tested using SIF modeling to maximize reliability while in transition.
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.
IEC 61511 Limitations on Instrumented Safety Layers
Another consideration when assigning protection layers is that IEC 61511 has recommended limiting how many credits are applied for instrumented systems using a combination of BPCS and SIS protection layers to no more than an RRF of 10,000 (5 orders of magnitude risk reduction). The intent is to avoid an over reliance upon instrumented safety for very high risk scenarios. In these cases, the preference is to consider redesign rather than trying to instrument your way out of an inherently dangerous design. Refer to IEC 61511-1 Section 9.2.5 for more details.
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