From Spreadsheets to Simulation: How SLIKWORKS Rebuilds the FMEDA on Evidence

Introduction

The Failure Modes, Effects and Diagnostic Analysis (FMEDA) is where an ISO 26262 safety case gets its key numbers. It looks at each component, its possible failure modes, the effect of each failure on the safety goal, and whether a diagnostic can detect it. From this table, we calculate SPFM, LFM, and PMHF.

Yet for most teams, FMEDA is still a manually built spreadsheet. It can take weeks to create and is painful to update after a design change. The two hardest questions are:

• What does this failure do to the circuit?

• Would our diagnostics detect it?

Today, these questions are often answered using engineering experience and library defaults rather than actual evidence. That matters because while the failure rates in a traditional FMEDA can be traced back to standards (e.g. IEC 62380/ MIL-HDBK-217F etc.), the failure effects often cannot. For example, an open resistor can have completely different effects depending on where it is used. An open resistor on a reset line behaves very differently from an open resistor in a current-sense circuit.

We built the Simulation-based FMEDA module in SLIKWORKS around a simple idea: the circuit itself should provide the evidence.

What simulation-based FMEDA means

The idea is to replace judgment-based effect entries with measured and simulated circuit behavior. The analysis starts from the actual design artifact - the SPICE netlist, rather than a parts list transcribed into a spreadsheet. Because the netlist carries the topology, every component is analyzed in its role, never in isolation.

The workflow looks like this:

• Compute the failure rate. Each component's failure rate comes from recognized reliability standards, adjusted for its real operating conditions.

• Apportion it across failure modes. The rate is split across the component's standard failure modes per IEC 61709 Annex A, so every mode carries its own share of the failure rate (its λ, in FIT).

• Inject the fault. Every mode with a physical circuit representation short-circuit, opens, drifts, stuck-at conditions, is injected directly into the netlist.

• Simulate both circuits. The faulted circuit runs alongside an un-faulted "golden" run of the same design.

• Measure the effect. Comparing the two runs at the measured nodes yields the local effect as an observation: a DC shift here, an amplitude collapse there, or no visible deviation at all.

Because every mode already carries its failure rate, the results roll up into something a safety case can actually use: a failure-rate-weighted picture of detectability, not just "N of M faults changed a waveform."

Two principles to keep in mind with this approach.

First, not everything can be simulated, and the tool says so. Many standard failure modes have no circuit-level representation. In our system those modes are never silently dropped, each is recorded as excluded, with a reason, and its failure rate stays in the denominator. A coverage figure computed only over the convenient faults would be flattering and meaningless; ours is always presented as "coverage of X%, of the share we could examine."

Fig 1: Failure mode coverage based on simulation

Second, diagnostic coverage belongs to the safety mechanism, not the part. A simulation showing that a fault failure in a node proves the fault is observable, it does not prove a diagnostic exists to observe it. In SLIKWORKS, coverage can only ever be attributed to a safety mechanism the analyst has declared for the unit. The simulation result is treated as evidence supporting that judgment, never as the judgment itself.

How we built it

Turning this into software meant building a pipeline where every stage either computes from a standard, measures from the design, or defers to the analyst, and where every failure path degrades conservatively.

It begins at netlist import. The parser extracts the component inventory; parts it can classify deterministically, and anything resolved with AI assistance is flagged for human review. Simulation is gated on that review: injecting a fault based on an unconfirmed classification would produce a clean simulation of the wrong fault, which is worse than no simulation at all.

The failure-rate engine implements the standards as three simple stages. First, the base failure rate for the component (see Fig 2). Then, stress factors that adjust it for real operating conditions: temperature, voltage, environment. Finally, an apportionment that splits it across failure modes.

Fig 2: Parsing a netlist file and identifying the failure rate

Fault injection is a simple and predictable process: one failure mode goes in, and one faulted circuit comes out.

The injected faults represent real physical failures:

• A stuck-at fault forces a signal to stay at a fixed value, such as 0 or 1, no matter what the circuit is trying to do.

• An open-circuit fault represents a broken or disconnected connection, so the signal can no longer properly pass through.

The faulted circuits are then simulated in LTspice (see example of a circuit in Fig 3). First, the fault-free or golden circuit must simulate successfully. If it does not, the entire fault-injection campaign stops because the results cannot be trusted.

Fig 3: Example of a circuit for simulation based FMEDA

The results go into a live FMEDA sheet, which calculates SPFM, LFM, and PMHF for each system effect. The AI is intentionally limited. It can suggest whether a failure mode can cause a specific system effect, based on the simulation results. It can also suggest which safety measures already defined by the analyst could detect the failure.

The AI cannot create or invent new diagnostics. If it cannot make a clear decision, the row is marked unassessed and the full failure rate is included in the safety calculations.

This means an unreviewed or uncertain result can only make the safety numbers worse, never better.

Fig 4: Example of the resulting FMEDA

Fig 5: Example of HW metrics

Conclusion

Simulation-based FMEDA does not replace the analyst. It changes where the analyst spends their time.

The repetitive work in identifying failure rates, fault allocation, and fault-by-fault circuit behavior is calculated automatically and can be reproduced.

The result is an FMEDA where system effects are supported by actual simulation results instead of assumptions. Every number comes with its uncertainty, and when the design changes, the analysis can be repeated in hours instead of weeks. That is what we believe a safety case should be built on: evidence first, and expert judgment where it matters.