Why Payload Processing Is Moving from Ground to Orbit

The short answer: Payload processing is moving from ground to orbit because satellite sensors now produce more data than downlink windows can carry. Processing on board decides what to keep before it uses link capacity. The trade-off is power, heat and radiation tolerance, all of which are fixed in the board design years before launch.

Earth observation satellite launches are close to tripling decade over decade. Novaspace counts 1,864 launched in the decade to 2023 and forecasts 5,401 for 2024 to 2033. Its current edition puts the figure above 6,500 by 2035. Downlink capacity per spacecraft has stayed roughly where it was. That gap is why compute is moving onto the satellite. The split between what a payload processes in orbit and what it ships to the ground becomes a decision about a circuit board, made years before launch.

The link is the binding constraint. A sensor that produces more data than its contact windows can carry is producing data that will be deleted, and deciding what to delete is a processing job. Do it on the ground and you have already paid the downlink cost. Do it in orbit and you pay in watts, in mass, and in a device that has to survive the radiation environment for the mission’s life.

Key takeaways

• Earth observation satellite launches are forecast to rise from 1,864 (2014–2023) to 5,401 (2024–2033), while downlink capacity per spacecraft has stayed roughly flat.
• Processing data in orbit pays off when it removes data before downlink. ESA’s Φ-sat-1 showed this in 2020 by screening out cloudy imagery on board.
• Each processing step should be judged against four constraints together: latency, downlink bandwidth, power and thermal capacity.
• Power is the most underweighted constraint, because onboard compute draws current across the whole orbit, not just during contact windows.
• The split between orbit and ground is fixed in the board specification and can’t be corrected after launch.

A payload gets no field service

Most arguments about edge computing assume a second chance. A gateway in a factory can be swapped. A vehicle can take a new module at the next service interval. Neither assumption survives launch.

The board that goes up is the board that runs the mission. Its power budget was allocated by the spacecraft, its thermal path was designed into the structure, and its interfaces were laid out before any flight software existed. Reconfigurable logic lets you change what a region computes. It gives you no extra bandwidth, current, or thermal headroom to do it with. All three were sized for the plan you had at layout. The onboard and ground split is settled in the specification, and the mission finds out whether it was right.

That is a different problem from the one the literature describes. Academic work on orbital edge computing models scheduling and latency well. Market forecasting sizes the opportunity. Neither tells an engineering team which tasks belong on the spacecraft, and that is the decision in front of them.

How do you decide what to process in orbit?

Teams that make this call well evaluate each processing step against latency, downlink bandwidth, power, and thermal capacity together, and reach a different answer for different steps in the same pipeline.

• Latency puts a task onboard when its output has to act before the ground can respond. A contact window may be twenty minutes away, too slow for closing a pointing loop, cueing a second sensor, or triggering a downlink. Those tasks are onboard by necessity, and the trade is about what they cost.
• Downlink bandwidth decides most of the rest. If processing a frame in orbit means the frame never needs a downlink slot, the compute has paid for itself in link budget. ESA flew this in 2020 on Φ-sat-1, which ran cloud detection on an Intel Movidius vision processor and sorted imagery before transmission. ESA’s account is that the mission achieved pre-filtering “so that only relevant part of the image with usable information are downlinked to the ground, thereby improving bandwidth utilisation and significantly reducing aggregated downlink costs.” Screening is the clearest case for it. The discard rate is high, and the decision itself is cheap to compute. Deeper products are harder to justify. A task that reduces data volume by a tenth buys a small link saving with a permanent power allocation.
• Power is the unit engineering leaders underweight. It is also the one that binds. Every task assigned to the payload processor draws current across the whole orbit, well beyond the minutes of a contact window. That current comes from a budget the spacecraft divided among the bus, the sensor, the transmitter and the payload before the compute requirement was firm. Onboard inference hardware is capable now, and Kratos records flight-track processors rated at 248 TOPS. The harder question is whether the spacecraft can feed one.
• Thermal capacity is power seen from the other side. In orbit, it is harsher than the number suggests. There is no convection. Every watt the processor draws becomes heat that has to conduct to a radiating surface, across a structure that is also cycling between sun and eclipse. A design that closes at nominal load and opens under worst-case switching will throttle in orbit. That turns a power problem into a missed deadline on the latency-critical tasks that justified onboard processing in the first place.
• Radiation sits underneath all four and decides which silicon is a candidate at all. Single-event effects, mitigation strategies and the choice between radiation-hardened and radiation-tolerant parts are their own discipline, covered in our write-up on FPGA design for aerospace. For this decision the relevant point is narrower. The device list is short before the trade starts, and a task that only closes on a part outside that list stays on the ground.

What this makes the compute board responsible for

The board has to run the tasks the trade assigned it, at the power the spacecraft allocated, through a thermal path the structure can carry, on a device the radiation environment permits, for the mission’s life.

Reconfigurable logic earns its place where the processing has to change after launch and where determinism carries more weight than peak throughput. For a mission-specific pipeline (filtering, compression, classical vision, beamforming), an FPGA holds a timing budget at a power number a GPU-class part will not meet. Large models and general-purpose inference are a separate problem with a separate power profile, and missions are now flying both kinds of hardware.

The physical design is where the trade holds or quietly breaks. Power delivery has to close under worst-case switching, and average draw will not tell you whether it does. Signal integrity has to survive the connector and layer stack at the rates the sensor interface demands. The thermal path has to be simulated against the real duty cycle. Those are separate disciplines and they are validated at the seams between them. A team deep in one and thin in the others finds that out late.

What goes wrong when the onboard/ground split is wrong?

The failure modes are the familiar FPGA ones with the recovery path removed.

Partitioning done early and never revisited puts a task in logic that belonged in software, or in software that belonged in logic, and the interface it implies gets frozen into the board. Simulation skipped in favour of lab work is the expensive one. The lab stops being available at launch, and the bench never reproduced the thermal and radiation environment anyway. Device selection sized for the current requirement leaves no margin for what the operator will ask the payload to do later in a fifteen-year mission.

Each of those is cheap while the design is still a specification. None of them is fixable once the spacecraft is on orbit. That is why the split gets settled as a hardware decision.

Getting the split right before launch

Contact Fidus while the split is still a line in a specification.

Frequently asked questions