FMEA: Bottom-Up Failure Analysis

13.1 The FMEA artifact and its methodology

FMEA is one of the oldest formal safety-engineering methods. It started in US military reliability engineering in the 1940s and was codified in MIL-STD-1629 (first published 1949, current as MIL-STD-1629A, 1980). The automotive industry adopted it through the 1970s and 1980s, with the German VDA (Verband der Automobilindustrie) and the American AIAG (Automotive Industry Action Group) maintaining competing methodologies. The 2019 joint AIAG & VDA FMEA Handbook harmonized the two, and that harmonized methodology is what Sylang's .flr file type implements.

The AIAG-VDA seven-step methodology

The AIAG-VDA methodology breaks FMEA into seven steps. The first three (Planning and Preparation, Structure Analysis, Function Analysis) set the analytical scope. Step 4 (Failure Analysis) enumerates the failure modes, and step 5 (Risk Analysis) scores each one for severity, occurrence and detection, then computes the action priority. Step 6 (Optimization) iterates the design to reduce action priority where needed, and step 7 (Results Documentation) produces the artifact for review and archival.

Sylang's .flr file holds the outputs of steps 4 to 7 directly: the failure modes, their scores, the mitigations that optimization drives, and the documented results. The earlier steps (planning, structure, function) live in the artifacts the .flr references: the .blk for structure and the .fun for function. So the full FMEA artifact set is the .flr plus those upstream artifacts. An .flr never stands alone.

File structure

An .flr file declares a failureset tied to a single block through occursin ref block. The body is a flat list of def failuremode clauses, one for each failure mode of that block. Failure modes form chains through causedby and effects, and they link to detection and mitigation functions through detectedby and mitigatedby.

hdef failureset CobotJointFailures
  name "Cobot Joint FMEA"
  safetylevel SIL-3
  level component
  timingreference ms
  occursin ref block JointAssembly

  def failuremode JointBearingFailure
    severity 9
    occurrence 2
    detectability 4
    actionpriority high
    rpn 72
    safetylevel SIL-3
    faultdetectiontime 50
    propagationdelay 100
    causedby ref failuremode LubricantContamination within 1000
    effects ref failuremode UncontrolledMotion within 50
    detectedby ref function TorqueAnomalyDetector within 50
    mitigatedby ref function SafeStopController within 100
    testedby ref testcase TC_COB_JOINT_BEARING
    derivedfrom ref requirement REQ_COB_005
    allocatedto ref block JointAssembly

The header carries three properties you'll use all the time. occursin ref block <Block> names the block whose failure modes this set analyzes (the convention is one block per .flr). timingreference sets the units for every temporal property in the file: ms, us, s or ns. propagateto ref failureset <Parent> names the upstream failure set that this set's failures propagate into, which is how you build hierarchical FMEA across blocks.

What follows

Subchapter 13.2 covers failure-mode scoring: S, O, D, RPN and action priority. Subchapter 13.3 covers the temporal constraints and the causedby/effects chains. Subchapter 13.4 walks through the cobot anchor's complete FMEA.

13.2 FMEA scoring: severity, occurrence, detectability, RPN, action priority

AIAG-VDA FMEA scoring uses three integer scales from 1 to 10: severity, occurrence and detectability. From those you derive a Risk Priority Number (RPN = S × O × D) and an Action Priority (AP) of high, medium or low, which drives the optimization decision. This subchapter shows you how each score works.

Severity (S, 1 to 10)

Severity rates the impact of the failure if it occurs and isn't detected. The AIAG-VDA scale runs from 1 (no discernible effect) to 10 (potential for death or serious injury). For the cobot anchor, the failure modes range from 4 (cosmetic: a minor surface defect on the workpiece) to 10 (catastrophic structural failure during human collaboration). In between sits 9: uncontrolled motion that could injure an operator.

Severity is a property of the failure's potential consequence. It says nothing about the failure's probability or the system's ability to detect it. A severity-9 failure may be very unlikely and very easy to detect; the score still reflects what could happen if the chain of mitigations failed. Severity scores the consequence, not the odds.

Occurrence (O, 1 to 10)

Occurrence rates the likelihood that the failure cause arises. The scale runs from 1 (cause virtually eliminated through design) to 10 (cause very likely; the design provides no prevention). The AIAG-VDA handbook gives explicit guidance for turning engineering judgment into the integer scale:

• 1 to 2: requires statistical evidence, such as six-sigma process control or validated reliability data.
• 3 to 5: proven designs with limited known failures.
• 6 to 8: new or unproven designs.
• 9 to 10: designs with a known failure history.

For the cobot's JointBearingFailure, occurrence is 2. The bearing's design carries substantial reliability margin (rated for more than 10,000 hours of duty), the lubrication interval is proven, and the operating environment is controlled. A low occurrence score doesn't mean the failure can't happen. It means the design and process controls make it improbable.

Detectability (D, 1 to 10)

Detectability rates the likelihood that, once the failure cause is present, the system's detection mechanisms will identify it before it produces the failure mode. Watch out, because this scale runs opposite to intuition. A score of 1 means almost certain detection and 10 means cannot be detected, so lower is better.

For the cobot's JointBearingFailure, detectability is 4. The torque-anomaly detector (a dedicated diagnostic function) catches bearing degradation before it shows up as uncontrolled motion in most cases, but not all. The detector relies on torque measurements that can themselves be noisy, and some failure trajectories evade detection until the failure is fully developed. The mid-range score reflects detection that is effective but imperfect.

RPN and action priority

The Risk Priority Number is the product RPN = S × O × D, so it ranges from 1 (S=O=D=1) to 1000 (S=O=D=10). Historically, automotive practice drove mitigation decisions with an RPN threshold, typically 100: any failure with RPN ≥ 100 required design action.

The AIAG-VDA harmonization replaced the RPN threshold with action priority: a lookup table over (S, O, D) triples that yields high, medium or low. The table is more nuanced than a single threshold and gives more weight to severity, particularly for S ≥ 9. The methodology now requires an actionpriority value on every failure mode, in addition to the RPN. So Sylang's .flr carries both: rpn for backward compatibility with older RPN-based queries, and actionpriority for current AIAG-VDA conformance.

Take the cobot's JointBearingFailure: S=9, O=2, D=4, so RPN = 72. The action priority is high, because severity ≥ 9 maps to high regardless of O and D in the AIAG-VDA table. High priority means mandatory design action. Either you modify the design to reduce S, O or D, or the safety case explicitly justifies accepting the residual risk.

What follows

Subchapter 13.3 covers the temporal constraints and the failure-mode chains. Subchapter 13.4 then closes the chapter with the cobot anchor's FMEA walkthrough and the cross-anchor mirrors.

13.3 Temporal constraints and the causedby / effects chains

Two things set Sylang's FMEA apart from a conventional spreadsheet FMEA, and this subchapter covers both. The first is explicit temporal constraints on failure propagation: the within N qualifier on causedby and effects. The second is formal failure-mode chains that link root causes, through propagation paths, to terminal effects. Together they support AIAG-VDA Failure Analysis (step 4) and Risk Analysis (step 5) at a depth conventional FMEAs rarely reach.

Temporal constraints: faultdetectiontime, faulttolerancetime, propagationdelay, recoverytime

Each def failuremode can carry four temporal properties. Their units come from the file-level timingreference.

• faultdetectiontime: the time from fault occurrence to detection by the mitigation function. The shorter this time, the higher the detectability score in the FMEA scoring.
• faulttolerancetime: the time the system can tolerate the fault without entering a hazardous state. It bounds the maximum allowable detection-plus-reaction time.
• propagationdelay: the time from the failure mode's manifestation to its downstream effect. FMEA chain analysis uses it to compute the total time-to-hazard from a root cause.
• recoverytime: the time from detection to system recovery (return to normal operation, where recovery is possible). The safety case uses it to argue degraded-mode bounds.

Back to the cobot's JointBearingFailure. Its faultdetectiontime is 50 ms: the torque-anomaly detector identifies the bearing degradation pattern within 50 ms of onset. Its propagationdelay is 100 ms, from bearing degradation to uncontrolled motion that would expose an operator, so the safe-stop controller must intercept the propagation within 100 ms. The temporal model makes the mitigation's time budget explicit, and "fast enough" becomes a number you can check.

The within N qualifier

The within N qualifier expresses temporal constraints on failure propagation paths. It is allowed on causedby, effects, detectedby and mitigatedby; the validator rejects it on any other relationship.

  def failuremode UncontrolledMotion
    ...
    causedby ref failuremode JointBearingFailure within 100
    causedby ref failuremode MotorControllerCrash within 20
    effects ref failuremode OperatorImpact within 200
    detectedby ref function TorqueAnomalyDetector within 50
    mitigatedby ref function SafeStopController within 100

Read causedby ref failuremode X within N as: this failure mode arises within N time units of cause X occurring. Read effects ref failuremode Y within M as: this failure mode causes Y within M time units. The annotations add up along the chain. A root cause's time-to-hazard is the sum of the within-N values on the path from that root cause to the top event.

Failure-mode chains: from root cause to top event

Together, causedby and effects form a directed graph over the failure modes: the failure-mode chain. Its roots (failure modes with no causedby) are the root causes. Its sinks (failure modes with no effects) are the top events, the failures that directly produce hazards.

The chain structure makes two consequential analyses possible. The first is common-cause analysis: when several top events share a root cause, you've found a single point of failure, and mitigating it pays off many times over. The second is temporal budget verification: the sum of within N values along the longest path from any root cause to any top event must fit within the safety goal's FTTI. A longer path points to either an unsupported safety claim or a process gap in the mitigation chain.

Sylang Studio's FMEA workbench draws the chain for you, with nodes color-coded by action priority and edges labeled with their within-N values. As a reviewer, you triage by walking backward from the highest-priority top events to their root causes, looking for mitigation gaps.

What follows

Subchapter 13.4 closes the chapter with the cobot anchor's FMEA walkthrough and brief mirrors from the EPB, autopilot and infusion pump anchors.

13.4 Cobot FMEA walkthrough and cross-anchor mirrors

This subchapter closes Chapter 13. We'll walk the cobot anchor's FMEA structure using the chapter's conventions, then look at brief mirrors from the EPB, autopilot and infusion pump. By the end, you'll see how the FMEA artifact set fits into the safety chain of Chapter 12.

The cobot's FMEA

The cobot FMEA isn't fully authored yet, so this walkthrough follows its planned structure. The principal block is the joint assembly: CobotJointFailures.flr, allocated to the JointAssembly block. The file enumerates about a dozen failure modes: mechanical (bearing failure, gear-tooth crack, encoder slip), electrical (motor coil short, encoder signal degradation) and software (controller crash, communication timeout). Each failure mode carries S/O/D scores, temporal constraints, and the chains that link root causes to top events.

The cobot FMEA has a single top event, UncontrolledMotion: the cobot moves outside its commanded trajectory with enough force to injure an operator. Several causedby paths lead there: joint-bearing failure (a slow degradation), motor-controller crash (a sudden failure) and communication timeout (an intermittent failure with race conditions). Each path has a different temporal profile. The mitigation chain (collision detection, safe-monitored speed, safe stop) must handle all three within the 100 ms FTTI inherited from the SG_NoOperatorImpact safety goal.

Mirror examples

The other anchors have FMEAs with comparable structure and domain-specific content.

1. EPB (.flr already authored). The EPB anchor's EpbFmea.flr covers nine failure modes across the EpbController block. They are clamp force undershoot and overshoot, force sensor open-circuit and drift, motor stall, motor divergence (dual-motor variant only), motor bond-wire failure, vehicle rollaway (top event), and latent motor fault state (top event, dual-motor variant only). Its two top events, VehicleRollaway and LatentMotorFaultState, are the FTA top events of Chapter 14.
2. Autopilot. An autopilot FMEA would cover failure modes of the flight-control computer (FCC) and the protection-law software. Those include alpha-sensor failure (one or both of the redundant sensors), FCC reset, protection-law numerical instability and sensor cross-check failure. The top event is protection-law lockout, which lets the aircraft enter the very flight envelope the protection law was designed to prevent. Timing is on the order of milliseconds: the FCC runs at 1 kHz, and the protection laws must respond within 10 to 100 ms.
3. Insulin pump. A pump FMEA would cover the dose-delivery hardware (motor stall, occlusion, air-in-line) and the software (dose calculation error, bolus calculator parameter drift). The top events are bolus overdose (the most-feared event), bolus omission (less acute, but harmful over time) and occlusion that prevents any delivery. Timing runs from seconds to minutes: slower than the autopilot, but faster than a clinical-trial study would resolve.

Closing Chapter 13

You now have FMEA at the depth you need for production authoring across all four anchor domains. We covered the artifact's structure and the AIAG-VDA methodology (13.1), S/O/D/RPN/AP scoring (13.2), temporal constraints and chains (13.3), and the cross-anchor walkthrough (this subchapter). Chapter 14 turns to Fault Tree Analysis (FTA), the top-down complement to FMEA's bottom-up approach.

Industry practice has historically kept FMEA in dedicated spreadsheet tools (IQ-FMEA, APIS IQ-RM, Plato e1ns and others), separate from the MBSE artifacts. If you've worked that way, you know the drift it produces. The FMEA shows one set of mitigations, the requirements show another, and the safety case has to reconcile the two by hand.

Exercises (Chapter 13)