0x28服务CommunicationControl是网络诊断里负责控制ECU通信状态的服务在刷写、下线检测、OTA升级和售后诊断场景中出现频率很高。做0x28服务的用例设计时最怕需求文档只写一句“刷写前禁止通信”然后就等测试交用例。这句话落到测试层包含子功能选择、通信类型位定义、会话条件、安全等级、响应是否可达、恢复机制、总线影响等多个维度只要漏掉一个用例评审时就会被挑战更麻烦的是台架上测过了却在实车暴露问题。这篇文章围绕0x28服务如何根据需求设计用例展开先讲清服务和需求的语义再按用例设计步骤、组合矩阵、工具辅助和排错链路逐层拆解。1. 先搞清楚0x28服务到底控制的是哪些报文1.1 三个常用子功能先把语义定死0x28服务的全名是CommunicationControl中文常叫通信控制服务。它接收两个字节参数子功能subfunction和通信类型communicationType。在量产项目里经常出现的子功能是这三个子功能常见语义典型用途0x00使能接收、禁止发送让ECU静默不主动发应用报文0x01使能接收、使能发送恢复通信结束0x28控制0x02禁止接收、使能发送忽略某类报文但还能正常响应诊断请求必须提醒一句不同OEM、不同协议版本对子功能0x02的语义定义可能存在差异。上表是项目里比较常见的理解设计用例前一定要翻开需求文档或ISO 14229-1把子功能的定义一个字一个字确认清楚。为什么说这叫“把语义定死”因为测试过程中很多争论都来自这里。我见过一条用例写“0x28禁止通信后ECU不应再响应任何诊断请求”这实际上把子功能、通信类型和服务本身的作用混在一起了。0x28控制的是ECU对外通信的发送和接收通路不是“不响应该诊断请求”这么简单。禁止发送后诊断请求能不能到达ECUECU还能不能处理诊断请求取决于通信类型是否覆盖诊断报文以及ECU软件对诊断报文的优先级定义。1.2 通信类型里的位定义决定用例矩阵的宽度0x28服务第二字节是通信类型常见实现中用位来表示控制范围位含义bit0应用报文application messagesbit1网络管理报文network management messagesbit2应用报文网络管理报文both真正写进用例时用0x01、0x02、0x03更常见。有些平台实现支持0xFF表示全部报文这要看诊断规范是否允许。通信类型位定义直接决定用例数量如果需求文档只允许0x02那用例矩阵里就不能出现0x01如果协议允许所有组合你至少要为每种通信类型分别在“合法”和“非法”两侧设计用例。这里有一个常见误判很多人把“禁止通信”理解成“ECU没电了”或者“ECU不再响应任何事情”于是设计用例时认为发送0x28之后ECU应该对任何操作都没有反应。真实情况复杂得多。0x28可能在禁止正常通信的同时依然接受诊断指令尤其在设计上会保留诊断报文通道的ECU里。判断依据永远来自需求文档和诊断规范不是来自直觉。2. 用例开写前先把需求拆成五个字段2.1 一段需求通常要拆出这些信息以一段常见需求为例“刷写过程中整车网络通讯复杂部分ECU会产生周期报文干扰刷写要求刷写前置步骤中先禁止目标ECU的应用报文发送刷写完成后恢复通信。”拆字段服务ID0x28子功能禁止发送通常是0x00或OEM自定义值通信类型应用报文通常是bit0会话条件刷写一般在扩展会话或编程会话下进行安全等级部分安全策略要求安全解锁后才能执行0x28部分只需要扩展会话只写“刷写前禁止通信”的需求描述是非常薄弱的。用例设计者拿到这种描述应该先整理一份需求问题清单再动笔写用例而不是直接套模板。2.2 主动找齐这五个问题的答案设计用例之前我通常会先确认执行0x28是否需要安全解锁未解锁时NRC是多少0x28执行的有效期是什么是重启后失效、跳会话后失效、下发0x01后恢复、还是定时自动恢复禁止通信期间ECU是否保留诊断响应通道禁止通信期间相关DTC状态是否变化恢复通信的方式是诊断指令、下电重启、还是总线唤醒这几个问题里第2个最容易踩坑。很多用例只写“下发0x28后ECU不再发报文”但没写“什么条件下恢复通信”。没有恢复条件测试脚本执行完就停留在禁止状态回归测试里会被反复质疑。实际项目里0x28的恢复条件往往和刷写流程强绑定。有些ECU设计成一旦进入默认会话0x28的禁止状态立即解除有些ECU则在任何会话下都保持直到收到恢复指令或下电。需求文档如果没有写一定要找系统工程师确认而不是自己猜一个默认值写入用例。注意需求没有写恢复条件时不要自己拍脑袋定一个“默认恢复”的逻辑。缺需求描述要先补需求用例阶段不应该承担需求决策。2.3 需求字段确认后做成一张需求解析表推荐把需求解析结果做成一张表既方便评审也方便后续用工具生成用例。需求点需求描述解析结论用例设计影响服务ID通信控制0x28服务级正反例子功能禁止发送0x00正向用例主路径通信类型应用报文bit00x01组合范围受限会话扩展会话0x03默认会话必须设计NRC用例安全需要解锁解锁后执行未解锁用例预期NRC 0x33我一般会在表里单独加一列“需求来源”记录来自哪份文档的哪一页。后续排查用例争议时这一列特别有用可以直接翻到原始需求而不是在群里反复讨论“当时到底是这么定的吗”。3. 以刷写前禁止通信为主线演示用例设计主流程3.1 从主路径开始不急着铺异常用例用例设计最容易犯的错是从异常用例开始写。异常用例当然重要但没有主路径用例做基线评审时大家讨论的基线就不存在。先有一条能完整走通的用例评审才能聚焦。以“刷写前禁止目标ECU应用报文发送完成后恢复”为例主路径用例大概这样用例编号前置条件步骤预期结果TC_CCT_001ECU上电进入扩展会话已解锁发送0x28 00 01收到正响应ECU的应用报文停止诊断报文可继续访问TC_CCT_002TC_CCT_001执行后等待2秒ECU保持静默应用报文不恢复TC_CCT_003TC_CCT_001执行后发送0x28 01 01收到正响应应用报文恢复发送TC_CCT_004TC_CCT_001执行后执行ECU下电再上电应用报文在满足上电条件后恢复这里的预期结果里“诊断报文可继续访问”这个判断取决于ECU设计。如果ECU设计为0x28禁止应用报文时不阻止诊断响应那正响应能收到如果设计为诊断报文也属于控制范围那正响应可能收不到。预期必须和需求文档一致不能直接从通用模板抄。注意预期结果里写“诊断报文可继续访问”之前先确认需求是否允许。很多测试脚本就是在这里卡死的0x28把诊断通路也禁了后面所有诊断步骤集体超时。3.2 主路径跑通后再扩展条件主路径用例跑通后再按条件维度扩展。子功能维度在上面的基础上增加0x02禁止接收、使能发送用例。通信类型维度在0x02的基础上增加网络管理报文控制用例。会话维度检查默认会话下执行0x28是否被拒绝。安全维度检查未解锁时执行0x28是否返回0x33。这样扩展出来的用例才不是零散的“我想到什么就写什么”而是有依据的覆盖。每条扩展用例都要基于前面那张需求解析表不要脱离解析表单独发挥。3.3 恢复机制用例不能只写一条恢复机制是0x28用例设计里最容易被忽略的部分。很多用例只验证“禁止成功”和“恢复成功”两条但实际刷写流程中恢复失败的后果很严重ECU保持静默整车上电后网络管理异常其他ECU无法唤醒它。恢复机制至少要覆盖通过0x28 01恢复通过下电重新上电恢复通过会话切换恢复如果设计如此通过唤醒信号恢复如果设计如此恢复失败后的表现ECU是否进入特定状态是否记录DTC每条恢复路径都要设计“恢复成功后再次发送0x28 00 01”的二次禁止用例确认从恢复到禁止的来回切换没问题。状态型服务最怕只测单向流程。4. 0x28服务用例矩阵把需求拆成可组合的测试条件4.1 合法组合用例矩阵当需求文档允许的子功能是0x00、0x01、0x02通信类型是0x01、0x02、0x03时合法组合可以整理成矩阵子功能/通信类型0x01应用0x02网络管理0x03全部0x00 禁止发送应用报文停发NM报文停发全部停发0x01 恢复发送应用报文恢复NM报文恢复全部恢复0x02 禁止接收应用报文被忽略NM报文被忽略全部被忽略每条组合还需要叠加会话和安全条件。最简单的拆分方式是给每个组合单独复制四组用例默认会话 未解锁预期NRC 0x7F扩展会话 未解锁预期NRC 0x33如果安全策略如此扩展会话 已解锁预期正响应编程会话 已解锁有些OEM允许需要单独确认这样矩阵就从一个3×3扩展成3×3×4。每个单元格内还要考虑响应可达性和DTC行为。4.2 异常用例矩阵异常用例要覆盖协议层面和状态层面异常类型请求内容预期结果子功能不支持0x28 04 01NRC 0x12通信类型非法0x28 00 05NRC 0x13 或 0x31长度错误0x28 00NRC 0x13未解锁0x28 00 01NRC 0x33会话不支持默认会话执行NRC 0x7F这里有一个细节子功能非法和通信类型非法的NRC可能因OEM实现而不同。0x28 00 05如果发生在已解锁且扩展会话下有些ECU返回0x13有些返回0x31。用例预期不能凭空指定必须依据需求规格或OEM诊断规范否则测试脚本会陷入“实际结果和预期不符”的争议。4.3 时序类用例连续、重复、间隔0x28服务还有一个特殊点它是带状态的。连续下发相同请求、在禁止状态中再次禁止、在恢复状态中再次恢复行为都可能不同。建议至少设计这些时序用例连续两次发送0x28 00 01第二次是否返回正响应是否影响状态机发送0x28 00 01后间隔100ms发送0x28 01 01间隔是否足够ECU完成切换在0x28 01 01恢复后立即发送0x28 00 01快速反转是否产生异常在0x28禁止状态中发送其他诊断服务结果是否符合预期这些时序用例在自动化测试里特别有用通常能用很少的成本暴露ECU状态机实现问题。实车问题里有一类就是快速反转操作触发的台架回归却不一定会发现。5. 用testbuddy这类用例生成工具时提示词和模板要这样写5.1 为什么不能直接写“生成0x28测试用例”现在有人会用testbuddy这类用例生成工具来辅助出用例。工具本身不差问题在于输入太笼统。直接让工具“生成0x28测试用例”它很可能给你一份看起来完整、实际落地却没法执行的通用模板。0x28服务的用例有效性和OEM规范强绑定包括子功能范围、通信类型定义、安全策略、会话支持、响应可达性这些信息工具无法自己猜。用工具前必须先把需求拆成结构化描述输进去工具才能基于规则补全条件。5.2 一个可以直接参考的提示词结构我第一次给AI辅助工具输入时会这样拆分“请根据以下需求生成0x28通信控制服务测试用例。服务ID0x28 CommunicationControl 支持子功能0x00 enableRxAndDisableTx0x01 enableRxAndEnableTx0x02 disableRxAndEnableTx 支持通信类型0x01 应用报文0x02 网络管理报文0x03 全部 会话条件0x28只能在扩展会话和编程会话下执行默认会话不支持NRC为0x7F 安全条件执行0x28前需要安全解锁未解锁NRC为0x33 恢复条件0x28 01 01恢复下电重新上电恢复会话切换恢复 总线约束禁止应用报文发送后ECU仍应响应诊断请求 DTC约束禁止通信期间不产生通信相关DTC 用例格式包含用例编号、前置条件、步骤、预期结果”实际使用testbuddy或类似工具时把上面结构填进需求描述或提示词生成结果才会更接近可评审状态。工具生成之后还是要人工做专家评审AI辅助生成用例的价值主要在于覆盖率补全和格式统一它不能替代你对需求的理解。注意工具生成结果只能当初稿。没有经过需求评审的用例不能直接作为测试依据进入执行阶段。5.3 生成后的用例清单怎么验收验收生成结果时我习惯用这三条标准每条用例是否都有明确的前置条件包括会话、安全状态、0x28初始状态预期结果是否写了“状态变化”而不是只写“通过”恢复机制和异常条件是否覆盖满足这三条再进入用例评审。不满足就继续补充需求信息或调整提示词。不要把工具生成的结果当成最终交付物它是草稿不是结论。6. 用例执行时容易翻车的场景和排查顺序6.1 禁止通信后诊断仪把自己玩断0x28用例执行中最常见的问题发送禁止通信指令后诊断请求也发不出去了。这时候不要急着改脚本先确认0x28的通信类型是否包含了诊断报文。如果包含了测试工具需要先恢复通信或者重新上电否则后续所有诊断步骤都停留在超时状态。实际项目里我遇到过一种情况脚本发送0x28 00 03把诊断报文也禁止了然后脚本继续发状态轮询等待回复结果一直超时。问题不在ECU而在于测试用例没有设计“禁止期间诊断响应是否可达”这个前置条件。遇到这种情况排查顺序是先看0x28请求是否收到正响应。再看测试工具能不能恢复通信比如发送复位或0x28 01。如果工具通信中断优先下电重启而不是反复发指令。最后回查用例矩阵确认禁止范围是否覆盖诊断报文。注意脚本里不要反复发送诊断请求来“试探”恢复先确认是通信控制导致的中断再执行恢复步骤。6.2 网络管理报文被抑制后的总线异常当0x28的通信类型包含NM报文时情况更复杂。ECU不再发送NM报文后整车网络管理的状态机可能认为该节点离线产生唤醒状态异常或休眠异常其他ECU会记录通信相关DTC。这种问题不是0x28服务本身错误而是测试场景没有隔离。执行这类用例时建议在总线仿真环境里单独验证避免在整车全网络环境里操作。如果一定要在实车上执行需要提前确认整车网络管理策略并准备恢复脚本。6.3 恢复不彻底的错觉有个隐蔽问题发送0x28 01 01后应用报文恢复了但ECU的网络管理状态没有回到正常。原因是部分ECU在0x28禁止NM报文期间网络管理状态机被强制置为Bus-Sleep或Prepare Bus-Sleep恢复指令只恢复报文发送不恢复状态机。用例预期里必须区分“报文恢复”和“网络管理状态恢复”。如果能通过诊断读取ECU状态最好把状态读取也写入步骤否则你就只验证了表面现象。6.4 台架和实车行为不一致0x28在台架上很好用但在实车上受网关路由、总线负载、电源管理影响行为可能完全不同。比如网关可能不会转发0x28请求到目标ECU导致指令实际上没有执行。排查时先抓总线报文确认请求真的到达了目标ECU再判断ECU行为。我在台架验证通过后一般会安排一版实车冒烟用例专门覆盖网关转发路径、整车上下电时序、网络管理状态恢复。这样可以提前暴露环境差异导致的问题。7. 用例设计完成前保留最后的自查清单7.1 一份可以复印的检查清单0x28用例设计完成后我会按下面清单自查服务ID是否与需求一致子功能列表是否与需求文档一致有没有把0x01误用成0x00通信类型范围是否覆盖需求允许的全部组合是否设计了默认会话下的NRC用例是否设计了未解锁场景下的NRC用例是否覆盖恢复机制诊断指令恢复、下电恢复、会话切换恢复是否覆盖禁止期间诊断响应的可达性是否覆盖DTC影响是否覆盖状态快速反转场景是否在实车环境安排冒烟用例这个清单不是万能清单但它能挡住0x28用例评审里最常见的十个问题。每次用例评审我基本都是从这十项开始问。7.2 落地时真正该盯住的不是功能列表0x28服务说到底只是一个带状态的控制服务真正的复杂度来自它和会话、安全、总线、网络管理、DTC之间的耦合。所以用例设计花大力气的地方不应该是“列出了多少条用例”而是有没有把这些耦合关系都写清楚。如果只是学习一遍默认矩阵可以这样起步主路径、恢复、异常、时序各写一组。如果要用于生产项目就要回到OEM规范逐条核对。多花时间把需求和协议字段抠清楚后面执行阶段会省掉很多无谓的返工。