我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。
我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?
我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。
我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?
当前回答
如何运行应用程序的许多实例。如果崩溃是由于随机的内存位变化造成的,那么你的一些应用程序实例很可能会通过并产生准确的结果。(对于有统计背景的人来说)很容易计算出在给定的比特翻转概率下需要多少个实例才能实现所希望的最小总体错误。
其他回答
使用循环调度程序。这使您能够增加定期维护时间,以检查关键数据的正确性。最常遇到的问题是堆栈损坏。如果您的软件是周期性的,您可以在周期之间重新初始化堆栈。不要为中断调用重用堆栈,请为每个重要的中断调用设置一个单独的堆栈。
与看门狗概念类似的是最后期限计时器。在调用函数之前启动硬件计时器。如果函数在截止时间计时器中断之前未返回,则重新加载堆栈并重试。如果在3/5次尝试后仍然失败,则需要从ROM重新加载。
将软件拆分为多个部分,并将这些部分隔离开来,以使用单独的内存区域和执行时间(尤其是在控制环境中)。示例:信号采集、预处理数据、主要算法和结果实现/传输。这意味着某一部分的失败不会导致整个程序的失败。因此,当我们修复信号采集时,其余任务将继续处理过时的数据。
一切都需要CRC。如果您在RAM中执行,甚至您的.txt也需要CRC。如果使用循环调度程序,请定期检查CRC。有些编译器(不是GCC)可以为每个部分生成CRC,有些处理器有专用硬件来进行CRC计算,但我想这将超出您的问题范围。检查CRC还会提示内存上的ECC控制器在出现问题之前修复单位错误。
使用看门狗进行启动,而不仅仅是一次操作。如果您的启动遇到问题,您需要硬件帮助。
我真的读了很多很棒的答案!
这是我的2美分:通过编写软件检查内存或执行频繁的寄存器比较,建立内存/寄存器异常的统计模型。此外,以虚拟机的形式创建一个仿真器,您可以在其中试验该问题。我想,如果你改变结尺寸、时钟频率、供应商、外壳等,你会观察到不同的行为。
即使我们的台式电脑内存也有一定的故障率,但这不会影响日常工作。
你问的是一个非常复杂的话题——不容易回答。其他答案是可以的,但它们只涵盖了你需要做的所有事情的一小部分。
正如在评论中看到的,不可能100%解决硬件问题,但是使用各种技术很可能减少或解决这些问题。
如果我是你,我会创建最高安全完整性级别(SIL-4)的软件。获取IEC 61513文件(适用于核工业)并遵循该文件。
免责声明:我不是放射性专业人员,也不是这类应用的工作人员。但我致力于关键数据的长期归档的软错误和冗余,这有点联系(相同的问题,不同的目标)。
在我看来,放射性的主要问题是放射性可以切换位,因此放射性可以/将篡改任何数字存储器。这些错误通常被称为软错误、比特腐烂等。
问题是:当你的内存不可靠时,如何可靠地计算?
要显著降低软错误率(以计算开销为代价,因为大多数情况下都是基于软件的解决方案),您可以:
依靠好的旧冗余方案,更具体地说,是更有效的纠错码(目的相同,但算法更聪明,这样可以用更少的冗余恢复更多的比特)。这有时(错误地)也称为校验和。使用这种解决方案,您必须随时将程序的完整状态存储在主变量/类(或结构?)中,计算ECC,并在执行任何操作之前检查ECC是否正确,如果不正确,则修复字段。然而,此解决方案不能保证您的软件能够正常工作(简单地说,它可以正常工作,否则停止工作,因为ECC可以告诉您是否有问题,在这种情况下,您可以停止软件,这样您就不会得到假结果)。或者,您可以使用弹性算法数据结构,这在一定程度上保证您的程序即使在存在软错误的情况下仍能给出正确的结果。这些算法可以看作是普通算法结构与ECC方案的混合,但这比这更具弹性,因为弹性方案与结构紧密结合,因此不需要编码额外的过程来检查ECC,而且通常速度更快。这些结构提供了一种方法,可以确保您的程序在任何条件下都能工作,直到软错误的理论范围。您还可以将这些弹性结构与冗余/ECC方案混合使用,以提高安全性(或将最重要的数据结构编码为弹性数据结构,其余的是可从主数据结构重新计算的消耗性数据,作为具有ECC或奇偶校验的正常数据结构,计算速度非常快)。
如果您对弹性数据结构感兴趣(这是一个最近但令人兴奋的算法和冗余工程领域),我建议您阅读以下文档:
罗马大学Giuseppe F.Italiano“Tor Vergata”介绍的弹性算法数据结构Christiano,P.、Demaine,E.D.和Kishore,S.(2011)。具有附加开销的无损容错数据结构。《算法和数据结构》(第243-254页)。施普林格柏林海德堡。Ferraro Petrillo,U.、Grandoni,F.和Italiano,G.F.(2013)。数据结构对记忆故障的恢复能力:词典的实验研究。实验算法杂志(JEA),18,1-6。意大利,G.F.(2010)。弹性算法和数据结构。《算法与复杂性》(第13-24页)。施普林格柏林海德堡。
如果您有兴趣了解弹性数据结构领域的更多信息,您可以查看Giuseppe F.Italiano的作品(并通过参考文献)和Fault RAM模型(在Finocchi等人2005;Finocchi和Italiano 2008中介绍)。
/编辑:我说明了主要针对RAM内存和数据存储的软错误的预防/恢复,但我没有谈到计算(CPU)错误。其他答案已经指出了在数据库中使用原子事务,所以我将提出另一个更简单的方案:冗余和多数投票。
其思想是,您只需对需要进行的每一次计算进行x次相同的计算,并将结果存储在x个不同的变量中(x>=3)。然后可以比较x变量:
如果他们都同意,那么根本就没有计算错误。如果他们不同意,那么您可以使用多数票来获得正确的值,因为这意味着计算部分损坏,您还可以触发系统/程序状态扫描以检查其余部分是否正常。如果多数投票无法确定获胜者(所有x值都不同),那么这是触发故障保护程序(重新启动、向用户发出警报等)的完美信号。
与ECC相比,这种冗余方案非常快(实际上是O(1)),当您需要故障保护时,它为您提供了清晰的信号。多数表决也(几乎)保证不会产生损坏的输出,并从较小的计算错误中恢复,因为x计算给出相同输出的概率是无穷小的(因为有大量可能的输出,所以几乎不可能随机获得3倍相同的结果,如果x>3,则可能性更小)。
因此,通过多数表决,您可以避免损坏的输出,并且通过冗余x==3,您可以恢复1个错误(如果x==4,则可以恢复2个错误,等等——确切的公式是nb_error_recoverable==(x-2),其中x是计算重复次数,因为您需要至少2个一致的计算才能使用多数表决进行恢复)。
缺点是你需要计算x次而不是一次,所以你有额外的计算成本,但是它的线性复杂性是渐进的,所以你不会因为你获得的好处而损失太多。进行多数表决的快速方法是计算阵列上的模式,但也可以使用中值滤波器。
此外,如果您想确保计算正确进行,如果您可以制作自己的硬件,您可以用x个CPU构建设备,并将系统连接起来,以便在x个CPU之间自动复制计算,并在最后以机械方式进行多数表决(例如,使用“与/或”门)。这通常在飞机和任务关键设备中实现(参见三模块冗余)。这样,你就不会有任何计算开销(因为额外的计算将并行进行),并且你有另一层防止软错误的保护(因为计算重复和多数表决将由硬件直接管理,而不是由软件管理——因为程序只是存储在内存中的位……)。
既然您专门要求软件解决方案,而且您使用的是C++,为什么不使用运算符重载来创建自己的安全数据类型呢?例如:
不要使用uint32_t(以及double、int64_t等),而是制作自己的SAFE_uint32-t,其中包含uint32/t的倍数(最小值为3)。重载您想要执行的所有操作(*+-/<<>>==!=等),并使重载的操作对每个内部值独立执行,即不要执行一次并复制结果。在之前和之后,检查所有内部值是否匹配。如果值不匹配,可以将错误的值更新为最常见的值。如果没有最常见的值,您可以安全地通知存在错误。
这样,即使ALU、寄存器、RAM或总线上发生损坏也无所谓,您仍然可以多次尝试并很好地捕获错误。然而,请注意,这只适用于您可以替换的变量-例如,堆栈指针仍然是易受影响的。
附带故事:我遇到了一个类似的问题,也是在一个旧的ARM芯片上。结果发现,这是一个使用旧版本GCC的工具链,与我们使用的特定芯片一起,在某些边缘情况下触发了一个错误,这会(有时)破坏传递到函数中的值。在将设备归咎于无线电活动之前,确保设备没有任何问题,是的,有时是编译器错误=)