自动驾驶协同测试白皮书 | MIL环境下的故障注入测试

2022年ASAM Evolving Landscapes of Collaborative Testing for ADAS & AD白皮书正式发布。前序推文为读者梳理了ADAS & AD新测试策略蓝图中的SIL和hil测试，本篇将详细介绍MIL环境下的故障注入测试。

01

MIL环境介绍

MIL（Model in the Loop，模型在环测试）是在基于模型的开发环境中测试单个或集成模块，即对模型在模型的开发环境下进行仿真，通过输入一系列的测试用例验证模型是否满足了设计的功能需求。

关于新测试策略蓝图下的MIL测试，在“自动驾驶协同测试白皮书 | 深度解读新测试策略蓝图之模型在环测试”一文中有提及，读者可进行回顾。

02

故障注入测试详解

故障注入测试(Fault Injection Test, FIT)，是一种常用的软件测试方法。其是标准ISO 26262流程模型右侧测试环节的重要部分，分布在软件单元验证、软件集成验证、软件验证、硬件测试验证、软硬件集成验证、系统集成与测试验证及整车集成与测试验证共7个开发环节。

ISO 26262总体框图

故障注入测试用于模拟软件系统中可能出现的各种故障情况。在这种测试方法中，工程师会“故意”向软件系统中引入各种故障，以检测和评估系统的可靠性和稳定性，从而提高软件系统的质量。

故障注入技术最早主要应用于航空航天工业领域中的可靠性测试，后来在计算机科学领域中也逐渐得到了广泛的应用。目前，故障注入技术已经成为了软件测试中非常重要的一环，被广泛应用于飞行控制、火车信号、工业自动化等领域。

某领域的故障注入系统示例

而在自动驾驶系统中，故障注入测试主要包括两个目的：一是检查旨在以容错方式（in a fault-tolerant manner）实现的功能是否确实维持了故障。二是分析非容错功能（not-fault-tolerant functionalities）在由于特定故障而发生故障时的行为。

03

MIL环境下的故障注入测试

对于基于需求的MIL测试，模型级别的故障注入测试旨在发现功能模型中的缺陷。这与后面的测试活动，例如硬件在环测试不同，硬件在环测试是在被测系统已经假定甚至要求没有错误的阶段进行的。

而MIL测试是发生在模型开发后不久，甚至在模型开发期间。因此，与硬件在环测试相比，故障注入测试的反馈周期相对较短，纠错成本更低。此外，故障注入测试在MIL环境非常有效且高度自动化，可以每分钟对系统进行数百次故障测试，进而产生完全可再现的结果。

当然MIL环境下的故障注入测试也存在局限性。例如，MIL测试无法模拟不属于环境模型部件中的故障，如传感器故障。在这些情况下，只能模拟故障对模型的预期影响，这足以用于测试驱动开发，但不能用于适当的系统确认。同样，也很难在MIL环境测试硬件鲁棒性，该测试涉及对设备施加物理应力。

04

测试用例

下面的测试用例将描述如何在MIL测试环境应用故障注入测试，以及在哪些情况和方面可以补充在硬件级别执行的经典故障注入测试活动。

如前所述，MIL故障注入测试非常适合在发生故障的情况下检查和评估功能模型的行为，主要检查功能模型对故障的反应。诸如回退模式甚至容错控制之类的措施通常在软件中实现，并且已经是代码派生或生成的功能模型的一部分。在这些情况下，名义上被称为“故障”的内容只是被测模型的另一个有效输入。

另一种情况是发生在被测模型内部的故障。无论是外部故障还是内部故障，都可以使用适当的MIL测试工具进行模拟和评估。

一般故障注入MIL测试流程

通常，故障注入测试的依据是一份测试文档，该文档对不同类型的故障以及它们可能、必须和不能对功能系统产生的影响进行了归档和规定。从这些文档中，测试工程师得出了他们想要测试系统的特定故障的半形式定义。这些可能是外部或内部故障，甚至是这两种故障的组合。

根据这些定义，可以得出具体的测试规范，通常遵循通用模式：

除了模拟之外，文档还应包含对预期内部和输出信号方面故障的预期反应。故障注入测试通常以闭环方式应用，即受测系统的输入端口由环境模型刺激，而环境模型反过来消耗其输出。在大多数情况下，环境模型和被测模型都不提供任何故障注入机制。因此，测试工具需要定位应注入故障的变量/信号（variables/signals），并用指定的故障值覆盖它们。

在模拟过程中，必须获取所有相关数据。这些数据尤其包括（常规）模拟（regular stimulation）、注入故障的所有变量/信号（all variables/signals with which a fault is injected），以及所有输出信号和内部信号（all output signals and all internal signals）。通过这些信号，可以了解发生故障时系统的行为。

对于基于需求的MIL测试，可以在后处理步骤中根据预期信号自动评估记录的信号，然后提取/生成便于阅读的测试报告。

05

自适应巡航控制示例

以自适应巡航控制（Adaptive Cruise Control, ACC）为例，考虑该系统针对环境模型进行测试，该环境模型为被测自适应巡航控制模型提供所需输入，包括与前车距离的模拟传感器值。

简化ACC模型示例

容错技术规范（the fault tolerance specification states）规定，距离传感器的（突然）故障不得导致ACC触发硬（潜在危险）减速。

在本例中，故障被注入到闭环内被测模型的模拟中。根据传感器的电气特性，测试工程师确定两个不同的逻辑信号值，这两个值可能会在传感器故障时提供给系统：0和NaN。

下面提供一个参数化的测试规范，测试中可以在8秒内将领头车（the lead car）加速到40公里/小时，此后保持不变，此时ACC已启用。本车(the ego car)在40米的距离处跟随领头车。在达到40公里/小时的最终速度两秒后，通过参数立即覆盖距离值来注入故障。

模拟将继续进行5秒钟。在整个过程中，至少捕捉到了以下信号：前车速度、本车速度、前车距离和加速度。有一点需要注意的是，其中一些信号是环境的内部信号。

生成两个测试用例实现，参数值分别为0和NaN，并自动执行。为了评估测试，扫描自适应巡航控制模型的加速度输出，以确定低于法定阈值的值。之后，可以生成故障注入测试报告，并根据研究结果将报告传回模型工程师或存档。

下表列出了所示示例的一些要求和特征，以便根据通用标准与其他用户历程进行快速比较。

有关测试规范的需求