UDS诊断服务基础详解之十四—85服务
目录
1 85服务的总体介绍
1.1 定义
1.2 85服务使用的场景
2 85服务的请求
2.1 85服务的请求格式
2.2 85服务请求参数说明
3 85服务的响应
3.1 85服务的肯定响应
3.2 85服务支持的否定响应码
4 举例说明
4.1 开启DTC设置举例
4.2 关闭DTC设置（并抑制响应）举例
4.3 否定响应举例
5 总结
1 85服务的总体介绍
1.1 定义
85服务，即ControlDTCSetting（控制故障码设置）服务，是UDS协议中用于动态管理ECU内部故障诊断功能（即DTC监控与存储）的开关。此服务允许客户端（如诊断仪、测试工具）请求服务器（ECU）临时禁止或恢复 DTC（诊断故障码）的设置为存储。
需要深刻理解的是，85服务并不清除已存储的DTC，也不影响故障本身的检测。它控制的是“检测到故障后，是否将对应的DTC及其相关快照信息记录到非易失性存储器中”这一行为。当DTC设置被禁止时，ECU的诊断功能仍在后台运行，并能够检测到故障，但不会产生新的DTC记录或更新已存在DTC的状态位（如故障发生计数器、待定码状态等）。一旦恢复DTC设置，所有诊断功能将恢复正常，新检测到的故障会被立即记录。
85服务是UDS诊断体系中实现生产下线检测、软件刷写、特定诊断操作及车辆维护等关键流程的核心服务，它能有效防止在这些特定场景下产生无关或干扰性的故障码，确保诊断数据的纯净性与有效性。
1.2 85服务使用的场景
场景1：车辆生产下线检测与终端装配
在整车生产线的末端，需要进行一系列功能性测试，例如激活执行器、读取传感器信号。这些测试操作本身可能不符合车辆的正常运行条件，从而触发大量的、临时的故障码（如“执行器电路开路”、“信号不可信”）。如果这些非真实的故障码被记录下来，会给后续的质量检查和售后维修带来极大的困扰和误判。因此，在开始下线检测程序前，诊断设备会通过85服务禁止所有ECU记录DTC。待所有测试完成后，再恢复DTC设置。这样，最终存储在ECU中的DTC只包含真实的、在测试后仍存在的故障。
场景2：ECU软件刷写或标定更新
在进行ECU软件重构（刷写）或标定数据更新时，ECU会经历复位、重启过程。在此期间，许多传感器和执行器可能处于未初始化或通信中断的状态，这极易触发通信类DTC（如UXXXX系列）或配置不匹配的DTC。通过在执行刷写程序前（通常在进入编程会话后）使用85服务禁止DTC设置，可以避免这些与刷写过程本身相关的、无实际意义的故障码被记录。刷写完成并验证后，再恢复DTC设置。
场景3：执行特定诊断例程或维修操作
维修技师在进行某些特定的维修或诊断步骤时，可能需要主动触发一个在正常行驶中不会出现的条件。例如，为了测试燃油系统，可能需要强制断开某个传感器的连接。如果不希望这个人为操作导致一个永久性的DTC被记录，技师可以在操作前使用85服务禁止DTC设置，操作完成并读取所需数据后，再将其恢复。
场景4：车辆排放检测或实验室测试
在排放检测或特定的实验室台架测试中，测试循环可能要求关闭某些与排放无关的系统故障记录，以避免非排放相关的DTC导致测试中断或结果无效。85服务为此提供了标准化控制手段。
2 85服务的请求
2.1 85服务的请求格式
85服务的请求通过一个子功能参数来定义所要执行的具体操作（开启或关闭）。它不支持数据标识符，其格式相对简单。
| 字节 | 参数名称 | 参数约定 | 数值（Hex） |
|---|---|---|---|
| Byte1 | Request SID 请求服务ID | M | 85 |
| Byte2 | subfunction 子功能参数 | M | 01 |
| Byte3（可选） | DTCSettingControlOptionRecord DTC设置控制选项记录 | C | 00 to FF |
参数约定说明：
-
M (Mandatory)： 必须发送的参数。
-
C (Conditional)： 有条件发送的参数，取决于子功能或制造商定义。
2.2 85服务请求参数说明
-
subfunction（子功能参数）：
这是一个1字节的参数，其最高位（bit 7）用于抑制肯定响应消息（Suppress Positive Response Message, SPRM）。其余7位（bit 6-0）定义了具体的服务模式。-
85 01： on - 开启DTC设置。此请求将使能ECU的DTC存储功能。 -
85 02： off - 关闭DTC设置。此请求将禁用ECU的DTC存储功能。
抑制肯定响应位（bit 7）的应用：如果客户端在请求中将子功能参数设置为
0x81（即0x01 | 0x80）或0x82（即0x02 | 0x80），则表示请求服务器在执行命令后，不发送肯定响应。这在需要高频发送命令以减少总线负载的场景下非常有用，例如在生产线快速循环测试中。 -
-
DTCSettingControlOptionRecord（可选）：
此参数在ISO 14229-1标准中预留，通常由车辆制造商自定义其内容和用法。例如，制造商可以利用此字段来指定仅对某类DTC（如仅与动力总成相关的DTC）进行设置控制，而不是控制所有DTC。但在大多数基础实现中，ECU在接收到85 01或85 02请求后，会全局性地开启或关闭所有DTC的设置功能，且此选项记录字段为空（即不发送）。
3 85服务的响应
3.1 85服务的肯定响应
85服务的肯定响应格式非常简洁，它回显服务ID和子功能参数，以确认命令已被成功执行。
| 字节 | 参数名称 | 参数约定 | 数值（Hex） |
|---|---|---|---|
| Byte1 | Positive Response SID 肯定响应回复ID | M | C5 |
| Byte2 | subfunction 回显的子功能参数 | M | 01 or 02 |
响应分析：
-
当客户端发送
85 01（开启DTC设置）后，ECU成功执行后将回复C5 01。 -
当客户端发送
85 02（关闭DTC设置）后，ECU成功执行后将回复C5 02。 -
如果请求中使用了抑制肯定响应位（如
85 81），则ECU在执行命令后将不回复任何消息。
3.2 85服务支持的否定响应码
当控制DTC设置的请求无法被执行时，ECU会回复否定响应。常见的否定响应码如下：
| NRC | 描述 | 可能原因 |
|---|---|---|
| 12 | 子功能不支持 Sub-function not supported | 请求的子功能参数不是01（on）或02（off）。 |
| 13 | 报文长度错误 Incorrect message length or invalid format | 请求报文长度不正确（例如，对于简单的on/off请求，长度应为2字节，但收到了3字节或更多，且ECU不支持选项记录）。 |
| 7F | 会话条件不满足 serviceNotSupportedInActiveSession | 该服务在当前会话下不支持 |
4 举例说明
4.1 开启DTC设置举例
在完成软件刷写后，诊断工具需要恢复ECU的DTC记录功能。
-
诊断仪请求：
02 85 01 -
ECU肯定响应：
02 C5 01
请求分析：
-
02： 有效数据长度为2字节。 -
85： 85服务请求。 -
01： 子功能，表示“开启DTC设置”。
响应分析：
-
02： 有效数据长度为2字节。 -
C5： 85服务的肯定响应ID。 -
01： 回显请求的子功能，确认DTC设置已被开启。
4.2 关闭DTC设置（并抑制响应）举例
在生产线上，测试系统为了快速进入测试状态，不希望等待ECU的响应，因此发送抑制肯定响应的请求来关闭DTC设置。
-
诊断仪请求：
02 85 82 -
ECU响应： 无（肯定响应被抑制）
请求分析：
-
02 85： 2字节的85服务请求。 -
82： 子功能。0x82=0x02（关闭DTC设置）与0x80（抑制肯定响应位）的按位或结果。ECU执行关闭操作后，不会发送肯定响应。
4.3 否定响应举例
诊断仪在默认会话中尝试关闭DTC设置，但ECU策略规定此操作必须在扩展诊断会话中执行。
-
诊断仪请求：
02 85 02 -
ECU否定响应：
03 7F 85 22
请求分析：
-
02 85 02： 请求在默认会话下关闭DTC设置。
响应分析：
-
03： 有效数据长度为3字节。 -
7F： 否定响应标识。 -
85： 表明是对85服务的否定响应。 -
22： 否定响应码，表示“条件不满足”。
5 总结
通过上文对85服务的详细解析，我们可以清晰地认识到，控制故障码设置服务在UDS诊断体系中扮演着“诊断流程管理器”和“数据质量守护者”的关键角色。
核心价值与战略意义：
-
保障制造与维护效率：85服务是车辆生产和维修环节不可或缺的工具。它通过消除非故障性DTC的干扰，极大地提高了生产线终检效率和售后维修的精准度，避免了因“误报”故障码导致的ECU不必要的更换和复杂的故障排查，直接节约了时间和经济成本。
-
确保诊断数据的真实性与有效性：在ECU软件更新、系统标定等关键操作期间，85服务维护了诊断数据记录的“纯洁性”。它确保了最终存储在ECU非易失性存储器中的每一个DTC，都真实反映了车辆在正常运营状态下所发生的故障，为基于大数据的车辆健康管理、预测性维护和零部件质量追溯提供了可靠的数据基石。
-
精细化诊断管理：虽然基础请求是全局开关，但通过可选的选项记录，85服务具备了实现精细化控制的潜力。制造商可以定义更复杂的控制策略，例如仅屏蔽特定系统的DTC，这体现了UDS协议在标准化基础上的高度灵活性。
与其他服务的协同工作流：
85服务几乎从不孤立存在，它总是嵌入在一个更复杂的诊断工作流中，与其他UDS服务紧密协作：
-
与10服务（诊断会话控制）和27服务（安全访问）的强依赖关系：
-
绝大多数ECU要求，执行
85 02（关闭DTC设置）必须先通过10服务切换到扩展诊断会话或编程会话。 -
随后，通常需要执行27服务，通过种子与密钥的交换，获取足够高的安全等级权限。只有在通过安全认证后，ECU才会允许关闭DTC设置。这是一个典型的安全链条：会话控制 -> 安全访问 -> 功能控制。
-
-
与19服务（读取DTC信息）和14服务（清除DTC信息）的配合：
-
在一个完整的维修或测试流程中，常见的顺序是：
a. 进入扩展会话（10 03）。
b. 通过安全认证（27 01...27 02）。
c. 关闭DTC设置（85 02），防止后续操作产生无效DTC。
d. 执行特定的测试、刷写或维修操作。
e. 开启DTC设置（85 01），恢复正常的故障监控。
f. 清除DTC信息（14 FF FF FF），将之前可能存在的、以及操作过程中产生的易失性故障状态彻底清空。
g. 进行路试或功能测试，让ECU重新检测故障。
h. 读取DTC信息（19 02/06/0A等），验证维修效果或系统状态。此流程清晰展示了85服务在DTC生命周期管理中的关键作用。
-
安全与访问控制：
85服务，特别是“关闭”功能，直接影响了ECU的核心诊断功能，因此被赋予了严格的安全访问控制。NRC 33（安全访问被拒绝）和NRC 22（条件不满足）是其最常见的“守护者”。这种设计防止了恶意或误操作导致ECU“失声”（不记录任何故障），从而掩盖真实的车辆问题，带来严重的安全隐患和合规风险。
综上所述，85服务是UDS协议中一个看似简单却至关重要的“开关”。它不仅是实现高效、精准的汽车制造与售后维修的工艺保障，也是维护整车诊断数据生态系统健康与可信的核心环节。深入理解85服务的应用场景、通信协议及其在完整诊断工作流中的定位，是每一位汽车诊断开发、测试及服务工程师必须具备的专业素养。
随着网联化和自动驾驶技术的发展，远程诊断（OTA）的重要性日益凸显。85服务所建立的标准化控制范式，为云端指令远程管理车辆端故障记录策略提供了技术可能，其价值将在未来的智能汽车时代得到进一步的延伸和体现。
以上就是本次85服务的讲解，如在学习过程中有任何疑问，欢迎留言沟通，一起努力，一起进步。