You have probably heard it in a HAZOP meeting: “We need SIL 2 for this.”
The discussion moves on. Everyone seems to agree. But what exactly has been agreed upon?
A required reduction in risk? A reliability target? A particular system architecture? Or simply a number that sounds reassuring?
Safety Integrity Level (SIL) is one of the most familiar terms in functional safety — and one of the easiest to misunderstand.
It is not a rating of how safe a plant is, nor a label that can be transferred from a certified device to an entire safety system. SIL expresses the integrity required of a specific safety function to deliver its allocated risk reduction.
1. A small story before the standard
Imagine a separator vessel. Its liquid level begins to rise. The control system responds, and an alarm alerts the operator. But suppose both measures fail. Liquid could carry over into equipment never designed to receive it.
The hazard analysis identifies the need for an independent Safety Instrumented Function (SIF): detect high-high level, process the signal through a safety logic solver and close the inlet emergency shutdown valve.
Now comes the question that defines the engineering challenge:
How reliably must this function work when it is needed?
“As reliably as possible” is not a measurable requirement. Neither is “whatever the vendor certificate supports.”
The answer must come from the risk assessment: the potential consequences, the likelihood of a demand, the effectiveness of other protection layers and the risk reduction allocated to this function.
That becomes the target SIL.
This is where functional safety becomes more than equipment selection. A risk identified during hazard analysis becomes a requirement that engineering must demonstrate can be met.
2. What SIL actually means
Safety Integrity Level is a discrete level used to specify the safety integrity requirements of a safety function. IEC 61508 defines four levels, SIL 1 through SIL 4, with progressively more demanding integrity requirements.
But two words deserve particular attention: required and achieved.
The target SIL is established through risk assessment and allocation. It represents what the function must deliver.
The achieved SIL is supported by verification of the implemented function against the applicable quantitative, architectural and systematic requirements.
One is the requirement. The other is the demonstrated capability.
Confusing them can turn an engineering requirement into an unsupported claim.
3. What do SIL 1, 2, 3 and 4 mean in numbers?
For low-demand operation — the usual process-industry case where the SIF is asked to act only when something goes wrong — SIL bands are commonly expressed using average probability of failure on demand, PFDavg. The reciprocal is the familiar risk reduction factor, RRF ≈ 1 / PFDavg.
For high-demand or continuous operation, the corresponding probabilistic measure is the average frequency of dangerous failure per hour, commonly written as PFH.
| SIL | Low-demand PFDavg | Approx. RRF | High / continuous PFH |
|---|---|---|---|
| SIL 1 | ≥ 10−2 to < 10−1 | > 10 to ≤ 100 | ≥ 10−6 to < 10−5 /h |
| SIL 2 | ≥ 10−3 to < 10−2 | > 100 to ≤ 1,000 | ≥ 10−7 to < 10−6 /h |
| SIL 3 | ≥ 10−4 to < 10−3 | > 1,000 to ≤ 10,000 | ≥ 10−8 to < 10−7 /h |
| SIL 4 | ≥ 10−5 to < 10−4 | > 10,000 to ≤ 100,000 | ≥ 10−9 to < 10−8 /h |
The table gives SIL its numerical meaning. But it also creates a common trap: treating a calculated probability as the entire SIL claim.
Suppose a low-demand SIF has a calculated PFDavg of 0.002. Its approximate risk reduction factor is 500, placing the result within the SIL 2 probability band.
Does that establish SIL 2?
Not yet.
The hardware architecture must satisfy the applicable constraints. The systematic integrity requirements must also be met. And the assumptions behind the reliability calculation must remain valid for the intended application.
A number in the correct range is an important result. It is not the complete engineering argument.
4. SIL belongs to a safety function, not a shopping list
A process-industry SIF is almost always a chain:
Consider a transmitter, logic solver and shutdown valve, each documented as suitable for SIL 2 applications.
Does connecting them create a SIL 2 safety function?
Not automatically.
Every subsystem contributes to the probability of dangerous failure. Architecture, voting arrangements, diagnostic coverage, common-cause failures, proof testing and repair assumptions all influence the result.
The final element may dominate the calculated PFDavg. The architecture may impose a lower integrity limit. Or a systematic requirement may remain unresolved.
This is why component certification is valuable evidence, but not the final answer.
A safety function does not inherit its SIL from its components. Its integrity must be demonstrated as a complete system.
5. What SIL is not
- Not a plant safety score. It is about one allocated safety function.
- Not a universal product badge. Device capability must still be applied correctly.
- Not PFDavg alone. Architecture and systematic capability also govern.
- Not a substitute for hazard analysis. SIL allocation follows required risk reduction.
- Not a promise of zero failure. It is a controlled integrity framework under stated assumptions.
These distinctions matter because SIL is easily reduced to a label.
Yet every SIL claim rests on decisions about risk, design, operating conditions, failure behaviour and supporting evidence.
Remove those assumptions, and the number loses much of its engineering meaning.
6. Where IEC 61508 and IEC 61511 fit
IEC 61508 provides the foundational functional safety framework for electrical, electronic and programmable electronic safety-related systems. It addresses the safety lifecycle, hardware and software integrity, systematic failures and architectural requirements.
IEC 61511 applies functional safety principles to Safety Instrumented Systems in the process industries.
Together, these standards connect activities that are sometimes treated as separate tasks: risk assessment, SIL allocation, safety requirements specification, design, verification, validation, operation, proof testing and modification.
But they are not independent paperwork exercises.
A safety requirement means little if the design does not implement it. A verification result means little if its assumptions are not maintained. And a successful calculation cannot compensate for a function that was incorrectly specified.
Functional safety is ultimately about maintaining that engineering connection throughout the lifecycle.
7. How to read a SIL result like an engineer
The next time you review a SIL verification report, look beyond the final number.
Ask:
What exactly has been demonstrated — and under which assumptions?
- Can you identify the complete safety function?
- Are the failure data and proof-test assumptions traceable?
- Are the architectural constraints satisfied?
- Is systematic integrity adequately addressed?
- Does the result actually meet the target established by risk assessment?
A credible report should allow another competent engineer to follow the reasoning, challenge the assumptions and understand what governs the final claim.
That transparency matters more than a polished certificate or a reassuring green indicator.
Because functional safety is not about producing the highest possible SIL number.
It is about demonstrating that the required protection can be relied upon.
The calculation provides a result. The engineering evidence gives that result meaning.
- International Electrotechnical Commission (IEC) — IEC 61508 functional-safety framework.
- IEC 61508-2:2010 — requirements for E/E/PE safety-related systems.
- UK HSE — Control systems — safety-related systems and integrity levels.
- UK HSE — Functional Safety Inspection Guide — SIL / PFDavg / RRF bands.