关于MIL、SIL、PIL和HIL之间的联系和异同分析

我们在使用MBD开发软件的过程中，经常会听到MIL、SIL、PIL和HIL等In-the-Loop测试。

这几种测试之间到底是什么关系？

分别做什么事情？

下面我来简单说说。

M模型在环测试（MIL）

图一：模型在环测试（MIL）示意图

如图一所示，如果在Simulink模型中，将控制算法模型和被控对象模型连起来形成闭环，就是我们经常说的MIL，顾名思义，在模型层面上实现闭环测试。这种测试通常发生在两种场景之下：

系统工程师为了验证算法，使用控制算法模型控制被控对象模型

软件工程师做模型级别的集成测试

当然，MIL测试的前提是要有被控对象模型，搭建被控对象模型或者采购现成的被控对象模型都可以。

M软件在环测试（SIL）

SIL测试，这里的Software是指控制策略模型转换成的C代码编译之后的软件。我们可以想象，对于图一，如果我们把控制策略模型替换成由控制策略模型转换得到的C代码编译后的DLL文件，如果我们使用了和MIL测试时相同的测试用例，如果我们的测试用例足够多，如果我们得到了和MIL测试相同的结果，那么我们是不是可以认为我们生成的C代码就和用于代码生成的模型是一致的呢？

没错，SIL测试的目的就是为了验证自动生成的代码和用于代码生成的模型中行为上是一致的。

也就是说SIL测试是一种等效性测试，既然是等效性测试，那么我们就没必要搭建图一那样的闭环模型，而可以用图二实现等效性测试。

图二：软件在环测试（SIL）示意图

其实Simulink提供了SIL仿真模式，所以，我们可以用更方便的方式实现SIL测试，使用：

set_param(model_name,’SimulationMode’,’Software-in-the-loop(SIL)’)

设置算法模型的仿真模式为SIL，然后对比Normal模式下的输出结果即可，并且这样做有助于过程自动化。如图三所示：

图三：选择SIL仿真模式测试

M处理器在环测试（PIL）

SIL测试是验证代码和模型的一致性，代码运行在Windows平台上，某种程度上说，这并不能保证代码到目标处理器上的运行结果也能够和模型保持一致。所以，就有了PIL测试。

PIL和SIL的不同之处在于，SIL将生成的代码通过DLL的方式运行在Windows平台上，而PIL，是将生成的代码运行到目标处理器上，两种模式使用的编译器也是不同的，SIL使用的就是Windows下的编译器，比如Visual Studio C++或者LCC编译器，而PIL使用的是目标编译器。

前面说过，等效性测试的目的是为了防止代码生成过程出错。同样，编译过程也可能出错，编译器也可能有bug，综合模型测试、SIL测试和PIL测试的结果，也可以帮助我们发现编译器出错可能引入的bug。

SIL和PIL是等效性测试，测试的目的是为了验证自动生成的代码和模型具有相同的行为，既然如此，对于SIL和PIL的测试用例就没有功能意义上的要求，只要要求代码和模型输入的测试数据相同即可，当然希望数据量足够大，能够覆盖各种路径以及各种信号范围。

另外，因为PIL测试中代码运行在实际的控制器上，所以PIL测试除了可以验证代码和模型是否一致之外，还可以获得算法在实际控制器上的最长运行时间，而这个最长时间的价值，做嵌入式实时软件开发的工程师都懂得。

M硬件在环测试（HIL）

最后再说一下HIL测试，很多人会把HIL和PIL混淆，也有人认为PIL是一种简化的HIL，理由是PIL测试的时候也需要引入硬件。这种理解是错误的。PIL和HIL测试的目的是不同的，PIL用于测试软件和模型是否一致，而HIL是用于测试控制器系统的，控制器系统包括了硬件、底层软件和应用层软件。HIL测试通常将一个被测控制器和工控机相连，工控机上运行着被控对象的模型，并且模拟出被控对象的一些电气特性。在HIL场景下，被测试的控制器并不知道和它相连的是一台工控机，它会认为自己连接的就是真实的实物对象。

MIL、SIL、PIL三种测试都是和MBD开发模式下特有的，而HIL不同，无论你是否使用MBD开发，都可能需要做HIL。不是所有的应用都需要，但是以下两种情况建议做HIL：

在控制器软硬件不成熟的条件下，运行出错可能会导致人身伤害或者重大财产损失的情况；

在开发过程中，被控对象开发滞后于控制器开发的情况。

另外，HIL测试通常比实物测试更节省成本，比如，做汽油机台架测试，需要有大量的汽油消耗，而通过HIL测试汽油机控制器，就没有汽油消耗。但这并不是说HIL可以替代实物测试，HIL测试之后，通常会跟着做实物测试。

如果记不住上面的大段文字

就请记住下面3点——

MIL用于测算法

SIL和PIL用于测代码（和模型的一致性）

HIL用于测控制器系统