侵权投诉
订阅
纠错
加入自媒体

HIL第3讲,HIL零基础教程,“整车模型”到底是个什么

2019-04-13 11:23
车辆技术
关注

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

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

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

HIL第3讲,HIL零基础教程,“整车模型”到底是个什么

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

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

HIL第3讲,HIL零基础教程,“整车模型”到底是个什么

“实时性”不是本节要讨论的概念,没有实时机,我们照样可以讲清楚“整车模型”的作用,所以,我们以图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文件的自动化测试用例设计方法,简单得让人很无语,后续章节会详细介绍。

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

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

声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号