What SAE ARP5580 Software FMECA covers
Issued in July 2001 and reaffirmed — unchanged — in August 2020, ARP5580 lays out functional, interface, and detailed FMEA, plus pre-analysis planning and post-analysis documentation, applied across hardware, software, and process design. It was a genuine step forward at the time: earlier guidance like MIL-HDBK-338B barely mentioned software at all. ARP5580 at least introduced the idea of distinct software viewpoints.
But "introduced" is the operative word. It names a handful of software failure modes and gives limited examples — and twenty-plus years later, that's still all it offers.
The CSCI approach — and its faulty assumption
SAE ARP5580 also lays out the analysis in terms of the Computer Software Configuration Item (CSCI) — a hardware-derived unit borrowed straight from systems engineering's parts-and-assemblies mindset. The implicit assumption is that software fails the way hardware does: at the level of a discrete, physically-bounded "part," where you can point to the component that broke.
That assumption doesn't hold. A CSCI is a packaging and configuration-management boundary, not a failure boundary — software failure modes routinely cut across CSCI lines through shared data, timing, and interface behavior that a component-by-component breakdown was never built to see. Treating software like an assembly of parts is the same category error the rest of this series keeps running into: it's the hardware-centric habit that SAE1025 Section 7 was written specifically to break.
Three real problems with the approach
ARP5580 vs. the 6D CDE Software FMEA
Code-level, line-by-line analysis. Expensive to run, and even when finished, catches roughly a third of real failure modes — drawn from a short, generic, frequently-reused list.
Seeded from a Common Defect Enumeration built from nearly a million real software failure events, examined across six dimensions instead of code alone — identifying on the order of 100 times more critical failure modes for comparable effort. Automated in Requs AI Software FMEA.
The 6D CDE model
The core insight: software doesn't fail in a silo. A failure mode is rarely just a code defect — it's the product of how software, hardware, and the world around it interact. The 6D CDE evaluates each candidate failure mode across six dimensions:
Where ARP5580 stops at the code, the 6D model deliberately asks how a candidate failure mode plays out against the hardware it runs on, the system it's part of, the person using it, the mission it supports, and the environment it operates in. The 6D CDE software FMEA is fully automated in Requs AI Software FMEA.
What it actually catches that SAE ARP5580 Software FMEA doesn't
Code-level analysis implicitly assumes most defects originate in the code itself — which is exactly what a detailed, line-by-line FMEA is built to find.
Root-cause analysis of real failure events shows roughly 70% of defects don't originate in the code at all — they trace back to requirements, design, or the interactions the 6D model is built to examine.
Where this comes from
The 6D CDE Software FMEA is the same practitioner lineage running through the rest of this series — the Common Defect Enumeration behind SAE1025's Section 7, and the occurrence model IEEE 1633 adopted. It was built directly in response to gaps like SAE ARP5580 software FMEA: too expensive at the code level, too generic a failure-mode list, and no real answer for occurrence. Requs AI Software FMEA automates the entire software FMEA process providing even more value in an agile environment.