专家
公告
财富商城
电子网
旗下网站
首页
问题库
专栏
标签库
话题
专家
NEW
门户
发布
提问题
发文章
NXP
【分享】ISO14229 1~7需要的来拿
2020-02-11 08:53
发布
×
打开微信“扫一扫”,打开网页后点击屏幕右上角分享按钮
站内问答
/
51单片机
13145
33
33
UDS协议,分享给大家,需要的自己下载。
友情提示:
此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
33条回答
kevin_me
2020-02-13 10:10
前言
由于工作中经常用到ISO-14229,因此决定对该协议做个总体介绍和总结,既是对自己学习的总结,也能够给初次涉及该协议的朋友一个参考。
首先简要介绍什么是ISO-14229,至于可以在网上找到的大篇理论介绍我就略过不讲了,有兴趣可以自行搜索。简单的说,它就是一个用于汽车行业诊断通信的需求规范,它只规定了与诊断相关的服务需求,并没有涉及通信机制,因此要实现一个完整的诊断通信还需要定义网络层协议(比如ISO-15765),还有底层硬件实现方式(比如CAN控制器)。由于不涉及网络通信机制,可以架设在各种网络之上,因此ISO-14229也称为UDS(Unified Diagnostic Services)。
1. 用途
ISO-14229的用途就是规定了诊断需求,因此想要了解ISO-14229的用途首先要知道诊断的用途。诊断最先用于汽车尾气排放的监测,后来发展为包括对汽车行驶故障的监测,想知道诊断的发展史,可以维基百科。至少现代的诊断可以粗略的分为排放相关和非排放相关,ISO-14229只定义非排放相关的诊断需求。非排放相关诊断可以做什么呢?其实用途很大,基本贯穿整个汽车ECU生命周期。首先,ECU开发时要用到它来构建bootloader,上传和下载数据;测试时要用它来读写RAM、ROM,控制外设;在产线上,要用它来校准机械件,刷新软件;在行驶过程中,要用它来监测各种故障,并记下故障码;在4S店,技师需要用它来读出故障码,判断故障发生点,还可以用来升级ECU程序。现在大热的车联网概念,其中一些就是通过OBD口联网,读取车内故障码,或者油量、速度等参数。
2. 诊断通信分层结构
虽然借鉴OSI的七层结构,但是诊断通信分层还是做了一些改变。可以参考如下列表:
无标题.png
(19.53 KB, 下载次数: 0)
下载附件
2018-6-26 13:25 上传
显然,从上表可以看出诊断通信分层模型和OSI的区别,同时也可以看到ISO-14229在该模型中的位置。其实,可以将该模型简化为:
- 统一诊断服务层 (layer 7)
- 网络服务层 (layers 1 to 6)
因此,在使用ISO-14229时,下面的通信机制可以改变,比如基于CAN,基于蓝牙,基于LAN,基于FlexRay等等。
3. 相关术语
3.1 协议相关术语
要了解协议,首先要知晓协议内定义的术语。我挑了一些使用频率比较高的在此解释。
1. Diagnostic Service (诊断服务)
诊断服务是介于诊断设备和被诊断ECU之间的一种信息交互方式。通常是由诊断设备发出请求,被诊断ECU做出回应。
2. Diagnostic Trouble Code (故障码)
故障码是用来标记ECU故障的代码,它遵循一定的规则(以后会介绍),驻留在ECU的非易失性存储器中。
3. Diagnostic Data (诊断数据)
诊断数据是可以被诊断设备请求的ECU内部数据,它包括:
-当前数据,即ECU正在使用的某个数据,比如车速、节气门角度等
-存储数据,即被ECU存储在存储器中某一时刻的数据,比如DTC
-静态数据,即恒定不变的ECU内部数据,比如VIN码。
4. Diagnostic Session (诊断会话)
可以理解为某种诊断模式或权限,即在不同的模式下,对不同的诊断服务的使用做了限制。
5. Diagnostic Routine (诊断例程)
驻留在被诊断ECU中的子程序,它可以被诊断设备启动和停止。比如格式化EEPROM的子程序。
6. Tester, 就理解为诊断设备或诊断仪吧。
3.2 诊断服务相关术语
再来说一些跟诊断服务相关的术语。
1 Addressing Type (寻址方式)
寻址方式指的是诊断消息的传递方式,有两种寻址方式:
-Physical ,物理寻址,即1对1通信,用于知道确切的被诊断ECU的地址
-Functional,功能寻址,即1对n通信,或者说广播发送,用于不知道确切的被诊断的ECU的地址,向一组或者全体ECU发送请求
2 Result
Result指的是tester请求诊断服务执行后,从ECU的返回结果。可以有两种结果:
-Positive Response,正响应,即诊断请求执行成功
-Negative Response,负响应,即诊断请求执行失败
3 Service Identifier
Service Identifier可以简称为SID,它是一个一字节的无符号整数,用以指代某个诊断服务。诊断协议为每一个诊断服务都分配了唯一一个SID,因此更方便协议的软件实现。同时,在日常工作中工程师们用SID来指代某个诊断服务比说出某个服务的名字更方便简洁。比如ReadDataByIdentifier这个服务是去按照ID去读某个诊断数据,直接说22服务会更加方便。
4 Data Identifier
简称DID,是2个字节无符号整数的ID,用来标识ECU中贮存的某个诊断数据单元。它的好处是当要读取某个单元的诊断数据时,只要读对应的DID就可以,不必知道数据的具体地址。即使当ECU中的数据地址发生变化时,只要DID和某个地址单元的映射地址改变即可,对于使用者来说DID屏蔽了具体实现细节,而将重点放在了数据本身。
5 Negative Response Code
可以简称为NRC,或者叫错误响应码,是一个字节的无符号整数。它是诊断协议为每一种执行失败的诊断服务分配的失败原因代号。
6 Sub-function
有些诊断服务可以支持不同的诊断子服务,sub-function就是用来定义这种子服务的,它将某一个服务细分为更为具体的服务,它是一个字节的无符号整数。比如ECUReset这个服务就有0x01,0x02,0x03等几种sub-function指代具体的reset方式。
原文链接:
https://www.cnblogs.com/autogeek/p/4458591.html
请问楼主,是在从事汽车软件行业吗?发展怎么样?
加载中...
查看其它33个回答
一周热门
更多
>
相关问题
手把手学会例程系列:i.MX<二>:图解i.mx53源码补丁+烧录(...
59 个回答
从零开始MQX开发之二 创建与调试MQX项目
24 个回答
7009: Trim value invalid, value is blank or zero是什么错误
0 个回答
怎么头像消失啊?
23 个回答
求推荐KINETIS评估板:必备USB HS,ETHERNET
5 个回答
相关文章
基于IMX6Q移植uboot2018-09——添加单板
0个评论
IMX6UL定时器按键消抖实验
0个评论
I.MX6U处理器LED灯点亮汇编程序代码编写
0个评论
在NXP I.MX6上做一个基于Opencv和OpenGL的打砖块游戏
0个评论
【RFID安全】浅谈卡片破解
0个评论
LM75a
0个评论
emwin字库制作及汉字显示
0个评论
STM32学习之I2C
0个评论
×
关闭
采纳回答
向帮助了您的知道网友说句感谢的话吧!
非常感谢!
确 认
×
关闭
编辑标签
最多设置5个标签!
NXP
保存
关闭
×
关闭
举报内容
检举类型
检举内容
检举用户
检举原因
广告推广
恶意灌水
回答内容与提问无关
抄袭答案
其他
检举说明(必填)
提交
关闭
×
打开微信“扫一扫”,打开网页后点击屏幕右上角分享按钮
×
付费偷看金额在0.1-10元之间
确定
×
关闭
您已邀请
0
人回答
查看邀请
擅长该话题的人
回答过该话题的人
我关注的人
由于工作中经常用到ISO-14229,因此决定对该协议做个总体介绍和总结,既是对自己学习的总结,也能够给初次涉及该协议的朋友一个参考。
首先简要介绍什么是ISO-14229,至于可以在网上找到的大篇理论介绍我就略过不讲了,有兴趣可以自行搜索。简单的说,它就是一个用于汽车行业诊断通信的需求规范,它只规定了与诊断相关的服务需求,并没有涉及通信机制,因此要实现一个完整的诊断通信还需要定义网络层协议(比如ISO-15765),还有底层硬件实现方式(比如CAN控制器)。由于不涉及网络通信机制,可以架设在各种网络之上,因此ISO-14229也称为UDS(Unified Diagnostic Services)。
1. 用途
ISO-14229的用途就是规定了诊断需求,因此想要了解ISO-14229的用途首先要知道诊断的用途。诊断最先用于汽车尾气排放的监测,后来发展为包括对汽车行驶故障的监测,想知道诊断的发展史,可以维基百科。至少现代的诊断可以粗略的分为排放相关和非排放相关,ISO-14229只定义非排放相关的诊断需求。非排放相关诊断可以做什么呢?其实用途很大,基本贯穿整个汽车ECU生命周期。首先,ECU开发时要用到它来构建bootloader,上传和下载数据;测试时要用它来读写RAM、ROM,控制外设;在产线上,要用它来校准机械件,刷新软件;在行驶过程中,要用它来监测各种故障,并记下故障码;在4S店,技师需要用它来读出故障码,判断故障发生点,还可以用来升级ECU程序。现在大热的车联网概念,其中一些就是通过OBD口联网,读取车内故障码,或者油量、速度等参数。
2. 诊断通信分层结构
虽然借鉴OSI的七层结构,但是诊断通信分层还是做了一些改变。可以参考如下列表:
无标题.png (19.53 KB, 下载次数: 0)
下载附件
2018-6-26 13:25 上传
显然,从上表可以看出诊断通信分层模型和OSI的区别,同时也可以看到ISO-14229在该模型中的位置。其实,可以将该模型简化为:
- 统一诊断服务层 (layer 7)
- 网络服务层 (layers 1 to 6)
因此,在使用ISO-14229时,下面的通信机制可以改变,比如基于CAN,基于蓝牙,基于LAN,基于FlexRay等等。
3. 相关术语
3.1 协议相关术语
要了解协议,首先要知晓协议内定义的术语。我挑了一些使用频率比较高的在此解释。
1. Diagnostic Service (诊断服务)
诊断服务是介于诊断设备和被诊断ECU之间的一种信息交互方式。通常是由诊断设备发出请求,被诊断ECU做出回应。
2. Diagnostic Trouble Code (故障码)
故障码是用来标记ECU故障的代码,它遵循一定的规则(以后会介绍),驻留在ECU的非易失性存储器中。
3. Diagnostic Data (诊断数据)
诊断数据是可以被诊断设备请求的ECU内部数据,它包括:
-当前数据,即ECU正在使用的某个数据,比如车速、节气门角度等
-存储数据,即被ECU存储在存储器中某一时刻的数据,比如DTC
-静态数据,即恒定不变的ECU内部数据,比如VIN码。
4. Diagnostic Session (诊断会话)
可以理解为某种诊断模式或权限,即在不同的模式下,对不同的诊断服务的使用做了限制。
5. Diagnostic Routine (诊断例程)
驻留在被诊断ECU中的子程序,它可以被诊断设备启动和停止。比如格式化EEPROM的子程序。
6. Tester, 就理解为诊断设备或诊断仪吧。
3.2 诊断服务相关术语
再来说一些跟诊断服务相关的术语。
1 Addressing Type (寻址方式)
寻址方式指的是诊断消息的传递方式,有两种寻址方式:
-Physical ,物理寻址,即1对1通信,用于知道确切的被诊断ECU的地址
-Functional,功能寻址,即1对n通信,或者说广播发送,用于不知道确切的被诊断的ECU的地址,向一组或者全体ECU发送请求
2 Result
Result指的是tester请求诊断服务执行后,从ECU的返回结果。可以有两种结果:
-Positive Response,正响应,即诊断请求执行成功
-Negative Response,负响应,即诊断请求执行失败
3 Service Identifier
Service Identifier可以简称为SID,它是一个一字节的无符号整数,用以指代某个诊断服务。诊断协议为每一个诊断服务都分配了唯一一个SID,因此更方便协议的软件实现。同时,在日常工作中工程师们用SID来指代某个诊断服务比说出某个服务的名字更方便简洁。比如ReadDataByIdentifier这个服务是去按照ID去读某个诊断数据,直接说22服务会更加方便。
4 Data Identifier
简称DID,是2个字节无符号整数的ID,用来标识ECU中贮存的某个诊断数据单元。它的好处是当要读取某个单元的诊断数据时,只要读对应的DID就可以,不必知道数据的具体地址。即使当ECU中的数据地址发生变化时,只要DID和某个地址单元的映射地址改变即可,对于使用者来说DID屏蔽了具体实现细节,而将重点放在了数据本身。
5 Negative Response Code
可以简称为NRC,或者叫错误响应码,是一个字节的无符号整数。它是诊断协议为每一种执行失败的诊断服务分配的失败原因代号。
6 Sub-function
有些诊断服务可以支持不同的诊断子服务,sub-function就是用来定义这种子服务的,它将某一个服务细分为更为具体的服务,它是一个字节的无符号整数。比如ECUReset这个服务就有0x01,0x02,0x03等几种sub-function指代具体的reset方式。
原文链接:https://www.cnblogs.com/autogeek/p/4458591.html
请问楼主,是在从事汽车软件行业吗?发展怎么样?
一周热门 更多>