作者 |李偉 上?？匕舶踩珳y評中心安全測評部總監(jiān)

來源 |鑒源實驗室

引言：前兩篇文章（汽車電子架構(gòu)和CAN網(wǎng)絡(luò)基礎(chǔ)，車載ECU嵌入式軟件的測試入門）我們講了汽車電子架構(gòu)和網(wǎng)絡(luò)歷史，分享汽車測試中的小知識，本章節(jié)我們將從診斷服務(wù)測試開始給大家細(xì)說測試相關(guān)知識。我們一直強(qiáng)調(diào)，CAN網(wǎng)絡(luò)通信是ECU中非常重要的基本功能，診斷服務(wù)就是基于CAN網(wǎng)絡(luò)實現(xiàn)的非常重要的基本功能。在實際項目中，ECU的CAN網(wǎng)絡(luò)測試內(nèi)容項比較多，供應(yīng)商和主機(jī)廠測試，跟網(wǎng)絡(luò)底層相關(guān)的CAN協(xié)議一致性測試之類，比如電平、通信速率、信號的各種精度等，還包括EMC測試，環(huán)境可靠性測試等等。我們這里主要講上層的相關(guān)應(yīng)用測試。

01

診斷相關(guān)基礎(chǔ)小知識

1.1 診斷地址

ECU的診斷地址，跟以太網(wǎng)設(shè)備間通訊地址設(shè)置不一樣。在以太網(wǎng)中每個設(shè)備都有一個唯一標(biāo)識符MAC地址。設(shè)備間的單播通訊如下圖所示：

圖 1

以太網(wǎng)絡(luò)的端口地址直接對應(yīng)物理設(shè)備，設(shè)備出廠時Mac地址直接燒錄在網(wǎng)卡的E2PROM中，從以太網(wǎng)地址配置上也可以看出兩者間的對應(yīng)關(guān)系。ECU的診斷地址是不一樣的，不存在類似以太網(wǎng)那樣的通訊端口，沒有像以太網(wǎng)那樣地址跟設(shè)備端口的綁定關(guān)系，廠商也不會有一個唯一地址在出廠時燒錄進(jìn)CAN處理芯片中，我們可以把它理解為邏輯上的地址。ECU接收到診斷請求時，檢查數(shù)據(jù)幀的接收地址是否跟本ECU配置的診斷地址一致，如果一致則接收并處理，不一致就丟棄。發(fā)送數(shù)據(jù)時則在數(shù)據(jù)幀對應(yīng)位置寫入配置好的本ECU診斷通訊響應(yīng)CANID。通過下圖我們可以直觀的看到診斷通訊關(guān)系。

圖 2

1.2物理尋址和功能尋址

在1.1章節(jié)中我們通過以太網(wǎng)的設(shè)備間單播通訊來類比解釋了CAN網(wǎng)絡(luò)兩個ECU間的一般通訊。我們知道以太網(wǎng)有單播、組播、和廣播通訊，對應(yīng)CAN網(wǎng)絡(luò)有物理尋址（Physical Address）和功能尋址（FunctionalAddress）。

我們通過一個生活中的例子來說明物理尋址和功能尋址的區(qū)別。比如我們在統(tǒng)計辦公室員工的核酸檢測情況時，統(tǒng)計人員分別找到每個員工進(jìn)行詢問，這種方式就類似物理尋址，是一對一的通訊；統(tǒng)計人員在辦公室吼一嗓子“大家核酸都做過了么，分別私下跟我說下”，然后每個員工單獨回復(fù)統(tǒng)計員，這種一對多的詢問就類似功能尋址。

通過上述例子，我們可以知道ECU間點對點通訊是物理尋址實現(xiàn)，一對多發(fā)出請求是通過功能尋址實現(xiàn)。這里我們強(qiáng)調(diào)下即使請求報文是功能尋址，響應(yīng)端發(fā)送回復(fù)報文時依然是使用物理尋址來進(jìn)行答復(fù)（不是功能尋址答復(fù)）。在實際項目中很多ECU的功能尋址地址通常都是0x7DF，具體項目中ECU地址是多少需要查閱項目對應(yīng)的診斷規(guī)范文檔。

通過上面兩個章節(jié)的講解，我們可以知道ECU通常情況下會有3個地址，分別對應(yīng)物理尋址的發(fā)和收，以及功能地址。

我們要注意的是CAN網(wǎng)絡(luò)是總線型網(wǎng)絡(luò)，采用的是CSMA/CA機(jī)制。ECU間的物理尋址和功能尋址的通訊報文在物理層面上其實都是以廣播的形式存在的，所有廣播域內(nèi)的ECU均能收到該通訊報文，至于收到該廣播報文后如何處理，ECU對比報文的目的地址跟自身的物理尋址接收地址和功能尋址地址是否匹配，然后再決定后續(xù)操作。

02

統(tǒng)一診斷服務(wù)（UDS）

UDS的全稱為Unified Diagnostic Services，關(guān)于UDS的詳細(xì)描述和定義，大家可以查閱ISO 14229標(biāo)準(zhǔn)的系列文件來深入了解。網(wǎng)絡(luò)上能夠找到的關(guān)于UDS的文章非常多，我們這里從通俗易懂的角度給大家進(jìn)行介紹，適合測試工程師快速入門，然后在實際項目中有工作經(jīng)歷之后可以通過其他方式再深入了解相關(guān)知識。

之所以一直強(qiáng)調(diào)UDS功能比較重要和基礎(chǔ)，是因為USD功能在車輛生產(chǎn)和使用過程中對很多其他功能模塊和基本操作有直接的影響。首先在車輛生產(chǎn)線下線時，產(chǎn)線電檢會使用電檢儀通過UDS對多個ECU寫入很多必要的預(yù)設(shè)值信息，如寫入對應(yīng)車輛的VIN碼、零件號、物流信息等，還可以激活某些特定設(shè)置，或者鎖定一些特定狀態(tài)以防止零部件的隨意變更等等。車輛在4S店進(jìn)行維護(hù)保養(yǎng)時，ECU固件的升級、故障碼的讀取和消除等等，也是通過OBD口連接使用UDS相關(guān)服務(wù)來完成的。

在上一篇文章中我們提到了，CAN網(wǎng)絡(luò)上設(shè)備間通信基本可以分為3種情況，分別是：設(shè)備周期性主動發(fā)送一些狀態(tài)報文；某個條件發(fā)生改變并符合設(shè)定要求，從而被動觸發(fā)型信號發(fā)送；查詢和回復(fù)型信號。這里查詢和回復(fù)型主要就是UDS功能產(chǎn)生的。

為了方便理解，我們可以不是很準(zhǔn)確地把UDS看作一個應(yīng)用層協(xié)議（實際肯定不準(zhǔn)確），因為在項目開發(fā)、測試、標(biāo)定、排錯等過程中接觸最多的就是應(yīng)用層相關(guān)的功能。

基于查詢和回復(fù)這種問答式通信方法，在CAN網(wǎng)絡(luò)上可以實現(xiàn)很多功能，如獲取信息、寫入信息、會話控制、重啟設(shè)備、上傳下載等等。我們把每種實現(xiàn)了特殊功能的查詢和回復(fù)稱為一種服務(wù)，UDS總體上有6大類，共26種不同服務(wù)。至于在具體項目中，網(wǎng)絡(luò)架構(gòu)工程師和系統(tǒng)設(shè)計工程師會根據(jù)實際情況對ECU支持的UDS服務(wù)種類進(jìn)行裁剪，所以一般情況下ECU支持的服務(wù)種類要少于26種，通常還會對服務(wù)的對子功能做自定義設(shè)計。

2.1 請求報文

請求報文的格式比較簡單，通常由3部分組成，首先是Service ID固定長度1字節(jié)，Service ID直接表明了本服務(wù)支持的功能類型，就是前面我們說的26種服務(wù)中的一種，Sub-Function是對應(yīng)的具體服務(wù)的每個子功能項設(shè)置，有的服務(wù)有多個子功能，也有的服務(wù)沒有子功能，所以Sub-Function項是可選項，最后Parameter項是對應(yīng)到最詳細(xì)子功能的屬性參數(shù)配置項，屬性參數(shù)的配置也是根據(jù)實際情況來進(jìn)行配備。

圖 3

通常Parameter在具體項目中是工程師自定義最多的對象，也有主機(jī)廠在診斷規(guī)范中會自定義子服務(wù)。

我們舉一個常見的服務(wù)來給大家說明下，如10服務(wù)。Service ID是10，功能是用來做會話控制，子功能通常是3個，分別為01、02、03，沒有parameter參數(shù)，3個子功能分別代表了3種不同會話模式。在某個主機(jī)廠的診斷規(guī)范中自定了子功能04，為特殊場景自定義了該會話模式。綜上所述10服務(wù)的請求報文通常會有：10 01、10 02、10 03。

2.2 響應(yīng)報文

對應(yīng)于UDS請求報文，ECU通常有3種不同的響應(yīng)處理。

1）Positive Response正響應(yīng)

正響應(yīng)是ECU對接收到的請求給予明確的成功內(nèi)容結(jié)果返回，意味著請求得到成功執(zhí)行。例如請求是讀取車輛VIN碼，正響應(yīng)就是回答VIN是XXX。

正響應(yīng)返回的報文格式跟請求報文類似分為3個部分，首先是Response SID是對請求服務(wù)的回顯，Response SID的值為請求報文中SID + 0x40；其他兩部分內(nèi)容為Sub-Function和Parameter，這兩部分的內(nèi)容根據(jù)具體情況確定，在項目診斷規(guī)范中有明確規(guī)定。

正響應(yīng)的報文格式如下圖所示：

圖 4

例如：請求10 01，正響應(yīng)為50 01；請求22 XX XX，正響應(yīng)為62 XX XX XX。

2）Negative Response負(fù)響應(yīng)

負(fù)響應(yīng)是ECU收到請求之后，無法對請求的內(nèi)容正確執(zhí)行，回復(fù)了失敗，并附帶了失敗的原因。

負(fù)響應(yīng)回復(fù)報文的格式同樣可以分為3個部分，首先第一個字節(jié)是0x7F，表明請求失敗，第二個字節(jié)為請求的服務(wù)ID，第三個字節(jié)為失敗原因代碼NRC。NRC代碼具體對應(yīng)的失敗原因可以查閱NRC的表格來確定，在具體的項目中這部分內(nèi)容可以查閱項目中的零部件網(wǎng)絡(luò)診斷規(guī)范，在文章中我們多次提及了該文檔，這個文檔是由車型項目組的網(wǎng)絡(luò)電子架構(gòu)團(tuán)隊負(fù)責(zé)整體匯總發(fā)布，零部件的產(chǎn)品系統(tǒng)設(shè)計工程師負(fù)責(zé)維護(hù)和變更，所以在實際項目中可以找這兩個崗位的工程師獲取。

負(fù)響應(yīng)報文格式如下圖所示：

圖 5

例如：請求10 02，負(fù)響應(yīng)7F 10 7E，7F表明該相應(yīng)失敗，對應(yīng)的失敗服務(wù)是10，失敗原因是7E，查閱NRC表知道7E的含義是“Sub-function not supported in active session”，提醒使用請求10 02子功能請求時不應(yīng)該在當(dāng)前會話模式下，當(dāng)前的會話模式不支持10 02子功能請求使用。

3）無響應(yīng)

無響應(yīng)的出現(xiàn)是網(wǎng)絡(luò)架構(gòu)部門為了降低CAN網(wǎng)絡(luò)上報文環(huán)境的復(fù)雜情況而做的設(shè)計。目的是不回復(fù)請求方正響應(yīng)數(shù)據(jù)幀，即，當(dāng)即將答復(fù)的響應(yīng)幀為正響應(yīng)時，不發(fā)送響應(yīng)幀。

無響應(yīng)是通過請求報文中子功能的抑制肯定響應(yīng)指示位實現(xiàn)的。在某些服務(wù)的子功能中，最高的bit7位置為1時即設(shè)置為正響應(yīng)抑制，該位置為0時關(guān)閉響應(yīng)抑制。支持響應(yīng)抑制設(shè)置的服務(wù)有10、11、28、3E、85等等。

圖 6

例如：發(fā)送10 81，當(dāng)回復(fù)是正響應(yīng)時，ECU不答復(fù)；發(fā)送10 82，答復(fù)7F 10 7E，同樣是請求帶正響應(yīng)抑制，但是ECU執(zhí)行失敗，此時則進(jìn)行了回復(fù)。

我們之前強(qiáng)調(diào)，可以把UDS視為應(yīng)用層協(xié)議，各主機(jī)廠對規(guī)范的自定義空間比較大，可以自由進(jìn)行定制化修改。我在一個項目中遇到工程師設(shè)計了負(fù)響應(yīng)抑制，跟本章節(jié)我們前面內(nèi)容說的場景恰好相反，前面我們細(xì)說了當(dāng)ECU響應(yīng)為正響應(yīng)時進(jìn)行抑制，只回復(fù)失敗。在一個項目中我遇到的是某些特定服務(wù)ECU正常發(fā)送正響應(yīng)，只有負(fù)響應(yīng)被抑制處理。所以診斷規(guī)范的自定義操作空間較大，測試設(shè)計時一定要仔細(xì)查閱相關(guān)規(guī)范。

2.3通訊幀

在上一章節(jié)中我們使用了一些服務(wù)來舉例，實例中包含了的是有效的數(shù)據(jù)內(nèi)容，在CAN網(wǎng)絡(luò)上進(jìn)行UDS報文傳輸時，CAN網(wǎng)絡(luò)的特性對于傳輸內(nèi)容長度有一定要求，普通的CAN數(shù)據(jù)幀每幀8字節(jié)長度，在這個長度的報文上傳輸U(kuò)DS協(xié)議數(shù)據(jù)時肯定會受到相應(yīng)的限制，如果1幀報文長度不滿足載荷需要，那就需要使用多條數(shù)據(jù)幀來信息承載。

1）單幀通訊

我們在上一章節(jié)列舉的例子內(nèi)容長度均比較短，7個字節(jié)的單個數(shù)據(jù)幀足夠使用，這樣的數(shù)據(jù)幀為單幀。

我們通過工具來查看網(wǎng)絡(luò)上服務(wù)問答真實數(shù)據(jù)報文形式，如下所示：

圖 7

我們可以看到兩條報文：報文1)，Tester傳輸，ECU接收ID717，數(shù)據(jù)長度8字節(jié)，我們使用了SID10的會話控制服務(wù)，發(fā)送了報文“02 10 01”，其中首字節(jié)“02”表明本報文后面有效數(shù)據(jù)長度為2字節(jié)，第二字節(jié)“10”表明服務(wù)為SID10，第三字節(jié)“01”表明子功能為01，剩余4-8字節(jié)使用AA自動補(bǔ)全。報文2) Tester接收，ECU發(fā)送ID71F，數(shù)據(jù)長度8字節(jié)，正響應(yīng)SID10的會話控制服務(wù)，發(fā)送了報文“02 50 01”，其中首字節(jié)“02”表明本報文后面有效數(shù)據(jù)長度為2字節(jié)，第二字節(jié)“50”表明SID10+0x40屬于SID10服務(wù)的正響應(yīng)，第三字節(jié)“01”是對應(yīng)子功能。

2）多幀通訊

當(dāng)一個數(shù)據(jù)幀7個字節(jié)不能完成一次通訊時，就需要把數(shù)據(jù)拆分到多個數(shù)據(jù)幀進(jìn)行傳輸。我們同樣通過下面的實例來進(jìn)行講解。

圖 8

我們首先看請求報文“03 22 F1 80”，首字節(jié)“03”表明報文后面有3字節(jié)有效數(shù)據(jù)，第二字節(jié)“22”表明是SID22讀取服務(wù)，22服務(wù)沒有子功能，第三、四字節(jié)是$22服務(wù)讀取的參數(shù)；返回報文的首幀為“10 10 62 F1 80 56 30 2E”，第一個字節(jié)“10”表明本條回復(fù)報文是多幀的第一幀，第二字節(jié)“10”表明后繼有效數(shù)據(jù)長度為0x10字節(jié)，換成10進(jìn)制為16字節(jié)，第三字節(jié)“62”是正響應(yīng)服務(wù)SID22+0x40，第四、五字節(jié)表明Parameter參數(shù)為F1 80，后繼的有效數(shù)據(jù)13字節(jié)的信息即為F1 80的讀取值；第三幀報文“30 00 00 00 00 00 00 00”，為多幀的流控幀，提示首個響應(yīng)報文成功發(fā)送，繼續(xù)發(fā)送剩余幀；第四幀“21 30 30 2E 30 30 46 42”首字節(jié)“21”表明是多幀的第二幀，本幀其余字節(jié)均為有效數(shù)據(jù)內(nèi)容；第五幀“22 4C 42 31 AA AA AA AA”，首字節(jié)“22”表明是多幀的第三幀，因全部多幀的有效長度在第一幀中記錄為16字節(jié)，所以至此第三響應(yīng)幀時有效數(shù)據(jù)內(nèi)容只有3個字節(jié)，加上首字節(jié)的序號位，前4字節(jié)為有效位，剩余4字節(jié)自動填充。

03

部分診斷服務(wù)

本章節(jié)我們對用到的一些服務(wù)做簡單介紹，后續(xù)使用最頻繁的服務(wù)我們會單獨講解。

1）$3E服務(wù)

$3E服務(wù)的用處是提示ECU狀態(tài)保持，如擴(kuò)展會話的狀態(tài)在一段時間后自動退出到默認(rèn)會話，使用3E服務(wù)可以將會話保持在擴(kuò)展會話模式下。

請求格式為3E 00和3E 80，其中3E 80即為正響應(yīng)抑制，不需要ECU回復(fù)。3E 00的正響應(yīng)回復(fù)報文格式為7E 00。

2）$11服務(wù)

$11服務(wù)的作用是將ECU進(jìn)行復(fù)位，最常用的有3個子服務(wù)，分別是01、02、03，04、05分別是使能和禁用快速休眠，0x40-0x7E為主機(jī)廠和零部件供應(yīng)商自定義字段。

11 01硬復(fù)位ECU，即要求ECU執(zhí)行電池斷電到設(shè)備上電的重啟；11 02車輛點火復(fù)位，即要求ECU執(zhí)行車輛整車電源從off到on狀態(tài)下的設(shè)備復(fù)位；11 03軟復(fù)位ECU，即要求ECU執(zhí)行應(yīng)用程序重啟，相當(dāng)于熱啟動。

11服務(wù)發(fā)送請求報文后，不一定有響應(yīng)報文，因為ECU執(zhí)行成功就是設(shè)備重啟，所以有主機(jī)廠要求11服務(wù)支持正響應(yīng)抑制標(biāo)識，會要求發(fā)送11 81。

3）$31服務(wù)

$31Routine服務(wù)基本上是廠家定制操作最多的服務(wù)，廠家可以預(yù)設(shè)值很多操作，然后通過31服務(wù)來調(diào)用執(zhí)行。比如可以讓進(jìn)行ECU狀態(tài)檢查，讓ECU通過預(yù)設(shè)算法生成特定數(shù)據(jù)，然后根據(jù)這些特定數(shù)據(jù)生成狀態(tài)，可以通過31服務(wù)鎖定這些狀態(tài)，這個功能在主機(jī)廠鎖定車輛上配套ECU零部件時會經(jīng)常用到，這樣一旦鎖定了當(dāng)前車輛ECU，其他任何人都不能隨意更換，車主想要對這些ECU進(jìn)行更換維修只能到指定正規(guī)的4S店完成，零部件一旦隨意更換，通過31服務(wù)調(diào)用執(zhí)行生成的狀態(tài)鎖定數(shù)據(jù)跟車輛不匹配，更換的ECU根本無法正常使用。當(dāng)然這只是31服務(wù)的一個設(shè)計功能。

31服務(wù)由4部分組成，第一部分SID31；第二部分子功能，分別是01啟動、02停止、03查詢；第三部分要調(diào)用執(zhí)行的routineID，這部分開始有主機(jī)廠自定義；第四部分可選的routine控制參數(shù)，跟第三部分的routineID是對應(yīng)的，也是主機(jī)廠自定義內(nèi)容。例如：31 01 08 09，讓ECU調(diào)用執(zhí)行08 09routine，ECU執(zhí)行成功反饋71 01 08 09，執(zhí)行過程出現(xiàn)一些問題，條件不滿足會返回71 01 08 09 xx yy，其中xx yy是不滿足的條件，這里的不滿足條件指的是執(zhí)行當(dāng)前31服務(wù)時的一些ECU其他信息預(yù)置條件，如執(zhí)行當(dāng)前服務(wù)需要已經(jīng)生成了XX信息，已經(jīng)鎖定了XX狀態(tài)等，可以理解為服務(wù)的內(nèi)部執(zhí)行錯誤。當(dāng)然如果返回7F 31 7E同樣是執(zhí)行失敗，失敗的原因可以查找NRC，NCR中的錯誤我們可以把他理解為服務(wù)外部錯誤，如執(zhí)行安全等級不正確，會話模式不正確，子功能不存在，超出范圍限制等等，NRC錯誤跟上面的不滿足條件失敗是兩種類型。

04

UDS的測試

UDS的測試通常在收到首個軟件版本后就開始執(zhí)行了，測試的時間段主要集中在OTS造車前，OTS開閥前必須確定UDS功能正常無故障。

UDS的測試設(shè)計依據(jù)最重要的文檔就是零部件的網(wǎng)絡(luò)診斷規(guī)范，在規(guī)范中詳細(xì)定義零部件支持的所有服務(wù)，以及服務(wù)的所有子功能和屬性參數(shù)。

通常UDS的功能測試設(shè)計重點在功能正常執(zhí)行場景部分，按照服務(wù)、子功能、功能屬性參數(shù)列舉所有請求報文，分別在不同會話模式和安全控制模式下，測試物理尋址、功能尋址的返回情況。正常測試還需要對會話返回的NRC進(jìn)行測試，這一部分內(nèi)容通常會被測試工程師遺漏，因為NRC中有部分的測試條件難以預(yù)置。

UDS功能還需要進(jìn)行異常測試的設(shè)計，這部分的測試設(shè)計通?？梢愿鶱RC部分合并進(jìn)行。

在設(shè)計DTC故障場景模擬時，需要特別注意電源短路的模擬，需要跟硬件工程師確認(rèn)是否對電源供電，線路板PCB靜電泄放等做保護(hù)性設(shè)計，否則容易造成板卡燒壞。

雖然我們是執(zhí)行UDS的功能測試，不需要對通訊的時隙精度等進(jìn)行驗證，報文響應(yīng)間隔時間的精度，超時時間范圍精度這些時間相關(guān)測試，通常跟信號電平等等一起在開發(fā)早期完成。但我們還是建議在測試設(shè)計上加入執(zhí)行時間監(jiān)控測試，以及報文間隔不同時隙的測試。如多幀發(fā)送或響應(yīng)時，幀間不同時間間隔設(shè)置的影響；會話自動退出的時間是否在設(shè)計要求內(nèi)；$30服務(wù)不同發(fā)送時間間隔對會話保持的影響等等。這部分功能在開發(fā)初期通常比較容易出現(xiàn)問題。

審核編輯 黃昊宇