Where Software FMEA Fits

The 12-part structure

ISO 26262:2018 spans twelve parts, from vocabulary to motorcycle adaptation. Three of them are where a software FMEA actually lives:

Highlighted: Part 4 (system-level safety analysis), Part 6 (software architecture and design), and Part 9 (the ASIL-oriented and safety-oriented analysis methods, including FMEA).

ASIL: the rigor dial

Every safety-related element gets an Automotive Safety Integrity Level — QM, A, B, C, or D — derived from Severity, Exposure, and Controllability during hazard analysis and risk assessment. ASIL doesn't just set a target; it scales how rigorously every downstream activity, including software FMEA, needs to be performed. Higher ASIL means more thorough structural coverage, more independence in review, and less tolerance for undetected failure modes.

Part 9 — where "safety analyses" is actually defined

Part 9, Clause 8, "Safety analyses," is where the software FMEA fits into ISO 26262. ISO 26262 requires inductive analysis (bottom-up: given a failure mode, what happens?) and/or deductive analysis (top-down: given an unwanted event, what could cause it?) to support hazard identification and verify that the architecture meets its safety requirements.

FMEA is the standard's go-to example of an inductive method; Fault Tree Analysis is the deductive counterpart. In practice, most teams reach for the same DFMEA/PFMEA structure from the AIAG-VDA Handbook to satisfy this clause — ISO 26262 supplies the requirement, not the worksheet.

The 6D CDE Software FMEA is a modern software centric approach to software FMEA adopted in the SAE 1025 FMEA section 7 and the IEEE 1633. The 6D standards for the 6 dimensions of failure 1) software 2) electronics 3) system 4) user 5) mission 6) environment. Each of these 6 dimensions must be considered by the software. Focusing only on the code or the CSCIs isn't historically effective. The CDE is the Common Defect Enumeration which is a structured list of root causes for the world's software failures. It ensures that a broad range of root causes is considered for full safety and reliability coverage.

Part 6 — where software-specific analysis happens

Part 6 covers software architectural design, unit design, implementation, integration, and verification, following the same V-model as hardware. Its Annex E addresses safety analysis at the software architecture level — this is where a software FMEA is actually applied, walking the software elements to find design weaknesses that could cause single-point or multi-point faults.

The analysis follows the software's functional and processing chains, considering both static structure and dynamic (runtime) behavior — not just what the code looks like, but how it actually executes.

The 6D CDE differs from hardware-centric, "shall statement" or code level FMEAs because it considers the behavior within the context of the system.

What a software FMEA is expected to produce

Per Part 6's software-oriented analysis activities, a software FMEA at this level has three jobs, done in order:

ISO 26262 sets the requirement; it doesn't hand you the method