基于模型的快速原型开发通常分为四个过程：MiL → SiL → PiL → HiL
1. MiL（Model in Loop）模型在环 在PC上基于模型的测试，它的输出是经过验证的控制算法模型。验证控制算法模型是否准确地实现了功能需求
2. SiL（Software in Loop）软件在环 将模型生成代码或者手工编写代码，编译成PC程序，在PC上的测试。它的输出是经过验证的嵌入式代码。 在PC上验证代码实现的功能是否与模型一致
3. PiL（Processor in Loop）处理器在环 将代码编译成目标系统程序，然后在PC上虚拟目标硬件环境（例如Simics，dSPACE），并进行测试。它的输出是经过验证的目标程序。在目标处理器上验证代码实现的功能是否与模型一致
4. HiL（Hardware in Loop）硬件在环 将目标系统程序烧入实际硬件设备，并进行测试或者汽车标定。 在ECU/EPP/整套系统上验证代码实现的功能是否与需求定义一致。
几个常见问题：
- 这四个测试名字里都有in the loop，那么是不是一定要有闭环？
- NO，某些控制算法实现的功能本身就是不带闭环的，比如接收到某信号后点亮某某灯，在这种情况下就不需要闭环。
- 是不是一定要有被控对象模型？
- NO，在笔者有限的认知里
（1） 大部分狭义的的MIL（End2End Test）是需要带被控对象模型的（也有例外，如上文讲的某功能知识控制一个灯的开关，大没有必要建一个灯泡的模型），广义的MIL一般不care被控对象模型;
（2） SIL测试可带被控对象模型，但带被控对象模型的意义不大；
（3）PIL一般是不带被控对象模型（PlantModel）的；
（4） HIL（无论哪个层级）一般来说都需要被控对象模型。
- 是不是MIL一定要用浮点数，SIL一定要用定点数？
- No. 有些公司进行开发时直接跳过浮点模型用定点建模，在这种情况下，MIL也是用定点数进行测试；dsp和最新的MCU的浮点运算功能都已经很强大，支持用浮点数生成（编写）的代码，在这种情况下SIL也是用浮点来测试。
- 不是模型生成的代码可不可以做SIL？
- Yes，前面已经讲了SIL不一定需要被控对象模型，手写代码也可以做SIL，只是测试用例需要提前根据功能定义好。
（一） MIL
MIL就是模型在环，通俗一点理解就是对模型在模型的开发环境下（如SIMULINK）进行仿真，通过输入一系列的测试用例，验证模型是否满足了设计的功能需求。MIL是所有测试中最关键的，因为MIL的test accept criterion必须源于功能需求，没有其它的东西可以参考。而SIL/PIL的测试用例往往都是借用MIL的测试用例，一旦在MIL这个阶段的使用了错误测试用例，这个Bug很有可能会最终流出去，即便所有的测试都通过了。
a) 狭义的MIL
狭义的MIL一般指针对带被控对象模型，实现整个控制功能的模型进行End to End的测试。
如下图，电机控制的MIL模型有MotorController和PlantModel两个子模型组成：
PlantModel又包含：
- Predriver
- Mosfet全桥
- 电流采样电路
- PMSM电机
- 电机位置传感器采集电路
运行simulink仿真，比如我们设定电池电压13V，电机转速800rpm，指令力矩2Nm，在scope中我们电机输出了较理想的正弦波，输出力矩也稳定在2Nm左右，如下：
做到这一步，MIL就算结束了吗?非也非也，MIL还有一个重要的任务是为SIL和PIL的testcase收集test vectors（TV）。仿真的侧重点在于功能是否已正确实现，而MIL在simulation的基础上，还要把所有的输入输出保存起来作为测试向量将来给SIL/PIL使用。
以MotorController为被控对象，让我们看看下表：
b) 广义的MIL
在软件测试领域还有一个很重要的概念是测试覆盖度，对于ASIL级别比较高的产品，一般都需要MCDC测试覆盖度100%，而如果模型比较复杂的话，往往前文所述的狭义的MIL很难达到100%的测试覆盖度，因此我们还需要对某一个具体的子功能模块特别设置一些测试用例来测试，在这种情况下，往往不使用PlantModel。
（二） SIL
SIL是一种等效性测试，测试的目的是验证代码与控制模型在所有功能上是完全一致的。其基本原则一般是使用与MIL完全相同的测试用例输入，将MIL的测试输出与SIL的测试输出进行对比，考察二者的偏差是否在可接受的范围之内？
因此这个测试的目的就决定了带不带被控对象模型并不是那么重要。SIL测试一般都在PC上完成，对代码的编译器一般都是LCC，SDK，MSC等这些。
至于SIL的实现方法，那真是五花八门多种多样了：
- 将代码封装成S function在simulink中进行比较
- 用Matlan GUI开发自定义MIL&SIL工具，完成simulink仿真、S-funtion仿真及比较功能（大部分工作都在后台完成，不用那么多鼠标键盘操作）
- Matlab中通过将模型转换为SIL模型 set_param(model_name, ‘SimulationMode’,’Software-in-the-loop’)
- 使用Targetlink工具箱（死鬼死贵的说）
- 使用基于Microsoft Visual Studio或基于VSC环境开发的其它第三方测试工具，如MxVDev
- 使用与Matlab和Targetlink无缝链接的第三方工具，如BTC
（三） PIL
PIL测试与SIL测试的不同在于软件是使用的目标MCU的编译器（Tasking）进行编译链接，也需要运行在目标板上，其基本工作原理如下。
其测试通过准则是，使用与SIL相同的测试用例输入进行测试时，比较PIL和SIL的输出，如果两者之差在容许范围之内，则测试通过。
此外，PIL测试还能够测量某个功能模块的程序运行时间、堆栈（系统和用户）使用情况等等如下图，这些数据在所有软件功能模块集成之前对软件CPU Load、软件是否有跑飞的风险都是有非常大的帮助的。
下面，我们再来讲讲HIL。HIL是Hardware-in-the-Loop Simulation的缩写。顾名思义，就是硬件在环仿真。其实“硬件”二字的含义比较宽泛，一般来说按照in the loop的深度不同可以分为三个层级：
- ECU级：也可以称之为信号级，仅仅ECU软硬件采用实物，闭环回路的其他组成部分均采用虚拟仿真系统
- EPP级：也可以称之为驱动级，EPP是Electrical Power Package的缩写， ECU及执行机构采用实物，闭环回路的其他组成部分采用虚拟仿真系统
- System级：也可以称之为机械级，系统组件采用实物，闭环回路其他组成部分采用虚拟仿真系统
为什么我们要采用HIL？这个问题可从以下几个方面来回答：
- 在某些项目的初期阶段，可能用于试验认证的MuleCar都没有造出来，因此可以利用HIL系统先行验证部分控制策略；
- 在项目开发过程中，软件Release往往比较频繁，但是整车验证的周期比较长且受各种条件限制，不可能针对每一版软件都进行整车试验，因此可以用HIL虚拟测试环境来替代部分功能性的整车验证；
- 某些测试工况（特别是FailSafe故障注入测试）风险很大，需要在HIL上先行模拟仿真测试或用HIL测试取代整车测试（试想一下如下场景：车辆180kph，转向过程中EPS电机卡死，what will happen？）
- HIL系统可以进行7*24自动化测试， 节约测试周期和人力投入（如EPS全功能故障注入测试，如手动试验，大概需要2人月，采用HIL测试可在1周内完成）
以EPS为例，HIL系统一般可以由以下几个部分构成：
- 被测的“Hardware”(ECU/EPP/EPS系统)
- 实时硬件仿真平台：用于模拟与in the loop 的Hard的电气及通讯输入输出接口，提供譬如TAS信号、电机位置信号、电流反馈信号、齿条力负载等等；接收被测Hardware发出的各种信号，传递给车辆模型（或车辆模型+转向系统模型）进行计算仿真；同时可以产生各种故障用于故障模拟。
- 实时仿真模型 用于模拟车辆在不同工况下的工作状态。一般来说包括车辆动力学模型,转向系统模型，驾驶员模型等。
- 试验管理软件 用于对试验进行管理、参数设置及监控、可视化界面输出、生成报告等等。
ECU级的EPS HIL系统
ECU级的EPS HIL系统被测对象是ECU，结构比较小巧，主要用于验证EPS的软件算法。EPS执行电机由实时硬件仿真平台（Motor Emulation）进行模拟，这一部分对模型的精度要求很高。
上图中实时模型仿真的Steering Sensor信号直接传递给了EPS软件，这种处理方法对EPS ECU厂家而言这样做是可行的（反正自家的软件，可以随便改接口）；但对某些OEM而言此路不通，因为EPS软件不能从模型中直接获取转矩和转角信号，这就需要将实时仿真模型中的扭矩和转角信号传递给实时硬件平台，由实时硬件平台模拟出转矩和转角的物理信号（模拟量/PWM/SENT/PAS4/PSI5/旋变等等不同接口，详见笔者文章《简述电动转向系统扭矩转角传感器》）提供给ECU。
EPP级的EPS HIL系统
EPP级的HIL与ECU级HIL的区别在于电机采用了真实的助力电机，但仍然没有转向系统的其它机械部件，因而需要一个额外的伺服电机（磁粉制动器）来模拟齿条力负载。
System级的EPS HIL系统
系统级的EPS HIL被测对象为整套转向系统，实时仿真模型中只有整车动力学模型和驾驶员模型（不需要转向器模型和TAS模型），因此体积庞大。“实时硬件仿真平台“其实就是两个伺服电机：一个伺服电机工作于扭矩伺服模式，用于模拟齿条力负载（加载在齿条上或输出轴上均可），力矩指令由整车模型给定；另一个伺服电机工作于位置伺服模式或扭矩伺服模式，用于模拟驾驶员给方向盘各种不同的操作工况，指令由HostPC的测试用例给定。这个层级的HIL系统最接近于真实转向系统在整车的表现。
常见问题：
（1） 关于系统选型
取决于测试需求、公司技术能力及研发预算。Dspace，ETAS，Hirain等等都是比较成熟的系统供应商，当然如果对本公司技术水平足够自信的话也可以用NI板卡自己搭建，灵活性更强，造价也会相对低不少。
（2） 整车模型
VeDYNA，Carsim，IPG等都是知名的整车动力学模型供应商，但对于EPS这个应用而言，与整车模型交互的信息并不是很多，输入给整车模型的输入主要是车速、发动机转速和方向盘转角（转矩），从整车模型获取的主要参数是齿条力，某些高级一点的应用需要用到质心侧偏角和横摆角速度等等。
所以不差钱就买成熟模型，自己有技术底蕴也可以自己建车辆动力模型。但无论怎样，有两件事情是绕不过去的：
- 整车参数的获取，直接影响到模型输出的准确程度。参数不准确，哪怕使用的是知名成熟供应商的模型，也得不到准确的输出。至于如何获取准确的参数，一方面找OEM要，另一方面可以通过一些实验用状态观测的方法获取，那又是另一个Topic了。
- 一般来说，转向器模型和TAS模型需要自己搭建，可参考下图建立微分方程
（3） 测试用例
测试用例来源于系统功能需求与安全需求，一般来说分为两类：
功能与性能测试：
在不同的道路特征下（路面附着系数、水平属性、侧坡属性、凹凸属性……）目标车辆处于不同的状态（满载/轻载，不同胎压……）时，驾驶员做不同操纵工况（加减速，双移线，转角阶跃，转角脉冲，转矩阶跃，转矩脉冲，蛇形机动，稳态回转……）；考察转向系统的稳定性和操纵感觉。
同上在不同工况下进行故障注入，考察整车的安全性；并检查故障是否被检测到，相应的FaultCode，DTC是否被记录，故障灯是否被点亮；是否能通过诊断会话获取相关的DTC及Snapshot？