ECU诊断基础：诊断协议（UDS、OBD-II）、诊断服务（SID）、诊断会话与安全访问

现代车辆电子电气架构中，ECU（电子控制单元）不仅是执行控制逻辑的节点，更是整车故障信息、标定参数和软件状态的载体。诊断协议是外部诊断仪（Tester）与ECU之间进行信息交互的“语言规则”，它定义了物理层、数据链路层和应用层的通信规范。在《诊断实战项目：ECU诊断功能验证》课程中，理解UDS（统一诊断服务）与OBD-II（车载诊断系统第二代）的差异、掌握SID（服务标识符）的语义、熟悉诊断会话切换与安全访问解锁机制，是后续编写诊断测试用例、解析DTC（诊断故障码）和进行Bootloader刷写验证的基石。本章将围绕这四个核心概念展开，结合ISO 14229、ISO 15765和SAE J1979标准，从原理到实战逐一拆解。

2.1 诊断协议：UDS与OBD-II的定位与协同

核心原理：两种协议的分工逻辑

UDS（Unified Diagnostic Services，统一诊断服务）定义在ISO 14229标准中，是面向整车所有ECU的通用诊断应用层协议。它不依赖特定总线，可运行于CAN、CAN-FD、LIN、FlexRay和以太网（DoIP）之上。UDS的核心特点是“服务导向”，通过不同的SID（Service Identifier）实现读取数据、写入参数、控制输入输出、清除故障码等功能。OBD-II（On-Board Diagnostics II）则源自美国加州CARB法规和SAE J1979标准，其初衷是监控排放相关系统（发动机、变速箱、三元催化器、氧传感器等）的实时状态和故障信息，以满足法规合规性要求。OBD-II的服务集合是UDS的一个子集，但OBD-II强制规定了标准DID（如车速、转速、冷却液温度）和标准DTC格式（如P0xxx、P1xxx），而UDS允许OEM自定义扩展。

判断方法：如何区分UDS与OBD-II报文

• 报文ID范围：OBD-II通常使用11位标准帧ID（如0x7E8/0x7E0），UDS在CAN上常用29位扩展帧ID（如0x18DA10F1），但部分OEM也使用11位ID。
• 服务ID范围：OBD-II服务ID固定为0x01~0x0A（如0x01请求当前数据、0x03读取DTC），UDS服务ID范围更广（0x10~0x3E），且支持子功能参数。
• DTC格式：OBD-II的DTC为2字节（如P0101），UDS的DTC为3字节（如0xC00101），包含故障类型和属性。
• 寻址方式：OBD-II采用功能寻址（广播到所有ECU），UDS支持物理寻址（点对点）和功能寻址（广播）。

实战场景：诊断仪协议栈自动切换

在某OEM的售后诊断仪开发中，诊断仪连接车辆后首先发送OBD-II模式0x01请求VIN（车辆识别码），若ECU响应则进入OBD-II模式；若超时无响应，则切换至UDS物理寻址发送0x22 F1 90读取VIN。这种“先OBD后UDS”的策略确保了兼容性。实际测试中发现，部分ECU在默认会话下不响应OBD-II请求，但响应UDS的0x10 01会话切换。因此，诊断仪需要维护一张“ECU能力矩阵表”，记录每个ECU支持的协议类型和会话能力。

2.2 诊断服务（SID）：指令集与报文结构

核心原理：SID是诊断操作的“操作码”

UDS协议中，每个诊断请求报文的首字节即为SID。SID分为请求SID（由Tester发送）和响应SID（由ECU回复）。响应SID = 请求SID + 0x40。例如，请求0x22（按标识符读取数据），正常响应为0x62；若ECU收到无法识别的SID，则返回0x7F（否定响应），并附带NRC（否定响应码）说明原因。SID按功能可分为六大类：诊断会话管理（0x10、0x11、0x3E）、数据读取（0x22、0x23、0x24）、数据写入（0x2E、0x2F）、故障管理（0x14、0x19、0x85）、输入输出控制（0x2F、0x31）、安全与通信（0x27、0x28、0x29）。

操作流程：构造一个UDS诊断请求

1. 确定目标ECU：根据诊断需求选择物理寻址（指定ECU）或功能寻址（广播）。
2. 选择SID：例如读取ECU软件版本号，使用0x22服务，DID为0xF1 90。
3. 封装报文：CAN物理层发送：ID（如0x18DA10F1）+ 数据场（02 22 F1 90），其中02表示后续数据长度。
4. 等待响应：ECU回复0x62 F1 90 01 02 03 04，解析数据。
5. 异常处理：若收到0x7F 22 31（请求超出范围），检查DID是否支持或当前会话是否允许。

// 示例：读取ECU软件版本号（DID 0xF1 90）
请求: 02 22 F1 90
响应: 06 62 F1 90 01 02 03 04  // 版本号 01.02.03.04
否定: 03 7F 22 31              // NRC=0x31 请求超出范围

案例拆解：SID组合应用完成一次完整诊断流程

在ECU下线检测（EOL）场景中，测试序列如下：①发送0x10 03切换到扩展会话；②发送0x27 05请求种子，ECU返回种子值；③发送0x27 06发送密钥，解锁安全访问；④发送0x2E F1 F2写入车辆配置参数；⑤发送0x11 01复位ECU使配置生效。整个流程涉及会话管理、安全访问、数据写入和ECU复位四个SID。测试中发现，若步骤②和③之间间隔超过5秒，ECU会因安全超时返回NRC 0x36（超过延迟时间），因此测试脚本必须严格控制时序。

2.3 诊断会话与安全访问：状态机与门禁机制

核心原理：会话是ECU诊断功能的“权限等级”

UDS定义了多种诊断会话，常见的有默认会话（Default Session，0x01）、编程会话（Programming Session，0x02）和扩展会话（Extended Session，0x03）。默认会话是ECU上电后的初始状态，仅允许读取DTC和部分数据；扩展会话允许写入参数和执行例程；编程会话专用于Bootloader刷写，禁止应用层通信。会话之间通过0x10服务切换，ECU内部维护一个S3Server定时器（通常为5秒），若在超时时间内未收到任何诊断请求，ECU自动回退到默认会话。安全访问（0x27服务）是另一道门禁，用于保护敏感操作（如写入配置、刷写Flash）。其流程为：Tester发送0x27 01请求种子，ECU返回随机种子；Tester使用特定算法计算密钥并发送0x27 02；ECU验证密钥正确后解锁，解锁状态在会话切换或ECU复位后失效。

判断方法：会话与安全访问的依赖关系

• 会话优先级：编程会话 > 扩展会话 > 默认会话。高等级会话可以切换到低等级，反之需要先切换。
• 安全访问限制：部分ECU要求必须在扩展会话下才能请求种子，默认会话下发送0x27会返回NRC 0x7F（服务不支持）或0x22（条件不满足）。
• 会话切换副作用：从扩展会话切换到默认会话会清除安全解锁状态，但不会清除DTC。
• 定时器监控：测试时需周期性发送0x3E（保持激活）防止会话超时，但0x3E不会重置安全访问的解锁计时器。

实战场景：安全访问解锁失败排查

在某项目测试中，诊断仪发送0x27 05请求种子，ECU返回种子0x12345678，但发送0x27 06密钥后收到NRC 0x35（无效密钥）。排查过程：①确认算法版本，OEM提供了两种密钥算法（AES-128和自定义CRC），诊断仪默认使用AES，但ECU实际配置为CRC算法；②检查种子字节序，ECU返回的种子为小端序，而诊断仪按大端序解析；③确认解锁等级，0x05/0x06对应等级1，但该ECU要求等级3（0x07/0x08）。修正后解锁成功。此案例说明，安全访问的种子长度、算法、字节序和等级必须与ECU的软件配置严格匹配。

2.4 常见误区与工程实践要点

误区一：混淆UDS与OBD-II的DTC格式

UDS的DTC为3字节，其中前2字节为故障码，第3字节为故障类型（如0x00表示无故障、0x01表示信号超时、0x02表示信号无效）。OBD-II的DTC为2字节，且编码规则不同（如P0101表示进气压力传感器范围/性能问题）。在诊断仪界面显示时，必须根据协议类型选择对应的解析规则，否则会出现“DTC显示乱码”或“故障码无法清除”的问题。

误区二：忽略会话超时导致测试中断

在长时间运行的诊断测试（如耐久性测试）中，若测试脚本未发送0x3E保持激活报文，ECU会在5秒后回退到默认会话，导致后续的0x2E写入操作失败。解决方法是：在测试循环中每2秒发送一次0x3E，并监控响应。但注意，0x3E的响应是0x7E，若ECU无响应，说明通信链路可能中断。

误区三：安全访问密钥算法硬编码

部分测试团队将密钥算法硬编码在测试脚本中，当ECU软件升级后算法变更，测试立即失败。建议将密钥算法封装为独立的动态链接库（DLL）或配置文件，测试框架通过接口调用，便于算法更新和版本管理。

本章从协议分层、服务定义、会话管理和安全机制四个维度构建了ECU诊断的基础框架。在实际项目中，诊断工程师需要根据ECU的通信矩阵（Communication Matrix）和诊断规范（Diagnostic Specification）来配置具体的报文ID、DID和SID。下一阶段，我们将基于这些基础概念，深入探讨如何设计诊断测试用例，以及如何利用自动化工具执行回归测试。