What makes AI on a satellite different?
Ground-based AI usually starts after measurements have been transmitted to a data center. Onboard AI performs part of that interpretation inside the spacecraft. This can help when the payload produces more data than the available downlink can carry, or when it is useful to prioritize an observation before the next ground contact.
It does not remove the need for ground processing. Training, independent evaluation, mission planning and deeper analysis normally remain on the ground. The onboard model is one part of a larger measurement and decision pipeline.
A practical onboard processing pipeline
- Acquire and time the data. Capture images or measurements with timestamps, instrument settings and spacecraft context.
- Preprocess consistently. Apply the calibration, resizing, normalization or tiling expected by the model. Differences from the training pipeline can change the result.
- Run inference. Execute the deployed model on a suitable CPU, FPGA or accelerator. Measure the complete processing chain, not only the neural network kernel.
- Apply a decision policy. Convert model scores into a queue priority, an event record or a region of interest. Include confidence limits and a defined fallback.
- Store and transmit. Retain the selected data with its metadata and transmit it during the scheduled communication window. Preserve enough audit data to evaluate decisions on the ground.
Example: cloud screening before downlink
A cloud-screening model can score image tiles so that clear observations receive higher downlink priority. The engineering decision is not simply whether a tile contains a cloud: thin cloud, snow, bright roofs and unusual illumination can create ambiguous cases. The mission must choose how to handle uncertainty and how much unfiltered data to retain for evaluation.
ESA’s Φsat-2 CubeSat provides a real example of onboard AI for Earth observation. Its described applications include cloud detection, image compression and converting imagery into maps. This is an external mission example, not an Alvexis flight reference.
Source: ESA — Introducing Φsat-2
Other useful application patterns
- Prioritize imagery containing a mission-defined environmental event for ground review.
- Identify changes between observations and attach compact metadata to the relevant scenes.
- Monitor instrument telemetry for unusual behavior and request additional diagnostic data.
- Compress or select data while measuring the effect on the downstream scientific or operational task.
Power, memory and communication budgets come first
Choose a model that fits the mission rather than starting with the largest model available. Processing speed must be considered alongside memory movement, image buffers, storage writes and the energy used per observation. Scheduling inference only during suitable operating windows may matter more than peak throughput.
A useful downlink estimate is the retained data volume divided by the effective communication rate, plus protocol and scheduling overhead. A useful compute estimate measures energy and latency for the full pipeline using representative data. Neither estimate can be replaced by an accelerator’s advertised peak operations per second.
How should the model be validated?
Use separate training and evaluation datasets, including difficult seasons, illumination conditions and sensor artifacts. Test the deployed model format and numerical precision on the intended processor. Measure false alarms, missed events, retained data quality, latency and energy under the proposed operating modes.
AI outputs should pass through bounded application logic. For spacecraft-critical functions, a model score should not bypass the independently designed command validation and fault-protection architecture. Keep versioned model packages, known-good recovery images and a controlled update process.
Where Alvexis can contribute
Alvexis can scope custom payload-processing electronics, sensor interfaces, embedded software and prototype integration around the mission data path. The first deliverable should be an agreed architecture and a measurable prototype plan. Flight qualification remains specific to the selected hardware, orbit and mission.
Satellite communication and onboard data reduction
Satellite communication capacity, contact opportunities and onboard storage affect which measurements should be transmitted first. Satcom and onboard edge AI therefore need a shared data policy: retain enough raw evidence to evaluate processing decisions, identify the model version and define what happens when a result is uncertain.
Local processing can reduce the amount of data selected for downlink, but its benefit must be balanced against power, memory and thermal constraints. Satellite-to-satellite communication adds another interface and scheduling problem. Mission-specific verification is still required; an engineering prototype is not evidence of flight qualification.