2、UDS协议基础：ISO 14229标准、服务ID（SID）与核心诊断机制
UDS（Unified Diagnostic Services，统一诊断服务）是ISO 14229标准定义的车载电子控制单元（ECU）诊断服务协议，广泛应用于Bootloader刷写、产线终检、售后故障排查等场景。在Bootloader开发中，UDS协议是上位机（Tester）与ECU底层软件之间唯一的“对话语言”。本章将围绕ISO 14229标准框架、服务ID（SID）的编码规则、诊断会话控制（0x10）与安全访问（0x27）两大核心机制展开深度剖析，帮助学员建立从协议规范到工程落地的完整认知。
上图展示了UDS协议在Bootloader场景下的核心机制关系。ISO 14229标准定义了统一的诊断服务框架，其中SID是服务标识符，用于区分不同的诊断功能；0x10服务负责会话模式切换，0x27服务负责安全校验。三者协同工作，构成了Bootloader刷写流程的基础链路。下面我们将逐一深入解析。
2.1 ISO 14229标准与SID编码规则
2.1.1 核心原理：标准分层与SID定义
ISO 14229标准（UDS）位于OSI模型的应用层（第7层），它不关心底层通信介质（CAN、LIN、FlexRay或以太网），而是定义了一套与传输层无关的诊断服务原语。在Bootloader场景中，UDS报文通常承载于CAN总线之上，通过CAN帧的8字节数据域传输。标准将诊断服务划分为六大类：诊断会话控制、数据读取/写入、输入输出控制、例程控制、上传/下载以及安全访问。每个服务由一个唯一的SID（Service ID）标识，SID占用报文数据域的第一个字节，取值范围为0x00~0x3E。
SID的编码遵循“请求-响应”模式。Tester发送请求帧（Request），ECU返回响应帧（Response）。响应帧的SID为请求SID加0x40（即最高位置1），用于区分请求与响应。例如，请求SID为0x10（诊断会话控制），则正常响应SID为0x50；若ECU无法执行该服务，则返回否定响应，SID为0x7F，并在后续字节中携带错误码（NRC，Negative Response Code）。
| SID（请求） | 服务名称 | 响应SID（正响应） | 典型应用场景 |
|---|---|---|---|
| 0x10 | 诊断会话控制 | 0x50 | 切换默认/编程/扩展会话 |
| 0x27 | 安全访问 | 0x67 | 解锁Bootloader刷写权限 |
| 0x34 | 请求下载 | 0x74 | 建立数据传输通道 |
| 0x36 | 数据传输 | 0x76 | 分块发送固件数据 |
| 0x37 | 请求退出传输 | 0x77 | 结束数据传输 |
| 0x31 | 例程控制 | 0x71 | 执行擦除、校验等例程 |
| 0x22 | 按ID读取数据 | 0x62 | 读取VIN、软件版本号 |
| 0x2E | 按ID写入数据 | 0x6E | 写入配置参数 |
2.1.2 判断方法：SID与NRC的对应关系
在实际开发中，工程师需要快速判断ECU返回的响应类型。正响应（SID+0x40）表示服务执行成功；否定响应（0x7F）表示执行失败，此时第三个字节为NRC码。常见的NRC码包括：0x10（一般拒绝）、0x12（子功能不支持）、0x13（报文长度错误）、0x22（条件不满足）、0x31（请求超出范围）、0x33（安全访问被拒绝）、0x35（无效密钥）等。在Bootloader刷写过程中，若上位机发送0x10 02（请求编程会话）后收到0x7F 10 22，说明ECU当前处于不可编程状态（例如发动机运转中），需要先满足前置条件。
#define SID_DIAG_SESSION_CONTROL 0x10，避免魔法数字散落各处。同时，响应SID的判断应使用 (requestSid + 0x40) 而非硬编码，以保持代码通用性。
2.1.3 案例拆解：Bootloader刷写中的SID交互序列
以一次典型的OTA固件刷写为例，上位机与ECU的交互序列如下：
- 上位机发送
0x10 02（请求进入编程会话），ECU返回0x50 02，表示已切换到编程会话。 - 上位机发送
0x27 01（请求种子），ECU返回0x67 01 [种子数据]。 - 上位机根据种子计算密钥，发送
0x27 02 [密钥]，ECU返回0x67 02，安全解锁成功。 - 上位机发送
0x31 01 02 01（例程控制-擦除Flash），ECU返回0x71 01，擦除完成。 - 上位机发送
0x34 00 44 [地址] [长度]（请求下载），ECU返回0x74 20 [块长度]。 - 上位机循环发送
0x36 01 [数据块]，ECU返回0x76 01，直至数据发送完毕。 - 上位机发送
0x37 01（请求退出传输），ECU返回0x77 01。 - 上位机发送
0x31 01 02 02（例程控制-校验），ECU返回0x71 01，校验通过。 - 上位机发送
0x11 01（ECU复位），刷写完成。
上述序列中，每个SID的请求和响应都遵循严格的状态机约束。例如，在未进入编程会话前发送0x34请求下载，ECU会返回NRC 0x7F 34 22（条件不满足）。
2.1.4 常见误区与总结
- 误区一：认为SID是固定不变的。实际上，OEM厂商可以在ISO 14229基础上扩展私有SID（如0x3E、0x3F），但必须遵循标准框架。
- 误区二：忽略响应SID的0x40偏移。部分初学者直接比较请求SID与响应SID，导致判断失败。
- 误区三：将NRC码与SID混淆。NRC是0x7F响应帧中的第三个字节，而非独立服务。
2.2 诊断会话控制（0x10）核心机制
2.2.1 核心原理：会话状态机与权限分级
诊断会话控制服务（0x10）用于切换ECU的诊断会话模式。ISO 14229定义了三种标准会话：默认会话（Default Session，0x01）、编程会话（Programming Session，0x02）和扩展会话（Extended Session，0x03）。此外，OEM可自定义会话（如0x04~0x7F）。不同会话模式下，ECU允许执行的诊断服务集合不同。例如，默认会话通常只允许读取故障码和基本数据；编程会话才允许执行0x34/36/37等刷写服务；扩展会话则开放写入参数、例程控制等高级功能。
会话切换的核心机制是“超时回退”。ECU内部维护一个会话定时器（通常为5秒），若在超时时间内未收到任何诊断请求，则自动回退到默认会话。这一机制防止ECU长时间停留在高权限会话中，降低安全风险。在Bootloader中，编程会话的超时时间通常可配置，但必须保证刷写过程中持续发送诊断请求（如周期性的0x3E服务）以维持会话。
2.2.2 操作流程：会话切换与维持
会话切换的请求帧格式为：0x10 [子功能]。子功能即目标会话ID。正响应帧为 0x50 [子功能] [P2*] [P2*_max]，其中P2*和P2*_max表示ECU在该会话下的响应时间参数（单位毫秒）。例如，请求进入编程会话：
请求：02 10 02 00 00 00 00 00
响应：06 50 02 00 32 01 F4 00响应中P2* = 0x0032（50ms），P2*_max = 0x01F4（500ms），表示ECU在编程会话下的正常响应时间为50ms，最大响应时间为500ms。上位机应根据该参数调整超时策略。
会话维持的常用方法是发送0x3E（Tester Present）服务。请求帧为 0x3E 00，ECU返回 0x7E 00。该服务不改变当前会话状态，仅重置会话定时器。
2.2.3 案例拆解：刷写过程中会话超时导致失败
背景：某ECU在Bootloader刷写过程中，上位机发送完0x34请求下载后，等待用户确认，耗时超过5秒，导致ECU回退到默认会话。后续发送0x36数据传输时，ECU返回NRC 0x7F 36 22（条件不满足）。
分析：ECU在编程会话下，若5秒内未收到任何诊断请求，自动回退到默认会话。默认会话不允许执行0x36服务，因此返回条件不满足。
解决方案：在上位机软件中增加会话维持机制。在等待用户确认期间，每2秒发送一次0x3E 00请求，保持编程会话有效。修改后，刷写流程顺利完成。
复盘：会话超时是Bootloader刷写中最常见的故障之一。工程上应在上位机中实现“心跳”线程，周期发送0x3E服务，并监控ECU的响应状态。
2.2.4 常见误区与总结
- 误区一：认为进入编程会话后可以一直停留。实际上，ECU的会话超时机制始终生效，必须持续维持。
- 误区二：忽略P2*参数。不同会话的响应时间不同，上位机应动态调整超时阈值。
- 误区三：在默认会话下直接发送刷写请求。必须先切换到编程会话，否则ECU会拒绝执行。
2.3 安全访问（0x27）核心机制
2.3.1 核心原理：种子-密钥校验与安全等级
安全访问服务（0x27）用于保护ECU中的敏感操作（如Flash擦写、配置修改）。其核心机制是“种子-密钥”（Seed-Key）校验：ECU生成一个随机种子（Seed），发送给Tester；Tester根据特定算法计算密钥（Key），返回给ECU；ECU校验密钥是否正确，若正确则解锁安全等级，允许执行受保护的服务。
ISO 14229定义了多个安全等级（Security Level），通过子功能区分。例如，0x27 01表示请求种子（等级1），0x27 02表示发送密钥（等级1）；0x27 03/04表示等级2的种子/密钥。不同等级对应不同的访问权限。在Bootloader中，通常使用等级1解锁刷写权限，等级2解锁更高级的配置操作。
安全访问的时序要求严格：ECU在发送种子后，会启动一个超时定时器（通常为1秒）。若Tester未在超时时间内发送密钥，ECU将丢弃种子并锁定安全访问，需重新请求。此外，ECU通常有尝试次数限制（如3次），超过次数后需等待一段时间（如10秒）才能再次尝试。
2.3.2 操作流程：安全解锁的完整步骤
安全解锁的流程如下：
- 请求种子：Tester发送
0x27 01，ECU返回0x67 01 [Seed]。Seed长度通常为2~4字节。 - 计算密钥：Tester根据Seed和内部算法计算Key。算法可能是简单的异或、CRC、AES或自定义查表法。
- 发送密钥：Tester发送
0x27 02 [Key]，ECU校验Key。 - 校验结果：若Key正确，ECU返回
0x67 02，解锁成功；若错误，返回0x7F 27 35（无效密钥）或0x7F 27 36（尝试次数超限）。
在Bootloader中，安全访问通常在进入编程会话后立即执行。解锁成功后，ECU会记录当前安全状态，允许执行0x34/36/37等刷写服务。
2.3.3 案例拆解：安全访问算法逆向与防重放
背景：某ECU的Bootloader使用固定密钥（Key = Seed ^ 0x5A5A），且种子为递增计数器。攻击者截获一次合法的种子-密钥对后，即可重放攻击。
分析：固定算法和可预测种子导致安全机制形同虚设。ISO 14229建议使用随机种子和加密算法，但部分低成本ECU仍使用简单算法。
改进方案：在Bootloader中引入真随机数发生器（TRNG）生成种子，并使用AES-128算法计算密钥。同时，增加防重放机制：ECU记录最近使用的种子，若收到重复种子则拒绝响应。
复盘：安全访问的强度取决于算法保密性和种子随机性。工程上应至少使用CRC32或自定义混淆算法，并确保种子不可预测。
2.3.4 常见误区与总结
- 误区一：认为安全访问是可选功能。实际上，几乎所有量产ECU的Bootloader都要求安全解锁后才能刷写。
- 误区二：忽略尝试次数限制。连续多次发送错误密钥会导致ECU锁定，需等待解锁时间。
- 误区三：在非安全状态下发送刷写请求。ECU会返回NRC 0x33（安全访问被拒绝）。
2.4 本章知识结构总览
| 核心机制 | 关键参数 | 常见NRC | Bootloader应用要点 |
|---|---|---|---|
| SID编码 | SID范围0x00-0x3E，响应SID=请求+0x40 | 0x12（子功能不支持） | 维护SID宏定义，避免硬编码 |
| 会话控制（0x10） | 会话ID、P2*超时、会话定时器 | 0x22（条件不满足） | 刷写前切换编程会话，周期发送0x3E维持 |
| 安全访问（0x27） | 种子长度、密钥算法、尝试次数 | 0x33（安全拒绝）、0x35（无效密钥） | 解锁后执行刷写，注意防重放 |