一.概述

UDS定義的服務從邏輯上分為6類，在上一篇文章中已經對診斷和通信管理類”“數據傳輸類”“存儲數據傳輸“進行了解讀。本文將介紹余下3類UDS服務，即“IO控制服務”“例行程序服務”“上傳與下載服務”。

二.診斷服務內容

O控制服務

1.?InputOutputControlByIdentifier (0x2F)

$2F這個服務即利用ID對ECU的輸入輸出進行控制，經常會在生產線上使用來驗證零部件的功能。比如，在總裝階段，工人需要驗證車上的各種功能是否正常，例如四個車窗的升降是否正常，如果挨個開關去按，那效率很低，如果通過一個診斷命令就能夠觀察到車窗升降的情況，效率則高得多。

比如，ECU接收一個輸入信號A，我們就可以利用2F給這個A賦個我們需要的值；ECU對某個執行器B進行控制，我們就可以利用2F服務再配上某些特定的參數來實現對B的控制，例如門控對車窗升降、后視鏡折疊等的控制。

$2F服務的request由4部分組成

第一個字節：SID=0x2F

第二三個字節：dataIdentifier(2 byte)，用于標識被控制的IO對象，例如下文舉例0x9B00（進氣口門位置）

第四個字節：controlOptionRecord，用于標識控制類型，以及若干byte由廠家自定義使用的controlState。UDS明確定義了四種控制類型

0x00 將控制權還給ECU，即結束控制

0x01 將DID標識的對象的輸入信號、內部參數、輸出信號等設為默認值

0x02 將DID標識的對象的的輸入信號、內部參數、輸出信號等凍結住

0x03 將DID標識的對象的的輸入信號、內部參數、輸出信號進行設置，其實就相當于開始了對ECU的控制，這種控制類型其后會跟著第五個字節，可以表示控制對象的數字量或模擬量。

舉例來說：

使用2F控制Air Inlet Door Position （進氣口門位置），用DID（標識符）=0x9B00來標識進氣口門的位置。

Air Inlet Door Position [%] = decimal(Hex) * 1 [%] ，即用一個百分比來表示這個位置。

step1:

tester 發送22 9B 00讀取當前進氣口門的位置，這里22即SID，0x9B00即第二三字節DID。

ECU返回62 9B 00 0A ，這里 0x0A = 10（dec），即表示當前位置是10%

（UDS定義可以用22服務讀取2F服務中使用的dataIdentifier，返回值是狀態信息，具體的狀態信息是什么，則由使用者自定義了。）

step2:

tester 發送2F 9B 00 03 3C ，表示要將進氣口門的位置調整到60%，0x3C = 60（dec）表示要將控制對象的模擬量設定為60%。

ECU返回6F 9B 00 03 0C，表示接受控制，當前進氣口門的位置為12%。因為ECU收到請求后是立刻響應的，而門的位置調節需要時間，所以還沒有達到60%。

step3:

過一段時間后tester 發送22 9B 00讀取當前進氣口門的位置

ECU返回62 9B 00 3C ， 0x3C = 60（dec），表示當前位置已經到了60%

step4:

tester 發送2F 9B 00 00，將控制權交還給ECU

ECU返回6F 9B 00 00 3A，表示接受請求，當前位置為58%

step5:

tester 發送2F 9B 00 02，凍結9B 00這個ID所代表的進氣口門位置這個狀態

ECU返回6F 9B 00 02 32，表示接受請求，當前位置保持在50%

此外，2F服務存在一個問題（引自知乎作者“心靈之花”），如果通過2F服務修改了某個值，后續也不把控制權還給ECU，那么這個修改的有效時間是一直持續下去？正確的做法是如果擴展會話超時，即切回默認會話，此時控制權應還給ECU，畢竟 2F的03子功能是"暫時接管控制權"。

例行程序控制服務

RoutineControl (0x31)

$31服務是調用ECU內置的一些操作序列的接口，這個服務的應用很靈活，因為廠家可以根據自己的需要為ECU定義各種各樣的內部操作，而要執行這些操作只需要調用31服務就好了。典型的用途包括檢查邊界條件、清除閃存、對數據進行較驗、對軟硬件依賴性進行校驗等，甚至有需要的話可以進行恢復出廠設置的操作，還有很多與ECU自身邏輯功能相關的操作也可以定義。

31服務的request由4部分組成

SID=0x31

sub-function，子功能，啟動（0x01）、停止（0x02）、查詢結果（0x03）

routineIdentifier，即任務ID，用于標識要執行的routine

routineControlOptionRecord，這是一個可選參數，用于標識routine執行時所需要的參數，由各家自定義它的內容

舉個例子：

假設用0x0809這個ID來代表檢查ECU是否滿足軟件刷寫條件（比如車速、轉速為0，KL15接通等）的routine。

tester發送31 01 08 09來啟動0x0809這個routine

如果所有條件都滿足，則ECU返回71 01 08 09作為echo即可，如果條件不滿足，則ECU返回71 01 08 09 XX YY ZZ，后邊的XX YY ZZ則表明哪些條件不滿足，具體的內容就由廠家自己定義了。

上傳與下載服務

關于ECU升級數據的傳輸，是通過34（請求下載）、36（傳輸數據）、37（請求退出傳輸）等服務來完成的。由于汽車ECU中用于緩存診斷服務數據的buffer大小有限，所以當我們需要讀取或寫入超過buffer大小的數據時，就無法簡單地使用2E和22服務了，因此UDS據此定義了幾個將大塊數據寫入或讀出的服務，即數據下載和上傳。

Upload Download functional unit總共定義了5個診斷服務，分別是：

RequestDownload （0x34）：診斷儀向ECU請求下載數據

RequestUpload （0x35）診斷儀向ECU請求上傳數據

TransferData（0x36） 診斷儀向ECU傳數據（下載），或者服務器向客戶端傳數據（上傳）

RequestTransferExit（0x37）數據傳輸完成，請求退出

RequestFileTransfer（0x38） 傳輸文件的操作，可以用于替代上傳下載的服務。

下圖是數據下載的簡略過程，用到了34，36，37這三個服務，如果是上傳的話，34服務被35服務替換，數據傳輸方向變一下，就可以了。

step1:

診斷儀通過34服務傳輸該塊的起始地址、該塊的數據長度信息；進行下載請求；

ECU收到34服務的下載請求后，通過74肯定響應報文通知診斷儀，其（診斷儀）接下來的每個數據傳輸的報文中（36服務）應包含多少數據字節。診斷儀則根據該返回的參數對自身的發送能力進行調整；

step2:

診斷儀通過36服務傳輸該塊的數據，每個36服務傳輸的數據量大小由ECU返回的34服務（即SID=0x74）中的參數確定，詳情見下文。

ECU對36服務返回肯定響應；

通過36服務依次將該數據進行拆分發送，期間每完成一次36服務的發送，ECU進行肯定響應的回復。直到該塊數據全部發送完；

step3:

診斷儀通過發送37服務進行傳輸退出的請求；

ECU進行肯定響應回復。

各服務說明如下所示：

各服務說明如下所示：

RequestDownload （0x34）：

0x34服務用于啟動下載傳輸，作用是告知ECU準備接受數據，ECU則通過0x74 response告訴診斷儀自己是否允許傳輸，以及自己的接受能力是多大。

0x34服務的請求格式包括5個部分

第一部分：1個byte的SID=0x34

第二部分：1個byte的dataFormatIdentifier，用于指示數據壓縮和加密的方法。其中，第7-4位定義了壓縮方法；第3-0位定義了加密方法。該字節為0x00時則表示既沒有使用壓縮方法也沒有使用加密方法。0x00外的其他值的定義是由車產自行規定的。

第三部分：1個字節的addressAndLengthFormatIdentifier，用于指示后面兩個部分所占用的字節數，高4bit表示memorySize所占的字節長度，低4bit表示memoryAddress所占的字節長度。在這個例子中我將這兩個值分別設置為n和m。

第四部分：m個字節的memoryAddress，由addressAndLengthFormatIdentifier中的低4bit指示。含義是要寫入數據在ECU中的邏輯地址。

第五部分：n個字節的memorySize，由addressAndLengthFormatIdentifier中的高4bit指示。含義是要寫入數據的字節數。

ECU收到請求之后，如果允許傳輸的話，會給出如下response

第一部分：1個byte的 Response SID=0x74

第二部分：1個byte的dataFormatIdentifier作為echo

第三部分：maxNumberOfBlockLength，長度不定，表示可以通過0x36服務一次傳輸的最大數據量。

TransferData（0x36）：

如果34服務得到了正確響應，tester就要啟動數據傳輸過程了，使用的就是36服務。36服務的格式如下。

第一部分：1個byte的 SID=0x36。

第二部分：1個byte的blockSequenceCounter，標識當前傳輸的是第幾個數據塊，即幀序號，或者簡單地說就是第幾次調用36服務。

第三部分：transferRequestParameterRecord，傳輸的數據。第次傳輸數據量的上限就是34服務響應中的maxNumberOfBlockLength。

舉例：如果ECU告知tester,maxNumberOfBlockLength = 20（來自$34服務的echo），也就是說tester每次通過36服務只能發送最多20個字節，其中還包括了SID和blockSequenceCounter，所以實際上每次可傳的數據信息只有18個字節。如果tester要傳的數據為50個字節，則需要傳輸三次，每次分別傳輸18，18，14個字節，即調用3次36服務。

36的響應很簡單，就是一個字節的Response SID再加一個字節的blockSequenceCounter作為echo。

RequestTransferExit（0x37）：

$37服務用于退出上傳下載，如果之前的34和36服務都順利執行完成，那么37服務就可以得到ECU的positive response。

格式很簡單，請求就是37，正確響應就是77，都是一個字節。

如果前面的36服務沒有執行完成，以我前面舉的例子來說，比如這個數據塊有50個字節，但是tester只發了兩次36服務傳了36個字節，那么這次傳輸對于ECU來說是失敗的，所以ECU應該給出NRC 0x7F 37 24，表示診斷序列執行有錯誤。

三. UDS應用的設備

在UDS診斷產品中知名度最高，應用最廣泛的是德國Vector公司的CAN卡 VN1630/1640 配合其CANoe 軟件，Vector 產品功能齊全，適合系統級汽車總線開發，被大部分汽車廠商采用。通常工程師先用Vector的CANdela進行cdd文件的開發，之后將該cdd文件導入CANoe.diva中進行功能測試。下面的鏈接是Vector提供的全套解決方案，里面的CANdesc是UDS代碼生成軟件。

Vector 產品很好用，節省開發時間，不開放API，且價格昂貴，不適用于硬件開發團隊和生產線的自動化測試。目前市面上有很多CAN 廠商（如Kvaser, ZLG 等）能提供低成本、體積小、驅動簡單、開放API 的設備，很適合進行二次開發。

小結

至此，關于UDS診斷協議更新完畢，UDS協議晦澀復雜， 需要真切體驗才能加深記憶，在使用過程中加深理解，歡迎大家隨時交流。

總結

以上是生活随笔為你收集整理的（转发）详解汽车UDS诊断协议（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。