HIL第3講，HIL零基礎教程，“整車模型”到底是個什么

本節(jié)，我們講講，讓無數(shù)HIL從業(yè)人員不明就里、讓很多HIL廠商念念不忘并引以為豪的“整車模型”，到底是個什么。

先重復一句，師子一號對“硬件在環(huán)”的理解，指的就是，在硬件實體控制器層面上所做的測試，把輸入和輸出都引了出來，使其可以被控制或被觀測，通過一定的辦法，控制控制器的輸入，檢查相應的控制器的期望輸出，就叫硬件在環(huán)。這個“環(huán)”，可是人，也可以是軟件，或者是腳本甚至是別的一個或多個控制器。。在本系列文章中，師子一號將通過多個章節(jié)對其進行深入講解，但不做表面上的名詞解釋，因為那在作者看來，那跟講茴字到底有幾種寫法差不多。

回顧之前章節(jié)，我們把HIL的架構貼出來看一下：

圖1：不帶實時機的HIL系統(tǒng)

在帶有整車模型的情況下，HIL就是這么個東東，左邊的一大塊，就是給右邊的VCU制造輸入、輸出信號的。如果我們不苛求“實時性”，那左邊就是一臺普通PC機，里面裝上了matlab，VC編譯器、板卡驅動等等；如果我們要求實時性，那左邊就是一個裝了實時系統(tǒng)的電腦，這個實時系統(tǒng)只負責運行，我們需要再另外找一個普通PC，通過網(wǎng)線去控制這個實時系統(tǒng)里面的變量，然后就成了下面的這種架構：

“實時性”不是本節(jié)要討論的概念，沒有實時機，我們照樣可以講清楚“整車模型”的作用，所以，我們以圖1為例來說明。

回想一下我們在第二講的時候，說發(fā)動機控制器的輸入信號比較特殊，說需要周期為6．28秒，一周期變化20次。

這個是人難以實現(xiàn)的，哪個操作員的手速能這么快，控制這么精確呢？所以必須做個軟件。我們需要做個軟件，讓它運行在電腦上，這個軟件的運行周期是6．28s，每0．314s更新一次，更新的值就是sin（x）的值，這就可以了嘛。這個軟件呢，可以用C，也可以是C＋＋，也可以是別的，反正只要能運行在目標操作系統(tǒng)（我們是按照圖1來說明的，所以，此處所說的目標操作系統(tǒng)，就是個普通的PC）上就行。

但是，用VC做這樣的軟件，還是太麻煩了?？萍嫉倪M步，就是讓人類有條件更懶惰更省勁，效率更高，我們可以用simulink圖形化編程，然后在編譯成C代碼，效果是一樣的，也是可以運行在目標系統(tǒng)上的。Simulink在這方面很擅長，也有成熟的技術體系，直接拿來用就好了。至此，大名鼎鼎的“整車模型”就誕生了。

說它是“整車”，因為它模擬了發(fā)動機控制器之外的其他外界環(huán)境，發(fā)動機控制器特別希望這個模型去模擬出整車的情況，然后才來檢測自己是否ok，這和現(xiàn)實工作中有些工程師的心態(tài)是類似的，明明是兩個人配合，他卻說“你先把你的做好，拿給我看，然后我再做我的”。

說它是“模型”，就是因為它是用simulink做的。

就這樣，我們用simulink，做成了一個最簡單的“周期信號生成”的整車模型。這個整車模型可以讓我們有條件去測試發(fā)動機控制器的“周期信號檢測”功能，如果沒有這樣的整車模型，那就寸步難行了，我們只能把發(fā)動機控制器的“周期信號檢測”功能給屏蔽了，才能測試。

除了“周期信號生成”生成之外，還有其他的，比如“氧傳感器”的快速變化的信號、報文的 rolling和checksum、兩個加速踏板電壓的二倍關系等等，都是通過這種方式來實現(xiàn)的。如果我們不能通過類似的“整車模型”去控制器相應的信號，我們就只能在被測對象控制器（圖1示的VCU）的軟件功能中屏蔽掉相應的故障檢測，測試才能進行下去。

這些只是最基本的“整車模型”，他們實現(xiàn)的是一些必須的功能，沒有這些功能，測試壓根沒法進行下去。這些“必須的整車模型”，師子一號稱其為“第一類整車模型”。

除了這些必須的功能，我們還有一些錦上添花的功能，這才是廣大供應商眼中的真正賣點所在。師子一號稱這些整車模型為“第二類整車模型”。

我們做個比喻，醫(yī)學進步很快，人造心臟也成功了，為了測試這個人造心臟運行是否正常，醫(yī)學家做了復雜的電子裝置和機構，用于和心臟的血管、神經、動脈、靜脈、瓣膜、膈肌、體溫、酸堿度、鹽度、呼吸頻率等多種接口進行對接（假設不存在排異反應，電子裝置或真人的相應器官，和人造心臟只要一靠近，就能自動成功對接安裝），然后，做出極其復雜的軟件模型，去控制或者檢測這些電子裝置和機構的狀態(tài)，并且盡可能讓這些電子裝置和機構的工作過程和真人的胳膊、大腦、腿、心肝胰脾肺等等一樣，從而讓這個混合的整體，工作得像一個真人，惟妙惟肖、動作協(xié)調……在這個過程中，還可以設置一些觀測參數(shù)，看看心臟的運行狀態(tài)如何…

在此，師子一號不得不說，這是一個非常非常龐大的工程，甚至于永無止境、永遠也做不好，這也是廣大HIL集成商在廣大整車企業(yè)眼中高不可攀、神秘莫測的秘訣所在。但是，哪怕HIL集成商，也不可能根據(jù)客戶的要求，給做得很好。他們只能拿出一個基礎版的給客戶，告訴客戶，我們這個整車模型只包括什么什么什么的，一般就是包括一維縱向模型，也就是所謂的速度積分模型、自動擋檔位切換模型什么的。什么電池電機的，各個客戶情況都不一樣，供應商也不可能給你定做開發(fā)。這是HIL領域內最大的一個坑，這個坑借由中國新能源的風，吹出來的，吹得鋪天蓋地，好像不配上，出門就不好意思跟同行打招呼似的。

這樣做有什么好處呢？這樣做，可以在臺架上，就能通過接近于純軟件的方式，仿真整車的實際運行狀態(tài)，測試開始，我們就能在電腦屏幕上看到，檔位自動掛上了，加速踏板自動踩下，車速上去了，SOC下降了，發(fā)動機轉速提高了，效果真的很形象，也很動感，嗯，真的很好看。

在傳統(tǒng)車領域，整個汽車還是機械工程師的天下，電子控制器還不多，關鍵控制器也只有發(fā)動機控制器、變速箱控制器、ESP等幾個，而且軟件更改量不大（軟件更改量不大就意味著整車模型更改量也不大，可沿用度很高），軟件的工作主要是標定，修改修改參數(shù)，所以，制作復雜、逼真的整車模型（第二類整車模型），是可以理解的，也是有一定用途的。

在新能源領域，電子電控產品占據(jù)了相當部分的主流，越來越復雜，絕不是某兩三個控制器就能搞定的，也不是單單標定、修改參數(shù)就能完成的。僅僅是功能測試就要占據(jù)很大的工作內容，我們要用全新的思維去面對情況的變化。

第二類整車模型的特點在于，具有閉環(huán)反饋功能。比如，假如圖1中的被測對象vcu，輸出了一個信號，ToqReq，給電機，而整車模型要模擬電機的功能，就要在檢測到vcu發(fā)的“ToqReq”信號之后，將通過CAN卡發(fā)送給vcu的的“車速”信號不斷提升，實現(xiàn)積分的功能。

這樣，當我們通過HIL測試的面板（面板和整車模型可以是不同的東西）踏板，控制板卡的模擬量輸出腳的電壓給vcu，vcu檢測到電壓，發(fā)ToqReq給整車模型，整車模型對車速積分，把車速提上去。最終，整體上看，踏板踩一下，車速就上去了，很動感，很形象，效果也很直觀。

大量的這種具有閉環(huán)交互功能的軟件代碼，就成了“第二類整車模型”，他們讓這個HIL測試變得很逼真，也很形象。雖然，難度非常非常大，雖然新能源車發(fā)展迅速，改動很大且很難沿用。

下面，師子一號要發(fā)話了，并且予以佐證。

首先，第一類整車模型是非常有必要的，沒有他們，測試無法真正進行，除非屏蔽掉被測對象某些功能，它才會不報錯。

第二，“第二類整車模型”，是從傳統(tǒng)車遺傳過來的一些做法，它不適用于新能源車。只有我們和傳統(tǒng)車一樣，是在為了HIL臺架上做標定的情況下，“第二類整車模型”才有必要做得很復雜很逼真。

第三，師子一號認為，HIL不適合做標定，HIL更適合做功能測試，與其花大量精力去做第二類整車模型，去仿真電機等零部件的運行特征，還不如直接去車上標定，效果更好，更有意義。并且，如果我們在HIL上做標定，那功能測試去哪里做？實際上，只有功能測試差不多了，才能進行標定。

第四，師子一號推薦只做第一類整車模型，然后開放出其他信號的控制接口，做功能HIL測試。

關于第四點，原因在于，針對功能測試，第二類整車模型，雖然更形象更動感，但是不適用，除了好看一些，價值不大。第二類整車模型，通過閉環(huán)反饋給被測對象的，往往就是一些常規(guī)的值（取決于整車模型的輸出值類型），這大大降低了控制器功能測試的覆蓋率，使得測試工程師很難自由設計各種信號組合、工況，深入測試被測對象（圖1示VCU）的功能。

HIL上的“第二類整車模型”，開發(fā)周期非常長，效果非常一般。最后往往非但不能為項目出力，檢查控制器的功能，反而要借助項目中的控制器，去查HIL設備以及整車模型是不是有問題！??！

“第二類整車模型”在一定條件下，是可以轉化成“第一類整車模型”的，判斷的關鍵點在于，是不是“必須的”。

假如，我們的被測對象，比如vcu，具備了車速積分偵測功能，它在發(fā)出ToqReq信號的同時，也實時監(jiān)測車速有沒有上來，如果車速沒有上來，vcu就認為車可能出了問題，然后就報故障。這種情況下，車速閉環(huán)的“第二類整車模型”就變成了“第一類整車模型”了，變成了必須的。

師子一號認為，在HIL設備上，做好了必要的“第一類整車模型”之后，把其他信號全部通過面板接出來，予以控制或者檢測，是效果最好的HIL功能測試方案。這種測試，vcu每個輸入信號的，都是可以控制的，可以仿真出許多種組合，覆蓋率可以做得很高。

師子一號以自己的切身體驗，認為，這種做法，效果非常之好。但這種方式，對測試工程師個人能力、對研發(fā)流程，都有一定的要求，要求功能定義明確、有清晰的輸出物，并且，很多情況下，測試工程師往往就是功能設計工程師本身。并且，要求提高了，并不是壞事，大家覺得呢？

按照師子一號建議的測試方法，會有很多變量接口出現(xiàn)在控制面板上，這對測試操作人員的細心程度要求很高，人工操作容易出錯（但是效果也是可以的），不過，部分HIL廠商也提供了專門的自動化測試執(zhí)行方案，比如NI公司的TestStand、Dspace公司的automation desk等等，而且，師子一號對此也有專門的研究，提供了一種非常易用、方便復用的基于Excel文件的自動化測試用例設計方法，簡單得讓人很無語，后續(xù)章節(jié)會詳細介紹。

大家要是覺得師子一號說得還不夠通俗易懂，可以在底下或者在后臺留言，后續(xù)會針對性改進。

下一章節(jié)，我們將簡單介紹一下“故障注入”的概念。

.adva-cont{margin: 20px 0;background: #f2f2f2;width: 604px;height: 200px;padding: 20px;position: relative;}.adva-cont .img-cont{float: left;position: relative;width: 160px;height: 160px;padding: 20px;background: #FFF;}.adva-cont .img-cont img{position: absolute; top: 50%; left: 50%; max-width: 90%; max-height: 90%; transform: translate(-50%,-50%); -webkit-transform: translate(-50%,-50%);}.adva-cont h3 a{font-family: SimHe, '黑體';text-decoration: none;font-size: 20px;color: #000;display: -webkit-box;-webkit-box-orient: vertical;-webkit-line-clamp: 2;overflow: hidden;}.adva-cont .adva-text{position: absolute;top: 50%;transform: translateY(-50%);padding: 20px 20px 20px 230px;}.adva-text p{margin-top: 30px;}.adva-text p a{height: 79px;text-decoration: none;font-size: 14px;color: #666;display: -webkit-box;-webkit-box-orient: vertical;-webkit-line-clamp: 4;overflow: hidden;}#keywordsHidden{display:none;}HIL硬件在環(huán)測試新能源汽車電控測試