NASA有一篇关于防辐射软件的论文。它描述了三个主要任务：

定期监控内存中的错误，然后清除这些错误，稳健的错误恢复机制，以及如果某些东西不再工作，重新配置的能力。

请注意，内存扫描速率应该足够频繁，很少发生多位错误，因为大多数ECC内存可以从单位错误而不是多位错误中恢复。

稳健的错误恢复包括控制流传输（通常在错误发生之前的某个点重新启动流程）、资源释放和数据恢复。

他们对数据恢复的主要建议是，通过将中间数据视为临时数据，避免数据恢复的需要，以便在错误发生之前重新启动也能将数据回滚到可靠状态。这听起来类似于数据库中的“事务”概念。

他们讨论了特别适用于面向对象语言（如C++）的技术。例如

用于连续内存对象的基于软件的ECC契约编程：验证先决条件和后决条件，然后检查对象以验证其是否仍处于有效状态。

而且，正是如此，美国宇航局（NASA）已将C++用于火星探测器等重大项目。

C++类抽象和封装支持多个项目和开发人员之间的快速开发和测试。

他们避免了某些可能产生问题的C++特性：

例外情况模板Iostream（无控制台）多重继承运算符重载（new和delete除外）动态分配（使用专用内存池并放置新的以避免系统堆损坏的可能性）。

你问的是一个非常复杂的话题——不容易回答。其他答案是可以的，但它们只涵盖了你需要做的所有事情的一小部分。

正如在评论中看到的，不可能100%解决硬件问题，但是使用各种技术很可能减少或解决这些问题。

如果我是你，我会创建最高安全完整性级别（SIL-4）的软件。获取IEC 61513文件（适用于核工业）并遵循该文件。

如何运行应用程序的许多实例。如果崩溃是由于随机的内存位变化造成的，那么你的一些应用程序实例很可能会通过并产生准确的结果。（对于有统计背景的人来说）很容易计算出在给定的比特翻转概率下需要多少个实例才能实现所希望的最小总体错误。

以下是一些想法和想法：

更创造性地使用ROM。

在ROM中存储任何可以存储的东西。不要计算东西，而是将查找表存储在ROM中。（确保编译器将查找表输出到只读部分！在运行时打印内存地址以进行检查！）将中断向量表存储在RAM中。当然，运行一些测试以查看ROM与RAM相比的可靠性。

为堆栈使用最好的RAM。

堆栈中的SEU可能是最可能的崩溃源，因为它是索引变量、状态变量、返回地址和各种类型的指针通常存在的地方。

执行计时器滴答声和看门狗计时器例程。

您可以在每一次计时器计时时运行一个“健全性检查”例程，以及一个看门狗例程来处理系统锁定。您的主代码还可以周期性地增加一个计数器以指示进度，而健全性检查例程可以确保发生了这种情况。

在软件中执行纠错代码。

您可以为数据添加冗余，以便能够检测和/或纠正错误。这将增加处理时间，可能会使处理器长时间暴露在辐射中，从而增加出错的机会，因此您必须考虑权衡。

记住缓存。

检查CPU缓存的大小。您最近访问或修改的数据可能位于缓存中。我相信您可以禁用至少一些缓存（以较大的性能代价）；你应该试试看缓存对SEU的敏感性。如果缓存比RAM更硬，那么您可以定期读取和重新写入关键数据，以确保它保留在缓存中并使RAM恢复正常。

巧妙地使用页面错误处理程序。

如果将内存页标记为不存在，CPU将在您尝试访问它时发出页面错误。您可以创建一个页面错误处理程序，在处理读取请求之前进行一些检查。（PC操作系统使用此功能透明地加载已交换到磁盘的页面。）

对关键的事情使用汇编语言（可能是所有事情）。

使用汇编语言，您知道寄存器中的内容和RAM中的内容；你知道CPU使用的是什么特殊的RAM表，你可以用迂回的方式来设计，以降低风险。

使用objdump实际查看生成的汇编语言，并计算每个例程占用的代码量。

如果你使用的是像Linux这样的大型操作系统，那么你就是在自找麻烦；有太多的复杂性和太多的事情要出错。

记住这是一场概率游戏。

一位评论者说

你为捕捉错误而编写的每一个例程都会因同样的原因而失败。

虽然这是真的，但检查例程正确运行所需的（例如）100字节代码和数据中发生错误的机会要比其他地方发生错误的几率小得多。如果你的ROM非常可靠，并且几乎所有的代码/数据都在ROM中，那么你的可能性就更大了。

使用冗余硬件。

使用具有相同代码的两个或更多相同硬件设置。如果结果不同，应触发重置。对于3个或更多设备，您可以使用“投票”系统来尝试确定哪一个已被破坏。

您可能还对有关算法容错的丰富文献感兴趣。这包括旧的赋值：编写一个排序，当恒定数量的比较将失败时（或者，更糟糕的版本，当失败的比较的渐近数量为n次比较的log（n）时），正确地对其输入进行排序。

开始阅读黄和亚伯拉罕1984年的论文《矩阵运算的基于算法的容错》。他们的想法隐约类似于同态加密计算（但实际上并不相同，因为他们正在尝试在操作级别进行错误检测/纠正）。

该论文的一个较新的后代是Bosilca、Delmas、Dongarra和Langou的“基于算法的容错应用于高性能计算”。

首先，围绕失败设计应用程序。确保作为正常流程操作的一部分，它需要重置（取决于您的应用程序和软或硬故障类型）。这很难做到完美：需要某种程度的事务性的关键操作可能需要在组装级别进行检查和调整，以便关键点的中断不会导致不一致的外部命令。一旦检测到任何不可恢复的内存损坏或控制流偏差，就立即失败。如果可能，记录故障。

第二，如果可能，纠正腐败并继续下去。这意味着经常检查和修复常量表（如果可以的话，还包括程序代码）；可能在每个主要操作之前或在定时中断上，并将变量存储在自动校正的结构中（同样在每个主要运算之前或在计时中断上，从3中获得多数票，如果是单个偏差，则进行校正）。如果可能，记录更正。

第三，测试失败。设置一个可重复的测试环境，随机翻转内存中的位。这将允许您复制损坏情况，并帮助围绕它们设计应用程序。