4. UDS会话管理：默认会话、扩展会话、编程会话、会话切换机制、会话超时处理

聊到UDS诊断，会话管理是绕不开的基础。说白了，ECU就像个有门禁的房间，不同的人进来权限不一样。默认会话、扩展会话、编程会话，就是三种不同级别的“门禁卡”。

我刚开始做诊断协议时，觉得会话切换不就是发个指令嘛，有啥难的？后来在项目里踩过坑才明白——会话超时处理不好，ECU可能直接“罢工”，导致产线刷写失败。嗯，咱们今天就把这块彻底讲透。

4.1 三种会话模式

UDS协议里定义了三种标准会话，咱们一个一个看。

会话模式	SID	子功能	典型用途
默认会话 (Default Session)	0x10	0x01	上电后的初始状态，只允许读取基本数据
扩展会话 (Extended Session)	0x10	0x03	允许读写参数、执行例程，常用于标定
编程会话 (Programming Session)	0x10	0x02	允许刷写Flash，权限最高

4.2 默认会话

ECU上电后，默认进入的就是默认会话。这个状态下，能做的事情很有限——读个DTC、读个数据标识符，基本就这些了。

我个人习惯把默认会话叫做“安全模式”。为什么？因为在这个模式下，你动不了任何关键参数，也刷不了程序。万一诊断仪发了个非法请求，ECU也不会出大问题。

4.3 扩展会话

扩展会话，说白了就是“调试模式”。在这个模式下，你可以读写大部分参数，执行例程，甚至做一些IO控制。

我记得有个项目，客户抱怨ECU在产线上总是报错。我排查后发现，产线设备在扩展会话下发送了写请求，但ECU还没来得及切回默认会话就断电了。下次上电时，参数处于不一致状态。后来我建议他们在写操作完成后，主动切回默认会话，问题就解决了。

4.4 编程会话

编程会话是权限最高的模式。在这个模式下，你可以擦除Flash、写入新的应用程序或Bootloader。

你想想看，如果谁都能随便进编程会话，那ECU的安全性就形同虚设了。所以，进入编程会话前，通常需要先通过安全访问（0x27服务）的验证。

4.5 会话切换机制

会话切换通过0x10服务（Diagnostic Session Control）实现。请求格式很简单：

请求：0x10 + 子功能（0x01/0x02/0x03）
响应：0x50 + 子功能 + 会话参数（可选）

举个例子，从默认会话切到编程会话：

请求：02 10 02
响应：06 50 02 00 32 00 0A

响应里的后四个字节，00 32 表示P2Server_max（500ms），00 0A表示P2*Server_max（10ms）。这两个参数告诉诊断仪：ECU处理请求的最大时间是多少。

为什么会这样？因为不同会话下，ECU的响应速度可能不一样。编程会话时ECU忙着擦写Flash，响应自然慢一些。

4.6 会话超时处理

这是最容易出问题的地方。每个会话都有一个超时时间（S3Server），如果在这个时间内没有收到任何诊断请求，ECU会自动切回默认会话。

会话模式	典型S3Server超时时间	说明
默认会话	无超时（或很长）	默认会话不会自动切换
扩展会话	5秒	常见值，可配置
编程会话	5秒	刷写过程中要持续发送请求保持会话

我曾经在产线上遇到过一个问题：刷写工具每发送一个数据块后，要等ECU擦写完才能发下一个。但擦写时间超过了5秒，ECU自动切回了默认会话。结果刷写工具再发数据时，ECU直接返回NRC 0x78（RequestCorrectlyReceived-ResponsePending），然后超时失败。

怎么解决？两个办法：

• 刷写工具在等待期间，定期发送0x3E（TesterPresent）保持会话
• ECU在擦写期间，主动发送0x78响应，告诉诊断仪“我还在忙，别急”

4.7 实际项目中的建议

说了这么多，总结几条实战经验：

1. 会话状态机要清晰：我建议用状态机实现会话管理，每个状态明确允许哪些服务。别搞成“万能状态”，容易出安全漏洞。
2. 超时时间要合理：扩展会话和编程会话的超时时间，别设太短也别设太长。5秒是个不错的起点，但要根据实际场景调整。
3. 0x3E服务必须实现：这是保持会话的“救命稻草”。特别是刷写场景，没有它，会话超时是必然的。
4. 会话切换要检查权限：从默认会话切到编程会话，必须先通过安全访问。别让任何人随便进编程模式。

好了，会话管理这块就聊到这儿。下一章咱们讲安全访问——怎么给ECU上把锁，防止别人乱动你的程序。