3. OBD通信协议详解：KWP2000与ISO 15765
好，咱们今天聊聊OBD通信协议里两个绕不开的老伙计——KWP2000和ISO 15765。说实话，我刚入行那会儿，面对这些协议栈也是一头雾水。但后来在项目里被它们“教育”了几次，才真正摸透了脾气。
KWP2000，全称是Keyword Protocol 2000，对应ISO 14230标准。它主要用在早期的车载诊断系统里，尤其是2008年之前的很多欧洲车。而ISO 15765，则是CAN总线上的OBD协议，现在几乎所有的车都在用。你想想看，一个是从K线时代过来的“老兵”，一个是CAN时代的“主力军”，咱们都得搞明白。
3.1 KWP2000的帧结构
KWP2000的通信，说白了就是基于K线的串行通信。它的帧结构，我个人习惯把它拆成三部分来看：
- 首字节（Header）：包含格式信息、目标地址、源地址。格式信息决定了后面跟几个字节。
- 数据字节（Data Bytes）：实际要传输的诊断数据，比如服务ID、参数等。
- 校验和（Checksum）：一个字节，用来保证数据没传错。
嗯，这里要注意，KWP2000的帧长度是可变的。最短的帧可能只有3个字节，长的能到几十个字节。我在项目中遇到过，有些老款ECU对帧长度特别敏感，发长了它直接不理你。
典型KWP2000帧格式示例：
| 首字节 (Fmt + Tgt + Src) | 数据字节 (Data) | 校验和 (CS) |
|--------------------------|-----------------|-------------|
| 0xC1 | 0x10 0x01 | 0xD3 |这里0xC1表示：格式=1（单帧），目标地址=0x01（ECU），源地址=0x01（诊断仪）。
3.2 KWP2000的寻址方式
KWP2000有两种寻址方式，这个我建议你记牢了，因为选错了ECU根本不响应。
- 物理寻址：一对一的通信。诊断仪直接指定某个ECU的地址。比如你只想读发动机ECU的数据，就用物理寻址。
- 功能寻址：一对多的广播。诊断仪发一个功能地址，所有支持该功能的ECU都会响应。比如你发“读取所有故障码”的功能寻址，所有ECU都会回你。
我曾经在测试时犯过一个低级错误——用功能寻址去读某个ECU的VIN码。结果所有ECU都回了，数据全混在一起，解析出来全是乱码。所以，记住：读特定数据用物理寻址，广播请求用功能寻址。
3.3 KWP2000的服务ID
服务ID，就是诊断命令的“指令码”。KWP2000定义了很多服务，但常用的就那么几个。我列个表给你看：
| 服务ID | 服务名称 | 说明 |
|---|---|---|
| 0x10 | 诊断会话控制 | 启动、切换诊断会话模式 |
| 0x11 | ECU复位 | 让ECU重启 |
| 0x22 | 读取数据标识符 | 读某个DID（数据ID）的值 |
| 0x23 | 读取内存地址 | 直接读ECU内存，慎用 |
| 0x2E | 写入数据标识符 | 写数据到ECU，比如刷写配置 |
| 0x31 | 例程控制 | 启动、停止ECU内部例程 |
| 0x3E | 测试器存在 | 保持诊断会话不超时 |
你看，0x3E这个服务特别不起眼，但特别重要。如果不定期发这个，ECU会认为诊断仪掉线了，自动退出诊断模式。我有个同事就因为这个，调试了一整天，最后发现是忘了发0x3E。
3.4 CAN总线上的OBD：ISO 15765
好了，聊完K线，咱们说说CAN总线上的OBD。ISO 15765，也叫CAN诊断协议。它把诊断数据封装在CAN帧里传输。说白了，就是把KWP2000那套东西，搬到了CAN总线上。
ISO 15765的帧格式，我建议你从两个层面去理解：
- CAN数据链路层：标准CAN帧，11位ID，数据场最多8个字节。
- 诊断应用层：在CAN数据场里，再封装诊断协议信息。
ISO 15765单帧格式示例：
CAN ID: 0x7DF (功能寻址请求)
数据场: [0x02] [0x01] [0x0D] [0x00] [0x00] [0x00] [0x00] [0x00]
| | |
| | +-- 服务ID: 0x0D (读取诊断故障码)
| +-- 子功能: 0x01 (请求当前故障码)
+-- 协议控制信息 (PCI): 0x02 表示单帧，数据长度2字节这里有个关键点：CAN ID的分配。ISO 15765定义了两种CAN ID：
- 功能寻址ID：0x7DF（请求），0x7E8~0x7EF（响应）。所有ECU都能收到。
- 物理寻址ID：0x7E0~0x7E7（请求），0x7E8~0x7EF（响应）。一对一通信。
我记得有一次，客户反馈说诊断仪连不上某个ECU。我抓了CAN总线一看，发现诊断仪发的CAN ID是0x7DF，但那个ECU只响应物理寻址。原来ECU的配置里，把功能寻址给关了。所以，遇到连不上的情况，先看看CAN ID对不对。
3.5 多帧传输：长数据的处理
当诊断数据超过8个字节时，就需要用到多帧传输了。ISO 15765定义了四种帧类型：
| 帧类型 | PCI字节 | 说明 |
|---|---|---|
| 单帧 (SF) | 0x00~0x07 | 数据长度≤7字节 |
| 首帧 (FF) | 0x10~0x1F | 多帧传输的第一帧，包含总数据长度 |
| 连续帧 (CF) | 0x20~0x2F | 后续数据帧，带序列号 |
| 流控帧 (FC) | 0x30~0x3F | 接收方控制发送方的节奏 |
多帧传输的过程，说白了就是“请求-流控-发送”的握手。发送方先发一个首帧，告诉接收方“我要发这么多数据”。接收方回一个流控帧，说“你可以发了，一次发几个，间隔多久”。然后发送方就按这个节奏发连续帧。
实战小技巧：
如果你在开发诊断工具，建议把流控帧的“块大小”和“间隔时间”设得保守一点。我曾经把块大小设成8，结果ECU处理不过来，直接丢帧了。后来改成4，就稳了。
3.6 两种协议的对比与选择
最后，我做个简单的对比，帮你理清思路：
| 特性 | KWP2000 (ISO 14230) | ISO 15765 (CAN诊断) |
|---|---|---|
| 物理层 | K线 (单线) | CAN总线 (双线差分) |
| 速率 | 10.4 kbps | 最高1 Mbps |
| 帧长度 | 可变，最长255字节 | 每帧最多8字节数据 |
| 寻址方式 | 物理/功能寻址 | 物理/功能寻址 (通过CAN ID) |
| 应用场景 | 老车型、低成本系统 | 现代车型、高速诊断 |
嗯，现在的新车基本都用ISO 15765了。但KWP2000在售后市场依然存在，尤其是那些老款欧洲车。我建议你两个都掌握，毕竟修车的时候，你永远不知道下一辆开进来的是什么车。
避坑指南：
我曾经在开发一个通用诊断工具时，默认用了ISO 15765的CAN ID去连一台2005年的宝马车。结果死活连不上。后来查资料才发现，那台车用的是KWP2000 over K线。所以，动手之前，先确认车型和协议版本，能省你半天时间。
好了，这一章的内容就到这儿。KWP2000和ISO 15765，一个是“老将”，一个是“新星”，但核心思想是一样的——通过标准化的协议，让诊断工具和ECU能“说上话”。下一章，咱们聊聊具体的诊断服务实现，比如怎么读故障码、怎么清故障码。到时候，我会拿实际项目里的代码给你看。