我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。

我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?


当前回答

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

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

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

其他回答

也许了解一下硬件“为这种环境而设计”意味着什么会有所帮助。它如何纠正和/或指示SEU错误的存在?

在一个与空间探索相关的项目中,我们有一个自定义MCU,它会在SEU错误时引发异常/中断,但会有一些延迟,即在导致SEU异常的insn之后可能会通过一些循环/执行一些指令。

数据缓存尤其容易受到攻击,因此处理程序会使有问题的缓存行无效并重新启动程序。只是,由于异常的不精确性,以引发异常的insn为首的insn序列可能无法重新启动。

我们确定了危险的(不可重启的)序列(如lw$3,0x0($2),然后是insn,它修改了$2,数据不依赖于$3),我对GCC进行了修改,所以这样的序列不会发生(例如,作为最后的手段,用nop分隔两个insn)。

只是需要考虑的事情。。。

考虑到超级跑车的评论、现代编译器的趋势以及其他因素,我很想回到古代,用汇编和静态内存分配的方式到处编写整个代码。对于这种完全的可靠性,我认为组装不再会带来很大的成本差异。

这是一个非常广泛的主题。基本上,您无法真正从内存损坏中恢复,但至少可以尝试立即失败。以下是您可以使用的一些技巧:

校验和常量数据。如果有任何配置数据长期保持不变(包括已配置的硬件寄存器),请在初始化时计算其校验和并定期验证。当您看到不匹配时,应该重新初始化或重置。冗余存储变量。如果你有一个重要的变量x,把它的值写在x1、x2和x3中,然后读为(x1==x2)?x2:x3。实施程序流程监控。将全局标志与从主循环调用的重要函数/分支中的唯一值进行异或。在接近100%测试覆盖率的无辐射环境中运行程序,应为您提供循环结束时标志的可接受值列表。如果看到偏差,则重置。监视堆栈指针。在主循环的开头,将堆栈指针与其预期值进行比较。偏差复位。

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

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

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

您可能还对有关算法容错的丰富文献感兴趣。这包括旧的赋值:编写一个排序,当恒定数量的比较将失败时(或者,更糟糕的版本,当失败的比较的渐近数量为n次比较的log(n)时),正确地对其输入进行排序。

开始阅读黄和亚伯拉罕1984年的论文《矩阵运算的基于算法的容错》。他们的想法隐约类似于同态加密计算(但实际上并不相同,因为他们正在尝试在操作级别进行错误检测/纠正)。

该论文的一个较新的后代是Bosilca、Delmas、Dongarra和Langou的“基于算法的容错应用于高性能计算”。