Skip to main content
INS // Insights

Small Satellite Ground Software Stack Design

Updated April 2026 · 7 min read

The commercial small satellite market has compressed mission timelines dramatically. Where a government satellite program once measured ground segment development in years, small satellite programs — CubeSats, 6U-12U class, and small LEO constellations — expect ground software to be operational before first light. That means building for deployment speed without sacrificing the operational reliability mission assurance requires.

Rutagon's ground segment software implementations cover the full stack: pass scheduling, contact management, telemetry ingest and decode, command authorization and uplink, anomaly detection, and multi-mission operations center (MOC) integration.

Ground Segment Architecture Principles

Small satellite ground software needs to balance competing constraints:

  • Deployment speed — missions have hard launch dates; ground systems can't be on the critical path
  • Operational continuity — a 6U satellite with a 2-year orbital life can't tolerate ground software downtime during contact windows
  • Mission flexibility — payload modes, orbit regimes, and operational concepts change; hardcoded assumptions are brittle
  • Cost efficiency — small satellite programs don't have the budget for large ground segment operations teams

Cloud-native architecture addresses all four: containerized services deploy fast, Kubernetes provides resilience without dedicated hardware, configuration-driven systems accommodate mission changes, and managed services reduce operational staffing requirements.

Pass Prediction and Contact Scheduling

Ground contact windows are determined by orbital geometry — the satellite passes overhead only when the antenna has line-of-sight. For LEO missions, contact windows are typically 5-12 minutes several times daily per ground station.

Rutagon's pass prediction layer uses the Skyfield library (Python, MIT license) for high-fidelity two-line element (TLE) propagation:

from skyfield.api import load, EarthSatellite, wgs84
from datetime import datetime, timezone

def compute_passes(tle_line1: str, tle_line2: str, 
                   station_lat: float, station_lon: float, station_alt: float,
                   min_elevation_deg: float = 5.0,
                   window_hours: float = 24.0):
    """
    Compute satellite passes for a ground station over the next N hours.
    Returns list of (rise_time, max_elevation, set_time) tuples.
    """
    ts = load.timescale()
    satellite = EarthSatellite(tle_line1, tle_line2, ts=ts)
    station = wgs84.latlon(station_lat, station_lon, elevation_m=station_alt)
    
    t0 = ts.now()
    t1 = ts.tt_jd(t0.tt + window_hours / 24)
    
    times, events = satellite.find_events(
        station, t0, t1, altitude_degrees=min_elevation_deg
    )
    
    passes = []
    for i in range(0, len(events) - 2, 3):
        if events[i] == 0:  # Rise event
            passes.append({
                "rise": times[i].utc_datetime(),
                "culmination": times[i+1].utc_datetime(),
                "set": times[i+2].utc_datetime(),
                "max_elevation": compute_max_elevation(satellite, station, times[i+1])
            })
    return passes

Pass predictions are computed 48-72 hours in advance and loaded into a scheduling service that manages contact queue prioritization, antenna steering commands, and handoff coordination between ground stations.

Telemetry Ingest Pipeline

Received telemetry frames arrive from the radio as raw binary. The ingest pipeline handles:

  1. Frame sync and deframing — identify frame boundaries from sync markers
  2. Reed-Solomon / LDPC error correction — forward error correction per mission link budget
  3. Frame authentication — HMAC or AES-CCM verification for command authentication
  4. Packet extraction — CCSDS primary/secondary header processing
  5. Parameter decode — engineering unit conversion from raw counts
  6. Limit checking — real-time health assessment against nominal bands
  7. Storage — time-series database and raw frame archive
from dataclasses import dataclass
import struct

CCSDS_PRIMARY_HEADER_SIZE = 6  # bytes

@dataclass
class CCSDSPrimaryHeader:
    version: int
    packet_type: int        # 0=TM, 1=TC
    secondary_header: bool
    apid: int               # Application Process Identifier
    sequence_flags: int
    sequence_count: int
    data_length: int        # Octets in data field - 1

def parse_ccsds_primary_header(raw: bytes) -> CCSDSPrimaryHeader:
    """Parse a 6-byte CCSDS primary header per CCSDS 133.0-B-2."""
    word1, word2, word3 = struct.unpack(">HHH", raw[:6])
    return CCSDSPrimaryHeader(
        version=(word1 >> 13) & 0x7,
        packet_type=(word1 >> 12) & 0x1,
        secondary_header=bool((word1 >> 11) & 0x1),
        apid=word1 & 0x7FF,
        sequence_flags=(word2 >> 14) & 0x3,
        sequence_count=word2 & 0x3FFF,
        data_length=word3
    )

def decode_engineering_unit(raw_value: int, cal_table: dict) -> float:
    """Apply calibration polynomial or lookup table to raw count."""
    if cal_table["type"] == "polynomial":
        coeffs = cal_table["coefficients"]
        return sum(c * (raw_value ** i) for i, c in enumerate(coeffs))
    elif cal_table["type"] == "lookup":
        return cal_table["table"].get(raw_value, float('nan'))

Decoded telemetry flows to TimescaleDB (PostgreSQL extension) for time-series storage, enabling efficient range queries for trend analysis and anomaly investigation.

Command Authorization and Uplink

Commands are the most security-critical element of ground operations. Rutagon's command management system implements a multi-stage authorization workflow:

  1. Command generation — operator selects command from mission database, fills parameters
  2. Validation — syntax, parameter range, and mission phase checks
  3. Authorization — two-person integrity rule for hazardous commands; single-operator for routine
  4. Scheduling — queued against the contact window with uplink time calculated for in-orbit execution timing
  5. Radiometric sign — HMAC-SHA256 authentication token appended before transmission
  6. Transmission and verification — uplinked, command execution telemetry verified in downlink

The authorization workflow is logged immutably — every command, every authorizer, every execution confirmation. For safety-critical commands (attitude control, payload mode changes, propulsion if present), the two-person integrity requirement is enforced at the application layer regardless of operator permissions.

Cloud-Native Operations Architecture

Rutagon deploys ground segment software on Kubernetes, enabling multi-mission operations from a single infrastructure:

# Kubernetes deployment — telemetry ingest service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: telemetry-ingest
  namespace: mission-ops
spec:
  replicas: 2  # HA for contact windows
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0  # Zero-downtime updates
  selector:
    matchLabels:
      app: telemetry-ingest
  template:
    spec:
      containers:
        - name: ingest
          image: $REGISTRY/telemetry-ingest:$VERSION
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "2000m"
              memory: "2Gi"
          env:
            - name: MISSION_ID
              valueFrom:
                configMapKeyRef:
                  name: mission-config
                  key: mission_id

Horizontal pod autoscaling during contact windows handles burst load from downlinks, while standard replicas maintain low-cost availability between passes.

Anomaly Detection

Small satellite operations teams are lean — monitoring dozens of telemetry points manually isn't feasible. Rutagon's automated anomaly detection layer applies configurable limit checking plus statistical deviation detection:

def check_telemetry_limits(param_id: str, value: float, 
                           limit_table: dict) -> list[str]:
    """
    Check a telemetry value against red/yellow limit bands.
    Returns list of active alarms.
    """
    limits = limit_table.get(param_id, {})
    alarms = []
    
    if "red_low" in limits and value < limits["red_low"]:
        alarms.append(f"RED LOW: {param_id}={value} < {limits['red_low']}")
    elif "yellow_low" in limits and value < limits["yellow_low"]:
        alarms.append(f"YELLOW LOW: {param_id}={value} < {limits['yellow_low']}")
    
    if "red_high" in limits and value > limits["red_high"]:
        alarms.append(f"RED HIGH: {param_id}={value} > {limits['red_high']}")
    elif "yellow_high" in limits and value > limits["yellow_high"]:
        alarms.append(f"YELLOW HIGH: {param_id}={value} > {limits['yellow_high']}")
    
    return alarms

Alarms feed to PagerDuty or equivalent on-call routing for on-orbit events requiring operator response.

Rutagon's ground segment software implementations are mission-specific but built on reusable components, accelerating deployment from contract award to operations-ready. For missions with ATO requirements, the architecture integrates with our standard DevSecOps delivery model.

Discuss your mission ground segment requirements →

Frequently Asked Questions

What programming standards does Rutagon use for space software?

Space software requirements vary by mission class. For small commercial and government missions without safety-critical certification requirements, Rutagon uses modern Python (typing, async), Go for high-throughput ingest services, and Kubernetes for orchestration. For missions requiring ECSS or NASA safety standards, additional review processes and potentially different toolchains apply. The appropriate standard is determined during mission requirements analysis.

How does cloud-native ground software handle contact window reliability?

Contact windows are time-critical — a 5-minute pass can't recover from a 3-minute software restart. Rutagon addresses this through: zero-downtime rolling deployments (never updating during scheduled contacts), pre-contact health checks with automated escalation if services aren't ready, and stateless ingest services that can be rapidly restarted without data loss (frames are queued at the radio layer with buffering).

What telemetry database does Rutagon use for ground segment operations?

For small satellite programs, TimescaleDB (PostgreSQL extension for time-series data) is the standard choice — it provides excellent query performance for telemetry patterns, PostgreSQL's mature ecosystem, and cloud-native deployment on Kubernetes. For higher-rate constellations or missions with complex geospatial queries, InfluxDB or Amazon Timestream are evaluated. Raw frame archives are stored in S3 with intelligent tiering for cost efficiency.

How are TLE updates managed for accurate pass prediction?

TLEs for tracked objects are published by Space-Track.org (operated by 18th Space Defense Squadron). Rutagon's ground software ingests TLE updates on a scheduled basis (typically every 8-12 hours for LEO satellites) using the Space-Track API. TLE age is monitored as a system health metric — predictions older than 48 hours for maneuvering satellites trigger operator review before contact window scheduling.

Can Rutagon's ground software handle multi-mission operations?

Yes. The architecture is designed from the start for multi-mission operations: mission context is a first-class configuration parameter, command databases and limit tables are mission-specific but managed by the same infrastructure, and the scheduler handles contact windows across multiple satellites sharing ground station resources. This is particularly valuable for constellation deployments where operational efficiency requires shared infrastructure.