Every automotive safety team has a version of this story.
Six months into a program, a systems engineer opens the FMEA and realises the failure mode they're staring at was written for a contactor topology that no longer exists. The design changed in week three. Someone updated the schematic. Someone updated the requirements. Nobody updated the FMEA — or if they did, nobody checked whether that update propagated to the safety goals, the FSC, the verification plan, or the test coverage.
The FMEA looks like a document. It behaves like a snapshot.
This isn't a process failure. It's a structural one. And it's the part of safety case management that tooling has almost entirely ignored.
Generation Is the Easy Problem
The last few years have produced a wave of tools — and a lot of vendor excitement — around generating FMEAs. Feed in a system architecture, get out a failure mode table. Feed in an ECU spec, get out an ASIL assignment. It's genuinely useful, particularly for getting early-phase analysis off the ground quickly.
But generation solves maybe 20% of the problem.
The hard 80% is what happens after you generate it. It's:
- Consistency: Is the failure mode in the FMEA actually consistent with the hazard in the HARA, the safety goal in the FSC, and the safety requirement in the TSC? In most programs, these documents were written at different phases by different engineers and never formally reconciled.
- Propagation: When a design change happens — a new sensor, a revised actuation strategy, a software architecture refactor — which FMEA rows are affected? Which safety goals need re-evaluation? Which tests need to be re-run? In practice, this is answered by whoever happens to be in the room when the change is reviewed.
- Evidence: When an assessor asks "show me the rationale for why this failure mode is classified ASIL B and not ASIL C," can you trace that decision back to a specific analysis, a specific revision, a specific engineer approval? Or does it live in someone's email archive?
These aren't edge cases. They're the daily reality of functional safety programs in development — which means they're moving targets, not static ISO exercises.
The Problem Isn't the FMEA. It's the Data Model.
An FMEA in a spreadsheet is a table of claims: this component, in this operating mode, can fail in this way, with these effects, at this severity level. Those claims are only meaningful if they stay connected to the rest of the safety case — the hazards they contribute to, the safety goals they inform, the requirements they constrain, the tests that verify them.
A spreadsheet doesn't model those connections. It stores rows.
So when something upstream changes — a hazard reclassification, a new functional safety requirement, a revised system boundary — there's no mechanism to propagate the impact downstream. An engineer has to know to check the FMEA. Then they have to know which rows are affected. Then they have to update them manually. Then they have to update everything downstream of those rows, also manually.
This is why safety teams spend more time maintaining artifacts than reasoning about safety.
What a Living FMEA Actually Looks Like
The alternative is to treat the FMEA not as a document but as a structured layer in a connected safety graph — where failure modes are formal nodes with typed relationships to hazards, safety goals, FSC requirements, TSC requirements, and verification evidence.
In that model, a design change triggers something meaningful. If a BMS contactor is redesigned to add a welding detection circuit, the system can identify which failure modes reference that component, which safety goals those failure modes contribute to, which verification steps cover them, and which of those steps need to be revisited. The engineer sees a scoped impact analysis, not a blank spreadsheet and a responsibility to figure it out.
This is what Saphira builds — a structured safety graph where FMEA, HARA, FSC, and TSC aren't separate documents but connected layers of the same model. When the model changes, the impact surfaces automatically. Engineers spend time making safety decisions, not chasing document consistency.
The output still looks like the artifacts your assessors expect — the FMEA table, the safety case report, the clause-level traceability matrix. But the underlying structure means those artifacts stay consistent with each other, and every decision in them carries a rationale trail that's audit-defensible from day one.
What This Means at Program Scale
Teams we've worked with — across automotive OEMs, Tier-1 suppliers, and autonomous vehicle programs — describe the same inflection point: the moment a safety program goes from "we're generating artifacts" to "we're maintaining a living safety case." That transition is where most of the risk lives, and where most of the tool gaps show up.
A few patterns we've seen consistently:
Change management is tribal knowledge. The engineer who remembers that the ASIL assignment on failure mode 47 changed because of a specific assessor comment in Q3 is usually the same engineer who's the single point of failure for the whole analysis.
FMEAs and FTAs drift apart. In programs that run both, they're typically maintained by different teams using different tools with no formal reconciliation. The failure modes in one rarely match the basic events in the other, and neither team knows it until an assessor flags it.
Audit prep is a project, not a deliverable. Teams routinely spend weeks before a stage gate or functional safety assessment assembling evidence that should have been captured continuously. The work itself was done. The documentation of the work wasn't.
The Gap Worth Closing
If your team is generating FMEAs well — getting consistent, comprehensive failure mode analysis out of your system architecture — that's genuinely progress. The next question is whether those FMEAs stay connected to the rest of your safety case as the design evolves, and whether the evidence of that connection is something you can show an assessor on short notice.
That's the gap most teams haven't closed yet. And it's the one that determines whether your safety case is a living system or an archive of documents that were accurate once.
Saphira builds the safety infrastructure layer that keeps FMEA, HARA, FSC, and verification evidence consistent across a program's lifecycle. If this resonates with how your team is managing safety today, we'd love to show you what it looks like in practice — book a call.
