做网络诊断测试时0x28CommunicationControl通信控制服务是我认为最需要“花心思设计用例”的服务之一。原因很简单它直接控制ECU对外通信的收与发一旦用例覆盖不全轻则测试阶段漏掉关键故障重则导致整车上电后网络管理异常、ECU无法正常休眠。本文结合实际的诊断开发与测试经验围绕“0x28服务根据需求设计用例”这一主题从协议定义、需求拆解、用例设计、自动化执行到常见问题排查完整梳理一套可直接参考的落地思路。1. 0x28服务是什么1.1 服务定义0x28服务是UDSUnified Diagnostic Services统一诊断服务协议中的一员标准定义在ISO 14229-1中。它的作用非常直接控制ECU的通信行为。通俗地说诊断仪可以通过发送0x28服务让某个ECU“暂时闭嘴”或者“重新开口”。这里的“张嘴闭嘴”不是物理断电而是控制ECU对外通信报文的接收和发送。比如禁止ECU发送应用报文禁止ECU接收应用报文禁止ECU进行网络管理报文的收发恢复以上所有通信。为什么要这么做因为汽车电子系统中ECU之间的报文交互非常频繁。在某些特殊场景下比如 ECU 刷写Flash Bootloader、整车下线配置、部分网络测试我们需要暂时切断目标ECU的通信避免干扰诊断流程或者导致总线负载异常。1.2 诊断帧格式0x28服务的请求格式如下0x28 SubFunction CommunicationType0x28服务IDSID。SubFunction子功能表示要对通信做什么操作常见取值见下表。CommunicationType通信类型表示要控制哪一类通信。响应格式分为两种肯定响应0x68 SubFunction CommunicationType否定响应0x7F 0x28 NRC当ECU无法执行请求时会回复否定响应码NRCNegative Response Code。1.3 子功能与通信类型子功能值名称含义0x00enableRxAndTx允许接收和发送0x01enableRxAndDisableTx允许接收禁止发送0x02disableRxAndEnableTx禁止接收允许发送0x03disableRxAndTx禁止接收和发送通信类型 CommunicationType 是一个字节每个bit表示一种通信类别Bit位含义示例Bit 0应用报文周期性发送的传感器/状态报文Bit 1网络管理报文网络管理相关报文如NM报文Bit 2诊断报文物理请求/响应带物理寻址点对点的诊断报文Bit 3诊断报文功能请求/响应带功能寻址广播的诊断报文举个实际例子请求28 03 01这表示子功能 0x03disableRxAndTx通信类型为 0x01仅禁止应用报文。也就是“只关闭应用报文的接收和发送不关闭诊断报文”。请求28 00 03这表示子功能 0x00enableRxAndTx通信类型为 0x03应用报文 网络管理报文。也就是“恢复应用报文和网络管理报文的收发”。1.4 为什么需要单独设计用例0x28服务很容易被误认为“几行报文就能测完”实际上它牵涉很多边界条件通信类型是否可以组合诊断会话切换后是否自动恢复通信不同子功能之间是否可以连续切换功能寻址和物理寻址行为是否一致网络安全认证通过之前是否允许执行网络管理状态机是否会因为通信关闭而进入异常。每一项都对应至少一到两个独立用例。如果不按需求拆解大概率会漏测。2. 0x28服务的典型应用场景2.1 ECU软件刷写前的通信隔离在线刷写Flash时刷写工具通常会在进入编程会话前通过0x28服务关闭ECU的应用报文和网络管理报文。这样可以避免刷写过程中应用层程序继续运行导致Flash读写冲突或总线收到异常报文。常见流程诊断仪 - ECU10 02进入编程会话 诊断仪 - ECU28 03 03关闭应用报文网络管理报文 诊断仪 - ECU34 36 37请求下载、转移数据、退出传输2.2 网络管理与休眠唤醒测试在整车网络测试中测试工程师经常需要单独验证某个ECU的休眠唤醒策略。此时会通过0x28服务关闭某个ECU的NM报文观察总线其他节点是否因此进入网络异常或者观察该ECU是否在超时后自动休眠。设计用例时要特别关注通信关闭后Bus Off、节点复位、网络状态切换等时序问题。2.3 网关路由与子网隔离对于带有网关的整车网络网关节点可以通过0x28服务控制某个子网内的报文路由从而实现子网隔离。这种场景下0x28服务的用例不只是“诊断仪和ECU点对点通信”还要验证路由表在通信关闭/恢复后的行为。2.4 安全攻击模拟与故障注入在网络安全测试中0x28服务也是常用的故障注入手段之一。通过关闭接收或发送模拟ECU“失联”或“静默”验证上层应用例如远程控制、在线状态监测的降级策略是否正确。3. 根据需求设计0x28用例的整体思路3.1 需求拆解步骤设计用例不是凭空脑补而是基于需求文档一条条拆。通常可以按下面四步走第一步提取需求项。把需求文档中所有与0x28相关的描述摘出来包括功能需求、时序需求、安全需求和诊断需求。第二步确认协议行为。将需求项映射到ISO 14229-1的协议行为确定预期报文格式和响应行为。这里特别要确认当前ECU是否实现了所有子功能还是只实现了部分。第三步识别正常流与异常流。正常流是“请求合法ECU响应肯定”异常流是“请求非法ECU响应NRC”。第四步设计时序和交互场景。0x28服务一旦涉及网络管理和会话切换用例就要从“单帧请求/响应”扩展为“多步骤时序验证”。3.2 正常流用例模板正常流用例关注的是在合法输入下ECU能否正确执行通信控制动作。用例编号前置条件测试步骤预期结果TC_0x28_001默认会话总线通信正常发送 28 01 01返回 68 01 01ECU停止发送应用报文TC_0x28_002默认会话应用报文已停止发送 28 00 01返回 68 00 01ECU恢复发送应用报文3.3 异常流用例模板异常流用例关注的是在非法输入、错误状态下ECU能否正确拒绝。用例编号前置条件测试步骤预期结果TC_0x28_101默认会话发送 28 03 00返回 7F 28 13IncorrectMessageLengthOrInvalidFormatTC_0x28_102默认会话发送 28 04 01返回 7F 28 12SubFunctionNotSupported或 0x313.4 时序类用例模板时序类用例关注的是通信控制动作对后续诊断流程、网络管理状态机、路由行为的影响。用例编号前置条件测试步骤预期结果TC_0x28_201默认会话发送 28 03 01等待10s后发送诊断请求诊断请求可以被正常处理应用报文连续静默TC_0x28_202扩展会话发送 28 03 01然后发送 10 01 回到默认会话默认会话重启后通信类型恢复为默认状态4. 设计一份可落地的0x28用例集这一节围绕一个通用ECU诊断需求设计一组完整用例集。实际项目中你可以在此基础上按车型需求增删。4.1 需求假设我们假设目标ECU满足以下需求支持0x28服务的三个子功能0x00、0x01、0x03不支持0x02支持通信类型应用报文Bit0、网络管理报文Bit1、诊断物理报文Bit2、诊断功能报文Bit3进入默认会话Default Session时必须支持通信控制通信类型为0x00时禁止关闭所有通信0x28服务在安全解锁前后行为一致通信控制状态在会话切换后重置为默认。4.2 用例编号规范建议采用统一编号便于测试管理和问题追踪TC_0x28_XXX_YYYXXX用例类型如001-099为正常流101-199为异常流201-299为时序/恢复流301-399为安全/会话流。YYY可选表示与子功能相关的细分编号。4.3 正常流用例用例编号用例名称前置条件测试步骤预期结果TC_0x28_001关闭应用报文收发默认会话发送 28 03 01返回 68 03 01ECU停止发送应用报文诊断通信正常TC_0x28_002恢复应用报文收发已执行28 03 01发送 28 00 01返回 68 00 01ECU恢复发送应用报文TC_0x28_003关闭网络管理报文收发默认会话发送 28 03 02返回 68 03 02NM报文停止发送TC_0x28_004恢复网络管理报文收发已执行28 03 02发送 28 00 02返回 68 00 02NM报文恢复TC_0x28_005同时关闭应用和网络管理报文默认会话发送 28 03 03返回 68 03 03两种报文均停止TC_0x28_006禁止RX允许TX默认会话发送 28 02 01预期NRC 0x12该ECU不支持0x02子功能具体以需求为准TC_0x28_007只禁止发送应用报文默认会话发送 28 01 01返回 68 01 01ECU仍正常接收应用报文但不发送应用报文TC_0x28_008关闭诊断功能报文默认会话发送 28 03 08返回 68 03 08功能寻址请求无法控制该ECU物理寻址诊断不受影响这里的 TC_0x28_006 在需求假设中说明ECU不支持0x02因此预期NRC 0x12。如果你的ECU支持0x02则需要调整为肯定响应。4.4 异常流用例用例编号用例名称前置条件测试步骤预期结果TC_0x28_101请求长度错误默认会话发送 28 03返回 7F 28 13错误长度或格式TC_0x28_102子功能不支持默认会话发送 28 04 01返回 7F 28 12子功能不支持TC_0x28_103通信类型置0默认会话发送 28 03 00返回 7F 28 31请求超出范围或按需求定义TC_0x28_104通信类型保留位置1默认会话发送 28 03 80返回 7F 28 31TC_0x28_105服务ID错误默认会话发送 29 03 01返回 7F 29 11服务不支持异常流用例的核心价值在于验证ECU对错误输入的处理是否符合规范同时防止协议栈在异常输入下产生不可控行为。4.5 时序与恢复流用例用例编号用例名称前置条件测试步骤预期结果TC_0x28_201通信关闭后诊断会话请求仍可响应已发送28 03 01发送 10 02返回 50 02ECU正常进入扩展会话TC_0x28_202会话切换后通信控制状态重置已发送28 03 03发送 10 01等待恢复到默认会话ECU恢复默认通信行为应用和NM报文重新发送TC_0x28_203ECU复位后通信控制状态重置已发送28 03 03执行ECU复位如 11 01等待重启ECU恢复默认通信行为TC_0x28_204通信关闭状态下功能寻址请求已发送28 03 08通过功能寻址发送诊断请求若配置为忽略功能诊断则无响应物理寻址正常第 TC_0x28_202 和 TC_0x28_203 是实际项目中最容易被漏测的因为很多ECU的需求确实规定“会话切换或复位后重置通信控制状态”但测试工程师往往只测了单次请求/响应。4.6 安全与网络管理交互用例用例编号用例名称前置条件测试步骤预期结果TC_0x28_301通信关闭后NM超时已发送28 03 02观察5分钟ECU应按照网络管理状态机进入准备休眠或总线休眠TC_0x28_302通信恢复后NM重新发送网络处于休眠状态已发送28 00 02等待网络管理唤醒条件ECU重新加入网络管理发送NM报文TC_0x28_303安全解锁状态下关闭通信执行安全解锁发送28 03 03返回 68 03 03通信控制正常生效TC_0x28_304安全锁定状态下关闭通信默认会话发送28 03 03若需求要求安全等级则返回NRC 0x33若不要求则返回肯定响应安全相关预期必须严格以需求文档为准。有的ECU在默认会话就允许执行0x28有的则要求安全等级。设计用例前建议把安全访问和诊断会话关系表整理成矩阵。5. 结合CAPL与Python实现0x28用例自动化5.1 为什么建议自动化0x28用例测试过程中需要反复切换会话、发送请求、抓取总线报文、判断报文静默时间。如果全部手工在CANoe或PCAN上操作效率非常低而且很容易漏观察报文。建议至少把正常流和异常流用例自动化。下面提供两种常见的自动化思路。5.2 CAPL脚本示例CANoe如果你使用CANoe进行总线仿真与测试可以直接用CAPL模拟诊断仪发送0x28请求并检查响应。保存文件0x28_Test.can/* 0x28 CommunicationControl 测试脚本示例 */ variables { // 诊断请求报文ID根据项目配置修改 const int DIAG_REQ_ID 0x7E0; const int DIAG_RES_ID 0x7E8; // 等待肯定响应超时时间 const int RESP_TIMEOUT 1000; } void SendDiagnosticRequest(byte data[], int len) { int i; diagRequest req; req.SetP2(50); req.SetS3(5000); req.SetPhysicalRequest(DIAG_REQ_ID); for (i 0; i len; i) { req.SetByte(i, data[i]); } req.SendRequest(); } testcase TC_28_001_DisableRxTx_AppMessage() { byte request[3] {0x28, 0x03, 0x01}; SendDiagnosticRequest(request, 3); if (testWaitForDiagResponse(DIAG_RES_ID, RESP_TIMEOUT) 0) { testStep(PASS, 0x28肯定响应收到); } else { testStep(FAIL, 0x28响应超时); } } main() { TC_28_001_DisableRxTx_AppMessage(); }这个脚本的核心思路是通过diagRequest对象构造0x28诊断请求然后等待诊断响应。实际项目中你还需要在响应回调函数里对“肯定响应码”和“NRC”做更细粒度的判断。5.3 Python脚本示例python-can如果你的测试环境不是CANoe而是基于PCAN或CANable的Python环境可以这样写保存文件uds_0x28_test.py# -*- coding: utf-8 -*- 0x28 CommunicationControl 用例自动化示例 依赖python-can import can import time # 诊断请求ID和响应ID按项目实际配置修改 DIAG_REQ_ID 0x7E0 DIAG_RES_ID 0x7E8 # ISO-TP 单帧发送仅供参考实际项目建议使用 isotp 库 def send_isotp_single_frame(bus, req_id, data, timeout1.0): # 诊断请求通常走 ISO-TP 协议这里使用 python-can 直接发送 CAN 帧 # 对于长度 7 的请求可以直接作为单帧发送 sf_pci (len(data) 0x0F) | 0x00 frame_data [sf_pci] list(data) msg can.Message(arbitration_idreq_id, dataframe_data, is_extended_idFalse) bus.send(msg) # 等待响应帧示例简化处理只检测第一帧 end_time time.time() timeout while time.time() end_time: rx_msg bus.recv(timeout0.2) if rx_msg is None: continue if rx_msg.arbitration_id DIAG_RES_ID: return rx_msg.data return None def main(): bus can.interface.Bus(channelPCAN_USBBUS1, interfacepcan, bitrate500000) # 测试28 03 01 关闭应用报文收发 request [0x28, 0x03, 0x01] response send_isotp_single_frame(bus, DIAG_REQ_ID, request) if response is None: print(FAIL: 响应超时) return # 预期肯定响应 0x68 0x03 0x01 if len(response) 4 and response[1] 0x68 and response[2] 0x03 and response[3] 0x01: print(PASS: 0x28 03 01 返回肯定响应) else: print(fFAIL: 预期 68 03 01实际响应 {response.hex()}) bus.shutdown() if __name__ __main__: main()强烈建议如果在真实项目中做诊断自动化不要自己手动解析ISO-TP直接使用can-isotp库或udsoncan库它们会帮你处理单帧、连续帧、流控等细节。上面示例只是为了展示最小逻辑实际工程化时需要替换为成熟的诊断协议栈。6. 用testbuddy思路批量生成与维护0x28用例6.1 testbuddy是什么“testbuddy”是近年在测试圈讨论度较高的用例生成辅助工具/思路它强调通过结构化需求描述、自动生成测试用例框架、再结合人工评审来提升用例编写效率。虽然不同团队落地方式不同但核心思路完全可以借鉴到0x28用例设计中。6.2 如何借鉴你可以把0x28需求拆成结构化表格让工具辅助生成用例骨架。第一步结构化需求描述服务名称CommunicationControl SID0x28 支持的子功能0x00, 0x01, 0x03 支持的通信类型 - AppMessage(0x01) - NetworkManagement(0x02) - DIAG_PHYSICAL(0x04) - DIAG_FUNCTIONAL(0x08) 限制条件 - 通信类型0x00不允许 - 保留位不允许置1 - 会话切换后重置第二步生成用例骨架工具可以根据“服务子功能通信类型限制条件”的组合自动生成正常流和异常流用例名称TC_0x28_001_DisableAppMessage TC_0x28_002_DisableNetworkManagement TC_0x28_003_DisableAppAndNM TC_0x28_101_InvalidCommunicationTypeZero TC_0x28_102_ReservedBitSet第三步人工补充后续动作自动生成的用例通常只覆盖“请求-响应”层面无法完全替代测试工程师的领域经验。你需要人工补充通信关闭后的总线静默观察通信恢复后的报文重建时间网络管理状态机变化会话切换边界与其他服务10服务、11服务、27服务的交互。6.3 用例维护建议用testbuddy或类似工具生成的用例集建议定期回归。因为ECU诊断需求会随软件版本迭代而变化比如新版本可能增加0x02子功能支持或改变NRC返回策略。每次需求变更都应该同步更新用例矩阵。7. 常见问题与排查清单问题现象常见原因解决思路发送0x28请求后无响应诊断请求报文ID错误或ISO-TP层未正确建立连接检查请求/响应ID、波特率、ISO-TP地址响应为7F 28 12子功能不支持核对需求文档确认ECU支持的子功能列表响应为7F 28 13请求长度错误或格式错误检查请求数据长度确保至少两个数据字节响应为7F 28 31请求参数超出范围检查通信类型是否置了保留位或为0关闭通信后应用报文仍然在发ECU进入总线静默需要时间或需求规定延迟生效延长观察时间确认ECU是否配置了延迟关闭关闭NM报文后ECU不进入休眠网络管理状态机存在超时保护或KeepAwake条件结合NM状态机分析检查其他唤醒源会话切换后通信控制状态未重置需求未定义重置行为核对DTC和配置表确认是否存在“通信类型保持”需求功能寻址请求被ECU响应但物理寻址请求无响应通信类型控制诊断功能寻址检查请求中的通信类型是否为0x08并确认ECU对功能寻址的处理逻辑排查时建议按照“请求发出→总线抓包→响应解析→状态观察”的顺序进行不要一上来就怀疑ECU实现错误。很多时候问题出在测试工具配置上比如报文ID、波特率、ISO-TP地址。8. 最佳实践与工程建议8.1 用例设计层面先做需求矩阵。将子功能与通信类型做成二维矩阵逐个组合评估避免漏组合。不要只测单帧。0x28服务的关键在于“控制之后的链路状态变化”必须增加时序观察。区分物理寻址和功能寻址。很多ECU对两者处理逻辑不同建议分别设计用例。会话切换和ECU复位场景必须覆盖。这是通信控制状态机重置最典型的两条路径。8.2 测试执行层面使用CANoe或CANalyzer抓取总线报文观察通信关闭前后的报文静默时间记录NRC响应码不能只判断“有响应”或“无响应”在测试报告中标注所使用的诊断仪与ECU软件版本方便问题回溯涉及ECU复位、网络管理状态切换等操作时确保测试环境不涉及实车安全风险推荐在台架或仿真环境先行验证。8.3 自动化与工具层面优先使用成熟的诊断协议栈库如udsoncan、can-isotp、CAPL的diagRequest避免重复造轮子用例命名统一做好前置条件和预期结果的规范描述结合testbuddy思路把需求表维护成结构化数据用例变更时做到“需求一处修改用例批量更新”。8.4 安全与合规层面0x28服务虽然主要用在诊断测试但它有能力让ECU暂时失去通信能力。在实车或接近量产状态的测试环境中执行“关闭通信”类用例前务必确认该操作不会影响行车安全功能并且操作人员具备合法测试授权。所有诊断变更类操作都应保持最小影响范围测试完成后及时恢复通信状态。0x28服务在整套UDS协议里的代码量不大但它牵涉的知识面很广ISO-TP、网络管理、会话管理、安全访问、路由转发、总线静默策略。设计用例时不要只盯着诊断仪发出去的那几帧报文更要关注ECU在被“断网”和“恢复网络”前后整个系统状态如何迁移。把这些边界想清楚0x28服务的用例才算是真正覆盖到位。