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

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


当前回答

有人提到使用较慢的芯片来防止离子同样容易地翻转比特。以类似的方式,可能使用专门的cpu/ram,它实际上使用多个位来存储单个位。因此,提供了硬件容错,因为不太可能所有的位都被翻转。所以1=1111,但需要被击中4次才能真正翻转。(4可能是一个坏数字,因为如果2位被翻转,它就已经不明确了)。因此,如果您使用8,您得到的ram将减少8倍,访问时间也会慢一些,但数据表示更可靠。您可能可以在软件级别使用专门的编译器(为所有内容分配更多的空间)或语言实现(为以这种方式分配内容的数据结构编写包装器)来实现这一点。或具有相同逻辑结构但在固件中执行此操作的专用硬件。

其他回答

你需要3台以上的从机,在辐射环境外有一台主机。所有I/O都通过包含表决和/或重试机制的主机。每个从设备必须有一个硬件监视器,并且撞击它们的调用应该被CRC等包围,以降低非自愿撞击的概率。转发应该由主机控制,因此与主机的连接丢失等于几秒钟内重新启动。

此解决方案的一个优点是,您可以对主机和从机使用相同的API,因此冗余成为一种透明的特性。

编辑:从评论中,我觉得有必要澄清“CRC的想法”。如果你用CRC来围绕碰撞,或者对来自主设备的随机数据进行摘要检查,那么从设备碰撞它自己的看门狗的可能性接近于零。只有当受监视的从设备与其他设备对齐时,才从主设备发送随机数据。随机数据和CRC/摘要在每次碰撞后立即清除。主从缓冲频率应超过看门狗超时的两倍。每次从主机发送的数据都是唯一生成的。

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

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

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

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

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

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

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

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

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

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

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

使用循环调度程序。这使您能够增加定期维护时间,以检查关键数据的正确性。最常遇到的问题是堆栈损坏。如果您的软件是周期性的,您可以在周期之间重新初始化堆栈。不要为中断调用重用堆栈,请为每个重要的中断调用设置一个单独的堆栈。

与看门狗概念类似的是最后期限计时器。在调用函数之前启动硬件计时器。如果函数在截止时间计时器中断之前未返回,则重新加载堆栈并重试。如果在3/5次尝试后仍然失败,则需要从ROM重新加载。

将软件拆分为多个部分,并将这些部分隔离开来,以使用单独的内存区域和执行时间(尤其是在控制环境中)。示例:信号采集、预处理数据、主要算法和结果实现/传输。这意味着某一部分的失败不会导致整个程序的失败。因此,当我们修复信号采集时,其余任务将继续处理过时的数据。

一切都需要CRC。如果您在RAM中执行,甚至您的.txt也需要CRC。如果使用循环调度程序,请定期检查CRC。有些编译器(不是GCC)可以为每个部分生成CRC,有些处理器有专用硬件来进行CRC计算,但我想这将超出您的问题范围。检查CRC还会提示内存上的ECC控制器在出现问题之前修复单位错误。

使用看门狗进行启动,而不仅仅是一次操作。如果您的启动遇到问题,您需要硬件帮助。

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

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

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

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