TL;DR: At the 40th Small Satellite Conference in Salt Lake City, a paper in the Constellations track argued something I have been saying about ground software for years, only aimed at spacecraft: autonomy is not an algorithm you add at the end, it is an architectural property you either designed for or you did not. The Design Mechanism Framework in SSC26-VI-02 decomposes constellation autonomy into five layers - mission awareness, state awareness, autonomous decision-making, coordination and inter-satellite communication, and execution and response - gives each a mathematical form, and evaluates the closed loop on a four-spacecraft LEO constellation over 20 days. Reported results: coordination continuity index 0.95, ground dependency ratio 0.15, inter-satellite link availability 92 percent, and recovery from a forced link outage in 10 minutes. The layering is nearly identical to the control plane structure we build for distributed systems on the ground, which is either reassuring or a warning, depending on how much you trust our track record.
I spent the week of August 23rd at the Salt Palace Convention Center for the 40th Annual Small Satellite Conference. The theme this year was "The Clouds Above the Clouds: 40 Years of Collaboration," and the technical program reflected a field that has stopped arguing about whether small satellites are serious and started arguing about how to operate hundreds of them at once. The session that stayed with me was Session VI on Constellations, and specifically SSC26-VI-02, "Design Mechanism Framework for Autonomous Small Satellite Constellations - A NewSpace Outlook," presented by Mohammed Irfan Rashed of the Hawaii Institute of Geophysics and Planetology at the University of Hawaii at Manoa on Tuesday afternoon.
I have since read the paper properly. This post is my reading of it and what I think it means for anyone who builds distributed control systems, whether those systems fly or sit in a rack. Where I am reporting the paper I say so. Where I am extrapolating from my own experience building agent and platform infrastructure, I say that too, because the two should not be confused.
The Problem: Ground-Centric Operations Do Not Scale
The framing is direct. Constellation deployment is growing, mission complexity is growing, and traditional ground-centric operational approaches become difficult to scale for three stated reasons: communication limitations, delayed decision-making, and increased operational workload. Mission operations architectures, the paper notes, were originally developed for single-spacecraft missions, where operators periodically assess telemetry, generate plans, and upload command sequences during scheduled windows. That model does not survive contact with a hundred spacecraft.
Anyone who has run a distributed system will recognize the shape of this immediately. A ground-centric constellation is a system where every non-trivial decision requires a round trip to a single coordinator, and that coordinator is only reachable during scheduled windows. In terrestrial terms, imagine a Kubernetes cluster where the API server is reachable for eleven minutes at a time, four times a day, and every reconciliation must be batched into those windows. You would not fix that by writing smarter controllers. You would move the decisions closer to the nodes.
The paper quantifies the pressure with two relationships that sit in tension, and that tension is the most interesting thing in the problem statement. Operational decisions are modeled as growing with constellation size:
N_ops proportional to N
while the communication surface of a fully connected constellation grows quadratically:
N_links = N(N - 1) / 2
Linear operator workload against a quadratic coordination surface. The paper uses the second to argue that centralized architectures become inefficient as spacecraft are added, which is correct. My own read is that the first relationship is the optimistic one: in a genuinely coordinated constellation, the decisions that matter are about spacecraft pairs and groups, not spacecraft individually, so operator workload plausibly tracks something closer to the link count than the node count. If that is right, the case for architectural autonomy is stronger than the paper's own math claims, not weaker.
To make ground dependence measurable rather than rhetorical, the paper introduces the Ground Dependency Ratio:
GDR = N_ground / N_total
the fraction of operational decisions requiring direct ground intervention. Naming and measuring this is a modest-looking contribution that I think is the most portable idea in the paper. You cannot manage what you do not measure, and "how much of your operations is a human in a windowed loop" is exactly the number a constellation program should track as it scales.
graph TB
subgraph Ground["Ground-Centric Operations"]
GS[Ground Station] -->|contact window| S1[Sat 1]
GS -->|contact window| S2[Sat 2]
GS -->|contact window| S3[Sat 3]
GS -->|contact window| SN[Sat N]
OPS[Operations Team] --> GS
end
subgraph Auto["Supervisory Autonomy"]
A1[Sat 1] <-->|ISL| A2[Sat 2]
A2 <-->|ISL| A3[Sat 3]
A3 <-->|ISL| AN[Sat N]
AGS[Ground Station] -.->|intent and exception handling| A1
end
The distinction is not that one architecture has inter-satellite links and the other does not. It is where decision authority lives. In the first, the ground segment holds the decision and the link is a control channel. In the second, the ground segment holds the intent and the links are a coordination fabric.
What Is Actually New Here
The honest question about any autonomy paper is what it adds to a field that has been publishing onboard autonomy work since the Remote Agent Experiment in 1998. The paper's answer, which I think is correct and underappreciated: autonomy has been widely explored through onboard algorithms and AI techniques, but there has been limited attention to how autonomy should be integrated into the systems engineering architecture of constellation missions. Autonomous functions get introduced at the subsystem or software level without addressing how autonomy influences constellation topology, operational workflows, inter-satellite coordination, communication architecture, and mission-level decision processes.
The paper makes this concrete with a comparison table positioning the work against prior art. Remote Agent and the EO-1 Autonomous Science Agent are rated high autonomy but no constellation focus and no systems engineering integration. Araguz and colleagues on distributed autonomy: medium and partial. Qiao and colleagues on ISL planning and Luo and colleagues on autonomous navigation: medium autonomy, constellation focus, no systems engineering integration. Rodriguez and colleagues on systems engineering: low autonomy but with integration. The claimed gap is the corner where all three are present at once.
That gap is real, and it is the same gap I keep hitting in enterprise AI work. There is an enormous body of work on models and planners and a much thinner body on where those components sit in a system, what contracts they expose, what they are permitted to decide, and what happens when they are wrong. A scheduling algorithm is a component. An operational architecture is a set of decisions about authority, state ownership, failure domains, and degradation behavior. You can put a state of the art planner inside an architecture that cannot survive one node going quiet.
The Five Layers
The framework decomposes into five layers forming a closed loop. I am giving the paper's definition and formalism for each, then my own commentary on the terrestrial analogue, since that is where I can add something rather than repeat.
graph TD
L1["Mission Awareness<br/>M(t) = objectives, environment, requirements"] --> L2["State Awareness<br/>Si(t) = state, health, comms"]
L2 --> L3["Autonomous Decision<br/>Ai(t) = f(M, Si, Ni)"]
L3 --> L4["Coordination and ISL<br/>Ci(t) = weighted sum of active links"]
L4 --> L5["Execution and Response<br/>Xi(t+1) = F(Xi, Ai)"]
L5 -.->|updated state feeds awareness| L2
GND["Ground Segment<br/>supervisory guidance G(t)"] -.-> L1
Mission awareness establishes the strategic context as M(t) = {O(t), E(t), R(t)} - objectives, environmental conditions, and operational requirements. This is the layer that makes autonomy tractable rather than terrifying: it is the declarative specification, the desired state, the thing against which every autonomous action is checked. In control plane terms it is the spec, not the status.
State awareness maintains Si(t) = {Xi(t), Hi(t), Ci(t)} - the spacecraft state vector including orbital position, velocity, attitude, power availability and payload status; health status covering subsystem performance and fault conditions; and communication status covering link availability and quality with neighbors and ground. This is the hardest layer in practice and the one where distributed systems experience transfers most directly. A constellation cannot have a globally consistent view of itself. Light time is small in LEO but link availability is not, and any state a spacecraft holds about a neighbor is stale by an unknown amount. The paper acknowledges the dependence on accuracy and timeliness of state information; I would go further and say staleness should be a typed, first-class input to the decision layer rather than an assumption about data quality.
Autonomous decision is the central reasoning component: Ai(t) = f(M(t), Si(t), Ni(t)), where Ni(t) is information received from neighbors over inter-satellite links. Note what this signature commits to. The decision function takes mission intent, local state, and neighbor state - and nothing from the ground. Ground influence enters only through M(t), as intent. That is the entire architectural argument compressed into one equation, and it is the right one.
Coordination and inter-satellite communication turns individually reasonable local decisions into coherent constellation behavior, with coordination influence modeled as a weighted sum over active links. Link availability itself is a geometry predicate: the link between spacecraft i and j is active when separation dij(t) is within the maximum communication range and inactive otherwise, producing a time-varying communication graph G(t) = (V, E(t)). This is the layer with the least terrestrial slack. You cannot assume a quorum, you cannot assume bounded message delay, and you cannot assume the partition heals on a schedule you control - the topology is a function of orbital mechanics, not of your retry policy.
Execution and response converts coordinated decisions into actuation, Xi(t+1) = F(Xi(t), Ai(t)), covering attitude maneuvers, orbit maintenance, link establishment, payload operations, fault recovery, and resource management. Critically, the response half monitors execution outcomes and feeds deviations back to the higher layers. The overall loop is stated compactly:
M(t) -> S(t) -> A(t) -> C(t) -> X(t+1)
That feedback edge matters more than it looks. Without it the stack is open loop, and an open loop autonomous system is just a very confident scheduler.
Supervisory Autonomy: The Ground Segment Does Not Disappear
The section I most appreciated is the one on ground integration, because it refuses the easy story. The framework is explicitly not intended to remove the ground segment. It redefines the relationship as supervisory autonomy: routine operational decisions happen in the constellation, while the ground focuses on mission planning, objective management, performance assessment, and exception handling. The interaction is written as:
M(t+1) = G(t) + X(t+1)
where G(t) is supervisory guidance from the ground and X(t+1) is the constellation state after autonomous execution, together forming the next mission context. The notation is loose - you are not literally summing guidance and state - but the intent is unambiguous and correct: the next cycle's intent is a function of what the ground wants and what the constellation actually did.
This is the same shift infrastructure went through over the last decade, from imperative runbooks to declarative intent with a reconciliation loop. The operator stops issuing steps and starts specifying outcomes and exception policy. The paper is making that argument for spacecraft operations, and the analogy holds tightly enough that I expect the failure modes to transfer too: intent that is underspecified, exception handling that was never exercised, and the slow drift where operators lose the ability to reason about a system they no longer drive.
The Simulation: Small, Honest, and Legible
Here is where the paper is refreshingly unpretentious. The evaluation uses a four-spacecraft LEO constellation, named HI1 through HI4, simulated over 20 days in a mission design and analysis environment.
| Parameter | Value | | --- | --- | | Number of spacecraft | 4 | | Semi-major axis | 7000 km | | Approximate altitude | 622 km | | Eccentricity | 0 (near-circular) | | Simulation duration | 20 days | | ISL condition | contact and line-of-sight based | | Maximum communication range | 3000 km | | Disturbance | forced HI2-HI3 link outage |
Two scenarios are compared: a conventional ground-driven baseline where decision authority stays centralized, and the DMF scenario where decisions are distributed across the constellation. Metrics are the Coordination Continuity Index CCI = Tcoord / Tmission, the Ground Dependency Ratio, recovery time, and ISL availability.
The link geometry over the run is reported per pair:
| Link pair | Representative range | Status | | --- | --- | --- | | HI1-HI2 | ~2431 km | Active | | HI1-HI3 | ~3623 km | Inactive | | HI1-HI4 | ~5486 km | Inactive | | HI2-HI3 | ~2529 km | Active | | HI2-HI4 | ~3516 km | Inactive | | HI3-HI4 | ~2431 km | Active |
And the headline results:
| Metric | Value | | --- | --- | | Coordination Continuity Index | 0.95 | | Ground Dependency Ratio | 0.15 | | Recovery time after forced outage | 10 minutes | | ISL availability | 92 percent |
The paper is careful about what the outage result means, and the framing deserves repeating because it is the kind of precision that makes a result trustworthy: the framework does not prevent the physical link loss, it reduces the operational impact of that loss by preserving coordination through alternate available links.
The choice of metrics is the most interesting methodological decision here. Coordination continuity, ground dependency, recovery time, and link availability are operability metrics, not performance metrics. They measure whether the system keeps working, not how well it performs when it does. That is the right axis for evaluating an architecture, and it is a notably different framing from the pointing-accuracy and delta-v numbers that dominate constellation papers.
Where I Would Push
None of what follows is an objection to the framework. These are the questions that become askable precisely because the paper put autonomy in the architecture where it can be interrogated.
The recovery result deserves a closer look at the topology. With a 3000 km threshold, the active links form a path: HI1-HI2, HI2-HI3, HI3-HI4. Forcing HI2-HI3 down cuts the middle edge of a path graph, which at that instant partitions the constellation into two pairs. The recovery therefore cannot come from a spare edge sitting idle; it has to come from the time-varying geometry, as HI2-HI4 or HI1-HI3 drop under threshold while the orbits evolve. If that reading is right, the 10-minute recovery is substantially a measure of orbital geometry rather than of decision-making speed, and it would strengthen the result considerably to separate the two: how long until an alternate path exists, versus how long after that until coordination is re-established. The second number is the one that characterizes the framework.
GDR needs a denominator definition. A ratio of 0.15 is only as meaningful as the decision-counting convention behind N_total. Is a routine link activation one decision? Is a coordinated observation one decision or four? Without a stated counting rule, GDR is hard to compare across missions, which is a shame because comparability is exactly what would make it valuable. Nailing this down would turn a good internal metric into a field-wide one.
A CCI of 0.95 over 20 days is about a day of non-coordinated operation. That may be entirely acceptable, or it may be mission-ending, depending on when it falls and what the constellation was supposed to be doing at the time. Continuity metrics tend to hide their worst case inside the average, and the distribution of the gaps is more operationally interesting than the ratio.
Four spacecraft is a demonstration, not a scalability result, which the paper says plainly rather than overclaiming. The scalability argument is architectural: awareness, decision, coordination, and execution functions scale independently of N, and adding spacecraft does not alter the operational architecture. I find that credible on its own terms, and it is also exactly the kind of argument terrestrial distributed systems have repeatedly falsified in practice - the architecture scales, and then the coordination layer discovers a quadratic nobody budgeted for. The paper's own N(N-1)/2 is a hint about where to look first.
The trust model in the coordination layer is unaddressed, and the paper does list cybersecurity among the open implementation challenges. The decision function consumes Ni(t), state assertions from neighbors. A spacecraft that is compromised, or simply failing in a non-fail-stop way, becomes a source of plausible but wrong state that propagates into everyone else's decision logic. Byzantine behavior is not hypothetical in a system whose links are RF and whose nodes sit in a radiation environment. The per-link weights in the coordination equation are the natural hook for a confidence or trust model, and I would like to see them carry that meaning.
Verification and validation is called out honestly as the hard problem. Autonomous constellations continuously adapt their behavior, so validation has to cover constellation-level decision and coordination behavior, not just subsystem performance, and the paper is clear that hardware-in-the-loop testing and operational demonstration remain necessary. This is the largest gap between this framework and a flight program, and it is to the paper's credit that it says so rather than burying it.
Why This Matters Beyond Spacecraft
Here is my own extrapolation, offered as such.
The five-layer decomposition is nearly isomorphic to the architecture we converged on for reliable distributed control planes on the ground: declarative intent, observed state, a reconciliation decision, a coordination step, and an actuation step that feeds observation back. M(t) -> S(t) -> A(t) -> C(t) -> X(t+1) is a reconciliation loop with an explicit coordination stage. That convergence is not a coincidence. Both domains face partial views, unreliable links, no global clock, and real consequences for wrong decisions, and both arrived at the same shape.
The difference is the cost of failure and the impossibility of a hotfix. A bad reconciliation loop in a cluster gets rolled back in minutes. A bad coordination policy in orbit is a fleet-wide behavior you may not be able to reach for hours, running on hardware you will never touch again. That asymmetry is exactly why the systems engineering framing is the right one, and why the implementation substrate for these layers deserves more attention than it usually gets. Long-duration autonomous operation, no garbage collection pause inside a control loop, memory safety without a runtime, and exhaustive handling of the state space at compile time are not stylistic preferences in this environment.
What that looks like if you take the state awareness and decision boundary seriously:
/// A neighbor's state is an observation with an age, never a fact.
/// This is Ni(t) in the framework's decision function.
pub struct NeighborView {
pub sat_id: SatId,
pub observed_at: Epoch,
pub ephemeris: Ephemeris,
pub health: HealthStatus,
/// The coordination weight from the paper, reinterpreted as trust.
pub weight: f32,
}
impl NeighborView {
/// Staleness is an input to every decision, not an afterthought.
pub fn confidence(&self, now: Epoch) -> Confidence {
match now - self.observed_at {
age if age < Duration::from_secs(60) => Confidence::Fresh,
age if age < Duration::from_secs(600) => Confidence::Degraded,
_ => Confidence::Stale,
}
}
}
pub enum Decision {
/// Safe to act on local knowledge alone.
Autonomous(Maneuver),
/// Requires agreement from the coordination layer first.
RequiresCoordination(Proposal),
/// Confidence too low to act. Hold, observe, and let the
/// ground segment's supervisory guidance arrive if it can.
Defer(HoldReason),
}
The point of the Defer arm is that an autonomous system needs an explicit, designed answer to "I do not know enough to act." Systems that lack that arm do not become cautious under uncertainty. They become confidently wrong. In the framework's terms, Defer is what keeps a degraded state awareness layer from silently poisoning the decision layer, and it is also the natural place for the ground segment to re-enter the loop.
Closing Thought
The most useful thing about SSC26-VI-02 is not any single layer or number. It is the reframing. For most of the last decade, autonomy in this field has meant a smarter algorithm running on one spacecraft. This paper treats it as a property of the mission architecture, gives it a formal structure, evaluates it on operability metrics under CubeSat-class constraints, and is candid that a four-spacecraft demonstration is a starting point rather than a proof. The stated next steps - dozens to hundreds of spacecraft, learning-based decision support in the decision layer, and extension to cislunar and deep-space regimes - are the right ones, and the last of those is where ground intervention stops being merely inconvenient and starts being physically impossible.
Forty years in, the Small Satellite Conference has gotten very good at the question of how to build the spacecraft. The interesting frontier now is how to operate a thousand of them without a thousand operators.
References
- Rashed, Mohammed Irfan. "Design Mechanism Framework for Autonomous Small Satellite Constellations - A NewSpace Outlook." SSC26-VI-02, 40th Annual Small Satellite Conference, Salt Palace Convention Center, Salt Lake City, UT, August 25, 2026. DigitalCommons@USU, DOI 10.26077/d71a-a240
- Small Satellite Conference 2026 proceedings, "The Clouds Above the Clouds: 40 Years of Collaboration." DigitalCommons@USU
- Muscettola, N., Nayak, P. P., Pell, B., and Williams, B. C. "Remote Agent: To Boldly Go Where No AI System Has Gone Before." Artificial Intelligence, vol. 103, pp. 5-47, 1998.
- Araguz, C., Bou-Balust, E., and Alarcon, E. "Applying Autonomy to Distributed Satellite Systems: Trends, Challenges, and Future Prospects." Systems Engineering, 2018.
- Edmonson, W. et al. "Systems Engineering of Inter-Satellite Communications for Distributed Systems of Small Satellites." IEEE Systems Conference (SysCon).
Comments (0)
No comments yet. Be the first to share your thoughts!