基于K线的KWP2000协议标准主要包括ISO/WD 14230-1～14230-4，各部分协议与OSI模型的对应关系如表1所示。

表1 KWP2000协议与OIS模型的对应关系

ISO 14230-1规定了KWP2000协议的物理层规范（K线、L线），它在ISO 9141-2的基础上把数据交换系统扩展到了24V电压系统。ISO 14230-2规定了KWP2000的数据链路层协议，包括报文结构、初始化过程、通讯连接管理、定时参数和错误处理等内容。K线的报文包括报文头、数据域和校验和三部分，其中报文头包含格式字节、目标地址（可选）、源地址（可选）和附加长度信息（可选），如表2所示。

表2 基于K线的KWP2000报文结构[3]

在开始诊断服务之前，诊断设备必须对ECU进行初始化，通过ECU的响应获取ECU的源地址、通讯波特率、支持的报文头格式、定时参数等信息。ECU所支持的报文头和定时参数信息包含在ECU返回的“关键字（Key Word）”中（这也是协议命名的由来）。关键字由两个字节构成，如图1所示，关键字的低字节中各位的含义如表3所示。

图1 关键字格式[3]

表3 关键字低字节中各位的含义[3]

*) 只允许TP0,TP1 = 0,1 或者1,0

诊断设备可以采用两种方式对ECU进行初始化——5Baud初始化和快速初始化，对于这两种初始化的时序在数据链路层协议[3]中均有明确规定。完成初始化过程后，诊断设备和ECU方可进行应用层的诊断服务和响应。ISO 14230-3规定了应用层的服务规范，包括诊断管理功能组、数据传输功能组、诊断信息传输功能组、输入/输出控制功能组、远程启动ECU例程功能组、数据上载/下载功能组和扩展功能组。在诊断服务请求/响应过程中，诊断设备和ECU必须遵循图2所示的时序和相关定时参数。对于初始化和诊断服务过程中出现的各种定时错误，在数据链路层和应用层协议里面都有相应的处理规范，诊断设备及ECU的应用程序都必须严格遵守。

图2 K线诊断服务时序图[3]

基于CAN总线的KWP2000协议实际上指的就是ISO/WD 15765-1～15765-4，该协议把KWP2000应用层的诊断服务移植到CAN总线上。数据链路层采用了ISO 11898-1协议，该协议是对CAN2.0B协议的进一步标准化和规范化；应用层采用了ISO 15765-3协议，该协议完全兼容基于K线的应用层协议14230-3，并加入了CAN总线诊断功能组；网络层则采用ISO 15765-2协议，规定了网络层协议数据单元（N_PDU，如表4所示）与底层CAN数据帧、以及上层KWP2000服务之间的映射关系，并且为长报文的多包数据传输过程提供了同步控制、顺序控制、流控制和错误恢复功能。

表4 网络层协议数据单元（N_PDU）格式[7]

应用层协议规定了四种服务数据结构，.Request、.Indication、.Response和.Confirm，分别用于诊断设备（Tester）的服务请求、ECU的服务指示、ECU的服务响应和Tester的服务确认。这些数据结构中包含了地址信息、服务请求ID和服务请求参数等内容。基于CAN总线的KWP2000诊断服务流程如图3所示。

图3 基于CAN总线的KWP2000诊断服务流程图

从上面的服务流程可以看出，基于CAN总线的KWP2000协议支持多包数据传输，并且多包数据的管理和组织是在网络层完成的，应用层不必关心数据的打包和解包过程。为实现这一功能，网络层定义了四种PDU（以PCI类型进行区分，如表5所示）：
单帧（Single Frame，SF） － 数据域及PCI可在一个CAN数据帧中容纳时，服务报文以单帧CAN报文进行发送。
第一帧（First Frame，FF） － 数据域及PCI不能在一个CAN数据帧中容纳时，服务报文以多帧CAN报文进行发送，其中第一帧（FF）除传送数据外，还包含了多包数据的长度信息。
连续帧（Consecutive Frame，CF） － 多包数据中除第一帧外的连续数据帧，除传送数据外，还包含了多包数据的包序号。
流控制帧（Flow Control，FC） － 用于多包数据传输过程中的流控制，不包含数据，只包含流控制状态、数据块大小和最小间隔时间等流控制信息。

表5 15765协议网络层四种PDU对应的PCI格式[7]

多包数据的传输流程如图4所示。发送节点首先发送“第一帧”，告知接收节点将要发送的数据的总长度；接收节点分配好资源、准备接收数据，然后以一帧“流控制帧”告知发送节点一次可以发送的数据包数目和时间间隔；发送节点接下来就根据接收节点的接收能力将编好序号的数据包依次发送过去。

图4 多包数据传输流程图

在数据传送过程中，一个网络层PDU被编排成一个CAN数据帧，它们之间的对应关系由寻址模式（Addressing mode）决定。基于ISO 15765协议规定了四种寻址模式：正常寻址模式（Normal）、正常固定寻址模式（Normal fixed）、扩展寻址模式（Extended）和用于远程诊断的混合寻址模式（Mixed）。其中，正常固定寻址模式必须采用CAN扩展帧，并且SAE J1939为该寻址模式下的KWP2000诊断服务保留了两个专用参数组编号（PGN）：其中PF=218（PF的具体定义请参考SAE J1939数据链路层协议）的参数组用于物理寻址（phy），PF=219的参数组用于功能寻址（fcn）。正常固定寻址模式的PDU与CAN数据帧之间的对应关系如表6所示。

表6 正常固定寻址模式下N_PDU与CAN数据帧之间的对应关系[7]

混合寻址模式与正常固定寻址模式类似，唯一的区别是CAN数据域的第一个字节用于填充远程地址（RA），N_PCI和诊断服务数据的填充位置向后移动一个字节。混合寻址模式用于跨越网段进行远程诊断，远程诊断的机制如图5所示。图中CAN1和CAN2两个不同的子网通过网桥相连，网桥在子网1中的源地址为200，在子网2中的源地址为10，位于子网1中的诊断设备（源地址为241）可通过网桥对子网2中的ECU（源地址为62）进行诊断。

图5 跨越网段的远程诊断

从前面基于K线和基于CAN总线的KWP2000协议可以看出，两种协议在物理层、数据链路层及网络层（15765）上存在以下主要差别，这也是K线被CAN总线取而代之的主要原因所在：

• K线通讯速率较低，最大波特率仅为10400bps；CAN总线通讯速率较高，最大波特率可达1Mbps。
• K线采用单端信号传输，抗干扰能力较弱，可靠性较差；CAN总线采用差分信号传输，抗干扰能力强，信号传输的可靠性高。
• K线诊断在启动应用层诊断服务之前必须对ECU进行初始化建立连接，并且初始化过程比较复杂；而基于CAN总线的诊断设备不需要对ECU进行初始化即可进行诊断服务。
• K线诊断应用程序开发者必须亲自管理数据传输过程中的字节间定时，并处理底层通讯错误；CAN数据帧以整帧报文的形式进行发送，应用程序开发者不必管理字节间定时，并且CAN总线物理层和数据链路层具备完善的错误检测和错误恢复机制，应用程序不必监视和处理底层通讯错误。
• K线网络结构单一，网络管理功能很弱；而利用CAN总线可构建复杂的网络结构，可跨越网段进行远程诊断。
• K线网络采用破坏性的仲裁机制，当诊断设备采用功能寻址与多个ECU进行通讯时，为避免总线冲突，ECU开发者必须采取措施保证多个ECU顺序访问总线；而CAN网络采用非破坏性的仲裁机制，并且仲裁过程由数据链路层完成，当诊断设备采用功能寻址与多个ECU进行通讯时，ECU开发者不必考虑总线访问冲突问题。
• K线服务报文最大字节长度仅为255，无法满足更长报文的传输要求，并且在长报文的传输过程中用户必须自己采取措施进行连接管理，可靠性和兼容性较差；而CAN总线诊断服务报文最大字节长度可达4096（12位），对于长报文的传输，网络层协议还具备标准化和规范化的同步控制、顺序控制、流控制和错误恢复等功能，具备很高的可靠性、兼容性。

物理层及链路层记录

物理层主要记录要素

• 诊断座定义：用图片或图形记录诊断座形状，脚位定义；
• 电气特性：工作电平、通讯电平
• 通讯方式：正逻辑or负逻辑？双工或半双工

链路层主要记录要素

• 位格式：1+8+1
• 波特率：105200
• 帧格式：使用哪种帧格式进行通讯
• 交互模式：帧交互的方式及各个时间参数
• 系统进入方式说明：说明系统具体进入方式

应用层记录

• 系统说明
• 故障信息
• 数据流
• 动作测试
• 版本信息
• 其他功能

系统说明

需要记录的信息

• 系统名称：指明系统是为那个车型、那个模式进行开发的
• 协议类型：指明该系统的协议类型及物理层和链路层的隶属关系
• 帧格式：指明具体的帧格式，KWP协议的帧格式有4种
• 通讯速度和脚位：说明本系统使用具体通讯波特率和脚位，KWP一般通讯波特率为10400（10416）BPS，使用OBD-16接头的7号脚进行通讯
• 系统进入：写明本系统的系统进入方式，KWP一般为快速进入方式，有少部分为地址码进入方式
• 辅助命令：包括系统进入命令、链路命令、退出命令等，在已经定义具体帧格式下可以只写数据部分

故障信息

记录故障码读取和清除的相关信息 
- 故障码读取命令：写明故障码读取命令及ECU回复的命令结构，KWP协议一般用SID 18进行故障码读取； 
- 故障码算法：写明故障码的算法规则，怎么确认故障码数量、故障码编码怎么确认；KWP协议里，一般ECU回复数据的第二位为故障码个数，接下来每3个字节代表一个故障码，前2位是该故障码的PCBU编码，第三位为故障状态。当然故障码的编码根据具体ECU的不一样还存在2位甚至4位的编码方式。 
- 故障码清除命令：写明故障码清除命令及ECU回复的命令结构，KWP协议一般用SID14进行故障码读取； 
- 故障码清除算法：说明故障码清除操作是否成功或进行的方法

故障信息

故障码列表记录注意点

• 记录其在文本库中的编码（文本库ＩＤ在协议书写时不用填，到加文本库时有工具自动生成再填进去，便于在总库中查找）
• 记录故障码的ＰＣＢＵ编码或其他规则的编码；
• 故障码内容，记录使用的语言文本，同时也保留原始文本

数据流

数据流读取命令：写明数据流读取命令的格式及ECU回复格式；数据流回复数据读取方法：写明怎么样对ECU回复数据进行读取；数据流列表记录注意点 
- PID，byteNo.,bitNo.三部分决定数据流值的具体位置，之间存在范围逐步细化的关系。byteNo.和bitNo.都是从左到右的顺序 
- 存在实际采集数据的，记录数据流模拟值，便于软件完成后对算法的验证，这项只针对用原厂设备破解的协议 
- 算法，为了方便算法直接向库中拷贝，算法描述需要遵循程序里统一的算法解析语法，而且每个算法都必须写一行，中间不要有换行和Tab格

动作测试

动作测试命令：写明动作测试命令的格式及ECU回复格式；数据流列表记录注意点 
- 动作测试关键命令字的记录 
- 如果涉及到计算的，需要记录算法，单位及步长等信息 
- 有分步执行的，需要记录每一步执行的提示及条件 
- 在特殊情况下，可以采取其他格式进行记录

其他功能

特殊功能，如果与基础功能在执行方面差别不大的，采取与基础功能一致的记录方法；在特殊功能执行比较复杂的情况下，可以采用其他方式进行记录后链接