1. The sensor that disagreed with itself

Arthur C. Clarke’s 2001: A Space Odyssey returns as the recalled work because HAL 9000 is, among other things, a catastrophic example of fault management gone wrong: a system that detects an inconsistency, concludes the humans are the fault, and recovers by removing them. Real spacecraft FDIR is less dramatic and more rule-bound, but it faces the same basic problem — when sensors or subsystems disagree, something has to decide what to trust and what to do.

This entry reads about fault detection, isolation, and recovery (FDIR).

2. The FDIR cycle

FDIR is the discipline of keeping a spacecraft operational in the presence of faults. The cycle has three steps:

  • Detection: recognize that something is off-nominal. This can be limit checking, redundancy voting, model-based comparison, or anomaly detection.
  • Isolation: identify which subsystem or component is responsible.
  • Recovery: take action to restore function or reach a safe state.

A NASA survey of FDIR for autonomous space systems notes that modern FDIR must handle discrete sensor faults, actuator faults, and cascading failures while the spacecraft continues its mission.

3. Architectures: centralized, distributed, hybrid

FDIR can be organized in different ways:

  • Centralized: a single fault-management computer gathers telemetry, runs diagnostics, and issues recovery commands. Simple, but a single point of failure.
  • Distributed: each subsystem runs its own FDIR and reports status. Resilient, but harder to coordinate.
  • Hierarchical: low-level FDIR handles local faults quickly; higher-level FDIR handles system-wide effects and resource conflicts.

The CubeSat flight-software survey describes a typical ECSS-aligned FDIR process: define autonomy levels, partition functions between hardware and software, build a failure-mode list, and then derive recovery procedures.

4. E3 and event-driven FDIR

ECSS E3 missions introduce event-driven autonomy. As described in the AI-driven FDIR overview, faults are treated as events that trigger on-board control procedures (OBCPs) through PUS Service 19. A star-tracker anomaly, for example, can automatically activate a backup tracker and run diagnostics without waiting for ground command.

The DLR/ESA survey on AI in space adds that anomaly detection, health monitoring, and autonomous recovery are active research areas, with model-based and data-driven methods both in use.

5. What this changes

  • FDIR is not an afterthought; it shapes the autonomy architecture.
  • The desktop needs a hierarchical FDIR design: local fast responses at the cell level, system-wide coordination at the platform level.
  • Event-driven procedures can reduce dependence on ground intervention.
  • The next entry will translate the autonomy and FDIR literature into requirements for the desktop.