FMEA — failure mode, effect, severity, detection, RPN

What is FMEA?

The Five Core Elements

Element	Definition	Scale	What It Measures
Failure Mode	The specific way a component fails	N/A	"Power supply shorts", "propellant leak", "sensor drift"
Effect	Consequence on subsystem/mission	N/A	"Loss of attitude control", "mission abort", "data corruption"
Severity (S)	Impact magnitude	1-10	1 = negligible, 10 = catastrophic (loss of crew/mission)
Occurrence (O)	Likelihood of failure	1-10	1 = extremely unlikely, 10 = almost certain
Detection (D)	Ability to catch failure before impact	1-10	1 = always detected early, 10 = undetectable until disaster

How to Perform FMEA: Step-by-Step Derivation

Step 1: Decompose the System

Break spacecraft into functional blocks (power, propulsion, thermal, C&DH, etc.), then into components (battery cells, thrusters, thermistors, CPUs).

Why? A "reaction wheel fails" is too vague. "Reaction wheel bearing seizes due to lubricant degradation" is actionable.

Step 2: Identify Failure Modes

For each component, ask: "What are all the ways this can fail?"

Example — Li-ion battery cell:

• Internal short circuit
• Electrolyte leakage
• Capacity fade beyond spec
• Thermal runaway
• Open circuit (connector failure)

Why exhaustive listing? The failure mode you don't consider is the one that kills the mission (see Mars Climate Orbiter: units mismatch wasn't in the FMEA).

Step 3: Analyze Effects (Local → Global)

Trace each failure mode up the system hierarchy:

Example: Battery cell internal short

1. Local effect: Cell voltage →0 V, current spike
2. Subsystem effect: Battery management system triggers emergency disconnect
3. System effect: Power bus drops below minimum → spacecraft safes (reaction wheels stop, transmitter off)
4. Mission effect: Loss of attitude control → solar panels misaligned → power death spiral → mission loss

Why trace upward? A "minor" component failure can cascade into mission-critical disaster.

Step 4: Score Severity (S)

Use a standardized scale (example aerospace scale):

| S | Effect | Description | |---|-------------| | 1 | None | No impact | | 2-3 | Minor | Slight performance degradation, no mission impact | | 4-6 | Moderate | Reduced capability, mission objectives partially met | | 7-8 | Major | Severe degradation, mission success at risk | | 9 | Critical | Mission failure, no crew injury | | 10 | Catastrophic | Loss of crew (human spaceflight) or flagship mission |

Battery cell short → S = 9 (mission loss) if no redundancy.

Why 1-10? Logarithmic-like scale reflects human risk perception (9→10 feels like a qualitative jump, not +1).

Step 5: Score Occurrence (O)

Estimate failure rate over mission lifetime:

O	Probability	Failure Rate Example
1	< 0.01%	1 in 1,000,000 hours (design proven over decades)
2-3	0.01-0.1%	1 in 100,000 hours
4-6	0.1-1%	1 in 10,000 hours (new design, limited testing)
7-8	1-10%	1 in 1,000 hours (known weakness)
9-10	> 10%	1 in 100 hours (almost certain to fail)

Battery cell short in Li-ion → O = 4 (rare but documented industry).

Why probabilistic? Converts "could happen" to "will happen X times per Y units", enabling Monte Carlo mission sims.

Step 6: Score Detection (D)

Rate how early and reliably you can detect the failure:

D	Detection	Description
1-2	Almost certain	Automated sensors, continuous monitoring, pre-failure warnings
3-4	High Periodic checks detect before mission impact
5-6	Moderate	Detected during failure, but correctable
7-8	Low	Detected after mission impact begins
9-10	None	Undetectable until catastrophic failure

Battery cell short → D = 3 (voltage/current sensors catch it within seconds, BMS disconnects).

Why detection matters? A high-S, high-O failure with low D (we catch it early) can be managed. Same failure with high D is a silent killer.

Step 7: Calculate RPN and Prioritize

$\text{RPN}_{\text{battery short}} = 9 \times 4 \times 3 = 108$

Interpretation:

• RPN < 50: Monitor, no immediate action
• RPN 50-150: Design review, test-then-decide
• RPN 150-500: Redesign or add redundancy
• RPN > 500: Unacceptable — must fix before flight

Why the threshold? Based on industry data: missions with RPN > 500 items unfixed have ~60% higher in-flight anomaly rates.

Step 8: Mitigate and Recalculate

Mitigation for battery short:

• Add fuses to isolate failed cell (reduces Effect severity → S = 6)
• Increase cell testing (reduces O → 3)
• Add redundant voltage monitoring (reduces D → 2)

$\text{RPN}_{\text{new}} = 6 \times 3 \times 2 = 36 \quad (\text{acceptable})$

Why iterate? FMEA is a living document — every design change requires re-scoring.

Recall Explain to a 12-Year-Old

Imagine you're building a robot for a science fair on Mars. Once you launch it, you can't go fix it if something breaks. So before you launch, you sit down and play a game called "What Could Go Wrong?"

You list every single way each part could break: the battery could die, a wheel could get stuck, a wire could snap. For each break, you imagine: "OK, if that happens, what breaks next?" Maybe the stuck wheel makes the robot spin in circles, then it can't charge its solar panels, then it dies.

Then you give each break a score:

• How bad is it? (Severity) Does the robot just get confused for a second, or does it die forever?
• How likely is it? (Occurrence) Does this break happen to1 in 10 robots, or 1 in 1000?
• Can you see it coming? (Detection) Does the robot bep a warning, or does it just suddenly stop?

You multiply those three scores to get a danger number (RPN). The biggest danger numbers are the problems you must fix before launch — maybe add a backup wheel, or a sensor that yells "hey, I'm about to break!"

That's FMEA: a checklist to make sure you thought of every way things could fail, and fixed the scariest ones. Because once your robot is on Mars, it's on its own.

Connections

• Risk Management in Spacecraft Design — FMEA is one tool in a broader risk framework (also FMECA, fault trees, hazard analysis)
• Reliability Engineering — FMEA feeds into reliability predictions (MTBF, survival curves)
• Redundancy and Fault Tolerance — High-RPN failures drive redundancy requirements (dual-string power, quad reaction wheels)
• Systems Engineering V-Model — FMEA starts at preliminary design, updates through testing and flight
• Quality Assurance and Testing — Detection (D) scores depend on test coverage and-orbit monitoring
• Mission Assurance — FMEA evidence required for flight readiness reviews
• Mars Climate Orbiter — Case study: unit conversion error not in FMEA → mission loss

#flashcards/physics

What does FMEA stand for and what is its purpose? ::: Failure Mode and Effects Analysis — a systematic method to identify all possible component failure modes, analyze their effects on the system/mission, and quantify risk using Severity, Occurrence, and Detection scores to prioritize mitigation before launch.

What are the five core elements of FMEA? :::

1. Failure Mode (specific way a component fails),2. Effect (consequence on subsystem/mission), 3. Severity (S, impact magnitude 1-10), 4. Occurrence (O, likelihood 1-10), 5. Detection (D, ability to catch before impact 1-10).

What is the Risk Priority Number (RPN) formula and why do we multiply? ::: RPN = S × O × D. We multiply because each factor is a conditional probability gate: high severity is only catastrophic if it's likely AND undetectable. Multiplication captures the compounding risk.

What RPN ranges correspond to action thresholds in spacecraft FMEA? ::: < 50: monitor, 50-150: review and test, 150-500: redesign or add redundancy, > 500: unacceptable and must fix before flight.

A reaction wheel bearing fails (S=8, O=5, D=4, RPN=160). After adding redundancy, S drops to 4 and predictive monitoring drops D to 2. What is the new RPN and is it acceptable? ::: New RPN = 4 × 5 × 2 = 40. This is acceptable (< 50), showing that redundancy (cuts S) and monitoring (cuts D) successfully mitigated a high-RPN failure.

Why is scoring Detection (D) based on ground testing a mistake? ::: Because D measures in-flight detection capability, not ground test detectability. Failures that only manifest after years in orbit (wear, UV degradation) won't appear in months-long ground tests. D=1 requires continuous on-orbit monitoring with early warning.

Two failures both have RPN=180. Failure A: S=10, O=2, D=9. Failure B: S=6, O=6, D=5. Which is more dangerous and why? ::: Failure A is far worse. It's catastrophic (S=10) and undetectable (D=9), meaning when it happens (even if rare), it kills the mission with no warning. Failure B is frequent but survivable and detectable. RPN hides this — always prioritize high S first.

What is the purpose of running FMEA on the mitigation itself? ::: Mitigation adds complexity (redundancy, sensors, watchdog code), which introduces new failure modes. You must verify that the RPN reduction is real and not just transferred to a different component (e.g., shared power bus becoming a single-point failure).

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

FMEA yani Failure Mode and Effects Analysis ek bahut zaroori process hai spacecraft design mein. Socho ki tumne ek satellite banaya, aur launch hone ke bad agar kuch fail ho gaya toh tum physically jake fix nahi kar sakte — isliye pre-launch planning mein hi har possible failure ke bare mein sochna padta hai. FMEA kehta hai: har component ke liye list karo ki wo kis-kis tarah se fail ho sakta hai (battery short circuit, reaction wheel jam, sensor drift), phir dekho ki agar wo fail hua toh system pe kya effect hoga (loss of power, attitude control gaya, mission khatam).

Har failure ko teen number milte hain: Severity (S) yani kitna bhayankar hai (1 = kuch nahi hua, 10 = pura mission fail), Occurrence (O) yani kitni baar ho sakta hai (1 = bahut rare, 10 = paka hoga), aur Detection (D) yani kya tum pehle hi pakad loge ya disaster ke time pata chalega (1 = sensors alert kar denge, 10 = pata hi nahi chalega). In teno ko multiply karo: RPN = S × O × D. Jo failure ka RPN sabse zyada hai, wahi tumhara priority hai fix karne ke liye — redundancy add karo, testing badhao, monitoring sensors lagao. FMEA ek living document hai, har design change ke baad phir se calculate karna padta hai ki risk kam hui ya nahi. Ye systematic approach ensure karta hai ki tumne "What if...?" har scenario ke liye pucha, taki space mein jake surprise na mile.