开头这次我们来看一个诊断开发过程中绕不开的环节0x28 服务的需求分析与测试用例设计。0x28 服务是 UDSUnified Diagnostic Services统一诊断服务协议里的 CommunicationControl中文叫通信控制服务。它不负责刷写、不负责读故障码而是直接控制 ECU 对外通信报文的收发状态比如让某个应用报文暂时静默、禁止发送、或者只允许接收。很多网络诊断问题尤其是总线负载过高、节点休眠异常、诊断仪与 ECU 握手异常最后排查的时候都会回到 0x28 服务的实现是否严谨、测试是否覆盖到位。这篇文章会围绕 0x28 服务展开三条线第一0x28 服务是什么报文格式和子功能怎么理解第二怎么从需求文档中提取测试点逐步写出可执行、可回归、可评审的用例第三如何把用例落到实际测试链路里包括手工测试、自动化脚本和接口级验证。文中还会用一个诊断用例模板作为基础演示正向、反向、边界、时序和偶发场景怎么写。如果你正在做 CAN/LIN 网络诊断测试或者刚接触 UDS 诊断用例设计这篇文章可以直接作为一份清单来对照使用。1. 0x28 服务核心能力速览能力项说明服务名称CommunicationControl通信控制服务服务 ID0x28服务作用控制 ECU 通信报文的使能与禁用包括发送、接收、或同时控制常见子功能0x00 使能接收与发送、0x01 使能接收并禁用发送、0x02 禁用接收并使能发送、0x03 禁用接收与发送子功能参数部分实现中会有 Communication Type通信类型字节用于指定控制哪类报文如应用报文、网络管理报文、诊断报文会话要求通常需在非默认会话下使用默认会话下可能返回否定响应安全等级部分 OEM 会要求先做安全解锁也有的只限制会话不限制安全等级典型应用总线负载控制、节点静默、网络管理测试、休眠唤醒测试、诊断干扰测试测试重点肯定响应、否定响应 NRC、通信类型过滤、子功能状态切换、掉电复位恢复、会话切换恢复适用读者诊断测试工程师、网络测试工程师、ECU 开发、自动化测试脚本开发需要说明的是UDS 协议本身定义了 0x28 服务的基本框架但具体支持哪些子功能、是否带 Communication Type、默认会话下是否允许执行在 ISO 14229-1 的基础上还受到 OEM 诊断规范和 ECU 设计文档的约束。因此在设计用例之前必须先拿到项目自己的诊断规范不能把通用标准直接当作全部依据。2. 适用场景与使用边界0x28 服务不是每天都会用到的“高频诊断服务”但一旦项目进入网络管理联调、总线负载测试、休眠唤醒测试阶段它就是最重要的开关之一。适合使用 0x28 服务的场景包括测试某个节点静默后其他节点是否正常通信。模拟 ECU 故障验证应用层容错逻辑。控制特定报文类型的收发观察总线负载变化。配合 0x10 会话控制、0x27 安全访问等测试矩阵做诊断链路的组合验证。验证诊断仪下发通信控制命令后ECU 是否能按需求在指定时间内恢复默认状态。同时也要明确 0x28 服务的使用边界。它主要用于测试、下线检测、产线配置和特定售后流程不能用来掩盖或规避真正的软硬件缺陷。测试过程中如果通过 0x28 服务禁用了某个节点的报文发送测试结束后必须确认 ECU 复位的默认状态否则会导致后续测试结果失真。项目开发阶段不建议长期关闭网络管理报文否则总线休眠唤醒逻辑可能被误判。从合规角度说如果测试车辆、台架或模拟环境涉及真实车辆数据、他人隐私数据或商业协议内容需要在授权范围内使用并保护测试数据不被滥用。诊断测试使用的台架、总线接口设备、诊断仪固件都要来自正规渠道避免使用破解或未授权的诊断设备。3. 0x28 服务需求分析先拆需求再写用例很多测试人员写用例时容易陷入一个误区打开标准文档找到 0x28 服务的报文格式然后直接套模板把“发送请求、验证肯定响应”写完就算结束。这样的用例通常流于表面等到了实车测试阶段会发现大量场景没有被覆盖。从需求到用例中间需要做一层“测试颗粒度拆解”。以 0x28 服务为例需求拆解可以从下面几个维度展开。3.1 从诊断规范中提取服务基本信息第一步先锁定服务本身的静态信息。这是用例的“地基”服务 ID 是否为 0x28。支持的子功能列表。子功能是否带抑制肯定响应位SuppressPosRspMsgIndicationBit, bit 7。是否支持 Communication Type 参数。Communication Type 的取值范围例如 bit0 是否表示 Application 报文bit1 是否表示 Network Management 报文bit2 是否表示 Diagnostic 报文。请求是否需要带长度字节例如带 SubFunction 后是否还有 communicationControlType。支持的会话类型例如默认会话、扩展会话、编程会话中哪些允许执行。是否要求安全解锁。肯定响应格式是否包含子功能回显。否定响应中可能出现的 NRC 列表。这些信息在 ISO 14229-1 里能找到一部分但具体车型上很可能有裁剪。比如某些控制器不支持“禁用接收并使能发送”这个子功能或者对网络管理报文不做控制。因此正文规范、诊断调查表、软件需求规格说明书中的一个字都不能漏。3.2 拆出“状态”与“迁移”0x28 服务最核心的不是“发一帧请求收一个响应”而是 ECU 通信状态的变化。需求拆解时要显式画出两条状态线请求前的通信状态。请求后的通信状态。例如一个 ECU 初始状态是“发送使能、接收使能”。发送 0x28 03 后状态变为“发送禁用、接收禁用”。这个状态会持续到什么时候是持续到收到新的 0x28 00 请求还是 ECU 复位后自动恢复如果是复位后恢复恢复时间有没有要求这些状态迁移点必须逐一落到用例里。每一类迁移方向都至少要有正向一条、反向一条、边界一条。3.3 拆出“通信类型”的组合关系如果需求文档中 0x28 服务带 Communication Type那么测试用例就不能只测一个报文类型。要把通信类型字段拆成位级组合优先覆盖全 0即不控制任何通信类型。全 1即控制所有通信类型。单 bit 置 1如只控制 Application 报文。单 bit 置 0如除了 Network Management 报文外都控制。多个 bit 组合如同时控制 Application 和 Network Management。非法 bit 组合如保留了某些 bit 但需求中未定义。针对每个组合还要明确“控制后 E 节点的实际行为”是什么。例如只发送 0x28 02 20communicationControlType 中 bit 0 置位控制应用报文子功能是禁用接收并启用发送那么应用报文还能不能收网络管理报文是不是不受影响这些细节只能从具体项目中获得不能靠猜。3.4 拆出时序与恢复条件诊断服务设计用例时时序往往比单帧交互更容易被遗漏。0x28 服务尤其如此。因为通信控制的本质是让 ECU 在时间轴上进入一个“非正常通信状态”所以必须考虑收到请求后ECU 在多长时间内完成通信状态切换。控制命令是否在总线周期内立即生效。控制持续期间ECU 的收发行为是否符合规范。ECU 复位后是否恢复到默认状态。会话切换后是否恢复到默认状态。多个 0x28 请求连续下发时相互之间的覆盖关系。0x28 服务与 0x28 服务相同子功能重复执行是否有副作用。0x28 服务执行过程中插入 0x10 01 会话切换状态如何恢复。这些点写成测试用例时不能只写“手动观察”更合理的方式是结合总线报文记录和时间戳给出可量化的判断条件。4. 0x28 服务用例设计步骤下面是适用于 0x28 服务的基础用例设计流程。这套流程也可以套用到其他 UDS 服务上但这里我们只看 0x28。4.1 第一步确定测试环境与链路用例可以设计成台架环境也可以设计成实车环境。设计用例时就要明确定位总线类型CAN、CAN FD、LIN、以太网。诊断请求的发送源诊断仪、CANoe、Pytest 脚本、自定义诊断盒。被测试的 ECU一个节点还是多个节点。对端节点是否需要模拟例如用两个节点模拟网关和控制器。总线报文记录工具CANalyzer、PCAN、Vspy 等。环境信息不用在每条用例里重复写但可以在用例模板顶部的“前置条件”中统一声明保证用例可复现。4.2 第二步定义用例模板建议直接用下面的模板字段不要随意省略用例编号TC_0x28_001 用例名称 测试目的 前置条件 测试步骤 预期结果 实际结果 优先级 关联需求对于诊断类用例建议再加入“禁止在真实车辆公共道路上测试”“执行前确认总线报文已记录”等安全提示作为通用前置条件。4.3 第三步按需求矩阵生成基础用例把需求拆解中得到的信息填进一张服务测试矩阵中每行对应一种请求组合每列对应一个预期结果。用例编号子功能Communication Type会话安全状态预期响应预期 ECU 通信行为TC_0x28_0010x000xFF扩展会话已解锁肯定响应发送与接收均恢复使能TC_0x28_0020x010x01扩展会话已解锁肯定响应接收使能发送禁用仅控制 Application 报文TC_0x28_0030x020x02扩展会话已解锁肯定响应发送使能接收禁用仅控制 Network Management 报文TC_0x28_0040x030x03扩展会话已解锁肯定响应发送与接收均禁用控制 Application 和 Network ManagementTC_0x28_0050x030x00扩展会话已解锁肯定响应无实际控制效果因为通信类型为 0TC_0x28_0060x000x05默认会话未解锁否定响应 0x7F 0x28 NRC请求不执行通信状态不变这张矩阵先解决“覆盖面”问题后续再针对每一行扩展边界和异常。4.4 第四步补充边界、异常和时序用例基础矩阵里的正向用例只能证明“行得通”不能证明测试充分。真正拉开用例质量差距的是下面这几类。边界用例子功能为最小值和最大值。Communication Type 只有最低位为 1。Communication Type 只有最高位为 1。Communication Type 全部位为 1。Communication Type 为 0。请求长度为最短合法长度和最长合法长度。请求连续发送 2 次、10 次、100 次。异常用例子功能值不在支持范围内。Communication Type 包含未定义 bit。请求长度错误。请求缺少参数。请求在默认会话下执行。请求在安全锁定状态下执行。请求被另一个诊断服务打断。请求在传输层被分帧且分帧间隔超时。时序用例ECU 复位后立即执行 0x28 服务。执行 0x28 服务后立即执行 0x10 01 回默认会话。执行 0x28 服务后立即执行 0x11 01 复位。连续发送 0x28 03 两次观察第二次是否以第一次状态为准。发送 0x28 03 后等待超过 5 秒再发送 0x28 00观察恢复时间是否在需求范围内。这些用例写完后最好再找一位熟悉需求的人做一次交叉评审重点确认“ECU 通信行为”这个预期结果是否符合需求文档而不是只看响应字节。5. 0x28 服务典型报文格式与用例示例为了让用例设计落到具体帧上这里给出 0x28 服务的基础报文格式。注意具体长度和参数偏移要以项目诊断规范为准这里只描述常见形式。5.1 请求报文格式请求报文通常由服务 ID、子功能和通信类型组成Byte 0: 0x28 Byte 1: Sub-Function Byte 2: Communication Type (可选)其中 Sub-Function 的 bit 6 和 bit 7 有特殊含义bit 7抑制肯定响应位。如果为 1ECU 不发送肯定响应。bit 6控制参数位。如果为 1表示后续带 Communication Type 参数具体项目中可能固定为 0 或固定为 1。bit 0-5实际的子功能值。例如发送 “0x28 03” 表示禁用接收和发送但要看项目是否要求带通信类型。如果需要带通信类型则请求可以是 “0x28 03 0xFF”表示控制所有通信类型。5.2 肯定响应报文格式肯定响应通常回显服务 ID 和子功能Byte 0: 0x68 Byte 1: Sub-Function如果有额外的数据则按项目规范追加。5.3 否定响应报文格式否定响应的格式是固定的Byte 0: 0x7F Byte 1: 0x28 Byte 2: NRC常见的 NRC 包括NRC含义常见触发场景0x12子功能不支持发送了未定义的子功能0x13消息长度错误请求长度不对或缺少通信类型参数0x22条件不满足当前状态不允许执行例如未处于正确会话0x31请求超出范围Communication Type 包含非法 bit0x33安全访问被拒绝需要安全解锁但当前未解锁0x7F服务不支持该 ECU 未实现 0x28 服务这些 NRC 不能只写在标准里要映射到具体需求。比如“0x22 条件不满足”可以细分为“默认会话下不允许”“未解锁不允许”“当前通信状态不允许切换”等不同场景。5.4 示例用例一正向控制所有报文收发字段内容用例编号TC_0x28_001用例名称扩展会话下禁用并恢复所有通信测试目的验证 0x28 03 能禁用所有通信0x28 00 能恢复前置条件ECU 上电处于扩展会话安全解锁总线报文记录已开启测试步骤1. 记录初始状态下 ECU 发送的应用报文和网络管理报文。2. 发送诊断请求 0x28 03 FF。3. 等待 500 ms。4. 记录当前总线报文。5. 发送诊断请求 0x28 00 FF。6. 等待 500 ms。7. 记录恢复后的总线报文。预期结果第 2 步后 ECU 响应 0x68 03第 3 步到第 5 步之间ECU 不再发送任何应用报文和网络管理报文第 5 步后 ECU 响应 0x68 00第 6 步后 ECU 恢复发送报文。5.5 示例用例二仅禁用应用报文字段内容用例编号TC_0x28_002用例名称仅禁用应用报文保留网络管理报文测试目的验证 Communication Type 对报文类型的过滤功能前置条件ECU 上电处于扩展会话安全解锁总线报文记录已开启测试步骤1. 发送 0x28 03 01。2. 等待 1 秒。3. 观察总线上的应用报文和网络管理报文。4. 发送 0x28 00 01。预期结果应用报文停止发送网络管理报文仍然正常发送两个请求均返回肯定响应。5.6 示例用例三安全锁定状态下执行被拒绝字段内容用例编号TC_0x28_003用例名称安全锁定状态下执行 0x28 被拒绝测试目的验证 0x28 服务的安全访问限制前置条件ECU 上电处于扩展会话未执行安全解锁测试步骤1. 发送 0x28 03 FF。2. 观察响应。3. 检查 ECU 通信状态。预期结果返回否定响应 0x7F 0x28 0x33ECU 的通信行为不发生变化。6. testbuddy 式用例生成从手工用例到半自动生成作为“最新网络热词”里出现的 testbuddy 用例生成这里可以多说一句。testbuddy 这类用例生成工具本质上是把需求结构化成测试逻辑再自动输出用例文本。对于 0x28 服务这种参数组合型测试非常适合用类似思路来提效。手工写用例时很容易漏掉“Communication Type 每一位的组合”和“子功能 × 会话 × 安全状态”的交叉场景。用工具或脚本自动生成时思路可以拆成三步。6.1 第一步参数化需求把需求中所有输入项变成参数sub_functions [0x00, 0x01, 0x02, 0x03] comm_types [0x00, 0x01, 0x02, 0x03, 0xFE, 0xFF] sessions [0x01, 0x02, 0x03] security [True, False]6.2 第二步定义预期结果规则每个参数组合对应的预期结果不能靠程序乱猜而是要写成规则。比如如果 session 为默认会话预期 NRC 0x22。如果 security 为 False 且 session 为扩展会话预期 NRC 0x33。如果 sub_function 在支持列表之外预期 NRC 0x12。如果 comm_type 包含未定义 bit预期 NRC 0x31。这些规则在代码里可以表现为字典或 if-else 分支rules { session_ok: [0x02, 0x03], security_required: True, supported_sub_function: [0x00, 0x01, 0x02, 0x03], valid_comm_type_mask: 0x03, }6.3 第三步批量生成用例文本参数组合的笛卡尔积可以自动生成大量候选用例。但要注意全量笛卡尔积会产生冗余比如 “0x28 00 00” 和 “0x28 01 00” 除了子功能字段不同预期结果完全一致可以合并或调整优先级。生成之后还要按优先级过滤正向高优先级、异常中优先级、边界中优先级、跨场景低优先级。下面是一个最简单的生成脚本思路import itertools sub_functions [0x00, 0x01, 0x02, 0x03] comm_types [0x00, 0x01, 0x02, 0x03, 0xFF] sessions [0x01, 0x02, 0x03] security_states [False, True] cases [] for sub, comm, session, sec in itertools.product( sub_functions, comm_types, sessions, security_states): case { sub_function: f0x{sub:02X}, comm_type: f0x{comm:02X}, session: f0x{session:02X}, security: sec, } cases.append(case) print(f生成用例总数量: {len(cases)})这段脚本只生成参数组合真正的预期结果还是需要从需求规则中映射。也可以把规则放到一个 Excel 表格中脚本读取后自动拼装用例描述。这样需求变更时维护规则表格比修改用例文档更快也更不容易漏项。需要强调的是自动生成不能替代人工设计尤其是 0x28 服务这类与通信状态强相关的服务很多预期结果依赖实车总线的真实行为必须由人来做判断和修正。7. 0x28 服务接口 API 与自动化测试0x28 服务的测试不一定只能在诊断仪上手工操作。在自动化测试框架中通常会封装一个诊断服务发送函数让脚本直接通过总线接口发送诊断请求。下面给出一个通用的 Python 示例假设底层已经有一个 can_send 函数用于发送 CAN 帧实际项目中需要替换为 CANoe、PCAN、python-can 等适配层。# 发送 0x28 诊断请求并接收响应 # 底层函数 can_send / can_receive 需要按实际总线工具实现 def send_0x28(service_id0x28, sub_function0x03, comm_type0xFF, expect_nrcNone, timeout1.0): request [service_id, sub_function, comm_type] can_send(request, arbitration_id0x7E0) response None # 阻塞等待响应实际项目中建议使用回调或队列 response can_receive(arbitration_id0x7E8, timeouttimeout) if response is None: raise TimeoutError(no response for 0x28 service) # 否定响应格式 7F 28 NRC if response[0] 0x7F: nrc response[2] if expect_nrc is not None and nrc expect_nrc: return fPASS: got expected NRC 0x{nrc:02X} return fFAIL: got NRC 0x{nrc:02X}, expected 0x{expect_nrc:02X} # 肯定响应 if response[0] 0x68: return fPASS: positive response 0x{response[1]:02X} return fFAIL: unknown response {response}调用示例# 正向用例禁用所有通信 result send_0x28(sub_function0x03, comm_type0xFF) print(result) # 异常用例默认会话下期望 NRC 0x22 result send_0x28(sub_function0x03, comm_type0xFF, expect_nrc0x22) print(result)编写自动化脚本时还需要注意几个实际问题CAN 帧的 DLC 不要多加字节0x28 服务请求长度通常为 2 或 3 字节多发的空字节可能被 ECU 判定为长度错误。响应仲裁 ID 要按项目配置有的 ECU 使用 0x7E8有的会使用功能寻址响应。总线波特率、CAN FD 还是经典 CAN都会影响请求发送和响应接收。连续发送多个 0x28 请求时脚本要加入帧间间隔否则可能触发 ECU 的 DoIP 或 CAN 传输层超载保护。收到否定响应后一定要保存原始响应字节方便回溯。如果项目使用的是 DOIP 或以太网诊断0x28 服务的请求和响应会封装在 DoIP 协议里。此时底层需要实现 TCP 连接、DoIP 头部封装和 payload 拆解逻辑比 CAN 复杂一些但用例设计的服务逻辑仍然相同。8. 0x28 服务资源占用与性能观察方法0x28 服务不涉及图像或大模型那种显存监控但测试时仍然要关注总线和 ECU 资源层面的“性能”表现具体包括响应时间、状态切换时间、总线负载变化、CPU 负载影响四个方面。8.1 响应时间观察从诊断请求发出到 ECU 返回响应的时间是诊断测试中的基础指标。在 CAN 总线上可以用 CANoe 的 Trace Window 偏移列直接测量或者在脚本中用高精度时间戳记录start time.perf_counter() resp send_0x28(sub_function0x03, comm_type0xFF) elapsed_ms (time.perf_counter() - start) * 1000 print(fresponse time: {elapsed_ms:.2f} ms)如果需求文档中规定响应时间不超过 50 ms那么用例预期结果中就应写明这个阈值而不是笼统写“尽快响应”。8.2 状态切换时间观察0x28 服务的“切换时间”指标指的是从 ECU 收到请求到实际停止/恢复发送报文的时间。这个时间不能只看响应帧要结合总线报文记录辅助分析。例如发送 0x28 03 后记录到 0x68 03 肯定响应但应用报文仍然继续发送了 200 ms 才停。此时不能说测试失败必须先看需求中是否允许这个“延迟停止”窗口。写入用例时建议这样表达在 0x28 03 请求后的 100 ms 内ECU 应停止发送目标报文。在 0x28 00 请求后的 100 ms 内ECU 应恢复发送目标报文。具体数值以实际需求文档为准。8.3 总线负载变化观察通过 0x28 服务禁用发送后总线负载应该下降。这个值可以通过总线统计工具直接读取。测试前记录初始负载率执行 0x28 03 后再记录一次恢复后再记录一次。三次数据可以作为用例附件保留用于判断 0x28 服务是否真正影响了总线流量。8.4 降低干扰与提高稳定性0x28 服务测试中最大的稳定性风险是测试者忘记恢复通信状态导致后续用例全部跑偏。建议在自动化测试夹具的启动初始化和结束清理阶段都执行一次 0x28 00 请求或 ECU 复位操作def setup_ecu_default(): # 进入扩展会话并锁定安全或直接复位 ECU按项目要求选择 send_ecu_reset() time.sleep(2) print(ECU reset to default state)这样可以保证每个用例的起点一致减少用例间污染。9. 0x28 服务常见问题与排查方法问题现象可能原因排查方式解决方案发送 0x28 请求后无响应诊断请求发送错误、CAN ID 配置错误、ECU 不在线用总线工具检查 ECU 是否发其他响应检查通信是否进入应用模式确认仲裁 ID、波特率、ECU 供电状态返回否定响应 0x7F 0x28 0x12子功能不支持对照项目诊断规范检查支持的子功能列表使用需求中明确支持的子功能返回否定响应 0x7F 0x28 0x13请求长度错误或参数缺失检查请求帧 DLC 和包含的字节数按规范补上 Communication Type 字节或删除多余字节返回否定响应 0x7F 0x28 0x22条件不满足检查当前会话、安全状态、ECU 工作模式先进入正确会话和安全解锁再执行返回否定响应 0x7F 0x28 0x31Communication Type 超出范围对比需求中的通信类型位定义只使用项目定义的通信类型返回肯定响应但报文未停止控制的是非目标报文类型或需求允许延迟停止查看 Trace 中控制后的报文类型和时间戳使用正确 Communication Type对照需求确认延迟窗口执行 0x28 03 后总线一直静默无法恢复ECU 死机或未实现自动恢复检查 ECU 日志手动复位 ECU记录问题反馈给相关团队批量执行多个 0x28 请求时偶发失败总线负载高、帧间隔不足、状态切换未完成增大帧间间隔查看失败时的总线负载脚本中加入等待确保状态稳定后再发下一帧自动化脚本中收到响应为空响应仲裁 ID 不是默认值检查 ECU 地址和网络层配置修改响应仲裁 ID 配置排查时最忌讳只看单个响应。0x28 服务与总线状态强相关一定要把请求帧、响应帧、目标报文、时间戳四个维度对齐起来看。先把总线记录导出再逐步定位。10. 0x28 服务最佳实践与使用建议10.1 先用最小集跑通链路第一次接触 0x28 服务时不要一上来就做全组合测试。先跑通“扩展会话 安全解锁 0x28 03 0x28 00”这个最小闭环确认 ECU 能正常响应、通信状态可控后再扩展组合。最小闭环的三个判断标准收到肯定响应 0x68 03。总线上的应用报文确实停止。发送 0x28 00 后应用报文恢复。满足这三条说明链路正常再进入复杂用例。10.2 把“恢复”放在第一位执行 0x28 03 之前先想好怎么恢复。推荐把 ECU 复位命令作为兜底恢复手段。测试脚本的 finally 块里一定要有复位或恢复动作避免测试一半卡死导致现场不可控。try: send_0x28(sub_function0x03, comm_type0xFF) # 执行测试步骤... finally: send_ecu_reset() time.sleep(2)10.3 需求变更时同步更新用例0x28 服务的子功能、通信类型、会话要求往往在开发阶段会调整。每次需求变更后建议用参数化表格重新生成一轮用例重点检查变更字段是否影响已有预期结果。如果只增加一个通信类型位那么所有涉及通信类型的用例都要回归。10.4 证据链要完整诊断测试的每条有效用例都建议保留三项证据总线记录文件Trace。自动测试脚本日志。通过/失败判定结果。这样即使几个月后有人质疑测试结论也能快速定位。对于 OEM 审核或者产线测试追溯证据链尤其重要。10.5 合规与授权提醒0x28 服务通常会实际控制车辆的通信行为测试前务必确认测试环境处于台架、封闭场地或授权测试车辆中。涉及第三方协议和数据时要遵循相关方的保密要求。任何诊断操作都不得用于绕过安全机制、篡改排放或影响公共道路安全。11. 总结与下一步0x28 服务的用例设计并不复杂但容易在“状态恢复”“通信类型组合”“时序窗口”这些细节上翻车。建议你在自己的项目里先做三件事第一去读当前项目的诊断规范确认 0x28 支持的子功能、Communication Type、会话和安全要求不要拿通用标准硬套。第二构建用例矩阵时把“请求字节”和“ECU 实际通信行为”绑定起来写预期结果不要只写返回什么响应还要写总线上能观察到什么变化。第三把手工用例逐步脚本化用 testbuddy 这类参数化生成思路维护规则让每次需求变更都能快速回归。最容易踩的坑仍然是“忘记恢复”。任何 0x28 测试脚本都要默认带上复位兜底。下一步可以继续往 0x28 与 0x10 会话控制、0x11 ECU 复位、0x27 安全访问的组合场景扩展这些服务经常串在一起组合用例的价值远大于单服务用例。建议把本文档中的用例模板、报文格式和自动化脚本示例收藏备用实际编写时直接按项目参数替换即可。 
长河君 · 2026/9/1 4:21:24 · 阅读 1.2k UDS 0x28通信控制服务需求分析与测试用例设计
开头这次我们来看一个诊断开发过程中绕不开的环节0x28 服务的需求分析与测试用例设计。0x28 服务是 UDSUnified Diagnostic Services统一诊断服务协议里的 CommunicationControl中文叫通信控制服务。它不负责刷写、不负责读故障码而是直接控制 ECU 对外通信报文的收发状态比如让某个应用报文暂时静默、禁止发送、或者只允许接收。很多网络诊断问题尤其是总线负载过高、节点休眠异常、诊断仪与 ECU 握手异常最后排查的时候都会回到 0x28 服务的实现是否严谨、测试是否覆盖到位。这篇文章会围绕 0x28 服务展开三条线第一0x28 服务是什么报文格式和子功能怎么理解第二怎么从需求文档中提取测试点逐步写出可执行、可回归、可评审的用例第三如何把用例落到实际测试链路里包括手工测试、自动化脚本和接口级验证。文中还会用一个诊断用例模板作为基础演示正向、反向、边界、时序和偶发场景怎么写。如果你正在做 CAN/LIN 网络诊断测试或者刚接触 UDS 诊断用例设计这篇文章可以直接作为一份清单来对照使用。1. 0x28 服务核心能力速览能力项说明服务名称CommunicationControl通信控制服务服务 ID0x28服务作用控制 ECU 通信报文的使能与禁用包括发送、接收、或同时控制常见子功能0x00 使能接收与发送、0x01 使能接收并禁用发送、0x02 禁用接收并使能发送、0x03 禁用接收与发送子功能参数部分实现中会有 Communication Type通信类型字节用于指定控制哪类报文如应用报文、网络管理报文、诊断报文会话要求通常需在非默认会话下使用默认会话下可能返回否定响应安全等级部分 OEM 会要求先做安全解锁也有的只限制会话不限制安全等级典型应用总线负载控制、节点静默、网络管理测试、休眠唤醒测试、诊断干扰测试测试重点肯定响应、否定响应 NRC、通信类型过滤、子功能状态切换、掉电复位恢复、会话切换恢复适用读者诊断测试工程师、网络测试工程师、ECU 开发、自动化测试脚本开发需要说明的是UDS 协议本身定义了 0x28 服务的基本框架但具体支持哪些子功能、是否带 Communication Type、默认会话下是否允许执行在 ISO 14229-1 的基础上还受到 OEM 诊断规范和 ECU 设计文档的约束。因此在设计用例之前必须先拿到项目自己的诊断规范不能把通用标准直接当作全部依据。2. 适用场景与使用边界0x28 服务不是每天都会用到的“高频诊断服务”但一旦项目进入网络管理联调、总线负载测试、休眠唤醒测试阶段它就是最重要的开关之一。适合使用 0x28 服务的场景包括测试某个节点静默后其他节点是否正常通信。模拟 ECU 故障验证应用层容错逻辑。控制特定报文类型的收发观察总线负载变化。配合 0x10 会话控制、0x27 安全访问等测试矩阵做诊断链路的组合验证。验证诊断仪下发通信控制命令后ECU 是否能按需求在指定时间内恢复默认状态。同时也要明确 0x28 服务的使用边界。它主要用于测试、下线检测、产线配置和特定售后流程不能用来掩盖或规避真正的软硬件缺陷。测试过程中如果通过 0x28 服务禁用了某个节点的报文发送测试结束后必须确认 ECU 复位的默认状态否则会导致后续测试结果失真。项目开发阶段不建议长期关闭网络管理报文否则总线休眠唤醒逻辑可能被误判。从合规角度说如果测试车辆、台架或模拟环境涉及真实车辆数据、他人隐私数据或商业协议内容需要在授权范围内使用并保护测试数据不被滥用。诊断测试使用的台架、总线接口设备、诊断仪固件都要来自正规渠道避免使用破解或未授权的诊断设备。3. 0x28 服务需求分析先拆需求再写用例很多测试人员写用例时容易陷入一个误区打开标准文档找到 0x28 服务的报文格式然后直接套模板把“发送请求、验证肯定响应”写完就算结束。这样的用例通常流于表面等到了实车测试阶段会发现大量场景没有被覆盖。从需求到用例中间需要做一层“测试颗粒度拆解”。以 0x28 服务为例需求拆解可以从下面几个维度展开。3.1 从诊断规范中提取服务基本信息第一步先锁定服务本身的静态信息。这是用例的“地基”服务 ID 是否为 0x28。支持的子功能列表。子功能是否带抑制肯定响应位SuppressPosRspMsgIndicationBit, bit 7。是否支持 Communication Type 参数。Communication Type 的取值范围例如 bit0 是否表示 Application 报文bit1 是否表示 Network Management 报文bit2 是否表示 Diagnostic 报文。请求是否需要带长度字节例如带 SubFunction 后是否还有 communicationControlType。支持的会话类型例如默认会话、扩展会话、编程会话中哪些允许执行。是否要求安全解锁。肯定响应格式是否包含子功能回显。否定响应中可能出现的 NRC 列表。这些信息在 ISO 14229-1 里能找到一部分但具体车型上很可能有裁剪。比如某些控制器不支持“禁用接收并使能发送”这个子功能或者对网络管理报文不做控制。因此正文规范、诊断调查表、软件需求规格说明书中的一个字都不能漏。3.2 拆出“状态”与“迁移”0x28 服务最核心的不是“发一帧请求收一个响应”而是 ECU 通信状态的变化。需求拆解时要显式画出两条状态线请求前的通信状态。请求后的通信状态。例如一个 ECU 初始状态是“发送使能、接收使能”。发送 0x28 03 后状态变为“发送禁用、接收禁用”。这个状态会持续到什么时候是持续到收到新的 0x28 00 请求还是 ECU 复位后自动恢复如果是复位后恢复恢复时间有没有要求这些状态迁移点必须逐一落到用例里。每一类迁移方向都至少要有正向一条、反向一条、边界一条。3.3 拆出“通信类型”的组合关系如果需求文档中 0x28 服务带 Communication Type那么测试用例就不能只测一个报文类型。要把通信类型字段拆成位级组合优先覆盖全 0即不控制任何通信类型。全 1即控制所有通信类型。单 bit 置 1如只控制 Application 报文。单 bit 置 0如除了 Network Management 报文外都控制。多个 bit 组合如同时控制 Application 和 Network Management。非法 bit 组合如保留了某些 bit 但需求中未定义。针对每个组合还要明确“控制后 E 节点的实际行为”是什么。例如只发送 0x28 02 20communicationControlType 中 bit 0 置位控制应用报文子功能是禁用接收并启用发送那么应用报文还能不能收网络管理报文是不是不受影响这些细节只能从具体项目中获得不能靠猜。3.4 拆出时序与恢复条件诊断服务设计用例时时序往往比单帧交互更容易被遗漏。0x28 服务尤其如此。因为通信控制的本质是让 ECU 在时间轴上进入一个“非正常通信状态”所以必须考虑收到请求后ECU 在多长时间内完成通信状态切换。控制命令是否在总线周期内立即生效。控制持续期间ECU 的收发行为是否符合规范。ECU 复位后是否恢复到默认状态。会话切换后是否恢复到默认状态。多个 0x28 请求连续下发时相互之间的覆盖关系。0x28 服务与 0x28 服务相同子功能重复执行是否有副作用。0x28 服务执行过程中插入 0x10 01 会话切换状态如何恢复。这些点写成测试用例时不能只写“手动观察”更合理的方式是结合总线报文记录和时间戳给出可量化的判断条件。4. 0x28 服务用例设计步骤下面是适用于 0x28 服务的基础用例设计流程。这套流程也可以套用到其他 UDS 服务上但这里我们只看 0x28。4.1 第一步确定测试环境与链路用例可以设计成台架环境也可以设计成实车环境。设计用例时就要明确定位总线类型CAN、CAN FD、LIN、以太网。诊断请求的发送源诊断仪、CANoe、Pytest 脚本、自定义诊断盒。被测试的 ECU一个节点还是多个节点。对端节点是否需要模拟例如用两个节点模拟网关和控制器。总线报文记录工具CANalyzer、PCAN、Vspy 等。环境信息不用在每条用例里重复写但可以在用例模板顶部的“前置条件”中统一声明保证用例可复现。4.2 第二步定义用例模板建议直接用下面的模板字段不要随意省略用例编号TC_0x28_001 用例名称 测试目的 前置条件 测试步骤 预期结果 实际结果 优先级 关联需求对于诊断类用例建议再加入“禁止在真实车辆公共道路上测试”“执行前确认总线报文已记录”等安全提示作为通用前置条件。4.3 第三步按需求矩阵生成基础用例把需求拆解中得到的信息填进一张服务测试矩阵中每行对应一种请求组合每列对应一个预期结果。用例编号子功能Communication Type会话安全状态预期响应预期 ECU 通信行为TC_0x28_0010x000xFF扩展会话已解锁肯定响应发送与接收均恢复使能TC_0x28_0020x010x01扩展会话已解锁肯定响应接收使能发送禁用仅控制 Application 报文TC_0x28_0030x020x02扩展会话已解锁肯定响应发送使能接收禁用仅控制 Network Management 报文TC_0x28_0040x030x03扩展会话已解锁肯定响应发送与接收均禁用控制 Application 和 Network ManagementTC_0x28_0050x030x00扩展会话已解锁肯定响应无实际控制效果因为通信类型为 0TC_0x28_0060x000x05默认会话未解锁否定响应 0x7F 0x28 NRC请求不执行通信状态不变这张矩阵先解决“覆盖面”问题后续再针对每一行扩展边界和异常。4.4 第四步补充边界、异常和时序用例基础矩阵里的正向用例只能证明“行得通”不能证明测试充分。真正拉开用例质量差距的是下面这几类。边界用例子功能为最小值和最大值。Communication Type 只有最低位为 1。Communication Type 只有最高位为 1。Communication Type 全部位为 1。Communication Type 为 0。请求长度为最短合法长度和最长合法长度。请求连续发送 2 次、10 次、100 次。异常用例子功能值不在支持范围内。Communication Type 包含未定义 bit。请求长度错误。请求缺少参数。请求在默认会话下执行。请求在安全锁定状态下执行。请求被另一个诊断服务打断。请求在传输层被分帧且分帧间隔超时。时序用例ECU 复位后立即执行 0x28 服务。执行 0x28 服务后立即执行 0x10 01 回默认会话。执行 0x28 服务后立即执行 0x11 01 复位。连续发送 0x28 03 两次观察第二次是否以第一次状态为准。发送 0x28 03 后等待超过 5 秒再发送 0x28 00观察恢复时间是否在需求范围内。这些用例写完后最好再找一位熟悉需求的人做一次交叉评审重点确认“ECU 通信行为”这个预期结果是否符合需求文档而不是只看响应字节。5. 0x28 服务典型报文格式与用例示例为了让用例设计落到具体帧上这里给出 0x28 服务的基础报文格式。注意具体长度和参数偏移要以项目诊断规范为准这里只描述常见形式。5.1 请求报文格式请求报文通常由服务 ID、子功能和通信类型组成Byte 0: 0x28 Byte 1: Sub-Function Byte 2: Communication Type (可选)其中 Sub-Function 的 bit 6 和 bit 7 有特殊含义bit 7抑制肯定响应位。如果为 1ECU 不发送肯定响应。bit 6控制参数位。如果为 1表示后续带 Communication Type 参数具体项目中可能固定为 0 或固定为 1。bit 0-5实际的子功能值。例如发送 “0x28 03” 表示禁用接收和发送但要看项目是否要求带通信类型。如果需要带通信类型则请求可以是 “0x28 03 0xFF”表示控制所有通信类型。5.2 肯定响应报文格式肯定响应通常回显服务 ID 和子功能Byte 0: 0x68 Byte 1: Sub-Function如果有额外的数据则按项目规范追加。5.3 否定响应报文格式否定响应的格式是固定的Byte 0: 0x7F Byte 1: 0x28 Byte 2: NRC常见的 NRC 包括NRC含义常见触发场景0x12子功能不支持发送了未定义的子功能0x13消息长度错误请求长度不对或缺少通信类型参数0x22条件不满足当前状态不允许执行例如未处于正确会话0x31请求超出范围Communication Type 包含非法 bit0x33安全访问被拒绝需要安全解锁但当前未解锁0x7F服务不支持该 ECU 未实现 0x28 服务这些 NRC 不能只写在标准里要映射到具体需求。比如“0x22 条件不满足”可以细分为“默认会话下不允许”“未解锁不允许”“当前通信状态不允许切换”等不同场景。5.4 示例用例一正向控制所有报文收发字段内容用例编号TC_0x28_001用例名称扩展会话下禁用并恢复所有通信测试目的验证 0x28 03 能禁用所有通信0x28 00 能恢复前置条件ECU 上电处于扩展会话安全解锁总线报文记录已开启测试步骤1. 记录初始状态下 ECU 发送的应用报文和网络管理报文。2. 发送诊断请求 0x28 03 FF。3. 等待 500 ms。4. 记录当前总线报文。5. 发送诊断请求 0x28 00 FF。6. 等待 500 ms。7. 记录恢复后的总线报文。预期结果第 2 步后 ECU 响应 0x68 03第 3 步到第 5 步之间ECU 不再发送任何应用报文和网络管理报文第 5 步后 ECU 响应 0x68 00第 6 步后 ECU 恢复发送报文。5.5 示例用例二仅禁用应用报文字段内容用例编号TC_0x28_002用例名称仅禁用应用报文保留网络管理报文测试目的验证 Communication Type 对报文类型的过滤功能前置条件ECU 上电处于扩展会话安全解锁总线报文记录已开启测试步骤1. 发送 0x28 03 01。2. 等待 1 秒。3. 观察总线上的应用报文和网络管理报文。4. 发送 0x28 00 01。预期结果应用报文停止发送网络管理报文仍然正常发送两个请求均返回肯定响应。5.6 示例用例三安全锁定状态下执行被拒绝字段内容用例编号TC_0x28_003用例名称安全锁定状态下执行 0x28 被拒绝测试目的验证 0x28 服务的安全访问限制前置条件ECU 上电处于扩展会话未执行安全解锁测试步骤1. 发送 0x28 03 FF。2. 观察响应。3. 检查 ECU 通信状态。预期结果返回否定响应 0x7F 0x28 0x33ECU 的通信行为不发生变化。6. testbuddy 式用例生成从手工用例到半自动生成作为“最新网络热词”里出现的 testbuddy 用例生成这里可以多说一句。testbuddy 这类用例生成工具本质上是把需求结构化成测试逻辑再自动输出用例文本。对于 0x28 服务这种参数组合型测试非常适合用类似思路来提效。手工写用例时很容易漏掉“Communication Type 每一位的组合”和“子功能 × 会话 × 安全状态”的交叉场景。用工具或脚本自动生成时思路可以拆成三步。6.1 第一步参数化需求把需求中所有输入项变成参数sub_functions [0x00, 0x01, 0x02, 0x03] comm_types [0x00, 0x01, 0x02, 0x03, 0xFE, 0xFF] sessions [0x01, 0x02, 0x03] security [True, False]6.2 第二步定义预期结果规则每个参数组合对应的预期结果不能靠程序乱猜而是要写成规则。比如如果 session 为默认会话预期 NRC 0x22。如果 security 为 False 且 session 为扩展会话预期 NRC 0x33。如果 sub_function 在支持列表之外预期 NRC 0x12。如果 comm_type 包含未定义 bit预期 NRC 0x31。这些规则在代码里可以表现为字典或 if-else 分支rules { session_ok: [0x02, 0x03], security_required: True, supported_sub_function: [0x00, 0x01, 0x02, 0x03], valid_comm_type_mask: 0x03, }6.3 第三步批量生成用例文本参数组合的笛卡尔积可以自动生成大量候选用例。但要注意全量笛卡尔积会产生冗余比如 “0x28 00 00” 和 “0x28 01 00” 除了子功能字段不同预期结果完全一致可以合并或调整优先级。生成之后还要按优先级过滤正向高优先级、异常中优先级、边界中优先级、跨场景低优先级。下面是一个最简单的生成脚本思路import itertools sub_functions [0x00, 0x01, 0x02, 0x03] comm_types [0x00, 0x01, 0x02, 0x03, 0xFF] sessions [0x01, 0x02, 0x03] security_states [False, True] cases [] for sub, comm, session, sec in itertools.product( sub_functions, comm_types, sessions, security_states): case { sub_function: f0x{sub:02X}, comm_type: f0x{comm:02X}, session: f0x{session:02X}, security: sec, } cases.append(case) print(f生成用例总数量: {len(cases)})这段脚本只生成参数组合真正的预期结果还是需要从需求规则中映射。也可以把规则放到一个 Excel 表格中脚本读取后自动拼装用例描述。这样需求变更时维护规则表格比修改用例文档更快也更不容易漏项。需要强调的是自动生成不能替代人工设计尤其是 0x28 服务这类与通信状态强相关的服务很多预期结果依赖实车总线的真实行为必须由人来做判断和修正。7. 0x28 服务接口 API 与自动化测试0x28 服务的测试不一定只能在诊断仪上手工操作。在自动化测试框架中通常会封装一个诊断服务发送函数让脚本直接通过总线接口发送诊断请求。下面给出一个通用的 Python 示例假设底层已经有一个 can_send 函数用于发送 CAN 帧实际项目中需要替换为 CANoe、PCAN、python-can 等适配层。# 发送 0x28 诊断请求并接收响应 # 底层函数 can_send / can_receive 需要按实际总线工具实现 def send_0x28(service_id0x28, sub_function0x03, comm_type0xFF, expect_nrcNone, timeout1.0): request [service_id, sub_function, comm_type] can_send(request, arbitration_id0x7E0) response None # 阻塞等待响应实际项目中建议使用回调或队列 response can_receive(arbitration_id0x7E8, timeouttimeout) if response is None: raise TimeoutError(no response for 0x28 service) # 否定响应格式 7F 28 NRC if response[0] 0x7F: nrc response[2] if expect_nrc is not None and nrc expect_nrc: return fPASS: got expected NRC 0x{nrc:02X} return fFAIL: got NRC 0x{nrc:02X}, expected 0x{expect_nrc:02X} # 肯定响应 if response[0] 0x68: return fPASS: positive response 0x{response[1]:02X} return fFAIL: unknown response {response}调用示例# 正向用例禁用所有通信 result send_0x28(sub_function0x03, comm_type0xFF) print(result) # 异常用例默认会话下期望 NRC 0x22 result send_0x28(sub_function0x03, comm_type0xFF, expect_nrc0x22) print(result)编写自动化脚本时还需要注意几个实际问题CAN 帧的 DLC 不要多加字节0x28 服务请求长度通常为 2 或 3 字节多发的空字节可能被 ECU 判定为长度错误。响应仲裁 ID 要按项目配置有的 ECU 使用 0x7E8有的会使用功能寻址响应。总线波特率、CAN FD 还是经典 CAN都会影响请求发送和响应接收。连续发送多个 0x28 请求时脚本要加入帧间间隔否则可能触发 ECU 的 DoIP 或 CAN 传输层超载保护。收到否定响应后一定要保存原始响应字节方便回溯。如果项目使用的是 DOIP 或以太网诊断0x28 服务的请求和响应会封装在 DoIP 协议里。此时底层需要实现 TCP 连接、DoIP 头部封装和 payload 拆解逻辑比 CAN 复杂一些但用例设计的服务逻辑仍然相同。8. 0x28 服务资源占用与性能观察方法0x28 服务不涉及图像或大模型那种显存监控但测试时仍然要关注总线和 ECU 资源层面的“性能”表现具体包括响应时间、状态切换时间、总线负载变化、CPU 负载影响四个方面。8.1 响应时间观察从诊断请求发出到 ECU 返回响应的时间是诊断测试中的基础指标。在 CAN 总线上可以用 CANoe 的 Trace Window 偏移列直接测量或者在脚本中用高精度时间戳记录start time.perf_counter() resp send_0x28(sub_function0x03, comm_type0xFF) elapsed_ms (time.perf_counter() - start) * 1000 print(fresponse time: {elapsed_ms:.2f} ms)如果需求文档中规定响应时间不超过 50 ms那么用例预期结果中就应写明这个阈值而不是笼统写“尽快响应”。8.2 状态切换时间观察0x28 服务的“切换时间”指标指的是从 ECU 收到请求到实际停止/恢复发送报文的时间。这个时间不能只看响应帧要结合总线报文记录辅助分析。例如发送 0x28 03 后记录到 0x68 03 肯定响应但应用报文仍然继续发送了 200 ms 才停。此时不能说测试失败必须先看需求中是否允许这个“延迟停止”窗口。写入用例时建议这样表达在 0x28 03 请求后的 100 ms 内ECU 应停止发送目标报文。在 0x28 00 请求后的 100 ms 内ECU 应恢复发送目标报文。具体数值以实际需求文档为准。8.3 总线负载变化观察通过 0x28 服务禁用发送后总线负载应该下降。这个值可以通过总线统计工具直接读取。测试前记录初始负载率执行 0x28 03 后再记录一次恢复后再记录一次。三次数据可以作为用例附件保留用于判断 0x28 服务是否真正影响了总线流量。8.4 降低干扰与提高稳定性0x28 服务测试中最大的稳定性风险是测试者忘记恢复通信状态导致后续用例全部跑偏。建议在自动化测试夹具的启动初始化和结束清理阶段都执行一次 0x28 00 请求或 ECU 复位操作def setup_ecu_default(): # 进入扩展会话并锁定安全或直接复位 ECU按项目要求选择 send_ecu_reset() time.sleep(2) print(ECU reset to default state)这样可以保证每个用例的起点一致减少用例间污染。9. 0x28 服务常见问题与排查方法问题现象可能原因排查方式解决方案发送 0x28 请求后无响应诊断请求发送错误、CAN ID 配置错误、ECU 不在线用总线工具检查 ECU 是否发其他响应检查通信是否进入应用模式确认仲裁 ID、波特率、ECU 供电状态返回否定响应 0x7F 0x28 0x12子功能不支持对照项目诊断规范检查支持的子功能列表使用需求中明确支持的子功能返回否定响应 0x7F 0x28 0x13请求长度错误或参数缺失检查请求帧 DLC 和包含的字节数按规范补上 Communication Type 字节或删除多余字节返回否定响应 0x7F 0x28 0x22条件不满足检查当前会话、安全状态、ECU 工作模式先进入正确会话和安全解锁再执行返回否定响应 0x7F 0x28 0x31Communication Type 超出范围对比需求中的通信类型位定义只使用项目定义的通信类型返回肯定响应但报文未停止控制的是非目标报文类型或需求允许延迟停止查看 Trace 中控制后的报文类型和时间戳使用正确 Communication Type对照需求确认延迟窗口执行 0x28 03 后总线一直静默无法恢复ECU 死机或未实现自动恢复检查 ECU 日志手动复位 ECU记录问题反馈给相关团队批量执行多个 0x28 请求时偶发失败总线负载高、帧间隔不足、状态切换未完成增大帧间间隔查看失败时的总线负载脚本中加入等待确保状态稳定后再发下一帧自动化脚本中收到响应为空响应仲裁 ID 不是默认值检查 ECU 地址和网络层配置修改响应仲裁 ID 配置排查时最忌讳只看单个响应。0x28 服务与总线状态强相关一定要把请求帧、响应帧、目标报文、时间戳四个维度对齐起来看。先把总线记录导出再逐步定位。10. 0x28 服务最佳实践与使用建议10.1 先用最小集跑通链路第一次接触 0x28 服务时不要一上来就做全组合测试。先跑通“扩展会话 安全解锁 0x28 03 0x28 00”这个最小闭环确认 ECU 能正常响应、通信状态可控后再扩展组合。最小闭环的三个判断标准收到肯定响应 0x68 03。总线上的应用报文确实停止。发送 0x28 00 后应用报文恢复。满足这三条说明链路正常再进入复杂用例。10.2 把“恢复”放在第一位执行 0x28 03 之前先想好怎么恢复。推荐把 ECU 复位命令作为兜底恢复手段。测试脚本的 finally 块里一定要有复位或恢复动作避免测试一半卡死导致现场不可控。try: send_0x28(sub_function0x03, comm_type0xFF) # 执行测试步骤... finally: send_ecu_reset() time.sleep(2)10.3 需求变更时同步更新用例0x28 服务的子功能、通信类型、会话要求往往在开发阶段会调整。每次需求变更后建议用参数化表格重新生成一轮用例重点检查变更字段是否影响已有预期结果。如果只增加一个通信类型位那么所有涉及通信类型的用例都要回归。10.4 证据链要完整诊断测试的每条有效用例都建议保留三项证据总线记录文件Trace。自动测试脚本日志。通过/失败判定结果。这样即使几个月后有人质疑测试结论也能快速定位。对于 OEM 审核或者产线测试追溯证据链尤其重要。10.5 合规与授权提醒0x28 服务通常会实际控制车辆的通信行为测试前务必确认测试环境处于台架、封闭场地或授权测试车辆中。涉及第三方协议和数据时要遵循相关方的保密要求。任何诊断操作都不得用于绕过安全机制、篡改排放或影响公共道路安全。11. 总结与下一步0x28 服务的用例设计并不复杂但容易在“状态恢复”“通信类型组合”“时序窗口”这些细节上翻车。建议你在自己的项目里先做三件事第一去读当前项目的诊断规范确认 0x28 支持的子功能、Communication Type、会话和安全要求不要拿通用标准硬套。第二构建用例矩阵时把“请求字节”和“ECU 实际通信行为”绑定起来写预期结果不要只写返回什么响应还要写总线上能观察到什么变化。第三把手工用例逐步脚本化用 testbuddy 这类参数化生成思路维护规则让每次需求变更都能快速回归。最容易踩的坑仍然是“忘记恢复”。任何 0x28 测试脚本都要默认带上复位兜底。下一步可以继续往 0x28 与 0x10 会话控制、0x11 ECU 复位、0x27 安全访问的组合场景扩展这些服务经常串在一起组合用例的价值远大于单服务用例。建议把本文档中的用例模板、报文格式和自动化脚本示例收藏备用实际编写时直接按项目参数替换即可。