做车载诊断测试这几年一个很深的感受是越简单的服务越容易在用例设计上翻车。0x3ETesterPresent就是这样典型的例子。它没有 0x10 的会话切换能力没有 0x27 的加解密逻辑也没有 0x31 的例程执行功能从协议看就是周期性地发一帧02 3E 01心跳报文很多刚入行的同学甚至觉得它不值得单独写用例。但如果你真的负责过整车级诊断或者刷写标定就会知道很多莫名其妙的诊断失败最后都指向 0x3E 没设计好。要么发送周期超过了 S3Server 导致会话回退要么在功能寻址下所有 ECU 同时响应把总线负载打爆要么刷写过程中一次心跳超时导致整个编程流程前功尽弃。这篇文章围绕“0x3E 服务根据需求设计用例”展开核心判断是0x3E 用例设计的重点不在正常路径而在时序边界、异常响应和组合业务场景。读完你至少能拿走三样东西第一0x3E 服务从需求文档里到底要提取哪些关键参数第二一份可以直接复用或改造成项目模板的 0x3E 用例清单第三用例落地成自动化脚本的具体思路包括 CANoe/CAPL、Python、SocketCAN 命令三种方式。1. 0x3E 服务到底是什么先搞清楚三个概念1.1 从 UDS 诊断体系说起UDSUnified Diagnostic Services统一诊断服务是 ISO 14229 定义的一套诊断协议广泛应用在整车 OBD、产线 EOL、售后诊断仪和刷写工具中。在这套协议里所有诊断请求都通过 SIDService Identifier服务标识符区分例如0x10DiagnosticSessionControl诊断会话控制0x22ReadDataByIdentifier按 DID 读取数据0x27SecurityAccess安全访问0x2EWriteDataByIdentifier按 DID 写入数据0x31RoutineControl例程控制0x3ETesterPresent诊断仪在线0x19ReadDTCInformation读取故障码信息0x3E 服务的作用很朴素让 ECU 知道诊断仪还“在线”。它不是用来读数据、写参数或者执行动作的而是用来维持当前诊断会话状态的。很多刚接触诊断的同学会困惑0x3E 和网络管理报文有什么不同网络管理报文如 NM 报文解决的是总线休眠和唤醒问题属于网络层0x3E 属于应用层诊断服务解决的是诊断会话保活问题两者不能互相替代。1.2 0x3E 的报文格式与子功能0x3E 请求报文一般由 3 个字节构成典型发送格式为CAN 报文数据场02 3E 0102ISO-TP 单帧 PCI 字节表示后面有 2 个数据字节3E服务标识符01子功能0x3E 服务支持的子功能通常有子功能含义典型行为0x00stopSending停止发送部分 ECU 支持表示诊断仪将停止周期发送 0x3E若不支持会返回 NRC 0x120x01send发送并使能正响应ECU 收到后返回肯定响应03 7E 010x02抑制正响应ECU 正常处理请求、重置会话定时器但不发送肯定响应子功能的具体支持情况要以项目需求为准。不同 OEM 对 0x00 子功能的定义差别比较大有的保留有的直接移除。对测试工程师来说最重要的基础判断是0x3E 服务进入 ECU 时正常响应是03 7E 01子功能原值回显不是03 7E 41也不要指望所有实现都完全一致。如果响应字节和你预期不一致先查需求和诊断调查表Diagnostic Specification。1.3 会话保持的关键S3Server理解 0x3E 之前必须理解 S3Server。S3Server 是 ECU 侧定义的非默认会话超时时间它表示如果 ECU 在非默认会话扩展会话、编程会话等下超过该时间没有收到任何诊断请求它会自动回到默认会话Default Session。S3Server 的具体数值不是 ISO 14229 强制规定的而是 OEM 在项目需求里定义的常见值有 5000ms、10000ms 等。0x3E 的典型做法是ECU 每次收到 0x3E 请求后重置 S3Server 定时器。诊断仪侧也有一个 S3Client 定时器用于判断 ECU 是否失联。所以 0x3E 用例设计最核心的时序逻辑是在非默认会话下周期性发送 0x3E且发送周期 S3Server会话保持不回落停止发送 0x3E且等待时间 S3ServerECU 回落默认会话发送周期和 S3Server 之间的余量大小直接影响诊断流程的稳定性对测试团队来说S3Server 不是一个“知道就行”的参数它会直接决定 0x3E 用例里等着多少毫秒、发多少次心跳。这也是后面用例设计的锚点。2. 0x3E 用例设计的前置需求分析2.1 从需求文档中提取哪些要点设计 0x3E 用例之前先做需求分析。不要拿到协议规范就开始写用例。0x3E 虽然简单但需求文档里值得提取的信息不少列出关键项需求要素说明在用例中的作用支持的子功能是否支持 0x00/0x01/0x02决定正常用例和 NRC 用例范围正响应格式响应 SID、子功能回显方式判断响应报文字节0x3E 发送周期诊断仪侧心跳周期设计时序保持用例S3Server 超时时间ECU 会话保活期限设计超时回落用例支持的会话列表默认会话、扩展会话、编程会话覆盖多会话场景功能寻址支持是否允许用 0x7DF 发送设计多 ECU 总线负载场景抑制正响应0x02 允许条件下是否生效设计无响应场景特殊条件限制电源模式、总线唤醒状态等设计 NRC 0x22 用例有一个经验可以参考如果需求文档里连 S3Server 大小、0x3E 发送周期没有写清楚那么直接把需求打回不要急着写用例。因为缺了这两个参数你根本无法判断“会话保持”用例的预期结果是真通过还是假通过。2.2 需求不完整时怎么补实际项目里需求文档不完整很常见。遇到这种情况建议按以下顺序推进找诊断规范或 CAN 矩阵文件确认报文 ID、周期、填充字节找测试车辆或台架 ECU 实际抓包确认 0x10 会话响应里 S3Server 参数真实值与 OEM 接口人或系统工程师确认 NRC 覆盖范围把确认结果沉淀为“补充需求说明”不能只留在口头特别提醒S3Server 通常可以在 ECU 收到0x10 02的响应中读到但不同 ECU 的实现格式可能不同。如果响应里没有明确给出别猜直接向供应商要诊断调查表。2.3 判断用例设计完备性的四个维度写 0x3E 用例时我的判断维度是四个功能维度正常能响应吗会话保持吗抑制正响应生效吗异常维度非法子功能、错误长度、不支持场景NRC 是否正确时序维度周期余量、S3Server 边界、超时回落是否符合需求组合维度0x3E 与刷写、安全访问、通信控制、多 ECU 功能寻址组合是否稳定只要这四个维度都覆盖到了0x3E 用例基本不会漏得太多。下面几章按维度拆开讲。3. 0x3E 功能用例设计3.1 正常响应场景正常响应是 0x3E 用例的第一层。它的核心验证点是ECU 能正确识别 0x3E 服务并且返回正确的肯定响应。在默认会话下发送02 3E 01预期 ECU 返回03 7E 01不能返回 NRC同时 ECU 不应因为收到 0x3E 而改变当前会话。这个用例看起来简单实际上能挡掉很多低级问题比如报文 ID 配置错误、诊断报文长度错误、ECU 侧服务未使能等。在扩展会话和编程会话下0x3E 01 同样应正常响应。这里有一个容易被忽略的点进入扩展会话后ECU 会启动 S3Server 定时器。如果不发 0x3E几秒后会话就回默认了。所以当你用诊断工具切到扩展会话然后开始写用例时最好先把 0x3E 周期发送打开否则测试过程中会出现“明明刚才还正常过一会儿再发 0x22 就失败了”的奇怪现象。3.2 抑制响应场景0x3E 02 是很多车厂在功能寻址场景下的推荐做法。它表示ECU 正常接收并处理该请求会重置会话定时器但不发送任何肯定响应。这样做的直接收益是降低总线负载。这类用例的预期结果是“没有响应”而不是“响应错误”。有经验的测试人员会关注一两秒时间窗内 ECU 是否真的没有发出任何响应帧。如果这时候收到 NRC说明 ECU 可能不支持 0x02 抑制响应或者实现有 bug需要进一步与开发确认。需要注意0x3E 02 不返回正响应不代表它不生效。验证它是否生效需要通过其他服务验证会话是否被保持。比如发送 0x3E 02等待接近 S3Server 的时间再发送 0x22 读 DID如果 0x22 能正常响应且处于非默认会话说明 0x3E 02 的会话保活逻辑是生效的。3.3 会话保持与超时回落会话保持是 0x3E 用例的重头戏。具体来说分两个方向方向一发送周期 S3Server 时会话保持不回落。例如项目定义的 S3Server 为 5000msTester 每 2000ms 发一次 0x3E 01。测试时先进入扩展会话开始周期发送 0x3E持续 10s 以上然后通过 0x10 或 0x22 确认 ECU 仍处于扩展会话。这里验证的核心是“周期足够快ECU 不会超时”。方向二停止发送且超过 S3Server 时ECU 复位到默认会话。同样先进入扩展会话停止发送任何诊断请求等待超过 S3Server例如等 6000ms 或 7000ms再发送 0x22 读 DID 或发送 0x10 01 读取当前会话确认 ECU 已经回到默认会话。这个用例非常能反映 ECU 是否严格遵守需求中的会话超时策略。注意时间余量不能写死成 5000/2000必须从需求文档读。如果需求里写的 S3Server 是 3000ms你的用例却按 5000ms 设计测试结果就没有意义了。3.4 组合业务场景0x3E 很少单独存在更多时候它作为“背景服务”与其他诊断服务一起工作。比较典型的组合用例有刷写场景进入编程会话后在刷写过程中周期发送 0x3E 01验证整个刷写流程不中断安全访问场景执行 0x27 解锁后通过 0x3E 维持会话验证解锁状态在会话存续期间保持例程控制场景进入扩展会话后执行 0x31 长任务例程同时在任务执行期间发送 0x3E验证任务不被中断通信控制场景执行 0x28 通信控制禁用应用报文后0x3E 诊断请求是否仍被正常响应组合用例的难点不是执行而是预期结果的判定。比如刷写过程中 0x3E 为什么必须持续发送因为 ECU 在编程会话下同样有 S3Server 超时检查如果刷写工具某个阶段等待时间过长会话掉到默认会话后续的 0x31 例程或 0x2E 写入就可能失败。这类问题在产线和售后现场非常常见。4. 0x3E 异常与边界用例设计4.1 非法子功能与错误长度0x3E 的异常用例集中在 NRC 检查上。这里先列出 0x3E 常见的 NRC 和触发条件便于对照设计。NRC含义常见触发场景0x12子功能不支持发送 0xAA、0x03 等未定义子功能0x13报文长度错误或格式无效缺少子功能、多出额外字节0x22条件不满足ECU 电源模式不满足、不安全状态等具体用例可以表格式列出请求02 3E AA预期返回03 7F 3E 12请求02 3E 03如果需求未定义 0x03 子功能预期返回03 7F 3E 12请求03 3E 01 00多了一个字节预期返回03 7F 3E 13请求01 3E缺少子功能预期返回03 7F 3E 13这类用例的验证价值在于ECU 对格式错误报文的处理不能影响后续正常诊断。也就是说发完错误报文后再发正常的02 3E 01不应该出现无响应、ECU 死机、总线 BusOff 等异常现象。4.2 时序边界值设计0x3E 用例的时序边界值设计是大多数测试工程师容易遗漏的部分。建议把 S3Server 作为边界值目标设计三档第一档在 S3Server 之前发送 0x3E例如 S3Server 为 5000ms在第 4000ms 发送预期会话保持第二档精确在 S3Server 边界时刻发送例如恰好 5000ms预期按需求定义判断——有的 ECU 会回退有的还存在微小余量第三档超过 S3Server 后发送 0x3E例如第 6000ms 发送这时 ECU 可能已经回退为默认会话需要重新发送 0x10 02这里最容易踩坑的是“精确边界时刻”很难在真实总线上做到毫秒级。建议在自动化脚本中把时间用msTimer或者time.sleep精确控制并允许 ±50ms 偏差。如果测试依赖人工按秒表结果基本不可复现。4.3 多 ECU 与功能寻址场景0x3E 还有一个容易被业务方忽视的点功能寻址。普通的物理寻址是 Tester 向某个 ECU 发请求功能寻址例如 CAN ID 0x7DF是同时向总线上多个 ECU 广播请求。在多 ECU 场景下如果采用功能寻址发送02 3E 01那么总线上所有能响应 0x3E 的 ECU 都会同时回正响应03 7E 01。节点少还好节点多的时候总线负载会明显上升。所以很多系统设计会把功能寻址下的 0x3E 固定为02 3E 02也就是抑制正响应。这里的用例设计要点包括功能寻址发送 0x3E 02总线上各 ECU 均不应回复正响应功能寻址发送 0x3E 01观察总线