4、诊断会话控制（0x10）：默认会话、编程会话、扩展会话、安全会话的切换机制
各位工程师朋友，咱们今天聊聊诊断会话控制。这个服务在UDS协议里代号0x10，说白了就是ECU的“工作模式切换器”。
我刚开始接触UDS时，觉得这玩意儿不就是发个指令切个模式嘛，有啥好讲的？后来在产线上被坑过几次才明白——会话切换要是搞不清楚，后面所有诊断服务都可能翻车。
4.1 四种会话模式概述
UDS 0x10服务定义了四种标准会话模式。每种模式对应不同的权限和功能集合。我习惯把它们比作ECU的“门禁卡”——不同卡能开的门不一样。
| 会话模式 | SID+SubFunc | 主要用途 | 典型场景 |
|---|---|---|---|
| 默认会话 | 0x10 01 | 基础诊断通信，只读操作 | 读取VIN、DTC状态 |
| 编程会话 | 0x10 02 | ECU固件刷写、标定 | EOL下线刷写、OTA升级 |
| 扩展会话 | 0x10 03 | 高级诊断功能，读写参数 | 写入配置、执行例程 |
| 安全会话 | 0x10 04 | 安全相关操作，需解锁 | 密钥写入、安全访问 |
关键点：ECU上电后默认进入默认会话。其他会话需要通过0x10服务主动切换。切换时ECU会终止当前会话下的非持久性操作。
4.2 会话切换机制详解
会话切换不是你想切就能切的。ECU内部有一套严格的规则。我给大家拆开讲。
4.2.1 切换流程
客户端发送0x10服务请求，格式如下：
请求：02 10 03 AA
响应：02 50 03 BB
其中：
02 = 数据长度
10 = 服务ID
03 = 子功能（目标会话模式）
AA = 补充字节（可选）
BB = 响应参数（当前会话剩余时间等）ECU收到请求后，会做三件事：
- 验证当前会话是否允许切换——有些会话不能直接切到另一些会话
- 终止当前会话下的非持久性操作——比如正在执行的例程会被强制停止
- 初始化目标会话环境——分配资源、设置定时器
我曾经踩过的坑：有一次在EOL产线上，编程会话切到扩展会话时，ECU没有正确终止刷写流程，导致后续写入的参数全部丢失。后来查了几个月才发现是会话切换时没有先发0x28（通信控制）停止通信。从那以后，我每次切换会话前都会检查当前是否有未完成的操作。
4.2.2 会话间的切换限制
不是所有会话都能互相切换。我画了一张图，大家一看就明白。
我个人习惯：在EOL测试脚本里，每次切换会话前都先切回默认会话，再切到目标会话。虽然多了一步，但能避免很多奇奇怪怪的切换失败问题。你想想看，ECU厂商的实现千奇百怪，走标准路径最安全。
4.3 会话超时与保持
每个会话都有超时定时器。ECU如果在超时时间内没有收到任何诊断请求，会自动切回默认会话。这个机制是为了防止诊断会话一直占用ECU资源。
| 会话模式 | 默认超时时间 | 可配置性 |
|---|---|---|
| 默认会话 | 无超时（一直保持） | — |
| 编程会话 | 5秒（典型值） | 可通过0x83服务修改 |
| 扩展会话 | 5秒（典型值） | 可通过0x83服务修改 |
| 安全会话 | 5秒（典型值） | 可通过0x83服务修改 |
注意：超时时间是从收到上一条诊断请求开始计算的。如果你在编程会话里刷写固件，刷写过程中ECU会持续收到数据，超时定时器会不断重置。但刷写完成后，如果5秒内没有新请求，ECU就会切回默认会话。我曾经在产线上遇到过刷写完成后忘记发保持会话请求，结果ECU切回默认会话，后续的配置写入全部失败。
4.4 实际应用中的避坑指南
做EOL下线测试这么多年，我总结了几条会话切换的实战经验：
- 切换前先读当前会话——用0x22 00 10读一下当前会话ID，确认ECU状态。我见过有些ECU在特定条件下会拒绝切换。
- 编程会话和扩展会话不能互切——必须经过默认会话中转。这是ISO 14229-1的强制要求，但有些ECU厂商会自己加实现，别依赖这个。
- 安全会话需要先做安全访问——切到安全会话后，还需要通过0x27服务解锁才能执行安全相关操作。别以为切过去就能直接写密钥。
- 超时时间要留余量——产线上网络可能有延迟，建议把超时时间设到10秒以上，或者用0x83服务修改ECU的超时参数。
一句话总结：会话控制是UDS诊断的“门禁系统”。搞懂了它，后面的诊断服务才能顺畅执行。我个人建议大家在写EOL测试脚本时，把会话切换封装成一个独立函数，每次调用都做完整的切换-确认-超时处理。这样既规范又省心。