2. UDS协议概述：协议栈架构、服务分类、与OBD-II的区别、应用场景
好，咱们正式开始聊UDS协议。这一章算是整个课程的地基，我会把UDS的骨架给你搭起来。你可能会问，为什么非得学UDS？说白了，现在市面上跑的车，从几万块的代步车到百万级的豪车，ECU（电子控制单元）之间的诊断通信，几乎都绕不开UDS。我入行那会儿，还在用一些厂商私有的诊断协议，那叫一个乱。后来UDS一统江湖，大家开发起来省心多了。
2.1 UDS协议栈架构
UDS的全称是 Unified Diagnostic Services，统一诊断服务。它定义在ISO 14229标准里。但注意，它不是一个孤立的协议，而是跑在OSI模型上层的一个应用层协议。
嗯，这里有个关键点：UDS本身不关心数据是怎么传过去的。它只定义“我说了什么话”，至于“这话是通过快递还是飞鸽传书”，那是下层协议的事。在实际的CAN总线系统中，它的架构通常是这样的：
- 应用层（UDS）：你发的诊断请求，比如“读取故障码”、“写入参数”，这就是UDS干的事。
- 会话层与网络层（ISO 15765-2，也叫TP层）：这一层负责把UDS的大数据包，拆成CAN总线能一次发送的小数据包（单帧、多帧）。我个人习惯把这一层叫做“打包拆包层”。
- 数据链路层与物理层（CAN）：这就是CAN总线本身了，负责把数据变成电信号在线上跑。
我遇到过不少新手，拿着CAN工具直接发UDS报文，发现发不出去，或者收不到响应。其实就是没搞懂TP层。你发一个超过8字节的请求，TP层没配置好，数据就丢了。
核心理解：UDS是“内容”，CAN是“载体”，TP层是“搬运工”。三者缺一不可。
2.2 UDS服务分类
UDS定义了很多服务，每个服务都有一个唯一的ID（SID，Service Identifier）。为了好记，标准把它们分成了三大类。你想想看，一个ECU从出生到报废，无非就是这几件事：
- 诊断和通信管理类：这类服务负责建立诊断会话、控制ECU的通信行为。比如：
- 10 服务（诊断会话控制）：告诉ECU“我要开始诊断了”，ECU会切换到对应的诊断模式。
- 3E 服务（待机握手）：防止ECU因为长时间没收到诊断请求而自动退出诊断模式。我在项目中就吃过亏，没发3E，ECU自己睡着了，后面所有请求都石沉大海。
- 28 服务（通信控制）：可以临时关掉某些报文，比如刷写程序时关掉应用报文，防止干扰。
- 数据传输类：这是最常用的，用来读写ECU内部的数据。
- 22 服务（按标识符读取数据）：比如读VIN码、读软件版本号。
- 2E 服务（按标识符写入数据）：比如写配置参数。
- 23 服务（按地址读取内存）：这个更底层，直接读内存地址，刷写Bootloader时常用。
- 存储数据传输类：专门用来处理故障码（DTC）。
- 14 服务（清除诊断信息）：修完车后，清故障码用的。
- 19 服务（读取诊断信息）：读当前故障、历史故障、快照数据等。这个服务很复杂，子功能特别多。
我的小技巧：刚开始记不住SID没关系。你只要记住，10服务是“开门”，3E服务是“别关门”，22/2E是“读写数据”，19/14是“管故障码”。剩下的用到再查表。
2.3 UDS与OBD-II的区别
这个问题面试经常被问到。很多人把UDS和OBD-II搞混，其实它们完全是两码事。
| 对比项 | UDS (ISO 14229) | OBD-II (ISO 15031) |
|---|---|---|
| 目的 | 整车厂内部开发、售后诊断、产线刷写 | 法规要求的排放相关诊断 |
| 服务范围 | 非常广泛，几乎能控制ECU所有功能 | 很窄，只关注排放相关的系统 |
| 请求ID | 通常是功能寻址（0x7DF）或物理寻址（0x7xx） | 固定为0x7DF |
| 数据格式 | 灵活，可以自定义数据标识符（DID） | 固定，PID（参数ID）是标准定义的 |
| 安全性 | 有安全访问（27服务）和种子密钥机制 | 通常没有安全校验 |
说白了，OBD-II是“法律底线”，保证你的车排放达标就行。而UDS是“功能全集”，从刷写Bootloader到读取某个传感器的原始电压，都能干。我曾经在一个项目中，客户要求用OBD-II的协议去刷写程序，那根本行不通，因为OBD-II就没定义刷写服务。
避坑指南：千万不要在量产车的OBD接口上，用UDS的27服务（安全访问）去尝试解锁ECU。有些ECU会记录非法解锁尝试，次数多了直接锁死，只能返厂维修。我曾经见过一个同事，在测试车上玩脱了，最后只能换ECU。
2.4 UDS应用场景
UDS的应用场景非常广，我简单列几个最常见的：
- 产线刷写（EOL）：新车下线时，通过UDS把应用程序、标定数据刷进ECU。这时候用的主要是34服务（请求下载）、36服务（传输数据）、37服务（请求退出传输）。
- 售后诊断：车坏了进4S店，诊断仪通过UDS读取故障码、读取实时数据流、执行动作测试（比如驱动某个继电器吸合）。
- 远程诊断（OTA）：现在很多车支持远程升级。TSP后台通过车机，再通过UDS把升级包发给ECU。这里要注意，远程诊断对TP层的超时处理要求很高，网络一卡，会话就断了。
- 功能配置：比如根据车型配置，通过2E服务写入不同的参数，开启或关闭某些功能（比如自动泊车、座椅加热）。
嗯，这里我想多说一句。很多初学者觉得UDS就是发几个16进制的报文，没什么难的。但实际项目里，难点往往不在协议本身，而在“状态机管理”。比如，你必须在正确的会话状态下才能做安全访问，必须在安全访问解锁后才能刷写。顺序错了，ECU就会给你回一个否定响应（NRC，Negative Response Code）。
好了，这一章的内容就这些。UDS的架构、服务分类、和OBD-II的区别、以及应用场景，都是后续章节的基础。下一章，我们会深入CAN报文，看看UDS报文到底是怎么在CAN总线上“说话”的。