LOPA and SIL determination.
Layer of protection analysis takes one scenario a HAZOP has already identified, credits the protection layers that genuinely act on it, and works out whether what is left meets the frequency the operator is willing to tolerate.
What LOPA is for
A HAZOP tells you a scenario exists and roughly how bad it is. It does not tell you whether the protection against it is enough, because a risk matrix works in bands and a band cannot be divided by another band.
LOPA is the semi-quantitative step in between. It takes a single cause-consequence pair, puts a frequency on the initiating event, credits each independent layer that acts on that specific scenario with a probability of failure on demand, and compares the result against a tolerable frequency the operator has set in advance. The output is a number: how much more risk reduction is needed, if any.
It is not applied to every line of the worksheet. LOPA costs time, and it is worth spending where the consequence is severe and the sufficiency of the safeguards is genuinely in question. A scenario whose answer is obvious either way does not need it.
What counts as a layer
An independent protection layer is not simply a safeguard the HAZOP listed. To be credited it has to be:
- Independent of the initiating event and of every other layer being credited. A trip and a control loop that share a transmitter are one layer, not two: the thing that fails takes both with it.
- Specific to this scenario. A layer that protects against something else does not count here, however valuable it is.
- Dependable, with a failure probability that can be justified rather than assumed, and large enough to matter.
- Auditable: tested and maintained at an interval somebody can demonstrate, because an untested layer degrades to a number nobody can defend.
Common-cause failure is where LOPA is most often done badly. Two layers on the same power supply, the same instrument air, or the same operator responding to two alarms in the same minute are not two independent layers, and crediting them as such produces a comfortable answer that the plant does not actually have.
The arithmetic
Each credited layer carries a probability of failure on demand, or PFD: the chance it does not act when the scenario calls on it. The mitigated frequency is the initiating frequency multiplied by the PFD of every layer credited.
required risk reduction = mitigated frequency ÷ tolerable frequency
If the required reduction comes out at 1 or below, the layers in place already meet the target and no safety instrumented function is called for. Above 1, the shortfall is what a SIF has to supply, and that figure is the required risk reduction factor.
The tolerable frequency is the operator’s own number, set by severity, and it is the input people argue about most. It is a statement of how often a company is prepared for a given consequence to occur, which is an uncomfortable thing to write down and the reason LOPA makes risk decisions explicit rather than implicit.
The SIL band
Where a SIF is required, the band follows from the required risk reduction factor, per IEC 61511-1:
- 1 or less
- No instrumented function required. The layers already in place meet the target.
- 1 to 10
- SIL a. Below the range an instrumented function is normally specified for.
- 10 to 100
- SIL 1
- 100 to 1,000
- SIL 2
- 1,000 to 10,000
- SIL 3
- 10,000 to 100,000
- SIL 4
- Above 100,000
- Beyond SIL 4. A single instrumented function is not the answer; the design needs changing.
The boundaries are closed at the bottom: a required reduction of exactly 100 is SIL 2, not SIL 1. It is a small point that decides real cases, and the error is not symmetric. A band too strong costs money; a band too weak costs what the function was installed to prevent.
A worked example
An initiating event at 0.1 per year, two independent layers credited at a PFD of 0.1 each, against a tolerable frequency of 1 × 10-5 per year:
required RRF = 1 × 10-3 ÷ 1 × 10-5 = 100
band = SIL 2
Change one input and the answer moves a band. Drop a layer that turns out not to be independent and the requirement becomes SIL 3, which is a materially different piece of equipment with different proof-test and architecture obligations. This is why the independence test is worth being strict about.
What LOPA will not tell you
LOPA is order-of-magnitude by design. The inputs are rounded to powers of ten because the data does not support more precision, and an answer carried to three significant figures is false confidence rather than better analysis.
It also answers only the scenario it was given. It will not find a hazard the HAZOP missed, it does not model two scenarios occurring together, and it says nothing about whether a SIF, once specified, is actually designed, proof-tested and maintained to hold the band the analysis asked for. That is the rest of the functional safety lifecycle, and the LOPA is the start of it.
TechPHA carries the LOPA beside the worksheet it came from, with the credit for each layer shown rather than assumed. See how a study runs.