What Is IEC 61508? The Root Standard for Functional Safety Across Industries

If you work in automotive, industrial machinery, medical devices, or rail, you have almost certainly encountered a sector-specific functional safety standard. ISO 26262 governs road vehicles. IEC 62061 covers machinery. EN 50128 applies to railway software. IEC 60601 shapes medical electrical systems. These standards differ in terminology, sector context, and specific requirements—but they share a common ancestor.

IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems, is that ancestor. Published by the International Electrotechnical Commission and currently in its second edition (2010, with ongoing maintenance), it defines the vocabulary, the risk framework, and the process architecture that every derivative standard builds on. Understanding IEC 61508 is not an academic exercise. It is the fastest way to understand why sector standards are structured the way they are, and what they are actually trying to achieve.

What IEC 61508 Covers

The standard’s scope is defined by three types of systems: electrical (E), electronic (EE), and programmable electronic (PE) systems—collectively E/E/PE. This encompasses anything from a simple relay circuit to a complex embedded microcontroller running safety-critical software.

The standard is organized into seven parts:

• Parts 1–3 cover requirements: overall safety requirements (Part 1), requirements for E/E/PE safety-related systems (Part 2), and software requirements (Part 3).
• Parts 4–7 are informative or guidance: definitions and abbreviations (Part 4), risk determination methods (Part 5), guidelines for Parts 2 and 3 (Part 6), and an overview of techniques and measures (Part 7).

Parts 2 and 3 carry the real weight for engineering teams. Part 2 specifies what the hardware and system design must achieve. Part 3 specifies what the software development process must demonstrate. Both are organized around the concept of the safety lifecycle.

Safety Integrity Levels: Quantifying Required Risk Reduction

The most widely recognized concept from IEC 61508 is the Safety Integrity Level, or SIL. A SIL is a discrete level—1, 2, 3, or 4—that specifies the required probability of dangerous failure for a safety function over a given time frame.

The standard defines two failure modes:

Low demand mode: The safety function is activated infrequently (less than once per year). Risk is expressed as Probability of Failure on Demand (PFD). SIL 1 requires PFD ≥ 10⁻² and < 10⁻¹. SIL 4 requires PFD ≥ 10⁻⁵ and < 10⁻⁴.

High demand or continuous mode: The safety function operates continuously or is demanded frequently. Risk is expressed as Probability of Dangerous Failure per Hour (PFH). SIL 1 requires PFH ≥ 10⁻⁶ and < 10⁻⁵. SIL 4 requires PFH ≥ 10⁻⁹ and < 10⁻⁸.

These are not targets for the overall system failure rate. They are targets for the safety function specifically—the function that detects a hazard and brings the equipment to a safe state.

SIL assignment is the output of a risk analysis process. IEC 61508 Part 5 provides calibrated risk graph and risk matrix methods for determining which SIL applies to which safety function. The principle: the higher the severity and likelihood of the hazard the safety function is controlling, the higher the SIL required.

What engineers sometimes underestimate is that SIL is a claim about both random hardware failures and systematic failures. Random hardware failures are addressed through redundancy, diagnostic coverage, and component reliability data. Systematic failures—errors introduced by incorrect design, incorrect requirements, or incorrect implementation—are addressed through process rigor. This is where IEC 61508’s requirements on systematic capability become critical.

The Safety Lifecycle: IEC 61508’s Central Organizing Principle

IEC 61508 defines a safety lifecycle as the structured set of activities that must occur, in a defined sequence, to correctly specify, develop, validate, and maintain a safety-related system. The lifecycle begins at the point of hazard identification and does not end until the system is decommissioned.

The key phases, as defined in Part 1, Clause 6, are:

1. Concept: Define the scope of the E/E/PE system and identify hazards.
2. Overall scope definition: Establish what is and is not in scope for safety analysis.
3. Hazard and risk analysis: Identify hazardous events, estimate likelihood and consequence, determine required risk reduction.
4. Overall safety requirements: Specify functional safety requirements allocated to safety functions, and assign SIL targets.
5. Safety requirements allocation: Allocate safety requirements to the E/E/PE system, other risk reduction measures (e.g., administrative controls), and external risk reduction.
6. Overall planning: Develop plans for operation, maintenance, validation, and modification.
7. E/E/PE safety-related system realisation: The actual design, implementation, and integration work—governed by Parts 2 and 3.
8. Overall installation and commissioning: Verification that the installed system matches the design.
9. Overall safety validation: Confirm the installed system meets the overall safety requirements.
10. Overall operation and maintenance: Ongoing monitoring, periodic proof tests, change management.
11. Overall modification and retrofit: Structured change control maintaining safety integrity.
12. Decommissioning: Structured end-of-life with documented safety implications.

Each phase has defined inputs, defined activities, and required output documentation. Transitions between phases require verification—evidence that the outputs of one phase correctly and completely address the inputs to the next. This is not proceduralism for its own sake. It is a systematic defense against the class of failure that kills people: requirements that were never written down, design decisions that were never reviewed, assumptions that were never validated.

Systematic Capability: The Process Rigor Requirement

Random hardware failures can be modeled and reduced through redundancy and reliability engineering. Systematic failures are harder because they arise from human error in the specification, design, or implementation process—and they do not behave probabilistically. A software requirement that is ambiguous does not fail some percentage of the time; it consistently produces the wrong behavior in a specific scenario that may not be encountered until a safety-critical condition arises.

IEC 61508 addresses systematic failures through systematic capability ratings (SC 1–4, roughly corresponding to SIL 1–4). For a given SIL target, the development process must demonstrate a matching level of systematic capability. This means:

• Requirements must be complete, unambiguous, and verifiable.
• Traceability must be maintained from safety requirements through design, implementation, and test.
• Tools used in development must be qualified if their output is not independently verified.
• Reviews, inspections, and structured analysis techniques must be applied at defined points.
• Change management must maintain traceability integrity when requirements change.

Part 3, Annex A provides extensive tables of recommended and required techniques for software development at each SIL level. Static analysis, formal methods, structured programming, module testing—the selection and rigor of these techniques scales with SIL target. What ties them together is the requirement for documented evidence that they were performed correctly.

How Sector Standards Inherit IEC 61508

IEC 61508 explicitly permits sector-specific standards that follow its framework while adapting to a specific application domain. These are called “derived” or “sector” standards. The pattern is consistent across all of them:

ISO 26262 (road vehicles) maps IEC 61508’s SIL levels to Automotive Safety Integrity Levels (ASIL A–D), adapts the hazard analysis method to Automotive Hazard Analysis and Risk Assessment (HARA), and adds automotive-specific requirements for items and elements, safety goals, and the distinction between hardware metrics (SPFM, LFM, PMHF) and software process requirements.

IEC 62061 (machinery safety) applies IEC 61508’s framework to machines defined under the EU Machinery Directive. It adds the concept of a Safety-Related Control Function (SRCF) and provides specific guidance for combining subsystems with different SIL claims.

EN 50128 (railway software) inherits IEC 61508 Part 3’s software lifecycle and adapts it with railway-specific terminology (THR, SIL 0–4) and normative references to CENELEC practices.

IEC 60601-1 (medical electrical) incorporates risk management requirements that parallel IEC 61508’s hazard analysis concepts, though it references IEC 62304 for software specifically.

In each case, engineers familiar with IEC 61508’s vocabulary—SIL, safety lifecycle, systematic capability, functional safety management—can navigate the sector standard’s structure without starting from scratch. The adaptations are substantial and matter for compliance; the framework is shared.

From Standard Requirements to Engineering Practice

Here is where IEC 61508 moves from regulation to execution challenge. The standard tells you what you must achieve. It does not tell you which software to use or how to structure your requirements database. That gap is where most functional safety programs succeed or fail.

The standard’s requirements for systematic capability and traceability are, in practice, requirements about information management. Consider what Part 1 Clause 7.2 requires for the overall safety requirements specification: it must contain each safety function with its associated SIL, the required safe state for each safety function, the response time requirements, and references to the hazard analysis from which each requirement was derived. Multiply this across a complex system with hundreds of safety functions, multiple subsystem suppliers, and iterative design changes, and the information management challenge becomes immediately concrete.

Document-based approaches—Word, Excel, or even early-generation requirements tools—create problems specific to functional safety. Requirements spread across multiple documents become difficult to trace. Change propagation is manual and error-prone. When an auditor asks “show me all the safety requirements that changed in the last revision, and show me which tests cover them,” the answer requires a manual reconstruction process that takes days and introduces its own errors.

Graph-based requirements management platforms represent a different architecture. Instead of documents containing requirements, the database holds requirements as nodes, with typed relationships between them—derived-from, allocated-to, verified-by, implemented-in. Changes propagate through the graph. Impact analysis becomes a query, not a manual audit.

Flow Engineering (flowengineering.com) is built on this graph-based architecture, specifically for hardware and systems engineering teams operating under standards like IEC 61508 and its derivatives. The platform maintains live traceability from hazard analysis outputs through safety requirements, design specifications, and test cases. When a safety requirement changes, the graph immediately surfaces which design elements and tests are affected—which is exactly what IEC 61508’s change management requirements demand.

The systematic capability obligations in IEC 61508 Part 3 for software—particularly the requirements around requirements specification quality, review evidence, and configuration management—map directly to the kind of structured workflow that Flow Engineering enforces by platform design rather than by discipline alone. Requirements cannot exist without a defined type and status. Relationships between requirements and verification artifacts are explicit, not implied. Review and approval states are tracked on individual items, not on document versions.

This matters for audits and for the actual safety argument. When a TÜV assessor or notified body asks for evidence of systematic capability, the question is answered by the state of the requirements database, not by a collection of review meeting minutes stapled to a printed requirements document. The former is auditable and defensible. The latter is fragile.

Flow Engineering’s deliberate specialization in hardware and systems engineering—rather than general software development or quality management—means its data model reflects the concepts that matter for IEC 61508 compliance: safety functions, SIL allocations, verification relationships, and the interface between system-level and software-level requirements.

Practical Starting Points

If you are beginning IEC 61508 compliance work, or helping a team that is:

Start with Part 1, Clause 6 (the safety lifecycle overview) and Part 4 (definitions). Establish a shared vocabulary before discussing requirements or tools.

Determine your SIL targets before designing anything. The SIL drives every subsequent process decision. Doing hazard analysis late is the single most common functional safety program failure mode.

Map your existing documentation to the lifecycle phases. Most teams have something that functions as a hazard log, something that functions as a requirements specification, and something that functions as a test plan. Identifying what maps to what—and where the gaps are—gives you a concrete work plan.

Choose your requirements infrastructure before your design is mature. Migrating requirements from Word documents to a structured platform mid-project, under schedule pressure, is a painful and error-prone process. The infrastructure decision is a Phase 1 decision, not a Phase 6 one.

Treat traceability as a first-class deliverable, not a documentation afterthought. IEC 61508 assessors evaluate whether traceability is complete and current, not just whether it exists. A stale RTM is evidence of systematic capability failure, not compliance.

Honest Assessment

IEC 61508 is a demanding standard, and it is demanding for good reasons. The systems it governs—industrial safety systems, programmable logic controllers in process plants, safety-related software in complex machinery—have caused fatalities when they fail. The standard’s architecture reflects decades of incident analysis and hard learning.

The challenge for engineering teams is that the standard specifies outcomes and activities, not implementations. The gap between “requirements shall be unambiguous and verifiable” and an actual, auditable requirements database is filled by tool selection, process design, and organizational discipline. Graph-based, AI-native platforms close more of that gap by design than document-based tools can. The standard does not mandate any particular approach—but the evidence of systematic capability that auditors evaluate is much harder to produce from a flat document than from a structured, traceable database.

Understanding IEC 61508 as the root from which your sector standard grows is the first step. Building a process and tool architecture that can actually produce the required evidence is where the real engineering work begins.