第4章 OBD诊断服务（上）

4、OBD诊断服务（上）：模式$01、$02、$03

好，咱们今天正式进入OBD诊断服务的核心部分。说实话，前面讲的那些协议层、物理层的东西，都是铺垫。真正跟故障打交道，就是从这几个模式开始的。我个人习惯把模式$01到$03称为“三板斧”，你把这几个玩熟了，80%的车辆健康问题都能摸到门道。

模式$01，说白了就是“实时快照”。你发一个请求过去，ECU（发动机控制单元）会把它当前能采集到的所有传感器数据都吐出来。比如发动机转速、车速、冷却液温度、氧传感器电压等等。

它的PID（参数ID）结构是这样的：

请求格式： 01 + PID
例如： 01 0C  （请求发动机转速）
响应格式： 41 + PID + 数据字节
例如： 41 0C 1A F8  （转速 = (0x1A * 256 + 0xF8) / 4 = 1722 RPM）

嗯，这里要注意一个坑。很多刚入行的朋友以为发个01就能拿到所有数据，其实不是的。你得一个一个PID去问。比如你要看转速，就发01 0C；要看车速，就发01 0D。ECU不会一次性把所有数据都告诉你，它没那么大方。

我的小技巧： 在实际项目中，我习惯先发一个01 00去获取“支持的PID列表”。这样你就知道这辆车能读到哪些数据，避免后面发一堆无效请求浪费时间。

我在项目中遇到过一辆车，读转速总是返回0。折腾了半天，发现是CAN总线上的终端电阻坏了，导致信号反射干扰。你看，有时候问题不在协议本身，而在物理层。

模式$02，这个就有点意思了。它相当于ECU的“黑匣子”。当某个故障码被记录时，ECU会把当时的车辆状态“拍一张照片”存下来。这个照片就是冻结帧。

为什么需要冻结帧？

你想想看，故障码只能告诉你“哪里坏了”，但没法告诉你“当时发生了什么”。比如一个氧传感器故障码，你光看码不知道是电压过高还是过低，也不知道当时发动机转速是多少。冻结帧就能把这些信息还原出来。

请求格式： 02 + PID
例如： 02 0C  （请求冻结帧中的发动机转速）
响应格式： 42 + PID + 数据字节
例如： 42 0C 1A F8

注意，模式$02的PID和模式$01是通用的。也就是说，你能在模式$01里读到的数据，在冻结帧里也能读到，只不过冻结帧里存的是“事发当时”的值。

避坑指南： 我曾经遇到过一个问题：有些ECU只保存一个冻结帧，也就是最近一次故障发生时的数据。如果你清除了故障码，冻结帧也可能被清掉。所以，诊断时一定要先读冻结帧，再清码。顺序搞反了，数据就没了。

我个人习惯在诊断流程中，只要看到有故障码，第一件事就是读模式$02。先把现场保护起来，再慢慢分析。这就像警察办案，先封锁现场，再找线索。

模式$03，这个最简单，也最常用。它就是用来读取当前ECU里存储的所有排放相关故障码。

请求和响应格式：

请求： 03
响应： 43 + 故障码数量 + 故障码列表
例如： 43 01 01 03  （表示有1个故障码，码为P0103）

故障码的编码规则大家应该都熟悉了：P代表动力系统，B代表车身，C代表底盘，U代表网络通信。后面四位数字，第一位表示故障类型（0-3），后三位是具体编号。

这里有个细节：模式$03只返回“当前存在的”故障码。那些历史故障码、间歇性故障码，它是不管的。如果你想看所有码，包括历史的，得用模式$07或$0A，这个后面会讲到。

  实战经验： 我见过不少维修师傅，一上来就清码，清完发现故障灯还亮，又回来读码。其实，模式$03返回的故障码数量，如果大于0，说明故障当前是存在的。你清码只是把ECU里的记录清了，但故障本身没解决，ECU很快又会重新报码。所以，先读码，再修车，最后清码验证，这个顺序不能乱。

模式	功能	典型应用场景	注意事项
$01	实时数据	监控发动机运行状态，如转速、水温	需要逐个PID请求，先读支持列表
$02	冻结帧数据	分析故障发生时的车辆状态	清码前务必先读，否则数据丢失
$03	排放故障码	读取当前存在的故障码	只返回当前故障，历史码需用其他模式

好了，这三个模式是OBD诊断的基石。你把这几个玩透了，后面那些模式$04、$05、$06什么的，学起来就快多了。说白了，OBD诊断就是“问-答”的游戏，你问对了问题，ECU就会给你答案。下一节我们继续讲模式$04到$06，到时候再聊。