K线诊断协议驱动器设计.docx
- 文档编号:25142708
- 上传时间:2023-06-05
- 格式:DOCX
- 页数:10
- 大小:75.72KB
K线诊断协议驱动器设计.docx
《K线诊断协议驱动器设计.docx》由会员分享,可在线阅读,更多相关《K线诊断协议驱动器设计.docx(10页珍藏版)》请在冰豆网上搜索。
K线诊断协议驱动器设计
K线诊断协议驱动器设计
Time:
2012-03-2211:
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
表1ISO14230与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个字节
表2K线诊断报文结构
K线报文由报文头、数据字段及校验和组成。
报文头包含格式字节Fmt、目标地址Tgt、源地址Src和可选附加长度信息Len,Fmt指定目标地址的形式(物理地址/功能地址),当报文头中不包含可选Len字段时指定数据字段的长度;数据字段包括服务标识符Sid和数据Data,其长度由Fmt和Len决定;CS为单字节校验和。
设计报文结构体如下:
typedefstruct
{
k_statestate;
ucharfmt;
uchartgt_addr;
ucharsrc_addr;
uchardatalen;
ucharsid;
uchar*data;
ucharchecksum;
ucharmsgdatalen;
uchardone;
}k_msg;
typedefenum{
k_FMT=0,
k_TGTADDR,
k_SRCADDR,
k_DATALEN,
k_SID,
k_DATA,
k_CS
}k_state;
成员变量state表示当前K线通信数据是报文中的哪个组成部分,msgdatalen用于数据字段字节数的统计,done表示该报文是否发送或接收完成,其它成员变量与报文结构组成部分一一对应。
voidk_ifc_rx(void)
{
k_u8ch,SciSr1;
SciSr1=Kline_periph[SCISR1];
ch=Kline_periph[SCIDRL];
TimerStop(k_TP4);
switch(k_curmsg.state){
casek_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;
casek_TGTADDR:
...
break;
casek_SRCADDR:
...
break;
casek_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;
casek_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;
casek_DATA:
...
break;
casek_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(WakeUpPattern),然后发送STC(StartCommunication)Request,ECU检测出WuP并接收到正确的STCRequest后返回STCResponse,该报文的Data字段为由两个字节构成的“关键字(KeyWord)”,指定了ECU所支持的报文头和定时参数信息,如KeyWord指定为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,等待诊断仪发送的STCRequest,接收到请求后返回STCResponse肯定响应,建立诊断通讯。
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和STCRequest。
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所示。
图2K线诊断框架
与CAN总线诊断不同的是,K线诊断需要诊断仪通过初始化过程和ECU建立诊断通讯,诊断通讯的建立如图3所示。
建立诊断通讯后便可以像CAN诊断一样进行诊断服务了,这方面论文很多,在此不再赘述。
图3建立诊断通讯
结语
本文实现的K线协议驱动器模块经过严格测试,能够高效完成K线诊断,性能和稳定性达到预期设计要求。
驱动器独立于处理器和操作系统,具有良好的通用性和灵活性,可以方便得集成到应用程序中,具有很高的实用价值和借鉴意义。
信你自己罢!
只有你自己是真实的,也只有你能够创造你自己
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 诊断 协议 驱动器 设计