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

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

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

以下是一些想法和想法：

更创造性地使用ROM。

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

为堆栈使用最好的RAM。

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

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

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

在软件中执行纠错代码。

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

记住缓存。

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

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

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

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

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

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

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

记住这是一场概率游戏。

一位评论者说

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

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

使用冗余硬件。

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

考虑到超级跑车的评论、现代编译器的趋势以及其他因素，我很想回到古代，用汇编和静态内存分配的方式到处编写整个代码。对于这种完全的可靠性，我认为组装不再会带来很大的成本差异。

使用循环调度程序。这使您能够增加定期维护时间，以检查关键数据的正确性。最常遇到的问题是堆栈损坏。如果您的软件是周期性的，您可以在周期之间重新初始化堆栈。不要为中断调用重用堆栈，请为每个重要的中断调用设置一个单独的堆栈。

与看门狗概念类似的是最后期限计时器。在调用函数之前启动硬件计时器。如果函数在截止时间计时器中断之前未返回，则重新加载堆栈并重试。如果在3/5次尝试后仍然失败，则需要从ROM重新加载。

将软件拆分为多个部分，并将这些部分隔离开来，以使用单独的内存区域和执行时间（尤其是在控制环境中）。示例：信号采集、预处理数据、主要算法和结果实现/传输。这意味着某一部分的失败不会导致整个程序的失败。因此，当我们修复信号采集时，其余任务将继续处理过时的数据。

一切都需要CRC。如果您在RAM中执行，甚至您的.txt也需要CRC。如果使用循环调度程序，请定期检查CRC。有些编译器（不是GCC）可以为每个部分生成CRC，有些处理器有专用硬件来进行CRC计算，但我想这将超出您的问题范围。检查CRC还会提示内存上的ECC控制器在出现问题之前修复单位错误。

使用看门狗进行启动，而不仅仅是一次操作。如果您的启动遇到问题，您需要硬件帮助。

这个答案假设你关心的是一个工作正常的系统，而不是一个成本最低或速度快的系统；大多数玩放射性物品的人都看重正确性/安全性而不是速度/成本

有几个人建议您可以进行硬件更改（很好，答案中已经有很多好东西，我不打算重复所有内容），还有一些人建议冗余（原则上很好），但我认为没有人建议冗余在实践中如何工作。你怎么会失败？你怎么知道什么时候出了问题？许多技术都是在一切都会成功的基础上工作的，因此失败是一件棘手的事情。然而，一些为规模而设计的分布式计算技术预计会出现故障（毕竟，规模足够大，多个节点中的一个节点的故障是不可避免的，单个节点的平均无故障时间为MTBF）；你可以利用它来保护你的环境。

以下是一些想法：

确保整个硬件复制n次（其中n大于2，最好是奇数），并且每个硬件元素可以与其他硬件元素通信。以太网是实现这一点的一种明显方式，但还有许多其他更简单的路由可以提供更好的保护（例如CAN）。尽量减少常见组件（甚至电源）。例如，这可能意味着在多个地方对ADC输入进行采样。确保应用程序状态在一个地方，例如在有限状态机中。这可以完全基于RAM，但并不排除稳定的存储。因此，它将存储在几个地方。对状态变化采用仲裁协议。例如，请参见RAFT。当您在C++中工作时，有一些众所周知的库可以实现这一点。只有当大多数节点同意时，才能对FSM进行更改。为协议堆栈和仲裁协议使用一个已知的好库，而不是自己滚动一个，否则当仲裁协议挂断时，您在冗余方面的所有好工作都将被浪费。确保您对FSM进行校验和（例如，CRC/SHA），并将CRC/CHA存储在FSM本身中（以及在消息中传输，并对消息本身进行校验和）。让节点定期对照这些校验和、传入消息的校验和检查其FSM，并检查其校验和是否与仲裁的校验和匹配。在系统中构建尽可能多的其他内部检查，使检测到自身故障的节点重新启动（这比在有足够节点的情况下继续半工作要好）。尝试让他们在重新启动过程中彻底退出仲裁，以防他们再次出现。在重新启动时，让他们检查软件映像（以及他们加载的任何其他内容），并在重新引入仲裁之前进行完整的RAM测试。使用硬件支持您，但要小心操作。例如，您可以获取ECC RAM，并定期对其进行读/写，以纠正ECC错误（如果错误无法纠正，则会死机）。然而（从内存来看）静态RAM比DRAM更能耐受电离辐射，因此最好使用静态DRAM。请参见“我不会做的事情”下的第一点。

假设您在一天内任何给定节点都有1%的失败机会，假设您可以使失败完全独立。如果有5个节点，一天内需要3个节点失败，这是0.00001%的概率。有了更多，你就明白了。

我不会做的事情：

低估了一开始没有问题的价值。除非重量是一个问题，否则你的设备周围的一大块金属将是一个比程序员团队所能想到的更便宜、更可靠的解决方案。同样，EMI输入的光学耦合也是一个问题，等等。无论怎样，在采购部件时，都要尽量选择那些抗电离辐射性能最好的部件。使用自己的算法。人们以前也做过这种事。利用他们的工作。容错和分布式算法很难。尽可能利用他人的工作。使用复杂的编译器设置，天真地希望您检测到更多失败。如果你运气好，你可能会发现更多的失败。更有可能的是，您将在编译器中使用一个测试较少的代码路径，特别是如果您自己滚动的话。使用在您的环境中未经测试的技术。大多数编写高可用性软件的人必须模拟故障模式，以检查其HA是否正常工作，并因此错过了许多故障模式。你处于“幸运”的境地，经常按需出现故障。因此，测试每种技术，并确保其应用程序实际提高MTBF的数量超过引入它的复杂性（复杂性带来了bug）。特别是将此应用于我的建议重新仲裁算法等。

使用C语言编写在这种环境中表现稳健的程序是可能的，但前提是大多数形式的编译器优化都被禁用。优化编译器旨在用“更高效”的编码模式替换许多看似冗余的编码模式，并且可能不知道当编译器知道x不可能保持任何其他值时，程序员测试x==42的原因是因为程序员想要阻止执行某些代码，而x保持某个其他值——即使在这样的情况下，它保持该值的唯一方法是系统接收到某种电气故障。

将变量声明为易失性通常很有用，但可能不是万能药。特别重要的是，注意安全编码通常需要操作具有需要多个步骤来激活的硬件联锁，并且使用以下模式编写代码：

... code that checks system state
if (system_state_favors_activation)
{
  prepare_for_activation();
  ... code that checks system state again
  if (system_state_is_valid)
  {
    if (system_state_favors_activation)
      trigger_activation();
  }
  else
    perform_safety_shutdown_and_restart();
}
cancel_preparations();

如果编译器以相对文字的方式翻译代码，并且如果全部在prepare_for_activation（）之后重复对系统状态的检查，系统可以对几乎任何可能的单一故障事件具有鲁棒性，甚至那些会任意破坏程序计数器和堆栈的程序。如果在调用prepare_for_activation（）之后发生了一个小故障，这意味着激活是合适的（因为没有其他原因prepare_for_activation（）将在故障发生之前被调用）。如果故障导致代码不正确地到达prepare_for_activation（），但如果没有后续故障事件，则代码将无法在未通过验证检查或先调用cancel_preparies的情况下到达trigger_activation（）[如果堆栈出现问题，则在调用prepare_for_activation（）的上下文返回后，执行可能会继续到trigger_active（）之前的某个位置，但调用cancel_preparations（从而使后者的调用无害。

这样的代码在传统的C语言中可能是安全的，但在现代的C编译器中却不安全。这种编译器在这种环境中可能非常危险，因为它们努力只包含通过某种定义良好的机制可能出现的情况下相关的代码，并且其结果也将得到很好的定义。在某些情况下，旨在检测和清理故障的代码可能会使情况变得更糟。如果编译器确定尝试的恢复在某些情况下会调用未定义的行为，则可能推断在这种情况下不可能出现需要恢复的条件，从而消除了检查这些条件的代码。