3.6.29 · D5Spacecraft Structures & Systems Engineering
Question bank — FMEA — failure mode, effect, severity, detection, RPN
Before we start, recall the three earned scores so no symbol is used unexplained:
- S — Severity: how bad the effect is, (nothing) to (loss of mission/crew).
- O — Occurrence: how often the failure happens, (nearly never) to (nearly always).
- D — Detection: how hard it is to catch before it hurts you, (caught instantly) to (invisible until disaster).
- And , ranging to .
Notice the direction trap baked into D: a good detection system scores a low number. Half the errors below come from forgetting that.
True or false — justify
A failure with but and automatically deserves the top priority-1 fix.
False. Its , which is trivial — it almost never happens and we'd catch it instantly. RPN, not severity alone, sets priority; a catastrophic-but-rare-and-visible risk is often acceptable.
Two failures with the same RPN are equally urgent.
False. and both give , but the first can kill the mission while the second is harmless — RPN ties must be broken by looking at S first.
Lowering the Detection score means your detection got worse.
False. The D scale is inverted: a lower D means detection is better/earlier. Adding a good sensor pushes D down, which lowers RPN.
If you add redundancy, the Occurrence score of a single unit drops.
False. Redundancy doesn't stop that unit from failing — its O is unchanged. Redundancy lowers Severity, because the system survives the failure.
RPN is a genuine probability, so an RPN of 500 means "50% chance of disaster".
False. RPN is an ordinal ranking product of three 1–10 scales, not a probability. It ranks risks against each other; the numbers have no physical units.
Multiplying S, O, D (rather than adding) is an arbitrary choice.
False. Multiplication makes any factor near its safe end (small S, O, or D) shrink the whole RPN — modelling that a risk needs to be severe and frequent and hidden to be dangerous. Addition would let one large term dominate even when another is safe.
FMEA is a one-time analysis done before the design freezes.
False. FMEA is a living document: every design change (adding a fuse, new software) re-scores affected rows, so RPN must be recomputed after each mitigation.
FMEA is a top-down method starting from mission failure and working backward.
False. FMEA is bottom-up: start at each component's failure modes and trace effects upward to the mission. (The top-down "how could the mission fail?" method is fault-tree analysis — a different tool.)
A component with no known failure modes needs no FMEA row.
False and dangerous. "No known modes" usually means you haven't looked hard enough; the mode you omit is the one that bites you (see Mars Climate Orbiter).
Spot the error
"The battery cell short scored , so we added a redundant cell — that fixes the severity to ."
Two errors: severity is never multiplied to zero, and redundancy reduces S to a milder value (say 6) because the system now survives, it doesn't erase the score.
"Our failure is undetectable, so we gave it to be safe."
Backwards. Undetectable is the worst case and scores . Choosing hides the risk by artificially shrinking its RPN — exactly the mistake FMEA exists to prevent.
"We reduced O from 5 to 5 after mitigation, so nothing changed — the redundancy was useless."
The reasoning wrongly demands O drop. Redundancy legitimately leaves O unchanged while cutting S and D; the RPN still falls. Judge the product, not one factor.
"RPN went from 336 to 100, which is under 150, so this row is now closed and needs no monitoring."
An RPN in the 50–150 band means "design review / monitor", not "closed". Only near-trivial rows are truly dropped; a recovered software leak still gets memory telemetry.
"We set for a science instrument glitch because losing science data feels catastrophic."
Severity is anchored to a standardized scale, not feelings. is loss of crew or flagship mission; recoverable science downtime is major (7–8) at most. Inflating S corrupts prioritisation.
"Occurrence is just engineering judgement, so any number in 1–10 is defensible."
O should be tied to a rate over mission lifetime (failure-rate data, heritage, testing). Pure gut-feel O values make the whole reliability estimate meaningless.
Why questions
Why trace effects upward through local → subsystem → system → mission levels?
Because a "minor" local fault (one cell to 0 V) can cascade — bus drops, spacecraft safes, attitude lost, power death-spiral. Only the top-level effect reveals the true severity.
Why is the 1–10 scale "logarithmic-like" rather than linear?
Human risk perception jumps qualitatively near the top: 9→10 (major→catastrophic) is a bigger real gap than 2→3. Compressed high-end steps mirror how badly the worst outcomes matter.
Why does a high-, high- failure with low become manageable?
Low D means we catch it early, so we can act (switch to redundant unit, safe the craft) before the effect matures — turning a silent killer into a handled event.
Why re-run FMEA after adding a fuse or a monitor?
Each mitigation changes one or more of S, O, D, so the RPN must be recomputed to confirm the row actually dropped below the action threshold — and to make sure the fix didn't introduce a new failure mode.
Why does aerospace tolerate an unchanged O in the reaction-wheel example?
Because with four wheels (3+1) and predictive alarms, the failure is now survivable and foreseeable; we accept that a wheel may still seize because its consequence and detectability are under control.
Why can FMEA connect to redundancy and risk management but not replace the V-model?
FMEA feeds which risks to mitigate; redundancy is one mitigation lever (cuts S), risk management sets the acceptance thresholds, and the V-model is the surrounding process that decides when FMEA is done and verified.
Edge cases
What RPN does a truly harmless component get, and does it need a row?
forces , which stays small regardless of O and D. It still gets a row for completeness, but it lands in "monitor / no action".
Can RPN ever be exactly 0?
No. The minimum of each scale is 1, so the smallest possible RPN is . A row can never mathematically vanish — every risk carries at least a floor value.
Two mitigations both drop RPN below threshold — which do you pick?
Prefer the one that lowers S (you survive the failure) over one that only lowers O or D, because reducing severity protects you even if the failure occurs and detection later proves unreliable.
A mitigation lowers this row's RPN but creates a new failure mode elsewhere — what now?
Add a new FMEA row for the introduced mode and score it. Net risk, not just the original row, must improve; otherwise you've moved the danger, not removed it.
What if O is genuinely unknown (brand-new, untested technology)?
You must not leave it blank; assign a conservative (high) O reflecting limited data, which raises RPN and correctly forces testing to earn a lower, evidence-based score later.
A failure is caught exactly as the mission impact begins — what D range fits?
Around ("low" detection): detected only after impact starts, so it's too late to fully prevent the effect but recovery may still be partial.
If S, O, and D are all mid-scale (say 5 each), is RPN "medium"?
— inside the 50–150 review band, so "medium" is fair here, but never assume mid-inputs give mid-RPN in general: a single high factor can push an otherwise-average row into the action zone.
Recall One-line self-test
Adding a perfect early-warning sensor changes which score, and in which direction? ::: It lowers D (detection improves), which lowers RPN — even though the failure still occurs at the same rate.