《UDS协议从入门到精通（UDS速查手册）》（完结撒花版）

总目录：《UDS协议从入门到精通（UDS速查手册）》（完结撒花版）

• 一、前言
• 一、UDS简介
• • 1.1 从汽车诊断说起
  • 1.2 两种常见的诊断协议：OBD & UDS
• 二、相关术语介绍
• • 2.1 Service ID（SID）
  • 2.2 诊断请求（Diagnostic Request）
  • 2.3 正响应/负响应（Positive/Negative Response）
  • • 2.3.1 正响应报文格式
    • 2.3.2 负响应报文格式
  • 2.4 负响应码（Negative Response Code - NRC）
• 三、UDS服务详述
• • 3.1 诊断和通信管理类
  • 3.2 数据传输类
  • 3.3 存储数据传输类
  • 3.4 IO控制类
  • 3.5 例程功能类 - 调用ECU内部预置函数
  • 3.6 上传下载类
• 四、写在最后

一、前言

  汽车软件开发/测试工作中不免涉及到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📌：表格中标黄部分为常用的服务，其他的不常用。

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用一个字节表示，每个取值都对应一种不同的错误类型。

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

三、UDS服务详述

  Tip📌：各表格中标黄的为常用服务！！对于不常用服务的讲解会相对没有那么深入和精致，如有特殊需要，尽可提出，博主会尽其所能细化相关不常用服务的讲解！！

3.1 诊断和通信管理类

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

3.2 数据传输类

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

3.3 存储数据传输类

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

3.4 IO控制类

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

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

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

3.6 上传下载类

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

四、写在最后

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

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

  专栏精心制作，历时半年，码字不易，期间收获众多网友的宝贵意见或好评，郑重感谢。本专栏将于2024年7月15日设置为付费专栏，此日期之前任何对于专栏内容曾做出提问、意见、评论的小伙伴，均可将截图记录私信给博主并附上你的邮箱，最迟两日内你的邮箱会收到该专栏的pdf版本。（Tip：pdf版本丧失跳转以及鼠标悬停时名词解释的功能）

>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<