統一診斷服務 (Unified diagnostic services ， UDS) （七）
在關於UDS的第二篇文章中，我提到過UDS定義的服務從邏輯上分為6類，在第二至第六篇中已經講解了前五類，在本文中將介紹最後一類UDS服務，即Upload Download functional unit ，資料的上傳下載。
從成本等角度考慮，汽車ECU中用於快取診斷服務資料的buffer大小有限，所以當我們需要讀取或寫入超過buffer大小的資料時，就無法簡單地使用2E和22服務了，UDS據此定義了幾個將大塊資料寫入或讀出的服務，即資料下載和上傳。
Upload Download functional unit總共定義了5個診斷服務，分別是：
- RequestDownload （0x34）：客戶端向伺服器請求下載資料
- RequestUpload （0x35）客戶端向伺服器請求上傳資料
- TransferData（0x36） 客戶端向伺服器傳資料（下載），或者伺服器向客戶端傳資料（上傳）
- RequestTransferExit（0x37）資料傳輸完成，請求退出
- RequestFileTransfer（0x38） 傳輸檔案的操作，可以用於替代上傳下載的服務。
下圖是資料下載的簡略過程，用到了34，36，37這三個服務，如果是上傳的話，34服務被35服務替換，資料傳輸方向變一下，就可以了。
Tester向ECU刷寫資料的大概過程
RequestDownload （0x34）：
0x34服務用於啟動下載傳輸，作用是告知ECU準備接受資料，ECU則通過0x74 response告訴診斷儀自己是否允許傳輸，以及自己的接受能力是多大。
0x34服務的請求格式
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
0x34服務的響應格式
第一部分：1個byte的 Response SID
第二部分：1個byte的dataFormatIdentifier作為echo
第三部分：maxNumberOfBlockLength，長度不定，表示可以通過0x36服務一次傳輸的最大資料量。
TransferData（0x36）：
如果34服務得到了正確響應，tester就要啟動資料傳輸過程了，使用的就是36服務。36服務的格式如下。
0x36服務的請求格式
第一部分：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中涉及到的各種時間引數。感興趣的話可以繼續關注。