前阵子我拿到一条需求ECU在刷写过程中需要禁止应用报文要求用 UDS 0x28 服务实现。乍看很简单发送28 03 01让 ECU 停止发送应用报文完事。但真正走到用例设计这一步时我发现自己要回答的问题远比这三字节请求多得多。在哪个会话下执行要不要安全解锁是只禁止发送还是收发都禁止恢复方式是什么断电重启后是什么状态哪些报文算“应用报文”把这些问题都写进测试用例0x28 服务就从一个三字节请求长成了一张覆盖正常、异常、边界、恢复和关联场景的测试网。这篇文章就围绕 0x28 服务聊聊怎么从一条模糊的原始需求设计出可落地、可复用、不会漏场景的用例。1. 先别急着发报文0x28 服务控制的是“通信行为”1.1 请求、响应和三个核心要素0x28 服务在 ISO 14229 里的正式名称是 CommunicationControl中文可以叫通信控制服务。它和 0x10 会话控制、0x27 安全访问这类“改变 ECU 状态”的服务不太一样0x28 的核心动作是让 ECU 在某个时间段内停止或恢复指定类型报文的接收和发送。请求格式很固定总共 3 个字节0x28 Sub-function CommunicationType第一个字节是服务 ID固定 0x28。第二个字节是子功能也就是控制类型。第三个字节是通信类型也就是控制哪类报文。先看子功能。ISO 14229 里常用的有四个子功能含义作用0x00enableRxAndTx恢复该类型报文的接收和发送0x01enableRxAndDisableTx允许接收但禁止发送0x02disableRxAndEnableTx禁止接收但允许发送0x03disableRxAndTx禁止该类型报文的接收和发送再看通信类型通信类型含义0x01应用报文Application Messages0x02网络管理报文Network Management Messages0x03应用报文和网络管理报文都控制0x04诊断报文部分实现需以规范为准肯定响应的格式是0x68 Sub-function只回子功能不回通信类型。例如请求28 03 01成功响应就是68 03。如果请求失败ECU 返回否定响应格式是7F 28 NRC。后面会专门讲 NRC 排查。这里有一个很容易被误解的地方0x28 名字叫“通信控制”但多数场景下它控制的不是诊断通信本身而是 ECU 对外发送的应用报文和网络管理报文。诊断服务请求还是会走诊断通道诊断报文本身不一定被禁用。所以“禁止通信”不等于“ECU 失联”。1.2 为什么这个服务看起来简单却经常出事0x28 服务是 UDS 里少见的“破坏性很强”的控制类服务。一旦发错子功能或者通信类型轻则总线上看不到该 ECU 的报文重则 ECU 直接不再响应诊断请求只能断电重启恢复。我在实际项目里见过几种典型问题第一测试者把28 03 03直接发出去结果应用报文和网络管理报文全没了。这个请求本身是合法的但如果没有预判恢复机制测试会卡在“ECU 不响应”这一步。尤其是整车级测试网络管理报文被停掉其他节点可能会因为收不到网络管理 PDU 而进入异常状态。第二部分 ECU 对 0x28 服务有会话要求和安全要求。比如规范里要求必须在扩展会话或者编程会话下执行默认会话直接发会收到 NRC 0x22。如果需求文档没有写明测试人员看到 NRC 0x22 会误以为 ECU 有问题。第三0x28 的通信类型定义在不同项目里有差异。有的 ECU 把“应用报文”定义为所有非网络管理报文有的 ECU 则只包含应用层周期报文。设计用例之前不确认 DBC 和诊断规范预期结果就是拍脑袋。所以说0x28 本身不复杂复杂的是它和其他条件之间的约束关系会话、安全、网络管理状态、DBC 信号定义、恢复机制。这些约束没理清用例设计就是一张没打准的靶子。2. 从需求到用例先做需求拆解再谈设计2.1 一条需求原文能拆出多少信息假设需求文档里只有一句话刷写过程中ECU 需要禁止应用报文的发送。这句话看起来已经说清楚了但对用例设计来说信息远远不够。它没有回答下面这些关键问题ECU 在什么时候进入“禁止发送”状态是收到 0x10 02编程会话之后自动进入还是收到 0x28 请求之后进入是只禁止发送还是接收和发送都禁止应用报文的范围是什么是所有应用 PDU还是特定周期报文网络管理报文要不要禁恢复方式是什么是 0x28 00 01还是断电重启这个服务在默认会话下能否执行是否需要安全解锁这些不是空想出来的问题而是每次设计 0x28 用例前必须和需求提出方对齐的信息。测试用例如果只写“发 0x28验证报文消失”那这条用例大概率会在真实执行时因为前置条件不满足而失败。2.2 用“五要素”把需求补完整我自己在做需求拆解时会把一条 0x28 需求拆成五个要素对象、动作、时机、恢复、边界。对象控制哪类报文。是应用报文、网络管理报文还是两者都控制如果 DBC 里有多个报文组还要清楚哪些 CAN ID 属于这个范围。动作是禁止发送、禁止接收、禁止收发还是恢复在 0x28 服务里对应 0x00 到 0x03 哪个子功能。时机什么时候触发有的场景是 ECU 收到 0x28 请求后立即生效有的场景是 ECU 进入编程会话后自动进入特定通信模式0x28 只是辅助。恢复如何退出禁止状态常见的有三种发送 0x28 00 01 或 0x28 00 03 主动恢复ECU 重新上电后自动恢复到默认通信状态切换到其他会话时自动恢复。边界如果 ECU 处于禁止状态时收到了其他诊断请求应该怎么响应如果请求参数非法会返回哪个 NRC如果反复发送相同的 0x28 请求ECU 行为是否稳定这个“五要素”拆解方法不只适用于 0x28也可以用在 0x85 控制 DTC 设置、0x11 复位、0x10 会话切换等控制类服务上。它的本质是把一句话需求翻译成可验证的技术条件。2.3 需求模糊时怎么确认如果需求确实没有写清楚我一般按三条路径去确认第一看诊断规范草案。ECU 的诊断规范里通常会有 0x28 服务的详细定义包括子功能范围、通信类型范围、会话要求、安全等级和否定响应码。这是最权威的依据。第二看 DBC 和网络管理规范。应用报文和网络管理报文的 DBC 分类决定了28 03 01会停掉哪些报文而不会停掉哪些报文。特别注意有些 ECU 会把自己的网络管理报文归到 0x02 类型有些则归到 0x01 类型这个必须以 ECU 实现为准。第三向上位机或基础软件工程师确认。如果规范文档缺失就只能通过实际请求确认。但这里要非常谨慎因为 0x28 一旦发错ECU 可能失联所以建议先确认恢复手段再动请求。需求拆解阶段多花十分钟后面用例设计阶段就能少改十次。3. 用例设计的核心方法先覆盖矩阵再补异常路径3.1 用例矩阵怎么搭0x28 服务用例最大的风险不是单个用例写错而是组合覆盖不全。子功能有 4 个通信类型有 4 个再加上会话、安全、ECU 行为差异组合数量会快速膨胀。一种可行的方法是先用“子功能 × 通信类型”搭正向矩阵再叠加上下文条件最后筛选出有效组合。子功能通信类型 0x01通信类型 0x02通信类型 0x030x00 使能接收和发送常用常用常用0x01 使能接收、禁止发送可选可选可选0x02 禁止接收、使能发送可选可选可选0x03 禁止接收和发送常用常用常用这里要注意不是每个子功能和通信类型的组合都会被实际使用。例如刷写场景中通常只关心28 03 01禁止应用报文收发和28 00 01恢复应用报文这两个组合。设计用例时先根据需求筛选有效组合再补异常组合而不是把所有组合都无差别覆盖一遍。3.2 正常流程用例设计正常流程用例的出发点是“需求要的正确路径”。我的建议是最少覆盖下面这几类扩展会话下禁止应用报文前置条件是 ECU 已进入扩展会话必要时完成安全解锁。发送28 03 01预期响应68 03然后监控总线确认该 ECU 的应用报文不再出现。恢复应用报文在上一用例基础上发送28 00 01预期响应68 00并确认应用报文重新出现。禁止网络管理报文发送28 03 02确认网络管理报文停止。这个用例要特别关注后续网络管理状态是否异常。恢复网络管理报文发送28 00 02确认网络管理报文恢复。同时控制应用报文和网络管理报文发送28 03 03确认两类报文都停止再发送28 00 03确认都恢复。每条用例最好都记录两个时间点禁用生效时间和恢复生效时间。有些 ECU 不是立即生效而是有一个短暂的延迟这个也要写进预期结果。3.3 异常和边界用例设计异常用例的价值在于确认 ECU 对非法输入和异常状态的处理是符合规范的。0x28 服务常见的异常场景包括发送不支持的子功能例如28 04 01预期返回 NRC 0x12。发送非法的通信类型例如28 03 00或28 03 05预期返回 NRC 0x31。请求长度错误例如只发送28 03缺少通信类型字节预期返回 NRC 0x13。在默认会话下发送28 03 01如果规范要求扩展会话或编程会话预期返回 NRC 0x22。未解锁时发送28 03 01如果规范要求安全访问预期返回 NRC 0x33。重复发送相同的 0x28 请求确认 ECU 不会因为重复请求而行为异常。发送28 03 01后紧接发送28 00 01确认快速恢复路径可用。边界用例里还有一个容易被忽略的场景ECU 在禁止应用报文的状态下诊断服务请求是否仍然被正常处理。如果 0x28 只控制应用报文那么诊断仪发送 0x22 读取数据应该能正常响应如果连诊断报文也被一并禁止了那就属于高风险场景用例设计时必须注明恢复手段。3.4 用例优先级怎么定不是所有用例都要在同一轮测试里跑完。我的习惯是分三个优先级P0影响刷写流程、可能导致 ECU 失联、涉及安全姿态的用例。例如28 03 03同时禁用应用报文和网络管理报文恢复用例也必须放在 P0。P1常规功能验证和恢复验证例如28 03 01和28 00 01的基本路径。P2参数边界、非法请求、重复请求等异常路径可以在回归测试阶段覆盖。这样安排的好处是在工期紧张时可以先跑 P0确保最危险、最核心的路径没有问题剩余用例再按回归批次补齐。4. 一个可以直接参考的 0x28 用例集合4.1 从测试工程师视角写的用例清单下面这些用例是我在新项目里会首轮补充的 0x28 用例你可以根据自己项目的需求和 ECU 实现做删减。用例编号测试目的前置条件测试步骤预期结果TC_0x28_001扩展会话下禁止应用报文ECU 上电进入扩展会话按需安全解锁1. 发送28 03 012. 等待 500ms3. 监控总线应用报文4. 发送28 00 01响应68 03应用报文消失恢复后应用报文重新出现TC_0x28_002禁止网络管理报文ECU 上电进入扩展会话按需安全解锁1. 发送28 03 022. 等待 500ms3. 监控网络管理报文4. 发送28 00 02响应68 03网络管理报文停止恢复后网络管理报文重新出现TC_0x28_003同时禁止应用报文和网络管理报文ECU 上电进入扩展会话按需安全解锁1. 发送28 03 032. 等待 500ms3. 监控总线4. 发送28 00 03响应68 03应用报文和网络管理报文都停止恢复后两类报文都重新出现TC_0x28_004不支持的子功能ECU 上电进入扩展会话1. 发送28 04 01响应7F 28 12TC_0x28_005非法的通信类型ECU 上电进入扩展会话1. 发送28 03 00响应7F 28 31TC_0x28_006默认会话下发送 0x28ECU 上电处于默认会话未解锁1. 发送28 03 01若规范要求扩展会话则响应7F 28 22TC_0x28_007未解锁时发送 0x28ECU 进入扩展会话但未执行安全解锁1. 发送28 03 01若规范要求安全访问则响应7F 28 33TC_0x28_008禁止应用报文期间诊断请求仍可用ECU 上电进入扩展会话应用报文处于禁止状态1. 发送28 03 012. 发送22 F1 90读取数据28 03 01响应68 0322 F1 90正常响应证明诊断通道未被禁止这张表是我在实际项目中最常用的最小集合。它的设计思路是先保证正常路径完整再覆盖最关键的异常 NRC最后验证禁用状态下的诊断可用性。你也可以在这张表的基础上把更多组合和边界场景加进去。4.2 执行时的通用步骤0x28 用例的执行虽然简单但因为影响面大我建议每次执行时都按这个顺序走一遍连接准备确认上位机工具、CAN 通道、DBC 文件加载正确CAN ID 和寻址方式物理寻址/功能寻址匹配。记录基线在发送 0x28 请求之前先记录目标 ECU 在总线上正常发出的所有报文 ID、类型和周期。没有基线后面判断“报文是否消失”就没有依据。发送请求用诊断工具发送 0x28 请求确认 ECU 响应。验证效果在 Trace 窗口中对应用报文和网络管理报文做过滤确认禁用生效。恢复发送恢复子功能重新记录总线报文和基线对比确认恢复。在写脚本或工具命令时常见发送方式有两种。一种是直接用 Python 的 python-can 库import can bus can.interface.Bus(channelcan0, bustypesocketcan, bitrate500000) # 请求: 0x28服务, 子功能0x03(禁用接收和发送), 通信类型0x01(应用报文) req [0x28, 0x03, 0x01] send_id 0x7E0 # 根据项目实际填写 resp_id 0x7E8 # 根据项目实际填写 msg can.Message(arbitration_idsend_id, datareq, is_extended_idFalse) bus.send(msg)另一种是 CANoe 的 CAPL 脚本// 0x28服务请求示例 txMsg.id 0x7E0; txMsg.dlc 3; txMsg.byte(0) 0x28; txMsg.byte(1) 0x03; txMsg.byte(2) 0x01; output(txMsg);注意0x28 的 DLC 是 3不要多也不要不。请求里的 CAN ID 要根据 ECU 的物理寻址请求 ID 来填不同项目差异很大。4.3 用例里最容易被漏掉的三个场景第一断电重启后的默认状态。很多 ECU 在重新上电后会退出所有禁止状态但这不是必然的。如果规范里定义了“禁止状态持续到下一次上电”那用例就要增加“禁止后重启验证应用报文仍处于禁止状态”或“禁止后重启应用报文恢复”取决于实际需求。第二禁用期间诊断请求的响应。0x28 禁止的是应用报文或网络管理报文诊断报文通常不受影响。部分 ECU 实现可能会误把诊断响应也停掉导致测试过程中无法继续发送恢复请求。用例里必须明确验证禁用期间诊断服务仍然可用或者明确记录这是一个高风险行为。第三多个 ECU 之间的连锁影响。如果整车测试中某个 ECU 的 0x28 请求影响了网络管理报文其他节点可能因为超时进入异常状态。用例预期结果不能只写“目标 ECU 无报文”还要关联验证相邻节点是否受影响。5. 实际执行时的问题排查链路0x28 用例执行过程中最容易出现四种现象我按排查链路整理一下。5.1 现象ECU 对 0x28 请求无响应先看请求报文有没有发出去。检查 CAN ID、通道、寻址方式是否匹配。再确认 ECU 是否处于能处理诊断请求的状态。如果 ECU 已经因为之前的 0x28 请求进入禁止接收状态那它对新的请求可能没有响应。此时需要确认 ECU 是否支持恢复路径必要时断电重启。然后检查会话状态和安全状态。0x28 很多实现要求扩展会话或编程会话且部分子功能需要安全解锁。如果 ECU 当前在默认会话请求会被忽略或返回否定响应。最后看总线上是否有错误帧排除 CAN 物理层问题。5.2 现象响应了 NRC但和预期不一致0x28 相关的 NRC 排查可以按下面的速查表来定位NRC含义常见的触发原因0x12子功能不支持子功能超出 ECU 支持范围0x13报文长度或格式错误缺少通信类型字节或 DLC 不正确0x22条件不满足当前会话不是扩展/编程会话0x31请求超出范围通信类型非法或子功能与通信类型组合不被支持0x33安全访问被拒绝未解锁或解锁后重试失败如果收到的是 0x22 或 0x33先检查前置条件不要急着改请求参数。很多时候不是请求写错了而是会话和安全状态不符合规范。5.3 现象禁用后应用报文还在发先确认通信类型有没有写错。28 03 01只停应用报文28 03 02只停网络管理报文28 03 03才停两者。如果需求要求停应用报文但发成了28 03 02报文当然还在。再确认目标 ECU 是谁。如果总线上有多个 ECUTrace 里看到的报文可能是别的节点发的不一定属于当前正在测试的 ECU。在 DBC 里按源节点过滤一下。然后确认报文类型归类。有些项目把周期报文、事件报文、诊断报文都归到应用报文里如果 DBC 的分类和规范不一致就会出现“明明已经禁用但某些报文仍然在发”的情况。最后确认 ECU 是否支持该通信类型。部分 ECU 对 0x01 和 0x02 的处理存在差异甚至不支持某个组合请求虽然返回了肯定响应但实际行为没有变化。这种情况要回到 ECU 实现文档去确认。5.4 现象恢复后报文没有回来先检查恢复请求的子功能。恢复应用报文通常是28 00 01恢复网络管理报文是28 00 02恢复两者是28 00 03。发错通信类型会恢复无效。再检查 ECU 是否需要重新进入特定会话。部分 ECU 在恢复时要求当前会话仍然是扩展会话或编程会话如果已经切回默认会话可能无法通过诊断请求恢复此时需要断电重启。最后检查 ECU 是否在超时后自动恢复。有些 ECU 实现了定时恢复机制超过一定时间后自动恢复应用报文发送也有 ECU 不会自动恢复。规范里如果没有写明可以在测试记录里备注“恢复依赖诊断请求”或“恢复依赖上电”。6. 把 0x28 用例设计沉淀成一套可复用方法6.1 每次新项目先回答五个问题0x28 服务在不同项目里的行为差异比想象中大得多。为了避免在新项目上沿用旧用例我每次都会先问自己五个问题第一这个 ECU 的 0x28 服务在哪些场景会被触发常见的是刷写、下线检测、运输模式、网络管理测试。第二实际使用的是哪些子功能多数项目只用到 0x00 和 0x03个别项目会用 0x01 或 0x02。第三通信类型是单独控制还是组合控制如果某个 ECU 把 0x01 和 0x02 合并处理那用例设计应该围绕组合行为来写而不是分开写两条独立用例。第四是否涉及会话和安全解锁这会直接决定前置条件也决定哪些用例属于 P0。第五ECU 失联后怎么恢复这个问题必须在执行任意一条高风险用例之前回答否则用例本身就不具备可执行性。6.2 用例模板的长期维护0x28 用例不应该是一锤子买卖。每次项目做完我会把新增的用例和踩过的坑收录到通用用例库里按几个维度归类功能用例覆盖子功能和通信类型的基本行为参数用例覆盖非法子功能、非法通信类型、长度错误异常用例覆盖会话不满足、安全不满足、重复请求恢复用例覆盖主动恢复、断电重启恢复、自动恢复。当新项目拿到需求时先按“五要素”拆解再从用例库里筛选出可复用部分最后补充项目特有的边界场景。这样既不会漏覆盖也不会每次从零开始。6.3 回到开头那个判断0x28 服务本身的代码量很小真正困难的地方在于需求如何被翻译成约束清晰、覆盖完整、边界明确的测试用例。很多人觉得 0x28 简单是因为只看到了三个字节的请求但一个成熟的测试工程师会先把会话、安全、通信类型、报文分类、恢复机制和关联影响全部理清楚再让手指按下发送键。下次再有人对你说“0x28 很简单”时你可以先问一句那失联之后怎么恢复很多时候答案并不简单。