在關(guān)于 UDS 的第二篇文章中，我提到過 UDS 定義的服務(wù)從邏輯上分為 6 類，在第二至第六篇中已經(jīng)講解了前五類，在本文中將介紹最后一類 UDS 服務(wù)，即 Upload Download functional unit ，數(shù)據(jù)的上傳下載。

從成本等角度考慮，汽車 ECU 中用于緩存診斷服務(wù)數(shù)據(jù)的 buffer 大小有限，所以當(dāng)我們需要讀取或?qū)懭?，超過 buffer 大小的數(shù)據(jù)時(shí)，就無法簡單地使用 2E 和 22 服務(wù)了，UDS 據(jù)此定義了幾個(gè)將大塊數(shù)據(jù)寫入或讀出的服務(wù)，即數(shù)據(jù)下載和上傳。

Upload Download functional unit 總共定義了 5 個(gè)診斷服務(wù)，分別是：

1. RequestDownload （0x34）：客戶端向服務(wù)器請(qǐng)求下載數(shù)據(jù)

2. RequestUpload （0x35）客戶端向服務(wù)器請(qǐng)求上傳數(shù)據(jù)

3. TransferData（0x36） 客戶端向服務(wù)器傳數(shù)據(jù)（下載），或者服務(wù)器向客戶端傳數(shù)據(jù)（上傳）

4. RequestTransferExit（0x37）數(shù)據(jù)傳輸完成，請(qǐng)求退出

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

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

RequestDownload? （0x34） ）： ：

0x34 服務(wù)用于啟動(dòng)下載傳輸，作用是告知 ECU 準(zhǔn)備接受數(shù)據(jù)，ECU 則通過 0x74 response 告訴診斷儀自己是否允許傳輸，以及自己的接受能力是多大。

0x34 服務(wù)的請(qǐng)求格式包括 5 個(gè)部分

第一部分：1 個(gè) byte 的 SID

第二部分：1 個(gè) byte 的 dataFormatIdentifier，這里面標(biāo)識(shí)了數(shù)據(jù)格式相關(guān)的信息，比如數(shù)據(jù)是否有壓縮，

是否有加密，用的什么算法加密等，應(yīng)該由主機(jī)廠與供應(yīng)商約定好，用哪個(gè) bit 來表示壓縮、加密等信息。

第三部分：1 個(gè)字節(jié)的 addressAndLengthFormatIdentifier，用于指示后面兩個(gè)部分所占用的字節(jié)，高4bit 表示 memorySize 所占的字節(jié)長度，低 4bit 表示 memoryAddress

所占的字節(jié)長度。在這個(gè)例子中我將這兩個(gè)值分別設(shè)置為 n 和 m。

第四部分：m 個(gè)字節(jié)的 memoryAddress，由 addressAndLengthFormatIdentifier 中的低 4bit 指示。含義是要寫入數(shù)據(jù)在 ECU 中的邏輯地址。

第五部分：n 個(gè)字節(jié)的 memorySize，由 addressAndLengthFormatIdentifier 中的高 4bit 指示。含義是要寫入數(shù)據(jù)的字節(jié)數(shù)

ECU 收到請(qǐng)求之后，如果允許傳輸?shù)脑?，?huì)給出如下 response

第一部分：1 個(gè) byte 的 Response SID

第二部分：1 個(gè) byte 的 dataFormatIdentifier 作為 echo

第三部分：maxNumberOfBlockLength，長度不定，表示可以通過 0x36 服務(wù)一次傳輸?shù)淖畲髷?shù)據(jù)量。

TransferData （0x36） ）： ：

如果 34 服務(wù)得到了正確響應(yīng)，tester 就要啟動(dòng)數(shù)據(jù)傳輸過程了，使用的就是 36 服務(wù)。36 服務(wù)的格式如下。

第一部分：1 個(gè) byte 的 SID

第二部分：1 個(gè) byte 的 blockSequenceCounter，標(biāo)識(shí)當(dāng)前傳輸?shù)氖堑趲讉€(gè)數(shù)據(jù)塊，或者簡單地說就是第

幾次調(diào)用 36 服務(wù)。

第三部分：transferRequestParameterRecord，傳輸?shù)臄?shù)據(jù)。第次傳輸數(shù)據(jù)量的上限就是 34 服務(wù)響應(yīng)中

的 maxNumberOfBlockLength。

舉例：如果 ECU 告知 tester,maxNumberOfBlockLength = 20，也就是說 tester 每次通過 36 服務(wù)只能發(fā)送最多 20 個(gè)字節(jié)，其中還包括了 SID 和 blockSequenceCounter，所以實(shí)際上每次可傳的數(shù)據(jù)信息只有18 個(gè)字節(jié)。如果 tester 要傳的數(shù)據(jù)為 50 個(gè)字節(jié)，則需要傳輸三次，每次分別傳輸 18，18，14 個(gè)字節(jié)，即調(diào)用 3 次 36 服務(wù)。

36 的響應(yīng)很簡單，就是一個(gè)字節(jié)的 Response SID 再加一個(gè)字節(jié)的 blockSequenceCounter 作為 echo。

RequestTransferExit （0x37） ）： ：

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

格式很簡單，請(qǐng)求就是 37，正確響應(yīng)就是 77，都是一個(gè)字節(jié)。

如果前面的 36 服務(wù)沒有執(zhí)行完成，以我前面舉的例子來說，比如這個(gè)數(shù)據(jù)塊有 50 個(gè)字節(jié)，但是 tester只發(fā)了兩次 36 服務(wù)傳了 36 個(gè)字節(jié)，那么這次傳輸對(duì)于 ECU 來說是失敗的，所以 ECU 應(yīng)該給出 NRC 0x7F 37 24，表示診斷序列執(zhí)行有錯(cuò)誤。

關(guān)于 UDS 所定義的診斷服務(wù)到這里就寫完了。接下來我會(huì)寫兩篇文章補(bǔ)充一下 UDS 系列，分別介紹一下 DTC 的 8 個(gè)狀態(tài)位的邏輯關(guān)系以及向 ECU 刷寫數(shù)據(jù)或軟件的完整流程。在此之后我會(huì)寫幾篇文章來講述 UDS 在 CAN 總線上的實(shí)現(xiàn)，即所謂的 UDSonCAN，涉及到 TP 層的分包、流控制、錯(cuò)誤識(shí)別等內(nèi)容，還有基于 CAN 實(shí)現(xiàn)的 UDS 中涉及到的各種時(shí)間參數(shù)。