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

0x00 UDS概述

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

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

0x10 層次類型

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

0x11 物理層

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

0x12 鏈路層

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

0x13協(xié)議層

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

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

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

數(shù)據(jù)幀定義	數(shù)據(jù)幀標識	數(shù)據(jù)實體示例
標準幀	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則是相關的時控參數(shù)，這個會在之后再講。

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

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

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

數(shù)據(jù)反饋則是對于當前的指令數(shù)據(jù)處理完成之后，將其處理結果反饋給當前的數(shù)據(jù)接收端，這個數(shù)據(jù)反饋分為正反饋（正確反饋）和負反饋（錯誤反饋）。且嚴格根據(jù)時序限制進行數(shù)據(jù)傳輸。

時間限制

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

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

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

0x21 單幀

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

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

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

0x22 多幀

首幀

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

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

流控幀

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

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

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

數(shù)據(jù)幀

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

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

0x30 模式類型

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

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

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

0x40 時效類型

時效類型主要為應用會話過期時效與幀交互過期時效。

0x41應用會話過期時效

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

0x42 幀交互過期時效

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

0x50 反饋類型

反饋類型主要分為：正反饋和負反饋，可能因為翻譯或者是我自己的感受，總是覺得這兩個稱呼很難受。其實正反饋就是正確的指令的編碼返回，而負反饋則是當指令的編碼錯誤或者流程原因導致了無法執(zhí)行指令的情況下，給客戶端反饋的錯誤代碼簡短的錯誤記錄。他們的格式基本上如下：

0x51 正反饋

反饋幀格式：

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

0x52 負反饋

反饋幀格式：

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