一、UDS诊断协议概述：从OSI七层模型到实车会话控制
大家好，我是老张。做汽车诊断这行十几年了，今天咱们聊聊UDS协议的基础。说实话，很多工程师一上来就啃协议栈，结果越看越懵。我个人习惯是，先搞清楚它到底在OSI模型里怎么跑的，再谈别的。
1.1 OSI七层模型与诊断协议栈
先问个问题：你发一条诊断请求，ECU是怎么收到的？
这背后就是OSI七层模型在干活。但咱们做诊断的，不用把七层全背下来。你只需要关注三层：
- 应用层（第7层）：UDS协议就在这层。说白了，就是定义“你说什么话，ECU能听懂”。比如0x10是诊断会话控制，0x22是读取数据。
- 网络层（第3层）：ISO 15765-2（也叫CAN TP）。它负责把长报文拆成CAN帧，再拼回去。我遇到过新手直接发超过8字节的请求，结果ECU没反应——就是忘了网络层分包。
- 数据链路层（第2层）：就是CAN总线本身。波特率、ID过滤、错误帧，都归它管。
嗯，这里要注意：诊断协议栈不是把七层全实现一遍。实际项目中，我们通常只实现应用层+网络层，底层用CAN驱动就行。
核心要点：UDS诊断请求的完整路径是：应用层（UDS）→ 网络层（CAN TP）→ 数据链路层（CAN）→ 物理层（差分信号）。反过来就是响应路径。
1.2 UDS与OBD的区别
很多刚入行的朋友分不清UDS和OBD。我简单说：
| 对比项 | UDS（ISO 14229） | OBD（ISO 15031） |
|---|---|---|
| 目的 | 整车诊断、刷写、配置 | 排放相关监测 |
| 服务数量 | 26个服务（0x10~0x3E等） | 9个服务（0x01~0x09） |
| 会话模式 | 默认、扩展、编程等 | 只有一种模式 |
| 应用场景 | 研发、产线、售后 | 年检、排放检测 |
我记得有一次，客户说“我的OBD诊断仪读不到UDS的DTC”。我一看，他用的OBD协议请求0x01，ECU当然不理你。UDS的DTC要用0x19服务去读。说白了，OBD是“体检”，UDS是“全身体检+手术”。
个人经验：如果你在做售后诊断工具，建议优先支持UDS。因为OBD能做的，UDS基本都能做，反过来就不行。
1.3 诊断会话控制（0x10）的三种模式
这是UDS里最基础也最重要的服务。0x10服务用来切换ECU的工作模式。为什么需要切换？你想想看，ECU平时要控制发动机、刹车，如果诊断请求一直占用资源，车还开不开了？
三种模式如下：
- 默认会话（0x01）：上电后的初始模式。只允许读取基本数据（如VIN码），不能刷写或执行特殊功能。说白了就是“只读模式”。
- 扩展会话（0x03）：允许读写更多数据，比如标定参数、IO控制。我一般在实车调试时用这个模式。注意：扩展会话有超时机制，默认5秒无活动就退回默认会话。
- 编程会话（0x02）：用于刷写ECU固件。这个模式下，ECU会停止大部分应用功能，只响应诊断请求。我曾经在产线上遇到过刷写中途掉线，ECU变砖的情况——就是因为没处理好编程会话的安全退出。
避坑指南：我曾经在项目里犯过一个低级错误——在编程会话里发了非刷写相关的请求（比如读VIN）。结果ECU直接NRC 0x22（条件不满足）。记住：编程会话只做刷写相关的事，别乱发其他服务。
来看一个实际的请求/响应示例：
// 请求：切换到扩展会话
发送：02 10 03 00 00 00 00 00
// 解释：02是长度，10是服务ID，03是扩展会话
// 响应：成功
接收：02 50 03 00 00 00 00 00
// 解释：50是响应（10+0x40），03表示当前在扩展会话嗯，这里要注意：响应的第二个字节是服务ID+0x40。这是UDS的固定规则，别搞混了。
小结
今天聊了三个核心点：OSI模型里诊断协议栈怎么分层、UDS和OBD的根本区别、0x10服务的三种会话模式。我个人觉得，理解这些基础比背协议栈更重要。下次咱们聊0x22和0x2E——读写数据的那些坑。
记住一句话：诊断协议是死的，但车是活的。多动手抓报文，比看十遍文档都管用。