SpaceOS on the spacecraft

SpaceOS runs on the payload side of the spacecraft. It does not fly the vehicle. The flight computer remains in charge and continues running if the payload computer fails.

Flight OS, container platform, and SpaceOS

SpaceOS handles payload middleware rather than flight control or general-purpose Linux application deployment.

	Flight OS	Container platform	SpaceOS
Examples	VxWorks, RTEMS, PikeOS	Docker or K3s on Linux, Yocto plus containers	MirageOS and Unikraft unikernels on Solo5, KVM, Xen, or a separation kernel
Job	The bus: attitude and orbit control, power, thermal, instrument timing	General-purpose application deployment on Linux	Payload middleware: deploying, isolating, and supervising mission applications
Real-time	Hard real-time scheduling	None	None
Isolation	ARINC 653 partitioning, separation kernel	Linux namespaces, shared kernel	One VM per workload, no shared kernel; a container mode shares the control-plane kernel
Footprint	Minimal, bare-metal or RTOS image	Hundreds of MB	Single-digit MB per unikernel
Updates	Full image replacement, infrequent	Registry pull	Delta-encoded OCI images over CCSDS links
Written by	Embedded specialists in C or Ada	Application developers using container tooling	Application developers in OCaml, C, C++, Python, or Rust

SpaceOS keeps the Docker workflow (build an image, push it to a registry, deploy it to a target) but executes a unikernel with no kernel underneath it rather than a process sharing one. VxWorks or PikeOS runs the bus; SpaceOS runs beside it on the payload computer and handles the software lifecycle for work that has no control-loop deadline.

Software domains

A spacecraft running SpaceOS has two software domains:

• The flight domain controls attitude, propulsion, power, and spacecraft commands. It usually runs a real-time operating system (RTOS) with a flight-software framework such as JPL’s F-Prime or NASA’s cFS. It has its own boot, its own fault detection, isolation, and recovery (FDIR), and a hardware watchdog: a timer that resets the computer if software stops refreshing it.
• The payload domain runs SpaceOS on a payload or mission computer. SpaceOS checks and starts isolated workloads. It also handles payload data sent to and from ground.

The flight computer boots and recovers without SpaceOS. SpaceOS may read telemetry and relay a signed command, but it cannot restart the flight computer, override it, or refresh its watchdog.

The flight computer runs the RTOS, flight framework, control functions, FDIR, and watchdog. The payload computer runs the SpaceOS control plane and isolated workloads, each in a hardware-isolated micro-VM (hvt) or a Linux container (runc). A spacecraft bus carries frames between the two domains, each frame tagged with an APID, the CCSDS number that says which stream it belongs to. The payload computer connects separately to the ground link and to any bulk-data instrument links.

The domains may run on separate computers. They may also share hardware under a separation kernel or a flight-owned hypervisor. In every layout, the flight computer keeps the same control.

Inspect the spacecraft boundary

Start with the target record. It shows which profile, ground route, and signing key the deployment will use:

space target show sat-42

Resolve the release without sending it:

space deploy payload:release --target sat-42 --plan

Check which telemetry IDs the payload may use and where its messages may go. The plan also shows what resets the payload computer and which key approves its boot image. Then deploy and watch the result:

space deploy payload:release --target sat-42
space status <deploy-id>

space status reports when the files arrive, when the node installs them, and when the new software passes its health checks. File delivery alone does not mean that the software is running.

Link responsibilities

• The spacecraft bus carries fixed-size, APID-tagged frames in both directions: flight telemetry, events, and parameters flowing to payload and ground; authorized commands flowing back. An isolated bus adapter owns the physical device, enforces direction and frame bounds, and fails closed on malformed traffic. Applications access it through the adapter.
• The flight computer checks every command. Each command names its target and action. It also carries limits, a sequence number, an expiration, and a signature. SpaceOS relays the command. The flight computer checks it before acting and reports the result in telemetry.
• The radio belongs to whichever domain the integration gives it. With full OS support SpaceOS frames the downlink itself (CFDP over BPv7/BPSec end to end, SDLS per hop); in a daemon install it can hand the framed stream to your flight software for transmission.
• High-throughput instrument data uses a separately granted bulk link distinct from the command path, over a spacecraft-grade serial fabric such as SpaceWire or SpaceFibre.

FDIR ownership

Each failure is handled at the smallest boundary that explains it. SpaceOS responses do not reach into the flight domain. An SEU is a single-event upset, a bit flipped by ionizing radiation.

Failure	Detected by	Response	Contained to
Service crashes or fails its healthcheck	The runner’s probe	Isolate, back off, relaunch that service	One service
Guest wedges (alive but silent)	Heartbeat stall on the supervision page	Restart that partition	One partition
SEU corrupts payload memory	Partition isolation; verified reads (dm-verity)	Contained; affected partition restarted	One partition
Payload control plane faults	space-init’s internal FDIR	Payload safe mode or power-off	The payload computer
Payload computer hangs	Hardware watchdog on the payload node	Reset; boot falls back to the last healthy release	The payload computer
Flight domain faults	Your FDIR and your watchdog	Your recovery, untouched by any of the above	Yours to bound

Payload-domain failures are contained to the payload domain. A dead payload computer cannot reset flight, refresh its watchdog, suppress its FDIR, or acquire a more privileged command channel. If the bus is congested, payload telemetry may be dropped under policy; it may not block a control loop.

Know what SpaceOS can control

• It provides no hard-real-time guarantees and schedules no fixed time windows; anything with a control-loop deadline stays in your domain.
• It cannot originate flight commands; it relays signed objects your domain independently verifies.
• Its workloads run inside fixed resource envelopes set at deployment (memory per partition, CPUs per service), so a runaway payload job is a starved payload job, not a bus event.
• Workload and system updates apply only to the payload computer. They are health-gated with automatic fallback and survive power loss at any instant.

Integration inputs

Integration requires four inputs:

1. The bus binding. Select the physical transport (MIL-STD-1553, CAN, serial, SpaceWire) and the frame budget; the payload-side protocol is the same fixed-size message format in every topology.
2. The APID plan. Declare which telemetry your domain publishes and which command streams it accepts; SpaceOS routes by identity underneath and treats APIDs as labels.
3. The command authority. Pin the public keys whose signed commands your domain will accept. Key custody stays with you.
4. The simulator, if you want one. A flight simulator attaches as a bus peer at deploy time, indistinguishable to consumers from the real flight node but unmistakably marked in provenance. Testing against a ground twin, a stand-in for the flight computer, therefore exercises exactly the interfaces flight will.

A physical bus binding is qualified by fault-injection tests: malformed traffic, saturated payload, adapter crash, cable loss, and stale or duplicated commands, all while your watchdog and FDIR keep running.