Unmanned systems programs — from tactical UAS to autonomous maritime and ground vehicles — increasingly rely on sophisticated software stacks to achieve mission objectives. Hardware primes that build the vehicles and sensors frequently need software-specialist subcontractors to develop the mission system software, ground control stations, and data processing pipelines that make those platforms operationally effective.
This is where Rutagon operates as a subcontractor: delivering the cloud-native software infrastructure that transforms sensor-equipped platforms into mission-capable systems.
The Unmanned Systems Software Stack
Modern unmanned systems programs require software across several functional layers:
Flight/vehicle management software: Autopilot integration, flight plan execution, vehicle health monitoring, and emergency response logic. For programs using open-source autopilot stacks (ArduPilot, PX4), integration and extension rather than from-scratch development is the standard approach.
Ground control station (GCS) software: Operator interface for mission planning, vehicle command, telemetry display, and payload control. Cloud-native GCS implementations replace traditional thick-client desktop software with web-based interfaces deployable in disconnected, tactical, or garrison environments.
Mission data processing: Payload sensor data — EO/IR imagery, SAR products, SIGINT collections, LiDAR point clouds — requires processing pipelines that convert raw sensor output into exploitable data products. This is data engineering at its core: ingestion, format conversion, metadata tagging, and delivery to exploitation systems.
C2 integration: Unmanned systems increasingly operate within Joint All-Domain C2 (JADC2) frameworks. See JADC2 software architecture for the data mesh and API-first interoperability patterns that connect unmanned system data to command and control networks.
Cloud-Native Ground Control Architecture
Traditional GCS software runs on dedicated Windows workstations at fixed ground stations. Cloud-native GCS architecture replaces this with:
Browser-based operator interface: React or Vue front-end providing map visualization, vehicle telemetry display, and mission planning tools. Deployable on any device with a browser — laptop, tactical tablet, or hardened display terminal.
Backend microservices: Separate services for telemetry ingestion, command processing, mission planning, and data management. Each service scales independently based on load — multiple vehicles simultaneously feeding telemetry to the same backend infrastructure.
Message bus for real-time data: Apache Kafka or AWS Kinesis for high-throughput telemetry streaming. Event-driven architecture decouples data producers (vehicles) from consumers (operators, analysts, archives) — standard event streaming patterns.
Geospatial services: Vector tile servers, raster imagery layers, and sensor coverage overlay services that provide operators with situational awareness context overlaid on vehicle telemetry.
Multi-vehicle coordination: For programs operating swarms or multiple autonomous assets, coordination state management and conflict detection logic live as shared backend services accessible to all operator clients simultaneously.
Mission Data Pipelines
Unmanned systems generate large volumes of sensor data that require processing before they're useful. The data pipeline challenge:
High ingestion rate: A UAS running EO/IR sensors can generate gigabytes of data per flight hour. Processing pipelines must ingest, decode, and route this data in near-real-time without dropping packets.
Multi-format sensor output: Different sensor packages produce different data formats — MISB-standard metadata-stamped video, raw imagery in NITF or GeoTIFF, point clouds in LAS format, and signal data in proprietary formats. Format normalization and schema mapping are engineering challenges.
Distribution to multiple consumers: Processed data products may need to reach multiple consumers simultaneously: the operator, an exploitation cell, an archive system, and a federated data lake for analytics. Publish-subscribe architecture handles fan-out without duplicating pipeline logic.
Cloud-native storage: AWS GovCloud or commercial cloud object storage (S3) provides cost-effective, scalable storage for large data volumes. Data lake patterns with appropriate access controls handle classification marking and user access enforcement.
Disconnected and Denied Operations
Unmanned systems programs often operate in environments where cloud connectivity isn't available — tactical forward positions, maritime operations, or classified environments without commercial internet access. Cloud-native architecture must accommodate this:
Edge computing pattern: Processing occurs at the vehicle or ground station level when cloud connectivity is unavailable. Data is buffered locally and synchronized to the cloud when connectivity is restored.
State reconciliation: When offline nodes reconnect, state must be reconciled without overwriting newer data. Conflict-resolution logic in the synchronization layer handles divergent states gracefully.
Containerized edge deployment: The same containerized microservices that run in the cloud can run on edge hardware — a tactical server or rugged compute node at the ground station. Kubernetes lightweight distributions (K3s, MicroK8s) enable this.
See resilient software disconnected military operations for the full architecture pattern for offline-capable mission software.
DevSecOps for UAS Programs
UAS software programs are subject to the same ATO requirements as any other DoD software system. Platform One software factory and DevSecOps mandates apply to UAS ground software, C2 integration, and mission data systems.
Rutagon applies the same DevSecOps pipeline to UAS programs as to other defense cloud programs:
- Iron Bank base containers for all GCS and pipeline services
- Automated STIG scanning in the CI/CD pipeline
- SBOM (Software Bill of Materials) generation for supply chain visibility
- ATO evidence artifact generation in the pipeline
- Continuous monitoring configuration from day one
The DevSecOps software factory DOD post covers the pipeline stack in detail.
ITAR Considerations for Unmanned Systems Content
Unmanned systems software — particularly anything related to autonomous flight controls, sensor processing, or mission planning — is ITAR-controlled under USML Category VIII (Aircraft and Related Articles) and Category XV (Spacecraft and Related Articles) depending on platform type. Rutagon's public-facing content covers architectural patterns using publicly available information:
- Open-source autopilot integration (ArduPilot, PX4 — publicly available)
- Standard message bus patterns (Kafka, Kinesis — commercial technology)
- Cloud-native ground software architecture (publicly documented)
- MISB-standard telemetry handling (MISB is a public standard)
Specific performance parameters, controlled algorithms, and program-specific technical data are handled within appropriate classification and ITAR boundaries.
Frequently Asked Questions
What types of unmanned systems has Rutagon built software for?
We've delivered mission system software for programs in production — not lab prototypes. We don't name specific systems in public materials, but the mission types we've supported include aerial and maritime surveillance applications. The software patterns (data pipelines, GCS architecture, C2 integration) are consistent across platform types.
Can Rutagon develop custom autopilot software?
Autopilot development falls within ITAR-controlled technology areas. We integrate with existing autopilot stacks (ArduPilot, PX4, vendor proprietary) and develop the GCS, mission planning, and data processing layers above the autopilot. Custom autopilot core development is discussed on a case-by-case basis for specific programs with appropriate ITAR handling.
How do you handle teaming with hardware primes for UAS programs?
Hardware primes building the vehicle typically own the hardware design and autopilot selection. Rutagon subs for the software layers — GCS, mission data pipelines, C2 integration, and DevSecOps. We're not competing with the hardware prime for control of the vehicle design; we're delivering the software infrastructure that makes the vehicle operationally useful. This complementary positioning is what makes the sub relationship work.
What's the ATO path for UAS ground software?
UAS ground software follows standard DoD RMF — system categorization, control selection, implementation, assessment, and authorization. The cloud-native deployment model (AWS GovCloud) accelerates the process by inheriting FedRAMP controls and providing automated compliance evidence. Ground software ATOs for UAS programs we've supported have followed the same process as other defense cloud programs. See ATO acceleration cloud sub for the specific approach at each RMF step.
How do you approach open-source software use in ITAR-sensitive programs?
Open-source software (ArduPilot, ROS, OpenMCT, etc.) is generally not ITAR-controlled by itself. ITAR controls apply when open-source software is modified or configured in ways that develop export-controlled technology. We use open-source foundations where appropriate, document SBOM, and apply ITAR-aware review to any modifications. Usage in programs with ITAR obligations follows program-specific ITAR management plans developed with the prime.
If your prime program has unmanned systems software requirements — ground control, mission data pipelines, or C2 integration — contact Rutagon to discuss your program's scope.