1. 引言
在车载测试中，UDS（Unified Diagnostic Services，统一诊断服务）是 ISO 14229 标准定义的一套诊断通信协议，广泛应用于 ECU 的刷写、标定、故障读取与例行测试等场景。UDS 诊断模块的测试不仅关注单个服务的请求与响应是否正确，更关键的是要验证各种时序是否符合规范。时序问题往往会导致诊断通信超时、会话切换失败、刷写中断等严重缺陷，因此时序测试是 UDS 诊断测试中不可忽视的一环。
本文围绕 UDS 诊断模块中需要重点测试的时序、测试逻辑以及判定标准展开，帮助测试工程师系统梳理测试思路。
2. 需要测试的核心时序
UDS 诊断模块中，需要测试的时序主要分布在连接建立、会话控制、服务请求响应、安全访问、刷写流程以及网络管理等多个层面。以下按场景分类列出关键时序。
2.1 连接建立与初始化时序
- 上电初始化时序：ECU 上电后，从初始化完成到可以正常响应诊断请求的时间窗口。
- 物理层连接建立时序：在 CAN、CAN FD 或以太网 DoIP 链路上，从建立通信到诊断会话可用的时间。
- DoIP 连接建立时序（若适用）：客户端发起 TCP 连接、车辆发现、路由激活等步骤之间的时间间隔。
2.2 会话控制时序
- 默认会话（Default Session）切换时序：从其他会话切回默认会话的响应时间。
- 扩展会话（Extended Session）切换时序：进入扩展会话的响应时间，以及会话保持时间（Session Timeout）。
- 编程会话（Programming Session）切换时序：进入编程会话的时序，以及刷写过程中会话保持的稳定性。
- 会话超时（S3 Server Timer）时序：当无诊断请求时，ECU 保持当前会话的最长时间，超时后自动回退到默认会话。
2.3 服务请求与响应时序
- 请求-响应时间（P2 Server Timing）：从 ECU 收到诊断请求到发出响应（或 NRC）的最大允许时间。
- P2* 扩展时间（P2* Server Timing）：当 ECU 需要更多处理时间时，在发送首个 NRC 0x78（响应待定）后，后续响应允许的间隔时间。
- 周期型响应时序：对于周期性上报的服务（如周期读取数据），两次响应之间的时间间隔。
2.4 安全访问时序
- 安全访问请求时序：发送 SecurityAccess 请求后，ECU 返回种子（Seed）的时间。
- 密钥验证时序：客户端发送密钥（Key）后，ECU 验证并返回响应的时间。
- 尝试次数限制与延迟时序：连续错误密钥后的锁定时间（Delay Timer），以及允许再次尝试的等待时间。
2.5 刷写（Bootloader）相关时序
- 进入编程会话时序：从请求进入编程会话到 ECU 切换到 Bootloader 模式的时间。
- 擦除与写入时序：EraseMemory、WriteDataByAddress 等服务的执行时间，以及块与块之间的间隔。
- 检查编程依赖（CheckProgrammingDependency）时序：刷写前置条件检查的响应时间。
- 例程控制（RoutineControl）时序：刷写完成后执行例程（如校验、复位）的响应时间。
2.6 网络管理相关时序
- 应用层与网络层交互时序：诊断请求触发网络管理报文（如 NM 报文）的时序。
- 总线关闭与唤醒时序：ECU 进入休眠或唤醒后，诊断通信恢复的时间。
3. 测试逻辑
UDS 时序测试的逻辑核心是验证 ECU 的行为是否符合 ISO 14229 及整车厂（OEM）规范中定义的时间参数。测试逻辑通常遵循以下步骤。
3.1 明确时序参数来源
首先需要从以下来源获取时序参数的基准值：
- ISO 14229-1 标准中定义的默认时间参数（如 P2、P2*、S3）。
- OEM 或供应商的诊断规范（Diagnostic Specification）中自定义的时间参数。
- ECU 软件需求文档中定义的时序要求。
3.2 设计测试用例
针对每个时序参数，设计正向和反向测试用例：
- 正向用例：在允许的时间范围内发送请求，验证 ECU 正常响应。
- 边界用例：在时间参数的临界值（如 P2 的最后一毫秒）发送请求，验证 ECU 是否仍能正确响应。
- 反向用例：故意延迟响应或提前发送请求，验证 ECU 是否按预期处理超时或异常。
3.3 使用工具进行时序测量
时序测试通常依赖以下工具：
- CANoe / CANalyzer：通过 CAPL 脚本精确控制报文发送时刻，并记录响应时间戳。
- 总线分析仪：抓取总线上的报文，计算请求与响应之间的时间差。
- 诊断测试仪（Tester）：模拟客户端行为，记录 ECU 响应时间。
3.4 记录与判定
测试过程中记录每个时序的实际测量值，与标准值进行比对，判定是否通过。对于不通过的用例，需要进一步分析是 ECU 软件问题、总线负载问题还是测试环境问题。
4. 判定标准
UDS 时序测试的判定标准主要依据 ISO 14229-1 标准以及 OEM 自定义规范。以下列出常见的判定标准。
4.1 P2 Server Timing（默认响应时间）
ISO 14229-1 规定，ECU 在收到诊断请求后，应在 P2 时间内发出响应。默认 P2 时间为 50ms（部分 OEM 可能自定义为 25ms 或 100ms）。若 ECU 在 P2 时间内无法完成处理，应发送 NRC 0x78（Response Pending）以告知客户端需要更多时间。
4.2 P2* Server Timing（扩展响应时间）
当 ECU 发送 NRC 0x78 后，后续响应应在 P2* 时间内发出。默认 P2* 时间为 5000ms（5 秒）。若 ECU 在 P2* 时间内仍无法完成，应再次发送 NRC 0x78，直到处理完成。测试时需验证 ECU 是否在 P2* 内持续发送 0x78，且最终给出正常响应或 NRC。
4.3 S3 Server Timer（会话超时时间）
ECU 在非默认会话（如扩展会话、编程会话）中，若在 S3 时间内未收到任何诊断请求，应自动回退到默认会话。默认 S3 时间为 5000ms（5 秒）。测试时需验证 ECU 在超过 S3 时间后是否自动切换回默认会话，且切换后不再响应扩展会话特有的服务。
4.4 安全访问延迟时间
当客户端连续发送错误密钥时，ECU 应进入锁定状态，并在 延迟时间内拒绝新的安全访问请求。延迟时间通常由 OEM 定义，常见为 10 秒或更长。测试时需验证 ECU 在锁定期间是否返回 NRC 0x37（Request Sequence Error）或 0x36（Invalid Key），且锁定时间结束后允许重新尝试。
4.5 刷写相关时序标准
刷写过程中的时序标准通常由 OEM 的刷写规范定义，常见包括：
- 进入编程会话后，ECU 应在规定时间内（如 2 秒）完成模式切换。
- 擦除操作应在规定时间内完成（如 10 秒），超时则判定失败。
- 写入操作中，每块数据的写入时间应在规定范围内，且块间间隔不应超过 P2* 时间。
- 刷写完成后，例程控制（如校验和验证）应在规定时间内返回结果。
4.6 总线负载与时序的关系
在总线负载较高时，诊断报文的传输可能延迟，导致时序超时。测试时需在空载和满载两种总线负载条件下分别验证时序，确保 ECU 在极端情况下仍能满足时序要求。
5. 常见问题与注意事项
- NRC 0x78 的滥用：部分 ECU 在简单服务上也发送 0x78，导致客户端等待时间过长，应通过测试识别并修正。
- 会话超时误判：测试时需注意 S3 计时是从最后一个请求开始计算，而非从会话建立开始。
- 安全访问锁定时间：锁定时间应从最后一次错误尝试开始计算，测试时需精确记录时间戳。
- DoIP 时序差异：以太网诊断的时序参数可能与 CAN 不同，需按 DoIP 规范单独验证。
- 环境因素：温度、电压变化可能影响 ECU 处理速度，时序测试应在不同环境条件下进行。
6. 总结
UDS 诊断模块的时序测试是确保诊断通信可靠性的关键环节。测试工程师需要围绕会话控制、服务响应、安全访问、刷写流程等核心场景，依据 ISO 14229-1 及 OEM 规范，设计覆盖正向、边界和反向的测试用例，并使用专业工具精确测量时间参数。只有严格验证各项时序，才能确保 ECU 在实际车辆环境中稳定、可靠地完成诊断与刷写任务。
