常用服务已更新完毕，后面将陆续更新不常用服务。
一、前言
汽车软件开发/测试工作中不免涉及到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线通信去实现，也能在Ether***上实现。并且，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 A***ess | |
| 28 | 通讯控制 | ***unication Control | |
| 3E | 待机握手 | Tester Present | |
| 83 | 访问时间参数 | A***ess 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，具体解释看下文）+ 不定长的实际数据构成，其格式如下所示：
Tip📌：spr存在的目的是告诉ECU针对某个服务请求是否需要发送正响应数据，用于减少ECU发送不必要的响应，节约系统资源：
- spr=1， 抑制正响应，即ECU不给出正响应；
- spr=0， 需要ECU给出正响应，如果某个服务没有sub-function，即没有第二个字节，那默认是要发正响应的。
2.3 正响应/负响应（Positive/Negative Response）
诊断工具向车辆发送服务请求后，如果服务执行成功，则返回的响应消息称为正响应，反之返回的响应消息称为负响应。
2.3.1 正响应报文格式
正响应报文的字节组成格式如下所示：
——举个最简单的例子（0x10-诊断会话控制服务）：
——再举个不带sub-function的例子（0x22-通过DID读数据）：
2.3.2 负响应报文格式
负响应消息由两部分组成：SID和负响应码（NRC）。SID用于标识响应的服务，负响应码指示服务执行失败的原因。
负响应报文的字节组成格式如下所示：
——还是拿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模块的开发有了一定的认识，后续将陆续开设各类专栏一方面对工作涉及的内容做较为全面的总结，一方面与大家分享，希望帮助更多的朋友进军汽车软件开发行业，共同学习进步！
>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<
