UDS诊断概述

UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议,位于OSI模型中的应用层,它可在不同的汽车总线(例如CAN, LIN, Flexray, 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本质上是一系列的服务,共包含6大类26种。每种服务都有自己独立的ID,即SID。

SID:Service Identifier,诊断服务ID。UDS本质上是一种定向的通信,是一种交互协议(Request/Response),即诊断方给ECU发送指定的请求数据(Request),这条数据中需要包含SID。如果是肯定的响应(Positive Response),回复[SID+0x40],就是请求10,响应50;请求22,响应62,回复的是一组数据。如果是否定的响应(Negative Response),回复7F+SID+NRC,回复的是一个声明。

肯定响应和否定响应的形式一定要熟记。

UDS的26种服务中,有7种很重要。它们分别是:$10 Diagnostic Session Control(诊断会话),$14 Clear Diagnostic Information(清除诊断信息),$19 Read DTC Information,$22 Read Data By Identifier(通过ID读数据),$27 Security Access(安全访问),$2EWrite Data By Identifier(通过ID写数据),$3E Tester Present(待机握手)。下面对这7个服务进行解读。

$10诊断会话

$10包含3个子功能,01 Default,02 Programming,03 Extended,ECU上电时,进入的是默认会话(Default)。如果您进入了一个非默认会话的状态,一个定时器会运转,如果一段时间内没有请求,那么到时间后,诊断退回到默认会话01。当然,我们有一个$3E的服务,可以使诊断保持在非默认的状态。

UDS包含4种类型,即SID,SID+SF(Sub-function),SID+DID(Data Identifier)(读写用),SID+SF+DID。

NRC: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 xx xx xx xx xx ; 02是网络层单帧SF,数据域有2个字节,10是SID,02是子功能。

肯定响应:02 50 02 xx xx xx xx xx;02同上,10+40表示对SID的肯定回复,02是子功能。

否定响应:03 7F 10 22 xx xx xx xx;03同上,7F表示否定响应,10是SID,22是NRC。

$3E待机握手

$3E服务用于向服务器指示诊断仪仍然连接在网络上,之前已经激活的诊断服务功能可以仍然保持激活状态。

例子:02 3E 80 00 00 00 00 00,发送一个3E服务的报文,保持非默认会话状态。80表示无需回复。

$27安全访问

$27安全访问:ECU当中有很多数据是整车厂独有的,并不希望开放给所有客户,它需要做一个保密的设定。我们在读取一些特殊数据的时候,要先进行一个安全解锁ECU上电之后是一个锁定的状态(Locked),我们通过$27服务,加上一个子服务,再加上一个钥匙,这样的服务请求可以进行解锁。比如下面的例子,2n-1是一个子服务,通过首轮种子的请求,首轮ECU会返回67+01+AA+BB+CC+DD,AA~DD就是种子了。之后第二轮,诊断端会利用种子进行运算(利用整车厂的算法),生成k1(不一定是1个字节),那么发送请求,27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时,解锁(Unlocked)成功。

$27安全访问服务的否定响应服务ID也是7F。还记得刚才否定响应的格式吗?7F+27+NRC(否定响应码)。

例子:

Rx: 02 27 05 00 00 00 00 00 安全访问,05子功能

Tx: 07 67 05 08 27 11 F0 77 肯定响应,回复了对应安全级别的种子

Rx: 06 27 06 FF FF FF FF 00 发送密钥,4个FF。注意06是与05成对使用的。

Tx: 03 7F 27 78 00 00 00 00 否定响应,7F+27+NRC

Tx: 02 67 06 00 00 00 00 00 肯定响应,通过安全校验

$22读数据

$22读数据,Request(请求):22+DID(Data Identifier,通常是两个字节)

Response(响应):62+DID+Data

DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符,0xF187就是车厂备件号数据标识符,0xF188就是车厂ECU软件号码数据ID,0xF189就是车厂ECU软件版本号数据标识符。

14229-1协议第339页

$2E写数据

$22写数据,Request(请求):2E+DID+Data

Response(响应):6E+DID

注意,比如0xF186这个DID不支持直接写入数据,需要用$10来进行会话转换。也就是说,对于写数据的请求,一般来说需要在一个非默认会话,和解锁的状态下才能进行。

$19 读DTC

DTC(diagnostic trouble code):如果系统检测到了一个错误,它将存储为DTC。DTC可表现为:一个显而易见的故障;通讯信号的丢失(不会使故障灯亮起);排放相关的故障;安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节,OBD II占用两个字节。图中FTB为Fault Type Byte。

故障码包括四个大类,分别是PCBU,P是powertrain动力系统,C是Chassis底盘,B是Body车身,U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。LowByte暂不清楚。

$19拥有28个子服务(Sub-Function)。常用的子服务有02(通过DTC状态掩码读取DTC),04(读取快照信息),06(读取扩展信息),0A(读ECU支持的所有DTC数据)。

刚才提到,一个DTC除了它自己的3个字节,还有一个字节专门用于表达DTC的状态。这个状态字节每个位的含义可以查询ISO 14229-1。注意,并不是所有的DTC状态都是支持的。下图是Request/Response。括号标识循环,可以读出很多DTC。

$14清除DTC

清除(复位)DTC格式,它可以改变DTC的状态。3个FF代表清除所有DTC。

Request:14+FF+FF+FF;

Response:54 。

我们刚才学完了7种重要的服务,SID。除此之外,在CAN总线中,Addressing information寻址信息通过CAN帧ID体现出来。

通讯的模式分两种,一种是物理寻址点对点),根据物理地址的不同进行访问,但只能访问单个ECU节点,Test为SA源地址,ECUX作为TA目标地址;对应的,另一种是功能寻址广播),根据功能的不同进行访问,它能访问多个ECU节点。

每一个ECU都有2个CAN帧ID,分别对应收和发的物理寻址

以上只是一些粗浅的理解。对26种服务更详细的解读请自行百度。

UDS应用的设备

在UDS 诊断产品中知名度最高,应用最广泛的是德国Vector公司的CAN case 配合其CANoe 软件,Vector 产品功能齐全,适合系统级汽车总线开发,被大部分汽车厂商采用。Vector 产品因不开放API,不能做二次开发且价格昂贵,不适用于硬件开发团队和生产线的自动化测试。目前市面上有很多CAN 厂商(如Kvaser, ZLG 等)能提供低成本、体积小、驱动简单、开放API 的设备,很适合进行二次开发。

杂记

变速器控制单元TCU和防抱死系统ABS是CAN车载网络上的两大电子控制单元, 这2个ECU要通过CAN网络进行大量的信息交互。但是由于电磁干扰、串扰、静电等外界干扰或电控单元本身控制策略引起的通信停止等原因, 2个控制单元之间可能会出现通信丢失的现象。控制系统需要将故障信息(例如通信丢失故障信息) 诊断出来, 以处理通信被破坏时出现丢失帧的故障现象, 并记录为DTC (diagnostic trouble code)。

ECU的输入信号主要有4种形式: ①模拟信号(水温、油压、蓄电池电压等); ②数字信号(各种开关信号等); ③PWM信号(脉冲信号、频率信号等); ④网络信号(CAN、LIN上传输的信号)。微控制器可以通过监测这些信号来判别输入电路的工作状况。输出的信号往往用作控制电磁阀、指示灯、步进电机等, 大多数为数字信号。

学习资料:

1.统一诊断服务 (Unified diagnostic services , UDS) (一)

2.统一诊断服务 (Unified diagnostic services , UDS) (二)

3.统一诊断服务 (Unified diagnostic services , UDS) (三)

4.统一诊断服务 (Unified diagnostic services , UDS) (四)

5.统一诊断服务 (Unified diagnostic services , UDS) (五)

6.统一诊断服务 (Unified diagnostic services , UDS) (六)

7.统一诊断服务 (Unified diagnostic services , UDS) (七)

8.基于CAN总线实现的UDS诊断(DoCAN)

9.【图文】UDS诊断服务_百度文库

10.CAN诊断基础-上部分_图文_百度文库

11.CAN诊断-下_已读_图文_百度文库

12.ISO 14229+统一诊断服务

13.FlashBootloader_图文_百度文库

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

15.ISO 15031-5-2015

16.ISO 15765-3车载诊断标准-详细中文版

17.吉利汽车基于CAN线诊断技术规范_百度文库

代码参考:

1.SAE J1939 协议源代码分析(一)-程序结构框架

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

3.基于CAN总线的汽车诊断协议UDS(ECU底层模块移植开发) - CSDN博客

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

原创文章 96 获赞 48 访问量 6万+

UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议,位于OSI模型中的应用层,它可在不同的汽车总线(例如CAN, LIN, Flexray, Internet 和K-line)上实现。UDS协议的应用层定义是ISO 14229-1,目前大部分汽车厂商均采用UDS on CAN的诊断协议。

猜你喜欢

转载自blog.csdn.net/wteruiycbqqvwt/article/details/101076617