前一段時間做了一個VCU的HIL測試工作，最近在整理整個的調(diào)試過程，寫了一份總結(jié)，在這里和大家分享一下。這里聲明一下，這里的內(nèi)容不做為指導性內(nèi)容，只是詳細講述一下測試過程和心得體會，供大家討論交流！下面步入正題：

Speedgoat公司：

本人工作中使用的機柜為Speedgoat提供的，這里也簡單介紹下這個公司。

1. Mathworks聯(lián)營公司，于2006由MathWorks前員工成立

2. 總部位于瑞士伯爾尼，分部門位于Natick（美國波士頓）和德國漢諾威

3. 致力提供專門針對Simulink環(huán)境的實時系統(tǒng)

4. 在Mathworks和Speedgoat內(nèi)，核心團隊(僅實時仿真和測試部門)約100人

可能可能 會問，為什么不選擇dspace的產(chǎn)品？當然是公司沒錢啦。業(yè)內(nèi)有一個調(diào)侃：一個公司如果購買HIL設(shè)備要走招標流程，那dspace就不來了。。。。。因此他的設(shè)備基本上都是比較貴的，招標他肯定沒戲。

機柜介紹

機柜的組成如下圖：

1） 電源分配箱：將進入的電力分配給各個模塊；

2） 程控電源：提供可控的電力；

3） 信號調(diào)理電源：為信號調(diào)理提供電力

4） 低壓負載測試箱：提供負載電阻

5） 調(diào)試CAN口：可進行信號采集和標定

6） 上下接插件：連通機柜與VCU之間的信號交互

7） DIO調(diào)理板卡：調(diào)理作用

8） 低壓故障注入箱：提供故障注入

9） 實時系統(tǒng)：目標機

對機柜有大致的了解之后就要開始對VCU收發(fā)的信號進行定義了，這里需要明白的是，機柜發(fā)出和接收信號，都是通過板卡來實現(xiàn)的。我們可以把板卡看作是一個重要的中轉(zhuǎn)，它可以接收到VCU發(fā)出來的信號，并通過驅(qū)動的配置將其發(fā)給目標機，目標機再根據(jù)其中的模型執(zhí)行相應(yīng)的動作；他也可以將目標機中發(fā)出的指令轉(zhuǎn)換成信號發(fā)給VCU，從而實現(xiàn)VCU和機柜的信號交互。這里就需要對板卡的資源進行分配和定義。

• I/O接口定義和資源分配

板卡中包含IO133、IO144等多個型號，在模型中使用板卡時，需要利用驅(qū)動對其進行管理調(diào)配，具體步驟如下:

1.打開Speedgoat提供各板卡的IO驅(qū)動庫：

方法1：在Simulink庫中直接找到該庫，可右鍵打開

方法2：在Matlab窗口輸入speedgoatlib

2.板卡驅(qū)動的使用

步驟1：將實時目標機具備的IO硬件的驅(qū)動模塊拖拽到模型中；

步驟2：將算法與IO硬件的驅(qū)動模塊鏈接

步驟3：通過對話界面配置IO通道和通訊協(xié)議；

步驟4：從Simulink模型自動的創(chuàng)建，并在實時機上運行你的應(yīng)用

3.以IO133板卡為例（僅舉例，用戶需使用自己系統(tǒng)中有的板卡）：

步驟1：將setup模塊首先拖到模型中，并打開做相應(yīng)配置，如使用系統(tǒng)中第幾塊IO133，模擬通道激活那幾路（輸入方式如[1 2]，或[1:4]，或[1:3 5]），每路的電壓范圍（不同板卡有不同設(shè)定）。數(shù)字通道的方向等（具體可參見setup模塊的help說明）

步驟2：將要使用的通道如ADC，DAC模塊添加到模型（如果模塊的接口沒有依據(jù)setup的設(shè)定自動調(diào)整，可Ctrl+D更新一下），并將模塊與模型連接即可。

4.接口定義分配

在收到VCU引腳定義后，需對引腳信號進行分類，其收發(fā)的信號通常包括Digital Input、Digital Output、Analog Input、Analog Output、PWM Input、PWM Output等類型，因此需要根據(jù)各板卡的特性，對各接口進行定義。這里據(jù)一個例子進行說明。

板卡的使用電機水泵電源控制，為Digital Output，則需要在板卡里找到Digital Input的接口，將其對應(yīng)的接插件管腳記錄下來，并在驅(qū)動中完成配置，完成接口定義。如果為Analog Input，還需進行電壓等其他配置。

經(jīng)過DIO的為可自定義的接口，因此若在資源分配中發(fā)現(xiàn)某一類型的接口不夠用，可以在Digital Input/Output之間相互轉(zhuǎn)換，以便對板卡進行資源分配。

整車環(huán)境模型架構(gòu)

整車環(huán)境模型的搭建是一個龐大的工程，里面涉及到車上的各個模塊邏輯和相關(guān)功能，還需考慮到各模塊之間的通訊、信號觀測和自動化測試等諸多因素，因此在搭建模型是建議參照如下原則。

獨立性：將CAN信號、IO信號、控制ECU、硬件模型、環(huán)境模型劃分模塊搭建，混在一起會導致模塊混亂、通用性差；

可觀測性：提前了解操作平臺的可觀測屬性和可標定屬性，在搭建模型時需要有意識的將重要模塊的輸入信號做Override，輸出信號做成可觀測量；

適用性：及時了解自動化測試所使用的工具和相關(guān)屬性，例如TPT只可控制Subsystem的最外層接口，因此需要將集成后的模型再打包成子模型；

便捷性：模塊的輸出信號和輸入信號的順序，要按照DBC的順序進行統(tǒng)一，方便后面的修改替換；

檢測順序：

模型搭完后需對模型的正確性、信號收發(fā)的正確性和面板控制的正確性等方面進行檢測，此過程中的檢測步驟如下：

1. 總線檢測：通過萬用表測量VCU接插件端到機柜板卡端的通斷，確?？偩€的正確性；

2. 板卡功能定義檢測：檢測板卡的輸入信號解析和輸出信號發(fā)送是否符合板卡定義，例如數(shù)字信號定義、模擬信號定義、PWM波信號定義等；

3. 駕駛員控制面板的檢測：檢測駕駛員控制操作，如油門、踏板、KeyON/Start等；

調(diào)試順序：

檢測工作完成后就進入了具體的調(diào)試階段了，在功能測試中慢慢發(fā)現(xiàn)問題，完善環(huán)境模型。在此過程中需遵循從簡單基礎(chǔ)功能開始測試的原則，逐漸覆蓋全功能，具體調(diào)試順序可參考如下：

1. 信號收發(fā)調(diào)試：完善信號收發(fā)必備的LIVECOUNTER 和CHECKSUM的計算；

2. 信號發(fā)送的正確性校驗：通過CANalyzer或CANape觀測報文，并校驗信號發(fā)送是否正確；

3. 上下電功能調(diào)試：根據(jù)設(shè)計要求，調(diào)試上下電功能；

4. 睡眠喚醒調(diào)試：根據(jù)設(shè)計要求，調(diào)試睡眠喚醒功能；

5. 充電功能調(diào)試：根據(jù)設(shè)計要求，調(diào)試充電功能；

車輛可以正常行駛后，開始對各個功能進行調(diào)試，在測試中發(fā)現(xiàn)問題，不斷優(yōu)化模型。