The 7-part structure
IEC 61508 splits cleanly along the hardware/software line — and that split is exactly why software FMEA needs its own treatment:
Highlighted: Part 1 (overall safety lifecycle, where hazard analysis sets SIL targets), Part 2 (hardware — FMEA's traditional home), and Part 3 (software requirements — where a software FMEA has to fit differently).
SIL: one scale, two kinds of failure
Both hardware and software are rated against the same Safety Integrity Level — SIL 1 through SIL 4 — but the standard treats their failure modes as fundamentally different in kind. Hardware fails randomly: components wear out, drift, or break, and that has a measurable rate. Software fails systematically: it does the same wrong thing every time it hits the same conditions, and no amount of run-time makes a design flaw more or less likely to exist.
Part 2 — where FMEA is native
In hardware, FMEA is the workhorse. It's how Safe Failure Fraction (SFF), hardware fault tolerance, and diagnostic coverage get calculated — walking each component's failure modes to determine whether it fails safely or dangerously, and how often. Its close cousin, FMEDA (Failure Modes, Effects, and Diagnostic Analysis), extends it to add detection: the resulting failure rates feed straight into PFDavg and PFH, the numbers that actually determine achieved SIL.
Part 3 — why FMEA doesn't just carry over
A quantitative FMEA needs a failure rate to work with, and software doesn't have one — there's no mean-time-between-failures for a logic error. That's the whole reason Part 3 doesn't lean on FMEA the way Part 2 does:
FMEA / FMEDA produces failure rates (per hour), Safe Failure Fraction, and diagnostic coverage — quantitative inputs straight into the PFDavg / PFH calculation.
No failure rate to compute. Instead, Part 3 leans on structured design, static analysis, and process rigor — techniques chosen and scaled by SIL through Annex A and Annex B, not by a probability calculation. Modern software FMEA methods such as SAE 1025 FMEA and IEEE 1633 assess the occurrence in objective measures such as the number of indepedent controls, whether or not the failure mode is explicitly tested and designed for and the repeatability of the failure mode.
Where software FMEA actually sits
Part 3's Annex A (techniques and measures for software development) and Annex B (nine detailed tables of design, coding, analysis, and testing techniques) are both required for compliance, and both scale by SIL using the standard's Highly Recommended / Recommended / Not Recommended ratings. A qualitative software FMEA sits here — as one of the structured analysis techniques teams can select to satisfy Part 3's failure-analysis objectives, alongside things like structured design methods, formal methods, and static analysis.
The software FMEA isn't named as mandatory the way an SFF calculation is for hardware — but at higher SILs, some form of systematic structural analysis is expected, and software FMEA is the most familiar way teams already know how to do it.
However, the team needs to focus on how software actually fails and not apply hardware-centric failure modes to software. The Common Defect Enumeration is a structured list of failure modes and root causes linked to hundreds of thousands of software failures. The CDE can be easily merged into the software FMEA as illustrated in the SAE 1025 FMEA and the IEEE 1633.
The team also needs to move away from the CSCI or shall statement viewpoint since failures spread across CSCIs and multiple shall statements. A systematic approach such as the 6D CDE focuses on the system effects of software failures.
What it has to produce
Since there's no failure rate to feed into a probability budget, the output that matters is evidence of systematic capability: a documented walk of the software's failure modes, their effects, and the design or process measure that controls each one — traceable back to the technique tables in Annex A/B and forward into the safety case's argument that systematic failure has been avoided or controlled, not just tested for.
The team must consider that software failures can and will cascade, repeat themselves and have few or no compensating provisions.
The 6D CDE Software FMEA is the modern and effective approach and is compatible with ISO 26262.