Autonomous spacecraft

Spacecraft autonomy is driven by physics, not by ambition. Light time and contact windows make ground control impossible for anything fast, and the question is only how much authority to delegate.

Why autonomy is forced

Two separate constraints operate. Light time removes the ground from any control loop faster than the round trip. Contact windows remove it even in low Earth orbit, where a satellite is typically in view of a given station for six to ten minutes, four to six times a day, as described in Ground segment.

A satellite is therefore alone for the overwhelming majority of its life regardless of how close it is. Entry, descent and landing at Mars takes about seven minutes and the ground learns the outcome after it has happened.

Levels of autonomy

The ECSS framework distinguishes four levels, and the distinction is useful because each level multiplies the verification burden.

Most operational spacecraft sit at E2 with elements of E3. The ground builds a command sequence, validates it against a simulator, and uplinks it. The spacecraft executes on a timeline and reacts to a limited set of conditions.

E4 remains rare, and the obstacle is not capability but verification. A system that plans its own actions has a state space too large to enumerate, so testing cannot cover it exhaustively. Demonstrating that an onboard planner will never generate a harmful plan is a substantially harder problem than demonstrating that a fixed sequence is correct, and mission assurance practice is built around the second.

Onboard planning

A planner takes a set of goals and constraints and produces a schedule of actions. Onboard, it must do this within severe limits: a flight processor three orders of magnitude slower than a laptop, and a hard requirement never to produce a plan that damages the spacecraft.

The flight heritage is real but narrow. Remote Agent flew on Deep Space 1 in 1999 and demonstrated onboard planning, execution and fault recovery, which remains the reference experiment for E4 autonomy. ASE on Earth Observing-1 detected volcanic and flood events onboard and autonomously retasked subsequent observations, running for years. AEGIS on Curiosity and Perseverance selects rock targets for laser spectroscopy autonomously, which recovers science that would otherwise be lost waiting for a ground cycle.

The pattern across all three is that the autonomy is bounded. It operates within a space the ground has constrained, and its worst possible action is acceptable. That boundedness is what made them flyable.

Fault management

Autonomous fault management is more widely deployed than autonomous planning, because it is unavoidable: a fault that will damage hardware in milliseconds cannot wait for a ground response.

The governing principle is that autonomy should be proportional to urgency. A fault that destroys hardware in milliseconds must be handled in hardware. A fault that merely degrades performance should be reported and left to the ground, which has more information and better judgement.

Building elaborate autonomous recovery for non-urgent faults adds software that is itself a failure source. FDIR logic misfiring on a healthy spacecraft is a well-represented category of anomaly, and the fix is usually to make the logic less aggressive rather than more capable. See Fault tolerance and reliability.

The verification problem

The central obstacle to greater autonomy is assurance, and it is worth stating precisely why it is hard.

State space explosion

A system that plans cannot be exhaustively tested, because the number of reachable states is astronomically large.

Emergent behaviour

Interactions between individually correct components produce behaviour nobody specified. Mars Polar Lander was lost to exactly this pattern.

Formal methods

Model checking and theorem proving can prove properties over the whole state space, and are used for critical components. They do not scale to a full system.

Runtime assurance

The practical compromise: let a complex planner propose actions, and interpose a simple, verifiable monitor that rejects anything violating a safety envelope.

Runtime assurance is the approach with the most traction, because it inverts the problem. Rather than proving a complex system is always safe, prove that a simple system will always catch unsafe outputs. The simple monitor is small enough to verify exhaustively, and the complex planner can then be as sophisticated as desired.

Machine learning onboard

Applying learned models to spacecraft control raises the verification problem in its sharpest form. A neural network’s behaviour on inputs outside its training distribution is not characterisable by testing, and space is precisely where out-of-distribution inputs occur.

The division that has emerged in practice is instructive.

The distinction is consequence. A misclassified cloud costs a downlink slot. A control action based on a misperception can destroy the spacecraft. See Computer vision in space and Edge computing in space.

References

• Muscettola, N. et al. “Remote Agent: to boldly go where no AI system has gone before”, Artificial Intelligence, 103:5, 1998.
• Chien, S. et al. “Using Autonomy Flight Software to Improve Science Return on Earth Observing One”, Journal of Aerospace Computing, Information and Communication, 2:196, 2005.
• Francis, R. et al. “AEGIS autonomous targeting for ChemCam on Mars Science Laboratory”, Science Robotics, 2:eaan4582, 2017.
• ECSS-E-ST-70-11C, Space segment operability, for the autonomy levels.
• Schierman, J. D. et al. “Runtime Assurance Framework Development for Highly Adaptive Flight Control Systems”, Barron Associates, 2015.