UDS：统⼀诊断服务

再学三分钟

已于 2023-12-26 14:05:22 修改

阅读量3.7k

点赞数 35

分类专栏： CANoe #自动测试文章标签：汽车测试工具

于 2023-11-29 22:05:05 首次发布

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

版权

CANoe 同时被 2 个专栏收录

5 篇文章 4 订阅

订阅专栏

#自动测试

4 篇文章 2 订阅

订阅专栏

⼀、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

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

⼆、UDS协议的详解

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

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

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

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

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

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

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

多帧发送的过程

//【多帧】发送过程中的报⽂解析
【⾸帧（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 ，并不是代表失败了，⽽是会晚⼀点给回响应

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

2. 六⼤类26个服务

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

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

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

不同的会话状态下，能做的事情不⼀样
我们可以使⽤ 0x10 服务来切换会话状态

注意点1：要想切换到编程会话，必须先进⼊扩展会话
注意点2：当处于⾮默认会话状态时，超过了ECU所设定的最⼤⾮活动时间，会⾃动跳回到默认会话状态

//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服务请求

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

使⽤0x27服务的注意点

必须在扩展会话模式下进⾏0x27服务操作
必须要为Tester设置好⼚商提供的安全算法程序的dll⽂件，以供Tester在发送27 02服务时计算key值

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

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

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

DID代表的是某⼀项数据的名称，不是值。
ECU中存储的⼤量的数据的DID都有⼀些⾏业标准，例如：

ECU的序列号的DID为：F1 8C
汽⻋的VIN码的DID为：F1 90
协议规定，ECU中存储的数据DID必须是2个字节

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

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

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

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

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

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

01 —— 读取ECU中的故障码的数量
02 —— 读取ECU中的故障码
04 —— 读取ECU中故障码的快照信息（发⽣故障的时候的相关数据：⻋速、⽔温、……）
0A —— 读取ECU所⽀持的故障码列表

19 01⼦功能

19 01 的语法

19 01的诊断命令实例

19 02 ⼦功能

19 02的诊断命令的语法

19 02的诊断命令实例

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）

2. 故障内码

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）

4. 故障码的状态

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

这1个字节上的8个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 —— 已确认的故障（历史和当前均有）