深入理解UDS诊断协议：从会话控制到安全访问的实战解析

在现代汽车电子系统中，ECU（电子控制单元）的数量早已突破百个。随着功能复杂度飙升，传统的OBD-II诊断标准已无法满足对深度故障读取、固件刷写和参数标定的需求。此时，统一诊断服务（Unified Diagnostic Services,UDS）作为ISO 14229定义的核心协议，成为连接诊断仪与ECU之间的“通用语言”。

但面对复杂的通信流程、层层嵌套的状态机以及严苛的时序要求，很多工程师在初次接触UDS时都会感到无从下手——为什么切换会话后还要解锁？种子是怎么生成的？数据怎么分帧传输？本文不讲空泛理论，而是带你一步步拆解真实场景下的UDS交互逻辑，用代码+图示的方式还原每一个关键步骤。

UDS不是“发命令-收回复”那么简单

很多人误以为UDS就是“我发一个0x22读VIN，它回个字符串”，其实远非如此。真实的UDS通信是一个状态驱动的过程，就像进入一间保险库：你不能直接拿走文件，必须先刷卡进入大厅（默认会话），再通过身份验证（安全解锁），最后才能打开特定抽屉（执行服务）。

整个过程依赖于一套清晰的五阶段通信模型：

1. 物理连接建立（CAN总线通电初始化）
2. 会话模式切换（Default → Extended/Programming）
3. 安全访问认证（Seed-Key挑战机制）
4. 执行诊断服务（读DID、刷写等）
5. 响应处理与错误反馈（正响应/NRC）

任何一步失败，后续操作都将被拒绝。下面我们以三个最常用的服务为例，逐层深入剖析其内在机制。

阶段一：诊断会话控制（SID: 0x10）——打开高级功能的钥匙

为什么要分“会话”？

ECU上电后默认处于Default Session（默认会话）。在这个状态下，仅允许执行基本诊断功能，如读取故障码或实时数据流。而像刷写程序、修改标定参数这类高风险操作，则必须先进入Extended Diagnostic Session或Programming Session。

这相当于操作系统中的“用户模式”与“管理员权限”的区别——防止误操作导致系统崩溃。

请求与响应格式详解

客户端发送请求：

[PCI][SID][SubFunction] | | | v v v 0x02 0x10 0x03 → 请求进入扩展会话

• PCI=0x02：表示这是一个单帧（Single Frame），数据长度为2字节
• SID=0x10：调用“诊断会话控制”服务
• SubFunction=0x03：目标是切换到扩展会话

服务器返回正响应：

0x03 0x50 0x03 0x00 0x1F

• 0x50 = 0x10 + 0x40：这是UDS的约定，正响应SID = 原SID + 0x40
• 0x03：确认当前已切换至扩展会话
• 0x001F：会话定时器最小值，单位毫秒（即31ms），超时则自动退回默认会话

⚠️ 注意：若ECU正处于某种保护状态（如正在执行关键任务），即使收到合法请求也会返回 NRC0x22（Conditions Not Correct），说明当前不允许切换。

实际代码如何实现？

typedef enum { SESSION_DEFAULT = 0x01, SESSION_PROGRAMMING = 0x02, SESSION_EXTENDED = 0x03, } UdsSessionType; static UdsSessionType current_session = SESSION_DEFAULT; static uint16_t session_timeout_ms = 0; void HandleDiagnosticSessionControl(uint8_t *req, uint16_t len) { if (len < 2) { SendNegativeResponse(0x10, NRC_INCORRECT_MESSAGE_LENGTH); return; } uint8_t target_session = req[1]; switch(target_session) { case SESSION_DEFAULT: SetSessionMode(SESSION_DEFAULT); break; case SESSION_EXTENDED: if (CanEnterExtendedSession()) { // 条件检查 SetSessionMode(SESSION_EXTENDED); ResetSessionTimer(0x001F); // 启动超时计时器 uint8_t resp[] = {0x50, 0x03, 0x00, 0x1F}; SendResponse(resp, 4); return; } else { SendNegativeResponse(0x10, NRC_CONDITIONS_NOT_CORRECT); return; } default: SendNegativeResponse(0x10, NRC_SUB_FUNCTION_NOT_SUPPORTED); return; } // 默认会话只需确认即可 uint8_t resp[] = {0x50, target_session}; SendResponse(resp, 2); }

✅ 关键点总结：
- 必须进行条件判断（如是否正在刷写、是否有其他诊断活动）
- 切换成功后需重置会话定时器
- 返回的定时器值由ECU能力决定，不可随意设定

阶段二：安全访问（SID: 0x27）——防止非法刷写的防火墙

即便进入了扩展会话，也不能随意修改敏感数据。这就是Security Access的作用：采用“挑战-响应”机制，确保只有授权设备可以执行写操作。

种子-密钥机制工作流程

该过程分为两个子步骤，且顺序严格固定：

第一步：请求种子（Request Seed）

客户端发起请求：

0x02 0x27 0x05 → 请求第5级安全访问的种子

ECU生成随机数并返回：

0x06 0x67 0x05 0xAA 0xBB 0xCC 0xDD

• 0x67 = 0x27 + 0x40：正响应标识
• 0x05：对应的安全等级
• 0xAABBCCDD：本次会话唯一的随机种子（Seed）

第二步：发送密钥（Send Key）

客户端使用预存算法计算密钥：

key = custom_hash(seed) # 算法由厂商定义，通常基于AES或HMAC

然后发送：

0x06 0x27 0x06 0xKK 0xKK 0xKK 0xKK

注意：这里的0x06是偶数，表示“回应密钥”。奇数用于请求种子，偶数用于提交密钥，这是UDS的标准编码规则。

如果密钥正确，ECU返回：

0x02 0x67 0x06

否则返回 NRC：
-0x35：Invalid Key（密钥错误）
-0x24：Attempt Failed Limit Exceeded（尝试次数超限）

如何防爆破攻击？

为了防止暴力破解，ECU端必须实现以下机制：

完整代码实现（含防重放攻击）

#define SECURITY_LEVEL 0x05 #define MAX_ATTEMPTS 3 #define LOCK_DURATION_MS 5000 uint8_t current_seed[4]; bool seed_valid = false; uint8_t attempt_count = 0; uint32_t lock_start_time = 0; void HandleSecurityAccess(uint8_t *req, uint16_t len) { uint8_t subFunc = req[1]; // 检查是否处于锁定状态 if (IsLocked()) { SendNegativeResponse(0x27, NRC_EXCEED_NUMBER_OF_ATTEMPTS); return; } if (subFunc & 0x01) { // 奇数：请求种子 if (subFunc == (SECURITY_LEVEL | 0x01)) { GenerateTrueRandomSeed(current_seed, 4); seed_valid = true; attempt_count = 0; // 成功发放种子，重置尝试计数 uint8_t resp[6] = {0x06, 0x67, subFunc, current_seed[0], current_seed[1], current_seed[2], current_seed[3]}; SendResponse(resp, 6); } else { SendNegativeResponse(0x27, NRC_SUB_FUNCTION_NOT_SUPPORTED); } } else { // 偶数：发送密钥 if (!seed_valid) { SendNegativeResponse(0x27, NRC_SEQUENCE_ERROR); // 未先请求种子 return; } if ((subFunc >> 1) != SECURITY_LEVEL) { SendNegativeResponse(0x27, NRC_SECURITY_ACCESS_DENIED); return; } uint8_t received_key[4]; memcpy(received_key, &req[2], 4); uint8_t expected_key[4]; CalculateKeyFromSeed(current_seed, expected_key); // 厂商私有算法 if (memcmp(received_key, expected_key, 4) == 0) { MarkSecurityLevelPassed(SECURITY_LEVEL); SendPositiveResponse(0x67, &subFunc, 1); seed_valid = false; // 一次性使用 attempt_count = 0; } else { attempt_count++; if (attempt_count >= MAX_ATTEMPTS) { StartLockTimer(); // 触发锁定 } SendNegativeResponse(0x27, NRC_INVALID_KEY); } } }

✅ 关键设计思想：
-种子只能用一次：防止重放攻击
-奇偶区分请求方向：避免混淆流程
-锁定机制独立于会话：即使重启会话也无法绕过

阶段三：按标识符读取数据（SID: 0x22）——实现参数透明化

完成前两步后，我们终于可以开始真正的诊断服务了。最常见的就是ReadDataByIdentifier（简称RID），通过一个两字节的DID来读取内部数据。

DID命名规范（你知道F190代表什么吗？）

例如：

请求：0x03 0x22 0xF1 0x90 → 读取VIN 响应：0x0A 0x62 0xF1 0x90 'L''S''V''A''B''C''D''E'

其中0x0A表示应用层数据共10字节（含SID和DID），后续8字节为实际VIN内容。

多帧传输怎么办？

当数据长度超过7字节（单帧CAN payload上限），就需要启用ISO 15765-2 分段机制：

1. ECU发送首帧（First Frame, FF）：
   0x10 0x0A 0x62 ... → 表示总共10字节数据
2. 诊断仪回复流控帧（Flow Control, FC）：
   0x30 0x00 0x05 0x00 → 允许连续发送5帧
3. ECU依次发送连续帧（Consecutive Frame, CF）：
   0x21 ... 0x22 ...

这套机制确保大数据块也能可靠传输，常用于读取完整标定表或日志记录。

查表式服务实现（适合量产项目）

typedef struct { uint16_t did; const uint8_t* data; uint8_t length; bool readable; } DidDescriptor; // 全局DID映射表（可动态注册） DidDescriptor g_DidTable[] = { {0xF190, (uint8_t*)"LSVABCDE", 8, true}, // VIN {0xF187, g_sw_version, 4, true}, // 软件版本 {0xF200, g_calibration_data, 256, true}, // 标定区（长数据） }; void HandleReadDataByIdentifier(uint8_t *req, uint16_t len) { if (len != 3) { SendNegativeResponse(0x22, NRC_INCORRECT_MESSAGE_LENGTH); return; } uint16_t requested_did = (req[1] << 8) | req[2]; for (int i = 0; i < ARRAY_SIZE(g_DidTable); ++i) { if (g_DidTable[i].did == requested_did && g_DidTable[i].readable) { BuildAndSendResponse(0x62, req[1], req[2], g_DidTable[i].data, g_DidTable[i].length); return; } } SendNegativeResponse(0x22, NRC_REQUEST_OUT_OF_RANGE); }

✅ 设计优势：
- 易于扩展新DID
- 支持静态/动态数据源
- 可结合权限控制系统（某些DID仅在安全解锁后可见）

一个完整的刷写流程长什么样？

让我们把前面的知识串起来，看看一次OTA固件升级是如何通过UDS实现的：

1. 物理连接建立
   - 诊断仪通过OBD口接入CAN FD网络
   - 发送寻址请求识别目标ECU

2. 进入编程会话
   c → 0x02 0x10 0x02 ← 0x03 0x50 0x02 0x00 0x1F

3. 安全解锁（Level 0x03）
   c → 0x02 0x27 0x03 // 请求种子 ← 0x06 0x67 0x03 0xAA 0xBB 0xCC 0xDD → 0x06 0x27 0x04 0x12 0x34 0x56 0x78 // 提交密钥 ← 0x02 0x67 0x04 // 解锁成功

4. 请求下载（指定地址与大小）
   c → 0x08 0x34 0x00 0x44 0x00 0x00 0x10 0x00 // 地址0x1000, 大小0x4400字节 ← 0x03 0x74 0x00 // 准备接收

5. 传输数据（分批发送）
   c → [CF] 0x21 xx xx ... ← [FC] 0x30 0x00 0x0A 0x00 // 流控：允许连续发10帧

6. 请求退出传输
   c → 0x01 0x37 ← 0x01 0x77

7. 触发刷写（例程控制）
   c → 0x04 0x31 0x01 0xFF 0x01 // 启动烧录例程 ← 0x04 0x71 0x01 0xFF 0x01

8. 复位ECU
   c → 0x02 0x11 0x01 // 硬件复位

每一步都有明确的响应机制和错误兜底策略，构成了一个高度可靠的刷写通道。

工程实践中那些“踩过的坑”

❌ 坑点1：忘记刷新会话定时器

现象：长时间无操作后突然发命令失败
原因：会话超时自动退回到默认会话
✅ 秘籍：定期发送TesterPresent (0x3E)保活

→ 0x01 0x3E 0x80 // 抑制正响应（静默保活）

❌ 坑点2：种子重复使用

现象：第二次提交相同密钥居然通过了
危害：存在重放攻击漏洞
✅ 秘籍：每次请求种子都应生成新的随机值，并立即作废旧种子

❌ 坑点3：多帧传输未处理流控

现象：ECU发送太快导致缓冲区溢出
✅ 秘籍：严格按照ISO 15765-2实现流控逻辑，特别是Block Size和STmin字段

写在最后：UDS不只是协议，更是系统思维的体现

掌握UDS，本质上是在训练一种状态机驱动的开发思维。它教会我们：

• 任何操作都不能脱离上下文环境
• 安全机制必须贯穿始终
• 错误反馈要足够精细，便于追溯

随着DoIP（基于以太网的诊断）和SOME/IP的普及，UDS正在向更高带宽、更低延迟的方向演进，但它核心的设计哲学不会变：有序、可控、可追溯。

如果你正在做汽车电子、智能驾驶域控或OTA系统开发，不妨从今天起，亲手实现一个最小化的UDS协议栈。你会发现，那些看似繁琐的流程背后，藏着的是工程世界对“可靠性”的极致追求。

如果你在实现过程中遇到了具体问题，比如“如何生成真随机种子？”、“多ECU并发访问怎么协调？”，欢迎在评论区留言讨论。