2、OBD-II标准详解：OBD-II起源、PIDs定义、强制要求与协议类型
好，咱们进入第二讲。这一章我打算把OBD-II这个标准彻底掰开揉碎了讲清楚。很多刚入行的朋友觉得OBD-II就是那个16针的插座，插上诊断仪就能读故障码。其实没那么简单。OBD-II背后是一整套从法规到物理层的完整体系。我个人习惯是，先搞清楚它为什么来，再搞懂它规定了什么，最后再看它怎么实现。
2.1 OBD-II的起源：从加州空气资源委员会说起
OBD-II的诞生，说白了是被环保逼出来的。上世纪80年代，美国加州空气资源委员会（CARB）发现汽车排放超标太严重了。他们想了个办法：让车自己监控排放系统，一旦有问题就亮灯提醒车主去修。这就是OBD-I（1988年）。
但OBD-I有个大问题——各厂家各玩各的。诊断接口不一样，协议不一样，连故障码含义都不一样。修车师傅得备十几套诊断设备，你说这多折腾？
所以到了1994年，美国环保署（EPA）和CARB联合推出了OBD-II。核心目标就一个：标准化。所有在北美销售的车辆，必须用统一的诊断接口、统一的通信协议、统一的故障码定义。嗯，这里要注意，OBD-II真正强制实施是从1996年款车型开始的。我在项目中遇到过一台1995年的老车，接口明明是16针，但协议还是OBD-I的，差点被坑。
关键时间节点：
- 1988年：OBD-I 推出（加州率先实施）
- 1994年：OBD-II 标准发布
- 1996年：OBD-II 在北美全面强制实施
- 2001年：欧盟强制实施EOBD（基本等同于OBD-II）
- 2005年：中国开始参照OBD-II制定国标
2.2 PIDs定义：诊断数据的“字典”
OBD-II最核心的设计之一，就是PIDs（Parameter IDs，参数标识符）。你可以把它理解成一本字典。诊断仪问“发动机转速是多少？”，ECU查字典找到转速对应的PID，然后把数据返回。
每个PID用一个字节（0x00-0xFF）来标识。比如：
- 0x0C：发动机转速（RPM）
- 0x0D：车速（km/h）
- 0x05：发动机冷却液温度
- 0x10：空气流量（MAF）
- 0x2F：燃油液位（%）
我刚开始做诊断开发时，最头疼的就是PID的编码格式。每个PID返回的数据长度和换算公式都不一样。比如转速PID 0x0C，返回两个字节A和B，实际转速 = (A*256 + B) / 4。你想想看，如果换算公式搞错了，读出来的转速能差好几千转。
避坑指南：我曾经在某个项目里，把车速PID 0x0D的换算公式写错了。标准公式是车速 = 返回字节（km/h），我误写成了乘以0.6214（转英里）。结果路试时仪表盘显示120km/h，诊断仪读出来只有74mph。测试工程师追着我问了一下午……从那以后，我每次写PID解析代码，都会先对照SAE J1979标准文档核对一遍公式。
OBD-II标准定义了约60个标准PID（0x00-0x3F），其中0x00是个特殊PID——它返回的是车辆支持哪些PID的位掩码。举个例子，你发请求读PID 0x00，ECU会返回4个字节，每个bit代表一个PID是否支持。这样诊断仪就能动态发现车辆的能力，不用硬编码。
标准PID之外，还有扩展PID（0x40-0xFF）。这部分各厂家可以自定义。比如大众的0x4A是进气温度，福特的0x4C是涡轮增压压力。嗯，这里要注意，扩展PID没有统一标准，换辆车可能就不一样了。
2.3 强制要求：哪些是必须实现的？
OBD-II对车辆有明确的强制要求。不是所有PID都得实现，但有一组“核心PID”是必须支持的。我列个表，大家一目了然：
| PID | 参数名称 | 强制要求 |
|---|---|---|
| 0x00 | 支持的PID列表（01-20） | 强制 |
| 0x01 | 监控状态（MIL灯状态、故障码数量） | 强制 |
| 0x04 | 计算负荷值 | 强制 |
| 0x05 | 发动机冷却液温度 | 强制 |
| 0x0C | 发动机转速 | 强制 |
| 0x0D | 车速 | 强制 |
| 0x0E | 点火正时提前角 | 强制 |
| 0x0F | 进气温度 | 强制 |
| 0x10 | 空气流量 | 强制 |
| 0x11 | 节气门位置 | 强制 |
除了PID，OBD-II还强制要求：
- MIL灯（故障指示灯）：排放相关故障时必须点亮
- 故障码存储：至少存储5个排放相关的故障码
- 冻结帧数据：发生故障时，记录当时的工况数据（转速、车速、温度等）
- 监控就绪状态：每个排放监控器（如催化器、氧传感器）是否完成自检
说白了，OBD-II强制要求的不是“你能读多少数据”，而是“你能监控排放系统是否正常工作”。这是法规的初衷，千万别忘了。
2.4 协议类型：五种物理层，一个应用层
OBD-II最让人眼花缭乱的地方，就是它支持五种不同的物理层协议。我当年刚入行时，光区分这五种协议就花了不少时间。咱们一个一个说：
- SAE J1850 PWM（脉冲宽度调制）：福特和部分美系车在用。41.6 kbps，两条线（总线+和总线-）。
- SAE J1850 VPW（可变脉冲宽度）：通用汽车在用。10.4 kbps，单线。
- ISO 9141-2：欧洲车和部分亚洲车在用。低速（5 baud init），单线或双线。
- ISO 14230 KWP2000（关键字协议2000）：ISO 9141-2的升级版。支持更快的初始化速度和更多功能。
- ISO 15765 CAN（控制器局域网）：2008年以后的新车几乎全用这个。250 kbps或500 kbps，双线。
你可能会问：为什么搞这么多种？说白了，历史原因。各厂家在OBD-II标准出台前都有自己的诊断协议，谁也不愿意放弃自己的技术积累。最后妥协的结果就是：应用层统一（PIDs、故障码格式等），物理层各玩各的。
重要提醒：从2008年开始，美国EPA要求所有新车必须支持CAN协议（ISO 15765）。所以现在市面上的车，90%以上都是CAN。但老车（2008年以前）还是可能遇到J1850或KWP2000。我建议做诊断工具的朋友，至少支持CAN和KWP2000两种协议，基本能覆盖95%的车型。
这里有个小技巧：怎么快速判断一辆车用的是什么协议？看诊断接口（DLC）的引脚。标准16针接口中：
- 引脚2：J1850 总线+
- 引脚6：CAN 高
- 引脚7：ISO 9141-2 / KWP2000 K线
- 引脚10：J1850 总线-
- 引脚14：CAN 低
- 引脚15：ISO 9141-2 / KWP2000 L线
用万用表量一下引脚电压，基本就能判断。CAN高和CAN低在空闲时是2.5V左右，J1850总线+是7V左右，K线是12V左右。嗯，这个方法我在现场排查时用过无数次，百试百灵。
最后说一句，OBD-II虽然叫“标准”，但它只定义了诊断的“最小公共集”。各厂家在OBD-II之上还有自己的增强诊断协议（比如UDS）。你想想看，OBD-II能读发动机转速，但读不了变速箱油温——因为变速箱油温不是排放相关的参数。所以做实际项目时，OBD-II只是起点，不是终点。
个人经验：我建议初学者先吃透OBD-II的CAN协议版本（ISO 15765）。因为CAN是目前的主流，而且UDS诊断也是基于CAN的。把OBD-II的CAN协议搞明白了，后面学UDS会轻松很多。我曾经带过一个新人，上来就啃J1850，结果发现市面上根本找不到支持J1850的新车，白白浪费了两个月时间。