Skip to main content

​
Constellation Execution

WS4 Agent Mode Constellation Execution extends the Operator Agent to orchestrate workloads across multiple satellites. A DAG-based execution plan is distributed across the constellation, with steps assigned to individual satellites and data transferred between them via inter-satellite links (ISLs). The agent runtime handles step lifecycle, ISL coordination, and automatic failover when a satellite becomes unhealthy.
Constellation mode requires a multi-satellite deployment created from a constellation DAG plan. See CAE Constellation DAG for how plans are generated.

​
ConstellationState

Each agent participating in a constellation deployment maintains a ConstellationState that tracks its view of the distributed execution.

​
Step Lifecycle

Each step in the constellation DAG follows a deterministic state machine:
When a step completes, its output data is made available for dependent steps. If the dependent step is assigned to a different satellite, an ISL transfer is initiated automatically.

​
Automatic Failover

The agent runtime continuously monitors satellite health during constellation execution. A failover is triggered when any of the following conditions are detected:
Failover reassigns the step to the next eligible satellite in the DAG. If no eligible satellite is available, the step is marked as failed and the constellation plan terminates with a partial completion status.
When a failover occurs, the following sequence executes:
  1. The current satellite emits constellation.failover with the reason
  2. The orchestrator selects an alternate satellite from the DAG
  3. The step is reassigned and a constellation.failover_acknowledged event is emitted
  4. The new satellite begins execution from the last checkpoint (if available)

​
ISL Transfer Lifecycle

Data transfers between satellites follow a multi-hop model. Each hop represents a direct ISL link between two satellites in range.
Link quality between any two satellites is computed dynamically based on distance and eclipse state:
The 2ms additional latency accounts for onboard processing and protocol overhead at each hop. For multi-hop transfers, latency is cumulative across all hops.
Example: Two satellites 2,000 km apart, one in eclipse:
  • Distance factor: 1 - (2000 / 5000) * 0.6 = 0.76
  • Eclipse penalty: 0.76 * 0.9 = 0.684
  • Effective bandwidth: 100 * 0.684 = 68.4 Mbps
  • Propagation latency: 2000 / 299792 + 0.002 = 8.67ms

​
Event Enrichment

All constellation events are enriched with real-time satellite telemetry at the moment the event is generated: This telemetry is sourced from the SimulatedSatellite executor, which integrates with the Simulation Sessions service for subsystem state.

​
Event Types

​
Constellation Events

​
ISL Events

​
Integration with SimulatedSatellite

In simulation mode, the constellation executor uses the SimulatedSatellite backend to model each satellite’s behavior. This executor:
  • Maintains per-satellite subsystem state (battery, thermal, memory, CPU)
  • Applies realistic charge/discharge and thermal models per tick
  • Evaluates failover conditions against live subsystem values
  • Generates ISL quality metrics from actual propagated positions
The SimulatedSatellite executor connects to the Sim service’s session API to persist and retrieve constellation state.

Agent Protocol

Full protocol specification for agent communication

CAE Constellation DAG

How constellation execution plans are generated