Unit 17 · lesson
Reliability, Fault Trees, and FMEA
A system can work once and still be unreliable.
Reliability asks how consistently the system performs under its expected conditions.
Fault tree thinking
Start with an unwanted event:
robot cannot stop as commanded
Possible contributing branches:
stop command absent
OR
controller fails to process command
OR
communication path fails
OR
driver ignores command
OR
mechanical system cannot decelerate as expectedA fault tree forces you to look beyond one component.
FMEA-style thinking
Failure Mode and Effects Analysis is a structured way to examine potential failures.
For this course, use a simplified table:
| Failure mode | Effect | Severity | Likelihood | Detectability | Mitigation |
|---|---|---|---|---|---|
| encoder unplugged | speed feedback lost | high | medium | high | detect stale/invalid input, safe fallback |
| loose wheel hub | motion differs from encoder | medium | medium | medium | inspection + cross-check motion |
| camera delayed | stale perception | medium | low | high | timestamp and stale-data rejection |
The scores are comparative, not universal truth.
Common-mode failure
Redundancy can fail if both channels depend on the same thing.
Two sensors on the same loose mount are not independent.
Two computers on the same failed power rail may both disappear.
When you add redundancy, ask what they still share.
Analyze your robot
Pick five failure modes across different layers.
For each:
- effect;
- how you would detect it;
- how the robot should respond;
- what design change could reduce risk.
Rank the top two and explain why they deserve attention first.
FMEA makes vague reliability concrete
Failure Mode and Effects Analysis asks what can fail, what happens if it does, and how the system detects or reduces the problem.
Example:
| Failure mode | Effect | Detection | Mitigation |
|---|---|---|---|
| encoder cable disconnects | speed estimate invalid | no count change / plausibility check | stop affected motion |
| camera process crashes | perception unavailable | heartbeat timeout | slow/stop or alternate sensor |
| gripper object slips | mission loses payload | force/position check | retry or abort |
| battery voltage sags | controller may reset | voltage telemetry | reduce load / service battery |
This table is not a prediction that every failure will happen. It is a way to expose assumptions before they become surprises.
Severity is not probability
A rare failure can still deserve attention if its consequence is severe. A frequent minor failure may deserve attention because it destroys reliability even if it is not dangerous.
When prioritizing, consider separately:
- severity;
- likelihood;
- detectability;
- recovery cost.
Do not collapse those ideas too early into one magic score. The discussion behind the rating is often more valuable than the number.