⼀、UDS概述

1. UDS概念

UDS（Unfied Diagnostic Services）—— 统⼀诊断服务

UDS是能够通过⼀套统⼀的诊断命令与汽⻋进⾏通信，读取汽⻋的相关数据，也可以向汽⻋中写⼊ ⼀些数据。

UDS的特点：统⼀

统⼀常⻅的汽⻋品牌、零部件⼚商的ECU

统⼀常⻅的汽⻋总线协议（CAN、LIN、FlexRay、⻋载以太⽹、K-Line）

UDS的作⽤

读取ECU的故障信息

刷写ECU（更新ECU中的固件程序）

读取/写⼊信息（汽⻋的VIN、ECU的序列号、ECU固件的版本号、ECU下线的⽇期时间）

UDS遵循的ISO标准

ISO-14229（应⽤层）、ISO-15765（⽹络传输层、基于CAN）、……

2. UDS是请求/响应模式的

Tester（诊断仪）发送请求（request）给ECU，ECU处理后返回响应给Tester。

请求和响应的本质都是报⽂数据（基于CAN总线的CAN报⽂）

响应根据成功或失败可以分为：肯定响应（Positive Response）、否定响应（Negative Response）

ECU的诊断地址

每个ECU都有⼀个唯⼀的请求ID和响应ID，专⽤于接收UDS请求命令和进⾏UDS响应报⽂发送 的

这个请求ID和响应的ID本质上都是CAN报⽂的ID

很多ECU都有⾏业上标准的诊断请求和响应ID，例如：

EMS的ECU的请求ID是7E0、响应ID是7E8

诊断的ID都是7开头的

物理地址和功能地址:

每个ECU各⾃的唯⼀请求ID就是这个ECU请求的物理地址

功能地址是所有ECU公⽤的地址请求地址

收到这个ID的请求，那么所有的ECU都会进⾏处理

//物理地址和功能地址

引擎ECU 请求的物理地址为 0x7E0, 响应地址0x7E8

空调ECU 请求的物理地址为 0x720, 响应地址0x728

⻋⻔ECU 请求的物理地址为 0x760, 响应地址0x768

这些ECU的功能地址均为 0x7DF（企业中实际上ECU的功能地址都设置为7DF）

场景1（单聊 @XXX ECU）【物理地址】

请求：Tester --> 0x760报⽂ --> ⻋⻔ECU

响应：⻋⻔ECU --> 0x768报⽂ --> Tester

场景2（群聊 @所有⼈）【功能地址】

请求：Tester --> 0x7DF报⽂ --> 发给所有ECU

响应：引擎ECU --> 0x7E8报⽂ --> Tester

响应：空调ECU --> 0x728报⽂ --> Tester

响应：⻋⻔ECU --> 0x768报⽂ --> Tester

UDS的报⽂是整体放在CAN报⽂数据域中的

image.png

⼆、UDS协议的详解

1. 每⼀帧UDS的报⽂⼜分为“⽹络传输层”的数据和“应⽤层”的数据

⽹络传输层的数据主要是控制UDS报⽂的拆包、装包、流程控制的

为什么要分包装包：UDS协议本身规定⼀个UDS命令最多可以有4095个字节，那么可能⼀帧 CAN报⽂装不下⼀个UDS命令，⼀个UDS命令只好被拆成很多帧 —— 拆包。

应⽤层的数据才是UDS最核⼼的常⽤服务命令。

2. UDS⽹络传输层协议规定的详解

image.png

⽹络传输层规定，UDS的报⽂分为单帧和多帧

如果⼀帧CAN报⽂能发送完所有数据，就是⽤[单帧]

如果⼀帧CAN报⽂不能发送完所有数据，就使⽤多帧，其中有：[⾸帧]、[连续帧]、[流控制]

多帧发送的过程

image.png

//【多帧】发送过程中的报⽂解析

【⾸帧（Sender 发给 Receiver）】

分析：10 7B

⾸位是1，所以是⾸帧，因此紧接着的07B就是本次多帧的UDS数据的总字节数

07B --> 123

【流控制（Receiver回给Sender）】

分析：30 00 14

⾸位是3，所以是流控制，那么剩下的PCI（协议控制信息）为：

FS（发送流程的控制状态） —— 0

0：代表可以继续发后⾯的连续帧

1：暂停发送后⾯的连续帧，直到等到我再次给你发流控制

2：本次多帧的整个发送重置，可能是发送⽅想要发的数据太多,接收⽅数据缓存不够

BS（Block Size 块⼤⼩）—— 00

允许发送⽅后续继续发送的连续帧的数量，00表示不限制（允许发送⽅尽情的发送，把连续帧都发

完）

STmin（最⼩间隔时间）—— 14

要求发送⽅后续发送连续帧时，每⼀个连续帧发送出来被接收⽅收到后，最少间隔多少毫秒后，再

发下⼀帧，00表示不⽤间隔

【典型的较⻓的⼀个UDS报⽂的多帧实例】

10 7B YY YY YY YY YY YY

30 00 14 00 00 00 00 00

21 YY YY YY YY YY YY YY

22 YY YY YY YY YY YY YY

23 YY YY YY YY YY YY YY

24 YY YY YY YY YY YY YY

25 YY YY YY YY YY YY YY

26 YY YY YY YY YY YY YY

27 YY YY YY YY YY YY YY

28 YY YY YY YY YY YY YY

29 YY YY YY YY YY YY YY

2A YY YY YY YY YY YY YY

2B YY YY YY YY YY YY YY

2C YY YY YY YY YY YY YY

2D YY YY YY YY YY YY YY

2E YY YY YY YY YY YY YY

2F YY YY YY YY YY YY YY

20 YY YY YY YY YY YY YY

21 YY YY YY YY YY 00 00

下面是两个示例:

连续帧

单帧

三、UDS应⽤层协议（UDS的常⽤的服务命令）详解

1. 应⽤层协议的⼀般规定

Tester可以发送UDS所规定的各项服务，每项服务有各⾃唯⼀固定的服务ID（SID）

UDS规定了6⼤类26个服务项，每个服务项有⾃⼰唯⼀的固定SID

请求发送的应⽤层第1个字节就是 请求的SID

当ECU收到Tester发送的请求后，处理后发回响应报⽂给Tester，响应报⽂分肯定响应和否定响应

肯定响应报⽂的第1个字节为 请求的SID + 0x40

否定响应报⽂的第1个字节固定为 7F ，第2个字节为 请求的SID ，第3个字节为 NRC 否定响 应码

⼀个特殊的否定响应码（NRC）是 78 ，并不是代表失败了，⽽是会晚⼀点给回响应

image.png

常⻅的否定响应码（否定响应的原因：失败的原因）

NRC

2. 六⼤类26个服务

image.png

3. 0x10服务(会话状态控制）

ECU有三种会话状态：默认会话（default）、扩展会话（extended）、编程会话（programming）

ECU上电后就处于默认会话状态

不同的会话状态下，能做的事情不⼀样

我们可以使⽤ 0x10 服务来切换会话状态

注意点1：要想切换到编程会话，必须先进⼊扩展会话

注意点2：当处于⾮默认会话状态时，超过了ECU所设定的最⼤⾮活动时间，会⾃动跳回到默认 会话状态

image.png

//0x10服务的请求和响应

============================================

肯定响应的实例

============================================

Tester：10 03

【10服务，且使⽤03⼦功能，表示要切换到扩展会话状态】

ECU： 50 03 00 96 00 C8

【50表示肯定响应，03代表切换到扩展会话状态成功】

p2 time为：00 96 => 150(ms)

p2ex time为：00 C8 * 10 => 200 * 10 => 2000(ms)

⾔外之意：

本次会话过程中，后续你每⼀个请求，我会在150ms内进⾏响应。

但如果你某⼀次请求，我给回你的是NRC为78的否定响应时，那么你这个请求我可能要处理的慢⼀

点，但会在2000ms给出响应。

============================================

否定响应的实例

============================================

Tester：10 02

【10服务，且使⽤02⼦功能，表示要切换到编程会话状态】

ECU: 7F 10 33

【7F表示否定响应，10表示否定的SID，33是NRC：代表没有权限】

4. 0x3E服务（诊断仪在线）

每隔⼀段时间（⼩于服务器⾃动跳回默认会话的时间间隔），发送⼀次3E请求给ECU

Tester都能配置⾃动发送3E服务请求

image.png

5. 0x27服务（获取安全访问的权限、解锁ECU）

image.png

image.png

使⽤0x27服务的注意点

必须在扩展会话模式下进⾏0x27服务操作

必须要为Tester设置好⼚商提供的安全算法程序的dll⽂件，以供Tester在发送27 02服务时计算key值

dll文件的配置:

image.png

6. 0x11服务（重启/复位ECU）

image.png

7. 0x22服务（根据DID读取数据）

ECU内部可以存储很多数据，那么多的数据，每⼀个数据，都有⼀个唯⼀的数据标识，这个标识被 称为DID。

DID代表的是某⼀项数据的名称，不是值。

ECU中存储的⼤量的数据的DID都有⼀些⾏业标准，例如：

ECU的序列号的DID为：F1 8C

汽⻋的VIN码的DID为：F1 90

协议规定，ECU中存储的数据DID必须是2个字节

image.png

读取ECU的序列号的诊断实例（国际惯例，ECU序列号的DID为F1 8C）

image.png

读取ECU的标识名的诊断实例（国际惯例，ECU的标识名的DID为F1 89）

image.png

8.0x2E服务（根据DID写⼊数据）

image.png

写⼊⻋窗当前升降百分值的数据

image.png

9. 0x19服务（读取故障信息的）

19服务主要是⽤于读取ECU的⼀些故障相关信息，使⽤不同的⼦功能完成具体的不同任务，如下：

01 —— 读取ECU中的故障码的数量

02 —— 读取ECU中的故障码

04 —— 读取ECU中故障码的快照信息（发⽣故障的时候的相关数据：⻋速、⽔温、……）

0A —— 读取ECU所⽀持的故障码列表

19 01⼦功能

19 01 的语法

image.png

19 01的诊断命令实例

image.png

19 02 ⼦功能

19 02的诊断命令的语法

image.png

19 02的诊断命令实例

image.png

10. 0x14服务（清除故障信息）

使⽤ 14 FF FF FF 清除所有ECU中存储的故障码

四、诊断故障码（DTC）

1. 故障码的基本概念

DTC（Diagnostic Trouble Code）—— 诊断故障码

产品设计时，会根据产品硬件罗列出所有可能的故障，并为每个特定的故障分配⼀个代码，这个代 码就是诊断故障码（DTC）。

如定义供电电压过低的故障码为U2E0468，诊断故障码可以理解为故障的身份证号。如Tester 读取到U2E0468，便知道发⽣了供电电压过低的故障，这个故障会在供电电压持续低于8.6V 3 秒后产⽣，⽽当供电电压持续⼤于9V 5秒后消失。

UDS的3个字节DTC（基于UDS with ISO15031-6/SAE J2012-DA）

image.png

故障内码

示例:

image.png

2. 故障内码

image.png

UDS故障码的内码

故障码内码实例（两个字节）：0 0 0 0 1 1 1 0 0 0 1 1 0 0 1 0

故障码内码实例（五位故障码）：P0E32

2个字节中的第1-2个bit代表五位故障码的第1位（代表的是P0E32中的P）：

0（P）：动⼒系统

1（C）：底盘系统

2（B）：⻋身系统

3（U）：⽹络控制系统

2个字节中的第3-4个bit代表五位故障码的第2位（代表的是P0E32中的0）：

0、2、3：ISO/SAE

1：制造商

2个字节中的第5-8个bit代表五位故障码的第3位（代表的是P0E32中的E）：

发⽣故障的⼦系统区域

0-2：燃油和空⽓质量测量系统

3：点⽕系统

A-E：混合动⼒系统

2个字节中的第9-12个bit代表五位故障码的第4位（代表的是P0E32中的3）

故障的具体位置信息

2个字节中的第13-16个bit代表五位故障码的第5位（代表的是P0E32中的2）

故障的具体位置信息

3. 故障类型字节（FTB）

image.png

4. 故障码的状态

UDS使⽤1个字节描述故障码的状态信息

这1个字节上的8个bit，每个bit都代表某⼀种状态

⼀个故障码可能同时处于多个状态

每个bit代表的含义

读取到的ECU返回的⼀个⼗六进制的【故障码信息】的字节报⽂：

02 51 00 09

DTC（前3个字节：故障内码+FTB）—— 02 51 00

P025100

DTC状态（第4个字节）—— 09

已确认的故障（历史和当前均有）

⼆进制： 0 0 0 0 1 0 0 1

bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0

常⻅的故障码状态

01 —— 当前错误

08 —— 已确认的故障（历史故障）

09 —— 已确认的故障（历史和当前均有）

原文链接：https://blog.csdn.net/2201_76134806/article/details/134699888