統一診斷服務 (Unified diagnostic services ， UDS) （七）

在關於UDS的第二篇文章中，我提到過UDS定義的服務從邏輯上分為6類，在第二至第六篇中已經講解了前五類，在本文中將介紹最後一類UDS服務，即Upload Download functional unit ，數據的上傳下載。

從成本等角度考慮，汽車ECU中用於緩存診斷服務數據的buffer大小有限，所以當我們需要讀取或寫入超過buffer大小的數據時，就無法簡單地使用2E和22服務了，UDS據此定義了幾個將大塊數據寫入或讀出的服務，即數據下載和上傳。

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

1. RequestDownload （0x34）：客戶端向伺服器請求下載數據
2. RequestUpload （0x35）客戶端向伺服器請求上傳數據
3. TransferData（0x36） 客戶端向伺服器傳數據（下載），或者伺服器向客戶端傳數據（上傳）
4. RequestTransferExit（0x37）數據傳輸完成，請求退出
5. RequestFileTransfer（0x38） 傳輸文件的操作，可以用於替代上傳下載的服務。

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

RequestDownload （0x34）：

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

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

第一部分：1個byte的SID

第二部分：1個byte的dataFormatIdentifier，這裡面標識了數據格式相關的信息，比如數據是否有壓縮，是否有加密，用的什麼演算法加密等，應該由主機廠與供應商約定好，用哪個bit來表示壓縮、加密等信息。

第三部分：1個位元組的addressAndLengthFormatIdentifier，用於指示後面兩個部分所佔用的位元組，高4bit表示memorySize所佔的位元組長度，低4bit表示memoryAddress

所佔的位元組長度。在這個例子中我將這兩個值分別設置為n和m。

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

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

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

第一部分：1個byte的 Response SID

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

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

TransferData（0x36）：

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

第一部分：1個byte的 SID

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

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

舉例：如果ECU告知tester,maxNumberOfBlockLength = 20，也就是說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系列，分別介紹一下DTC的8個狀態位的邏輯關係以及向ECU刷寫數據或軟體的完整流程。在此之後我會寫幾篇文章來講述UDS在CAN匯流排上的實現，即所謂的UDSonCAN，涉及到TP層的分包、流控制、錯誤識別等內容，還有基於CAN實現的UDS中涉及到的各種時間參數。感興趣的話可以繼續關注。