1. OBD协议基础：OBD-II标准概述、CAN总线基础、诊断协议简介

各位同学，咱们今天聊点实在的。OBD刷写与标定，说白了就是跟汽车ECU“对话”。你连它说什么都听不懂，怎么改？所以第一章，咱们先把地基打牢。

我个人习惯，讲技术之前先讲“为什么”。OBD-II标准，就是汽车诊断的通用语言。1996年以后的车，基本都支持。它的核心目的，是让维修人员用一个设备，就能读懂不同品牌车的故障码和数据流。嗯，这里要注意，OBD-II不只是个接口，它是一整套协议规范。

OBD-II标准概述

OBD-II标准定义了三个东西：硬件接口（那个16针的梯形插座）、信号协议（比如CAN、K线）、以及诊断消息格式。我在项目中遇到过，有些老车虽然也是OBD-II接口，但用的是ISO 9141协议，速度慢得让人抓狂。现在主流都是CAN了。

OBD-II的引脚定义，我建议你记住几个关键的：

• 引脚4： chassis ground（底盘地）
• 引脚5： signal ground（信号地）
• 引脚6： CAN High（CAN高线）
• 引脚14： CAN Low（CAN低线）
• 引脚16： 电池正极（常电）

你想想看，如果CAN High和CAN Low接反了，总线根本不通。我曾经被这个坑过，排查了半天，结果发现是线序错了。

CAN总线基础

CAN总线，全称Controller Area Network。它为什么在汽车里这么流行？说白了，就是抗干扰能力强，实时性好。每个ECU都挂在同一条总线上，谁想说话，谁就发消息。

CAN总线的物理层，用的是差分信号。CAN High和CAN Low的电压差，决定了逻辑“0”还是“1”。显性电平（逻辑0）时，CAN High比CAN Low高2V左右；隐性电平（逻辑1）时，两者电压接近。

我记得刚接触CAN时，总搞不清ID的优先级。其实很简单：ID值越小，优先级越高。总线仲裁时，谁先发显性位，谁就赢得总线控制权。

诊断协议简介

有了CAN总线这个“高速公路”，还得有“交通规则”。这就是诊断协议干的事。咱们主要讲两个：ISO 15765和ISO 14229。

ISO 15765：网络层协议

ISO 15765，也叫CAN诊断。它定义了如何在CAN总线上传输诊断消息。因为CAN帧一次最多只能传8字节数据，而诊断消息可能很长，所以需要分包和重组。

ISO 15765有四种帧类型：

帧类型	用途	特点
单帧（SF）	数据长度≤7字节	一帧搞定
首帧（FF）	数据长度＞7字节	包含总长度信息
连续帧（CF）	后续数据	带序列号
流控帧（FC）	接收方控制发送节奏	告诉发送方“慢点”或“继续”

为什么会这样设计？你想想看，如果ECU一下子收到几十个字节，它可能处理不过来。流控帧就是用来做流量控制的。我曾经调试一个刷写工具，发现总是丢包，后来发现是流控帧的间隔时间设得太短了。

ISO 14229：应用层协议

ISO 14229，也叫UDS（Unified Diagnostic Services）。它定义了诊断服务的具体内容。比如你想读故障码，就用0x19服务；你想写数据，就用0x2E服务。

UDS的请求和响应格式很固定：

请求： SID + 子功能 + 数据
响应： SID+0x40 + 子功能 + 数据
否定响应： 0x7F + SID + NRC（否定响应码）

举个例子，读取ECU的VIN码：

请求： 22 F1 90
响应： 62 F1 90 + VIN码数据

这里0x22是“按标识符读取数据”的服务，F1 90是VIN码的DID（数据标识符）。

小结

这一章咱们讲了OBD-II的硬件基础、CAN总线的帧结构、以及ISO 15765和ISO 14229这两个核心协议。说白了，OBD刷写就是：用CAN总线发UDS消息，通过ISO 15765打包，让ECU执行各种诊断服务。

下一章，咱们会深入讲UDS的会话管理和安全访问。嗯，那才是真正开始“动手”的时候。