UDS協(xié)議棧中的時間參數(shù)解析

畢乾坤，徐旭

UDS協(xié)議棧中的時間參數(shù)解析

畢乾坤，徐旭

（陜西法士特汽車傳動工程研究院智能傳動研究所，陜西 西安 710119）

UDS協(xié)議是道路車輛通用診斷規(guī)范的簡稱，目前主要應(yīng)用在商用車電氣零部件系統(tǒng)中，各個電氣子系統(tǒng)基于該協(xié)議與外部診斷設(shè)備進(jìn)行數(shù)據(jù)交互，從而實現(xiàn)程序更新、故障讀取等功能。完整的協(xié)議棧包含了多個國際標(biāo)準(zhǔn)，其中ISO14229-1、ISO 15765-2、ISO 15765-3分別定義了應(yīng)用層、網(wǎng)絡(luò)層中的時間參數(shù)，文章針對標(biāo)準(zhǔn)中所要求的時間參數(shù)進(jìn)行了解析和說明。

UDS協(xié)議；應(yīng)用層；網(wǎng)絡(luò)層

前言

UDS 協(xié)議是道路車輛通用診斷協(xié)議（Road Vehicles – Unified Diagnostic Services）的簡稱，是目前商用車電氣子系統(tǒng)TCU或ECU采用的主流診斷協(xié)議，電氣子系統(tǒng)控制器基于該協(xié)議和外部診斷設(shè)備進(jìn)行數(shù)據(jù)交互，從而實現(xiàn)程序更新和故障讀取等功能。

UDS協(xié)議棧了參照了OSI架構(gòu)設(shè)計，根據(jù)不同的軟件功能定義了7層分層架構(gòu)，

其中，14229-1協(xié)議定義了UDS應(yīng)用層的內(nèi)容，對協(xié)議要實現(xiàn)的服務(wù)功能進(jìn)行了抽象和定義。 ISO 15765 -2 / 3定義了網(wǎng)絡(luò)層的數(shù)據(jù)傳輸形式。

圖1 UDS協(xié)議數(shù)據(jù)單元傳輸流示意圖

圖1描述了數(shù)據(jù)發(fā)送方和接收方之間的數(shù)據(jù)流，當(dāng)發(fā)送方有一個消息需要傳輸時，會對數(shù)據(jù)字節(jié)大小進(jìn)行判斷，如果數(shù)據(jù)小于等于7個字節(jié)，則可以通過單幀SF（Single Frame）直接發(fā)送，反之，則需要通過網(wǎng)絡(luò)層進(jìn)行拆包，通過首幀F(xiàn)F（First Frame）和連續(xù)幀CF（Consecutive Frame）進(jìn)行發(fā)送。對于接收方來說則剛好是相反的過程，當(dāng)收到的數(shù)據(jù)超過7個字節(jié)時，則需要通過網(wǎng)絡(luò)層對離散的單包數(shù)據(jù)進(jìn)行“組裝”，然后再將該消息傳遞給上層-應(yīng)用層。

1 時間參數(shù)

為了保證協(xié)議棧通訊時的及時性和準(zhǔn)確性，協(xié)議?；趹?yīng)用層和網(wǎng)絡(luò)層的工作機(jī)制定義了不同的時間參數(shù)：

（1）應(yīng)用層標(biāo)準(zhǔn)14229-1中定義了“服務(wù)請求-服務(wù)響應(yīng)”時間參數(shù)，如果超時，則視為服務(wù)異常。

（2）網(wǎng)絡(luò)層標(biāo)準(zhǔn)ISO 15765中定義了網(wǎng)絡(luò)層的時間參數(shù)，對單幀、首幀、連續(xù)幀、流控幀的交互進(jìn)行了時間約束，如果超時，則視為通訊異常。

2 應(yīng)用層時間參數(shù)

應(yīng)用層中定義了兩個用戶角色：

（1）客戶端（Client / Tester），客戶端向服務(wù)器端請求某個服務(wù)，由外部診斷設(shè)備來實現(xiàn)。

（2）服務(wù)器端（Server），基于收到的客戶請求執(zhí)行某些動作并進(jìn)行反饋，由TCU或ECU來實現(xiàn)。

典型的服務(wù)請求例如會話服務(wù)，客戶端向服務(wù)器端請求切換到某個會話模式下，當(dāng)客戶端發(fā)送了服務(wù)請求后，服務(wù)器端應(yīng)在規(guī)定的時間結(jié)束前進(jìn)行反饋，否則視為時間超時，說明服務(wù)異常。

應(yīng)用層的時間參數(shù)又分為兩種場景，默認(rèn)會話模式下、非默認(rèn)會話模式下，所謂的會話模式，可類比為“語境”，標(biāo)準(zhǔn)中共定義了3種會話模式：

（1）默認(rèn)會話模式（Default Session）。

（2）擴(kuò)展會話模式（Extended Session）。

（3）程序下載會話模式（Programming Session）。

不同的會話模式下映射了不同的服務(wù)請求功能，也就是說某個具體的服務(wù)只能在規(guī)定的“語境”下才能執(zhí)行。

2.1 默認(rèn)會話模式下的時間參數(shù)

默認(rèn)會話模式下定義了6個時間參數(shù)：

（1）P2CAN_Client，客戶端時間參數(shù)，當(dāng)客戶端發(fā)出某個服務(wù)請求后，服務(wù)器端應(yīng)在該時間內(nèi)進(jìn)行反饋。

（2）P2*CAN_Client，客戶端增強(qiáng)時間參數(shù)，當(dāng)客戶端收到服務(wù)器端的負(fù)響響應(yīng)0x78后，應(yīng)在該時間到達(dá)前收到反饋。

（3）P2CAN_Server，服務(wù)器端時間參數(shù)，當(dāng)服務(wù)器端收到服務(wù)請求后，應(yīng)在該時間內(nèi)進(jìn)行反饋。

（4）P2*CAN_Server，服務(wù)器端增加時間參數(shù)，當(dāng)服務(wù)器端發(fā)送負(fù)響響應(yīng)0x78后，應(yīng)在該時間到達(dá)前進(jìn)行反饋。

（5）P3CAN_Client_Phys，客戶端以物理尋址形式發(fā)送服務(wù)請求的最短時間間隔，當(dāng)客戶端發(fā)送的服務(wù)不需要服務(wù)器端進(jìn)行響應(yīng)時，應(yīng)以該時間為間隔發(fā)送下一條物理尋址的請求報文。

（6）P3CAN_Client_Func，客戶端以功能尋址形式發(fā)送服務(wù)請求的最短時間間隔，當(dāng)客戶端發(fā)送的服務(wù)請求不需要響應(yīng)時，或是所請求的服務(wù)不被支持時，應(yīng)以該時間為間隔發(fā)送下一條功能尋址的請求報文。

2.2 非默認(rèn)會話模式下的時間參數(shù)

（1）S3Cline，客戶端在功能尋址模式下向多個服務(wù)器端發(fā)送TesterPresent（0x3E）服務(wù)的時間間隔，以用來使服務(wù)器端保持在非默認(rèn)會話模式下。

（2）S3Server，當(dāng)服務(wù)器端沒收到任何服務(wù)請求時，會在該時間內(nèi)保持非默認(rèn)會話模式，當(dāng)超時后，服務(wù)器端會自動切換到默認(rèn)會話模式下。

3 網(wǎng)絡(luò)層時間參數(shù)

ISO 15765標(biāo)準(zhǔn)中定義了4種不同的幀類型，以每幀數(shù)據(jù)中第一個字節(jié)中的NPCI（Network Protocol Control Informa tion）進(jìn)行標(biāo)示。

表1 協(xié)議控制單元對應(yīng)的幀類型

（1）單幀，NPCI = 0，對于不超過7個字節(jié)的數(shù)據(jù)單元，網(wǎng)絡(luò)層通過單幀報文進(jìn)行發(fā)送。

（2）首幀，NPCI = 1，當(dāng)數(shù)據(jù)單元的大小超過7字節(jié)時，則需通過首幀開始進(jìn)行發(fā)送，F(xiàn)F_DL表明了需要發(fā)送的字節(jié)長度，最多4095個字節(jié)。

（3）連續(xù)幀，NCPI = 2，當(dāng)大數(shù)據(jù)發(fā)送方完成首幀發(fā)送后，則開始通過連續(xù)幀進(jìn)行逐包發(fā)送。

（4）流控幀，NCPI = 3，當(dāng)數(shù)據(jù)接收方接收到首幀后，則應(yīng)該向發(fā)送方反饋流控信息，以表明自己對于大數(shù)據(jù)的接收能力，通過參數(shù)FlowStatus、BlockSize，Seperation Time Minimum來進(jìn)行標(biāo)示。

針對上述的報文交互過程，標(biāo)準(zhǔn)中定義了6個時間參數(shù)，每一個時間參數(shù)都對應(yīng)著一個定時器，通過定時器的啟動、結(jié)束時間來判斷是否有超時事件發(fā)生。

3.1 多幀報文時間參數(shù)解析

（1）N_As / N_Ar：分別指的是接收方和發(fā)送方在進(jìn)行每一幀CAN報文發(fā)送時的時間約束。

（2）N_Bs：當(dāng)發(fā)送方成功發(fā)送FirstFrame后，就開始啟動這個定時器，接收方應(yīng)在時間Br到達(dá)前向發(fā)送方發(fā)出流控報文FlowControl，流控報文應(yīng)在時間N_Ar之內(nèi)成功發(fā)送的到總線上。

（3）N_Br：這個時間是接收方內(nèi)部的一個過程響應(yīng)時間，成功收到FirstFrame后，應(yīng)在這個時間內(nèi)做出指令動作，命令數(shù)據(jù)鏈路層發(fā)送響應(yīng)報文- FlowControl，而Flow Control的具體發(fā)送過程又應(yīng)該滿足N_Ar時間的要求。

（4）N_Cs：當(dāng)發(fā)送方成功接收到FlowControl報文之后，應(yīng)該在這個時間內(nèi)進(jìn)行響應(yīng)并開始發(fā)送連續(xù)幀Consectuive Frame，而連續(xù)幀的具體發(fā)送過程又應(yīng)滿足N_As時間的要求。

（5）N_Cr：接收方在成功發(fā)送出流控幀之后，應(yīng)啟動定時器并開始等待連續(xù)幀的到達(dá)。

圖2 大數(shù)據(jù)發(fā)送、接收示意圖

通過這些時間參數(shù)對首幀、流控幀、連續(xù)幀報文進(jìn)行時間約束，以保證多包報文的傳輸，避免網(wǎng)絡(luò)中出現(xiàn)的報文丟失或次序混亂等現(xiàn)象。

4 總結(jié)

本文對UDS協(xié)議中兩類時間參數(shù)進(jìn)行了解析，只有準(zhǔn)確的理解了每個時間參數(shù)的意義，才能在日后的工作中正確的進(jìn)行UDS協(xié)議的應(yīng)用，從而在遇到問題時進(jìn)行正確的分析和定位。

[1] ISO 14229-1,Road Vehicles-Unified diagnostic services-Part 1: Speci -fication and requirements[S].ISO,2013.

[2] ISO 15765-2, Road Vehicles-Diagnostic communication over Contro -ller Area Network (DoCAN) -Part 2:Transport protocol and nwt work layer services [S]. ISO, 2011.

[3] ISO 15765-3,Road Vehicles-Diagnostic communication over Contro -ller Area Network (DoCAN)-Part 3: Implementation of unified diagnostic services (UDS on CAN) [S]. ISO, 2011.

Timing Parameter Parsing in UDS Protocol Stack

Bi Qiankun, Xu Xu

( Shaanxi Fast Auto Drive Engineering Research Insitute, Shaanxi Xi’an 710119 )

UDS protocol is Road Vehicles-Unified Diagnostic Services, which is mainly applied in electronic sub systems of commerical vehicle. The external tester and TCU exchange data based on it to implement flash programming and diag -nostic code parsing. ISO 14229-1, ISO 15765- 2, ISO 15765-3 specify application layer and network layer timing parame -ters which should be complied.

UDS Protocol; Application layer; Network layer

U472.9

A

1671-7988(2019)13-43-03

U472.9

A

1671-7988(2019)13-43-03

畢乾坤，首席控制工程師，中級工程師，就職于陜西法士特汽車傳功研究院智能傳動研究所，主要研究內(nèi)容：液力自動變速器控制邏輯開發(fā)，商用車診斷系統(tǒng)開發(fā)。

10.16638/j.cnki.1671-7988.2019.13.016