好文档就是一把金锄头!
欢迎来到金锄头文库![会员中心]
电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本

UDS最全内容总结.doc

18页
  • 卖家[上传人]:wdg****h8
  • 文档编号:306759300
  • 上传时间:2022-06-09
  • 文档格式:DOC
  • 文档大小:232.50KB
  • / 18 举报 版权申诉 马上下载
  • 文本预览
  • 下载提示
  • 常见问题
    • 前言2UDS 的7种服务及肯定响应和否定响应的形式2$10诊断会话2$3E待机握手2$27安全访问2$22读数据2$2E写数据2$19 读DTC2$14清除DTC2统一诊断服务 (Unified diagnostic services , UDS) (一)2Diagnostic request的格式:2统一诊断服务 (Unified diagnostic services , UDS) (二)2Diagnostic Session Control (0*10)2诊断response的格式:Diagnostic Session Control2ECU Reset 诊断request的格式2Security Access (0*27)2统一诊断服务 (Unified diagnostic services , UDS) (三)2Tester Present (0*3E)2Control DTC Setting (0*85)2Response On Event (0*86)2Link Control (0*87)2统一诊断服务 (Unified diagnostic services , UDS) (四)2Read Data By Identifier (0*22)20*23服务的请求格式0*232统一诊断服务 (Unified diagnostic services , UDS) (五)20*14:Clear Diagnostic Information20*19:Read DTC Information2统一诊断服务 (Unified diagnostic services , UDS) (六)2Input Output Control By Identifier (0*2F)2Routine Control (0*31)2统一诊断服务 (Unified diagnostic services , UDS) (七)2Request Download (0*34):2Transfer Data(0*36):2Request Transfer E*it(0*37):2基于CAN总线实现的UDS诊断(DoCAN)2. z.-前言UDS协议即ISO14229,是Unified Diagnostic Services,统一诊断服务,是诊断服务的规范化标准,比如读取故障码应该向ECU发什么指令,读数据流又是发什么指令。

      OBD是关注车辆售后实时排放的理念形成的行业规范,而UDS是诊断服务的统一化规范,只是应用层的规范UDS(Unified diagnostic services),与OBD最大的区别就在于“Unified”上,UDS是面向整车所有ECU(电控单元)的,而OBD是面向排放系统ECU的简单说UDS而言,它只是一个应用层协议(ISO 14229-1),所以它既可以在CAN线上实现(见下图.1),甚至也能在Ethernet上实现(DOIP, Diagnostic over Internet protocol 见下图.2)并且,UDS提供的是一个诊断服务的基本框架,主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来,所以基于UDS协议的诊断又常常被称为Enhanced diagnostic(增强型诊断),UDS不是法规要求的,没有统一实现标准,其优势在于方便生产线检测设备的开发,同时更大的方便了售后维修保养和车联网的功能实现UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议,位于OSI模型中的应用层,它可在不同的汽车总线(例如CAN, LIN, Fle*ray, Internet 和K-line)上实现。

      UDS协议的应用层定义是ISO 14229-1,目前大部分汽车厂商均采用UDS on CAN的诊断协议如下图所示,ISO 14229-1也就是UDS协议仅对应用层做出了定义,物理层有双绞线和光纤供用户选择,数据链路层采用CAN总线的ISO 11898-1协议,针对Classical CAN仅有8个字节的数据场与应用层可处理多帧数据的矛盾,ISO 15765-2对网络层进行了定义CAN的8字节数据场会腾出一帧来表示网络层的信息下图右侧是排放相关的协议,ISO 15031-5主要针对OBD协议,为法规强制要求车厂满足的协议学习时,我们应在了解CAN总线基本知识的前提下,着重学习ISO 15765-2和ISO 11898-1的协议内容,并通过BootLoader作为例子,对UDS有一个大致的了解UDS 的7种服务及肯定响应和否定响应的形式UDS本质上是一系列的服务,共包含6大类26种每种服务都有自己独立的ID,即SIDSID: (Service ID (Identifier)以下简称SID)Service,诊断服务IDUDS本质上是一种定向的通信,是一种交互协议(Request/Response),即诊断方给ECU发送指定的请求数据(Request),这条数据中需要包含SID。

      如果是肯定的响应(Positive Response),回复[SID+0*40],就是请求10,响应50;请求22,响应62,回复的是一组数据如果是否定的响应(Negative Response),回复[7F+SID+NRC],回复的是一个声明肯定响应和否定响应的形式一定要熟记UDS的26种服务中,有7种很重要它们分别是:$10Diagnostic Session Control(诊断会话),$14Clear Diagnostic Information(清除诊断信息),$19Read DTC Information,$22Read Data By Identifier(通过ID读数据),$27Security Access(安全访问),$2EWrite Data By Identifier(通过ID写数据),$3ETester Present(待机握手)下面对这7个服务进行解读10诊断会话Diagnostic Session Control (0*10)DiagnosticSessionControl诊断request的格式DiagnosticSessionControl这个服务的SID是0*10,request固定为2个byte,第一个byte是SID,第二个byte的低7bit是sub-function,用于指示ECU将进入的session。

      UDS定义的session包括:0*00 ISOSAEReserved(保留)0*01 defaultSession0*02 ProgrammingSession0*03 e*tendedDiagnosticSession0*04 safetySystemDiagnosticSession0*05 – 0*3F ISOSAEReserved(保留)0*40 – 0*5F vehicleManufacturerSpecific(由整车厂自定义使用)0*60 – 0*7E systemSupplierSpecific(由ECU供应商自定义使用)0*7F ISOSAEReserved(保留)DiagnosticSessionControl用于控制ECU在不同的session之间进行转换,session可以看作是ECU所处的一种软件状态,在不同的session中诊断服务执行的权限不同 ECU上电之后,默认处在defaultSession中,在这个session中很多诊断服务不可以执行,很多诊断相关的数据不能读取或写入一般的诊断仪启动之后,会给ECU发送10 03,即让ECU进入 e*tendedDiagnosticSession中,在这个session中可执行的诊断服务就很多了。

      而如果要让ECU保持在non-defaultSession中,则需要诊断仪每隔固定的时间发送0*3E服务,ECU才会知道诊断仪有和自己通信的需求,从而保持在non-defaultSession中另一个常用的session是ProgrammingSession,在这个session中可以进行软件刷写的一系列诊断服务0*40 – 0*5F 这个范围中的session由整车厂自定义使用,比如,*些诊断服务或诊断数据的操作需要在生产线上执行,即所谓的End-Of-Line,整车厂可以从这个范围中选择一个值来表示EOL session;又或者在开发阶段需要*种“超级”session,则也可以从这里选一个值用来使ECU进入开发模式的sessionDiagnosticSessionControl这个服务非常简单,但是它却是ECU和诊断通信的第一条诊断命令10包含3个子功能,01 Default,02 Programming,03 E*tended,ECU上电时,进入的是默认会话(Default)如果您进入了一个非默认会话的状态,一个定时器会运转,如果一段时间内没有请求,则到时间后,诊断退回到默认会话01。

      当然,我们有一个$3E的服务,可以使诊断保持在非默认的状态UDS包含4种类型,即SID,SID+SF(Sub-function),SID+DID(Data Identifier)(读写用),SID+SF+DIDNRC:Negative Response Code(否定响应码)如果ECU拒绝了一个请求,它会回应一个NRC不同的NRC有不同的含义14229-1协议第329页单词:Consult(查阅) Session(会话) DTC (diagnostic trouble code)故障码Handling(处理) Conditions(条件) restricted(受限的) Concept(概念)SA(source address 源地址) TA(目标地址)例子:以CAN总线网络举例八个帧数据字节,第一字节被网络层占用请求(Request):02 10 02 ** ** ** ** ** ; 02中的0代表网络层单帧SF,2代表数据域有2个字节;SF,数据域有2个字节,10是SID,02是子功能肯定响应:02 50 02 ** ** ** ** **;02同上,10+40表示对SID的肯定回复,02是子功能。

      否定响应:03 7F 10 22 ** ** ** **;03同上,7F表示否定响应,10是SID,22是NRC3E待机握手Tester Present (0*3E)这个诊断服务的用处可以通过它的名字很明显地得知,即告知ECU诊断仪还在连接着在上一篇文章中我说到了关于session的部分,如果没有诊断命令的发送和接收,ECU将从non-default session中回退到default session, 0*3E就是用于使ECU保持在当前session这应该是UDS中最简单的一个诊断服务了,它永远只有两个byte,格式如下:0*3E诊断服务的格式当sub-function是0*00时,ECU要给出response;当sub-function是0*80时,ECU不需要要给出response一般来说主机厂会为这个服务定义两个时间参数,一个参数用于规定自己的诊断仪发送0*3E服务的间隔,另一个参数用于定义ECU收不到0*3E服务的timeout时间3E服务用于向服务器指示诊断仪仍然连接在网络上,之前已经激活的。

      点击阅读更多内容
      关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
      手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
      ©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.