Autonomous and unmanned systems — aerial, surface, subsurface, and ground — are producing data at rates that legacy ground control architectures weren't designed to handle. A modern UAS ground software system must ingest telemetry from multiple vehicles simultaneously, execute state transitions in real time, present operators with actionable awareness without overwhelming them, and maintain mission data integrity for post-mission analysis.
Here's how Rutagon approaches ground software architecture for autonomous systems programs.
The Data Flow Problem
A single UAS generating 10Hz telemetry data — position, attitude, fuel state, payload status, sensor outputs — produces tens of thousands of data points per minute. A multi-vehicle operation multiplies this by the fleet size. Ground software that tries to process this through a monolithic architecture creates bottlenecks that degrade operator awareness at exactly the moments when operators need high-confidence situational picture.
The architecture solution is an event-driven, streaming data backbone — messages published by each vehicle into a broker, consumed by independent processing services:
Vehicle Telemetry →
[Ingest Service] →
[Kafka/SQS Topic per vehicle] →
├── [State Machine Service] — tracks vehicle state, mission phase
├── [Alert Service] — evaluates anomaly conditions, publishes alerts
├── [Data Lake Writer] — persists all telemetry to S3/GovCloud storage
└── [Map Display Feed] — downsampled position stream for operator UI
This pattern — the same streaming architecture Rutagon uses in production real-time systems — decouples ingestion from processing. The ingest service is the only component with a hard latency requirement (process and acknowledge within the telemetry interval); downstream consumers operate independently.
State Machine Architecture for Vehicle Management
Autonomous vehicles have complex operational state graphs — pre-flight, taxiing, takeoff, in-mission, return-to-home, emergency descent, landed, maintenance hold. Ground software must track each vehicle's state, enforce valid state transitions, and trigger appropriate automated responses.
A finite state machine implemented as a dedicated microservice handles this cleanly:
from transitions import Machine
class VehicleStateMachine:
states = [
'offline', 'pre_flight', 'ready', 'airborne',
'mission_active', 'returning', 'landing', 'landed', 'fault'
]
transitions = [
{'trigger': 'power_on', 'source': 'offline', 'dest': 'pre_flight'},
{'trigger': 'pre_flight_complete', 'source': 'pre_flight', 'dest': 'ready'},
{'trigger': 'takeoff', 'source': 'ready', 'dest': 'airborne'},
{'trigger': 'mission_start', 'source': 'airborne', 'dest': 'mission_active'},
{'trigger': 'recall', 'source': ['mission_active', 'airborne'], 'dest': 'returning'},
{'trigger': 'fault_detected', 'source': '*', 'dest': 'fault'},
]
def __init__(self, vehicle_id: str):
self.vehicle_id = vehicle_id
self.machine = Machine(model=self, states=self.states,
transitions=self.transitions, initial='offline')
def on_enter_fault(self):
# Trigger immediate operator alert
alert_bus.publish(FaultAlert(self.vehicle_id, timestamp=now()))
State transitions generate audit events — every state change is timestamped, attributed, and persisted for mission debrief. This audit trail is also critical for ATO evidence and safety case documentation in defense programs.
C2 Link Resilience
Command and control link loss is not an edge case for autonomous systems — it's an expected operating condition. Ground software must handle link degradation gracefully:
Heartbeat-based link monitoring: The ground station tracks last-heard timestamp per vehicle. After a configurable timeout (mission-dependent, typically 5-30 seconds), the system transitions the vehicle to a link-lost state and executes pre-programmed behaviors.
Command acknowledgment queuing: C2 commands are queued with sequence numbers and acknowledged by the vehicle. Unacknowledged commands are retried at appropriate intervals; command queues are drained when connectivity is restored.
Autonomous behavior handoff: For longer link-loss events, vehicles execute pre-loaded mission plans autonomously. Ground software tracks projected vehicle state (dead-reckoning position, estimated fuel state) even during link loss to maintain operator awareness.
This resilience architecture is directly aligned with DDIL (Disconnected, Degraded, Intermittent, Low-bandwidth) operation requirements that appear in most defense autonomous systems programs.
Operator Interface Design
Ground software operator interfaces have a fundamentally different design constraint from consumer applications: cognitive load management under high-stress, time-critical conditions. Design decisions:
Information hierarchy: Fault and warning conditions surface to the top of the operator's view automatically. Normal state indicators are present but subdued. The operator's attention should be captured by exceptions, not consumed by routine state.
Action confirmation design: Irreversible commands (recall all, emergency mode, abort mission) require explicit confirmation but must not introduce unacceptable latency. Two-step confirmation (click + confirm within 3 seconds) balances error prevention with response speed.
Data density vs. clarity: Experienced operators want high-density displays; operators monitoring many vehicles simultaneously need simplified views. Configurable display profiles allow experienced operators to access full telemetry while newer operators work with essential state indicators.
Rutagon's production SaaS platform has served as a proving ground for high-density real-time data interfaces — the same architecture (WebSocket push, React state management, optimistic UI updates) applies directly to autonomous systems operator displays.
Discuss your ground software program → rutagon.com/contact
Frequently Asked Questions
What does ITAR compliance mean for ground software design documentation?
Ground software architecture at the pattern level (event-driven pipelines, state machines, C2 resilience) is generally permissible under ITAR. System-specific documentation that includes specific vehicle performance parameters, mission payloads, or targeting algorithms requires appropriate handling under ITAR 22 CFR 120. Rutagon's development practices separate architecture documentation (architecture review board artifacts) from system specification (controlled distribution only).
How do you handle multi-vehicle coordination in ground software?
Multi-vehicle coordination requires a deconfliction layer above individual vehicle state machines — a mission coordination service that tracks relative positions, manages airspace zones, and sequences actions across the fleet. This is typically implemented as a separate microservice consuming the same vehicle telemetry stream, publishing coordination commands back through the C2 channel.
What cloud architecture supports ground software in deployed environments?
Deployed ground software typically runs on a tactical cloud or edge stack — AWS Snowball Edge, Azure Stack Edge, or on-premises Kubernetes cluster. The application architecture (Docker containers, Kubernetes orchestration) is portable across these platforms. Data synchronization with a rear-echelon cloud (AWS GovCloud or equivalent) allows mission data to be transmitted when connectivity is available.
Can ground software support heterogeneous vehicle fleets?
Yes — the key is abstracting vehicle-specific communication protocols behind a common telemetry model. An ingest adapter layer translates vehicle-specific message formats (MAVLink, STANAG 4586, proprietary formats) into a common internal schema. Ground software logic operates on the normalized schema, making the core architecture fleet-agnostic. Adding a new vehicle type means writing a new ingest adapter, not re-architecting the ground system.
What observability tools are appropriate for real-time ground software?
OpenTelemetry is the standard for distributed tracing — span instrumentation on the ingest pipeline reveals latency hotspots. Prometheus metrics on per-vehicle message rates, processing latency, and queue depths provide operational health visibility. In classified environments, OpenTelemetry Collector with a FIPS-compliant backend (CloudWatch in GovCloud, or self-hosted Jaeger/Tempo in air-gapped environments) provides equivalent observability within compliance constraints.