1. 诊断基础入门：汽车诊断协议概述

大家好，我是你们的老朋友。今天咱们正式开启《汽车诊断功能开发实战手册》的第一章。

说实话，每次带新人入门，我都要先问一个问题：你理解的汽车诊断，到底是什么？

很多人第一反应是「读故障码」。嗯，没错，但这只是冰山一角。真正的诊断，是ECU和诊断仪之间的一场「对话」。而这场对话，得有规矩——这就是诊断协议。

1.1 三大诊断协议：KWP2000、UDS、OBD-II

先聊聊这三个老熟人。我入行那会儿，KWP2000还是主流，后来UDS慢慢上位，现在基本是UDS的天下。OBD-II呢？它是个「法规定义」的东西，跟UDS有交集，但目的不同。

1.1.1 KWP2000（Keyword Protocol 2000）

KWP2000，全称是Keyword Protocol 2000。它最早是欧洲车厂用的，后来被ISO 14230标准化。

特点：

• 基于关键字（Keyword）握手建立通信
• 支持5 baud和fast初始化两种方式
• 报文长度固定，最大255字节
• 寻址方式：物理寻址和功能寻址

我记得刚做项目时，遇到一个老款大众的ECU，死活连不上。查了半天，发现是初始化方式搞错了——它用的是5 baud初始化，而我默认配了fast。嗯，这种坑，踩过一次就记住了。

1.1.2 UDS（Unified Diagnostic Services）

UDS，统一诊断服务，ISO 14229。说白了，它就是KWP2000的「升级版」。

核心优势：

• 服务ID（SID）统一，跨厂商兼容性好
• 支持CAN、LIN、FlexRay、以太网等多种总线
• 报文结构更灵活，支持多帧传输
• 会话层管理更完善（默认、扩展、编程三种会话）

我个人习惯把UDS比作「汽车界的HTTP协议」。你想想看，HTTP有GET、POST这些方法，UDS也有ReadDataByIdentifier、WriteDataByIdentifier这些服务。是不是很像？

UDS常用的服务ID，我列个表给大家：

SID（十六进制）	服务名称	用途
0x10	DiagnosticSessionControl	切换诊断会话
0x22	ReadDataByIdentifier	读取DID数据
0x2E	WriteDataByIdentifier	写入DID数据
0x31	RoutineControl	执行例程
0x19	ReadDTCInformation	读取故障码
0x14	ClearDiagnosticInformation	清除故障码

这里有个小技巧：0x10服务是「敲门砖」。你发任何诊断请求之前，必须先发0x10进入诊断会话。否则ECU会直接给你回一个NRC（Negative Response Code）0x78——requestCorrectlyReceived-ResponsePending。说白了就是「我收到了，但我不理你」。

1.1.3 OBD-II（On-Board Diagnostics II）

OBD-II是法规强制要求的诊断协议，ISO 15031。它的核心目的是排放相关。

OBD-II和UDS的区别：

• OBD-II的服务ID是固定的（如0x01读当前数据，0x03读故障码）
• OBD-II的数据格式是标准化的（如PID 0x0C是发动机转速）
• OBD-II只关注排放相关系统
• UDS覆盖整车所有ECU

我在项目中遇到过一种情况：客户要求同时支持UDS和OBD-II。嗯，这其实很常见。做法是：用同一个CAN ID，通过服务ID来区分。比如0x01~0x0A走OBD-II，0x10~0x3E走UDS。ECU收到报文后，先判断SID范围，再决定走哪套逻辑。

1.2 诊断系统架构

聊完协议，咱们看看整个诊断系统长什么样。

典型的诊断系统架构：

1. 诊断仪（Tester）：上位机，发送诊断请求
2. 通信链路：CAN/LIN/以太网等物理层
3. 网关（Gateway）：路由诊断报文到目标ECU
4. 目标ECU：执行诊断服务，返回响应

这里有个关键点：网关的角色。在整车网络中，诊断仪通常挂在OBD接口上，而OBD接口连的是网关。网关负责把诊断报文路由到对应的ECU。

举个例子：你想读ABS模块的故障码。诊断仪发0x19请求，网关收到后，发现目标地址是ABS的CAN ID，就把报文转发到ABS总线上。ABS ECU处理完，把响应发回网关，网关再转发给诊断仪。

1.3 ECU与诊断仪通信模型

最后，咱们看看ECU和诊断仪之间到底怎么「说话」的。

通信模型分三层：

• 应用层：UDS服务（如0x22读数据）
• 会话层：诊断会话管理（默认/扩展/编程）
• 传输层：CAN/LIN等总线传输

我画个简单的流程图（用文字描述）：

诊断仪发送：0x22 0xF1 0x90
    ↓
CAN总线传输：仲裁ID + 数据场
    ↓
ECU接收：解析CAN帧，提取UDS报文
    ↓
ECU处理：读取DID 0xF190的数据
    ↓
ECU响应：0x62 0xF1 0x90 + 数据
    ↓
CAN总线传输：返回给诊断仪

这里有个容易踩的坑：CAN帧的数据场最多8字节（CAN 2.0）。如果UDS报文超过8字节，就得用多帧传输。UDS的多帧传输机制叫「ISO-TP」（ISO 15765-2）。

再说说寻址方式。UDS支持两种：

• 物理寻址：点对点，发给特定ECU
• 功能寻址：广播，发给所有ECU

功能寻址常用于「一键唤醒所有ECU」或「同时读取多个ECU的版本信息」。但要注意：功能寻址的响应不能太多，否则总线会爆。我曾经在测试时，一个功能寻址请求下去，十几个ECU同时响应，CAN总线直接过载。嗯，从那以后，我每次用功能寻址都会加个延时。

小结

这一章咱们聊了：

• 三大诊断协议：KWP2000（老将）、UDS（主力）、OBD-II（法规）
• 诊断系统架构：诊断仪→网关→ECU
• 通信模型：应用层→会话层→传输层

下一章，咱们会深入UDS的会话管理，聊聊「默认会话」和「扩展会话」到底有什么区别。到时候我会分享一个真实项目中的「会话切换失败」案例，保证让你印象深刻。

好了，今天就到这儿。有问题欢迎在评论区留言，咱们下章见。