内容提要：本文描述了一种评估诊断机制及其诊断覆盖范围的新方法，该方法使用嵌入式软件实现，旨在识别影响数字组件的随机硬件失效。

摘要

本文描述了一种评估诊断机制及其诊断覆盖范围的新方法，该方法使用嵌入式软件实现，旨在识别影响数字组件的随机硬件失效。有许多采用故障注入方法的建议，其中大多数都关注瞬态故障，没有考虑功能安全标准要求。这种建议可以使汽车市场的开发人员受益，因为严格的安全和成本要求使得纯软件策略的采用变得很方便。因此，我们将重点放在遵守ISO 26262汽车功能安全标准上。该方法涉及影响微控制器的永久性故障，它提供了标准第11部分中描述的失效模式与所选故障模型之间的映射。我们提出了一个测试台，旨在将永久性失效注入仿真微控制器，并确定嵌入式软件检测到哪些失效。本文的主要贡献是一种与开源软件GCC、GDB和QEMU集成的新型故障注入管理器。该测试平台管理所有评估阶段，从故障生成到故障注入和ISA仿真管理，直至仿真结果的分类。

1.简介

如今，不同行业（例如航空航天、汽车和国防工业）用于实现安全关键任务应用的嵌入式系统的复杂性不断增加，人们越来越关注如何提高其可靠性。在汽车行业中，安装在车内的安全相关系统的数量正在稳步增长。由于这些系统的性质，证明它们能够实现正确的功能和足够的安全性至关重要。

在处理安全关键系统时，有必要按照国际功能安全标准进行开发。功能安全是产品或过程整体安全的一部分，特别注重保证系统能够执行其任务，而不会出现与电气和电子(E/E)设备相关的不合理风险，从而以正确的方式执行任务。在指定的时间限制内（在硬实时系统中），或者至少可以使受控物理过程进入安全状态。目前所有的功能安全标准均源自IEC 61508。特别是汽车应用要遵循的标准是ISO 26262。

为了保证此类系统不会让用户面临不可接受的风险，必须将其开发得可靠。对于本文来说，可靠性有双重含义。第一个考虑因素是不存在系统设计错误，而第二个因素是强化系统以防止随机硬件失效(RHF)。

一般来说，强化系统意味着添加某种冗余，通过添加额外的组件或在软件中在硬件中实现。无论如何，目标是保证任何影响系统的RHF都不会导致危险的不当行为。软件策略依赖于语句来监控有效负载应用程序的正确执行。

如果两种方法从安全角度来看是等效的，一般规则是，由于硬化部件相对于其他部件更昂贵，因此在设计必须少量生产的情况下采用硬件方法更方便。可以购买商用现成(COTS)形式的硬化硬件，从而降低开发成本。然而，当设计必须分成多个部分进行生产时，软件策略是更可取的。这种方法允许人们购买更便宜的硬件组件，并且可以在整个生产工作中分摊开发软件的高成本。

考虑到汽车应用的特点是产量大，软件策略更可取。然而，尽管硬件强化组件在销售时带有某种认证，可以假设它们在某些假设（包含在安全手册中）下具有一定的可靠性级别，如第2.2节中所述，但软件实现的强化方法必须在特定的应用程序上下文中进行测试。

为此，关键点是评估该方法在RHF检测中的性能，在ISO 26262标准中称为诊断覆盖率。

在此，我们提出了一种新颖的测试平台来帮助开发人员完成此评估过程，将永久性失效注入模拟微控制器中。其核心是集成了开源软件GCC、GDB和QEMU的故障注入管理器（FIM）。该测试平台管理从故障生成到故障注入的所有评估阶段，以及执行指令集架构（ISA）仿真管理，直至仿真结果的分类。

此外，我们通过提供标准第11部分中描述的失效模式与所选故障模型之间的映射，致力于遵守ISO 26262汽车功能安全标准。

本文的其余部分安排如下。

第2部分介绍了最新技术。第2.1节重点介绍故障注入，而第2.2节提供了ISO 26262标准的简要描述。

第3节描述了该提案，重点介绍了第3.1节中实施的故障模型及其与ISO 26262的映射，以及第3.2节中的测试台。

最后，第4节得出了一些结论。

2.最先进的技术

2.1.故障注入

根据FIDES/UTEC 80 811:2011，故障是判断或假设的不正确系统状态的原因，称为错误。失效是指提供不正确的服务时发生的事件，或者换句话说，是用户或外部系统感知到的错误。

多年来，人们一直在研究用于研究随机硬件失效影响的故障注入(FI)技术。为此目的已经提出了几种方法，并且已经开发了许多工具。

其中一些是硬件实现的：使用物理工具（例如外部电源或项目上的中子束）执行故障注入，以修改项目内的物理参数（例如电压或电流）。

这些技术可能成本高昂（例如，使用中子束通常只能研究整个技术（例如45 nm）对辐射的敏感性），并且使用激光或注入电压/电流需要其他技术昂贵的实验设备和大量的标本。

这些策略的另一个弱点是它们需要设计的硬件实现。

无论如何，物理操作对于确定失效模式率（组件可能发生失效的方式或模式）和概率分布至关重要。

为了克服这些弱点，特别是在成本和硬件实现的需求方面，多年来已经提出了各种基于仿真的技术。

无论选择哪种注入方式来注入故障，都需要定义故障模型。

这些描述了系统在运行过程中可能遇到的故障。从三个方面定义故障模型：注入什么、描述故障种类；何时注注入；以及注入位置，以确定注入的目标系统部分。

故障注入系统必须由以下组件组成：控制器、负载生成器、注入器、监视器，当然还有目标。

控制器生成命令，这些命令被传送到监视器、负载生成器和注入器。后者读取故障加载库并生成故障描述（所选要注入的故障模型的翻译，适合实际将其注入目标）。

负载生成器读取工作负载库并产生充当目标输入信号的输入激励，而监视器记录读数（目标输出信号）以产生故障影响分析。如果目标实现闭环控制系统，则负载生成器实现受控过程的物理或行为模型，能够对目标控制命令做出反应。

故障注入需要执行多个实验（或运行），这些实验与故障模型和工作负载库一起形成故障注入活动。

为了评估实验结果，通常将读数与无故障实验（称为黄金或无故障运行）获得的读数进行比较。

提案的其他重要特征（就方法和采用的故障模型而言）是代表性、可用性和效率（参考资料1，关注牛喀网公众号，后台咨询下载）。

代表性是故障负载库代表目标在运行过程中将遇到的真实故障的能力。这表明该方法将能够向目标提供适当的激励。从这个角度来看，考虑注入损坏和失效模式的类型和分布是至关重要的。可以通过适当调整所选故障模型的内容、地点和时间方面来保证注入损坏的有效性，以实现模型与实际故障之间的匹配，而必须根据失效模式的类型和分布来评估所选库生成实际失效模式，并因此评估容错能力的能力。

可用性是指在新目标系统上使用FI的能力。评估时考虑了系统的可移植性，即跨不同目标系统使用该工具的可能性；它的侵入性，或者所提出的方法不会向目标引入显著扰动的能力，这可能会扭曲实验结果；以及它的灵活性，即该方法的模块化以及定制或添加更新的故障模型的可能性。

可以考虑所需的实验数量以及注入的故障/错误的激活和传播来定义效率。首先需要最大限度地减少所需时间并获得系统的统计显著性评估。与此同时，第二种情况出现了，因为根据定义，未传播到错误然后传播到失效的故障是潜在的，因此不需要进一步的实验结果来研究其影响。

在我们的案例中，目标是对RHF的各种软件强化技术进行验证，例如其中应用此过程来验证基于软件的自测试技术的有效性；采用FI来证明作者为汽车微控制器提出的软件测试库的有效性，在（参考资料2，关注牛喀网公众号，后台咨询下载）中，该过程被提出作为确定在线功能不稳定故障存在的一种方法。

人们还提出了其他应用来证明基于软件的测试策略对人工神经网络在线测试的有效性，土木工程领域甚至出现了使用它们来监测混凝土复合材料的健康状态的新趋势。此外，由于采用了两种不同的抽象级别，它们已被用于评估嵌入式软件控制复杂机电系统以减轻RHF的能力。

本文提出了一种基于QEMU的故障注入系统，以确定软错误对嵌入式系统行为的影响。本文还提出了执行注入的流程图和故障描述。

SIHFT上的类似贡献

QEMU过去已被众多学者采用，用于在ISA级别实现基于仿真的故障注入系统，特别是研究软件实现的硬件容错(SIHFT)。

QEMU（快速仿真器）是一个开源机器仿真器和虚拟器，由Fabrice Bellard编写。

它可用于用户级进程的CPU模拟，使应用程序能够在与其编译时不同的体系结构上运行。

我们的提案中使用QEMU的主要原因是使测试平台与特定指令集无关，因为它可以模拟许多不同的ISA。

尽管研究人员决定修改模拟器来执行故障注入，但我们的方法不是在这个级别进行干预，而是只关注如何通过调试工具实现故障注入。

与后一项研究一样，作者决定修改QEMU。他们的目的是验证Linux v.4系统调用针对可能的x86 CPU软错误的稳健性。为了加快攻击速度，作者选择使用GNU Parallel来执行更多QEMU实例，同时提高其在多核系统上的性能。

另一方面，一篇文章（参考资料3，关注牛喀网公众号，后台咨询下载）的作者设计了一个系统，其目的与我们的系统类似，但使用Bochs、OpenOCD和Gem5作为仿真系统。

在我们的提案中，QEMU和GDB都没有被修改。我们做出这个选择有两个主要原因。

第一个是使故障注入系统能够注入所有指令集架构，而第二个是，通过这种方式，可以在未来的改进中留出空间，将这些技术用于实际的硬件组件，例如通过使用外部调试和跟踪工具。

第一个原因是微控制器市场上有大量可用的ISAs，而第二个原因是当硬化应用程序在目标中运行时，可以通过硬件在环等技术通过实验确定所选硬化技术的时序开销影响。

2.2.ISO 26262

ISO 26262是专为汽车应用设计的功能安全标准。它于2011年发布。当前版本是第二版，于2018年发布。本标准的核心是安全生命周期，是实现功能安全所需要遵循的过程。其主要思想是防止危险情况，从而避免设计中的系统错误。此外，当无法避免的RHF影响设计时，设计人员必须保证这些要求。

该标准是指在机动车辆内作为一个相关项执行一项或多项安全相关功能的设计。

与所有国际标准组织(ISO)文件一样，ISO 26262（2018年发布的版本）也分为多个部分。它由12个部分组成，其中6个部分描述了安全生命周期。

第3部分称为概念阶段，重点关注危害分析和风险评估、项目定义以及功能安全概念(FSC)的准备，该文件包含功能级别描述的所有安全要求。本文件还定义了所考虑项目的安全目标(SG)。对于概念阶段，提出了一种基于仿真的方法来帮助危害分析和风险评估的过程。

第4部分称为系统级产品开发，定义了技术安全概念(TSC)和技术安全要求(TSR)。正如其名称所示，TSC描述了技术层面的安全要求。此外，还涵盖安全验证以及系统和项目集成和测试，例如硬件/软件接口（HSI）的定义。HSI是标准第5部分和第6部分之间的概念桥梁。

第5部分描述了硬件级别的产品开发。它指定了硬件安全要求、如何设计硬件以防止缺陷（设计缺陷）、如何评估其架构指标，并概述了由于RHF导致的安全目标违规。此外，它还描述了如何执行硬件集成和验证。

第6部分重点介绍软件安全要求、其架构设计以及软件单元的设计和实现。

第7部分描述了该项目的生产、运行、服务和退役。

第11部分包含将ISO 26262应用于半导体的指南。

为了这项工作，我们对第5部分和第11部分感兴趣。无论如何，SIHFT算法应根据第6部分开发。

第5部分介绍失效模式、影响和诊断分析(FMEDA)。FMEDA的核心思想是量化所有可能影响硬件设计的失效模式(FM)对所考虑项目的安全要求的影响。

如果并非在所有情况下都检测到FM，则可以定义其诊断覆盖率(DC)，定义为在所有存在FM的条件下检测到FM的百分比。

借助DC，可以根据硬件设计的ISO 26262分类（潜伏、残余、单点和多点感知）计算。

从ISO 26262的角度来看，本文提出的测试台的主要目的是通过实验确定DC。

第11部分已添加到2018版标准中。正如其标题所示，它包含有关如何将第5部分中描述的分析应用于半导体元件特性的指南。通常，本标准的这一部分提供了解决失效模式的提示，并对汽车应用中使用的数字和模拟组件、存储器、可编程逻辑器件和其他硅IP进行了相应的分析。

我们强调，通过所提出的方法获得的分类不能直接用于计算ISO 26262第5部分要求的RHF指标，因为根本原因的概率分布必须从数字组件制造商提供的安全手册中获得，或者来自（参考资料4，关注牛喀网公众号，后台咨询下载）。

3.提议的方法

本文的提议将其纳入我们研究小组开展的更广泛的活动中。

一方面，我们的主要最终目标是定义转换规则，以强化代码以应对可能的RHF的影响，但为了实现这一结果，有必要设计一种方法来评估所提出的强化策略在DC方面的性能。

3.1.故障模型

当前版本工具中考虑的故障模型是通过分析标准第11部分中包含的表30获得的。

该表包含通常集成到数字组件中的常见IP块的示例FM列表。所包含的元素失效根据功能丢失（需要时不交付）、非预期（不需要时执行）、时间和值（以不正确的值交付）来建模。

它由三列组成：部件/子部件（例如CPU、DMA、中断控制器单元）、功能（部件/子部分在整个系统功能中的作用）和失效模式要考虑的方面（所考虑的部件/子系统失效模型的文本描述，例如CPU的遗漏对应于未执行的给定指令流）。

当前版本的FIM有两种故障模型：Permanent和PermanentStuckAt。

如2.1节所述，故障模型由三个方面来描述：注入什么、何时注入以及在何处（目标）注入。

永久性故障是根据文献中常见的定义来描述的，该定义与电气或门级故障产生的错误分析有关，即从注入到仿真结束，用固定值（永久固定在0或1）替换受影响寄存器或存储器位置字内的位。

有必要指定哪些位会受到故障的影响。这些由我们决定称为bitPosMaks的字段内设置为1的位来指示。

PermanentStuckAt故障被描述为整个受影响的寄存器，该寄存器永久地停留在bitPosMask字段中设置的值。

对于这两种故障模型，目前的目标是程序计数器（PC）寄存器，而注入时间被定义为最小和最大时间之间的矩形概率分布（指定为从应用程序开始的机器指令数）。

这两种故障模型可以与ISO 26262第11部分的表30中报告的失效模式(FM) 进行映射，涉及中央处理单元(CPU)、中断处理(INTH)、内存管理单元(MMU)和中断控制单元（ICU）。我们用斜体字表示标准提供的FM描述，后面是作者发现的永久故障模型（影响PC）的理由。

CPU：

•CPU_FM1.1—由于程序计数器挂起而未执行给定指令流（完全丢失），CPU_FM1.2—由于指令获取挂起而不执行给定指令流程（完全丢失）：

在PC中注入故障，使得控制流跳转到程序区域之外的位置或触发未处理的异常。程序可能会进入死循环。

•CPU_FM2—执行的非预期指令流（非预期）：

在PC中注入的故障导致控制流在程序区域内跳转，但跳转到错误的地址，从而创建与预期不同的指令流。

•CPU_FM3—指令流时序不正确（太早/太晚）：

在PC中注入故障，导致原程序流程中的一些指令被遗漏，导致程序提前/延迟终止。

•CPU_FM4—不正确的指令流结果：

在PC中注入的故障导致控制流在程序区域内跳转，但创建的指令流与预期不同，从而导致错误的结果。

INTH:

•CPU_INTH_FM1—ISR未执行（丢失/过小）：

当收到中断请求时，注入PC的故障不允许执行ISR（PC指向与要执行的ISR不同的地址）。

•CPU_INTH_FM2—非预期的ISR执行（非预期/过大）：

在PC中被注入故障，导致指令流异常进入ISR。

•CPU_INTH_FM3—延迟ISR执行（太早/太晚）：

一旦收到中断请求，PC中注入的故障会将执行流带到ISR之前的地址，其中内存使用NOP进行初始化。然后PC前进到ISR地址。

•CPU_INTH_FM4—ISR执行不正确（参见CPU_FM1/2/4）：

在PC中注入故障，导致控制流在程序区域内跳转，但会创建与预期不同的指令流。

ICU：

•ICU_FM1—对CPU的中断请求丢失：

当收到中断请求时，注入PC的故障不允许执行ISR（PC指向要执行的ISR以外的地址）。

•ICU_FM2—向CPU发出中断请求而不触发事件：

在PC中注入故障，导致指令流异常进入ISR。

•ICU_FM3—中断请求太早/太晚：

在PC中注入故障，导致指令流异常进入ISR（过早）。根据中断请求，注入PC的故障将执行流程带到ISR之前的地址，其中内存使用NOP进行初始化。然后PC前进到ISR地址（为时已晚）。

•ICU_FM4：发送的中断请求包含不正确的数据：

在PC中注入故障，导致执行与正确ISR不同的ISR。

3.2.测试台架

为了进行性能评估，我们提出了如下所述的测试台架。

该系统的核心是FIM（我们提案的控制器），是作者为此目的而设计的。它与三个开源软件平台交互：GCC、GDB和QEMU。

为了实现测试平台，需要C/C++编译器。我们的选择落在了GCC上。它有两个不同的用途。

第一个是针对目标微控制器的架构执行硬化源代码的交叉编译。此编译过程的结果是一个.ELF文件，其中包含机器可执行代码和内存映射信息。

一旦获得.ELF文件，QEMU（用于运行目标的模拟器加载机器可执行代码），而GBD（充当注入器、负载生成器和监视器的日志功能）加载内存映射信息（包括调试符号）。

它的第二个目的是编译分类器（执行监视器的读数分析功能），其源代码由FIM基于配置的监视和选择注入的故障模型生成。

GDB（GNU项目调试器）是完成这个难题的缺失部分，因为它允许FIM与QEMU提供的仿真环境以及在其中运行的软件进行交互。通过这些交互，GDB实现了对仿真环境的管理（主要是启动/停止执行和设置断点）来监控嵌入式软件的执行。此外，它还可以将故障注入到程序计数器(PC)、寄存器文件和仿真系统的存储位置中。

拟议测试台的总体描述如图1所示。

评估流程如下：

1.软件开发人员使用可用工具链之一为目标平台（在本例中为RISC-V RV32I微控制器）编译源代码。我们选择使用RISC-V，因为它是一种开源ISA，正在引起汽车和航天应用的兴趣。

2.准备一个设置文件，其中包含有关要执行的活动的信息。

3.FIM（控制器）启动。它读取设置文件以生成执行注入所需的所有脚本（由图中的CMD文件表示）。除了脚本之外，它还准备分类器源代码。

4.脚本启动。这些通过控制GDB执行黄金运行，然后执行所有所需的注入。对于黄金运行和每一次注入（注入器），都会保存一个包含程序输出的日志文件（监视器的日志任务）。

5.编译并运行分类器，将黄金运行和每个受故障影响的日志作为其输入。

6.分类器结果（每次注射一个）被合并到ISO 26262分类中，如第3.3节所述。

图1.建议的测试台架构。GCC还编译分类器，其源代码由FIM生成。圆形编号框和灰色箭头代表系统的功能流程

3.2.1.FIM设置文件

FIM加载描述故障注入活动的设置文件。它的结构是分层的，顶部是活动，叶子是Watch和故障型号列表。

活动

活动描述如下：

•Watch列表。其中之一称为端表，它定义了终止条件，允许仿真系统确定被测软件组件是否完成其任务。

•要注入的故障列表。

Watch

监视可以是用高级编程语言定义的变量，也可以是通过GDB监视的内存位置。

描述Watch需要以下参数：

•符号：要监视的变量的名称。如果我们想监视内存位置，可以将该字段留空。

•地址：要监视的存储位置的地址。如果符号名称已被定义，则该字段将被忽略。

•描述：Watch的文字描述。该字段有助于自动生成报告，但不需要执行注入，因此留空。

•DetectionWatch和DetectedCondition：如果DetectionWatch为真，则意味着变量/内存地址包含RHF检测机制的结果。DetectedCondition字段包含表示是否发生与DetectionWatch变量相关的检测的条件。

故障表示

故障表示是在工具内部实现故障模型的一种方式，其形式是在指令集级别对所考虑的RHF效应进行半形式化描述。

我们将其称为半形式描述，因为每种类型的故障都对应于执行其注入的GDB脚本。

以下参数（在半形式模型中需要表示内容、时间和地点方面）描述每个故障模型：

•类型：要注入的故障模型。

目前有两种故障：Permanent和PermanentStuckAt。

•目标：目标寄存器的名称。

•bitPosMaks：64位掩码，用于执行故障的按位级配置。

•容错时间间隔(FTTI)：仿真器从注入时间到检测发生期间可以执行的最大允许汇编指令。经过该时间后，最终检测被视为无效，因此在诊断覆盖率计算中不予考虑。

•最小注入时间：从仿真开始到注入故障时刻必须经过的最短时间（以机器指令数来衡量）。

•最大注入时间：从仿真开始到注入故障的时刻可以经过的最长时间（以机器指令数来衡量）。

•持续时间：如果被测软件单元没有设置终止条件，则故障注入后执行的汇编指令的数量。

•注入次数：随机生成并注入先前参数的故障数。

为了开展有意义的活动，需要三个Watch和一个故障。这三个Watch分别是：

•一个终端Watch，让测试台知道软件单元何时结束其功能：如果没有指定，FIM将不知道何时完成黄金运行。

•检测Watch，使分类器能够确定检测机制是否已被触发。

•普通Watch，允许分类器检查有效负载算法的行为是否与黄金运行相同。

3.2.2.分类器

分类器是负责分析从故障注入活动中获得的日志文件的组件。

它将黄金运行和所考虑的故障实例日志文件作为输入。它将测试中的软件组件的结果与黄金运行期间获得的结果进行比较，以确定计算结果是否由于注入的失效而发生变化，并为每次注入提供分类。此外，它还监视检测Watch和终止Watch。

分类器读取所有日志后，将其结果累积以获得符合ISO 26262的分类，重点是通过实验确定强化机制的诊断覆盖率。

它被设计为FSM，其状态转换如图2所示。它具有以下状态：

•潜伏：在注入故障之前。

•注入后的潜伏时间：注入的故障和黄金运行时的行为相同。

•不稳定行为：与黄金时段不同的行为。

•无限循环：PC在原始程序流中不存在的无限循环中移动，但由源代码和有缺陷的PC寄存器之间的交互创建。

•卡在某些指令上：电脑仍然卡在指向有效指令的位置。

•通过软件硬化（检测）：通过软件硬化机制检测。

•HW（机制）检测到：PC指向FLASH/RAM寻址空间之外。

•黄金运行：检测到，输出与黄金运行相同。

•误报：在注入故障之前进行检测。

•此外，状态“未定义”和“错误”表示分类器的内部错误。图2中未显示这些状态。

仅在FTTI过去之前，才允许从注入后的潜伏状态或危险/残留组中的任何状态转换到已检测侧的状态。

相反，当读取了日志文件的最后一行时，会执行从软件强化状态（检测到）到黄金状态的转换，尽管只有在软件组件的行为与整个日志文件的黄金运行行为保持相同的情况下。

图2.分类器FSM

3.3.符合ISO 26262的分类

根据应用程序的行为从分类器结果转变为符合ISO 26262第5部分的分类器结果。

我们只关注检测能力。我们的评估仅基于黄金（无故障）运行和受故障影响的运行之间的比较，并具有以下描述：

•安全：如果检测机制被触发，并且输出与黄金运行中获得的输出相同（无论是由于故障类型还是算法本身，还是由于基于软件的缓解策略）。当然，为了应用这样的假设，需要根据ISO 26262第6部分的规定开发软件组件。

•潜伏：未触发检测，但输出与黄金运行中获得的输出相同。

•危险：未触发检测机制且输出与黄金运行不同的一组失效模式。因此，它还包括多点感知故障。

•残差：基于给定故障的故障注入期间获得的注入后潜伏（假阴性）。

•误报：当检测机制被触发，但尚未注入故障时。ISO 26262没有描述此类（一致地，因为它要求避免出现系统错误，即嵌入式软件中的缺陷），但它很有用，因为我们希望使用此性能评估系统来帮助软件检测策略的开发人员。

此外，正如FMEDA分析中通常进行的那样，由于所需仿真呈指数增长，我们每次仿真仅注入一个故障。

图3以混淆矩阵的形式总结了分类。

图3.符合ISO 26262的建议分类的混淆矩阵

从分类器FSM开始（见图2），每次注入的分类与ISO 26262进行映射，如下所示：

•检测到的安全：针对给定故障最终分类为黄金级的注入百分比。

•检测到：最终由软件或硬件检测机制检测到的给定故障的注入百分比。我们选择将它们命名为Detected，因为没有考虑缓解策略的有效性。

•潜伏：针对给定故障的注入在注入后最终分类为潜伏的百分比。

•危险：给定故障的注入最终导致分类停留在某些指令、不稳定行为或无限循环的百分比。

如果这些注入对应于具有不同参数的同一故障，则这些注入被称为“残留”，而仿真结果被分类为“潜伏”或“已检测”。

“检测到安全”和“已检测到”结果的百分比之和代表ISO 26262描述的诊断覆盖率的实验值。相反，危险百分比累积了所有未检测到的（因此，ISO 26262术语中的单点失效）或剩余百分比给定故障模型的未检测到的运行数。

除了这四种分类之外，如前所述，我们还考虑了误报的百分比。

4.结论

本文重点介绍了一种故障注入系统，旨在评估嵌入式软件实现的检测机制，旨在识别影响数字组件的随机硬件失效。我们的方法可以帮助从事汽车应用的软件开发人员，在这些应用中，安全性和成本要求之间的权衡推动了纯软件策略的采用。因此，我们开发的测试台符合ISO 26262汽车功能安全标准第5部分和第11部分，通过提供理由将影响程序计数器的所选故障模型与标准描述的失效模式进行映射。

为了让软件开发人员能够通过实验评估其应用程序的诊断覆盖率，我们引入了一种新颖的测试平台，该测试平台基于与开源软件平台GCC、GDB和QEMU集成的故障注入管理器。

使用第2.1节中已介绍的分类，所提出的系统具有以下特征。

具有良好的代表性，因为我们考虑了注入损坏的类型和分布来证明所选择的故障模型的合理性：基于我们对ISO 26262描述的失效模式的解释（参见第3.1节），并考虑到有关失效模式的模型可以是检索了数字组件的安全手册。

从可用性的角度来看，由于该系统基于QEMU和GDB，因此所提出的方法表现出良好的可移植性。一方面，QEMU仿真许多ISA，而GDB可以用作每个ISA中的注入器或监视器。使用调试端口，可以注入真实的硬件组件。由于FIM是开源产品，不需要对嵌入式软件进行修改，因此具有较低的侵入性和良好的灵活性。每个故障模型都有一个相对的GDB脚本作为其半形式模型，因此添加更多的故障模型足以定义相应的故障类和脚本模板。

考虑到其效率，由于对注入故障/错误的激活和传播进行了分析，实验数量减少了。此外，它允许实现注入故障/错误的良好激活和传播，并且考虑到影响程序计数器的故障，可以定义一个掩码（在永久故障模型的情况下称为bitPosMask）来设置哪个位可能会受到影响。为此，影响太重要位的注入将产生跳转，这总是导致PC指向程序的文本段之外，而相反，如果涉及的位太低，这会导致针对非对齐的硬件保护干预使用权。

该测试平台与所选的开源软件集成，可管理从故障生成到故障注入和ISA仿真，直至仿真结果分类的所有评估阶段。

分类器分析从故障注入活动获得的日志文件，从而允许通过实施的强化机制确定诊断覆盖率。

我们进行了测试来评估控制流检查基准，获得每次注入的平均执行时间约为31.2秒（包括记录和分类所需的时间）。该持续时间是在配备Intel Core i7 4770K CPU（主频为3.5 GHz）的主机上的虚拟机内运行2000次注入而获得的。黄金运行和受故障影响的运行之间的执行时间非常相似，因为大多数活动都与软件结果的记录相关。

详询“牛小喀”微信：NewCarRen

详询“牛小喀”微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！