作者 | 客服小祥

小編 | CACTUS

背景

UDS（Unified Diagnostic Services，統(tǒng)一診斷服務(wù)）是汽車電子領(lǐng)域的關(guān)鍵通信協(xié)議（ISO 14229標(biāo)準(zhǔn)），它如同車輛的"神經(jīng)系統(tǒng)"，讓診斷儀能夠與ECU（電子控制單元）進(jìn)行深度交互。在車輛全生命周期中，UDS支撐著故障排查、軟件刷寫、傳感器校準(zhǔn)等核心操作，其分層架構(gòu)將復(fù)雜功能拆解到OSI模型的各層協(xié)作實(shí)現(xiàn)。

偌大的城市車流不息，面對(duì)繁雜且實(shí)時(shí)性要求高的通勤來說，紅綠燈是保障通行效率的利器，在汽車診斷通信的世界里，這個(gè)角色就是UDS會(huì)話層 (ISO 14229-2標(biāo)準(zhǔn)的核心)，雖然它不像紅綠燈那樣直觀可見，卻是保障整個(gè)診斷會(huì)話有序、高效的關(guān)鍵！

UDS會(huì)話層是診斷通信的“會(huì)話管家”

位置：

它在OSI網(wǎng)絡(luò)模型的第5層——會(huì)話層，夾在網(wǎng)絡(luò)層（負(fù)責(zé)“數(shù)據(jù)打包運(yùn)輸”，如CAN, IP）和應(yīng)用層（負(fù)責(zé)“發(fā)號(hào)施令”，如診斷服務(wù)指令）之間，如下圖所示。

核心職責(zé)：

會(huì)話管理，就如同對(duì)話需要管理發(fā)言順序和主題，車輛診斷時(shí)也需要管理客戶端（診斷儀）和服務(wù)器（車輛ECU）之間的“對(duì)話狀態(tài)”（例如切換到默認(rèn)模式、編程模式或擴(kuò)展模式）。

抽象無形：

和網(wǎng)絡(luò)層協(xié)議（DoCAN、DoIP等）能在報(bào)文中直接看到地址不同，會(huì)話層是“無形的智慧規(guī)則”。我們只能通過理解它的運(yùn)作方式（流程）來把握它。

會(huì)話層的工作機(jī)制：三大服務(wù)

會(huì)話層通過三個(gè)核心的“服務(wù)原語”與應(yīng)用層和網(wǎng)絡(luò)層溝通，相當(dāng)于三個(gè)專職“聯(lián)絡(luò)員”：

01. S_Data.request (發(fā)送請(qǐng)求)：

S_Mtype：消息類型（診斷或遠(yuǎn)程診斷）

S_SA：發(fā)送方地址

S_TA：接收方地址

S_TAtype：地址類型（物理尋址或功能尋址）

(可選)S_AE：擴(kuò)展地址（遠(yuǎn)程診斷需要）

S_Length：數(shù)據(jù)長(zhǎng)度

S_Data：要發(fā)送的診斷指令內(nèi)容（如0x10 01 切到默認(rèn)會(huì)話）

02. S_Data.indication (收到通知)：

S_Result：接收結(jié)果（成功S_OK、失敗S_NOK）

03. S_Data.confirm (發(fā)送確認(rèn))：

通知應(yīng)用層對(duì)之前S_Data.request的回應(yīng)

會(huì)話層時(shí)間參數(shù)

了解這部分之前，我們先了解一個(gè)SOM的概念：

SOM（Start Of Message） 是多幀傳輸?shù)钠鹗紭?biāo)識(shí)，用于處理長(zhǎng)度超過單幀容量的診斷數(shù)據(jù)，當(dāng)診斷數(shù)據(jù)包超過單幀最大長(zhǎng)度時(shí)（如 CAN 總線單幀最大 8 字節(jié)），UDS 通過多幀傳輸機(jī)制分段發(fā)送數(shù)據(jù)，SOM 作為多幀傳輸?shù)钠鹗紭?biāo)志，承擔(dān)關(guān)鍵功能：

數(shù)據(jù)包分包指示，向接收方聲明“后續(xù)數(shù)據(jù)將分多幀傳輸”

長(zhǎng)度預(yù)通知，攜帶完整數(shù)據(jù)包的總長(zhǎng)度，接收方可預(yù)留緩存

傳輸控制同步，建立發(fā)送方和接收方的流控機(jī)制

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

會(huì)話層定義了關(guān)鍵的時(shí)間參數(shù)，以保障診斷通信高效且不至于無限等待：

以下是時(shí)間參數(shù)的一些常用值和推薦值：

關(guān)鍵場(chǎng)景圖說：

P2、P6示意（有SOM，如CANTP）：

1、Client T_Data.req：客戶端診斷應(yīng)用層向網(wǎng)絡(luò)層報(bào)告了一個(gè)請(qǐng)求消息

2、Server T_DataSOM.ind:服務(wù)器網(wǎng)絡(luò)層向應(yīng)用層上報(bào)了一個(gè)StartOfMessage請(qǐng)求指示消息

3、Client T_Data.con:客戶端網(wǎng)絡(luò)層向應(yīng)用層上報(bào)了一個(gè)請(qǐng)求消息完成的確認(rèn)，客戶端啟動(dòng)P2Client計(jì)時(shí)器

4、Server T_Data.ind:請(qǐng)求消息由網(wǎng)關(guān)進(jìn)行轉(zhuǎn)發(fā)，其中轉(zhuǎn)發(fā)到服務(wù)器損耗的時(shí)間為ΔP2Request；服務(wù)器網(wǎng)絡(luò)層向應(yīng)用層上報(bào)接收到完整的請(qǐng)求消息的指示，P2Server計(jì)時(shí)器啟動(dòng)

5、Server T_Data.ind:服務(wù)器應(yīng)用層經(jīng)過內(nèi)部處理，準(zhǔn)備將診斷響應(yīng)發(fā)往網(wǎng)絡(luò)層，這時(shí)應(yīng)用層發(fā)送T_Data.req，同時(shí)停止P2Server計(jì)時(shí)器，由此看出，P2Server計(jì)時(shí)器是服務(wù)器接收到請(qǐng)求指示到準(zhǔn)備發(fā)出響應(yīng)的時(shí)間

6、Client T_DataSOM.ind:診斷響應(yīng)消息由網(wǎng)關(guān)進(jìn)行轉(zhuǎn)發(fā)，其中轉(zhuǎn)發(fā)到客戶端損耗的時(shí)間為ΔP2Response；客戶端網(wǎng)絡(luò)層接收到服務(wù)器傳來的響應(yīng)消息，向應(yīng)用層上報(bào)StartOfMessage指示，并停止P2Client計(jì)時(shí)器，由此看出，P2Client計(jì)時(shí)器就是客戶端完成請(qǐng)求發(fā)送到接收到響應(yīng)消息的起始或T_Data.ind的時(shí)間

7、Server T_Data.con:服務(wù)器網(wǎng)絡(luò)層向應(yīng)用層上報(bào)了一個(gè)響應(yīng)消息完成的確認(rèn)

8、Client T_Data.ind:客戶端網(wǎng)絡(luò)層完整接收到診斷響應(yīng)消息，向應(yīng)用層上報(bào)指示消息

9、ΔP6Response:從服務(wù)器準(zhǔn)備發(fā)出響應(yīng)到客戶端完整接收到響應(yīng)結(jié)束

P2、P6示意（無SOM，如DoIP）：

區(qū)別點(diǎn)：客戶端應(yīng)用層不再接收到T_DataSOM.ind指示

P4Server示意：

圖中可以看出：

01、服務(wù)器接收到診斷請(qǐng)求消息indication開啟P4Server計(jì)時(shí)器

02、服務(wù)器回復(fù)負(fù)響應(yīng)NRC78后啟動(dòng)P2*Server計(jì)時(shí)器

03、服務(wù)器準(zhǔn)備發(fā)出最終響應(yīng)結(jié)束P2*Server和P4Server計(jì)時(shí)器

因此，P4Server計(jì)時(shí)器為服務(wù)器接收到請(qǐng)求到發(fā)送最終響應(yīng)的時(shí)間，當(dāng)P2Servermax=P4Server時(shí)，不允許發(fā)送NRC78的負(fù)響應(yīng)

02. 非默認(rèn)會(huì)話下的時(shí)間參數(shù)（S3保活機(jī)制）：

注意：S3Server的定時(shí)器處理是基于網(wǎng)絡(luò)層/傳輸層服務(wù)，因此當(dāng)服務(wù)器接收到任何不支持的診斷消息時(shí)也能夠重新啟動(dòng)S3Server定時(shí)器。

以下是一個(gè)功能尋址0x3E服務(wù)的示例

關(guān)鍵場(chǎng)景圖說：

由圖可知：

1、第一步客戶端請(qǐng)求了一個(gè)非默認(rèn)會(huì)話的請(qǐng)求，例如：10 03或10 02

2、第二步當(dāng)客戶端成功發(fā)送請(qǐng)求消息,向應(yīng)用層上報(bào)T_Data.con后，開啟S3Client計(jì)時(shí)器

3、第四步中服務(wù)器響應(yīng)消息成功發(fā)送,向應(yīng)用層上報(bào)T_Data.con，服務(wù)器開啟S3Server計(jì)時(shí)器

4、第六步中服務(wù)器接收到客戶端發(fā)送來的請(qǐng)求消息，向應(yīng)用層上報(bào)T_Data.ind，停止S3Server計(jì)時(shí)器，當(dāng)服務(wù)器處理響應(yīng)報(bào)文時(shí)，任何由客戶端發(fā)送的功能尋址0x3E 0x80將被忽略

5、第9步中，S3Client超時(shí)，客戶端發(fā)送功能尋址的0x3E 0x80

6、第10步中，客戶端成功發(fā)送功能尋址的0x3E 0x80，向應(yīng)用層上報(bào)T_Data.con，開啟新的S3Client計(jì)時(shí)器

7、第11步中服務(wù)器成功發(fā)送響應(yīng)消息，向應(yīng)用層上報(bào)T_Data.con，開啟新的S3Server計(jì)時(shí)器

8、第13步中，客戶端S3Client超時(shí)后，再次發(fā)送功能尋址的0x3E 0x80，這時(shí)服務(wù)器S3Server計(jì)時(shí)器計(jì)時(shí)中，

因此會(huì)被客戶端發(fā)送的功能尋址的0x3E 0x80重置S3Server計(jì)時(shí)器

總結(jié)

汽車診斷絕非簡(jiǎn)單的“一問一答”。UDS會(huì)話層作為OSI模型里的“第五層居民”，就像一位看不見的交通指揮員和會(huì)話管家：

管理對(duì)話狀態(tài)：

讓診斷儀能和ECU在正確的“頻道”（會(huì)話模式）上溝通。

確保信息通達(dá)：

通過精心設(shè)計(jì)的服務(wù)接口，有序傳遞命令和響應(yīng)。

掌控時(shí)間節(jié)奏：

用各種定時(shí)器防止通信卡死或ECU“失聯(lián)”，保證流程高效可靠。

理解會(huì)話層，是真正吃透UDS協(xié)議精髓的關(guān)鍵一步。ISO14229-2協(xié)議文本如同藏寶圖，里面還蘊(yùn)含著錯(cuò)誤處理、復(fù)雜尋址等更多秘密，等待你去發(fā)掘！下次診斷時(shí)，別忘了這臺(tái)“精密對(duì)話機(jī)器”背后，還有這位無形的秩序維護(hù)者在默默工作。

參考文獻(xiàn)：

1.Road vehicles— Unified diagnostic services (UDS) —Part 2: Session layer services

2.Road vehicles—Diagnostic communication over Controller Area Network(Do CAN) — Part 2: Transport protocol and network layer services

注：文中部分圖片來自Vector