我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。
我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?
我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。
我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?
当前回答
有一点似乎没有人提到。你说你在GCC中开发,并在ARM上交叉编译。你怎么知道你的代码中没有关于空闲RAM、整数大小、指针大小、执行某个操作需要多长时间、系统将持续运行多长时间等的假设?这是一个非常普遍的问题。
答案通常是自动单元测试。编写在开发系统上执行代码的测试线束,然后在目标系统上运行相同的测试线束。寻找差异!
还要检查嵌入式设备上的勘误表。您可能会发现“不要这样做,因为它会崩溃,所以启用编译器选项,编译器会解决它”。
简而言之,崩溃的最可能来源是代码中的错误。在你确定这不是事实之前,不要担心更深奥的故障模式。
其他回答
这是一个非常广泛的主题。基本上,您无法真正从内存损坏中恢复,但至少可以尝试立即失败。以下是您可以使用的一些技巧:
校验和常量数据。如果有任何配置数据长期保持不变(包括已配置的硬件寄存器),请在初始化时计算其校验和并定期验证。当您看到不匹配时,应该重新初始化或重置。冗余存储变量。如果你有一个重要的变量x,把它的值写在x1、x2和x3中,然后读为(x1==x2)?x2:x3。实施程序流程监控。将全局标志与从主循环调用的重要函数/分支中的唯一值进行异或。在接近100%测试覆盖率的无辐射环境中运行程序,应为您提供循环结束时标志的可接受值列表。如果看到偏差,则重置。监视堆栈指针。在主循环的开头,将堆栈指针与其预期值进行比较。偏差复位。
也许了解一下硬件“为这种环境而设计”意味着什么会有所帮助。它如何纠正和/或指示SEU错误的存在?
在一个与空间探索相关的项目中,我们有一个自定义MCU,它会在SEU错误时引发异常/中断,但会有一些延迟,即在导致SEU异常的insn之后可能会通过一些循环/执行一些指令。
数据缓存尤其容易受到攻击,因此处理程序会使有问题的缓存行无效并重新启动程序。只是,由于异常的不精确性,以引发异常的insn为首的insn序列可能无法重新启动。
我们确定了危险的(不可重启的)序列(如lw$3,0x0($2),然后是insn,它修改了$2,数据不依赖于$3),我对GCC进行了修改,所以这样的序列不会发生(例如,作为最后的手段,用nop分隔两个insn)。
只是需要考虑的事情。。。
有人提到使用较慢的芯片来防止离子同样容易地翻转比特。以类似的方式,可能使用专门的cpu/ram,它实际上使用多个位来存储单个位。因此,提供了硬件容错,因为不太可能所有的位都被翻转。所以1=1111,但需要被击中4次才能真正翻转。(4可能是一个坏数字,因为如果2位被翻转,它就已经不明确了)。因此,如果您使用8,您得到的ram将减少8倍,访问时间也会慢一些,但数据表示更可靠。您可能可以在软件级别使用专门的编译器(为所有内容分配更多的空间)或语言实现(为以这种方式分配内容的数据结构编写包装器)来实现这一点。或具有相同逻辑结构但在固件中执行此操作的专用硬件。
在小型卫星的软件/固件开发和环境测试方面工作了大约4-5年,我想在这里分享我的经验。
*(小型卫星比大型卫星更容易发生单次事件干扰,因为其电子部件的尺寸相对较小且有限)
非常简洁和直接:没有机制可以从可检测到的错误中恢复过来软件/固件本身的情况,至少没有用于恢复目的的软件/固件的最低工作版本副本,以及支持恢复的硬件(功能)。
现在,这种情况通常在硬件和软件两级处理。在这里,根据您的要求,我将分享我们在软件级别可以做的事情。
…恢复目的。。。。提供在真实环境中更新/重新编译/刷新软件/固件的能力。这几乎是高度电离环境中任何软件/固件的必备功能。如果没有这一点,您可以拥有任意数量的冗余软件/硬件,但在某一点上,它们都会崩溃。所以,准备好这个功能!…最低工作版本。。。在您的代码中具有响应性、多个副本、最低版本的软件/固件。这类似于Windows中的安全模式。不要只拥有一个功能完整的软件版本,而是拥有软件/固件的最低版本的多个副本。最小副本通常比完整副本小得多,并且几乎总是只有以下两个或三个功能:能够监听来自外部系统的命令,能够更新当前软件/固件,能够监控基本操作的内务数据。…复制…某处。。。在某处安装冗余软件/固件。无论有无冗余硬件,您都可以尝试在ARM uC中使用冗余软件/固件。这通常是通过在单独的地址中有两个或多个相同的软件/固件来实现的,这些软件/固件将向彼此发送心跳信号,但一次只有一个处于活动状态。如果已知一个或多个软件/固件没有响应,请切换到其他软件/固件。使用这种方法的好处是,我们可以在发生错误后立即进行功能更换,而无需与负责检测和修复错误的任何外部系统/方进行任何联系(在卫星情况下,通常是任务控制中心(MCC))。严格来说,如果没有冗余硬件,这样做的缺点是实际上无法消除所有单点故障。至少,您仍然会有一个单一的故障点,那就是交换机本身(或者通常是代码的开头)。然而,对于高度电离环境中受尺寸限制的设备(如微微/毫微微卫星),在没有额外硬件的情况下将单点故障减少到一点仍然值得考虑。更重要的是,用于切换的代码肯定会比整个程序的代码少得多,从而显著降低了在其中出现单一事件的风险。但是,如果您没有这样做,您的外部系统中应该至少有一个副本,该副本可以与设备接触并更新软件/固件(在卫星情况下,它也是任务控制中心)。您还可以在设备的永久内存存储中保存副本,该副本可以被触发以恢复正在运行的系统的软件/固件…可检测到的错误情况。。该错误必须是可检测的,通常通过硬件纠错/检测电路或通过一小段纠错/检测代码来检测。最好将这些代码放得小、多,并且独立于主软件/固件。其主要任务仅用于检查/纠正。如果硬件电路/固件是可靠的(例如,它比其余的更抗辐射-或具有多个电路/逻辑),那么您可以考虑使用它进行错误校正。但如果不是,最好将其作为错误检测。可通过外部系统/设备进行校正。对于纠错,您可以考虑使用像Hamming/Golay23这样的基本纠错算法,因为它们可以更容易地在电路/软件中实现。但这最终取决于团队的能力。对于错误检测,通常使用CRC。…支持恢复的硬件现在是这个问题上最困难的方面。最终,恢复需要负责恢复的硬件至少能够正常工作。如果硬件永久损坏(通常发生在其总电离剂量达到一定水平后),则软件无法帮助恢复。因此,对于暴露在高辐射水平下的设备(如卫星)来说,硬件无疑是最重要的关注点。
除了上述预测固件错误的建议外,我还建议您:
子系统间通信协议中的错误检测和/或错误校正算法。这是另一个几乎必须具备的功能,以避免从其他系统接收到不完整/错误的信号过滤ADC读数。请勿直接使用ADC读数。通过中值过滤器、均值过滤器或任何其他过滤器对其进行过滤-切勿相信单个读数。多采样,而不是少采样-合理。
你问的是一个非常复杂的话题——不容易回答。其他答案是可以的,但它们只涵盖了你需要做的所有事情的一小部分。
正如在评论中看到的,不可能100%解决硬件问题,但是使用各种技术很可能减少或解决这些问题。
如果我是你,我会创建最高安全完整性级别(SIL-4)的软件。获取IEC 61513文件(适用于核工业)并遵循该文件。