Software FMEA is not just DFMEA with software words.
That is why SAE 1025 - 2026 becomes an interesting standard to watch.
Most automotive teams understand FMEA through the familiar world of:
▪ Product design risk
▪ Process risk
▪ Cause and effect analysis
▪ Prevention and detection controls
▪ Action priority based improvement
AIAG VDA FMEA has created strong discipline in this area.
But software does not always fail like a part.
Software may fail because of:
▪ Wrong logic
▪ Missing condition
▪ Wrong timing
▪ Incorrect state transition
▪ Interface mismatch
▪ Data handling issue
▪ Diagnostic gap
▪ Fault not detected
▪ Fault detected but not handled correctly
For software intensive vehicles, the question is not only:
“What can fail?”
The better question is:
“What can the software do wrongly, not do, do too late, do too early, or do in the wrong state?”
That is a different mindset.
The publicly available scope of SAE 1025 explicitly includes FMEA with criticality analysis, design FMEA, supportability FMEA, software FMEA and process FMEA.
That does not make it a replacement for AIAG VDA FMEA.
But it does remind us that FMEA thinking must expand as vehicles become more software defined.
For SDV, EV, ADAS and connected vehicle programs, Software FMEA should connect with:
▪ Requirements
▪ Architecture
▪ Interfaces
▪ States and modes
▪ Diagnostics
▪ Safety mechanisms
▪ Cybersecurity assumptions
▪ Verification and validation evidence
▪ Field monitoring and software update strategy
My view is simple.
AIAG VDA FMEA remains highly relevant for automotive quality planning.
But software intensive products need stronger behaviour based failure thinking.
The future of FMEA will not be only about better templates.
It will be about better failure imagination.
Are our FMEA teams ready for software defined failure modes?
#FMEA #SoftwareFMEA #SAE1025 #AIAGVDAFMEA #SDV #AutomotiveQuality #FunctionalSafety
