IEC 61508 is the international standard for functional safety of electrical, electronic and programmable electronic systems. For software teams it means a structured 16 phase lifecycle and testing rigour that rises with the target Safety Integrity Level (SIL), instead of build quickly and patch later.
What the standard is built on
Two principles: an engineering lifecycle aimed at finding and removing design errors, and a probabilistic treatment of how devices fail. The first edition appeared in 1998 to 2000 and the second in 2010. Many sector standards derive from it, including ISO 26262 for road vehicles, IEC 61511 for process industries, IEC 62061 for machinery and EN 50128 for rail.
The lifecycle in three groups
The safety lifecycle has 16 phases.
- Analysis (phases 1 to 5): understand the equipment and its environment, identify hazards, and define overall safety requirements.
- Realisation (phases 6 to 13): allocate safety functions, plan, design and build the safety related systems, and install, commission and validate them.
- Operation (phases 14 to 16): operate and maintain, modify, and eventually decommission.
Specific techniques are prescribed for each phase, because errors anywhere from concept to disposal can undermine a protective system.
What changes for code
Software testing depends on the SIL. The standard asks for testing at function level that exercises all branches and paths. At higher SILs it calls for modified condition and decision coverage (MC/DC) rather than simple branch coverage, which in practice needs a dedicated unit test tool. The MISRA C guidelines, which began in automotive work, are widely used in safety related embedded software.
A working pattern
- Know the target SIL for the function your code serves, and keep a trace from each requirement to design, code and test.
- Separate safety related code from the rest, so the strict process applies where it must.
- Use a coding standard and a static analysis gate, and make coverage evidence part of every build.
- Control change: every modification gets impact analysis before it is merged.
- Review independently, as the Therac-25 case showed (the lessons are here).
Gates in the pipeline
Pull request gates are a natural place to enforce these rules. The interactive demo shows how a gate blocks a merge until checks pass.
Click through it at your own pace, or open it full screen.
Safeguard policies and gates can block a pull request on defined conditions, such as new vulnerable dependencies. That supports the control the standard wants, but safety evidence itself still comes from your safety process.
Quick check
Does IEC 61508 apply to every embedded product?
No. It applies where a function is safety related. Other standards or regulations may govern your sector instead.
Is agile allowed?
The sources reviewed do not address this. Many teams combine iterative work with the required evidence and approvals, but confirm with your assessor.
Sources
Secondary summaries; the standard itself is authoritative.
Last reviewed: 19 October 2026.
