作者 |李偉 上海控安安全測評中心安全測評部總監

來源 |鑒源實驗室

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

01

診斷相關基礎小知識

1.1 診斷地址

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

圖 1

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

圖 2

1.2物理尋址和功能尋址

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

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

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

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

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

02

統一診斷服務（UDS）

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

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

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

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

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

2.1 請求報文

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

圖 3

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

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

2.2 響應報文

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

1）Positive Response正響應

正響應是ECU對接收到的請求給予明確的成功內容結果返回，意味著請求得到成功執行。例如請求是讀取車輛VIN碼，正響應就是回答VIN是XXX。

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

正響應的報文格式如下圖所示：

圖 4

例如：請求10 01，正響應為50 01；請求22 XX XX，正響應為62 XX XX XX。

2）Negative Response負響應

負響應是ECU收到請求之后，無法對請求的內容正確執行，回復了失敗，并附帶了失敗的原因。

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

負響應報文格式如下圖所示：

圖 5

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

3）無響應

無響應的出現是網絡架構部門為了降低CAN網絡上報文環境的復雜情況而做的設計。目的是不回復請求方正響應數據幀，即，當即將答復的響應幀為正響應時，不發送響應幀。

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

圖 6

例如：發送10 81，當回復是正響應時，ECU不答復；發送10 82，答復7F 10 7E，同樣是請求帶正響應抑制，但是ECU執行失敗，此時則進行了回復。

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

2.3通訊幀

在上一章節中我們使用了一些服務來舉例，實例中包含了的是有效的數據內容，在CAN網絡上進行UDS報文傳輸時，CAN網絡的特性對于傳輸內容長度有一定要求，普通的CAN數據幀每幀8字節長度，在這個長度的報文上傳輸UDS協議數據時肯定會受到相應的限制，如果1幀報文長度不滿足載荷需要，那就需要使用多條數據幀來信息承載。

1）單幀通訊

我們在上一章節列舉的例子內容長度均比較短，7個字節的單個數據幀足夠使用，這樣的數據幀為單幀。

我們通過工具來查看網絡上服務問答真實數據報文形式，如下所示：

圖 7

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

2）多幀通訊

當一個數據幀7個字節不能完成一次通訊時，就需要把數據拆分到多個數據幀進行傳輸。我們同樣通過下面的實例來進行講解。

圖 8

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

03

部分診斷服務

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

1）$3E服務

$3E服務的用處是提示ECU狀態保持，如擴展會話的狀態在一段時間后自動退出到默認會話，使用3E服務可以將會話保持在擴展會話模式下。

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

2）$11服務

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

11 01硬復位ECU，即要求ECU執行電池斷電到設備上電的重啟；11 02車輛點火復位，即要求ECU執行車輛整車電源從off到on狀態下的設備復位；11 03軟復位ECU，即要求ECU執行應用程序重啟，相當于熱啟動。

11服務發送請求報文后，不一定有響應報文，因為ECU執行成功就是設備重啟，所以有主機廠要求11服務支持正響應抑制標識，會要求發送11 81。

3）$31服務

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

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

04

UDS的測試

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

UDS的測試設計依據最重要的文檔就是零部件的網絡診斷規范，在規范中詳細定義零部件支持的所有服務，以及服務的所有子功能和屬性參數。

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

UDS功能還需要進行異常測試的設計，這部分的測試設計通常可以跟NRC部分合并進行。

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

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

審核編輯 黃昊宇