by Lauren J. Caldwell, PE(SC), CFSP, CMSE When performing risk assessments on process equipment, are you reviewing machinery as well? Bag dump stations, conveyors, and various vendor-packaged machinery provided with E-Stops are sometimes evaluated in a Process Hazards Analysis (PHA), but they tend to be reviewed at a high level. Because they do not have process flow, they may not be viewed as having traditional process safety hazards. Machines still have hazards, and there is a need for a deeper dive with respect to machinery-related hazards. Did you know that machinery E-Stops fall under OSHA’s General Duty Clause? In an interpretation letter from April 28, 1999, OSHA noted, “If a serious injury could result from an improperly-designed or installed emergency stop device, a citation under the OSH Act’s General Duty Clause could be issued.” This brings the question – how should machinery without process flow be addressed? There are separate standards available for evaluating machinery hazards and designing their safeguards appropriately: ISO 12100, IEC 62061, and ISO 13849. Fortunately, functional safety of machinery follows a similar workflow to the process safety lifecycle. Similar to identifying risk gaps in a Process Hazards Analysis (PHA), we can identify risk gaps for machinery. We can define risk targets, determine how to best close the risk gaps, specify a design, and verify the risk has been adequately addressed. This paper will present a practical example application to demonstrate machinery safety risk reduction in accordance with machinery safety standards for machinery common to chemical process plants. Click here to view the complete whitepaper

by Richard E. Hanner & Tab Vestal ​ The history of high consequence incidents in industry reveals that most accidents were the result of systematic failures, not hardware failures. However, a higher degree of focus in engineering is often on the quantifiable failures of hardware. Process Safety risk gaps are often closed or reduced by several types of Independent Protective Layers (IPLs). Two common types are Safety Instrumented Functions (SIFs) and Basic Process Control System (BPCS) functions. The SIFs typically reside within a SIL-rated programmable logic controller, and their achieved quantitative performance is calculated based on random hardware failures of the SIF hardware components. Conversely, BPCS protective layers are assigned generic industry-accepted probability of failure credits. The BPCS generic industry-accepted probabilities of failure are conservatively assigned and consider unquantifiable human-induced systematic failures. In either case, the likelihood of systematic failures can be reduced by recognizing design, specification, maintenance, and operations activities that are potential sources, and applying measures to prevent or reduce them. By reducing systematic failures, you reduce the risk in the industrial process and increase confidence in meeting the intended integrity requirements. This technical paper will discuss the common sources of systematic failures and preventative or mitigative measures to prevent their occurrence. Topics Included in Whitepaper: Systematic failure , random hardware failure , Independent Protective Layer, IPL, SIF, SIS, BPCS , common cause, Human Factor Analysis , SIL Verification Click here to view the complete whitepaper

The Process Industry has an established practice of crediting IPLs (Independent Protection Layers) to meet risk reduction targets as part of LOPA (Layer of Protection Analysis) studies. Often the risk targets are calculated to be on the order of 1E-4 per year or lower. Achieving the risk target on paper is one thing, but what is missing from the LOPA calculation is a statement of the confidence in the result. LOPA is an order-of-magnitude method, however, this only reflects the tolerance of error, not the tolerance of uncertainty. It is often stated that LOPA uses generic credits that are conservative, thereby implying the LOPA result should be conservative. By itself this statement is dubious because the generic data used in LOPA did not originate from the facility for which the statistical inferences are being made (which for frequentist-based statistics makes the inference invalid). Worse, when conservative credits are multiplied together to produce a rare-event number, does the conservative property emerge from the combination? There is no way to answer this question without performing IPL Validation (i.e., ensuring the IPL will function when needed). However, IPL Validation and related Safety Life-cycle methods (e.g. functional safety assessments and cyber-security audits related to barrier integrity) are purely qualitative and have no apparent relation to the quantitative risk target. There is a need therefore, to bridge the qualitative results of IPL validation with the quantitative result of the associated LOPA calculation, as a way to establish a site-specific confidence level in the risk target we are trying to achieve. This is where Bayes’ Theorem comes in. Bayes’ Theorem is an epistemological statement of knowledge, versus a statement of proportions and relative frequencies. It is therefore a method that can bridge qualitative knowledge with the rare-event numbers that are intended to represent that knowledge. Bayes’ Theorem is sorely missing from the toolbox of Process Safety practitioners. This paper will introduce Bayes’ Theorem to the reader and discuss the reasons and applications for using Bayes in Process Safety related to IPLs and LOPA. While intended to be introductory (to not discourage potential users), this paper will describe simple Excel based Bayesian calculations that the practitioner can begin to use immediately to address issues such as uncertainty, establishing confidence intervals, properly evaluating LOPA gaps, and incorporating site specific data, all related to IPLs and barriers used to meet LOPA targets. Click here to view the complete whitepaper

by Keith Brumbaugh Is our industry stuck in the past? The current industry trend is to only look at random hardware failures in safety integrity level (SIL) probability of failure on demand (PFD) ca lculations. No one would appear to be updating assumptions as operating experience is gained. Hardware failure rates are generally fixed in time, assumed to be average point values (rather than distributions), and either generic in nature or specific to a certain set of hardware and/or conditions which the vendors determine by suitable tests or failure mode analysis. But are random hardware failures the only thing that cause a safety instrumented function (SIF) to fail? What if our assumptions are wrong? What if our installations do not match vendor assumptions? What else might we be missing? How are we addressing systematic failures? One obvious problem with incorporating systematic failures is their non-random nature. Many functional safety practitioners claim that systematic errors are addressed (i.e., minimized or eliminated) by following all the pro cedures in the ISA/IEC 61511 standard. Y et even if the standard were strictly adhered to, could anyone realistically claim a 0% chance of a SIF failing due to a human factor? Some will say that systematic errors cannot be predicted, much less modeled. But is that true? This paper will examine factors which tend to be ignored when performing hardware-based reliability calculations. Traditional PFD calculations are merely a starting point. This paper will examine how to incorporate systematic errors into a SIF’s real-world model. It will cover how to use Bayes theorem to capture data after a SIF has been installed — either through operating experience or industry incidents — and update the function’s predicted performance. This methodology can also be used to justify prior use of existing and non-certified equipment. Click here to view the complete whitepaper

by Keith A. Brumbaugh, PE During a Safety Instrumented System (SIS) implementation project at a plant site new to the ANSI/ ISA 84 process safety lifecycle world, we discovered the importance of utilizing graphic diagrams in the development of SIS ‐related documentation to support the on‐site team meetings and document decisions. In a room full of plant operators and engineers accustomed to working “hands on” in the field, it was often far easier to keep the team on track when they were provided with a drawing to discuss, as opposed to having the team look at a screen full of text. The graphic diagrams also provided the design team with equal benefits as we received greater focused team member feedback, allowing for more efficient and thorough updates to documentation. This method of capturing team member input also enabled concise integration of the team input into various SIS‐related documents during and after the meetings. Examples of these graphic diagrams included the following: ​​ - A logic solver block diagram ‐ used to quickly identify which Logic Solver Safety PLCs, Independent Protection Layers (IPLs), Logic Narratives, and Equipment were related to each other. - Logic flow diagrams for heaters and boilers ‐ used to visualize the order in which light off permissive would be met, which statuses would cause a partial or complete trip, and related IPLs. - SIF Diagrams ‐ used to depict complex SIF architecture to keep track of how a SIF would function. The author will present examples of the different types of graphic diagrams, methods in which the diagrams were utilized, and the benefits that each provided in the implementation of certain phases of an ANSI/ ISA 84 SIS lifecycle project. These diagrams were considered to be valuable process safety information and part of the final SIS Front End Loading design. Click here to view the complete whitepaper

by Mike Scott , P.E., CFSE, aeSolutions Founder This case study will discuss the application of the safety lifecycle as defined by ANSI/ISA 84.00.01‐2004 (IEC 61511 mod) to two single burner multiple fuel boilers. Each boiler is capable of firing natural gas, oil and/or waste gas, in order to supply the plant header with 1,365 psig steam at a maximum capacity of 310,000 lb/hr. The project team included the end client task force at the manufacturing facility, the engineering firm with design/procurement responsibility, the boiler OEM, the burner/gas train OEM, and the safety instrumented system consultant. This paper will cover: the development of a SIS front end loading package the project cost savings realized attributed to following the safety lifecycle the challenges encountered during the design process associated with the implementation of the safety lifecycle across a diverse project team Click here to view the complete whitepaper https://www.aesolutions.com/terms/burner-management-systems

The case for incorporating site specific process safety data into our calculations, and how to do it. Originally presented at the AIChE 2023 Spring Meeting and 19th Global Congress on Process Safety If we’re honest with ourselves, Process Safety has a lack of data problem. Nowhere does this show up more than in the types of calculations we perform for Layer of Protection Analysis (LOPA) and Safety Integrity Level (SIL) calculations, for example. Sure, we have generic failure data. But do we have the confidence that this generic data is right for our specific application? In addition, many LOPA scenarios contain “one-off” equipment parameters (either initiating event frequency or probability of failure) for which there is no generic data, leaving teams guessing at what value to use. Worse, LOPA targets are getting smaller (i.e., 1e-5 or 1e-6 per yr) which often leaves gaps, requiring decisions to be made regarding capital spending. Sticking with generic data in these cases can leave us feeling that we are being too conservative. On the Operations and Maintenance side of the LOPA equation, we face similar problems when attempting to verify the installed performance of an IPL (Independent Protection Layer). A multitude of assumed parameters (e.g., failure rates, test and inspection intervals, time in bypass, etc.) for which we would like a method to incorporate actual site data into the values used during design. And ideally this method could optimize these parameters for potential cost savings (for example, extending maintenance intervals). This paper will present a straightforward and easy to use method for feeding operational data back into process safety calculations, using commercial software that is already running on your computer. The paper will explore how much data is needed to confidently claim a parameter value, starting with an assumed or generic value, and periodically updating that value with small data, as evidence (from testing, maintenance, actual demands, etc.) is collected over time. The authors have been using these methods successfully on real process safety applications for several years now, that were all triggered by difficulties and shortcomings in LOPA. These application case studies will be discussed as well. Click here to view the complete whitepaper

by Sarah Manelick ‘Evergreen’ and ‘lifecycle’ have become two common buzz words in our industry. They are thrown around in a variety of topics, processes, and philosophies as descriptions of how management plans should be set up. But what does it really mean to have an evergreen process? How does one keep a lifecycle alive? This is especially relevant when it comes to topics such as alarm management, where it is commonly touted that once a plant rationalizes their entire system, they have completed alarm management. This paper will deconstruct the alarm management lifecycle and pinpoint key aspects that can be integrated into process safety management systems and work processes that already exist. Tying the alarm management lifecycle to what is already being done as part of process safety and good engineering practice will help to ensure it remains ‘evergreen’ and delivers the intended benefits. Click here to view the complete whitepaper aeSolutions offers services and systems to bring the client’s alarm management practices into compliance with the current ISA 18.2 standard s. Our services are designed to support our clients’ desires to encourage a culture of sustainable alarm management as an important component to their overall process safety strategy. Learn more here.

By Emily Henry, PE(SC), CFSE & Joel Ramírez When your facility is tasked with industry safety standard compliance, where do you start? What do all those SIS acronyms mean? For OSHA PSM-covered facilities, adherence to a functional safety lifecycle can be a critical step in overall SIS performance assurance. What is hiding under the radar of a plant SIS? Risk assessments define hazard consequences with assumed initiating event frequencies. How do we prevent these consequences? By verifying the reliability and availability assumptions of SIL Verification design parameters. Without understanding the design parameters your SIS is based upon, or without proper maintenance of your SIS equipment, your risk assessment gap closure may be incomplete. What factors into the assumptions of an SIS design? Are your safety devices replaced at their specified asset life, tested at the interval, and tested with the necessary rigor to uncover dangerous failures as specified in your calculations? What does following the Functional Safety Lifecycle entail? Does your facility have a Functional Safety Management Plan, perform Functional Safety Assessments on your SIS Design, and keep records of device failures to evaluate field performance against assumed reliability? This paper illustrates the real consequences of failing to uphold SIS design assumptions or follow the Functional Safety Lifecycle. Click here to view the complete whitepaper Prepared for Presentation at American Institute of Chemical Engineers 2024 Spring Meeting and 20th Global Congress on Process Safety New Orleans, LA March 24-28, 2024

by Mike Scott , P.E., CFSE, aeSolutions Founder ​ A two‐prong templatized approach to multiple brownfield burner management system upgrades can result in significant cost savings. The first step requires coming up with an equivalent design for the safety instrumented burner management system following the ISA 84 safety lifecycle , as allowed in current NFPA standards. The second step utilizes a templatization approach for multiple units with common functionality that will allow an organization to further maximize savings. Actual experience doing this on repeat BMS projects indicate the level of overall savings can be as high as 75% on the safety lifecycle, 70% on the control system design and integration, and 35% on the operation and maintenance activities. The combined overall savings are roughly 60%. Click here to view the complete whitepaper Drive risk out of the business and maximize availability of your fired equipment by engaging aeSolutions Burner Management System and Combustion Control System experts. Our experts are active on NFPA, API, IEC and ISA committees to ensure that code compliance is built into everything we deliver. Learn More

Functional safety engineers follow the ISA/IEC 61511 standard and perform calculations based on random hardware failures. These result in very low failure probabilities, which are then combined with similarly low failure probabilities for other safety layers, to show that the overall probability of an accident is extremely low (e.g., 1E-5/yr). Unfortunately, such numbers are based on frequentist assumptions and cannot be proven. Looking at actual accidents caused by control and safety system failures shows that accidents are not caused by random hardware failures. Accidents are typically the result of steady and slow normalization of deviation (a.k.a. drift). It’s up to management to control these factors. However, Bayes theorem can be used to update our prior belief (the initial calculated failure probability) based on observing other evidence (e.g., the effectiveness of the facility’s process safety management process). The results can be dramatic. Click here to view the complete whitepaper

Functional Safety & Bayesian Networks Functional safety engineers fol low the ISA/IEC 61511 standard & perform calculations based on random hardware failures. These result in low failure probabilities, which are then combined with similarly low failure probabilities for other safety layers, to show that the overall probability of an accident is extremely low (e.g., 1E-5/yr). Unfortunately, such numbers are based on frequentist assumptions and cannot be proven. Looking at actual accidents caused by control and safety system failures shows that accidents are not caused by random hardware failures. Accidents are typically the result of steady and slow normalization of deviation (a.k.a. drift). It’s up to management to control these factors. However, Bayes theorem can be used to update our prior belief (the initial calculated failure probability) based on observing other evidence (e.g., the effectiveness of the facility’s process safety management process). The results can be dramatic. For example, ass uming a safety instrumented function w ith a risk reduction factor of 5,000 (i.e., SIL 3 performance), and a process safety management program with a 99% effectiveness, results in the function actually having a risk reduction factor of just 98 (i.e., essentially the borderline between SIL1 and SIL 2). The key takeaway is that the focus of functional safety should be on effectively following all the steps in the ISA/IEC 61511 safety lifecycle and the requirements of the OSHA PSM regulation, not the math or certification of devices. Both documents were essentially written in blood through lessons learned the hard way by many organizations. To learn more about the use of Bayesian networks in functional safety , read the full paper here. Click here to view the complete whitepaper