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

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

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

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

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

在小型卫星的软件/固件开发和环境测试方面工作了大约4-5年，我想在这里分享我的经验。

*（小型卫星比大型卫星更容易发生单次事件干扰，因为其电子部件的尺寸相对较小且有限）

非常简洁和直接：没有机制可以从可检测到的错误中恢复过来软件/固件本身的情况，至少没有用于恢复目的的软件/固件的最低工作版本副本，以及支持恢复的硬件（功能）。

现在，这种情况通常在硬件和软件两级处理。在这里，根据您的要求，我将分享我们在软件级别可以做的事情。

…恢复目的。。。。提供在真实环境中更新/重新编译/刷新软件/固件的能力。这几乎是高度电离环境中任何软件/固件的必备功能。如果没有这一点，您可以拥有任意数量的冗余软件/硬件，但在某一点上，它们都会崩溃。所以，准备好这个功能！…最低工作版本。。。在您的代码中具有响应性、多个副本、最低版本的软件/固件。这类似于Windows中的安全模式。不要只拥有一个功能完整的软件版本，而是拥有软件/固件的最低版本的多个副本。最小副本通常比完整副本小得多，并且几乎总是只有以下两个或三个功能：能够监听来自外部系统的命令，能够更新当前软件/固件，能够监控基本操作的内务数据。…复制…某处。。。在某处安装冗余软件/固件。无论有无冗余硬件，您都可以尝试在ARM uC中使用冗余软件/固件。这通常是通过在单独的地址中有两个或多个相同的软件/固件来实现的，这些软件/固件将向彼此发送心跳信号，但一次只有一个处于活动状态。如果已知一个或多个软件/固件没有响应，请切换到其他软件/固件。使用这种方法的好处是，我们可以在发生错误后立即进行功能更换，而无需与负责检测和修复错误的任何外部系统/方进行任何联系（在卫星情况下，通常是任务控制中心（MCC））。严格来说，如果没有冗余硬件，这样做的缺点是实际上无法消除所有单点故障。至少，您仍然会有一个单一的故障点，那就是交换机本身（或者通常是代码的开头）。然而，对于高度电离环境中受尺寸限制的设备（如微微/毫微微卫星），在没有额外硬件的情况下将单点故障减少到一点仍然值得考虑。更重要的是，用于切换的代码肯定会比整个程序的代码少得多，从而显著降低了在其中出现单一事件的风险。但是，如果您没有这样做，您的外部系统中应该至少有一个副本，该副本可以与设备接触并更新软件/固件（在卫星情况下，它也是任务控制中心）。您还可以在设备的永久内存存储中保存副本，该副本可以被触发以恢复正在运行的系统的软件/固件…可检测到的错误情况。。该错误必须是可检测的，通常通过硬件纠错/检测电路或通过一小段纠错/检测代码来检测。最好将这些代码放得小、多，并且独立于主软件/固件。其主要任务仅用于检查/纠正。如果硬件电路/固件是可靠的（例如，它比其余的更抗辐射-或具有多个电路/逻辑），那么您可以考虑使用它进行错误校正。但如果不是，最好将其作为错误检测。可通过外部系统/设备进行校正。对于纠错，您可以考虑使用像Hamming/Golay23这样的基本纠错算法，因为它们可以更容易地在电路/软件中实现。但这最终取决于团队的能力。对于错误检测，通常使用CRC。…支持恢复的硬件现在是这个问题上最困难的方面。最终，恢复需要负责恢复的硬件至少能够正常工作。如果硬件永久损坏（通常发生在其总电离剂量达到一定水平后），则软件无法帮助恢复。因此，对于暴露在高辐射水平下的设备（如卫星）来说，硬件无疑是最重要的关注点。

除了上述预测固件错误的建议外，我还建议您：

子系统间通信协议中的错误检测和/或错误校正算法。这是另一个几乎必须具备的功能，以避免从其他系统接收到不完整/错误的信号过滤ADC读数。请勿直接使用ADC读数。通过中值过滤器、均值过滤器或任何其他过滤器对其进行过滤-切勿相信单个读数。多采样，而不是少采样-合理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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