M8-T7: FMEA

Learning objectives

After this lesson, you should be able to:

• Describe the structure of an FMEA table and the meaning of severity, occurrence and detection.
• Build an FMEA for the navigation subsystem of a GNSS-denied UAV.
• Compute and critically use a risk priority number, and know its limits.
• Link each high-risk failure mode to a monitor, a mitigation and a test.

Conceptual explanation

An FMEA walks through the system element by element. For each element it lists the failure modes (how it can fail), their effects locally and at system level, the causes, the current controls (detection and prevention) and recommended actions. Each mode is scored for severity (S), occurrence (O) and detection (D), classically on 1–10 scales, and ranked by risk.

FMEA is a bottom-up method: start from components and ask what their failures do. Its complement, fault-tree analysis (lesson M8-T8), is top-down: start from a hazard such as “uncontrolled flight into a person” and ask which combinations of failures cause it. Use both.

Engineering intuition

The value of an FMEA is the conversation and the traceability, not the number. A team that writes “GNSS spoofing: effect, vehicle follows a false position; control: innovation gate only; detection score 8” has just discovered a gap, and the action (“add odometry cross-check, verify with the failure simulator”) is a requirement that can be tested. Scores help to order the work, but a mode with a catastrophic effect deserves action even if its risk priority number is low because it is rare.

Mathematical formulation

The classical risk priority number multiplies the three scores:

$S$

severity of the worst credible effect: 10 = catastrophic (injury or uncontrolled flight), 1 = negligible.

$O$

occurrence likelihood: 10 = almost certain in normal use, 1 = remote.

$D$

detection: 10 = no means of detection before the effect, 1 = almost certain detection.

RPN has well-known weaknesses: it treats the three factors as interchangeable ($S$ = 10, $O$ = 1, $D$ = 1 gives 10, the same as $S=2$, $O=5$, $D=1$), the scales are ordinal, and many different combinations give the same product. Modern practice (for example the harmonised AIAG-VDA approach) ranks by action priority that gives severity the strongest weight, and aviation safety processes tie severity classes to required assurance levels. For a first-pass UAV project, a simple rule works: act on every mode with severity ≥ 9 regardless of RPN, then on the highest RPNs.

Formal aviation practice (for example SAE ARP4761 for system safety assessment) uses defined severity classifications and probability targets per class. For an operation under a regulator’s risk assessment (for example JARUS SORA), the severity and likelihood definitions come from that framework: use them for any real approval.

Worked example: navigation subsystem of a GNSS-denied UAV

The scores above are illustrative: they show how the method ranks modes, not measured field rates. The two highest-risk items (spoofing with weak detection, and an overconfident estimator) have severity 9 and deserve action under the “severity first” rule. Each action must name a verification: the spoofing item is closed by adding the odometry cross-check and showing it works in the GNSS-Denied Failure Simulator and in a flight test of the acceptance plan.

Architecture and data flow

FMEA outputs feed the rest of the verification chain: each failure mode with a monitor becomes a requirement on the monitor (module 8, lesson M8-T1), each mitigation a design change to the architecture (lesson M2-T16), each detection claim a test case (lesson M8-T6), and the highest-severity modes the top events of fault trees (lesson M8-T8). Keep the FMEA as a living table under configuration control (lesson M7-T19): re-run it whenever the architecture changes.

Real-world UAV applications

• Planning the failure-injection tests for software-in-the-loop and flight test.
• Showing a regulator or customer that the navigation system’s failure modes were considered.
• Prioritising which monitors to build first.
• Choosing where redundancy buys the most risk reduction.

Implementation example

This runs as shown: a small FMEA tool that computes RPN, applies the “severity first” rule, and checks that every high-risk mode has a named verification. Keeping the FMEA as data lets the build fail when a high-risk mode has no test.

from dataclasses import dataclass

@dataclass
class Mode:
    item: str; mode: str; S: int; O: int; D: int; verification: str = ""
    @property
    def rpn(self): return self.S * self.O * self.D

fmea = [
    Mode("GNSS receiver", "spoofed position, slow ramp", 9, 3, 8, "SIM-GNSS-SPOOF; FT-04"),
    Mode("Camera / VIO", "timing offset after driver update", 7, 4, 8, ""),
    Mode("Estimator", "overconfident covariance", 9, 4, 6, "SIM-NEES; FT-02"),
    Mode("IMU", "accelerometer bias step", 8, 3, 4, "SIM-IMU-BIAS"),
    Mode("Link", "loss of GCS link", 7, 5, 2, "FT-07"),
]

def must_act(m: Mode, severity_threshold=9, rpn_threshold=150):
    return m.S >= severity_threshold or m.rpn >= rpn_threshold

for m in sorted(fmea, key=lambda m: (-m.S, -m.rpn)):
    flag = "ACT" if must_act(m) else "   "
    print(f"{flag} S={m.S} RPN={m.rpn:4d}  {m.item}: {m.mode}  [{m.verification or 'NO VERIFICATION'}]")

unverified = [m for m in fmea if must_act(m) and not m.verification]
print("high-risk modes without verification:", [m.mode for m in unverified])
assert [m.mode for m in unverified] == ["timing offset after driver update"]     # RPN 224 >= 150 and no test yet: the check catches it
assert max(fmea, key=lambda m: m.rpn).mode == "timing offset after driver update"

Common engineering mistakes

Failure modes

Debugging approach

1. Walk the system block diagram (Architecture Builder) and confirm every interface appears in the FMEA.
2. For each detection claim, point to a fault-injection test that triggered it.
3. Review each severity-9 mode with someone outside the design team.
4. Cross-check against incident reports of similar vehicles for modes you did not list.

Practical exercises

1. Add three failure modes for the companion computer and the power system and score them.
2. Show with numbers why $S=9$, $O=1$, $D=1$ should not be ranked below $S=4$, $O=5$, $D=6$.
3. Convert two FMEA rows into requirements with a verification method each.
4. Use the failure simulator to produce evidence that a detection score of 3 is justified for GNSS loss.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• SAE ARP4761: Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment
• EASA: specific category civil drones (operational risk assessment, SORA)
• NASA Systems Engineering Handbook (risk management and FMEA)
• IEC 60812, Failure modes and effects analysis (FMEA and FMECA).

What’s next