AI for mission planning

Mission planning converts what users want into what the spacecraft does. For a single satellite it is bookkeeping. For a constellation serving thousands of requests it is a hard combinatorial optimisation, and it is where much of the commercial value of an imaging system is created or lost.

The scheduling problem

An imaging satellite receives more requests than it can serve. The planner must choose which to serve, in what order, subject to constraints that interact.

The interaction is what makes it hard. Choosing to image target A may make target B unreachable because the slew cannot complete in time, which changes which of C or D is feasible afterwards. The problem is a variant of the orienteering problem with time windows and resource constraints, and it is NP-hard.

For a single satellite over one orbit it is tractable. For a constellation of hundreds over a week, with thousands of requests, exact optimisation is out of reach and the practical question is which heuristic gets closest.

Approaches

Operational systems are usually hybrids: a metaheuristic producing good solutions quickly, with the results checked against hard constraints independently, so that an optimiser bug cannot produce an infeasible plan that reaches the spacecraft.

Where learned methods help

Reinforcement learning for scheduling is an active research area with a specific and narrower value proposition than usually claimed.

Speed at inference

A trained policy produces a schedule in milliseconds where a solver takes minutes. That matters for onboard replanning, not for ground planning done overnight.

Handling uncertainty

A policy trained across distributions of weather and request patterns can be more robust than a plan optimised for one assumed scenario.

Not better solutions

On a well-specified static instance, a good solver generally beats a learned policy. The advantage is speed and robustness, not optimality.

The verification problem

A learned policy cannot be guaranteed to respect hard constraints, so it must be wrapped in a feasibility check, which is the runtime assurance pattern.

The honest framing is that learning helps where the problem must be solved fast, repeatedly, under uncertainty, and where a checker can validate the output. That describes onboard replanning well and ground planning poorly.

Cloud cover and the weather problem

For optical imaging, a substantial fraction of scheduled observations return cloud rather than ground. Imaging through cloud wastes the observation slot, the power, the storage and the downlink.

Predicting cloud at the observation time and location, and rescheduling around it, is one of the highest-value applications of forecasting in the field. A system that avoids clouded targets and substitutes clear ones increases usable yield substantially without any change to the space segment.

The stronger version runs onboard: assess cloud in the acquired image immediately, discard clouded scenes before they consume storage and downlink, and optionally retask. This is exactly the Phi-Sat-1 demonstration described in Edge computing in space.

Downlink allocation

Scheduling contacts is a second optimisation coupled to the first. Each satellite has visibility windows at each ground station, each station serves one satellite at a time, and data has priority and age.

The objective is usually latency rather than volume: minimising the age of delivered data matters more than maximising bytes transferred, because most commercial value decays with time. That changes the optimisation substantially, since an older lower-priority product may be worth transmitting before a newer one that will still be timely at the next pass.

Onboard replanning

The case for planning onboard rather than on the ground is that conditions change between uplink and execution.

A target may be clouded. An instrument may fault. A transient event may appear that is worth more than anything on the schedule. A ground-planned timeline cannot respond to any of these, and the opportunity is lost until the next planning cycle, which for a deep-space mission may be days.

The counterargument is verification, as in Autonomous spacecraft. An onboard planner that can generate any schedule can generate a harmful one.

The resolution used in practice is to bound the authority. The ground uplinks a plan plus a constrained set of permitted deviations, and the onboard system may choose within that set but not outside it. ASE on Earth Observing-1 operated this way for years: it could retask observations in response to detected events, within limits the ground had set.

Operator trust

The obstacle to deploying automated planning is frequently organisational rather than technical.

Operators are accountable for the spacecraft. A plan produced by a system whose reasoning they cannot inspect is one they must either accept on faith or verify manually, and manual verification of a complex schedule is slow enough to eliminate the benefit.

The practices that address this are unglamorous and effective.

The last row is underappreciated. Operators build intuition about a system’s behaviour, and an optimiser that finds a genuinely better but structurally different solution each cycle prevents that intuition from forming. Stability across planning cycles is worth some optimality.

References

• Chien, S. et al. “Using Autonomy Flight Software to Improve Science Return on Earth Observing One”, JACIC, 2:196, 2005.
• Lemaître, M. et al. “Selecting and scheduling observations of agile satellites”, Aerospace Science and Technology, 6:367, 2002.
• Wang, J. et al. “A review of Earth observation satellite scheduling”, IEEE Access, 2020 onward, for a survey of formulations and methods.
• Nag, S., Li, A. S. and Merrick, J. H. “Scheduling algorithms for rapid imaging using agile Cubesat constellations”, Advances in Space Research, 61:891, 2018.
• Giuffrida, G. et al. “The Phi-Sat-1 Mission”, IEEE TGRS, 60:1, 2022.