2、OBD协议基础：OBD-II标准、OBD引脚定义、OBD通信协议（CAN/KWP2000）、OBD服务模式
各位同学，欢迎来到第二章。上一章我们聊了UDS的整体框架，这一章咱们得把地基打牢——OBD协议。说实话，很多工程师一上来就扎进UDS的细节里，结果连OBD的引脚定义都搞不清楚，最后在台架上测了半天，发现线都接错了。嗯，这种事我见过不止一次。
OBD，全称是车载诊断系统。它最早是为了监控排放而生的。你想想看，一辆车如果排放超标，OBD系统必须能检测到，并且亮起故障灯。这就是OBD-II标准的初衷。我个人习惯把OBD-II看作是UDS的「前辈」，虽然UDS功能更强大，但OBD-II的很多基础概念，至今仍在沿用。
2.1 OBD-II标准
OBD-II是1996年之后在美国强制推行的标准。它的核心思想是统一。统一什么？统一诊断接口、统一通信协议、统一故障码定义。说白了，就是让所有车厂都按一个规矩来。
我记得有一次，一个刚入行的同事问我：「为什么OBD-II的故障码P0101，不管在丰田还是大众车上，含义都一样？」我告诉他，这就是OBD-II标准的力量。它定义了五个主要的标准：
- ISO 15031：通信协议和诊断服务的基础
- SAE J1979：定义了OBD-II的服务模式（Mode）
- SAE J2012：故障码定义（DTC）
- SAE J1962：诊断连接器（就是我们常说的OBD接口）
- ISO 15765：基于CAN总线的诊断协议
这里要特别提一下，OBD-II标准虽然统一了接口和协议，但它并没有强制规定所有车都必须用CAN总线。早期的车还有用K线（KWP2000）的。这一点，我们在后面会详细说。
重要提示：OBD-II标准中，诊断服务是通过「模式（Mode）」来区分的。比如Mode 01是请求当前数据，Mode 03是读取故障码。这和UDS的「服务ID（SID）」概念很像，但OBD-II的模式编号是固定的，而UDS的服务ID更灵活。
2.2 OBD引脚定义
说到引脚定义，我建议你最好把这张图刻在脑子里。OBD-II诊断接口是标准的16针D型接口，但并不是所有引脚都用上了。咱们来看看实际项目中常用的几个：
| 引脚号 | 信号定义 | 说明 |
|---|---|---|
| 4 | 底盘地（Chassis Ground） | 直接连到车身地 |
| 5 | 信号地（Signal Ground） | ECU的参考地 |
| 6 | CAN High（CAN_H） | CAN总线的高电平线 |
| 7 | K线（ISO 9141-2） | 用于KWP2000协议 |
| 14 | CAN Low（CAN_L） | CAN总线的低电平线 |
| 15 | L线（ISO 9141-2） | KWP2000的辅助线 |
| 16 | 电池正极（Battery +） | 常电，12V或24V |
这里有个坑，我曾经踩过。有一次在台架上测试，怎么都连不上ECU，折腾了半天才发现，是引脚4和引脚5没有共地。你想想看，如果底盘地和信号地之间有电位差，CAN信号根本没法正常传输。所以，我个人的习惯是，拿到一个新项目，第一件事就是用万用表量一下引脚4和引脚5之间的电阻，确保它们导通。
警告：引脚16是常电，直接连到蓄电池正极。有些车型的OBD接口在熄火后仍然有电。如果你在车上长时间插着诊断设备，记得确认设备有没有休眠功能，否则可能会把电瓶耗光。我曾经就因为这个，被客户骂了一顿。
2.3 OBD通信协议：CAN vs KWP2000
OBD-II支持的通信协议有好几种，但实际项目中，最常见的就是CAN和KWP2000。咱们一个一个说。
2.3.1 CAN总线
CAN总线，全称是控制器局域网。它现在是汽车诊断的绝对主流。为什么？因为它速度快、抗干扰能力强、而且支持多节点通信。OBD-II中使用的CAN协议，通常是ISO 15765-4定义的，波特率一般是250kbps或500kbps。
我记得刚入行那会儿，带我的老师傅跟我说：「CAN总线就是汽车的神经系统。」这话一点不假。在OBD诊断中，CAN总线负责传输诊断请求和响应。比如你发一个Mode 01的请求，ECU会通过CAN总线返回当前的车速、转速、水温等数据。
CAN总线的物理层很简单，就是两根线：CAN_H和CAN_L。它们之间的电压差决定了总线状态。显性电平（Dominant）对应逻辑0，隐性电平（Recessive）对应逻辑1。嗯，这里要注意，CAN总线是差分信号，所以抗干扰能力特别强。
// 一个简单的OBD请求示例（基于CAN）
// 请求Mode 01，PID 0x0C（发动机转速）
// CAN ID: 0x7DF（广播地址）
// 数据: 02 01 0C 00 00 00 00 00
// 发送CAN帧
CAN_SendFrame(0x7DF, 0x08, "02 01 0C 00 00 00 00 00");
// 等待ECU响应
// 响应CAN ID: 0x7E8
// 数据: 04 41 0C 0F A0 00 00 00
// 解析：发动机转速 = (0x0F * 256 + 0xA0) / 4 = 1000 RPM小技巧：在实际项目中，我建议你使用CAN分析仪（比如PCAN或Kvaser）来抓取总线上的原始数据。这样你可以直观地看到诊断请求和响应的时序。我曾经用这个方法，帮一个客户找到了ECU响应超时的根本原因——原来是CAN总线上的终端电阻坏了。
2.3.2 KWP2000
KWP2000，全称是Keyword Protocol 2000。它是在CAN普及之前，最常用的OBD诊断协议。KWP2000基于K线（ISO 9141-2）通信，速度比较慢，一般只有10.4kbps。你想想看，和CAN的500kbps比起来，简直是龟速。
KWP2000的通信方式很简单，就是一根K线（引脚7）负责收发数据，L线（引脚15）用来唤醒ECU。它的数据格式是字节流，没有CAN那样的帧结构。所以，KWP2000的协议解析相对简单，但缺点也很明显——速度慢、抗干扰能力差。
我记得有一次，在维修一辆老款大众车时，用的就是KWP2000协议。那车是2005年产的，ECU只支持K线。我拿着诊断仪，等了半天才读到故障码。嗯，那时候我就想，还是CAN好。
不过，KWP2000并没有完全消失。在一些商用车和农用机械上，你仍然能看到它的身影。所以，作为诊断工程师，你至少要知道它的存在。
2.4 OBD服务模式
OBD-II的服务模式，说白了就是一组标准化的诊断命令。每个模式对应一个功能。咱们来看看最常用的几个：
| 模式（Mode） | 功能描述 | 常见用途 |
|---|---|---|
| Mode 01 | 请求当前动力系统数据 | 读取车速、转速、水温、氧传感器等 |
| Mode 02 | 请求冻结帧数据 | 读取故障发生时的快照数据 |
| Mode 03 | 读取故障码 | 获取当前存储的DTC |
| Mode 04 | 清除故障码 | 清除DTC和相关数据 |
| Mode 05 | 请求氧传感器测试结果 | 仅用于CAN总线 |
| Mode 06 | 请求非连续监控测试结果 | 读取催化器、EGR等系统的监控结果 |
| Mode 07 | 请求待定故障码 | 读取尚未确认的故障 |
| Mode 08 | 请求控制车载系统 | 执行某些部件的测试（如喷油器） |
| Mode 09 | 请求车辆信息 | 读取VIN、软件版本等 |
| Mode 0A | 请求永久故障码 | 读取不可清除的DTC |
这里我重点说一下Mode 01。它是我们在项目中最常用的模式。每个Mode 01请求后面，都会跟一个PID（参数ID）。比如，PID 0x0C是发动机转速，PID 0x0D是车速。你想想看，如果你要开发一个OBD诊断仪，Mode 01就是你的核心功能。
举个例子，假设你要读取发动机转速：
// 请求：Mode 01, PID 0x0C
// 发送：02 01 0C 00 00 00 00 00
// 响应：04 41 0C 0F A0 00 00 00
// 解析响应：
// 第一个字节04：表示后续有4个有效数据
// 第二个字节41：表示这是Mode 01的响应（0x40 + 0x01）
// 第三个字节0C：表示PID是0x0C
// 第四、五字节0F A0：表示发动机转速的原始值
// 转速计算公式：(A * 256 + B) / 4
// 所以转速 = (0x0F * 256 + 0xA0) / 4 = (15 * 256 + 160) / 4 = 1000 RPM重要提示：OBD-II的响应格式中，第二个字节是请求模式加上0x40。比如你请求Mode 01，响应就是0x41；请求Mode 03，响应就是0x43。这个规律在解析数据时非常有用。我个人习惯在代码里写一个宏定义，直接做这个转换。
好了，这一章的内容就到这里。OBD协议基础是诊断工程师的必修课。不管你以后是做UDS开发，还是做OBD诊断仪，这些知识都会反复用到。下一章，我们会正式进入UDS协议的核心——服务ID和子功能。到时候，你会发现，OBD和UDS其实有很多相通的地方。