基于CANoe搭建的空調系統服務測試方法

【摘" 要】文章主要闡述一種基于Vector總線搭建的仿真測試方法，利用CANoe工具搭建仿真測試環境，對SOA架構開發下的空調系統進行功能服務測試，以便能提高測試效率，縮減開發周期和成本。

【關鍵詞】空調系統服務；SOA架構；CANoe；仿真測試

中圖分類號：U463.851" " 文獻標識碼：A" " 文章編號：1003-8639（ 2024 ）08-0091-03

AC System Simulation Test of Function Service Based on CANoe

CHAI Hua，ZHANG Song，WU Zhongfeng，GENG Weifeng

（Hebei Automotive Technology Innovation Center of Great Wall Motor Co.，Ltd.，Baoding 071000，China）

【Abstract】The article mainly elaborates on a simulation testing method based on Vector bus，using CANoe tool to build a simulation testing environment，and conducting functional service testing on air conditioning systems under SOA architecture development，in order to improve testing efficiency，reduce development cycle and cost.

【Key words】AC system services；SOA architecture；CANoe；simulation testing

作者簡介

柴華（1986—），女，電子電氣架構設計工程師，主要從事汽車電子電氣架構設計與開發工作。

空調作為提高汽車乘坐舒適性的一種重要部件已被廣大汽車制造企業及消費者所認可。在“軟件定義汽車”實現汽車智能化、多元化的需求下，空調系統開發由傳統的嵌入式開發改為SOA軟件開發。應用SOA軟件架構不僅能實現空調軟硬件解耦，將空調更多的功能以標準化服務接口的形式封裝到中央控制器CCU，而且根據以太網的動態配置特性還可進行不同服務接口的調用，給用戶帶來更好的空調服務體驗，在節省整車帶寬負載的前提下，能更好滿足用戶對空調的需求。

汽車空調把車內的溫度、濕度、空氣清潔度及車內風量控制在最佳狀態，為駕駛員和乘員提供舒適的乘坐環境，不僅減少了車內人員的路途疲勞，而且空調中的通風裝置對行車時的散熱也起到了重要作用。故整車功能開發中，空調系統的開發占據了越來越重要的地位。

隨著整車功能的持續增加和用戶多樣化的需求，空調系統可采用SOA架構開發方式來滿足日益復雜的功能增長需求。SOA架構，即面向服務的架構，采用軟件分層的模型開發方式，將空調系統中不同功能單元模塊通過服務定義成標準接口，通過服務訂閱與推送的方式建立層之間的通信關系。在系統開發中，SOA軟件架構在基于服務的模塊化和以太網動態的通信方式上去設計和擴展上層的應用。通過構建靈活可變的平臺系統，實現服務間松耦合、無依賴、可復用、可靈活重組及通信標準化。

SOME/IP是實現服務通信標準化的一個中間件協議，也是車載以太網技術中的核心內容。而應用SOA架構的空調系統開發需要交互大量的復雜數據，百兆、千兆甚至是多G以太網被引入到車內，故傳統的測試無論是軟件測試、硬件測試，還是集成測試，都無法滿足當下基于SOA架構開發的控制器測試需求，所以針對采用SOA架構開發的空調系統測試需搭建一套新的針對以太網的測試平臺，并同步增加服務接口功能和通信測試等。

CANoe設備作為一種控制器局域網絡（Controller Area Network）開發及測試工具，具備強大的節點仿真能力，故本文提出一種新的采用SOA軟件架構開發的空調系統功能服務驗證的思路：在空調系統功能開發完成后，利用CANoe對HUT模塊進行模擬仿真，并接入控制空調系統的硬件模塊中央控制器CCU，在臺架上實現二者功能交互的測試及驗證，這樣可提前發現、解決問題并完善軟件功能，縮短開發周期，提高開發效率。

1" CANoe工具介紹

CANoe是Vector公司推出的主要功能為整車仿真分析和通信測試的專業軟件工具，其豐富的功能和配置被廣泛應用到項目開發的各個階段。在開發過程中，可以通過CANoe設備虛擬仿真來測試控制器的功能，進行虛擬節點和部分物理節點的聯合仿真，測試分析整個系統功能，能盡早發現問題，解決問題。

本文主要使用了CANoe仿真環境軟件完成仿真模型的建立、測試及分析，仿真環境集成了Application Panel、Trace等環境來監測結果并分析。在CANoe設備自身的控制面板中修改參數，在Trace頁面中直接查看報文響應結果是否滿足功能開發邏輯要求。

2" 測試環境搭建

2.1" 硬件臺架搭建

本臺架主要模擬了空調系統的測試過程，測試內容包括測試上位機、CANoe設備、12V穩壓電源、中央控制器。現有空調硬件測試臺架如圖1所示，其系統邏輯框圖如圖2所示。

1）12V穩壓電源：為測試系統提供穩定的電源供給。

2）中央控制器：主要負責空調邏輯控制，通過百兆以太網和CANoe連接。

3）CANoe設備：主要為空調系統測試搭建仿真測試環境（仿真HUT客戶端）和空調數據庫測試參數配置。

4）測試上位機：提供測試數據通信界面，便于測試人員輸入控制參數且確認測試結果。

2.2" 仿真環境搭建

通過CANoe進行以虛擬節點為基礎的仿真分析來驗證空調系統物理節點的功能。物理節點指實際使用場景中的節點（CCU），虛擬節點指CANoe仿真的節點（HUT）和實際物理節點所對應的網絡節點。因此，用CANoe系統搭建一個新測試工程文件，充分利用CANoe系統的模型化界面優勢，從輸入參數到輸出參數及中間變量都可以在界面中加以同步顯示，不僅可以實時觀測當前測試模塊系統變化，也可以為完善邏輯設計提供更有力的測試環境。數據庫的導入和服務建模的步驟詳見下文。

1）將創建好的ARXML文件導入到CANoe新建工程中，分別添加CCU和HUT服務節點并分配建模，如圖3、圖4所示。

2）將CCU和HUT相對應端口和地址進行創建，同步根據SOME/IP-SD協議配置SD數據參數，如圖5、圖6所示。

3）所有參數配置操作完畢后，測試工程面板創建完成，如圖7所示。

3" 空調系統服務實例測試

空調系統具有除霜、溫度調節、內外循環、風量等級調節等功能，在SOA架構開發時均將其定義為標準化服務接口。本文以空調風量等級調節服務為例來搭建仿真環境并測試。

3.1" 風量等級調節服務邏輯

風量等級調節是用戶調整空調風量大小來滿足自身需求，可將風量等級調高或調低。用戶調節風量等級時，可通過HUT大屏語音或者開關發出請求，HUT收到請求后向中央控制器調用空調控制服務。在HUT請求服務時，HUT作為客戶端Client：發出請求，中央控制器作為服務端Server：提供服務。中央控制器收到請求后將信息通過CAN通信給到區域控制器，區域控制器則通過硬線驅動鼓風機調節風量，鼓風機風量調節完成后，區域控制器將當前風量等級反饋給中央控制器，中央控制器將風量等級狀態通過服務通知到HUT，HUT顯示當前風量等級并告知客戶。其空調風量調節邏輯如圖8所示。

3.2" 風量等級調節服務數據庫搭建

根據空調風量等級調節功能實現邏輯，編制風量等級調節服務矩陣，主要包含風量控制服務WindCtrlInpSrv和風量狀態服務WindCtrlStsSrv。根據服務矩陣，可通過PREEVISION生成ARXML文件，ARXML是空調風量等級調節數據庫，也可導入CANoe中直接使用。風量控制服務WindCtrlInpSrv中有4個接口，詳細闡述如下。

1）風量等級控制服務接口BloweLevelReq_Command_ Enum：定義風量等級共7個擋位，由0—7，0表示OFF，即風量關閉，7表示最高風量等級。

2）風量等級客戶端接口AC_ClntID：定義風量等級客戶端共3個，0表示HUT調節風量等級，1表示硬開關調節風量，2表示遠程調節風量大小，但不排除后續增加客戶端，故增加3Reserved；當AC_ClntID=0時，表示HUT端請求調節風量；當AC_ClntID=1時，表示CCSM硬開關端請求調節風量；當AC_ClntID=2時，表示遠程請求調節風量。

3）風量等級服務端接口AC_InstID：定義服務執行端共2個，0表示前空調，1表示后空調；當AC_InstID=0，表示前空調調節風量；當AC_InstID=1，表示后空調調節風量。

4）風量等級響應接口Response_Enum：定義共2個，0表示服務響應成功，定義為OK；1表示服務響應未成功，定義為NOK。

當空調執行成功后，則空調當前風量等級狀態同樣會反饋，且同步顯示執行成功的等級調節。其中，風量等級狀態服務WindCtrlStsSrv中有1個接口。

風量等級狀態服務接口FrontACVentnLevelDispSt：對應風量等級控制的狀態顯示，擋位從0—7；若風量等級控制執行成功，則風量等級狀態同步反饋顯示同一等級，狀態與控制是一一對應的，若不一一對應則證明功能驗證未通過。空調風量控制服務矩陣編制見表1。

4" 仿真測試

測試環境及數據庫搭建完成后，開始啟動測試。首先接通電源，確保測試系統通電正常。進入測試上位機，修改CANoe控制面板參數值，點擊CALL運行按鈕，觀察Trace窗口，當所有信號都顯示正常時，則證明通信正常。此時可在面板中Command處輸入4，表示想調整空調風量等級擋位為4。對應值為BloweLevelReq_Command_Enum=4，AC_ClntID=1，表示此時請求的客戶端為CCSM硬開關。點擊CALL，表示HUT調用空調控制器的風量控制服務WindCtrlInpSrv。在Trace窗口中可觀測到Response響應回復，Response_Enum=0：OK，表示風量等級請求已發出。待中央控制器將空調風量等級調整為4時，則中央控制器反饋空調風量等級當前狀態為4。此時空調狀態服務WindCtrlStsSrv中的風量等級狀態服務接口FrontACVentn LevelDispSt=4。

空調風量控制面板參數值如圖9所示，其報文響應如圖10所示。可看出空調系統風量等級調整控制驗證是可行的，得出的仿真結果具有較好的一致性，表示測試成功。

5" 總結

在面向服務開發的架構需求下，CANoe作為強大的網絡分析與系統仿真工具，為整車系統開發過程中的模型測試、軟件集成測試以及數據監測方面均能提供強大的支持，大大縮短整車系統開發測試周期。本文詳細介紹應用SOA架構開發下空調系統的交互邏輯及交互過程，針對功能服務測試提出了一種新的驗證思路。通過CANoe對HUT模塊進行模擬仿真，結合中央控制器硬件CCU，實現了二者功能交互的測試及驗證。在開發過程中無需等到雙方實物在整車裝配后再進行測試驗證，只要基于空調系統臺架的搭建和CANoe設備來模擬節點測試，對空調系統的功能實例應用進行測試，即可完成空調系統功能驗證。從本文空調風量等級調節驗證過程可知該測試方法是可行的，不僅能夠克服傳統的實車測試費用高、周期長等缺點，還提高了空調系統功能開發效率，為整車系統開發測試提供參考。

參考文獻：

[1] 陳世平，馬駒，陳思. 基于CANoe編程測試電動助力轉向模塊與自動泊車輔助模塊的功能交互[J]. 汽車實用技術，2022，47（7）：107-110.

[2] 王永輝. CANoe在整車系統開發測試中的應用[J]. 汽車實用技術，2019（16）：85-87.

（編輯" 凌" 波）