1.3 OBD-I到OBD-II——语言的第一次统一
1988年:加州,黄色烟雾,一个简单问题
你站在加州空气资源委员会(CARB)的会议室外面,手里揣着一份测试报告。报告上说,从1988年款的新车上强制安装的排放自诊断模块确实能检测氧传感器和三元催化器的劣化——但维修站读取这些故障码的工具覆盖率不足30%。因为每一家车厂都有自己的接口、自己的协议、自己的故障码含义。
CARB的技术官员面对一个问题:“我们法律条文说完了——车必须有排放自诊断功能——但没说这些功能怎么被读取。”
你如果强制车厂装自诊断模块,但不强制统一接口,会怎么样?车厂会照办——但他们会用自己的私有接口,只给自己的经销商修车。独立维修站买不起每家的专属诊断仪。消费者被锁定在授权维修网络里——修车费用居高不下。
法规做到了第一条——让车自己知道排放出了问题。但漏掉了第二条——让信息能传到任何一个维修站手里。这个洞必须补上。
OBD-I:每个人都搞了一套自己的接口
1991年,加州规定所有新售车辆必须装备OBD-I系统。但标准里只规定了“要有一个诊断连接器“——没规定连接器长什么样、用什么通信协议、故障码怎么编码。
于是一场轰轰烈烈的巴别塔工程开始了:
| 车厂 | 接口规格 | 故障码读取方式 |
|---|---|---|
| 通用(GM) | ALDL, 12针, 8192 baud UART | 短接端子A和B,灯闪码 |
| 福特(Ford) | MCU, 6针, PWM (J1850) | 模拟电压表或专用扫描仪 |
| 克莱斯勒(Chrysler) | SCI, 单针或6针, 7812 baud UART | 循环点火钥匙5次,灯闪码 |
| 丰田(Toyota) | DLC1/DLC2, 23针/17针, 多路复用(同一车两个位置:引擎舱/驾驶室) | 短接TE1和E1,灯闪码 |
| 本田(Honda) | 蓝色2针, 2针, 脉冲串 | 短接端子,LED闪码 |
| 日产(Nissan) | 灰色14针, 14针, 串行 | 手动进入诊断模式,ECU的LED闪码 |
每一个品牌不仅有不同的接口物理形状和引脚定义——连故障码的编码方式都不一样。GM的代码12=正常,13=氧传感器信号过慢;福特的自检代码却是两位数:11=系统通过,21=ECT传感器电压过低……技师面对一辆陌生品牌的车,连“正常“是什么代码都不知道。
更令人匪夷所思的是——有些车厂在同一款车型的不同年份——用的接口还不一样。1993款的克莱斯勒和1994款的底特律V6,同一个工厂出厂的两个引擎——诊断口引脚变了。
核心洞察:标准化的缺失不是技术能力的问题——是博弈的问题。每一个车厂都有能力设计自己的诊断协议。问题是——凭什么用你的不用我的?谁做的接口标准成本低谁赢——但胜利带来的不是统一,是碎片化。因为没有车厂有义务去设计一套和其他人兼容的东西——兼容是成本,收益不完全自己拿到。
一地鸡毛后,有人坐不住了
1994年,CARB的技术官员看着桌面上一排不同的诊断线和接头。市面上已经有了超过20种不同的汽车诊断接口——每种又对应着自己专属的诊断仪。一个独立修车行每年要花上万美元买各种品牌适配器和软件——而这钱最终变成维修费摊回消费者。
这一次,CARB不留情面。OBD-II(第二代车载诊断系统)——把诊断标准化写进了行政法规。
从1996年款开始,所有在美国销售的乘用车和轻卡必须满足:
- 统一的物理接口:SAE J1962定义的16针梯形DLC(Data Link Connector)
- 至少一种标准通信协议:ISO 9141-2 (K-Line)、SAE J1850 PWM、SAE J1850 VPW、或ISO 14230-4 (KWP2000)——但到后来,CAN成为实际唯一的强制选择
- 统一的故障码格式:P0xxx(动力总成)、C0xxx(底盘)、B0xxx(车身)、U0xxx(网络通信)——5位字母数字,每一位有明确的编码规则
- 统一的诊断请求模式:Mode 0x01~0x0A,定义了10种诊断功能
- 统一的MIL控制策略:什么故障亮灯、什么条件灭灯——检测和诊断周期的规则统一写入ISO标准
J1962:那个你至今在方向盘下面找到的16针梯形口
J1962标准规定的16针连接器是汽车诊断历史上最重要的物理接口标准。每一针的定义:
┌─────────────────────────────────┐
1 ║ 1 2 3 4 5 6 7 8 ║
9 ║ 9 10 11 12 13 14 15 16 ║
└─────────────────────────────────┘
Pin 2: J1850 Bus+ (PWM/VPW)
Pin 4: Chassis Ground
Pin 5: Signal Ground
Pin 6: CAN High (ISO 15765-4)
Pin 7: K-Line (ISO 9141-2 / ISO 14230-4)
Pin 10: J1850 Bus- (PWM only)
Pin 14: CAN Low (ISO 15765-4)
Pin 15: L-Line (ISO 9141-2 / ISO 14230-4, optional)
Pin 16: Battery Voltage (12V, permanent power)
剩下未分配的引脚,各车厂可以自定义。这就是标准的艺术——规定的是“不能冲突“的部分,开放的是“可以竞争“的部分。标准化的最高境界不是管束一切,是规定接口面上对所有人的最低保证。
为什么必须是16针?不是15针也不是17针?因为当年参与设计这个接口的时候,OEM需要适配多种通信协议——CAN、K-Line、J1850 PWM、J1850 VPW——每种占用两到三根线,16针刺针在有限的面板上刚好塞满。
为什么供电脚(pin 16)和地脚(pin 4/5)必须在这个固定位置?因为诊断仪取电靠着这两个引脚供电——如果10个诊断仪厂家的工具各有取的引脚——诊断接口就不能标准化——每一块插上是哪个引脚不确定。
核心洞察:一个标准接口的成功不取决于它有多少高级特性——取决于它的政治合法性和强制执行力。CARB有立法权,政府有罚则,强迫全体参与。但凡留下自愿选项,私有的接口永远比标准接口先出现。
OBD-II的10种诊断模式(Mode 0x01-0x0A)
OBD-II定义了10种标准诊断请求,每一种用一个字节的“MODE“码标识。这些Mode的编码规则是:请求Mode XX,肯定响应是Mode (XX+0x40)——和UDS在应用层的正响应SID偏移规则如出一辙。
| Mode | 名称 | 作用 |
|---|---|---|
| 0x01 | Request Current Powertrain Diagnostic Data | 读取当前动力总成数据(PID参数) |
| 0x02 | Request Powertrain Freeze Frame Data | 读取故障码发生时的冻结帧数据 |
| 0x03 | Request Emission-Related Diagnostic Trouble Codes | 请求所有已确认的排放相关DTC |
| 0x04 | Clear/Reset Emission-Related Diagnostic Information | 清除排放相关DTC及冻结帧、氧传感器监控结果 |
| 0x05 | Request Oxygen Sensor Monitoring Test Results | 请求氧传感器监控测试结果 |
| 0x06 | Request On-Board Monitoring Test Results for Specific Monitored Systems | 请求特定监控系统的连续/非连续监控结果 |
| 0x07 | Request Emission-Related DTCs Detected During Current or Last Completed Driving Cycle | 当前或上一个完成的驾驶循环中检测到的排放相关DTC |
| 0x08 | Request Control of On-Board System, Test or Component | 请求对车载系统的主动控制/测试(注:多数OEM保留给专属工具,极少在通用扫描仪上实现) |
| 0x09 | Request Vehicle Information | 请求车辆信息(VIN、标定ID、CVN校验和) |
| 0x0A | Request Emission-Related DTCs with Permanent Status | 请求带有永久状态的排放相关DTC(无法被清除的) |
Mode 0x01的核心参数叫PID(Parameter ID)——每个PID是一个字节的标识符,对应一个物理参数。例如PID 0x0C=发动机转速(256MSB+LSB)/4 rpm,PID 0x0D=车速(km/h),PID 0x05=冷却液温度(-40+scalereading)°C。
Mode 0x03的响应格式里——单个DTC编码为两个字节(而不是UDS的三个字节)。
| Byte | 含义 |
|---|---|
| Bits 7-6 | DTC分类代码(00=Powertrain, 01=Chassis, 10=Body, 11=Network) |
| Bits 5-0 | 前缀代码 |
| Byte 2 | 故障码主码+故障码后缀(低字节拆分) |
和UDS 0x19的三字节格式(B1=类别+前缀高位,B2=前缀低位+故障码高两位+后缀高位,B3=后缀低6位)相比,OBD-II字节编码空间有限但更容易计算。OBD-II的两个字节可以表达约4,096个独立故障码——比闪码时代的127个高两个数量级,比UDS的三字节表达少一个数量级但够排放用。
OBD-II奠定了什么,遗留了什么
OBD-II解决了三个最基础的问题:
- 物理接口统一——一个标准的16针端口,不再需要带一袋专属转接器
- 故障码编码统一——P/C/B/U四类字母前缀加上五位数字后缀,任何扫描仪“懂“这些码的含义
- 数据访问协议统一——10种Mode涵盖了排放诊断的核心流程
但OBD-II有三件事不碰:
- 非排放相关ECU的诊断——车身控制器、气囊控制器、仪表、中控显示屏、无钥匙系统、电动助力转向……这些完全不在OBD-II的管辖范围
- ECU的固件重刷——OBD-II只读数据、清除DTC、做主动测试,不允许写Flash
- 安全访问——OBD-II没有认证机制——任何拥有OBD-II扫描仪的人都能读任何参数、测试任何执行器
核心洞察:OBD-II的任务非常明确——确保排放系统的健康状况有人能看。它的边界划在排放相关功能上,不是它不想做更多——是当时没有政治和法规力量去推更广的标准化。法源驱动的标准从来不奢求一步登天:它追求的是可检测、可执行、可验证——这三样保证了,下一步才走得动。
故事的缺口:超过排放范围的诊断
记住:OBD-II只覆盖了排放相关的动力总成ECU——发动机控制模块(ECM)和传动控制模块(TCM)。但一辆2000年代的高端车已经有几十个独立ECU了:
ABS — 防抱死制动控制器
SRS — 安全气囊充气与传感诊断模块
BCM — 车身控制器(灯光、门窗、雨刮、座椅)
IC — 仪表组合(仪表盘、指示灯、蜂鸣器)
HVAC — 空调和暖风控制
PSCM — 电动助力转向
TPMS — 轮胎压力监测
RCDLR — 遥控无钥匙进入
PAM — 驻车辅助控制器(雷达/摄像头)
IPC — 仪表板显示
每一个ECU都有自己的故障码、自己的运行参数、自己的软件版本号——而且OBD-II一个都不管。
于是出现了第二个巴别塔——OEM专有诊断协议成倍增殖。大众用KWP1281(K-Line上的UART)、博世开发KWP2000(ISO 14230)、通用汽车在GMLAN上用GMW3110改造的诊断服务、福特用MS-CAN私有ID的UDS……
但这一次,有人提前看透了问题。汽车行业的通讯标准化组织——从国际标准化组织(ISO)到欧洲的AsAM、北美的SAE——开始着手一个野心勃勃的计划:把所有的诊断服务扩展成一套完整的、覆盖所有ECU的统一语言。 这个计划最终诞生的成果,叫做UDS(Unified Diagnostic Services,ISO 14229),而它的直接前身——KWP2000——已经在1999年埋下了大量概念种子。
本篇小结
- OBD-I的教训:只规定“必须有能力“,不规定“怎么传达“——等于没规定。接口碎片化的成本不是接口本身,是锁定了消费者的维修自由。
- OBD-II的统一是靠政治推力,不是靠市场自组织。CARB的立法权限和EPA的罚则保证了接口、故障码、通信协议的统一——汽车电子历史上最重要的标准化事件,导火索是洛杉矶盆地的一层黄霾。
- OBD-II的边界划在排放——排放之外的几十个ECU,是OBD-II的真空地带。UDS正是为了填补这个真空而生的。
- OBD-II模式码的正响应偏移(request+0x40=response)和PID编码哲学,被UDS完整继承并放大到26种服务——它们不是两个独立的协议,而是一棵传承树上分出的两根枝。
【下集预告】:OBD-II在排放这个封闭领域定下了规矩。但“排放之外“的真空地带怎么办?博世联合ISO给出的答案是KWP2000——第一个真正意义上的通用诊断协议。但KWP2000的设计DNA里藏了一个所有人都没意识到的缺陷——在CAN总线上跑,这个缺陷会被无限放大。解决这个缺陷的不是博世,而是ISO的工程师——他们在2006年完成了这一工作。