图1 初始化过程

初始化之前K线处于空闲状态，ECU禁止SCI功能并使能SCI的RXD引脚为IO模式，检测到下降沿时通过定时器统计RXD引脚的IO低电平的持续时间，检测到上升沿时开始统计RXD引脚的IO高电平持续时间，判断是否为有效的WuP；也可以设置SCI的波特率为200bps，判断是否能接收到数据0xf0（0xf0在总线上表现为5个0，5个1），检测出正确的WuP后，使能SCI功能，设置波特率为10400bps，等待诊断仪发送的STC Request，接收到请求后返回STC Response肯定响应，建立诊断通讯。

2.3 定时管理
ISO14230定义了4个定时参数管理字节间定时和报文间定时，诊断仪和ECU需要共同遵守这些定时约束以保证正常的诊断通讯，表2给出了这4个定时参数的含义及取值区间。

                                表2 定时参数

P1和P4是报文内字节间定时，P2和P3为报文间定时。诊断仪在初始化完成后或接收到诊断响应后需要在P3时间内发送诊断请求，否则ECU端退出诊断会话，断开诊断通讯，K线协议驱动器重启，等待诊断仪发出下一个WuP和STC Request。ECU在接收到诊断请求后，需要在P2时间内返回诊断响应， P2由ECU控制，通常采用25ms的固定值，当诊断请求报文中的Fmt字段指定目标地址为“功能地址”时，P2的取值需要用一个随机数发生器来产生，因为对于功能寻址的诊断仪请求来说，可能多个ECU都会返回响应，如果采用固定的P2参数的话，可能会因为多个ECU竞争总线而出现总线冲突问题，P2采用随机数，ECU不会在同一时间返回响应，从而避免了总线竞争问题。

3 协议驱动器测试

协议驱动器在Vector公司的CANoe软硬件平台上进行测试，进行基于K线的KWP2000服务测试时，将KWP2000.dll和KLineCPL.dll模块加入CANoe仿真环境，CANoe模拟诊断仪节点，并使用一个代理节点来实现CAN网络和K线之间的报文转发，此时CANoe使用计算机的串口，并通过串口/K线转换器与ECU相连，诊断实现框架如图2所示。

                            图2 K线诊断框架

与CAN总线诊断不同的是，K线诊断需要诊断仪通过初始化过程和ECU建立诊断通讯，诊断通讯的建立如图3所示。建立诊断通讯后便可以像CAN诊断一样进行诊断服务了，这方面论文很多，在此不再赘述。

                            图3 建立诊断通讯