The Three Gates to SIL

There is a moment that repeats on almost every project. Someone finishes a spreadsheet, points at a green cell, and says: “We are SIL 2 — look at the PFDavg.” The room relaxes. That relaxation is expensive. A robust SIL verification is a three-gate problem. The number matters. It is not the whole story.

1. Why one number feels so tempting

PFD_avg is concrete. It has exponents. It fits in a table. Managers can compare it. Spreadsheets love it. So teams naturally treat it as the finish line.

But functional safety standards are not only about random hardware failures that can be averaged. They also ask whether the hardware structure is allowed to carry the claim, and whether the design and lifecycle can defend against systematic mistakes — the kind of failure that does not care how pretty your λDU was.

“Three gates” is an explanatory model used in this paper. It is a teaching shorthand for the three constraints that usually decide a SIL claim in practice. It does not replace the normative wording of IEC 61508 / IEC 61511.

2. Gate 1 — Probabilistic performance

Gate 1 asks a quantitative question: how likely is this safety function to fail dangerously?

For a low-demand SIF, that is usually PFD_avg — the average probability that the function is unavailable when a demand arrives. For high-demand or continuous mode, it is usually PFH — average dangerous failures per hour.

The answer is sensitive to architecture and to assumptions: dangerous undetected and detected failure rates, proof-test interval, proof-test coverage, diagnostics, repair/restoration time, mission time and common-cause effects. If the assumptions are soft, the number is soft — no matter how many decimal places you print.

A useful interpretation for low demand is RRF ≈ 1 / PFD_avg. Useful for conversation. Not a complete verification criterion.

3. Gate 2 — Architectural constraints

Gate 2 asks a different question: is this hardware structure allowed to carry the SIL we want to claim?

Even a beautiful probability model can be rejected if the architecture does not provide the required Hardware Fault Tolerance (HFT), or if Safe Failure Fraction, equipment type and the selected IEC architectural route do not support the claim. The point of this gate is to stop “good maths on weak structure.”

Redundancy such as 1oo2 or 2oo3 can improve fault tolerance — it does not automatically mint a higher SIL. Failure modes, diagnostics, independence, common cause and the applicable tables still decide.

4. Gate 3 — Systematic capability

Gate 3 concerns failures that are not random wear-out stories: specification mistakes, software defects, configuration errors, manufacturing process issues, poor modification control, weak proof-test practice. These are systematic failures. Averaging λDU does not defend against them.

Systematic capability is how the standards ask whether the people, process and evidence behind the equipment and the SIF are strong enough for the claimed integrity. Certificates, safety manuals, proven-in-use arguments and lifecycle controls live here — and they must match the claim, not decorate it.

5. Why the weakest gate governs

Think of three doors in series. You only get through if all three open. If Gate 1 says SIL 3, Gate 2 says SIL 2 and Gate 3 says SIL 1, the honest claim is SIL 1 — or you change the design until the weak door moves.

That is not pessimism. That is how you keep functional safety from becoming marketing.

6. How to use this on Monday morning

1. Write the SIF in one sentence: detect → decide → act → safe state.
2. State the target SIL and risk basis explicitly.
3. Run the quantitative model with named assumptions.
4. Check architecture against the applicable route and tables.
5. Collect systematic capability evidence that matches the claim.
6. Report the governing (lowest) result — and which gate limited it.

If your report cannot say which gate limited the claim, it is not finished yet.