What Is a Safety Integrity Level (SIL) and How Is It Assigned

Safety Integrity Level is not a marketing designation or a general quality indicator. It is a quantitative target — defined in IEC 61508 — for the probability that a safety function will fail to perform its required action on demand, or fail dangerously over time. Every obligation that flows from a SIL rating — the hardware redundancy rules, the software development constraints, the verification coverage requirements — derives from that quantitative core.

If your team works in process automation, industrial robotics, functional safety for energy systems, or any industrial domain where IEC 61508 or one of its sector derivatives applies, understanding SIL precisely is not optional. Misunderstanding it produces either over-engineered systems that cost too much, or under-engineered systems that fail to satisfy regulator or notified body requirements during assessment.

The Four SIL Levels: What the Numbers Mean

IEC 61508 defines four Safety Integrity Levels. Each level specifies a target range for the Probability of Failure on Demand (PFD) for low-demand safety functions, and a Probability of Failure per Hour (PFH) for high-demand or continuous-mode functions.

SIL	PFD (low demand)	PFH (high demand / continuous)
1	10⁻² to 10⁻¹	10⁻⁶ to 10⁻⁵ per hour
2	10⁻³ to 10⁻²	10⁻⁷ to 10⁻⁶ per hour
3	10⁻⁴ to 10⁻³	10⁻⁸ to 10⁻⁷ per hour
4	10⁻⁵ to 10⁻⁴	10⁻⁹ to 10⁻⁸ per hour

SIL 4 is reserved for sectors where the consequence of failure is catastrophic and irreversible — nuclear reactor protection is the canonical example. The process industries (IEC 61511) and machinery sector (IEC 62061) cap their normative scope at SIL 3 and SIL 2 respectively in common industrial applications, though the underlying framework extends to SIL 4.

Each SIL level is one order of magnitude stricter than the previous. That gap is not cosmetic — it drives concrete differences in how hardware is architected, how software is developed, and how verification must be structured.

How SIL Is Assigned: Risk Analysis Methods

SIL is not selected by the safety engineer’s judgment or by convention in a given industry. It must be determined through documented risk analysis that starts from hazard identification and ends at a target risk reduction figure. Two methods dominate industrial practice.

Risk Graph

The risk graph method, described in IEC 61508-5 Annex D and widely used in IEC 61511 applications, is a semi-quantitative approach. It evaluates four parameters for each identified hazard:

• Consequence (C): Severity of harm, from minor injury to catastrophic multiple fatalities.
• Frequency and exposure time (F): How often personnel or assets are exposed to the hazard.
• Probability of avoiding the hazard (P): Whether the hazardous event can be detected and escaped once initiated.
• Demand rate (W): How often the hazardous event would occur without the safety function in place.

Each parameter has defined levels (C1/C2, F1/F2, P1/P2, W1/W2/W3). Traversing the risk graph from consequence through the other parameters produces a SIL recommendation — or a finding that no instrumented protective function is required. The risk graph is faster and well-suited to early-phase HAZOP studies where precise frequency data is unavailable.

Layer of Protection Analysis (LOPA)

LOPA is more rigorous and more quantitative. It starts from an initiating event with an estimated frequency (events per year), identifies all independent protection layers (IPLs) between the initiating event and the consequence, assigns a probability of failure on demand to each IPL, and calculates the mitigated consequence frequency.

The Safety Instrumented Function (SIF) being evaluated is assigned the SIL required to close the gap between the mitigated frequency (excluding the SIF) and the tolerable risk target. LOPA is the method preferred by regulators in the process industries for SIL 2 and above, and it is mandatory in many jurisdictions for SIL 3 functions.

Both methods require documented hazard identification — typically from a HAZOP or FMEA — before they can begin. The risk analysis is not a downstream activity. It must precede requirements allocation.

What a SIL Rating Actually Demands

Once a SIL target is assigned to a safety function, it imposes obligations across three distinct dimensions. These are independent requirements — satisfying one does not substitute for the others.

Hardware Architectural Constraints

IEC 61508 Part 2 specifies two hardware metrics that must be achieved independently of the PFD calculation:

Safe Failure Fraction (SFF) is the proportion of failure modes that are either safe or detected. A higher SFF means more of the system’s failures announce themselves rather than hiding until the safety function is demanded.

Hardware Fault Tolerance (HFT) is the number of faults a subsystem can tolerate while still performing its safety function. HFT 0 means a single fault can cause loss of function; HFT 1 requires two simultaneous faults before loss occurs.

IEC 61508-2 defines architectural constraints as a function of SIL and element type (Type A — fully characterized failure modes, Type B — not fully characterized). For example, a Type B subsystem targeting SIL 3 requires HFT 1 (one-fault tolerant redundancy) and SFF ≥ 90%. These constraints are not negotiable through additional software testing or argument alone.

This is why SIL 2 and SIL 3 process safety instrumented systems routinely appear in 1oo2D (one-out-of-two with diagnostics) or 2oo3 voting architectures. The architecture is demanded by the standard, not invented by the designer.

Software Safety Integrity Requirements

IEC 61508 Part 3 specifies software requirements as a function of SIL. Unlike hardware, software has no safe failure fraction — a software fault is either latent and undetected, or exposed. The standard therefore focuses on development rigor and verification coverage.

Higher SIL levels demand more stringent techniques at each phase:

• SIL 1: Structured programming, code reviews, dynamic testing.
• SIL 2: Adds formal design methods, static analysis, coverage measurement (MC/DC coverage at SIL 3/4).
• SIL 3: Adds formal verification for critical modules, independence between development and verification teams, documented tool qualification for any automated tools used in the process.
• SIL 4: Near-exhaustive formal methods, maximum independence constraints, and full traceability from system requirement to test result.

Tool qualification deserves specific attention. If your team uses a compiler, static analyzer, or requirements management tool as part of evidence generation, that tool must be qualified under IEC 61508-3 Annex D or an equivalent approach. This is a common gap in SIL 3 and SIL 4 programs.

Verification Coverage and Evidence

The standard requires that every safety requirement be verified and that verification results be traceable to requirements. This means:

• A complete Safety Requirements Specification (SRS) for each safety function
• Traceability from SRS requirements to design elements
• Traceability from design elements to test cases
• Evidence that tests were executed and results recorded
• Independence review of the evidence package at SIL 3 and SIL 4

The evidence package — sometimes called the functional safety assessment deliverable — is what a notified body or independent safety assessor actually examines. A system can be technically sound and still fail assessment if the evidence is incomplete or traceability is broken.

SIL vs. ASIL: Not the Same Framework

Automotive Safety Integrity Level (ASIL), defined in ISO 26262, is frequently confused with SIL. Both concepts measure safety integrity, both express it in levels (ASIL A through D), and both derive from a common ancestor in IEC 61508. They are not interchangeable.

The key differences:

Risk parameters: ASIL is determined from severity, exposure, and controllability — a three-parameter model. SIL is determined from consequence, frequency, probability of avoidance, and demand rate — a four-parameter model with different definitions.

Target domains: ISO 26262 applies to road vehicles and has sector-specific provisions for software, hardware, and the automotive development lifecycle (including AUTOSAR and relevant toolchains). IEC 61508 is the base standard for process, machinery, and general industrial applications.

Development lifecycle: ISO 26262 defines an automotive-specific V-model with phase-gate requirements. IEC 61508 is more principle-based and allows lifecycle flexibility, which the sector derivatives (IEC 61511, IEC 62061) constrain further.

Mapping ASIL D to SIL 3 (a common informal equivalence cited in cross-domain discussions) is technically arguable but must be formally justified for any specific project. Regulators in neither domain accept informal mapping as a substitute for domain-specific analysis.

How Modern Requirements Platforms Support SIL Programs

The obligations described above — structured risk analysis, hardware architectural constraints, software rigor, full traceability from hazard to test — generate a volume of interconnected requirements that exceeds what document-based tooling can reliably manage at SIL 2 and above.

A requirements document can state a SIL assignment. It cannot enforce that every derived software requirement carries the SIL attribute forward, that every design change is assessed for impact on the safety case, or that traceability gaps are detected before an assessor finds them. These are structural problems that require structural solutions.

Flow Engineering (flowengineering.com) is built around a graph-based model of requirements rather than a document hierarchy. In a graph model, every requirement is a node with typed relationships — derived-from, allocated-to, verified-by — rather than a paragraph in a numbered section. This matters for SIL programs in several concrete ways.

For process automation and energy systems teams, where safety functions are often distributed across multiple subsystems with shared hazard roots, the graph structure makes it possible to trace a SIL 3 requirement through its allocation to hardware and software subsystems, through design elements, and into test cases — and to query that trace automatically. When a requirement changes (the SRS is revised after a process hazard review, for example), the graph immediately surfaces all downstream nodes that depend on it, enabling systematic impact assessment rather than manual search through linked documents.

Flow Engineering also supports custom attributes at the requirement node level — making it practical to tag requirements with SIL level, verification method, responsible engineer, and verification status as structured data rather than free-text metadata. Those attributes can be queried across the model, which means generating a traceability matrix for a safety assessment becomes a report from a live model rather than a manually assembled spreadsheet.

For teams managing both SIL-rated safety functions and non-safety functionality in the same system — common in industrial robotics and process control — the platform’s filtering and view capabilities allow the safety-critical subset of requirements to be isolated and reviewed independently, without maintaining separate document sets that drift out of sync.

Flow Engineering’s focus is on requirements modeling and traceability. It does not replace a HAZOP tool, a reliability calculation package, or a formal verification environment. Teams still need domain-specific tools for quantitative risk analysis and hardware reliability prediction. What Flow Engineering addresses is the requirements management and traceability layer — which is where most SIL evidence packages break down under assessment scrutiny.

Practical Starting Points

If your team is beginning a SIL-rated development program, the sequence that causes the fewest downstream problems:

1. Complete hazard identification before allocating SIL. Running HAZOP or FMEA after the architecture is fixed produces SIL targets that the architecture cannot meet, requiring expensive redesign.

2. Document the risk analysis method and its inputs. The SIL assignment must be reproducible from documented inputs. A risk graph output without documented parameter justification is not defensible under assessment.

3. Establish the SRS before hardware architecture selection. The SRS defines what the safety function must do. Hardware architecture selection — including redundancy topology — follows from the SIL target and the SRS, not the other way around.

4. Set up traceability infrastructure before requirements are written. Retrofitting traceability into a completed requirements set is slow, error-prone, and produces incomplete evidence. Graph-based tools like Flow Engineering are most valuable when adopted at program initiation.

5. Plan for tool qualification early. Every automated tool that touches safety-critical deliverables needs a qualification argument. Identify those tools in the first month of the program, not six weeks before assessment.

SIL is not a certification you receive at the end of a program. It is a discipline applied throughout development. The evidence package that an assessor reviews is the artifact of that discipline — and it shows exactly how rigorously the discipline was applied.