UDS 0x28通信控制服务测试用例设计：从协议规范到CANoe自动化验证

在汽车电子网络诊断项目里，很多刚接触 UDS 测试的同学，第一眼看到 0x28 服务时都会觉得它很简单：不就是一个“控制 ECU 通信开关”的服务吗？但当需求文档里写着“在特定条件下临时屏蔽网络管理报文，同时保留诊断链路可用”，还要求考虑会话切换、安全解锁、上下电恢复路径时，用例设计的复杂度一下子就上来了。

本文围绕 0x28 CommunicationControl 服务，从协议报文格式讲起，结合实际需求文档给出测试用例设计思路，并附上可执行的 CAPL 脚本、Python 验证脚本以及基于 testbuddy 等平台的用例组织方法。无论你是刚进入诊断测试领域的新手，还是正在做网络诊断测试开发的工程师，都可以把这篇文章当作一份 0x28 服务用例设计的参考模板。

1. 背景与核心概念

1.1 什么是 0x28 服务

在整车电子电气架构中，ECU（电子控制单元）之间通过 CAN、CAN FD、LIN、FlexRay 等总线通信。为了让诊断仪、产线设备、售后设备能够和 ECU 对话，行业里广泛采用 UDS（Unified Diagnostic Services，统一诊断服务）协议。UDS 定义在 ISO 14229 标准中，是汽车诊断领域最基础的应用层协议之一。

0x28 服务，标准名称是 CommunicationControl，中文可以翻译为“通信控制服务”。它允许外部诊断仪向一个或者多个 ECU 发送控制指令，使 ECU 临时性地启用、禁用指定类型的通信报文。这里说的“通信报文”不是诊断请求本身，而是指 ECU 在正常运行过程中对外发送的应用报文、网络管理报文等周期性或者事件型报文。

例如，当整车进入某种静默模式时，控制器可以通过 0x28 服务暂时停止发送网络管理报文，从而让总线进入待机状态；当产线需要刷写某一个节点时，也可以通过 0x28 服务把其他节点的总线报文抑制掉，避免干扰。

1.2 0x28 服务解决什么问题

从功能边界来看，0x28 服务解决的核心问题是“在不改变 ECU 软件逻辑的前提下，临时控制 ECU 的对外通信行为”。

在实际项目中，它常常被用于以下几类场景：

• 静默模式控制：当整车下电或者进入某些低功耗状态时，通过 0x28 服务禁用网络管理报文，让总线负载降下来，帮助网络快速休眠。
• 产线 EOL（End 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 服务的请求报文格式如下：

这里先剥掉 ISO-TP 传输层，只看应用层 payload。举例来说，如果要发送“禁用网络管理报文”，通常请求为28 01 03。其中：

• 28是服务 ID。
• 01表示子功能为 disable（禁用通信）。
• 03表示通信类型为网络管理报文。

对应的正响应一般是一帧68 01，第一个字节是 SID + 0x40，即 0x68，第二个字节回显子功能 0x01。如果请求失败，ECU 会返回负响应，格式为7F 28 NRC，其中7F表示负响应，28是服务 ID，NRC是具体的否定响应码。

常用子功能值如下：

这里要特别提一下 SPR 位（Suppress Positive Response，抑制正响应位）。0x28 服务属于带子功能的服务，因此第 7 位可以作为 SPR 位。当发送的子功能最高位为 1 时，例如0x81，表示“抑制正响应”，也就是说，ECU 如果处理成功，只执行动作，不再回复正响应；如果处理失败，仍然需要回复负响应。这个细节在用例设计时非常容易遗漏。

2.2 通信类型参数

通信类型参数用于告诉 ECU“你要控制的是哪一类报文”。常见定义如下：

需要注意，上表中的数值是通用做法，不同 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 对应的用例策略完全不同。比如 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×2=40 条；再加上恢复路径和异常场景，很容易超过 100 条。

实际项目中不建议盲目做全组合，而是使用“参数矩阵”来收敛。具体做法是：先确认需求中是否存在明确的限制条件。例如需求写明了“只在扩展会话下支持 0x28”，那么默认会话的用例只需要验证“返回 0x7F 或 0x7E”，不需要把 5 种通信类型全部在默认会话下跑一遍。

再比如，如果安全解锁状态对所有子功能都有影响，那么“未解锁”只需要挑 1~2 个典型通信类型验证 0x33，再覆盖一个 SPR 位场景即可，不需要所有通信类型都重复验证。通过这种“先找同质性，再抽典型值”的方法，可以把用例数量控制在可维护的范围内。

4. 在 testbuddy 中组织 0x28 服务用例

4.1 为什么使用测试管理平台

在实际项目中，几十条 0x28 用例如果只靠 Excel 管理，会出现两个问题：一是需求变更后很难同步更新用例；二是执行结果、失败截图、问题单关联不直观。使用 testbuddy、QMetry、禅道这类测试管理平台，可以有效解决用例资产沉淀和追溯问题。

testbuddy 是近几年在测试团队中比较常用的一款用例管理平台，支持测试计划、用例编写、执行记录、缺陷跟踪等功能。对于 0x28 服务这种参数组合较多的诊断服务，可以在平台中为每个服务建一个测试套件，再按功能场景分子模块，而不是把所有用例平铺在一层目录里。

4.2 用例字段模板

在 testbuddy 中设计 0x28 服务用例时，建议至少包含以下字段：

通过这些字段，测试工程师可以在平台上快速筛选出“P1 且未执行”的用例，安排回归计划。

4.3 用例生成与评审流程

在 testbuddy 中生成 0x28 用例，可以分三步：

第一步，由测试工程师根据需求文档和参数矩阵，在测试套件中按照“正常场景、异常场景、恢复场景、关联场景”四个分组填写用例。不要一次性写完，先把每条用例的核心步骤和预期结果写粗，再逐条细化。

第二步，利用参数组合思路做批量生成。这里所谓的“生成”并不是完全自动生成，而是把子功能、通信类型、会话状态、安全状态做成枚举，再根据需求约束筛选出有效组合。可以用 Excel 或脚本先跑出一份组合清单，再导入 testbuddy 形成候选用例。

第三步，组织用例评审。评审时重点检查三个方面：是否覆盖所有需求点、前置条件是否可满足、预期结果是否可判定。评审通过后，将用例状态置为 Approved，再进入执行阶段。

5. 0x28 服务典型用例设计实战

5.1 基础请求响应用例

基础请求响应用例主要验证“请求能发、响应能回、参数正确”。这部分用例适合放在冒烟测试中，用来快速判断环境是否正常。

注意：用例中的具体 NRC 以 ECU 实际实现为准。如果需求文档没有明确说明，最好先在实车上用诊断仪确认一次，再把确认结果固化到用例中。

5.2 通信控制行为用例

通信控制行为用例是 0x28 服务的核心，重点是验证 ECU 的对外通信行为是否真的发生了变化。

这里的验证手段，建议用 CANoe 的统计窗口或 CAPL 脚本统计特定 ID 的报文数量。例如发送 disable 请求前记录 5 秒内 NM 报文数量，发送后同样记录 5 秒，如果从原来的几十帧降为 0，才说明通信控制生效。

5.3 会话切换与恢复场景

0x28 服务的“临时性”决定了恢复路径非常重要。很多测试只测到 disable 成功就结束，结果车辆下线后在售后被诊断仪误操作 disable 之后无法恢复，问题就严重了。

恢复场景的设计原则是：需求文档写了几条恢复路径，至少要覆盖几条；如果需求没有写，必须找系统工程师确认，否则这条用例是不完整的。

5.4 异常与容错场景

异常场景主要验证 ECU 在面对非法输入、未授权操作、总线异常时，能够正确拒绝动作并且不影响自身稳定性。

带 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; // SID：CommunicationControl msg.byte(2) = 0x01; // Sub-function：Disable msg.byte(3) = 0x03; // Communication Type：Network 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-function：Enable 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_id=0x7E0, data=payload, is_extended_id=False, dlc=4 ) bus.send(msg) print(f"Sent: 28 {sub_function:02X} {comm_type:02X}") if __name__ == "__main__": bus = can.interface.Bus(channel="can0", interface="socketcan") # 禁用网络管理报文 send_0x28(bus, sub_function=0x01, comm_type=0x03)

需要说明的是，这个示例没有实现 ISO-TP 的分包与流控，只适用于单帧请求。若你的诊断请求字节数超过 7 字节，或者使用了功能寻址，建议使用 python-can-isotp 库或成熟诊断工具封装。

6.4 执行与判定流程

一条 0x28 服务用例的完整执行流程通常如下：

1. 打开 CANoe 工程，加载 DBC、诊断数据库和测试脚本。
2. 给 ECU 上电，进入正常通信状态，确认总线无异常故障帧。
3. 执行 0x10 03 进入扩展诊断会话。
4. 如果需求要求安全解锁，通过 0x27 服务完成解锁。
5. 记录当前总线基线，例如 NM 报文周期和 ID 列表。
6. 发送 0x28 请求，等待 ECU 处理。
7. 采集 3~5 秒总线报文，对比目标报文是否停止或恢复。
8. 记录诊断响应、NRC、总线报文变化，填入 testbuddy 用例执行结果。
9. 如果用例失败，截图保存现场报文，创建缺陷并关联到对应需求。

判定结果时，不能只看“正响应是否返回”。0x28 的正响应只代表 ECU 接收并执行了命令，不代表通信行为一定符合预期。必须把“目标报文是否被抑制”“其他报文是否受影响”“恢复路径是否有效”作为整体判定依据。

7. 常见问题与排查思路