1. When the ocean flips a bit

Stanisław Lem’s Solaris returns as the recalled work because the station’s instruments must keep producing reliable readings even though the ocean below can generate phenomena that violate every assumption. The desktop’s compute must do the same: keep producing reliable results even when radiation flips bits in memory, registers, and configuration.

This entry defines success and failure for the single-event upset recovery test.

2. Minimum success

The test passes if:

  • All single-bit errors in protected memory are corrected without data loss.
  • Critical state is never corrupted by a correctable error.
  • Multi-bit errors within the designed correction capability are handled without service loss.
  • Multi-bit errors beyond the designed correction capability are detected and contained.
  • FPGA configuration upsets are repaired by scrubbing before they affect outputs.
  • Persistent storage writes are verified and bad blocks are managed.
  • Error events are logged with enough detail for ground analysis.
  • The platform returns to a stable state after each injected fault.

This minimum says the desktop’s layered radiation defenses work as designed.

3. Full success

A stronger result would add:

  • Correction is fast enough that real-time tasks meet deadlines despite repeated upsets.
  • Non-critical services also recover without manual intervention.
  • Error-rate trends trigger autonomous throttling or relocation before a hard failure.
  • The platform correlates error bursts with predicted radiation events.
  • No single SEU requires a platform reboot to recover.
  • Recovery actions consume predictable power and time.

This stronger result supports a claim that the desktop can operate autonomously through realistic radiation environments.

4. Failure modes

The test fails if any of the following occur:

  • A single-bit error in protected memory is not detected or not corrected.
  • A corrected error silently corrupts critical state before correction.
  • A multi-bit error within the designed capability causes data loss or service loss.
  • A multi-bit error beyond the designed capability is not detected.
  • An FPGA configuration upset is not repaired or produces an incorrect output.
  • A corrupted write to persistent storage is accepted as valid.
  • Error logging is missing, incorrect, or too late for ground analysis.
  • The platform does not return to a stable state after the fault is cleared.

Each failure mode points to a fix in ECC coverage, scrubbing frequency, voter design, storage verification, or recovery policy.

5. What this changes

  • The single-event upset recovery test has clear pass and fail criteria.
  • The criteria separate correction from containment and from graceful recovery.
  • The next entry will close the test arc.