IEC 61511 — SIS design and fault tree verification

Two numbers, produced by two different activities

The distinction that IEC 61511 is built around, and the one most often collapsed in practice, is between the SIL a hazard requires and the SIL a design achieves.

The required SIL comes out of hazard analysis — usually LOPA, sometimes a risk graph or a quantitative assessment. It starts from an initiating event frequency, credits the independent protection layers that already exist, and compares the residual risk with the tolerable target. Whatever gap remains is what the Safety Instrumented Function has to close, and the size of that gap is the required SIL. Note what it does not depend on: any property of the SIF, which does not exist yet.

The achieved SIL comes out of the design. Given real devices with real failure rates, a chosen voting architecture, a chosen proof-test interval and a common-cause assumption, what average probability of failure on demand does this arrangement actually deliver? That is a bottom-up calculation over the as-designed system, and it is where the fault tree does its work.

The two are compared, and the design is iterated until achieved beats required. LOPA + FTA — closing the loop on SIS verification walks a pressure-vessel hazard through both halves end to end, with the arithmetic shown.

What the SIF fault tree looks like

The top event is the SIF failing to act on demand. Below it, an OR gate over the three subsystems — because any one of them failing to do its part defeats the function:

• Sensor subsystem — transmitters or switches detecting the process deviation. Often 1oo2 or 2oo3, both for integrity and to keep spurious trips down.
• Logic solver — the safety PLC. Usually the smallest contributor; a certified solver's dangerous undetected rate is typically well below the field devices'.
• Final element subsystem — shutdown valves, solenoids, motor starters. Usually the largest contributor, because valves stick and their failures are the hardest to detect without stroking them.

Within each subsystem the voting arrangement determines the gate. A 1oo2 sensor pair is an AND — both must fail dangerously — plus a common-cause term that is not optional. A 2oo3 arrangement is a VOTE gate, which the tree expresses directly rather than expanding into the equivalent OR of ANDs.

Then read the minimal cut sets. Every order-one cut set is a single point of failure for the safety function; in a SIF claiming SIL 2 or higher, each one needs an explanation. Frequently the cut set that dominates is not a device at all but the common-cause term on a redundant pair — which is the analysis telling you that the second sensor bought less than the block diagram implied.

Where IEC 61511 diverges from IEC 61508

Prior use, not just certification

IEC 61508 assesses a device against the standard. IEC 61511 also allows prior use: evidence from operating history in comparable service can justify a failure rate, provided the population, environment and maintenance regime are genuinely comparable and the data is properly recorded. For a plant with decades of maintenance records this is often better evidence than a generic handbook figure — and it is the reason the failure rate in a well-founded SIF calculation may differ substantially from the published generic values.

The end user carries the lifecycle

IEC 61511 assigns responsibility to the operating company, not only the equipment manufacturer. Proof testing, management of change, bypass control and demand recording are all in scope. A SIL claim is a claim about an operating regime as much as about hardware, and it lapses when the regime does.

Spurious trips are part of the design problem

An unnecessary shutdown is not free: it costs production and, more importantly, every start-up carries its own hazards. 1oo2 improves integrity and worsens spurious trip rate; 2oo2 does the reverse; 2oo3 is the usual compromise, which is why it appears so often in process work. A tree that models only the fail-to-danger direction answers half the design question.

Where these calculations usually go wrong

• Perfect proof testing. A test that confirms the transmitter reads but never strokes the valve leaves part of the dangerous failure set untouched. That fraction must be modelled as an un-tested contribution, and it typically dominates the result at long intervals.
• Beta by default. Assuming a common-cause factor because it is conventional, rather than scoring the actual installation, produces a number with no defensible basis. Identical devices sharing an impulse line, a supply and a calibration technician are far more coupled than diverse devices on separate tappings.
• Counting a layer twice. If LOPA credited the basic process control system as an independent protection layer, it cannot also appear inside the SIF tree — that is the same protection claimed in two places, and reviewers look for it.
• Ignoring the architectural constraint. A computed PFD in the SIL 3 band does not license a SIL 3 claim if hardware fault tolerance and safe failure fraction cap the architecture lower. The two checks are separate and both must pass.
• Point estimates presented as certainty. Failure-rate data carries error factors of three or more. A result that clears its target by 10% has not really cleared it — propagating the uncertainty turns "passes" into "passes at the median, fails at the 95th percentile", which is a materially different conversation.

Doing this in FTA Studio

Set the project standard to IEC 61511 and the SIL verdict is computed against the low-demand PFD bands. Basic events take a dangerous undetected rate with a proof-test interval; VOTE gates express k-of-n voting directly; common-cause groups carry a beta factor and appear in the cut sets where they belong. Importance measures rank which element actually governs the result — usually the final element — and the hydrocarbon release and pressure-vessel rupture templates are complete worked SIL 2 examples you can open and take apart.