ForgeSDLC
Navigate
Home
Discover ForgeSDLC (101)
Practice (201)
Master (301)

This page is part of the ForgeSDLC knowledge base — an AI-assisted, human-directed methodology for taking product work from concept to production. For the core operating model and vocabulary, see Forge SDLC overview and What is ForgeSDLC?.

IEC 61508: Functional Safety of Electrical/Electronic Systems

Purpose: Summarize IEC 61508, the foundational functional safety standard for E/E/PE (electrical / electronic / programmable electronic) safety-related systems — lifecycle, SIL, methods, and mapping to sector standards.

Audience: Teams using safety/README.md and EMBEDDED-IOT.md.


Overview

IEC 61508 defines a full lifecycle approach: from concept through decommissioning, with verification, validation, and functional safety management. It is the parent of many domain-specific standards (automotive, rail, process, machinery adaptations).


Safety lifecycle phases

Phase Typical outputs
Concept Scope, context, high-level hazards
Overall scope definition Equipment under control (EUC), interfaces
Hazard & risk analysis Hazard log, initiating events
Overall safety requirements Safety functions, SIL targets
Safety requirements allocation Architecture, subsystem SIL
Design & development HW/SW per lifecycle models
Installation & commissioning FAT/SAT records
Operation & maintenance Procedures, proof tests
Modification Impact analysis, re-verification
Decommissioning Safe shutdown, data retention
flowchart TB subgraph left [Specification track] C[Concept] --> S[Scope] S --> H[HARA / Risk] H --> R[Safety requirements] R --> A[Allocation / architecture] end subgraph right [Realization track] A --> D[Design] D --> I[Implementation] I --> V[Verification] end V --> VAL[Validation] VAL --> OPS[Operation] OPS --> MOD[Modification] MOD --> DEC[Decommission] H -.->|feedback| H V -.->|evidence| VAL

SIL (Safety Integrity Level)

SIL Low demand mode
(PFDavg target order)
High demand / continuous
(PFH target order)
Indicative risk reduction factor
1 10⁻² to 10⁻¹ 10⁻⁵ to 10⁻⁶ ~10 to 100
2 10⁻³ to 10⁻² 10⁻⁶ to 10⁻⁷ ~100 to 1 000
3 10⁻⁴ to 10⁻³ 10⁻⁷ to 10⁻⁸ ~1 000 to 10 000
4 10⁻⁵ to 10⁻⁴ 10⁻⁸ to 10⁻⁹ ~10 000 to 100 000

Exact numeric targets are defined in the standard parts; use normative tables for certification work.

SIL Typical technique expectations (illustrative)
1 Structured methodology, basic testing
2 Stronger independence, FMEA, defined V-model
3 Diverse architecture, high diagnostic coverage, rigorous data
4 Maximum rigor; often physical separation, formal methods, exhaustive justification

SIL determination methods

Method Mechanism Strengths Caveats
Risk graph Calibrated parameters → SIL Fast workshop tool Calibration critical
LOPA Independent protection layers Quantitative-ish, auditable Needs scenario discipline
Risk matrix Severity × likelihood bands Communicates to management Can hide assumptions

Hardware architectural constraints (conceptual)

IEC 61508 Part 2 ties SIL to HFT (Hardware Fault Tolerance), SFF (Safe Failure Fraction), and diagnostic coverage for element types (Type A/B). Certified calculators and normative route tables should be used for compliance — the blueprint only orients.

Concept Meaning
HFT Extra channels to tolerate faults (1oo2, 2oo3, etc.)
SFF Fraction of failures leading to safe state vs dangerous
DC Diagnostic coverage — fraction of dangerous failures detected

Software requirements by SIL (illustrative)

Technique / evidence SIL 1 SIL 2 SIL 3 SIL 4
Coding standard Yes Yes Yes Yes
Static analysis Rec Rec Req Req
Dynamic testing Yes Yes Yes Yes
Data record & traceability Yes Yes Stricter Strictest
Formal methods Opt Opt Rec Rec/Req context-dependent
Independent verification Limited Increased High Highest

“Req/Rec” must be taken from normative tables in IEC 61508-3 for your SIL and software type.


V-model and safety analysis

flowchart LR subgraph left [Specification / realization] R[Overall / E/E safety requirements] A[Architecture / design] I[Implementation] end subgraph right [Verification / validation] UT[Unit / module test + analysis] IT[Integration test] ST[System test] AC[Acceptance / validation] end R --> A --> I I --> UT --> IT --> ST --> AC R -.->|safety verification plan| UT A -.->|FMEA / FTA updates| IT ST -.->|evidence to safety case| AC
Stage Safety analysis hooks
Requirements Traceability to hazards
Architecture Redundancy, separation, interfaces
Design FMEA on modules
Implementation Coding rules, reviews
Integration / test Fault injection where applicable
System validation End-to-end safety functions

Common cause failure (CCF)

Measure category Examples
Diversity Diverse SW, diverse sensors
Separation Physical / electrical isolation
Analysis β-factor models in Part 6; checklist-based scoring

Verification & validation techniques

Technique Typical use
FMEA Systematic failure modes per component
FTA Top-event logic, minimal cut sets
Reviews / walkthroughs Requirements and design
Simulation / HIL Dynamic behavior under faults
Statistical testing Reliability evidence where applicable

SIL raises the bar for independence of verification from design.


Competence (illustrative mapping)

Role SIL 1–2 SIL 3–4
Safety manager Trained FM Deep standard + project evidence
Safety assessor / verifier Independent Often organizational independence
Developer Aware of safety case MISRA-style discipline, evidence packs

Relationship to derivative / adjacent standards

Standard Domain Relationship to IEC 61508
ISO 26262 Automotive Adapted lifecycle, ASIL
IEC 62304 Medical SW Class A/B/C; risk (ISO 14971)
EN 50128 / EN 50657 Rail / road vehicles SIL software for rail
IEC 62443 Industrial cybersecurity Complements safety; not SIL replacement

Anti-patterns

Anti-pattern Effect
SIL chosen after build Unprovable architecture; costly rework
Uniform SIL everywhere Waste or false confidence
Paper compliance Fails assessment; no traceable tests

External references

Resource Notes
IEC 61508 (Parts 1–7) Normative — purchase via national bodies / IEC
TÜV / notified body guidance Certification interpretation
Safety Integrity Level Selection — Marszal & Scharpf SIL selection practice

Keep project-specific safety documentation in docs/safety/ and hazard analyses in docs/security/, not in this file.