The Software FMEA Guide

A practical guide to the modern 6-Dimensional Common Defect Enumeration (6D CDE) approach and example

Edge cases have a habit of showing up at the worst possible moment: during integration, in the field, or in an incident report. By then, fixing them costs far more than it would have at design time. Worse, teams tend to fix each one as a one-off, without seeing the pattern that produced it.

Software failure modes and effects analysis (SFMEA) is supposed to catch these problems early. In practice, many SFMEAs are slow, expensive, and miss the failures that matter. This guide explains why, and walks through an approach that grew out of more than 35 years of root-cause work on almost 1 million software failures.

Why traditional failure analysis misses software defects

It looks in the wrong places.Reviewing code line by line, or requirements one "shall" statement at a time, takes months or years and sees only a small slice of the defects. Most software failures live in the interfaces between components and in the design flows, not inside a single line or statement.
It doesn't look for the most likely culprits.Historically, most software failures trace back to a small set of functional root causes: faulty state management, error handling, timing, data, sequencing, usability, and so on. An analysis that doesn't target these directly relies on luck.
It starts from hardware assumptions.Hardware-centric risk tables assume random, independent failures. Software failures aren't random. One defect can fail every installation at once, a "minor" failure can become catastrophic when it repeats every minute, and failures can cascade across systems. Compensating provisions also mitigate fewer software failures than people expect.

Where you look for defects	Calendar time	Share of defects visible from this view	Better tool for this view
Each individual software requirement statement	Months to years	Under 9% are due entirely to a single specification	INCOSE-style requirements analyzers
Each line of code	Years to decades	Under 5% originate in a single line of code	Static code analyzers (Coverity, Fortify, LDRA)
Functions of code	Months to years	Under 30% originate in code functions	Static code analyzers

Our recommendation: let automated tools handle "shall" statements and code, and point human analysis at interfaces, states, flows, and sequences. That's where more than two-thirds of defects originate, and where 6D CDE focuses.

The common defect enumeration

The Common Defect Enumeration (CDE) is a structured list of generic root causes that have led to failures in mission- and safety-critical, software-intensive systems. It is built from our root-cause database, and it shows that history repeats itself: almost a million failures trace back to only about 200 unique root causes.

The CDEs are grouped by failure mode:

CDE family	Failure mode	Typical root cause
TL-SM	Faulty state management	Prohibited state transitions, stuck states
TL-EH	Faulty error handling	Failing to detect or handle faults in hardware, software, or communications
TL-FC	Faulty functionality	Something is missing from the software
TL-PR	Faulty processing	Can't handle peak loading or endurance
TL-T	Faulty timing	Timing requirements or mission times can't be met
TL-U	Faulty usability	Software leads the user into mission-critical mistakes
TL-DD	Faulty data	Mismatched units, scale, or type; corrupt or missing data
TL-SE	Faulty sequences	Functions execute out of order
TL-A	Faulty computations	Algorithm errors, or algorithms that don't match the customer spec
TL-ML	Faulty machine learning	Errors in the training population, ML process, or model

The six dimensions

Many edge cases come from tunnel vision. Software doesn't work, or fail, in a vacuum. The CDEs ask the analyst to look outward in six directions that are routinely overlooked:

1D Software

Other software components in the system, and how they can fail.

2D Electronics

The sensors and electronics the software depends on, and how they fail.

3D System

The larger system and how it must operate, including other subsystems and communications.

4D Users

The people who use the software, and what they need to get right.

5D Mission time

Mission duration and phases, including drift and accumulation over long runs.

6D Environment

Weather, radiation, power, and everything else surrounding the system.

Some CDEs cause unacceptable behavior when system faults arise. Others quietly accelerate hardware wear-out. Both kinds matter.

The process, step by step

Brainstorm the applicable CDEsWalk the CDEs across all six dimensions against your design models: state diagrams, sequence diagrams, activity diagrams. Defects are easier to see in models than in code or requirement text. No models? Defects in states, flows, and sequences still exist, and the analysis will still find them.
Connect each CDE to system effects and hazardsTrace the chain: specific root cause, local effect, next-level effect, system hazard. Keep it consistent with your functional hazard assessment or preliminary hazard analysis.
Assess likelihood and risk objectivelyAsk three questions. Is there an explicit test case for this failure mode? Is there an independent design control? Does it depend on other failures, and how likely are they? Use software-centric risk matrices such as those recommended in SAE and IEEE 1633 guidance.
Recommend actions and controlsCorrect the root cause in the design, add controls for the failure mechanism, and write the test cases that would have caught it. Update the models.
Generate the critical items list and track to closureCarry high-risk items through verification and validation until each one is closed.

Worked example: a smart traffic signal's timing loop

Consider an actuated intersection where a busy main street meets a quieter side street. The signal rests in main-street green. Detectors on the side street (inductive loops, video, or radar) place a "call" when a vehicle or cyclist arrives. The controller then times the main street down through yellow and all-red clearance, serves the side street for as long as traffic keeps arriving (up to a maximum), and returns to main-street green.

That timing logic is a closed control loop:

The timing control loop. The conflict monitor independently forces the signal into flashing red if it sees conflicting greens.

Step 1: Brainstorm CDEs against the state model

Because the timing loop is driven by states and sensors, state- and sensor-related CDEs come first. Here is the side-street portion of the controller's state diagram, as it might appear in a design model:

stateDiagram-v2
    direction LR
    state "Main green (rest)" as MG
    state "Main yellow" as MY
    state "All red" as AR1
    state "Side green" as SG
    state "Side yellow" as SY
    state "All red " as AR2
    [*] --> MG
    MG --> MY: side call AND main min green done
    MY --> AR1: yellow time elapsed
    AR1 --> SG: clearance elapsed
    SG --> SY: gap-out OR max green
    SY --> AR2: yellow time elapsed
    AR2 --> MG: clearance elapsed

As designed. The only way out of main-street green is a call from a side-street detector.

Walking the six dimensions across this model produces a list of candidate edge cases in minutes:

Dimension	Candidate edge case in the timing loop	CDE family
1D Software	Link to the central system drops and the controller keeps running a stale coordination plan, or jumps between plans mid-cycle.	TL-EH, TL-SE
2D Electronics	A side-street loop fails "off" (broken lead-in wire, pavement damage). No call is ever placed, so the controller never leaves main green.	TL-SM, TL-EH
2D Electronics	A loop fails "on" or chatters. Every cycle runs to max green, starving the main street.	TL-EH, TL-DD
3D System	Emergency-vehicle or railroad preemption arrives during yellow or all-red, and the transition truncates clearance time.	TL-SM, TL-T
4D Users	Cyclists and motorcycles are too small for the loop to detect, so they wait at a red that never changes.	TL-U, TL-FC
4D Users	Pedestrian clearance is timed for an average walking speed, leaving slower walkers in the crosswalk.	TL-U, TL-T
5D Mission time	Controller clock drifts over weeks, time-of-day plans shift, and coordination with neighboring signals degrades. Daylight-saving changes cause a double or skipped plan transition.	TL-T, TL-PR
6D Environment	Low sun glare, snow, or heavy rain blinds video detection, producing missing or phantom calls.	TL-EH, TL-DD

Notice that three different dimensions (a failed detector, an undetected cyclist, a blinded camera) all converge on the same flaw in the model: the transition out of main green trusts a single input absolutely. We'll follow that one through the rest of the process.

Generic root cause (state management, error handling)

Software can get stuck in a state because it doesn't detect that the sensor enabling the exit transition has failed.

Specific root cause

The controller is designed to leave main-street green only on a side-street detector call, with no check of detector health and no fallback recall.

Failure mechanism

The side-street detector fails "off" or can't see the road user, so no call is ever registered.

Step 2: Connect the root cause to the hazard

Read the chain from the bottom up, the same way the signal head stacks its lamps.

HazardRight-angle collision at the intersection

Next effectSide-street drivers and cyclists, after waiting indefinitely, proceed against the red

Local effectController stays in main-street green; side street is never served

Root causeExit from main green depends solely on one detector, with no health check or fallback

The conflict monitor won't intervene here: no conflicting greens are ever shown.

Step 3: Assess likelihood and risk

Is there an explicit test case for this failure mode?No

Acceptance tests verify that calls are served, not what happens when calls never arrive.

Is there an independent design control?No

The conflict monitor checks for conflicting indications, not for a starved phase.

Does it depend on other failures? How likely are they?One

A single detector failure is enough, and detectors are among the most failure-prone field devices. The 4D case (an undetected cyclist) needs no hardware failure at all.

LikelihoodHigh

SeverityCritical

RiskHigh

Over enough intersections and enough years, this edge case isn't a possibility. It's a certainty.

Step 4: Recommend actions and controls

Correct the root cause

Redesign the transition so the side street is also served when its detector is flagged faulty (fallback recall), or on a maximum wait timer.

Control the mechanism

Continuously monitor detector health: no activity for an unusually long period, constant presence, or erratic counts. On a fault, place a recall and alert maintenance.

Add the missing tests

Inject detector fail-off, fail-on, and chattering in hardware-in-the-loop tests, and test with a bicycle-sized target at each approach.

stateDiagram-v2
    direction LR
    state "Main green (rest)" as MG
    state "Main yellow" as MY
    state "Side green" as SG
    [*] --> MG
    MG --> MY: min green done AND (side call OR detector fault recall OR max wait)
    MY --> SG: yellow and all-red clearance
    SG --> MG: gap-out OR max green, then clearance

Revised model. The exit from main green no longer depends on a single input.

Step 5: Add it to the critical items list

Item	Root cause	Hazard	Risk before	Actions	Closure evidence
SIG-TIM-01	Main-green exit depends solely on side detector	Right-angle collision	High	Fallback recall, max-wait timer, detector diagnostics	Updated state model; HIL fault-injection tests pass; bicycle detection verified

Putting it to work

The whole example above took a single state diagram and a structured list of known root causes. No code review, no line-by-line analysis of requirements. That's the point: aim the analysis where defects actually come from, and let automated tools cover the rest.

We offer two ways to get started.

Training. Virtual self-guided classes follow a mission-critical system as the example throughout. Instructor-guided classes, virtual or on site, can use the same example or one from your own product. We believe in agile learning: learn a little, apply a little.

Requs AI Software FMEA Requs AI Edge Case brainstorms the CDEs that apply to your product from your models, and identifies controls and test cases for each edge case. Requs AI Software FMEA extends that by connecting each edge case to your hazards, computing objective likelihood, tailoring the output to almost any FMEA standard, and tracking items to closure.

Mission Ready Software
5011 Gate Parkway, Building 100, Suite 100, Jacksonville, FL 32256
missionreadysoftware.com
sales@missionreadysoftware.com