汽车诊断协议，（K线/CAN总线、kwp2000、ISO14230、ISO1575...）

相信像我这样的小白第一次接触汽车诊断协议肯定有点懵逼，什么鬼kwp2000，那什么又是ISO-14230，ISO-15765，ISO-14229，UDS，UDSonCAN？？？它们到底是什么关系，还有什么又是基于K线的KWP2000，基于CAN的KWP2000？？？嗯，慢慢来，一定不要混淆这些协议，首先对这些协议进行初步认识：

一、初步认识

KWP 2000和IS0-14230
在汽车故障诊断领域，针对诊断设备和汽车ECU之间的数据交换，最早欧洲出现了一种标准诊断协议KWP2000（Keyword Protocol 2000），又名关键字协议。
那时候KWP2000是基于K线的诊断协议，（一条线K，或者两条线K和L）那具体KWP2000协议是什么？这时候就要讲讲ISO-14230协议。
当时的KWP2000只三个子层有定义说明，即：应用层、数据链路层和物理层。并且这三个层都由ISO-14230-1、ISO-14230-2、ISO-14230-3定义标准，所以一直都这么说，ISO-14230就是KWP2000。

ISO-14229和UDS
先知道一件事，ISO-14229协议就是UDS(Unified diagnostic services)，这个标准定义了诊断的应用层服务，不基于任何底层标准。它是诊断服务的规范化标准，比如读取故障码应该向ecu发什么指令，读数据流又是发什么指令等…

ISO-15765 和UDSonCAN
由于K线物理层和数据链路层在网络管理和通讯速率上的局限性，使得K线无法满足日趋复杂的车载诊断网络的需求。这时候CAN总线出现并代替了K线，也就是我们说的ISO-15765。ISO-15765是基于CAN，它的ISO-15765-2、ISO-15765-3定义了诊断数据网络层和应用层的定义标准。

又因为ISO-15765-3使用了ISO-14229（UDS）的诊断服务，所以ISO-15765也叫UDSonCAN。

再看他们的关系

---

又有人把ISO-14230称为基于K线的KWP2000协议，把后面发展称为Can线的ISO-15765称为基于基于CAN的KWP2000协议。
其实都可以，不混淆就行，基于K线的KWP2000协议就是ISO-14230，基于CAN的KWP2000协议就是ISO-15765或者UDSonCAN！！！！

改个名字也行~

二、1. KWP 2000协议

KWP 2000协议是最常用的通信协议之一，又称为关键字协议，因为这种协议在系统进入时，会涉及到关键字的校验而得名。
K线KWP2000协议是异步半双工进行通讯的，通常采用10416BPS的波特率；空闲电平通常为12V。
其实很简单，就是用一条K线进行数据通讯，然后制定一些协议而已。
下面系统初始化进入、帧结构、命令交互、交互时间参数、常用命令字等几个方面来介绍这种协议。

1、系统进入初始化
有两种初始化方式，主要是用第一种初始化。由设备先发送25ms的拉低电平，然后是25ms的高电平（空闲电平），然后再发送系统进入数据，系统进入数据通常为5个字节，ECU响应7个字节，完成系统初始化交互。请参见下图：

第二种初始化方式为设备发送5BPS或者200BPS的地址码，ECU响应55H，KW1，KW2，设备对KW2取反发回给ECU，ECU对地址码取反发回给设备，完成系统初始化交互。其中55H这个字节用来规定后面的通信波特率。参见下图

2、帧结构
命令头（1个或多个字节）+命令体（1个或多个字节）+校验（通常为和校验）

在命令头中，包括以下几个部分的内容：格式+目标地址+源地址+长度字节。长度信息有时候在格式字节中体现，则不需要另外的长度字节，长度信息用以表示命令体的内容；目标地址和源地址有时候也会没有。
命令体的内容中：命令字+命令内容。命令内容可以没有。
举例如下：

81H 11H F1H 81H 04H

第一个字节81H为格式+长度信息（80+1）
第二个字节11H为目标地址
第三个字节F1H为源地址
第四个字节81H为命令字，表示系统进入
最后一个字节04H为前面4个字节的校验和
同样，也可能表现如下：（命令字）
80H 11H F1H 01H 3EH C1H
这种情况下，长度字节放在源地址之后
还可能表现为：
02H 1AH 9AH B6H
这种情况下，格式字节和目标地址源地址都已经没有了
还有一种特殊的情况，在上一种情况的基础上，在帧数据之前，加一个00，例如：
00H 02H 1AH 9AH B6H
但这种帧结构的情况极少

3、命令交互
命令交互通常情况下为1对1，但也存在1对多或者多对1的情况。下面是一组命令交互举例：
Tools: 81H 31H F1H 81H 24H
ECU: 83H F1H 31H C1H E9H 8FH DEH
在交互中，因为发送命令的对象不一样，所以目标地址和源地址是进行了互换；
同时，ECU响应设备的命令字在设备命令字的基础上 + 0x40（肯定回答）

还有否定回答，即回复 7F
Tools: 0x81, 0x11, 0xF1, 0x81, 0x04,
ECU: 0x83, 0xF1, 0x11, 0x7F, 0x81, 0x21, 0xA6,

4、交互时间参数
设备发送命令字节间的时间间隔P1，通常为5ms
ECU返回命令字节间的时间间隔P2，通常为0ms
设备发送完一帧命令后等待ECU响应的时间P3，通常为75ms~90ms
设备接收到ECU响应后到发送下一帧命令的时间P4，通常为20ms~26ms

5、常用命令字

系统进入：81H
系统退出：82H
链路保持：3EH
读故障码：18H
清除故障码：14H
读版本信息：1AH
读数据流：21H

6、数据格式

发送一字节的数据格式为（重点）：
起始位 + 数据 + 停止位
1 + 8 + 1
如下：

7、实训
从最底层开始，直接看K线的电平变化吧
截一段设备向ECU发送请求的数据：

**IO[0]：**用作K线通讯发送和接收数据的端口，变化电平高低（1,0）表示数据位的值
T：表示电平持续的时间

一个数据位的时间 = 1/波特率即： 1 / 10416 = 95 ns(约等于)

那就简单了，把上面电平持续时间时间除以95，可以得出K线的电平变化情况：

单位：一个数据位的时间单位

把每字节的起始位和结束位去掉，可以很容易看出，这个设备发送命令字节间的时间间隔P1，为4.5ms
所以解析一下电平图代表的数据实际是：

注意：数据先从低位开始发送，0000 0001 实际为 1000 0000 则 0x80

向ECU发送请求的数据为：0x80,0x11,0xF1,0x01
这段数据是没实际作用的，因为原地址后面没有命令字，没发实有用的命令

随便再搞一段ECU返回设备的数据：

电平持续时间时间除以95，可以得出K线的电平变化情况：

可知ECU返回命令字节间的时间间隔P2，为0ms
同上解析方法，很容易得出实际的数据为：

ECU返回设备的数据为：0x81,0xF1,0x11,0x7E
意思：ECU返回链路保持

大家对比发来的数据，是不是发现问题，校验位呢？？？

实际ECU返回设备的数据是：0x81,0xF1,0x11,0x7E,0x01 ，因为取的电平图漏了一字节，还有一个校验位没截完…好吧我也懒得从新取数据了，大家知道就好

注意：这两段电平不是对应的一发一收的，是我取两条简单的来解析，所以请求和返回没对应起来，大家不要误会

三、待续