However, the true cost of rad hard components is not the sticker price. It is the single-source, long-lead supply chain; the specialized software and firmware skills which may be 10 years obsolete; and the relatively low computing power. Where they start making sense is when you have a several-hundred-million $$ GEO or deep space mission; but I suspect with computing power so ubiquitous and the easy reusability of modular software the software-heavy approach will start to make more sense there as well. Keep in mind that permanent radiation damage is relatively rare; the much more common scenario is temporary latchup which is cleared by a power cycle or reboot of the affected chip. As long as your long tail time between failures is slower than your software’s ability to fix those failures and re-establish system state and maintain normal operations, you are okay. As long as you have enough computing overhead devoted to healing thyself, and are somewhat careful about choosing relatively rad-resistant technologies and screening your designs, software should be able to keep up.

Things get a little tougher for long-duration missions and missions to Jupiter or the inner solar system where you can expect higher and more energetic total exposures. At some point the likelihood of permanent damage to memory locations or processor switches gets large and then software is not nearly as well-developed to deal with it. At that point you need dynamic memory allocation which is usually considered a no-no on critical applications, and you may need on-the-fly re-architecting of FPGA firmware, which to my knowledge does not exist outside maybe some graduate theses. I’m not sure how you could even handle it in a microprocessor or a PROM aside from massive redundancy. So it probably makes sense for some components to remain rad-hard for those mission types, at least until flexible architectures and reactive software is sophisticated to compensate for “must not fail” failure points.

At the hardware end you can use SOI, core memory, BJT-based circuits and other forms that are less susceptible to ionizing radiation in the first place. At the software end you have programs to prevent effects from propagating (memory scrubbers), and programs to recover (lockstep processors, redundant cores). In general the hardware side will reduce the frequency, but you’ll always need some kind of software solution because eventually you’ll get hit.

I think most of the mammals in the industry go heavy on the software side, and the math is fairly compelling. With the pace of memory and processor development and mass production, a rad-hard architecture might be 100+ times slower for a given cost than a COTS part. Even if you devote 90% of your processor load to memory scrubbing, running checksums, watchdogging your co-processors, and coordinating between, say, 3 redundant cores in order to get comparable reliability to a rad-hard architecture, you come out ahead. The tradeoff is software complexity, but in return you’re getting a non-bottlenecked supply chain with lots of well-understood parts.

If you make a few fairly painless choices (careful about the type of RAM and ROM you use, upscreening from a handful of candidates) you can get your mean time between failures to a level that software can manage, certainly for LEO and probably for GEO/MEO/deep space missions that don’t go to Jupiter or suffer direct hits from solar flares.

It’s also instructive to see how nature does it. Deinococcus radiodurans has some hardware protection (manganese antioxidants) but mainly relies on redundancy and software (multiple copies of genome and advanced repair mechanisms).