UDS 85h服务为何无法激活ECU诊断会话？

Question

在使用UDS（统一诊断服务）时，85h服务（即控制DTC设置）常被误认为可触发ECU进入特定诊断会话。然而，85h服务本身并不具备激活诊断会话的功能。其作用仅为启用或禁用DTC的存储，不能改变ECU的当前会话模式。若未先通过10h服务正确切换至扩展会话或编程会话，直接发送85h指令将导致请求被拒绝（通常返回否定响应NRC 0x7F或0x12）。因此，常见问题是：为何发送85h服务后ECU未响应或无法执行后续操作？根本原因在于缺少前置的会话切换步骤。正确流程应为：先通过10h服务激活目标诊断会话，再执行85h控制DTC设置。忽略此顺序是导致诊断失败的典型配置错误。

Answer 1

1. 问题背景与常见误解

在使用UDS（统一诊断服务）协议进行ECU诊断通信时，许多工程师误认为发送 0x85 服务（控制DTC设置）可以触发ECU进入某种特定的诊断会话模式。这种误解源于对UDS服务功能边界的模糊理解。实际上，0x85服务仅用于启用或禁用DTC（诊断故障码）的记录行为，其子功能支持如开启/关闭DTC存储、暂停DTC检测等操作。

然而，该服务。若当前ECU处于默认会话（Default Session），直接发送 85h 请求将被拒绝，通常返回否定响应码 NRC 0x7F（服务不支持）或 NRC 0x12（子功能不支持）。这一现象常导致初学者困惑：“为何我的指令无响应？” 其根本原因在于忽略了UDS协议中严格的会话依赖机制。

2. UDS会话管理机制解析

UDS协议定义了多个诊断会话模式，主要通过 0x10 服务（诊断会话控制）实现切换。常见的会话类型包括：

• 0x01 - 默认会话（Default Session）：上电后初始状态，仅支持有限服务
• 0x02 - 编程会话（Programming Session）：用于刷写固件
• 0x03 - 扩展会话（Extended Session）：支持大多数诊断功能，如DTC控制、I/O控制等
• 0x04 - 安全会话（Safety System Session）：特定安全相关功能

每个会话具有不同的权限级别，高权限服务（如0x85）必须在扩展会话或编程会话下才能执行。这是UDS安全架构设计的一部分，防止未经授权的操作影响系统稳定性。

3. 错误案例分析流程图

graph TD
    A[开始诊断] --> B{是否已切换至扩展会话?}
    B -- 否 --> C[发送0x85服务]
    C --> D[ECU返回NRC 0x7F或0x12]
    D --> E[诊断失败]
    B -- 是 --> F[成功执行0x85服务]
    F --> G[完成DTC设置控制]

4. 正确操作流程与代码示例

为确保0x85服务正确执行，必须遵循标准流程：

1. 建立物理/功能寻址通信
2. 发送 10 03 进入扩展会话
3. 等待正响应 50 03
4. 可选：进行安全访问（若受保护）
5. 发送 85 01（启用DTC设置）或 85 02（禁用）
6. 验证响应 C5 01 或 C5 02

步骤	请求数据	预期响应	说明
1	10 03	50 03	进入扩展会话
2	27 01 (种子)	67 01 XX XX	安全访问请求（如需要）
3	27 02 (密钥)	67 02	提供计算后的密钥
4	85 01	C5 01	启用DTC存储
5	85 02	C5 02	禁用DTC存储
6	85 FF	7F 85 12	无效子功能，返回NRC 0x12
7	未切会话发85	7F 85 7F	NRC 0x7F表示服务不可用
8	3E 00	7E 00	保持会话激活（可选）
9	14 FF FF FF	54 FF FF FF	清除所有DTC
10	19 02 01	59 02 01 ...	读取DTC信息

5. 深层技术原理与协议规范依据

根据 ISO 14229-1:2020 标准文档，服务0x85的服务前提条件明确指出："The server shall only process this service if it is in a session other than the default session." 即服务器仅在非默认会话下处理此服务。这意味着即使ECU实现了0x85功能，也必须满足会话状态要求。

此外，NRC（否定响应码）的设计体现了分层校验逻辑：

• NRC 0x12：Sub-function not supported – 表示子功能无效或当前上下文不支持
• NRC 0x7F：Service not supported in active session – 明确指示服务在当前会话中不可用
• NRC 0x22：Conditions not correct – 常用于安全访问未完成等情况

这些NRC的返回顺序和条件构成了UDS错误处理的核心机制，帮助开发者逐层排查问题根源。