在汽车电子网络诊断项目里很多刚接触 UDS 测试的同学第一眼看到 0x28 服务时都会觉得它很简单不就是一个“控制 ECU 通信开关”的服务吗但当需求文档里写着“在特定条件下临时屏蔽网络管理报文同时保留诊断链路可用”还要求考虑会话切换、安全解锁、上下电恢复路径时用例设计的复杂度一下子就上来了。本文围绕 0x28 CommunicationControl 服务从协议报文格式讲起结合实际需求文档给出测试用例设计思路并附上可执行的 CAPL 脚本、Python 验证脚本以及基于 testbuddy 等平台的用例组织方法。无论你是刚进入诊断测试领域的新手还是正在做网络诊断测试开发的工程师都可以把这篇文章当作一份 0x28 服务用例设计的参考模板。1. 背景与核心概念1.1 什么是 0x28 服务在整车电子电气架构中ECU电子控制单元之间通过 CAN、CAN FD、LIN、FlexRay 等总线通信。为了让诊断仪、产线设备、售后设备能够和 ECU 对话行业里广泛采用 UDSUnified Diagnostic Services统一诊断服务协议。UDS 定义在 ISO 14229 标准中是汽车诊断领域最基础的应用层协议之一。0x28 服务标准名称是 CommunicationControl中文可以翻译为“通信控制服务”。它允许外部诊断仪向一个或者多个 ECU 发送控制指令使 ECU 临时性地启用、禁用指定类型的通信报文。这里说的“通信报文”不是诊断请求本身而是指 ECU 在正常运行过程中对外发送的应用报文、网络管理报文等周期性或者事件型报文。例如当整车进入某种静默模式时控制器可以通过 0x28 服务暂时停止发送网络管理报文从而让总线进入待机状态当产线需要刷写某一个节点时也可以通过 0x28 服务把其他节点的总线报文抑制掉避免干扰。1.2 0x28 服务解决什么问题从功能边界来看0x28 服务解决的核心问题是“在不改变 ECU 软件逻辑的前提下临时控制 ECU 的对外通信行为”。在实际项目中它常常被用于以下几类场景静默模式控制当整车下电或者进入某些低功耗状态时通过 0x28 服务禁用网络管理报文让总线负载降下来帮助网络快速休眠。产线 EOLEnd of Line测试在产线末端的检测环节可能只需要与目标 ECU 通信此时可以通过 0x28 服务暂时屏蔽其他 ECU 的报文避免总线冲突。软件刷写前置处理在刷写过程中某些 ECU 如果继续发送应用报文可能影响刷写工具的诊断通信质量刷写前可以禁用相关报文。防盗与安全策略某些安全场景下车辆控制器会根据整车状态禁用指定通信防止非授权访问。需要注意0x28 服务不等于“关闭整个 ECU”。ECU 本身仍然在工作只是通信栈对外表现为“不发报文”或者“不响应某些报文”。这种临时状态通常会在收到 enable 指令、切换诊断会话、ECU 重启或下电后恢复。1.3 0x28 服务用例设计的难点很多同学在设计 0x28 服务用例时容易只覆盖“发请求、看正响应”这层表面逻辑却忽略了它背后的影响面。真正把它做成一套可信赖的测试用例难点集中在三处第一参数组合多。0x28 服务包含子功能参数和通信类型参数再加上不同的诊断会话、安全等级、物理寻址/功能寻址组合起来可能有几十甚至上百条用例。如果需求文档描述不清晰用例很难收敛。第二影响范围广。0x28 服务会改变总线上的报文行为进而影响网络管理状态、DTC 状态、休眠唤醒策略、E2E 安全校验等。单独看一个 ECU 的响应不足以证明功能正确。第三恢复路径多。0x28 的“禁用”是临时状态至少要有一种可靠的恢复方式。是发 enable 命令恢复还是切会话恢复还是上下电恢复如果测试用例只验证了禁用效果没验证恢复路径那么这条用例在项目回归中是不可靠的。因此0x28 服务的用例设计不能只看协议手册必须结合具体车型的通信矩阵、诊断需求文档、网络管理规范一起展开。2. 0x28 服务报文格式与关键参数2.1 请求与响应报文格式在 UDS 应用层0x28 服务的请求报文格式如下字节位置参数名称说明Byte 0SID固定为 0x28Byte 1Sub-function子功能用于指示启用或禁用通信Byte 2Communication Type通信类型用于指定控制哪类报文Byte 3扩展控制参数可选部分 OEM 会扩展用于更细粒度的节点控制这里先剥掉 ISO-TP 传输层只看应用层 payload。举例来说如果要发送“禁用网络管理报文”通常请求为28 01 03。其中28是服务 ID。01表示子功能为 disable禁用通信。03表示通信类型为网络管理报文。对应的正响应一般是一帧68 01第一个字节是 SID 0x40即 0x68第二个字节回显子功能 0x01。如果请求失败ECU 会返回负响应格式为7F 28 NRC其中7F表示负响应28是服务 IDNRC是具体的否定响应码。常用子功能值如下子功能值含义说明0x00Enable Communication启用/恢复相关通信0x01Disable Communication禁用相关通信0x02 ~ 0x7F由 OEM 扩展或保留具体含义以需求文档为准这里要特别提一下 SPR 位Suppress Positive Response抑制正响应位。0x28 服务属于带子功能的服务因此第 7 位可以作为 SPR 位。当发送的子功能最高位为 1 时例如0x81表示“抑制正响应”也就是说ECU 如果处理成功只执行动作不再回复正响应如果处理失败仍然需要回复负响应。这个细节在用例设计时非常容易遗漏。2.2 通信类型参数通信类型参数用于告诉 ECU“你要控制的是哪一类报文”。常见定义如下通信类型值含义典型报文类型0x01Normal Application Messages应用报文例如周期性状态报文0x02Normal Diagnostic Messages诊断报文0x03Normal Network Management Messages网络管理报文例如 NM 报文0x040x01 0x02 组合应用 诊断0x050x01 0x03 组合应用 网络管理0x060x02 0x03 组合诊断 网络管理0x07全部报文类型所有正常通信报文0x00、0x08~0xFF保留或 OEM 自定义具体以需求为准需要注意上表中的数值是通用做法不同 OEM、不同车型对通信类型的定义可能不同。有些控制器项目会把“应用报文”进一步拆分为“周期应用报文”和“事件应用报文”此时会引入 OEM 自定义的扩展值。因此设计用例前一定把通信矩阵和需求文档打开逐项确认当前控制器支持的 communication type 范围。2.3 会话、安全等级与寻址方式0x28 服务并不是在任何状态下都能随意执行。通常需求文档会约定以下几个前置条件支持的诊断会话有的 ECU 只在扩展诊断会话0x10 03下支持 0x28 disable默认会话下可能直接返回 NRC。安全等级部分子功能需要先通过 0x27 服务进行安全解锁未解锁时返回 0x33 SecurityAccessDenied。寻址方式0x28 请求可以使用物理寻址也可以使用功能寻址。物理寻址时 ECU 会回复正响应功能寻址时按照 UDS 标准ECU 一般不回复正响应避免多个 ECU 同时回复导致总线冲突。这两种寻址方式都要写进用例尤其是功能寻址场景要验证“多个 ECU 不回复正响应但确实都执行了通信禁用动作”。2.4 常见否定响应码NRC含义常见出现原因0x12SubFunctionNotSupported子功能不是该 ECU 支持的 enable/disable0x13IncorrectMessageLengthOrInvalidFormat报文长度不对例如缺少通信类型字节0x22ConditionsNotCorrect前置条件不满足例如车速过高、电源状态不对0x31RequestOutOfRange通信类型参数超出 ECU 支持范围0x33SecurityAccessDenied未解锁或解锁等级不足0x7ESubFunctionNotSupportedInActiveSession当前会话不支持该子功能0x7FServiceNotSupportedInActiveSession当前会话不支持 0x28 服务本身不同 NRC 对应的用例策略完全不同。比如 0x31 说明参数越界用例重点是参数边界0x22 说明外部条件不满足用例重点是前置条件的组合覆盖。3. 需求分析与用例设计的通用方法3.1 从一份需求文档开始假设你拿到手的需求文档包含下面这段描述服务名称CommunicationControl (0x28) 支持会话扩展诊断会话0x10 03 安全等级执行 disable 子功能前需要安全解锁security level 0x01 支持子功能0x00 enable、0x01 disable 支持通信类型0x01 应用报文、0x03 网络管理报文 前置条件KL15 OFF 或 车速 5 km/h且无 BusOff 事件 控制效果0x28 01 03 生效后ECU 停止发送 NM 报文0x28 00 03 生效后恢复 NM 报文发送 退出扩展会话或重新上电后通信状态恢复为正常发送。这段需求虽然比较简短但已经包含了用例设计的五个关键要素条件会话、安全、车速、动作子功能、对象通信类型、效果报文行为、恢复路径会话切换、上下电。3.2 把需求拆成用例维度基于上面的需求描述可以拆出以下六个用例设计维度前置条件维度电源状态、诊断会话、安全解锁、车速、总线状态。请求参数维度子功能、通信类型、SPR 位、附加控制参数。响应维度正响应、负响应、抑制正响应。行为维度目标报文是否停止发送、停止后的总线状态、恢复时间。恢复维度enable 指令恢复、会话切换恢复、上下电恢复、ECU 复位恢复。异常维度非法参数、未解锁、会话不支持、重复执行、并发请求。每个需求点至少映射到一个维度每个维度至少对应一条用例。这样做的好处是需求评审时如果某个维度没有覆盖可以直接和系统工程师讨论把需求不明确的地方提前暴露出来。3.3 用参数矩阵压缩用例规模0x28 服务如果做全组合用例数会非常惊人。假设子功能有 2 个、通信类型有 5 个、会话有 2 种、安全状态有 2 种理论上就是 2×5×2×240 条再加上恢复路径和异常场景很容易超过 100 条。实际项目中不建议盲目做全组合而是使用“参数矩阵”来收敛。具体做法是先确认需求中是否存在明确的限制条件。例如需求写明了“只在扩展会话下支持 0x28”那么默认会话的用例只需要验证“返回 0x7F 或 0x7E”不需要把 5 种通信类型全部在默认会话下跑一遍。再比如如果安全解锁状态对所有子功能都有影响那么“未解锁”只需要挑 1~2 个典型通信类型验证 0x33再覆盖一个 SPR 位场景即可不需要所有通信类型都重复验证。通过这种“先找同质性再抽典型值”的方法可以把用例数量控制在可维护的范围内。4. 在 testbuddy 中组织 0x28 服务用例4.1 为什么使用测试管理平台在实际项目中几十条 0x28 用例如果只靠 Excel 管理会出现两个问题一是需求变更后很难同步更新用例二是执行结果、失败截图、问题单关联不直观。使用 testbuddy、QMetry、禅道这类测试管理平台可以有效解决用例资产沉淀和追溯问题。testbuddy 是近几年在测试团队中比较常用的一款用例管理平台支持测试计划、用例编写、执行记录、缺陷跟踪等功能。对于 0x28 服务这种参数组合较多的诊断服务可以在平台中为每个服务建一个测试套件再按功能场景分子模块而不是把所有用例平铺在一层目录里。4.2 用例字段模板在 testbuddy 中设计 0x28 服务用例时建议至少包含以下字段字段名示例值说明用例编号TC_0x28_NM_001按服务、场景、序号组织需求 IDREQ_0x28_001关联需求条目用例名称03 子功能为 0x01 时禁用 NM 报文描述核心验证点前置条件扩展会话、安全解锁、KL15 OFF描述环境条件测试步骤1. 打开 CANoe2. 进入扩展会话3. 发送 28 01 03可执行的操作序列输入数据SubFunction0x01, CommunicationType0x03请求参数预期结果ECU 不再发送 NM 报文正响应 0x68 0x01可判定的结果优先级P1 / P2 / P3决定回归顺序执行状态Pass / Fail / Blocked平台内置字段备注关注 BusOff 场景补充说明通过这些字段测试工程师可以在平台上快速筛选出“P1 且未执行”的用例安排回归计划。4.3 用例生成与评审流程在 testbuddy 中生成 0x28 用例可以分三步第一步由测试工程师根据需求文档和参数矩阵在测试套件中按照“正常场景、异常场景、恢复场景、关联场景”四个分组填写用例。不要一次性写完先把每条用例的核心步骤和预期结果写粗再逐条细化。第二步利用参数组合思路做批量生成。这里所谓的“生成”并不是完全自动生成而是把子功能、通信类型、会话状态、安全状态做成枚举再根据需求约束筛选出有效组合。可以用 Excel 或脚本先跑出一份组合清单再导入 testbuddy 形成候选用例。第三步组织用例评审。评审时重点检查三个方面是否覆盖所有需求点、前置条件是否可满足、预期结果是否可判定。评审通过后将用例状态置为 Approved再进入执行阶段。5. 0x28 服务典型用例设计实战5.1 基础请求响应用例基础请求响应用例主要验证“请求能发、响应能回、参数正确”。这部分用例适合放在冒烟测试中用来快速判断环境是否正常。用例编号用例名称测试步骤输入数据预期结果TC_0x28_BASIC_001发送 enable NM 请求验证正响应进入扩展会话发送 28 00 03SF0x00, CommType0x03正响应 68 00BUS 上 NM 报文恢复TC_0x28_BASIC_002发送 disable NM 请求验证正响应进入扩展会话发送 28 01 03SF0x01, CommType0x03正响应 68 01NM 报文停止TC_0x28_BASIC_003发送非法长度请求进入扩展会话发送 28 01SF0x01, 缺少 CommType负响应 7F 28 13TC_0x28_BASIC_004发送不支持的子功能进入扩展会话发送 28 05 01SF0x05负响应 7F 28 12TC_0x28_BASIC_005发送不支持的通信类型进入扩展会话发送 28 01 08CommType0x08负响应 7F 28 31注意用例中的具体 NRC 以 ECU 实际实现为准。如果需求文档没有明确说明最好先在实车上用诊断仪确认一次再把确认结果固化到用例中。5.2 通信控制行为用例通信控制行为用例是 0x28 服务的核心重点是验证 ECU 的对外通信行为是否真的发生了变化。用例编号用例名称测试步骤预期结果TC_0x28_BEH_001disable 应用报文后周期应用报文停止记录正常周期报文发送 28 01 01观察 2s 以上周期应用报文停止NM 报文不受影响TC_0x28_BEH_002enable 应用报文后周期应用报文恢复先 disable再发送 28 00 01周期应用报文恢复发送TC_0x28_BEH_003disable NM 报文后总线静默发送 28 01 03观察总线ECU 不再发送 NM 报文其他节点 NM 不受影响TC_0x28_BEH_004enable NM 报文后总线恢复正常先 disable再发送 28 00 03NM 报文恢复发送TC_0x28_BEH_005通信类型为 0x07 时禁用全部通信发送 28 01 07观察总线应用报文和 NM 报文均停止TC_0x28_BEH_006disable 后重复发送相同 disable 请求连续发送 28 01 03 两次第二次仍返回正响应状态不改变这里的验证手段建议用 CANoe 的统计窗口或 CAPL 脚本统计特定 ID 的报文数量。例如发送 disable 请求前记录 5 秒内 NM 报文数量发送后同样记录 5 秒如果从原来的几十帧降为 0才说明通信控制生效。5.3 会话切换与恢复场景0x28 服务的“临时性”决定了恢复路径非常重要。很多测试只测到 disable 成功就结束结果车辆下线后在售后被诊断仪误操作 disable 之后无法恢复问题就严重了。用例编号用例名称测试步骤预期结果TC_0x28_RST_001disable 后切换会话通信恢复扩展会话 disable NM切到默认会话观察总线NM 报文自动恢复TC_0x28_RST_002disable 后 ECU 复位通信恢复扩展会话 disable NM发送 11 01 ECUReset观察总线复位后 NM 报文恢复TC_0x28_RST_003disable 后整车上电下电通信恢复扩展会话 disable NM断开电源重新上电观察总线上电后 NM 报文恢复TC_0x28_RST_004enable 请求恢复扩展会话 disable NM发送 28 00 03NM 报文立即恢复TC_0x28_RST_005多次会话切换后状态一致性反复切换会话每次切断电验证通信状态始终符合预期不出现永久禁用恢复场景的设计原则是需求文档写了几条恢复路径至少要覆盖几条如果需求没有写必须找系统工程师确认否则这条用例是不完整的。5.4 异常与容错场景异常场景主要验证 ECU 在面对非法输入、未授权操作、总线异常时能够正确拒绝动作并且不影响自身稳定性。用例编号用例名称测试步骤预期结果TC_0x28_ERR_001默认会话下发送 disable 请求默认会话发送 28 01 03负响应 7F 28 7F 或 7F 28 7ETC_0x28_ERR_002未解锁时发送 disable 请求扩展会话但不执行 0x27发送 28 01 03负响应 7F 28 33TC_0x28_ERR_003发送带 SPR 位的 enable 请求扩展会话发送 28 80 03无正响应NM 报文恢复TC_0x28_ERR_004功能寻址发送 disable 请求通过 0x7DF 功能寻址发送 28 01 03所有节点不回复正响应但执行禁用TC_0x28_ERR_005总线 BusOff 后发送请求人为制造 BusOff恢复后发送 28 00 03通信恢复无异常 NRCTC_0x28_ERR_006通信类型 0x00 越界扩展会话发送 28 01 00负响应 7F 28 31带 SPR 位的场景容易被忽略但它经常用在“多个 ECU 同时执行同一个动作且不希望总线被正响应刷屏”的场景中。测试时要注意SPR 位只是抑制正响应不影响请求合法性的校验。5.5 关联场景网络管理、DTC 与休眠唤醒0x28 服务的威力在于它与整车网络行为的联动。设计用例时不能只盯着诊断仪那一侧。比如 disable NM 报文后如果该 ECU 是网络管理的主节点其他节点可能因为收不到 NM 而进入网络休眠流程如果该 ECU 是应用报文的重要数据源某些依赖该报文的功能控制器可能会报 DTC。因此在项目测试中还要增加以下关联用例0x28 disable NM 后观察整车网络是否可以在规定时间内进入休眠。0x28 disable 应用报文后确认目标 ECU 是否记录通信类 DTC。0x28 enable 后确认 DTC 是否从当前状态清除或变为历史故障。0x28 disable 应用报文期间执行 0x22 读取数据标识确认诊断链路仍然可用。0x28 disable 报文后通过 0x27 安全访问、0x2E 写入数据等操作验证诊断链路不受影响。这些关联用例不需要每条都做全组合而是选择项目中最关键的网络状态和 DTC 策略进行验证。一旦发现 0x28 动作影响了其他功能优先拉通网络工程师和软件工程师确认行为是否符合设计预期。6. 测试环境搭建与执行步骤6.1 测试环境组成0x28 服务测试的环境通常由以下几部分组成被测 ECU需要支持 0x28 服务的控制器。总线接口设备如 CANoe、VN1610、PCAN 等用于发送诊断请求和采集总线报文。总线仿真环境部分测试需要使用剩余总线仿真模拟其他节点周期发送报文。电源设备可控电源用于模拟 KL15 ON/OFF、上下电场景。诊断分析工具CANoe、CANalyzer、DIVA、或自研 Python 脚本均可。环境搭建时有一个细节要特别注意0x28 服务测试需要同时监控多个信号维度。除了诊断响应之外还要记录被测 ECU 的应用报文、网络管理报文、整车其他节点的响应情况才能完整判断测试结果。因此建议在 CANoe 工程中预先配置好待测报文的 DBC 文件并为关键报文建立统计窗口。6.2 用 CANoe/CAPL 发送 0x28 请求在 CANoe 中可以通过 CAPL 程序向总线上发送 0x28 请求。下面这个示例演示了如何向 CAN1 通道发送“禁用网络管理报文”的请求/* 文件路径TestNode.can */ on key d { message 0x7E0 msg; msg.byte(0) 0x03; // PCI单帧Payload 长度为 3 msg.byte(1) 0x28; // SIDCommunicationControl msg.byte(2) 0x01; // Sub-functionDisable msg.byte(3) 0x03; // Communication TypeNetwork Management msg.dlc 4; msg.can 1; // 指定发送通道多通道工程需要配置 write(Send 0x28 disable NM); output(msg); } on key e { message 0x7E0 msg; msg.byte(0) 0x03; msg.byte(1) 0x28; msg.byte(2) 0x00; // Sub-functionEnable msg.byte(3) 0x03; msg.dlc 4; msg.can 1; write(Send 0x28 enable NM); output(msg); }这个示例使用的是直接发送 CAN 报文的方式。严格来说完整项目中的诊断请求通常通过诊断层函数或诊断数据库生成但直接构造 ISO-TP 单帧报文可以帮你快速验证 ECU 的响应逻辑也便于初学者理解报文结构。如果你使用的是 CAN FD 或者报文包含地址扩展代码需要按实际通信矩阵调整。示例中0x7E0是常见的物理请求 CAN ID实际项目以通信矩阵为准。6.3 用 Python 脚本快速验证在部分自动化测试环境中团队更倾向于使用 Python 配合 python-can 库发送诊断请求。下面是一个最小可运行的示例# 文件路径send_0x28.py import can def send_0x28(bus, sub_function: int, comm_type: int): # 构造 0x28 请求28 子功能 通信类型 payload [0x03, 0x28, sub_function, comm_type] msg can.Message( arbitration_id0x7E0, datapayload, is_extended_idFalse, dlc4 ) bus.send(msg) print(fSent: 28 {sub_function:02X} {comm_type:02X}) if __name__ __main__: bus can.interface.Bus(channelcan0, interfacesocketcan) # 禁用网络管理报文 send_0x28(bus, sub_function0x01, comm_type0x03)需要说明的是这个示例没有实现 ISO-TP 的分包与流控只适用于单帧请求。若你的诊断请求字节数超过 7 字节或者使用了功能寻址建议使用 python-can-isotp 库或成熟诊断工具封装。6.4 执行与判定流程一条 0x28 服务用例的完整执行流程通常如下打开 CANoe 工程加载 DBC、诊断数据库和测试脚本。给 ECU 上电进入正常通信状态确认总线无异常故障帧。执行 0x10 03 进入扩展诊断会话。如果需求要求安全解锁通过 0x27 服务完成解锁。记录当前总线基线例如 NM 报文周期和 ID 列表。发送 0x28 请求等待 ECU 处理。采集 3~5 秒总线报文对比目标报文是否停止或恢复。记录诊断响应、NRC、总线报文变化填入 testbuddy 用例执行结果。如果用例失败截图保存现场报文创建缺陷并关联到对应需求。判定结果时不能只看“正响应是否返回”。0x28 的正响应只代表 ECU 接收并执行了命令不代表通信行为一定符合预期。必须把“目标报文是否被抑制”“其他报文是否受影响”“恢复路径是否有效”作为整体判定依据。7. 常见问题与排查思路问题现象常见原因解决思路发送 28 01 03 后 ECU 仍然 UDS 0x28通信控制服务测试用例设计：从协议规范到CANoe自动化验证
在汽车电子网络诊断项目里很多刚接触 UDS 测试的同学第一眼看到 0x28 服务时都会觉得它很简单不就是一个“控制 ECU 通信开关”的服务吗但当需求文档里写着“在特定条件下临时屏蔽网络管理报文同时保留诊断链路可用”还要求考虑会话切换、安全解锁、上下电恢复路径时用例设计的复杂度一下子就上来了。本文围绕 0x28 CommunicationControl 服务从协议报文格式讲起结合实际需求文档给出测试用例设计思路并附上可执行的 CAPL 脚本、Python 验证脚本以及基于 testbuddy 等平台的用例组织方法。无论你是刚进入诊断测试领域的新手还是正在做网络诊断测试开发的工程师都可以把这篇文章当作一份 0x28 服务用例设计的参考模板。1. 背景与核心概念1.1 什么是 0x28 服务在整车电子电气架构中ECU电子控制单元之间通过 CAN、CAN FD、LIN、FlexRay 等总线通信。为了让诊断仪、产线设备、售后设备能够和 ECU 对话行业里广泛采用 UDSUnified Diagnostic Services统一诊断服务协议。UDS 定义在 ISO 14229 标准中是汽车诊断领域最基础的应用层协议之一。0x28 服务标准名称是 CommunicationControl中文可以翻译为“通信控制服务”。它允许外部诊断仪向一个或者多个 ECU 发送控制指令使 ECU 临时性地启用、禁用指定类型的通信报文。这里说的“通信报文”不是诊断请求本身而是指 ECU 在正常运行过程中对外发送的应用报文、网络管理报文等周期性或者事件型报文。例如当整车进入某种静默模式时控制器可以通过 0x28 服务暂时停止发送网络管理报文从而让总线进入待机状态当产线需要刷写某一个节点时也可以通过 0x28 服务把其他节点的总线报文抑制掉避免干扰。1.2 0x28 服务解决什么问题从功能边界来看0x28 服务解决的核心问题是“在不改变 ECU 软件逻辑的前提下临时控制 ECU 的对外通信行为”。在实际项目中它常常被用于以下几类场景静默模式控制当整车下电或者进入某些低功耗状态时通过 0x28 服务禁用网络管理报文让总线负载降下来帮助网络快速休眠。产线 EOLEnd of Line测试在产线末端的检测环节可能只需要与目标 ECU 通信此时可以通过 0x28 服务暂时屏蔽其他 ECU 的报文避免总线冲突。软件刷写前置处理在刷写过程中某些 ECU 如果继续发送应用报文可能影响刷写工具的诊断通信质量刷写前可以禁用相关报文。防盗与安全策略某些安全场景下车辆控制器会根据整车状态禁用指定通信防止非授权访问。需要注意0x28 服务不等于“关闭整个 ECU”。ECU 本身仍然在工作只是通信栈对外表现为“不发报文”或者“不响应某些报文”。这种临时状态通常会在收到 enable 指令、切换诊断会话、ECU 重启或下电后恢复。1.3 0x28 服务用例设计的难点很多同学在设计 0x28 服务用例时容易只覆盖“发请求、看正响应”这层表面逻辑却忽略了它背后的影响面。真正把它做成一套可信赖的测试用例难点集中在三处第一参数组合多。0x28 服务包含子功能参数和通信类型参数再加上不同的诊断会话、安全等级、物理寻址/功能寻址组合起来可能有几十甚至上百条用例。如果需求文档描述不清晰用例很难收敛。第二影响范围广。0x28 服务会改变总线上的报文行为进而影响网络管理状态、DTC 状态、休眠唤醒策略、E2E 安全校验等。单独看一个 ECU 的响应不足以证明功能正确。第三恢复路径多。0x28 的“禁用”是临时状态至少要有一种可靠的恢复方式。是发 enable 命令恢复还是切会话恢复还是上下电恢复如果测试用例只验证了禁用效果没验证恢复路径那么这条用例在项目回归中是不可靠的。因此0x28 服务的用例设计不能只看协议手册必须结合具体车型的通信矩阵、诊断需求文档、网络管理规范一起展开。2. 0x28 服务报文格式与关键参数2.1 请求与响应报文格式在 UDS 应用层0x28 服务的请求报文格式如下字节位置参数名称说明Byte 0SID固定为 0x28Byte 1Sub-function子功能用于指示启用或禁用通信Byte 2Communication Type通信类型用于指定控制哪类报文Byte 3扩展控制参数可选部分 OEM 会扩展用于更细粒度的节点控制这里先剥掉 ISO-TP 传输层只看应用层 payload。举例来说如果要发送“禁用网络管理报文”通常请求为28 01 03。其中28是服务 ID。01表示子功能为 disable禁用通信。03表示通信类型为网络管理报文。对应的正响应一般是一帧68 01第一个字节是 SID 0x40即 0x68第二个字节回显子功能 0x01。如果请求失败ECU 会返回负响应格式为7F 28 NRC其中7F表示负响应28是服务 IDNRC是具体的否定响应码。常用子功能值如下子功能值含义说明0x00Enable Communication启用/恢复相关通信0x01Disable Communication禁用相关通信0x02 ~ 0x7F由 OEM 扩展或保留具体含义以需求文档为准这里要特别提一下 SPR 位Suppress Positive Response抑制正响应位。0x28 服务属于带子功能的服务因此第 7 位可以作为 SPR 位。当发送的子功能最高位为 1 时例如0x81表示“抑制正响应”也就是说ECU 如果处理成功只执行动作不再回复正响应如果处理失败仍然需要回复负响应。这个细节在用例设计时非常容易遗漏。2.2 通信类型参数通信类型参数用于告诉 ECU“你要控制的是哪一类报文”。常见定义如下通信类型值含义典型报文类型0x01Normal Application Messages应用报文例如周期性状态报文0x02Normal Diagnostic Messages诊断报文0x03Normal Network Management Messages网络管理报文例如 NM 报文0x040x01 0x02 组合应用 诊断0x050x01 0x03 组合应用 网络管理0x060x02 0x03 组合诊断 网络管理0x07全部报文类型所有正常通信报文0x00、0x08~0xFF保留或 OEM 自定义具体以需求为准需要注意上表中的数值是通用做法不同 OEM、不同车型对通信类型的定义可能不同。有些控制器项目会把“应用报文”进一步拆分为“周期应用报文”和“事件应用报文”此时会引入 OEM 自定义的扩展值。因此设计用例前一定把通信矩阵和需求文档打开逐项确认当前控制器支持的 communication type 范围。2.3 会话、安全等级与寻址方式0x28 服务并不是在任何状态下都能随意执行。通常需求文档会约定以下几个前置条件支持的诊断会话有的 ECU 只在扩展诊断会话0x10 03下支持 0x28 disable默认会话下可能直接返回 NRC。安全等级部分子功能需要先通过 0x27 服务进行安全解锁未解锁时返回 0x33 SecurityAccessDenied。寻址方式0x28 请求可以使用物理寻址也可以使用功能寻址。物理寻址时 ECU 会回复正响应功能寻址时按照 UDS 标准ECU 一般不回复正响应避免多个 ECU 同时回复导致总线冲突。这两种寻址方式都要写进用例尤其是功能寻址场景要验证“多个 ECU 不回复正响应但确实都执行了通信禁用动作”。2.4 常见否定响应码NRC含义常见出现原因0x12SubFunctionNotSupported子功能不是该 ECU 支持的 enable/disable0x13IncorrectMessageLengthOrInvalidFormat报文长度不对例如缺少通信类型字节0x22ConditionsNotCorrect前置条件不满足例如车速过高、电源状态不对0x31RequestOutOfRange通信类型参数超出 ECU 支持范围0x33SecurityAccessDenied未解锁或解锁等级不足0x7ESubFunctionNotSupportedInActiveSession当前会话不支持该子功能0x7FServiceNotSupportedInActiveSession当前会话不支持 0x28 服务本身不同 NRC 对应的用例策略完全不同。比如 0x31 说明参数越界用例重点是参数边界0x22 说明外部条件不满足用例重点是前置条件的组合覆盖。3. 需求分析与用例设计的通用方法3.1 从一份需求文档开始假设你拿到手的需求文档包含下面这段描述服务名称CommunicationControl (0x28) 支持会话扩展诊断会话0x10 03 安全等级执行 disable 子功能前需要安全解锁security level 0x01 支持子功能0x00 enable、0x01 disable 支持通信类型0x01 应用报文、0x03 网络管理报文 前置条件KL15 OFF 或 车速 5 km/h且无 BusOff 事件 控制效果0x28 01 03 生效后ECU 停止发送 NM 报文0x28 00 03 生效后恢复 NM 报文发送 退出扩展会话或重新上电后通信状态恢复为正常发送。这段需求虽然比较简短但已经包含了用例设计的五个关键要素条件会话、安全、车速、动作子功能、对象通信类型、效果报文行为、恢复路径会话切换、上下电。3.2 把需求拆成用例维度基于上面的需求描述可以拆出以下六个用例设计维度前置条件维度电源状态、诊断会话、安全解锁、车速、总线状态。请求参数维度子功能、通信类型、SPR 位、附加控制参数。响应维度正响应、负响应、抑制正响应。行为维度目标报文是否停止发送、停止后的总线状态、恢复时间。恢复维度enable 指令恢复、会话切换恢复、上下电恢复、ECU 复位恢复。异常维度非法参数、未解锁、会话不支持、重复执行、并发请求。每个需求点至少映射到一个维度每个维度至少对应一条用例。这样做的好处是需求评审时如果某个维度没有覆盖可以直接和系统工程师讨论把需求不明确的地方提前暴露出来。3.3 用参数矩阵压缩用例规模0x28 服务如果做全组合用例数会非常惊人。假设子功能有 2 个、通信类型有 5 个、会话有 2 种、安全状态有 2 种理论上就是 2×5×2×240 条再加上恢复路径和异常场景很容易超过 100 条。实际项目中不建议盲目做全组合而是使用“参数矩阵”来收敛。具体做法是先确认需求中是否存在明确的限制条件。例如需求写明了“只在扩展会话下支持 0x28”那么默认会话的用例只需要验证“返回 0x7F 或 0x7E”不需要把 5 种通信类型全部在默认会话下跑一遍。再比如如果安全解锁状态对所有子功能都有影响那么“未解锁”只需要挑 1~2 个典型通信类型验证 0x33再覆盖一个 SPR 位场景即可不需要所有通信类型都重复验证。通过这种“先找同质性再抽典型值”的方法可以把用例数量控制在可维护的范围内。4. 在 testbuddy 中组织 0x28 服务用例4.1 为什么使用测试管理平台在实际项目中几十条 0x28 用例如果只靠 Excel 管理会出现两个问题一是需求变更后很难同步更新用例二是执行结果、失败截图、问题单关联不直观。使用 testbuddy、QMetry、禅道这类测试管理平台可以有效解决用例资产沉淀和追溯问题。testbuddy 是近几年在测试团队中比较常用的一款用例管理平台支持测试计划、用例编写、执行记录、缺陷跟踪等功能。对于 0x28 服务这种参数组合较多的诊断服务可以在平台中为每个服务建一个测试套件再按功能场景分子模块而不是把所有用例平铺在一层目录里。4.2 用例字段模板在 testbuddy 中设计 0x28 服务用例时建议至少包含以下字段字段名示例值说明用例编号TC_0x28_NM_001按服务、场景、序号组织需求 IDREQ_0x28_001关联需求条目用例名称03 子功能为 0x01 时禁用 NM 报文描述核心验证点前置条件扩展会话、安全解锁、KL15 OFF描述环境条件测试步骤1. 打开 CANoe2. 进入扩展会话3. 发送 28 01 03可执行的操作序列输入数据SubFunction0x01, CommunicationType0x03请求参数预期结果ECU 不再发送 NM 报文正响应 0x68 0x01可判定的结果优先级P1 / P2 / P3决定回归顺序执行状态Pass / Fail / Blocked平台内置字段备注关注 BusOff 场景补充说明通过这些字段测试工程师可以在平台上快速筛选出“P1 且未执行”的用例安排回归计划。4.3 用例生成与评审流程在 testbuddy 中生成 0x28 用例可以分三步第一步由测试工程师根据需求文档和参数矩阵在测试套件中按照“正常场景、异常场景、恢复场景、关联场景”四个分组填写用例。不要一次性写完先把每条用例的核心步骤和预期结果写粗再逐条细化。第二步利用参数组合思路做批量生成。这里所谓的“生成”并不是完全自动生成而是把子功能、通信类型、会话状态、安全状态做成枚举再根据需求约束筛选出有效组合。可以用 Excel 或脚本先跑出一份组合清单再导入 testbuddy 形成候选用例。第三步组织用例评审。评审时重点检查三个方面是否覆盖所有需求点、前置条件是否可满足、预期结果是否可判定。评审通过后将用例状态置为 Approved再进入执行阶段。5. 0x28 服务典型用例设计实战5.1 基础请求响应用例基础请求响应用例主要验证“请求能发、响应能回、参数正确”。这部分用例适合放在冒烟测试中用来快速判断环境是否正常。用例编号用例名称测试步骤输入数据预期结果TC_0x28_BASIC_001发送 enable NM 请求验证正响应进入扩展会话发送 28 00 03SF0x00, CommType0x03正响应 68 00BUS 上 NM 报文恢复TC_0x28_BASIC_002发送 disable NM 请求验证正响应进入扩展会话发送 28 01 03SF0x01, CommType0x03正响应 68 01NM 报文停止TC_0x28_BASIC_003发送非法长度请求进入扩展会话发送 28 01SF0x01, 缺少 CommType负响应 7F 28 13TC_0x28_BASIC_004发送不支持的子功能进入扩展会话发送 28 05 01SF0x05负响应 7F 28 12TC_0x28_BASIC_005发送不支持的通信类型进入扩展会话发送 28 01 08CommType0x08负响应 7F 28 31注意用例中的具体 NRC 以 ECU 实际实现为准。如果需求文档没有明确说明最好先在实车上用诊断仪确认一次再把确认结果固化到用例中。5.2 通信控制行为用例通信控制行为用例是 0x28 服务的核心重点是验证 ECU 的对外通信行为是否真的发生了变化。用例编号用例名称测试步骤预期结果TC_0x28_BEH_001disable 应用报文后周期应用报文停止记录正常周期报文发送 28 01 01观察 2s 以上周期应用报文停止NM 报文不受影响TC_0x28_BEH_002enable 应用报文后周期应用报文恢复先 disable再发送 28 00 01周期应用报文恢复发送TC_0x28_BEH_003disable NM 报文后总线静默发送 28 01 03观察总线ECU 不再发送 NM 报文其他节点 NM 不受影响TC_0x28_BEH_004enable NM 报文后总线恢复正常先 disable再发送 28 00 03NM 报文恢复发送TC_0x28_BEH_005通信类型为 0x07 时禁用全部通信发送 28 01 07观察总线应用报文和 NM 报文均停止TC_0x28_BEH_006disable 后重复发送相同 disable 请求连续发送 28 01 03 两次第二次仍返回正响应状态不改变这里的验证手段建议用 CANoe 的统计窗口或 CAPL 脚本统计特定 ID 的报文数量。例如发送 disable 请求前记录 5 秒内 NM 报文数量发送后同样记录 5 秒如果从原来的几十帧降为 0才说明通信控制生效。5.3 会话切换与恢复场景0x28 服务的“临时性”决定了恢复路径非常重要。很多测试只测到 disable 成功就结束结果车辆下线后在售后被诊断仪误操作 disable 之后无法恢复问题就严重了。用例编号用例名称测试步骤预期结果TC_0x28_RST_001disable 后切换会话通信恢复扩展会话 disable NM切到默认会话观察总线NM 报文自动恢复TC_0x28_RST_002disable 后 ECU 复位通信恢复扩展会话 disable NM发送 11 01 ECUReset观察总线复位后 NM 报文恢复TC_0x28_RST_003disable 后整车上电下电通信恢复扩展会话 disable NM断开电源重新上电观察总线上电后 NM 报文恢复TC_0x28_RST_004enable 请求恢复扩展会话 disable NM发送 28 00 03NM 报文立即恢复TC_0x28_RST_005多次会话切换后状态一致性反复切换会话每次切断电验证通信状态始终符合预期不出现永久禁用恢复场景的设计原则是需求文档写了几条恢复路径至少要覆盖几条如果需求没有写必须找系统工程师确认否则这条用例是不完整的。5.4 异常与容错场景异常场景主要验证 ECU 在面对非法输入、未授权操作、总线异常时能够正确拒绝动作并且不影响自身稳定性。用例编号用例名称测试步骤预期结果TC_0x28_ERR_001默认会话下发送 disable 请求默认会话发送 28 01 03负响应 7F 28 7F 或 7F 28 7ETC_0x28_ERR_002未解锁时发送 disable 请求扩展会话但不执行 0x27发送 28 01 03负响应 7F 28 33TC_0x28_ERR_003发送带 SPR 位的 enable 请求扩展会话发送 28 80 03无正响应NM 报文恢复TC_0x28_ERR_004功能寻址发送 disable 请求通过 0x7DF 功能寻址发送 28 01 03所有节点不回复正响应但执行禁用TC_0x28_ERR_005总线 BusOff 后发送请求人为制造 BusOff恢复后发送 28 00 03通信恢复无异常 NRCTC_0x28_ERR_006通信类型 0x00 越界扩展会话发送 28 01 00负响应 7F 28 31带 SPR 位的场景容易被忽略但它经常用在“多个 ECU 同时执行同一个动作且不希望总线被正响应刷屏”的场景中。测试时要注意SPR 位只是抑制正响应不影响请求合法性的校验。5.5 关联场景网络管理、DTC 与休眠唤醒0x28 服务的威力在于它与整车网络行为的联动。设计用例时不能只盯着诊断仪那一侧。比如 disable NM 报文后如果该 ECU 是网络管理的主节点其他节点可能因为收不到 NM 而进入网络休眠流程如果该 ECU 是应用报文的重要数据源某些依赖该报文的功能控制器可能会报 DTC。因此在项目测试中还要增加以下关联用例0x28 disable NM 后观察整车网络是否可以在规定时间内进入休眠。0x28 disable 应用报文后确认目标 ECU 是否记录通信类 DTC。0x28 enable 后确认 DTC 是否从当前状态清除或变为历史故障。0x28 disable 应用报文期间执行 0x22 读取数据标识确认诊断链路仍然可用。0x28 disable 报文后通过 0x27 安全访问、0x2E 写入数据等操作验证诊断链路不受影响。这些关联用例不需要每条都做全组合而是选择项目中最关键的网络状态和 DTC 策略进行验证。一旦发现 0x28 动作影响了其他功能优先拉通网络工程师和软件工程师确认行为是否符合设计预期。6. 测试环境搭建与执行步骤6.1 测试环境组成0x28 服务测试的环境通常由以下几部分组成被测 ECU需要支持 0x28 服务的控制器。总线接口设备如 CANoe、VN1610、PCAN 等用于发送诊断请求和采集总线报文。总线仿真环境部分测试需要使用剩余总线仿真模拟其他节点周期发送报文。电源设备可控电源用于模拟 KL15 ON/OFF、上下电场景。诊断分析工具CANoe、CANalyzer、DIVA、或自研 Python 脚本均可。环境搭建时有一个细节要特别注意0x28 服务测试需要同时监控多个信号维度。除了诊断响应之外还要记录被测 ECU 的应用报文、网络管理报文、整车其他节点的响应情况才能完整判断测试结果。因此建议在 CANoe 工程中预先配置好待测报文的 DBC 文件并为关键报文建立统计窗口。6.2 用 CANoe/CAPL 发送 0x28 请求在 CANoe 中可以通过 CAPL 程序向总线上发送 0x28 请求。下面这个示例演示了如何向 CAN1 通道发送“禁用网络管理报文”的请求/* 文件路径TestNode.can */ on key d { message 0x7E0 msg; msg.byte(0) 0x03; // PCI单帧Payload 长度为 3 msg.byte(1) 0x28; // SIDCommunicationControl msg.byte(2) 0x01; // Sub-functionDisable msg.byte(3) 0x03; // Communication TypeNetwork Management msg.dlc 4; msg.can 1; // 指定发送通道多通道工程需要配置 write(Send 0x28 disable NM); output(msg); } on key e { message 0x7E0 msg; msg.byte(0) 0x03; msg.byte(1) 0x28; msg.byte(2) 0x00; // Sub-functionEnable msg.byte(3) 0x03; msg.dlc 4; msg.can 1; write(Send 0x28 enable NM); output(msg); }这个示例使用的是直接发送 CAN 报文的方式。严格来说完整项目中的诊断请求通常通过诊断层函数或诊断数据库生成但直接构造 ISO-TP 单帧报文可以帮你快速验证 ECU 的响应逻辑也便于初学者理解报文结构。如果你使用的是 CAN FD 或者报文包含地址扩展代码需要按实际通信矩阵调整。示例中0x7E0是常见的物理请求 CAN ID实际项目以通信矩阵为准。6.3 用 Python 脚本快速验证在部分自动化测试环境中团队更倾向于使用 Python 配合 python-can 库发送诊断请求。下面是一个最小可运行的示例# 文件路径send_0x28.py import can def send_0x28(bus, sub_function: int, comm_type: int): # 构造 0x28 请求28 子功能 通信类型 payload [0x03, 0x28, sub_function, comm_type] msg can.Message( arbitration_id0x7E0, datapayload, is_extended_idFalse, dlc4 ) bus.send(msg) print(fSent: 28 {sub_function:02X} {comm_type:02X}) if __name__ __main__: bus can.interface.Bus(channelcan0, interfacesocketcan) # 禁用网络管理报文 send_0x28(bus, sub_function0x01, comm_type0x03)需要说明的是这个示例没有实现 ISO-TP 的分包与流控只适用于单帧请求。若你的诊断请求字节数超过 7 字节或者使用了功能寻址建议使用 python-can-isotp 库或成熟诊断工具封装。6.4 执行与判定流程一条 0x28 服务用例的完整执行流程通常如下打开 CANoe 工程加载 DBC、诊断数据库和测试脚本。给 ECU 上电进入正常通信状态确认总线无异常故障帧。执行 0x10 03 进入扩展诊断会话。如果需求要求安全解锁通过 0x27 服务完成解锁。记录当前总线基线例如 NM 报文周期和 ID 列表。发送 0x28 请求等待 ECU 处理。采集 3~5 秒总线报文对比目标报文是否停止或恢复。记录诊断响应、NRC、总线报文变化填入 testbuddy 用例执行结果。如果用例失败截图保存现场报文创建缺陷并关联到对应需求。判定结果时不能只看“正响应是否返回”。0x28 的正响应只代表 ECU 接收并执行了命令不代表通信行为一定符合预期。必须把“目标报文是否被抑制”“其他报文是否受影响”“恢复路径是否有效”作为整体判定依据。7. 常见问题与排查思路问题现象常见原因解决思路发送 28 01 03 后 ECU 仍然