Inferensys

Glossary

Safety Integrity Level (SIL)

A discrete measure of the relative risk reduction provided by a safety function, defined by IEC 61508, that dictates the rigorous development and architectural requirements for safety-related control systems.
Risk analyst performing AI risk assessment on laptop, risk matrices visible, casual office risk session.
FUNCTIONAL SAFETY METRIC

What is Safety Integrity Level (SIL)?

A discrete measure of the relative risk reduction provided by a safety function, defined by IEC 61508, that dictates the rigorous development and architectural requirements for safety-related control systems.

Safety Integrity Level (SIL) is a discrete level (1 through 4) specifying the risk reduction factor a safety instrumented function (SIF) must achieve, as defined by the international functional safety standard IEC 61508. It quantifies the probability of a safety function failing on demand, with SIL 4 representing the highest integrity and a risk reduction factor exceeding 10,000.

Achieving a target SIL mandates strict adherence to architectural constraints like hardware fault tolerance (HFT) and safe failure fraction (SFF) calculations, alongside a rigorous software development lifecycle. In virtualized industrial control systems, maintaining SIL certification requires proving that the real-time hypervisor and shared hardware introduce no undetected systematic faults that compromise the deterministic execution of the safety logic.

IEC 61508 SAFETY INTEGRITY LEVELS

SIL Levels: Probability of Failure and Risk Reduction

Comparison of the four discrete Safety Integrity Levels defined by IEC 61508, specifying the target probability of failure on demand and the corresponding risk reduction factor for safety-related control functions.

MetricSIL 1SIL 2SIL 3SIL 4

Probability of Failure on Demand (Low Demand Mode)

≥10⁻² to <10⁻¹

≥10⁻³ to <10⁻²

≥10⁻⁴ to <10⁻³

≥10⁻⁵ to <10⁻⁴

Probability of Dangerous Failure per Hour (High Demand/Continuous Mode)

≥10⁻⁶ to <10⁻⁵

≥10⁻⁷ to <10⁻⁶

≥10⁻⁸ to <10⁻⁷

≥10⁻⁹ to <10⁻⁸

Risk Reduction Factor (RRF)

10 to 100

100 to 1,000

1,000 to 10,000

10,000 to 100,000

Safe Failure Fraction (SFF) Minimum for Type B Subsystems

60%

60%

60%

60%

Hardware Fault Tolerance (HFT) Minimum for Type B with SFF 60-90%

1
1
2
2

Hardware Fault Tolerance (HFT) Minimum for Type B with SFF >90%

0
1
1
2

Typical Architectural Constraint

Single channel with diagnostics

Redundant channels with diagnostics

Triple modular redundancy with voting

Triple modular redundancy with high-coverage diagnostics

Systematic Capability Requirement

SC 1

SC 2

SC 3

SC 4

IEC 61508 ARCHITECTURAL CONSTRAINTS

Core Architectural Requirements for SIL Compliance

Safety Integrity Level (SIL) is not merely a software quality metric; it dictates the hardware fault tolerance (HFT) and safe failure fraction (SFF) of the underlying architecture. These constraints define the minimum redundancy required for a safety function to achieve a specific risk reduction target.

01

Hardware Fault Tolerance (HFT)

HFT defines the number of dangerous faults a subsystem can sustain without losing its safety function. HFT = N means the system can tolerate N hardware failures.

  • HFT 0: A single fault causes loss of safety (typical for SIL 1/2).
  • HFT 1: Requires at least two channels (1oo2 architecture); one fault is tolerated (mandatory for SIL 3).
  • HFT 2: Requires triple modular redundancy; two faults tolerated (often required for SIL 4).

In virtualized environments, HFT must account for shared physical resources to ensure a single silicon fault doesn't cascade across redundant virtual PLCs.

HFT 1
Minimum for SIL 3
02

Safe Failure Fraction (SFF)

SFF is the ratio of safe failures plus detected dangerous failures to total failures. It determines the maximum SIL a subsystem can claim based on its diagnostic coverage.

  • SFF < 60%: Restricted to SIL 1 (Type A) or not allowed (Type B).
  • SFF 60%–90%: Permits SIL 2.
  • SFF 90%–99%: Permits SIL 3.
  • SFF > 99%: Required for SIL 4.

Achieving high SFF requires extensive diagnostic circuits and proof-test intervals that detect latent faults before a second fault creates a dangerous condition.

> 99%
SFF for SIL 4
03

Type A vs. Type B Subsystems

IEC 61508 classifies subsystems based on failure mode predictability.

  • Type A: Well-understood components with fully defined failure modes (e.g., relays, discrete transistors). Less stringent SFF requirements apply.
  • Type B: Complex components with undefined or partially defined failure modes (e.g., microprocessors, FPGAs, software). These require higher SFF or HFT to achieve the same SIL.

Virtualized controllers are inherently Type B due to the complexity of the hypervisor and host OS, demanding rigorous fault injection testing to validate failure mode assumptions.

Type B
Classification for Virtual PLCs
04

Spatial and Temporal Isolation

In mixed-criticality systems, safety functions must be strictly partitioned from non-safety workloads.

  • Spatial Isolation: Prevents a non-safety partition from writing to the memory space of a safety partition. Enforced by the hypervisor's memory management unit (MMU).
  • Temporal Isolation: Guarantees the safety partition receives its allocated CPU time slice deterministically, regardless of non-safety workload demand. Enforced by a real-time scheduler.

Without verified isolation, a denial-of-service in a non-critical container could starve a SIL 3 control loop, violating the safety requirement.

< 10 µs
Max Scheduling Jitter
05

Proof Test Interval (PTI)

The PTI is the scheduled period between manual or automatic diagnostic tests designed to reveal undetected dangerous faults. The SFF calculation directly depends on the PTI.

  • A shorter PTI increases diagnostic coverage, improving SFF.
  • Automatic diagnostics (continuous monitoring) can reduce or eliminate the need for manual proof tests.
  • In virtualized safety systems, the hypervisor can automate proof tests by injecting fault conditions into redundant channels during runtime without stopping production.
Continuous
Ideal Diagnostic Coverage
06

Systematic Capability (SC)

While HFT and SFF address random hardware failures, Systematic Capability addresses design and human errors. SC defines the maximum SIL a component can claim based on the rigor of its development process.

  • SC 1: Basic quality management.
  • SC 2: Formal specification and structured design.
  • SC 3: Formal methods, semi-formal verification, and extensive static analysis.

A virtual PLC must demonstrate SC 3 to be used in a SIL 3 safety function, requiring a certified development lifecycle for both the hypervisor and the control runtime.

SC 3
Required for SIL 3
SAFETY INTEGRITY LEVEL CLARIFIED

Frequently Asked Questions

Precise answers to the most common technical questions about SIL determination, architectural constraints, and the implications of IEC 61508 for software-defined industrial systems.

A Safety Integrity Level (SIL) is a discrete measure of the relative risk reduction provided by a safety function, defined by the IEC 61508 standard. It is determined through a rigorous risk assessment process that quantifies the required risk reduction for a specific hazardous event. The determination involves analyzing the severity of potential harm, the frequency and duration of exposure, the possibility of avoiding the hazard, and the probability of the hazardous event occurring. This analysis yields a target SIL, ranging from SIL 1 (the lowest integrity, requiring a risk reduction factor of 10 to 100) to SIL 4 (the highest, requiring a risk reduction factor of 10,000 to 100,000). The assigned SIL then dictates the entire lifecycle of the safety function, from design and development to validation and maintenance, imposing increasingly stringent requirements for architectural redundancy and systematic capability.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.