基于CANoe搭建的空調(diào)系統(tǒng)服務(wù)測試方法

【摘" 要】文章主要闡述一種基于Vector總線搭建的仿真測試方法，利用CANoe工具搭建仿真測試環(huán)境，對SOA架構(gòu)開發(fā)下的空調(diào)系統(tǒng)進行功能服務(wù)測試，以便能提高測試效率，縮減開發(fā)周期和成本。

【關(guān)鍵詞】空調(diào)系統(tǒng)服務(wù)；SOA架構(gòu)；CANoe；仿真測試

中圖分類號：U463.851" " 文獻(xiàn)標(biāo)識碼：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—），女，電子電氣架構(gòu)設(shè)計工程師，主要從事汽車電子電氣架構(gòu)設(shè)計與開發(fā)工作。

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

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

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

SOME/IP是實現(xiàn)服務(wù)通信標(biāo)準(zhǔn)化的一個中間件協(xié)議，也是車載以太網(wǎng)技術(shù)中的核心內(nèi)容。而應(yīng)用SOA架構(gòu)的空調(diào)系統(tǒng)開發(fā)需要交互大量的復(fù)雜數(shù)據(jù)，百兆、千兆甚至是多G以太網(wǎng)被引入到車內(nèi)，故傳統(tǒng)的測試無論是軟件測試、硬件測試，還是集成測試，都無法滿足當(dāng)下基于SOA架構(gòu)開發(fā)的控制器測試需求，所以針對采用SOA架構(gòu)開發(fā)的空調(diào)系統(tǒng)測試需搭建一套新的針對以太網(wǎng)的測試平臺，并同步增加服務(wù)接口功能和通信測試等。

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

1" CANoe工具介紹

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

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

2" 測試環(huán)境搭建

2.1" 硬件臺架搭建

本臺架主要模擬了空調(diào)系統(tǒng)的測試過程，測試內(nèi)容包括測試上位機、CANoe設(shè)備、12V穩(wěn)壓電源、中央控制器?，F(xiàn)有空調(diào)硬件測試臺架如圖1所示，其系統(tǒng)邏輯框圖如圖2所示。

1）12V穩(wěn)壓電源：為測試系統(tǒng)提供穩(wěn)定的電源供給。

2）中央控制器：主要負(fù)責(zé)空調(diào)邏輯控制，通過百兆以太網(wǎng)和CANoe連接。

3）CANoe設(shè)備：主要為空調(diào)系統(tǒng)測試搭建仿真測試環(huán)境（仿真HUT客戶端）和空調(diào)數(shù)據(jù)庫測試參數(shù)配置。

4）測試上位機：提供測試數(shù)據(jù)通信界面，便于測試人員輸入控制參數(shù)且確認(rèn)測試結(jié)果。

2.2" 仿真環(huán)境搭建

通過CANoe進行以虛擬節(jié)點為基礎(chǔ)的仿真分析來驗證空調(diào)系統(tǒng)物理節(jié)點的功能。物理節(jié)點指實際使用場景中的節(jié)點（CCU），虛擬節(jié)點指CANoe仿真的節(jié)點（HUT）和實際物理節(jié)點所對應(yīng)的網(wǎng)絡(luò)節(jié)點。因此，用CANoe系統(tǒng)搭建一個新測試工程文件，充分利用CANoe系統(tǒng)的模型化界面優(yōu)勢，從輸入?yún)?shù)到輸出參數(shù)及中間變量都可以在界面中加以同步顯示，不僅可以實時觀測當(dāng)前測試模塊系統(tǒng)變化，也可以為完善邏輯設(shè)計提供更有力的測試環(huán)境。數(shù)據(jù)庫的導(dǎo)入和服務(wù)建模的步驟詳見下文。

1）將創(chuàng)建好的ARXML文件導(dǎo)入到CANoe新建工程中，分別添加CCU和HUT服務(wù)節(jié)點并分配建模，如圖3、圖4所示。

2）將CCU和HUT相對應(yīng)端口和地址進行創(chuàng)建，同步根據(jù)SOME/IP-SD協(xié)議配置SD數(shù)據(jù)參數(shù)，如圖5、圖6所示。

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

3" 空調(diào)系統(tǒng)服務(wù)實例測試

空調(diào)系統(tǒng)具有除霜、溫度調(diào)節(jié)、內(nèi)外循環(huán)、風(fēng)量等級調(diào)節(jié)等功能，在SOA架構(gòu)開發(fā)時均將其定義為標(biāo)準(zhǔn)化服務(wù)接口。本文以空調(diào)風(fēng)量等級調(diào)節(jié)服務(wù)為例來搭建仿真環(huán)境并測試。

3.1" 風(fēng)量等級調(diào)節(jié)服務(wù)邏輯

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

3.2" 風(fēng)量等級調(diào)節(jié)服務(wù)數(shù)據(jù)庫搭建

根據(jù)空調(diào)風(fēng)量等級調(diào)節(jié)功能實現(xiàn)邏輯，編制風(fēng)量等級調(diào)節(jié)服務(wù)矩陣，主要包含風(fēng)量控制服務(wù)WindCtrlInpSrv和風(fēng)量狀態(tài)服務(wù)WindCtrlStsSrv。根據(jù)服務(wù)矩陣，可通過PREEVISION生成ARXML文件，ARXML是空調(diào)風(fēng)量等級調(diào)節(jié)數(shù)據(jù)庫，也可導(dǎo)入CANoe中直接使用。風(fēng)量控制服務(wù)WindCtrlInpSrv中有4個接口，詳細(xì)闡述如下。

1）風(fēng)量等級控制服務(wù)接口BloweLevelReq_Command_ Enum：定義風(fēng)量等級共7個擋位，由0—7，0表示OFF，即風(fēng)量關(guān)閉，7表示最高風(fēng)量等級。

2）風(fēng)量等級客戶端接口AC_ClntID：定義風(fēng)量等級客戶端共3個，0表示HUT調(diào)節(jié)風(fēng)量等級，1表示硬開關(guān)調(diào)節(jié)風(fēng)量，2表示遠(yuǎn)程調(diào)節(jié)風(fēng)量大小，但不排除后續(xù)增加客戶端，故增加3Reserved；當(dāng)AC_ClntID=0時，表示HUT端請求調(diào)節(jié)風(fēng)量；當(dāng)AC_ClntID=1時，表示CCSM硬開關(guān)端請求調(diào)節(jié)風(fēng)量；當(dāng)AC_ClntID=2時，表示遠(yuǎn)程請求調(diào)節(jié)風(fēng)量。

3）風(fēng)量等級服務(wù)端接口AC_InstID：定義服務(wù)執(zhí)行端共2個，0表示前空調(diào)，1表示后空調(diào)；當(dāng)AC_InstID=0，表示前空調(diào)調(diào)節(jié)風(fēng)量；當(dāng)AC_InstID=1，表示后空調(diào)調(diào)節(jié)風(fēng)量。

4）風(fēng)量等級響應(yīng)接口Response_Enum：定義共2個，0表示服務(wù)響應(yīng)成功，定義為OK；1表示服務(wù)響應(yīng)未成功，定義為NOK。

當(dāng)空調(diào)執(zhí)行成功后，則空調(diào)當(dāng)前風(fēng)量等級狀態(tài)同樣會反饋，且同步顯示執(zhí)行成功的等級調(diào)節(jié)。其中，風(fēng)量等級狀態(tài)服務(wù)WindCtrlStsSrv中有1個接口。

風(fēng)量等級狀態(tài)服務(wù)接口FrontACVentnLevelDispSt：對應(yīng)風(fēng)量等級控制的狀態(tài)顯示，擋位從0—7；若風(fēng)量等級控制執(zhí)行成功，則風(fēng)量等級狀態(tài)同步反饋顯示同一等級，狀態(tài)與控制是一一對應(yīng)的，若不一一對應(yīng)則證明功能驗證未通過?？照{(diào)風(fēng)量控制服務(wù)矩陣編制見表1。

4" 仿真測試

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

空調(diào)風(fēng)量控制面板參數(shù)值如圖9所示，其報文響應(yīng)如圖10所示。可看出空調(diào)系統(tǒng)風(fēng)量等級調(diào)整控制驗證是可行的，得出的仿真結(jié)果具有較好的一致性，表示測試成功。

5" 總結(jié)

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

參考文獻(xiàn)：

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

[2] 王永輝. CANoe在整車系統(tǒng)開發(fā)測試中的應(yīng)用[J]. 汽車實用技術(shù)，2019（16）：85-87.

（編輯" 凌" 波）