我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。
我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?
我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。
我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?
当前回答
有人提到使用较慢的芯片来防止离子同样容易地翻转比特。以类似的方式,可能使用专门的cpu/ram,它实际上使用多个位来存储单个位。因此,提供了硬件容错,因为不太可能所有的位都被翻转。所以1=1111,但需要被击中4次才能真正翻转。(4可能是一个坏数字,因为如果2位被翻转,它就已经不明确了)。因此,如果您使用8,您得到的ram将减少8倍,访问时间也会慢一些,但数据表示更可靠。您可能可以在软件级别使用专门的编译器(为所有内容分配更多的空间)或语言实现(为以这种方式分配内容的数据结构编写包装器)来实现这一点。或具有相同逻辑结构但在固件中执行此操作的专用硬件。
其他回答
能帮助你的是看门狗。20世纪80年代,看门狗被广泛用于工业计算。当时,硬件故障更为常见——另一个答案也提到了那个时期。
看门狗是一种组合的硬件/软件功能。硬件是一个简单的计数器,从一个数字(比如1023)向下计数到零。可以使用TTL或其他逻辑。
软件的设计使得一个例程可以监控所有基本系统的正确运行。如果此例程正确完成=发现计算机运行正常,则将计数器设置回1023。
总体设计使得在正常情况下,软件可以防止硬件计数器达到零。如果计数器达到零,计数器的硬件将执行其唯一的任务并重置整个系统。从计数器的角度来看,零等于1024,计数器继续向下计数。
该看门狗可确保所连接的计算机在多次故障情况下重新启动。我必须承认,我不熟悉能够在当今计算机上执行这种功能的硬件。与外部硬件的接口现在比过去复杂得多。
看门狗的一个固有缺点是,从出现故障到看门狗计数器达到零+重新启动时间,系统就不可用。虽然该时间通常比任何外部或人为干预短得多,但在该时间段内,受支持的设备需要能够在没有计算机控制的情况下继续工作。
既然您专门要求软件解决方案,而且您使用的是C++,为什么不使用运算符重载来创建自己的安全数据类型呢?例如:
不要使用uint32_t(以及double、int64_t等),而是制作自己的SAFE_uint32-t,其中包含uint32/t的倍数(最小值为3)。重载您想要执行的所有操作(*+-/<<>>==!=等),并使重载的操作对每个内部值独立执行,即不要执行一次并复制结果。在之前和之后,检查所有内部值是否匹配。如果值不匹配,可以将错误的值更新为最常见的值。如果没有最常见的值,您可以安全地通知存在错误。
这样,即使ALU、寄存器、RAM或总线上发生损坏也无所谓,您仍然可以多次尝试并很好地捕获错误。然而,请注意,这只适用于您可以替换的变量-例如,堆栈指针仍然是易受影响的。
附带故事:我遇到了一个类似的问题,也是在一个旧的ARM芯片上。结果发现,这是一个使用旧版本GCC的工具链,与我们使用的特定芯片一起,在某些边缘情况下触发了一个错误,这会(有时)破坏传递到函数中的值。在将设备归咎于无线电活动之前,确保设备没有任何问题,是的,有时是编译器错误=)
免责声明:我不是放射性专业人员,也不是这类应用的工作人员。但我致力于关键数据的长期归档的软错误和冗余,这有点联系(相同的问题,不同的目标)。
在我看来,放射性的主要问题是放射性可以切换位,因此放射性可以/将篡改任何数字存储器。这些错误通常被称为软错误、比特腐烂等。
问题是:当你的内存不可靠时,如何可靠地计算?
要显著降低软错误率(以计算开销为代价,因为大多数情况下都是基于软件的解决方案),您可以:
依靠好的旧冗余方案,更具体地说,是更有效的纠错码(目的相同,但算法更聪明,这样可以用更少的冗余恢复更多的比特)。这有时(错误地)也称为校验和。使用这种解决方案,您必须随时将程序的完整状态存储在主变量/类(或结构?)中,计算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之间自动复制计算,并在最后以机械方式进行多数表决(例如,使用“与/或”门)。这通常在飞机和任务关键设备中实现(参见三模块冗余)。这样,你就不会有任何计算开销(因为额外的计算将并行进行),并且你有另一层防止软错误的保护(因为计算重复和多数表决将由硬件直接管理,而不是由软件管理——因为程序只是存储在内存中的位……)。
如果你的硬件出现故障,你可以使用机械存储来恢复它。如果你的代码库很小,并且有一些物理空间,那么你可以使用一个机械数据存储。
材料表面不会受到辐射的影响。将有多个档位。机械读卡器将在所有齿轮上运行,并且可以灵活地上下移动。向下表示为0,向上表示为1。从0和1可以生成代码库。
你问的是一个非常复杂的话题——不容易回答。其他答案是可以的,但它们只涵盖了你需要做的所有事情的一小部分。
正如在评论中看到的,不可能100%解决硬件问题,但是使用各种技术很可能减少或解决这些问题。
如果我是你,我会创建最高安全完整性级别(SIL-4)的软件。获取IEC 61513文件(适用于核工业)并遵循该文件。