企业官网建设流程全解析

在整车网络诊断开发中，0x85 服务（ControlDTCSetting）是一个低频出现但影响面很大的服务。它不直接参与故障读取，也不负责功能寻址刷写，但它决定了“ECU 在什么条件下允许记录 DTC”。如果你的工作是诊断测试、台架标定或者刷写流程设计，控制不好 0x85，可能会出现“故障码不见了”或者“故障码莫名其妙全冒出来”的情况。

这篇文章继续网络诊断系列，把 0x85 服务的需求拆解、用例设计、验证方法和排查思路完整展开。先明确一点：0x85 的核心是“DTC 设置的开关控制”，不是“删除 DTC”，也不是“读取 DTC”。所有用例设计都要围绕开关语义、状态保持、安全访问和会话权限四个维度来做。

从实际需求出发，一个合格的 0x85 服务测试方案至少要覆盖五类场景：正常开关控制、异常参数请求、安全访问限制、会话模式限制、与其他诊断服务的联动。下面我们从协议规范开始，逐步搭建一套可以直接落到测试用例文档里的完整方案。

1. 0x85 服务核心能力速览

从材料来看，0x85 服务在 UDS 协议栈中属于“DTC 相关服务”，但它的行为边界很容易被人忽略。很多测试用例只写了“0x85 发送 01 返回 C5 01”就结束了，这远远不够。真正需要验证的是：关闭 DTC 记录后，故障事件是否不再写入 NVMDTC；恢复记录后，之前冻结的 DTC 是否继续工作；在没有安全解锁的情况下，0x85 是否被拒绝；在默认会话下请求，是否返回 0x7F。这些才是 0x85 用例的核心。

2. 0x85 服务适用场景与使用边界

2.1 适用场景

0x85 服务最常见的需求场景有三个。

第一个是刷写前置处理。ECU 在进行 Bootloader 刷写或者应用软件升级时，可能会因为电压不稳、通信中断、校验失败等原因产生大量非预期 DTC。这些 DTC 会干扰整车下线检测或者售后故障分析。所以刷写流程的第一步通常是发送 0x85 01 关闭 DTC 记录，刷写完成后再发送 0x85 02 恢复记录。

第二个是标定和台架测试。标定工程师在反复调整参数时，会人为制造一些越界条件。如果 DTC 一直记录，会导致台架测试的故障统计不准确。关闭 DTC 设置后，测试过程就不会被大量故障码打断。

第三个是下线检测（EOL）和产线配置。车辆下线时需要写入 VIN、配置项等数据，这个过程会触发一些“未配置完成”类 DTC。通过 0x85 关闭记录，可以保证下线检测数据的干净。

2.2 使用边界

0x85 服务不是万能的，设计用例前必须明确边界。

• 0x85 只控制“是否允许记录新的 DTC”，不能清除已有的 DTC。清除 DTC 要用 0x14（ClearDiagnosticInformation）。
• 0x85 不等于“屏蔽故障报警”。故障仍可能发生并且被识别，只是不写入 DTC 存储区。
• 0x85 的作用通常是临时的。ECU 复位后，DTC 设置控制状态可能会恢复到默认开启状态，除非需求明确规定持久化保存。
• 0x85 执行前一般需要安全访问。如果需求中没有定义安全解锁要求，就必须和诊断规范严格对齐，否则测试环境会出现“同样的请求在台架上通过，在整车上被拒”的情况。

3. 测试环境与前置条件

3.1 硬件环境

3.2 软件环境

• CANoe / CANalyzer，或者 PCAN-View；
• CANdb++（至少需要 DBC 文件）；
• 诊断测试脚本平台，CAPL 或 Python；
• ECU 的诊断规范文档（DLL 或诊断需求说明书）；
• ISO 14229-1 标准文本，作为用例设计的参考依据。

3.3 测试前置条件

• ECU 正常上电，网络通信稳定；
• 诊断仪能够进入扩展会话（0x10 03 或 0x10 02）；
• 已通过 0x27 安全访问解锁；
• 无其他诊断服务占用总线；
• 已确认数据库中的 0x85 服务定义与规范一致。

4. 0x85 服务报文格式与基础验证

4.1 请求报文格式

0x85 服务的诊断请求格式为：

标准 ISO 14229-1 中定义的 DTCSettingType 为：

DTCSettingControlOptionRecord 是可选字段。部分 ECU 实现中直接省略该字段，此时请求长度就是 2 字节；部分 ECU 要求带一个字节的控制选项记录，请求长度就是 3 字节。设计用例时必须确认 ECU 诊断规范里的精确要求。

4.2 肯定响应报文格式

正常情况下，ECU 返回的肯定响应为：

标准的肯定响应示例：

请求：85 01 响应：C5 01

请求：85 02 响应：C5 02

4.3 否定响应报文格式

当请求不满足条件时，ECU 返回否定响应：

7F 85 NRC

常见 NRC 包括：

4.4 基础验证示例：Python 模拟诊断请求

在测试环境中如果使用 Python 和 CAN 接口库，可以通过类似下面的方式来发送 0x85 请求：

import can bus = can.interface.Bus(bustype='pcan', channel='PCAN_USBBUS1', bitrate=500000) def send_uds_request(request_bytes, arbitration_id=0x7E0): msg = can.Message( arbitration_id=arbitration_id, data=request_bytes, is_extended_id=False ) bus.send(msg) # 发送 0x85 02，请求恢复 DTC 记录 send_uds_request([0x85, 0x02])

这里只是基础发送示例。实际工程中还需要接收 ECU 响应并做时序判断，建议把请求发送和响应接收放到同一个线程中循环处理，避免丢帧。

5. 0x85 服务正常用例设计

根据需求设计用例时，第一步是列出正常场景。0x85 的正常场景围绕子功能 01 和 02 的状态切换。

5.1 子功能 02：恢复 DTC 记录

该用例是 0x85 服务最基础的验证项。如果 ECU 返回 NRC 0x22，优先检查是否缺少前置条件，例如没有进入扩展会话、电压异常或安全解锁未通过。

5.2 子功能 01：关闭 DTC 记录

这个用例验证的是 on 语义。发送成功后，ECU 应当不再记录新的 DTC。注意这里说的是“不再记录新的”，已经存在的 DTC 不会被清除，状态位也不会复位。

5.3 开关状态反复切换

这个用例的重点是状态机稳定性。如果 ECU 的 DTC 设置状态机实现有缺陷，反复切换可能出现第二次 on 请求被错误拒绝的情况。

5.4 关闭 DTC 记录后故障注入验证

这个用例是验证 0x85 功能“有没有真的关掉”。如果测试人员只做报文响应验证，很容易漏掉这个关键步骤。

5.5 恢复记录后故障记录恢复

5.6 断电重启后的状态验证

这里需要特别强调：如果需求文档规定“断电后保持关闭状态”，那么 ECU 必须通过非易失存储记录状态；如果需求规定“断电后恢复默认”，则无需持久化。这个用例的设计必须严格按照需求文档来定预期结果。

6. 0x85 服务异常与 NRC 用例设计

6.1 未安全解锁时请求

如果 ECU 在没有安全访问要求的情况下也允许 0x85，那属于安全漏洞。此用例是安全类用例中的必测项。

6.2 默认会话下请求

该用例覆盖 0x85 的会话模式限制。不同 OEM 可能定义 0x85 在扩展会话或编程会话下可用，但默认会话下大概率被拒绝。如果 ECU 在默认会话下也允许执行，需要与需求文档确认是否合规。

6.3 无效子功能请求

同时还可以测试 0x85 00、0x85 FF、0x85 80（抑制响应位 + 保留子功能位）等边界子功能，找出“非法子功能被接受”的协议栈漏洞。

6.4 无效控制参数请求

注意：如果 ECU 实现中不接受任何控制选项记录字段，那么发送 0x85 01 0x10 可能返回 0x13 而不是 0x31。具体以 ECU 规范为准。

6.5 错误报文长度

6.6 抑制肯定响应位测试

7. 0x85 服务与其他服务联动用例设计

0x85 服务在真实诊断流程中很少单独使用。下面给出 4 个联动用例，这些用例通常是被测试团队遗漏的高价值场景。

7.1 与 0x10 会话控制联动

这个用例有一个典型争议点：切换会话时，DTC 设置状态是否保持？有的 ECU 在会话切换时会清除未持久化的 DTC 设置状态。该场景必须以实际需求来决定预期结果，不能默认“一定保持”。

7.2 与 0x27 安全访问联动

7.3 与 0x19 读取 DTC 联动

7.4 与 0x11 ECU 复位联动

8. 0x85 服务边界值与性能用例设计

8.1 边界值分析

在 0x85 用例设计中，边界值主要体现在子功能字段和控制参数上。

8.2 连续发送压力测试

典型异常是：ECU 在处理完第一次 0x85 01 后，把“关闭 DTC 记录”误当成一次性操作，第二次 0x85 01 返回 0x22。这种情况属于状态设计不合理，必须通过压力测试发现。

8.3 响应时间测试

UDS 规范通常要求 ECU 在 P2 时间内返回响应，默认 P2 为 25ms 或 50ms，具体以 OEM 诊断规范为准。如果响应时间连续超过 P2，说明 0x85 服务处理路径中存在耗时操作，需要优化。

8.4 总线负载对 0x85 的影响

在实车环境或台架环境下，总线可能有大量报文。设计用例时，可以在 0x85 请求的同时，让总线保持 60% 以上的负载，观察 0x85 请求是否出现丢帧、超时或错误响应。这个测试往往能暴露网络调度和报文优先级配置问题。

9. 常见问题与排查方法

针对 0x85 特有的一个坑：如果 ECU 在 0x85 01 成功后立即复位，且复位逻辑中 DTC 记录状态恢复为默认 on，那么此时再发送 0x85 01 是合法的，但部分测试脚本会误判为“重复请求”。这里需要结合用例 TC_0x85_016 来设计自动化脚本，明确复位后的状态预期。

10. 0x85 服务用例设计方法与最佳实践

10.1 需求分析先行

设计 0x85 用例前，必须把需求文档里的功能描述转换成可验证的“状态-事件”模型。建议画出四个维度：

• 关键状态：DTC 记录开启、DTC 记录关闭、未知状态（复位后）。
• 触发事件：0x85 01 请求、0x85 02 请求、会话切换、复位、断电、故障发生。
• 前置条件：安全解锁状态、会话模式、电压条件、点火状态。
• 预期结果：肯定响应、否定响应、DTC 记录行为、状态保持行为。

把表头列出来之后，需求中的每一个“如果...那么...”描述，都会变成一个用例。

10.2 用例分类

按测试目标可以把 0x85 用例分为四类：

10.3 自动化落地

如果是基于 CANoe 做自动化，建议用 CAPL 写一个公共函数库，把 0x85 请求、响应判定、NRC 断言封装成可复用模块：

void SendControlDTCSetting(byte subFunction) { byte request[2]; request[0] = 0x85; request[1] = subFunction; diagRequestSend(0x85, request, elCount(request)); }

这样每个测试用例只需调用函数，不需要在每个用例里重复写报文拼接逻辑。

10.4 基于 Python 的自动化测试

在 Python 测试框架中，可以这样封装 0x85 的请求和期望响应匹配：

class UDSClient: def control_dtc_setting(self, sub_function, expected_nrc=None): request = [0x85, sub_function] response = self.send_request(request) if expected_nrc: assert response[0] == 0x7F and response[2] == expected_nrc, \ f"Expected NRC {expected_nrc:#04x}, got {response.hex()}" else: assert response[0] == 0xC5 and response[1] == sub_function, \ f"Expected positive response, got {response.hex()}"

这里的send_request是底层 CAN/UDS 传输方法。实际接入时，可以替换成 python-can、CANoe COM 接口或者其他诊断库。

10.5 测试记录和跟踪

每次 0x85 测试都要保留：

• 测试时间戳和 ECU 软硬件版本；
• 请求报文和响应报文原始帧；
• 0x85 状态切换前后的 DTC 列表快照；
• 总线负载和响应时间记录；
• 故障注入方式、注入时间和恢复时间。

有了这些记录，出现“边界状态下的 DTC 记录异常”时就能快速定位是测试环境问题还是 ECU 实现问题。

10.6 合规与安全边界

0x85 服务通常和刷写、标定、下线检测相关，测试时需要特别注意：

• 在实车上测试前，确认关闭 DTC 记录不会影响安全相关功能的故障监控；
• 涉及 OTA 刷写流程的 0x85 用例，必须确认刷写失败后的回退逻辑不会导致 DTC 永远关闭；
• 测试过程中产生的 DTC，测试完成后必须通过 0x14 服务清理干净；
• 不要在生产配置或安全关键 ECU 上随意执行 0x85 01 后断电，以免造成诊断数据不可追溯。

11. 总结与下一步

0x85 服务本身很简单，就是两个子功能加上几个 NRC。但真正考验测试功底的是“根据需求设计用例”这件事。需求里写的“控制 DTC 设置”，落到用例里至少需要覆盖状态切换、权限校验、会话限制、故障注入、复位行为五个层面。只要你把 4 个典型前置条件和 5 类场景的用例跑完，0x85 这块基本就能交付了。

最容易踩的坑有三个：一是把 0x85 和 0x14 混为一谈；二是不验证“关闭后是否真的不记录”；三是忽略复位和会话切换对 DTC 设置状态的影响。下一轮测试开始前，建议先按照文中的用例清单对一遍现有的测试设计，缺口补上再执行。

如果你正在做整车诊断或 UDS 协议栈相关的开发和测试，欢迎把这套用例框架直接拿过去改造成自己的测试规范。后续文章会继续安排 0x86、0x87 等服务的用例设计，保持更新，建议收藏备用。