你问的是一个非常复杂的话题——不容易回答。其他答案是可以的，但它们只涵盖了你需要做的所有事情的一小部分。

正如在评论中看到的，不可能100%解决硬件问题，但是使用各种技术很可能减少或解决这些问题。

如果我是你，我会创建最高安全完整性级别（SIL-4）的软件。获取IEC 61513文件（适用于核工业）并遵循该文件。

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

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

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

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

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

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

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

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

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

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

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