Can COTS AI Accelerators Survive in Orbit? Radiation, Power, and Fault Handling for Onboard Satellite Inference
Two-thirds of the Earth is under cloud at any moment, on average. A satellite that photographs the ground, spends precious downlink time sending those images home, and then lets a ground system discover that most of the frames show cloud has wasted most of its mission. That arithmetic is why running a neural network on the satellite itself, rather than on the ground, moved from research curiosity to engineering practice over the past few years. It is also why a hardware team with a good edge-AI product and no spaceflight background keeps hearing the same question from satellite builders: could your accelerator work up there?
The honest answer is "possibly, and the interesting part is why." A commercial accelerator is not designed for radiation, vacuum, or thermal cycling in eclipse. Skeptics are right about that. But the skeptics' conclusion, that commercial parts have no place in orbit, has been overtaken by flight results, by testing campaigns on popular accelerator families, and by a design discipline that treats the commercial chip as one component inside a fault-tolerant system. This post takes the skeptic's objections in the order they tend to arrive, answers each with what is known, and ends with a build sequence for a team that wants to prototype a payload.
Do not ask whether a commercial chip is radiation-hard. It is not. Ask whether the system around it detects, contains, and recovers from the faults that radiation will cause, for the mission length you actually have.
"Radiation will kill a commercial chip in weeks"
This is the objection to answer first, because it is half true and the half that is true is specific.
Low Earth orbit exposes electronics to two broad kinds of radiation damage. Total ionising dose (TID) is the slow accumulation of charge in oxide layers, which shifts transistor thresholds and eventually degrades or kills a device. Single-event effects (SEE) are instantaneous events when a single energetic particle strikes the silicon. They come in several kinds: a single-event upset (SEU) flips a bit in memory or logic and does no permanent harm; a single-event functional interrupt (SEFI) puts a device into an unresponsive state that a reset clears; a single-event latch-up (SEL) creates a parasitic low-resistance path that draws destructive current unless power is removed quickly.
For a mission in a typical remote-sensing LEO orbit lasting one to three years, TID is usually the lesser worry for modern commercial parts. Published testing on popular embedded GPU modules found tolerance comfortably above what shielding of a few millimetres of aluminium leaves behind. One 2025 feasibility study for a commercial GPU-based module reported simulation results for a representative LEO mission in which a 10 mm aluminium shield reduced the dose well below the tested tolerance of the module under consideration. That shielding is simply the chassis and structure around the board in most small satellites, and it costs mass but not engineering.
The effects to design around are SEEs, and above all latch-up. Testing on embedded GPU families has reported that the GPU blocks themselves were comparatively resilient to single-event effects, while adjacent CPU subsystems, caches, and memory were more susceptible. That pattern has a practical implication: the accelerator may be less fragile than the host processor and memory that feed it.
A further wrinkle is the South Atlantic Anomaly, a region where the inner radiation belt dips closer to Earth and the particle flux a satellite sees rises sharply during each pass. A 2026 paper reporting in-orbit validation of a heterogeneous payload (an FPGA-based system-on-chip alongside an embedded GPU module) discusses this region as a primary contributor to the radiation environment in LEO. The same paper offers a finding that matters more than the radiation story: many of the faults observed in orbit traced to system integration and operational-protocol problems rather than isolated radiation events, and the campaign did not measure upset rates directly.
Effect | What it does | Reaction in the design |
Total ionising dose | Slow degradation of device parameters | Shielding, part screening, margin on mission life |
Single-event upset | Flips a bit in memory or logic; recoverable | Error-correcting memory, periodic scrubbing, output checking |
Single-event functional interrupt | Device hangs or misbehaves until reset | Hardware watchdog, supervised reset, health telemetry |
Single-event latch-up | Destructive high current unless power is cut | Current-sensing power switch that trips within microseconds to milliseconds, then power-cycles |
The short answer to the objection: weeks is wrong, years is plausible for LEO with shielding and the protections above, and the latch-up circuit is the line item that separates a payload that survives from one that does not.
A corrupted neural-network output looks exactly like a normal one.
"A bit flip will silently corrupt the answer"
This is the objection that deserves the most engineering attention, because it targets the thing that makes AI payloads distinctive: a corrupted neural-network result looks like a normal result.
Two separate things can flip. Weights and activations in memory change when a particle strikes the accelerator's on-chip memory or the external memory holding the model. Computation in flight changes when a strike hits a multiplier or accumulator during inference.
Neural networks tolerate some of this naturally. A flip in a low-order bit of a weight perturbs an output slightly; a flip in a sign or high-order bit can change it substantially. Quantised 8-bit integer models are generally less vulnerable to catastrophic single flips than floating-point models, where a flip in an exponent bit can change a value by orders of magnitude. That is one more reason that INT8 deployment is the norm on edge accelerators, apart from throughput.
Tolerance by luck is not a design. The standard system-level tools are cheap and effective:
Protect the model in memory. Store a checksum per model layer or per block, scrub periodically, and reload from protected storage on mismatch.
Redundant inference for high-consequence outputs. Run the same input twice (sequentially, or on two accelerators) and compare. If the results disagree, discard both and re-run, or flag the frame.
Plausibility checks on outputs. A classifier that suddenly reports 100 percent confidence on every frame, or a detector that returns hundreds of boxes, has a fault worth catching before the result is used.
Heartbeat and watchdog. The accelerator must return results within a time bound, and a supervising processor must be able to reset it independently.
A scrubber and a dual-run comparator look like this in outline:
// Supervisor-side health logic for an AI payload (simplified)
#include <stdint.h>
#include <stdbool.h>
#define N_BLOCKS 64
typedef struct {
uint32_t golden_crc[N_BLOCKS]; // computed at ground, stored in protected NVM
} model_manifest_t;
bool scrub_model(const model_manifest_t *m, const uint8_t *weights_ram, size_t block_size)
{
static uint8_t next = 0; // scrub one block per call to bound CPU use
uint32_t crc = crc32(weights_ram + next * block_size, block_size);
bool ok = (crc == m->golden_crc[next]);
if (!ok) request_reload_from_nvm(next); // reload only the damaged block
next = (next + 1) % N_BLOCKS;
return ok;
}
typedef struct { int32_t cls; int16_t conf_x1000; } result_t;
bool dual_run_agree(const uint8_t *img, result_t *out)
{
result_t a = infer(img), b = infer(img); // same input, run twice
bool agree = (a.cls == b.cls) &&
(abs(a.conf_x1000 - b.conf_x1000) <= CONF_TOL);
if (agree) *out = a;
else log_event(EVT_INFER_MISMATCH); // triggers re-run, then accelerator reset
return agree;
}
Redundancy costs throughput, so it is applied where a wrong answer is expensive (an alert that triggers a downlink or a manoeuvre) and relaxed where a wrong answer is cheap (a quick-look thumbnail). The expensive form, triple modular redundancy on a vote, is worth reserving for the few outputs that justify it.
"Commercial parts mean no heritage, and heritage is the whole game"
The heritage argument is serious: the space industry trusts what has flown. It has also changed as commercial parts accumulated flight history. The ESA mission Φsat-1, launched in 2020, carried a commercial vision processing unit (the Intel Movidius Myriad 2 family) and used it to run cloud screening onboard a small Earth-observation satellite: exactly the arithmetic from the opening of this post. A second class of accelerators, the edge tensor processing units, has been under radiation assessment in European programmes, and embedded GPU modules have appeared in flight computers and short-duration missions. A 2026 NASA small-satellite avionics survey lists a number of commercial-off-the-shelf AI computing boards that implement single-event mitigation around their accelerators, and describes onboard AI and machine-learning accelerators as a continuing trend.
Heritage also shows up in the standards. The European Cooperation for Space Standardization has a standard governing the use of commercial EEE (electrical, electronic, and electromechanical) components in space projects, ECSS-Q-ST-60-13C, which defines a risk-managed route for selecting, evaluating, and screening commercial parts. It exists because commercial parts are used and the industry wanted a repeatable method.
The practical conclusion: heritage is a gradient, not a gate. A mission with a tolerance for partial failure and a one-to-three-year life can accept less heritage than a mission carrying a crew or a billion-dollar observatory. The risk-management question is how much radiation testing and design protection the mission class justifies, not whether commercial parts are allowed.
"The power and thermal budget will not close"
This objection is the one most often correct about the wrong chip. A data-centre GPU is out of the question for a small satellite: such cards draw tens to hundreds of watts. A CubeSat or small satellite typically has a few watts to a few tens of watts for the entire payload, shared across imaging, processing, and communications, with solar power varying by orbit and attitude.
Accelerator class | Typical power | Representative role in orbit |
Vision processing unit (Myriad-class) | About 1.5 to 2 W | Cloud screening, simple classification; flown on a European demonstrator |
Edge TPU class | Low single-digit watts | INT8 CNN inference, with model conversion constraints |
Embedded GPU module | About 5 to 15 W | General AI workloads, short-to-medium missions, more software flexibility |
M.2 NPU-class accelerator on a small host | Few watts for the accelerator, plus host | Compact payload computers; one 2026 conference paper describes a COTS-centric payload around 12 W and 703.5 g delivering up to 32 TOPS |
Data-centre GPU | 20 to 70 W and above | Exceeds nanosatellite power; shown for context only |
Thermal design is a separate problem that surprises teams used to terrestrial products. In vacuum there is no convection. All heat must leave by conduction to the structure and by radiation. A board that runs at a comfortable temperature on a bench with a fan can overheat in orbit at the same dissipation. Eclipse cycles then swing the temperature by tens of degrees every 90 minutes or so in LEO, which is a mechanical fatigue problem for solder joints.
Duty cycling is the lever that closes most power budgets. A payload that wakes when the satellite is over a target region, runs inference on a burst of frames, writes results, and powers down can average a small fraction of its peak power. Plan the average, not the peak, and size the thermal path for the peak.
"Why not just downlink everything and process on the ground?"
Ground processing is simpler, and for many missions it remains the right answer. Onboard inference earns its place when downlink is the scarcest resource, which it usually is.
An illustrative calculation: a 12-megapixel sensor at 12 bits per pixel produces roughly 18 MB per raw frame. A ground-station pass lasting six minutes at an X-band rate of 50 Mbit/s moves about 2.25 GB, which is around 125 frames per pass. If cloud covers two-thirds of the frames on average, about 83 of those 125 frames are wasted on cloud. Onboard cloud screening that removes most of them roughly triples the useful imagery per pass without a single additional ground-station contact.
The second argument is latency. For time-critical events (a fire front, a vessel in a restricted area, a flood edge), waiting for a ground pass, downlinking, processing, and delivering an alert can take hours. Onboard detection can queue a prioritised, small message (coordinates, class, confidence, a thumbnail) for the first available link, including a low-rate crosslink or relay path. Small messages like that are exactly what satellite IoT links carry well, which connects this topic to the bearer discussion in our satellite IoT post.
The third argument is selection: sending only the interesting frames lowers storage, ground compute, and analyst time.
Onboard AI is a downlink-and-latency optimisation. Justify it with the megabytes it does not send and the minutes it saves, not with the novelty of running a network in orbit.
"How will you update a model that is 550 km away?"
Models improve, and a model frozen at launch will age. Uplink capacity is small and often available only in short windows, so model updates must be designed from the start.
A workable pattern has four parts. Keep two model slots (A and B) in protected non-volatile memory so a failed update never leaves the payload without a working model. Sign every update package and verify the signature on board before activation, which makes an update path safe against both corruption and misuse. Prefer small changes: quantised adapter layers, a replacement classification head, or a threshold table are kilobytes, while a full backbone may be megabytes and take many passes to send. And validate on the ground first: run the candidate model through the same fault-injection and accuracy tests as the original before it is queued for upload.
The security side deserves care. An onboard model update channel is a remote code path into a spacecraft payload. Signature verification with a key held in the payload's protected storage, replay protection with a monotonic version counter, and a rollback to the last known good slot on any failure are the minimum.
"Models trained on Earth will not match the sensor in orbit"
This objection is the most underrated, because it applies even when the hardware behaves perfectly. A model trained on images from one set of conditions meets different ones in orbit: illumination geometry, atmospheric haze, sensor ageing, and radiation-induced hot and dead pixels that accumulate on the imager over years. Calibration drifts. A cloud detector trained on one sensor's response may misjudge thin cirrus on another.
Mitigations are mostly about process:
Train and validate on imagery from the same sensor class, with the same calibration chain, wherever possible.
Include degraded imagery in the training set: simulated hot pixels, noise, and haze.
Build a ground-truth feedback loop: periodically downlink a random sample of frames together with the onboard decisions, compare, and track agreement over time. A slow decline in agreement is the first sign of sensor drift.
Keep confidence thresholds adjustable by uplinked command so that operators can retune behaviour without a model change.
The supervisor microcontroller, the latch-up switch and the watchdog are the architecture. The accelerator is a replaceable part inside it.
A Representative Payload, End to End
A composite, genericised, shows how the pieces combine. A small Earth-observation satellite carries an optional AI payload for onboard cloud screening and coarse change detection. The payload computer has a low-power, radiation-tolerant supervisor microcontroller; a commercial AI accelerator module with a host processor; error-correcting memory on the host side; a current-sensing latch-up protection switch on the accelerator's supply rail; and non-volatile storage holding two signed model slots.
The payload runs about 10 percent of each orbit, during passes over land. In a burst, the host loads frames from the imager, the accelerator runs the model, and the supervisor monitors a heartbeat from the host every second. If the heartbeat stops, the supervisor cuts and restores power to the accelerator rail; if the rail's current crosses a threshold, a hardware comparator opens the switch within microseconds, and the supervisor power-cycles the module after a short delay. Every inference pass is logged with a result code, and the supervisor keeps counters of resets, scrub corrections, and mismatches per orbit.
The design was verified in three stages. First, a bench fault-injection campaign flipped random bits in the model memory and measured the accuracy impact, which produced the scrub interval. Second, proton-beam testing at an accelerator facility exposed a flight-representative board to controlled particle fluxes while running inference, logging every upset, hang, and current spike, which sized the latch-up threshold and confirmed recovery behaviour. Third, thermal-vacuum and vibration testing exercised the mechanical and thermal path, including the solder joints that eclipse cycling will fatigue.
The telemetry from the first months in orbit would then answer the questions bench testing cannot: how many resets per week, how many scrub corrections, and whether upset counts rise during South Atlantic Anomaly passes. A design that counts these things can be improved; a design that does not is flying blind.
Fault Injection You Can Run This Week
The cheapest, most informative experiment for any team considering this work is a software fault-injection study on its own model. It takes an afternoon and tells you how fragile the model is to the kind of damage radiation does.
# bitflip_study.py -- measure accuracy loss vs. random weight bit flips (INT8 model)
import numpy as np
def flip_random_bits(weights_int8: np.ndarray, n_flips: int, rng) -> np.ndarray:
w = weights_int8.copy().view(np.uint8).ravel()
idx = rng.integers(0, w.size, n_flips)
bit = rng.integers(0, 8, n_flips)
w[idx] ^= (1 << bit).astype(np.uint8)
return w.view(np.int8).reshape(weights_int8.shape)
def run_study(model, dataset, flips_list=(0, 1, 10, 100, 1000), trials=20, seed=0):
rng = np.random.default_rng(seed)
base_w = model.get_weights_int8()
for n in flips_list:
accs = []
for _ in range(trials):
model.set_weights_int8(flip_random_bits(base_w, n, rng))
accs.append(model.evaluate(dataset)) # your own accuracy function
print(f"{n:5d} flips: mean acc {np.mean(accs):.3f} worst {np.min(accs):.3f}")
model.set_weights_int8(base_w)
Plot accuracy against flip count. A model whose accuracy barely moves until hundreds of flips is forgiving, and a modest scrub interval will keep it safe. A model with a cliff after ten flips needs protection on the layers that cause the cliff, and the study shows which layers those are if you inject per layer. Many teams find that the first and last layers dominate, which suggests protecting those layers more aggressively (extra redundancy or storing them in better-protected memory) while leaving middle layers to the scrub.
What a Beam Test Day Is For
Radiation testing sounds exotic, and the logic behind it is plain statistics. A beam facility fires a known flux of particles at your powered, running board, and you count what goes wrong. Dividing the count of events by the particle fluence (particles per square centimetre) gives a cross-section: the effective target area per event type. Once you have cross-sections for upsets, hangs, and latch-ups, you can predict how often each will occur in orbit by multiplying by the flux the orbit delivers.
# Event rate in orbit = cross-section x flux (units: events/s = cm^2 x particles/(cm^2 s))
# sigma_*: measured at the beam, per device, from test logs
# flux: from an environment tool for your orbit (e.g. ESA SPENVIS or CREME96),
# for the particle energies the beam test covered
def orbit_event_rate(sigma_cm2: float, flux_per_cm2_s: float) -> float:
return sigma_cm2 * flux_per_cm2_s
# Beam test log -> cross-section
def cross_section(events: int, fluence_per_cm2: float) -> float:
return events / fluence_per_cm2 # report with a confidence interval, not a point value
Use the numbers to set scrub intervals and reset policies: if the predicted hang rate is one per week averaged over an orbit but clusters into the South Atlantic Anomaly passes, a supervisor that expects hangs only during those windows can be tuned to recover faster in them. Two habits make a beam day productive. Run the same workload you intend to fly, because a board idling in a console produces different events from one running inference at full rate. And log timestamps, rail currents, and board temperature continuously so that any event can be tied to what the board was doing, not just that it happened.
Beam time at proton and heavy-ion facilities is limited and booked well in advance, so book it early and arrive with the test software already debugged. A beam day spent fixing a driver is an expensive way to find a bug.
How Much Qualification a Mission Class Justifies
The right depth of testing and protection depends on what is at stake, and the mission class sets it. A rough ladder, from least to most demanding, helps teams avoid both under-testing and gold-plating:
Mission class | Typical profile | Reasonable approach to a commercial accelerator |
Technology demonstrator | Weeks to months in LEO; failure is acceptable and informative | Bench fault injection, thermal-vacuum, vibration; accept untested radiation behaviour with telemetry to learn from it |
Commercial small-satellite payload | One to three years in LEO; payload loss degrades revenue but not the platform | Beam test on a representative sample, latch-up protection, supervisor, redundancy on critical outputs |
Government or institutional Earth observation | Three to five years or more; mission value is high | Full part evaluation per a commercial-parts standard, lot screening, extended beam and thermal campaigns, documented risk acceptance |
Beyond LEO or safety-critical | High radiation, no repair | Radiation-hardened or radiation-tolerant parts for the critical path, commercial parts only in carefully isolated roles |
Notice that the ladder describes how much evidence to gather, not whether to use a commercial part at all. The cost of a rung is mostly time and test budget, and the mistake worth avoiding is climbing a rung that the mission does not need.
When Onboard Inference Is the Wrong Choice
When the downlink is not the bottleneck. A mission with ample ground contact and small image volumes gains little from onboard AI and adds a payload to qualify.
When a wrong answer is costly and you cannot verify. Without a way to detect corrupted outputs, selection errors silently discard data you cannot get back. Keep raw frames in a ring buffer long enough for a ground check.
When the mission is short. For a two-week demonstration, simpler hardware with no protection circuits may be acceptable, and the engineering effort should go into the science instead.
When the team has no radiation test path. A payload flown untested on a mission that matters is a gamble, and gambling is only appropriate when failure is cheap.
When model updates cannot be controlled. An unsigned or unverified update path in orbit is a hazard in itself.
Starting a Payload Prototype
Fix the mission numbers. Orbit altitude and inclination, mission length, payload power average and peak, mass, and thermal path. Everything else is derived from these.
Pick the accelerator class by power and model support, then check that your model's operators compile cleanly on its toolchain (see our accelerator vetting checklist) before any radiation work.
Run the bit-flip study on your model and set a scrub interval and protection plan from the results.
Design the supervisor first. The radiation-tolerant microcontroller, the watchdog, the latch-up switch, and the power-cycle logic are the architecture. The accelerator is a replaceable part inside it.
Define telemetry before hardware is built: reset counts, scrub corrections, inference mismatches, rail current peaks, board temperature, and orbit position for each event.
Plan the test campaign: proton or heavy-ion beam time for SEE characterisation, thermal-vacuum cycling, vibration, and a long-duration soak at temperature. Beam time is scarce and booked months ahead.
Plan the update path with two slots, signing, rollback, and ground validation, and test it end to end.
The Question to Carry Forward
"Is it radiation-hard?" is the wrong question and it is the one most people ask first. The question that survives contact with a real mission is how many different ways the payload can be wrong, and what it does about each one. A commercial accelerator inside a supervised, protected, observable system can serve a short LEO mission well. A commercial accelerator left to fend for itself will teach its builders about the South Atlantic Anomaly the hard way.
EurthTech is an engineering-first product design and embedded systems company with a development center in Hyderabad. To discuss a project, write to connect@eurthtech.com or see https://www.eurthtech.com/case-studies.
Comments