KWP2000协议分析及基于CANoe的开发测试

合集下载

KWP2000协议分析及基于CANoe的开发测试

KWP2000协议分析及基于CANoe的开发测试

KWP2000协议分析及基于CANoe的开发测试摘要:本文介绍了欧洲汽车领域广泛采用的车载诊断协议KWP2000,针对KWP2000诊断服务在K 线(ISO 14230)和CAN总线(ISO 15765)上的两种实现方式,对协议的核心内容和发展历史进行了较为深入的剖析和对比。

本文还介绍了采用Matlab/Simulink/StateFlow进行协议开发的一般流程,以及该协议在Vector公司的CANoe软硬件平台上的应用实现和开过程。

关键词:KWP2000,K线,CAN总线,开发,CANoe1 前言在汽车故障诊断领域,针对诊断设备和汽车ECU之间的数据交换,各大汽车公司几乎都制订了相关的标准和协议。

其中,欧洲汽车领域广泛使用的一种车载诊断协议标准是KWP2000(Keyword Protocol 2000),该协议实现了一套完整的车载诊断服务,并且满足E-OBD(European On Board Diagnose)标准。

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

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

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

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

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

KWP2000协议

KWP2000协议

KWP2000协议协议名称:KWP2000协议一、背景介绍KWP2000协议是一种用于汽车诊断和通信的标准协议,它提供了一种标准化的方式,使得汽车制造商和汽车诊断工具供应商能够在汽车电子系统中进行通信和诊断。

该协议的设计旨在支持诊断、编程和传输数据等功能,以实现对汽车电子控制单元(ECU)的有效管理。

二、目标和目的本协议的目标是确保汽车制造商和汽车诊断工具供应商之间的通信和诊断能够高效、准确地进行。

具体目的包括:1. 提供一种标准化的通信协议,使得汽车制造商和汽车诊断工具供应商能够在汽车电子系统中进行通信和诊断。

2. 支持诊断、编程和传输数据等功能,以实现对汽车电子控制单元(ECU)的有效管理。

3. 提供一种可靠的通信机制,确保数据的准确传输和解析。

4. 保护汽车电子系统的安全性,防止未经授权的访问和操纵。

三、协议内容1. 物理层协议KWP2000协议使用标准的物理层接口,如ISO 9141-2、ISO 14230-4(K-Line)和ISO 15765-4(CAN)等。

具体的物理层协议需根据实际应用情况进行选择和配置。

2. 数据链路层协议KWP2000协议使用数据链路层协议进行数据的可靠传输和解析。

具体协议内容包括:- 数据帧格式:KWP2000协议使用统一的数据帧格式,包括帧头、数据和帧尾等部分。

- 数据帧解析:接收方需要能够正确解析数据帧,包括帧头、数据和帧尾的解析、校验和错误处理等。

- 数据流控制:KWP2000协议支持数据流控制功能,确保数据的有序传输和接收。

3. 应用层协议KWP2000协议的应用层协议定义了具体的诊断和通信功能。

具体协议内容包括:- 诊断服务:KWP2000协议支持多种诊断服务,如读取和清除故障码、读取传感器数据、编程和配置等。

- 诊断请求和响应:KWP2000协议规定了诊断请求和响应的格式和内容,确保诊断数据的准确传输和解析。

- 诊断会话管理:KWP2000协议支持诊断会话的建立、维护和结束,确保诊断过程的顺利进行。

KWP2000协议:应用层详细分析

KWP2000协议:应用层详细分析

保持通讯(testerPresent):0X3E
该服务ID用于空闲情况下保持诊断设备和ECU的通信,以防止ECU在超 过P3 MAX时间没有收到诊断设备信息进入休眠状态。 问题:模式一、二,该命令完整应该是什么? 模式一:0X80,0X11,0XF1,0X01,0X3E,0XC1 模式二:0X81,0X11,0XF1,0X3E,0XC1
0X18 清除诊断信息(clearDiagnosticInformation):0X14
通过局部标识读取数据(readDataByLocalIdentifier):0X21
输入输出控制(inputOutputControlByLocalIdentifier):0X30
启动通讯(startCommunication):0X81
KWP常用SID介绍
启动通讯(startCommunication):0X81
结束通讯(stopCommunication):0X82
保持通讯(testerPresent):0X3E 读取ECU信息(readEcuIdentification):0X1A
读状态诊断故障代码(readDiagnosticTroubleCodesByStatus):
读取ECU信息(readEcuIdentification):0X1A
该服务ID用于读取ECU记录的本身标识及车辆信息。ISO14230中对具 体的PID进行了定义,具体为80-9F。
其 中 0X92 systemSupplierECUHardwareNumber ( ECU 硬 件 号 ) 和 0X94 ystemSupplierECUSoftwareNumber(ECU软件号)为强制要求,其 他都为可选。
对于第4种服务的发送格式为:

KWP2000诊断通信模块的开发

KWP2000诊断通信模块的开发

故 障诊 断 模 块 是 发 动 机 电控 系 统 中 不 可 或 缺
少 的环节 之一 , 它保 证 了车辆 在 使 用 过程 中 的稳 定
1 KW P 2 0 0 0通 信 协 议
KWP 0 0协 议 , 称 IO一 1 2 0国 际标 准 , 20 亦 s 43
用 于定义 基 于 串行 数 据 连 接 的诊 断 系统 的通 用 要
Ab t a t KW P2 0 r t o s wi ey us d i h il u o tv e ce . Th a e e c ie he sr c : 0 0 p o oc li d l e n t e fed ofa t mo i ev hils e p p rd s rb s t
描述 了基 于 I0 9 4 s 1 1用 以实 现诊 断 服 务 的物
E U 的基础 上 , C 开发 了基 于 KW ] 协议 主要 由物 理层 , 数据 链 路层 和应 用层 等 3
部分 组成 .
1 1 物 理 层 .
通信 模块 , 在 系 统 中 实 现 了基 于 KWP 0 0通 信 并 20
协议 的故 障诊 断通 信.
维普资讯
第 6卷 第 5期 20 0 7年 1 0月
江 南 大 学 学 报 ( 然 科 学 版) 自
J u n l fJ a g a ie st ( t r l c e c d t n o r a in n n Un V r i Na u a in e E i o ) o y S i
Vo1 N o .6 .5 0C . 20 t 07
文 章 编 号 : 6 1 7 4 ( 0 7 0 — 0 4 —0 1 7 — 1 7 2 0 )5 5 7 4

KWP2000 瑞典车协议

KWP2000 瑞典车协议

7.4 DynamicallyDefineLocalIdentifier service7.4.1 Message description报文描述This message is used by the client (tester) to dynamically define the content of a local identifier accessible with the readDataByLocalIdentifier service. 该报文是客户端(测试器)用来动态定义本地ID,The request message may consist of multiple definitions of different definitionModes (other than clearDynamicallyDefinedLocalIdentifier).请求报文可能由多个不同定义模式的定义构成,而非仅仅清除动态定义的本地ID。

The server shall send a positive response message after it has stored the definition of the dynamicallyDefinedLocalIdentifier record. 服务器在存储了动态定义本地ID记录之后会发送肯定响应。

If the definitionMode parameter is set to clearDynamicallyDefinedLocalIdentifier this service is used by the client to clear a dynamicallyDefinedLocalIdentifier. This request message shall free up the server's memory which is used to create a dynamicallyDefinedLocalIdentifier data record. 如果定义模式参数设置是为了清除动态定义的本地ID,该服务则是客户端用来清除动态定义的本地ID。

KWP2000协议

KWP2000协议

KWP2000协议协议名称:KWP2000协议协议简介:KWP2000协议是一种用于汽车诊断通信的标准协议,它定义了在汽车电子控制单元(ECU)和诊断设备之间进行通信的规范。

该协议旨在提供一种统一的方式,使诊断设备能够与不同制造商的汽车进行通信和诊断。

协议内容:KWP2000协议包括以下几个方面的内容:1. 物理层:- 通信介质:KWP2000协议支持多种通信介质,如ISO 9141-2、ISO 14230-4和ISO 15765-4等。

- 通信速率:协议规定了不同通信介质的通信速率范围,以确保通信的稳定和可靠性。

2. 数据链路层:- 帧结构:KWP2000协议定义了数据帧的结构,包括帧起始符、数据长度、数据字段和校验位等。

- 帧类型:协议支持不同类型的帧,如初始化帧、诊断请求帧和诊断响应帧等。

- 错误检测和纠正:协议提供了校验位和重发机制,以确保数据的完整性和正确性。

3. 应用层:- 服务和功能:KWP2000协议定义了一系列的服务和功能,如读取数据、写入数据、诊断控制和故障码读取等。

- 诊断会话:协议规定了诊断会话的建立和终止过程,以及会话模式的切换规则。

- 诊断地址:协议定义了不同ECU的诊断地址,以便诊断设备能够正确地与目标ECU进行通信。

4. 错误处理:- 错误码:协议规定了一系列的错误码,用于标识和描述通信过程中的错误情况。

- 错误恢复:协议提供了错误恢复机制,包括错误帧的处理和错误状态的清除等。

5. 兼容性:- KWP2000协议具有良好的兼容性,可以与不同制造商的汽车和诊断设备进行通信。

- 协议支持不同的诊断设备接口标准,如RS-232、USB和以太网等。

协议优势:KWP2000协议作为一种标准化的汽车诊断通信协议,具有以下优势:1. 统一性:协议提供了一种统一的方式,使不同制造商的汽车和诊断设备能够进行通信和诊断,降低了诊断设备的开发和维护成本。

2. 灵活性:协议支持多种通信介质和通信速率,适用于不同类型和年份的汽车。

KWP2000协议

KWP2000协议协议名称:KWP2000协议一、引言KWP2000协议是一种用于诊断汽车电子控制单元(ECU)的通信协议。

本协议旨在规范车辆制造商和诊断设备供应商之间的通信接口,以实现车辆故障诊断、参数设置和编程等功能。

本协议适用于汽车制造商、诊断设备供应商和相关技术人员。

二、范围本协议适用于使用KWP2000协议进行车辆故障诊断、参数设置和编程的相关设备和软件。

本协议涵盖了通信协议的物理层、数据链路层、网络层和应用层的规范。

三、术语和定义在本协议中,以下术语和定义适用:1. ECU:电子控制单元,指车辆上的电子设备,例如发动机控制单元、制动控制单元等。

2. 诊断设备:使用KWP2000协议进行车辆故障诊断、参数设置和编程的设备,例如诊断仪、编程工具等。

四、物理层规范1. 通信介质:KWP2000协议支持多种通信介质,包括ISO 9141-2、ISO 14230-4和ISO 15765-4等。

2. 通信速率:KWP2000协议支持不同的通信速率,最高可达到20Kbps。

3. 连接方式:KWP2000协议采用双线制连接方式,包括K线和L线。

五、数据链路层规范1. 数据帧格式:KWP2000协议使用帧格式进行数据传输,包括起始字节、数据字节、校验字节和结束字节。

2. 数据传输方式:KWP2000协议采用主从式通信方式,诊断设备作为主站发送请求,ECU作为从站响应请求。

3. 错误检测和纠正:KWP2000协议使用校验字节进行错误检测,通过奇偶校验或循环冗余校验(CRC)进行数据完整性验证。

六、网络层规范1. 通信地址:KWP2000协议使用物理地址和功能地址进行通信,物理地址用于识别ECU,功能地址用于识别具体的诊断服务。

2. 通信会话:KWP2000协议使用会话控制字节进行通信会话的建立和终止,确保通信的可靠性和安全性。

3. 会话模式:KWP2000协议支持默认会话和扩展会话两种模式,其中默认会话用于普通诊断服务,扩展会话用于特殊诊断服务。

(汽车诊断协议KWP2000,CANBUS)sid,pid应用详细分析


详细介绍-Upload/Download Functiona点l U击n添it加标题
35- RequestUpload(请求上传)
详细介绍-Upload/Download Functiona点l U击n添it加标题
36- TransferData(数据传输)
详细介绍-Upload/Download Functiona点l U击n添it加标题
详细介绍-Input/Output Control Functio点n击al添加标题
2F- inputOutputControlByCommonIdentifier Request SId (动作测试)
详细介绍-Remote Activation Of Routin点e 击Fu添nc加ti标on题al Unit
1A- readEcuIdentification Request Service Id(读ECU版本信息) 常用在KWP2000协议中 如: Req:82 10 F1 1A 94 31 Ans:8C F1 10 5A 94 50 5F 38 32 38 20 56 34 36 20 CC
详细介绍-Data Transmission Functiona点l U击n添it加标题
37- RequestTransferExit(传输结束)
第四部分
实例分析
实例分析
14蒙迪欧大灯协议文档
点击添加标题
实例分析
14蒙迪欧大灯协议文档
点击添加标题
实例分析
14蒙迪欧大灯协议文档点击来自加标题第五部分常见SID,PID组合
常见SID,PID组合
读VIN码(车架号) 0902 22F190
17- ReadStatusOfDiagnosticTroubleCodes service (读取诊断故障代码及状态)

KWP2000协议

KWP2000协议协议名称:KWP2000协议一、介绍KWP2000协议是一种用于汽车诊断和通信的标准协议。

它定义了一套规范,用于在汽车电子控制单元(ECU)和诊断工具之间进行通信。

该协议旨在支持诊断、编程和通信功能,以便更好地管理和维护汽车系统。

二、协议结构KWP2000协议采用了基于ISO 9141-2的物理层和基于ISO 14230-3的数据链路层。

它使用了串行通信,允许通过诊断插座与汽车的ECU进行通信。

协议的结构如下:1. 物理层:KWP2000协议使用单线的K线通信,通过ISO 9141-2规范定义的物理层进行通信。

该规范定义了电气特性、通信速率和连接方式等。

2. 数据链路层:KWP2000协议使用基于ISO 14230-3的数据链路层,该层定义了数据帧的格式和传输方式。

数据链路层包括以下几个重要的部分: - 起始字节:用于标识数据帧的开始。

- 服务字节:包含了命令或响应的类型和长度信息。

- 数据字节:用于携带命令或响应的数据。

- 校验字节:用于检测数据传输的正确性。

- 结束字节:用于标识数据帧的结束。

3. 应用层:KWP2000协议的应用层定义了命令和响应的格式和含义。

它包括了以下几个重要的部分:- 诊断服务:用于执行诊断操作,如读取故障码、清除故障码等。

- 编程服务:用于对ECU进行编程操作,如刷写固件、配置参数等。

- 通信服务:用于进行ECU和诊断工具之间的通信,如建立、维护和关闭通信会话。

三、通信流程KWP2000协议的通信流程如下:1. 建立通信会话:- 诊断工具发送初始化命令(0x81)给ECU。

- ECU收到初始化命令后,返回一个肯定响应(0x83)。

- 诊断工具收到肯定响应后,建立通信会话。

2. 发送命令:- 诊断工具发送命令请求给ECU。

- ECU收到命令请求后,执行相应的操作,并返回一个响应。

3. 接收响应:- 诊断工具接收ECU返回的响应。

- 诊断工具解析响应,并根据需要执行后续的操作。

KWP2000协议

KWP2000协议一、引言KWP2000协议是一种用于汽车电子控制单元(ECU)通信的标准协议。

本协议定义了ECU之间的通信协议和数据格式,旨在实现汽车电子系统的互操作性和互通性。

本协议适用于汽车制造商、ECU供应商和汽车维修服务提供商。

二、范围本协议适用于使用K线物理层的汽车ECU之间的通信。

KWP2000协议主要包括以下方面:1. 通信物理层:定义了K线物理层的电气特性和通信速率。

2. 数据链路层:定义了数据帧的格式和错误检测机制。

3. 应用层:定义了ECU之间的通信协议和数据格式。

三、术语和定义1. ECU:电子控制单元,指汽车中的电子设备,如发动机控制单元、制动系统控制单元等。

2. K线:一种串行通信物理层接口,使用单根双绞线进行通信。

3. 数据帧:在数据链路层中传输的数据单元,包括帧头、数据字段、校验和等。

4. 服务:在应用层中定义的一组功能或命令,用于实现特定的操作或数据交换。

四、通信物理层1. 电气特性:K线的电平定义为逻辑高电平(Vhigh)和逻辑低电平(Vlow),分别对应于电压范围[Vhigh_min, Vhigh_max]和[Vlow_min, Vlow_max]。

2. 通信速率:KWP2000协议支持多种通信速率,包括5Kbps、10Kbps、15Kbps、20Kbps、40Kbps、50Kbps和80Kbps。

五、数据链路层1. 数据帧格式:KWP2000协议使用基于字节的数据帧格式,包括帧头、数据字段、校验和等。

2. 帧头:帧头由一个起始字节和一个地址字节组成,用于标识数据帧的起始和接收方地址。

3. 数据字段:数据字段包含应用层数据和控制信息。

4. 校验和:校验和用于检测数据帧传输过程中的错误。

六、应用层1. 服务请求:应用层通过发送服务请求来实现特定的操作或数据交换。

服务请求由一个服务标识符和相关参数组成。

2. 服务响应:ECU在接收到服务请求后,根据请求的类型和参数进行相应的处理,并返回服务响应。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

KWP2000协议分析及基于CANoe的开发测试刘国权,张伯英,宋卫锋(恒润科技有限公司汽车电子事业部,北京市朝阳区安翔北里甲11号创业大厦B座8层,邮编:100101)摘要:本文介绍了欧洲汽车领域广泛采用的车载诊断协议KWP2000,针对KWP2000诊断服务在K线(ISO 14230)和CAN总线(ISO 15765)上的两种实现方式,对协议的核心内容和发展历史进行了较为深入的剖析和对比。

本文还介绍了采用Matlab/Simulink/StateFlow进行协议开发的一般流程,以及该协议在Vect or公司的CANoe软硬件平台上的应用实现和开过程。

关键词:KWP2000,K线,CAN总线,开发,CANoe1 前言在汽车故障诊断领域,针对诊断设备和汽车ECU之间的数据交换,各大汽车公司几乎都制订了相关的标准和协议。

其中,欧洲汽车领域广泛使用的一种车载诊断协议标准是KWP2000(Keyword Protocol 2000),该协议实现了一套完整的车载诊断服务,并且满足E-OBD(European On Board Diagnose)标准。

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

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

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

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

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

表1 KWP2000协议与OIS模型的对应关系ISO 14230-1规定了KWP2000协议的物理层规范(K线、L线),它在ISO 9141-2的基础上把数据交换系统扩展到了24V电压系统。

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

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

表2 基于K线的KWP2000报文结构[3]1)可选字节,取决于格式字节Fmt的A1A0位2)服务标识符(Service ID),数据域的第1个字节在开始诊断服务之前,诊断设备必须对ECU进行初始化,通过ECU的响应获取ECU的源地址、通讯波特率、支持的报文头格式、定时参数等信息。

ECU所支持的报文头和定时参数信息包含在ECU返回的“关键字(K ey Word)”中(这也是协议命名的由来)。

关键字由两个字节构成,如图1所示,关键字的低字节中各位的含义如表3所示。

图1 关键字格式[3]表3 关键字低字节中各位的含义[3]*) 只允许TP0,TP1 = 0,1 或者1,0诊断设备可以采用两种方式对ECU进行初始化——5Baud初始化和快速初始化,对于这两种初始化的时序在数据链路层协议[3]中均有明确规定。

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

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

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

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

图2 K线诊断服务时序图[3]3 基于CAN总线的KWP2000协议基于CAN总线的KWP2000协议实际上指的就是ISO/WD 15765-1~15765-4,该协议把KWP2000应用层的诊断服务移植到CAN总线上。

数据链路层采用了ISO 11898-1协议,该协议是对CAN2.0B协议的进一步标准化和规范化;应用层采用了ISO 15765-3协议,该协议完全兼容基于K线的应用层协议14230-3,并加入了CAN总线诊断功能组;网络层则采用ISO 15765-2协议,规定了网络层协议数据单元(N_PDU,如表4所示)与底层CAN数据帧、以及上层KWP2000服务之间的映射关系,并且为长报文的多包数据传输过程提供了同步控制、顺序控制、流控制和错误恢复功能。

表4 网络层协议数据单元(N_PDU)格式[7]1) 地址信息:包含源地址(SA)、目标地址(TA)、目标地址格式(TA_Type)和远程地址(RA)2) 协议控制信息:包含四种帧格式,见表53) 数据域:KWP2000服务标识符(Service ID) + 服务参数应用层协议规定了四种服务数据结构,<Service_Name>.Request、<Service_Name>.Indication、<Servic e_Name>.Response和<Service_Name>.Confirm,分别用于诊断设备(Tester)的服务请求、ECU的服务指示、ECU的服务响应和Tester的服务确认。

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

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

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

为实现这一功能,网络层定义了四种PDU (以PCI类型进行区分,如表5所示):单帧(Single Frame,SF)-数据域及PCI可在一个CAN数据帧中容纳时,服务报文以单帧CAN报文进行发送。

第一帧(First Frame,FF)-数据域及PCI不能在一个CAN数据帧中容纳时,服务报文以多帧CAN报文进行发送,其中第一帧(FF)除传送数据外,还包含了多包数据的长度信息。

连续帧(Consecutive Frame,CF)-多包数据中除第一帧外的连续数据帧,除传送数据外,还包含了多包数据的包序号。

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

表5 15765协议网络层四种PDU对应的PCI格式[7]1) 单帧数据中数据域的字节长度,PCI的长度不包括在内。

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

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

4) 流控制状态信息。

5) 数据块大小。

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

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

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

图4 多包数据传输流程图在数据传送过程中,一个网络层PDU被编排成一个CAN数据帧,它们之间的对应关系由寻址模式(Addres sing mode)决定。

基于ISO 15765协议规定了四种寻址模式:正常寻址模式(Normal)、正常固定寻址模式(Normal fixed)、扩展寻址模式(Extended)和用于远程诊断的混合寻址模式(Mixed)。

其中,正常固定寻址模式必须采用CAN扩展帧,并且SAE J1939为该寻址模式下的KWP2000诊断服务保留了两个专用参数组编号(PGN):其中PF=218(PF的具体定义请参考SAE J1939数据链路层协议)的参数组用于物理寻址(phy),PF=219的参数组用于功能寻址(fcn)。

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

表6 正常固定寻址模式下N_PDU与CAN数据帧之间的对应关系[7]混合寻址模式与正常固定寻址模式类似,唯一的区别是CAN数据域的第一个字节用于填充远程地址(RA),N_PCI和诊断服务数据的填充位置向后移动一个字节。

混合寻址模式用于跨越网段进行远程诊断,远程诊断的机制如图5所示。

图中CAN1和CAN2两个不同的子网通过网桥相连,网桥在子网1中的源地址为200,在子网2中的源地址为10,位于子网1中的诊断设备(源地址为241)可通过网桥对子网2中的ECU(源地址为62)进行诊断。

图5 跨越网段的远程诊断4 两种协议的简单比较从前面基于K线和基于CAN总线的KWP2000协议可以看出,两种协议在物理层、数据链路层及网络层(15 765)上存在以下主要差别,这也是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位),对于长报文的传输,网络层协议还具备标准化和规范化的同步控制、顺序控制、流控制和错误恢复等功能,具备很高的可靠性、兼容性。

相关文档
最新文档