1. The computer that ran the Moon

Robert A. Heinlein’s The Moon Is a Harsh Mistress gives us Mike, a computer that becomes sentient and ends up managing much of Luna’s infrastructure. Mike is a fantasy, but the underlying idea is practical: a lot of operations work is repetitive, time-critical, and better done by software than by humans refreshing a screen. The desktop’s flight software will not become sentient, but it should be smart enough to keep the spacecraft alive between ground contacts.

Entry 266 sized the ground segment. This entry defines what the desktop’s onboard software does on its own.

2. What flight software is

Flight software is the layer that connects the hardware to the mission. It runs on the compute attachment and is responsible for:

  • Executing scheduled commands and sequences.
  • Collecting and storing telemetry.
  • Running the ADCS control law and estimator.
  • Managing power states and thermal limits.
  • Handling communications protocols and file transfers.
  • Detecting faults and escalating to safe mode.
  • Serving as the interface between the ground and the subsystems.

It is not the same as the payload application software that processes images or serves customers. Flight software is the operating system of the spacecraft.

3. Autonomy level for the desktop

The desktop targets moderate autonomy. It does not need to be a fully autonomous agent, but it cannot require human approval for every action.

Autonomous functions:

  • Attitude control and momentum dumping.
  • Power management: battery charging, load shedding, eclipse entry and exit.
  • Thermal management: heater control, safe mode triggers.
  • Safe mode entry and recovery.
  • Execution of pre-loaded command schedules.
  • Storage management: file creation, deletion, and prioritisation.
  • Basic fault detection and logging.

Ground-instructed functions:

  • New mission schedules and observation campaigns.
  • Propulsive manoeuvres.
  • Software updates and configuration changes.
  • Payload calibration and special tests.
  • Recovery from anomalies that the onboard software cannot classify.

This split keeps the spacecraft alive while reserving important decisions for humans.

4. The command executor

The command executor is the part of flight software that takes uplinked commands and turns them into actions. It must be predictable and robust. A few design rules:

  • Commands are atomic and verifiable.
  • Dangerous commands, such as thruster firing or software updates, require confirmation or are disabled by default.
  • Command sequences can be stored and executed at scheduled times.
  • Commands can be aborted if a precondition fails.
  • All commands and their outcomes are logged.

The executor is the boundary between ground intent and spacecraft action. It should be conservative: if in doubt, do not execute.

5. The scheduler

The scheduler runs the daily mission timeline. It decides when to point the solar arrays at the Sun, when to take images, when to downlink data, and when to slew between targets. The scheduler must respect constraints:

  • Power balance: do not schedule high-power activities during eclipse or low battery state.
  • Thermal balance: do not point sensitive surfaces at the Sun for too long.
  • Communications: align high-data activities with upcoming ground passes.
  • ADCS: avoid slews that would saturate reaction wheels before a momentum dump opportunity.
  • Customer priorities: rank observation requests by value and feasibility.

For the desktop, the scheduler can be relatively simple at first: a time-ordered list of activities with hard constraints. As operations mature, it can become more optimisation-driven.

6. Telemetry and data management

Flight software collects housekeeping data at a regular cadence, typically 1 Hz or faster for critical parameters. It stores this telemetry in a circular buffer and downlinks the most relevant parts during each ground pass. It also manages payload data files, keeping track of what has been downlinked and what is still on board.

A key function is data prioritisation. If storage is limited, older or lower-priority data is overwritten. If a ground pass is short, only the highest-priority files are downlinked.

7. Fault protection

Fault protection is the set of rules that detect when something is wrong and respond. The hierarchy is:

  • Monitoring: continuously check temperatures, voltages, currents, wheel speeds, attitude errors, and communication status.
  • Detection: compare measured values to limits and raise flags when limits are exceeded.
  • Response: take automatic action for known faults, such as entering safe mode, switching to redundant hardware, or shedding loads.
  • Reporting: log the fault and include it in telemetry for ground analysis.

The desktop’s fault protection should be layered. Simple faults are handled automatically. Complex or ambiguous faults trigger safe mode and wait for ground instruction.

8. Software architecture

A practical flight software architecture for the desktop:

  • Real-time operating system: FreeRTOS, RTEMS, or a Linux real-time patch. Provides task scheduling and inter-process communication.
  • Core services: command and telemetry handling, file system, time management, watchdog.
  • Subsystem interfaces: drivers for the radio, ADCS hardware, power system, thermal system, and payload.
  • Application layer: ADCS estimator and controller, scheduler, fault protection, payload interface.
  • Ground interface: packet parser, command validator, telemetry formatter, file transfer protocol.

The architecture should be modular so that individual subsystems can be tested and updated independently.

9. Updates and patches

Flight software will need updates. The desktop must support in-orbit software uploads, verification, and rollback. A common approach is to keep two software images: the active image and a fallback image. A new image is uploaded, verified by checksum, and then activated. If the new image fails, the system reverts to the fallback.

This capability is essential for a long mission. It is also risky, so updates are planned, verified on the ground, and executed during a contact window when the ground can monitor the result.

What this changes

  • The desktop’s flight software is the operating system of the spacecraft, running on the compute attachment.
  • Autonomy is moderate: routine housekeeping and safe mode are autonomous; manoeuvres and schedule changes are ground-instructed.
  • A command executor, scheduler, telemetry manager, and fault protection layer are the core functions.
  • The scheduler must respect power, thermal, communications, ADCS, and customer constraints.
  • Software updates are supported with dual-image rollback.
  • The next entry will define command procedures and anomaly response.