相信像我这样的小白第一次接触汽车诊断协议肯定有点懵逼,什么鬼kwp2000,那什么又是ISO-14230,ISO-15765,ISO-14229,UDS,UDSonCAN???它们到底是什么关系,还有什么又是基于K线的KWP2000,基于CAN的KWP2000???嗯,慢慢来,一定不要混淆这些协议,首先对这些协议进行初步认识:

一、初步认识

KWP 2000和IS0-14230
在汽车故障诊断领域,针对诊断设备和汽车ECU之间的数据交换,最早欧洲出现了一种标准诊断协议KWP2000(Keyword Protocol 2000),又名关键字协议。
那时候KWP2000是基于K线的诊断协议,(一条线K,或者两条线K和L)那具体KWP2000协议是什么?这时候就要讲讲ISO-14230协议。
当时的KWP2000只三个子层有定义说明,即:应用层、数据链路层和物理层。并且这三个层都由ISO-14230-1、ISO-14230-2、ISO-14230-3定义标准,所以一直都这么说,ISO-14230就是KWP2000。

ISO-14229和UDS
先知道一件事,ISO-14229协议就是UDS(Unified diagnostic services),这个标准定义了诊断的应用层服务,不基于任何底层标准。它是诊断服务的规范化标准,比如读取故障码应该向ecu发什么指令,读数据流又是发什么指令等…

ISO-15765 和UDSonCAN
由于K线物理层和数据链路层在网络管理和通讯速率上的局限性,使得K线无法满足日趋复杂的车载诊断网络的需求。这时候CAN总线出现并代替了K线,也就是我们说的ISO-15765。ISO-15765是基于CAN,它的ISO-15765-2、ISO-15765-3定义了诊断数据网络层和应用层的定义标准。

又因为ISO-15765-3使用了ISO-14229(UDS)的诊断服务,所以ISO-15765也叫UDSonCAN。

再看他们的关系


又有人把ISO-14230称为基于K线的KWP2000协议,把后面发展称为Can线的ISO-15765称为基于基于CAN的KWP2000协议
其实都可以,不混淆就行,基于K线的KWP2000协议就是ISO-14230,基于CAN的KWP2000协议就是ISO-15765或者UDSonCAN!!!!

改个名字也行~

二、1. KWP 2000协议

KWP 2000协议是最常用的通信协议之一,又称为关键字协议,因为这种协议在系统进入时,会涉及到关键字的校验而得名。
K线KWP2000协议是异步半双工进行通讯的,通常采用10416BPS的波特率;空闲电平通常为12V。
其实很简单,就是用一条K线进行数据通讯,然后制定一些协议而已。
下面系统初始化进入、帧结构、命令交互、交互时间参数、常用命令字等几个方面来介绍这种协议。

1、系统进入初始化
有两种初始化方式,主要是用第一种初始化。由设备先发送25ms的拉低电平,然后是25ms的高电平(空闲电平),然后再发送系统进入数据,系统进入数据通常为5个字节,ECU响应7个字节,完成系统初始化交互。请参见下图:

第二种初始化方式为设备发送5BPS或者200BPS的地址码,ECU响应55H,KW1,KW2,设备对KW2取反发回给ECU,ECU对地址码取反发回给设备,完成系统初始化交互。其中55H这个字节用来规定后面的通信波特率。参见下图

2、帧结构
命令头(1个或多个字节)+命令体(1个或多个字节)+校验(通常为和校验)

在命令头中,包括以下几个部分的内容:格式+目标地址+源地址+长度字节。长度信息有时候在格式字节中体现,则不需要另外的长度字节,长度信息用以表示命令体的内容;目标地址和源地址有时候也会没有。
命令体的内容中:命令字+命令内容。命令内容可以没有。
举例如下:

81H 11H F1H 81H 04H

第一个字节81H为格式+长度信息(80+1)
第二个字节11H为目标地址
第三个字节F1H为源地址
第四个字节81H为命令字,表示系统进入
最后一个字节04H为前面4个字节的校验和
同样,也可能表现如下:(命令字)
80H 11H F1H 01H 3EH C1H
这种情况下,长度字节放在源地址之后
还可能表现为:
02H 1AH 9AH B6H
这种情况下,格式字节和目标地址源地址都已经没有了
还有一种特殊的情况,在上一种情况的基础上,在帧数据之前,加一个00,例如:
00H 02H 1AH 9AH B6H
但这种帧结构的情况极少

3、命令交互
命令交互通常情况下为1对1,但也存在1对多或者多对1的情况。下面是一组命令交互举例:
Tools: 81H 31H F1H 81H 24H
ECU: 83H F1H 31H C1H E9H 8FH DEH
在交互中,因为发送命令的对象不一样,所以目标地址和源地址是进行了互换;
同时,ECU响应设备的命令字在设备命令字的基础上 + 0x40(肯定回答)

还有否定回答,即回复 7F
Tools: 0x81, 0x11, 0xF1, 0x81, 0x04,
ECU: 0x83, 0xF1, 0x11, 0x7F, 0x81, 0x21, 0xA6,

4、交互时间参数
设备发送命令字节间的时间间隔P1,通常为5ms
ECU返回命令字节间的时间间隔P2,通常为0ms
设备发送完一帧命令后等待ECU响应的时间P3,通常为75ms~90ms
设备接收到ECU响应后到发送下一帧命令的时间P4,通常为20ms~26ms

5、常用命令字

系统进入:81H
系统退出:82H
链路保持:3EH
读故障码:18H
清除故障码:14H
读版本信息:1AH
读数据流:21H

6、数据格式

发送一字节的数据格式为(重点):
起始位 + 数据 + 停止位
1 + 8 + 1
如下:

7、实训
从最底层开始,直接看K线的电平变化吧
截一段设备向ECU发送请求的数据:

**IO[0]:**用作K线通讯发送和接收数据的端口,变化电平高低(1,0)表示数据位的值
T:表示电平持续的时间

一个数据位的时间 = 1/波特率即: 1 / 10416 = 95 ns(约等于)

那就简单了,把上面电平持续时间时间除以95,可以得出K线的电平变化情况:

单位:一个数据位的时间单位

把每字节的起始位和结束位去掉,可以很容易看出,这个设备发送命令字节间的时间间隔P1,为4.5ms
所以解析一下电平图代表的数据实际是:

注意:数据先从低位开始发送,0000 0001 实际为 1000 0000 则 0x80

向ECU发送请求的数据为:0x80,0x11,0xF1,0x01
这段数据是没实际作用的,因为原地址后面没有命令字,没发实有用的命令

随便再搞一段ECU返回设备的数据:

电平持续时间时间除以95,可以得出K线的电平变化情况:

可知ECU返回命令字节间的时间间隔P2,为0ms
同上解析方法,很容易得出实际的数据为:


ECU返回设备的数据为:0x81,0xF1,0x11,0x7E
意思:ECU返回链路保持

大家对比发来的数据,是不是发现问题,校验位呢???

实际ECU返回设备的数据是:0x81,0xF1,0x11,0x7E,0x01 ,因为取的电平图漏了一字节,还有一个校验位没截完…好吧我也懒得从新取数据了,大家知道就好

注意:这两段电平不是对应的一发一收的,是我取两条简单的来解析,所以请求和返回没对应起来,大家不要误会

三、待续

汽车诊断协议,(K线/CAN总线、kwp2000、ISO14230、ISO1575...)相关推荐

  1. 汽车诊断协议,(K线/CAN总线、kwp2000、ISO14230、ISO1575...)(转)

    相信像我这样的小白第一次接触汽车诊断协议肯定有点懵逼,什么鬼kwp2000,那什么又是ISO-14230,ISO-15765,ISO-14229,UDS,UDSonCAN???它们到底是什么关系,还有 ...

  2. 14229汽车诊断协议学习笔记

    14229汽车诊断协议学习笔记 什么是14229协议 诊断服务基本知识 确认的服务 未确认的服务 请求原语格式 响应原语格式 诊断分层结构 诊断服务 诊断会话控制(0x10)服务 ECU 重置(0x1 ...

  3. 汽车诊断协议(K线/CAN总线、kwp2000、ISO14230、ISO1575...)

    一.初步认识 KWP 2000和IS0-14230  在汽车故障诊断领域,针对诊断设备和汽车ECU之间的数据交换,最早欧洲出现了一种标准诊断协议KWP2000(Keyword Protocol 200 ...

  4. 基于CAN总线的汽车诊断协议UDS (网络层 ISO 15765)

    上个月一个同事Z跳槽去了德赛西威,Z之前是完全不懂诊断的MCU工程师,去德赛后做诊断开发,让我感觉到,汽车嵌入式行业,CAN和诊断工程师还是比较稀缺的.之前我和Z共同负责一个项目,我负责CAN网络和诊 ...

  5. GD32 汽车诊断协议J1850-PWM 测试

    J1850-PWM 硬件说明:  MCU: GD32C103 120M,128K,32k RAM.  输入:USB 5V.  OBD功能口定义:OBD(2,10)VPWM.OBD 7(K线).O ...

  6. GD32汽车诊断协议 ISO-9141测试

    硬件说明:  MCU: GD32C103 120M,128K,32k RAM.  输入:USB 5V.  OBD功能口定义:OBD(2,10)VPWM.OBD 7(K线).OBD 6(CAN H ...

  7. 基于CAN总线的汽车诊断协议UDS(上位机开发网络层及错误代码解析)

    UDS协议栈的开发和测试对于刚刚接触UDS协议的开发人员来说,不但需要阅读大量的标准文档,短时间内很难理解透彻,标准协议栈代码的编写更加困难,刚入门又没有快捷简单的测试工具帮助加快理解和验证,使得UD ...

  8. 汽车诊断协议 - KWP2000

    KWP2000协议是最常用的通信协议之一,是属于OBDII标准协议的一种.KWP系统又称为关键字协议,因为这种协议在系统进入时,会涉及到关键字的校验而得名.下面从物理层特性.系统进入.帧结构等几个方面 ...

  9. 基于CAN总线的汽车诊断协议UDS的开发重点

    一.意义 为了指导开发工程师,正确的使用诊断模块,快速开发出满足车厂要求的诊断功能. 二.诊断模块介绍 此诊断模块根据ISO-14229-1文档,并结合部分车厂的文档进行开发,使用面向对象的思路进行设 ...

最新文章

  1. 第十九章 代码重用 5包含对系统的消耗
  2. 企业网络推广方案浅析网站优化中外链该怎么发布?
  3. 利用jquery给指定的table动态添加一行、删除一行
  4. 微软在Skype推出LGBT骄傲月表情与贴纸
  5. 20170204-py
  6. oracle package lock,Oracle 11g下重现library cache lock等待事件
  7. 在javafx中界面主题_最小的JavaFX演示文稿(在JavaFX中)
  8. 番石榴分配器vs StringUtils
  9. ubuntu修改字体 样式
  10. java实践项目_Java项目开发实践
  11. java clone原理_详解Java中的clone方法 -- 原型模式
  12. 为什么ElasticSearch应用开发者需要了解cluster state
  13. html加载时页面闪烁白色背景,解决页面加载闪白问题-背景图片加载优化
  14. 十分钟释疑Oracle中“小表超慢”之谜(SQL调优/SQL优化)
  15. Qt学习笔记(十九):QTreeWidget 的常用方法
  16. java实现微信公众号的模板消息推送
  17. 海康大华摄像头GB/T28181接入国标视频平台如何选择主码流还是子码流
  18. html背景图片固定代码
  19. linux 删除回收站文件,浅析linux下的回收站以及U盘中的.Trash文件夹
  20. 2021-08-16

热门文章

  1. 生鲜APP开发解决方案
  2. 2023最新完整版python安装教程
  3. 数据结构 浙江大学 2019春期末考试
  4. 30多岁零基础想转行学编程,来得及吗?
  5. 超全面!用户生命周期分析攻略
  6. 使用 vue 开发 APICloud 应用的教程
  7. seata报错问题总结 Unable to commit against JDBC Connection
  8. MATLAB中写TXT文件换行的实现
  9. ctf网络安全大赛web
  10. 十进制负数转换成二进制数的方法