徐永新，劉建飛，華 典，朱 娟

（濰柴動力股份有限公司，山東 濰坊 261061）

科技的進步與發(fā)展使得人們的生活與工作更加電子化、自動化與智能化，汽車電子技術(shù)也在不斷地創(chuàng)新與發(fā)展。隨著控制器功能的不斷擴張，各個廠家對自身產(chǎn)品的控制和信息讀取提出了更多的要求，為了規(guī)范各個制造商的產(chǎn)品的質(zhì)量和規(guī)范性，國際規(guī)定了統(tǒng)一的協(xié)議來滿足制造商的需求。

基于控制器局域網(wǎng) （Controller Area Network, CAN）總線的統(tǒng)一診斷服務(wù)（Unified Diagnostic Services, UDS）協(xié)議診斷被廣泛應(yīng)用到國內(nèi)外的控制器開發(fā)中，來滿足自身的開發(fā)需求和客戶的下線與使用需求。電子控制單元（Electronic Control Unit, ECU）的UDS協(xié)議及功能的正確性必須得到充分的保證，便于產(chǎn)品的推廣及應(yīng)用。

目前測試方法更多的偏向使用報文收發(fā)工具進行手動測試或使用專用診斷工具測試；專用工具無法提前開發(fā)，常常會出現(xiàn)因工具未及時交付導(dǎo)致控制器本身沒有全面測試而出現(xiàn)質(zhì)量問題，導(dǎo)致ECU軟件開發(fā)成本的增加。UDS診斷系統(tǒng)自動化測試可以高效完成基于報文交互的全面測試，從而降低缺陷率，減少軟件開發(fā)成本。

1 UDS診斷系統(tǒng)

ECU的UDS診斷測試主要分為診斷協(xié)議測試和診斷功能測試。

UDS協(xié)議是基于開放系統(tǒng)互聯(lián)（Open Systems Interconnection, OSI）參考模型設(shè)計，采用分層結(jié)構(gòu)，主要包括物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、會話層和應(yīng)用層。ISO14229協(xié)議定義了通用診斷服務(wù)，這些診斷服務(wù)允許診斷儀控制車輛內(nèi)部ECU內(nèi)的診斷功能，但是ISO14229協(xié)議僅定義了應(yīng)用層的服務(wù)，而ISO15765協(xié)議是基于CAN總線實現(xiàn)了UDS協(xié)議，二者與OSI的映射關(guān)系如表1所示。

表1 UDS協(xié)議與OSI的映射關(guān)系

本文主要闡述的UDS診斷協(xié)議為應(yīng)用層的ISO14229協(xié)議。

UDS協(xié)議診斷功能單元主要有診斷和通信管理功能單元、數(shù)據(jù)傳輸功能單元、傳輸儲存的數(shù)據(jù)功能單元、輸入輸出控制功能單元、遠程激活例程功能單元、上傳下載功能單元，本文主要闡述表2中UDS相關(guān)服務(wù)。

表2 UDS服務(wù)列表

UDS診斷系統(tǒng)中有三種會話模式，分別是正常會話模式、擴展模式及編程模式。其中正常會話模式，是ECU根據(jù)輸入接口信號的變化進行邏輯計算從而控制車輛行駛；擴展模式主要用于外部維修及執(zhí)行器測試；而編程模式則是進行ECU內(nèi)部數(shù)據(jù)刷寫。當(dāng)存在外部請求時，會根據(jù)0x10服務(wù)進行會話模式的切換。

然而為保證ECU數(shù)據(jù)的安全性及軟件的正常運行，擴展模式及編程模式下的外部請求操作需要經(jīng)過0x27服務(wù)的密鑰安全校驗，順利通過安全校驗則解鎖ECU，進行維修測試或數(shù)據(jù)刷寫等操作，否則外部請求無效，ECU會回復(fù)響應(yīng)以提示安全校驗失敗。具體流程如圖1所示。

圖1 安全訪問流程圖

診斷協(xié)議主要測試國際標(biāo)準(zhǔn)化組織（International Organization for Standardization, ISO）標(biāo)準(zhǔn)協(xié)議中規(guī)定的內(nèi)容，借助CANoe等診斷工具即可完成；而診斷功能主要測試ECU的輸入輸出功能是否滿足軟件開發(fā)需求，比如外部設(shè)備請求ECU輸出啟動繼電器吸合的控制信號，則需要觀察啟動繼電器負載是否有輸出。本文著重介紹UDS診斷功能的自動化測試。

2 測試系統(tǒng)搭建

測試UDS診斷功能需要搭建一個閉環(huán)系統(tǒng)，從硬件輸入信號的變化到ECU的響應(yīng)輸出最終到執(zhí)行器的實際動作檢測，才是一條完整的測試流程并能保證測試的有效性及功能的正確性。通常的閉環(huán)測試系統(tǒng)如圖2所示，主要包括被測ECU、硬件在環(huán)測試設(shè)備（Hareware In the Loop, HIL）臺架（含有虛擬或真實負載）、診斷工具（Vector Hardware）、標(biāo)定工具（Integrated Calibration and Acquisition Systems, INCA）、上位機。

圖2 測試閉環(huán)系統(tǒng)

依據(jù)上述的測試平臺，需要工程師對ECU中的每一條數(shù)據(jù)流、每一個執(zhí)行器的診斷進行測試，數(shù)量之多，耗時耗力，且UDS的診斷測試操作相似，非常適合自動化測試及測試用例的移植。本文依據(jù)自動化測試軟件ECU-TEST進行測試用例的開發(fā)。

ECU-TEST工具可以與HIL設(shè)備、INCA、Vector-Hardware進行鏈接，并通過應(yīng)用程序編程接口（Application Programming Interface, API）函數(shù)對HIL設(shè)備上位機軟件、INCA、Vector-Hardware進行讀寫操作，而且ECU-TEST軟件支持二次開發(fā)，可以通過開發(fā)Python腳本實現(xiàn)特殊的測試需求，保證測試用例的順利進行。

3 自動測試用例實現(xiàn)

根據(jù)圖2所示的測試環(huán)境，通過ECU-TEST自動化測試軟件將Vector、INCA及HIL上位機軟件連接起來，形式閉環(huán)測試系統(tǒng)，并在ECU-TEST中編制測試用例及相應(yīng)的腳本實現(xiàn)UDS診斷系統(tǒng)的自動化測試。

3.1 數(shù)據(jù)流自動化測試

數(shù)據(jù)流測試是根據(jù)ISO14229協(xié)議中的0x22服務(wù)獲取ECU中相關(guān)變量的數(shù)值，該服務(wù)不需要經(jīng)過ECU的安全訪問。

數(shù)據(jù)識別符（Data Identifier, DID）數(shù)據(jù)流信息匯總?cè)绫?所示，在測試過程中根據(jù)DID碼獲取ECU的響應(yīng)，并將返回值根據(jù)其基礎(chǔ)數(shù)據(jù)類型、因子及偏移進行換算與INCA（XCP:1協(xié)議）監(jiān)測值進行對比，判斷DID碼返回值是否正確。

表3 DID數(shù)據(jù)流信息

DID數(shù)據(jù)流的自動化測試采用ECU-TEST的Parameter Generator功能實現(xiàn)，可以在20 min內(nèi)完成300條DID數(shù)據(jù)流的自動化測試，其測試流程如圖3所示。該測試方法簡單、高效且便于移植。

圖3 DID數(shù)據(jù)流測試流程

3.2 執(zhí)行器測試與服務(wù)功能自動化測試

UDS的執(zhí)行器測試與服務(wù)診斷測試，使用ISO14229協(xié)議的0x2F服務(wù)及0x31服務(wù)，需要經(jīng)過ECU的安全訪問才可以進行后續(xù)操作，如圖1所示。

為確保ECU軟件及整車的行駛安全性，不同的控制器、相同的控制器不同的功能都會有各自的安全校驗算法。因此，診斷功能的自動化測試難點及關(guān)鍵點就是如何與ECU完成安全校驗。

ECU安全校驗算法文件是ECU的門戶，在ECU的生命周期中密級是最高的，所以無法獲取該文件中的具體算法，因而可以使用腳本調(diào)用該算法文件間接實現(xiàn)全面的自動化測試。通過ECU-TEST調(diào)用Vector的API函數(shù)模擬圖1的安全訪問過程，在獲取到Seed時調(diào)用Python腳本計算出Key，然后再通過Vector的API函數(shù)發(fā)送給ECU，從而實現(xiàn)與ECU的安全校驗。安全訪問的自動化測試用例流程如圖4所示，圖5為某ECU安全訪問自動化測試順利通過安全訪問的測試報告。

圖4 安全訪問測試流程

圖5 安全訪問報告

將安全訪問的自動化測試用例封裝成模塊庫，可以被ECU各執(zhí)行器的測試任意調(diào)用。診斷功能的自動化測試流程如圖6所示，其中“安全訪問”是對安全訪問自動測試用例模塊庫的調(diào)用。

圖6 執(zhí)行器自動化測試

某發(fā)動機ECU執(zhí)行器測試的自動化測試用例如圖7所示，測試報告如圖8所示。

圖7 某發(fā)動機ECU執(zhí)行器診斷自動測試用例

圖8 測試報告

4 結(jié)束語

通過對某發(fā)動機ECU執(zhí)行器診斷功能的測試，充分證明該自動測試方法可以順利通過ECU的安全訪問并完成對ECU數(shù)據(jù)流讀取、執(zhí)行器測試和服務(wù)診斷功能的驗證，大大縮減了ECU軟件開發(fā)過程中的重復(fù)性測試的工作量，保證了軟件測試的高效性和一致性，有效保障了軟件的開發(fā)進度及UDS診斷系統(tǒng)質(zhì)量。