Reliability and fault response

• 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.

• experimental-method
• robot-architecture

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.

Problem

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.

Steps

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%.

Result

Under the stated independence and mission definitions, estimated system reliability is about 97.03%.

Sanity check

Series reliability is lower than the least-reliable component’s 98.5%, as it must be when every component is required.

Two identical distance sensors share one supply and face the same glossy surface. Why is treating their failures as independent questionable?

A. Because two sensors can never improve a system B. Because common power and environmental conditions can cause correlated failures in both channels C. Because reliability multiplication always produces a number above one D. Because software cannot compare two values

Your answer: ______________________________

Reasoning:

Goal

Verify a safe, observable response to a seeded sensor-staleness fault.

Equipment

• Microcontroller
• LED output or restrained low-voltage robot
• sensor or synthetic data source
• serial console
• timer

Procedure

1. Write a table for stale sensor data: detection threshold, safe output, latched evidence, and explicit recovery condition.
2. Run fresh timestamped samples at 20 Hz and enable a bounded LED duty or raised-wheel motion command.
3. Introduce a deliberate fault by pausing sample publication in software; do not short or overvoltage hardware.
4. Measure time from last fresh sample to fault detection and output-zero command; verify the cause remains logged after recovery.
5. Repeat with one late sample below the threshold and a sustained pause above it to examine nuisance-trip tradeoffs.

What to 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.

Transfer challenge

Draft fault responses for a camera occlusion, one stuck wheel, and a low battery, distinguishing continue-degraded, stop, and operator-recovery decisions.

Cautions

• Inject software or unpowered low-voltage connector faults only; keep motion restrained and never test protection by defeating it or intentionally overheating/stalling hardware.

Learner: ____________________ Date: ____________________

Evidence artifact or file: ____________________________________________

Notes: