羅　峰, 郁靜華

(1. 同濟大學(xué) 汽車學(xué)院, 上海 201804; 2. 同濟大學(xué) 新能源汽車工程中心, 上海 201804)

?

汽車統(tǒng)一診斷服務(wù)診斷協(xié)議棧網(wǎng)絡(luò)層測試方法

羅峰1,2, 郁靜華1,2

(1. 同濟大學(xué) 汽車學(xué)院, 上海 201804; 2. 同濟大學(xué) 新能源汽車工程中心, 上海 201804)

摘要：提出了一種基于CAN總線的汽車統(tǒng)一診斷服務(wù)(UDS)診斷協(xié)議棧開發(fā)過程中的網(wǎng)絡(luò)層功能測試方法.利用AutoCAN總線設(shè)計工具，將位于PC機的上層測試儀與搭載有被測協(xié)議棧的下層測試儀連接，形成實際總線測試網(wǎng)絡(luò).通過參數(shù)分層法，結(jié)合實際被測協(xié)議棧通信要求，建立測試用例集，并據(jù)此編寫測試腳本和仿真運行.通過監(jiān)控每一條測試用例的報文流記錄，判斷其是否符合測試要求.該方法能夠?qū)崿F(xiàn)UDS診斷協(xié)議棧的網(wǎng)絡(luò)層測試，驗證網(wǎng)絡(luò)層是否符合國際標準.

關(guān)鍵詞：統(tǒng)一診斷服務(wù); 網(wǎng)絡(luò)層; 功能測試; 參數(shù)分層方法

國際標準ISO14229[1]，即統(tǒng)一診斷服務(wù)(unified diagnostic service，UDS)，將各種基于不同總線網(wǎng)絡(luò)的診斷服務(wù)進行了統(tǒng)一的規(guī)定，從而使得在不同物理介質(zhì)下，對車輛的相關(guān)診斷服務(wù)的開發(fā)和應(yīng)用變得更為便捷.

汽車UDS診斷協(xié)議棧是指符合統(tǒng)一診斷服務(wù)(UDS)標準,能夠?qū)崿F(xiàn)車輛標準化診斷通信的系統(tǒng).對于每一個完成開發(fā)的UDS協(xié)議棧而言，對其進行專業(yè)而規(guī)范的測試必不可少.這能保證所開發(fā)的協(xié)議棧符合國際標準，滿足通信設(shè)計需求.因此，UDS協(xié)議棧的測試技術(shù)也是在汽車UDS開發(fā)過程中較為重要的一個方面.

目前，國內(nèi)外的一些研究人員及公司都對該技術(shù)有著一定的研究.德國Vector Informatik 公司對于該診斷協(xié)議棧，有著一條完整的開發(fā)工具鏈.使用測試工具CANoe Option DiVa，可根據(jù)導(dǎo)入的數(shù)據(jù)庫文件，自動生成測試用例后對整個協(xié)議棧進行自動化測試[2].使用CANdelaStudio，則可建立診斷數(shù)據(jù)庫文件[3].以上方法均采用Vector Informatik公司的診斷工具鏈中的專業(yè)工具對協(xié)議棧進行測試，專業(yè)便捷，且使用較為廣泛.但其工具價格較為昂貴，使用成本較高.并且以上方法均為對整個UDS協(xié)議棧的測試，而沒有對協(xié)議棧中的單獨網(wǎng)絡(luò)層測試.

除上述方法外，還使用LabVIEW工具，設(shè)計了一個虛擬測試儀[4]，它能夠?qū)f(xié)議棧的應(yīng)用功能進行驗證.或使用VC6.0環(huán)境開發(fā)了一個測試用上位機，并且通過USBCAN接口卡，將PC機連入總線網(wǎng)絡(luò)進行測試[5].以上方法所使用的工具成本較低，易于獲得，但其對協(xié)議棧所做的驗證工作，并不全面和規(guī)范.只是針對協(xié)議棧所要求的應(yīng)用功能做了簡單驗證，并沒有全面專業(yè)地將規(guī)范中一些關(guān)鍵處進行測試.

本文設(shè)計了一種UDS診斷協(xié)議棧的網(wǎng)絡(luò)層功能測試方法.該方法使用AutoCAN總線設(shè)計工具，搭建實際測試網(wǎng)絡(luò).通過參數(shù)分層法，結(jié)合實際被測協(xié)議棧通信要求，建立測試用例集并據(jù)此編寫腳本，仿真通信過程.最后通過分析實際通信時的報文記錄，從而判斷各條件下的單獨網(wǎng)絡(luò)層工作是否通過測試.

該方法無需高昂的專業(yè)軟件費用，并且可以單獨對網(wǎng)絡(luò)層進行測試.因此在協(xié)議棧自下而上的開發(fā)過程中，只要完成了網(wǎng)絡(luò)層的部分功能，即可馬上測試已完成部分的功能，而無需等待整個協(xié)議棧完成后再進行測試，保證了開發(fā)的效率.此外，使用該參數(shù)分層方法進行用例設(shè)計，使得一個協(xié)議棧的測試更加完整通用，解決了上述部分文獻中用例測試過于零散、不全面的問題.

1測試體系架構(gòu)

1.1測試環(huán)境

本測試環(huán)境框如圖1所示.

圖1　測試環(huán)境框圖

其中，被測協(xié)議棧(protocol stack under test，PSUT)是搭載在下層測試儀(lower tester, LT)來進行測試實現(xiàn)的.根據(jù)測試規(guī)范，LT將特定測試用例的參數(shù)傳給被測協(xié)議棧，并給當前用例創(chuàng)造所需的運行條件.上層測試儀(upper test，UT)則用來模擬PSUT使用者的行為，測試中按照測試要求與PSUT進行通信，從而驗證PSUT是否正常工作.消息監(jiān)測則記錄整個通信過程中的CAN報文流，從而對照測試規(guī)范來判斷本次測試是否通過.UT與LT之間則通過測試規(guī)范來進行統(tǒng)一協(xié)調(diào).

1.2測試對象

本文測試對象為基于CAN總線的汽車UDS診斷協(xié)議棧網(wǎng)絡(luò)層部分.參考ISO15765-2標準中的描述[6]，可以將整個UDS協(xié)議棧大致分為3個層次，結(jié)構(gòu)如圖2所示.

圖2　基于CAN總線的UDS診斷協(xié)議棧結(jié)構(gòu)

其中，最底層為CAN數(shù)據(jù)鏈路層和物理層，能實現(xiàn)基本CAN報文的收發(fā)[7]；中間層是網(wǎng)絡(luò)層，能對上下層之間傳輸?shù)臄?shù)據(jù)進行打包或解包；最上層是應(yīng)用層，能根據(jù)接收的數(shù)據(jù)，執(zhí)行相應(yīng)的服務(wù).每一個層次都有對應(yīng)的國際標準來規(guī)范使用.

網(wǎng)絡(luò)層在整個UDS協(xié)議棧中起到了一個重要的橋梁作用.因此，在整個協(xié)議棧的開發(fā)中，必須保證網(wǎng)絡(luò)層能夠按照標準中的要求正常工作，這樣才能有效地進行下一步開發(fā).

一個正確的網(wǎng)絡(luò)層包含以下幾個主要方面：上下層間服務(wù)原語工作正常；單幀及多幀的傳輸操作正常，數(shù)據(jù)有效；上下層間數(shù)據(jù)映射正確；定時參數(shù)要求滿足；能正確進行異常處理.因此，對于網(wǎng)絡(luò)層的測試必須完整包含這幾個方面，才能確保測試結(jié)果的正確性.

2測試組織設(shè)計

2.1通用步驟

一個完整的測試實際是由很多個小的測試用例組成，每一個測試用例針對被測對象的性能要求，組織不同的測試環(huán)境，對某一目標功能進行驗證.雖然測試用例內(nèi)容不同，但都遵循著一個通用的測試步驟，從而有序規(guī)范地進行測試.本文的每一個測試用例都遵循以下3個通用步驟:①測試前，建立當前測試用例的測試環(huán)境，即根據(jù)本條測試規(guī)則，修改下層測試儀對應(yīng)參數(shù)值，并載入對應(yīng)用例的上層測試儀測試腳本.②測試時，打開報文記錄儀，運行測試工具仿真.③測試后，根據(jù)所記錄的報文流，對照本條用例測試規(guī)范，判斷是否通過，并在報告記錄結(jié)果及必要的分析.至此則完成了一個有效的用例測試.依照此通用步驟依次進行，則可完成整個測試.

2.2用例設(shè)計

測試用例的設(shè)計是整個測試規(guī)范制定當中較為重要的一部分.好的用例可以較為完整地反映被測對象的性能，判斷是否符合設(shè)計規(guī)范要求，發(fā)現(xiàn)可能的潛在錯誤并及時修正.

在本測試中，因被測對象為UDS網(wǎng)絡(luò)層協(xié)議棧，本身可配置參數(shù)較多，功能要求也較為復(fù)雜，因此，此處采用一種分層結(jié)構(gòu)，將各種功能或主要參數(shù)合并分類，理清相互之間的關(guān)系，從而能夠較為有效地設(shè)計出合理的測試用例.

參數(shù)分層結(jié)構(gòu)如圖3所示.

圖3　參數(shù)分層結(jié)構(gòu)

如圖3所示，第1層為通信類型層，分為單幀傳輸，多幀無流控傳輸和多幀有流控傳輸.單幀傳輸即為數(shù)據(jù)在單個CAN報文中就能夠傳輸完成.網(wǎng)絡(luò)層能支持最高達4 095個字節(jié)的數(shù)據(jù)傳輸，而CAN報文一次只能收發(fā)8個字節(jié).因此，網(wǎng)絡(luò)層通過多幀傳輸?shù)姆绞?，也就是將?shù)據(jù)拆分或組裝來實現(xiàn).多幀傳輸可使用或不使用流控幀來完成通信.第2層為通信方向?qū)?，分為被測協(xié)議棧至上層測試儀和上層測試儀至被測協(xié)議棧.該分類保證了網(wǎng)絡(luò)層在兩個方向上都能夠正常工作.第3層為通信狀態(tài)層，分為正常通信和錯誤通信.正常通信用于驗證不同參數(shù)下網(wǎng)絡(luò)層是否能夠按照規(guī)范正常工作，而錯誤通信則用來檢查網(wǎng)絡(luò)層能否進行正確的錯誤處理.第4層為參數(shù)層，其中可包含有剩余的各種不同參數(shù).

當?shù)?層為正常通信時，第4層參數(shù)包括，數(shù)據(jù)長度，CANID，是否優(yōu)化數(shù)據(jù)，尋址方式，目標地址類型和消息類型.這些參數(shù)根據(jù)上面各層的參數(shù)選擇，按需要設(shè)置.例如，在特定的網(wǎng)絡(luò)層要求下，遍歷本層某個關(guān)鍵的參數(shù)值而保持其他參數(shù)不變，來檢查網(wǎng)絡(luò)層在此關(guān)鍵參數(shù)的每一種情況下都是否能正常工作.

當?shù)?層參數(shù)為錯誤通信時，第4層參數(shù)則為錯誤要求.此參數(shù)根據(jù)上面各層的參數(shù)選擇，按需要進行設(shè)置.例如，在有流控情況下LT傳輸多幀時，可設(shè)置UT在接收到首幀時不響應(yīng)，使得LT端N_Bs參數(shù)超時，來驗證此錯誤能否被正確檢測到并處理.或者，多幀傳輸中，設(shè)置后續(xù)幀的幀編號不連續(xù)，從而檢測接收方在收到錯誤序列幀時能否報告幀序列錯誤的情況.

根據(jù)以上的分層方法，排列組合前3層參數(shù)，并根據(jù)組合出來的每一種情況，按實際被測網(wǎng)絡(luò)層要求設(shè)置第4層參數(shù)，最后可得到一張完整的網(wǎng)絡(luò)層功能測試用例表，如表1所示.表中OK表示正確測試；ERR表示錯誤測試.

表1　網(wǎng)絡(luò)層功能測試用例表格式

需要說明的是，并不是所有的變量都必須遍歷.在實際測試中，可根據(jù)被測協(xié)議棧的具體要求，只取關(guān)鍵變量進行測試即可，而忽略無關(guān)變量.例如在本文中，目標網(wǎng)絡(luò)層的消息類型均為診斷消息，且尋址方式為混合尋址，因此，在形成測試用例時直接將該兩個變量排除，減小測試用例數(shù)量.

3測試驗證

3.1測試環(huán)境建立

要完成整個實物功能測試，首先必須建立一個實際的測試環(huán)境.使用飛思卡爾XDP512芯片作為測試系統(tǒng)中的下層測試儀，上面搭載被測協(xié)議棧，用PC機作為上層測試儀，模擬協(xié)議棧使用者行為.兩者接入同一CAN網(wǎng)絡(luò)，建立通信.

測試環(huán)境實物連接圖如圖4所示.

其中，AutoCAN為德國益馳公司的一款CAN總線設(shè)計測試工具，它能夠直接接入CAN網(wǎng)絡(luò)，用上位機向網(wǎng)絡(luò)中發(fā)送或者接收報文，對網(wǎng)絡(luò)層進行監(jiān)控及操作.它還支持腳本操作，通過編寫相應(yīng)腳本代碼，仿真被測協(xié)議棧用戶的行為，來驗證協(xié)議棧工作是否正常.測試環(huán)境中的消息監(jiān)測工作也將通過AutoCAN本身的報文記錄儀進行記錄.

圖4　測試環(huán)境實物連接圖

下層測試儀通過燒寫器將測試參數(shù)的修改載入到下層測試儀中.而在PC端，則通過調(diào)用對應(yīng)的AutoCAN測試腳本，來實現(xiàn)特定測試行為的配置.CANH和CANL為CAN總線的通信中的兩種信號，CANH為CAN高，CANL為CANAL.

3.2測試實現(xiàn)

以測試用例表中的某一用例為例，詳細說明一個網(wǎng)絡(luò)層測試的全過程.

3.2.1規(guī)范描述

該測試用例用于驗證：被測協(xié)議棧能否在有流控幀的情況下，正確向使用者發(fā)送多幀數(shù)據(jù).

(1) 測試準備

測試環(huán)境正確建立.下層測試儀：配置協(xié)議棧，寫命令令其上電3 s后自行發(fā)送30個字節(jié)的數(shù)據(jù).上層協(xié)議棧載入“有流控多幀接收”腳本.打開AutoCAN報文記錄儀，等待開始.

(2) 測試進行

運行仿真后，給下層測試儀上電.3 s后下層測試儀開始發(fā)送數(shù)據(jù)，通信開始，直至完成.

(3) 結(jié)果判斷

根據(jù)報文流記錄，判斷上層端是否接收到完整的數(shù)據(jù)，且在接收到首幀后，上端向總線發(fā)出一個流控幀.各報文數(shù)據(jù)格式正確.

3.2.2測試準備

首先對下層測試儀端做相關(guān)設(shè)置，使其發(fā)送的數(shù)據(jù)滿足要求.主要參數(shù)修改如表2所示.

然后在PC端使用AutoCAN腳本仿真功能，來響應(yīng)接收到的首幀.

在AutoCAN界面上選擇“仿真”選項卡，并右鍵在通道1中“插入仿真節(jié)點”，完成后界面如圖5所示.

表2　下層測試儀端變量值修改

圖5　仿真網(wǎng)絡(luò)配置界面

接著對該仿真節(jié)點進行配置，主要是選擇一個腳本文件，用于規(guī)定該節(jié)點在仿真過程中的一些執(zhí)行動作.而后在腳本文件中編寫相關(guān)代碼，實現(xiàn)所需處理.

為了實現(xiàn)上述測試用例中的功能，在腳本文件中，需要定義一個CAN報文類型的變量，并將其配置成流控幀的形式.其函數(shù)如下所示.

Configure_message(&msg1,0x654,1,1,8,0x03,0x08,0x04,0xff,0xff,0xff,0xff,0xff);

(1)

其中configure_message函數(shù)的參數(shù)依次表示所配置消息變量的地址，報文ID,是否為標準幀，是否為數(shù)據(jù)幀，數(shù)據(jù)場長度以及8個數(shù)據(jù)場數(shù)據(jù).

然后在CAN報文事件中規(guī)定：一旦接受到CAN ID號為0x123的報文時，立即啟動一個5 ms的定時器，當該定時器計數(shù)溢出后，則向網(wǎng)絡(luò)上發(fā)送事先配置好的流控幀.當完成腳本，并編譯通過后，即可等待測試.

3.2.3測試進行

測試過程較為簡單，只需點擊AutoCAN上位機仿真按鈕，并給下層測試板上電后，待其自行完成即可.

3.2.4結(jié)果判斷

報文完成發(fā)送后，即停止運行，并根據(jù)報文流記錄，來查看整個通信過程.

圖6為仿真測試的報文流記錄.從中可以看到，當AutoCAN接收到了中央控制單元(electronic control unit, ECU)端發(fā)來的首幀，并等待了一個時間間隔后，其向總線上發(fā)出一個流控幀.當ECU接收到了該流控幀后，則開始發(fā)送續(xù)幀直至30個字節(jié)的數(shù)據(jù)全部發(fā)送完成.最后的4個FF字節(jié)即為選擇數(shù)據(jù)自動填充后，網(wǎng)絡(luò)層對CAN報文數(shù)據(jù)場的自動填寫數(shù)據(jù).

圖6　仿真測試的報文流記錄

整個過程符合本條測試規(guī)范的要求，從而得出，本條測試用例通過.

在某些測試中，得到的測試結(jié)果可能不能滿足要求，則表示測試不通過.這種情況下，需要根據(jù)下層測試儀端變量的變化及報文流的記錄，分析并定位協(xié)議棧的問題，修改后重新按照測試步驟執(zhí)行，直至全部通過.

3.2.5測試總結(jié)

根據(jù)上述步驟，可以對測試用例表中的用例一一測試.使用上文描述的參數(shù)分層法，測試用例表中共有28個測試用例，其涵蓋了對網(wǎng)絡(luò)層協(xié)議棧的主要功能，如單幀與多幀的收發(fā)，流控機制，不同數(shù)據(jù)流方向，是否具有填充數(shù)據(jù)等測試.并根據(jù)國際標準中規(guī)定的錯誤處理情況，人為模擬出不同的故障情況，進行錯誤測試.

通過AutoCAN工具及仿真腳本，能方便地控制網(wǎng)絡(luò)中的數(shù)據(jù)行為，實現(xiàn)了單獨網(wǎng)絡(luò)層的功能測試.通過觀察AutoCAN的報文記錄以及在調(diào)試模式下查看下層測試儀中相關(guān)變量的改變情況，從而能夠判斷該條測試用例是否正確實施了，最后得出完整的網(wǎng)絡(luò)層測試情況報告.

4結(jié)論

設(shè)計了一種對汽車UDS診斷協(xié)議棧網(wǎng)絡(luò)層進行功能測試的方法.首先給出了測試的通用架構(gòu)及步驟，以及分層方法下測試用例集的設(shè)計.根據(jù)用例規(guī)范要求，編寫測試腳本并使用AutoCAN工具進行實際網(wǎng)絡(luò)測試，從而實現(xiàn)網(wǎng)絡(luò)層功能的測試.

該方法具有較好的通用性，對測試用例的設(shè)計可以根據(jù)具體的被測協(xié)議棧的要求進行變化，以達到最高的測試效率.對于總線工具的使用，只需選擇支持腳本編輯的總線工具即可，無需使用特定的昂貴工具.從而提高了開發(fā)效率，也降低了開發(fā)成本.

參考文獻:

[1]International Organization for Standardization. ISO14229-1 Road vehicles-unified diagnostic services (UDS)-Part 1: Specification and requirements[S]. Geneva: ISO, 2013.

[2]Peti Philipp, Timmerberg Armin, Pfeffer Thomas,etal. A quantitative study on automatic validation of the diagnostic services of Electronic Control Units [C]//IEEE International Conference on Emerging Technologies and Factory Automation, Hamburg: IEEE, 2008: 799-808.

[3]馬莎,奚英澤,戢慧，等.汽油機ECU基于ODX的UDS數(shù)據(jù)庫開發(fā)[C]//2013中國汽車工程學(xué)會年會論文集.北京：中國汽車工程學(xué)會，2013:413-415.

MA Sha, XI Yingze, JI hui,etal. UDS database development of gasoline ECU based on ODX[C]//SAE-China, Annual Meeting Proceedings of SAE-China. Iasi: SAE, 2013: 413-415.

[4]Salcianu M, Fosalau C. A new CAN diagnostic fault simulator based on UDS protocol [C]∥2012 International Conference and Exposition on Electrical and Power Engineering (EPE). Iasi: IEEE, 2012: 820-824.

[5]韓鑫,鮑可進.CAN總線網(wǎng)絡(luò)層協(xié)議淺開發(fā)測試[J].計算機工程,2011,37(15):232.

HAN Xin, BAO Kejin. Development and test of CAN bus network layer protocol stack[J]. Computer Engineering, 2011,37(15):232.

[6]International Standard Organization (ISO). ISO15765-2 Road vehicles—diagnostics on controller area networks (CAN)—Part 2: network layer services [S]. Geneva: ISO, 2004.

[7]International Standard Organization(ISO). ISO11898-1 Road vehicles—controller area network (CAN)—part 1: data link layer and physical signalling [S]. Geneva: ISO, 2003.

Approach for Network Layer Test in Vehicle Unified Diagnositc Service Diagnostic Protocol Stack

LUO Feng1,2, YU Jinghua1,2

(1. College of Automotive Studies, Tongji University, Shanghai 201804, China; 2. New Energy Automotive Engineering Center, Tongji University, Shanghai 201804, China)

Abstract：The paper presents an approach for network layer test, which is important during the development of unified diagnostic service(UDS) diagnostic stack. The upper tester in PC was connected to the lower tester, which carried the protocol stack under test, by a network-design tool called AutoCAN to build a test network. After analyzing the characteristics of network parameters and the demands of the device under test, a test case set was designed with the parameters classified method. Then the scripts were programmed and AutoCAN simulated the progress of all the designed communications. By monitoring every record of CAN frames transmission, it is clear to decide if this test meets the requirements of the specification. This method can accomplish the network-layer functional tests and find whether it works correctly based on the relevant international standards.

Key words：unified diagnostic service; network layer; functional test; parameters classified method

文獻標志碼：A

中圖分類號：TP1

通訊作者：郁靜華(1990—)，女，碩士生，主要研究方向為汽車網(wǎng)絡(luò).E-mail:yujinghua@outlook.com

收稿日期：2015—04—06

第一作者： 羅峰(1969—)，男，教授,主要研究方向為汽車網(wǎng)絡(luò). E-mail: luo_feng@#edu.cn