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

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

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

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

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

有一点似乎没有人提到。你说你在GCC中开发，并在ARM上交叉编译。你怎么知道你的代码中没有关于空闲RAM、整数大小、指针大小、执行某个操作需要多长时间、系统将持续运行多长时间等的假设？这是一个非常普遍的问题。

答案通常是自动单元测试。编写在开发系统上执行代码的测试线束，然后在目标系统上运行相同的测试线束。寻找差异！

还要检查嵌入式设备上的勘误表。您可能会发现“不要这样做，因为它会崩溃，所以启用编译器选项，编译器会解决它”。

简而言之，崩溃的最可能来源是代码中的错误。在你确定这不是事实之前，不要担心更深奥的故障模式。

以下是一些想法和想法：

更创造性地使用ROM。

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

为堆栈使用最好的RAM。

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

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

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

在软件中执行纠错代码。

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

记住缓存。

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

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

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

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

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

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

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

记住这是一场概率游戏。

一位评论者说

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

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

使用冗余硬件。

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

为放射性环境编写代码实际上与为任何任务关键型应用程序编写代码没有什么不同。

除了已经提到的内容外，还有一些杂项提示：

使用任何半专业嵌入式系统都应具备的日常“面包和黄油”安全措施：内部看门狗、内部低电压检测、内部时钟监视器。这些事情在2016年甚至不需要提及，它们几乎是每个现代微控制器的标准。如果您有一个面向安全和/或汽车的MCU，它将具有某些看门狗功能，例如给定的时间窗口，您需要在其中刷新看门狗。如果您有任务关键型实时系统，则首选此选项。一般来说，使用适用于这类系统的MCU，而不是在一包玉米片中收到的普通主流绒毛。现在几乎每个MCU制造商都有专门为安全应用设计的MCU（TI、Freescale、Renesas、ST、Infineon等）。它们有很多内置的安全功能，包括锁步内核：这意味着有两个CPU内核执行相同的代码，它们必须彼此一致。重要事项：您必须确保内部MCU寄存器的完整性。硬件外设的所有可写控制和状态寄存器可能位于RAM内存中，因此易受攻击。为了保护自己免受寄存器损坏，最好选择具有内置寄存器“一次写入”功能的微控制器。此外，您需要在NVM中存储所有硬件寄存器的默认值，并定期将这些值复制到寄存器中。您可以以同样的方式确保重要变量的完整性。注意：始终使用防御性编程。这意味着您必须在MCU中设置所有寄存器，而不仅仅是应用程序使用的寄存器。你不希望一些随机的硬件外设突然醒来。有各种各样的方法来检查RAM或NVM中的错误：校验和、“行走模式”、软件ECC等。现在最好的解决方案是不使用任何这些，而是使用内置ECC和类似检查的MCU。因为在软件中这样做很复杂，因此错误检查本身可能会引入错误和意外问题。使用冗余。您可以将易失性和非易失性内存存储在两个相同的“镜像”段中，这两个段必须始终相等。每个段可以附加CRC校验和。避免使用MCU外部的外部存储器。为所有可能的中断/异常实现默认中断服务例程/默认异常处理程序。即使是你不使用的。默认例程除了关闭自己的中断源之外，不应该做任何事情。理解并接受防御性编程的概念。这意味着您的程序需要处理所有可能的情况，即使是理论上无法发生的情况。示例。高质量的任务关键型固件检测到尽可能多的错误，然后以安全的方式处理或忽略它们。不要编写依赖于指定不良行为的程序。这种行为可能会因辐射或EMI引起的意外硬件变化而发生剧烈变化。确保您的程序没有此类垃圾的最佳方法是使用像MISRA这样的编码标准，以及静态分析器工具。这也有助于防御编程和消除bug（为什么您不想在任何类型的应用程序中检测bug？）。重要提示：不要依赖静态存储持续时间变量的默认值。也就是说，不要信任.data或.bss的默认内容。从初始化点到实际使用变量的点之间可能有任何时间，RAM可能有足够的时间损坏。相反，编写程序，以便在运行时从NVM中设置所有此类变量，就在首次使用此类变量之前。在实践中，这意味着如果变量在文件范围内声明或声明为静态，则永远不应该使用=来初始化它（或者可以，但这是没有意义的，因为无论如何都不能依赖于值）。始终在运行时设置，就在使用之前。如果可以从NVM中重复更新这些变量，那么就这样做。类似地，在C++中，对于静态存储持续时间变量，不要依赖构造函数。让构造函数调用公共的“设置”例程，您也可以稍后在运行时直接从调用方应用程序调用该例程。如果可能的话，请完全删除初始化.data和.bss（并调用C++构造函数）的“向下复制”启动代码，这样在编写依赖于这些的代码时就会出现链接器错误。许多编译器都可以选择跳过这一步，通常称为“最小/快速启动”或类似操作。这意味着必须检查任何外部库，以便它们不包含任何此类依赖。实现并定义程序的安全状态，以便在发生严重错误时恢复到该状态。实施错误报告/错误日志系统总是有帮助的。