05在环测试

MIL、SIL、PIL、HIL在环测试简介
在进行车载软件开发时经常会听到MIL、SIL、PIL和HIL等各种测试，它们都是什么意思呢？它们之间的区别是什么呢？

XIL 在环测试
XIL, 其中的IL是In-the-Loop在环的意思。In-the-Loop又是什么意思？这个又涉及到我们平时经常听“闭“”这个概念。

闭环
学术上，严谨的“闭环”概念是在控制论中出现的。较为抽象的定义是：当我们要准确控制一个系统的行为时，我们根据系统的输出来校正对它的输入，以达到较为准确的控制精度。因为系统的输出会导入到输入端的计算，形成一个不断往复的循环，称之为闭环(Closed Loop)。
通俗的例子，我们要把鼠标移到屏幕中的某一个目标位置，我们手在移动鼠标的过程中，眼睛观察当前位置与目标位置，大脑计算两者之间的偏差，控制手中鼠标指针移动的方向和速度。移动过程的前一段会快一些，到目标位置附近再做精细调节。眼睛观察到到的新的鼠标偏离会导入到大脑中用来计算手部移动的距离。不断循环这个闭环过程，只到鼠标到达目标位置。看起来很简单，但却是一个非常通用的过程。自动驾驶的车辆控制算法、远程导弹的制导都是类似的过程。
我们用一个具体的例子来说明。

研发闭环和运行时闭环
如前文所述，“闭环”是一个很通用的概念，可以出现在很多领域，尤其在自动驾驶系统的研发和运行过程中处处可见。为了更准确的描述本文的话题，我们先澄清容易误解的概念。这里先区分“研发闭环”(Develop Closed Loop)与“运行时闭环”(Runtime Closed Loop)。

我们用一个具体的例子来说明。

自动驾驶功能中比较基础的功能是“车道居中”，即在有车道线的情况下，保持车辆沿车道中心线行使。这个功能的关键技术是两项：车道线识别的视觉感知算法和横向车辆控制算法。

其“运行时闭环”就是：车辆行使过程中，摄像头采集前方道路图像，识别出车道线并转换成合适的坐标系，估算当前车辆在车道中的位置，控制算法接收车道线信息、车辆位置信息、车辆自身的速度、方向等信息，控制方向盘的角度或扭矩。整个闭环周而复始的运转，保持车辆居中。

这个运行时闭环的标的是“保持车辆居中”，闭环的偏离定义为车辆方向与车道中线方向的偏离，反馈回路是根据偏离计算出的横向控制指令再控制车辆状态发生变化。

而“研发闭环”是开发这个“运行时闭环”的研发、测试和集成过程。我们可以为上述运行时闭环设计两个独立的研发闭环，一个用于开发和测试感知算法，从视觉图像中计算车道线，并根据通过其它手段获（如仿真系统）得的车道线真值验证计算是否正确，这个研发闭环反复迭代，持续改进算法；另一个研发闭环之间获取车道线的真值，只是开发和测试横向控制算法。这两个研发闭环可以独立进行，最后集成在一起。

在环测试
一般我们对自动驾驶数据闭环的理解就是：驾驶专业采集车或者通过量产车辆采集数据，用来改进各种算法、发现并解决驾驶场景中出现的各种问题，改进自动驾驶系统，形成自动驾驶能力的闭环迭代。

这个理解本身并没有问题，但是这么复杂的系统，如果没有一个合适的层级分解，直接就整个复杂系统的进行讨论，那就是在讨论一个玄学问题，而不是一个工程问题。
一个大的研发闭环是由一系列相互关联的小闭环组成特定。有的是层级关系，大闭环内有小闭环。不同小闭环之间还有相互衔接的形式。我们来看具体的例子。

上图演示了车辆控制算法开发时4个可能的闭环（A，B，C，D）。
一般车辆控制算法做原型开发时会直接使用“闭环B”，在这个闭环中，控制算法是使用Model Based Development 模式开发，常用的是使用MATLAB+Simulink构建算法模型，模型生成的C代码会编译运行在一个快速原型设备（如：dSpace AutoBox）,快速原型设备与车辆总线相连，通过车辆线控系统控制车辆运行。
但是“闭环B”是需要实际的车辆的，当车辆未就绪或者资源不够时，我们可以先采用“闭环A”，这个闭环中我们使用软件仿真工具代替车辆，仿真软件可以配置模拟车辆(ego car)的动力学参数，给出ego car 周围环境的真值出道路环境的真值。这样控制算法开发人员可以脱离车辆，先在桌面进行开发，而且感知结果使用的是真值，相当于减少了可变量。

“闭环C”与“闭环A”的差别在于去掉了快速原型设备，使用一块MCU开发板来运行控制算法模型生成的 C 代码。这可以用来验证控制算法模型转换成 C 代码后是否正确。这个MCU应该就是我们量产时打算使用的芯片，但是量产硬件的开发还需要时间，我们可以使用厂家提供的开发板来快速搭建试验环境。可能导致不正确的原因至少有：

Simulink模型转换成 C 代码时有错误，可能需要对模型进行调整
MCU性能比快速原型设备差，出现之前（闭环A）没有发现的问题
模型生成的 C 语言代码在往 RTOS 集成时出现的 Bug. 这是将来在量产开发中会出现的问题，可以提前在这个阶段发现
。
“闭环D”与 “闭环C”相比，用实车替换了仿真，相当于增加了真实的车辆动力学因素进闭环。

下表这四个闭环各自的标的，同时列出每个闭环的可变量与不可变量(真值)。

闭环A是典型模型在环（MiL, Model in Loop）, 闭环C是属于软件在环（SiL，Software in Loop），将模型生成了软件代码进行执行。

重点是Simulink 模型直接运行在快速原型设备里，仿真软件直接给出传感器的真值数据。也就是说就是仿真软件渲染了场景动画，也是给人看的，实际的真值直接发送给模型作为输入，当然真值数据怎么从仿真软件到模型需要工程师写代码来集成。

PIL
自动驾驶系统是一个异构系统。硬件上有高实时性的MCU和高性能多功能的 SoC芯片。MCU上运行RTOS系统，SoC 上有 Linux 或 QNX 也可以运行RTOS系统。SoC上有通用CPU，有用于渲染的GPU，有用于数学计算的 DSP 和深度学习的NPU，有用于编解码的CODEC, 有用视觉处理加速的CVA, 其中每个部分的软件实现方式也是不一样的。

单元测试、模块测试甚至基于CPU的子系统都可以在x86的开发设备上进行测试。但是如果子系统涉及到嵌入式平台的专用设备，其真实效果，尤其是性能表现只能到目标嵌入式平台进行测试。一般我们称之为处理器在环(Processor in Loop)。

所以整个测试闭环以及测试工具系统，需要考虑对嵌入式平台的支持。
异构子系统的集成是可以将多个子系统逐步集成进来的。如果把视觉算法也运行在目标嵌入式平台处理器上，视觉数据从仿真软件中提取出来通过网络发送到嵌入式平台，那就是 PiL 和 MiL 的混合模式。这时候仿真软件渲染的图像是有用的，运行在嵌入式平台的视觉算法根据图像识别出目标发送给Simulink模型。比纯粹的 MiL ，这一部集成了更多内容进仿真闭环中。

HIL
标准的硬件在环(HiL，Hardware in Loop) 是要用正式量产的ECU硬件，而且数据与 ECU 硬件交互的方式都应该与实际在车上是一样。虽然车辆周围的环境是通过仿真模拟出来的，但从ECU本身的视角，几乎是分不出自己是在仿真测试环境还是在真实车上。这样整个测试的环境就与真实车辆更接近了了。

在PiL测试中，如果需要使用原始的图像数据，一般图像数据是通过对视频文件的回放，并通过网络发送到目标嵌入式平台（ECU），而 HiL 则是直接通过物理设备将仿真出来的图像转成原始图像格式注入到 ECU 的视频采集端口，只是通过仿真跳过了传感器模数转换和ISP 处理的过程。这样ECU的采集模块也备集成到测试闭环中了。当然，完成这个视频数据从仿真软件到ECU视频端口，需要专门的硬件设备，这就是HiL台架的作用了。

车辆在环仿真(ViL, Vehicle in Loop) 实际上跟 HiL 很接近，但是全套HiL设备要能小型化后装到车上，控制算法的执行不是基于仿真软件的动力学模型，而是实际物理车辆的控制系统。仿真软件把模拟的场景注入到ECU，相当于物理汽车认为自己在某个道路场景中驾驶，ViL 跟HiL 的差别在于使用了真实的车辆控制系统。

参考链接：https://zhuanlan.zhihu.com/p/156854116