基于總線數據及Simulink熱管理軟件測試方法

中圖分類號：U463.6 文獻標識碼：A 文章編號：1003-8639（2025）07-0178-0：

TestMethod Based on Bus Data and Simulink Thermal Management Software

Xu Jinsheng，Zhang Yue，Li Jiaye，Zhong Linggui

（AutomotiveEngineering Research Institute，Guangzhou AutomobileGroupCo.，Ltd.，Guangzhou510ooo，China）

【Abstract】Against the backdrop of the developmentof new energyandinteligent connectedvehicles，the importanceof software testing andfault locationof thevehicle thermal management system has become prominent.The article focuses onsoftware unit verificationand integration testing，and proposesa test scheme modeled bythe MBD method based onCAN bus datainthe Simulink environment.Byconstructinga test system including bus tools，CAN communicationconversion，etc.，the upper computer is realized to simulateandaccess thereal vehicle CAN data for white-box testing.Intheverificationofthehuman-computer interactionmodule，thismethodrealizesthe functional integrationanddebugging withtheaidof thebuspaneltol.Intheinvestigationofrealvehiclefaults，thetraditional compilationstepwasomitted，reducingtheproblem troubleshotingtimefrom 2hours to50minutes，effectivelyimproving the efficiency and quality of software iteration.

【Key words】 thermal management software；CAN bus；MBD method；software testing；white-box verification;faultlocation

0 引言

隨著新能源汽車的普及，整車熱管理系統的功能需求日益復雜。其除了需要滿足乘員艙冷熱管理，還需肩負起電池系統熱管理的需求，在整車中的作用俞發重要。同時，在智能網聯汽車的發展背景下，熱管理系統的控制功能和邏輯大幅增加，如何對熱管理軟件進行系統測試，以及在軟件出現問題后快速高效地定位具體原因，成為亟待解決的重要問題。

目前，乘用車主機廠軟件開發普遍采用V字開發流程。整個流程為：系統需求分析 $$ 系統架構設計 $$ 軟件需求分析 $$ 軟件架構設計 $$ 軟件詳細設計和單元構建 $$ 軟件單元驗證 $$ 軟件集成和集成測試$$ 軟件合格性測試 $$ 系統集成和系統合格性測試。綜合以往研究可知，在軟件測試領域，行業內眾多專家已在軟件合格性測試以及系統集成與合格性測試中提出了大量優秀解決方案。例如，在HIL機柜中通過Simulink建模并結合Python腳本，可實現測試的自動化，降低測試成本；利用狀態機搭建測試流程，通過離散輸入量，能減少測試數量并增加測試覆蓋率等。

基于上述研究現狀，本文將重點從軟件單元驗證和集成測試的角度，探索提升開發效率的方法。采用基于模型的設計（Model-BasedDesign，MBD）進行軟件建模，同時利用CAN總線輸入建立測試模型，這樣無需依賴控制器和調試器等硬件環境，通過上位機仿真連接實車CAN總線數據，即可進行軟件白盒仿真檢驗，當出現問題時，也能快速定位軟件內部原因并迭代修復。

1測試系統設計與實現

1.1基于MBD的熱管理軟件建模

MBD是一種以模型為核心開展項目開發的方法。該方法通過對系統進行分析、建模和驗證，然后直接利用模型生成軟件代碼。使用MBD進行軟件設計開發具有諸多優點： ① 能夠簡化開發環境，減少對不同工具環境的依賴； ② 可將復雜功能分解為單元模塊進行開發，且獨立單元模塊可單獨測試； ③ 便于直接與一些物理模型進行聯合仿真，提前檢驗軟件算法效果； ④ 相較于手寫代碼，基于規則生成的代碼質量更高，便于直接使用靜態代碼進行異常檢驗。

綜上所述，使用MBD建模軟件可使邏輯更加直觀，開發迭代和仿真測試更為快速，已成為嵌入式軟件開發的主要方式。目前，應用較多的MBD建模工具是MATLAB公司的Simulink。本文基于Simu-linkAUTOSAR框架構建了整車熱管理控制模型，該模型涵蓋信號輸入、信號輸出、人機交互控制模塊、信號數字處理模塊、舒適性計算及控制模塊、制冷路控制模塊、空氣質量模塊、整車熱管理模式及驅動模塊等。熱管理軟件模塊如圖1所示。

1）信號輸入輸出模塊主要負責接收和發送總線信號、內部信號以及服務信號，同時對信號進行分辨率放縮轉化和總線異常處理，例如總線超時異常、傳輸數據為矩陣中定義的無效值等情況，

2）信號數字處理模塊用于進行負載故障診斷、DTC處理，如DTCDebounce函數防抖可由各節點應用層自行制定。該模塊還包含信號濾波以及信號異常值處理等運算，信號濾波通常采用滑移均值濾波、一階線性濾波、卡爾曼濾波算法等。

3）人機交互模塊負責主機大屏等相關外部輸入處理以及交互反饋和空調模式狀態存儲。輸入處理包括原子服務功能、空調硬按鍵功能、語音信號功能、主機虛擬按鍵信號等輸入源信號的歸一執行；交互反饋則依據功能清單邏輯進行處理并反饋顯示狀態信號。

4）舒適性計算模塊承擔乘員艙冷熱負荷計算和乘員艙部分舒適性控制任務。乘員艙冷熱負荷計算主要基于外溫、內溫、乘客設置的目標溫度、陽光輻射、車速等參數計算目標出風溫度。舒適性控制主要包括箱體控制，如鼓風機、內外循環風門、模式風門、溫度風門等的邏輯控制。

5）制冷路控制模塊進行壓縮機、EXV、電磁閥等模式的邏輯運算和驅動處理。制冷路相關負載控制依據系統需求和特性可對應相關負載制定控制參數，比如制冷工況時，壓縮機轉速根據目前蒸發器溫度控制；熱泵采暖工況時，壓縮機可以根據目標水溫或自標低壓壓力控制轉速。

6）整車熱管理驅動模塊負責計算電池熱管理模式、采暖發動機耦合等水路控制模式，以及相關負載驅動。電池熱管理模式主要控制信號依據BMS請求信號，但電池散熱是使用壓縮機提供冷源還是使用電驅耦合散熱器提供散熱需要整車熱管理模塊綜合判斷。同樣作為PHEV或REEV車型何時請求發動機啟動采暖或耦合發動機熱水等需求也需要整車熱管理模塊綜合判斷。模塊還涉及一些水路和空氣路負載邏輯及驅動，如風扇、水泵、多通閥、比例三通閥體等控制。

7）空氣質量模塊執行相關空氣凈化功能，如蒸發器自干燥等功能，以及在AQS空氣質量差或外部PM2.5高時切換內循環等。同時還驅動空氣質量負載，如香氛、等離子等。

1.2 測試系統建立

基于總線數據軟件測試框架由總線工具、CAN通信轉換、全局數據函數和主模型測試框架構成，如圖2所示。

1）總線工具采用同星TSMaster，利用其總線實時仿真或在線回放功能，需將不同CAN通道中所需數據映射至同一CAN通道上，以避免因虛擬通道過少而導致數據無法傳輸的問題，總線通道映射采用虛擬通道。在實際采集數據時，可能存在一個節點在不同CAN網段中都有數據的情況，此時需要先對CAN數據進行篩選過濾，對原始報文進行預處理后再進行報文在線回放。

2）CAN通信轉換采用將實車CAN網絡數據直接導人測試模型的方式，使用Simulink中的CANFD配置模塊、CANFD數據接收發送模塊、CANFD數據解包模塊實現。配置模塊需要配置對應虛擬通道及波特率；CANFD數據解包模塊需要導人CAN矩陣DBC文件，并選取對應報文幀進行解包。DBC基本信息需按照通信矩陣協議制作，包含報文ID、信號長度、信號起始位，而為了方便模型直接引入采集數據，需要將信號分辨率轉換、信號偏移量、信號最大值和信號最小值按照解包前數據進行更改。

3）構建全局函數時，可直接使用原始客服/服務接口（CS接口）索引，以方便測試工程構建，但需要考慮對應全局函數數組的大小，防止出現構建的全局函數無法包含實際使用總線函數定義范圍而導致超限的問題。全局函數構建完成后，可直接引入CANFDUnpack和Pack工具包。

4）主模型測試框架使用SimulinkMIL（ModelInLoop）測試框架生成，生成后的測試框架包含軟件輸入輸出接口、熱管理主體軟件封裝后模型、軟件內部調度表、全局變量接口，如圖3所示。

輸入、輸出接口中包含軟件初始上電時的NVM讀取存儲值、原子服務接口以及內部應用交互信號，可根據測試用例及需求選擇必要接口進行輸人輸出導人。軟件主體模塊為熱管理軟件整體打包封裝后的模型。由于熱管理軟件模塊具有獨立性與復雜性，采用MBD建模后，軟件內部分為多個模塊獨立運行。內部調度表為實際運行時每個子模塊的調度順序及周期，其直接采用ARXML字典中任務調度序列進行設置，如圖4所示。若并非AUTOSAR架構，則可自行編寫任務調度序列。

2 測試系統應用

2.1 人機交互模塊白盒驗證

隨著智能網聯汽車的興起，熱管理軟件中人機交互（HumanMachineInterface，HMI）模塊的功能不斷增加。然而，熱管理軟件與主機大屏軟件分屬不同團隊開發，開發周期不同，因此HMI的測試成為熱管理軟件開發中的重要環節。

在軟件開發前期階段，可利用總線設備面板工具對HMI進行功能聯調和模型白盒測試。設計的空調總線工具面板如圖5所示，該面板包含主要的空調功能，如風量加減調節、主副駕設置溫度加減、Auto按鍵及狀態顯示、AC按鍵及狀態顯示、除霜按鍵及狀態顯示、內外循環按鍵及狀態顯示、速冷/速暖/通風等按鍵及狀態顯示。

將面板按鍵信號綁定實車CAN矩陣，并按照CAN矩陣速率實時仿真發送，然后通過測試系統接入熱管理模型進行HMI內部模塊測試。采用CAN信號直接輸入模型的方式，更貼近實際HMI運行環境，能夠觀測HMI實際反饋的顯示信號，當出現交互問題時，也便于在模型內部直接進行數據流追蹤，從而快速高效地鎖定問題并進行迭代開發。

2.2實車故障數據問題調查

以實車故障數據為例進行測試，故障類型為電池水泵轉速低導致電池溫差增大，如圖6所示。由于水泵控制為軟件內部變量邏輯計算，并未發送到總線，因此無法直接查出問題原因。傳統的調查方法是先在模型中增加臨時變量，然后編譯最新模型，再通過調試器觀察臨時變量來鎖定內部問題。完成這一全套流程，從熱管理模型轉換為可刷寫的BIN文件，至少需要2h，尤其是在目前整車電器架構已升級為區域控制器的背景下，從編譯模型到刷寫文件的轉化耗時增加更為明顯。

而本測試系統可直接將問題總線數據接入模型，無需額外增加流程。CAN數據連入模型后如圖7所示，模型接收的CAN數據與實車采集數據一致。同時，可實時讀取電池水泵控制的內部狀態和變量。通過對數據流的追查，最終發現問題原因是開發初期階段電池水泵控制狀態機中的需求定義不完善，在特定工況下無法及時增加電池水泵轉速，導致電池水泵在較低轉速時間過長，進而使電池進出水溫差過大，最終導致電池溫差被放大。

采用基于總線數據耦合熱管理模型的測試方法，只需對原測試MIL工程進行小改后導人實車CAN數據，省去了額外的軟件編譯步驟。調查上述問題大約僅用時 50min ，而且方便軟件開發人員直接定位、精準鎖定問題。在軟件更新后，可采用相同的測試CAN數據直接進行回歸測試，大大加快了軟件迭代速度，提升了軟件品質。

3結論

本文從軟件單元驗證和集成測試的角度，提出了一種基于CAN總線數據在Simulink環境建模下的軟件開發測試方法。利用該方法，可在上位機直接導人總線數據進行模擬測試，無論是對軟件單元模塊的驗證，還是對集成白盒測試或問題調查，開發人員都能夠實時觀測軟件內部的動態運行過程和變量。此方法可有效節省熱管理軟件功能開發及調試周期，提升軟件問題解決速度，提高軟件迭代品質。

參考文獻

[1]許思睿，龔代花.基于Simulink及CANoe的電動助力轉向系統ADAS性能測試方法研究[J].時代汽車，2024（19）：122-124.

[2]胡海華，季金強，錢正華.基于CAN總線的自動化測試系統[J].汽車電器，2024（7）：67-70.

[3]鄭淳允，江坤.汽車空調控制器自動化測試建模的研究與應用[J].自動化應用，2023，64（16）：25-27.

[4]夏鋅.基于硬件在環的電動汽車整車控制器功能測試方法研究[D].天津：天津大學，2014.

[5]查正運.基于模型驅動的汽車電子軟件開發方法研究[J].科技創新與應用，2015（25）：76.

（編輯凌波）