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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使用C语言编写在这种环境中表现稳健的程序是可能的，但前提是大多数形式的编译器优化都被禁用。优化编译器旨在用“更高效”的编码模式替换许多看似冗余的编码模式，并且可能不知道当编译器知道x不可能保持任何其他值时，程序员测试x==42的原因是因为程序员想要阻止执行某些代码，而x保持某个其他值——即使在这样的情况下，它保持该值的唯一方法是系统接收到某种电气故障。

将变量声明为易失性通常很有用，但可能不是万能药。特别重要的是，注意安全编码通常需要操作具有需要多个步骤来激活的硬件联锁，并且使用以下模式编写代码：

... code that checks system state
if (system_state_favors_activation)
{
  prepare_for_activation();
  ... code that checks system state again
  if (system_state_is_valid)
  {
    if (system_state_favors_activation)
      trigger_activation();
  }
  else
    perform_safety_shutdown_and_restart();
}
cancel_preparations();

如果编译器以相对文字的方式翻译代码，并且如果全部在prepare_for_activation（）之后重复对系统状态的检查，系统可以对几乎任何可能的单一故障事件具有鲁棒性，甚至那些会任意破坏程序计数器和堆栈的程序。如果在调用prepare_for_activation（）之后发生了一个小故障，这意味着激活是合适的（因为没有其他原因prepare_for_activation（）将在故障发生之前被调用）。如果故障导致代码不正确地到达prepare_for_activation（），但如果没有后续故障事件，则代码将无法在未通过验证检查或先调用cancel_preparies的情况下到达trigger_activation（）[如果堆栈出现问题，则在调用prepare_for_activation（）的上下文返回后，执行可能会继续到trigger_active（）之前的某个位置，但调用cancel_preparations（从而使后者的调用无害。

这样的代码在传统的C语言中可能是安全的，但在现代的C编译器中却不安全。这种编译器在这种环境中可能非常危险，因为它们努力只包含通过某种定义良好的机制可能出现的情况下相关的代码，并且其结果也将得到很好的定义。在某些情况下，旨在检测和清理故障的代码可能会使情况变得更糟。如果编译器确定尝试的恢复在某些情况下会调用未定义的行为，则可能推断在这种情况下不可能出现需要恢复的条件，从而消除了检查这些条件的代码。

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

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

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

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