背景：

UDS（Unified Diagnostic Services，统一诊断服务）是汽车电子领域的关键通信协议（ISO 14229标准），它如同车辆的"神经系统"，让诊断仪能够与ECU（电子控制单元）进行深度交互。在车辆全生命周期中，UDS支撑着故障排查、软件刷写、传感器校准等核心操作，其分层架构将复杂功能拆解到OSI模型的各层协作实现。

偌大的城市车流不息，面对繁杂且实时性要求高的通勤来说，红绿灯是保障通行效率的利器，在汽车诊断通信的世界里，这个角色就是UDS会话层 (ISO 14229-2标准的核心)，虽然它不像红绿灯那样直观可见，却是保障整个诊断会话有序、高效的关键！

一、UDS会话层是诊断通信的“会话管家”

• 位置：

它在OSI网络模型的第5层——会话层，夹在网络层（负责“数据打包运输”，如CAN, IP）和应用层（负责“发号施令”，如诊断服务指令）之间，如下图所示。

• 核心职责：

会话管理，就如同对话需要管理发言顺序和主题，车辆诊断时也需要管理客户端（诊断仪）和服务器（车辆ECU）之间的“对话状态”（例如切换到默认模式、编程模式或扩展模式）。

• 抽象无形：

和网络层协议（DoCAN、DoIP等）能在报文中直接看到地址不同，会话层是“无形的智慧规则”。我们只能通过理解它的运作方式（流程）来把握它。

二、会话层的工作机制：三大服务

会话层通过三个核心的“服务原语”与应用层和网络层沟通，相当于三个专职“联络员”：

（一）S_Data.request (发送请求)：

S_Mtype：消息类型（诊断或远程诊断）

S_SA：发送方地址

S_TA：接收方地址

S_TAtype：地址类型（物理寻址或功能寻址）

(可选)S_AE：扩展地址（远程诊断需要）

S_Length：数据长度

S_Data：要发送的诊断指令内容（如0x10 01 切到默认会话）

（二）S_Data.indication (收到通知)：

S_Result：接收结果（成功S_OK、失败S_NOK）

（三）S_Data.confirm (发送确认)：

通知应用层对之前S_Data.request的回应

三、会话层时间参数

了解这部分之前，我们先了解一个SOM的概念：

SOM（Start Of Message） 是多帧传输的起始标识，用于处理长度超过单帧容量的诊断数据，当诊断数据包超过单帧最大长度时（如 CAN 总线单帧最大 8 字节），UDS 通过多帧传输机制分段发送数据，SOM 作为多帧传输的起始标志，承担关键功能：

• 数据包分包指示，向接收方声明“后续数据将分多帧传输”
• 长度预通知，携带完整数据包的总长度，接收方可预留缓存
• 传输控制同步，建立发送方和接收方的流控机制

（一）默认会话下的时间参数

会话层定义了关键的时间参数，以保障诊断通信高效且不至于无限等待：

以下是时间参数的一些常用值和推荐值：

关键场景图说：

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示意：

图中可以看出：

• 1、服务器接收到诊断请求消息indication开启P4Server计时器
• 2、服务器回复负响应NRC78后启动P2*Server计时器
• 3、服务器准备发出最终响应结束P2*Server和P4Server计时器

因此，P4Server计时器为服务器接收到请求到发送最终响应的时间，当P2Servermax=P4Server时，不允许发送NRC78的负响应

（二）非默认会话下的时间参数（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