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

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

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

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

既然您专门要求软件解决方案，而且您使用的是C++，为什么不使用运算符重载来创建自己的安全数据类型呢？例如：

不要使用uint32_t（以及double、int64_t等），而是制作自己的SAFE_uint32-t，其中包含uint32/t的倍数（最小值为3）。重载您想要执行的所有操作（*+-/<<>>==！=等），并使重载的操作对每个内部值独立执行，即不要执行一次并复制结果。在之前和之后，检查所有内部值是否匹配。如果值不匹配，可以将错误的值更新为最常见的值。如果没有最常见的值，您可以安全地通知存在错误。

这样，即使ALU、寄存器、RAM或总线上发生损坏也无所谓，您仍然可以多次尝试并很好地捕获错误。然而，请注意，这只适用于您可以替换的变量-例如，堆栈指针仍然是易受影响的。

附带故事：我遇到了一个类似的问题，也是在一个旧的ARM芯片上。结果发现，这是一个使用旧版本GCC的工具链，与我们使用的特定芯片一起，在某些边缘情况下触发了一个错误，这会（有时）破坏传递到函数中的值。在将设备归咎于无线电活动之前，确保设备没有任何问题，是的，有时是编译器错误=）

首先，围绕失败设计应用程序。确保作为正常流程操作的一部分，它需要重置（取决于您的应用程序和软或硬故障类型）。这很难做到完美：需要某种程度的事务性的关键操作可能需要在组装级别进行检查和调整，以便关键点的中断不会导致不一致的外部命令。一旦检测到任何不可恢复的内存损坏或控制流偏差，就立即失败。如果可能，记录故障。

第二，如果可能，纠正腐败并继续下去。这意味着经常检查和修复常量表（如果可以的话，还包括程序代码）；可能在每个主要操作之前或在定时中断上，并将变量存储在自动校正的结构中（同样在每个主要运算之前或在计时中断上，从3中获得多数票，如果是单个偏差，则进行校正）。如果可能，记录更正。

第三，测试失败。设置一个可重复的测试环境，随机翻转内存中的位。这将允许您复制损坏情况，并帮助围绕它们设计应用程序。

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

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

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

使用循环调度程序。这使您能够增加定期维护时间，以检查关键数据的正确性。最常遇到的问题是堆栈损坏。如果您的软件是周期性的，您可以在周期之间重新初始化堆栈。不要为中断调用重用堆栈，请为每个重要的中断调用设置一个单独的堆栈。

与看门狗概念类似的是最后期限计时器。在调用函数之前启动硬件计时器。如果函数在截止时间计时器中断之前未返回，则重新加载堆栈并重试。如果在3/5次尝试后仍然失败，则需要从ROM重新加载。

将软件拆分为多个部分，并将这些部分隔离开来，以使用单独的内存区域和执行时间（尤其是在控制环境中）。示例：信号采集、预处理数据、主要算法和结果实现/传输。这意味着某一部分的失败不会导致整个程序的失败。因此，当我们修复信号采集时，其余任务将继续处理过时的数据。

一切都需要CRC。如果您在RAM中执行，甚至您的.txt也需要CRC。如果使用循环调度程序，请定期检查CRC。有些编译器（不是GCC）可以为每个部分生成CRC，有些处理器有专用硬件来进行CRC计算，但我想这将超出您的问题范围。检查CRC还会提示内存上的ECC控制器在出现问题之前修复单位错误。

使用看门狗进行启动，而不仅仅是一次操作。如果您的启动遇到问题，您需要硬件帮助。