作者 | 客服小祥

小編 | CACTUS

背景

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

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

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

位置：

它在OSI網絡模型的第5層——會話層，夾在網絡層（負責“數據打包運輸”，如CAN, IP）和應用層（負責“發號施令”，如診斷服務指令）之間，如下圖所示。

核心職責：

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

抽象無形：

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

會話層的工作機制：三大服務

會話層通過三個核心的“服務原語”與應用層和網絡層溝通，相當于三個專職“聯絡員”：

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

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

S_SA：發送方地址

S_TA：接收方地址

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

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

S_Length：數據長度

S_Data：要發送的診斷指令內容（如0x10 01 切到默認會話）

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

S_Result：接收結果（成功S_OK、失敗S_NOK）

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

通知應用層對之前S_Data.request的回應

會話層時間參數

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

SOM（Start Of Message） 是多幀傳輸的起始標識，用于處理長度超過單幀容量的診斷數據，當診斷數據包超過單幀最大長度時（如 CAN 總線單幀最大 8 字節），UDS 通過多幀傳輸機制分段發送數據，SOM 作為多幀傳輸的起始標志，承擔關鍵功能：

數據包分包指示，向接收方聲明“后續數據將分多幀傳輸”

長度預通知，攜帶完整數據包的總長度，接收方可預留緩存

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

01. 默認會話下的時間參數

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

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

關鍵場景圖說：

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

1、Client T_Data.req：客戶端診斷應用層向網絡層報告了一個請求消息

2、Server T_DataSOM.ind:服務器網絡層向應用層上報了一個StartOfMessage請求指示消息

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

4、Server T_Data.ind:請求消息由網關進行轉發，其中轉發到服務器損耗的時間為ΔP2Request；服務器網絡層向應用層上報接收到完整的請求消息的指示，P2Server計時器啟動

5、Server T_Data.ind:服務器應用層經過內部處理，準備將診斷響應發往網絡層，這時應用層發送T_Data.req，同時停止P2Server計時器，由此看出，P2Server計時器是服務器接收到請求指示到準備發出響應的時間

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

7、Server T_Data.con:服務器網絡層向應用層上報了一個響應消息完成的確認

8、Client T_Data.ind:客戶端網絡層完整接收到診斷響應消息，向應用層上報指示消息

9、ΔP6Response:從服務器準備發出響應到客戶端完整接收到響應結束

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

區別點：客戶端應用層不再接收到T_DataSOM.ind指示

P4Server示意：

圖中可以看出：

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

02、服務器回復負響應NRC78后啟動P2*Server計時器

03、服務器準備發出最終響應結束P2*Server和P4Server計時器

因此，P4Server計時器為服務器接收到請求到發送最終響應的時間，當P2Servermax=P4Server時，不允許發送NRC78的負響應

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

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

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

關鍵場景圖說：

由圖可知：

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

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

3、第四步中服務器響應消息成功發送,向應用層上報T_Data.con，服務器開啟S3Server計時器

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

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

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

7、第11步中服務器成功發送響應消息，向應用層上報T_Data.con，開啟新的S3Server計時器

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

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

總結

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

管理對話狀態：

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

確保信息通達：

通過精心設計的服務接口，有序傳遞命令和響應。

掌控時間節奏：

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

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

參考文獻：

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