基于AUTOSAR的车载软件故障注入测试方法

如今，汽车搭载了大量电子控制系统，这些系统通过网络互联并交互数据。随着电子控制单元（ECU）中软件规模不断扩大，软件故障的发生频率也持续上升。由于汽车软件故障可能引发严重事故甚至造成人员死亡，车辆软件的设计与测试必须将安全性作为核心考量。道路车辆功能安全国际标准ISO 26262推荐将故障注入测试作为功能安全验证的手段，但该标准并未明确规定应注入何种故障、在何时注入、在何处注入。

过去，故障注入测试主要用于验证硬件或软件的容错能力，通过注入故障后检测故障、隔离故障、重构系统与恢复功能，来验证系统的容错性。但以往的故障注入测试多聚焦于硬件故障，即便是软件故障注入测试，在大多数情况下也仅模拟内存、中央处理器（CPU）、通信等硬件类故障。然而，随着车载软件规模扩大与安全重要性不断提升，亟需一种实用的软件故障注入测试方法，在汽车电子嵌入式软件（以下简称“汽车软件”）的开发过程中验证其功能安全。

本文基于汽车开放系统架构（AUTOSAR），提出一种可应用于ECU软件开发过程的故障注入方法。AUTOSAR是为提升汽车软件开发效率而制定的汽车软件标准平台，基于AUTOSAR的软件通常分为四层，相邻层之间常发生调用关系，非相邻层之间则极少产生直接调用。本文定义了AUTOSAR软件组件（以下简称“SWC”）内部及不同层级间可能出现的软件故障类型，并提出在基础软件（以下简称“BSW）层注入软件故障的方法，以实现对所有定义故障的注入。该方法的核心贡献在于：无需使用额外硬件设备即可注入汽车软件中可能出现的各类故障，同时最大限度降低故障注入带来的性能损耗。通过将该方法应用于多款实际汽车软件，验证了其优异的性能。

本文结构如下：第2节论述故障注入测试相关研究；第3节定义基于AUTOSAR的汽车软件故障；第4节提出软件故障注入测试方法；第5、6节分析该方法的效果；最后第7节给出结论并展望未来研究方向。

本节介绍故障注入测试的现有研究，以及适用于基于AUTOSAR的汽车软件的故障类型。

2.1 开发过程中的故障注入

ISO 26262为汽车系统开发提出了V模型，如图1所示。该标准建议在整个开发过程中使用故障注入测试，包括系统开发（硬件/软件集成测试、系统集成测试、整车集成测试）、硬件开发（硬件集成测试）、软件开发（软件单元测试、软件集成测试）。本研究聚焦于软件开发过程中的软件单元/集成测试阶段的故障注入测试。

图1：ISO 26262标准的V模型

2.2 基于AUTOSAR的汽车软件故障注入方法

软件开发阶段可使用的故障注入方法主要分为硬件实现的故障注入与软件实现的故障注入（SWIFI）。

硬件实现的故障注入方法利用硬件特性生成故障，主流硬件故障注入工具（FIT）包括 GOOFI-2、RIFLE，也可通过TRACE32等硬件探针实现故障注入。但这类工具需使用额外硬件设备注入故障，成本高昂，且更适用于硬件或系统开发阶段，而非软件开发阶段。

软件实现的故障注入（SWIFI）无需额外设备，通过运行注入故障的软件代码实现，成本更低。基于AUTOSAR的汽车软件中，SWIFI方法主要分为三类：直接修改软件源代码、使用AUTOSAR钩子函数、为故障注入目标函数封装包装器。

直接修改源代码是直接修改二进制代码的执行逻辑，使目标代码执行时触发故障。该方法可精准在测试者指定位置注入故障，但源代码修改会导致执行流程与原代码不一致。汽车软件对执行时序高度敏感，代码修改引发的时序变化可能导致软件运行偏离预期。

AUTOSAR钩子函数通过在AUTOSAR标准定义的函数中插入任务前、任务后、错误钩子等跟踪代码，实现执行监控或故障注入。该方法在使用标准定义函数时效果良好，但钩子函数的实现效果随操作系统对AUTOSAR标准的实现程度而异，难以适配多种场景。

为故障注入目标函数封装包装器是依据AUTOSAR层级结构创建包装组件，在监控原组件执行的同时注入故障，多数SWIFI均采用包装器实现故障注入。该方法可注入多种故障（如故障注入目标函数的参数、返回值、函数调用故障），但仅依靠软件、无硬件调试器辅助，实现难度较高。

2.3 汽车软件故障类型

开展故障注入测试前，需明确待注入的故障类型。AUTOSAR定义了汽车软件中可能出现的五类错误：数据错误、程序流错误、访问错误、时序错误、非对称错误。

– 数据错误：函数参数、变量、组件间交互消息的数值无效引发的故障。例如丰田汽车突发意外加速事故，即因共享内存存储数据变为无效值引发数据错误。

– 程序流错误：因操作缺失、无效或冗余，导致程序执行偏离预期流程。

– 访问错误：软件尝试访问无权限的资源时触发的故障。

– 时序错误：组件间消息传输过早、过晚或丢失引发的故障。

– 非对称错误：多个软件组件同时接收消息时，收到冲突消息引发的故障。

支持注入上述汽车软件故障的工具包括Kayotee、CANoe、G-SWFIT、GRINDER。

Kayotee是直接修改源代码的故障注入工具，可注入修改变量值的数据错误，但不支持其他类型故障注入。

基于CANoe的故障注入工具利用AUTOSAR钩子函数，可拦截并修改与外部ECU通信的信号或消息，实现数据错误注入，但无法直接修改当前监控的故障注入目标函数的参数或返回值，可注入故障类型受限。

G-SWFIT与GRINDER是采用包装器的故障注入工具，与基于AUTOSAR钩子函数的CANoe不同，可注入故障注入目标函数的参数、返回值或函数调用本身的故障。依据包装器实现方式，基于包装器的方法可实现AUTOSAR定义的五类错误的故障注入。G-SWFIT与GRINDER可在函数调用时，为相关参数或函数本身注入部分故障类型，包括数据错误与程序流错误。

综上，现有汽车软件故障注入工具多聚焦于数据错误。本文提出的方法不仅可注入数据错误，还能实现基于AUTOSAR的应用中全部五类错误的故障注入。

本节阐述汽车软件中故障的注入位置与类型。故障注入位置依据基于AUTOSAR的汽车软件SWC、SWC与其他层级的调用关系推导，最终结合AUTOSAR软件各位置可能出现的错误类型，定义基于AUTOSAR的汽车软件故障。

3.1 AUTOSAR软件层级间的调用关系

向基于AUTOSAR的汽车软件注入故障，需先理解AUTOSAR平台。AUTOSAR是为提升汽车电子嵌入式软件开发效率制定的标准架构，如图2所示。

图2：AUTOSAR软件架构

AUTOSAR定义的软件架构主要由应用软件（ASW）、运行时环境（RTE）、基础软件（BSW）、微控制器抽象层（MCAL）组成。虚拟功能总线概念的RTE层用于提升开发效率，各类SWC部署于RTE层之上的ASW层。可运行实体（Runnable）是实现SWC内部功能、相互调用的函数。但SWC的实现方式各异，因此不同SWC间无直接调用，SWC需通过RTE层与其他SWC通信。BSW层部署操作系统及内存、通信等服务软件，MCAL层部署硬件设备控制相关驱动程序。通常AUTOSAR各层间的调用仅发生在相邻层，但为最大化软件性能，SWC可跳过RTE层直接调用BSW。

基于AUTOSAR的汽车软件中可能出现的调用关系分类如下：

◆ 软件-软件调用关系：

– SWC内部可运行实体间的调用；

– SWC与RTE间的调用；

– SWC与BSW间的调用；

– RTE与BSW间的调用。

◆ 软件-硬件调用关系：

– BSW与MCAL间的调用。

◆ 硬件-硬件调用关系：

– MCAL内部驱动程序间的调用。

3.2 故障注入位置

需依据汽车软件的单元测试与集成测试阶段确定故障注入位置。ISO 26262标准规定：单元测试中，需在软件单元注入破坏变量值、修改代码、破坏CPU寄存器值等随机故障；集成测试中，需通过破坏软件或硬件组件验证安全机制。据此，本文推导故障注入位置，并最终选定“可通过包装器实现故障注入的位置”作为本文方法的故障注入位置。

软件单元测试的故障注入位置包括：软件单元内部语句（关键字、大括号、序列）、一元/二元运算符、变量（标量变量、全局变量、数组、指针、结构体）、常量。但除全局变量外，所有单元的故障注入仅能通过直接修改代码实现。因此，本文采用包装器的故障注入测试中，单元测试故障注入位置限定为全局变量。

软件集成测试的故障注入目标为软件组件间的集成接口。AUTOSAR中组件按层级划分，因此3.1节所述层级间调用关系即为故障注入位置。层级间调用包含调用方（caller）与被调用方（callee），本文对两类函数分别应用接口变异算子，推导故障注入位置。

汽车软件单元测试与集成测试阶段的故障注入位置如下：

◆ 软件单元测试阶段：

– SWC可运行实体使用的全局变量。

◆ 软件集成测试阶段：

– 层级间调用关系中的调用方函数：函数调用参数、调用语句本身；

– 被调用方函数：来自调用方的接收参数、被调用方内部使用的变量、返回语句。

3.3 故障类型

如2.3节所述，基于AUTOSAR的汽车软件存在五类错误：数据错误、程序流错误、访问错误、时序错误、非对称错误。本文分析错误成因，推导故障类型，如表1所示。

表1：故障类型

3.4 基于AUTOSAR接口的汽车软件故障

将3.3节所述故障类型应用于3.2节推导的各故障注入位置，基于AUTOSAR接口重新定义汽车软件故障。数据错误应用于全局变量、函数参数、返回值；程序流错误与时序错误应用于调用方函数的调用语句、被调用方函数的返回语句；访问错误仅应用于调用关系中共享的全局变量；非对称错误应用于为容错设计冗余机制时的返回值。具体定义如表2所示。

表2：基于AUTOSAR接口的汽车软件故障

如图3所示，为向汽车软件注入3节定义的故障，需先分析汽车软件二进制代码执行流程生成故障，再将故障集成至汽车软件完成注入。故障生成分为故障注入位置提取模块与故障注入代码生成模块；故障集成至汽车软件分为故障注入目标监控模块与实际执行故障的故障注入模块。

图3：ASFIT：基于AUTOSAR的汽车软件故障注入方法

4.1 故障注入位置提取

表2定义了各测试阶段的故障注入位置，通过对故障注入测试目标软件的可执行二进制文件进行静态分析，推导故障注入位置。推导故障注入位置的核心是提取可运行实体与任务。可运行实体是与C函数共同实现SWC内部指令执行的单元，任务是可运行实体的集合，一个可运行实体可归属多个任务。可运行实体是SWC运行的核心，因此本文将可运行实体作为故障注入的最小单元，同时作为监控任务调用与管理可运行实体、执行故障注入的单元。基于任务与可运行实体，提取可运行实体使用的全局变量、可运行实体调用的其他可运行实体、RTE/BSW层函数。

从汽车软件二进制文件中提取的故障注入位置包括：

– SWC内部的可运行实体；

– 各可运行实体归属的任务；

– 可运行实体使用的全局变量；

– 调用关系（可运行实体-可运行实体、SWC可运行实体-RTE、SWC可运行实体-BSW）中的可运行实体或函数原型（参数、返回值）。

4.2 故障注入代码生成

故障注入代码是一种包装器函数，在监控故障注入位置函数的同时，在故障注入时机触发故障注入。包装器函数分为任务包装器（T_wrapper）（负责监控）与故障包装器（F_wrapper）（负责实际注入故障）。T_wrapper 监控当前运行的任务是否属于故障注入位置，若是则调用F_wrapper注入故障，再继续执行原任务。

图4 为在任务FuncOSTask_ASW_FW1_100ms中，SWC-RTE 层间函数调用时注入“未调用函数”故障（表2故障ID 15）的示例。图4 (a)为T_wrapper，先检查故障注入是否启用，再检查当前任务调用的函数是否为故障注入目标函数，若是则调用图4 (b)所示的F_wrapper。

图4：故障注入代码示例

4.3 T_wrapper

2.2节对比了直接修改代码、使用AUTOSAR钩子函数、使用包装器三种基于AUTOSAR的汽车软件故障注入方法，本文采用基于包装器的故障注入方法。使用包装器函数的核心优势是：通过调用包装器函数替代原函数注入故障，可生成表2定义的各类故障。

使用包装器注入故障时，需关注包装器对原程序执行的影响。基于AUTOSAR的汽车软件是强实时嵌入式系统，对时序约束要求极高，因此故障注入需将时间开销降至最低。

为最小化故障注入开销，本文监控包含故障注入位置的任务，而非直接监控故障注入位置。若监控的任务包含故障注入位置，则调用包装器注入故障。换言之，无需监控SWC内部所有可运行实体调用、SWC可运行实体、RTE/BSW/MCAL层所有函数调用，仅监控由多个可运行实体组成的任务，即可判断位置是否为故障注入目标，从而降低开销。

如图5所示，故障注入位置为SWC_runnable_1()与SWC_runnable_2()间的调用。若要监控任务1的所有故障注入位置，需监控任务1的所有可运行实体调用、SWC_runnable_1()与SWC_runnable_3()内部所有调用关系，至少需监控6次调用。该方法开销极大，因为每次调用都需判断位置是否为故障注入目标。

图5：任务监控与故障注入示例

本文方法仅监控任务本身，对任务1仅执行一次监控。任务1运行时，检查其调用的可运行实体是否包含故障注入位置，若是则立即注入故障。该方法无需每次层间调用都执行检查，节省开销，实现轻量化故障注入。

4.4 F_wrapper

本文故障注入方法为故障注入目标函数封装包装器，但不为故障注入位置单独创建包装器。如4.3节所述，本文方法在运行包含故障注入目标的任务时，通过BSW层函数的包装器注入软件故障。

实际上，基于包装器的故障注入方法，会因包装器函数所属层级不同而存在差异，如表3所示。同时，可注入故障的调用关系与故障类型，也会因包装器函数所属层级不同而变化。

在SWC层生成包装器并注入故障，仅能注入数据错误与程序流错误，因为SWC无法调用与通信、内存管理相关的BSW层函数。

表3：基于各AUTOSAR层级的包装器故障注入方法

在BSW层生成包装器，因BSW层函数负责执行控制（任务模块）、内存管理（内存模块）、通信控制（通信模块），可实现从SWC到ECU硬件层所有AUTOSAR层级的全部五类故障注入。

待注入的软件故障与故障注入位置相关，故障注入位置可能是SWC内部可运行实体间调用，或SWC与RTE/BSW/MCAL层函数间调用，如表3所示。本文为这些故障注入位置对应的各函数创建包装器，仅为BSW层函数实现包装器，而非同时执行故障监控与注入。仅为BSW层函数生成故障注入包装器，可实现与直接向SWC或RTE层注入故障相同的效果，且包装器函数能最小化新增代码，进而最小化执行二进制文件体积。

以故障ID 7为例，为可运行实体-可运行实体调用中被调用方可运行实体的全局变量注入“无效地址”故障。注入故障前，如图6 (a) 所示，SWC_runnable_1()调用SWC_runnable_2()时，被调用方SWC_runnable_2访问的全局变量地址位于非保护内存区，可正常访问。采用本文方法注入故障时，如图6 (b) 所示，任务1运行前先执行BSW层的T_wrapper，调用故障注入F_wrapper（①）；F_wrapper将SWC_runnable_2访问的variable_1所在内存注册为操作系统保护内存（②）；随后执行原任务1（③），SWC_runnable_2()访问variable_1时，因访问无权限内存区触发访问错误。

图6：可运行实体中变量的无效地址故障注入

值得注意的是，若不使用BSW层的F_wrapper，直接为SWC_runnable_2()（本示例故障注入位置）封装包装器注入故障，仅能修改变量variable_1的值，无法将变量地址修改为操作系统保护内存区、实现无效地址访问故障注入。

针对本文定义的故障类型，对比使用ASFIT与现有故障注入方法注入汽车软件故障的效果。

5.1 实验设计

本实验目的是通过对比现有故障注入方法与本文方法对表2定义故障的支持程度，验证本文方法的优越性能。选取2.2节所述硬件实现与软件实现（SWIFI）的故障注入方法作为对比对象，如表4所示。

表4：实验所用的故障注入方法

不同ECU的特性差异会导致可出现的软件故障不同，因此实验选用多款ECU，注入表2定义的所有汽车软件故障类型。如图7所示，实验目标ECU包括：车身控制模块的雨刮控制系统（负责车内便捷设施控制）、电子转向柱锁（ESCL）控制系统（智能钥匙控制）、基于移动开放平台的车辆控制单元（VCU）（信息物理系统实验开发的车辆行驶系统）。

图7：实验所用的目标ECU

5.2 实验结果

各故障注入机制可注入的软件故障如表5所示。本文提出的ASFIT可注入全部54种故障，而其他方法仅能注入12至42种故障。

表5：可注入的软件故障

5.3 分析

图8 (f)对比了ASFIT与其他故障注入方法在全部54种故障中的可注入数量。ASFIT可注入全部54种故障，软件类故障注入工具可注入5-23种，硬件类故障注入工具可注入42种。图8 (a)-8 (e) 按错误类型展示 54 种故障的测试结果。

图8：基于AUTOSAR的可注入故障数量对比

软件类故障注入工具Kayotee、CANoe、G-SWFIT仅能分别注入5种、12种、12种数据错误相关故障，如图8 (a)所示。如表4所述，CANoe与G-SWFIT仅能注入修改变量、修改函数调用关系参数或返回值的数据错误；Kayotee仅能注入软件使用变量的数据错误。三类工具均无法注入程序流错误、访问错误、时序错误、非对称错误相关的软件故障。

另一款软件类故障注入工具GRINDER依据ISO 26262标准，可在AUTOSAR各层注入位翻转、基于数据类型的损坏、时序故障，但位翻转与数据类型损坏故障仅能注入调用关系函数，无法注入全局变量数据错误；同时不支持CPU时钟损坏（属于时序错误，由MCAL层CPU时钟控制实现）的故障注入，也不支持除数据、时序错误外的访问错误、程序流错误、非对称错误故障注入。

TRACE32、GHS Probe、CW IDE等硬件调试器类故障注入工具，通过在源代码中添加断点，可在指定位置注入故障。这类工具可注入大部分故障，但无法注入部分时序错误、访问错误、非对称错误。时序错误方面，可通过断点暂停执行后修改数据，实现数据丢失、CPU时钟损坏故障注入，但无法注入执行过程中的数据延迟、无响应等故障。

ASFIT的最大优势是：与其他方法不同，可注入所有访问错误、时序错误、非对称错误相关故障。汽车软件是由多款ECU组成的强实时系统，共享内存管理至关重要，且需避免ECU交互时的延迟。同时，软件执行中出现的故障需精准传递给交互的其他ECU，因此必须通过访问、时序、非对称错误的故障注入验证功能安全。下文结合这类故障的具体案例，深入分析ASFIT方法。

◆ 案例1（ESCL访问错误）：故障ID 7——可运行实体-可运行实体集成测试阶段，被调用方全局变量无效地址故障注入

ESCL通过车辆智能钥匙实现车轮锁止与解锁。注入的故障用于校验ESCL硬件与控制系统间的车辆方向盘锁止状态一致性，随后将ESCL供电变量的地址修改为无效值。该故障发生时，因无法读取变量值，ESCL无法正常供电，包含ESCL控制相关可运行实体的任务会为安全重启。

该故障在SWC内部可运行实体集成阶段注入。如图9所示，可运行实体EsclConsistencyCheck()调用ESCLPowerSupply()时，注入的故障修改了被调用方ESCLPowerSupply()中使用的全局变量b_ESCLPowerSupplied的地址。

图9：案例1：使用ASFIT进行访问错误故障注入

ESCLConsistencyCheck()与ESCLPowerSupply()间的调用在任务FuncOSTask_BSW_FG3_AppModeRequest()执行时发生。因此，对应任务的 T_wrapper 先判断是否为故障注入目标，再调用F_wrapper注入故障（①），最后调用原任务（②）。访问错误是访问无权限地址的故障，因此将全局变量b_ESCLPowerSupplied的地址注册到操作系统管理的保护内存中。当ESCLPowerSupply()尝试访问该变量时，因无访问权限触发访问错误。

为验证ASFIT故障注入效果，在汽车软件运行环境中，故障注入代码执行时控制LED状态：未注入故障、正常运行时，LED保持初始全亮状态；注入故障时，故障注入函数关闭指定 LED；目标板重启或安全机制调用LED控制函数后，LED恢复全亮初始状态。

图10 (a) 中左侧第三个LED熄灭，证实故障注入引发访问错误；故障注入后任务重启，所有LED恢复全亮（图10 (a)），说明本文定义的安全机制正常生效。

图10：故障注入结果

现有软件类故障注入方法不支持修改操作系统保护的内存区，硬件类故障注入方法若无操作系统完整源代码，难以定位操作系统保护内存区。与之不同，ASFIT生成故障注入代码时，可从二进制文件中定位操作系统保护内存区，实现故障注入。

◆ 案例2（ESCL 时序错误）：故障ID 13——SWC-RTE集成测试阶段，调用方参数数据延迟故障注入

ESCL通过车辆智能钥匙实现车轮锁止与解锁。注入的故障延迟通信交互数据的数值，校验ESCL硬件与控制系统间的一致性。

该故障在SWC内部可运行实体调用RTE函数时注入，属于SWC与RTE层集成测试阶段故障。可运行实体EsclControl()调用Rte_Write_P_ConsistencyCheck_L_ESCLUnlock()时，注入的故障延迟调用方EsclControl()传输的参数l_ESCLUnlock的数值。该故障发生时，无法校验ESCL硬件与控制系统间的一致性，触发安全机制——在一致性校验通过前，切断ESCL供电。

图11详细展示故障注入流程。包含SWC-RTE调用（故障注入位置）的任务的T_wrapper调用F_wrapper注入故障（①），再调用原任务（②）。此时F_wrapperTE_Delay()将SWC-RTE调用代码中RTE函数的地址修改为Delay()函数地址，触发故障。

图11：案例2：使用ASFIT进行时序错误故障注入

与案例1一致，为验证ASFIT故障注入效果，在汽车软件运行环境中，故障注入代码执行时控制LED状态。故障注入后LED熄灭，ESCL重启，随后所有LED恢复全亮，证实本文设计的安全机制正常生效。

该故障可通过软件类故障注入方法实现，但无法通过硬件类故障注入方法实现。如前文所述，硬件类故障注入方法需暂停程序执行注入故障，但与分配内存或寄存器值修改不同，数据延迟需添加执行代码，必须重新编译软件。

◆ 案例3（非对称错误）：故障ID 40——SWC-BSW集成测试阶段，被调用方返回语句非对称数值故障注入

VCU负责车辆行驶相关控制（电机、方向盘等）。注入的故障在系统发生错误时，调用向全系统通知错误的函数，此时修改单次调用的错误数值（不发送统一数值）。该故障发生时，系统依次停止运行并关机。

该故障发生在SWC与BSW层集成测试阶段。如图12所示，故障注入发生在SWC中：调用Det_ReportError()时，被调用方Det_ReportError()向其他SWC或ECU传输的错误值，仅针对特定SWC单独修改。该故障发生时，触发依次停止所有操作、关闭系统的安全机制。仅通过LED状态难以验证安全机制运行效果，因此本案例通过串口连接目标板进行调试验证。

图12：使用ASFIT进行非对称错误故障注入

图12展示ASFIT故障注入流程。非对称错误场景下，系统任意位置发生故障或事件时，为向全系统传递故障/事件的BSW层函数生成T_wrapper。本案例中，T_wrapper的生成目标是向其他SWC与ECU传递故障的函数Det_ReportError()。T_wrapper_wrap_Det_ReportError()调用F_wrapper注入故障（①），再调用原函数（②）。此时故障注入函数ASE_value()仅针对特定调用方修改错误数值，生成非对称错误。

向全系统发送统一数值的故障可通过其他故障注入方法实现，但在系统需发送统一数值的场景下，仅向部分系统发送不同数值的故障，无法通过硬件或软件类故障注入方法实现。ASFIT 通过向错误报告函数的特定调用关系单独注入故障，实现非对称故障注入。

汽车软件对实时性要求极高。注入表2所列全部软件故障固然重要，但性能（尤其是运行时开销）测试同样关键。故障注入导致的任务执行延迟，可能引发除注入故障外的副作用。

6.1运行时开销测量

硬件类故障注入工具TRACE32、GHS Probe、CW IDE为硬件调试器，注入故障前会临时暂停程序，因此排除在运行时开销测量范围外。仅测量软件类故障注入工具（基于CANoe的故障注入工具、G-SWFIT、GRINDER）的开销，并与ASFIT对比。Kayotee因直接修改软件向故障注入位置注入故障，排除在测量范围外。

仅测量表2中AUTOSAR五类错误里数据错误相关软件故障的运行时开销。时序错误是延迟数据传输或不传输数据，与运行时无关；程序流错误是不调用函数或访问寄存器终止执行，任务执行无关紧要；非对称错误与访问错误无法应用于其他方法，且运行逻辑与数据错误相似，因此排除。

故障注入时机也会影响运行时开销。例如，首次调用故障注入函数时注入故障，直接修改源代码的方法运行时开销始终最小。因此，本实验在故障注入目标函数第五次调用时注入故障。

运行时开销通过在系统中重复执行故障注入目标任务10000次，测量应用故障注入方法前后的平均时间，按以下公式计算：

6.2 性能测量结果

图13展示ASFIT与软件类故障注入工具（基于CANoe的故障注入工具、G-SWFIT、GRINDER）的运行时开销测量结果。结果显示，ASFIT运行时开销最低，较原运行时间仅增加1.24%；采用AUTOSAR钩子函数注入故障的基于CANoe的故障注入工具，运行时开销为3.22%；基于包装器的故障注入方法G-SWFIT与GRINDER，运行时开销分别为2.0%与6.34%。

本研究基于汽车软件平台AUTOSAR的不同层级间调用关系，定义了汽车软件中可能出现的软件故障类型，并提出针对这些故障的软件故障注入测试方法。该方法采用软件实现方式，无需额外硬件设备，即可注入表2定义的所有汽车软件故障，同时最大限度降低故障注入带来的运行时开销。

本文将所提方法实现为ASFIT，并通过案例研究与主流现有软件、硬件类故障注入方法对比。结果表明，ASFIT可实现其他故障注入方法无法注入的访问错误、非对称错误故障注入，也可实现其他方法仅能部分注入的数据错误、时序错误故障注入。此外，故障注入方法运行时开销测试显示，除硬件类故障注入方法与直接修改代码的工具外，ASFIT的运行时开销最低，证实其轻量化特性。

如第5节实证研究所述，韩国某汽车公司已在软件开发阶段，采用本文提出的软件故障与故障注入方法，对多款基于AUTOSAR开发的ECU开展故障注入测试。本文注入的故障中，非法指令引发的程序流错误、CPU时钟损坏引发的时序错误等故障，效果会随硬件差异变化。未来将把该方法应用于更多类型ECU，提升通用性；同时将方法扩展至系统开发阶段的软硬件集成测试阶段。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。