最新KWP协议.docx

上传人:b****5 文档编号:11808860 上传时间:2023-04-02 格式:DOCX 页数:9 大小:101.41KB
下载 相关 举报
最新KWP协议.docx_第1页
第1页 / 共9页
最新KWP协议.docx_第2页
第2页 / 共9页
最新KWP协议.docx_第3页
第3页 / 共9页
最新KWP协议.docx_第4页
第4页 / 共9页
最新KWP协议.docx_第5页
第5页 / 共9页
点击查看更多>>
下载资源
资源描述

最新KWP协议.docx

《最新KWP协议.docx》由会员分享,可在线阅读,更多相关《最新KWP协议.docx(9页珍藏版)》请在冰豆网上搜索。

最新KWP协议.docx

最新KWP协议

KWP2000协议

KWP2000协议分析

2022-11-1915:

59

1前言

在汽车故障诊断领域,针对诊断设备和汽车ECU之间的数据交换,各大汽车公司几乎都制订了相关的标准和协议。

其中,欧洲汽车领域广泛使用的一种车载诊断协议标准是KWP2000〔KeywordProtocol2000〕,该协议实现了一套完整的车载诊断效劳,并且满足E-OBD〔EuropeanOnBoardDiagnose〕标准。

KWP2000最初是基于K线的诊断协议,由于K线物理层和数据链路层在网络管理和通讯速率上的局限性,使得K线无法满足日趋复杂的车载诊断网络的需求。

而CAN网络〔ControllerAreaNetwork〕由于其非破坏性的网络仲裁机制、较高的通讯速率〔可达1Mbps〕和灵活可靠的通讯方式,在车载网络领域广受青睐,越来越多的汽车制造商把CAN总线应用于汽车控制、诊断和通讯。

近年来欧洲汽车领域广泛采用了基于CAN总线的KWP2000,即ISO15765协议,而基于K线的KWP2000物理层和数据链路层协议将逐步被淘汰。

2基于K线的KWP2000协议

基于K线的KWP2000协议标准主要包括ISO/WD14230-1~14230-4,各局部协议与OSI模型的对应关系如表1所示。

表1KWP2000协议与OIS模型的对应关系

OSI模型

基于K线的KWP2000

基于CAN总线的KWP2000

应用层

ISO14230-3

ISO15765-3

表述层

N/A

N/A

会话层

N/A

N/A

传输层

N/A

N/A

网络层

N/A

ISO15765-2

数据链路层

ISO14230-2

ISO11898-1

物理层

ISO14230-1,ISO9141-2

用户选择

ISO14230-1规定了KWP2000协议的物理层标准〔K线、L线〕,它在ISO9141-2的根底上把数据交换系统扩展到了24V电压系统。

ISO14230-2规定了KWP2000的数据链路层协议,包括报文结构、初始化过程、通讯连接管理、定时参数和错误处理等内容。

K线的报文包括报文头、数据域和校验和三局部,其中报文头包含格式字节、目标地址〔可选〕、源地址〔可选〕和附加长度信息〔可选〕,如表2所示。

表2基于K线的KWP2000报文结构[3]

报文头

数据域

校验和

Fmt

Tgt1)

Src1)

Len1)

SId2)

..

Data2)

..

CS

最长4字节

最长255字节

1字节

TP0*)

采用正常定时参数设置

采用扩展定时参数设置

TP1*)

采用扩展定时参数设置

采用正常定时参数设置

*)只允许TP0,TP1=0,1或者1,0

诊断设备可以采用两种方式对ECU进行初始化——5Baud初始化和快速初始化,对于这两种初始化的时序在数据链路层协议[3]中均有明确规定。

完成初始化过程后,诊断设备和ECU方可进行应用层的诊断效劳和响应。

ISO14230-3规定了应用层的效劳标准,包括诊断管理功能组、数据传输功能组、诊断信息传输功能组、输入/输出控制功能组、远程启动ECU例程功能组、数据上载/下载功能组和扩展功能组。

在诊断效劳请求/响应过程中,诊断设备和ECU必须遵循图2所示的时序和相关定时参数。

对于初始化和诊断效劳过程中出现的各种定时错误,在数据链路层和应用层协议里面都有相应的处理标准,诊断设备及ECU的应用程序都必须严格遵守。

图2K线诊断效劳时序图[3]

3基于CAN总线的KWP2000协议

基于CAN总线的KWP2000协议实际上指的就是ISO/WD15765-1~15765-4,该协议把KWP2000应用层的诊断效劳移植到CAN总线上。

数据链路层采用了ISO11898-1协议,该协议是对CAN2.0B协议的进一步标准化和标准化;应用层采用了ISO15765-3协议,该协议完全兼容基于K线的应用层协议14230-3,并参加了CAN总线诊断功能组;网络层那么采用ISO15765-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效劳标识符〔ServiceID〕+效劳参数

应用层协议规定了四种效劳数据结构,.Request、.Indication、.Response和.Confirm,分别用于诊断设备〔Tester〕的效劳请求、ECU的效劳指示、ECU的效劳响应和Tester的效劳确认。

这些数据结构中包含了地址信息、效劳请求ID和效劳请求参数等内容。

基于CAN总线的KWP2000诊断效劳流程如图3所示。

图3基于CAN总线的KWP2000诊断效劳流程图

从上面的效劳流程可以看出,基于CAN总线的KWP2000协议支持多包数据传输,并且多包数据的管理和组织是在网络层完成的,应用层不必关心数据的打包和解包过程。

为实现这一功能,网络层定义了四种PDU〔以PCI类型进行区分,如表5所示〕:

单帧〔SingleFrame,SF〕-数据域及PCI可在一个CAN数据帧中容纳时,效劳报文以单帧CAN报文进行发送。

第一帧〔FirstFrame,FF〕-数据域及PCI不能在一个CAN数据帧中容纳时,效劳报文以多帧CAN报文进行发送,其中第一帧〔FF〕除传送数据外,还包含了多包数据的长度信息。

连续帧〔ConsecutiveFrame,CF〕-多包数据中除第一帧外的连续数据帧,除传送数据外,还包含了多包数据的包序号。

流控制帧〔FlowControl,FC〕-用于多包数据传输过程中的流控制,不包含数据,只包含流控制状态、数据块大小和最小间隔时间等流控制信息。

表515765协议网络层四种PDU对应的PCI格式[7]

N_PDU名称

Byte#1

Byte#2

Byte#3

Bit#7-4

Bit#3-0

N/A

N/A

单帧〔SF〕

N_PCItype=0

SF_DL1)

N/A

N/A

第一帧〔FF〕

N_PCItype=1

FF_DL2)

N/A

连续帧〔CF〕

N_PCItype=2

SN3)

N/A

N/A

流控制帧〔FC〕

N_PCItype=3

FS4)

BS5)

STmin6)

1)单帧数据中数据域的字节长度,PCI的长度不包括在内。

2)多包数据的数据域字节总长度。

3)多包数据的数据包编号。

4)流控制状态信息。

5)数据块大小。

6)多包数据传输的最小时间间隔。

多包数据的传输流程如图4所示。

发送节点首先发送“第一帧〞,告知接收节点将要发送的数据的总长度;接收节点分配好资源、准备接收数据,然后以一帧“流控制帧〞告知发送节点一次可以发送的数据包数目和时间间隔;发送节点接下来就根据接收节点的接收能力将编好序号的数据包依次发送过去。

图4多包数据传输流程图

在数据传送过程中,一个网络层PDU被编排成一个CAN数据帧,它们之间的对应关系由寻址模式〔Addressingmode〕决定。

基于ISO15765协议规定了四种寻址模式:

正常寻址模式〔Normal〕、正常固定寻址模式〔Normalfixed〕、扩展寻址模式〔Extended〕和用于远程诊断的混合寻址模式〔Mixed〕。

其中,正常固定寻址模式必须采用CAN扩展帧,并且SAEJ1939为该寻址模式下的KWP2000诊断效劳保存了两个专用参数组编号〔PGN〕:

其中PF=218〔PF的具体定义请参考SAEJ1939数据链路层协议〕的参数组用于物理寻址〔phy〕,PF=219的参数组用于功能寻址〔fcn〕。

正常固定寻址模式的PDU与CAN数据帧之间的对应关系如表6所示。

表6正常固定寻址模式下N_PDU与CAN数据帧之间的对应关系[7]

N_PDU类型

CAN29位标识符

CAN数据域

28~26

25

24

23~16

15~8

7~0

1

2

3

4

5

6

7

8

单帧〔SF〕

011(bin)

0

0

218(dec)-phy

219(dec)-fcn

N_TA

N_SA

N_PCI

N_Data

第一帧〔FF〕

011(bin)

0

0

218(dec)-phy

219(dec)-fcn

N_TA

N_SA

N_PCI

N_Data

连续帧〔CF〕

011(bin)

0

0

218(dec)-phy

219(dec)-fcn

N_TA

N_SA

N_PCI

N_Data

流控制〔FC〕

011(bin)

0

0

218(dec)-phy

219(dec)-fcn

N_TA

N_SA

N_PCI

N/A

混合寻址模式与正常固定寻址模式类似,唯一的区别是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位〕,对于长报文的传输,网络层协议还具备标准化和标准化的同步控制、顺序控制、流控制和错误恢复等功能,具备很高的可靠性、兼容性。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 解决方案

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1