1. When a single bad assumption spreads

Michael Crichton’s The Andromeda Strain returns as the recalled work because its crisis begins with a small, unexpected behavior that propagates through a tightly coupled system. Software faults behave the same way: a corrupted value, a stale pointer, or a missed deadline in one task can cascade into others. The desktop’s flight software must be tested to see whether it contains such cascades.

This entry explains why the software fault injection test matters.

2. Why architecture reviews are not enough

The flight software reading arc established that the desktop should use a layered, message-based architecture with fault containment. Architecture is a design claim. The software fault injection test is the experiment that validates the claim.

Without fault injection, the desktop might discover these problems only after launch:

  • A memory leak in a low-priority task eventually exhausts the heap and crashes a critical service.
  • A corrupted telemetry message causes a subscriber to divide by zero.
  • A task that should be restarted hangs instead, blocking a queue.
  • A software update leaves two applications expecting incompatible message formats.
  • A safe-mode transition fails because the safe-mode image depends on a service that has already failed.

3. The failures that only appear when faults are forced

Fault injection exposes behaviors that do not appear in nominal testing:

  • A watchdog fires but the recovery action is itself faulty.
  • A task restart frees a resource that another task still needs.
  • A message queue fills because a producer outruns a consumer after a fault.
  • A fallback algorithm is slower than expected and misses its deadline.
  • A fault in one cell causes a federation-wide reaction that makes things worse.

4. What this test must cover

The software fault injection test must exercise:

  • Single-task faults: crash, hang, exception, and memory corruption in individual applications.
  • Message faults: corrupted, delayed, missing, or duplicated messages on the software bus.
  • Resource faults: memory exhaustion, CPU overload, and queue overflow.
  • Timing faults: missed deadlines and priority inversion scenarios.
  • Version faults: incompatible application or configuration versions.
  • Update faults: failed activation and rollback scenarios.

The goal is to prove that the software architecture can absorb faults and recover cleanly.

5. What this changes

  • Software fault injection testing is identified as the next qualification step for the desktop.
  • The test must verify fault containment and recovery, not just fault detection.
  • The next entry will define the test matrix.