作者 | 客服小祥

小編 | CACTUS

背景

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

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

UDS會話層是診斷通信的“會話管家”

位置：

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

核心職責：

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

抽象無形：

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

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

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

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

S_Mtype：消息類型（診斷或遠程診斷）

S_SA：發(fā)送方地址

S_TA：接收方地址

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

(可選)S_AE：擴展地址（遠程診斷需要）

S_Length：數(shù)據(jù)長度

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

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

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

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

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

會話層時間參數(shù)

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

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

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

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

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

01. 默認會話下的時間參數(shù)

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

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

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

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

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

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

3、Client T_Data.con:客戶端網(wǎng)絡(luò)層向應(yīng)用層上報了一個請求消息完成的確認，客戶端啟動P2Client計時器

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

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

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

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

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

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

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

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

P4Server示意：

圖中可以看出：

01、服務(wù)器接收到診斷請求消息indication開啟P4Server計時器

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

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

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

02. 非默認會話下的時間參數(shù)（S3保活機制）：

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

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

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

由圖可知：

1、第一步客戶端請求了一個非默認會話的請求，例如：10 03或10 02

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

確保信息通達：

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

掌控時間節(jié)奏：

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

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

參考文獻：

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