Radshield: Software Radiation Protection for Commodity Hardware in Space

Haoda Wang, Steven Myint, Vandi Verma, Yonatan Winetraub, Junfeng Yang and Asaf Cidon

Cheap satellites increasingly fly ordinary off-the-shelf chips instead of costly radiation-hardened ones, but space radiation can short-circuit those chips into permanent failure or flip a single bit and silently corrupt a result; this paper (Columbia and NASA JPL) builds Radshield, a pure-software defense that catches the short-circuit by watching for a tiny anomalous rise in the chip's current draw during quiet moments it deliberately creates, and catches the bit-flip by running the workload redundantly in a way that stays power-efficient and still detects corruption even in the CPU's cache or pipeline — and it is already flying on missions in low-earth orbit and deep space.

The argument in one glance

Problem

Cheap satellites fly ordinary chips that radiation can destroy or silently corrupt

Launch costs have collapsed — putting a kilogram into low-earth orbit fell from tens of thousands of dollars in the 1980s to around a thousand today — so orbit is filling with inexpensive satellites, often flying commodity off-the-shelf chips to get the performance and cost that specialized parts cannot. The problem is that those commodity chips have none of the radiation hardening that traditional, expensive, decades-behind space chips carry, so space radiation hits them unprotected. Two radiation faults are especially common and costly. A single-event latchup is a radiation-induced short-circuit inside the chip: it makes the device draw excess current and overheat, and left unchecked it permanently destroys the chip — several of the authors' own small satellites have been lost this way. A single-event upset is a transient charge that flips a single bit, silently corrupting a computation's result, the kind of error traced to faults on a Mars rover. Cheap hardware in a harsh environment needs protection, but adding rad-hardened silicon defeats the point.
What people did

Threshold the current draw, and re-run the computation many times

The conventional software defenses are simple. For short-circuits, watch the device's total current draw and raise an alarm when it crosses a fixed threshold. For bit-flips, run the whole computation several times and compare the results — if the runs disagree, a bit was likely flipped.
Why it fell short

Thresholds cannot tell radiation from a busy CPU, and re-running wastes scarce power

Both defenses are too crude for a power- and thermally-starved satellite. A latchup raises the current draw only slightly, and a busy CPU's normal power scaling swings the current far more than that, so a fixed threshold cannot distinguish a radiation short-circuit from an ordinary workload spike — it either misses real latchups or fires constantly on false alarms. And re-running the entire computation several times multiplies the energy consumption and heat exactly where a spacecraft has the least to spare, straining the tight thermal and power envelopes that define these missions. Running the copies naively in parallel to save time does not help either, because they share the CPU cache, so one radiation-corrupted cache line silently poisons every copy at once and the error slips through undetected.
This paper's idea

Model the quiet current signature, and duplicate execution efficiently

Radshield is a pure-software defense with two matched components. Against latchups, its detector stops treating the chip as a black box: it uses performance counters to predict what the current draw should be for the current workload, and to find or deliberately inject brief idle moments where that prediction is cleanest, then flags the tiny excess current a latchup adds against that predicted baseline. Against bit-flips, it runs the workload redundantly but in a CPU- and memory-efficient way that deliberately keeps the copies from sharing the same cached data at the same time, so a single corruption cannot fool all copies, catching silent data corruption even when it strikes the CPU's cache or pipeline. It is deployed on real missions in low-earth orbit and deep space.

Why this problem is worth solving

The two radiation faults Radshield targets are the ones that actually end or endanger missions.

Space radiation striking a chip causes distinct failure modes; two dominate operators’ concerns. A single-event latchup is a localized short-circuit triggered inside the semiconductor: the affected region begins conducting far more current than it should, which draws excess power and generates heat, and if the device is not power-cycled the overheating permanently damages the chip. Latchups are mission-ending — several small satellites have been destroyed by them. A single-event upset is a transient charge deposited by a particle that flips a single bit in memory, a register, or logic; unlike a latchup it does no permanent damage, but it silently corrupts whatever value that bit held, producing silent data corruption whose wrong answer looks entirely legitimate. Upsets have been traced to real errors on spacecraft including Mars rovers, and they can, for example, sharply degrade the accuracy of an onboard machine-learning model. Traditional space hardware is radiation-hardened with redundant transistor structures to resist both, but that hardening is expensive and lags commercial chips by many years, which is exactly why cheap missions flying commodity parts need a way to get the protection in software instead.

The reason a software defense is even conceivable is that these faults leave measurable, if subtle, fingerprints.

On a commodity chip with no radiation hardening, the only tools a defender has are the ordinary facilities the hardware and operating system already expose — the device’s current-draw sensor, performance counters that report cycles and instructions, and multiple CPU cores. A latchup shows up as a small anomalous increase in current draw, but it is small relative to the large, legitimate current swings a workload causes as the CPU scales power up and down, so detecting it means separating the tiny radiation signal from the loud workload noise. An upset shows up only as a disagreement between what the program computed and what it should have computed, which is why redundancy — computing the same thing more than once and comparing — is the classic way to catch it, at the cost of extra work. The engineering challenge is doing both within the brutal constraints of a satellite: a fixed power budget, a hard thermal limit, and a modest processor, where every extra watt of detection overhead is a watt not spent on the mission. Making radiation protection cheap enough in energy and compute to run on the same commodity hardware it protects is the whole game.

What people did before, and where it broke

Fly radiation-hardened hardware. Use specialized, redundant, rad-hard chips designed to withstand ionizing radiation. Where it broke. They are expensive and lag commercial chips by decades in performance, which defeats the cost and capability advantages that make commodity-chip constellations attractive in the first place.
Black-box current-draw thresholds for latchups. Watch total current draw and trip an alarm past a fixed threshold. Where it broke. A latchup’s current increase is small, while a busy CPU’s normal power scaling swings current far more, so a threshold cannot separate radiation from workload — it misses real latchups or floods operators with false alarms.
Black-box current spikes with a simple model. Add a model over current draw to catch latchup-induced spikes. Where it broke. Treating system resources as a black box still ignores that the current is dominated by what the workload is doing, so without knowing the compute load it cannot attribute a rise to radiation versus computation.
Brute-force re-execution for upsets. Run the whole computation several times sequentially and compare, flagging divergence. Where it broke. It multiplies energy consumption and heat on a spacecraft that has neither to spare; and naive parallel copies share the CPU cache, so one corrupted cache line poisons every copy identically and the error goes undetected.
The gap. No software defense both detected latchups by accounting for the workload’s own current draw rather than thresholding a black box, and detected upsets with redundancy efficient enough for a satellite’s power and thermal limits while still covering corruption in the shared cache and pipeline. Providing both, cheaply, on commodity hardware is what Radshield does.

How Radshield works

Two matched software defenses for two radiation faults

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Catch a bit-flip with redundancy, but make the redundancy cheap and cache-aware. The classic way to detect silent corruption is to compute something more than once and compare, and Radshield keeps that principle but fixes its two costs. First, brute-force sequential re-execution multiplies energy and heat, so Radshield runs the copies in parallel across the multi-core CPUs commodity satellites now carry. Second, and more subtly, naive parallel copies share the CPU cache, so a single radiation-corrupted cache line would poison every copy identically and the comparison would see agreement, not error — a silent failure of the detector itself. Radshield’s redundancy component solves this by automatically scheduling the copies, using the data-access patterns of common onboard algorithms, so that no two copies touch the same cached data at the same moment, which is what lets it catch corruption even in the shared cache and pipeline rather than being blinded by it. Protecting software from silent hardware corruption by running redundant computation and reconciling the results is the same fault-tolerance stance the hardware-silent-error work covered elsewhere on this site takes, guarding applications against corruption the hardware gives no other warning of.

Detect a latchup by modeling the current the workload should draw, not by a raw threshold. The reason a fixed current threshold fails is that it treats the chip as a black box, but the current draw is overwhelmingly determined by what the workload is doing, and that legitimate variation dwarfs the tiny extra current a latchup adds. Radshield’s detector opens the box: it reads performance counters that report the compute load and trains a model to predict the current those counters should produce, so it can subtract the workload’s own contribution and see the small radiation-induced excess that remains. To make that subtraction as clean as possible, it seeks out — and, during long jobs, deliberately creates — brief idle windows where the workload’s current is low and predictable, and checks for the anomalous excess there. Learning a model of a system’s normal hardware behavior from its own performance counters so that a small abnormal deviation can be spotted against the predicted baseline is the same on-node-learning approach the safe-on-node-learning work covered elsewhere on this site is built on, turning the machine’s own low-level signals into a detector for conditions a coarse threshold would miss.

Get reliability from cheap commodity parts instead of paying for hardened silicon. The overarching bet is that a mission can fly ordinary, capable, inexpensive chips and recover the reliability that expensive rad-hardened hardware would have provided, purely in software. That only works if the software protection is itself cheap enough to run on the constrained device it protects, which is why both components are tuned for minimal overhead — a couple of percent for latchup detection, and redundancy that is up to thirty-five times more power-efficient than the prior state of the art at detecting corruption. Extracting dependable operation from cheap, individually-unreliable infrastructure by adding a smart software layer, rather than buying costly reliable hardware, is the same economic move the reliable-low-cost-computing work covered elsewhere on this site makes, building trustworthy service on top of inexpensive, failure-prone resources so the savings survive.

Following a radiation event through Radshield

A latchup and an upset, each caught in software

A trace, from the paper, of how Radshield's two components handle the two radiation faults on a commodity satellite chip.

Step 1 of 5

The workload runs, drawing a workload-dependent current

The spacecraft processor executes its jobs, and its current draw rises and falls with the compute load as the CPU scales power. Radshield's detector continuously reads performance counters and uses its model to predict the current these counters imply, tracking what the draw should be.

The workload's normal current variation is large — far larger than a latchup's signature — which is why a raw threshold cannot work.

Why it works

Modeling the workload’s current exposes the radiation signal a threshold hides. A latchup’s current increase is tiny next to the workload’s own swings → but predicting the expected current from performance counters subtracts the workload’s contribution → so the small radiation-induced excess becomes visible, catching latchups at a 0.02 percent false-positive rate.
Injected idle windows make the prediction cleanest. Even a good model is noisiest when the CPU is busy → but finding and deliberately creating idle moments gives a low, predictable baseline → so the anomalous current is measured where it stands out most, not buried in workload noise.
Parallel redundancy avoids the energy blowup of re-running. Running the whole computation several times sequentially multiplies energy and heat a satellite cannot spare → but running the copies in parallel across cores keeps the wall-clock and energy cost down → so redundancy fits the power and thermal envelope.
Cache-aware scheduling stops one fault from fooling every copy. Naive parallel copies share the cache, so a corrupted line poisons all identically and the comparison sees false agreement → but scheduling copies so they never share cached data at once keeps corruption isolated to one copy → so silent corruption in the cache or pipeline is detected, not agreed upon.
Cheap enough to run on the hardware it protects. Reliability from software is pointless if it exhausts the device → but roughly two percent overhead for latchup detection and up to thirty-five-times-better power efficiency than prior redundancy keep the cost low → so the protection actually runs on real commodity missions in orbit and deep space.

What it costs (trade-offs and scope)

The detector needs a model calibrated to the device. Predicting current from performance counters requires training a model for the specific hardware and workloads, and its accuracy governs the false-positive and false-negative rates; a poorly-fit model, or a workload far outside what it saw, could miss a latchup or raise false alarms, so the approach depends on good calibration and representative behavior.
Injecting idle windows perturbs the workload. Creating clean measurement moments during long jobs means briefly pausing useful work; the overhead is small (about two percent), but it is real, and workloads with no tolerance for such micro-pauses, or that never idle, give the detector less to work with.
Redundancy still costs extra compute and energy. Even efficient, cache-aware modular redundancy runs the computation multiple times, so it consumes more energy and cores than a single run; it is far cheaper than brute-force re-execution and prior schemes, but it is not free, and it is applied where the extra assurance is worth the cost.
The scheduling exploits assumed data-access patterns. Keeping copies from sharing cached data relies on the data-access patterns of common spacecraft algorithms; workloads whose access patterns do not fit those assumptions may parallelize less cleanly or need care to keep the copies isolated, so the efficiency is strongest for the targeted class of onboard computations.
It targets two fault types, not all radiation effects. Radshield addresses single-event latchups and single-bit upsets, the two most common and costly cases; other radiation effects, multi-bit upsets, or total-dose degradation are outside its stated scope, and it complements rather than wholly replaces hardware and system-level fault tolerance.

The evaluation

Protecting a commodity satellite chip from radiation

Property	Rad-hardened hardware	Threshold plus re-run	Radshield
Cost and capability of the chip
Distinguishes a latchup from a busy CPU	Hardware handles it
Latchup false-positive rate	n/a
Catches corruption in shared cache or pipeline	By hardware redundancy
Power efficiency of corruption detection	n/a

From the paper's evaluation. Radshield gives commodity space chips software radiation protection: detecting single-event latchups at a 0.02 percent false-positive rate with about 2 percent overhead, and detecting single-event-upset silent data corruption (including in the cache and pipeline) 1.4 to 35.5 times more power-efficiently than state-of-the-art protection. It is deployed on real missions in low-earth orbit and deep space.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The contribution is a practical, deployed software defense that lets cheap commodity chips survive space radiation without rad-hardened silicon, targeting the two faults operators care about most. For latchups, Radshield replaces a black-box current threshold with a model that predicts the workload’s own current draw from performance counters and checks for the small radiation-induced excess in clean idle windows, catching latchups at a 0.02 percent false-positive rate for about two percent overhead. For upsets, it runs the workload redundantly across cores while scheduling the copies so they never share cached data at once, so it catches silent corruption even in the cache and pipeline, one-and-a-half to thirty-five times more power-efficiently than prior protection. Read that within its scope. The latchup detector needs a model calibrated to the device and representative workloads, and injecting idle windows briefly perturbs execution; the redundancy still costs extra compute and energy, and its efficiency leans on the data-access patterns of common spacecraft algorithms; and Radshield addresses single-event latchups and single-bit upsets specifically, complementing rather than replacing other fault tolerance. Its strongest validation is that it is not a paper prototype but is flying on real missions in low-earth orbit and deep space.

Background

Why cheap chips in space is a new and growing problem

It helps to see why software radiation protection matters now in a way it did not before. For most of the space age, the answer to radiation was simply expensive: fly custom, radiation-hardened processors, accept that they cost a fortune and lag commercial chips by many years, and design missions around a handful of extremely reliable, extremely costly computers. That calculus made sense when a launch itself cost a fortune and satellites were few, large, and bespoke. Collapsing launch costs upended it. When it is cheap to reach orbit, it becomes economical to fly many small, inexpensive satellites in constellations, and the pressure shifts to minimizing the unit cost of each one — which means flying the same capable commodity chips that phones and datacenters use, precisely the chips that have no radiation hardening. So a hardware problem the field had solved by spending money reappears as a systems problem to be solved by software, at exactly the moment thousands of vulnerable satellites are going up. That world, where cheap access to orbit turns satellites into a mass-produced commodity whose design is an engineering optimization rather than a bespoke marvel, is the same one the nanosatellite-constellation-design work covered elsewhere on this site inhabits, treating small, numerous, inexpensive spacecraft as the unit of a modern space system. Radshield is what keeps those cheap chips alive and correct once they are up there.

If you remember only three things

1. Collapsing launch costs have filled orbit with cheap satellites flying commodity off-the-shelf chips that, unlike expensive radiation-hardened hardware, have no protection against space radiation; the two most common and costly faults are single-event latchups (radiation-induced short-circuits that overheat and permanently destroy the chip) and single-event upsets (transient charges that flip a single bit and silently corrupt data), and the standard software defenses — black-box current thresholds and brute-force re-execution — either cannot tell radiation from a busy workload or multiply the energy and heat a thermally-constrained satellite cannot spare.
2. Radshield is a pure-software defense with two matched components. Its latchup detector opens the black box: it predicts the current draw the workload should produce from performance counters, finds or deliberately injects brief idle windows where that prediction is cleanest, and flags the small radiation-induced excess current against the predicted baseline, catching latchups at a 0.02 percent false-positive rate for about 2 percent overhead. Its upset defense runs the workload redundantly across cores but automatically schedules the copies, using the data-access patterns of common spacecraft algorithms, so they never share the same cached data at once — which lets it catch silent data corruption even when it strikes the shared cache or the CPU pipeline, where naive parallel copies would all be poisoned identically.
3. Radshield gives commodity chips the reliability that costly rad-hardened silicon would provide, cheaply enough to run on the constrained hardware itself: its corruption detection is 1.4 to 35.5 times more power-efficient than state-of-the-art protection, and it is deployed on real missions in low-earth orbit and deep space. Its scope is single-event latchups and single-bit upsets, its latchup detector depends on a model calibrated to the device, and its redundancy still costs extra compute and leans on assumed data-access patterns, so it complements rather than replaces other fault tolerance.

Check yourself

Check your understanding

1. What two radiation faults does Radshield target, and why do they matter?
2. Why does a fixed current-draw threshold fail to detect latchups, and what does Radshield do instead?
3. How does Radshield detect single-event upsets efficiently, and why is cache-aware scheduling essential?
4. What did Radshield achieve, and what are its limits?

Sources

The paper is “Radshield: Software Radiation Protection for Commodity Hardware in Space” by Haoda Wang (Columbia University), Steven Myint and Vandi Verma (Jet Propulsion Laboratory, California Institute of Technology), Yonatan Winetraub (Aptos Orbital), Junfeng Yang, and Asaf Cidon (Columbia University), published at ASPLOS 2026, DOI 10.1145/3760250.3762218.

This explainer is written from the full text of the authors’ copy of the paper. Everything above comes from the paper’s own sections: the introduction motivating commodity chips on cheap satellites (launch costs falling from tens of thousands of dollars per kilogram to low-earth orbit in the 1980s to around a thousand today, driving constellations of inexpensive satellites flying off-the-shelf chips that lack the radiation hardening of expensive, decades-behind specialized hardware); the two targeted radiation faults (single-event latchups as localized short-circuits that overheat and permanently damage the chip, with several of the authors’ small satellites destroyed by them, and single-event upsets as transient single-bit flips causing silent data corruption, traced to errors on Mars rovers and able to drop a model’s accuracy); the limitations of prior defenses (black-box current-draw thresholds that cannot distinguish a latchup from workload-driven power scaling, and brute-force sequential re-execution that multiplies energy and heat); the Instantaneous Latchup Detector (using OS-visible performance counters representing per-core compute load to predict current draw with a lightweight machine-learning model, finding naturally idle periods and injecting short idle windows for a clean measurement environment, and flagging a persistent excess above roughly a fraction of an amp, at a 0.02 percent false-positive rate with about 2 percent overhead); the Efficient Modular Redundancy component (a runtime and programming model managing three-way modular redundancy and checkpointing that parallelizes copies across cores while scheduling them, based on spacecraft algorithms’ data-access patterns, so they do not access the same shared-cache data at the same time, catching silent data corruption even in the cache and pipeline); and the evaluation reporting the 0.02 percent latchup false-positive rate, the roughly 2 percent overhead, the 1.4-to-35.5-times power-efficiency improvement over state-of-the-art protection for detecting silent data corruption, and deployment on real missions in low-earth orbit and deep space.