Digital FMEA: AIAG-VDA 7-Step Method, Knowledge Graphs and the PLM Digital Thread

Most failure mode and effects analyses are born as a spreadsheet, reviewed once in a workshop, signed, and never opened again. The product then ships, field data arrives, engineering changes pile up, and the document that was supposed to hold the company’s risk knowledge quietly drifts away from the real design. That drift is the real defect in FMEA practice, not any single wrong rating.

Digital FMEA treats the analysis as structured, linked data instead of a table of free text: every element, function, failure mode, cause and control is a node with an identity, connected to requirements, the bill of materials, the control plan and field returns. This matters in 2026 because the AIAG-VDA method gives us the vocabulary (structure, function and failure nets), connected PLM and IoT platforms give us the data, and language models make drafting cheaper than ever, which makes governance the hard part.

You will leave with the seven steps in practical detail, a clear explanation of why the Risk Priority Number failed and what Action Priority does instead, a property-graph data model with Cypher, runnable Python for a failure net and a Bayesian occurrence update, and a candid view of where LLM drafting helps and where it hurts.

What this covers: the AIAG-VDA method, Action Priority, DFMEA vs PFMEA vs FMEA-MSR, the knowledge-graph model, the PLM digital thread, closing the loop with IoT data, tooling, and failure modes of the whole approach.

Context and Background

Failure mode and effects analysis is one of the oldest structured reliability techniques. The generic international standard is IEC 60812, whose third edition (2018) cancels and replaces the 2006 edition and describes how to plan, perform, document and maintain FMEA and its criticality-ranking variant FMECA, across hardware, software, human-action processes and their interfaces (IEC 60812:2018 at the IEC webstore). IEC 60812 is deliberately generic. It does not prescribe rating tables for a particular industry, which is why sector handbooks matter.

In automotive, the dominant handbook is the AIAG and VDA FMEA Handbook, released jointly in 2019 by the Automotive Industry Action Group (North America) and the Verband der Automobilindustrie (Germany). It replaced the earlier four-step, RPN-based practice with a seven-step method, introduced Action Priority in place of the Risk Priority Number, reworked the severity, occurrence and detection tables, and added a supplemental FMEA for Monitoring and System Response (FMEA-MSR) (overview of what changed). Because OEM customer-specific requirements commonly point suppliers at this handbook, it has become a de facto reference well outside cars.

Other sectors layer their own rules on the same idea. Functional safety work under ISO 26262 uses FMEA-type analyses as one input to safety analysis, and medical device risk management under ISO 14971:2019 treats FMEA as one technique feeding hazard analysis rather than as the risk process itself. I come back to both below.

The tooling market splits into spreadsheets, dedicated FMEA applications (for example APIS IQ-FMEA and Relyence, which advertises AIAG-VDA worksheets, Action Priority and an FMEA-MSR template (Relyence AIAG-VDA FMEA)), and quality modules inside PLM suites such as Siemens Teamcenter Quality. Most of these store the FMEA in a document-shaped model: a worksheet with rows. That is a problem when you want to ask a graph-shaped question like “which failure causes are shared across three product variants and tied to the same supplier lot?”

This post sits next to a few related pieces on this site. If your requirements live in a model, read the SysML v2 and MBSE integration with PLM tutorial first, because FMEA functions should trace to those requirements. If you are deciding where the FMEA data will live, the comparison of Teamcenter X, 3DEXPERIENCE and Windchill covers the platform side. And for the field-data loop, see remaining useful life prediction with Weibull, survival models, LSTM and Kalman filters.

The AIAG-VDA Seven-Step Method as a Data Pipeline

The core idea of this post is simple: each of the seven steps produces a specific kind of data, and a digital FMEA is what you get when you store those outputs as typed, linked records rather than as cells. If you remember one thing, remember that the method is already a graph; the worksheet is just a lossy printout of it.

Direct answer: Digital FMEA is the practice of storing AIAG-VDA FMEA content as linked, versioned data (structure, function and failure nets) tied to requirements, BOM, control plans and field data, so that risk analysis updates when the design or the field evidence changes instead of being re-typed.

Figure 1: Digital FMEA reference architecture. The seven AIAG-VDA steps write into a shared property graph that PLM, requirements and IoT field data read from and update.

The figure shows the seven steps on the left feeding a graph store in the middle, with upstream sources (requirements, BOM, process flow) feeding structure and function analysis, and downstream consumers (control plan, work instructions, field monitoring) reading from risk analysis and optimization. The loop back from field data into occurrence ratings is what separates a digital FMEA from a digitised one.

Steps 1 to 3: Planning, Structure and Function

Step 1, planning and preparation, defines what the FMEA is for. The handbook frames this with the “5T” idea: InTent, Timing, Team, Task and Tool. In data terms, this step creates the analysis scope record: which product or process, which revision, which baseline of the BOM, which customer requirements, and who is on the team. If you skip modelling this, you cannot answer later why a rating was set, because you lost the baseline it applied to.

Step 2, structure analysis, decomposes the system into elements: system, subsystem, component for a DFMEA; process item, process step, process work element for a PFMEA. This is a tree, and in a PLM environment it should not be re-drawn by hand. The mechanical or system structure already exists as an engineering BOM or a SysML block definition. A digital FMEA imports it and keeps a stable identifier on each element, so a part renumbering does not orphan its failure data.

Step 3, function analysis, assigns functions and requirements to each structure element and links them vertically: a component function contributes to a subsystem function, which contributes to a system function. These links are what later let a cause on a seal propagate to an effect at vehicle level. The handbook uses function trees and parameter diagrams (P-diagrams) here. The value of a graph is that a function can be linked to the requirement that justifies it, so a change to the requirement flags the function and everything downstream as needing review.

Steps 4 and 5: Failure and Risk Analysis

Step 4, failure analysis, is where the “net” appears. For a chosen function, a failure mode is the negation or deviation of that function. Its effects are found by following the function links upward, and its causes by following them downward to lower-level elements. The same failure mode is therefore a focus element with a failure effect above and a failure cause below. This is a chain, and chains share nodes: one cause can lead to several failure modes, and one effect can result from several modes. A flat worksheet duplicates text for each combination, and the copies drift apart. A graph stores the node once.

Step 5, risk analysis, adds the controls and the ratings. Prevention controls act on causes; detection controls act on a cause or a failure mode. Severity belongs to the failure effect, occurrence to the cause given its prevention controls, and detection to the combination of cause or mode and its detection controls. Action Priority is then assigned. I treat that in its own section because it is where most teams get the method wrong.

Steps 6 and 7: Optimization and Documentation

Step 6, optimization, assigns actions to the high-priority items, tracks owner and due date, and records a re-rating after implementation. The data point most often lost here is the link between the action and the change that implemented it. In a digital thread, an FMEA action should reference an engineering change request or change notice in PLM, so that closing the change closes the action and the re-rating can be verified against the released design.

Step 7, results documentation, is the report. A digital FMEA generates this view from the graph rather than being it. The 2019 handbook explicitly moved toward a structure where the document is a view of an analysis, which is the easiest way to reconcile the method with software.

Action Priority and Why RPN Failed

The Risk Priority Number multiplies severity, occurrence and detection, each on a 1 to 10 scale, giving a value from 1 to 1,000. Teams then sorted by RPN and acted above a threshold; 100 and 125 are the numbers commonly quoted in practice, though no threshold was ever scientifically grounded.

The mathematical problem

The three scales are ordinal. A rating of 8 is worse than 4, but it is not twice as bad, and the gaps between levels are not equal. Multiplying ordinal numbers produces a number whose magnitude has no consistent meaning. The most visible symptom is collisions: very different risks get the same score. In a widely used illustration, a mode rated S=10, O=2, D=5, another at S=2, O=5, D=10 and a third at S=4, O=5, D=5 all yield an RPN of 100 (worked examples at ReliaMag). The first is a possible safety event that is rare and moderately detectable. The second is a cosmetic issue that nobody can detect. They are not equivalent, yet a sort by RPN places them side by side.

The snippet below shows the collision rate over the full rating space. It runs as written and needs only the standard library.

from collections import Counter
from itertools import product

rpn = Counter(s * o * d for s, o, d in product(range(1, 11), repeat=3))
print("combinations:", sum(rpn.values()))            # 1000
print("distinct RPN values:", len(rpn))
print("most shared value:", rpn.most_common(1))
high_sev = [(s, o, d) for s, o, d in product(range(9, 11), range(1, 11), range(1, 11))
            if s * o * d < 100]
print("S>=9 combos with RPN below 100:", len(high_sev))

Running it on my machine printed 1,000 combinations, only 120 distinct RPN values, and a most-shared value of 60 that 24 different rating triples produce. It also found 50 combinations with severity 9 or 10 whose RPN is below 100. That last number is the dangerous one: a threshold on RPN can let a severity 10 item with good perceived detection slide under the line.

Why detection distorts the result

Detection is the third problem. A strong detection rating (low number) can offset a severe, frequent failure in the product, even though detection at design or process control level does nothing to prevent the failure from happening, and in the field the customer meets whatever escapes. Teams discovered they could lower RPN by adding an inspection step, which treats the symptom and adds cost, rather than prevent the cause.

What Action Priority does

AIAG-VDA replaces the multiplication with Action Priority (AP), a lookup table keyed on severity, occurrence and detection that returns High, Medium or Low. The ordering of priorities is explicit: severity dominates first, occurrence second, detection last. High means the team must identify an action or justify why current controls are adequate. Medium means the team should identify an action or may justify adequacy. Low means no action is required, though the team may choose one. Because the table is not an arithmetic product, two items with the same S, O and D digits in different order no longer collide.

A caution on sources. Some secondary articles describe AP slightly differently, for instance on whether detection enters the lookup; I treat the handbook itself as authoritative and I am not reproducing its table here, since it is a copyrighted, 1,000-cell lookup that you should license from AIAG or VDA. The code later in this post uses a deliberately simplified rule, clearly labelled as illustrative, so you can see the data flow without implying it is the official table.

Practical consequences of AP

First, AP is a prioritisation device, not a risk metric. You cannot average APs or sum them across a product. Second, “Low” is not “safe”; it means the method does not require action. Third, severity 9 and 10 items with any realistic occurrence will land in High, which pushes teams toward reducing occurrence by design change rather than hiding behind detection. That behavioural shift, more than the table itself, is the real improvement.

The Knowledge Graph Data Model

A worksheet row in an AIAG-VDA FMEA reads left to right: element, function, failure mode, effect, cause, controls, ratings. Each row repeats text from the one above. A property graph stores those repeats once and records relationships.

Figure 2: FMEA knowledge graph schema. Node types and the relationships that carry the structure, function and failure nets, plus links to requirements, BOM items and the control plan.

The schema in the figure has a small number of node types, and keeping it small is a feature. Element nodes represent structure. Function nodes hang off elements. Failure mode, effect and cause nodes form the failure net. Control nodes cover prevention and detection. Requirement and BOM item nodes are external references that point into PLM and requirements management rather than copying their data.

Node and edge design

Four rules keep this model maintainable.

Stable identifiers. Every node carries a UUID plus the source-system key (for example a PLM item ID and revision). Display names are attributes, never keys.
Ratings live on relationships or on cause nodes, not on text. Severity attaches to an effect-to-mode relationship because the same mode can have different effects at different levels or in different applications. Occurrence attaches to a cause in a context.
Versioning by baseline. Rather than editing nodes in place, record a baseline snapshot per released design revision, or use valid-from and valid-to timestamps on relationships. Regulators and customers ask what you knew at the time.
Controls are first-class. A prevention control is a node linked to the cause it acts on, and ideally to the specification, design rule or control-plan characteristic that implements it.

A Cypher sketch

The following is a representative fragment, not a complete production schema. I have not run it against a live database here, so treat it as a starting sketch to adapt.

// Structure and function
CREATE (c:Element {id:'EL-CAL', name:'Brake Caliper', plm_item:'100234', rev:'C'})
CREATE (s:Element {id:'EL-SEAL', name:'Piston Seal', plm_item:'100871', rev:'B'})
CREATE (c)-[:HAS_PART]->(s)
CREATE (f:Function {id:'FN-HOLD', text:'Hold fluid pressure'})
CREATE (s)-[:PERFORMS]->(f)
CREATE (r:Requirement {id:'REQ-4521', text:'No leakage at 180 bar'})
CREATE (f)-[:SATISFIES]->(r)
// Failure net
CREATE (fm:FailureMode {id:'FM-LEAK', text:'Fluid leaks past seal'})
CREATE (f)-[:FAILS_AS]->(fm)
CREATE (fe:Effect {id:'FE-LOSS', text:'Loss of braking force', severity:10})
CREATE (fm)-[:LEADS_TO]->(fe)
CREATE (fc:Cause {id:'FC-GAP', text:'Extrusion gap too large', occurrence:4})
CREATE (fc)-[:CAUSES]->(fm)
CREATE (pc:Control {type:'prevention', text:'Gap tolerance per drawing rule DR-17'})
CREATE (pc)-[:PREVENTS]->(fc)

// Query: every unreviewed failure mode downstream of a changed requirement
MATCH (r:Requirement {id:'REQ-4521'})<-[:SATISFIES]-(f:Function)-[:FAILS_AS]->(fm:FailureMode)
OPTIONAL MATCH (fc:Cause)-[:CAUSES]->(fm)
RETURN fm.text, collect(fc.text) AS causes

The last query is the payoff. A requirement change in your requirements tool triggers a graph traversal that lists exactly which failure modes need re-review. In a spreadsheet FMEA this is a manual read-through.

RDF as an alternative

If your organisation already runs ontologies, the same model fits RDF and SHACL. Elements, functions, modes and causes become classes; the rating constraints (severity in 1 to 10, mandatory prevention control for High priority) become SHACL shapes that validate completeness. The trade-off is tooling and talent. Property graphs are easier for application developers and have simple traversal syntax. RDF gives you open vocabularies, reasoning and cross-organisation interchange, which is attractive when OEMs and suppliers must share structure. I have no verified production benchmark comparing the two for FMEA workloads, so choose on team skills and integration needs rather than performance claims.

A Runnable Failure Net in Python

The following script builds a small failure net with networkx, rolls the maximum severity up from effects to modes, and computes an Action Priority from an illustrative rule. It was run in this session and prints three cause rows.

import networkx as nx

G = nx.DiGraph()
def add(n, kind, **kw): G.add_node(n, kind=kind, **kw)

add("Brake Caliper", "element"); add("Piston Seal", "element")
G.add_edge("Brake Caliper", "Piston Seal", rel="HAS_PART")
add("F1 Hold fluid pressure", "function"); add("F2 Retract piston", "function")
G.add_edge("Piston Seal", "F1 Hold fluid pressure", rel="PERFORMS")
G.add_edge("Piston Seal", "F2 Retract piston", rel="PERFORMS")

add("FM Fluid leaks past seal", "failure_mode")
add("FM Piston fails to retract", "failure_mode")
add("FE Loss of braking force", "effect", S=10)
add("FE Brake drag", "effect", S=6)
add("FC Seal extrusion gap too large", "cause", O=4, D=6)
add("FC Seal material swelling", "cause", O=3, D=8)
add("FC Seal groove burr", "cause", O=5, D=4)

G.add_edge("F1 Hold fluid pressure", "FM Fluid leaks past seal", rel="FAILS_AS")
G.add_edge("FM Fluid leaks past seal", "FE Loss of braking force", rel="LEADS_TO")
G.add_edge("FC Seal extrusion gap too large", "FM Fluid leaks past seal", rel="CAUSES")
G.add_edge("FC Seal material swelling", "FM Fluid leaks past seal", rel="CAUSES")
G.add_edge("F2 Retract piston", "FM Piston fails to retract", rel="FAILS_AS")
G.add_edge("FM Piston fails to retract", "FE Brake drag", rel="LEADS_TO")
G.add_edge("FC Seal groove burr", "FM Piston fails to retract", rel="CAUSES")

def action_priority(s, o, d):
    """ILLUSTRATIVE rule only. NOT the AIAG-VDA lookup table."""
    if s <= 1: return "L"
    if s >= 9:
        if o >= 4 or (o >= 2 and d >= 5): return "H"
        return "M" if o >= 2 else "L"
    if s >= 7:
        if o >= 6 and d >= 5: return "H"
        if o >= 4 or d >= 7: return "M"
        return "L"
    if s >= 4:
        return "M" if (o >= 6 and d >= 7) else "L"
    return "L"

modes = [n for n, a in G.nodes(data=True) if a["kind"] == "failure_mode"]
for fm in modes:
    s = max(G.nodes[e]["S"] for e in G.successors(fm))
    for c in [x for x in G.predecessors(fm) if G.nodes[x]["kind"] == "cause"]:
        a = G.nodes[c]
        print(f"{c:34s} S={s} O={a['O']} D={a['D']} RPN={s*a['O']*a['D']:3d} "
              f"AP={action_priority(s, a['O'], a['D'])}")

Its output on my run was:

FC Seal extrusion gap too large    S=10 O=4 D=6 RPN=240 AP=H
FC Seal material swelling          S=10 O=3 D=8 RPN=240 AP=H
FC Seal groove burr                S=6 O=5 D=4 RPN=120 AP=L

Two things are worth noticing. The first two causes share an RPN of 240 yet differ in character: one is more frequent with moderate detection, the other rarer with poor detection. A graph lets you inspect each cause with its own controls. The third cause has an RPN of 120, which the older rule of thumb would flag, but a severity of 6 and low-ish detection concerns put it at Low under the illustrative rule. Whether that reflects the official table is exactly why you should use the real lookup in production.

The design point is that severity is computed by traversing the graph (the maximum over effects reachable from a mode), not typed into each row. If a new, more severe effect is linked later, every cause under that mode gets a new priority automatically.

DFMEA, PFMEA and FMEA-MSR in One Model

The handbook defines three analysis types that share the same seven steps but differ in what the structure represents and what the failure net means. A digital FMEA should treat them as views over one connected model rather than three separate documents.

Figure 3: How DFMEA, PFMEA and FMEA-MSR connect. Product characteristics from the design analysis become the effects and special characteristics in the process analysis, and diagnostic coverage links the supplemental analysis back to both.

Design versus process

The design FMEA (DFMEA) analyses a product’s structure and function: how a component, subsystem or system might fail to deliver its required function. The process FMEA (PFMEA) analyses manufacturing and assembly steps: how a step might fail to produce a conforming product. The causes in a DFMEA are design characteristics; the causes in a PFMEA are process variations such as a worn tool, a wrong torque or a missing operator check.

The key link is the product characteristic. A DFMEA cause such as “seal groove depth out of tolerance” becomes a PFMEA failure mode at the machining step, and the severity carries over from the DFMEA effect. In a worksheet world, people copy this severity by hand. In the graph, the PFMEA failure mode links to the same effect node, so severity can never diverge between the two analyses. The same linking lets the control plan inherit its special characteristics from High-priority items rather than from a manually curated list.

FMEA-MSR

FMEA for Monitoring and System Response is the 2019 addition. A conventional DFMEA assumes the failure occurs and asks about prevention and detection during development. The supplemental analysis asks a different question about the delivered product: when a fault occurs during customer operation, does the system detect it through diagnostic monitoring, and does it respond to reach a safe or acceptable state? It is most relevant for systems with software diagnostics, such as electronic control units, where the ability to detect and degrade gracefully is part of the design.

In data terms, FMEA-MSR adds nodes for monitor, the response and the state reached, plus a rating of the severity of the effect after the system response. This links naturally to functional safety work. ISO 26262 (road vehicle functional safety) asks for safety analyses at system and component level and treats the diagnostic coverage and safe-state transitions that FMEA-MSR documents. I would not claim that FMEA-MSR substitutes for the ISO 26262 analyses or that a given clause maps one to one; check the standard and your assessor’s expectations. The practical benefit is shared data: the monitor and safe-state nodes in your FMEA graph can be the same nodes referenced by your safety case, instead of a second description that gets out of sync.

Relation to ISO 14971 and IEC 60812

For medical devices, ISO 14971:2019 defines the risk management process around hazards, hazardous situations and harm. FMEA is a technique inside it, not the process. A useful point from the supporting guidance in ISO/TR 24971:2020 is that the probability of a fault is not the probability of harm, because a fault begins a sequence of events and does not necessarily lead to a hazardous situation (discussion at MDDI). That has a modelling consequence: if you reuse FMEA occurrence as harm probability you are making a category error. In the graph, keep a separate path from effect to hazardous situation to harm, with its own probability fields, and let only the effects that can lead to a hazardous situation feed the risk file.

IEC 60812 is the generic technique standard underneath all of this. If you work outside automotive, it tells you how to plan and document the analysis; the AIAG-VDA tables are an automotive profile of that idea, not a requirement of IEC 60812 itself.

The PLM Digital Thread: Where FMEA Gets Its Data

An FMEA is only as current as the objects it references. The digital thread is the set of traceable links between requirements, design, manufacturing, quality and field data. FMEA sits in the middle of it, consuming from upstream and informing downstream.

Figure 4: Change propagation through the digital thread. A released engineering change is detected, affected FMEA nodes are flagged for review, and downstream control plans and monitoring are updated after the re-rating.

Upstream: requirements, structure and process

Requirements arrive from a requirements tool or an MBSE model. Structure arrives from the engineering BOM. Process flow arrives from the manufacturing BOM or process plan. A reliable integration references these objects by ID and revision and subscribes to change events rather than copying data. The SysML v2 and PLM integration tutorial covers how the model-based side exposes stable element identifiers, which is what you need to anchor function nodes to requirement nodes.

The PLM platform choice matters here. SaaS PLM suites differ in how they expose change events, item revisions and quality objects through APIs. The Teamcenter X, 3DEXPERIENCE and Windchill comparison is a good starting point; the question for FMEA is whether you can subscribe to a released-change event and read BOM structure at a given effectivity, because without both you will fall back to polling and manual export.

The change-impact loop

The sequence in Figure 4 is the single most valuable automation in a digital FMEA. When a change notice is released, the integration looks up every changed item, traverses from the element to its functions, modes and causes, and marks those nodes as “review required” with a link to the change. Reviewers see a bounded list, not the entire FMEA. After review and re-rating, the downstream control plan, inspection plans and monitoring rules are regenerated or flagged.

A worked sizing example, illustrative rather than measured: suppose a product FMEA has 40 elements, 120 functions, 300 failure modes and 900 causes. A change touching two elements might reach perhaps 6 functions, 15 modes and 40 causes through the graph. Reviewing 40 causes is a morning’s work; re-reading 900 rows is something teams skip. Those counts are invented to show scale, so replace them with your own distributions.

Downstream: control plan, work instructions and quality

The control plan lists the characteristics to be controlled, with methods and reaction plans. In a connected model, each control plan line references the cause and control nodes that justify it. Two benefits follow. First, an audit question such as “why do you measure this?” has a graph answer. Second, when a cause’s priority drops after an improvement, you can see which controls are candidates for relaxation, which is an honest way to remove inspection cost that no longer buys risk reduction.

Identity, effectivity and variants

The hard part of this thread is identity. Part numbers change, variants multiply, and effectivity (which units a design applies to) differs between sites. Model the FMEA against a product family with variant-specific overrides, not as a separate FMEA per variant. Use a base failure net plus delta nodes for variant-specific causes. The alternative, one copy per variant, is how organisations end up with forty near-identical files that nobody can keep consistent.

Closing the Loop with IoT Field Data

Occurrence ratings in a design-stage FMEA are judgments based on experience and prevention controls. After launch you have evidence. A connected product, or even a conventional one with warranty and service data, can feed that evidence back into the graph. This is where the IoT side of this site meets quality engineering.

What data matters

Three sources carry most of the value. Warranty and service records give counts of confirmed failures with cause codes, though coding quality is often poor. Telemetry gives operating context and precursor signals such as temperature, vibration or fault codes. Returned-part analysis (teardown) gives the true failure mechanism. The essential engineering task is mapping these to FMEA nodes: a fault code to a failure mode, a teardown finding to a cause. That mapping table is a maintained asset, and its accuracy limits everything downstream.

Bayesian updating of occurrence

A clean way to turn field counts into an occurrence update is a conjugate Beta-Binomial model. Treat the per-unit probability of a cause producing a failure in a defined exposure period as a Beta-distributed quantity, encode the design-stage belief as the prior, and update with field counts. The code below uses scipy for the credible interval and was run in this session.

from scipy import stats

a0, b0 = 2, 998            # prior Beta, mean 0.002 (about 1 in 500), weight 1000 units
fails, units = 9, 1500     # field evidence: 9 confirmed failures in 1,500 units
a, b = a0 + fails, b0 + units - fails
post = stats.beta(a, b)
lo, hi = post.interval(0.95)
print("prior mean", a0 / (a0 + b0))
print("posterior mean", round(a / (a + b), 5))
print("95% credible interval", round(lo, 5), round(hi, 5))

On my run it printed a prior mean of 0.002, a posterior mean of 0.0044 and a 95% credible interval of roughly 0.0022 to 0.0074. The design-stage belief of about 1 in 500 has shifted to roughly 1 in 227 after 9 failures in 1,500 units, and the interval says the true rate is plausibly anywhere from about 1 in 450 to 1 in 135. Those counts are illustrative, chosen to show the mechanics.

Against the occurrence anchors in one published teaching example, where 1 in 400 maps to a rating of 5 and 1 in 80 to a rating of 6 (ReliaMag), a posterior near 1 in 227 sits between two ratings. The handbook’s own occurrence criteria are what you must use in a formal FMEA, and my understanding is that the DFMEA occurrence scale is built around prevention-control maturity and operating experience rather than raw failure rates, so a statistical estimate should inform the rating, not replace the judgment. The graph’s role is to store the evidence, the date and the model parameters next to the rating, so the next reviewer sees why it moved.

Prognostics and the detection side

Field data also improves detection and monitoring. If a precursor signal reliably precedes a failure mode, you can add a monitor with a measured lead time and false-alarm rate, which is exactly the kind of content FMEA-MSR wants. The remaining useful life methods in the prognostics post on Weibull, survival models, LSTM and Kalman filtering estimate how long a degrading component has left; a digital FMEA can link a cause node to the prognostic model that watches it, with the model’s validated detection performance recorded as evidence for the detection rating.

Guardrails for the loop

Do not let the loop auto-change ratings. A statistical update should create a proposed change with its evidence, and a named reviewer should accept it. Three failure patterns are common: survivorship bias when only returned units are counted, exposure errors when units shipped is used as denominator for a time-dependent failure, and cause misattribution when a fault code covers several mechanisms. The Beta-Binomial model assumes a fixed exposure and independent units; a time-to-failure cause such as wear needs a Weibull or survival formulation instead.

Tooling Landscape and Build-versus-Buy

Three families of tools exist, and which fits depends on how much of the graph model you need.

Option	Strengths	Weaknesses	Fit
Spreadsheet	Zero cost, familiar	No identity, no links, drift, no audit trail	Small one-off analyses only
Dedicated FMEA application (for example APIS IQ-FMEA, Relyence)	AIAG-VDA worksheets, AP support, libraries, reports	Integration with PLM varies; data model is vendor-defined	Teams needing compliance quickly
PLM-embedded quality module (for example Siemens Teamcenter Quality)	Native links to BOM, change and requirements	Tied to the suite; may be heavier to configure	PLM-centric organisations
Custom graph layer (Neo4j or RDF) over PLM APIs	Full control, flexible queries, analytics	You own the build, schema and governance	Large product lines with data-science teams

I list product names as examples of categories based on vendor descriptions, not as endorsements, and I have not verified specific feature lists beyond what the vendors publish. Relyence’s page, for instance, confirms Action Priority and an FMEA-MSR worksheet template, but does not describe a graph model. Check current versions and API documentation before committing.

A pragmatic hybrid

For most organisations the sensible path is hybrid: keep the authoritative FMEA in a dedicated or PLM-embedded tool that handles worksheets, signatures and customer-format reporting, and export its content nightly into a read-optimised graph for analytics, impact analysis and field-data joins. This respects the reality that auditors want the formal tool, while analysts get the graph. The cost is a synchronisation job and an identity-mapping table, and you must decide which side is the system of record for each attribute.

LLM-Assisted FMEA Drafting

Language models are good at generating plausible lists of failure modes, effects and causes from a function description, which is exactly the tedious part of FMEA. They are also good at normalising messy text, such as mapping free-text service notes to existing failure mode nodes.

What the evidence shows

Published work is early and cautious. The FMEA Builder paper from IBM-affiliated researchers describes expert-guided LLM text generation for equipment maintenance FMEAs, reporting that in empirical testing foundation models correctly generated more than half of the key content, with positive feedback from reliability professionals surveyed (arXiv 2411.05054). “More than half” is the useful phrase: it means a meaningful share was wrong or missing, and an expert still has to catch which. I would not extrapolate that figure to your product, your domain or a newer model.

A safe workflow

Treat the model as a junior analyst who writes fast and is never held accountable.

Ground it in the graph. Give the model the structure and function nodes and the existing failure net for similar items, so it proposes against your vocabulary instead of inventing new terms.
Draft into a staging area. LLM output enters the graph as nodes flagged status: proposed with provenance (model, prompt version, date). Proposed nodes never count toward released ratings.
Never let it assign final ratings. Severity, occurrence and detection depend on the customer’s use, controls actually in place and field evidence. A model can suggest, but a human with product knowledge decides.
Review for omissions, not just errors. The dangerous failure mode is the one the model did not mention. Compare against field data, lessons learned and a second independent method such as a fault tree on critical functions.
Log acceptance rates. Track what share of proposals reviewers accept or edit. If acceptance is high and reviewers are rubber-stamping, your review process has failed, not succeeded.

Where it goes wrong

Models tend toward generic, textbook failure modes and underweight your specific history. They can hallucinate controls that do not exist in your process, which is serious because a documented but fictional detection control inflates confidence. Confidentiality is another constraint: design details sent to an external service may breach customer agreements. Sector regulators and customers may also expect that records of safety analyses reflect human engineering judgment, so check requirements before using generated content in a formal safety submission. The model is an accelerator for the draft, and the accountability remains with the team.

Trade-offs, Gotchas, and What Goes Wrong

Digital FMEA is not free, and several failure modes are specific to it.

Over-modelling. A fine-grained graph with every part, every function and every cause can become unmaintainable. FMEA effort should follow risk: apply deep decomposition to novel, safety-relevant or high-warranty areas, and reuse proven analyses for carry-over designs. The handbook itself encourages scoping through the planning step.

False precision from numbers. Storing Bayesian posteriors next to ratings can make a judgment look like a measurement. The ratings are still ordinal classifications. Dashboards that colour by AP and show averages invite exactly the arithmetic that AP was designed to stop.

Identity drift. If node IDs are derived from part numbers and the numbering changes, links break silently. Use opaque stable IDs and a mapping table. Test the mapping with a deliberate renumbering exercise before you rely on it.

Review fatigue. An impact analysis that flags hundreds of nodes for each change trains people to click approve. Tune the traversal depth, prioritise by severity, and measure how long reviews actually take.

Mismatched granularity with field data. Service codes are usually coarse; FMEA causes are fine. If a code maps to six causes you cannot attribute failures among them without teardown data, and spreading counts evenly is a guess you should label as one.

Compliance mismatch. A customer may demand a specific form or a particular tool format. The graph can generate it, but you need to test that exports meet each customer’s expectations. Also remember the handbook is a copyrighted document; embedding its tables in an open-source tool raises licensing questions.

Cultural failure. The oldest FMEA failure is doing it to satisfy a gate rather than to find problems. Digital tooling does not fix that; it can make it worse by making it easier to produce a complete-looking document quickly. The test of a digital FMEA is whether engineers open it to make decisions.

Practical Recommendations

Start with the problem you actually have. If your FMEAs are stale, begin with change-impact flagging rather than a full graph migration: stable IDs for elements and functions, a link to the BOM revision, and a subscription to released changes. That alone delivers the most value per unit effort.

Adopt AIAG-VDA Action Priority using the official table and retire RPN thresholds in procedures. Explain the reason to your teams, because people attached to the 100 or 125 rule need to see the collisions, not just be told to stop. Keep severity computed from linked effects so it cannot be edited inconsistently across DFMEA and PFMEA.

Pilot field-data feedback on one product line with a good failure coding discipline. Build the mapping from fault codes and teardown findings to cause nodes first, then add the Bayesian proposals with a human approval step. Pilot LLM drafting in a staging mode with logged acceptance rates, and begin with non-safety-critical subsystems.

A short checklist to close:

Every node has a stable ID and a source-system reference with revision.
Severity is derived from effects; occurrence and detection are stored with evidence and date.
Action Priority comes from the official table, not arithmetic.
FMEA actions link to change notices; closing the change closes the action.
DFMEA, PFMEA and FMEA-MSR share product characteristic and effect nodes.
LLM output is staged, attributed and reviewed; it never sets released ratings.
Field-data updates are proposals with named reviewers.
One system of record is declared for each attribute.

Frequently Asked Questions

What is digital FMEA?

Digital FMEA is the practice of keeping failure mode and effects analysis as structured, linked data rather than a static spreadsheet. Elements, functions, failure modes, effects, causes and controls become identifiable records connected to requirements, the bill of materials, control plans and field data. The benefit is automatic impact analysis when designs change, consistent severity across design and process analyses, and the ability to update occurrence from real failure evidence while keeping a full audit trail.

What are the seven steps of AIAG-VDA FMEA?

The 2019 AIAG and VDA handbook defines seven steps: planning and preparation, structure analysis, function analysis, failure analysis, risk analysis, optimization, and results documentation. The first three define scope, the system breakdown and what each element must do. Failure analysis builds the chain of effect, mode and cause. Risk analysis rates severity, occurrence and detection and assigns Action Priority. Optimization assigns and verifies actions, and documentation records the outcome.

Why did AIAG-VDA replace RPN with Action Priority?

RPN multiplies three ordinal ratings, which has no consistent mathematical meaning, and it lets very different risks share the same number. Across all 1,000 possible rating combinations there are only 120 distinct RPN values, and 50 severity 9 or 10 combinations score below 100. Action Priority instead uses a lookup that weights severity first, then occurrence, then detection, returning High, Medium or Low so serious failures cannot hide behind good detection scores.

What is the difference between DFMEA, PFMEA and FMEA-MSR?

DFMEA analyses how a product’s design could fail to deliver its functions, with causes in design characteristics. PFMEA analyses how manufacturing or assembly steps could fail to produce conforming product, with causes in process variation. FMEA-MSR, new in the 2019 handbook, is a supplement that examines whether the system detects faults during customer use and responds to reach a safe or acceptable state. All three can share effect and characteristic nodes in a connected model.

How do you build an FMEA knowledge graph?

Define a small schema: element, function, failure mode, effect, cause and control nodes, plus references to requirements and BOM items. Give every node a stable ID with the source system key and revision. Store severity on effect relationships, occurrence and detection on causes with evidence, and version by baseline. Load structure from PLM, then traverse the graph for impact analysis. Property graphs such as Neo4j with Cypher are the simplest start.

Can AI or LLMs write an FMEA?

LLMs can draft candidate failure modes, effects and causes quickly, and can map free-text service notes to existing nodes. Early research, such as the FMEA Builder study, reports that models generated more than half of key content correctly, which implies substantial errors and omissions remain. Use them in a staging workflow with provenance, never let them set released ratings, and review specifically for missing failure modes and invented controls.