在网络协议开发和应用方面，美国MathWorks公司和德国Vector公司提供了功能强大的开发和测试工具，可用于协议栈源码的开发和ECU测试。

1、基于K线的KWP2000协议:

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

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

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

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

2、基于CAN总线的KWP2000协议

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

   从上面的服务流程可以看出，基于CAN总线的KWP2000协议支持多包数据传输，并且多包数据的管理和组织是在网络层完成的，应用层不必关心数据的打包和解包过程。为实现这一功能，网络层定义了4种PDU（以PCI类型进行区分，如表5所示）。
   单帧（Single Frame, SF）-数据域及PCI可在一个CAN数据帧中容纳时，服务报文以单帧CAN报文进行发送。 
   混合寻址模式与正常固定寻址模式类似，唯一的区别是CAN数据域的第一个字节用于填充远程地址（RA），N_PCI和诊断服务数据的填充位置向后移动一个字节。混合寻址模式用于跨越网段进行远程诊断，远程诊断的机制如图5所示。图中CAM和CAN2两个不同的子网通过网桥相连，网桥在子网1中的源地址为200，在子网2中的源地址为10，位于子网1中的诊断设备（源地址为241）可通过网桥对、子网2中的ECU（源地址为62）进行诊断。

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

3 、两种协议的简单比较

    a. K线通讯速率较低，最大波特率仅为10400bps；CAN总线最大波特率可达1 Mbps。

    b. K线采用单.端信号传输，抗干扰能力较弱，可靠性较差;CAN总线采用差分信号传输，抗干扰能力强，信号传输的可靠性高。

    c. K线在启动应用层诊断服务之前必须对ECU进行初始化建立连接，且初始化过程比较复杂；基于CAN总线的诊断设备不需要对ECU进行初始化即可进行诊断服务。

    d. K线诊断应用程序开发者必须亲自管理数据传输过程中的字节间定时，并处理底层通讯错误；CAN数据帧以整帧报文的形式进行发送，应用程序开发者不必管理字节间定时，并且CAN总线物理层和数据链路层具备完善的错误检测和错误恢复机制，应用程序不必监视和处理底层通讯错误。

    e. K线网络结构单一，网络管理功能很弱；而利用CAN总线可构建复杂的网络结构，可跨越网段进行远程诊断。

    f. K线网络采用破坏性的仲裁机制，当诊断设备采用功能寻址与多个ECU进行通讯时，为避免总线冲突,ECU开发者必须采取措施保证多个ECU顺序访问总线；而CAN网络采用非破坏性的仲裁机制，并且仲裁过程由数据链路层完成，当诊断设备采用功能寻址与多个ECU进行通讯时，ECU开发者不必考虑总线访问冲突问题。

    g. K线服务报文最大字节长度仅为255,无法满足更长报文的传输要求，并且在长报文的传输过程中用户自己必须采取措施进行连接管理，可靠性和兼容性较差；CAN总线诊断服务报文最大字节长度可达4096（12位），对于长报文的传输，网络层协议还具备标准化和规范化的同步控制、顺序控制、流控制和错误恢复等功能，具备很高的可靠性、兼容。
  4、 KWP2000协议栈的开发及测试

   CANoe中的KWP2000实际指的是基于CAN总线的KWP2000，即15765协议。由于CANoe默认的硬件板卡是CAN卡，因此在建立仿真程序时，只需将ECU的网络模块设置为KWP2000.d11即可进行CAN总线的KWP2000服务测试。KWP2000.d11中包含 15765应用层协议中规定的服务请求、服务指示、服务响应和服务确认接口函数，用户调用这些函数即可完成Tester端和ECU端的KWP2000诊断服务。此外，该模块中的功能函数还可对ECU的源地址、目标地址、寻址模式等参数进行动态设置。需要注意的是，KWP2000.d11目前只提供了部分 KWP2000服务的接口函数，如果用户需要进行其它的KWP2000服务测试，必须根据KWP2000应用层协议构造服务报文数据，然后调用该模块中的 KWP DataReq （）和KWP GetRxData （）函数进行报文的发送和接收。
   进行基于K线的KWP2000服务测试时，需要将K线CPL.dll模块加入CANoe仿真环境，并使用一个代理节点来实现CAN网络和K线之间的报文转发。此时CANoe使用计算机的串口，并通过一个串口/K线转换器与实际的ECU相连。

    MATLAB/Simulink/Stateflow为协议栈开发提供了方便直观的图形用户接口和功能强大的仿真调试环境及代码生成工具，为嵌人式开发开辟了一条高效快捷之路。Vector公司的CANoe和相关硬件板卡是一个功能强大的应用开发平台，可针对基于K线和CAN总线的KWP2000进行 ECU和诊断设备的上层协议开发、测试及仿真。