尧图网页设计 
这次我们直接讲 UDS 诊断里的 0x85 服务也就是 ControlDTCSetting控制 DTC 设置。先区分一个容易搞混的点0x85 不是 Security AccessSecurity Access 是 0x27。很多刚接触诊断协议的人会把这两个服务 ID 记混实际它们做的事完全不一样。0x27 负责安全解锁0x85 负责让 ECU 暂时停止或恢复故障码记录。这篇文章的落地目标是从一份需求文档出发把 0x85 服务的测试用例完整设计出来。我会先从服务原理和需求分析入手给出一份可参考的示例需求再按正常流程、异常流程、状态边界三个维度展开用例设计最后给出基于 CAPL 和 Python 的自动化测试实现示例以及常见问题排查清单。整套思路可以直接用于搭建你自己的 0x85 服务测试用例库。另外先说明一个边界0x85 服务虽然是普通诊断功能但所有测试操作必须在授权的台架、实验室或实车测试环境中执行不得利用诊断服务干扰正常车辆运行也不能把本文方法用于任何未授权场景。1. 0x85 服务核心能力速览能力项说明服务 ID0x85服务名称ControlDTCSetting控制 DTC 设置正响应 SID0xC5负响应格式0x7F 0x85 NRC核心功能控制 ECU 是否记录 / 存储新的 DTC子功能定义0x01 on开启 DTC 记录、0x02 off关闭 DTC 记录可选参数DTCSettingControlOptionRecordDTC 设置控制选项记录会话要求一般为扩展会话 0x03 或编程会话 0x02具体以 ECU 设计为准安全访问要求部分 ECU 要求先执行 0x27 解锁未解锁返回 NRC 0x33 或 0x22典型应用场景刷写前关闭故障码记录、EOL 下线屏蔽 DTC、功能测试期间避免误报状态保持策略上下电、会话切换后的 DTC 设置状态由 ECU 具体实现决定从这张表可以看出来0x85 服务本身不复杂但它和会话模式、安全访问、DTC 状态机都有耦合。测试用例设计如果只盯着“发一个 0x85 02 然后看正响应”一定会漏掉关键边界条件。2. 0x85 服务原理与需求分析2.1 服务定义与业务语义ControlDTCSetting 的作用是让诊断仪控制 ECU 是否记录新的故障码。典型业务场景是 ECU 刷写刷写过程中ECU 的通信、电压、内存状态都处在非正常状态如果不先关闭 DTC 记录ECU 会把刷写过程产生的异常动作全部记为故障码刷写完成后要额外做一次清除 DTC既耗时又容易留下隐患。所以规范通常要求刷写前发送 0x85 02 关闭记录刷写完成后发送 0x85 01 恢复记录。设计用例前必须明确一个语义0x85 off 只影响“新 DTC 是否被记录”不会清除 ECU 中已经存储的 DTC。也就是说发送 0x85 02 后ECU 内存里已有的故障码仍然保留只是不再新增。这个语义和 0x14 ClearDiagnosticInformation清除 DTC是完全不同的用例设计时不能混淆。2.2 报文格式0x85 服务的请求报文由服务 ID、子功能和可选的 DTCSettingControlOptionRecord 组成。报文方向字节位置内容说明请求Byte 00x85服务 ID请求Byte 10x01 / 0x02子功能on 或 off请求Byte 2...nDTCSettingControlOptionRecord可选OEM 自定义正响应Byte 00xC5正响应 SID正响应Byte 10x01 / 0x02回显子功能正响应Byte 2...nDTCSettingControlOptionRecord是否回显由规范定义负响应Byte 00x7F负响应固定值负响应Byte 10x85服务 ID负响应Byte 2NRC负响应码子功能 0x01 和 0x02 是最基础的定义。实际项目中OEM 可能扩展子功能编号例如 0x03 用于某种特定 DTC 组的控制0x04 用于另一种。因此用例设计的第一步永远是从需求文档里把子功能定义表摘出来而不是假设只有 on/off 两种。2.3 需求分析关键点设计 0x85 服务用例前需要从需求文档中提取以下信息支持哪些子功能每个子功能的具体语义是什么。是否允许携带 DTCSettingControlOptionRecord记录格式是什么支持哪些取值。允许执行 0x85 服务的会话模式列表。是否需要先完成 0x27 安全访问解锁。0x85 off 后 ECU 多久停止记录 DTC0x85 on 后多久恢复。0x85 off 状态下已存储的 DTC 是否可读取、可清除。ECU 上下电或者会话切换后DTC 设置状态是保持还是恢复默认。连续发送相同子功能时ECU 是否返回正响应还是返回 NRC。这些关键点直接决定测试用例的覆盖范围。如果需求文档没有写清楚就是需求缺陷测试人员要把问题反馈回去而不是自己猜测。3. 示例需求规格说明为了下文用例设计方便这里给出一份简化的示例需求。实际项目以你的需求文档为准下面的内容只是演示“从需求到用例”的推导过程。需求编号需求描述REQ-0x85-001ECU 支持 0x85 服务子功能 0x01 为 on0x02 为 offREQ-0x85-0020x85 服务仅在扩展会话0x03下允许执行REQ-0x85-003执行 0x85 服务前必须先通过 0x27 安全访问解锁 Level 1REQ-0x85-0040x85 请求不携带 DTCSettingControlOptionRecord 时请求长度为 2 字节REQ-0x85-0050x85 请求可携带 1 字节 DTCSettingControlOptionRecord用于指定 DTC 组0x01 表示动力系统0x02 表示底盘系统其他值返回 NRC 0x31REQ-0x85-006发送 0x85 02 后ECU 在 100ms 内停止记录新的 DTC发送 0x85 01 后ECU 在 100ms 内恢复记录REQ-0x85-0070x85 02 不影响已存储 DTC已存储 DTC 仍可被 0x19 读取、被 0x14 清除REQ-0x85-008ECU 复位后DTC 设置状态恢复为 onREQ-0x85-009同一子功能重复发送ECU 返回正响应REQ-0x85-010未解锁时发送 0x85返回 NRC 0x33REQ-0x85-011非扩展会话发送 0x85返回 NRC 0x22REQ-0x85-012不支持的子功能返回 NRC 0x12REQ-0x85-013请求长度异常返回 NRC 0x13这份示例需求基本覆盖了正常、异常、边界三大类。下面所有测试用例都围绕这 13 条需求展开读者可以对照需求编号追踪用例覆盖情况。4. 测试环境准备与前置条件4.1 硬件与软件工具0x85 服务属于网络诊断测试环境搭建相对标准。推荐使用以下组合CAN 接口卡CANoe、PCAN、周立功 USBCAN 等根据实际台架接口选择。诊断工具CANoe 结合诊断协议栈或 ODIS、CANDela Studio 这类诊断开发工具。脚本语言环境Python 3.8 以上安装python-can库用于快速验证请求响应。模拟负载或台架如果是台架测试需要保证 ECU 供电稳定必要时连接模拟负载。数据库文件DBC、CDD、ODX 等描述报文地址和诊断参数自动化测试依赖这些文件。4.2 前置条件检查正式执行测试前逐项确认ECU 上电正常CAN 通信物理层正常。诊断仪能够正常进入扩展会话说明 0x10 服务可用。如果需求要求安全访问先用 0x27 完成解锁确认正响应 0x67 返回正常。确认 ECU 当前的 DTC 设置状态可以通过 0x19 02 读取 DTC 状态掩码来辅助判断。CANoe 或 Python 脚本的发送 ID、接收 ID 配置无误例如物理寻址请求 0x7E0响应 0x7E8。环境准备不复杂但容易被忽略。尤其是安全访问前置条件很多测试人员直接发 0x85 结果返回 NRC 0x33误以为是 ECU 故障其实是前置解锁没做。5. 正常流程测试用例设计正常流程用例的目标是验证 ECU 在合法输入下能否正确执行 0x85 服务并返回符合规范的正响应。5.1 开启 DTC 设置正常流程用例 IDTC_0x85_001关联需求REQ-0x85-001、REQ-0x85-002、REQ-0x85-003测试目的验证解锁状态下发送 0x85 01 能正常开启 DTC 记录前置条件进入扩展会话完成 0x27 解锁测试步骤1. 发送请求 85 012. 等待响应预期结果收到正响应 C5 01判定标准响应字节 0 为 0xC5字节 1 为 0x01备注无5.2 关闭 DTC 设置正常流程用例 IDTC_0x85_002关联需求REQ-0x85-001、REQ-0x85-002、REQ-0x85-003测试目的验证解锁状态下发送 0x85 02 能正常关闭 DTC 记录前置条件进入扩展会话完成 0x27 解锁测试步骤1. 发送请求 85 022. 等待响应预期结果收到正响应 C5 02判定标准响应字节 0 为 0xC5字节 1 为 0x02备注无5.3 功能生效时间验证用例 IDTC_0x85_003关联需求REQ-0x85-006测试目的验证 0x85 02 后 ECU 在 100ms 内停止记录 DTC前置条件进入扩展会话完成解锁ECU 当前处于 DTC on 状态测试步骤1. 发送 85 022. 等待正响应 C5 023. 人为制造一个故障例如断开某传感器信号4. 等待 200ms5. 使用 0x19 读取 DTC预期结果步骤 5 读取不到新产生的故障码或故障码状态不更新判定标准新故障没有被记录备注制造故障的方式要可控避免损坏硬件同样反向测试可以验证 0x85 01 后恢复 DTC 记录。这两个用例是 0x85 服务最核心的功能验证不能只看响应报文必须验证业务语义真正生效。5.4 带 DTCSettingControlOptionRecord 的测试用例 IDTC_0x85_004关联需求REQ-0x85-005测试目的验证携带合法 DTC 组控制记录时服务正常执行前置条件进入扩展会话完成解锁测试步骤1. 发送请求 85 02 01记录指定动力系统 DTC 组2. 等待响应预期结果收到正响应 C5 02 01DTC 组 0x01 不再记录新故障判定标准响应与请求一致且目标 DTC 组停止记录备注实际记录格式按项目需求定义用例 IDTC_0x85_005关联需求REQ-0x85-005测试目的验证携带非法 DTC 组控制记录时返回 NRC 0x31前置条件进入扩展会话完成解锁测试步骤1. 发送请求 85 02 FF2. 等待响应预期结果收到负响应 7F 85 31判定标准NRC 为 0x31备注无5.5 重复子功能测试用例 IDTC_0x85_006关联需求REQ-0x85-009测试目的验证重复发送同一子功能时 ECU 不报错前置条件进入扩展会话完成解锁测试步骤1. 连续发送 85 02 三次2. 每次等待响应预期结果每次均返回正响应 C5 02判定标准三次响应均为 C5 02备注如果需求要求第二次返回 NRC 0x24 或 0x22按需求实际定义修正6. 异常流程与负响应测试用例设计异常流程用例的核心是验证 ECU 在非法输入下能否返回正确负响应码。0x85 服务常见 NRC 有 0x12、0x13、0x22、0x31、0x33。下面按异常类型分组给出用例设计。用例 ID关联需求测试场景请求报文预期 NRC备注TC_0x85_010REQ-0x85-010未解锁直接发送 0x8585 020x33安全访问未通过TC_0x85_011REQ-0x85-011默认会话下发送 0x8585 020x22会话条件不满足TC_0x85_012REQ-0x85-012发送不存在的子功能 0x0385 030x12子功能不支持TC_0x85_013REQ-0x85-013请求长度只有 1 字节850x13报文长度错误TC_0x85_014REQ-0x85-013请求长度 3 字节且带非法记录85 02 FF0x31 或 0x13具体按需求定义TC_0x85_015需求补充请求长度超过最大限制85 02 01 010x13超出允许长度TC_0x85_016REQ-0x85-012发送子功能 0x0085 000x120x00 通常不合法设计负响应用例时要注意不同 OEM 对相同异常输入的 NRC 定义可能不同。比如未解锁时有的 ECU 返回 0x33有的返回 0x22有的返回 0x31。写用例前必须把 ECU 诊断规范里的 NRC 列表拿到手不能拿通用 UDS 标准硬套。7. 状态与边界测试用例设计这部分最容易漏。0x85 服务在状态机层面有几个关键问题状态是否保持、状态是否受上下 UDS诊断0x85服务ControlDTCSetting测试用例设计全解析
这次我们直接讲 UDS 诊断里的 0x85 服务也就是 ControlDTCSetting控制 DTC 设置。先区分一个容易搞混的点0x85 不是 Security AccessSecurity Access 是 0x27。很多刚接触诊断协议的人会把这两个服务 ID 记混实际它们做的事完全不一样。0x27 负责安全解锁0x85 负责让 ECU 暂时停止或恢复故障码记录。这篇文章的落地目标是从一份需求文档出发把 0x85 服务的测试用例完整设计出来。我会先从服务原理和需求分析入手给出一份可参考的示例需求再按正常流程、异常流程、状态边界三个维度展开用例设计最后给出基于 CAPL 和 Python 的自动化测试实现示例以及常见问题排查清单。整套思路可以直接用于搭建你自己的 0x85 服务测试用例库。另外先说明一个边界0x85 服务虽然是普通诊断功能但所有测试操作必须在授权的台架、实验室或实车测试环境中执行不得利用诊断服务干扰正常车辆运行也不能把本文方法用于任何未授权场景。1. 0x85 服务核心能力速览能力项说明服务 ID0x85服务名称ControlDTCSetting控制 DTC 设置正响应 SID0xC5负响应格式0x7F 0x85 NRC核心功能控制 ECU 是否记录 / 存储新的 DTC子功能定义0x01 on开启 DTC 记录、0x02 off关闭 DTC 记录可选参数DTCSettingControlOptionRecordDTC 设置控制选项记录会话要求一般为扩展会话 0x03 或编程会话 0x02具体以 ECU 设计为准安全访问要求部分 ECU 要求先执行 0x27 解锁未解锁返回 NRC 0x33 或 0x22典型应用场景刷写前关闭故障码记录、EOL 下线屏蔽 DTC、功能测试期间避免误报状态保持策略上下电、会话切换后的 DTC 设置状态由 ECU 具体实现决定从这张表可以看出来0x85 服务本身不复杂但它和会话模式、安全访问、DTC 状态机都有耦合。测试用例设计如果只盯着“发一个 0x85 02 然后看正响应”一定会漏掉关键边界条件。2. 0x85 服务原理与需求分析2.1 服务定义与业务语义ControlDTCSetting 的作用是让诊断仪控制 ECU 是否记录新的故障码。典型业务场景是 ECU 刷写刷写过程中ECU 的通信、电压、内存状态都处在非正常状态如果不先关闭 DTC 记录ECU 会把刷写过程产生的异常动作全部记为故障码刷写完成后要额外做一次清除 DTC既耗时又容易留下隐患。所以规范通常要求刷写前发送 0x85 02 关闭记录刷写完成后发送 0x85 01 恢复记录。设计用例前必须明确一个语义0x85 off 只影响“新 DTC 是否被记录”不会清除 ECU 中已经存储的 DTC。也就是说发送 0x85 02 后ECU 内存里已有的故障码仍然保留只是不再新增。这个语义和 0x14 ClearDiagnosticInformation清除 DTC是完全不同的用例设计时不能混淆。2.2 报文格式0x85 服务的请求报文由服务 ID、子功能和可选的 DTCSettingControlOptionRecord 组成。报文方向字节位置内容说明请求Byte 00x85服务 ID请求Byte 10x01 / 0x02子功能on 或 off请求Byte 2...nDTCSettingControlOptionRecord可选OEM 自定义正响应Byte 00xC5正响应 SID正响应Byte 10x01 / 0x02回显子功能正响应Byte 2...nDTCSettingControlOptionRecord是否回显由规范定义负响应Byte 00x7F负响应固定值负响应Byte 10x85服务 ID负响应Byte 2NRC负响应码子功能 0x01 和 0x02 是最基础的定义。实际项目中OEM 可能扩展子功能编号例如 0x03 用于某种特定 DTC 组的控制0x04 用于另一种。因此用例设计的第一步永远是从需求文档里把子功能定义表摘出来而不是假设只有 on/off 两种。2.3 需求分析关键点设计 0x85 服务用例前需要从需求文档中提取以下信息支持哪些子功能每个子功能的具体语义是什么。是否允许携带 DTCSettingControlOptionRecord记录格式是什么支持哪些取值。允许执行 0x85 服务的会话模式列表。是否需要先完成 0x27 安全访问解锁。0x85 off 后 ECU 多久停止记录 DTC0x85 on 后多久恢复。0x85 off 状态下已存储的 DTC 是否可读取、可清除。ECU 上下电或者会话切换后DTC 设置状态是保持还是恢复默认。连续发送相同子功能时ECU 是否返回正响应还是返回 NRC。这些关键点直接决定测试用例的覆盖范围。如果需求文档没有写清楚就是需求缺陷测试人员要把问题反馈回去而不是自己猜测。3. 示例需求规格说明为了下文用例设计方便这里给出一份简化的示例需求。实际项目以你的需求文档为准下面的内容只是演示“从需求到用例”的推导过程。需求编号需求描述REQ-0x85-001ECU 支持 0x85 服务子功能 0x01 为 on0x02 为 offREQ-0x85-0020x85 服务仅在扩展会话0x03下允许执行REQ-0x85-003执行 0x85 服务前必须先通过 0x27 安全访问解锁 Level 1REQ-0x85-0040x85 请求不携带 DTCSettingControlOptionRecord 时请求长度为 2 字节REQ-0x85-0050x85 请求可携带 1 字节 DTCSettingControlOptionRecord用于指定 DTC 组0x01 表示动力系统0x02 表示底盘系统其他值返回 NRC 0x31REQ-0x85-006发送 0x85 02 后ECU 在 100ms 内停止记录新的 DTC发送 0x85 01 后ECU 在 100ms 内恢复记录REQ-0x85-0070x85 02 不影响已存储 DTC已存储 DTC 仍可被 0x19 读取、被 0x14 清除REQ-0x85-008ECU 复位后DTC 设置状态恢复为 onREQ-0x85-009同一子功能重复发送ECU 返回正响应REQ-0x85-010未解锁时发送 0x85返回 NRC 0x33REQ-0x85-011非扩展会话发送 0x85返回 NRC 0x22REQ-0x85-012不支持的子功能返回 NRC 0x12REQ-0x85-013请求长度异常返回 NRC 0x13这份示例需求基本覆盖了正常、异常、边界三大类。下面所有测试用例都围绕这 13 条需求展开读者可以对照需求编号追踪用例覆盖情况。4. 测试环境准备与前置条件4.1 硬件与软件工具0x85 服务属于网络诊断测试环境搭建相对标准。推荐使用以下组合CAN 接口卡CANoe、PCAN、周立功 USBCAN 等根据实际台架接口选择。诊断工具CANoe 结合诊断协议栈或 ODIS、CANDela Studio 这类诊断开发工具。脚本语言环境Python 3.8 以上安装python-can库用于快速验证请求响应。模拟负载或台架如果是台架测试需要保证 ECU 供电稳定必要时连接模拟负载。数据库文件DBC、CDD、ODX 等描述报文地址和诊断参数自动化测试依赖这些文件。4.2 前置条件检查正式执行测试前逐项确认ECU 上电正常CAN 通信物理层正常。诊断仪能够正常进入扩展会话说明 0x10 服务可用。如果需求要求安全访问先用 0x27 完成解锁确认正响应 0x67 返回正常。确认 ECU 当前的 DTC 设置状态可以通过 0x19 02 读取 DTC 状态掩码来辅助判断。CANoe 或 Python 脚本的发送 ID、接收 ID 配置无误例如物理寻址请求 0x7E0响应 0x7E8。环境准备不复杂但容易被忽略。尤其是安全访问前置条件很多测试人员直接发 0x85 结果返回 NRC 0x33误以为是 ECU 故障其实是前置解锁没做。5. 正常流程测试用例设计正常流程用例的目标是验证 ECU 在合法输入下能否正确执行 0x85 服务并返回符合规范的正响应。5.1 开启 DTC 设置正常流程用例 IDTC_0x85_001关联需求REQ-0x85-001、REQ-0x85-002、REQ-0x85-003测试目的验证解锁状态下发送 0x85 01 能正常开启 DTC 记录前置条件进入扩展会话完成 0x27 解锁测试步骤1. 发送请求 85 012. 等待响应预期结果收到正响应 C5 01判定标准响应字节 0 为 0xC5字节 1 为 0x01备注无5.2 关闭 DTC 设置正常流程用例 IDTC_0x85_002关联需求REQ-0x85-001、REQ-0x85-002、REQ-0x85-003测试目的验证解锁状态下发送 0x85 02 能正常关闭 DTC 记录前置条件进入扩展会话完成 0x27 解锁测试步骤1. 发送请求 85 022. 等待响应预期结果收到正响应 C5 02判定标准响应字节 0 为 0xC5字节 1 为 0x02备注无5.3 功能生效时间验证用例 IDTC_0x85_003关联需求REQ-0x85-006测试目的验证 0x85 02 后 ECU 在 100ms 内停止记录 DTC前置条件进入扩展会话完成解锁ECU 当前处于 DTC on 状态测试步骤1. 发送 85 022. 等待正响应 C5 023. 人为制造一个故障例如断开某传感器信号4. 等待 200ms5. 使用 0x19 读取 DTC预期结果步骤 5 读取不到新产生的故障码或故障码状态不更新判定标准新故障没有被记录备注制造故障的方式要可控避免损坏硬件同样反向测试可以验证 0x85 01 后恢复 DTC 记录。这两个用例是 0x85 服务最核心的功能验证不能只看响应报文必须验证业务语义真正生效。5.4 带 DTCSettingControlOptionRecord 的测试用例 IDTC_0x85_004关联需求REQ-0x85-005测试目的验证携带合法 DTC 组控制记录时服务正常执行前置条件进入扩展会话完成解锁测试步骤1. 发送请求 85 02 01记录指定动力系统 DTC 组2. 等待响应预期结果收到正响应 C5 02 01DTC 组 0x01 不再记录新故障判定标准响应与请求一致且目标 DTC 组停止记录备注实际记录格式按项目需求定义用例 IDTC_0x85_005关联需求REQ-0x85-005测试目的验证携带非法 DTC 组控制记录时返回 NRC 0x31前置条件进入扩展会话完成解锁测试步骤1. 发送请求 85 02 FF2. 等待响应预期结果收到负响应 7F 85 31判定标准NRC 为 0x31备注无5.5 重复子功能测试用例 IDTC_0x85_006关联需求REQ-0x85-009测试目的验证重复发送同一子功能时 ECU 不报错前置条件进入扩展会话完成解锁测试步骤1. 连续发送 85 02 三次2. 每次等待响应预期结果每次均返回正响应 C5 02判定标准三次响应均为 C5 02备注如果需求要求第二次返回 NRC 0x24 或 0x22按需求实际定义修正6. 异常流程与负响应测试用例设计异常流程用例的核心是验证 ECU 在非法输入下能否返回正确负响应码。0x85 服务常见 NRC 有 0x12、0x13、0x22、0x31、0x33。下面按异常类型分组给出用例设计。用例 ID关联需求测试场景请求报文预期 NRC备注TC_0x85_010REQ-0x85-010未解锁直接发送 0x8585 020x33安全访问未通过TC_0x85_011REQ-0x85-011默认会话下发送 0x8585 020x22会话条件不满足TC_0x85_012REQ-0x85-012发送不存在的子功能 0x0385 030x12子功能不支持TC_0x85_013REQ-0x85-013请求长度只有 1 字节850x13报文长度错误TC_0x85_014REQ-0x85-013请求长度 3 字节且带非法记录85 02 FF0x31 或 0x13具体按需求定义TC_0x85_015需求补充请求长度超过最大限制85 02 01 010x13超出允许长度TC_0x85_016REQ-0x85-012发送子功能 0x0085 000x120x00 通常不合法设计负响应用例时要注意不同 OEM 对相同异常输入的 NRC 定义可能不同。比如未解锁时有的 ECU 返回 0x33有的返回 0x22有的返回 0x31。写用例前必须把 ECU 诊断规范里的 NRC 列表拿到手不能拿通用 UDS 标准硬套。7. 状态与边界测试用例设计这部分最容易漏。0x85 服务在状态机层面有几个关键问题状态是否保持、状态是否受上下