4. UDS常用服务

UDS（Unified Diagnostic Services，统一诊断服务）是ISO 14229标准定义的应用层诊断协议，它规定了诊断仪（Tester）与ECU（电子控制单元）之间进行诊断通信的标准化服务集合。在车载诊断协议栈中，UDS服务是诊断功能的核心载体，无论是产线终检、售后故障排查，还是OTA刷写前的会话切换，都离不开对UDS服务的精确调用。本章将聚焦于最常用的几类UDS服务：诊断会话控制（0x10）、ECU复位（0x11）、安全访问（0x27）、读取数据（0x22）、写入数据（0x2E）以及相关的读写扩展服务，深入剖析其原理、报文格式、时序流程和工程实践中的关键要点。

上图展示了UDS常用服务之间的逻辑关系与典型调用链路。在实际工程中，这些服务并非孤立使用，而是按照一定的时序和依赖关系组合调用。例如，写入标定数据前必须先进入扩展会话并完成安全解锁；ECU复位后会自动回到默认会话，需要重新进行会话切换。理解这些服务间的耦合关系，是设计诊断测试序列和排查通信故障的基础。

4.1 诊断会话控制服务（0x10）

4.1.1 核心原理

诊断会话控制服务用于切换ECU的诊断会话状态。ECU上电后默认进入默认会话（Default Session），该会话下仅允许执行读取类服务（如0x22读取数据、0x19读取故障码）和部分不影响安全的功能。当需要执行编程、标定或特殊测试时，必须切换到编程会话（Programming Session）或扩展会话（Extended Session）。会话切换的本质是改变ECU内部诊断状态机的运行等级，不同等级对应不同的服务权限和定时参数（如P2Server定时、S3Server定时）。

4.1.2 报文格式与操作流程

请求报文格式为：0x10 + Sub-function。常见的子功能定义如下表：

操作流程如下：

1. 诊断仪发送 0x10 03 请求进入扩展会话。
2. ECU校验当前状态，若允许切换，则回复 0x50 03（肯定响应）。
3. 若ECU正在执行其他任务或不允许切换，则回复 0x7F 10 22（条件不满足）或 0x7F 10 12（子功能不支持）。
4. 切换成功后，ECU启动S3Server定时器（默认5000ms），若超过该时间未收到任何诊断请求，ECU自动退回默认会话。

4.1.3 案例拆解：OTA刷写前的会话切换

某车型OTA升级时，诊断仪需要将ECU从默认会话切换到编程会话。初始现象：直接发送 0x10 02 后，ECU回复 0x7F 10 22（条件不满足）。分析过程：查阅该ECU的诊断规范发现，进入编程会话前必须先进入扩展会话，且需要满足车速为0、发动机熄火等安全条件。实际操作：先发送 0x10 03 进入扩展会话，再发送 0x10 02 切换至编程会话，同时通过读取DID 0xF190（车速）确认车辆状态。结果：切换成功，后续刷写流程正常执行。复盘：会话切换并非简单的命令发送，必须结合ECU的状态机设计和安全策略，否则会触发NRC。

4.1.4 常见误区

• 误区一：认为所有ECU都支持0x10 02直接切换。实际上，部分ECU要求先进入扩展会话，再进入编程会话。
• 误区二：忽略S3Server定时器。若诊断仪长时间不发送请求，ECU自动退回默认会话，导致后续服务被拒绝。
• 误区三：在会话切换后立即发送写操作，未等待ECU完成内部状态初始化。

4.2 ECU复位服务（0x11）

4.2.1 核心原理

ECU复位服务用于强制ECU执行一次复位操作，包括硬件复位、软件复位或快速下电。复位后ECU会重新初始化所有硬件和软件模块，并自动进入默认会话。该服务常用于刷写完成后重启ECU、清除异常状态或恢复通信。

4.2.2 子功能定义与选择

操作流程：诊断仪发送 0x11 03，ECU收到后回复 0x51 03（肯定响应），随后立即执行复位。诊断仪需在复位后等待ECU重新上线（通常需要500ms-2s），再重新建立通信。

4.2.3 实战场景：刷写后的自动复位

在OTA刷写流程中，刷写完成后诊断仪发送 0x11 01 硬复位，使ECU从Bootloader跳转到应用程序。关键参数：复位后等待时间设为1500ms，若超过3s未收到ECU的0x11响应或后续的0x10 01响应，则判定复位失败。实际操作中，诊断仪需监听CAN总线上的网络管理报文（如0x100），确认ECU已重新上线。结果：复位成功，ECU进入默认会话，可继续执行故障码清除操作。

4.2.4 常见误区

• 误区一：复位后立即发送诊断请求，导致NRC 0x78或超时。
• 误区二：在刷写过程中使用软复位，导致程序指针错乱。
• 误区三：忽略复位对通信地址的影响，部分ECU复位后CAN ID会改变。

4.3 安全访问服务（0x27）

4.3.1 核心原理

安全访问服务用于保护ECU中的敏感数据（如标定参数、密钥、VIN码）不被未授权访问。其原理是挑战-应答机制：诊断仪发送请求种子（Seed），ECU返回一个随机种子；诊断仪使用特定算法计算密钥（Key），并发送给ECU；ECU校验密钥是否正确，若正确则解锁安全等级。安全访问通常分为多个等级（如0x01/0x02为等级1，0x03/0x04为等级2），不同等级对应不同的数据访问权限。

4.3.2 操作流程与算法要求

1. 诊断仪发送 0x27 01（请求种子）。
2. ECU回复 0x67 01 + Seed（4字节）。
3. 诊断仪使用种子和密钥算法计算Key。
4. 诊断仪发送 0x27 02 + Key（4字节）。
5. ECU校验Key，若正确回复 0x67 02，否则回复 0x7F 27 35（无效密钥）。

密钥算法通常由OEM定义，常见算法包括：种子与固定常数异或、CRC16校验、AES加密等。算法必须保密，且每次解锁尝试次数有限（通常3次），超过次数后ECU会锁定安全访问功能一段时间（如10秒）。

4.3.3 案例拆解：安全访问失败排查

某ECU在产线终检时，诊断仪发送 0x27 01 后收到种子 0x12345678，计算密钥后发送 0x27 02 0x9ABCDEF0，但ECU回复 0x7F 27 35。分析过程：检查密钥算法发现，该ECU的算法为“种子与0x5A5A5A5A异或后取反”，而诊断仪使用的是“种子与0xA5A5A5A5异或”。修正算法后，重新发送密钥，解锁成功。复盘：安全访问失败90%以上是密钥算法错误或字节序问题（大端/小端），建议在开发阶段使用OEM提供的算法验证工具。

4.3.4 常见误区

• 误区一：忽略安全访问的尝试次数限制，导致ECU锁定。
• 误区二：在默认会话下请求种子，未先切换至扩展会话。
• 误区三：密钥计算时未考虑字节序（如种子为小端存储，但算法按大端计算）。

4.4 读取数据服务（0x22）与写入数据服务（0x2E）

4.4.1 核心原理

读取数据服务（0x22）通过DID（Data Identifier，数据标识符）读取ECU内部数据，如VIN码、软件版本号、传感器实时值、故障码状态等。写入数据服务（0x2E）则通过DID写入数据，如标定参数、配置信息、VIN码等。DID是16位的标识符，范围从0xF000到0xF1FF为OEM自定义区域，0xF190通常表示车速，0xF187表示VIN码。

4.4.2 报文格式与操作流程

读取请求：0x22 + DID（2字节），响应：0x62 + DID + 数据。写入请求：0x2E + DID + 数据，响应：0x6E + DID。写入操作通常需要安全解锁，且部分DID只允许在特定会话下写入。

4.4.3 实战场景：VIN码写入

在整车下线时，需要将VIN码写入ECU。初始现象：诊断仪发送 0x2E F187 + VIN码，ECU回复 0x7F 2E 31（请求超出范围）。分析：该ECU要求写入VIN码前必须先进入扩展会话并完成安全访问。操作：发送 0x10 03 进入扩展会话，发送 0x27 01/02 完成解锁，再发送 0x2E F187 + VIN码。结果：ECU回复 0x6E F187，写入成功。复盘：写入类服务必须严格遵循“会话切换→安全解锁→写入”的时序，且VIN码的字节序必须与ECU定义一致（通常为ASCII码直接存储）。

4.4.4 常见误区

• 误区一：写入数据时未检查DID的写入条件（如只读DID被写入）。
• 误区二：读取数据时DID长度不匹配，导致NRC 0x13。
• 误区三：写入数据后未执行读取回读验证，导致数据错误未被发现。