线诊断协议驱动器设计.doc

K线诊断协议驱动器设计
Time:2023-03-22 11:49:41  Author:  Source:中电网
关键字：K线诊断,汽车电子控制单元,协议驱动器
分享到：
引言：

随着汽车电子控制单元功能的增长及升级换代的需要，诊断功能已经成为ECU不可或缺的重要组成部分，因此，进一步研究诊断协议及其实现非常必要。基于K线的ISO14230和基于CAN总线的ISO15765是业内广泛采用的两种诊断标准【1】，K线是ISO9141定义的诊断通信总线，ISO14230在ISO9141的基础上将K线电压扩展到24V，并扩展了诊断服务。相比较于CAN总线，K线诊断既能满足规定，又能节约成本，在国产车上得到大规模应用。不同于CAN总线有专门的协议驱动器，用户直接进行应用程序的编写而不用管理底层的通信，K线没有专门的协议驱动器，一般要在SCI模块的基础上用软件实现其底层通信管理，笔者为某国产车设计了一款带K线诊断功能的车身控制模块，结合ISO14230规范，一方面分析K线诊断协议驱动器的功能，然后介绍协议驱动器的关键设计技术，最后用CANoe进行测试。

1 协议驱动器功能

ISO14230-1定义了K线物理层协议，ISO14230-2定义了数据链路层协议，ISO14230-3定义了应用层协议【2】，其与OSI模型相应关系如表1所示。
OSI模型
K线诊断协议
应用层
ISO14230-3
表述层
N/A
会话层
N/A
传输层
N/A
网络层
N/A
数据链路层
ISO14230-2
物理层
ISO14230-1
表1 ISO14230与OSI模型的相应关系

物理层定义了逻辑位与物理电平的相应关系，同时定义了信号位的上升时间和下降时间，数据链路层协议定义了K线数据格式、诊断报文格式、定期参数及通信错误鉴定及解决机制，应用层协议定义了基于请求/响应的诊断过程及各项诊断服务。做为待诊断ECU节点，K线协议驱动器实现的重要功能涉及：

1、诊断报文的封装和发送、接受和解析，根据报文格式填充/提取SID和数据；

2、通过初始化过程建立与诊断仪之间的诊断通信；

3、保持对的的帧间定期、字节间定期，检测诊断仪报文的定期错误及其它通信错误；

4、根据诊断仪的诊断请求和ECU当前状态返回相应的诊断响应，管理诊断会话；

下面结合数据链路层的协议分析及其数据结构、驱动程序的设计介绍下K线诊断协议驱动器的原理及实现。

2 协议驱动器设计

K线基于异步串行通信接口，在底层传输上采用8N1格式的SCI串行数据链路格式：8个数据位+1个停止位、无奇偶校验，由于K线在物理层上是单根线，在发送时也会触发接受中断，所以K线报文的发送和接受解析统一在SCI接受中断解决函数中以状态机的形式实现【3】。下面从报文收发及解析、初始化、定期管理三个方面介绍下数据链路层的实现。

2.1 报文收发及解析

K线诊断报文结构如表2所示：
报文头
数据字段
校验和
Fmt
Tgt
Src
Len
Sid
Data
CS
最大4个字节
最大63字节或255字节
1个字节

表2 K线诊断报文结构

K线报文由报文头、数据字段及校验和组成。报文头包含格式字节Fmt、目的地址Tgt、源地址Src和可选附加长度信息Len，Fmt指定目的地址的形式（物理地址/功能地址），当报文头中不包含可选Len字段时指定数据字段的长度；数据字段涉及服务标记符Sid和数据Data，其长度由Fmt和Len决定；CS为单字节校验和。设计报文结构体如下： 

typedef struct

{

  k_state state;

  uchar fmt;

  uchar tgt_addr;

  uchar src_addr;

  uchar datalen;

  uchar sid;

  uchar *data;

  uchar checksum;

  uchar msgdatalen;

  uchar done;  

}k_msg;

typedef enum{

  k_FMT=0,

  k_TGTADDR,

  k_SRCADDR,

  k_DATALEN,

  k_SID,

  k_DATA,

  k_CS

}k_state;

成员变量state表达当前K线通信数据是报文中的哪个组成部分，msgdatalen用于数据字段字节数的记录，done表达该报文是否发送或接受完毕，其它成员变量与报文结构组成部分一一相应。 
void k_ifc_rx(void)

{

  k_u8 ch,SciSr1; 

  SciSr1=Kline_periph[SCISR1];

  ch=Kline_periph[SCIDRL];

  TimerStop(k_TP4);

  switch(k_curmsg.state){

  case k_FMT:

    if(k_REP==k_drvhandle.mode){

      if(ch==k_curmsg.fmt){

        k_curmsg.state=k_TGTADDR;

        k_SendChar(k_curmsg.tgt_addr);

      }

    }else{

      k_curmsg.state=k_TGTADDR;

      k_curmsg.fmt=ch;

    }

    break;

  case k_TGTADDR:

    ...

    break;

  case k_SRCADDR:

    ...

    break;

  case k_DATALEN:

    if(k_REP==k_drvhandle.mode){

      if(ch==k_curmsg.datalen){

        k_curmsg.msgdatalen=0;

        k_curmsg.state=k_SID;

        k_SendChar(k_curmsg.sid);

      }

    }else{

      k_curmsg.msgdatalen=0;

      k_curmsg.datalen=ch;

      free(k_curmsg.data);

k_curmsg.data=malloc(k_curmsg.datalen);

      k_curmsg.state=k_SID; 

    }

    break;

  case k_SID:

    if(k_REP==k_drvhandle.mode){

      if(ch==k_curmsg.sid){

        k_curmsg.msgdatalen++; 

if(k_curmsg.msgdatalen==k_curmsg.datalen){

          k_curmsg.state=k_CS;  

k_SendChar(k_curmsg.checksu);

        }else{

          k_curmsg.state=k_DATA;

        k_SendChar(k_curmsg.data[0]);

        }

      }

    }else{

      k_curmsg.sid=ch;

      k_curmsg.msgdatalen++;

if(k_curmsg.datalen==k_curmsg.msgdatalen){

        k_curmsg.state=k_CS;

      }else{

        k_curmsg.state=k_DATA;

      }      

    }

    break;

  case k_DATA:

    ...

    break;

  case k_CS:

    k_curmsg.state=k_FMT;

    if(k_REP==k_drvhandle.mode){

      if(ch==k_curmsg.checksum){

        k_curmsg.done=1; 

      }

    }else{

      k_curmsg.checksum=ch;

      k_curmsg.done=1; 

    }

      break;

  }   if((k_REQ==k_drvhandle.mode)&&(k_FMT!=k_curmsg.state)){

    TimerStart(k_REP_P4MS,k_TP4,0,1);

  } 

} 
2.2 初始化

在开始诊断服务之前，诊断仪必须对ECU进行初始化，通过ECU的响应获取ECU支持的报文头格式和定期参数，建立诊断通讯【4】。初始化过程如图1所示，诊断仪发送一个25ms ’0’、25ms’1’的WuP(WakeUp Pattern)，然后发送STC(StartCommunication) Request，ECU检测出WuP并接受到对的的STC Request后返回STC Response，该报文的Data字段为由两个字节构成的“关键字（Key Word）”，指定了ECU所支持的报文头和定期参数信息，如Key Word指定为0x8fea即表达在报文头中采用附加长度信息Len表达数据字段长度，同时采用默认的定期参数。

图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个定期参数的含义及取值区间。
参数变量
描述
最小值(ms)
最大值(ms)
P1
ECU响应的字节间时间间隔
0
20
P2
诊断仪请求和ECU响应之间的时间间隔，或两个ECU响应之间的时间间隔
25
50
P3
ECU响应和诊断仪请求之间的时间间隔
55
5000
P4
诊断仪请求的字节间时间间隔
0
20
表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线的KWP2023服务测试时，将KWP2023.dll和KLineCPL.dll模块加入CANoe仿真环境，CANoe模拟诊断仪节点，并使用一个代理节点来实现CAN网络和K线之间的报文转发，此时CANoe使用计算机的串口，并通过串口/K线转换器与ECU相连，诊断实现框架如图2所示。

图2 K线诊断框架

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

图3 建立诊断通讯

结语

本文实现的K线协议驱动器模块通过严格测试, 可以高效完毕K线诊断，性能和稳定性达成预期设计规定。驱动器独立于解决器和操作系统，具有良好的通用性和灵活性，可以方便得集成到应用程序中，具有很高的实用价值和借鉴意义。