What is the Nippon Dynawave facility?

The mill sits in Longview, Washington, in the Columbia River industrial corridor about 50 miles north of Portland, Oregon, sharing that stretch of riverfront with other timber, paper, and chemical operations. This is an industrial area, not a residential one, and no surrounding neighborhood was evacuated after the failure. Longview itself is a city of roughly 38,000.

Nippon Dynawave runs a kraft pulp and paper mill that produces bleached paperboard, the stiff stock used in milk cartons, beverage containers, cups, plates, and food packaging, plus kraft pulp for tissue and printing paper. Around 1,000 people work in the facility, roughly 550 in the pulp and paper mill and 450 in the packaging plant. The site is a US subsidiary of Japan-based Nippon Paper, which bought it in 2016.

The Longview site has made pulp since 1931, and this paperboard mill has run since 1953, originally built by Weyerhaeuser. The infrastructure is roughly seven decades old. The age of the specific tank that imploded is not publicly known.

What is white liquor?

White liquor is the cooking chemical kraft mills pump into their digesters to break wood chips down into pulp. It dissolves lignin, the natural binder that holds wood fibers together, so the cellulose fibers can be freed and turned into paper. The name is standard industry shorthand, one of a set: white liquor is the fresh cooking chemical, black liquor is the spent liquor after cooking, and green liquor is the intermediate in the chemical recovery cycle.

Chemically, it is a water-based solution of sodium hydroxide (NaOH), sodium sulfide (Na2S), and sodium carbonate (Na2CO3). The combination of high temperature and high alkalinity does the cooking work.

White liquor is strongly caustic, meaning basic. It is not a solvent like paint thinner, and it is not flammable: no flash point, no flammable vapor. The danger it carries is corrosivity, severe caustic burns on contact and damage to eyes, skin, and lungs on exposure.

What occurred on May 26, 2026?

Around 7:15 AM local time, the tank imploded, collapsing inward on itself under vacuum. It did not explode.

That distinction matters, and the early public account struggled with it. In the first day, authorities and reporters reached for three different words: explosion, then implosion, then rupture. Implosion is the accurate one. The tank failed under underpressure, a vacuum pulling its walls inward, not under the outward force of an overpressure or a blast.

The timing made it worse. A shift change about fifteen minutes earlier had put an unusually large number of workers in the immediate area, across operations, an administrative space, and a break room. It became the deadliest industrial disaster in Washington state since 1930.

The cause of the vacuum has not been established publicly, and there is no way to know it with certainty until the investigation runs its course.

Sadly, eleven workers were killed. Eight others were injured, seven workers and one responding firefighter, with chemical burns and inhalation injuries.

What causes a tank to implode?

A white liquor storage tank is almost certainly an atmospheric tank. In kraft mills, white liquor is held at close to ambient pressure, in tanks built for the narrow band near atmospheric, not in pressure vessels and not in vacuum vessels. “Atmospheric” is a pressure rating, not a description of the lid. Plenty of atmospheric tanks are fully enclosed, with fixed roofs, vents, and conservation devices. The term describes how much pressure the shell can hold, which is very little.

That last point is the whole story of an implosion. An atmospheric tank is far weaker against vacuum than against pressure. A few inches of water column of underpressure, a trivial amount, can buckle a fixed-roof tank inward. Modest internal pressure it shrugs off; modest vacuum it cannot.

Vacuum builds in a storage tank through ordinary mechanisms: pumping liquid out faster than air can flow back in through the vent, the contents cooling and contracting, condensation after a steam-out, or a vent that is simply blocked or frozen shut.

Tank vacuum protection, the vacuum-relief side of a tank’s venting, is what stands between routine operation and a collapse like this. The consensus standard for sizing it, alongside the pressure side, is API Standard 2000, “Venting Atmospheric and Low-Pressure Storage Tanks.” In practice, the vacuum side tends to get less attention than the overpressure side, both when the venting is first sized and in the maintenance that follows. The standard covers both cases. Field habits often do not.

This is also where process hazard analysis (PHA) could fall short, a gap SIL Safe often sees in hazard study reviews. A hazard and operability study (HAZOP) or a layer of protection analysis (LOPA) could give overpressure scenarios full rigor and treat low pressure as less likely. Vacuum is exactly the low-frequency, high-consequence scenario those studies exist to catch.

What regulations apply?

This is a US incident, so the analysis below is US-specific; readers elsewhere operate under their own frameworks. One thread runs through all of it: being regulated and being hazardous are not the same thing.

Does OSHA PSM apply to the white liquor tank?

OSHA’s Process Safety Management (PSM) standard (29 CFR 1910.119) reaches a process through one of two doors: a chemical on its Appendix A list at or above a threshold quantity, or a flammable liquid or gas at or above 10,000 pounds.

White liquor opens neither. Appendix A names 137 highly hazardous chemicals, and white liquor’s constituents, sodium hydroxide, sodium sulfide, and sodium carbonate, are not among them. OSHA has said so directly: its published interpretations confirm that sodium hydroxide is not an Appendix A chemical. The other two are not listed either. And because white liquor is aqueous and non-flammable, the flammable threshold never comes into play.

OSHA PSM does not reach the white liquor tank.

Does EPA RMP apply?

EPA’s Risk Management Program (RMP) rule (40 CFR 68.130) works off its own lists: regulated toxic substances and regulated flammable substances. White liquor’s components appear on neither. The toxic list is built around inhalation hazards, gases and volatile toxics such as chlorine (Cl2), ammonia (NH3), hydrogen sulfide (H2S), and methyl isocyanate. The flammable list covers flammable gases and volatile flammable liquids. A non-volatile, non-flammable aqueous caustic fits none of that.

EPA RMP does not apply.

Do paper mills fall under PSM and RMP?

Often, yes, but not because of white liquor. A kraft mill usually does have PSM-covered and RMP-covered processes, and they sit in the bleach plant and the chlorine dioxide generation area, not on the white liquor side. The chemicals that trigger coverage are chlorine dioxide (ClO2), chlorine, sulfur dioxide (SO2), and methanol. Chlorine dioxide is unstable and is typically generated on-site from sodium chlorate (NaClO3), methanol, and sulfuric acid (H2SO4); methanol is flammable. Those are what put a mill under federal coverage.

The obvious follow-up: if part of the mill is covered, isn’t all of it? Under OSHA’s interpretations, an interconnected process is treated as a single process, and if any part of it holds a listed chemical above the threshold, the whole interconnected process is covered. But in a kraft mill, the white liquor system and the bleach plant are not interconnected in that sense. They are linked by pulp moving from the cook side to the bleach side, not by any PSM-listed chemical flowing between them. So even where the bleach plant is covered, the white liquor tank generally falls outside that covered process. That said, this is an interpretation of federal law, and a lawyer should weigh in on any specific case.

The practical read: it is more likely than not that this part of the plant was not covered by PSM or RMP at all.

Two federal duties still apply regardless. The OSHA General Duty Clause, Section 5(a)(1), requires employers to keep a workplace free of recognized hazards whether or not a chemical is listed. The EPA Clean Air Act General Duty Clause, Section 112(r)(1), requires facilities handling hazardous substances to design and maintain a safe operation, listed or not. Those are the backstop when a tank falls outside both PSM and RMP on a listing technicality.

Any additional requirements in the State of Washington

Washington enforces workplace safety itself, as a state-plan state, through the Department of Labor and Industries (L&I) and its Division of Occupational Safety and Health (DOSH), not federal OSHA. It has its own rule modeled on federal PSM, WAC 296-67, with the same listed-chemical structure and thresholds, but no separate state list of additional regulated chemicals the way California does with CalARP, its accidental-release program. So the state PSM rule pulls the white liquor tank in no further than the federal one does.

Where Washington does reach this facility directly is through WAC 296-79, “Safety standards for pulp, paper, and paperboard mills,” an industry-specific standard that applies regardless of PSM coverage. The Department of Ecology also holds dangerous-waste and spill authority, and is already engaged in the environmental response.

Does this trigger functional safety via IEC 61511?

Likely no, not through regulation. This tank sits outside both PSM and RMP, and its white liquor system most likely isn’t part of any covered process at the mill. Since PSM and RMP are the route by which US regulation pulls in IEC 61511, the recognized and generally accepted good engineering practice (RAGAGEP) for safety instrumented systems (SIS), a tank that neither rule reaches isn’t pulled into IEC 61511 by them either. That is a regulatory point, not an engineering one: if a facility chose to guard a tank like this with a safety instrumented function (SIF) rather than a mechanical relief device, IEC 61511 would still be the standard to design, verify, and proof test it to. It just isn’t compelled here.

What we do not know at the time of writing (June 2026)

Until more comes out, most likely through the CSB investigation, the important questions stay open.

• What pulled the tank into vacuum. A blocked or plugged vent, pump-out outrunning the make-up air, thermal contraction, or condensation after a steam-out could each do it.
• The condition of the tank: its corrosion history in caustic service, when it was last inspected, and the age of the specific tank that failed.
• Whether the tank vacuum protection was present and working. Whether a pressure and vacuum relief device or vacuum breaker was installed, sized per API 2000, and maintained, and whether the vacuum scenario was ever identified in the facility’s PHA.
• The longer-term environmental and health impact of the white liquor that escaped into the site’s storm-drain and dike system.

Frequently Asked Questions

Q1. I used to work at a paper mill and it definitely had a functional safety program. You’re telling me this tank may not have been covered? Why is that?

Both things can be true. Your mill almost certainly did have a functional safety program, and it was almost certainly built around the bleach plant and chlorine dioxide generation, where the listed chemicals live and where PSM requires it. The white liquor system is a separate process. It is tied to the rest of the mill by pulp, not by any PSM-listed chemical, so it usually sits outside the covered process even at a mill that takes PSM seriously everywhere it applies. The program you remember was real. It just was likely not pointed at this tank, because the rules that drive those programs were not pointed there either.

Q2. Why do so many states have extra regulations on top of PSM and RMP? Is that just a US thing?

To a large degree, yes. The US splits authority between federal and state government, and occupational and process safety is one of the areas where states are allowed to run their own show. About half the states operate their own OSHA-approved safety programs instead of deferring to federal OSHA, and they can be stricter than the federal floor, never weaker. On top of that, a few states have built their own chemical-accident programs, California’s CalARP being the best known, that add requirements beyond federal RMP.

Most other countries run process safety through a single national framework, so the patchwork across US states is, in fact, fairly distinctive.

Q3. My plant has atmospheric tanks of non-flammable caustic. After reading this, what should I be checking on Monday morning?

Start with the vent path. For each tank, confirm there is a vacuum relief device, that it is sized for your worst-case outflow plus thermal effects per API 2000, and that it is actually maintained, not painted over, corroded shut, or screened off by a bird guard nobody has looked at in years. Then check pump-out rates against that vent capacity, because the fastest way to pull a vacuum is to draw liquid out faster than air can come back in. Last, pull the PHA and see whether vacuum or low pressure shows up as a deviation with a credited safeguard. If the study spent ten pages on overpressure and one line on vacuum, that is your gap. None of this needs the CSB report.

Q4. I work with safety instrumented systems for a living. Could a SIF have prevented this?

Possibly, and it is the right question to ask, though not automatically the right answer. The first line of defense against tank vacuum is mechanical: a properly sized, properly maintained vacuum relief device. That is simpler and more reliable than instrumentation for the basic breathing case, and it is what API 2000 is built around. A safety instrumented function earns its place when the mechanical layer cannot cover the credible scenarios on its own, say a pump-out rate that can outrun any practical vent, where you might credit a vacuum or low-pressure instrument that trips the outflow before the tank is endangered.

Further Reading

Internal (silsafe.net):

• Hazard and Risk Analysis Methods: How HAZOP, What-If, LOPA, Risk Graph, FTA, ETA, and Bowtie Fit Together
• Layer of Protection Analysis (LOPA): The Engineer’s Guide to SIL Selection
• Hazard and Risk Assessment (H&RA): The Foundation of Functional Safety

External:

• Washington Department of Ecology, Nippon Dynawave Longview incident page
• U.S. Chemical Safety Board, investigation announcement
• Wikipedia, “2026 Longview, Washington paper mill implosion”
• PBS NewsHour (Associated Press), recovery and casualty coverage
• OSHA, OSH Act Section 5 (General Duty Clause)
• Washington L&I, WAC 296-79, “Safety standards for pulp, paper, and paperboard mills”

The Disciplines Are Not the Same

Occupational safety is a discipline and a professional track. Process safety is an engineering discipline. Functional safety is an engineering discipline that follows a specific set of standards (IEC 61511 and IEC 61508) to implement risk reduction within process safety.

• Occupational safety protects workers from workplace hazards: falls, struck-by, chemical exposure, ergonomics, noise, confined spaces, electrical contact.
• Process safety is the engineering discipline for preventing major accidents from the process itself, such as releases, fires, explosions, and runaway reactions.
• Functional safety sits inside process safety as the standards-based engineering discipline (IEC 61511 and IEC 61508) for reducing process risk through instrumented protective functions.

A Venn diagram makes the relationship clear. Occupational safety is a separate circle. Process safety is a larger circle. Functional safety is a circle inside process safety.

Functional safety does not overlap with occupational safety as disciplines, though the two are adjacent and several site activities bring them together. They differ at the technical level, and skill sets do not transfer between them.

The Professionals and Their Backgrounds

The discipline distinction shows up cleanly in who does the work, where they train, and what credentials or certifications they hold.

Occupational safety professionals

The job type or discipline goes by several names depending on company and region: HSE (Health, Safety, and Environment), EHS (Environment, Health, and Safety), SHE (Safety, Health, and Environment), and HSSE (with Security added). The people doing the work carry an even longer list of job titles:

• Safety Manager
• Safety Engineer
• Safety Specialist
• Safety Coordinator
• HSE / EHS Manager
• Health and Safety Officer
• Industrial Hygienist
• Occupational Health Specialist
• Director of EHS / HSE

At SIL Safe, we refer to all of these roles collectively as occupational safety. Backgrounds run through occupational health and safety, industrial hygiene, environmental health, and sometimes engineering or kinesiology. Industrial hygiene is the field that figures out what workers are being exposed to on the job (chemicals, dust, noise, heat) and gets the exposure down to safe levels.

Professional bodies include the Board of Certified Safety Professionals (BCSP), the American Industrial Hygiene Association (AIHA), the UK Institution of Occupational Safety and Health (IOSH), the British Occupational Hygiene Society (BOHS), and the International Occupational Hygiene Association (IOHA) as the global umbrella.

Credentials include the Certified Safety Professional (CSP), the Certified Industrial Hygienist (CIH), and the Chartered Member of IOSH (CMIOSH).

Day-to-day work is workplace chemical exposure monitoring (airborne contaminants, dust, vapors), Personal Protective Equipment (PPE) programs, ergonomic assessments, incident investigation for personnel injuries, and regulatory compliance for worker protection.

Process safety professionals

Backgrounds are typically chemical engineering, though mechanical, electrical and controls, and other engineering disciplines with relevant process experience are also represented.

Professional bodies include the Center for Chemical Process Safety (CCPS, part of the American Institute of Chemical Engineers, AIChE), the Institution of Chemical Engineers (IChemE) in the UK, and the Mary Kay O’Connor Process Safety Center on the academic side.

Credentials include the Certified Process Safety Professional (CCPSC) via CCPS, IChemE professional registration, and often a Professional Engineer license (PE in the United States, P.Eng in Canada, CEng in the UK) in chemical, electrical, or other relevant engineering field.

Day-to-day work is Hazard and Operability (HAZOP) and Layer of Protection Analysis (LOPA) facilitation, mechanical integrity programs, management of change, and Process Hazard Analysis (PHA) revalidation.

Functional safety professionals

Functional safety professionals come from the same engineering backgrounds as process safety professionals, with deeper instrumentation, controls, and reliability engineering experience. The same professional bodies apply (AIChE, IChemE, and equivalents cover functional safety to a degree), with additional bodies that focus directly on it: TÜV Rheinland, TÜV SÜD, Exida, and the CFSE Governance Board.

The directly relevant credentials are the Certified Functional Safety Expert (CFSE) and Certified Functional Safety Professional (CFSP) from Exida, and TÜV FS Eng. Additionally, the International Society of Automation (ISA) and Underwriters Laboratories (UL) offer certifications.

Day-to-day work spans the full life-cycle: Safety Instrumented System (SIS) design and verification, proof testing oversight, functional safety audits, training, procedure maintenance, and competency matrix management, all governed by IEC 61511.

Occupational safety credentials and process / functional safety credentials do not cross. A CIH is not on a track to become a CFSE. The training, the math, and the body of standards are different worlds. Process safety and functional safety credentials, on the other hand, do cross. The underlying engineering background is the same, and many practitioners hold both. A CCPSC who is also a CFSE is a common and useful profile.

Where Functional Safety Meets Occupational Safety

The disciplines are not sealed off from each other.

• Hazardous area classification. Process safety defines the zones (Class I Div 1/2, Zone 0/1/2) based on the flammable inventory and release sources. Occupational safety enforces the consequences in the field: no uncertified tools, no non-intrinsically-safe radios, no work without the right PPE and procedures. A worker cannot walk into a Zone 1 area with an off-the-shelf iPad or their phone in their pocket. The classification is a process safety output. The daily enforcement is an occupational discipline.
• Personal gas monitors (flammable gas / Lower Explosive Limit, hydrogen sulfide, oxygen). A worker wearing a personal monitor is an occupational control protecting that worker from a process hazard. The hazard originated in the process. The control is occupational. Both disciplines have a stake.
• Confined space entry. Occupational program (permits, attendants, retrieval), but the atmosphere being tested exists because of process residues and the equipment being entered is process equipment. The entry decision depends on understanding the process chemistry: what was last in the vessel, what reactions are possible, what residual hazards remain after isolation.

Overlap at the activity level is real and common practice in a healthy organization. Overlap at the competency level is minimal. The HSE professional running the confined space program is not qualified to verify a Safety Integrity Level 2 (SIL 2) Safety Instrumented Function (SIF). The functional safety engineer verifying that SIF is not qualified to write the confined space program. The activities cross. The competencies do not.

Common Mistakes

Strong personnel safety record interpreted as process safety health. A facility logs years without a recordable injury, leadership concludes the safety program is working, and a major release blindsides them six months later. Texas City, Buncefield, and Jaipur all happened at facilities with strong personnel safety records. The Baker Panel report after Texas City made this pattern explicit: BP had been managing personal safety while neglecting process safety. Personnel injury rate measures slips, trips, hand cuts, and ergonomic strains. None of those metrics tell you anything about whether the SIS will work on demand or whether the relief valves are adequately sized.

• Leadership asking for process safety KPIs and getting handed occupational ones. Boards and executives ask “how safe are we?” and HSE shows them Total Recordable Incident Rate (TRIR), Lost Time Incident Rate (LTIR), and Days Away, Restricted, or Transferred (DART) trending down. The metrics are real and the trend may be real, but they answer a different question. Process safety health is measured by leading indicators tied to Process Safety Management (PSM) and Risk-Based Process Safety (RBPS) elements: management of change (MOC) backlog, PHA action items overdue, proof test completion rate, SIF demand rate. Personnel injury statistics are not those indicators.
• Putting functional safety under the HSE function. Org chart logic (“safety is safety, put it under the safety guy”) or cost pressure pushes functional safety, the Safety Requirements Specification (SRS), and the Hazard and Risk Assessment (H&RA) under HSE ownership. The work either gets skipped or gets done badly by someone with the wrong training, and the deliverables end up in the wrong hands organizationally.

Q&A

Q1. My boss says our safety manager can handle the SIL stuff. What do I tell him?

Tell him that your safety manager is properly an Occupational Safety Manager by role, even though the actual title varies (Safety Manager, HSE Manager, EHS Director, and so on). An occupational safety professional is fundamentally a different animal than a functional safety engineer. The safety manager probably runs PPE programs, exposure monitoring, ergonomic assessments, and injury investigations. SIL work is a different domain: IEC 61511, SIS architecture, failure modes, reliability mathematics, proof testing. The training does not transfer, and the credentials do not overlap. A CSP is not on a track to a CFSE, and a few hours of online refresher will not bridge the gap.

In the safety manager’s defense, occupational safety professionals carry a confusing array of job titles, and the word “safety” appearing in both disciplines does not help. The conflation is understandable. The substitution is not. The two roles can sit in the same organization and respect each other, but one cannot substitute for the other.

Q2. Isn’t process safety just functional safety at a bigger scale?

It is the other way around. Process safety is the broader engineering discipline. Functional safety is a subset of process safety, tied to the standards (IEC 61511 and IEC 61508) that govern instrumented protective functions. HAZOP, LOPA, mechanical integrity, management of change, and Pre-Startup Safety Review are all process safety activities that are not functional safety.

Q3. We have an excellent TRIR. Doesn’t that mean our process safety program is working?

No, but there is some overlap. A process safety incident with injuries does show up in TRIR. The metric itself is dominated by occupational events, though: slips, trips, hand cuts, strains. A facility can drive TRIR to industry-leading levels while its SIS portfolio is overdue for proof testing, its MOC backlog is unmanaged, and its layers of protection have eroded. The Baker Panel report after Texas City documented exactly that pattern at BP. TRIR is a useful occupational metric. It is not a leading indicator of functional safety or process safety health.

Q4. If a personal gas monitor protects a worker from a process release, why isn’t it a LOPA credit?

A personal gas monitor can sometimes meet IPL (Independent Protection Layer) criteria within a functional safety LOPA, but the claim is often made without testing them. An IPL must satisfy three requirements:

• Independence. The protection layer cannot share failure modes with the initiating cause or with other claimed layers.
• Specificity to the scenario. The monitor must detect the specific release and give the wearer enough time to act before harm.
• Auditability. Calibration records, bump test records, and battery and gas check records must be in place and reviewable.

Take two scenarios:

• Slow flange leak detected on a routine round. The wearer has time to back away, and an audited monitor program can credibly support an IPL claim for that scenario.
• Line rupture that puts the wearer in a vapor cloud within seconds. The same monitor cannot stand as an IPL, because the detection-to-action time is not there.

The other common failures are claiming credit against the wrong consequence type (the monitor does nothing about equipment damage, fire escalation, or fence-line population) and double-counting the same monitor across multiple scenarios where independence does not hold. A personal gas monitor is a real occupational control that saves lives. It is not, by default, a LOPA credit, and the judgment can be tricky.

Q5. Does the functional safety person need to work with and talk to the HSE / occupational safety team?

Absolutely, they should be considered colleagues. Hazardous area classification needs both sides aligned: process safety defines the zones, and HSE enforces the field consequences. Personal gas monitor programs cross both disciplines, with the monitor itself an occupational control protecting against a process hazard. Confined space work that involves SIS equipment needs functional safety input on bypass and recovery procedures, while the HSE program owns the entry permit itself. The relationship is collaborative, not hierarchical. Each side owns its discipline.

Further Reading

Internal (SIL Safe)

• Hazard and Risk Assessment (H&RA): The Foundation of Functional Safety
• Layer of Protection Analysis (LOPA): The Engineer’s Guide to SIL Selection
• SIL Verification: The Three Gates Every SIF Must Clear

External

• IEC 61511 standard page (IEC)
• UK Health and Safety Executive: Control of Major Accident Hazards (COMAH)
• American Industrial Hygiene Association: Discover Industrial Hygiene
• International Occupational Hygiene Association (IOHA)

Functional safety is complex, and the stakes are high. If you have questions about your SIS design, SIL verification, or where to start with IEC 61511, the team at SIL Safe is here to help. Reach out to us today.

What is the GKN Aerospace facility?

The site is operated by GKN Aerospace Transparency Systems Inc., a subsidiary of GKN Aerospace, and sits on roughly 15.5 acres in Garden Grove, California. GKN has been at this location since 2004.

The facility makes the windows and canopies of major aircraft. The Garden Grove site designs and produces cockpit canopies, fighter canopies, and passenger windows, including the F-35 canopy and transparencies for the Boeing 787 and 737, the Airbus A350, HondaJet, and the Bombardier C-Series. Those transparencies are made from polymethyl methacrylate (PMMA, also known as acrylic, Plexiglas, or Lucite), and that is why a substantial inventory of MMA is on site. MMA is the monomer feedstock for making the polymer.

The tank and the chemical

Methyl methacrylate is a colorless flammable liquid monomer with a fruity odor. Its flash point is 36°F (2°C), which puts it in the same general “ignites at room temperature” category as gasoline (flash point roughly -45°F). For context on the other end of the common fuels, diesel sits around 125°F. The boiling point of MMA is 214°F (101°C), so it stays liquid through any realistic ambient condition.

The tank has a capacity of approximately 34,000 gallons; reporting indicates an MMA inventory of 6,000 to 7,000 gallons at the time of the incident. From photos circulating in news coverage, the tank appears to be fully enclosed, fixed-roof construction with external insulation that has since been removed by responders to aid cooling. Enclosure alone does not determine whether the tank is “atmospheric” in the regulatory sense, which has a specific technical meaning that matters for the PSM analysis.

The reason MMA is stored with care is that it is a reactive monomer. If temperature control is lost or if the inhibitor (typically methyl ether of hydroquinone, MEHQ, at low ppm) is depleted, MMA can undergo exothermic polymerization, where the chemical reacts with itself to form the polymer. That reaction releases heat, which accelerates the reaction, which releases more heat. That is the runaway pattern, and once it starts there is no easy way to stop it. It is the central hazard of bulk MMA storage and the reason a tank of this material is taken so seriously.

What occurred in May 2026

The incident began on May 21, 2026, when the storage tank started overheating and venting vapors. Orange County Fire Authority responded that afternoon, and over the next several days the Garden Grove chemical incident escalated. The evacuation zone started as a roughly one-mile radius around the facility, then expanded to cover approximately nine square miles, ultimately displacing somewhere between 44,000 and 50,000 residents. The Governor of California declared a state of emergency.

As of writing, stabilization efforts are ongoing. Reports indicate that a crack in the tank may have vented pressure and reduced the immediate explosion risk, but the data is preliminary. The Orange County District Attorney has opened a tip line for information related to GKN’s operations.

The cause of the temperature excursion has not been publicly established, and we do not speculate.

What regulations apply?

The Garden Grove chemical incident plays out under three US frameworks: OSHA’s Process Safety Management (PSM) standard, EPA’s Risk Management Program (RMP), and California’s CalARP. International readers will be familiar with frameworks like Seveso (EU) and COMAH (UK), which operate on a different basis and are not within scope here.

Does OSHA PSM apply?

PSM (29 CFR 1910.119) has two pathways for coverage. One is the list of specifically named highly hazardous chemicals in Appendix A. MMA is not on that list. The other pathway, in 1910.119(a)(1)(ii), covers any process involving a flammable liquid with a flash point below 100°F in quantities of 10,000 lb or more at one location.

MMA clears both criteria easily:

• Flash point of 36°F is well below the 100°F threshold.
• At a density of 0.94 g/cm³, even the lower-end reported inventory of 6,000 gallons is roughly 47,000 lb.

The MMA storage at GKN satisfies the PSM flammable liquid trigger. The standard has an important exemption.

The atmospheric tank exemption in 1910.119(a)(1)(ii)(B) excludes flammable liquids stored in atmospheric tanks kept below their normal boiling point without chilling or refrigeration. Two things to get right here:

• “Atmospheric tank” is a pressure-rating definition, not a description of the lid. Many atmospheric tanks have fixed roofs, vents, and conservation devices. A tank can be fully enclosed and still be atmospheric.
• The “below normal boiling point without chilling” condition is satisfied by ordinary ambient storage of MMA. MMA boils at 214°F and an unrefrigerated tank at typical ambient temperature is well below that.

On the pressure-rating side, the GKN tank is almost certainly atmospheric. Bulk MMA storage in industry is standard atmospheric tank service. The vapor pressure of MMA at typical storage temperature is low, and there is no operational reason to put MMA in a pressure-rated vessel. The major MMA producers describe atmospheric storage practice on their technical data sheets. So the pressure-rating element of the test is not the issue. The issue, as covered further below, is the chilling and refrigeration clause.

The atmospheric tank exemption is the reason every gas station in the US is not subject to PSM and RMP. OSHA’s view was that ordinary atmospheric storage of flammable liquids is adequately covered by NFPA 30, API 650, OSHA’s own 1910.106 flammable liquids standard, and local fire code.

Interconnection cuts the other direction. If something else on the GKN site triggers PSM (a covered process, a covered chemical inventory elsewhere), and the MMA tank is interconnected to it through piping, the MMA tank gets pulled into scope by virtue of that connection. So even if the MMA tank by itself qualifies for the atmospheric tank exemption, the tank may still be PSM-covered through the rest of the facility. Whether that is the case at GKN depends on facility details that are not public.

Regulatory uncertainty of a chiller

One more wrinkle, and this is where engineering ends and law begins. According to OCFA statements during the response, the MMA tank had an active cooling system designed to keep the contents at around 50°F, and the failure of that cooling system was central to the incident. The atmospheric tank exemption requires storage “kept below their normal boiling point without benefit of chilling or refrigeration.” That clause supports two reads:

• “No chilling of any kind.” Any chilling on the tank disqualifies the exemption.
• “No chilling needed to keep below boiling.” Only chilling that exists to manage boiling point disqualifies the exemption. Chilling for other purposes (polymerization control, viscosity control) does not.

MMA boils at 214°F and would stay well below boiling at any reasonable ambient temperature with no cooling at all. The cooling system at GKN was almost certainly there to suppress the polymerization reaction, not to keep the liquid below boiling. So a refrigerated MMA tank sits squarely in the gap between those two readings. This is the kind of question engineers end up handing to lawyers, because regulatory interpretation isn’t an engineering call.

Does EPA RMP apply?

EPA’s Risk Management Program (RMP, 40 CFR Part 68) works differently from PSM. Rather than a generic flammable-liquid trigger, RMP applies only to a curated list of regulated substances in 40 CFR 68.130. MMA is not on that list.

The reason MMA is not on the list comes down to chemistry. EPA built Table 3 (the flammable substances portion) using the criteria for a flammability rating of 4 on the NFPA 704 fire diamond, which require flash point below 73°F AND boiling point below 100°F. MMA’s flash point of 36°F clears the first hurdle, but its boiling point of 214°F fails the second by a wide margin. The substances that did make Table 3 are predominantly gases or near-gases at ambient: propane, ethylene, butadiene, methane. These are the materials that flash to vapor on release and produce expanding vapor clouds. MMA does not fit that profile.

Therefore, RMP does not apply to MMA storage at GKN.

California regulation: CalARP

California has a state-level analog called CalARP (California Accidental Release Prevention Program, Title 19 CCR §5130.6). MMA is not on any CalARP table, so CalARP does not apply either.

Even if any of these regulations did apply, none of them directly require IEC 61511. They require “recognized and generally accepted good engineering practices” (RAGAGEP) for safety-critical systems, and IEC 61511 is the RAGAGEP for safety instrumented systems in the process industry. The hook into functional safety is by reference, not by name.

Was OSHA PSM actually being applied at GKN?

There is no way to know with certainty from outside the fence line.

OSHA does not maintain a public registry of PSM-covered facilities. Coverage is self-determining; an operator evaluates its own processes against the standard, and verification happens through inspections.

Prior OSHA inspections and worker complaints at the Garden Grove site have been reported in recent coverage, along with a 2018 California Department of Industrial Relations penalty involving machinery and fabrication concerns. None of that confirms whether PSM applied to the MMA storage. Those inspections may have addressed occupational safety topics like machine guarding, lockout-tagout, and fall protection rather than process safety. The two are distinct disciplines, often handled by different teams inside a facility and inspected against different standards.

GKN’s public statement says the company “follows all standard safety protocols and processes and is regularly audited by numerous state and federal agencies.” The statement does not specifically address PSM coverage of the MMA storage.

Is there evidence GKN has a functional safety program?

Not publicly. Functional safety programs (IEC 61511 SIS implementations, SIL verifications, safety requirements specifications) are not typically disclosed publicly by operators. They live in internal documentation and are reviewed by regulators or third-party assessors, not posted on company websites.

The Orange County DA tip line and ongoing investigations suggest authorities are looking at safety system adequacy, but no findings are public.

Has the CSB said anything?

The U.S. Chemical Safety and Hazard Investigation Board (CSB) is an independent federal agency that investigates industrial chemical accidents. As of writing, the CSB has not publicly announced a deployment to the Garden Grove chemical incident.

What we do not know at the time of writing (May 2026)

• The cause of the temperature excursion. Public reporting has not established what initiated the runaway, and we do not speculate.
• What safety systems were in place at GKN, and how they performed.
• Whether GKN’s specific tank configuration qualifies for the atmospheric tank exemption. That requires facility data not in public reporting.
• Long-term health and environmental impact in the affected zone.
• Anything that would require information held by GKN, OSHA, EPA, or the Orange County Fire Authority but not yet released publicly.

Q&A

Q1: What is MMA and why is it stored in tanks like this?

MMA is methyl methacrylate, a flammable liquid organic compound. It is a monomer, meaning a small molecule that chemically links with copies of itself to form a long-chain polymer. The polymer in MMA’s case is polymethyl methacrylate (PMMA, also called acrylic or Plexiglas). Bulk MMA storage is common anywhere PMMA is manufactured.

Q2: Is methyl methacrylate covered by OSHA PSM?

Possibly. MMA is not on the OSHA PSM Appendix A list of named highly hazardous chemicals, but PSM has a separate pathway for flammable liquids with flash point below 100°F in quantities of 10,000 lb or more. MMA meets both criteria. The complication is the atmospheric tank exemption, which excludes flammable liquids in atmospheric tanks kept below boiling point without chilling or refrigeration. For an unrefrigerated MMA tank at ordinary ambient conditions, the exemption likely applies. For a refrigerated MMA tank like the one at GKN, applicability is genuinely unsettled and depends on how the chilling clause is interpreted.

Q3: The tank at GKN has a lid on it. Doesn’t that mean it’s not an atmospheric tank under PSM?

No. “Atmospheric tank” in 1910.119 is a pressure-rating definition, not a description of whether the tank is open to the air. Most atmospheric tanks have fixed roofs, vents, manways, and conservation devices. A tank can be fully enclosed and still be atmospheric. What disqualifies a tank from being atmospheric is being designed and rated for higher internal pressure than atmospheric service. The presence of a lid is not the deciding factor.

Q4: Do engineers ever need lawyers to interpret regulatory language?

More often than people outside the field would guess. Regulations like PSM are written in language that looks straightforward but contains clauses with multiple defensible readings. The atmospheric tank exemption is a good example: the phrase “kept below their normal boiling point without benefit of chilling or refrigeration” can mean “no chilling of any kind” or “no chilling needed for boiling-point control,” and a tank that is refrigerated for a non-boiling-point reason sits squarely in the gap between those two readings. Engineers can describe the tank, the chemistry, and how the system operates. Whether those facts add up to the exemption applying or not is a regulatory interpretation question, and that is lawyer territory. On material questions, engineering and legal teams have to work together — the engineer establishes what the system is, and the lawyer establishes what the regulation says about it.

Further Reading

Internal (silsafe.net):

• Hazard and Risk Assessment (H&RA): The Foundation of Functional Safety
• Layer of Protection Analysis (LOPA): The Engineer’s Guide to SIL Selection

External:

• Garden Grove chemical leak — Wikipedia
• California chemical tank has cracked, causing state of emergency, thousands to evacuate — NPR
• Live updates: Garden Grove chemical tank emergency — NBC Los Angeles
• CalEPA — California Accidental Release Prevention (CalARP) Program
• U.S. Chemical Safety and Hazard Investigation Board
• CDC/NIOSH Pocket Guide — Methyl Methacrylate

The three gates are:

1. PFDavg / PFH — the quantitative gate. The SIF’s failure probability must meet its allocated SIL band.
2. Systematic capability — every device in the SIF must be fit for the required SIL, by certification or by prior use.
3. Architectural constraints — the SIF’s hardware fault tolerance must be sufficient for its target SIL.

A SIF that nails its PFDavg but fails on systematic capability or architecture is not verified. The gate that gets the most attention, PFDavg, is rarely the one that fails an audit.

A note on terminology before going further. “Verification” in IEC 61511 is broader than what this article covers. It spans the whole life-cycle: H&RA, SRS, design, FAT, operations. “SIL verification” is the industry shorthand for the design-phase SIF verification specifically, and that is what this article covers.

The three worked scenarios at the end show the gates working together: one clean pass and two failure cases that mirror what auditors actually find.

Gate 1: PFDavg / PFH

This is the quantitative gate, defined in IEC 61511 Clause 11.9. The SIF’s calculated probability of failing to act on demand must meet or exceed its allocated SIL band.

Demand mode determines which metric applies. Low demand, where the SIF is called on less than once per year, covers most process industry shutdown SIFs and uses Probability of Failure on Demand average (PFDavg). High demand and continuous mode, more frequent than once per year, cover some compressor protection, fired equipment trips, and machinery safety, and use Probability of Failure per Hour (PFH). High demand and continuous are treated together for SIL verification purposes.

This article is not a PFDavg tutorial. For depth on inputs and methods, see the dedicated PFDavg article in Further Reading.

Why this is the gate everyone fixates on

It produces a number, and numbers feel definitive. Tools automate it. The other two gates require judgment, evidence, and documentation. The PFDavg report is the tangible deliverable a manager can hold up and point to.

The trap is that it’s also the gate easiest to engineer to pass on paper while the SIF still fails on Gates 2 or 3.

Where this gate fails

The PFDavg calculation is only as honest as its inputs and architecture assumptions. The same calculation can produce a false pass or a false fail depending on which way the assumptions lean.

• False pass: optimistic TI, overstated Cpt, generic failure rates that don’t match the real device. The number passes, but real-world risk reduction is lower than the report claims.
• False fail: overly conservative inputs reject a SIF that would actually meet its target. The design ends up over-engineered relative to the real risk.
• Wrong architecture: sometimes the architecture is just wrong for the target SIL. No amount of input tweaking saves a wrong-fit architecture.

Gate 2: Systematic Capability

This gate is about whether the components of the SIF have an applicable level of quality and design rigor for the required SIL. It comes from IEC 61511 Clause 11.5, with the prior use path specifically governed by Clause 11.5.3, and the systematic capability concept itself defined in IEC 61508-2. Systematic capability is a property of the device, not the loop. It addresses systematic faults (design errors, software bugs, manufacturing defects) that redundancy can’t solve.

The systematic capability rating of every device must equal or exceed the SIF’s SIL.

There are two paths to demonstrate it.

IEC 61508 certification (manufacturer-side)

The manufacturer has had the device assessed against IEC 61508 by a certification body. The outcome is a SIL Certificate stating the systematic capability rating, typically expressed as SC 2, SC 3, etc.

Inside IEC 61508, certification can be achieved through different S routes. Route 1S (design-process rigor) is the most common. Route 2S (proven in use) is less common. Route 3S applies to software.

For the facility verifier, what matters is the systematic capability rating on the certificate. The route the manufacturer used to achieve it is documented in the SIL Certificate. Software systematic capability is handled by Route 3S, applied to embedded firmware and application software during certification of devices like logic solvers. For a facility verifier using a certified logic solver, this is captured by the SC rating on the certificate. No separate software analysis required at the facility level.

IEC 61511 prior use (facility-side)

This is IEC 61511’s alternative path when no IEC 61508 certification exists for the device, governed by Clause 11.5.3.

The owner-operator demonstrates suitability through documented field history under similar operating conditions. No certificate of conformance is involved. Prior use is a facility-side justification, not a third-party attestation. The deliverable is a documented prior use file evaluated by the facility’s functional safety engineer and audited by an FSA team.

It requires evidence of:

• Manufacturer quality management
• Device identification and version control
• Performance in similar operating environments
• Sufficient volume of operating experience

Generally a more difficult and document-heavy path than using a certified component.

Terminology traps to watch for

Prior use vs. proven in use. Prior use is the IEC 61511 facility-side path. Proven in use is a specific IEC 61508 route (Route 2S) used by manufacturers seeking certification without a full FMEDA-driven path. Even Goble’s books and many practitioners use “proven in use” loosely to describe both. Be precise in your own documentation.

The H/S route split. The H routes (1H, 2H) belong to architectural constraints (Gate 3). The S routes (1S, 2S, 3S) belong to systematic capability (Gate 2). The H/S split distinguishes what kind of capability is being demonstrated, not which subsystem the route applies to. Practitioners regularly try to apply S routes to Gate 3 or H routes to Gate 2. Keep them separate.

Where this gate fails

• Legacy field devices with no certificate and no defensible prior use file. “We’ve used it for years” claimed without documentation, version control, or operating-condition records is the typical pattern.
• Mismatched systematic capability rating, like using an SC 2 device in a SIL 3 SIF.

Gate 3: Architectural Constraints (Hardware Fault Tolerance)

This gate is about the inherent redundancy of the SIF: does it have enough fault tolerance to survive a single dangerous failure at its required SIL. It comes from IEC 61511 Clause 11.4, with route definitions inherited from IEC 61508-2 Clause 7.4.4.

Hardware fault tolerance (HFT) is the number of dangerous failures a subsystem can tolerate before losing its safety function. A 1oo1 subsystem has no hardware fault tolerance (HFT = 0). A 1oo2 subsystem has HFT = 1.

Two H routes are available, applied per element. Different elements in the same SIF can use different routes.

Route 1H

Route 1H is based on Safe Failure Fraction (SFF) and Type A vs. Type B classification, using IEC 61508-2 Tables 2 and 3. It requires FMEDA-grade failure data to compute SFF.

Type A devices have simple, well-understood failure modes (most mechanical devices). Type B devices are complex with embedded software or microprocessors. The Route 1H tables apply different SFF thresholds to each. Type A is treated more leniently than Type B at the same SIL.

This is the most common route for modern certified components, particularly logic solvers, smart instruments, and modern positioners with documented FMEDAs.

A note on diagnostics. SFF improves when diagnostics catch dangerous failures, but high SFF doesn’t strictly require diagnostics. A device with intrinsically safe failure modes (for example, a spring-return solenoid where loss of power drives the safe state) can hit high SFF with no diagnostics at all. In practice, though, most devices that achieve high SFF on Route 1H do so because of diagnostic coverage.

Route 1H — Type A devices (IEC 61508-2 Table 2)

Route 1H — Type B devices (IEC 61508-2 Table 3)

Route 2H

Route 2H is based on hardware structural resilience and field reliability data. It does not require SFF and uses simpler tables driven by SIL alone.

This is effectively the route IEC 61511 uses on its own. IEC 61511’s architectural constraint table is derived from IEC 61508 Route 2H, and Goble notes the two are essentially identical.

Route 2H is most common for mechanical devices with no or minimal diagnostics (rack-and-pinion actuators, manual valves), legacy equipment that predates IEC 61508, and any device where FMEDA data is not available.

Prior use data can contribute to other parts of the verification, most directly to Gate 2 systematic capability. The same field history that supports a Route 2H argument for hardware integrity may also support a prior use justification under Clause 11.5.3.

Route 2H — minimum HFT by SIL

Choosing an H route

For new SIFs designed with modern equipment, the route appears on the SIL Certificate for certified components, typically labeled “Route 2H Device” or similar. This is the most common situation a facility verifier will encounter.

The decision is per-element and driven by available evidence:

• Devices with FMEDA data and meaningful diagnostics generally go Route 1H.
• Devices without FMEDA data, or mechanical devices where diagnostics can’t catch the dominant failure modes, go Route 2H.

Both routes are legitimate. Route 2H is not a fallback or a downgrade. It is the appropriate route for hardware where the SFF-based approach doesn’t fit, and either route is acceptable evidence for SIL verification at the target SIL.

Where this gate fails

• Claiming Route 1H without the FMEDA data to back it.
• Selecting a 1oo1 architecture for a device whose SFF and Type combination can’t reach the target SIL because of required HFT.
• Using a Route 2H legacy device in a SIL 3 application where Route 2H can’t get there regardless of redundancy.
• Mixing route claims across elements without verifying each element’s evidence stands on its own.

Worked SIL Verification Examples

Three scenarios to make the three-gate framing concrete. Each zooms in on a single component (or two in Scenario 2) within an otherwise-passing SIF. Each scenario opens with a scope statement, then walks through all three gates in whichever order makes the component’s story easiest to follow. These are SIL verification scenario walkthroughs, not PFDavg calculation tutorials.

Scenario 1: A straightforward verification

For this scenario we focus on a smart pressure instrument on a SIL 2 SIF, used in a 1oo1 architecture. Assume the rest of the SIF verifies cleanly.

• Gate 2: The device is IEC 61508 certified, with an SC 2 rating on the SIL Certificate. SC 2 matches the SIF’s required SIL — passes.
• Gate 1: The certificate provides manufacturer failure rate data. This instrument’s contribution to the SIF-level PFDavg, combined with the rest of the SIF’s components, clears the SIL 2 band — passes.
• Gate 3: The SIL Certificate confirms Route 1H, Type B, and a documented SFF of 93% (in the 90% to <99% band). The Route 1H Type B table allows SIL 2 at HFT 0, so the 1oo1 architecture clears — passes.

The rest of the SIF (final element and logic solver) verifies via the same logic. This is what a modern and clean SIL verification looks like: a certified component, a matching SC rating, an architecture that fits the route’s table, and a PFDavg that lands in band.

Scenario 2: A trickier case

For this scenario we focus on two components (a final element and an instrument) on a SIL 2 SIF in low-demand mode. Assume the rest of the SIF verifies cleanly, including the SIF-level PFDavg contribution from other components.

Final element walkthrough, non-certified valve in a 1oo2 architecture:

• Gate 2: Non-certified valve with no IEC 61508 certificate. The facility attempted prior use, but the operating-history records don’t meet Clause 11.5.3 documentation requirements — fails.
• Gate 1: Failure rate data sourced from OREDA for this device class, applied to the SIF-level PFDavg — passes.
• Gate 3: Route 2H requires minimum HFT 0 for SIL 2 in low-demand mode. The 1oo2 architecture provides HFT 1, which exceeds the minimum — passes.

Instrument walkthrough, certified instrument in a 1oo1 architecture:

• Gate 2: The device is IEC 61508 certified with an SC 2 rating — passes.
• Gate 1: Failure rate from the SIL Certificate plugs into the SIF-level PFDavg — passes.
• Gate 3: Type B smart instrument with documented SFF in the 60% to <90% band, in a 1oo1 architecture, is capped at SIL 1 by the Route 1H Type B table — fails.

Two components, two unrelated gate failures, both blocking SIL verification of the SIF as a whole. The final element passes its architecture check but fails systematic capability. The instrument passes systematic capability but fails its architecture check. This is why the gates are treated as independent: a SIF doesn’t get partial credit for clearing two of three on any given component, and clearing all three on most components doesn’t help if one element fails one gate.

Scenario 3: The hardest one to catch

For this scenario we focus on a non-certified globe valve, used in a 1oo1 architecture. Assume the rest of the SIF verifies cleanly.

The engineer specified this valve from a familiar vendor because it was the right size, available, and had been used in non-safety service at the site for years. To populate the verification report, the engineer pulled an SFF figure from the SIL-rated version of the same product family, same vendor, same valve series, but a different model.

• Gate 2: No IEC 61508 certificate for the actual valve installed. The non-safety service history doesn’t qualify for prior use under Clause 11.5.3 — fails.
• Gate 1: PFDavg calculation passes using the borrowed SFF and a generic failure rate from a database — passes.
• Gate 3: Both Route 1H and Route 2H were considered. Route 1H requires FMEDA-grade failure data for the actual device installed. The borrowed SFF from a sibling SIL-rated model doesn’t qualify, and no FMEDA exists for this valve. Route 2H doesn’t require SFF, but does require documented hardware reliability evidence, and the non-safety service history doesn’t meet that bar either — fails.

The rest of the SIF verifies cleanly. One bad component sinks the SIL verification.

The lesson here is that the gates are independent in principle but often connected in practice. A device with no certificate and no defensible field history typically fails on Gate 2 and leaves Gate 3 with no defensible route. And route claims on Gate 3 must be defended with evidence that’s specific to the device installed, not borrowed from a similar product.

Life-cycle Placement

SIL verification sits in the design phase of the IEC 61511 safety life-cycle.

What comes before: H&RA and LOPA produce the SIL allocation for each SIF. The SRS captures the safety requirements. Conceptual SIS design proposes a candidate architecture and equipment selection. SIL verification then takes those inputs and tests them against the three gates.

What comes after: continued detailed design, FAT, installation and commissioning. The verification report is a key input to the Functional Safety Assessment and to operational handover.

Common Mistakes

The mistakes that surface during SIL verification audits are rarely about the math. They are about evidence, judgment, and which gate the engineer treated as optional.

• Treating PFDavg as the only gate. The calculation passes, often using manufacturer numbers without scrutiny, and the audit fails on Gate 2 or Gate 3. This is the most common pattern, and it’s the spine of most of the failures below.
• Claiming prior use without the documentation to defend it. “We’ve run this valve for 15 years” is not a prior use file. Clause 11.5.3 wants quality management, version control, and operating-condition records, not informal recollection.
• Confusing prior use with proven in use, then defending neither correctly when challenged.
• Not realizing a route was claimed at all. Accepting whichever H route the calculation tool defaulted to without checking whether the device’s evidence supports it.

Most of these share a root cause: engineers default to whichever gate they’re most comfortable with and underweight the other two.

Q&A

Q1: I thought PFDavg was all we had to do. What’s the deal?

PFDavg is one of three independent gates, not the whole verification. IEC 61511 Clause 11 also requires systematic capability (the device is fit for the SIL by certification or prior use) and architectural constraints (the hardware fault tolerance is sufficient for the SIL). A SIF can have a beautiful PFDavg report and still fail SIL verification. PFDavg gets the attention because it produces a number and tools automate it, but the other two gates are where audits most often turn up problems.

Q2: I heard we have to use SIL-certified devices. Is that correct?

Certified devices make your life easier and are recommended, but not strictly required. IEC 61511 also allows prior use as an alternative path under Clause 11.5.3. Prior use is harder and document-heavy. That is the trade-off for skipping certification. Most facilities find the cost of building defensible prior use files component by component exceeds the price premium on certified equipment. SIL Safe defaults to certified components on every project for exactly this reason.

Q3: I’ve been using this family of PLCs for years and they’re great. Never had a problem. How can I use this in a SIF?

Possible in theory, expensive in practice, scrutinized at all three gates of SIL verification. On Gate 2, prior use under Clause 11.5.3 needs more than a track record. It needs documented manufacturer quality management, version control, and operating-environment records. On Gate 3, general-purpose PLCs typically lack the diagnostic coverage and architectural features that certified safety PLCs are designed around, so SFF and HFT arguments get hard to defend.

On Gate 1, manufacturer failure rate data is rarely available for non-safety PLCs, and generic database values may not match the actual hardware. The same field history that might support prior use only contributes to the failure rate argument if the facility has safety-grade failure recording, which most general-purpose PLC installations don’t. Add it up and a certified safety PLC almost always wins on total cost.

Q4: We just did all this work to use a valve under prior use, and I thought that was it. Now I need to calculate PFDavg too. Where does that data come from?

Prior use clears Gate 2 only. Gate 1 still needs failure rate data to support the PFDavg calculation. For a non-certified valve, that typically means industry databases (OREDA, Exida’s data handbook, or similar) applied to the device class. The data is generally more conservative than what an FMEDA would produce on a certified device, which is one of the practical reasons certified components ease SIL verification across all three gates simultaneously.

Q5: Our FuSa engineer says we need 2oo3 voting on this SIF instead of a single instrument, which is going to triple our hardware cost. The PFDavg calculation passes fine on a 1oo1, so why do we need 2oo3?

PFDavg and HFT are independent gates. The PFDavg calculation can pass on a 1oo1 architecture, but Gate 3 is a separate check that the architecture has enough hardware fault tolerance to be trusted at the target SIL. If the instrument’s SFF and Type combination requires HFT ≥ 1 to reach the target SIL per the Route 1H tables, a 1oo1 architecture (HFT 0) is insufficient regardless of what the PFDavg math says.

Two paths through this:

• Pick an instrument with higher SFF (typically smart, fail-safe-designed, or with stronger diagnostics) so 1oo1 clears Gate 3.
• Accept the redundancy.

The expensive smart instrument frequently beats three cheaper instruments plus the wiring, I/O, and proof-testing overhead once total cost is honest.

Q6: How do we at SIL Safe advise our clients on this topic?

Use IEC 61508-certified components wherever possible. It is the simplest path through all three gates.

Gate 1 is easier because the manufacturer provides failure rate data, and that data is typically less conservative than generic database values for the same equipment type. The FMEDA process produces a component-specific number rather than a worst-case estimate across a heterogeneous population.

Gate 2 collapses to a check that the SC rating matches the SIL.

Gate 3 collapses to a check of the architecture against what the certificate documents (route, SFF where applicable, and Type). SFF on certified components tends to be relatively high because the FMEDA process and the certification market push toward devices with strong diagnostics, which makes the table lookup more likely to clear at the target SIL.

Q7: Does the standard clearly state these three gates in those exact terms?

No. The three-gate framing for SIL verification is shorthand extracted from various clauses (11.4, 11.5, 11.9). The standard treats the requirements as separate within the design phase. The framing is a teaching device, not a quoted structure.

Further Reading

Internal:

• Layer of Protection Analysis (LOPA): The Engineer’s Guide to SIL Selection
• Hazard and Risk Analysis Methods: How HAZOP, What-If, LOPA, Risk Graph, FTA, ETA, and Bowtie Fit Together
• PFDavg Explained: 6 Essentials for Getting Started with SIL Calculations

External:

• IEC 61511-1:2016+A1:2017 — official IEC publication page
• HSE — Functional safety (BS EN 61511 reference page)
• ISA-84 Series of Standards
• The 61508 Association — Proven in Use technical guide

Closing Synthesis

SIL verification is three independent gates, all of which must pass. Most failures come from underweighting two of the three, usually because the third produces a clean number on a report. Treat them as separate checks, defend each one with its own evidence, and the verification holds up under audit.

Functional safety is complex, and the stakes are high. If you have questions about your SIS design, SIL verification, or where to start with IEC 61511, the team at SIL Safe is here to help. Reach out to us today.

That gap creates real problems. Teams default to whatever their site does and can’t articulate why, can’t recognize when the wrong tool is being used, and outgrow their methodology without realizing it. IEC 61511 requires a hazard and risk assessment (H&RA) but is method-agnostic. The choice of hazard and risk analysis methods is on you, and the right choice depends on your facility, your scenarios, and the depth of analysis your risk picture demands.

The Two Halves of Hazard and Risk Assessment

Clause 8 of IEC 61511 requires both halves of an H&RA: hazard identification and risk assessment.

Hazard identification is discovery work: what can go wrong here? The output is a list of credible scenarios with causes, consequences, and existing safeguards.

Risk assessment is evaluation work: for each identified hazard, how bad is it, how likely is it, and how much risk reduction is needed to make it tolerable? The output is a defensible determination of required risk reduction, often expressed as a Safety Integrity Level (SIL) when the reduction is allocated to a Safety Instrumented Function (SIF).

Most method confusion comes from not recognizing which half a given tool serves. HAZOP is hazard identification. LOPA is mostly risk assessment. They do different cognitive work, and they aren’t interchangeable.

Another source of confusion: some methods are treated differently by different practitioners. The same method can be identification-only at one site and identification-plus-assessment at another. This article names the common patterns, but your facility may run them differently.

Hazard Identification Methods

The hazard and risk analysis methods in this section are collectively known as Process Hazard Analysis (PHA) methods in much of industry practice. PHA usually refers to the identification activity specifically, while H&RA is the IEC 61511 phrasing for the full activity covering both halves.

HAZOP

A Hazard and Operability Study (HAZOP) is a hazard identification method by design, but in practice it often extends into risk assessment. Two patterns are worth recognizing:

• HAZOP-as-identification: the team identifies hazards, applies a risk ranking for prioritization, and hands the scenarios off to LOPA or risk graph for assessment. Cleaner pattern, dominant at larger facilities.
• HAZOP-as-everything: the team identifies hazards and uses a calibrated risk matrix to determine SIL requirements directly, with no separate risk assessment step. Common at smaller facilities and in revalidations.

The workshop mechanics are the same either way. A multidisciplinary team works node-by-node through the process, applying parameter and guideword combinations (no flow, more pressure, reverse flow) to surface deviations from design intent. HAZOP is time-intensive, depends heavily on facilitator skill, and works best on continuous processes.

What-If (Typically Run as What-If/Checklist)

What-If is a hazard identification method. A team works through the process asking open-ended what if questions and brainstorms consequences and safeguards.

In practice almost nobody runs pure What-If — the risk of missing something obvious is too high. What sites actually do is What-If/Checklist: the team brainstorms freely, then uses a backing checklist as a safety net to catch what was missed. When practitioners say “we did a What-If,” they almost always mean What-If/Checklist.

What-If/Checklist is the practical alternative to HAZOP for smaller, simpler, or batch processes. It’s accepted under major regulatory frameworks (OSHA Process Safety Management in the US, COMAH in the UK, Seveso in the EU) and is the right call for Management of Change (MOC) reviews, Pre-Startup Safety Reviews, and revalidations of well-understood operations.

Pure Checklist

Pure checklist is verification, not discovery — the team walks through a pre-built list of standard hazards or design conditions for that process type and confirms each one is addressed. It’s used for screening reviews, very simple operations, or as an MOC tool for minor changes.

Example: a process safety engineer is evaluating a proposed minor MOC. They walk through a standard checklist (does it change relief valve sizing, introduce new hazardous materials, affect classified area boundaries, touch a SIF), and the checklist confirms whether a fuller PHA review is needed.

Related but Out of Scope: FMEA and FMEDA

Failure Modes and Effects Analysis (FMEA) and Failure Modes, Effects and Diagnostic Analysis (FMEDA) don’t belong in the H&RA toolkit. Equipment-level FMEA and FMEDA belong to device certification under IEC 61508, the manufacturer’s domain, with outputs consumed by IEC 61511 users during SIS design and SIL verification. Process FMEA exists as a hazard identification method in adjacent industries (pharma, food, automotive) but isn’t standard in the process industry. Not covered further.

Risk Assessment Methods

LOPA

Layer of Protection Analysis (LOPA) is a risk assessment method. It serves the assessment half of the H&RA, but it straddles the Clause 8 / Clause 9 boundary of IEC 61511. The analytical work is risk assessment under Clause 8, while the output feeds SIL allocation under Clause 9. That dual nature is why LOPA gets described both ways depending on context.

The mechanics are semi-quantitative and scenario-based. For each scenario, the team multiplies the initiating event frequency by the probability of failure on demand of each Independent Protection Layer (IPL) credited against the scenario, then compares the residual risk to the tolerable risk criterion. Where residual risk exceeds tolerable, the gap defines the required risk reduction factor (RRF) and corresponding SIL.

LOPA is the most widely adopted risk assessment method globally, the default tool for most facilities. Its strengths are visible math, defensible documentation, and scalability across hundreds of scenarios. Its limitations are real: order-of-magnitude resolution can hide meaningful differences, and IPL crediting requires real discipline. Sloppy IPL crediting produces inflated risk reduction credit and leaves real gaps.

Risk Graph

Risk graph is a risk assessment method. A calibrated decision tree uses four parameters: consequence severity (C), frequency or exposure (F), possibility of avoidance (P), and demand rate (W). The path through the tree lands on a SIL.

Risk graph compresses risk assessment and SIL selection into a single traversal: consequence severity, exposure, avoidance, and tolerable risk comparison are all baked into the calibrated tree. It’s common in European-influenced practice, in oil & gas globally, and in machinery safety; it remains a fully legitimate IEC 61511-3 method.

Strengths: speed, no failure rate data required for IPLs, easy to teach. Limitations: calibration is everything, sensitivity is poor, qualitative judgments hide assumptions that LOPA forces explicit.

LOPA and Risk Graph Are Alternatives, Not Complements

Both methods occupy the same workflow slot: risk assessment with a SIL output. Running both on the same scenario set creates conflicting answers and an unauditable documentation trail. Sites pick one or the other as their site standard and apply it consistently.

The Quantitative Deep-Dive Methods

FTA, ETA, and bowtie are risk assessment tools, not hazard identification tools. Like LOPA and risk graph, they require an upstream identification activity to define what gets analyzed. They cannot tell you what hazards you forgot to consider.

Fault Tree Analysis (FTA)

FTA works top-down and deductively. Start with a top event and work backward through the failure combinations that produce it using Boolean logic. Logic gates (AND, OR), basic events with failure rates, and minimal cut sets give a quantified frequency for the top event.

Strengths: rigorous quantification, handles complex failure logic, identifies common cause failure (CCF) contributors. Limitation: FTA only analyzes the top event you defined. It cannot surface hazards nobody named.

Event Tree Analysis (ETA)

ETA is the structural mirror of FTA: bottom-up and inductive. Start with an initiating event and work forward through outcome paths, assigning branching probabilities at each protection layer or conditional modifier (ignition / no ignition, immediate vs. delayed, occupancy at the time).

The output is the full consequence space mapped quantitatively. Limitation: ETA is only as good as the initiating event you picked.

Bowtie Analysis: The Integrating Visual

A bowtie puts the hazardous event in the middle, with threats and causes on the left (FTA territory), consequences on the right (ETA territory), and barriers across both sides. It can be qualitative (illustrative) or quantitative (backed by FTA/ETA data).

Bowtie’s strength is communication: management, operations, and maintenance can read a bowtie even if they can’t read a fault tree. It’s also powerful for barrier management, making preventive and mitigative barriers visible together. Limitation: a bowtie is only as rigorous as the analysis behind it. A whiteboard sketch is not an H&RA.

How a Complete H&RA Comes Together

A complete H&RA combines hazard and risk analysis methods from both halves: one for identification, one for assessment. Several pairings are common in practice.

The Common Pairing: HAZOP + LOPA

HAZOP plus LOPA is the dominant H&RA pairing globally. HAZOP identifies, LOPA assesses, with a clean handoff between the two halves. The pairing extends one step beyond H&RA. LOPA’s output feeds Clause 9 SIL allocation directly.

The Alternative Pairing: HAZOP + Risk Graph

Same handoff structure, different risk assessment tool. Common in European-influenced practice. Site-wide methodology choice. Risk graph outputs a SIL directly, also feeding Clause 9 allocation.

The Quantitative Pairing: Identification + FTA/ETA + Bowtie

Reserved for high-consequence facilities or specific scenarios within an otherwise LOPA-based program. Identification can be HAZOP or another systematic method, but the upstream identification step cannot be skipped. The Common Mistakes section below walks through what happens when it is.

The Small-Facility Pattern: What-If/Checklist (or HAZOP) + Calibrated Risk Matrix

A single workshop does identification, assessment, and SIL determination using a calibrated matrix. The identification method is What-If/Checklist for smaller operations; some sites use HAZOP and run it the same way. The matrix serves double duty: both the tolerable risk reference and the SIL determination output. Common at facilities that don’t have the scenario count to justify a separate LOPA program. The matrix’s resolution caps how defensible higher-SIL determinations can be.

Why You Can’t Skip Hazard Identification

FTA and ETA both start from a known event. LOPA and risk graph both evaluate scenarios they’re given. None of them can tell you what hazards you forgot to analyze. Identification and assessment are different cognitive tasks, and skipping the identification step doesn’t reduce the rigor of the H&RA. It produces a different activity that happens to share vocabulary with one.

Common Mistakes

The mistakes below show up across all the hazard and risk analysis methods covered in this article. They’re field-grounded patterns, not generic warnings about following the standard.

1. Doing a high-quality assessment on a hazard while forgetting that not all hazards have been identified.

A specialty chemical facility decides to do a quantitative analysis on a 50,000-gallon flammable solvent tank. The team builds a rigorous fault tree on loss of containment, an event tree on ignition and consequences, and a bowtie that ties it all together. The analysis is technically excellent. A SIL is assigned to the overfill protection SIF.

Six months later, an operator opens a sample valve that sticks open. Several thousand gallons release into a containment area not designed for that volume, and an uncoordinated maintenance activity provides the ignition source. None of it was in the analysis. Nobody ever did systematic hazard identification. The team jumped straight to “tank fire” as the assumed hazard and built outward.

FTA and ETA are powerful at analyzing hazards you’ve already named. They cannot tell you what hazards you forgot to name. That’s HAZOP’s job.

2. Mixing LOPA and risk graph on the same scenario set. Two methods occupying the same workflow slot produces conflicting answers and unauditable documentation.

3. Crediting IPLs in LOPA without independence and auditability discipline. Loose IPL crediting inflates risk reduction credit and leaves real gaps. Independence, auditability, and access integrity have to be earned, not assumed.

4. Drawing a bowtie without the underlying analysis. A diagram with barriers in marker is a communication tool, not an assessment.

5. Defaulting to whatever the site has always done. Methodology should match process complexity and scenario severity, not just inherit.

6. Treating FTA and ETA as substitutes for HAZOP. They analyze hazards deeply. They don’t discover them.

Q&A

Q1. I sometimes hear PHA and sometimes H&RA. Are they the same thing?

PHA is the umbrella term most practitioners use, particularly in CCPS-influenced documentation, and usually refers to the hazard identification activity specifically. H&RA is the IEC 61511 phrasing for the full activity covering both identification and assessment. Practitioners sometimes use PHA loosely to mean the whole exercise, which is part of where the confusion comes from.

Q2. How do I know if my site is using the wrong H&RA method?

This is a hard question and often needs the judgment of experienced professionals to answer well. Some clues:

• Mismatch: a small facility running a full quantitative program for routine scenarios is using more methodology than the risk profile warrants; a complex high-consequence facility relying on a calibrated risk matrix for SIL determination is using less methodology than the risk profile warrants
• Inconsistency: scenarios assessed by different methods with no documented basis for the choice, or IPLs credited differently across similar scenarios

Q3. Can FTA and ETA satisfy IEC 61511’s H&RA requirement on their own?

No. FTA and ETA take hazardous events as a design input. The methods cannot generate the events themselves. Something upstream has to identify them, which is the work of a hazard identification method like HAZOP. Without that step, the quantitative analysis is rigorous about whatever events the team happened to think of, and silent about everything else.

Q4. Is risk graph an acceptable method, or do I have to use LOPA?

Risk graph is a fully legitimate IEC 61511-3 method. The standard does not mandate LOPA. The right choice depends on facility context. Risk graph is common in European-influenced practice, oil & gas globally, and machinery safety; LOPA dominates in many regulatory contexts, particularly under PSM/RMP. What’s not acceptable is mixing the two on the same scenario set.

Q5. My boss says HAZOP takes too many people for too many days and costs too much. Why can’t we just do a What-If/Checklist?

Sometimes you can. What-If/Checklist is a legitimate hazard identification method, accepted under OSHA PSM, COMAH, Seveso, and similar frameworks. It’s the right tool for smaller, simpler, or batch processes, for MOC reviews, and for revalidations of well-understood operations. The choice should be based on process complexity and consequence severity, not on cost alone. Cost is a real factor, and not every scope warrants a full HAZOP. As process complexity, scenario count, or consequence severity increase, the cost-benefit shifts back toward HAZOP. Using What-If/Checklist on a scope that genuinely needs HAZOP is how facilities miss hazards that come back to bite them later.

Q6. Where does LOPA actually sit in the IEC 61511 life-cycle, Clause 8 or Clause 9?

Both. The analytical work is risk assessment under Clause 8. The output (required risk reduction expressed as a SIL) is consumed by Clause 9 for protection layer allocation. LOPA spans the boundary, which is why it’s described both as an H&RA method and a SIL determination method.

Q7. Do I need a bowtie for every hazardous event?

No. Bowtie is most valuable for high-consequence scenarios where barrier management and stakeholder communication justify the effort. For routine scenarios handled in a HAZOP and LOPA workflow, a bowtie adds little beyond what the LOPA worksheet documents.

Further Reading

• SIL Safe: Hazard and Risk Assessment (H&RA): The Foundation of Functional Safety
• SIL Safe: Layer of Protection Analysis (LOPA): The Engineer’s Guide to SIL Selection
• IEC 61511-3:2016: informative annex on risk assessment methods
• CCPS, Guidelines for Hazard Evaluation Procedures, 3rd Edition
• CCPS, Layer of Protection Analysis: Simplified Process Risk Assessment
• OSHA PSM 29 CFR 1910.119: PHA requirements for US-regulated facilities (paragraph (e))
• HSE COMAH guidance: UK regulatory framework for major accident hazards

Functional safety is complex, and the stakes are high. If you have questions about your SIS design, SIL verification, or where to start with IEC 61511-1, the team at SIL Safe is here to help. Reach out to us today.

LOPA can be conducted as a semi-quantitative or quantitative analysis. The vast majority of LOPA studies — roughly 80% — are semi-quantitative.

LOPA Key Terms

These terms appear throughout every LOPA study — precision matters.

Initiating event — the specific failure or error that starts the hazard sequence, such as a pump trip, a valve failing open, or an operator error.

Independent protection layer (IPL) — a safeguard capable of preventing the hazard from escalating to a consequence, provided it meets all four criteria: specific, independent, dependable, and auditable.

Risk reduction factor (RRF) — a measure of how much a protection layer reduces risk. An IPL with an RRF of 100 prevents the hazardous outcome on 99 out of 100 demands. RRF and probability of failure on demand (PFDavg) are inverses: RRF = 1 / PFDavg.

Tolerable risk — the maximum frequency of a hazardous event the facility has determined is acceptable. LOPA compares mitigated event frequency against this threshold.

Additional terms specific to quantitative LOPA are introduced later in this article.

How a LOPA Scenario Works

LOPA determines how much risk reduction is needed for each specific hazard scenario — not a facility-wide number. Each scenario is analyzed individually, which is what makes LOPA more rigorous than a risk graph or qualitative approach. The structure is simple: one initiating event, one consequence. That narrow scope is intentional.

The core equation is:

Mitigated Event Frequency = Initiating Event Frequency × (PFD of IPL-1) × (PFD of IPL-2) × … × modifiers

The mitigated event frequency is compared to the facility’s tolerable risk threshold. If the mitigated frequency falls below the target, no additional protection is needed. If a gap remains, the required RRF is calculated and a SIL target assigned to close it. LOPA establishes the target — it does not calculate whether the SIS design achieves it. That is the job of SIL verification, which comes later in the life-cycle.

LOPA was formalized by the Center for Chemical Process Safety (CCPS) in their 2001 book Layer of Protection Analysis: Simplified Process Risk Assessment. IEC 61511-3, Annex F (informative) incorporates it as a recognized semi-quantitative method within the standard.

Initiating Events

Before evaluating whether safeguards are sufficient, a credible frequency for the initiating event is needed. Typical frequencies used in semi-quantitative LOPA:

• Control valve fails open or closed: 1E-1 per year
• Pump trip (loss of flow): 1E-1 per year
• Operator error on a routine task: 1E-2 per year
• Cooling water failure: 1E-1 per year
• Small bore pipe rupture: 1E-3 per year

These are starting points. Facility-specific data and operating history should inform what is reasonable for a given site.

One important point: the basic process control system (BPCS) can itself be the initiating event. If a BPCS pressure control loop failure causes an overpressure scenario, that same loop cannot be claimed as an IPL for that scenario — it is not independent of the cause.

Independent Protection Layers (IPLs)

To qualify as an IPL, a safeguard must satisfy all four criteria — and all four means all four:

• Specific — capable of preventing the specific consequence being analyzed
• Independent — functions independently of the initiating event and of other IPLs claimed in the same scenario
• Dependable — performs with the reliability assumed in the analysis
• Auditable — supported by documentation proving it exists, works, and is maintained

Common IPL types and typical risk reduction credit in semi-quantitative LOPA:

• BPCS control loop: RRF of 10
• Operator response to alarm: RRF of 10, with sufficient response time and documented procedures
• Pressure safety valve (PSV): RRF of 10 to 100, depending on sizing and testing for the specific scenario
• Safety instrumented function (SIF): RRF varies by SIL — this is what LOPA is sizing

The BPCS as an IPL: why RRF 10 is the limit

The cap of RRF 10 for a BPCS loop is based on real-world data. A control loop has many ways to fail beyond the primary sensing element — control valve degradation, signal wiring faults, software changes, maintenance errors, the loop being placed in manual. When all failure modes across the full loop are accounted for, historical plant data consistently supports an RRF of 10 as a reasonable and defensible credit. Claiming more is not supported by what facilities actually see in the field.

What disqualifies a safeguard

• A high-level alarm tied to the same transmitter as the control loop that caused the initiating event — fails independence
• A spare pump with no documented proof test procedure — fails dependability and auditability
• An operator response procedure requiring 45 minutes when the scenario allows 20 minutes — fails specificity

Enabling Conditions and Conditional Modifiers

Enabling conditions and conditional modifiers can legitimately reduce the calculated demand frequency or consequence likelihood in a LOPA scenario. An enabling condition is something that must be present for the consequence to occur but does not itself cause the initiating event — the presence of an ignition source, or a person in the hazard zone. A conditional modifier is a probability factor applied to account for conditions that affect whether the initiating event leads to the full consequence, such as probability of ignition or occupancy probability.

In semi-quantitative LOPA, these are typically embedded in the initiating event frequency or handled with conservative round numbers. The risk of abuse is real: stacking multiple modifiers without documented evidence produces an analysis that is optimistic rather than conservative.

Semi-Quantitative vs. Quantitative LOPA

Semi-quantitative LOPA uses order-of-magnitude estimates for initiating event frequencies and IPL PFD values, drawn from standardized tables rather than facility-specific reliability data. It is conservative by design and appropriate for the data quality available at most facilities.

Quantitative LOPA assigns precise numerical values to each input and applies conditional modifiers explicitly as documented multipliers. The following terms are specific to quantitative LOPA and are unlikely to appear on a standard semi-quantitative worksheet:

• Implicit vs. explicit modifiers — a modifier is implicit when its effect is already embedded in the source data; explicit when it is a named, separate multiplier on the worksheet
• Operational factor — the fraction of time the process is running in the hazardous state (e.g., a unit running 6 months per year applies a factor of 0.5 to the initiating event frequency)
• Use factor / occupancy factor — the fraction of time a person is present in the hazard zone, used to probability-weight a consequence

Mixing the two approaches is a common mistake — applying precise numerical modifiers in an otherwise semi-quantitative study creates false precision and can produce unconservative results. A future article will cover quantitative LOPA in depth.

Where LOPA Fits in the IEC 61511 Safety Life-Cycle

IEC 61511 requires a documented, defensible basis for every SIL target. Layer of protection analysis is how most facilities satisfy that requirement. The standard does not mandate LOPA specifically — several methods are acceptable — but LOPA dominates in practice.

Note that where LOPA sits can confuse practitioners as it is at the boundary between two phases of the IEC 61511 life-cycle. The scenario evaluation, IPL crediting, and risk gap calculation are Clause 8 risk H&RA (specifically on the “A” side), while the resulting required risk reduction is consumed by Clause 9 when that risk reduction is allocated to a SIF and the SIL is assigned.

What Comes Before: The “H” of the H&RA

The hazard and risk assessment (H&RA) is a mandatory IEC 61511 life-cycle activity. The HAZOP (Hazard and Operability Study) is the most common method used to carry it out the “H” portion. The term process hazard analysis (PHA) refers to the same concept in OSHA PSM and EPA RMP contexts. The H&RA identifies hazard scenarios, defines consequences, and establishes unmitigated risk. LOPA does not re-identify hazards (the “H” term); it takes the HAZOP output and determines whether existing protection is sufficient.

HAZOP and LOPA are often conducted together in the same study or meeting, and some facilities call the entire exercise a “HAZOP” even when LOPA is embedded within it. If a study only lists safeguards without comparing them to a tolerable risk threshold, it is a HAZOP — not a LOPA, regardless of what it was called.

What Comes After: SIS Design Begins

The SIL target produced by LOPA is the starting point for SIS design. From there, engineers move into the full design process — developing the safety requirements specification (SRS), working through conceptual and detailed design, selecting equipment, performing SIL verification, and ultimately installing and validating the system. PFDavg calculations, spurious trip rate (STR) analysis, proof test interval (TI) optimization, and common cause failure (CCF) evaluation are all part of that design and verification work. LOPA hands off a SIL target; everything that follows is about proving the design meets it.

A note on ALARP: LOPA establishes the minimum required risk reduction. As low as reasonably practicable (ALARP) is a separate obligation that asks whether risk can be reduced further at a reasonable cost — it is not a basis for doing less than LOPA requires. Facilities subject to ALARP obligations should treat LOPA output as the starting point, not the conclusion.

Other SIL Selection Methods — and Why LOPA Dominates

IEC 61511 accepts several SIL selection methods. The right choice depends on the facility, available data, and scenario complexity.

Risk graph — a parameter-based method that works through structured questions about consequence severity, occupancy, avoidability, and demand rate to arrive at a SIL target. Used in some sectors and regulatory contexts; works well when properly calibrated to the facility’s risk tolerance.

Fault tree analysis (FTA) / quantitative risk analysis (QRA) — the most rigorous end of the spectrum. Appropriate when consequence modeling is required (toxic dispersion, blast overpressure) or when regulatory requirements demand precise probabilistic treatment.

LOPA dominates because it fills the practical gap between a qualitative approach and a full QRA — rigorous enough to be defensible, practical enough to execute without a specialized modeling team. That said, a risk graph may serve better when a facility has built its procedure around one and knows how to use it well, and a full QRA may be necessary when consequence modeling is non-negotiable.

LOPA in Practice — Two Examples

Setting the Scene

The facility is a mid-size natural gas processing plant subject to OSHA PSM. It processes raw natural gas to remove liquids, water, and acid gases (H₂S and CO₂) before pipeline delivery. Both examples are set in the amine treating unit — a section of the plant that uses a liquid amine solution to absorb H₂S from the gas stream through direct gas-liquid contact.

The facility’s tolerable risk criteria:

• Potential single fatality: 1E-4 per year
• Potential multiple fatalities: 1E-5 per year

Example 1: Existing Safeguards Are Sufficient — No SIF Required

Scenario

The gas-liquid contact vessel in the amine treating unit operates at elevated pressure. A control valve failing open on the high-pressure gas inlet could allow pressure to build beyond the normal operating range, leading to a flange leak or seal failure and H₂S release near the unit. Consequence: potential single fatality.

Initiating event: Control valve fails open — 1E-1 per year

Tolerable risk target: 1E-4 per year (single fatality)

Required RRF before IPLs: 1E-1 / 1E-4 = 1,000

IPL evaluation

IPL 1 — BPCS pressure control loop The BPCS loop is independent of the failed inlet valve. Functional, tested, and documented. Credit: RRF = 10

IPL 2 — High-pressure alarm with operator response The alarm activates at 110% of normal operating pressure on a separate transmitter. The operator has a documented response procedure and approximately 25 minutes to respond before a credible consequence — sufficient for trained response. Credit: RRF = 10

IPL 3 — Pressure safety valve The PSV is sized for the credible overpressure load from this specific scenario, including the valve fail-open case. Bench tested annually with documentation on file. Credit: RRF = 100

Mitigated event frequency

1E-1 × (1/10) × (1/10) × (1/100) = 1E-5 per year

Achieved RRF = 1E-1 / 1E-5 = 10,000

Result: The mitigated event frequency of 1E-5 per year is below the tolerable risk target of 1E-4 per year for a single fatality event. No SIF is required.

Example 2: Existing Safeguards Fall Short — SIL 2 SIF Required

Scenario

The amine regenerator column — the vessel that thermally strips H₂S from the amine solution for reuse — operates at elevated temperature. Loss of cooling water to the overhead condenser allows column pressure to rise. If pressure exceeds the column design rating, a catastrophic release of hot amine and H₂S-bearing vapor is possible. Consequence: potential multiple fatalities.

Initiating event: Cooling water failure — 1E-2 per year

Tolerable risk target: 1E-5 per year (multiple fatalities)

Required RRF before IPLs: 1E-2 / 1E-5 = 1,000

IPL evaluation

IPL 1 — BPCS pressure control loop The BPCS loop is independent of the cooling water failure. Functional, tested, and documented. Credit: RRF = 10

Candidate IPL — High-pressure alarm with operator response A high-pressure alarm is present. However, the response procedure requires approximately 18 minutes to complete, and the time available from alarm to potential consequence — based on process dynamics — is 12 minutes. The response time does not fit the scenario. This safeguard does not qualify as an IPL.

Candidate IPL — Pressure safety valve A PSV is installed on the column but was sized for a blocked outlet case. Documentation confirming adequacy for the loss-of-cooling scenario is not available. This safeguard does not qualify as an IPL for this scenario as evaluated.

Mitigated event frequency

1E-2 × (1/10) = 1E-3 per year

Achieved RRF = 1E-2 / 1E-3 = 10

Gap analysis

Required RRF: 1,000 | Achieved RRF: 10 | Remaining gap: RRF of 100

An RRF of 100 falls within the SIL 2 range (RRF 100 to 1,000). A SIL 2 SIF is required.

Result: The mitigated event frequency of 1E-3 per year does not meet the tolerable risk target of 1E-5 per year for a multiple fatality event. Existing safeguards are insufficient. The LOPA identifies a SIL 2 SIF as the minimum required protection layer.

This example also surfaces two recommendations: confirm whether the operator response procedure can be shortened — if the time gap closes, that safeguard may qualify as an IPL and reduce the SIL requirement. And confirm PSV sizing for this specific relief scenario — if adequate, it may also qualify as an IPL.

Common LOPA Mistakes

Claiming IPL credit for untested or undocumented safeguards. If there is no proof test record and no written procedure, the safeguard fails the auditable criterion. No documentation means no credit, regardless of whether the safeguard is functioning.

Double-counting BPCS-based safeguards. A BPCS pressure control loop and a BPCS high-pressure alarm on the same transmitter are not two independent IPLs. Independence means independence all the way through — sensing element, signal path, and control action.

Misidentifying available operator response time. Response time in LOPA is the window between alarm activation and the point at which the consequence becomes unavoidable — not the total time available to complete a recovery procedure, and not the time from process deviation to alarm.

Failing to evaluate IPL validity for each initiating event independently. An IPL that qualifies for one scenario may not qualify for another — this check must be done scenario by scenario, not at the system level. More critically, an IPL’s own failure mode can itself become an initiating event on a different accident path, a cross-scenario interaction that is easy to miss.

Mixing semi-quantitative and quantitative practices. Applying precise numerical modifiers — occupancy factors, operational factors — in an otherwise semi-quantitative study creates false precision. If the data doesn’t support the specificity, the result can be unconservative.

Not revisiting LOPA when the process changes. This is fundamentally a management of change (MOC) failure. Changes to operating conditions, throughput, equipment, or chemicals can invalidate initiating event frequencies and IPL credits — but if LOPA isn’t triggered as part of the MOC review, those changes go unexamined. LOPA is a point-in-time analysis. The MOC process is what keeps it current.

LOPA Q&A

Why do some facilities call it a HAZOP when they’re also doing LOPA?

Two reasons. First, a HAZOP itself is treated slightly differently between facilities, some facilities go beyond the identification (the “H”) and do assessment activities. It is not a consistent term.

Second, because the two processes are often conducted together and many facilities never distinguished them in their terminology. A HAZOP team identifies scenarios and then — sometimes in the same meeting — evaluates whether safeguards are sufficient using LOPA methodology. The distinction matters because the two produce different outputs. A HAZOP identifies and characterizes scenarios; LOPA evaluates whether those scenarios require a SIF and at what SIL.

I don’t see conditional modifiers on my LOPA worksheet. Does that mean something is wrong?

Not necessarily. In semi-quantitative LOPA, conditional modifiers are often implicit — their effect is already embedded in the initiating event frequencies or consequence categories being used, so they don’t appear as separate columns. In quantitative LOPA, these factors are explicit: each one is named, assigned a specific probability value, and multiplied through the calculation.

Are there situations where LOPA is not the right choice?

In a few specific situations, another method is the better fit. For scenarios requiring consequence modeling — toxic dispersion, blast overpressure — LOPA doesn’t do that work; a full quantitative risk analysis (QRA) is needed. For highly complex scenarios with multiple interacting causes or common-cause dependencies, fault tree analysis can give a more accurate picture than LOPA’s simplified scenario structure. And for facilities where a risk graph has been well-calibrated and the team knows how to use it, that method may be entirely appropriate. The method should match the facility and the problem.

Can an IPL be claimed for more than one scenario?

Yes, but each claim must be evaluated independently. A PSV that qualifies as an IPL for a blocked outlet overpressure scenario may or may not qualify for a fire case. The specificity criterion must be satisfied for every scenario in which an IPL is claimed.

Does LOPA apply to continuous mode SIFs?

Standard LOPA methodology is designed for low-demand mode SIFs — functions called upon infrequently where PFDavg is the relevant performance measure. Continuous mode SIFs use probability of failure per hour (PFH) rather than PFDavg. Quantitative LOPA can be adapted for continuous mode by adjusting the variable in the calculation.

Further Reading

External Links

Internal — related articles on this site:

• The Garden Grove Chemical Incident: What We Know So Far

• CCPS Layer of Protection Analysis: Simplified Process Risk Assessment (2001) — aiche.org
• IEC 61511-3 Annex F — iec.ch
• University of Michigan Chemical Engineering – Layers of Protection
• Wikipedia article Layer of Protection Analysis
• Sphera – What is the Difference Between PHA, HAZOP, & LOPA
• Mary Kay O’Connor Process Safety Center – On the Use of LOPA and Risk Graphs for SIL Determination

Functional safety is complex, and the stakes are high. If you have questions about your SIS design, SIL verification, or where to start with IEC 61511-1, the team at SIL Safe is here to help. Reach out to us today.

What Is a Hazard & Risk Assessment (H&RA)?

A hazard is a physical situation with the potential to cause harm. A risk is what you get when you combine two things: the probability that the hazard leads to a harmful event, and the severity of the consequences. Risk is never just one of those dimensions. A high-severity outcome with negligible probability may be entirely tolerable. A low-severity outcome that happens constantly may not be. Both dimensions must be assessed together — always.

The H&RA is the structured process of identifying hazards, evaluating the associated risks, and determining whether those risks are tolerable. It is the foundation of the functional safety life-cycle — the end-to-end engineering process defined in IEC 61511 that governs how Safety Instrumented Systems are designed, implemented, operated, and maintained. Without the H&RA, there is no technical basis for any of what follows.

A note on terminology — you will encounter several names and acronyms for this activity depending on the standard or industry context:

• H&RA (Hazard and Risk Assessment) — the term used in IEC 61511
• HRA and HARA — also widely used within the functional safety community; same activity, different shorthand
• PHA (Process Hazard Analysis) — the equivalent term under the OSHA PSM regulation (29 CFR 1910.119) and the EPA RMP regulation; same concept, different regulatory language
• Other safety disciplines — machinery safety, for example — may use different terms again

The variation is mostly regulatory and organizational preference. The underlying activity is the same.

When a Hazard and Risk Assessment Fits in the IEC 61511 Safety Life-Cycle

A hazard and risk assessment must be conducted early in the safety life-cycle — specifically under Clause 8 — before SIS design begins.

The accepted practice is to conduct the H&RA when the P&IDs (Piping and Instrumentation Diagrams) are at Rev 0 — the point at which the process design is sufficiently defined to support a meaningful hazard study, but not so advanced that changes identified during the study become costly or impractical to implement. Too early and the hazard picture is incomplete; too late and the window to influence design has closed.

A poorly timed H&RA compounds every problem that follows.

Key Steps in Conducting an H&RA

The H&RA is not a single task — it is a structured sequence of activities. The order matters.

Step 1 – Determine tolerable risk. Before you can assess whether any risk is acceptable, you need to define what “acceptable” means for your organization. This benchmark must be established first. It governs every risk judgment that follows. (See the next section for details.)

Step 2 – Define the scope and boundaries. What process units, equipment, and operating modes are included in this H&RA? Scope creep and scope gaps are both problems. A clearly documented boundary prevents both.

Step 3 – Identify hazards. What physical situations exist that have the potential to cause harm? This is where the structured identification methodology — HAZOP, What-If, or similar — is applied.

Step 4 – Identify hazardous events and demand scenarios. A hazard becomes a hazardous event when a specific initiating cause triggers it — the conditions under which a safety function would be called upon to act.

Step 5 – Assess consequences. For each hazardous event, what is the worst credible outcome? Consequences are typically assessed in terms of harm to people, environmental impact, and asset damage.

Step 6 – Assess likelihood/frequency. How often is the hazardous event expected to occur, without any protection layers in place? This is the unmitigated or inherent demand rate.

Step 7 – Identify the risk gap. With both consequence severity and likelihood established, the assessed risk can be compared against the tolerable risk criteria and the calibrated risk matrix. Where the assessed risk exceeds tolerable risk, a gap exists. That gap is the direct trigger for a SIS.

Determining Tolerable Risk — The Foundation of Step 1

Under IEC 61511, tolerable risk is the level of risk accepted in a given context based on the current values of society. It is not zero risk — every industrial process carries some inherent risk, and the goal of IEC 61511 is to ensure that risk is identified, evaluated, and reduced to a tolerable level, not eliminated entirely. The instinct to demand “no risk” is understandable but neither achievable nor the intent of the standard.

Tolerable risk criteria must be documented — a specific IEC 61511 requirement and a common gap at smaller PSM and RMP facilities. Without documented criteria, every risk judgment becomes too subjective and the study loses its technical defensibility.

A calibrated risk matrix is the standard tool for establishing and communicating tolerable risk criteria. It is a specific type of risk matrix in which the axis boundaries are anchored to actual numerical frequency and consequence values — not vague qualitative descriptors like “frequent” or “catastrophic.” Calibration reduces subjectivity as much as possible, improves consistency across the study, and makes the risk criteria defensible under regulatory or third-party scrutiny. Larger organizations and multi-site facilities often maintain multiple calibrated risk matrices — one for each consequence category or tailored to specific process units. The PEAR Model, discussed further in the Related Topics section, provides a useful framework for structuring those consequence categories.

The Risk Gap and the Case for a SIS

The risk gap is the difference between the unmitigated risk of a hazardous event and the tolerable risk threshold. When a gap exists — when the assessed risk exceeds what is tolerable — a protection layer is required.

Protection layers can take many forms:

• Inherently safer design
• Basic process control
• Physical relief devices
• Operator response
• Safety Instrumented Functions (SIFs)

When a hazard cannot be reduced to a tolerable level through other means, it requires a Safety Instrumented Function (SIF) — a specific automated safety action that brings the process to a safe state in response to a defined demand. A process will typically have multiple hazards that each require their own SIF. All of those SIFs together constitute the Safety Instrumented System (SIS) — the SIS does not exist independently of the SIFs that define it; it is the sum of them.

This is why the hazard and risk assessment is the primary input to SIS design. Without it, there is no basis for knowing which SIFs are needed or what they must do. The H&RA outputs flow directly into other life-cycle documents, such as the Safety Requirements Specification (SRS).

The Link Between H&RA and SIL Determination

Identifying that a SIF is needed is only the first step. The H&RA provides the information that a SIL allocation is required — the size and nature of the risk gap determines how much risk reduction each SIF must deliver.

Safety Integrity Level (SIL) is a discrete measure of the required risk reduction performance of a SIF. IEC 61511 defines three SIL levels for the process sector — SIL 1, SIL 2, and SIL 3 — each representing an order-of-magnitude increase in performance. The required SIL is determined by the size of the risk gap: the larger the gap, the higher the SIL required to close it.

Layer of Protection Analysis (LOPA) is the most widely used SIL determination methodology in the process industry. Note though that where LOPA sits can confuse practitioners as it is at the boundary between two phases of the IEC 61511 life-cycle. The scenario evaluation, IPL crediting, and risk gap calculation are Clause 8 risk H&RA (specifically on the “A” side of that), while the resulting required risk reduction is consumed by Clause 9 when that risk reduction is allocated to a SIF and the SIL is assigned.

H&RA Methodologies

IEC 61511 does not prescribe a specific H&RA methodology. The right choice depends on process complexity, the stage of design, available data, and the level of rigor required. What the standard does require is that the methodology is appropriate and applied systematically.

All H&RA methodologies fall into one of three umbrella categories:

Qualitative — judgment-based and descriptive. No numerical failure frequencies or consequence magnitudes are required. The output is a structured list of hazards, causes, consequences, and existing safeguards. Qualitative methods are the most widely used in the process industry for H&RA purposes.

Semi-quantitative — structured scoring or ranking. Numbers are used to characterize risk, but a full probabilistic analysis is not performed. The output provides more consistency and defensibility than a purely qualitative approach.

Quantitative — numerical frequency and consequence analysis with full probabilistic treatment. The output is a calculated risk value that can be compared directly against a numerical tolerable risk criterion.

Qualitative Methods

HAZID (Hazard Identification Study) is an upstream screening tool used to identify major hazards early in a project, before detailed design is available. It is typically applied at the conceptual or FEED stage and is less structured than a HAZOP. The primary reference standard is ISO 17776.

HAZOP (Hazard and Operability Study) is the dominant H&RA methodology in the process industry. It uses a systematic, guide-word-driven approach applied by a multi-disciplinary team to identify deviations from design intent and evaluate their causes and consequences. HAZOP produces a structured, auditable record that serves as the primary H&RA documentation. The governing standard is IEC 61882.

What-If Analysis is a less formal brainstorming technique useful for simpler processes, preliminary reviews, or as a supplement to a more structured study.

FMEA (Failure Mode and Effects Analysis) examines individual components to identify failure modes and their system-level effects. It is a bottom-up analysis most commonly used in equipment-focused assessments.

Semi-Quantitative Methods

Risk Graph is a structured method that uses defined parameters — consequence severity, occupancy, probability of avoiding harm, and demand rate — to assign a SIL target. It is widely used as an initial SIL targeting tool where a full LOPA is not warranted.

Quantitative Methods

Event Tree Analysis (ETA) models the sequences of events following an initiating cause, branching at each point where a safety barrier succeeds or fails. It is used to quantify outcome frequencies and is commonly paired with fault tree analysis in broader QRA work.

Quantitative Risk Analysis (QRA) is a formal methodology combining frequency analysis and consequence modeling to produce a quantified risk picture — typically expressed as individual risk contours or F-N curves. QRA draws on ETA, fault tree analysis, and dispersion analysis as inputs and is the most rigorous and resource-intensive approach.

FMEDA (Failure Mode, Effects and Diagnostic Analysis) is primarily a manufacturer and device certification tool conducted against IEC 61508. It produces quantitative failure rate data — including dangerous undetected failure rate and diagnostic coverage — that process facilities consume from equipment supplier safety manuals rather than generating themselves.

Related Topics and Tools

Bow-Tie Analysis places the top event at the center, with threat pathways on the left and consequence pathways on the right. Barriers appear on both sides. Bow-tie diagrams are effective for communicating H&RA outputs to management, regulators, and operating teams.

Fault Tree Analysis (FTA) is a top-down tool that works backward from an undesired top event to identify the combinations of failures that could cause it. FTA can be used qualitatively as a logic map or quantitatively with failure rate data. It is often paired with ETA in QRA studies.

Dispersion Analysis models the physical spread of a hazardous material release — gas cloud, toxic plume, or flammable vapor — to quantify the geographic extent and frequency of harm. It is a quantitative calculation that supports consequence assessment and is an essential input to QRA at facilities handling hazardous materials.

The PEAR Model structures consequence assessment around four dimensions: People, Environment, Assets, and Reputation. It is particularly relevant where tolerable risk criteria extend beyond personnel safety — and in practice, many facilities maintain a separate calibrated risk matrix for each PEAR dimension.

Hazardous Area Classification is a discipline that should be completed prior to the H&RA. The already-established hazardous areas (or zones) can serve as an independent protection layer and may be credited as such during the risk assessment process.

Security Risk Assessment (SRA) is a parallel requirement under IEC 61511 Clause 8 — the same clause that governs the H&RA. Where the H&RA addresses process hazards, the SRA addresses intentional threats and cybersecurity vulnerabilities to the SIS. Both are required to meet full Clause 8 obligations.

Common Mistakes and Pitfalls

Timing it wrong. Too early and the hazard picture is incomplete; too late and design changes to address identified hazards may already be impractical. The H&RA should be conducted when the P&IDs are at Rev 0.

No documented tolerable risk criteria. Without a defined, documented calibrated risk matrix, every risk judgment in the study is a personal opinion — and the study cannot be defended or verified by a third party.

Poorly defined hazardous events. Vague events produce incorrect consequence and frequency assessments, which produce incorrect risk gap calculations. Each hazardous event needs a defined initiating cause, affected equipment, and demand scenario.

Ignoring human factors and demand rates. Human error is a significant source of SIF demand. Underestimating it produces an overly optimistic risk picture and may result in incorrect SIL targets.

Treating the H&RA as a one-time exercise. The H&RA is a living document. When the process changes, it must be reviewed and updated.

Confusing inherent risk with residual risk. Inherent risk is assessed before protection layers. Residual risk is what remains after. Conflating the two leads to incorrect safeguard crediting and inaccurate risk gap calculations.

Keeping Your Hazard and Risk Assessment Current (Management of Change)

IEC 61511 is explicit: the H&RA must be reviewed whenever changes occur that could affect its validity. Triggers include process modifications, near misses, new or modified equipment, regulatory updates, and periodic revalidation obligations under the safety life-cycle. A formal Management of Change (MOC) process that flags these triggers is the most reliable way to keep the H&RA aligned with the actual process.

Frequently Asked Questions

Q1: I keep hearing different terms — PHA, HARA, HRA, H&RA. Are these all the same thing?

H&RA, HRA, and HARA all refer to the same IEC 61511 activity. Process Hazard Analysis (PHA) is the equivalent term under the OSHA PSM and EPA RMP regulations — different regulatory language, same concept. Other safety disciplines, such as machinery safety, may use different terms again — it can be a bit confusing.

Q2: I’ve heard that LOPA and HAZOP are often done together in the same study. Is that correct, and if so, how does that work?

Yes — many organizations run HAZOP and LOPA back-to-back in the same workshop series for efficiency, completing the HAZOP for each node before immediately running the LOPA on the identified scenarios. They remain technically distinct activities: HAZOP is the “H” of the H&RA. LOPA is the “A” + SIL determination (thus a LOPA straddles two lifecycle phases). Combining the workshops is a logistical choice, not a technical one. Most tools now are setup for that purpose.

Q3: Is HAZOP the standard way to conduct an H&RA in the process industry?

In practice, yes — HAZOP is the de facto H&RA methodology for most process facilities operating under IEC 61511, ISA 84, PSM, and RMP. That said, IEC 61511 does not mandate it; other methodologies such as What-If or QRA are appropriate depending on the project stage and complexity.

Q4: Does IEC 61511 require a specific H&RA methodology?

No — IEC 61511 requires that an appropriate methodology is applied systematically, but does not mandate a specific one. HAZOP is the most common choice in the process sector, but What-If and other approaches are all valid depending on the context.

Q5: What is the difference between inherent risk and residual risk?

Inherent risk is the risk before any protection layers are applied. Residual risk is what remains after all protection layers — including the SIS — have been credited.

Q6: Who should be involved in conducting an H&RA?

An H&RA is a multi-disciplinary team activity requiring input from process, operations, instrumentation, and safety disciplines at a minimum — these can be multi-day affairs, painful, particularly when LOPA is run back-to-back with the HAZOP. IEC 61511 requires that at least one team member holds functional safety competence; this role is often referred to in practice as the Team Leader or HAZOP Leader.

Q7: How often does an H&RA need to be revalidated?

IEC 61511 requires H&RA review whenever changes occur that could affect its validity — process modifications, near misses, new equipment, or regulatory changes. Periodic revalidation is also required as part of the broader safety life-cycle review obligations.

Further Reading

Internal — related articles on this site:

• What is Functional Safety?
• Proof Testing and Management of Change
• Stated Risk vs. Revealed Risk
• SIL Safe Glossary – H&RA Terms
• Hazard and Risk Analysis Methods — How They Fit Together
• HAZOP — A Deep Dive – coming soon
• Layer of Protection Analysis (LOPA): The Engineer’s Guide to SIL Selection
• The Garden Grove Chemical Incident: What We Know So Far
• Functional Safety Is Not the Same as Occupational Safety

External authoritative references:

• ISA — ISA 84 / IEC 61511 resources
• IEC — IEC 61511 standard
• OSHA — Process Safety Management regulation (29 CFR 1910.119)
• EPA — Risk Management Program (RMP)

Conclusion

A hazard and risk assessment is not a compliance checkbox. It is the technical foundation on which every downstream SIS decision is built — from SIF definition to SIL determination to verification. A well-conducted H&RA, performed at the appropriate time, gives you a defensible, documented basis for your safety case. A poor one — or one conducted too early or too late — leaves your entire SIS design without a credible technical basis.

For facilities operating under IEC 61511, PSM, or RMP, the message is straightforward: invest in getting the H&RA right, time it correctly, and make sure it is conducted by people who understand both the process and the standard.

Functional safety is complex, and the stakes are high. If you have questions about your SIS design, SIL verification, or where to start with IEC 61511, the team at SIL Safe is here to help. Reach out to us today.

Functional safety is the engineering discipline that is about making sure that when something goes wrong, the systems intended to protect people and the environment work when they are needed.

A simple illustration helps.

Over roughly 20 years, I have had about six driver’s side window regulators fail. Annoying—but not dangerous.  If the window is used about three times per week, that’s roughly 3,120 operations. Six failures over that period corresponds to a probability of failure of about 1.92E-3 per demand.  Is this acceptable?  It has been annoying for me, but never once was a safety issue.  It also was not a cost risk for the manufacturer since they all failed post-warranty.  Now, imagine the regulator is a life safety device, that failure rate would be too high.  Functional safety is the program that takes that failure rate and lowers it multiple orders of magnitude, to perhaps 1.92E-5.  One cannot do that by building a “better” regulator.  You can get there, but it would be via a layer of controls throughout the lifecycle of the regulator.

Driving failure probabilities down by orders of magnitude is the core driver of functional safety. It is not achieved by a single “better” device. It requires coordinated engineering: design choices, architecture, testing, diagnostics, maintenance, and governance across the life of the system.  In the process industry, this structured approach is most commonly defined and implemented through IEC 61511, which provides the framework for how functional safety is applied across the lifecycle of a facility.

Functional safety is implemented through active protection functions that span the full loop—sensor, logic solver, and final element. When a hazardous condition is detected, this chain must act correctly to move the process to a safe state, whether that means closing a valve, stopping a motor, or isolating energy.

Just as important, that performance has to hold over time. Functional safety is not about working once—it is about continuing to meet required performance over years of operation, testing, maintenance, and change.

Why Functional Safety is Applied in the Process Industry

Consider a reactor that begins to over‑pressurize.

If nothing intervenes, the vessel could rupture, leading to injury, environmental release, or significant damage. Operators may not respond in time. Standard control systems can help, but systems designed for normal control are typically not sufficient for safety-critical action when consequences are severe.

A system that fails 1% of the time may be acceptable for control. It is often unacceptable for protection.

Functional safety via IEC 61511 is applied to reduce the probability that the protection fails when it is needed, thus making the process move to a safe state under abnormal conditions.

What Is Functional Safety?

Functional safety is an engineering discipline that ensures safety‑significant functions perform correctly when required. It is not a single device, calculation, or tool. It is a structured approach to designing, implementing, and managing systems so that their performance is sufficiently reliable for the hazards they control.

The core concept to understand is risk.  A process will have hazards (such as a tank rupture) and that hazard has an associated level of risk.  Risk is always the combination of probability and severity.

Functional safety contributes to risk reduction by lowering the probability that a hazardous outcome occurs and, in some designs, by limiting its severity.

How Functional Safety Reduces Risk

Every facility has hazards. But before the hazards are evaluated, the facility needs to determine what risks are acceptable.  This is an odd concept for people new to process safety because one has to decide what is an acceptable amount of death or injury.  This decision making is documented in a calibrated risk matrix.  The next task is to understand those hazards, determine what risks they hold, are those risks tolerable, and reduce risk where they exceed the tolerable level.

Functional safety provides this method of reducing this risk.

The central metric is the probability of failure on demand (PFDavg). If a safety function has a PFDavg of 0.01, it will fail about 1% of the time when demanded and succeed about 99% of the time. This corresponds to a risk reduction factor (RRF) of 100.  RRF = 1/PFDavg

In practical terms, this safety function reduces the probability of a hazardous outcome by a factor of 100. This quantified reduction is the mechanism by which functional safety works.

Standards Governing Functional Safety

Functional safety is applied across multiple industries, each with standards built on the same underlying principles. Examples include ISO 26262 for automotive systems, IEC 62061 for machinery, and EN 50126/50128/50129 for rail.

At the foundation is IEC 61508, which defines the general framework for functional safety of electrical, electronic, and programmable electronic systems.

IEC 61511 applies these principles to the process industry. It is not a separate concept; it is a sector-specific implementation of the IEC 61508 framework tailored to process facilities.

Note that in my experience as an engineer, almost all codes and standards are applicable to a certain area.  Such as a country or perhaps the European Union.  But functional safety is truly one of the few global standards.  In almost all counties, if they implement a process safety approach, it will be functional safety.  This is one of the reasons SIL Safe exists.

Hazard and Risk Assessment (H&RA)

The functional safety lifecycle begins with understanding hazards in your process.  This is called the hazard and risk assessment (H&RA) which identifies scenarios that could lead to harm, estimates their risk (probability and severity), and determines whether risk is tolerable.  Under IEC 61511, the H&RA is the starting point of the safety lifecycle, and it directly drives the identification of Safety Instrumented Functions (SIFs) and their required performance.

Typical activities in an H&RA include identifying credible scenarios, estimating probability and severity, and deciding where additional protection is required.

Common methods in the process industry include HAZOP and risk matrices. The outcome of this work will establish whether SIFs are needed.

When this occurs in the design process is important.  The H&RA cannot be too early or too late in the process.  If too early, much of the hazards would likely change, not exist, or only be a partial list.  If done too late, you are asking for challenges as changes may need to be modified in existing equipment.  Think cutting pipe to add a SIF.  That is never fun.

See this full article for deeper dive into an H&RA.

Independent Protection Layers (IPLs)

Facilities rely on multiple layers of protection rather than a single safeguard.  Meaning safeguards should be put in place BEFORE a SIF is needed. If this happens, then perhaps a SIF would not be needed or a SIF at a lower SIL level. 

These layers can include the basic process control system (BPCS), relief devices, operator response, and safety instrumented systems. For layers to count independently, they must not fail for the same reasons.  This collection of independent items that can protect a SIF are called Independent Protection Layers (IPL).

The key question is whether the existing layers reduce risk to tolerable levels. If they do not, additional protection is required.

This evaluation is often formalized through a Layer of Protection Analysis (LOPA), which builds directly on H&RA results.  This is one of the most common methods used within IEC 61511 programs to determine the required SIL for each SIF.  This asks…

• Is the risk associated with each hazard tolerable?  This would assess the risk for each hazard against the calibrated risk matrix.

• If not, are there IPLs present or can they be added?  This could be extra pressure relief valves, other instruments in the BPCS. 
• Does each hazard scenario need a SIF?  This compares the risk with the IPLs, against the tolerable risk.  If the risk is not tolerable, a SIF is added to mitigate the risk of that hazard.
• How much risk must each SIF reduce?  Generally, this is thought of in orders of magnitude via a calibrated risk matrix.  Each box the hazard moves is considered one order of magnitude.
• What is the SIL level of each SIF?  This is how many orders of magnitude the risk must be reduced to be tolerable.

Safety Instrumented Systems (SIS)

When existing protection is insufficient, a Safety Instrumented System (SIS) is the system that comes into play.  The SIS is the core system involved in IEC 61511, although the standard also has lifecycle requirements.  Meaning functional safety is not just the SIS.

A SIS is an independent system designed to detect hazardous conditions and move the process to a safe state. It operates separately from the basic process control system (BPCS), which manages normal operation. A typical SIS consists of sensors, a logic solver, and final elements such as shutdown valves or motor isolation devices.  

A Safety Instrumented Function (SIF) is a single protection loop within the SIS. A facility may have one SIF or many, depending on the number of scenarios requiring protection.  Again, it is the LOPA that dictates where the SIFs are and the SIL needed per SIF.

For example, a simple SIF could be a pressure switch sensing high pressure and turning off a pump with a contactor via the controls in a PLC.  Then another SIF can sense a high level and open a dump valve to prevent an overflow.  It goes to the same PLC as the first SIF.  This would have two SIFs, both using the same PLC and together they would be the SIS.

Safety Integrity Levels (SIL)

Each SIF must meet the required level of reliability, expressed as a Safety Integrity Level (SIL).

SIL is always determined after the H&RA and during the allocation of safety layers, typically determined during the LOPA (which itself is typically done directly after the H&RA, often in the same long meeting). In the process industry, most applications are SIL 1 or SIL 2, with occasional SIL 3. SIL 4 is rarely used.

SIL is often associated with equipment ratings, which is technically correct. But more importantly, it defines the required performance of the safety function across design, implementation, and maintenance. For example, higher SIL levels will need more redundancy and would have different levels of controls and different rules about software.  This can be complicated and best discussed elsewhere.

Below is the standard relationship between SIL, Risk Reduction Factor (RRF), and PFDavg for low demand mode:

Other Design Considerations in Functional Safety

Designing a SIF involves more than selecting components.  There are many other concepts that need to be considered, understood, and decided during the design phase.

• hardware fault tolerance (HFT) – Reliability requirements
• voting architecture – Such as 1oo1 voting, 2oo3, and others
• proof test interval (TI) – Duration between proof tests. See this in-depth article.
• proof test coverage (Cpt) – How good proof testing is at detecting failures. See this deeper dive on Cpt.
• mean time to restore (MTTR) – Facility’s time to repair a problem, relates to available spare parts. Read more about MTTR.
• spurious trip rate (STR) – The balance between safety and facility uptime
• diagnostic coverage (DC) – How good the on-board diagnostics are at detecting failures
• common cause failure (beta factor) – Redundant systems may jointly fail due to a common design flaw. Lean more on CCF in this article.

These parameters all interact. There is a push and pull between the terms and even departments in a facility.  Decisions about testing, architecture, spare parts, and maintenance can materially change achieved performance via PFDavg. Each topic is substantial and better explored individually.  

These concepts receive significant attention in functional safety engineering and certification exams.  These will also take significant effort to decide and work through during the detailed design phase of the SIS.

Verifying Safety Instrumented Function Performance (PFDavg)

Once a SIF is designed, IEC 61511 requires that it be verified against its SIL requirement, per SIF.  PFDavg calculations quantify whether the design meets the target. They account for failure rates of the SIF components, architecture, testing intervals, coverage, and repair assumptions.

The process of doing the calculations is complicated.  There are simple equations and complex equations.  Think of it as a specific PFDavg calculation stems from a series of decisions that are made by engineering.  For example, if the SIF is tested only when the unit is shutdown versus bypassed – that impacts PFDavg in different ways.  Generally, practitioners use software or Excel to facilitate.

There is a related approach called Markov Analysis which we will not get into here as it is a more advanced approach.

While central, PFDavg is only one step in a broader discipline. It verifies performance; it does not define the entire program.  Inexperienced users may think PFDavg is all functional safety is about.  But that is an over-simplification.

The simplest PFDavg equation is shown below.  This is for a 1oo1 architecture. 

• TI – proof test interval
• λ_DU – the dangerous undetected failure rate.

The Functional Safety Life-Cycle

Functional safety is governed by a structured life-cycle, and this is one of the most important concepts to understand. The structure of this lifecycle is defined in IEC 61511, and following it is what distinguishes a complete functional safety program from isolated design efforts.  Many engineers initially approach functional safety as a design activity, but that is only one portion of the overall process.

The life-cycle defines how safety is managed from the earliest concept of a facility through to its eventual decommissioning. It ensures that safety functions are not only designed correctly, but also installed, operated, maintained, and periodically assessed in a consistent and auditable manner.

Typical phases include:

• Hazard and risk assessment (H&RA) such as a HAZOP
• Allocation of safety functions (such as via a LOPA)
• Design and engineering – detailed design of the SIFs and SIS
• Verification and validation
• Operation and maintenance
• Functional safety assessment (FSA)
• Decommissioning

Each of these phases has specific deliverables and expectations. For example, the design phase may define the architecture of a SIF, but the operation and maintenance phase ensures that proof testing is performed and that failures are addressed correctly.

The key point is continuity. Functional safety is not a one-time effort. A system that is properly designed but poorly maintained will not achieve its required performance over time.

An all-too-common scenario is that a compliant SIS is installed in a facility.  The company is then bought by a firm in an adjacent industry that has never implemented, nor understands, IEC 61511.  Over time, budgets can be cut or key people can navigate to other departments, companies, or retire.  In this possible scenario various things could happen that could impact the SIS design.  For example, proof tests being done at the wrong intervals or not in accordance with the requirements.  Components could be replaced with non-SIL qualified versions, or the competency and training program could become weak.  All of this is why the functional safety lifecycle is so important.

Regulatory Context

In the United States, regulatory frameworks such as OSHA’s Process Safety Management (PSM) and the EPA’s Risk Management Program (RMP) are the core two regulations.  These get triggered if a certain weight of various materials is on site (called threshold quantity).  These regulations do not prescribe exact methods for managing risk. Instead, they require that facilities follow sound engineering practices.  IEC 61511 is not listed specifically as applicable in the Code of Federal Regulations (CFR), but both OSHA and EPA have stated in writing that using that standard is a sufficient and preferred way to meet the regulations.  In other words, it is considered a RAGAGEP (recognized and generally acceptable good engineering practice).

Therefore, IEC 61511 is often used to demonstrate that a facility is meeting those regulations. It provides a structured and well-understood approach that regulators, auditors, and engineers recognize.  Other countries have similar laws and regulations requiring the standard.

In practice, this means that even though IEC 61511 is not mandatory by law, it is frequently treated as if it were, because it defines what “good” looks like for functional safety in the process industry.

In addition to RMP and PSM, other things could trigger using IEC 61511.  This could be contracts between parties or insurance requirements.  At times, projects for various reasons will not invoke IEC 61511 in full, but may require certain instruments or automated valve maintain a SIL certification.  These SIL only requirements have become more typical as SIL rated components become more common.  SIL Safe welcomes this change in the industry.

Common Misconceptions About Functional Safety

Functional safety via IEC 61511 is often misunderstood, particularly by those who are new to the discipline or who have only been exposed to portions of it.

One common misconception is that functional safety is primarily about calculations, especially PFDavg. While calculations are important, they are only one part of the overall process. Without proper hazard assessment, design, testing, and maintenance, calculations alone do not ensure safety.

Another misconception is that functional safety is only relevant during design. In reality, long-term performance depends heavily on proof testing, maintenance practices, and how changes are managed over time.

A third misconception is that higher SIL automatically means a better system. In practice, SIL is determined by the risk of the hazard along with the IPLs that exist. A higher SIL requirement often indicates a more severe hazard rather than a superior design choice.

Understanding these misconceptions is important because they often lead to incomplete or ineffective implementations of functional safety programs.

Why Functional Safety Programs Matter — and When Expertise Is Needed

Functional safety programs provide a structured way to manage risk across a facility. At a high level, they help ensure that hazards are identified, risks are evaluated, and appropriate protections are implemented and maintained over time.

Effective programs reduce the probability and severity of major accidents, support regulatory compliance, and provide confidence that safety systems will perform when required.

In practice, many organizations require additional expertise at certain points, such as:

• Implementing IEC 61511 for the first time
• Performing SIL determination or verification
• Preparing for and conducting functional safety assessments
• Modifying or upgrading existing SIS implementations

These situations often involve complex decisions, tradeoffs, and documentation requirements that benefit from experienced practitioners.

Q&A Section

1. What is functional safety in simple terms?

Functional safety is the part of overall facility safety that depends on safety functions operating correctly when required. It focuses on ensuring that protection systems perform reliably enough to reduce risk to tolerable levels.  It has the ability to take a typical failure rate of a safety system of perhaps 0.01 (1%) down multiple orders of magnitude.  It does this through a layer of requirements throughout the lifecycle of the system.

Functional Safety is applied to various industries.  SIL Safe focuses on its application to the process industry via IEC 61511.

2. What is the difference between a SIF and a SIS?

A Safety Instrumented System (SIS) is the overall system that performs safety functions. A Safety Instrumented Function (SIF) is a single protection loop within that system, typically consisting of a sensor, logic solver (think a PLC), and final element (like a valve or contactor).

3. If I have hazardous scenarios, why can’t I just add an extra instrument?

Adding an extra instrument and connecting that to your BPCS does not necessarily reduce risk enough. Risk reduction must be quantified, and the resulting protection must meet the required performance level. Without it, the hazard may still exceed tolerable risk.

For example, at times a SIF will have to have an architecture of 2oo3 (meaning three instruments at one point).  One would not know that it was needed unless the process was followed and a PFDavg was calculated

4. I’ve worked on projects where SIL 2 instruments were specified, but the facility was not doing functional safety in its entirety. What is happening there?

Some projects contractually require certain instruments or “safety instruments” to be SIL rated (for example SIL 2 transmitters or valves). This does not mean that the facility is implementing the full functional safety lifecycle. In many cases, companies attempt a compromise where equipment meets SIL capability requirements even if the broader IEC 61511 functional safety program is not fully implemented.

5. What standards govern functional safety?

The foundational standard is IEC 61508, which defines the general framework for functional safety of electrical, electronic, and programmable electronic systems. For the process industry specifically, IEC 61511 defines how those principles are applied to Safety Instrumented Systems.

6. What about machinery safety?

Machinery safety is important, of course.  But it is distinct.  Functional safety for the process industry is focused on reducing the risk (probability and severity) of a major accident.  Machinery safety focuses on the user of the machine.

However, …. as SIL ratings are more common, what is happening is machinery safety risk assessment now will often require a SIL rated instrument.  SIL Safe fully supports this excellent use of SIL instruments.  However, this should not be construed as functional safety.

Conclusion

Functional safety via IEC 61511 combines hazard analysis, engineered protection systems, and structured life-cycle management to reduce the probability and severity of hazardous events.

It is not a single calculation or device, but a coordinated engineering approach that spans the entire life of a facility.

For engineers working in the process industry, understanding these concepts is essential to designing and operating safe systems.

Call to Action

If your facility is implementing or improving a functional safety program, expert guidance can make the process significantly more effective.

Contact SIL Safe to discuss consulting services for IEC 61511 programs, SIS design, and functional safety assessments.

Additional Resources:

Internal — related articles on this site:

• Functional Safety Is Not the Same as Occupational Safety

External authoritative references:

• IEC 61511 Official Standard
• International Society of Automation (ISA)
• UK Health and Safety Executive (HSE)
• CCPS Guidelines

Failure rates sit at the center of how we evaluate, verify, and maintain safety instrumented systems (SIS) under IEC 61511. They show up in SIL verification, PFDavg and STR calculations, equipment selection, and proof test strategy. If you understand the failure‑rate categories and how to obtain them correctly, you can avoid many of the mistakes that derail SIL verification or misrepresent SIS performance.

This article explains the four failure‑rate categories, where the values come from, how to interpret them, and how a functional safety engineer uses them in practice.

The Big Picture: What We Mean by a “Failure Rate”

In functional safety, failure rate is represented by λ (lambda), typically shown in units of 1/hour or in FITs (failures per 1E9 hours). It represents the frequency of random hardware failures—the only failures that can be mathematically modeled.

Random vs. Systematic Failures

Random hardware failures are the only failures that can be described by a rate. Systematic failures absolutely matter, but because they arise from design or process weaknesses, they cannot be represented by λ. You must manage them through quality processes and functional safety management—not statistics.

Constant Failure Rate Assumption

IEC 61511 modeling assumes a constant failure rate. Real‑world devices follow a classic bathtub curve: higher failures early in life (infant mortality), a long flat useful‑life period, and then increasing failures late in life. Failure‑rate data used for SIL verification assumes you are in that useful‑life region.

Statistical Nature of λ Values

Certification bodies and data handbooks treat λ values as statistical estimates with confidence bounds. The SIL certificate condenses this into a single number, but it should be remembered that every published λ carries uncertainty.  However, most of that is a bit behind the scenes for functional safety engineers.

The Four Failure Rate Categories in Functional Safety

Failure modes in functional safety fall into four buckets based on whether the failure is safe or dangerous, and whether it is detected or undetected by diagnostics:

• λSD – Safe Detected
• λSU – Safe Undetected
• λDD – Dangerous Detected
• λDU – Dangerous Undetected

These categories determine whether the failure affects safety, reliability, or uptime—and how it appears in SIL and STR calculations.  Note that “detected” means detected by diagnostics, not by proof tests.

How the Four Failure Rates Feed Functional Safety Calculations

λDU is the largest driver of safety risk. It represents failures that prevent the SIF from acting and are not discovered by diagnostics. This value is always used in PFDavg.  λDD may be used in PFDavg if the detected failure notifies only (does not trip the SIF).

λSU always contributes to spurious trip rate (STR).  λDD and λSD contribute to STR if the control logic forces a safe‑state action when diagnostics detect a failure.  See this article on STR for more background.

λSU and λSD influence reliability and uptime but do not affect PFDavg.

Finally, proof tests exist specifically to reveal undetected dangerous failures—the λDU portion. Some engineers misunderstand this and assume proof tests simply “detect failures,” but in functional safety terms, proof tests are how you manage the DU accumulation.  See this article on proof testing.

Where Failure Rates Come From

Where the Functional Safety Engineer Actually Gets Failure Rates

In real SIS design work, most failure‑rate data comes from certified products, where a certification body (CB) has already performed a detailed IEC 61508 assessment. The FS engineer reads the SIL certificate and the Safety Manual, which provide the extracted λDU, λDD, λSU, and λSD values. These two documents are the authoritative sources for day‑to‑day engineering. The underlying FMEDA exists, but it is not normally reviewed or needed by the practitioner.

When a certified device is not available, several alternate data routes exist. Each route has tradeoffs and requires engineering judgment:

• Manufacturer‑supplied reliability data – useful when transparent and well‑supported, but assumptions must be confirmed.
• Validated site or company datasets – often the most realistic if maintenance and failure tracking are strong.
• User‑generated field data – applicable for legacy equipment with a long operating history.
• Industry sources such as OREDA – helpful when carefully matched to device type, service, and environment.

These alternatives are less typical in functional safety practice, but they require more scrutiny than certified data.

How Failure Rates Are Determined (Typical Scenario)

For certified devices, IEC 61508 defines the process for establishing failure rates. Behind the scenes, the CB reviews or performs:

• FMEDA (failure‑mode analysis and diagnostic modeling)
• Test campaigns and empirical validation
• Diagnostic behavior evaluation
• Environmental and installation assumption checks

The FS engineer does not redo this work. Instead, their responsibility is to:

• Use the published λ values correctly
• Ensure the application matches the assumptions in the Safety Manual
• Integrate diagnostics the way the certification expects

This is where many real‑world errors occur—not because the values are wrong, but because the application does not match the assumptions behind them.

Broader Reliability Concepts

Failure rates are not standalone constants; they are shaped by reliability principles that sit behind the λ numbers. A functional safety engineer must understand these broader ideas to avoid misusing published data.

Systematic failures are not described by λ values. Random hardware failures can be modeled with rates; systematic failures cannot. They arise from design issues, configuration errors, software defects, or procedure gaps. They must be controlled through functional safety management (such as what IEC 61508 does), not reliability math.

Failure‑rate uncertainty is always present. λ values are statistical estimates derived from limited testing, modeling, or field data. Certification bodies select a representative value for the SIL certificate, but there is natural variability behind every λ. The published number is not a perfect truth—it is a useful engineering approximation.

Application and environment can change the true failure rate. A device used in corrosive service, high vibration, or aggressive cycling may experience a higher effective λ than the certified value. Likewise, poor installation, improper mounting, or low‑quality air supply (for valves) can shift failure behavior. The published λ applies only when the Safety Manual conditions are met.

The Safety Manual controls the validity of the data. A λ value is only valid if the equipment is installed, wired, maintained, and operated according to the Safety Manual. If diagnostics are not used, if limits are exceeded, or if maintenance intervals differ from expectations, the certified failure rates no longer describe the real system.

Automated Valve Assemblies and How Their Failure Rates Combine

Automated valves used as final elements are not single devices—they are assemblies made of several components, each with their own failure behavior. A functional safety engineer must gather λ values for each sub‑component and understand how they combine to represent the full final element.

Typical valve‑assembly components include the valve body, actuator, solenoid, positioner, and any boosters or air relays. Each component contributes its own λDU, λDD, λSU, and λSD. Because the SIF fails if any one of these components cannot perform its intended action, the failure rates are combined using Boolean OR logic:

λ_total ≈ λ₁ + λ₂ + λ₃ + …

In practice, most λDU comes from mechanical components such as the actuator and valve body. These parts typically lack meaningful diagnostics, so λDU remains the dominant contributor for the final element. Electronic components—like smart positioners—may reduce λDD by improving diagnostics, but they seldom reduce λDU in a significant way.

Some manufacturers have begun certifying complete valve assemblies under IEC 61508. When available, this simplifies the engineer’s task: the assembly‑level λ values are already validated and consolidated under a single device boundary. See this example from Emerson: https://www.emerson.com/en-us/automation/valves/controlvalves/digital-isolation-solutions. We at SIL Safe expect and hope this trend continues.

Practical Examples

Sensor Example: How the Engineer Obtains λ Values

A functional safety engineer begins by locating the λDU, λDD, λSU, and λSD values published in the device’s SIL certificate or Safety Manual. These documents reflect the certification body’s IEC 61508 assessment and define how the device behaves under expected diagnostic, installation, and environmental conditions. The engineer then confirms that the plant’s SIS logic and wiring actually use the diagnostic features assumed in the certification. Once these steps are complete, the engineer has the correct λ values that will be applied in later PFDavg or STR calculations.

Final Element Example: How the Engineer Obtains λ Values

For an automated valve assembly, the process is more involved because a final element is made of multiple components that must all function correctly. The engineer identifies each sub-component—such as the valve body, actuator, solenoid, positioner, and boosters—and retrieves λ values from each component’s SIL certificate or Safety Manual. The installation and diagnostic assumptions must match the application for the values to be valid. Because a failure in any single sub-component prevents the valve from performing its safety function, the engineer combines the λ values using OR logic to produce the total assembly failure rate. This assembled λ dataset will be used in downstream PFDavg and STR calculations.

Common Mistakes Engineers Make with Failure Rates

Even experienced engineers can misapply failure‑rate data if the context behind the numbers is not fully understood. A few issues show up repeatedly in real SIS design and verification work.

Misinterpreting λDU vs. λDD. These two values behave very differently. λDU always goes into PFDavg because it represents failures that diagnostics cannot find. λDD may or may not impact STR or PFDavg depending on how diagnostics are integrated. Treating DD like DU—or assuming DD never matters—produces incorrect verification results.

Using generic values without validating assumptions. Generic data tables, old spreadsheets, or handbook values can be misleading if the assumptions behind them do not match your application. Certified values come with defined conditions; generic values usually do not.

Ignoring diagnostics. Sometimes diagnostics exist on the device but do not make it into the SIS logic or maintenance workflow. If a diagnostic bit is unwired, unmapped, filtered out, or simply ignored in operations, detected dangerous failures behave like undetected failures. In this case, λDD effectively becomes λDU.

Treating λ values as universal constants. A λ value from a certificate is not automatically valid everywhere. Installation, environment, cycling, mounting, and maintenance determine whether the published λ truly reflects your plant’s conditions. Failure rates must be applied with engineering judgment, not copied blindly.

When Diagnostics Exist but Are Not Used

Diagnostics only add value when the SIS actually acts on them. A device may have excellent internal diagnostics, but if they are not used by the controls, the failure behaves as if it were undetected. In this situation, λDD is effectively added to λDU for purposes of SIL verification because the SIF remains impaired until someone actively responds.  It could really impact PFDavg.

This scenario is more common in brownfield facilities, older installations, poorly integrated SIS/BPCS architectures, or sites where diagnostics alarm but no work process exists to ensure timely repair. The lesson for the engineer is simple: diagnostics only help if the entire chain—from device to logic to maintenance—uses them correctly.

Where Failure Rates Influence SIS Design Decisions

Failure‑rate data influences several real‑world engineering choices throughout the SIS life‑cycle. Understanding how λ values behave helps the engineer select architectures, manage proof‑test strategies, and apply diagnostics intentionally—not blindly.

Architecture selection. If λDU is high, additional redundancy may be required to achieve the target SIL. Failure‑rate data helps determine whether 1oo1, 1oo2, or 2oo3 architectures are appropriate for the SIF.

Choosing the proof‑test interval (TI). Proof tests exist to reveal λDU—the part diagnostics cannot see. A higher λDU or lower proof‑test coverage (Cpt) typically requires a shorter TI. Failure‑rate data directly shapes the proof‑test strategy.  See this other article about CPT.

Partial‑stroke testing for final elements. For valves that dominate λDU, partial‑stroke testing may reduce the exposure time of dangerous failures. This decision depends on understanding which failure modes are found by diagnostics versus proof tests.

Diagnostic selection and integration. λDD and λSD only help if diagnostics are wired, mapped, and acted on. Understanding the diagnostic coverage of a device and the assumptions in the Safety Manual helps engineers design logic and maintenance workflows that truly reduce risk.

Summary: A Practical Way to Think About Failure Rates

Failure rates are the foundation of how we model and manage random hardware failures in functional safety. λDU represents the portion of failures that silently erode the ability of a SIF to act when needed. λDD and λSD describe failures that diagnostics can reveal, informing how often a SIF may trip unnecessarily and how reliably it stays available. λSU supports reliability but does not influence risk directly.

These four failure‑rate categories show up throughout the IEC 61511 safety life‑cycle: in equipment selection, architectural decisions, proof‑test strategy, diagnostic design, and SIL verification. If the failure‑rate assumptions in the SIL certificate and Safety Manual are respected—and if diagnostics are used correctly—then λ values become powerful tools for designing and maintaining a dependable SIS.

Need Help With Failure Rates?

For more help applying failure‑rate data correctly—or for third‑party SIS verification—reach out through SIL Safe’s contact page.

Further Reading

Internal:

• SIL Safe Glossary
• Proof Testing of SIFs: Understanding Its 3 Purposes and Its Importance
• PFDavg Explained: 6 Essentials for Getting Started with SIL Calculations

External:

• ISA — Updated guidelines for using ISA-IEC 61511
• Emerson — Certified automated valves

Q&A Section

• What’s the practical difference between λDU and λDD?
  λDU drives PFDavg because the failure is both dangerous and undetected. λDD is dangerous but detected, so it typically results in an alarm or forced-safe trip and may contribute to STR depending on configuration.
• Do failure rates change over time in my facility?
  Yes. The published λ values assume controlled conditions; however, real‑world factors like environment, cycling, installation quality, and maintenance can shift the true failure rate up or down. However, we assume constant for modeling purposes.
• Why do certified products help for accurate λ values?
  Certified devices provide validated λ values and clearly defined DU/DD/SU/SD splits under IEC 61508. This reduces interpretation errors and ensures the assumptions behind the numbers are understood and controlled.
• Is it okay to use generic failure rates?
  Only if you confirm that they match your device and application. Generic values may not reflect your environment, proof-test strategy, or diagnostic coverage.
• What if the device doesn’t have a SIL certificate?
  You can still use it, but you must rely on credible manufacturer reliability data, validated site history, or reputable sources such as OREDA. These represent the alternate data routes when a certified data path is not available. Assumptions must match the application, and justification must be documented.
• Why do final elements almost always have higher λDU than sensors?
  Most λDU in a final element comes from mechanical components like the actuator and valve body, which lack strong diagnostics. Sensors generally have better diagnostic coverage and fewer mechanical wear points, so their λDU values are typically much lower.
• I understand why λDU impacts PFDavg, but why would λDD impact PFDavg?
  It depends on how the controls and diagnostics are set up. In many low-demand configurations, only λDU enters PFDavg. But if a dangerous detected failure leaves the SIF unable to perform its function—and the system does not act on or repair that diagnostic—then that portion of λDD effectively behaves like λDU and may need to be included in the PFDavg analysis.
• How are λ values used differently in high-demand or continuous modes?
  Failure rate is highly relevant but used differently.  In low-demand mode (most common), we use λDU to calculate PFDavg.  In continuous or high-demand modes, PFDavg is not used. Instead, SIL is based on PFH — the rate of dangerous failure per hour. In these cases, λDU is used to calculate PFH through a different series of equations than PFDavg. 

What Is It? (CCF vs. Beta Factor and Why It Matters)

Common cause failure (CCF) is a concept of multiple things failing for the same core reason. It is a concept in various industries and practices. In a Safety Instrumented System (SIS) it means multiple channels in redundant architectures fail together because of a shared cause. For example:

• Sensors: Two pressure transmitters mounted side‑by‑side exposed to the same vibration or plugged impulse lines.
• Logic solver: Both processor cards affected by the same unknown software bug.
• Final element: Two solenoids sharing the same instrument air header that fail simultaneously.

The beta factor (β) is the fraction of all dangerous failures that occur from a CCF. It is the mathematical representation of the CCF concept. It converts the qualitative idea of “common cause” into a quantifiable term used in equations. Ignoring β will almost always make your average probability of failure on demand (PFDavg) appear lower than it really is — giving a false sense of security.

Where to Get Beta Factor Values

There are two primary sources:

1. SIL certificates or FMEDA reports from manufacturers. These often include β values based on test data and modeling assumptions.
2. IEC 61508‑6 Annex D – the formal method for determining β using dependent failure analysis. This process is complex and beyond the scope of this article, but it is the standard reference.

Other useful references include ISA TR84.00.02, OREDA, and CCPS reliability publications. Some companies maintain internal databases based on field performance.

A practical approach:

• Start with the β from the SIL certificate.
• Review Annex D factors to see if your installation justifies adjustment.
• Document and justify the final value in your Safety Requirements Specification (SRS).

How Architecture Affects β

The β‑factor is not constant; it changes with architecture. This is a common point of confusion within Functional Safety. Think of redundancy as a team of security guards protecting a building:

• In a 1oo2 architecture, either guard can respond to stop a robbery. If both guards eat the same lunch and get food poisoning, that’s a CCF — a shared vulnerability.
• In a 1oo4 architecture, four guards must all get sick for the robbery to succeed. The common cause event would have to be much stronger or more universal, or “more common,” to take them all down. Think of a really widespread case of food poisoning. Therefore, the effective β is lower.

This creates a feedback loop: changing architecture alters the PFDavg equation, but it also justifies a new β — which again changes the PFDavg. It is a bit odd, but it is correct. IEC 61508‑6 Annex D Table D.5 gives architectural correction factors (roughly 0.3 – 1.74) that help account for this effect. Most β values published in SIL certificates are assumed for 1oo2 configurations.

NooN Architectures and Why β Is Not Present

For NooN architectures (e.g., 2oo2 or 3oo3), β is normally not present in the mathematics. Any single channel failure will cause the function to fail because all channels must work. The total λDU (dangerous undetected failure rate) already includes both independent and common‑cause contributions. Applying a separate β term would double‑count the effect.

Returning to the guard analogy: if three guards must all respond correctly and any one failure causes system failure, it doesn’t matter if their failures were independent or shared — the result is the same. For this reason, modeling tools and standards do not include β for NooN designs.

Note that this can be thought of as “β is set to 0 for NooN” but that is not how we at SIL Safe think of this. Yes, you can use the MooN PFDavg equations, set β = 0, and get the same results. But as we discussed above, β is accounted for in λDU.

Typical Values and Influencing Factors

Factors that increase β:

• Common environment (same enclosure, same power, same impulse lines)
• Identical design and firmware
• Shared maintenance procedures or simultaneous testing

Factors that decrease β:

• Physical separation and shielding
• Vendor or technology diversity
• Independent power and utilities
• Separate calibration schedules
• Staggered proof testing

PFDavg Equation Discussion

In a 1oo2 system, the total PFDavg is made up of independent and common‑cause terms. Using a simplified version of the equation:

Where:

• λ_DU = dangerous undetected failure rate (per hour)
• TI = proof test interval (hours)
• β = fraction of failures due to common causes

The first term (squared) represents two independent latent failures. The second (linear) term represents the probability that both channels fail from a shared cause. Because the independent term is squared, it becomes much smaller — making β a powerful driver in redundant designs.

PFDavg Calculation Examples (1oo2)

Case A – Good β Factor (Target: SIL 2)

Given: β = 0.03, λ_DU = 2E-6/hr, TI = 8,760 hr (1 year)

1. Independent term:
   (1/3) × [(1 − 0.03) × 2E-6 × 8,760]² = 9.63E-5
2. Common‑cause term:
   (1/2) × 0.03 × 2E-6 × 8,760 = 2.63E-4
3. Total PFDavg = 3.59E-4
4. RRF = 1 / PFDavg = 2,785 → SIL 2

STR (spurious trip rate): assume λ_SP = 1E-5/hr per channel. For 1oo2 (trip on any channel):
STR ≈ 2 × λ_SP = 2E-5/hr → 0.175 trips per year ≈ a trip every 5.7 years.

Case B – Poor β Factor (Target: SIL 1)

Given: β = 0.15, λ_DU = 2E-6/hr, TI = 8,760 hr (same assumptions)

1. Independent term:
   (1/3) × [(1 − 0.15) × 2E-6 × 8,760]² = 7.4E-5
2. Common‑cause term:
   (1/2) × 0.15 × 2E-6 × 8,760 = 1.31E-3
3. Total PFDavg = 1.38E-3
4. RRF = 1 / PFDavg = 725 → SIL 1

STR (same λ_SP): 2E-5/hr → 0.175 trips/year or one trip every 5.7 years (same as Case A).

Comparison: Raising β from 0.03 to 0.15 increased total PFDavg by ≈ 4×, dropping the SIL from 2 to 1.

Impact of Common Cause Portions of PFDavg

Because the independent term is squared, it diminishes as reliability increases, while the common‑cause term remains linear. The result: CCF often dominates total PFDavg in redundant architectures.

• Case A (β = 0.03): PFDavg_ind = 9.63E-5, PFDavg = 2.63E-4 → CCF ≈ 73% of total.
• Case B (β = 0.15): PFDavg_ind = 7.4E-5, PFDavg = 1.31E-3 → CCF ≈ 95% of total.

Even at modest β values, most of the total unavailability stems from common causes — which is why reducing β through independence and diversity is far more effective than upgrading the architecture. The same pattern holds true for higher architectures like 2oo3.

Common Mistakes

• Applying the same β to every subsystem without justification.
• Assuming diagnostics lower β (they don’t; they reduce λ_DU).
• Forgetting to justify β selection in the SRS.
• Focusing only on adding redundancy instead of lowering β.

Summary

The β‑factor is what connects real‑world dependencies to your math. A small change in β can shift a design from SIL 2 to SIL 1 — even when every other parameter is identical. Real independence, not just redundancy, drives reliability.

Document your β assumptions, revisit them throughout the SIS life‑cycle, and when in doubt, verify them against IEC 61508‑6 Annex D or manufacturer data.

If you’d like a second set of eyes on your β assumptions or SIL verification model, contact SIL Safe for a practical review or training session.

Q&A

1. Does beta factor (β) apply only to 1oo2 architectures?
No. The concept applies to any redundant system where channels can fail together, though it’s most visible in 1oo2.

2. Can β ever be zero?
Not realistically. There’s always some shared factor — environment, maintenance, or design — that introduces correlation.  For NooN scenarios, β does not appear in the mathematics, so some say  β is zero, but it is still included in the λ_DU term.

3. What does β actually represent?
It’s the percentage of dangerous failures that are shared between channels rather than truly independent.

4. How often should β be revisited?
Any time design, environment, or procedures change — typically during periodic review or FSA Stage 4.  It is common for β to change over the safety lifecycle.

5. Can one simply apply the β in the SIL certificate?
Use it as a starting point. Then compare against Annex D’s checklist and justify any adjustment.

6. What portion can common cause contribute to total PFDavg?
Often the majority. For 1oo2 with β ≈ 0.1–0.2, common cause failures can make up 70–95 % of total PFDavg — the same trend appears in higher architectures.

7. I’ve heard that for NooN architectures, β is set to 0, but I thought that is not possible?
β is involved in NooN, but it is already included in the λ_DU term. Meaning we don’t want to double count. The NooN equations will not have any β terms. Thus, it can be thought of as they were set to zero, but that is not technically correct.

Further Reading

Internal:

• SIL Safe Glossary
• PFDavg Explained: 6 Essentials for Getting Started with SIL Calculations

External:

• Analog Devices — Guidance on quantification of common cause failure
• NRC — Common Cause Failure Guidance (PDF)
• NRC — NUREG-2225 Index