UDS
本文最后更新于2 天前,其中的信息可能已经过时,如有错误请发送邮件到big_fw@foxmail.com

一、UDS简介

1.1汽车诊断

汽车诊断是指对汽车进行故障检测和定位的过程,它是确保汽车安全和性能的重要环节。

在汽车维修和开发工作中,诊断工具是必不可少的设备。通过诊断工具,技师可以读取车辆的故障码,进而定位故障原因。汽车软件 开发或者测试人员也可以通过诊断工具连接到汽车的电子系统,读取和解析车辆的实时数据。而汽车诊断协议就是指诊断工具与车辆之间 的通信协议。目前,市场上最常见的两种汽车诊断协议是OBD(On-Board Diagnostics)和UDS(Unified Diagnostic Services)。

1.2两种常见的诊断协议 OBD&UDS

OBD和UDS是两种常见的诊断协议,它们在目标和应用领域上存在一些区别。OBD协议主要用于监测车辆的排放情况,通过读取车 辆的故障码来判断是否符合排放标准。而UDS协议则更加全面和灵活,在各个ECU上是一种通用型的协议。

OBD:

主要用于跟汽车排放系统相关的ECU(电子控制单元,汽车上的板级控制器)的诊断。OBD协议分为两种:OBD-I(美国)和OBD-II(1996年实施)。

因此,OBD标准可以看作一系列标准的集合,是具有强制标准需要参照的,是由法规要求的,其最初目的是环保,用于汽车排放系统相关的ECU上。

UDS:

UDS是一种通用的汽车诊断协议,由欧洲汽车制造商协会(ACEA)和日本汽车制造商协会(JAMA)共同制定。它与OBD最大的区别就在于“Unified“上,是面向整车所有ECU的。单就UDS而言,它只是一个应用层协议(ISO14229-1),不关心应用层以下的实现,比如执行该协议的应用层程序不关心通过何种物理传输方式实现与ECU硬件的通信,因此它既可以基于CAN线通信去实现,也能在Ethernet上实现。并且,UDS提供的是一个诊断服务的基本框架,定义了一系列的诊断服务和通用化的诊断流程,主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来,所以基于UDS协议的诊断又常常被称为Enhanced diagnosic(增强型诊断)。

可见,UDS不是法规要求的,没有统一实现标准,可以基于该协议提供的诊断请求及响应格式进行二次开发。

简言之,UDS服务主要用于诊断设备Tester(Client)和ECU(Server)之间的诊断通信,诊断设备(Tester)发送诊断请求 (request),ECU给出诊断响应(response),通过这种“一问一答”的形式让目标ECU执行一些期望的操作,而UDS就是为不同类型 诊断功能的request和response定义了统一的内容和格式。

二、相关术语介绍

2.1 Service ID(SID)

在UDS协议中,Service ID(SID)是指服务标识符,用于标识要执行的服务。每个服务都有一个唯一的SID,在诊断会话中通过SID来区分要执行/响应哪种服务请求。14229-1中定义了26种服务并将这些服务分为6大类诊断和通信管理类、数据传输类、存储数据传输类、输入输出控制类、例程功能类、上传下载类。

Ps:加粗为常用服务

2.2 诊断请求

诊断请求是指诊断工具向车辆发送的请求消息,用于请求执行某个服务。诊断请求消息由三个部分组成:SID、子功能和实际数据。其中,SID用于标识要执行的服务,至于子功能:指的是这个服务还能更进一步的划分或者具有启动/暂停之类的子功能。

尽管服务类型不尽相同,但UDS针对这些服务定义了统一的诊断请求包的格式,每个诊断请求由1个Byte的SID+1个Byte的sub-function(实际上是1bit spr+7bit sub-function)+不定长的实际数据构成,其格式如下所示:

Ps:spr存在的目的是告诉ECU针对某个服务请求是否需要发送正响应数据,用于减少ECU发送不必要的响应,节约系统资源:

spr=1,抑制正响应,即ECU不给出正响应; spr=0,需要ECU给出正响应,如果某个服务没有sub-function,即没有第二个字节,那默认是要发正响应的。

2.3 正响应/负相应

诊断工具向车辆发送服务请求后,如果服务执行成功,则返回的响应消息称为正响应,反之返回的响应消息称为负响应。

2.3.1正响应报文格式

正响应报文的字节组成格式如下所示:

2.3.2 负相应报文格式

负响应消息由两部分组成:SID和负响应码(NRC)。SID用于标识响应的服务,负响应码指示服务执行失败的原因。 负响应报文的字节组成格式如下所示:

2.4 负相应码

三、相关服务

3.1 诊断会话控制

10 诊断会话控制

01- 默认会话模式

02- 编程会话模式

03- 拓展会话模式

04- 安全系统诊断会话模式

服务功能:诊断会话控制启用服务器中一组特定的诊断服务/功能,

通俗解释:就是请求不同的诊断服务需要在不同的会话模式下进行。

应用场景:

当执行27或者28等非常规服务时,则需要在非默认会话下执行,在默认会话下则不能够使用;

当需要重新编程Server时,那么此时需进入到编程会话下,这样所有与编程会话相关的诊断服务便可以设定仅允许在该session下运行;

当整车制造商或者零部件供应商需要在自定义的seesion下完成某些特别的操作时,可以采用10服务控制,如产线内部使用的特定服务便可以在其自定义的会话下进行,避免与客户的会话下服务需求起冲突。

举例

该服务的SID是0x10,发送帧固定为2个byte第一个byte是SID,第二个byte的低7bit 是sub-function,用于指示ECU将进入的session。例如:发送10 03,ECU正响应之后从 默认会话进入外部扩展会话。

请求帧:02代表请求的数据字节数10 01,两个字节;

回复: 06代表ECU回复的数据字节数;

00 32 01 F4代表上述两个时间参数

当进入到编程会话时且当前车速条件不满足,此时Client发送诊断指令”10 02″请求Server进入编程模式时,Server将会回复“7F 10 22”来告诉请求者当前进入编程会话的条件不满足,请再次检查进入编程会话的条件。

3.2 ECU复位

11 ECU复位

01 – 硬重置

02 – 点火钥匙关闭/重置

03 – 软重置

04 – 启动快速断电

05 – 禁用快速断电

服务功能: 该服务请求ECU根据请求消息中的ResetType(重置类型)参数值的内容有效地 执 行ECU重置。成功重置后(ECU正响应该服务请求),进入defaultSession (默认会话)。

通俗解释: 执行该命令之后,ECU退出之前的服务进入默认会话,类似初始化操作

举例:

ECUReset 这个服务的 SID是0x11,request固定为2个byte,第一个byte是SID,第 二个byte的低7bit是sub-function,用于指示ECU将模拟哪种方式进行重启

图中的第一字节02代表发送的字节数11 01以及回复的字节数51 01的长度。

大家看上图首先是进入了10 03外部扩展会话,并且请求3E服务让ECU保持在该会话。 正常情况下该会话可以直接进入10 02编程会话。但是由于我们使用11 01重置了ECU,让其进入默认会话,因此在重置后请求10 02会出现ECU否定响应7F 10 7E (请求顺序 有误 )以此证明重置成功。

3.3 安全访问

27 安全访问

01 – 请求Seed 1

02 – 发送Key 2

服务功能:由于(保密、排放或安全的原因),安全访问服务提供一种方法以方便访问受限制的数据或诊断服务。

举例:

第一个字节就是SID,后边的一个字节 用于标识将要访问的安全访问类型。

红色框内是请求Seed的帧格式,绿色框是请求对比密钥的帧格式。

总结:27安全访问就是进入重要区域的门禁,要想进入要先获取认证

3.4 通讯控制

28 通讯控制

00 – 启用Rx和Tx

01 – 启动Rx和禁用Tx

02 – 禁用Rx和启用Tx

03 – 禁用Rx和Tx

04 – 根据强化的地址信息启用Rx和禁用Tx

05 – 根据强化的地址信息启用Rx和Tx

00 01一般通讯报文

00 02网络管理报文

00 03一般通讯报文和网络管理报文

1.服务功能: 通讯控制服务用于开启/关闭电控单元对某些报文的发送或接收

2.控制类型:

总共有四种控制类型图中的约定列中: M代表强制,U代表可选倘若下图 是整车厂发来的诊断规范,那么在开发的时候就必须支持00和03

此图和上面00.01.02.03子服务相同

3.报文类型:

通信的报文类型所要控制通信的报文类型,如下图强制要支持 01(一般通信报文)

请求报文组合如下

28 00 01:使能一般报文的收发

28 00 02:使能网络报文的收发

28 00 03:使能一般和网络报文的收发

28 03 01:禁止一般报文的收发

28 03 02:禁止网络报文的收发

28 03 03:禁止一般和网络报文的收发

举例:

28 03 01禁止发送和接收一般通信报文(除了网络报文和诊断报文,都统称一般通信报文,即APP报文)

当诊断工具收到ECU回复的正响应68 03。该节点就不会收发一般通信报文。只收 发网络报文和诊断报文

见上面报文数据图可知,正响应的报文是02 68 03 AA AA AA AA AA

02:正响应数据长度2字节,0x68 0x03

68: 回复ID 0x28 +0x40= 0x68 (统一规范规则

AA:未使用的字节填充0xAA (一般整车厂会告知你未使用的位应该用什么数字来填充

3.5按标识符读数据

22按标识符读取数据

1.服务功能:用户通过请求该服务,读取指定dataldentifler (数据标识符DID) 所记录的数据值。

2.应用场景

读取当前ECU的序列号,版本号等

标定成功后读取内部标定结果等;

读取当前ECU所处在的Session,内部状态,Snapshot Data等

其他需要读取内部相关参数的场合

举例:

第一个字节就是SID,后边的两个字节 用于标识将要读取的DID

红色框内即是请求读取DID为0xF195的一报文

例如当尝试读取F190的DID值且当前车速条件不满足,此时Client发送诊断指令”22 F1 90″请求Server读取数据,Server将会回复“7F 22 22”来告诉请求者当前读取数据的条件不满足,请再次检查读取该DID的条件。

当发送报文长度或者格式不对时,则Server会回复”7F 22 13″;

当诊断请求的DID太多导致超出了传输层的限定时,则Server会回复”7F 22 14“;

当诊断请求DID不存在或者在当前Session中不支持时,则Server就会回复“7F 22 31”;

当Server在发生复位前处于security lock状态,那么此时Server则会回复”7F 22 33″;

4.较为常见的DID种类及其含义:

2.6 按标识符写数据

2E 按标识符写数据

1.服务功能:用户通过请求该服务,写指定dataldentifler (数据标识符DID) 所记录

的数据值到 NVMQ中(非易失性存储,上下电不会被清除的空间,如: EEPROM,ROM,一般常 用DataFlash仿EE,性价比高)

2.应用场景:

在整车下线的过程中写入相关配置信息,如常见的VIN码

清除NVM;

重置已写入到Flash中的数据

其他需要写入内部相关参数的场合

3.常用的DID及含义

举例

第一个字节就是SID,后边的两个字节 用于标识将要读取的DID

例如:我们写入车辆的十七位vin码,那么请求报文格式: 2E f1 90 AA AA AA AA AA…… (注意:请求多帧数据在请求时需要加入留空帧,报文长度大于8字节的统称于多帧数据。)

上图所示:10 0c是通过22服务读取得到F1 94是DID后面30是我们要写入的数据由于数据大于8个字节就有了第二行,30依旧是要写入的数据,为了表示这两条报文是属于一条报文数据,就用21开头来体现。

例如当尝试写入F190的DID值且当前车速条件不满足,此时Client发送诊断指令”2E F1 90″请求Server读取数据,Server将会回复“7F 2E 22”来告诉请求者当前读取数据的条件不满足,请再次检查读取该DID的条件。

当发送报文长度或者格式不对时,则Server会回复”7F 2E 13″;

当诊断请求DID不存在或者在当前Session中不支持时,则Server就会回复“7F 2E 31”;

当Server在发生复位前处于security lock状态,那么此时Server则会回复”7F 2E 33″;

当2E服务写入的内存地址错误时,那么此时Server则会回复”7F 2E 72 “;

四、其他

bit就是位,也叫比特位,是计算机表示数据最小的单位

byte就是字节

1byte=8bit

1byte就是1B

一个字符=2字节

1KB=1024B

1.字节就是Byte,也是B

2.位就是bit也是b

3.转换关系如下:1)1KB=1024B

  1. 1B= 8b

文末附加内容
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!