Reliability and fault response
Identify credible faults, detect them independently where possible, and choose bounded degraded or safe responses instead of promising fault-free operation.
- Build a fault-response table, estimate simple series reliability, and verify that one seeded low-energy fault becomes detectable and leads to a defined state.
Related study — optional context
Understand
The working idea
Reliability is the probability that a system performs its required function under stated conditions for a stated time. Safety asks about unacceptable harm; availability asks whether service is ready. They overlap but are not synonyms. A robot can be safely stopped yet unavailable, or highly available while hiding a hazardous failure. Requirements need operating conditions and time horizon rather than adjectives such as “robust.”
A fault is a cause, an error is an incorrect internal state, and a failure is externally incorrect service. A loose encoder connector is a fault; a frozen wheel count is an error; driving the wrong distance is a failure. A fault-response table lists cause, observable symptom, detection, reaction, recovery, and retained evidence. For independent series elements whose success probabilities are R1 and R2, combined success is R = R1R2. Two elements each at 0.99 yield 0.9801, showing that adding required parts can reduce mission reliability. Independence is a strong assumption, not a free fact.
Detection should use independent evidence when practical. A commanded motor with zero encoder change could mean a disconnected encoder, stalled wheel, or driver problem; current and inertial motion can separate hypotheses. The build decision might be: if command exceeds 20% for 300 ms while encoder count stays unchanged, command zero and latch DRIVE_FAULT. Threshold and delay must reject normal startup yet respond before damage, using tested bounds.
A common misconception is that redundancy automatically improves reliability. Two sensors sharing one connector, supply, algorithm, or environmental weakness can fail together; voting also introduces logic and diagnostic complexity. Another failure is automatically resetting faults so quickly that evidence disappears or motion resumes into the same condition. Prefer bounded energy, explicit safe or degraded states, latched cause records, and deliberate recovery criteria. Do not create destructive faults to test them: inject messages, disconnect only unpowered low-voltage signals, or use simulation and current limits.
Follow the reasoning
Worked example
A mission requires a controller (R = 0.995), motor driver (0.990), and encoder (0.985), treated as independent series elements. Estimate mission success probability.
- 1
Multiply the controller and driver reliability: 0.995 × 0.990 = 0.98505.
- 2
Include the encoder: 0.98505 × 0.985 = 0.97027425.
- 3
Estimated failure probability for at least one required element is 1 - 0.97027425 = 0.02972575, about 2.97%.
Under the stated independence and mission definitions, estimated system reliability is about 97.03%.
Sanity checkSeries reliability is lower than the least-reliable component’s 98.5%, as it must be when every component is required.
Try it yourself
Independent check
Move to the bench
Verify a safe, observable response to a seeded sensor-staleness fault.
- Microcontroller
- LED output or restrained low-voltage robot
- sensor or synthetic data source
- serial console
- timer
Experiment
- Write a table for stale sensor data: detection threshold, safe output, latched evidence, and explicit recovery condition.
- Run fresh timestamped samples at 20 Hz and enable a bounded LED duty or raised-wheel motion command.
- Introduce a deliberate fault by pausing sample publication in software; do not short or overvoltage hardware.
- Measure time from last fresh sample to fault detection and output-zero command; verify the cause remains logged after recovery.
- Repeat with one late sample below the threshold and a sustained pause above it to examine nuisance-trip tradeoffs.
Observe
- Expected: data age crosses the threshold, the system enters a named fault state, and bounded output goes to zero.
- Record actual last-sample, detection, and output timestamps separately from the configured threshold.
- Expected diagnostic: a short allowed delay does not latch, while the sustained pause does; actual boundary behavior must be measured.
Draft fault responses for a camera occlusion, one stuck wheel, and a low battery, distinguishing continue-degraded, stop, and operator-recovery decisions.
- Inject software or unpowered low-voltage connector faults only; keep motion restrained and never test protection by defeating it or intentionally overheating/stalling hardware.
Keep evidence
Bench note
Record what you expected, what you actually measured or observed, and one difference worth investigating. This is self-reported evidence, not a certification.