UDS会话层级结构图解说明-编程阁

深入理解UDS会话层级：从启动到刷写，一文掌握诊断状态机核心逻辑

在汽车电子开发的日常中，你是否曾遇到这样的场景？
OTA升级时固件传输突然中断；安全访问反复失败却无明确报错；调试工具无法触发执行器动作……
这些问题背后，往往不是通信链路或代码逻辑出了问题，而是会话状态没对上。

统一诊断服务（Unified Diagnostic Services,UDS）作为现代车辆诊断系统的“通用语言”，其核心并不仅仅是那些以22读数据、14清故障码的服务指令。真正决定这些指令能否生效的关键，在于一个贯穿始终的机制——会话管理（Session Management）。

本文将带你穿透协议文档的术语迷雾，用工程师的视角拆解UDS的会话层级结构。我们将从ECU上电那一刻讲起，一步步解析它是如何通过“会话”这扇门，控制外部世界能看什么、改什么、做些什么。无论你是正在开发Bootloader、集成AUTOSAR诊断栈，还是在售后支持一线排查问题，这篇文章都会让你对诊断流程有更本质的理解。

一切始于Default Session：诊断世界的“默认入口”

当你的ECU完成上电复位，CAN控制器初始化完毕后，它并不会静默等待。相反，它已经悄悄进入了一个预设的诊断状态——Default Session（默认会话），对应会话ID为0x01。

这个状态不需要任何请求就能自动激活。换句话说，只要ECU活着，并且能通信，它就在Default Session里。

它允许你做什么？

在这个模式下，你可以安全地执行以下操作：
- 读取DTC（19服务）
- 查询VIN、 Calibration ID等车辆信息（22+ DID）
- 获取当前运行状态（如发动机转速、车速）

这些都是“只读”类操作，不会影响ECU的功能行为。你可以把它想象成进了一家店，只能看商品不能碰——这是系统设计上的最小权限原则。

为什么必须有超时机制？

有趣的是，UDS规定：如果一段时间内没有收到任何诊断请求，ECU必须自动返回Default Session。即使你之前进入了编程模式，也会被强制退出。

这个设计非常关键。试想一下，如果一次刷写中途断电，下次上电时ECU还停留在Programming Session，那岂不是任何人都可以继续写Flash？超时回归Default Session，相当于给系统加了一道“自动锁门”的保险。

✅ 实践建议：在实际项目中，即使Default Session是开放的，也应限制敏感DID的访问，比如密钥存储区、算法校验值等。别让“基础权限”变成信息泄露的突破口。

编程会话（Programming Session）：固件更新的专属通道

当你需要给ECU刷写新程序时，就不能再待在“只读区”了。你需要进入一个更高权限的空间——Programming Session（编程会话），会话ID为0x02。

如何进入？一条命令即可

诊断仪发送：

10 02

ECU若允许，则回应：

50 02

看似简单，但这背后是一整套防护机制的开启。

进入之后能做什么？

一旦成功切换，你就可以调用一系列高风险服务：
-27Security Access：解锁写权限
-31Routine Control：例如擦除Flash扇区
-34Request Download：准备接收数据
-36Transfer Data：真正传输二进制块
-37Request Exit Transfer：结束传输

这一连串操作构成了完整的Flash编程生命周期。

关键限制：它不是随时可用的

注意，并非所有情况下都能进入Programming Session。通常要求满足以下条件之一：
- ECU处于生产模式（Production Programming Mode）
- 车辆未处于行驶状态（如P挡、熄火）
- 没有活跃的安全告警（如碰撞信号触发）

这也是为什么你在车上直接连诊断仪，大概率无法进入编程模式——系统主动拒绝了潜在的风险操作。

一段真实的处理代码

void Uds_HandleSessionControl(uint8_t *reqData, uint32_t reqLen) { if (reqLen < 2) return; uint8_t sessionId = reqData[1]; switch(sessionId) { case 0x01: EnterDefaultSession(); break; case 0x02: // 必须在特定模式下才允许进入编程会话 if (IsVehicleInProgrammingMode()) { EnterProgrammingSession(); Uds_SendResponse(0x50, 0x02); } else { Uds_SendNegativeResponse(NRC_CONDITIONS_NOT_CORRECT); } break; default: Uds_SendNegativeResponse(NRC_SUB_FUNCTION_NOT_SUPPORTED); break; } }

这段代码的核心在于IsVehicleInProgrammingMode()的判断。它可能是基于K-line唤醒、专用硬件引脚拉高，或是通过某种产线协议激活的标志位。这种“环境感知”能力，正是嵌入式诊断系统智能化的体现。

⚠️ 常见坑点：很多刷写失败并不是因为数据传输出错，而是会话超时。长时间没有交互，ECU自动退回Default Session，后续的36传输就会收到NRC_SESSION_INCORRECT错误。解决办法很简单：定期发一条3E 80（Tester Present）保活。

扩展诊断会话（Extended Diagnostic Session）：工程师的秘密武器

如果说Programming Session是为了刷写服务，那么Extended Diagnostic Session（扩展会话，ID: 0x03）就是为研发和调试而生的“超级模式”。

在这里，你可以：
- 主动驱动执行器（如点亮某个灯、打开继电器）
- 启用高频数据流记录（用于标定或故障复现）
- 修改PID参数、关闭故障检测逻辑
- 输出内部调试日志到CAN总线

这些功能在量产车中通常是禁用的，但在开发阶段却是不可或缺的利器。

它为何需要双重验证？

进入扩展会话，往往不只是发个10 03那么简单。典型实现如下：

bool CanEnterExtendedSession(void) { return (g_securityLevel >= SECURITY_LEVEL_2) && (g_vehicleMode == VEHICLE_MODE_DEBUG); } void EnterExtendedDiagnosticSession(void) { if (CanEnterExtendedSession()) { g_currentSession = SESSION_EXTENDED; EnableExtendedServices(); StartDiagTimer(DIAG_SESSION_TIMEOUT_LONG); // 可设置更长超时 } else { Uds_SendNegativeResponse(NRC_SECURITY_ACCESS_DENIED); } }

这里有两个门槛：
1.安全等级 ≥ Level 2：意味着你已经完成了至少一轮Challenge-Response认证
2.车辆处于DEBUG模式：通常由编译宏控制，出厂后即关闭

这种“双因素”控制极大提升了安全性，防止恶意设备滥用高级功能。

📌 经验之谈：我们曾在一个项目中发现，某供应商的ECU即使在正式版固件中仍保留了扩展会话入口。结果导致第三方设备可通过诊断协议完全控制系统——这就是典型的攻击面未裁剪问题。务必在发布前通过编译开关移除非必要功能。

安全访问（Security Access）：通往高权限的“钥匙机制”

虽然Security Access（SA）本身不属于会话类型，但它与会话跃迁紧密绑定，堪称整个UDS权限体系的“密码学基石”。

它是怎么工作的？

采用经典的挑战-响应（Challenge-Response）机制：
1. 客户端请求进入受保护功能（如27 05请求Seed）
2. ECU生成随机数（Seed）并通过67 05 [seed]返回
3. 客户端使用预共享算法计算Key（例如AES加密Seed）
4. 发送27 06 [key]
5. ECU本地计算预期Key，比对一致则提升安全等级

整个过程无需传输密钥，有效防范窃听。

安全等级与会话之间的联动关系

当前会话	目标操作	所需安全等级
Default	写入参数（`2E`）	Level 1
Default	进入编程会话	Level 1
Programming	开始刷写	Level 2 或更高
Extended	执行高危例程	Level 2

可以看到，UDS构建的是一个“会话 + 安全等级”二维权限模型。只有两个维度都达标，才能执行对应操作。这种分层防御思想，在功能安全（ISO 26262）和网络安全（ISO/SAE 21434）中都被广泛推崇。

🔐 安全提醒：Seed必须由真随机源生成，避免可预测性；Key计算应在安全环境中完成（如HSM模块），防止侧信道攻击（如功耗分析）。

实际工作流还原：一次完整的ECU刷写全过程

让我们把前面的知识串起来，看看在真实场景中，一次OTA升级是如何依赖会话切换推进的。

步骤分解

建立连接
- 诊断仪上线 → 发送10 01→ ECU进入Default Session
切换至编程模式
- 发送10 02→ 收到50 02→ 成功进入Programming Session
安全解锁
- 请求Seed：27 05→ 收到67 05 ab cd ef 01
- 计算Key → 回传：27 06 [key]→ 收到正响应 → 安全等级升至Level 2
开始刷写
-31 01 xx：执行前置例程（如关闭看门狗、擦除Flash）
-34：Request Download，告知将要传输的数据地址和长度
- 循环执行36：逐包发送数据帧
-37：请求退出传输，确认完整性
收尾操作
-10 01：返回Default Session
-14：清除旧版本可能产生的临时DTC
- 复位ECU，启用新固件

整个过程中，每一个环节都依赖正确的会话状态。任何一个步骤状态不匹配，都会导致负响应（Negative Response Code, NRC），例如：
-NRC_SUB_FUNCTION_NOT_SUPPORT：不支持该会话
-NRC_SECURITY_ACCESS_DENIED：未解锁
-NRC_INCORRECT_SESSION：当前会话不允许此操作

工程设计中的关键考量点

掌握了原理，接下来是如何落地的问题。以下是我们在多个项目中总结出的设计要点：

1. 合理会话超时设置

Default Session：5~10秒（快速释放资源）
Programming / Extended Session：可达几分钟（适应大数据传输）

2. 状态迁移合法性检查

禁止非法跳转，例如：
- ❌ 不允许从Programming直接跳到Extended
- ✅ 必须先回Default，再申请新会话

这可以通过状态机严格约束：

typedef enum { STATE_DEFAULT, STATE_PROGRAMMING, STATE_EXTENDED, } UdsSessionState; // 判断是否允许切换 bool IsSessionTransitionAllowed(UdsSessionState from, UdsSessionState to) { if (to == STATE_DEFAULT) return true; // 任何状态都可返回default if (from == STATE_DEFAULT) return true; // default可前往任意 return false; // 其他直接跳转均禁止 }

3. 日志追踪必不可少

关键事件打时间戳：
- “12:34:56.789 – Entered Programming Session”
- “12:35:01.234 – Security Level upgraded to Level 2”

这对后期问题追溯极为重要，尤其是在现场刷写出错时。

4. AUTOSAR兼容性处理

如果你使用的是AUTOSAR架构，推荐通过标准模块进行管理：
-Dcm模块：负责会话控制服务（SID 0x10）的解析与调度
-Dem模块：管理DTC相关行为
-FiM模块：功能抑制，可在特定会话下屏蔽某些报警

遵循AUTOSAR规范不仅能提高可移植性，还能更好地对接主流工具链（如ETAS INCA、Vector CANoe）。

写在最后：会话管理不只是协议细节，更是系统思维的体现

UDS的会话层级，表面看是一个简单的状态机，实则蕴含着深厚的工程哲学。

它用最基础的方式回答了三个问题：
-谁可以访问？→ 通过Security Access认证身份
-能做什么？→ 由当前会话决定服务可用性
-持续多久？→ 超时机制确保状态最终收敛

这套机制不仅支撑了今天的OBD、OTA、远程诊断，也为未来SOA（面向服务的架构）下的跨域诊断提供了演进基础。随着域控制器和中央计算平台的普及，UDS可能会与SOME/IP共存，但其“分权控制、按需授权”的设计理念仍将延续。

掌握UDS会话层级，不只是为了读懂ISO 14229文档，更是为了建立起一种分层管控、安全优先的系统级开发思维。下次当你面对一个诊断问题时，不妨先问一句：现在是什么会话状态？

如果你在实现过程中遇到了其他挑战，欢迎在评论区分享讨论。

UDS会话层级结构图解说明