基于K线的应用层协议14230-3，并加入了CAN总线诊断功能组；网络层则采用ISO 15765-2协议，规定了网络层协议数据单元（N_PDU，如表4所示）与底层CAN数据帧、以及上层KWP2000服务之间的映射关系，并且为长报文 的多包数据传输过程提供了同步控制、顺序控制、流控制和错误恢复功能。
表4 网络层协议数据单元（N_PDU）格式[7]
地址信息 协议控制信息 数据域 N_AI1) N_PCI2) N_Data3)
1) 地址信息：包含源地址（SA）、目标地址（TA）、目标地址格式（TA_Type）和远程地址（RA） 2) 协议控制信息：包含四种帧格式，见表5
3) 数据域：KWP2000服务标识符（Service ID） + 服务参数
应用层协议规定了四种服务数据结 构，
图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]
N_PDU 名称
Byte #1
Byte #2
N/A
Byte #3 N/A
Bit # 3-0
Bit # 7-4
单帧（SF）
第一帧
FF_DL2) N/A
（FF） 连续帧
SN3) N/A N/A
（CF） 流控制帧
FS4) BS5) STmin6)
（FC）
1) 单帧数据中数据域的字节长度，PCI的长度不包括在内。 2) 多包数据的数据域字节总长度。 3) 多包数据的数据包编号。 4) 流控制状态信息。 5) 数据块大小。
6) 多包数据传输的最小时间间隔。
多包数据的传输流程如图4所示。发送节点首先发送“第一帧”，告知接收节点将要发送的数据的总长度；接收节点分配好资源、准备接收数据，然后以一帧 “流控制帧”告知发送节点一次可以发送的数据包数目和时间间隔；发送节点接下来就根据接收节点的接收能力将编好序号的数据包依次发送过去。
N_PCItype=0 N_PCItype=1 N_PCItype=2 N_PCItype=3
SF_DL1) N/A N/A
图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]
N_PDUCAN 29位标识符 CAN数据域 类型 28~26 25 24 23~16 15~8 7~0 1 2 3 4 5 6 7 8
011(b
单帧0 0 218(dec)-phy N_TA N_SA N_PCI N_Data
in)
（SF） 219(dec)-fcn
第一帧011(b
0 0 218(dec)-phy N_TA N_SA N_PCI N_Data
（FF） in)
219(dec)-fcn
连续帧011(b
0 0 218(dec)-phy N_TA N_SA N_PCI N_Data
（CF） in)
219(dec)-fcn
流控制011(b
0 0 218(dec)-phy N_TA N_SA N_PCI N/A
（FC） in)
219(dec)-fcn
混合寻址模式与正常固定寻址模式类似，唯一的区别是CAN数据域的第一个字节用于填充远程地址（RA），N_PCI和诊 断服务数据的填充位置向后移动一个字节。混合寻址模式用于跨越网段进行远程诊断，远程诊断的机制如图5所示。图中CAN1和CAN2两个不同的子网通过网 桥相连，网桥在子网1中的源地址为200，在子网2中的源地址为10，位于子网1中的诊断设备（源地址为241）可通过网桥对子网2中的ECU（源地址为 62）进行诊断。
图5 跨越网段的远程诊断
4 两种协议的简单比较
从前面基于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位），对于长报 文的传输，网络层协议还具备标准化和规范化的同步控制、顺序控制、流控制和错误恢复等功能，具备很高的可靠性、兼容性。
5 KWP2000协议栈的开发及测试
从前面的协议分析可以看出，无论是基于K线还是CAN总线的KWP2000协议，都是逻辑非常复杂的系 统，并且具有严格的定时和错误处理规范。如果采用纯手工的方式来进行KWP2000协议栈的开发，不仅要耗费大量的时间和人力，其通用性、完备性、可靠性 和可维护性都很难保证。而MATLAB/Simulink/StateFlow不仅具备方便快捷的上层实时仿真环境，还集成了高效的嵌入式代码自动生成工 具，为协议栈的开发和维护提供了强大的支持平台。此外，由德国Vector公司的CANoe软件和相关硬件板卡组成的应用开发平台，可用于汽车网络 （CAN，Lin等）的上层协议开发和系统测试，该平台同时支持基于K线和CAN总线的KWP2000诊断协议，可作为ECU和诊断设备的测试标准。
图6是协议源码开发过程示意图。首先在MATLAB/Simulink/StateFlow中遵照协议 标准进行KWP2000协议栈开发，在仿真调试环境下实现通讯逻辑、定时控制和错误处理，待系统完善后利用StateFlow嵌入式代码生成工具自动生成 协议栈C代码，并与目标系统的底层驱动进行集成，然后植入目标系统形成应用程序，最后再利用CANoe作为标准进行系统集成测试。
图6 KWP2000协议栈开发及测试流程
在MATLAB/Simulink/StateFlow中进行协议栈仿真开发是协议栈开发过程中的关键 环节，在这一过程中必须严格遵照协议标准来实现通讯逻辑，往往需要经过多次“设计－仿真－修改”循环才能使系统最终趋于完善。MATLAB的图形界面提供 了方便快捷的仿真输入/输