我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。
我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?
我们正在编译一个嵌入式C++应用程序,它部署在电离辐射轰击的环境中的屏蔽设备中。我们正在为ARM使用GCC和交叉编译。在部署时,我们的应用程序会生成一些错误的数据,并且比我们希望的更频繁地崩溃。硬件是为这个环境而设计的,我们的应用程序已经在这个平台上运行了几年。
我们是否可以对代码进行更改,或对编译时进行改进,以识别/纠正由单个事件扰乱导致的软错误和内存损坏?是否有其他开发人员成功地减少了软错误对长时间运行的应用程序的有害影响?
当前回答
为放射性环境编写代码实际上与为任何任务关键型应用程序编写代码没有什么不同。
除了已经提到的内容外,还有一些杂项提示:
使用任何半专业嵌入式系统都应具备的日常“面包和黄油”安全措施:内部看门狗、内部低电压检测、内部时钟监视器。这些事情在2016年甚至不需要提及,它们几乎是每个现代微控制器的标准。如果您有一个面向安全和/或汽车的MCU,它将具有某些看门狗功能,例如给定的时间窗口,您需要在其中刷新看门狗。如果您有任务关键型实时系统,则首选此选项。一般来说,使用适用于这类系统的MCU,而不是在一包玉米片中收到的普通主流绒毛。现在几乎每个MCU制造商都有专门为安全应用设计的MCU(TI、Freescale、Renesas、ST、Infineon等)。它们有很多内置的安全功能,包括锁步内核:这意味着有两个CPU内核执行相同的代码,它们必须彼此一致。重要事项:您必须确保内部MCU寄存器的完整性。硬件外设的所有可写控制和状态寄存器可能位于RAM内存中,因此易受攻击。为了保护自己免受寄存器损坏,最好选择具有内置寄存器“一次写入”功能的微控制器。此外,您需要在NVM中存储所有硬件寄存器的默认值,并定期将这些值复制到寄存器中。您可以以同样的方式确保重要变量的完整性。注意:始终使用防御性编程。这意味着您必须在MCU中设置所有寄存器,而不仅仅是应用程序使用的寄存器。你不希望一些随机的硬件外设突然醒来。有各种各样的方法来检查RAM或NVM中的错误:校验和、“行走模式”、软件ECC等。现在最好的解决方案是不使用任何这些,而是使用内置ECC和类似检查的MCU。因为在软件中这样做很复杂,因此错误检查本身可能会引入错误和意外问题。使用冗余。您可以将易失性和非易失性内存存储在两个相同的“镜像”段中,这两个段必须始终相等。每个段可以附加CRC校验和。避免使用MCU外部的外部存储器。为所有可能的中断/异常实现默认中断服务例程/默认异常处理程序。即使是你不使用的。默认例程除了关闭自己的中断源之外,不应该做任何事情。理解并接受防御性编程的概念。这意味着您的程序需要处理所有可能的情况,即使是理论上无法发生的情况。示例。高质量的任务关键型固件检测到尽可能多的错误,然后以安全的方式处理或忽略它们。不要编写依赖于指定不良行为的程序。这种行为可能会因辐射或EMI引起的意外硬件变化而发生剧烈变化。确保您的程序没有此类垃圾的最佳方法是使用像MISRA这样的编码标准,以及静态分析器工具。这也有助于防御编程和消除bug(为什么您不想在任何类型的应用程序中检测bug?)。重要提示:不要依赖静态存储持续时间变量的默认值。也就是说,不要信任.data或.bss的默认内容。从初始化点到实际使用变量的点之间可能有任何时间,RAM可能有足够的时间损坏。相反,编写程序,以便在运行时从NVM中设置所有此类变量,就在首次使用此类变量之前。在实践中,这意味着如果变量在文件范围内声明或声明为静态,则永远不应该使用=来初始化它(或者可以,但这是没有意义的,因为无论如何都不能依赖于值)。始终在运行时设置,就在使用之前。如果可以从NVM中重复更新这些变量,那么就这样做。类似地,在C++中,对于静态存储持续时间变量,不要依赖构造函数。让构造函数调用公共的“设置”例程,您也可以稍后在运行时直接从调用方应用程序调用该例程。如果可能的话,请完全删除初始化.data和.bss(并调用C++构造函数)的“向下复制”启动代码,这样在编写依赖于这些的代码时就会出现链接器错误。许多编译器都可以选择跳过这一步,通常称为“最小/快速启动”或类似操作。这意味着必须检查任何外部库,以便它们不包含任何此类依赖。实现并定义程序的安全状态,以便在发生严重错误时恢复到该状态。实施错误报告/错误日志系统总是有帮助的。
其他回答
能帮助你的是看门狗。20世纪80年代,看门狗被广泛用于工业计算。当时,硬件故障更为常见——另一个答案也提到了那个时期。
看门狗是一种组合的硬件/软件功能。硬件是一个简单的计数器,从一个数字(比如1023)向下计数到零。可以使用TTL或其他逻辑。
软件的设计使得一个例程可以监控所有基本系统的正确运行。如果此例程正确完成=发现计算机运行正常,则将计数器设置回1023。
总体设计使得在正常情况下,软件可以防止硬件计数器达到零。如果计数器达到零,计数器的硬件将执行其唯一的任务并重置整个系统。从计数器的角度来看,零等于1024,计数器继续向下计数。
该看门狗可确保所连接的计算机在多次故障情况下重新启动。我必须承认,我不熟悉能够在当今计算机上执行这种功能的硬件。与外部硬件的接口现在比过去复杂得多。
看门狗的一个固有缺点是,从出现故障到看门狗计数器达到零+重新启动时间,系统就不可用。虽然该时间通常比任何外部或人为干预短得多,但在该时间段内,受支持的设备需要能够在没有计算机控制的情况下继续工作。
NASA有一篇关于防辐射软件的论文。它描述了三个主要任务:
定期监控内存中的错误,然后清除这些错误,稳健的错误恢复机制,以及如果某些东西不再工作,重新配置的能力。
请注意,内存扫描速率应该足够频繁,很少发生多位错误,因为大多数ECC内存可以从单位错误而不是多位错误中恢复。
稳健的错误恢复包括控制流传输(通常在错误发生之前的某个点重新启动流程)、资源释放和数据恢复。
他们对数据恢复的主要建议是,通过将中间数据视为临时数据,避免数据恢复的需要,以便在错误发生之前重新启动也能将数据回滚到可靠状态。这听起来类似于数据库中的“事务”概念。
他们讨论了特别适用于面向对象语言(如C++)的技术。例如
用于连续内存对象的基于软件的ECC契约编程:验证先决条件和后决条件,然后检查对象以验证其是否仍处于有效状态。
而且,正是如此,美国宇航局(NASA)已将C++用于火星探测器等重大项目。
C++类抽象和封装支持多个项目和开发人员之间的快速开发和测试。
他们避免了某些可能产生问题的C++特性:
例外情况模板Iostream(无控制台)多重继承运算符重载(new和delete除外)动态分配(使用专用内存池并放置新的以避免系统堆损坏的可能性)。
这里有大量的回复,但我将尝试总结我对此的想法。
某些东西崩溃或不正常工作可能是您自己的错误造成的,那么当您找到问题时,应该很容易解决。但也有可能出现硬件故障,如果不是不可能,整体上很难解决。
我建议首先尝试通过日志记录(堆栈、寄存器、函数调用)来捕捉问题情况——要么将它们记录到文件中的某个位置,要么以某种方式直接发送(“哦,不,我崩溃了”)。
从这种错误情况中恢复可以是重新启动(如果软件仍然处于活动状态)或硬件重置(例如硬件看门狗)。从第一个开始更容易。
若问题是硬件相关的,那个么日志记录应该可以帮助您确定在哪个函数调用中发生了问题,这可以让您了解什么是不工作的以及在哪里。
此外,如果代码相对复杂-“分割并征服”它是有意义的-这意味着你在怀疑问题所在的地方删除/禁用一些函数调用-通常禁用一半代码并启用另一半代码-你可以得到“确实有效”/“不有效”的决定,然后你可以专注于另一半代码。(问题所在)
若问题在一段时间后发生,那个么可以怀疑堆栈溢出,那个么最好监视堆栈点寄存器,若它们不断增长。
如果你设法完全最小化代码,直到“hello world”类型的应用程序出现故障,那么硬件问题是意料之中的,需要进行“硬件升级”,这意味着发明这样的cpu/ram/-能够更好地耐受辐射的硬件组合。
最重要的事情可能是,如果机器完全停止/重新设置/不工作,您如何取回日志-这可能是bootstap应该做的第一件事-如果有问题的情况被解决,您应该回家。
如果在您的环境中也可以发送信号和接收响应,那么您可以尝试构建某种在线远程调试环境,但您必须至少有通信媒体工作,并且某些处理器/某些ram处于工作状态。通过远程调试,我的意思是GDB/GDB存根类型的方法,或者您自己实现从应用程序中获取所需的内容(例如,下载日志文件、下载调用堆栈、下载ram、重新启动)
使用循环调度程序。这使您能够增加定期维护时间,以检查关键数据的正确性。最常遇到的问题是堆栈损坏。如果您的软件是周期性的,您可以在周期之间重新初始化堆栈。不要为中断调用重用堆栈,请为每个重要的中断调用设置一个单独的堆栈。
与看门狗概念类似的是最后期限计时器。在调用函数之前启动硬件计时器。如果函数在截止时间计时器中断之前未返回,则重新加载堆栈并重试。如果在3/5次尝试后仍然失败,则需要从ROM重新加载。
将软件拆分为多个部分,并将这些部分隔离开来,以使用单独的内存区域和执行时间(尤其是在控制环境中)。示例:信号采集、预处理数据、主要算法和结果实现/传输。这意味着某一部分的失败不会导致整个程序的失败。因此,当我们修复信号采集时,其余任务将继续处理过时的数据。
一切都需要CRC。如果您在RAM中执行,甚至您的.txt也需要CRC。如果使用循环调度程序,请定期检查CRC。有些编译器(不是GCC)可以为每个部分生成CRC,有些处理器有专用硬件来进行CRC计算,但我想这将超出您的问题范围。检查CRC还会提示内存上的ECC控制器在出现问题之前修复单位错误。
使用看门狗进行启动,而不仅仅是一次操作。如果您的启动遇到问题,您需要硬件帮助。
也许了解一下硬件“为这种环境而设计”意味着什么会有所帮助。它如何纠正和/或指示SEU错误的存在?
在一个与空间探索相关的项目中,我们有一个自定义MCU,它会在SEU错误时引发异常/中断,但会有一些延迟,即在导致SEU异常的insn之后可能会通过一些循环/执行一些指令。
数据缓存尤其容易受到攻击,因此处理程序会使有问题的缓存行无效并重新启动程序。只是,由于异常的不精确性,以引发异常的insn为首的insn序列可能无法重新启动。
我们确定了危险的(不可重启的)序列(如lw$3,0x0($2),然后是insn,它修改了$2,数据不依赖于$3),我对GCC进行了修改,所以这样的序列不会发生(例如,作为最后的手段,用nop分隔两个insn)。
只是需要考虑的事情。。。