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.
Glossary
Safety Integrity Level (SIL)

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.
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.
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.
| Metric | SIL 1 | SIL 2 | SIL 3 | SIL 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 |
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.
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.
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.
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.
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.
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.
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.
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.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Understanding Safety Integrity Level requires familiarity with the architectural patterns, standards, and system properties that enable deterministic safety functions in software-defined industrial control.
Mixed-Criticality System
A consolidated computing architecture where safety-critical functions (high SIL) and non-critical applications execute on a single hardware platform. The hypervisor enforces strict temporal and spatial isolation to prevent lower-criticality tasks from interfering with safety functions. This is the foundational architectural pattern enabling virtualized safety controllers.
Fault Tolerance (FT)
An operational design where a secondary redundant system executes in lockstep with the primary safety controller. Upon hardware failure, the secondary takes over instantaneously without loss of state. For SIL 3 and SIL 4 applications, fault tolerance is often a mandatory architectural requirement to achieve the necessary hardware fault tolerance (HFT) level.
CPU Pinning
The technique of binding a virtual machine or process thread exclusively to a dedicated physical processor core. In safety contexts, this eliminates cache misses and scheduling jitter that could cause a safety function to miss its deterministic deadline. Essential for achieving the temporal determinism required by high-SIL applications on consolidated hardware.
Real-Time Hypervisor
A bare-metal virtualization platform engineered to host both real-time operating systems (RTOS) and general-purpose operating systems on shared silicon. It guarantees microsecond-level latency for critical tasks through mechanisms like interrupt passthrough and deterministic scheduling. The enabler for virtualizing SIL-rated safety functions alongside non-safety workloads.
IEC 61131-3
The global standard defining the five programming languages for programmable logic controllers, including Ladder Diagram and Structured Text. Safety-related application software for SIL-rated functions is typically developed using a restricted subset of these languages with additional static analysis and formal verification requirements mandated by the safety lifecycle.

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.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us