基于總線數(shù)據(jù)及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 引言

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

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

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

1測試系統(tǒng)設計與實現(xiàn)

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

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

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

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

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

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

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

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

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

7）空氣質(zhì)量模塊執(zhí)行相關空氣凈化功能，如蒸發(fā)器自干燥等功能，以及在AQS空氣質(zhì)量差或外部PM2.5高時切換內(nèi)循環(huán)等。同時還驅(qū)動空氣質(zhì)量負載，如香氛、等離子等。

1.2 測試系統(tǒng)建立

基于總線數(shù)據(jù)軟件測試框架由總線工具、CAN通信轉(zhuǎn)換、全局數(shù)據(jù)函數(shù)和主模型測試框架構(gòu)成，如圖2所示。

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

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

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

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

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

2 測試系統(tǒng)應用

2.1 人機交互模塊白盒驗證

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

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

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

2.2實車故障數(shù)據(jù)問題調(diào)查

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

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

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

3結(jié)論

本文從軟件單元驗證和集成測試的角度，提出了一種基于CAN總線數(shù)據(jù)在Simulink環(huán)境建模下的軟件開發(fā)測試方法。利用該方法，可在上位機直接導人總線數(shù)據(jù)進行模擬測試，無論是對軟件單元模塊的驗證，還是對集成白盒測試或問題調(diào)查，開發(fā)人員都能夠?qū)崟r觀測軟件內(nèi)部的動態(tài)運行過程和變量。此方法可有效節(jié)省熱管理軟件功能開發(fā)及調(diào)試周期，提升軟件問題解決速度，提高軟件迭代品質(zhì)。

參考文獻

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

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

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

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

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

（編輯凌波）