CubeSat ground software has evolved dramatically over the past decade. What once required purpose-built ground station hardware running legacy mission control systems can now run as cloud-native microservices — more scalable, easier to maintain, and accessible from anywhere with proper authentication.
But "cloud-native ground software" is not just lifting a traditional ground system into a container. The architecture must account for the fundamental constraints of small satellite operations: short, infrequent passes (a LEO CubeSat typically has 4–8 contact opportunities per day, each 5–12 minutes long), narrow bandwidth, data volume budgets, and the need to maintain state across intermittent connections.
This article covers the ground software design patterns Rutagon uses for small satellite programs.
Ground System Architecture Overview
A complete CubeSat ground software stack has four functional layers:
- Ground station interface: Physical or virtual antenna, radio, demodulator, decoder
- Data transport and ingest: Pass management, bitstream → packet decoding, data routing
- Mission management: Command scheduling, telecommand generation, uplink queuing
- Analysis and visualization: Telemetry database, dashboards, anomaly detection, operator tools
Cloud-native design applies most directly to layers 2–4. Layer 1 (the RF chain) remains hardware-dependent, but modern software-defined radios (SDRs) and commercial ground station networks (AWS Ground Station, RBC Signals, KSAT) provide API-accessible ground station infrastructure that integrates cleanly with cloud-native backend systems.
Pass Scheduling Architecture
Pass scheduling is the temporal heartbeat of any satellite ground system. Every ground operation must be planned against a contact window.
Core components:
Orbital propagation: The ground software must predict contact windows from TLE (Two-Line Element) data. Astropy, Skyfield, and the Python sgp4 library are commonly used for propagation. Pass prediction typically runs as a scheduled job, computing contacts for the next 24–72 hours and storing them in a scheduling database.
from skyfield.api import load, EarthSatellite, wgs84
from datetime import datetime, timezone
def compute_next_passes(tle_line1, tle_line2, station_lat, station_lon, station_elev_m):
ts = load.timescale()
satellite = EarthSatellite(tle_line1, tle_line2, 'MISSION', ts)
station = wgs84.latlon(station_lat, station_lon, elevation_m=station_elev_m)
t0 = ts.now()
t1 = ts.utc(t0.utc_datetime().replace(tzinfo=None) + timedelta(hours=48))
# Find events: rises (0), culminates (1), sets (2)
times, events = satellite.find_events(station, t0, t1, altitude_degrees=5.0)
return [(t.utc_iso(), event) for t, event in zip(times, events)]Pass queue: Each predicted contact window becomes a scheduled task with a priority queue. High-priority commands (mode changes, anomaly response) are inserted at the front; routine telemetry requests fill remaining bandwidth.
Constraint management: Contact windows constrain when ground operations can occur. The scheduling system must prevent command scheduling outside contact windows and handle window changes (updated TLEs, ground station outages) gracefully.
Telemetry Decode Pipeline
Raw telemetry arrives as a bitstream from the ground station. The decode pipeline transforms it into structured, queryable mission data.
Pipeline stages:
RF signal → demodulator → frame sync → packet decode → frame store → telemetry DBFrame processing:
CubeSat telemetry typically uses CCSDS (Consultative Committee for Space Data Systems) space packet protocol. CCSDS Space Packet encapsulates housekeeping and science data with standard headers (APID, sequence count, timestamp, data length).
import struct
CCSDS_PRIMARY_HEADER_FMT = ">HHH" # version/type/APID, flags/seq, length
def decode_ccsds_primary_header(data: bytes) -> dict:
if len(data) < 6:
raise ValueError("Insufficient data for CCSDS primary header")
word1, word2, length = struct.unpack(CCSDS_PRIMARY_HEADER_FMT, data[:6])
return {
"version": (word1 >> 13) & 0x7,
"packet_type": (word1 >> 12) & 0x1,
"apid": word1 & 0x7FF,
"sequence_flags": (word2 >> 14) & 0x3,
"sequence_count": word2 & 0x3FFF,
"data_length": length + 1
}Telemetry database: Parsed telemetry packets are stored in a time-series database (InfluxDB is common for satellite telemetry; TimescaleDB works well when you need PostgreSQL-compatible queries alongside time-series). Data should be stored with original packet-level granularity to support retrospective analysis.
Command Uplink Architecture
Commanding a satellite introduces reliability requirements that simple request-response architectures cannot satisfy. Commands are fire-and-forget in the uplink direction — you don't get an immediate acknowledgment from a LEO satellite. Acknowledgment comes from downlinked housekeeping telemetry in a subsequent pass.
Command lifecycle:
- Command creation: Operator or automated system creates a telecommand (TC) packet targeting a specific APID and function code
- Validation: Command parameters are range-checked against the command database. Invalid parameters are rejected before transmission.
- Scheduling: Command is placed in the uplink queue for the next appropriate pass
- Uplink: During the contact window, commands are transmitted in priority order
- Confirmation: Next housekeeping telemetry packet confirms receipt; anomaly detection monitors for expected state change
Command database: A telecommand database (CCDB) stores the definition of every valid command — APID, function code, parameter types, valid ranges, and expected response telemetry. This database is the source of truth for both command generation and parameter validation.
Safety constraints: Critical commands (mode changes, reboot, payload activation) should require explicit operator confirmation and may require dual-person integrity for operational systems. Automated commanding (e.g., autonomous anomaly response) requires clearly bounded authority limits and audit logging.
Cloud-Native Ground Segment Design
A production cloud-native ground segment for a CubeSat program typically runs on Kubernetes with the following service decomposition:
┌─────────────────────────────────────────────────┐
│ Ground Station APIs (AWS Ground Station / SDR) │
└────────────────────┬────────────────────────────┘
│ TM/TC Streams
┌────────────────────▼─────────────────────────────┐
│ pass-scheduler │ frame-processor │
│ (orbital math, │ (bitstream → CCSDS packets, │
│ contact windows) │ packet → telemetry DB) │
├─────────────────────┤─────────────────────────────┤
│ command-manager │ telemetry-api │
│ (TC queue, │ (GraphQL/REST, operator │
│ uplink dispatch) │ query, alert thresholds) │
├─────────────────────┴─────────────────────────────┤
│ TimescaleDB / InfluxDB (telemetry store) │
│ PostgreSQL (mission state, command log, config) │
└───────────────────────────────────────────────────┘Each service scales independently — telemetry processing spikes during a pass; command management is low-volume but latency-sensitive during a contact window.
For multi-satellite or multi-mission programs, this architecture scales horizontally without redesign. Each mission gets its own namespace and command database configuration; shared services (authentication, observability, ground station APIs) operate at the cluster level.
Rutagon's Ground Software Experience
Rutagon has designed and operated cloud-native ground software for small satellite programs, building on production SaaS architecture experience adapted for the unique timing and reliability requirements of space operations. The pattern of pass-driven, intermittent connectivity mirrors other real-time systems Rutagon has operated at scale — just with an orbital mechanic constraint layered on top.
Rutagon Aerospace Capabilities →
JADC2 Software Architecture Patterns →
Frequently Asked Questions
What is the best database for CubeSat telemetry storage?
TimescaleDB (PostgreSQL extension) is a strong choice when you need SQL queries alongside time-series performance — useful for mixing telemetry queries with mission configuration and event data. InfluxDB is faster for pure time-series ingestion and has a purpose-built query language (Flux). For programs with strict ITAR data handling requirements, running either database in a GovCloud environment or on-premise within your facility provides the required data controls.
Can AWS Ground Station work for CubeSat programs?
Yes. AWS Ground Station supports S-band and X-band, covers most LEO orbits, and integrates with AWS services via a DataflowEndpointGroup that delivers decoded frames to S3 or directly to EC2/Fargate via AWS DataChannel. It eliminates the need for owned ground station infrastructure at the cost of per-minute contact fees. For programs without dedicated ground station infrastructure, it's a viable path — cost-effective for early missions where contact frequency is low.
How do you handle telemetry gaps when a pass has poor link quality?
Design the telemetry frame protocol with sequence counters (CCSDS sequence count) and implement gap detection in the frame processor. Log gaps with precise timestamps. For critical telemetry (power, thermal, attitude), use store-and-forward — the satellite buffers telemetry in onboard storage and downlinks historical data during subsequent passes. The ground software must handle out-of-order and duplicate packets gracefully.
What are the ITAR implications for ground software development?
Ground software that interfaces with spacecraft designed for U.S. government or defense programs may be subject to ITAR restrictions on personnel access, code export, and collaboration with foreign nationals. Rutagon operates within ITAR compliance requirements — access to technical data and software developed for controlled programs is restricted to U.S. persons. Consult with export control counsel for your specific program before engaging contractors.
How does redundancy work for a critical ground system?
For mission-critical programs, the ground software requires high availability — at minimum, multi-AZ deployment with automatic failover. The telemetry database must use synchronous replication (TimescaleDB streaming replication, or PostgreSQL Patroni cluster) to prevent data loss during a failover that occurs during a pass. Command queues should be durable (Kafka or PostgreSQL-backed) so commands survive ground system restarts without being lost.