Schedule a Software Walkthrough Free Trial
Home / Software FMEA / States
FMEA Step 2 — State Transitions

State transitions

State-related failure modes are relatively common and relatively severe in consequence. The state transition table defines the top-level state table for the software — typically already captured in a system or software requirements specification.

Inputs

Worked example — a traffic light

Enter an “x” to denote that a transition is prohibited.

 
red
red
Red timer has not expired
yellow
Yellow timer has expired
green
x (prohibited)
 
yellow
red
x (prohibited)
yellow
Yellow timer has not expired
green
Green timer has expired
 
green
red
Red timer has expired, and the opposite lights aren’t green or yellow
yellow
x (prohibited)
green
Green timer has not expired

The state-related common defect enumerations are:

Failure mode ID
Description
Discussion / example
TL-SM-1
Prohibited state transitions are executed
The light turns yellow→green, red→yellow, or red→green
TL-SM-2
Valid transitions allowed under invalid conditions (a conditional prohibited transition)
The light turns red→green before the timer expires, or while the opposite light is green or yellow
TL-SM-3
States are stuck (dead state) — most common when an error state isn’t reset once corrected
The light stays red/yellow/green even though its timer has expired
TL-SM-4
The software is unstable after an unexpected loss of power in a particular state
Unstable state after power loss while the light was red, yellow, or green
TL-SM-5
The software is unstable after an unexpected user abort in a particular state
Doesn’t apply to a traffic light (no user abort) — engineers often fail to consider every state a user can abort from; sometimes the abort must be disabled entirely (e.g. during an OS upgrade).
TL-SM-6
The software is missing a fault or safe state
No faulted state exists — e.g. a blinking light for bad weather or a recent power loss
TL-SM-7
The software is missing a transition to a fault or safe state
No transition to a faulted state exists after a recent power loss
TL-SM-8
The fault/safe state behavior is inappropriate for the mission
All-sides solid or blinking green would be inappropriate on power loss; all-sides solid red would be safer
TL-SM-9
The software as a whole is missing a state
Could be missing blinking-yellow or blinking-red states entirely
TL-SM-10
The software as a whole is missing a state transition
No transition from red/green/yellow to the blinking states
TL-SM-11
The software commits a prohibited transition to a different feature (state machine) within the software
E.g. a state change intended for one light is applied to the wrong light in a series
TL-SM-12
The software accepts a prohibited transition from a different software feature
E.g. a state change from one light is incorrectly accepted by a different light
Outputs

What gets auto-generated

Saving the state table automatically generates rows for TL-SM-1 through TL-SM-5; the remaining CDEs are already in the worksheet and can be edited.

In the worked example: three prohibited transitions generate three TL-SM-1 rows, each analyzed individually since effects can differ dramatically (a green→red transition could be deadly; a red→yellow transition merely confusing). Six conditionally-prohibited transitions generate six TL-SM-2 rows. Three states generate three TL-SM-3 rows (the software can get stuck in any of them) and three each of TL-SM-4 and TL-SM-5 (power loss can occur in any state; TL-SM-5 doesn’t apply here since there’s no user).

TL-SM-6 through TL-SM-10 are auto-added since the example has no fault/safe state, no transition to one, and is missing an initializing state and its transition. TL-SM-11 and TL-SM-12 are auto-added to prompt the question of whether one light’s state machine could affect — or be affected by — a different light or an external device.

Continue the FMEA workflow.

Next, define the hardware and communication interfaces.

Define HW/Comm Interfaces → ← Back to Hazards