On-Orbit Software Updates: Architecture Patterns

Software updates to spacecraft are among the highest-stakes software operations in any domain. When you push an update to a production SaaS platform and something goes wrong, you roll back in minutes. When you push an update to an on-orbit spacecraft and something goes wrong, you may have a non-operational satellite, limited ground contact windows to diagnose it, and no ability to physically intervene.

This reality shapes every architectural decision in on-orbit software update systems. The patterns described here reflect the engineering rigor that spacecraft ground systems require — architecture that assumes failures will occur and designs for controlled recovery.

The Fundamental Architecture: Ground-to-Space Software Delivery

An on-orbit software update follows a structured path from development to execution aboard the spacecraft:

Developer → Version Control → Build System → Ground System → Upload Queue → Uplink Pass → On-board Execution

Each stage has verification gates. The architecture must guarantee that only cryptographically signed, validated software can be loaded onto the spacecraft — an unsigned or corrupted payload must be detected and rejected before it ever reaches the vehicle.

Ground System Commanding Layer

The ground system commanding layer receives software patch files from the delivery pipeline and translates them into spacecraft commands. For most spacecraft, this means breaking the software binary into transfer frames that fit within the uplink data rate and protocol frame size.

Key architecture decisions:

Protocol choice: CCSDS (Consultative Committee for Space Data Systems) standards define the standard space data link protocols. CCSDS TC (Telecommand) space data link protocol provides error detection and optional command authentication for uplink frames. If your spacecraft doesn't use CCSDS natively, you're defining a custom protocol with custom error handling — adding risk.

Authentication: All commanding should use an authentication scheme. CCSDS SDLS (Space Data Link Security) provides authenticated commanding. At a minimum, the ground system should sign software upload commands with a hardware security module (HSM) — key material for spacecraft commanding must never exist in software-accessible memory on a network-connected host.

Transfer sequencing: Multi-frame uploads require ordered delivery. Implement sequence numbering and acknowledgment at the application layer, not just at the link layer — link-layer acknowledgment tells you the frame reached the spacecraft receiver, not that it was correctly buffered in on-board memory.

On-Board Software Update Execution

Once the software package arrives on the vehicle, on-board software manages loading and activation. This is where the most critical architectural decisions live.

Memory Architecture for Safe Updates

Spacecraft software update architectures use one of two primary memory models:

Dual-bank flash (A/B partitioning): The spacecraft maintains two complete copies of flight software in separate flash memory regions — Bank A (active) and Bank B (standby). Software updates load to the inactive bank while the spacecraft continues running from the active bank. After upload completes and passes verification, the spacecraft is commanded to activate the new bank on the next boot cycle.

This model provides:

• Clean rollback: if the new software fails to initialize, the spacecraft reboots from the previous bank
• Zero-interrupt loading: the active software continues operating during the multi-pass upload
• Single comparison point: you can verify the uploaded image in Bank B matches the expected hash before activating

Patching / memory overlay: Smaller updates can be applied as patches to the active software in RAM, without full bank switching. This is faster but requires atomic application of the patch and verification that the patched software is coherent before execution continues. More appropriate for critical parameter updates (thresholds, gain tables) than for significant software changes.

Verification Protocol

The on-board verification sequence for any software upload:

1. Receive complete transfer (all frames acknowledged)
2. Compute CRC / hash over received binary
3. Verify signature against stored public key (HSM-provisioned)
4. Compare hash against expected value from ground-signed manifest
5. Confirm memory write completed without ECC errors
6. Report verification status to ground

If any step fails, the spacecraft must be able to report specific failure codes that allow ground analysts to determine whether the failure was a data corruption, authentication failure, or hardware issue.

Contact Window Management

Spacecraft ground contact is intermittent. A Low Earth Orbit satellite at 400km altitude may have 4-8 contact windows per day, each lasting 5-12 minutes. Geosynchronous satellites have continuous contact but limited uplink bandwidth. Every ground-to-space software delivery architecture must account for interrupted transfers.

Segmented Upload Protocol

Large software payloads (flight software images may be tens of megabytes) require an upload protocol designed for intermittent contact:

• Persistent segment tracking: The spacecraft maintains a persistent map of which segments have been received and verified. On reconnect, ground queries the spacecraft's segment map and resumes from the last unacknowledged segment
• Idempotent retransmission: Retransmitting an already-received segment is handled gracefully — the spacecraft discards duplicates based on sequence number without storing redundant data
• Timeout parameters: If no new segments arrive for a configurable period (configurable by ground command), the spacecraft places the upload in a suspended state, preserving partial upload state but not continuing to wait indefinitely

Commanding Watchdog

Any on-board software update execution must operate under a hardware watchdog. If the new software crashes on first activation and doesn't refresh the watchdog within its timeout window, the hardware watchdog triggers a reboot — ideally back to the known-good bank. This is the last resort recovery mechanism that doesn't require ground intervention.

Ground System State Machine

The ground system maintains a state machine tracking each software upload operation:

States: IDLE → QUEUED → UPLOADING → VERIFYING → AWAITING_ACTIVATION → ACTIVATING → CONFIRMED
Error states: UPLOAD_FAILED → VERIFICATION_FAILED → ACTIVATION_FAILED → ROLLED_BACK

Each state transition is persisted to the mission database. An interrupted uplink session returns the system to a known state that can be resumed or rolled back without ambiguity. State is visible to operations analysts through the ground system monitoring dashboard.

Integration with Ground Software Architecture

On-orbit software update is one function of the broader ground segment. It integrates with:

Mission planning: Uplink scheduling systems allocate bandwidth to software uploads based on contact window availability and mission priority. Software uploads compete with science data downlink, command sequences, and telemetry for contact time.

Telemetry processing: After software activation, telemetry analysis tools look for health indicator changes that indicate the new software is operating correctly. Anomaly detection on telemetry streams should be pre-configured with baselines for the new software version before activation.

Configuration management: The ground system must maintain a complete record of what software version is running on each spacecraft (for constellation programs), what versions are in queue, and what the rollback state is for each vehicle. This integrates with standard configuration management databases.

These patterns build on the satellite ground system software architecture we've implemented for aerospace programs.

Frequently Asked Questions

How long does an on-orbit software upload typically take for a small satellite?

For a small satellite (CubeSat class, 50-100 KB flight software), a complete upload can be completed in a few contact windows at typical UHF/S-band uplink data rates (9.6 kbps to several hundred kbps). For larger satellites with higher-bandwidth Ka-band ground links and megabyte-scale software images, uploads may span multiple contact days. Schedule planning allocates specific contact windows for software maintenance operations outside of normal mission operations.

What happens if the spacecraft loses contact mid-upload?

With a properly designed segmented upload protocol, a mid-upload contact loss is a recoverable event. The spacecraft retains segments received before contact loss in non-volatile memory. On the next contact pass, the ground queries the spacecraft's segment map, identifies the last verified segment, and resumes the transfer from that point. The upload is not restarted from the beginning. The design must ensure that segment state storage is itself protected against power loss or reset events during the upload.

Can software updates be sent to a spacecraft with no ground contact?

Autonomous software updates without ground contact are generally not deployed for mission-critical flight software — the risk of an unverified autonomous update rendering the spacecraft non-operational without any ground recovery path is too high. However, parameter updates (configuration adjustments, threshold changes, gain table updates) can be scheduled for autonomous application at specific times, provided the parameters are within pre-validated bounds. The key distinction is between flight software (never fully autonomous) and operating parameters (bounded autonomous application possible).

How is software signing key management handled for spacecraft programs?

Spacecraft commanding key material should be managed through a Hardware Security Module (HSM) that never allows private key export. The HSM performs signing operations on command — ground software submits the payload hash and receives the signature, without the private key ever leaving the HSM. Key rotation requires a special commanding procedure that provisions a new public key to the spacecraft and transitions authentication. This key transition is itself a sensitive operation requiring strict authentication with the existing key.

How do multi-spacecraft constellation programs manage software versions across the fleet?

Constellation programs maintain a software version configuration database that tracks the version running on each spacecraft in the fleet, when each vehicle was last updated, and which vehicles are scheduled for update. Rolling updates stagger activation across the fleet — update a subset of vehicles, observe telemetry for anomalies, then proceed to the next batch. This mirrors blue-green deployment patterns from commercial software but at a cadence determined by ground contact availability rather than deployment automation.

Rutagon builds ground software systems for aerospace and defense programs →