这里有大量的回复，但我将尝试总结我对此的想法。

某些东西崩溃或不正常工作可能是您自己的错误造成的，那么当您找到问题时，应该很容易解决。但也有可能出现硬件故障，如果不是不可能，整体上很难解决。

我建议首先尝试通过日志记录（堆栈、寄存器、函数调用）来捕捉问题情况——要么将它们记录到文件中的某个位置，要么以某种方式直接发送（“哦，不，我崩溃了”）。

从这种错误情况中恢复可以是重新启动（如果软件仍然处于活动状态）或硬件重置（例如硬件看门狗）。从第一个开始更容易。

若问题是硬件相关的，那个么日志记录应该可以帮助您确定在哪个函数调用中发生了问题，这可以让您了解什么是不工作的以及在哪里。

此外，如果代码相对复杂-“分割并征服”它是有意义的-这意味着你在怀疑问题所在的地方删除/禁用一些函数调用-通常禁用一半代码并启用另一半代码-你可以得到“确实有效”/“不有效”的决定，然后你可以专注于另一半代码。（问题所在）

若问题在一段时间后发生，那个么可以怀疑堆栈溢出，那个么最好监视堆栈点寄存器，若它们不断增长。

如果你设法完全最小化代码，直到“hello world”类型的应用程序出现故障，那么硬件问题是意料之中的，需要进行“硬件升级”，这意味着发明这样的cpu/ram/-能够更好地耐受辐射的硬件组合。

最重要的事情可能是，如果机器完全停止/重新设置/不工作，您如何取回日志-这可能是bootstap应该做的第一件事-如果有问题的情况被解决，您应该回家。

如果在您的环境中也可以发送信号和接收响应，那么您可以尝试构建某种在线远程调试环境，但您必须至少有通信媒体工作，并且某些处理器/某些ram处于工作状态。通过远程调试，我的意思是GDB/GDB存根类型的方法，或者您自己实现从应用程序中获取所需的内容（例如，下载日志文件、下载调用堆栈、下载ram、重新启动）

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

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

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

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

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

使用任何半专业嵌入式系统都应具备的日常“面包和黄油”安全措施：内部看门狗、内部低电压检测、内部时钟监视器。这些事情在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++构造函数）的“向下复制”启动代码，这样在编写依赖于这些的代码时就会出现链接器错误。许多编译器都可以选择跳过这一步，通常称为“最小/快速启动”或类似操作。这意味着必须检查任何外部库，以便它们不包含任何此类依赖。实现并定义程序的安全状态，以便在发生严重错误时恢复到该状态。实施错误报告/错误日志系统总是有帮助的。

我真的读了很多很棒的答案！

这是我的2美分：通过编写软件检查内存或执行频繁的寄存器比较，建立内存/寄存器异常的统计模型。此外，以虚拟机的形式创建一个仿真器，您可以在其中试验该问题。我想，如果你改变结尺寸、时钟频率、供应商、外壳等，你会观察到不同的行为。

即使我们的台式电脑内存也有一定的故障率，但这不会影响日常工作。

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

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

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

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

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

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

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

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

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

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

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

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

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

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