Design a way through a failure

Redundancy — open definition provides another way to perform a function when something fails. It may use a spare component, parallel units or another operating mode. A duplicate box is useful only if the spacecraft can detect the relevant failure, isolate it and route power — open definition, commands and data to a working path.

Some backups are inactive until needed; others work at the same time. Each choice affects power, heat, complexity and the ability to detect hidden faults. The design question is specific: which failures can be tolerated, for how long, and with what loss of capability? No finite design covers every imaginable failure.

Consider two fictional units, each with a 0.10 probability of failure during one defined interval. If failures are independent and either surviving unit can do the job with perfect switching, both fail with probability 0.10 × 0.10 = 0.01. The modeled chance of retaining the function is therefore 0.99.

Those conditions are essential. A common power controller, shared cooling problem or identical software defect can defeat both units together. You cannot multiply individual probabilities as if failures were independent when one cause affects both. The arithmetic is a model demonstration, not a reliability claim about an actual spacecraft.

Fault protection compares observations with expectations and chooses a response. Detection must distinguish a real problem from an unusual but acceptable condition. Isolation limits the damage; recovery attempts to restore an allowed mode. A response that is too aggressive can turn a temporary sensor anomaly into an avoidable shutdown.

In a hypothetical low-power event, stopping science collection might preserve command reception and temperature control. A safe mode — open definition prioritizes a defined survivable state and communication when possible. It does not guarantee a repair, and its success depends on the remaining hardware and environmental conditions.

Two units do not always mean two paths

Inject representative faults into a controlled test environment: missing messages, invalid values, an unavailable unit or a failed switchover. Check the complete chain from detection through hardware behavior and operator information. A test that only confirms an alarm appears may leave the most consequential actions unverified.

Return to the observation dependency diagram from the first lesson. Identify one shared component whose loss defeats two nominally redundant branches. Then propose evidence that would support a mitigation: separation, isolation, a genuinely different path or a reduced mission mode. Reliability comes from these explicit arguments and tests, not the number of boxes in a drawing.