3、诊断会话控制(0x10)：默认会话、编程会话、扩展会话的切换逻辑与安全策略
各位工程师朋友，咱们今天聊聊诊断会话控制。这个服务，服务ID是0x10，说白了就是ECU的“工作模式切换器”。你想想看，ECU不可能在所有场景下都开放全部功能吧？那太危险了。所以UDS协议定义了三种基本会话：默认会话、编程会话和扩展会话。它们之间的切换，可不是随便点一下鼠标那么简单。
3.1 三种会话的基本定位
先说说这三种会话各自是干嘛的。我个人习惯把默认会话叫做“看门狗模式”——ECU上电后自动进入，只响应最基础的诊断服务，比如读取故障码(0x19)、读取数据(0x22)这些。说白了，就是只让你看，不让你动。
编程会话呢，是给ECU刷写软件用的。我记得有一次在产线上，有个同事没切换到编程会话就直接发下载请求，结果ECU直接回了NRC 0x78（请求正确接收-响应待定），然后就没然后了。嗯，这里要注意：编程会话下，ECU会关闭一些非关键通信，腾出带宽给固件传输。
扩展会话就更有意思了。它开放了那些“高级调试功能”——比如写入配置参数、执行例程控制。我在项目中遇到过，有些ECU在扩展会话下才能做DTC状态位清零。你如果没切过去，发0x14服务（清除诊断信息）就会收到否定响应。
| 会话类型 | 子功能ID | 典型用途 | 安全等级 |
|---|---|---|---|
| 默认会话 | 0x01 | 基础诊断、故障读取 | 低（无需解锁） |
| 编程会话 | 0x02 | ECU刷写、固件升级 | 高（需安全访问） |
| 扩展会话 | 0x03 | 参数配置、例程控制 | 中（需安全访问） |
3.2 会话切换的逻辑与规则
切换会话，发送的报文格式很简单：0x10 + 子功能ID。但背后的逻辑，我建议你仔细看看。
规则一：从任何会话都能切到默认会话。 这是最安全的兜底策略。不管你现在在编程会话还是扩展会话，发一个0x10 0x01，ECU立马回到默认会话。我曾经调试一个ECU，刷写中途卡住了，就是靠这个命令让ECU“冷静下来”的。
规则二：从默认会话切到其他会话，必须经过安全解锁。 你想想看，如果随便一个诊断仪就能切到编程会话，那车岂不是谁都能刷？所以ECU会先检查你是否处于解锁状态。没解锁？给你回NRC 0x33（安全访问被拒绝）。
规则三：会话切换会重置安全状态。 这个坑我踩过。有一次我在扩展会话下解锁成功了，然后切到默认会话读了个数据，再切回扩展会话——结果发现又要重新解锁！为什么？因为每次会话切换，ECU都会把安全状态重置为“锁定”。嗯，这是设计上的安全考量，防止恶意程序利用已解锁的会话做坏事。
核心要点： 会话切换 = 状态机跳转。每次跳转都会触发：
- 重置安全访问状态（需重新解锁）
- 重置DTC状态位（部分ECU会清空待处理DTC）
- 重置通信参数（如P2定时器）
3.3 安全策略：谁可以切？怎么切？
安全策略这块，说白了就是“权限管理”。ECU怎么知道你有资格切到编程会话？靠的是安全访问服务(0x27)。
流程是这样的：
- 诊断仪发送0x10 0x02请求切到编程会话
- ECU回复NRC 0x33（安全访问被拒绝）
- 诊断仪发送0x27 0x01（请求种子）
- ECU返回种子（比如4字节随机数）
- 诊断仪用密钥算法计算响应，发送0x27 0x02
- ECU验证通过，解锁成功
- 诊断仪再次发送0x10 0x02——这次就成功了
我曾经在测试中遇到一个奇葩问题：某ECU的种子生成算法有bug，每次返回的种子都一样。这等于把安全大门敞开了！所以一致性测试里，会专门检查种子随机性和密钥算法的强度。
避坑指南： 我曾经见过一个项目，测试工程师在编程会话下直接发0x10 0x01切回默认会话，然后发0x10 0x02想再切回去——结果ECU死机了。为什么？因为默认会话下某些硬件模块还没初始化完成，切回去太快导致状态机混乱。所以我的建议是：切回默认会话后，等至少100ms再发下一个请求。
3.4 一致性测试中的常见检查项
做一致性测试时，0x10服务是必测项。我列几个常见的测试点：
- 会话切换响应时间： 从发送请求到收到响应，必须在P2_Server时间内完成。我记得某款ECU的P2时间是50ms，结果切换编程会话花了80ms——直接判定失败。
- 非法会话切换： 比如从编程会话直接切到扩展会话，有些ECU会拒绝（返回NRC 0x12），有些会允许。标准里其实没强制规定，但一致性测试会要求你明确行为。
- 会话超时： 默认会话下如果长时间无诊断请求，ECU会保持默认会话。但编程会话和扩展会话通常有超时机制——比如30秒无活动，自动切回默认会话。这个超时时间，测试时会用示波器精确测量。
- 并发会话： 有些ECU支持多个诊断仪同时连接，但会话切换只能由当前活动的诊断仪发起。测试时会模拟两个诊断仪同时发0x10请求，看ECU怎么处理。
个人小技巧： 测试会话切换时，我习惯用CANoe的CAPL脚本写一个自动测试序列。先发0x10 0x01确认在默认会话，然后发0x10 0x02，检查响应是否为NRC 0x33。接着执行安全解锁流程，再发0x10 0x02，检查响应是否为肯定响应。最后发0x10 0x01切回来。一套下来，5分钟就能跑完所有分支。
3.5 实战中的那些坑
最后分享几个我踩过的坑，希望能帮你少走弯路。
坑一：会话切换后DTC状态变化。 有一次我在扩展会话下清除了DTC，然后切到默认会话读DTC状态——发现之前清除的DTC又出现了！后来查规范才知道，有些ECU在会话切换时会重新运行DTC监控逻辑，导致“已清除”的DTC又被检测出来。解决办法是：清除DTC后，在同一个会话下读取确认，不要切来切去。
坑二：编程会话下的通信中断。 我记得有个项目，刷写过程中诊断仪突然断电了。ECU一直卡在编程会话里，无法响应任何请求。最后只能给ECU硬断电重启。所以现在很多ECU会加一个“编程会话超时自动回退”机制——比如5分钟内没收到任何刷写数据，自动切回默认会话。
坑三：扩展会话的“隐藏功能”。 有些ECU在扩展会话下会开放一些“非标服务”——比如修改VIN码、校准传感器。这些功能在默认会话下根本不可见。所以如果你发现某个服务总是返回NRC 0x11（服务不支持），不妨先切到扩展会话试试。
好了，关于诊断会话控制，今天就聊这么多。记住一句话：会话切换不是简单的“发个命令就完事”，它背后是一整套安全策略和状态机逻辑。做测试时，多想想“如果这样切会怎样”，能帮你发现很多隐藏的bug。