HIL22讲，实车功能自动化测试系统

严格意义上讲，实车是无法做自动化测试的

车上的按钮、开关、灯光甚至扭矩输出，都是有物理意义上的作用对象的，可能是给人操作的、观察的，或者直接作用于地面的等等。

但是无论如何，它绝对不是为了给板卡采集的，所以，天然不适合做自动化测试，天生相克。

但是，在具体的应用场景中，实车自动化测试仍然是一个值得探讨的技术路线，如果能够将自动化测试和实车结合在一起，那么我们的测试工作就变得更加有意义、更加有用、更加有价值，对车型项目开发而言，更有用……

毕竟，HIL仿真测试的终极目标也只是模拟实车测试而已，只不过HIL对极端罕见工况更好下手了，更容易搞出来。。。

在实际工作中，由于这样那样的原因，其他专业对测试专业不信任的话，通常会不care HIL，因为这个事情超出了他们的知识范畴，并且也不符合他们的思考习惯。

而是直接拿实车说事儿，实车没暴问题，HIL暴了问题，是HIL的问题；实车暴了问题，HIL没有报问题，还是HIL的问题，HIL水平不行😂

言归正传，实车自动化测试有自己的使用限制：

待测对象应优选逻辑类控制器，比如VCU、BCM、BMS等等，这些控制器环境零碎多变，HIL模拟起来容易挂一漏万、搞错，耽误时间，容易形式主义，性价比较低。

而在实车上就不容易搞错。

至于EMS、TCU、ESP等控制器，还是好好搞搞HIL吧，因为实车有一定的危险性。在仿真模型上多下点功夫，哪怕仿真模型自己做不好也没关系，外购的HIL模型如果能用得起来，也是超过了很多人的水平的。

可以参考下面文章的说法，大家一起膜拜一下比亚迪，文章中间部分介绍了比亚迪的HIL仿真模型的现状

​​比亚迪187万辆！中国品牌有史以来最强表现​​

基础版实车自动化测试方案

基本概念可参考下面的文章：

​​总线17讲，基于LabVIEW的实车自动化测试系统​​

这个文章里面讲的实车自动化测试方案，侧重于网络方面，属于实车网络自动化测试。

比如自动分析各个网段的报文一致性、多发了哪些，少发了哪些，周期DLC是否一致；批量读故障码，看返回是否正常；自动做休眠唤醒测试，看功能是否正常；通过picoscope示波器自动截获并分析CAN报文物理层波形……

我们可以在上述思路基础上进行延伸，从而创造出极具应用潜力的实车功能自动化测试方案。以BMS电池管理器或BCM车身域控制器为例：

把验证读取的信号，深入至信号层面即可。

举个例子，以BMS为例：

步骤1：用CAN工具实时读取BMS发出的ECAN报文信号。

步骤2：软件弹窗并提示：“请踩下制动踏板并按启动按钮”

步骤3：上位机软件持续监控BMS发出的信号，根据预先设计好的时序关系，检测关键信号是否如预期，比如接触器状态、母线电压等等。

并且，在这个步骤3中，我们完全可以随着设计工作的细化，不断增加要检测校对的信号数量，从而使实车表现更加优秀可靠，一旦发现哪个信号的值或者时间不符合预期，就在测试报告中予以体现，从而优化设计。

此外，步骤3的场景库可以随着工作的积累，变得越来越丰富，工程师需要做的仅仅是根据弹窗提醒，操作对应的按钮即可。

大家可能注意到了，这种实车自动化测试方案，对硬件要求极低，只需要一个CAN卡即可。

代价就是需要人工操作，而且无法检测BMS的硬线输出，只能通过读报文来观察值是否符合预期，有时候某个硬线输出，没有定义与其同步的CAN信号，就不好办了。

高级版实车自动化测试方案

鸟枪换炮！

以BCM为例，实车自动化测试时，加上一个实车测试BOB，再加一个数采模块，即可实时监测BCM的硬线输出是否如何当下场景的预期，同时也不影响其对实车负载的驱动。

当然，您也可以在BOB上控制BCM的输入，通过继电器对开关类传感器的有效无效进行自动控制，相当于在真实开关上面并联了一个程控开关（继电器），就能实现完全的无人操作自动化实车测试了。

这种测试方案，刚开始的时候可能不是特别显成绩，因为用例库要一点点积累，一开始并没有规模效应。

但是这个测试方案最大的好处就是攻城略地、所向披靡，只要它查出来的问题，100%就是问题，不可能是设备本身原因导致的。实车了嘛！

而且这些用例在不同项目上基本上都是可以复用的，毕竟通讯矩阵、功能定义都会参考并沿用，不太可能完全推到重来。

哪怕测试用例复用错了，没有做好裁剪，再核对一眼测试报告就可以了。

当然，由于我们经常要更新优化测试场景库，所以需要excel来做测试用例，并且能够通过勾选来选择性执行。Excel方便评审、协作、分享，在这一点上要比直接在CAPL、python代码里面写逻辑，更靠谱一些，领导也方便参与。

测试报告就是经典的Excel了，自动生成，使用方便，领导也喜欢。

总结

针对低实时性控制器的功能逻辑测试，比如BMS、BCM、VCU等，因为环境复杂多变，逻辑含糊不清，HIL测试反而更容易出错，结果不可信，这个时候，把实车环境用进来，在实车的基础上做自动化测试，性价比极高。

它本质上就是把大家一直在用的“实车人工测试步骤”，变成自动化执行了。

上面说的高级版方案，并不一定是比基础版全盘优秀，实车上有些人工操作可能还是必要的，强行自动化并不可取，代价高昂，比如遥控钥匙的操作。

经常出问题、一直搞不好的事情，反而更获取公司、领导更多的关注和支持，要不要去推动一些貌似一劳永逸，但是也挺费劲的方式，在某些江湖环境下，可能需要商榷。

但是无论如何，请相信我们，本文所述的做法，从产品和技术角度而言，效果非常好，非常适合系统级功能逻辑测试，排查掉一些显而易见的问题。

也有供应商伙伴提供这样的完整测试方案，如有需要可以后台沟通。

还有一点需要说明，它并不适用于芯片级别、硬件模块级别、软件白盒模块级别的测试，这种测试一般都是供应商在做，车企一般不参与。

此外，对于性能测试，比如uds服务是否有缺漏、唤醒时间是否超标、busoff恢复是否正常、bootloader是否合格等等测试项，还是需要专门的测试方案去做的啊啊啊。末尾这个图片是咋回事？谁加的？？？

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