TL;DR: A paper in the Constellations track at the 40th Small Satellite Conference made an argument I have been making 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. 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 - 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, link availability 92 percent, and recovery from a forced link outage in 10 minutes.
I spent the week of August 23rd at the Salt Palace Convention Center for the 40th Annual Small Satellite Conference. The theme was "The Clouds Above the Clouds: 40 Years of Collaboration," and the 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 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. What follows 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, I say that too.
Ground-Centric Operations Do Not Scale
The framing is direct. Constellation size and mission complexity are both growing, and ground-centric operations become hard to scale for three reasons: communication limitations, delayed decision-making, and operational workload. Mission operations architectures were built 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 recognizes the shape. Imagine a cluster whose API server is reachable for eleven minutes at a time, four times a day, with every reconciliation batched into those windows. You would not fix that with smarter controllers. You would move the decisions closer to the nodes. The paper's version of the argument is that operator workload grows linearly with the number of spacecraft while the communication surface of a fully connected constellation grows quadratically, so centralized architectures become inefficient as spacecraft are added. I would add that the linear half is the optimistic half: the decisions that matter in a coordinated constellation concern pairs and groups rather than individual spacecraft, so workload plausibly tracks something closer to the link count. If so, the case for architectural autonomy is stronger than the paper's own math claims.
To make ground dependence measurable rather than rhetorical, the paper introduces the Ground Dependency Ratio: the fraction of operational decisions requiring direct ground intervention. That is the most portable idea here, because it is really a proxy for where decision authority lives. The difference between a ground-centric constellation and an autonomous one is not that the second has inter-satellite links. It is that in the first, the ground holds the decision and the link is a control channel; in the second, the ground holds the intent and the links are a coordination fabric.
What Is Actually New
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 explored extensively through onboard algorithms and AI techniques, but little attention has gone to how autonomy should be integrated into the systems engineering architecture of a constellation mission. Autonomous functions get introduced at the subsystem or software level without addressing how they influence topology, operational workflows, coordination, communication architecture, and mission-level decision processes. The paper claims the corner where high autonomy, constellation focus, and systems engineering integration are all present at once - Remote Agent and EO-1 have the first without the others, prior systems engineering work has the last without the first.
That gap is the same one 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 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
Mission awareness holds the strategic context: objectives, environmental conditions, and operational requirements. This is what makes autonomy tractable rather than terrifying - the declarative specification against which every autonomous action is checked. In control plane terms it is the spec, not the status.
State awareness maintains each spacecraft's own state, its health and fault conditions, and its link status with neighbors and ground. This is the hardest layer in practice. 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 notes the dependence on accuracy and timeliness of state information. I would go further: 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, and its inputs are the whole architectural argument. It takes mission intent, local state, and neighbor state received over inter-satellite links - and nothing from the ground. Ground influence enters only as intent, through the mission awareness layer.
Coordination and inter-satellite communication turns individually reasonable local decisions into coherent constellation behavior, weighting the contribution of each active link. Whether a link exists at all is a geometry question, so connectivity changes continuously as the orbits evolve. This layer has the least terrestrial slack: you cannot assume a quorum, bounded message delay, or that a 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, then feeds observed deviations back to the higher layers, closing the loop from intent to state to decision to coordination to action. 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 section I most appreciated refuses the easy story. The framework is explicitly not intended to remove the ground segment; it redefines the relationship as supervisory autonomy. Routine decisions happen in the constellation, while the ground handles mission planning, objective management, performance assessment, and exceptions. Each cycle's intent then depends on two things: what the ground wants next, and what the constellation actually did.
This is the 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 analogy holds tightly enough that I expect the failure modes to transfer too: underspecified intent, 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
The evaluation is refreshingly unpretentious: four spacecraft, HI1 through HI4, in a near-circular orbit around 622 km, simulated over 20 days with a 3000 km maximum communication range and a forced HI2-HI3 outage as the disturbance. A ground-driven baseline with centralized decision authority is compared against the framework scenario with decisions distributed across the constellation. Three of the six possible links sit inside the range threshold for the run: HI1-HI2, HI2-HI3, and HI3-HI4.
| 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 precision deserves repeating: the framework does not prevent the physical link loss, it reduces the operational impact by preserving coordination through alternate available links.
The metrics are the most interesting methodological choice 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 a notably different framing from the pointing-accuracy and delta-v numbers that dominate constellation papers.
Where I Would Push
None of this is an objection. These questions become askable precisely because the paper put autonomy in the architecture where it can be interrogated.
The recovery result is partly a geometry result. The three active links form a path, so forcing the middle one down splits the constellation into two pairs. Recovery cannot come from a spare edge sitting idle; it has to wait for the orbits to bring another pair inside range. If that reading is right, the 10 minutes measures orbital geometry as much as decision-making speed. Separating the two - how long until an alternate path exists, versus how long after that until coordination is re-established - would strengthen the result, because the second number is the one that characterizes the framework.
Ground Dependency Ratio needs a counting rule. A ratio of 0.15 is only as meaningful as the convention behind the denominator. Is a routine link activation one decision? Is a coordinated observation one decision or four? Without a stated rule the metric is hard to compare across missions, which is a shame, because comparability is what would make it a field-wide metric rather than an internal one.
A continuity index of 0.95 over 20 days is about a day of non-coordinated operation. That may be acceptable or mission-ending, depending on when it falls and what the constellation was supposed to be doing. Continuity metrics hide their worst case inside the average; the distribution of the gaps is more interesting than the ratio.
Four spacecraft is a demonstration, not a scalability result, which the paper says plainly rather than overclaiming. Its scalability argument is architectural: the awareness, decision, coordination, and execution functions are defined independently of constellation size. Credible on its own terms, and also exactly the kind of argument terrestrial distributed systems have repeatedly falsified - the architecture scales, and then the coordination layer discovers a quadratic nobody budgeted for. The paper's own observation about quadratic link growth is a hint about where to look first.
The trust model is unaddressed, though cybersecurity appears among the open challenges. The decision function consumes state assertions from neighbors, so 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 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 layer 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. That is the largest gap between this framework and a flight program, and it is to its credit that it says so.
Why This Matters Beyond Spacecraft
Offered as my own extrapolation: the five-layer decomposition is nearly isomorphic to the architecture we converged on for distributed control planes on the ground - declarative intent, observed state, a reconciliation decision, a coordination step, and an actuation step that feeds observation back. That 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. 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 why the systems engineering framing is the right one.
It also implies a design rule the framework leaves implicit: a neighbor's state is an observation with an age, never a fact, and the decision layer needs an explicit outcome for "I do not know enough to act." Systems that lack that third option alongside act-locally and coordinate-first do not become cautious under uncertainty. They become confidently wrong. Deferring is what keeps a degraded state awareness layer from poisoning the decision layer, and it is the natural place for the ground 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, evaluates it on operability metrics under CubeSat-class constraints, and is candid that four spacecraft is a starting point rather than a proof. Forty years in, the Small Satellite Conference has gotten very good at 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!