Visual walkthrough — FMEA — failure mode, effect, severity, detection, RPN
We are going to answer one question: given a component that might break, how do we turn our worry about it into a single measurable size we can rank against every other worry?
Step 1 — A failure is an event, and events have three independent handles
WHAT. Before any numbers, picture a single component — say one battery cell. It sits there doing its job. Then, at some moment, it fails. That failure is an event: a thing that either happens or doesn't.
WHY. We cannot rank "worry" directly — worry is a feeling. To rank, we need a size. So we must first ask: what makes one failure scarier than another? Not one thing. Three separate things, and they are genuinely independent — knowing one tells you nothing about the others:
- How bad is it if it happens? (this is Severity, written )
- How often will it happen? (this is Occurrence, written )
- How blind are we to it happening? (this is Detection, written )
PICTURE. Look at the figure: one failure event in the centre, three arrows pulling on it in three completely different directions. A battery cell short is severe (arrow up is long), rare (arrow right is short), and visible (arrow down is short). These three are like the length, width, and height of a box — you cannot get one from the others.

Step 2 — Turn each handle into a number on a 1-to-10 ruler
WHAT. Each handle is a feeling ("pretty bad", "fairly rare"). We stamp a number from to onto it using a fixed, agreed-upon ruler. Not a random guess — a table everyone on the team reads the same way.
WHY 1 to 10, and why not a probability? A raw probability like is unreadable and does not mix with "severity" (which is not a probability at all — you can't put a probability on "loss of crew"). So we map everything onto the same – ruler. Now three unlike things speak one language and can be combined. The scale is deliberately coarse — a human can honestly tell a from a , but not a from a .
PICTURE. Three vertical rulers side by side, each marked at the bottom and at the top. On each, a red dot marks the battery-cell short: high up (near-catastrophe), low-ish (documented but rare), low (sensors catch it fast). Read the dots — that is the failure, now in numbers.

Step 3 — Why we multiply (and never add)
WHAT. We now combine , , into one number. The parent said "multiply". Here is the reason, drawn.
WHY not add? Suppose we added: . Then a failure with (catastrophic but essentially impossible and instantly caught) scores . A failure with (moderate, common, half-visible) also scores . Adding says they are equally worrying — but they are not. The catastrophic one is defused by being rare and visible. Addition lets one big term hide the others.
Multiplication does the opposite: it makes each factor a gate. If any factor is near , it shrinks the whole product. A failure is only truly dangerous when it is bad and likely and blind — all three at once. That "all three at once" is exactly what multiplication encodes.
PICTURE. Think of a rectangle: width , height . Its area is . Now push that rectangle into the page by depth — you get a box, and its volume is . The whole worry is the volume of that box. Look at the figure: shrink any one edge toward and the box collapses to a sliver — small volume, small worry. That is the multiplication doing its job.

Step 4 — Why Detection is scored backwards
WHAT. means we detect the failure almost perfectly; means it is invisible until disaster. This feels upside-down. Let's earn it.
WHY. The RPN is meant to measure danger, and danger grows with every factor. Severity grows danger (obvious). Occurrence grows danger (obvious). What grows danger for detection? Not good detection — bad detection. A failure you can't see coming is the scary one. So the "" ruler must measure blindness, not sight, so that large pushes the volume up, in the same direction as large and large .
PICTURE. Two identical battery failures side by side. Left: sensors watching (good detection) — we relabel that as small , and the risk box is short in depth. Right: no sensor, silent leak — large , and the same failure now has a deep, large-volume box. Same , same , but the blind one is objectively more dangerous, and only " = blindness" makes the volume reflect that.

Step 5 — Reading the volume: thresholds and the danger ceiling
WHAT. One number came out. Now we sort it into action bands. The box's volume ranges from the smallest possible to the largest possible.
WHY have bands? A raw volume like means nothing alone. We need "how big is too big?" The team fixes cut-lines from mission history: below just watch it; up to review and test; up to redesign or add a backup; above you are not allowed to fly.
PICTURE. A single number line from to , split into coloured bands, with the battery-short RPN of marked as a red tick sitting in the "test-then-decide" band. You can literally see how far it is from the danger ceiling.

Step 6 — The corners: the smallest and largest possible boxes
WHAT. Every ruler runs to , so the box can never be smaller than nor bigger than . These are the two extreme corners of the whole space.
WHY show the edges? So you never meet a number you can't place. The degenerate best case: a harmless, impossible, obvious failure → . The degenerate worst case: a catastrophic, near-certain, invisible failure → . Every real failure lives inside this box-of-boxes.
PICTURE. The full cube from the tiny corner to the far corner , with the battery short plotted as a red dot floating inside — closer to the safe corner than the deadly one.

Step 7 — Shrinking the box: what mitigation does geometrically
WHAT. Fixing a failure means shrinking one or more edges of its box, lowering the volume until it drops below a threshold.
WHY. You rarely can't change (physics is physics — the cell can still short). But you can add a fuse to cut the damage (shrink ), and add a redundant monitor to catch it sooner (shrink ). Each design change pulls an edge inward and the volume falls.
PICTURE. The tall battery box on the left () with two red arrows squeezing the edge from and the edge from , producing the smaller box on the right (). Same failure — a much smaller box.

The one-picture summary
Everything above, compressed: a failure event → three independent rulers → one risk box whose volume is the RPN → sorted against a danger ceiling → shrunk by mitigation.

Recall Feynman retelling — say it back in plain words
Imagine a part that might break. Three totally separate questions decide how much I should lose sleep over it: how bad is the mess if it breaks, how likely is it to break, and how blind am I to it breaking. I score each one from one to ten on a fixed ruler everybody agrees on — and I score "blindness" not "sight", so that being unable to see it makes the number bigger, because that is genuinely more dangerous. Then I don't add the three numbers, because adding would let one huge number hide two tiny ones and pretend everything's fine. Instead I multiply them, like multiplying width, height, and depth to get the volume of a box. A failure is only truly scary when the box is big in all three directions at once — and multiplication guarantees that if any single direction is small, the whole box is small. The box's volume is the Risk Priority Number, always between one and a thousand. I line all my failures' boxes up, fix the biggest ones first by squeezing their edges down with fuses, backups, and better sensors, and re-measure. That's FMEA.
Recall Quick checks
Why multiply instead of add? ::: Multiplication makes each factor a gate — any factor near 1 shrinks the whole product, so a failure is only "big" if it is bad AND likely AND blind. Adding lets one big term mask small ones. Why is worse than ? ::: measures blindness, not detection quality. High = we never see it coming = more dangerous, so it must push the RPN up alongside and . What is the geometric meaning of RPN? ::: The volume of a box with edges , , . What are the smallest and largest possible RPN? ::: () and (). Battery short before/after mitigation? ::: before; after.
See also: parent topic · Reliability Engineering · Risk Management in Spacecraft Design · Systems Engineering V-Model · Quality Assurance and Testing · Mission Assurance · Mars Climate Orbiter