《UDS协议从入门到精通（UDS速查手册）》持续更新中...-Toy模板网

这篇具有很好参考价值的文章主要介绍了《UDS协议从入门到精通（UDS速查手册）》持续更新中...。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

常用服务已更新完毕，后面将陆续更新不常用服务。

一、前言

汽车软件开发/测试工作中不免涉及到UDS协议。实际上该协议的应用不仅仅局限于最常见的汽车故障检测工作中（比如4S店对汽车故障的快速定位），在车载ECU间的通信、数据传输、ECU软件的升级刷写等场景中都有着广泛的应用。
经查阅各类资料和网络文章，仔细阅读14229-1协议标准，集众多网友、博主以及自己对该协议的理解，在本专栏针对UDS 14229-1中定义的全部26种服务作详细阐述，并以图示方式给出直观的通信示例，可以作为一部中文UDS手册，便于随手查询。

一、UDS简介

1.1 从汽车诊断说起

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

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

Tip📌：诊断工具也就是下文常提到的Tester，它可以是任何实现了通信协议的东西，比如可以是一个实现了UDS协议的上位机软件、实际的硬件设备（4S店的诊断仪）甚至是一个实现了UDS协议的系统中的测试脚本。

在过去的几十年里，汽车诊断系统经历了巨大的变革和发展。起初，汽车诊断主要依靠人工检测和经验判断来发现问题。随着科技的进步，电子系统在汽车中的应用越来越广泛，汽车诊断也逐渐走向了自动化和数字化。从最初的简单故障指示灯到现在的复杂电子控制单元（ECU）和诊断协议的应用，汽车诊断技术已经取得了长足进步。

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

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

OBD（On-Board Diagnostic）：
主要用于跟汽车排放系统相关的ECU（电子控制单元，汽车上的板级控制器）的诊断。OBD协议分为两种：OBD-I和OBD-II。OBD-I是由美国为当时制造的加州汽车所制定的排放法规，随后这套法规被逐渐标准化，于是又提出了OBDII标准，包括：标准化的车载ECU数据诊断接口（SAE-J1962，也就是现在常说的OBD接口）、标准化的诊断解码工具（SAE-J1978）、标准化的诊断协议（ISO 9141-2、ISO 14230-4、ISO 15765-4）、标准化的故障码定义（SAE-J2012、ISO 15031-6）、标准化的维修服务指南（SAE-J2000），OBD-II在1996年开始实施，目前已经成为全球汽车行业的标准。因此，OBD标准可以看作一系列标准的集合，是具有强制标准需要参照的，是由法规要求的，其最初目的是环保，用于汽车排放系统相关的ECU上。

UDS（Unified diagnostic services）：
UDS（Unified Diagnostic Services）是一种通用的汽车诊断协议，由欧洲汽车制造商协会（ACEA）和日本汽车制造商协会（JAMA）共同制定。它与OBD最大的区别就在于“Unified“上，是面向整车所有ECU的。单就UDS而言，它只是一个应用层协议（ISO 14229-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大类：诊断和通信管理类、数据传输类、存储数据传输类、输入输出控制类、例程功能类、上传下载类。

Tip📌：表格中标黄部分为常用的服务，其他的不常用。

大类	SID (Hex)	诊断服务名	服务Service
诊断和通信管理类	10	诊断会话控制	Diagnostic Session Control
	11	ECU复位	ECU Reset
	27	安全访问	Security Access
	28	通讯控制	Comunication Control
	3E	待机握手	Tester Present
	83	访问时间参数	Access Timing Parameter
	84	安全数据传输	Secured Data Transmission
	85	控制DTC的设置	Control DTC Setting
	86	事件响应	Response On Event
	87	链路控制	Link Control
数据传输类	22	通过ID读数据	Read Data By Identifier
	23	通过地址读取内存	Read Memory By Adress
	24	通过ID读比例数据	Read Scaling Data By Identifier
	2A	通过周期ID读取数据	Read Data By Periodic Identifier
	2C	动态定义标识符	Dynamically Define Data Identifier
	2E	通过ID写数据	Write Data By Identifier
	3D	通过地址写内存	Write Memory By Adress
存储数据传输类	14	清除诊断信息	Clear Diagnostic Infomation
存储数据传输类	19	读取故障码信息	Read DTC Infomation
输入输出控制类	2F	通过ID控制输入输出	Input/Output Control By Identifier
例程功能类	31	例行程序控制	Routine Control
上传下载类	34	请求下载	Request Download
	35	请求上传	Request Upload
	36	数据传输	Transfer Data
	37	请求退出传输	Request Transfer Exit
	38	请求文件传输	Request File Transfer

2.2 诊断请求（Diagnostic Request）

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

尽管服务类型不尽相同，但UDS针对这些服务定义了统一的诊断请求包的格式，每个诊断请求由1个Byte的SID + 1个Byte的 sub-function（实际上是1bit spr + 7bit sub-function，具体解释看下文）+ 不定长的实际数据构成，其格式如下所示：

uds协议,UDS协议从入门到精通,车载系统,测试工具,信息与通信

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

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

2.3 正响应/负响应（Positive/Negative Response）

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

2.3.1 正响应报文格式

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

uds协议,UDS协议从入门到精通,车载系统,测试工具,信息与通信

——举个最简单的例子（0x10-诊断会话控制服务）：

——再举个不带sub-function的例子（0x22-通过DID读数据）：

2.3.2 负响应报文格式

负响应消息由两部分组成：SID和负响应码（NRC）。SID用于标识响应的服务，负响应码指示服务执行失败的原因。

负响应报文的字节组成格式如下所示：

uds协议,UDS协议从入门到精通,车载系统,测试工具,信息与通信

——还是拿0x10-诊断会话控制服务来举例：

2.4 负响应码（Negative Response Code - NRC）

在UDS协议中，负响应码用于指示服务执行失败的原因。NRC用一个字节表示，每个取值都对应一种不同的错误类型。

NRC码	含义	NRC码	含义
0x01 - 0x0f	暂保留；	0x78	收到请求，延迟响应；
0x10	未知错误，服务被拒绝；	0x79 - 0x7d	暂保留；
0x11	不支持该服务请求；	0x7e	当前会话下子功能不支持；
0x12	不支持子功能；	0x7f	当前会话下服务不支持；
0x13	消息长度或格式错误；	0x80	暂保留；
0x14	请求信息长度超出；	0x81	rpm（每分钟转速）太高；
0x15 - 0x20	暂保留；	0x82	rpm太低；
0x21	服务端正忙；	0x83	当前引擎正在运行；
0x22	条件不满足；	0x84	当前引擎未运行；
0x23	暂保留；	0x85	截止当前时间引擎运行时间太短；
0x24	请求顺序错误；	0x86	温度过高；
0x25	指令已经被接收，但是未被执行；	0x87	温度过低；
0x26	失败的操作导致当前操作无法执行；	0x88	车速过高；
0x27 - 0x30	暂保留；	0x89	车速过低；
0x31	参数错误；	0x8a	油门/踏板过高（超过了当前要求的最大阈值）；
0x32	暂保留；	0x8b	油门/踏板过低；
0x33	安全校验未通过；	0x8c	变速器档位不在空档；
0x34	暂保留；	0x8d	变速器档位不在排挡；
0x35	密钥不匹配；	0x8e	暂保留；
0x36	已达到解锁最大错误次数；	0x8f	制动开关没有关闭
0x37	超时时间未到；	0x90	换挡杆不在驻车档；
0x38 - 0x4f	由扩展数据链路安全性保留；	0x91	变矩器离合器锁定；
0x50 - 0x6f	暂保留；	0x92	电压过高；
0x70	不允许上传下载；	0x93	电压过低；
0x71	数据传输中断；	0x94 - 0xef	暂保留（特定条件下）；
0x72	擦除或烧写内存错误；	0xf0 - 0xfe	为汽车制造商保留；
0x73	块序列计数错误；	0xff	暂保留；
0x74 - 0x77	暂保留；

以上内容是对UDS协议及一些入门基础知识的阐述，在接下来的篇章中，将详细介绍UDS协议中定义的全部26种服务。每一种服务都将被仔细解析和阐述，以便大家能够全面理解其功能和用法。各篇章还将通过图示方式给出直观的通信示例，帮助大家更好地理解UDS协议的实际应用。

三、UDS服务详述

Tip📌：各表格中标黄的为常用服务！！！

3.1 诊断和通信管理类

诊断和通信管理类是UDS服务的核心部分，它提供了与ECU进行通信以及执行诊断操作的基本功能。这些功能包括诊断会话的建立和终止、ECU的重置和诊断通信的管理。通过诊断和通信管理类，技术人员可以与ECU进行交互，获取ECU的状态信息，并执行各种诊断操作。主要包括如下服务：

Service（点击即可跳转）	功能简述
0x10：诊断会话控制	客户端控制目标ECU的诊断会话状态。
0x11：ECU复位	客户端强制让目标ECU执行复位操作。
0x27：安全访问	客户端请求解锁受保护的目标ECU。
0x28：通讯控制	客户端控制目标ECU中通信参数的设置(例如，通信波特率)。
0x3E：待机握手	客户端向目标ECU表明它仍然存在。
0x85：控制DTC的设置	客户端控制目标ECU中dtc的设置。
0x83：访问时间参数（待更新...）	客户端使用此服务读取/修改当前通信的定时参数。
0x84：安全数据传输（待更新...）	客户端使用此服务执行具有扩展数据链路安全性的数据传输。
0x86：事件响应（待更新...）	客户端请求设置和/或控制目标ECU中的事件机制。
0x87：链路控制（待更新...）	客户端请求控制通信波特率。

3.2 数据传输类

数据传输类是用于在ECU和诊断工具之间传输数据的UDS服务类别。它提供了可靠的数据传输机制，确保数据的完整性和准确性。数据传输类包括数据的读取和写入功能，允许技术人员读取和修改ECU中的数据。此外，数据传输类还支持数据的块传输，以提高数据传输的效率。主要包括如下服务：

Service（点击即可跳转）	功能简述
0x22：通过ID读数据	客户端请求读取由提供的DID标识的记录的当前值。
0x2E：通过ID写数据	客户端请求写入由提供的DID指定的记录数据。
0x23：通过地址读内存（待更新… …）	客户端请求读取所提供内存范围的当前值。
0x24：通过ID读比例数据（待更新… …）	客户端请求读取由提供的DID标识的比例数据。
0x2A：通过周期读ID数据（待更新… …）	客户端请求调度目标ECU中的数据进行周期性传输。
0x2C：动态定义标识符（待更新… …）	客户端请求动态定义数据标识符，这些标识符随后可能被0x22-读DID服务读取。
0x3D：通过地址写内存（待更新… …）	客户端请求覆盖提供的内存范围。

3.3 存储数据传输类

存储数据传输类是一种特殊的数据传输类别，用于在ECU和诊断工具之间传输存储数据。存储数据可以是ECU的配置信息、故障码或日志文件等。通过存储数据传输类，技术人员可以读取和清除ECU中的存储数据，以便进行故障诊断和维修。所涉及的两个服务都是常用服务类型。主要包括如下服务：

Service（点击即可跳转）	功能简述
0x14：清除诊断信息	允许客户端从目标ECU清除诊断信息(包括dtc、捕获的数据等)。
0x19：读取故障码信息	允许客户端从目标ECU请求诊断信息(包括dtc、捕获数据等)。

3.4 IO控制类

IO控制类是用于控制ECU输入输出（IO）功能的UDS服务类别。它提供了对ECU输入输出功能的访问和控制，包括读取和设置ECU的输入输出状态。通过IO控制类，技术人员可以与ECU的IO功能进行交互，实现对车辆系统的控制和监控。主要包括如下服务：

Service（点击即可跳转）	功能简述
0x2F：通过ID控制输入输出	客户端请求控制特定于目标ECU的输入/输出。

3.5 例程功能类 - 调用ECU内部预置函数

例程功能类是一种特殊的UDS服务类别，它允许技术人员调用ECU内部预置的函数。这些函数可以执行特定的操作，如执行自检、执行校准或执行特殊功能。通过例程功能类，技术人员可以利用ECU内部的功能来进行诊断和维修。主要包括如下服务：

Service（点击即可跳转）	功能简述
0x31：例行程序控制	客户端请求启动、停止目标ECU中的例程（简单理解就是个函数）或请求例程结果。

3.6 上传下载类

上传下载类是用于在ECU和诊断工具之间进行数据上传和下载的UDS服务类别。它提供了将数据从ECU上传到诊断工具或将数据从诊断工具下载到ECU的功能。上传下载类可用于备份和恢复ECU配置、更新ECU软件或执行其他数据传输操作。主要包括如下服务：

Service（点击即可跳转）	功能简述
0x34：请求下载	客户端请求协商从客户端到目标ECU的数据传输。
0x36：数据传输	客户端向目标ECU发送数据(下载)或向目标ECU请求数据(上传)。
0x37：请求退出传输	客户端请求终止数据传输。
0x35：请求上传（待更新... ...）	客户端请求从目标ECU到客户端的数据传输。
0x38：请求文件传输（待更新... ...）	客户端请求在目标ECU和客户端之间进行文件传输。

四、写在最后

汽车软件开发、测试、维修等过程中，UDS协议的使用已经越来越广泛了，不管底层基于哪种物理总线实现ECU间或者诊断设备和ECU间的通信，应用层大多都会经过UDS协议封装数据包。但这个协议细节众多，直接看ISO 14229-1标准文件的话学习成本太高，对不常读英文手册的人来说看起来更是尤为烦躁，而网上很多文章通常直接截取标准文件中的图片加以简单说明，同样不够友好。因此开设该专栏，力争针对ISO14229-1标准做一份细致全面的中文手册，以便随手查阅。

近一年来，我从事车载操作系统的开发工作，即ECU固件软件的开发，又以ECU OTA升级为主要工作内容，对UDS、ECU软件刷写、部分BSW模块的开发有了一定的认识，后续将陆续开设各类专栏一方面对工作涉及的内容做较为全面的总结，一方面与大家分享，希望帮助更多的朋友进军汽车软件开发行业，共同学习进步！