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

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


当前回答

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

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

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

其他回答

你问的是一个非常复杂的话题——不容易回答。其他答案是可以的,但它们只涵盖了你需要做的所有事情的一小部分。

正如在评论中看到的,不可能100%解决硬件问题,但是使用各种技术很可能减少或解决这些问题。

如果我是你,我会创建最高安全完整性级别(SIL-4)的软件。获取IEC 61513文件(适用于核工业)并遵循该文件。

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

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

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

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

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

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

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

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

我真的读了很多很棒的答案!

这是我的2美分:通过编写软件检查内存或执行频繁的寄存器比较,建立内存/寄存器异常的统计模型。此外,以虚拟机的形式创建一个仿真器,您可以在其中试验该问题。我想,如果你改变结尺寸、时钟频率、供应商、外壳等,你会观察到不同的行为。

即使我们的台式电脑内存也有一定的故障率,但这不会影响日常工作。

NASA有一篇关于防辐射软件的论文。它描述了三个主要任务:

定期监控内存中的错误,然后清除这些错误,稳健的错误恢复机制,以及如果某些东西不再工作,重新配置的能力。

请注意,内存扫描速率应该足够频繁,很少发生多位错误,因为大多数ECC内存可以从单位错误而不是多位错误中恢复。

稳健的错误恢复包括控制流传输(通常在错误发生之前的某个点重新启动流程)、资源释放和数据恢复。

他们对数据恢复的主要建议是,通过将中间数据视为临时数据,避免数据恢复的需要,以便在错误发生之前重新启动也能将数据回滚到可靠状态。这听起来类似于数据库中的“事务”概念。

他们讨论了特别适用于面向对象语言(如C++)的技术。例如

用于连续内存对象的基于软件的ECC契约编程:验证先决条件和后决条件,然后检查对象以验证其是否仍处于有效状态。

而且,正是如此,美国宇航局(NASA)已将C++用于火星探测器等重大项目。

C++类抽象和封装支持多个项目和开发人员之间的快速开发和测试。

他们避免了某些可能产生问题的C++特性:

例外情况模板Iostream(无控制台)多重继承运算符重载(new和delete除外)动态分配(使用专用内存池并放置新的以避免系统堆损坏的可能性)。