既然您专门要求软件解决方案，而且您使用的是C++，为什么不使用运算符重载来创建自己的安全数据类型呢？例如：

不要使用uint32_t（以及double、int64_t等），而是制作自己的SAFE_uint32-t，其中包含uint32/t的倍数（最小值为3）。重载您想要执行的所有操作（*+-/<<>>==！=等），并使重载的操作对每个内部值独立执行，即不要执行一次并复制结果。在之前和之后，检查所有内部值是否匹配。如果值不匹配，可以将错误的值更新为最常见的值。如果没有最常见的值，您可以安全地通知存在错误。

这样，即使ALU、寄存器、RAM或总线上发生损坏也无所谓，您仍然可以多次尝试并很好地捕获错误。然而，请注意，这只适用于您可以替换的变量-例如，堆栈指针仍然是易受影响的。

附带故事：我遇到了一个类似的问题，也是在一个旧的ARM芯片上。结果发现，这是一个使用旧版本GCC的工具链，与我们使用的特定芯片一起，在某些边缘情况下触发了一个错误，这会（有时）破坏传递到函数中的值。在将设备归咎于无线电活动之前，确保设备没有任何问题，是的，有时是编译器错误=）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

能帮助你的是看门狗。20世纪80年代，看门狗被广泛用于工业计算。当时，硬件故障更为常见——另一个答案也提到了那个时期。

看门狗是一种组合的硬件/软件功能。硬件是一个简单的计数器，从一个数字（比如1023）向下计数到零。可以使用TTL或其他逻辑。

软件的设计使得一个例程可以监控所有基本系统的正确运行。如果此例程正确完成=发现计算机运行正常，则将计数器设置回1023。

总体设计使得在正常情况下，软件可以防止硬件计数器达到零。如果计数器达到零，计数器的硬件将执行其唯一的任务并重置整个系统。从计数器的角度来看，零等于1024，计数器继续向下计数。

该看门狗可确保所连接的计算机在多次故障情况下重新启动。我必须承认，我不熟悉能够在当今计算机上执行这种功能的硬件。与外部硬件的接口现在比过去复杂得多。

看门狗的一个固有缺点是，从出现故障到看门狗计数器达到零+重新启动时间，系统就不可用。虽然该时间通常比任何外部或人为干预短得多，但在该时间段内，受支持的设备需要能够在没有计算机控制的情况下继续工作。