本节，我们讲讲，让无数HIL从业人员不明就里、让很多HIL厂商念念不忘并引以为豪的“整车模型”，到底是个什么。

先重复一句，师子一号对“硬件在环”的理解，指的就是，在硬件实体控制器层面上所做的测试，把输入和输出都引了出来，使其可以被控制或被观测，通过一定的办法，控制控制器的输入，检查相应的控制器的期望输出，就叫硬件在环。这个“环”，可是人，也可以是软件，或者是脚本甚至是别的一个或多个控制器。。在本系列文章中，师子一号将通过多个章节对其进行深入讲解，但不做表面上的名词解释，因为那在作者看来，那跟讲茴字到底有几种写法差不多。

回顾之前章节，我们把HIL的架构贴出来看一下：

图1：不带实时机的HIL系统

在带有整车模型的情况下，HIL就是这么个东东，左边的一大块，就是给右边的VCU制造输入、输出信号的。如果我们不苛求“实时性”，那左边就是一台普通PC机，里面装上了matlab，VC编译器、板卡驱动等等；如果我们要求实时性，那左边就是一个装了实时系统的电脑，这个实时系统只负责运行，我们需要再另外找一个普通PC，通过网线去控制这个实时系统里面的变量，然后就成了下面的这种架构：

“实时性”不是本节要讨论的概念，没有实时机，我们照样可以讲清楚“整车模型”的作用，所以，我们以图1为例来说明。

回想一下我们在第二讲的时候，说发动机控制器的输入信号比较特殊，说需要周期为6．28秒，一周期变化20次。

这个是人难以实现的，哪个操作员的手速能这么快，控制这么精确呢？所以必须做个软件。我们需要做个软件，让它运行在电脑上，这个软件的运行周期是6．28s，每0．314s更新一次，更新的值就是sin（x）的值，这就可以了嘛。这个软件呢，可以用C，也可以是C＋＋，也可以是别的，反正只要能运行在目标操作系统（我们是按照图1来说明的，所以，此处所说的目标操作系统，就是个普通的PC）上就行。

但是，用VC做这样的软件，还是太麻烦了。科技的进步，就是让人类有条件更懒惰更省劲，效率更高，我们可以用simulink图形化编程，然后在编译成C代码，效果是一样的，也是可以运行在目标系统上的。Simulink在这方面很擅长，也有成熟的技术体系，直接拿来用就好了。至此，大名鼎鼎的“整车模型”就诞生了。

说它是“整车”，因为它模拟了发动机控制器之外的其他外界环境，发动机控制器特别希望这个模型去模拟出整车的情况，然后才来检测自己是否ok，这和现实工作中有些工程师的心态是类似的，明明是两个人配合，他却说“你先把你的做好，拿给我看，然后我再做我的”。

说它是“模型”，就是因为它是用simulink做的。

就这样，我们用simulink，做成了一个最简单的“周期信号生成”的整车模型。这个整车模型可以让我们有条件去测试发动机控制器的“周期信号检测”功能，如果没有这样的整车模型，那就寸步难行了，我们只能把发动机控制器的“周期信号检测”功能给屏蔽了，才能测试。

除了“周期信号生成”生成之外，还有其他的，比如“氧传感器”的快速变化的信号、报文的 rolling和checksum、两个加速踏板电压的二倍关系等等，都是通过这种方式来实现的。如果我们不能通过类似的“整车模型”去控制器相应的信号，我们就只能在被测对象控制器（图1示的VCU）的软件功能中屏蔽掉相应的故障检测，测试才能进行下去。

这些只是最基本的“整车模型”，他们实现的是一些必须的功能，没有这些功能，测试压根没法进行下去。这些“必须的整车模型”，师子一号称其为“第一类整车模型”。

除了这些必须的功能，我们还有一些锦上添花的功能，这才是广大供应商眼中的真正卖点所在。师子一号称这些整车模型为“第二类整车模型”。

我们做个比喻，医学进步很快，人造心脏也成功了，为了测试这个人造心脏运行是否正常，医学家做了复杂的电子装置和机构，用于和心脏的血管、神经、动脉、静脉、瓣膜、膈肌、体温、酸碱度、盐度、呼吸频率等多种接口进行对接（假设不存在排异反应，电子装置或真人的相应器官，和人造心脏只要一靠近，就能自动成功对接安装），然后，做出极其复杂的软件模型，去控制或者检测这些电子装置和机构的状态，并且尽可能让这些电子装置和机构的工作过程和真人的胳膊、大脑、腿、心肝胰脾肺等等一样，从而让这个混合的整体，工作得像一个真人，惟妙惟肖、动作协调……在这个过程中，还可以设置一些观测参数，看看心脏的运行状态如何…

在此，师子一号不得不说，这是一个非常非常庞大的工程，甚至于永无止境、永远也做不好，这也是广大HIL集成商在广大整车企业眼中高不可攀、神秘莫测的秘诀所在。但是，哪怕HIL集成商，也不可能根据客户的要求，给做得很好。他们只能拿出一个基础版的给客户，告诉客户，我们这个整车模型只包括什么什么什么的，一般就是包括一维纵向模型，也就是所谓的速度积分模型、自动挡档位切换模型什么的。什么电池电机的，各个客户情况都不一样，供应商也不可能给你定做开发。这是HIL领域内最大的一个坑，这个坑借由中国新能源的风，吹出来的，吹得铺天盖地，好像不配上，出门就不好意思跟同行打招呼似的。

这样做有什么好处呢？这样做，可以在台架上，就能通过接近于纯软件的方式，仿真整车的实际运行状态，测试开始，我们就能在电脑屏幕上看到，档位自动挂上了，加速踏板自动踩下，车速上去了，SOC下降了，发动机转速提高了，效果真的很形象，也很动感，嗯，真的很好看。

在传统车领域，整个汽车还是机械工程师的天下，电子控制器还不多，关键控制器也只有发动机控制器、变速箱控制器、ESP等几个，而且软件更改量不大（软件更改量不大就意味着整车模型更改量也不大，可沿用度很高），软件的工作主要是标定，修改修改参数，所以，制作复杂、逼真的整车模型（第二类整车模型），是可以理解的，也是有一定用途的。

在新能源领域，电子电控产品占据了相当部分的主流，越来越复杂，绝不是某两三个控制器就能搞定的，也不是单单标定、修改参数就能完成的。仅仅是功能测试就要占据很大的工作内容，我们要用全新的思维去面对情况的变化。

第二类整车模型的特点在于，具有闭环反馈功能。比如，假如图1中的被测对象vcu，输出了一个信号，ToqReq，给电机，而整车模型要模拟电机的功能，就要在检测到vcu发的“ToqReq”信号之后，将通过CAN卡发送给vcu的的“车速”信号不断提升，实现积分的功能。

这样，当我们通过HIL测试的面板（面板和整车模型可以是不同的东西）踏板，控制板卡的模拟量输出脚的电压给vcu，vcu检测到电压，发ToqReq给整车模型，整车模型对车速积分，把车速提上去。最终，整体上看，踏板踩一下，车速就上去了，很动感，很形象，效果也很直观。

大量的这种具有闭环交互功能的软件代码，就成了“第二类整车模型”，他们让这个HIL测试变得很逼真，也很形象。虽然，难度非常非常大，虽然新能源车发展迅速，改动很大且很难沿用。

下面，师子一号要发话了，并且予以佐证。

首先，第一类整车模型是非常有必要的，没有他们，测试无法真正进行，除非屏蔽掉被测对象某些功能，它才会不报错。

第二，“第二类整车模型”，是从传统车遗传过来的一些做法，它不适用于新能源车。只有我们和传统车一样，是在为了HIL台架上做标定的情况下，“第二类整车模型”才有必要做得很复杂很逼真。

第三，师子一号认为，HIL不适合做标定，HIL更适合做功能测试，与其花大量精力去做第二类整车模型，去仿真电机等零部件的运行特征，还不如直接去车上标定，效果更好，更有意义。并且，如果我们在HIL上做标定，那功能测试去哪里做？实际上，只有功能测试差不多了，才能进行标定。

第四，师子一号推荐只做第一类整车模型，然后开放出其他信号的控制接口，做功能HIL测试。

关于第四点，原因在于，针对功能测试，第二类整车模型，虽然更形象更动感，但是不适用，除了好看一些，价值不大。第二类整车模型，通过闭环反馈给被测对象的，往往就是一些常规的值（取决于整车模型的输出值类型），这大大降低了控制器功能测试的覆盖率，使得测试工程师很难自由设计各种信号组合、工况，深入测试被测对象（图1示VCU）的功能。

HIL上的“第二类整车模型”，开发周期非常长，效果非常一般。最后往往非但不能为项目出力，检查控制器的功能，反而要借助项目中的控制器，去查HIL设备以及整车模型是不是有问题！！！

“第二类整车模型”在一定条件下，是可以转化成“第一类整车模型”的，判断的关键点在于，是不是“必须的”。

假如，我们的被测对象，比如vcu，具备了车速积分侦测功能，它在发出ToqReq信号的同时，也实时监测车速有没有上来，如果车速没有上来，vcu就认为车可能出了问题，然后就报故障。这种情况下，车速闭环的“第二类整车模型”就变成了“第一类整车模型”了，变成了必须的。

师子一号认为，在HIL设备上，做好了必要的“第一类整车模型”之后，把其他信号全部通过面板接出来，予以控制或者检测，是效果最好的HIL功能测试方案。这种测试，vcu每个输入信号的，都是可以控制的，可以仿真出许多种组合，覆盖率可以做得很高。

师子一号以自己的切身体验，认为，这种做法，效果非常之好。但这种方式，对测试工程师个人能力、对研发流程，都有一定的要求，要求功能定义明确、有清晰的输出物，并且，很多情况下，测试工程师往往就是功能设计工程师本身。并且，要求提高了，并不是坏事，大家觉得呢？

按照师子一号建议的测试方法，会有很多变量接口出现在控制面板上，这对测试操作人员的细心程度要求很高，人工操作容易出错（但是效果也是可以的），不过，部分HIL厂商也提供了专门的自动化测试执行方案，比如NI公司的TestStand、Dspace公司的automation desk等等，而且，师子一号对此也有专门的研究，提供了一种非常易用、方便复用的基于Excel文件的自动化测试用例设计方法，简单得让人很无语，后续章节会详细介绍。

大家要是觉得师子一号说得还不够通俗易懂，可以在底下或者在后台留言，后续会针对性改进。

下一章节，我们将简单介绍一下“故障注入”的概念。