[導(dǎo)讀]0x00UDS概述UDS（UniversityDiagnosticsSystem通用診斷系統(tǒng)）是一個(gè)在整車系統(tǒng)上經(jīng)常使用的設(shè)備維護(hù)協(xié)議。其主要遵循的法規(guī)為：ISO-15765、ISO-14229，其主要協(xié)議模式脫胎于OBD（On-boarddiagnostics）診斷協(xié)議。經(jīng)常應(yīng)...

0x00 UDS概述

UDS（University Diagnostics System通用診斷系統(tǒng)）是一個(gè)在整車系統(tǒng)上經(jīng)常使用的設(shè)備維護(hù)協(xié)議。其主要遵循的法規(guī)為：ISO-15765、ISO-14229，其主要協(xié)議模式脫胎于OBD（On-board diagnostics）診斷協(xié)議。經(jīng)常應(yīng)用在整車的各種ECU上面。是一個(gè)在整車ECU應(yīng)用層開發(fā)經(jīng)常使用的也是較為復(fù)雜的協(xié)議層之一。
本篇文章主要介紹了UDS協(xié)議相關(guān)的協(xié)議的宏觀介紹。閱讀本文之前，您需要了解的一些前置技能有：

技能名稱	技能熟練度	技能教程鏈接
CAN總線	熟悉	暫無
數(shù)據(jù)類型	熟悉	暫無
OBD	了解	暫無
整車縮寫	了解	暫無

0x10 層次類型

UDS主要分為五大協(xié)議層次：物理層、鏈路層、協(xié)議基層、協(xié)議網(wǎng)絡(luò)層、協(xié)議應(yīng)用層。此外，還有較為完善的協(xié)議時(shí)效管理與協(xié)議的錯(cuò)誤、正確反饋碼。
而整個(gè)協(xié)議的交互分為客戶端和服務(wù)端，而客戶端為診斷儀；服務(wù)端就是整車上的ECU。
需要注意的是：錯(cuò)誤反饋值嚴(yán)格根據(jù)反饋的錯(cuò)誤檢測流程決定。這種錯(cuò)誤檢測流程會在后期簡述。
為了方便講解，我暫時(shí)將協(xié)議基層、協(xié)議網(wǎng)絡(luò)層、協(xié)議應(yīng)用層統(tǒng)稱為協(xié)議層，具體的詳情會在后期簡述。

0x11 物理層

物理層主要的實(shí)現(xiàn)可以為任何協(xié)議的硬件決定，這個(gè)是由鏈路層的選擇支持的。例如常用CAN協(xié)議進(jìn)行載體，物理層就可以使用相應(yīng)的CAN芯片進(jìn)行構(gòu)架。如果使用LAN進(jìn)行載體則也可以使用相應(yīng)的芯片進(jìn)行構(gòu)架。

0x12 鏈路層

鏈路層是整個(gè)協(xié)議的實(shí)現(xiàn)基石（從軟件工程師的角度來講），鏈路層定義了當(dāng)前的系統(tǒng)基層數(shù)據(jù)定義與底層驅(qū)動的選擇和編寫。而整個(gè)鏈路層穩(wěn)定性對于當(dāng)前網(wǎng)絡(luò)的實(shí)現(xiàn)都是非常重要的地方。其決定了數(shù)據(jù)接收的正確性與誤碼率，也決定的反饋碼的傳輸正常，很多上層查詢不到的問題都有可能出在這里。

0x13協(xié)議層

協(xié)議層主要進(jìn)行以下幾大操作：數(shù)據(jù)接收、數(shù)據(jù)處理、數(shù)據(jù)反饋、時(shí)間限制。

數(shù)據(jù)接收

UDS主要依托于硬件協(xié)議進(jìn)行數(shù)據(jù)構(gòu)架，本文主要以汽車行業(yè)常用的CAN總線協(xié)議進(jìn)行數(shù)據(jù)構(gòu)架。CAN幀數(shù)的數(shù)據(jù)是固定的，對于大數(shù)據(jù)的傳輸是比較難受的，基于此，UDS具有一定的數(shù)據(jù)定義：標(biāo)準(zhǔn)幀（Normal Frame）、首幀（First Frame）、流控幀（Constraints Frame）、數(shù)據(jù)幀（Data Frame）。對于各個(gè)數(shù)據(jù)的定義主要是靠CAN單幀數(shù)據(jù)中的第一位字節(jié)數(shù)據(jù)中的前四位Bit數(shù)據(jù)決定。

數(shù)據(jù)幀定義	數(shù)據(jù)幀標(biāo)識	數(shù)據(jù)實(shí)體示例
標(biāo)準(zhǔn)幀	00	00 XX XX XX XX XX XX XX
首幀	01	1X XX XX XX XX XX XX XX
流控幀	11	30 AA BB XX XX XX XX XX
數(shù)據(jù)幀	10	20 XX XX XX XX XX XX XX

而首幀中，AABB則是相關(guān)的時(shí)控參數(shù)，這個(gè)會在之后再講。

數(shù)據(jù)處理

數(shù)據(jù)處理主要是根據(jù)當(dāng)前的接收數(shù)據(jù)，將其根據(jù)應(yīng)用層相應(yīng)的指令進(jìn)行數(shù)據(jù)處理。

數(shù)據(jù)反饋

數(shù)據(jù)反饋則是對于當(dāng)前的指令數(shù)據(jù)處理完成之后，將其處理結(jié)果反饋給當(dāng)前的數(shù)據(jù)接收端，這個(gè)數(shù)據(jù)反饋分為正反饋（正確反饋）和負(fù)反饋（錯(cuò)誤反饋）。且嚴(yán)格根據(jù)時(shí)序限制進(jìn)行數(shù)據(jù)傳輸。

時(shí)間限制

協(xié)議層主要的時(shí)間限制為兩項(xiàng)，一項(xiàng)為流控幀對于數(shù)據(jù)幀發(fā)送時(shí)間的時(shí)控參數(shù)限制（網(wǎng)絡(luò)層），另一項(xiàng)為應(yīng)用系統(tǒng)在線時(shí)效和模式時(shí)控參數(shù)限制（應(yīng)用層）。前者主要原因?yàn)楸苊猱?dāng)前數(shù)據(jù)重放錯(cuò)誤，后者主要避免當(dāng)前模式錯(cuò)誤定義。

0x20 數(shù)據(jù)類型

數(shù)據(jù)主要分為單幀和多幀。而多幀則根據(jù)傳輸流程分為：首幀、多幀、流控幀。

0x21 單幀

單幀則很簡單，主要給一些不怎么長的指令集進(jìn)行傳輸，優(yōu)點(diǎn)在于快準(zhǔn)狠，一幀即可代表一個(gè)指令，對于軟件測試模擬也比較方便。但是缺點(diǎn)在于很多場景下無法使用，例如大量數(shù)據(jù)的傳輸。其主要的數(shù)據(jù)格式定義為：

數(shù)據(jù)定義	長度bit	備注
幀格式定義	0~3	相應(yīng)的協(xié)議數(shù)據(jù)定義
幀長度	4~7	后面的有效字節(jié)長度
數(shù)據(jù)實(shí)體	8~63	數(shù)據(jù)根據(jù)幀長度定義

對于單幀的反饋也是相似的，也就不在闡述了。

0x22 多幀

首幀

首幀的是整個(gè)多幀傳輸流程的起始，一般由客戶端先發(fā)出，包括了當(dāng)前指令請求的長度和先前的幾個(gè)數(shù)據(jù)。其主要的數(shù)據(jù)格式定義為：

數(shù)據(jù)定義	長度bit	備注
幀格式定義	0~3	相應(yīng)的協(xié)議數(shù)據(jù)定義
幀長度	4~15	整個(gè)多幀的有效數(shù)據(jù)長度
數(shù)據(jù)實(shí)體	16~63	一部分?jǐn)?shù)據(jù)

流控幀

流控幀是當(dāng)前的首幀接收端接收后，判斷當(dāng)前數(shù)據(jù)沒有出錯(cuò)的情況下，發(fā)送的一種數(shù)據(jù)響應(yīng)，主要包含了當(dāng)前多幀的數(shù)據(jù)發(fā)送最短間隔時(shí)間與流控幀發(fā)送次數(shù)。其主要的數(shù)據(jù)格式定義為：

數(shù)據(jù)定義	長度bit	備注
幀格式定義	0~3	相應(yīng)的協(xié)議數(shù)據(jù)定義
流控幀狀態(tài)	4~7	一般為0，具體詳見ISO14229
流控幀最短發(fā)送次數(shù)	8~15	塊大小
數(shù)據(jù)發(fā)送最短間隔時(shí)間	16~24	流控幀的時(shí)控主要參數(shù)
填空	25~63	一般為協(xié)定值

塊大?。寒?dāng)前發(fā)送的數(shù)據(jù)幀是有一定的次序的，而一旦發(fā)到一定次序，則數(shù)據(jù)接收端就會發(fā)送一次流控幀，否則發(fā)送端就會判斷當(dāng)前多幀發(fā)送失敗。
數(shù)據(jù)發(fā)送最短間隔時(shí)間：當(dāng)前兩幀數(shù)據(jù)幀的發(fā)送間隔時(shí)間，單位為毫秒。

數(shù)據(jù)幀

數(shù)據(jù)幀是當(dāng)前的服務(wù)端發(fā)出流控幀之后，在一定時(shí)間內(nèi)由客戶端進(jìn)行發(fā)出。數(shù)據(jù)幀就是大量幀格式的主要組成部分，也是經(jīng)常在編程上面會出錯(cuò)的地方。其主要的數(shù)據(jù)格式定義為：

數(shù)據(jù)定義	長度bit	備注
幀格式定義	0~3	相應(yīng)的協(xié)議數(shù)據(jù)定義
數(shù)據(jù)幀長度	4~7	與流控幀[8_{15]相關(guān),0}0xF循環(huán)
數(shù)據(jù)實(shí)體	8~63	剩下的全部數(shù)據(jù)

0x30 模式類型

模式是UDS中的一個(gè)非常重要的軟件抽象，UDS在應(yīng)用層中抽象了3大模式：普通模式、擴(kuò)展模式、編程模式。而擴(kuò)展和編程模式中，又分為普通權(quán)限模式和特權(quán)模式。模式之間的主要區(qū)別如下：

模式名稱	授權(quán)模式	具有權(quán)限
普通模式	普通權(quán)限模式	無法讀取內(nèi)部數(shù)據(jù)，執(zhí)行較為簡單的指令（重啟、模式切換、會話保持）
普通模式	特權(quán)模式	無此模式
擴(kuò)展模式	普通權(quán)限模式	可以讀取內(nèi)部的ECU狀態(tài)值，ECU錯(cuò)誤值，廠商SN號等
擴(kuò)展模式	特權(quán)模式	可以讀寫內(nèi)部的ECU錯(cuò)誤值、廠商SN號等
編程模式	普通權(quán)限模式	可以讀取一些廠商內(nèi)部值
編程模式	特權(quán)模式	可以讀寫廠商內(nèi)部值、可以刷新當(dāng)前的固件版本

而在普通權(quán)限模式下，可以使用相應(yīng)的應(yīng)用層指令可以將其切換呈特權(quán)模式，但是會有自有的密鑰算法進(jìn)行交互，且有很嚴(yán)格的時(shí)序和錯(cuò)誤次數(shù)的要求。這個(gè)我會在之后的應(yīng)用層的詳細(xì)講解中進(jìn)行介紹。

0x40 時(shí)效類型

時(shí)效類型主要為應(yīng)用會話過期時(shí)效與幀交互過期時(shí)效。

0x41應(yīng)用會話過期時(shí)效

應(yīng)用會話是指當(dāng)前客戶端與服務(wù)端的交互中，應(yīng)用層完成指令的間隔。單位一般為秒，例如五秒。一般主要使用在普通模式與擴(kuò)展模式的切換和普通模式與編程模式的切換作為時(shí)間限制。
整個(gè)會話期間，要求客戶端一直進(jìn)行應(yīng)用層的指令發(fā)送，就算僅僅使用CAN幀進(jìn)行發(fā)送也無法算作會話成功。

0x42 幀交互過期時(shí)效

此與流控幀的時(shí)序控制相關(guān)，一般由服務(wù)端進(jìn)行發(fā)送，單位為毫秒。主要是在數(shù)據(jù)幀的發(fā)送期間使用，但是需要注意的是，這個(gè)時(shí)序控制并不是限制最大時(shí)間，而是限制最小發(fā)送時(shí)間。也就是說，如果發(fā)送的是10ms的時(shí)序控制時(shí)間，則客戶端的每一個(gè)數(shù)據(jù)幀的最小的發(fā)送時(shí)間就是10ms，如果在9ms的時(shí)候發(fā)送了數(shù)據(jù)幀，則很多時(shí)候會服務(wù)器端會將其丟棄。附多幀發(fā)送的時(shí)序圖：
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-uRMnfXox-1574862939925)(https://www.abcde.engineer/wp-content/uploads/2019/05/2d46212699373f8ce6170de603e2731b.png)]

0x50 反饋類型

反饋類型主要分為：正反饋和負(fù)反饋，可能因?yàn)榉g或者是我自己的感受，總是覺得這兩個(gè)稱呼很難受。其實(shí)正反饋就是正確的指令的編碼返回，而負(fù)反饋則是當(dāng)指令的編碼錯(cuò)誤或者流程原因?qū)е铝藷o法執(zhí)行指令的情況下，給客戶端反饋的錯(cuò)誤代碼簡短的錯(cuò)誤記錄。他們的格式基本上如下：

0x51 正反饋

反饋幀格式：

幀格式定義	位置bit	備注
正反饋位置	2	當(dāng)其為1時(shí)就是正反饋，否則就可能不是正反饋
客戶端指令	0~2、3~7	一般都是客戶端傳輸過來的指令
相應(yīng)的狀態(tài)數(shù)據(jù)	8~63	根據(jù)相應(yīng)的指令格式進(jìn)行反饋

0x52 負(fù)反饋

反饋幀格式：

幀格式定義	位置bit	備注
負(fù)反饋位置	1~7	固定為全一
客戶端指令	8~15	固定為客戶端指令
相應(yīng)的錯(cuò)誤狀態(tài)	16~63	根據(jù)ISO14229相關(guān)的錯(cuò)誤狀態(tài)定義反饋