1. The monks who preserved the code

Walter M. Miller Jr.’s A Canticle for Leibowitz returns as the recalled work because the novel’s monks preserve technical knowledge through dark ages when the infrastructure that created it has collapsed. The desktop’s flight software must be similarly preservable: organized, documented, and modular enough that future operators can understand and modify it long after the original developers have moved on.

Entries 597 through 599 read about flight software architectures, real-time operating systems, and what they mean for the desktop. This entry closes the arc.

2. What was learned

The flight software literature gives the desktop four constraints:

  • Layered architecture is standard practice. Hardware abstraction, core services, and applications should be separated.
  • Message-based communication decouples applications. This supports modularity, relocation, and runtime reconfiguration.
  • RTOS selection matters. VxWorks and RTEMS are both flight-proven, with different licensing and ecosystem trade-offs.
  • Runtime updateability is valuable. The ability to load, unload, and replace applications or tables reduces long-term risk.

3. What was decided

The desktop will adopt a layered, message-based flight software architecture running on a flight-proven RTOS. This means:

  • The software will be organized into hardware abstraction, core services, and application layers.
  • Applications will communicate through a publish-subscribe or equivalent message bus.
  • Critical tasks will run under deterministic scheduling.
  • The system will support runtime loading and unloading of applications and configuration tables.
  • The RTOS choice will be between VxWorks and RTEMS, based on licensing, certification, and hardware compatibility.

4. Interaction with earlier arcs

The flight software arc connects directly to the autonomy, communications, predictive maintenance, and long-duration autonomy arcs. It also supports the autonomous software update wondering arc and the software fault injection test arc that come next.

5. What remains open

The exact RTOS choice, the message bus implementation, and the partitioning between cell-local and platform-wide services depend on the hardware selection and operational concept. The reading arc has set the strategy; detailed software design comes later.

6. What this changes

  • The flight software reading arc is closed.
  • The desktop inherits explicit layered, message-based software architecture requirements.
  • Entry 600 is a small milestone: six hundred ledger entries.
  • The next arc will wonder about autonomous software update and patching in orbit.