UDS协议教程：探索汽车诊断协议

系列文章目录

---

文章目录

• 系列文章目录
• 前言
• UDS协议教程
• UDS协议简介
• UDS在汽车ECU中的实现
• 提供 ISO-14229 标准
• UDS协议如何诊断？
• 什么是UDS协议？
• 为什么需要在车辆中进行诊断？
• UDS 协议物理和功能寻址：
• UDS 标准中的会话层时序：
• UDS 协议帧格式
• UDS协议请求帧格式：
• UDS协议响应帧格式：
• 积极响应帧格式：
• 负响应帧格式：
• UDS协议架构
• UDS协议栈
• 诊断服务的功能在UDS协议中
• 诊断和通信管理：
• 诊断会话控制 （0x10）：
• 默认会话 （0x01）
• UDS 响应：服务器 –>客户端：
• 积极回应：
• 否定回应：
• 诊断会话控制请求消息布局：
• 示例：请求编程会话：
• ECU复位服务标识符（0x11）
• 安全访问 （27X）
• （4）通讯控制设置：UDS协议
• （5） TesterPresent （3E hex）： UDS协议
• （6）接入时序参数（0x83）：UDS协议
• （7） 安全数据传输 （0x84）：UDS 协议
• （8） 控制DTC设置（0x85）：UDS协议
• （9） 事件响应 （0x86）：UDS 协议
• （10） 链路控制 （0x87）：UDS 协议
• 数据传输功能单元：UDS协议
• 按标识符读取数据（22 十六进制）：UDS 协议
• WriteDataByIdentifier （2E 十六进制）： UDS 协议
• ReadMemoryByAddress （0x23）：UDS 协议
• WriteMemoryByAddress （0x3D）：UDS 协议
• ReadScalingDataByIdentifier （24 十六进制）： UDS 协议
• ReadDataByPeriodicIdentifier （2A hex）： UDS 协议
• 动态定义数据标识符（2C 十六进制）：UDS 协议
• 存储数据传输功能单元：UDS协议
• ReadDTCInformation （19 十六进制）： UDS 协议
• 清除诊断信息（14 十六进制）：UDS 协议
• 输入输出控制功能单元：UDS协议
• 按标识符（2F 十六进制）的输入输出控制：UDS 协议
• 远程激活常规功能单元：UDS协议
• 常规控制（31 十六进制）：UDS 协议
• 例行控制请求消息布局：
• 例：
• 反应：
• 上传下载功能单元：UDS协议
• 请求下载（34 十六进制）：UDS 协议
• 请求下载请求消息格式：
• 反应：
• 请求下载响应消息 LayOut：
• 例：
• 否定响应代码：
• 请求上传（35 十六进制）服务
• 例：
• 传输数据（36 十六进制）：UDS 协议
• 请求：
• 传输数据请求消息帧格式：
• 反应：
• 传输数据响应消息布局：
• 阴性 Response C颂歌：
• 请求 TransferExit（37 十六进制）：UDS 协议
• 请求传输退出请求消息布局：
• 响应：
• 请求传输退出响应消息布局：
• 否定响应代码：
• 请求文件传输（38 十六进制）：UDS 协议
• UDS协议中使用的术语
• 总结

---

---

前言

UDS协议教程

大家好！我非常高兴能与大家分享UDS协议的一些基础知识，以及为什么它在汽车诊断方面如此出色。UDS 代表统一诊断服务，它是一种定义测试仪（如扫描工具或笔记本电脑）如何与车辆中的电子控制单元 （ECU） 通信的标准。它基于 ISO 14229 标准，并使用 ISO 15765-2 传输协议通过 CAN 总线发送和接收消息。

与KWP2000或OBD-II等较旧的诊断方案相比，UDS具有许多优势。例如，UDS在诊断服务中提供了更大的灵活性和功能，例如读取和擦除故障代码、对ECU进行编程和编码、执行安全访问、执行例程等等。UDS 还支持不同的会话类型，例如默认会话、编程会话、扩展会话和安全关键会话类型，这些会话类型可以改变 ECU 的行为和可用性。UDS还具有称为动态子功能的功能，这意味着测试仪可以根据服务向ECU请求其他信息或参数。

UDS 中最重要的概念之一是诊断服务标识符 （SID），它是一个单字节代码，用于指定测试人员从 ECU 请求的服务类型。例如，SID 0x10 表示启动诊断会话，SID 0x22 表示按标识符读取数据，SID 0x27 表示安全访问，依此类推。UDS 中定义了数十个 SID，每个 SID 都有自己的子函数和数据格式。ECU 使用肯定或否定响应代码（PRC 或 NRC）响应每个服务请求，该代码指示服务是否成功以及原因。

举个简单的例子来说明UDS的工作原理，假设我们想读取ECU的软件版本。我们将发送一条消息，其中包含 SID 0x22（按标识符读取数据）和与软件版本（如 0xF180）相对应的数据标识符 （DID）。

然后，ECU 将回复 SID 0x62（按标识符读取数据的积极响应）和软件版本数据的正响应，或使用 SID 0x7F（负响应）和 NRC 进行否定响应，解释服务失败的原因，例如 0x31（请求超出范围）或0x22（条件不正确）。

本 UDS 协议教程将为您提供有关 ISO-14229 标准的最佳 UDS 协议知识。哪些将帮助您在职业生涯中获得汽车领域的好机会？SAE计划为每辆车增加诊断功能，以达到安全和维护的目的。

那么，如果您已经完成了工程设计并正在尝试在汽车领域找到一份工作？或者在其他领域工作并有兴趣进入汽车领域？或者想在公司实施UDS协议时学习深入的知识？那么这是在嵌入式汽车开发或测试领域学习和工作的最佳场所。

此 UDS 协议以诊断通信管理器 （DCM） 的名义非常有名。它主要用于AUTOSAR分层软件架构。

UDS协议简介

UDS协议是最新的汽车诊断协议，用于诊断世界各地的任何车辆。该协议在 ISO-14229 标准中定义，因此每个汽车 OEM 都将遵循该标准，以提供可用于诊断任何车辆的非常通用的计算机系统。但在此之前，我想澄清您的疑问，通信协议和诊断协议之间有什么区别。

通信协议用作在两台或多台机器或计算机之间交换信息的手段。在汽车工业中，这通常被称为电子控制单元（ECU）。为了清楚起见，我们将在整个过程中使用术语 ECU。正如人类可以理解并寻求医生的治疗以解决健康问题一样，机器可以通过ECU提供的适当解决方案进行有效的通信和运行。

UDS在汽车ECU中的实现

机器如何解释其处理器、I/O 外设中的问题所在，或识别短路等问题？为了在机器中启用此功能，我们可以开发在处理器中定期运行的诊断程序。如果发生任何故障，它将被记录为诊断故障代码 （DTC） 并存储在处理器的非易失性存储器中。这样，人类以后可以访问和读取代码，以方便车辆维修。

为了在电子控制单元 （ECU） 中实现这种能力，ISO 技术委员会和 SAE 委员会制定了一个包含各种服务和子功能的标准。这些标准允许通过从任何计算机系统请求特定的服务命令来识别和执行服务，从而提供必要的结果。因此，ECU可以有效地与人类沟通，提供有关其中问题的信息，并促进简单的故障排除和维修。

提供 ISO-14229 标准

UDS 协议规范在 ISO 14229 的不同子标准中定义。ISO-14229 标准 UDS 协议由以下部分组成，总标题为道路车辆 - 统一诊断服务 （UDS）：

• ISO 14229-1：UDS协议的规范和要求。
• ISO 14229-2：UDS 协议的会话层服务。
• ISO 14229-3：CAN实施上的统一诊断服务（UDSonCAN）。
• ISO 14229-4：FlexRay实施（UDSonFR）上的统一诊断服务。
• ISO 14229-5：互联网协议实施 （UDSonIP） 上的统一诊断服务。
• ISO 14229-6：K-Line 实施 （UDSonK-Line） 上的统一诊断服务。
• ISO 14229-7：本地互连网络实施 （UDSonLIN） 上的统一诊断服务（正在进行实施研究）。
• ISO 14229-8：UD上的统一诊断服务...将逐步准备并在此处添加

UDS协议如何诊断？

让我向你解释一个故事，让新工程师理解。假设你是一个人，如果你有任何健康问题，你就要去医院。在医院里，有不同的楼层用于不同的诊断目的。正如您可以说一楼用于一般或紧急目的，二楼是诊断中心，每个房间都用于不同的服务，如血液、皮肤、眼睛等。 3 楼是手术中心，4 楼是安全，因为您可以说在发生任何事情之前，您可以从医生那里得到保护，以免发生任何事情。

计算机中也可能发生相同的情况，因此请解决诊断协议所需的问题。因此，任何人或其他机器都可以使用称为UDS协议的协议在另一台机器上进行诊断

什么是UDS协议？

UDS协议是汽车中使用的诊断协议，用于查找运行状况检查问题的原因。基本上，它用于汽车领域的车辆诊断，ECU新软件刷新等。如今，由于其灵活性，该协议的使用正在增加。该协议在 ISO-14229-1 标准中定义，源自 ISO 14230-3 （KWP-2000） 和 ISO 15765-3（CAN 诊断通信 （DoCAN）。

UDS（统一诊断服务）协议在 OSI 模型的第 5 层（会话层）和第 7 层（应用层）运行。另一方面，CAN（控制器局域网）协议在 OSI 模型的第 1 层（物理层）和第 2 层（数据链路层）起作用。

从本质上讲，UDS协议建立在CAN协议之上，用于在客户端（请求者）和服务器（响应者）之间建立通信，以便进行诊断。这种通信模式，即根据请求在服务器上执行诊断，通常称为CAN诊断（DoCAN）。通过利用CAN协议提供的较低级别的功能，UDS协议增强了系统的诊断能力。

为什么需要在车辆中进行诊断？

当一个人发生任何问题并且他要去医院进行诊断并获得解决方案时，就像车辆一样，它也需要进行诊断，以便告知人类他的问题，例如：

1. 我们可能希望看到存储在系统中的数据（例如故障代码）或某种形式的身份识别。
2. 我们可能希望看到实时数据，例如发动机或车速。
3. 我们可能想要传输大量数据，例如重新刷新模块（ECU）。
4. 我们可能希望直接控制模块 I/O，例如禁用单个气缸以识别故障。
5. 我们可能希望在模块中运行特定的例程，例如某种形式的自校准。
6. 我们可能希望对某些服务应用安全锁，或者允许系统的正常功能受到不同程度的干扰。

UDS 协议物理和功能寻址：

事实上，当使用 UDS 协议进行诊断时，诊断测试人员（客户端）可以灵活地发送物理或功能 UDS 请求。

功能请求是一种广播类型的消息，这意味着它被发送到CAN网络上的所有电子控制单元（ECU）。当导致问题的特定故障模块或ECU未知，并且诊断测试人员希望从所有ECU收集信息以确定问题的根源时，这将非常有用。

另一方面，物理 UDS 请求被发送到网络上的单个特定 ECU。如果诊断工程师已经知道哪个模块或ECU出现故障，他们可以使用物理寻址直接连接到该特定ECU。这种有针对性的方法允许他们将诊断请求直接发送到已识别的ECU，并从该特定模块中检索诊断数据。这可以简化诊断过程，使其更有效率，并更快地解决问题。

通过在功能寻址和物理寻址之间进行选择，诊断工程师可以根据情况调整其诊断方法，从而在服务中心进行更有效的故障诊断和故障排除。

绝对，你是对的。当诊断工程师不知道故障的具体位置时，他们可以使用功能寻址方法向车辆中的所有电子控制单元 （ECU） 全局发送诊断请求。这样，工程师就可以从各种ECU读取所有活动的诊断故障代码（DTC），帮助他们识别报告故障的模块或ECU。

UDS 协议提供了使用功能和物理寻址方法的灵活性，为诊断工程师提供了一个通用且自发的界面，以便于诊断。这种多功能性至关重要，因为它允许工程师根据情况调整他们的诊断方法，使故障诊断过程更加高效和有效。通过提供这些寻址方法，UDS 协议简化了诊断过程并帮助及时解决问题。

UDS 标准中的会话层时序：

在 UDS 标准中，有一个标准用于管理开放系统互连 （OSI） 模型中的会话层服务，称为 ISO 14229-2，只有 UDS 协议。此项目中最重要的会话层时序是 P2 和 P2 扩展时序，它们指定服务器 （ECU） 或客户端（测试人员）等待或响应 UDS 请求的最长时间。

在 UDS（统一诊断服务）协议中，与响应时间相关的值由 ECU 通过 UDS 协议响应传达给诊断会话控制服务。

参数 P2 指定应用于服务器 （ECU） 响应的默认时序。它定义客户端（诊断测试人员）在发送请求后应等待服务器响应的时间。但是，ECU 可以选择发送否定响应代码 （NRC） 0x78（请求已正确收到 - 响应待处理），而不是提供即时响应。

当 ECU 发送 NRC 0x78时，它表示它需要更多时间来处理请求并生成响应。在这种情况下，扩展时序值（也称为 P2*（P2 星））开始发挥作用。P2* 值指定 ECU 生成响应所需的最大允许额外时间。诊断测试人员应等待延长时间 （P2*），然后再将请求视为超时，并假设没有响应。

这种机制允许ECU处理需要额外处理时间的情况，以便对复杂的诊断请求提供全面的响应，确保诊断会话保持平稳和可靠。

UDS 协议帧格式

由于 UDS 协议在 CAN 协议上工作，因此可以请求最多 8 字节的数据并在消息中获取响应。与CAN协议一样，在UDS协议中，有2种类型的帧可用。UDS 协议帧格式定义如下。

1. 诊断请求帧（带/不带子功能 ID）。
2. 诊断响应帧。

同样，响应帧分为两种类型：

• 积极回应。
• 否定响应。

UDS协议请求帧格式：

每当客户端想要从数据中请求任何内容时，测试人员都会向此请求发送帧，以从服务器获取 CAN 数据字段的响应。该框架由 3 个字段组成：

• 服务 ID。
• 子功能 ID（可选：某些诊断服务不存在）。
• 数据字节。

注意：D1=BIT7（POSRESPONSEINDICATIONBIT） +SUB-FUNCTION ID（BIT0...BIT6）

• 如果 bit7=True;然后不需要响应。
• 如果 bit7=False;然后是需要的响应。

SID	SBF	Data Bytes
0x10	0x01	xx

UDS 协议请求帧格式

UDS协议响应帧格式：

每当诊断工程师或测试人员请求对车辆进行任何服务时，车辆或特定ECU可能会根据物理或功能请求类型做出两种类型的响应。

积极响应帧格式：

每当测试人员向服务器请求正确并且服务器已成功执行请求时，它将通过向相应的服务 ID 添加0x40以供参考来发送有关此请求的响应消息。肯定响应的第一个字节应为请求服务 ID + 0x40。

负响应帧格式：

如果客户端没有以正确的帧格式请求，或者服务器由于内部问题而无法执行请求，那么它将向客户端发送否定响应。

• 否定响应的第一个字节应为 0x7F。
• 否定响应的第二个字节应为服务 ID。
• 否定响应的第 3 个字节应为响应代码。

请求帧 （C–>S）	10	01	xx
+VE 响应帧 （S–>C）	50	01	00
-VE 响应帧 （S–>C）	7楼	10	NRC公司

负响应帧格式

在上表中，我演示了请求和响应消息格式。通过这种方式，每当需要诊断数据时，测试人员都可以将其从计算机请求到车辆或特定的电子控制单元 （ECU），并将数据作为响应消息接收。

如果ECU或服务器成功接收并处理请求，满足所有必要的前提条件，则将向测试人员发送一个积极的响应帧。但是，如果请求遇到任何问题或未能满足先决条件，ECU 或服务器将响应包含特定否定响应代码 （NRC） 的否定响应消息。

这种机制确保了有效的沟通，允许测试人员通过正面或负面的响应消息获得请求的诊断信息并了解操作状态，从而促进了诊断和解决任何潜在问题的系统方法。

在本说明中，我将仅重点介绍 UDS（统一诊断服务）帧格式。如果您有兴趣进一步了解其他方面或完整的帧格式，正如我之前提到的，您不能单独使用此协议进行通信。相反，您需要使用 CAN、LIN 等通信协议。为了更深入地了解如何通过CAN进行诊断通信，我建议阅读我的CAN诊断（DoCAN）教程。

UDS协议架构

这些服务允许测试人员（客户）控制车载电子控制单元（服务器）中的诊断功能，例如应用于电子燃油喷射、自动变速箱、防抱死制动系统等，这些系统连接到嵌入在道路车辆中的串行数据链路上。

此外，该标准的这一部分指定了允许诊断测试仪（客户端）在数据链路上存储或恢复非诊断消息传输的通用服务。但是，该标准的第 1 部分没有规定任何实施要求。图 7 显示了车辆网络中客户端-服务器连接的一般配置。

Client-Server Communication in Vehicle

对于车辆 3，服务器直接连接到诊断数据链路，车辆 4 将其服务器/网关直接连接到车辆 3 服务器/网关。对于车辆 4，服务器通过内部数据链路连接，并通过网关间接连接到诊断数据链路。ISO 14229-1 或 UDS 协议适用于通过诊断数据链路进行的诊断通信;通过内部数据链路进行的诊断通信可能符合相同或其他协议。

服务器（通常是ECU的一部分）使用应用层服务将请求的诊断服务提供的响应数据发送回客户端。当客户端处于非板载状态时，它通常被称为外部测试设备，但在某些系统中，也可以称为板载测试仪。应用层服务的使用与客户端是板外测试人员还是板载测试人员无关。在同一车辆系统上有多个客户端是可能的。

带车载网络的OBD-II网关

用于车辆诊断的客户端-服务器通信的最典型网络配置：客户端作为车载测试仪。通信基于请求-响应模型。在诊断的上下文中，以下概念对于更好地了解 UDS 标准环境中处理的语义非常有用：

1. 诊断故障代码 （DTC）：由车载诊断系统识别的数字通用标识符故障情况。
2. 诊断数据：位于电子控制单元存储器中的数据，可以由测试仪检查和/或可能修改（诊断数据包括模拟输入和输出、数字输入和输出、中间值和各种状态信息）。示例：车速、油门角度、后视镜位置、系统状态等。
3. 诊断会话： 服务器的当前型号，它会影响诊断功能的级别。
4. 诊断程序： 嵌入在电子控制单元中的例程，可由服务器根据客户端的请求启动。注意：它可以代替正常操作程序运行，也可以与正常操作程序同时运行。在第一种情况下，ECU无法正常运行。在第二种情况下，可以启用多个诊断例程，这些例程在电子控制单元的所有其他部分正常工作时运行。
5. 测试 仪： 控制车载电子控制单元的测试、检查、监控或诊断等功能的系统，可以专用于特定类型的操作员（例如，专用于车库机械师的扫描工具或专用于装配厂代理的测试工具）。

UDS协议栈

如前所述，UDS（统一诊断服务）独立于较低层协议运行。因此，车辆诊断可以通过在应用层级别利用UDS进行，在中间级别整合通用网络层服务，并在较低阶段采用通信总线协议，如CAN（控制器局域网）、LIN（本地互连网络）、FlexRay或以太网。这种分层方法允许有效和高效的诊断程序，UDS促进了应用层的诊断，而较低层的协议则在各自的级别处理数据通信和传输。

这种方法符合网络的通用 OSI 模型。图 9 显示了根据标准 ISO-15765-3 通过 CAN 实施诊断服务的层的分层排列。

UDS Standard 中的安全层

通过CAN执行诊断时，客户端（诊断测试仪）发起请求并等待确认。然后，服务器（ECU中的功能）接收指示并发送响应。

诊断服务的功能在UDS协议中

除了指定描述客户端-服务器交互的服务基元和协议外，UDS 还在其框架中定义了几个功能单元，每个功能单元包含多个服务，用十六进制代码标识。这些单元旨在用于支持整体诊断功能/任务的不同个人目的。UDS协议具有不同的服务，用于在服务器上执行不同类型的工作任务。这些有 6 种类型：

1. 诊断和沟通管理。
2. 数据传输。
3. 存储的数据传输。
4. 输入/输出控制。
5. 远程激活例程。
6. 上传/下载。

每个功能组都有多个服务 ID，用于不同的 2 个任务，以便获取上述功能组和相关服务的详细信息。

诊断和通信管理：

该模块提供 10 种服务来控制 ECU 中的诊断和通信相关。

1. 诊断会话控制 （0x10）
2. ECU复位 （0x11）
3. 安全访问 （0x27）
4. 通信控制 （0x28）
5. 测试人员在场 （0x3E）
6. 访问时序参数 （0x83）
7. 安全数据传输 （0x84）
8. 控制 DTC 设置 （0x85）
9. 对事件的响应 （0x86）
10. 链路控制 （0x87）

诊断会话控制 （0x10）：

UDS 协议的核心是诊断会话控制服务。诊断会话控制是ECU中诊断服务器的大门，测试人员或诊断工程师将通过该门进入服务器的诊断实验室，并能够决定问题的状态以及他必须去哪个会话进行会话。

基本上，此服务用于使服务器中的不同诊断会话能够对其进行处理。在每个会话中，他们都定义了一些诊断服务，这些服务仅启用这些会话，以便它们可以完美运行而不会对服务器产生任何负面影响。

UDS 诊断会话

1. 如果服务器处于默认会话中，并且客户端请求启动默认会话，则服务器应完全重新初始化 defaultSession。
2. 如果服务器处于缺省会话中，并且客户端请求启动非缺省会话（extendedDiagnosticSession 或编程会话），则服务器应仅在转换到另一个会话之前重置已通过 ResponseOnEvent 服务在服务器中配置的事件。
3. 当服务器从非默认会话转换到默认会话时，服务器应重置已通过 ResponseOnEvent 服务在服务器中配置的每个事件，并应启用安全性。任何配置的定期调度程序都将被禁用，通信控制和 ControlDTCSetting 服务应重置为默认状态。在激活的会话期间，服务器应重置所有已激活/启动/更改的设置/控件。
4. 如果服务器处于非默认会话中，并且客户端请求启动相同或另一个非默认会话，则服务器应（重新）初始化非默认会话。应重置已通过 ResponseOnEvent 服务在服务器中配置的事件并启用安全性。

SBF 编号	SBF 名称	描述
0x01	默认会话	上电后， ECU将停留在此会话中
0x02	编程 会议	用于新 软件刷机的ECU启动模式
0x03	扩展诊断 会话	一个真正的诊断会话，大部分诊断工作都已 完成
0x04	系统安全 诊断会议	用于测试所有与安全 相关的ECU。例如：安全气囊
0x05 – 0x3F	保留 ISO SAE	SAE 团队可以在这些 SBF ID 下 定义任何额外的 诊断会话
0x40 – 0x5F	特定车辆制造商	每个 OEM 都可以在这些 SBF ID 下 定义任何额外的 诊断会话。 例如：沃尔沃、奥迪等。
0x60 – 0x7E	特定于系统供应商	任何供应商都可以在这些 SBF ID 下 定义任何额外的 诊断会话。 例如：Robert BOSCH
0x7F	ISO SAE 保留	它仍然保留给未来， 仍然不用于任何功能

诊断会话控制子功能标识符表

基本上，大多数 OEM 都在使用 3-4 个非常重要的子功能，我们在这里也只讨论这些子功能。大多数情况下，如果您有任何其他疑问或任何疑问，请搜索我的博客文章和问答论坛页面，即使您也可以写信给我们 piembsystech@gmail.com

1. 默认会话 （0x01）。
2. 编程会议 （0x02）。
3. 扩展诊断会话 （0x03）。
4. 系统安全诊断会话 （0x04）。

默认会话 （0x01）

每当任何 ECU 通电时，ECU 都将通过默认诊断会话激活。在此会话中，只有一些基本的诊断功能才能在运行时执行，这意味着如果车辆正在运行，您可以执行这些任务，而不会对运行时车辆造成任何阻碍或干扰。让我们去讨论请求和响应帧格式的细节，了解它是如何真正工作或由开发人员实现的。

PCI	SID	SBF	DB4	DB3	DB2	DB1	DB0
02	10	01	00	00	00	00	00

从客户端到服务器的默认会话请求消息

在这里，我将从左到右解释字节，以便更好地理解，所以请不要自己混淆。

其中第一个字节为：CAN-TP 的 02–> PCI（协议控制信息）字节。

MSB 4 位 –> 0x0 –> CAN-TP 帧类型和 0x2 –> LSB 4 位–> DLC。

第 2 字节：SID –> 0x10

第 3 字节：子函数 –> 01。

由于对于此请求，2 字节就足够了，并且 PCI 使用 1 字节，但不需要其他 3 字节。

注意：如果您不确定 PCI 和 CAN-TP 并希望了解更多信息，请参阅 CAN-TP 的主菜单。在继续了解本页的 UDS 协议之前，了解 CAN-TP 协议非常重要。通常，建议在深入研究 UDS 协议之前同时了解 CAN 协议和 CAN-TP 协议。如果您有任何疑问或问题，请随时在下面发表评论。或者，您可以通过电子邮件与我联系 piembsystech@gmail.com.

UDS 响应：服务器 –>客户端：

积极回应：

06

50

01

00

19

07

D0

00

从服务器到客户端的默认会话响应

字节 [1]：06 –> 用于 CAN-TP 的 PCI（协议控制信息）字节。

MSB 4 位 –> 0x0 –> CAN-TP 帧类型和 0x6 –> LSB 4 位–> DLC。

字节 [2]：SID –> 0x50（积极响应 = 请求 SID + 0x40）。

字节 [3]：SFID –> 0X01。

字节 [4-5]：P2 服务器计时参数（0x19 –> 25 毫秒）。

字节 [6-7]：P2* 服务器计时参数（0x7D0 –> 2 秒（十进制）。

否定回应：

03

7楼

10

12/13/22

00

00

00

00

诊断会话控制服务的否定响应帧

其中第 1 个字节为：03 –> CAN-TP 的 PCI（协议控制信息）字节。

MSB 4 位 -> 0x0 -> CAN-TP 帧类型和 0x4 -> LSB 4 位-> DLC。

第 2 个字节：-Ve 响应 SID –> 0x7F。

第 3 字节：0x10 –> SID。

第 4 个字节：0x1 –> SFID。

第 5 个字节：0x12/13/22 –> -Ve 响应 ID。

诊断会话控制请求消息布局：

数据字节	参数名称	十六进制值
0	PCI接口	0x01
1	诊断会话请求服务 ID	0x10
2	诊断会话类型	0x01-0x05

示例：请求编程会话：

字节	0	1	2	3	4	5	6	7
价值	0x01	0x10	0x02	0x55	0x55	0x55	0x55	0x55

注意：下面定义了所有否定响应 ID。

ECU复位服务标识符（0x11）

这项服务的目标是重置特定的目标ECU或所有ECU，除了车辆之外别无他物。UDS协议标准文档中提供或定义了不同类型的复位，例如硬复位、软复位、钥匙关断复位等，用于任何ECU的复位。每种重置类型都有自己的功能，用于如何重置以及需要重置的内容。要了解有关此服务的更多信息和深入信息，请选择或单击上面的链接以阅读ECU复位服务ID

安全访问 （27X）

此服务标识符用于解锁车辆中的 ECU。为了了解安全访问，我为此编写了一个单独的教程。如果您想了解更多信息，可以点击此链接作为安全访问 SID

（4）通讯控制设置：UDS协议

此服务用于控制与服务器的通信，即启用或禁用来自服务器的消息的传输和接收。

子功能：

SBF-ID的	SBF 名称
0x00	启用 Rx & Tx
0x01	启用 Rx 和禁用 Tx
0x02	禁用 Rx 和启用 Tx
0x03	禁用 Rx & Tx

例：

请求：客户端 - >服务器：03 28 00 03
其中，03 –> PCI（0–> 单帧和 3–> TP 数据长度）
28 –> SID
00–> SBF（启用 Rx 和 Tx）
03–> 通信类型为两者（正常和诊断）
+Ve 响应：02 68 00
其中，02 –> PCI（0–> 单帧和 3–> TP 数据长度）
0x68–> +Ve 响应 ID （0X28 + 0X40）
0X00 –> SBF

（5） TesterPresent （3E hex）： UDS协议

此服务的目的是向服务器（或多台服务器）指示客户端仍连接到车辆。它确保以前激活的某些诊断服务和/或通信保持活动状态。将一台或多台服务器保留在默认会话以外的诊断会话中。服务保持通信处于活动状态：避免通信超时。没有像其他服务那样的 Subfunction 参数。

例：

请求：客户端 - >服务器：02 3E 00
+VE 响应：服务器 - >客户端：02 7E 00

（6）接入时序参数（0x83）：UDS协议

此服务用于读取和更改通信链路的默认定时参数。它在此通信链路的持续时间内运行。通过使用此服务，可以读取/写入超时值和消息间隔时间。

SBF-ID的	SBF 名称
0x01	readExtendedTimingParameterSet。
0x02	setTimingParametersToDefaultValues。
0x03	readCurrentActiveTimingParameters。
0x04	setTimingParametersToGivenValues。

访问时序参数服务子功能表

（7） 安全数据传输 （0x84）：UDS 协议

根据 ISO 15764，此服务的目的是传输受保护的数据，防止可能危及数据安全的第三方攻击。如果客户端-服务器打算使用在安全模式下定义的诊断服务，则此服务适用。在这种情况下，安全模式意味着传输的数据受到加密方法的保护。发送器的安全子层对封装的服务进行编码。接收方的安全子层对封装的服务进行解码。

（8） 控制DTC设置（0x85）：UDS协议

客户端使用 ControlDTCSetting 服务来停止或恢复 ECU 中诊断故障代码 （DTC） 的设置。它用于激活/停用错误存储器中的错误存储。大多数情况下，它用于闪存编程和开发。

SBF-ID的	SBF 名称
0x01	DTC 开启
0x02	DTC 关闭

例：

客户端 –> 服务器（请求消息）
02 85 01
其中，02 –> PCI [0–> 单帧 & 2–> CAN_TP 长度]
85 –> SID
01 –> SBF [DTC 控制设置开启]
服务器 –> 客户端 （+VE 响应）
02 C5 01
02 –> PCI [0–> 单帧 & 2–> CAN_TP 长度]
C5 –> +VE 响应 SID
01 –> +VE 响应验收 SBF

（9） 事件响应 （0x86）：UDS 协议

ResponseOnEvent 服务请求服务器启动或停止对指定事件的响应传输。此服务提供了在服务器中发生指定事件时自动执行诊断服务的可能性。客户端指定事件发生时要执行的事件（包括可选事件参数）和服务（包括服务参数）。有关客户端和服务器行为的简要概述，请参见图 12。使用此服务，您可以将ECU配置为在发生定义事件时发送响应，而无需请求。

子功能：

SBF-ID的	SBF 名称
0x00	stopResponseOnEvent
0x01	onDTCStatus更改
0x02	onTimerInterrupt
0x03	onChangeOfDataIdentifier
0x04	reportActivatedEvents
0x05	startResponseOnEvent
0x06	clearResponseOnEvent
0x07	onComparisonOfValues

（10） 链路控制 （0x87）：UDS 协议

此服务用于控制测试仪和 ECU 之间的通信链路波特率，以交换诊断数据。此服务（可选）适用于允许在活动诊断会话期间进行波特率转换的数据链路层。

子功能：

SBF-ID的	SBF 名称
0x1	verifyBaudrateTransitionWithFixedBaudrate
0x2	verifyBaudrateTransitionWithSpecificBaudrate
0x3	transition波特率

baudrateIdentifier 值确定波特率。例如，11 – CAN 250 Mbps、12 – CAN500KBPS、13 – CAN 1 Mbps

数据传输功能单元：UDS协议

这些服务用于在服务器之间读取或写入数据，以满足不同的功能要求。

按标识符读取数据（22 十六进制）：UDS 协议

ReadDataByIdentifier 服务允许客户端从由一个或多个数据标识符标识的服务器请求数据记录值。ECU可能会限制一个请求中可以读取的数据标识符的数量。DataIdentifier — 标识 ECU 请求的 ECU 数据记录。

例如：

• F180 – bootSoftwareIdentificationDataIdentifier。
• F181- applicationSoftwareIdentificationDataIdentifier。
• F191 – vehicleManufacturerECUHardwareNumberDataIdentifier。

WriteDataByIdentifier （2E 十六进制）： UDS 协议

This service allows the client/Tester to write information into the server/ECU at an internal location specified by the provided data identifier. The WriteDataByIdentifier service is used by the client to write a data Record to a server. The data is identified by a data identifier and may or may not be secured.

Dynamically defined data identifier(s) shall not be used with this service. It is the vehicle manufacturer’s responsibility that the server conditions are met when performing this service. Possible uses for this service are:

–>将配置信息编程到服务器中（例如VIN）;
–> 清除非易失性存储器;
–>重置学习的值。
–>设置选项内容。

ReadMemoryByAddress （0x23）：UDS 协议

ReadMemoryByAddress 服务使客户端能够从服务器请求内存数据。它涉及指定起始地址和要读取的内存大小。

ReadMemoryByAddress 请求消息用于根据指定的内存地址和大小向服务器请求内存数据。内存地址和大小的字节计数由 addressAndLengthFormatIdentifier （低半字节和高半字节） 确定。使用固定 addressAndLengthFormatIdentifier 也是一种选择。内存地址或大小参数中任何未使用的字节都会在较高范围的地址位置中填充值 00 十六进制。

WriteMemoryByAddress （0x3D）：UDS 协议

此服务允许客户端/测试人员在一个或多个连续的内存位置将信息写入服务器/ECU。测试仪发送一个内存地址，以及一个字节数和一个数据字符串（根据字节数）。ECU将数据字符串写入其存储器。请求中的 addressAndLengthFormatIdentifier 参数指定用于内存地址和内存大小参数的字节数。

ReadScalingDataByIdentifier （24 十六进制）： UDS 协议

此服务用于从 ECU 读取由提供的数据标识符标识的记录的缩放信息。客户端请求消息包含一个数据标识符值，用于标识服务器维护的数据记录。数据记录的格式和定义特定于车辆制造商。它可能包括模拟输入和输出信号、数字输入和输出信号、内部数据和系统状态信息，前提是服务器支持它。

ReadDataByPeriodicIdentifier （2A hex）： UDS 协议

UDS 协议用于通过0x21服务标识符从服务器读取定期数据标识符。此服务允许客户端请求从服务器定期传输数据记录值。客户端的请求消息包括一个或多个 1 字节 periodicDataIdentifier 值，用于标识服务器中的数据记录。

periodicDataIdentifier 表示为此服务保留的范围内数据标识符的低字节（F2xx 十六进制，有关允许的 periodicDataIdentifier 值，请参阅 C.1）。例如，此服务中的 periodicDataIdentifier E3 十六进制对应于数据标识符 F2E3 十六进制。传输模式也在请求中指定。对于 Ex ：sendAtSlowRate、sendAtMediumRate、sendAtFastRate，请停止发送，并且上述值特定于制造商。

动态定义数据标识符（2C 十六进制）：UDS 协议

此服务的目的是使客户端能够将一个或多个数据元素分组到数据超集中。可以通过 ReadDataByIdentifier 或 ReadDataByPeriodicIdentifier 服务共同请求此超集。用于分组的数据元素可以由任一引用。这使客户端能够请求一个或多个分组数据元素的集合。

• 源数据标识符、位置和大小，或
• 内存地址和内存长度，或者
• 两种方法的组合。

存储数据传输功能单元：UDS协议

ReadDTCInformation （19 十六进制）： UDS 协议

0x19服务是 ISO 14229 标准 UDS 协议的核心。此服务的主要目的是从服务器或 ECU 读取诊断故障代码。它具有多个子功能，您可以通过这些子功能读取诊断分析所需的不同数据。您可以点击此链接，详细了解读取 DTC 信息 （0x19） 服务标识符。

清除诊断信息（14 十六进制）：UDS 协议

UDS 协议中的清除诊断信息服务（由代码 14 十六进制标识）用于重置或清除存储在电子控制单元 （ECU） 中的诊断信息。请求此服务时，ECU 会删除或重置故障代码、诊断故障代码 （DTC） 和其他诊断相关信息。它有助于清除诊断历史记录，并允许重新开始监测和诊断车辆的状况。清晰的诊断信息服务在维护和故障排除过程中起着至关重要的作用，确保为有效的车辆诊断提供准确和最新的信息。

输入输出控制功能单元：UDS协议

在UDS协议中，输入输出控制（IOC）功能单元是指控制车辆电子控制单元（ECU）中各种输入和输出功能的能力。此功能允许诊断测试仪（客户端）和ECU之间进行通信，以管理和监控输入和输出信号，例如传感器和执行器。通过输入输出控制服务，客户端可以请求ECU执行与输入和输出操作相关的特定操作，使其成为UDS协议中诊断和控制目的的关键组件。

按标识符（2F 十六进制）的输入输出控制：UDS 协议

在UDS协议中，输入输出标识符控制（2F十六进制）是一项服务，可以控制和监控车辆电子控制单元（ECU）中的各种输入和输出功能。当客户端发送具有特定标识符的请求时，ECU 会将其解释为对已识别的输入或输出执行某些操作的指令。该服务有助于与ECU进行实时交互，从而可以控制、监控和测试传感器、执行器和其他输入输出元件。通过标识符进行输入-输出控制服务对于诊断目的至关重要，并通过与ECU的有效通信来增强车辆系统的功能。

远程激活常规功能单元：UDS协议

在UDS协议中，远程激活常规功能单元是指从远程位置在车辆的电子控制单元（ECU）内启动预定义的常规或功能的能力。此服务允许客户端触发存储在 ECU 内存中的特定例程。例程可以包括需要由ECU执行的各种测试、过程或操作。远程激活常规功能单元为客户端提供了一种远程启动特定程序的方法，从而在车辆的电子系统中实现诊断测试、配置更改或其他预定义操作。

常规控制（31 十六进制）：UDS 协议

车辆诊断可能需要在给定的参数范围内测试故障部件。在车辆测试期间，某些系统测试可能需要延长运行时间。若要启动测试，客户端会在服务器内存中触发例程。此 UDS 协议远程请求服务中存在两种方法：一种是客户端中断例程以停止例程，另一种是服务器/ECU 在指定的时间范围后完成例程。此服务允许客户端在成功执行后启动、中断和检查例程的结果。

UDS 标准中定义的例程控制服务之一是擦除内存或擦除闪存例程。它将在加载新模块之前执行EEPROM和闪存的擦除。它具有例程标识符 FF01，在 UDS 请求中的字节 #3-4 上指定。请求的其余字节包含一个例行控制选项记录，该记录的长度可变，具体取决于车辆制造规格和使用的例行标识符。启动“擦除闪存例程控制”服务的示例。

让我解释一下为什么我们需要这种例行控制服务。车库内的服务诊断工程师可以使用此服务使发动机风扇运行一段时间并记录结果。这将帮助他很好地理解特定问题并在不使用任何打击和试验方法的情况下纠正它。

请求：RoutineControl类型：

1. startRoutine （01 十六进制）。
2. stopRoutine（02 十六进制）。
3. reqestRoutineControl （03 十六进制）。

RoutineIdentifier： 此参数标识服务器的本地例程。

例行控制请求消息布局：

数据字节	参数名称	十六进制值
0	PCI接口	0x01
1	常规控制 SID	0x31
2	例程标识符	0x00-0xFF
3	例程ControlType	0x01-0x03

例行控制请求消息布局：

例：

典型的擦除闪存例程控制 UDS 请求。此请求旨在在下载块0x15之前开始擦除 EEPROM 或闪存扇区。

价值	1	2	3	4	5	6	7	8
字节	0x31	0x01	0xFF	0x00	0x01	0x15	–	–

反应：

积极响应代码：

• 例程控制类型：此参数是请求消息中子函数参数的位 6 – 0 的回显。
• routineIdentifier： 此参数是请求消息中 routineIdentifier 的回显。

否定响应代码：

• 不支持子功能（12 十六进制）： 如果请求的子函数不受支持，则返回此代码。
• 邮件长度不正确或格式无效（13 十六进制）： 消息的长度是错误的。
• 条件不正确（22 十六进制）： 如果不满足请求 RoutineControl 的条件，则应返回此代码。
• 请求序列错误（24 十六进制）： 如果收到“停止例程”子函数而未首先收到请求例程标识符的“启动例程”，则应返回此代码。
• 请求超出范围（31 十六进制）： 如果服务器不支持请求的 routineIdentifier，则应返回此代码。
• 安全访问被拒绝（33 十六进制）： 如果客户端发送的请求具有有效的安全例程标识符，并且服务器的安全功能当前处于活动状态，则返回此代码，则应发送此代码。
• 常规编程失败（72 十六进制）： 如果服务器在执行访问服务器内部存储器的例程时检测到错误，则应发送此返回代码。例如，当例程擦除或编程永久存储设备（例如闪存）中的某个存储器位置时，对该存储器位置的访问失败。

上传下载功能单元：UDS协议

请求下载（34 十六进制）：UDS 协议

当数据要传输到 ECU 时，将调用请求下载服务。请求应包含要传输的数据的大小和放置地址。ECU 以其缓冲区的大小进行响应，以便发送方可以将数据划分为适当大小的块，并一次发送一个。

请求：请求中可以包含四个不同的请求参数。

1. 请求下载服务标识符： 此参数是任何类型的下载请求的服务 ID。
2. DataFormatIdentifier：此数据参数是一个单字节值，每个半字节单独编码。高半字节指定“压缩方法”，低半字节指定“加密方法”。值 0x00 指定不使用压缩方法或加密方法。
3. AddressAndLengthFormatIdentifier：
   • 位 7 – 4：内存大小参数的长度（字节数）。
   • 位 3 – 0：内存地址参数的长度（字节数）。
4. 内存地址：参数 memory Address 是要将数据写入的服务器内存的起始地址。
5.  内存大小 （unCompressedMemorySize）： 服务器应使用此参数将未压缩的内存大小与 TransferData 服务期间传输的数据总量进行比较。

请求下载请求消息格式：

数据字节	参数名称	十六进制值
0	PCI接口	0x01
1	请求下载 SID	0x34
2	数据格式标识符	0x00 – 0xFF
3	addressAndLengthFormatIdentifier	0x00 – 0xFF
4…n	memory地址	0x00-0xFF
n…m	内存大小	0x00-0xFF

反应：

积极响应代码：

• 长度格式标识符：
  1. 位 7 – 4：maxNumberOfBlockLength 参数的长度（字节数）。
  2. 位 3 – 0：由文档保留，设置为 0 十六进制。

最大块长度数： 请求下载肯定响应消息使用参数将每个 TransferData 请求的 maxNumberOfBlockLength 传达给客户端。此长度包括 TransferData 请求消息中的服务标识符和数据参数。该参数的作用是使客户端能够在启动数据传输过程之前适应服务器的接收缓冲区大小。

请求下载响应消息 LayOut：

数据字节	参数名称	十六进制值
0	PCI接口	0x01
1	请求下载 RSID	0x74
2	lengthFormatIdentifier	0x00-0xFF
3	maxNumberOfBlockLength	0x00-0xFF

例：

客户端 –> 服务器（请求）
34 00 45 01 00 04 00 00 00 09 93 78
服务器 –>客户端（+ve 响应）
74 20 0F FA
服务器 –> 客户端（-ve 响应）
7F 74 13/22/31

请求下载服务 （0x34） 完整的教程在我们的新文章中提供。如果您有兴趣学习，请单击此 RequestDownloadService（0x34） 教程。

否定响应代码：

• 邮件长度不正确或格式无效（13 十六进制）：消息的长度是错误的。
• 条件不正确（22 十六进制）： UDS 代表 统一诊断服务。它是测试仪和车辆电子控制单元 （ECU） 之间通信的标准。UDS 通过 CAN 总线使用 ISO 14229 和 ISO 15765-2。
• 请求超出范围（31 十六进制）：如果出现以下情况，则应发送此返回代码：
  1. 指定的数据格式标识符无效，
  2. 指定的 addressAndLengthFormatIdentifier 无效，或者
  3. 指定的 memory Address/memory Size 无效。
• SecurityAccessDenied（33 十六进制）： 服务器在请求时发送 SecurityAccess 服务的此返回代码，并且服务器是安全的。
• UploadDownloadNotAccepted（70 十六进制）： 此响应代码表示由于故障情况，无法尝试下载到服务器的内存。

请求上传（35 十六进制）服务

客户端请求协商从服务器到客户端的数据传输。此服务与0x34 SID 正好相反。请求下载肯定响应消息使用参数将每个 TransferData 请求的 maxNumberOfBlockLength 传达给客户端。此长度包括 TransferData 请求消息中的服务标识符和数据参数。该参数使客户端能够在启动数据传输过程之前适应服务器的接收缓冲区大小。

数据字节	参数名称	十六进制值
1	请求上传 SID	35
2	dataFormatIdentifier	00-FF型
3	addressAndLengthFormatIdentifier	00-FF型
4	memoryAddress[]=[Byte1（MSB） – Byten（）LSB]	00-FF 至 00-FF
5	memorySize[]= [字节1（MSB） – Byten（）LSB]	00-FF 至 00-FF

数据格式标识符： 此数据参数是一个单字节值，每个半字节单独编码。高半字节指定“压缩方法”，低半字节指定“加密方法”。值 00 十六进制指定不使用压缩方法或加密方法。00 十六进制以外的值特定于车辆制造商。

AddressAndLengthFormatIdentifier： 该参数是一个字节值。每个半字节都单独编码，以识别内存阵列中的地址和数据。

• 位 7 – 4：“内存大小”参数的长度（字节数）;
• 位 3 – 0：“内存地址”参数的长度（字节数）。

内存地址：参数 memory Address 是要从中检索数据的服务器内存的起始地址。此地址的字节计数由地址格式标识符的低半字节（位 3 – 0）定义。内存 Address 参数中的 Byte#m 始终是服务器中引用的地址的最低有效字节。地址的最高有效字节可用作内存标识符。

内存大小：服务器使用此参数将未压缩的内存大小与传输数据服务中传输的总数据进行比较，从而增强了编程安全性。地址和长度格式标识符的高半字节定义了用于此目的的字节计数。

例：

客户端 –> 服务器（请求）
35 00 45 01 00 04 00 00 00 09 93 78
服务器 –> 客户端（响应）

传输数据（36 十六进制）：UDS 协议

传输数据服务接收数据块并进行检查，以便按正确的顺序接收数据块。如果接收到正确的块，则将其写入正确的内存位置并发送正响应。

请求：

BlockSequenceCounter： blockSequenceCounter 参数值从 01 十六进制开始，第一个 TransferData 请求位于 RequestDownload （34） 十六进制服务之后。对于每个后续的 TransferData 请求，其值将递增 1。在 FF 十六进制值时，blockSequenceCounter 将滚动并从 00 十六进制开始，并显示下一个 TransferData 请求消息。

传输数据请求消息帧格式：

数据字节	参数名称	十六进制值
0	PCI接口	0x01/0x10/0x20-0x2F
1	传输数据 SID	0x36
2	blockSequenceCounter	0x00-0xFF
3..n	数据	0x00-0xFF

反应：

积极响应代码：

• 块序列计数器。
• 此参数是请求消息中块序列计数器参数的回显。

传输数据响应消息布局：

数据字节	参数名称	十六进制值
0	PCI接口	0x01/0x10/0x20-0x2F
1	传输数据 SID	0x76
2	块序列计数器	0x00-0xFF

阴性 Response C颂歌：

• 邮件长度不正确或格式无效（13 十六进制）： 消息的长度是错误的（例如，消息长度不符合对请求下载的肯定响应中返回的最大块长度数参数的要求）。
• 请求序列错误 （24 十六进制） ：请求序列错误 （NRC 24 十六进制） 与传输数据服务 （36 十六进制） 有关。当数据传输过程中发出的请求顺序存在差异或错误时，将触发此错误响应。NRC 24 十六进制，具体表示“请求序列错误”，表示收到的请求未按预期或正确的顺序排列，从而导致数据传输过程失败。此错误机制可确保数据交换序列的完整性，并提示客户端在继续 UDS 通信中的传输数据服务之前解决序列问题。

服务器应使用以下响应代码：

• 如果在收到此服务的请求时请求下载服务未处于活动状态。
• 如果请求下载服务处于活动状态，但服务器已收到由活动请求下载或请求上传服务中的内存大小参数确定的所有数据。

请求超出范围（31 十六进制）： 如果传输请求参数记录包含其他控制参数（例如其他地址信息）并且此控制信息无效，则应发送此返回代码。

• 传输数据暂停（71 十六进制）： 如果出现以下情况，则应发送此返回代码：
  1. 响应代码指示数据传输操作因故障而停止。
  2. 下载模块长度不符合请求下载服务的请求消息中发送的 memory Size 参数的要求。
• GeneralProgrammingFailure（72 十六进制）： 如果服务器在下载数据期间擦除或编程永久存储设备（例如闪存）中的内存位置时检测到错误，则应发送此返回代码。
• WrongBlockSequenceCounter （73 十六进制）： 如果服务器在 blockSequenceCounter 的序列中检测到错误，则应发送此返回代码。

服务器应接受具有块序列计数器的传输数据请求消息的重复，该消息的块序列计数器等于上一个传输数据请求消息中包含的序列计数器。

请求 TransferExit（37 十六进制）：UDS 协议

数据传输完成后，将向请求传输退出服务发送一条消息。如果传输数据已完成并已收到所有数据，则会发回肯定的响应。

请求：

请求传输退出请求消息布局：

数据字节	参数名称	十六进制值
0	PCI接口	0x01
1	请求传输退出 SID	0x37

响应：

请求传输退出响应消息布局：

数据字节	参数名称	十六进制值
0	PCI接口	0x01
1	请求转账退出 RSID	0x77

否定响应代码：

• 邮件长度不正确或格式无效（13 十六进制）： 消息的长度是错误的。
• 请求序列错误 （24 十六进制）：服务器应使用以下响应代码：
  1. 收到此服务的请求时，编程过程未完成。
  2. RequestDownload 服务未处于活动状态。

请求文件传输（38 十六进制）：UDS 协议

请求文件传输服务用于通过下载或上传功能启动从客户端到服务器或服务器到客户端的文件数据传输。此服务是请求下载和请求上传服务的替代方法，可提供更好的保护和高级数据传输方法。

UDS协议中使用的术语

• UDS汽车协议：探索UDS汽车协议，这是汽车行业中使用的标准化通信方法。
• UDS 通信协议：了解 UDS 通信协议及其在高效车辆诊断中的作用。
• UDS 诊断协议：深入了解 UDS 诊断协议，这是诊断和排除汽车系统故障的关键方面
• UDS 协议概述：全面了解 UDS 协议及其在汽车行业的相关性。
• UDS协议实施：了解UDS协议在汽车系统中的实施过程，以便进行有效诊断。
• UDS 协议规范：了解 UDS 协议的规范，包括消息格式和通信要求。
• UDS 协议功能：了解 UDS 协议的主要功能，使其成为车辆诊断的重要工具。
• UDS 协议优势：探索使用 UDS 协议实现高效、准确的车辆诊断的优势。
• UDS协议应用：了解UDS协议在汽车行业不同领域的各种应用。
• UDS 协议开发：深入了解 UDS 协议的开发过程及其随时间的演变。
• UDS 协议测试：了解测试 UDS 协议的重要性，以确保其可靠性和与不同系统的兼容性。
• UDS 协议安全性：探索集成到 UDS 协议中的安全措施，以防止未经授权的访问和数据泄露。
• UDS 协议标准：了解与 UDS 协议相关的行业标准及其在确保兼容性和互操作性方面的作用。

• AUTOSAR DCM型
• 负响应代码 （NRC）：UDS 协议
• UDS的应用：ECU闪存编程
• 请求下载 （0x34） 服务：UDS 协议
• 请求文件传输 （0x38） 服务：UDS 协议

---

总结

参考链接（包括但不限于）：
UDS Protocol - PiEmbSysTech

题外话

以上就是今天要讲的内容，如果您觉得文章还不错，还请您给个三连加关注，非常感谢！

本文作者：WeSiGJ

欢迎加入技术交流群：

QQ群：701203462