Space Domain Awareness encompasses the detection, tracking, identification, and characterization of objects and events in the orbital environment. It's operationally critical — without accurate space object tracking, satellite operators face collision risk, and defense organizations lose insight into adversary orbital activity. The software challenge: processing sensor data from geographically distributed ground sensors and space-based sensors into coherent, actionable orbital pictures in near-real time.
Here's how Rutagon approaches the software architecture for SDA systems.
The SDA Data Pipeline
An SDA system's core function is sensor data ingestion and fusion. Sensors (radar, optical, RF) generate observation data — individual measurements of an object's position, velocity, and other characteristics. The pipeline fuses these observations into state vectors (precise orbital element sets), maintains catalogues of tracked objects, and presents the fused picture to analysts and automated consumers.
Data ingestion architecture:
[Radar/Optical Sensors] → [Observation Ingest Service]
→ [Message Queue (high throughput)]
→ [Preprocessing Service] (format normalization, quality filtering)
→ [State Vector Update Service] (orbit determination)
→ [Catalogue Service] (persistent object database)
→ [Dissemination Layer] (operator displays, external feeds)
Each service in this pipeline has different latency and throughput requirements. The ingest layer handles high-rate observation bursts during sensor passes (seconds to minutes of high-throughput data followed by silence). Orbit determination is computationally intensive but less latency-sensitive. The dissemination layer needs sub-second updates for real-time operator displays.
This architecture — event-driven with independent scaling per service — maps cleanly to cloud-native patterns: managed queuing (SQS or Kafka), containerized processing services (EKS), and a managed database tier (Aurora PostgreSQL or DynamoDB for catalogue storage).
Orbit Determination in Cloud Infrastructure
The computational kernel of SDA is orbit determination — fitting an orbital model to observations to estimate the current state vector and predict future positions. This is computationally intensive, particularly for batch processing (updating many objects from a dense sensor pass) and conjunction analysis (checking all tracked object pairs for close approaches).
Cloud execution model: - Routine state vector updates: containerized workers consuming from the message queue, horizontally scalable on demand - Batch reprocessing (when new sensor calibration data changes historical observation values): spot instance compute for cost efficiency on large but time-insensitive workloads - Conjunction analysis (screening all object pairs for potential collisions): scheduled high-compute jobs, results cached and updated on each catalogue update cycle
In GovCloud, this workload profile maps to EKS worker pools with node group autoscaling — routine workers run on on-demand instances; batch jobs run on Spot-tolerant node groups with data checkpointing to survive interruptions.
Ground Software for Alaska-Based SDA
Alaska's geographic position — spanning both Pacific and Arctic sectors, with radar installations ranging from Kodiak to Clear Space Force Station — is strategically significant for space surveillance. Ground software supporting Alaska-based radar or optical sensor networks must handle high-latitude operational factors:
Ionospheric effects: The polar ionosphere introduces additional uncertainty in radar range measurements during geomagnetic disturbances. Calibration data from ionospheric monitoring networks (such as those operated by research institutions and defense agencies) can be ingested to correct observation quality estimates.
Polar night / midnight sun scheduling: Optical sensors have stark operational variations between polar winter (extended observing windows) and polar summer (minimal darkness). Automated scheduler components must account for solar illumination conditions when generating sensor tasking.
Communication resilience: Some Alaska sensor sites have limited commercial connectivity. Software must operate in a store-and-forward mode, buffering observations locally during connectivity outages and synchronizing with central processing when connectivity is restored — the DDIL architecture pattern.
Rutagon's Alaska-based engineering team understands these operational realities from proximity to the installations and infrastructure involved. It's a meaningful differentiator for SDA programs with Alaska sensor components.
Discuss your space domain awareness program → rutagon.com/contact
Frequently Asked Questions
What ITAR considerations apply to SDA software development?
SDA software architecture at the pattern level (data pipelines, orbit determination workflow, cloud infrastructure) is generally permissible. Specific technical details of defense SDA systems — sensor capabilities, tracking accuracy parameters, classified catalogue data structures — are controlled under ITAR and handled appropriately. Rutagon's development processes separate architecture-level documentation from system specification, ensuring ITAR-controlled details are handled only within appropriate program boundaries.
How does cloud-native SDA software differ from traditional ground system architectures?
Traditional SDA ground systems were often monolithic architectures running on dedicated hardware at fixed locations. Cloud-native SDA software is decomposed into independent services that can be geographically distributed, scaled independently, and updated without full-system downtime. Cloud-native approaches also enable multi-classification environments (combining commercial and government cloud tiers) and hybrid architectures that include on-premises components at sensor locations alongside cloud processing.
What databases are appropriate for orbital object catalogues?
The choice depends on query patterns. PostgreSQL (Aurora Serverless v2 in GovCloud) handles complex conjunction queries and orbital element storage well — spatial indexing and custom PostgreSQL extensions support orbital mechanics query patterns. For high-throughput observation streams, a time-series database or DynamoDB handles the write-heavy ingest pattern. Production SDA systems often use both: DynamoDB for observation ingest and PostgreSQL for the curated catalogue.
How do you handle real-time updates to operator displays?
WebSocket connections from the operator display to an API layer provide push-based real-time updates without polling. The display subscribes to specific object tracks or event types; the back-end publishes updates as state vectors change. For high-density displays (many objects, frequent updates), server-sent events or WebRTC data channels can reduce WebSocket connection overhead. The display rendering layer (React with WebGL for orbital visualization) handles the data volume with performant virtual rendering for large catalogues.
What does a cloud sub bring to a prime-led SDA program?
A cloud sub on an SDA program provides the infrastructure and pipeline layer — scalable ingest, processing, and dissemination infrastructure running on GovCloud, with STIG compliance and ATO evidence baked in. The prime typically holds system-level responsibility and the sensor integration domain expertise; Rutagon contributes cloud-native architecture that processes sensor data efficiently and maintains compliance without imposing a compliance tax on the mission data throughput.