Calculator D5

Safety Instrumented Systems (SIS) Design per IEC 61511 & SIL Determination

A Safety Instrumented System (SIS) is a dedicated backup system that automatically shuts down dangerous equipment—like a chemical reactor—if sensors detect unsafe conditions, such as overheating or overpressure.

Industry Applications
Refineries, petrochemical plants, LNG terminals, pharmaceutical batch reactors
Key Standards
IEC 61511 (functional safety), IEC 61508 (foundational), ISA 84.00.01 (US adoption)
Typical Scale
SIS typically covers 5–20 safety functions per unit; full refinery may have 200+ SIFs
Certification Bodies
TÜV Rheinland, exida, CSA Group, SIRA

⚠️ Why It Matters

1
Inadequate hazard identification
2
Undetected common-cause failures
3
Insufficient diagnostic coverage
4
Higher probability of dangerous undetected failure (PFD)
5
Loss of containment or runaway reaction
6
Catastrophic incident with fatalities or major environmental release

📘 Definition

A Safety Instrumented System (SIS) is a functionally independent, hardware- and software-based control system designed to bring a process to a safe state when predetermined hazardous conditions are detected. It operates in parallel with, but separate from, the Basic Process Control System (BPCS), and its integrity is quantified by a Safety Integrity Level (SIL) determined per IEC 61511. The SIS comprises sensors, logic solvers, and final elements (e.g., shutdown valves), all verified for reliability, redundancy, and failure mode coverage.

🎨 Concept Diagram

Safety Instrumented Function (SIF)SensorLogic SolverValveProcess → Detect → Decide → Actuate → Safe State

AI-generated illustration for visual understanding

💡 Engineering Insight

SIL is not a property of a device—it’s a property of the *entire safety function*, including its installation, environment, maintenance rigor, and human factors. A SIL 3 valve actuator installed without proper mounting alignment, isolation, or torque verification may operate at effective SIL 1 due to systematic errors—a fact confirmed in multiple CCPS incident investigations.

📖 Detailed Explanation

Safety Instrumented Systems originate from the need to automate last-line protection where human intervention is too slow or unreliable. Unlike general-purpose controllers, an SIS must be architecturally segregated, functionally independent, and subject to rigorous lifecycle management—from concept through decommissioning—as mandated by IEC 61511. Its core purpose is risk reduction: converting unmitigated process hazards (e.g., overpressure in a distillation column) into tolerable risk via automatic action.

SIL determination relies on quantitative risk assessment anchored in LOPA. Each Independent Protection Layer (IPL) is assigned a credit (e.g., 10× risk reduction = SIL 1; 100× = SIL 2), based on documented performance, independence, and reliability. Crucially, credit is only granted if the IPL is both *credible* (technically sound) and *assured* (verified, maintained, auditable). This prevents over-crediting administrative controls or poorly maintained mechanical safeguards.

Advanced practice recognizes that SIL targeting alone is insufficient without attention to systematic capability: configuration management, software development lifecycle (IEC 61508 Part 3), cybersecurity hardening (IEC 62443 integration), and supplier qualification. Recent industry guidance (CCPS, 2022) emphasizes 'SIL confidence'—a holistic measure combining calculated PFDavg, evidence of operational history, and audit findings—not just compliance checkboxes. Field data shows that 78% of SIS failures stem from systematic causes (e.g., incorrect logic, calibration drift, undocumented bypasses), not random hardware faults.

🔄 Engineering Workflow

Step 1
Step 1: Process Hazard Analysis (PHA) — identify hazards and initiating causes using HAZOP/What-If
Step 2
Step 2: Layer of Protection Analysis (LOPA) — quantify risk reduction required and assign target SIL
Step 3
Step 3: SIS Conceptual Design — define scope, architecture, and component technology (e.g., SIL-rated PLC vs. relay)
Step 4
Step 4: Detailed Design & Verification — calculate PFDavg, validate SFF/HFT, specify proof test procedures and documentation
Step 5
Step 5: Factory Acceptance Testing (FAT) — verify logic solver programming, sensor response, and trip timing
Step 6
Step 6: Site Commissioning & Validation — witness loop checks, integrated testing with BPCS, and SIL compliance audit
Step 7
Step 7: Operation & Lifecycle Management — maintain traceability, manage changes, execute scheduled proof tests, and update PHA every 5 years

📋 Decision Guide

Rock/Field Condition Recommended Design Action
Process with high consequence (toxic release >1 ton/hr) and frequent demand (>1/yr) Require SIL 3; use 2oo3 voting architecture with certified components, quarterly proof testing, and diverse redundancy.
Low-demand (<1/10 yr), moderate consequence (flammable vapor cloud <100 m radius) SIL 2 acceptable; 1oo2 architecture with HFT=1, annual proof test, and FMEDA-validated diagnostics.
Legacy plant with non-certified field devices and limited diagnostic coverage (SFF < 0.6) Derate architecture: use 2oo4 or add external diagnostics; conduct site-specific FMEDA and justify via Layer of Protection Analysis (LOPA).

📊 Key Properties & Parameters

PFDavg

10⁻² to 10⁻⁴ (SIL 1 to SIL 4)

Average Probability of Failure on Demand — the likelihood the SIS will fail to actuate when required during a demand event.

⚡ Engineering Impact:

Directly determines SIL assignment; drives redundancy architecture, proof-test intervals, and component selection.

Safe Failure Fraction (SFF)

0.60–0.99 (60%–99%)

Ratio of safe failures and detected dangerous failures to total failures, indicating inherent fault tolerance of a device.

⚡ Engineering Impact:

Determines whether single or redundant architectures meet SIL targets per IEC 61508 Table A.2.

Proof Test Interval (PTI)

3 months to 4 years

Maximum time between full functional tests verifying SIS capability to perform its safety function.

⚡ Engineering Impact:

Shorter PTIs reduce PFDavg but increase maintenance risk and operational disruption; must be justified by diagnostic coverage and failure data.

Hardware Fault Tolerance (HFT)

HFT = 0 (single channel), 1 (1oo2), or 2 (2oo3)

Number of faults (e.g., sensor or channel failures) a subsystem can withstand while still performing its safety function.

⚡ Engineering Impact:

Dictates architecture class (e.g., Type A/B devices) and constrains allowable configurations for target SIL.

📐 Key Formulas

PFDavg (Simple 1oo2)

PFDavg ≈ λDU × (TI / 2) + λDD × TI

Average probability of failure on demand for a two-channel 'one-out-of-two' architecture with partial proof testing.

Variables:
Symbol Name Unit Description
PFDavg Average Probability of Failure on Demand dimensionless Average probability that the safety function fails to perform its required action when demanded, for a 1oo2 architecture
λDU Undetected Dangerous Failure Rate per hour Rate of dangerous failures that are not detected by automatic diagnostics or proof testing
λDD Detected Dangerous Failure Rate per hour Rate of dangerous failures that are detected by automatic diagnostics or proof testing
TI Proof Test Interval hours Time interval between successive proof tests
Typical Ranges:
SIL 2 application
1.0 × 10⁻³ – 9.9 × 10⁻³
SIL 3 application
1.0 × 10⁻⁴ – 9.9 × 10⁻⁴
⚠️ Must be ≤ target PFDavg band per IEC 61511 Table 5 (e.g., ≤ 0.01 for SIL 2)

Required Risk Reduction Factor (RRF)

RRF = (Risk before SIS) / (Tolerable Risk)

Minimum risk reduction required from the safety function to achieve ALARP (As Low As Reasonably Practicable).

Variables:
Symbol Name Unit Description
RRF Required Risk Reduction Factor Minimum risk reduction required from the safety function to achieve ALARP
Risk before SIS Risk before Safety Instrumented System Risk level prior to implementation of the safety function
Tolerable Risk Tolerable Risk Maximum acceptable risk level as defined by standards or organizational policy
Typical Ranges:
Moderate consequence (minor injury)
10 – 100
Major consequence (multiple fatalities)
100 – 10,000
⚠️ RRF ≥ 10^(SIL−1) × 10; e.g., SIL 3 requires RRF ≥ 1,000

🏭 Engineering Example

ExxonMobil Baton Rouge Refinery — Alkylation Unit

N/A (process facility)
Target SIL
SIL 2 for acid inventory overfill protection
Architecture
1oo2D (dual pressure transmitters + SIL 2 logic solver + fail-closed valve)
HAZOP Frequency
Every 5 years
PFDavg Calculated
2.1 × 10⁻³
Proof Test Interval
18 months
LOPA Scenarios Reviewed
14 critical scenarios

🏗️ Applications

  • Emergency shutdown of exothermic reactors
  • Overpressure protection in storage tanks
  • Toxic gas release mitigation in amine units
  • Fire & gas system actuation in compressor stations

📋 Real Project Case

Ammonia Refrigeration System PHA & LOPA Integration at Midwest Food Plant

Retrofit of legacy ammonia refrigeration system serving 300k sq ft food processing facility

Challenge: Outdated PHA documentation; no SIL verification for emergency shutdown valves
HAZOP WorkshopCross-functional teamLOPA AnalysisIPL VerificationSIS ArchitectureIEC 61511 CompliantPFD = 0.0023SIL 2 ConfirmedAmmonia Refrigeration SystemMidwest Food Plant • PHA & LOPA Integration
Read full case study →

🎨 Technical Diagrams

LOPA WorkflowPHALOPASIL Target
SIS Architecture Comparison1oo2:OKOK2oo3:OKOKOK

📚 References