第2章诊断基础与标准协议

第2章：诊断基础与标准协议

各位同学，大家好。今天我们聊聊诊断的基础。说白了，就是车坏了，你怎么跟它“对话”。

我刚开始做自动驾驶诊断那会儿，最头疼的就是协议太多。CAN、CAN FD、DoIP，还有一堆标准号。别急，我们一个一个捋清楚。

2.1 UDS（ISO 14229）基础

UDS，全称是 Unified Diagnostic Services。它是诊断的“普通话”。不管哪个厂家，只要支持UDS，大家沟通起来就方便了。

我个人习惯把UDS理解成一套“指令集”。你发一个请求，它回一个响应。就这么简单。

核心概念：

服务ID（SID）：每条指令的编号。比如0x10是“诊断会话控制”，0x22是“读取数据”。
子功能：有些服务还有细分。比如0x10下面有0x01（默认会话）、0x02（编程会话）、0x03（扩展会话）。
肯定响应：正常情况，ECU会回复“SID + 0x40”。比如你发0x22，它回0x62。
否定响应：出错了，回复0x7F + 你发的SID + 错误码。

举个例子。你想读取ECU的VIN码。发送的报文是这样的：

请求：02 22 F1 90
解释：
02 - 数据长度（2字节）
22 - 服务ID（读取数据）
F1 90 - 数据标识符（VIN码的ID）

ECU回复：

响应：06 62 F1 90 4C 53 56 38 30 31
解释：
06 - 数据长度
62 - 肯定响应（22+40）
F1 90 - 数据标识符
4C 53 56 38 30 31 - 数据内容（"LSV801"）

嗯，这里要注意。UDS的请求和响应都有固定的格式。你发错了，ECU直接不理你。我曾经在项目里遇到过，一个同事把长度字段写错了，结果ECU一直不回。排查了半天才发现是长度不对。

我的小技巧：

刚开始学UDS，别死记硬背。先记住几个常用的服务ID：0x10（会话控制）、0x22（读取数据）、0x2E（写入数据）、0x19（读取故障码）。其他的用到再查。

2.2 OBD-II标准

OBD-II，车载诊断系统第二代。它跟UDS什么关系？

说白了，OBD-II是“法规要求”，UDS是“实现方式”。OBD-II规定了必须诊断哪些项目，比如排放相关的。UDS规定了怎么去诊断。

OBD-II有几个关键点：

强制要求：所有在售车辆必须支持。主要是排放相关。
标准协议：早期用ISO 9141、ISO 14230（KWP2000），现在主流是ISO 15765（CAN上的OBD）。
诊断座：标准的16针OBD接口。DLC（数据链路连接器）。

OBD-II的请求格式跟UDS不太一样。它用的是“模式（Mode）”和“参数ID（PID）”。比如：

请求：01 0D
解释：
01 - 模式1（显示当前数据）
0D - PID（车速）

响应：41 0D 64
解释：
41 - 模式1的响应
0D - PID
64 - 车速数据（0x64 = 100 km/h）

你想想看，OBD-II其实更简单。它只关心几个固定的参数。但UDS更灵活，可以自定义数据标识符。

避坑指南：

我曾经在测试时发现，有些ECU对OBD-II请求的响应很慢。后来查了资料才知道，OBD-II的优先级其实不高。ECU会优先处理UDS请求。所以，如果你发现OBD-II响应超时，别急着怀疑硬件，先看看是不是UDS请求太频繁了。

2.3 CAN/CAN FD总线诊断

CAN总线，老熟人了。自动驾驶里，CAN还是主力。但CAN FD（灵活数据速率）也越来越多了。

为什么要有CAN FD？

原因很简单。CAN总线一帧最多传8字节数据。对于诊断来说，有时候不够用。比如你要刷写一个固件，一帧8字节，得传几万次。太慢了。

CAN FD把数据长度扩展到了64字节。速率也从500kbps提升到了2Mbps甚至更高。

诊断报文在CAN/CAN FD上的格式是这样的：

CAN ID: 0x7DF（功能寻址）或 0x7E0（物理寻址）
数据：PCI + SID + 数据

PCI（协议控制信息）：
- 单帧（SF）：长度 <= 7字节
- 首帧（FF）：长度 > 7字节，包含总长度
- 连续帧（CF）：后续数据
- 流控帧（FC）：控制发送节奏

举个例子。你要发送一个UDS请求，数据长度是5字节。用CAN发送：

CAN ID: 0x7E0
数据：02 22 F1 90 00
解释：
02 - PCI（单帧，长度2）
22 - SID
F1 90 - 数据标识符
00 - 填充字节

如果数据长度超过7字节，就得用多帧传输了。先发首帧，再发连续帧。ECU收到首帧后，会回复流控帧，告诉你可以继续发了。

关键区别：

特性	CAN	CAN FD
最大数据长度	8字节	64字节
最大速率	1 Mbps	8 Mbps（数据段）
兼容性	所有ECU支持	需要硬件支持

我个人建议，新项目尽量上CAN FD。虽然硬件成本高一点，但诊断效率提升明显。尤其是刷写固件的时候，能省不少时间。

2.4 DoIP协议入门

DoIP，Diagnostic over Internet Protocol。说白了，就是用以太网做诊断。

为什么需要DoIP？

原因有两个。第一，CAN/CAN FD的带宽还是不够。自动驾驶里，传感器数据量巨大，诊断也需要传大量数据。第二，远程诊断的需求。你想想看，车在用户手里，工程师在办公室，怎么诊断？用DoIP，通过4G/5G网络，远程就能搞定。

DoIP的协议栈是这样的：

物理层：100BASE-TX（百兆）或1000BASE-T（千兆）
传输层：TCP/UDP
网络层：IPv4/IPv6
应用层：UDS over DoIP

DoIP的报文格式：

DoIP头部（8字节）：
- 协议版本（1字节）：0x02
- 反向协议版本（1字节）：0xFD
- 负载类型（2字节）：0x8001（诊断消息）
- 负载长度（4字节）：后续数据长度

UDS数据：
- 源地址（2字节）：发送方逻辑地址
- 目标地址（2字节）：接收方逻辑地址
- UDS请求/响应

举个例子。用DoIP发送UDS请求：

DoIP头部：02 FD 80 01 00 00 00 07
UDS数据：0E 00 00 00 00 02 22 F1 90
解释：
02 FD - 协议版本
80 01 - 负载类型（诊断消息）
00 00 00 07 - 负载长度（7字节）
0E 00 - 源地址（0E00 = 诊断仪）
00 00 - 目标地址（0000 = ECU）
02 - PCI
22 - SID
F1 90 - 数据标识符

我的经验：

DoIP调试时，最容易出问题的是网络配置。IP地址、端口号、逻辑地址，一个不对就连不上。我建议先用Wireshark抓包，看看DoIP的“车辆声明”报文有没有发出来。如果没发，说明ECU的网络层有问题。

小结

这一章我们讲了四个核心内容：

UDS：诊断的“普通话”，用服务ID和子功能来通信。
OBD-II：法规要求的诊断标准，用模式和PID。
CAN/CAN FD：诊断的物理层和传输层，CAN FD效率更高。
DoIP：基于以太网的诊断，适合大数据量和远程诊断。

嗯，内容不少。但别急，后面我们会一个一个深入。下一章，我们专门讲UDS的会话控制和安全访问。到时候，你会看到这些协议是怎么配合工作的。

记住，诊断不是背协议，而是理解“车”和“人”怎么对话。你掌握了这个思路，后面就顺了。

📚 课程目录