The market for radiation-hardened processors is not large, and the vendors who serve it are not investing at the pace of commercial semiconductor development. That's an economic reality, not a criticism — the total available market for space-grade silicon is a fraction of the commercial market, and the qualification overhead for producing a certified rad-hard part is substantial. The result is a performance gap between what's available in space-qualified silicon and what's available in commercial off-the-shelf processors that has widened significantly over the past decade, and shows no sign of narrowing.
For hardware engineers designing compute systems for orbit, this gap is not an abstraction. It's a design constraint that shapes every decision about what can actually run on a satellite — and how to close the gap between the performance requirements of useful onboard applications and the performance available from qualified hardware.
The Space-Grade Processor Landscape
The established space-grade processor families — devices produced via radiation-hardened-by-process (RHBP) or radiation-hardened-by-design (RHBD) techniques — have served the space industry reliably for decades. For applications where guaranteed single-event latch-up (SEL) immunity, full total ionizing dose (TID) tolerance across deep-space radiation environments, and long-term reliability with no acceptable failure modes are the requirements, these parts earn their substantial price premium.
The performance characteristics of these devices, however, reflect the state of the underlying process nodes at the time of their qualification. Qualifying a new radiation-hardened processor requires extensive testing — TID testing to characterize threshold voltage shifts and leakage behavior, heavy-ion and proton testing to characterize SEU cross-sections, and qualification testing for latch-up sensitivity. This process takes years and costs millions. As a result, the radiation-hardened processor catalog tends to lag commercial silicon generations by years to a decade, operating at clock frequencies and with micro-architectural capabilities that commercial silicon left behind long ago.
For a mission requiring significant compute throughput — running a neural network inference pipeline, for example — the performance available from a space-qualified RHBP processor is often inadequate. The math doesn't close: the inference latency requirement and the available FLOPS don't align. The designer has a problem that RHBP silicon alone cannot solve.
COTS in LEO: The Risk Profile Is Not Uniform
Commercial off-the-shelf processors fly in orbit. This is no longer controversial. The CubeSat community has operated commercial silicon in LEO environments for years, and the data on SEU rates in low Earth orbit at low inclinations is reasonably well-characterized. For commercial LEO missions with planned operational lives of two to five years, at altitudes below 600 km and avoiding the South Atlantic Anomaly as much as orbital mechanics permit, the accumulated TID on unshielded commercial silicon is modest and the SEU event rate — while not zero — is manageable with software-level fault tolerance and EDAC on critical memory.
We're not saying COTS silicon is equivalent to space-grade silicon in all environments — it is clearly not. Deep-space missions, high-altitude orbits, and missions passing through the inner radiation belts regularly face dose rates and SEE environments that would degrade COTS devices to unacceptable reliability levels within months. The appropriate radiation tolerance strategy is orbit-dependent, mission-life-dependent, and consequence-of-failure-dependent. There is no single correct answer.
What has changed is that the risk calculus for COTS in appropriate LEO environments has become well enough understood that informed engineering tradeoffs are possible. A mission team that understands their orbit, their TID exposure estimate, their SEU event rate expectation, and their acceptable risk tolerance can make a defensible decision to incorporate COTS compute — with appropriate mitigation strategies — rather than accepting the performance limitations of the qualified space-grade catalog.
Mitigation Strategies That Actually Work
Using COTS processors in orbit doesn't mean abandoning reliability engineering. It means applying reliability engineering at the system level rather than the device level. The strategies that make COTS compute viable in LEO include several that are well-established in the smallsat engineering community.
Error detection and correction on all SRAM used for program code and data is essential. Modern FPGA fabrics and microcontrollers can implement EDAC relatively efficiently; the question is whether the EDAC coverage extends to all memory paths that could corrupt program execution, not just the obvious data buffers. Triple modular redundancy (TMR) for critical logic paths — implemented in FPGA fabric or as a software pattern for critical state variables — provides protection against SEU-induced bitflips in sequential logic.
Watchdog supervision is necessary but not sufficient. A watchdog that detects a processor lockup and resets the board protects against the catastrophic failure case. It does not protect against soft errors — bit flips that change a register value without causing an immediate fault. Detecting soft errors requires either EDAC, periodic memory scrubbing, or application-level sanity checks on computed values. The appropriate combination depends on the criticality of the affected function and the acceptable consequences of an undetected error.
Power supply protection against SEL is a distinct concern. COTS processors that are not latch-up immune require current limiting and latch-up detection on their power supply rails. A latch-up event that causes sustained high current draw will damage an unprotected device; with appropriate current monitoring and power cycling capability, the same event results in a reset and recovery. This is a board-level design requirement, not a processor selection criterion per se.
The Performance-Reliability Design Space
The practical design space for orbital compute today involves selecting from a spectrum rather than a binary choice. At one end: RHBP processors with full qualification, lowest SEU cross-section, highest TID tolerance, lowest performance. At the other: high-performance commercial ML accelerators with no radiation characterization, maximum throughput, unknown on-orbit behavior. In between: a range of options including radiation-characterized COTS processors, commercial FPGAs with known SEU cross-sections (and EDAC-implementable architecture), and hybrid approaches that use a small RHBP device for supervisory and safety-critical functions while delegating compute-intensive processing to a COTS accelerator.
For the in-orbit edge compute use case — running ML inference pipelines at the power and performance levels needed to classify imagery or run sensor fusion in real time — the fully space-graded path does not currently provide viable performance. The hardware to close that gap requires the hybrid approach: system-level mitigation on top of commercially performant silicon. As the smallsat industry accumulates on-orbit experience with characterized COTS devices, the risk models for this approach will become more precise, and the design space will become more accessible to mission teams without deep radiation effects expertise in-house.
The performance gap between commercial and space-grade silicon is not closing from the space-grade side. It will be closed, for the relevant use cases, by engineering better system-level mitigation around commercially capable hardware. That's the direction the industry is moving, and hardware designed for orbit-native compute needs to be designed with that reality in mind.
