AI-Powered FMEA: Teaching Machines to Read a Diagram and Predict Failure

Failure Mode and Effects Analysis, or FMEA, is one of engineering's most important safety tools, also and one of its most tedious. In safety-critical industries like automotive and aerospace, building a single FMEA can take an experienced engineer weeks, and most of that time is spent not on analysis but on documentation: typing out failure modes, copying effects and causes, and arguing over risk scores.

At SafeLink Innovations, we asked a different question: what if an AI could read the system's architecture diagram and draft the FMEA itself? Our paper, "AI-Powered FMEA in the Safety-Critical Industry," presents the first systematic study of using large language models (LLMs) to do exactly that. This post explains what we built, what we found, and importantly, where the limits are.

A quick refresher on FMEA

FMEA is a bottom-up method (see more in this article). You take each component or function in a system, ask how it could fail, trace what effect that failure would have, and then score the risk. The industry-standard AIAG-VDA approach scores every failure mode on three dimensions : Severity, Occurrence, and Detectability (S/O/D), each on a 1–10 scale, which together determine how urgently it needs to be addressed.

The method is powerful, but its practical execution has well-known pain points. It's slow and manual. Engineers repeat near-identical documentation for similar failure modes. And scoring is inconsistent: two qualified engineers will often assign different S/O/D values to the same failure, because the judgment depends on experience, attention, and the standards in front of them. The result is that highly trained people spend their time on clerical work instead of engineering insight.

The core idea: don't make one AI do everything

The naive approach would be to paste a specification into a chatbot and ask for an FMEA. That fails, because FMEA isn't one task, instead it's several very different ones, from reading regulations to interpreting diagrams to reasoning about how failures propagate. Modern LLMs are good at all of these, but not equally, and not all at once.

So, our framework decomposes FMEA into three sequential stages, each matched to a distinct LLM strength, with each stage building on the one before it. The pipeline moves from knowledge extraction to architectural reasoning to predictive synthesis, and it's designed to be domain-agnostic, applicable to automotive (ISO 26262), aerospace (DO-178C, ARP4761), and general functional safety (IEC 61508) alike.

Stage 1: Reading the standards and documentation

The first stage builds a foundation of knowledge. The model parses the relevant safety standards to extract things like safety-integrity levels and hazard-classification criteria, and digests the project documentation, information like requirements, interfaces, operating conditions. The output is a structured knowledge base that grounds everything that follows. This is something LLMs do exceptionally well: pulling structured meaning out of dense, diverse documents.

Stage 2: Reading the architecture diagram

This is where the approach gets novel. Using the vision-language capabilities of modern LLMs, Stage 2 reads the system's actual architecture diagram, a block diagram, signal-flow diagram, P&ID, or schematic directly, regardless of which tool drew it. The model identifies components, classifies them by safety criticality, and traces the signals and interfaces between them. From there it maps dependencies: how a failure in one component cascades through the system, where the common-cause failures are, and which components are single points of failure. Crucially, it cross-checks everything against the Stage 1 knowledge base so the reading stays standards-aligned.

Stage 3: Predicting failures and scoring risk

The final stage synthesizes the first two into the FMEA itself. For each component, the model predicts credible failure modes, traces their effects through the dependency map built in Stage 2, and assigns S/O/D scores mapped explicitly to AIAG-VDA criteria. Every score comes with a rationale that traces back to specific evidence from the earlier stages, like a citation trail rather than a black-box number. The output is a complete, auditable FMEA matrix plus recommended mitigations.

Does it actually work?

We tested the framework with three leading models: Claude Sonnet 4, GPT-4o-mini, and Gemini 2.0, on a real driver-assistance system architecture, and validated every result against a ground truth built by an expert.

On Stage 1 document extraction, all three models performed near the top, around 96–97% accuracy. A human still edged them on raw accuracy (about 99%), but took roughly 30 minutes to do what the AI completed in under a minute, and the AI's output was more consistently structured.

On Stage 2 architecture analysis, Claude Sonnet 4 led the field, reaching about 92% accuracy on component identification and classification. Here we also found the framework's hardest problem: signal-relationship mapping, understanding how things connect, not just what they are, which topped out around 75%. LLMs, it turns out, are much better at recognizing objects than at reasoning about the relationships between them. That single finding is one of the most important in the paper, because it tells you precisely where human oversight is non-negotiable.

On Stage 3 failure prediction and scoring, the models differed, with the one offering the most usable context capacity handling complete, complex FMEAs best. Across the board, the LLMs won decisively on consistency, scale, and speed, while human experts retained the edge on deep domain nuance. Overall, the framework points to compressing FMEA development from roughly 4 - 6 weeks to 4 - 6 days, with early experiments suggesting even larger speed-ups on some systems.

The honest limitations

LLMs have domain-knowledge gaps. They can list common failure modes for, say, a LiDAR sensor, but a truly defensible list depends on the specific sensor type, its manufacturing process, and supplier quality, details a general model won't know. They can hallucinate plausible-but-wrong failure modes. They're sensitive to diagram quality, a messy drawing produces a messy analysis. And the regulatory path for AI-generated safety analysis is still being written.

These aren't reasons to avoid the technology; they're reasons to engineer around it. Grounding the model with retrieval over approved standards and historical FMEAs, requiring citations, constraining outputs to a fixed schema, and forcing the model to flag low-confidence items for review all sharply reduce the risks.

Why "human-in-the-loop" is the whole point

The headline of our work isn't automation, rather collaboration. The right division of labor is clear from the data: let the AI do the systematic, repetitive, fast work of extraction, drafting, and consistent scoring, and let human experts do what they're uniquely good at, like validating, contextualizing, and making the final call on safety-critical items. The staged design gives natural checkpoints for exactly that review.

Looking ahead, we see this maturing into a multi-model pipeline: a precise model for standards, a vision-strong model for diagrams, a long-context model for synthesis, and a lightweight "critic" model to cross-check the rest, backed by per-item confidence scores and targeted fine-tuning.

The bottom line

AI is not going to replace the safety engineer. But our research shows it can hand that engineer a strong, traceable first draft in minutes instead of weeks, freeing them to spend their expertise on judgment rather than transcription.

To read the full study, including the complete results and methodology, get in touch with us at info@safelinkinnovations.com