MBD开发模式下的XIL仿真测试
“想了解MBD模式下的MIL、SIL、PIL、HIL吗？”——虹科
汽车从一个发动机加上几个轮子的简单形态发展到如今机械与电子高度融合的复杂整体，经历了巨变。汽车电子控制单元的数量和复杂度也呈几何级数增加，给软硬件测试工程师带来了巨大的挑战。以往常用的测试方法，汽车ECU研发初期利用工具对其进行理论验证和单一的测试便在整车仿真或实际环境中测试，通过这种方式难以发现问题，到最后的整车测试发现问题需要对该模块进行重新设计、重新编写程序、重新测试等，耗费了大量的人力和时间成本。我们更加希望在研发初期对硬件和软件进行高覆盖率的测试，并能够模拟其汽车在不同工况下的各项功能测试以及逻辑验证，以便于在研发初期就能发现问题，降低开发成本，减短开发时间周期。
目前，汽车行业应用得比较广泛的软件开发方式为MBD（Model base design），也就是以模型为基础的软件开发，传统的嵌入式软件开发模式是无法与之比拟的。感兴趣的读者可以查找相关资料，深入学习，在这里笔者就不展开了。今天主要想和大家探讨的是在MBD中我们经常会谈到的MIL、SIL、PIL和HIL，XIL是各种测试环境的专用术语，可能很多人非常熟悉它们之间的区别与联系，当然也会有部分读者容易混淆这些概念，我就是其中之一，今天梳理一下分享给大家，希望能为你们带来一些帮助。
MIL（模型在环测试）
模型在环测试，顾名思义就是指基于模型级别所进行的闭环测试，用得比较多的是在Matlab的Simulink平台下，将被控对象与算法模型连接在一起形成一个闭环，对被测系统预期行为动作的测试，测试套件是由模型生成，而不是由源代码生成，因此，基于模型的测试实质是黑盒测试。在这里举个例子，在汽车上的车窗升降电机，工程师可以给创建的模型设定输入，将实际输出与期望输出进行对比，如果两者结果一致，实现功能需求，则通过测试。可以说MIL是整个测试过程中较为关键的一环，其必须要基于功能需求开展，如果在这个阶段中采用了错误的测试用例，也就是没有对应功能需求，即使其他的所有测试均通过了，这也将成为一个致命的问题。
SIL （软件在环测试）
我们可以将软件在环测试看作是从模型在环测试原有的基础上引申出来的，实际上就是将控制器模型生成C代码，这个过程在Simulink平台上很容易就可以实现，之后对比验证生成的C代码和模型二者的功能一致性（等效性测试），也就是back2back测试（背靠背测试），由于在这个测试中，要用到C代码的运行结果来进行比较，所以要保证模型生成的C代码是可以编译通过的。模型生成的代码会用到已有代码的一些头文件、定义等内容，我们需要把头文件加载到生成的C代码中。那么，是否一定需要创建被控对象模型，我们才能进行软件在环测试？并不是，因为我们的目的是为了验证生成的C代码和模型功能的一致性，那么我们也可以通过手工编写代码，比较手写代码和模型在相同输入下的输出结果是否一致，就能够达到软件在环测试的目的。
PIL（处理器在环测试）
上边提到的SIL测试的目的是为了防止模型生成的C代码出错，最后的输出结果与模型输出结果不一致，除了生成C代码这个过程中可能会出错，在编译的过程中，同样也会出现错误。我们通常情况下，是在Windows的平台下建立模型生成C代码并进行编译，使用的也是Windows平台下的编译器，但是将生成的C代码运行到目标处理器上，由于编译环境不一样，导致编译出来的结果也不是完全一致，因此可能会引入新的问题。结合模型测试、SIL测试、PIL测试的结果，可以帮助我们找到可能出现的缺陷和错误。除此之外，通过PIL测试我们可以获得算法在处理器上运行的总时间，这能够为实时控制开发带来便利。
HIL（硬件在环测试）
HIL是用于测试控制器系统的，其中包括硬件、底层软件和应用层软件。通常情况下，HIL测试将被控对象的模型生成C代码并生成可执行文件导入到工控机上运行，工控机连接到控制器，在该状态下，对于被测试的控制器来说，它并不知道与其连接的是一台工控机，而是认为当下处于真实环境，相当于是在实际控制系统中工作。无论是不是MBD开发模式，一般在以下情形都有必要进行HIL测试：
（1）被控对象昂贵，且控制软硬件技术不成熟，运行不当会危机人身安全或者造成重大财产损失
（2）为了降低开发成本或是控制器开发出来了但是被控对象还未开发出来
HIL测试提供一个平台，让我们能够将复杂的算法导入到动态的控制系统，控制系统的MCU通过各种接口连接到HIL平台，实现被控对象实时仿真运行。
如果记不住上面的一大段文字，可以通过下面这个表格，对比一下MIL、SIL、PIL、HIL它们之间的联系与特点：
