自动驾驶仿真测试：仿真测试的各种手段

自动驾驶仿真测试：仿真测试的各种手段

“ 经常有朋友问如何学习仿真测试，于是想着把自己的一些经验和理解分享出来，希望能有所帮助。不过视野和技术有限，所说不一定对，供大家批评和参考。这是第14篇，模拟仿真测试各种手段”

仿真测试系统可以通过模型或者设备模拟车辆行驶过程中的环境、传感器和车辆情况，创建自动驾驶系统的闭环运行环境，在车辆开发的不同阶段对自动驾驶系统进行测试。在不同的开发阶段，作为被测对象的自动驾驶系统也可能具有不同的形态，如算法软件或者控制器。因此，仿真测试也被称为在环测试（XIL，x in the loop），“X”代表不同形态的被测对象（即自动驾驶系统），“the loop”代表被测对象接收输入、进行计算、对被控对象（即自动驾驶车辆）进行控制、被控对象状态变化并再次被被测对象接收、进而周而复始的运行“闭环”，如下图所示。

在环测试方法在基于模型的设计方法（MBD，Model-Based Design）得到了广泛应用，并在自动驾驶仿真测试中进行了适配和发展。

附赠自动驾驶最全的学习资料和量产经验：链接

1. 基于模型的设计方法

基于模型的设计方法是一种以模型为核心的嵌入式软件设计方法，模型中包含了与系统表现相关的各项内容并贯穿整个开发流程。基于模型的设计方法支持进行系统和部件级的设计及仿真、自动代码生成和持续的测试验证。其开发流程如下图所示。

1.1 需求管理

不同于传统工作流程中使用文档管理需求，基于模型的设计方法中采用模型管理需求。整个流程的第一步便是将需求转化为可执行的模型文件，该模型是一个高级别低保真度的系统架构模型，包含了所有设计信息，如预期实现的功能、系统组件和关系、输入输出等。

使用模型管理需求的好处是：模型比文档包含更多的信息，而且是明确的、不需要解释，可以方便的在不同人员之间进行无歧义、无遗漏的沟通。

1.2.设计

设计的过程也是分层建立模型的过程：系统设计会建立系统级的模型，组件设计会建立组件级模型。建模时使用MBD开发工具（如Mathworks Simulink）进行图形化操作。

模型不仅包括预期开发的功能模块的模型，也包括被控对象和环境的模型，这便于在不同的开发阶段、随时进行充分的仿真测试。系统级仿真可验证系统设计是否满足了所有需求、各模块间的逻辑和信号交互是否正确，同时可以对各种设计思路进行快速评估和验证；组件级仿真可用于验证组件设计是否满足功能要求。

1.3.实现

这一步骤中进行各组件功能、算法的详细设计和实现，实现的过程也是模型逐步细化、迭代测试、并自动生成代码的过程。下面对不同开发阶段和采取的仿真测试手段进行说明。

1.3.1. 模型细化和模型在环测试

模型细化过程中，可以视需求进行仿真测试。此处的仿真测试和设计阶段进行的仿真测试，都为模型在环测试（MIL，Model-In-the-Loop）。模型在环测试的被测对象是算法模型，测试目的是验证算法模型功能是否完整、正确。测试闭环中的被控对象也为模型，两者都运行在模型开发环境（如Windows电脑上的Simulink中）。

算法模型的功能验证、改进完毕后，可通过MBD工具自动生成代码。自动生成代码是MBD的一个显著优势，可大幅提高开发效率并减少代码错误。由于自动代码生成工具的配置、模型由浮点向定点转化等原因，可能引入一些错误，因而也要对自动生成的代码进行充分测试。

1.3.2. 代码自动生成和软件在环测试

对自动生成的算法软件进行的测试，称为软件在环测试（SIL，Software-In-the-Loop）。软件在环测试的对象是自动生成的算法软件，测试目的是验证自动生成的代码功能是否与算法模型一致。从而，软件在环测试有两种思路：

（1）采用带被控对象的闭环测试，测试闭环中的被控对象依然为模型，算法软件和被控模型都运行在模型开发环境。采用和模型在环测试一致的测试用例，验证算法软件功能是否完整、正确；

（2）采用不带被控对象的开环测试，在模型在环测试时记录不同测试用例的输入和输出，并将相同的输入信号发送给算法软件，查看算法软件的输出是否与算法模型一致；或者是并列连接算法软件和模型，并比较两者输出是否一致。

1.3.3. 软件下载和处理器在环测试

之后便可将算法模型交叉编译为适配目标处理器的代码，并下载到目标处理器上，验证算法软件在目标处理器上的运行情况。这一仿真测试的手段，称为处理器在环测试（PIL，Processor-In-the-Loop）。处理器在环测试的对象是运行着算法软件的处理器，测试目的是验证算法软件在目标处理器上的运行情况，本质也是验证其表现是否与算法模型预期的一致。从而，处理器在环测试也有两种思路：

（1）采用带被控对象的闭环测试，测试闭环中的被控对象依然为模型，算法软件运行在目标处理器上，被控模型运行在模型开