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

Speedgoat公司：

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

Mathworks聯營公司，于2006由MathWorks前員工成立

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

致力提供專門針對Simulink環境的實時系統

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

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

機柜介紹

機柜的組成如下圖：

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

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

3） 信號調理電源：為信號調理提供電力

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

5） 調試CAN口：可進行信號采集和標定

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

7） DIO調理板卡：調理作用

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

9） 實時系統：目標機

圖1 Speedgoat VCU機柜

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

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

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

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

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

方法2：在Matlab窗口輸入speedgoatlib

圖2 speedgoat提供的模型庫

2.板卡驅動的使用

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

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

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

步驟4：從Simulink模型自動的創建，并在實時機上運行你的應用

圖3 驅動板卡的使用

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

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

圖4 IO133板卡使用

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

圖5 IO板卡添加到模型中

4.接口定義分配

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

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

圖2 IO133板卡接口

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

整車環境模型架構

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

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

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

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

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

檢測順序：

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

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

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

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

調試順序：

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

1.?信號收發調試：完善信號收發必備的LIVECOUNTER 和CHECKSUM的計算；

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

3.?上下電功能調試：根據設計要求，調試上下電功能；

4.?睡眠喚醒調試：根據設計要求，調試睡眠喚醒功能；

5.?充電功能調試：根據設計要求，調試充電功能；

車輛可以正常行駛后，開始對各個功能進行調試，在測試中發現問題，不斷優化模型。

編輯：黃飛

?