Bow-Tie Analysis — Threats, Barriers, and Consequences

Introduction

Process safety has three dominant analytical methods. HAZOP identifies hazards through structured deviation analysis. LOPA quantifies the frequency of hazardous events to determine SIL targets. Bow-tie analysis sits between them — it is the structured visualisation of what prevents a hazard from realising and what mitigates it once realised. Done well, a bow-tie diagram tells a regulator, an operator, and a board director the same thing in the same picture.

This post walks through the anatomy of a bow-tie, when to use it, what makes a barrier credible, and the common failure modes that turn a bow-tie from a reliability tool into a wallpaper exercise.

Anatomy of a Bow-Tie

The bow-tie shape gives the technique its name. From left to right:

• Threats — initiating events that could trigger the hazard (shown as labels on the left)
• Preventive barriers — controls that stop a threat from becoming the top event (shown as bars between threats and centre)
• Top event / Loss event — the unwanted release, deviation, or initiating moment (centre of the diagram, typically a circle)
• Mitigative barriers — controls that limit the consequence once the top event has occurred (shown as bars between centre and right)
• Consequences — the outcomes if mitigative barriers fail (labels on the right)

Imagine a hazard like "uncontrolled release of LPG from a storage vessel." The top event is the loss of containment. Threats might include: corrosion-induced failure, overpressure from external fire, mechanical impact from a vehicle, valve failure during transfer, sample valve left open. Preventive barriers could include corrosion-monitoring inspection programmes, the PSV protecting against fire, vehicle barriers and ESD impact protection, interlocked transfer pump permissive, sample valve administrative controls. Once a release occurs, mitigative barriers include gas detection with ESD, water deluge, fire and gas monitoring, evacuation procedures, exclusion zoning. Consequences range from minor release to flash fire to unconfined vapour cloud explosion to fatality.

The bow-tie places these on one diagram so the reviewer can see, at a glance, how many independent layers of protection exist between threat A and consequence B.

Threats vs Causes vs Initiating Events

Vocabulary matters. In many bow-tie standards:

• Threat is the thing that could initiate the loss event — corrosion, overpressure, mechanical impact, human error.
• Cause is sometimes used synonymously with threat; sometimes used at a more granular level (the specific failure mode of a barrier).
• Initiating event is a LOPA-specific term — typically aligned with threats but quantified by frequency.

Inconsistency in vocabulary is the single most common source of bow-tie review confusion. Pick one set of definitions before the workshop starts.

The Four Barrier Types

Not every barrier carries equal weight. The CCPS classification is widely used:

1. Hardware Barriers

Physical equipment that operates without human action. PSVs, blowdown valves, ESD systems, dikes, fire walls, sprinkler heads. These are quantifiable through PFDavg (probability of failure on demand) and are the highest-credit barrier type.

2. Hardware-with-Human Barriers

Equipment whose effectiveness depends on a human action. Manual ESD pushbutton, manual fire pump start, manual gas-detection isolation. Credit reduced because the human element introduces variability.

3. Procedural Barriers

Pure human action — operator response to alarm, permit-to-work, lock-out/tag-out, isolation procedures, emergency response plan. Credit is heavily limited and very dependent on training, fatigue, and complexity. Most regulators cap procedural barriers at PFD ≈ 0.1 (10⁻¹) — meaning a 10% failure rate, regardless of how meticulously the procedure is written.

4. Inherent Safety / Passive Design

Features that eliminate the threat by design — minimum inventory, lower operating pressure, lower temperature, less hazardous material substitution. These are the highest-credit barriers because they cannot fail in the conventional sense; the hazard is reduced by physics, not vigilance.

A bow-tie heavy on procedural barriers and light on hardware/passive design is a structurally weak protection scheme, regardless of how many bars are drawn on the diagram.

Effectiveness vs Reliability vs Independence

Three dimensions distinguish a credible barrier from a wishful one:

Effectiveness

Does the barrier, when it works, fully prevent or fully mitigate the threat or consequence? A PSV is highly effective for overpressure; a high-temperature alarm is partially effective (it warns but does not act). Effectiveness is binary in classical bow-tie practice — a barrier either gets credit for that pathway or it does not.

Reliability

When called upon, what is the probability the barrier performs as intended? PSVs ≈ 0.01 (PFDavg of well-maintained relief). SIL-2 SIS ≈ 0.001–0.01. Operator action on alarm ≈ 0.1. Fire pump on demand: depends entirely on test programme.

Independence

Does the barrier rely on the same component, the same operator, or the same root cause as another barrier? The classic LOPA failure: counting the BPCS alarm and the BPCS automatic shutdown as two independent barriers when both depend on the same process measurement and the same logic solver. The independence test: if one fails, does the other still work? If no, only count one.

When to Use Bow-Tie

The bow-tie is most useful in three contexts:

1. Major Accident Hazard (MAH) Assessment

Regulators in the UK, Norway, Australia, and increasingly the GCC require bow-tie diagrams for the most significant offshore and onshore facility hazards as part of the safety case. The bow-tie is the visual artefact that demonstrates "we have understood this hazard and it is being managed."

2. Communication Across Disciplines

A bow-tie communicates a hazard scenario to people who don't read P&IDs — operators, maintenance, emergency response, regulators, board members. A LOPA worksheet does not. A HAZOP report does not. A bow-tie does.

3. Bridging HAZOP to LOPA

In a typical safety lifecycle, HAZOP identifies hazards, LOPA quantifies them, SIL determination assigns IPL credit. The bow-tie sits naturally between HAZOP (hazard identification) and LOPA (quantification) — it organises the threats and consequences from HAZOP into the structure LOPA needs.

Bow-Tie Software

Hand-drawn bow-ties on a whiteboard work for one or two scenarios. Beyond that, dedicated software is the practical tool:

The value of dedicated software is not the diagram — it is the metadata: barrier ownership, performance standard, test interval, last test result, link to maintenance records. A bow-tie diagram with no metadata is decoration. A bow-tie linked to maintenance management with current barrier status is a live safety case.

Practical Example: LPG Storage Tank Overfilling

Top event: liquid level above design in a 50 m³ atmospheric LPG storage tank.

Threats (left side):

• Filling line valve fails open
• High-level alarm not acknowledged by operator
• Filling rate exceeds maximum design

Preventive barriers:

• High-high level switch with automatic filling line shut-off (SIL-2 SIS) — hardware, PFD 0.001
• High-level alarm with operator response procedure — procedural, PFD 0.1
• Filling rate restriction orifice in fill line — passive design, PFD ~0.0001

Top event (centre): tank overfill → liquid carryover into vapour space → vapour-side relief device

Mitigative barriers:

• Vapour-side relief valve with vapour-only routing — hardware, PFD 0.01
• Fire and gas detection at filling area — hardware-with-human, PFD 0.05
• Emergency response (firewater, evacuation) — procedural, PFD 0.1

Consequences:

• Atmospheric LPG release → vapour cloud (large)
• Vapour cloud ignition → flash fire / explosion
• Fatality / equipment damage / environmental release

The bow-tie immediately shows: only one hardware preventive barrier between threat and top event (the SIS), one passive design barrier (orifice). The procedural alarm is not a credible third barrier in regulatory terms. If the SIS fails proof testing, the protection scheme leans on a procedural barrier with PFD 0.1 and a passive flow-restriction barrier — that is exposure that may or may not meet target tolerable risk.

This is exactly the conversation the bow-tie is designed to surface.

Common Pitfalls

• Counting the same barrier twice under preventive and mitigative pathways. A barrier can be preventive or mitigative depending on where on the bow-tie you place it, but if the same physical device prevents threat A and mitigates consequence B, it gets two separate placements with separate credit — the credit is not shared.
• Crediting procedural barriers heavily. Operator action on an alarm is not equivalent to a SIL-2 SIS. Many sites build bow-ties that look protective but are reliant on operator response under emergency conditions — exactly when human reliability is lowest.
• Independent in name only. Two barriers crediting the same sensor, the same logic solver, or the same final element are not independent. The bow-tie diagram doesn't show this; the engineer must verify.
• Treating the bow-tie as a one-time deliverable. A bow-tie that hasn't been updated to reflect the last MoC, the last inspection finding, or the last incident is fiction. Live bow-ties with metadata sync to maintenance systems are the operational gold standard.
• Drawing too many threats and consequences. A bow-tie with thirty threats per side becomes unreadable. Group threats by mechanism (corrosion, overpressure, mechanical, human), and group consequences by severity. The clean version is more useful than the comprehensive version.
• Ignoring escalation factors. A bow-tie barrier can have its own internal failure modes ("escalation factors") — e.g., the SIS depends on instrument air, a backup generator, a competent operator. Showing these is optional but illuminates barrier vulnerabilities.

Conclusion

The bow-tie is the most communicative tool in process safety. It does not replace HAZOP (you still need to identify hazards) or LOPA (you still need to quantify frequencies), but it shows — in one diagram — what stands between an initiating event and a catastrophe, and how many of those stands are independent, hardware-based, and reliable.

The honest test of a facility's safety scheme is to draw the bow-tie for its three most consequential hazards and count the independent hardware barriers between threat and top event, and between top event and worst consequence. Two or three on each side, all hardware or passive, is robust. One hardware barrier supplemented by procedural fallback is a thin protection scheme that the diagram makes uncomfortably visible.

Many bow-ties are uncomfortable to look at. That is the point.