c++ - 编译用于高放射性环境的应用程序

Question

我们正在编译一个嵌入式C/C++应用程序，它被部署在屏蔽设备中，在一个环境中被AA>轰击。我们正在为ARM使用GCC和交叉编译。部署时，我们的应用程序生成一些错误数据，并比我们希望的更频繁地崩溃。硬件就是为这个环境设计的，我们的应用程序已经在这个平台上运行了好几年了。
我们是否可以对代码进行更改，或对编译时进行改进，以识别/纠正由ionizing radiation引起的soft errors和内存损坏？有没有其他开发人员成功地减少了软错误对长期运行的应用程序的有害影响？

Answer 1

在miniaturized satellites*的软件/固件开发和环境测试方面工作了4-5年，我想在此分享我的经验。
*（小型卫星比大型卫星更容易发生单次事故，因为其电子元件的尺寸相对较小、有限）
简明扼要：没有任何机制可以从可察觉的错误中恢复过来
软件/固件本身的情况，至少没有
用于恢复目的的软件/固件的最低工作版本副本-以及支持恢复的硬件（功能）。
现在，这种情况通常在硬件和软件两个级别都可以处理。在这里，根据您的要求，我将分享我们在软件级别可以做的事情。
…恢复目的。。。。提供在真实环境中更新/重新编译/刷新软件/固件的能力。对于高度电离环境中的任何软件/固件，这几乎是必须具备的功能。如果没有这个，你可以拥有你想要的任意多的冗余软件/硬件，但在某一点上，它们都会爆炸。所以，准备这个功能！
…最低工作版本。。。在您的代码中具有响应性、多个副本、软件/固件的最低版本。这就像Windows中的安全模式。与其只有一个功能齐全的软件版本，不如有多个软件/固件最低版本的副本。最小副本的大小通常比完整副本小得多，并且几乎总是只有以下两个或三个功能：
能够监听外部系统的命令，
能够更新当前的软件/固件，
能够监控基本操作的内务数据。
…收到。。。在某个地方。。。在某处安装冗余软件/固件。
无论有无冗余硬件，您都可以尝试在ARMUC中使用冗余软件/固件。这通常是通过在单独的地址中有两个或多个相同的软件/固件来完成的，这些地址相互发送心跳信号，但一次只有一个处于活动状态。如果已知一个或多个软件/固件没有响应，请切换到其他软件/固件。使用这种方法的好处是，我们可以在错误发生后立即进行功能替换，而不必与负责检测和修复错误的任何外部系统/方进行任何接触（在卫星情况下，通常是任务控制中心（MCC））。
严格地说，如果没有冗余的硬件，这样做的缺点实际上是不能消除所有单点故障。至少，您仍然会有一个单一的故障点，那就是开关本身（或者经常是代码的开头）。然而，对于高度电离环境中受尺寸限制的设备（如pico/femto卫星），在没有额外硬件的情况下将单点故障减少到一点仍然值得考虑。更重要的是，用于切换的代码肯定要比整个程序的代码少得多，这大大降低了在其中获得单个事件的风险。
但如果你不这样做，你应该在你的外部系统中至少有一个副本，可以与设备接触并更新软件/固件（在卫星情况下，它又是任务控制中心）。
您也可以将副本保存在设备的永久存储器中，该存储器可被触发以还原正在运行的系统的软件/固件
……可察觉的错误情况。。错误必须是可检测的，通常通过硬件错误校正/检测电路或一小段用于错误校正/检测的代码来检测。最好将这些代码放在小的、多个的位置，并且独立于主软件/固件。它的主要任务只是检查/纠正。如果硬件电路/固件是可靠的（例如它比其余的更抗辐射-或有多个电路/逻辑），那么您可以考虑用它进行错误校正。但如果不是，最好将其作为错误检测。可通过外部系统/设备进行校正。对于纠错，可以考虑使用基本的纠错算法，如Hamming/Golay23，因为它们在电路/软件中都可以更容易地实现。但这最终取决于你的团队的能力。对于错误检测，通常使用CRC。
…现在支持恢复的硬件是这个问题上最困难的方面。最终，恢复需要负责恢复的硬件至少能够正常工作。如果硬件永久损坏（通常在其总电离剂量达到一定水平后发生），那么（遗憾的是）软件无法帮助恢复。因此，对于暴露在高辐射水平下的设备（如卫星），硬件是最重要的考虑因素。
除了上述由于单一事件不正常导致固件错误的建议外，我还建议您：
子系统间通信协议中的错误检测和/或纠错算法。为了避免从其他系统接收到不完整/错误的信号，这几乎是必须的
过滤ADC读数。不要直接使用ADC读数。通过中值滤波器、均值滤波器或任何其他滤波器对其进行过滤-切勿信任单个读取值。多采样，而不是少采样-合理。