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

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

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

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

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

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

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

这是一个非常广泛的主题。基本上，您无法真正从内存损坏中恢复，但至少可以尝试立即失败。以下是您可以使用的一些技巧：

校验和常量数据。如果有任何配置数据长期保持不变（包括已配置的硬件寄存器），请在初始化时计算其校验和并定期验证。当您看到不匹配时，应该重新初始化或重置。冗余存储变量。如果你有一个重要的变量x，把它的值写在x1、x2和x3中，然后读为（x1==x2）？x2:x3。实施程序流程监控。将全局标志与从主循环调用的重要函数/分支中的唯一值进行异或。在接近100%测试覆盖率的无辐射环境中运行程序，应为您提供循环结束时标志的可接受值列表。如果看到偏差，则重置。监视堆栈指针。在主循环的开头，将堆栈指针与其预期值进行比较。偏差复位。

有人提到使用较慢的芯片来防止离子同样容易地翻转比特。以类似的方式，可能使用专门的cpu/ram，它实际上使用多个位来存储单个位。因此，提供了硬件容错，因为不太可能所有的位都被翻转。所以1=1111，但需要被击中4次才能真正翻转。（4可能是一个坏数字，因为如果2位被翻转，它就已经不明确了）。因此，如果您使用8，您得到的ram将减少8倍，访问时间也会慢一些，但数据表示更可靠。您可能可以在软件级别使用专门的编译器（为所有内容分配更多的空间）或语言实现（为以这种方式分配内容的数据结构编写包装器）来实现这一点。或具有相同逻辑结构但在固件中执行此操作的专用硬件。

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

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

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

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

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

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

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

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

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

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

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

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

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

你需要3台以上的从机，在辐射环境外有一台主机。所有I/O都通过包含表决和/或重试机制的主机。每个从设备必须有一个硬件监视器，并且撞击它们的调用应该被CRC等包围，以降低非自愿撞击的概率。转发应该由主机控制，因此与主机的连接丢失等于几秒钟内重新启动。

此解决方案的一个优点是，您可以对主机和从机使用相同的API，因此冗余成为一种透明的特性。

编辑：从评论中，我觉得有必要澄清“CRC的想法”。如果你用CRC来围绕碰撞，或者对来自主设备的随机数据进行摘要检查，那么从设备碰撞它自己的看门狗的可能性接近于零。只有当受监视的从设备与其他设备对齐时，才从主设备发送随机数据。随机数据和CRC/摘要在每次碰撞后立即清除。主从缓冲频率应超过看门狗超时的两倍。每次从主机发送的数据都是唯一生成的。