1. The primer that ran on many layers
Neal Stephenson’s The Diamond Age returns as the recalled work because the Young Lady’s Illustrated Primer is a distributed system: some intelligence lives in the book, some in remote actors, some in the girl’s environment. The desktop is similar. Its software is not a single program but a federation of tasks running across cells, with some logic local and some delegated to ground.
This entry applies the flight software and RTOS literature to the desktop.
2. The desktop’s software-relevant features
The desktop has several characteristics that shape its flight software architecture:
- Multiple cells: compute, storage, power, thermal, communications, and payload functions may run on different processors.
- Modularity: cells can be added, removed, or upgraded independently.
- Long life: software will need updates after launch.
- Mixed criticality: some tasks are safety-critical; others are best-effort customer payloads.
- Autonomy: decisions must be made locally when ground is unavailable.
These features push the desktop toward a layered, message-based, modular software architecture.
3. Derived requirements
The flight software literature gives the desktop six practical requirements:
- Layered architecture: separate hardware abstraction, core services, and applications so that changes at one layer do not ripple unpredictably.
- Message-based inter-application communication: use publish-subscribe or similar patterns so that applications can be relocated or replaced without rewriting interfaces.
- Runtime loading and unloading: support starting, stopping, and replacing applications or configuration tables without a full reboot.
- Deterministic scheduling for critical tasks: attitude, thermal, power, and fault protection must meet deadlines.
- Fault containment: a fault in one application should not corrupt the entire system.
- Multi-cell coordination: the software architecture must span cells, not just a single processor, with clear interfaces between cell-local and platform-wide services.
4. Interaction with earlier arcs
The flight software arc connects to several earlier decisions:
- The autonomy literature arc defined the need for hierarchical decision-making.
- The communications arc defined the need for adaptive, multi-path links.
- The predictive maintenance arc defined the need for health monitoring and trend analysis.
- The software fault injection test arc that comes next will verify these architectural choices.
5. What this changes
- The desktop inherits explicit flight software architecture requirements.
- The software design should favor modularity, message passing, runtime reconfiguration, and fault containment.
- The next entry will close the flight software reading arc and record the decision.