HIL17讲，MIL测试+端口测试，黄金组合的强大威力

测试方案没有万能的，根据实际情况，选择最高效的方式，是工程师的责任和使命

师子一号多次说过，HIL测试是最后一道防线，问题如果没有在这个环节被发现，就会流向实车，就麻烦了。

然鹅，对于具有自主开发能力的车企而言，可选的测试方案更加丰富多样，更加自由，想象空间更大，手段更多……标准HIL测试，并不是唯一的测试手段，甚至于，它可能都不是最好的手段。

啥是标准HIL呢？就是那种硬件实物层面的测试方案，所有硬线信号均用对应的板卡进行模拟或者采集，大大的机柜，双机HIL。

为什么

为啥说它未必是最好的手段呢？

因为标准HIL机柜测试VCU之类的低实时性控制器，需求变化较快，问题五花八门，测试设备问题也是层出不穷，简直乱成一锅粥了。

怎么办

用“MIL测试”+“端口测试”的办法来解决。

自主开发嘛，一般是有a2l文件的，也是可以通过诊断来修改配置参数的。

而且，对于simulink开发嵌入式代码而言，为了充分利用标定工具，往往在IO接口部分有类似下图的逻辑：

其中，“信号选择器”、“虚拟IO采集”都是可写标定量。

当“信号选择器”值为0时，“软件使用值”采用“真实IO采集”；

当“信号选择器”值为1时，“软件使用值”采用“虚拟IO采集”；

所以，MIL测试就很好实现了，把“信号选择器”值设置为1，然后就可以愉快地直接控制各种逻辑的输入了，至于输出，不需要信号选择器，直接观测即可。

端口测试

但是这么做，还有个不足，就是无法确定IO采集的功能是否正常。

我们通过端口测试来解决这个问题，此种测试，就需要VCU的输出也做信号选择器，当“信号选择器”值为0时，硬线输出采用软件的真实逻辑输出，当“信号选择器”值为1时，采用标定值直接控制硬线输出。

端口测试的工作可以由硬件或者底层软件相关的开发人员来做，设计变动很小，自动跑一遍很简单！

总结

用了“MIL测试+端口测试”的方案，那么软件测试的可信度将大大提高，毕竟，软件开发人员肯定是承认标定量这个级别的数据的，加变量也很方便。

100%一切的输入，所有的信号交互，是必然体现在标定量里面的。

而且，标定量的名字取决于模型名字，它很稳定，几乎不会胡乱修改变动。当然，我们也可以通过受控文档的方式，把这些名字固化下来。

它更有利于做自动化测试，测试环境更加稳定可靠，业务分层更加清晰合理。

怪不得ETAS在官宣放弃HIL业务的时候，仍然保留了MIL测试等软件测试的业务。

败走麦城，ETAS官宣退出HIL市场

节省设备

标定量可以使MIL测试所需要的硬件板卡极其稀少，IO板卡肯定是不需要了。

能够给企业节省很大的设备投入成本！！！

如果您想进一步节省，甚至CAN、LIN都板卡也不需要了（标定CAN除外），直接读写对应的标定量即可。

当然，如果这样，那我们需要在端口测试的环节增加CAN信号和对应的标定量的映射关系测试。

不过，鉴于CAN、LIN设备并不麻烦，建议对通讯信号进行直接读写，不利用标定量。

适用范围

1、适合低实时性控制器的测试，因为它们侧重逻辑，不侧重实时性仿真模型。

2、这种方案适合基本功能逻辑测试，不适合协议栈测试，因为协议栈那些东西比较晦涩，很难进行软硬件解耦，不好操作，比如：

• 诊断测试

• CAN(FD)、LIN物理层、链路层、应用层测试

• OSEK或AutoSAR网络管理测试

• SOA测试

• 以太网测试

• 刷写测试

等等…

或许等到哪一天，这些高级的协议栈测试，全行业都搞透了，能进行软硬件解耦了，也就可以做MIL测试了，但是很难，希望不大…

欢迎后台联系，一起探讨“MIL测试+端口测试”的技术路线，并给您推荐较为成熟的供应商解决方案

文章转载自公众号：车辆技术