UDS（统一诊断服务）—— 轻松入门

“本文介绍了UDS（统一诊断服务）协议及其在汽车电子控制单元（ECU）中的应用。内容涵盖UDS的通信方式、客户端-服务器模式、诊断和固件更新功能。详细解释了UDS消息结构，包括协议控制信息（PCI）和服务标识符（SID）。此外，还介绍了UDS在读取故障诊断代码（DTC）、提取参数数据和启动诊断会话等方面的具体应用。”

1. 什么是UDS协议？

统一诊断服务（UDS）是一种通信协议，广泛用于汽车的电子控制单元（ECU）。这个协议主要帮助进行各种诊断、更新固件、做常规测试等任务。UDS（即ISO 14229）是一个跨制造商和跨技术的标准，它支持多种通信方式，包括CAN、KWP 2000、以太网、LIN等。目前，几乎所有一级供应商和整车制造商的ECU都在使用这个协议。

在实际使用中，UDS遵循客户端-服务器的通信模式。这里的测试工具就是客户端，而车辆的ECU则充当服务器。比如说，你可以通过将CAN总线接口插到车的OBD2连接器上，然后向车辆发送UDS请求。如果ECU支持UDS，它就会根据你的请求做出回应。

基于UDS可以做很多事情：

读取/清除故障诊断代码（DTC），以排除车辆问题
提取温度、电量状态、VIN等参数值数据值
启动诊断会话，例如测试安全关键特性
通过固件刷新来更新控制器软件

2. UDS消息结构

UDS是一个基于请求的协议。在下图中，我们简单描述了一个UDS请求帧的例子（使用CAN总线）：

2.1 协议控制信息（PCI）

PCI字段虽然和UDS协议的具体内容没直接关系，但如果你想在CAN总线上发送UDS请求，这个字段就必不可少。简单来说，PCI字段的长度从1到5个字节不等。它包含了一些关键参数，这些参数帮助我们把长的UDS消息拆分成几个短的CAN报文。这部分内容其实属于ISO-TP协议的范畴，ISO-TP会详细介绍如何进行这种操作。

2.2 服务ID（SID）

当我们使用UDS去执行不同的服务时，我们需要在传输的报文里使用特定的UDS服务标识符（SID）。这些标识符主要有两种：请求标识符和响应标识符。通常，响应标识符就是请求标识符的数值上加上0x40。如果你看下面的图表，你会发现UDS（ISO 14229）标准支持的所有请求和响应标识符都列在那里了。

确实，UDS服务标识符（SID）中只有一部分数字是被标准化使用的。还有一些服务标识符被其他标准所使用。例如，从0x00到0x0F的标识符是专门为OBD服务保留的。这种区分有助于避免不同系统间的标识符冲突，确保每种服务的唯一性和可识别性。

2.3 子函数字节

在UDS（统一诊断服务）中，除了用服务标识符（SID）来调用不同的服务，还有一个叫做子函数字节的东西来扩展功能。这个子函数字节由两部分组成：

首先是肯定响应抑制标识符，它占据了字节的第一个比特位。通常，当你向车辆的电控单元（ECU）发送一个请求时，ECU会回应说它收到了（肯定响应）或者请求有问题（否定响应）。如果你设置这个抑制标识符为1，那么ECU就不会发送肯定响应了，但如果有问题，它还是会发送否定响应。

其次，字节里剩下的7个比特位用来定义多达128个不同的子函数值。这就像是给基本功能加上一些变化。比如说，使用SID=0x19（读取诊断信息）来读取故障代码（DTC），这些子函数就能帮你控制想要的报告类型。

只有部分UDS服务是支持子函数的如下图，其他服务是不支持的。

2.4 请求数据参数

在UDS（统一诊断服务）的大多数请求中，除了我们之前讨论的服务标识符和子函数字节，还有一个叫做请求数据参数的部分，这可以帮助我们进一步定制我们的请求。来看两个例子来更好地说明这一点：

上例中0x22服务中使用一个数据标识符（DID），长度2字节值来获取ECU里面对应DID的数据结果。部分DID对应的数据含义已经在标准中定义了。

3. UDS响应结构

3.1 UDS的肯定响应

当汽车的电控单元（ECU）收到一个UDS请求并且可以正常处理时，它会发回一个肯定响应。这个肯定响应的结构跟请求时用的结构很像。比如，如果你发送了一个服务请求0x22来获取某个特定的数据，那么ECU的肯定响应会以响应服务标识符0x62开始（这就是请求标识符0x22加上0x40），紧接着是2字节的数据标识符（DID），然后是你请求的那个DID的实际数据。

每种服务的正面响应消息的具体结构可能会有所不同，这取决于服务的种类。但大体上，ECU的回复会告诉你请求是否成功，并提供你需要的数据。这种方式确保了信息的清晰传达和问题的有效解决。

3.2 UDS的否定响应

当车辆的电控单元（ECU）无法对一个UDS（统一诊断服务）请求提供肯定响应时，它会发送一个否定响应，比如ECU不支持你请求的服务时。否定响应的结构通常包括几个部分：

第一个字节，协议控制信息（PCI）：这部分和UDS的具体操作无关，但它是UDSonCAN响应消息的必要组成。
第二个字节，否定响应码：这个字节固定为0x7F，用来标识这是一个否定响应。
第三个字节，被拒绝的服务标识符（SID）：这里会显示你原始请求中用的那个SID。
第四个字节，否定响应码（NRC）：这个码提供了请求失败的具体原因，比如“不支持该服务”或“请求格式错误”等。
第五个字节，原因代码：这只在NRC为0x22时出现，即“条件不正确”时，会进一步解释拒绝的详细原因。

这样的响应结构让你能清楚地了解请求失败的具体原因，并根据这些信息调整你的诊断策略。通过这种方式，技术人员可以更有效地识别问题，并采取适当的措施来解决。

4. UDS vs. CAN总线

要真正弄懂UDS，我们需要看看它是如何在OSI模型里与CAN总线标准一起工作的。想象一下，OSI模型像一栋楼，不同的楼层代表不同的技术层级。CAN标准就像是在这栋楼的底部，负责最基础的任务，也就是让数据能在车辆的网络中物理传输，这部分包括了物理层和数据链路层。

而UDS则在楼层更高一些的位置，具体来说，它涵盖了会话层和应用层。会话层就像是保证我们发送的信息能按顺序且完整地到达，而应用层则更进一步，直接处理诊断信息，确保车辆的系统能理解和使用这些数据。

通过这种方式，我们可以看到UDS和CAN怎么合作，让车辆的诊断和通信既精确又高效。

ISO 14229-1（应用层）

ISO 14229-1标准详细定义了UDS（统一诊断服务）的应用层要求，这些要求是独立于任何底层通信协议的。该标准主要涵盖以下几个关键领域：

客户端与服务器之间的通信流程，包括请求和响应等交互模式。
各类具体的UDS服务功能。
肯定响应和否定响应的编码（Negative Response Codes，NRCs）。
其他相关定义，如诊断故障代码（Diagnostic Trouble Codes，DTCs）、数据标识符（Data Identifiers，DIDs）等。

ISO 14229-3（基于CAN的应用层）

ISO 14229-3的主要目标是在CAN总线上实现统一诊断服务（UDS），即UDSonCAN。该标准并没有定义任何特定的车载CAN总线架构的具体实现，而是附加了一些针对UDSonCAN的特定需求和限制。具体来说，ISO 14229-3详细概述了哪些UDS服务在应用于CAN时有特定的需求。其中，受影响的服务包括响应事件的周期标识符和读取数据的操作，这些CAN特定的需求在标准中有详尽的阐述。除此之外，所有其他的UDS服务都遵循ISO 14229-1和ISO 14229-2的规定。

此外，ISO 14229-3还描述了ISO 14229-2和ISO 15765-2（ISO-TP）之间的映射关系，以及在使用UDS和OBD时11位和29位CANID的具体要求。

ISO 14229-2（会话层）

UDS标准（ISO 14229-1）详细描述了OSI模型中的会话层，特别是服务请求、确认和指示原语的实现。这些接口原语为UDS与任何底层通信协议之间的交互提供了标准化的接口。通过这种方式，UDS能够在各种不同的车辆网络环境中实现，确保了其广泛的兼容性和灵活性。

ISO 15765-2（CAN的传输+网络层）

对于基于CAN的UDS，ISO 15765-2标准扮演了核心角色，它详细描述了诊断请求和响应的实现机制。具体而言，该标准阐释了如何通过多个CAN帧的组合来传输较大的数据有效负载。这一过程是实现UDSonCAN的关键步骤，确保了复杂数据的顺利传递与处理。

ISO 11898（CAN的物理+数据链路层）

在UDSonCAN中，基本的CAN通信协议定义在ISO 11898-1和ISO 11898-2标准中，涵盖了CAN总线的物理层和数据链路层规范。这两个标准共同构成了CAN通信系统的基础框架，确保了数据传输的标准化和可靠性。

5. ISO 15765-3 vs. ISO 14229-3

在CAN总线上的UDS协议，之前是按照ISO 15765-3:2004标准来设定的。但到了2012年，这个旧标准被ISO 14229-3取代了。新的ISO 14229-3标准对CAN总线上的UDS（也就是UDSonCAN）进行了更详细的规定，这样做是为了确保系统与更多设备兼容，同时满足最新的技术要求。

6. UDS数据是公开的吗？

UDS（统一诊断服务）其实就是一种由制造商定制的车辆诊断协议。虽然UDS的大框架是标准化的，但具体到每条数据怎么解读，这些都还是厂家的秘密，一般我们普通人是不太知道的。比如，UDS可以让你通过一个特定的服务来从车辆的电控单元（ECU）拉数据，但具体要用什么代码，或者数据意味着什么，这些信息并没有公开标准化。

不过，对于支持某些特定协议的车（比如WWH-OBD或OBDonUDS），我们还是可以比较容易地拿到一些基本数据，比如车速或者发动机转速，这些通常用一些固定的代码（比如前缀是0xF4的）就能查到。但如果要深入了解更多细节，除非你是车厂的工程师，不然可能需要通过一些技术手段，像是反向工程，这可是相当复杂的技术活。幸好，现在网上有一些高手已经分享了他们的成果，比如反向工程出来的数据表和dbc文件，这对相关从业者来说，还是挺有用的。

7. UDS为什么越来越重要？

现在大部分车都用OBD2，这是一种车辆诊断系统，可以帮助我们读取车速、转速、油门位置和燃油水平等信息。但是，未来OBD2可能不会这么普遍了。首先，有一种新的系统叫做WWH-OBD或者基于UDS的OBDonUDS，它可能会逐渐取代OBD2，成为新的行业标准。其次，随着电动车越来越多，法律可能不再要求车辆一定要支持OBD2。而且，电动车有些特别的信息，比如电池电量（SoC）和电池健康状况（SoH），OBD2是读不出来的。不过，大多数电动车还是会支持UDS系统，因为UDS可以获取更多种类的数据。随着电动车市场的扩大，基于UDS的通信变得越来越关键了。

8. 软件定制开发（Dots）

如果你想更好地与车辆通信系统交互，定制开发UDS PC软件可能是一个很好的选择。通过定制开发，你可以拥有一个完全符合你特定需求的软件工具，无论是进行诊断、固件更新，还是执行特定的监控任务。这种软件可以设计成用户友好、功能丰富，支持多种车辆通信协议，如CAN、Ethernet等。

这样的软件开发服务通常包括需求分析、系统设计、实现编码、测试验证，直到最终的部署和支持。开发团队会与你紧密合作，确保软件完全符合你的操作流程和技术规格，同时也能灵活应对将来可能的需求变更。此外，定制的UDS PC软件还可以整合先进的数据分析和可视化工具，帮助你更有效地理解车辆数据，提升诊断和维护效率。通过这种专业的软件定制服务，你可以大大提高工作流程的自动化和精确度，让车辆维护和测试变得更简单、更高效。

示例1：获取和解码DID数据（车辆识别代号）

让我们来看一个具体的例子，了解如何使用UDS协议读取车辆识别号（VIN）。在这个示例中，我们将使用数据标识符0xF190来读取车辆识别号，这个识别号可以在UDS标准中获知。

我们将使用我们定制化软件软件作为我们的工具。

步骤如下：

发送请求：使用UDS服务0x22（读取数据标识符）发送请求，数据标识符为0xF190。

请求帧示例：03 22 F1 90 AA AA AA AA

接收响应：车辆会响应并返回包含车辆识别号的帧。

响应帧示例：62 F1 90 56 49 4E …（其中，56 49 4E …代表车辆识别号的具体字符）

通过上述步骤，我们可以轻松地获取车辆识别号。这种方式不仅适用于技术人员，任何对车辆诊断有兴趣的人都可以尝试使用。使用UDS协议读取车辆信息变得简单而直观。

示例2：读取DTC故障码（DTC 0x080511，离合器位置传感器短地）

在这个示例中，我们将展示如何使用UDS协议读取所有的历史故障。假设现在控制器里面只有一个历史故障，即离合器位置传感器短路故障（DTC：0x080511，状态：0x2F）。

我们将使用UDS服务0x19（诊断故障码相关服务）中的子功能0x02（通过状态掩码读取DTC），并指定状态掩码为0x08（历史故障）。状态掩码的作用：状态掩码与DTC的实际状态按位逻辑与，结果非零，则匹配。

步骤如下：

发送请求：使用UDS服务0x19的子功能0x02，带上状态掩码0x08。

请求帧示例：03 19 02 08 AA AA AA AA

接收响应：车辆会响应并返回包含特定状态的故障码信息。

响应帧示例：07 59 02 08 08 05 11 2F（其中，08 05 11表示DTC 0x080511，2F为该故障的状态码）

通过上述步骤，我们可以成功读取状态掩码为0x08的故障码。在这个例子中，我们读取了DTC 0x080511，表示离合器位置传感器短路，并且确认了其状态码为08。这种方法帮助我们更精确地诊断和解决车辆问题。

示例3：刷写Flash数据

统一诊断服务（UDS）是车辆通信的一个超级实用工具，除了能进行诊断和安全检测等操作。还可以用来更新车上电子控制单元（ECU）的固件，

每个车厂和控制器的UDS刷写过程可能有点不同，具体步骤要根据车厂的具体要求来调整，但基本的流程大概是这样的：

开启诊断会话：首先，我们用诊断会话控制服务（SID=0x10）启动一个扩展会话。这种会话让我们可以进行写操作和其他需要更多权限的操作。

进行安全认证：安全访问服务（SID=0x27）确保只有授权的工具才能进行写操作或其他敏感操作。这通常包括一个请求和响应的过程，防止未授权访问。

准备数据下载或上传：接下来，我们用请求下载服务（SID=0x34）或请求上传服务（SID=0x35）来为接收或发送数据做准备。这里要设置数据的大小和存储地址等。

传输数据：数据传输服务（SID=0x36）是用来实际传送数据的。在固件更新的情况下，诊断工具会分几次把固件数据包发给ECU。

结束传输：传输退出服务（SID=0x37）标志着数据传输结束，此时ECU会开始处理收到的数据，比如把新固件写进闪存。

重启控制器：更新完毕后，通常会用控制单元重置服务（SID=0x11）来重启ECU，确保新固件能正确加载并运行。

这就是UDS刷写的基本流程。虽然每个厂商或控制器的具体步骤可能会有些不同，比如某些服务的细节或顺序可能会根据具体的硬件和软件需求调整，但整个过程的核心目标是确保固件能安全、有效地更新。这样一来，车辆的系统就能保持最新，运行更加顺畅。

在Dots定制化开发中，我们提供了非常灵活的解决方案，能够精准满足各种厂商的特定需求。不论是执行标准的刷写流程还是进行复杂的定制化操作，客户都能根据自己刷新流程配置出自己需要刷新流，从快速应对不同项目的需求。

此外，我们还使用了广播刷写技术，这一技术允许在厂线上批量刷新多个控制器。通过将固件更新包通过广播方式同时发送到多个控制器，这能大幅节省了时间。