畢乾坤，徐旭

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

畢乾坤，徐旭

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

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

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

前言

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

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

其中，14229-1協(xié)議定義了UDS應(yīng)用層的內(nèi)容，對(duì)協(xié)議要實(shí)現(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ā)送方有一個(gè)消息需要傳輸時(shí)，會(huì)對(duì)數(shù)據(jù)字節(jié)大小進(jìn)行判斷，如果數(shù)據(jù)小于等于7個(gè)字節(jié)，則可以通過(guò)單幀SF（Single Frame）直接發(fā)送，反之，則需要通過(guò)網(wǎng)絡(luò)層進(jìn)行拆包，通過(guò)首幀F(xiàn)F（First Frame）和連續(xù)幀CF（Consecutive Frame）進(jìn)行發(fā)送。對(duì)于接收方來(lái)說(shuō)則剛好是相反的過(guò)程，當(dāng)收到的數(shù)據(jù)超過(guò)7個(gè)字節(jié)時(shí)，則需要通過(guò)網(wǎng)絡(luò)層對(duì)離散的單包數(shù)據(jù)進(jìn)行“組裝”，然后再將該消息傳遞給上層-應(yīng)用層。

1 時(shí)間參數(shù)

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

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

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

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

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

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

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

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

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

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

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

（3）程序下載會(huì)話模式（Programming Session）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 多幀報(bào)文時(shí)間參數(shù)解析

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

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

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

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

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

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

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

4 總結(jié)

本文對(duì)UDS協(xié)議中兩類時(shí)間參數(shù)進(jìn)行了解析，只有準(zhǔn)確的理解了每個(gè)時(shí)間參數(shù)的意義，才能在日后的工作中正確的進(jìn)行UDS協(xié)議的應(yīng)用，從而在遇到問(wèn)題時(shí)進(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

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

10.16638/j.cnki.1671-7988.2019.13.016