我们正在编译一个嵌入的C++应用程序，它被部署在屏蔽设备中，在电离辐射的环境中。我们正在为ARM使用GCC和交叉编译。部署时，我们的应用程序会生成一些错误数据，并且崩溃的频率比我们希望的要高。硬件是为这个环境设计的，我们的应用程序已经在这个平台上运行了好几年
我们是否可以对代码进行更改，或者对编译时进行改进，以识别/纠正由单事件中断引起的软错误和内存损坏？是否有其他开发人员成功地减少了软错误对长期运行的应用程序的有害影响
在小型卫星的软件/固件开发和环境测试方面工作了大约4-5年*，我想在这里分享我的经验
*（小型化卫星比大型卫星更容易发生单事件干扰，因为其电子组件相对较小，尺寸有限）
简明扼要地说：没有任何机制可以从可检测的、错误的中恢复
情况由软件/固件本身造成，但不包括，至少一个
将软件/固件的最低工作版本复制到某个地方，用于恢复目的，并使用支持恢复的硬件（功能）
现在，这种情况通常是在硬件和软件层面上处理的。在这里，根据您的要求，我将分享我们在软件级别可以做的事情
-
…恢复目的…。提供在真实环境中更新/重新编译/刷新软件/固件的能力。这是高度电离环境中任何软件/固件几乎必须具备的功能。如果没有这一点，你可以拥有你想要的任意多的冗余软件/硬件，但在某一点上，它们都会爆炸。所以，准备这个功能
-
…最低工作版本…在您的代码中有响应性的、多份的、最低版本的软件/固件。这类似于Windows中的安全模式。您的软件不是只有一个功能齐全的版本，而是具有软件/固件最低版本的多个副本。最小副本通常比完整副本小得多，并且几乎总是只有以下两个或三个功能：
- 能够监听来自外部系统的命令
- 能够更新当前软件/固件
- 能够监控基本操作的内务数据
-
…复制。。。某处…某处有冗余软件/固件
-
您可以使用或而不使用冗余硬件，尝试在ARM uC中使用冗余软件/固件。这通常是通过在单独的地址中有两个或多个相同的软件/固件来实现的，它们相互发送心跳信号，但一次只有一个处于活动状态。如果已知一个或多个软件/固件无响应，请切换到其他软件/固件。使用这种方法的好处是，我们可以在错误发生后立即进行功能更换，而无需与负责检测和修复错误的任何外部系统/方进行任何联系（在卫星情况下，通常是任务控制中心（MCC））
严格地说，如果没有冗余硬件，这样做的缺点是实际上无法消除所有单点故障。至少，您仍然会有一个单点故障，即开关本身（或者通常是代码的开头）。然而，对于高度电离环境中受尺寸限制的设备（如皮托/飞秒卫星），在不增加硬件的情况下，将单点故障减少到一点仍值得考虑。更重要的是，用于切换的代码片段肯定会比整个程序的代码少得多，这大大降低了在其中获取单个事件的风险
-
但是，如果您不这样做，您的外部系统中应该至少有一个副本，可以与设备接触并更新软件/固件（在卫星情况下，它也是任务控制中心）
- 您还可以将副本保存在设备中的永久内存存储器中，该存储器可被触发以恢复正在运行的系统的软件/固件
-
-
…可检测的错误情况..错误必须可检测，通常通过硬件纠错/检测电路或一小段纠错/检测代码。最好将这些代码放在主软件/固件的小型、多个且独立的。它的主要任务是检查/纠正。如果硬件电路/固件是可靠的（例如，它比REST更硬，或者具有多个电路/逻辑），那么您可以考虑用它进行纠错。但如果不是，最好将其作为错误检测。可通过外部系统/设备进行校正。对于纠错，可以考虑使用像Hamming／Galay23这样的基本纠错算法，因为它们可以在电路/软件中更容易实现。但这最终取决于团队的能力。对于错误检测，通常使用CRC
-
…支持恢复的硬件现在，在这个问题上，最困难的方面来了。最终，恢复要求负责恢复的硬件至少能够正常工作。如果硬件永久损坏（通常发生在其总电离剂量达到一定水平后），则（遗憾的是）软件无法帮助恢复。因此，对于暴露在高辐射水平下的设备（如卫星），硬件是最重要的考虑因素
除了上述建议，我还建议您：
-
子系统间通信协议中的错误检测和/或错误纠正算法。这是另一个几乎必须具备的功能，以避免从其他系统接收到不完整/错误的信号
-
过滤ADC读数。不要直接使用ADC读数。通过中值滤波器、均值滤波器或任何其他滤波器对其进行过滤-从不信任单个读取值。多取样，而不是少取样-合理