在 UDS（统一诊断服务）的几十种诊断服务中，10 服务（会话控制服务，Session Control Service）是 “入门级” 却又 “核心级” 的存在 —— 它像 ECU（电子控制单元）的 “模式切换开关”，所有高权限诊断操作（如读取标定数据、刷写程序），都必须先通过 10 服务切换到对应会话才能执行。今天我们聚焦 10 服务，从原理到实战，彻底搞懂它的功能、流程与应用。
一、10 服务是什么？为什么它是 UDS 的 “入口”？
先明确一个核心认知：ECU 的诊断模式不是 “一刀切” 的。
车辆正常行驶时，ECU 只需提供基础诊断功能（如读取故障码），若此时允许高权限操作（如修改标定参数），不仅有安全风险（比如误改发动机参数导致故障），还会额外消耗算力与电量。而在研发调试、维修刷写时，又需要 ECU 开放更多功能。
10 服务的本质，就是通过标准化指令，让 ECU 在不同 “诊断会话” 间切换，实现 “按需开放权限”—— 它是所有高权限 UDS 服务（如 27 安全访问、34 程序刷写）的 “前置条件”，没有 10 服务的会话切换，后续操作都会被 ECU 拒绝。
简单说：10 服务是 UDS 诊断的 “钥匙”，不同会话对应不同 “房间”，只有用 10 服务打开对应 “房间”，才能进行里面的操作。
二、10 服务的核心：4 种会话类型详解
根据 ISO 14229-1 标准，10 服务定义了 4 种核心会话类型，每种会话的 “权限、用途、进入条件” 都不同，是 10 服务的核心知识点。我们用表格清晰对比：
子功能码（1 字节） | 会话名称 | 核心用途 | 权限等级 | 进入条件 | 典型场景 |
0x01 | 默认会话 | 车辆正常运行时的基础诊断，提供 “最小必要” 诊断功能 | 最低 | ECU 上电后自动进入，无需额外条件 | 读取当前故障码（19 服务）、读取基础数据（22 服务） |
0x03 | 扩展会话 | 研发 / 维修时的深度诊断，开放更多数据读取、参数配置功能 | 中等 | 诊断仪发送 10 服务请求（0x10 0x02），ECU 无故障即可进入 | 读取详细运行日志、修改怠速参数（2E 服务） |
0x02 | 编程会话 | ECU 程序刷写（如升级固件），关闭核心控制功能，仅保留刷写相关模块 | 高 | 1. 发送 10 服务请求（0x10 0x03）；2. 部分 ECU 需先通过 27 安全验证 | 工厂下线刷写、售后固件升级 |
0x04 | 安全会话 | 高权限操作的 “过渡会话”，用于执行安全相关诊断（如解除硬件锁定） | 最高 | 1. 发送 10 服务请求（0x10 0x04）；2. 必须先通过 27 安全访问验证 | 解除 ECU 硬件锁定、读取加密故障数据 |
这里有 3 个关键注意点：
- 会话权限不可逆：只能从低权限向高权限切换（如默认→扩展→编程），不能反向直接切换（如编程→扩展需先回到默认，再进入扩展）；
- 编程会话风险高：进入编程会话后，ECU 会暂停发动机控制、底盘控制等核心功能，必须确保车辆处于安全状态（如熄火、驻车）；
- 安全会话不常用：多数场景下，高权限操作可通过 “默认→扩展 + 27 安全验证” 实现，安全会话仅用于特殊安全需求（如军工级 ECU）。
三、10 服务的通信格式：请求与响应怎么写？
10 服务的通信遵循 UDS 通用格式，但有其专属参数（如会话子功能、超时时间），我们以最常用的 CAN 总线为例，拆解请求帧与响应帧的结构。
1. 诊断请求帧（诊断仪→ECU）
10 服务的请求帧由 “服务 ID + 子功能 + 可选参数” 组成，最多 8 字节（CAN 单帧限制），具体结构：
字节位置 | 字段名称 | 取值 / 说明 |
1 | 服务 ID（SID） | 固定为 0x10（代表会话控制服务） |
2 | 子功能（SF） | 对应 4 种会话：0x01（默认）、0x02（扩展）、0x03（编程）、0x04（安全） |
3~8 | 可选参数 | 仅 1 个常用参数：会话超时时间（P2Server_max），占 2 字节（单位：ms）；若不填，用 ECU 默认超时 |
实例 1：进入扩展会话（不指定超时时间）
诊断仪发送请求帧（CAN ID 通常为 0x7E0）：
0x10 0x02
→ 含义：请求 ECU 进入扩展会话，使用 ECU 默认的会话超时时间（如 5000ms）。
实例 2：进入编程会话（指定超时时间为 10000ms）
诊断仪发送请求帧：
0x10 0x03 0x27 0x10
→ 含义：0x10 = 服务 ID，0x03 = 编程会话，0x27 0x10 = 十六进制的 10000ms（超时时间）。
2. 诊断响应帧（ECU→诊断仪）
ECU 收到 10 服务请求后，会返回 “肯定响应” 或 “否定响应”，两种响应格式不同。
（1）肯定响应（操作成功）
肯定响应的核心是 “服务 ID+0x40”，结构：
字节位置 | 字段名称 | 取值 / 说明 |
1 | 肯定响应 ID（PRID） | 0x10 + 0x40 = 0x50（固定，代表 10 服务的成功响应） |
2 | 子功能（SF） | 与请求帧的子功能一致（如请求 0x02 扩展会话，响应也为 0x02） |
3~8 | 响应参数 | 包含 2 个关键参数：① 当前会话类型（1 字节，与子功能一致）；② 实际生效的超时时间（2 字节，ms） |
实例：进入扩展会话的肯定响应
ECU 返回响应帧（CAN ID 通常为 0x7E8）：
0x50 0x02 0x02 0x13 0x88
→ 含义：0x50 = 肯定响应，0x02 = 确认进入扩展会话，0x02 = 当前会话类型，0x13 0x88=5000ms（实际超时时间）。
（2）否定响应（操作失败）
若 ECU 无法执行请求（如不支持编程会话、未通过安全验证），会返回否定响应，结构：
字节位置 | 字段名称 | 取值 / 说明 |
1 | 否定响应标识 | 固定为 0x7F（代表 UDS 否定响应） |
2 | 被拒绝的服务 ID | 固定为 0x10（代表拒绝的是 10 服务） |
3 | 否定响应码（NRC） | 代表失败原因，10 服务常见 NRC 码见下文 “常见问题” 部分 |
实例：请求进入编程会话但未通过安全验证
ECU 返回否定响应：
0x7F 0x10 0x33
→ 含义：0x7F = 否定响应，0x10 = 被拒绝的服务，0x33 = 安全访问未通过（需先执行 27 服务验证）。
四、10 服务的关键流程：切换、超时与退出
掌握 10 服务，不仅要懂格式，更要懂实际操作中的 “动态流程”—— 比如怎么切换会话、会话为什么会自动退出、怎么回到默认会话。
1. 核心流程：从默认会话切换到扩展会话
这是最常用的流程，工程师调试 ECU 时几乎每天都会用到，步骤如下：
- 初始状态：ECU 上电后，自动进入 “默认会话（0x01）”，此时只能执行低权限操作（如 19 服务读故障码）；
- 发送请求：诊断仪发送 10 服务请求（0x10 0x02），请求进入扩展会话；
- ECU 校验：ECU 检查自身状态（如是否有严重故障、是否支持扩展会话），若没问题则切换到扩展会话；
- 返回响应：ECU 发送肯定响应（0x50 0x02 ...），告知诊断仪已进入扩展会话；
- 执行高权限操作：诊断仪可执行扩展会话支持的操作（如 22 服务读标定 DID、2E 服务写参数）；
- 会话保持：诊断仪需在 “超时时间” 内（如 5000ms）发送 “心跳请求”（如再次发送0x10 0x02或其他诊断请求），否则会话会自动退出。
2. 关键机制：会话超时（为什么会话会 “掉”？）
ECU 不会一直保持高权限会话，这是为了安全和节能 —— 若诊断仪忘记退出会话，ECU 会在 “超时时间” 后自动切回默认会话，这个机制叫 “会话超时”。
- 超时时间来源：① 诊断仪请求时指定（如实例 2 中的 10000ms）；② 若未指定，用 ECU 默认值（通常 5000~30000ms）；
- 超时重置：只要在超时前，诊断仪发送任何诊断请求（如 19 服务、22 服务，或再次发送 10 服务请求），ECU 会重置超时计时器，重新开始计时；
- 超时后果：超时后，ECU 自动切回 “默认会话”，所有高权限操作会被拒绝，需重新发送 10 服务请求切换会话。
实例：会话超时场景
诊断仪进入扩展会话（超时时间 5000ms）后，若 6 秒内未发送任何请求，ECU 会自动切回默认会话；此时诊断仪再发送 22 服务读标定 DID，ECU 会返回否定响应（0x7F 0x22 0x33，安全访问未通过 —— 本质是会话已回到默认，无权限读取）。
3. 退出流程：怎么从高权限会话回到默认会话？
有 3 种方式退出高权限会话，回到默认会话：
- 主动请求：诊断仪发送 10 服务请求（0x10 0x01），ECU 收到后立即切回默认会话，返回肯定响应（0x50 0x01 ...）；
- 会话超时：如上文所述，超时后自动切回默认会话；
- ECU 复位：ECU 断电重启或执行复位指令（如 11 服务）后，会重新上电进入默认会话。
五、实际应用：10 服务的常见问题与排查方法
在开发或调试中，10 服务最容易遇到 “响应失败” 或 “会话异常”，核心问题集中在 “否定响应码（NRC）” 和 “会话超时”，我们逐一拆解解决方案。
1. 常见 NRC 码与排查思路
10 服务的否定响应码（NRC）有明确含义，通过 NRC 能快速定位问题：
NRC 码 | 含义 | 典型场景 | 排查方法 |
0x11 | 服务子功能不支持 | 向仅支持默认 / 扩展会话的 ECU，发送0x10 0x03（编程会话）请求 | ① 查 ECU 的诊断规范，确认是否支持该会话；② 检查子功能码是否写错（如 0x03 写成 0x30） |
0x22 | 请求参数不正确 | 指定的超时时间超出 ECU 支持范围（如 ECU 最大支持 30000ms，却指定 40000ms） | ① 查 ECU 规范，确认超时时间的取值范围；② 检查超时时间的十六进制转换是否正确（如 10000ms=0x2710，不是 0x1027） |
0x33 | 安全访问未通过 | 请求进入编程 / 安全会话，但未先执行 27 服务（安全验证） | ① 先发送 27 服务完成种子 - 密钥验证；② 确认安全验证的算法和密钥是否正确 |
0x78 | 资源暂时不可用 | ECU 正在执行刷写程序，此时请求进入扩展会话 | ① 等待 ECU 完成当前任务（如刷写）；② 若 ECU 卡住，执行复位指令（11 服务）后重试 |
0x85 | 会话切换不允许 | ECU 处于故障保护模式（如发动机缺缸），不允许进入扩展 / 编程会话 | ① 用 19 服务读取故障码，修复 ECU 故障；② 清除故障码（14 服务）后重试 |
2. 会话超时的常见原因与解决
“会话频繁超时” 是工程师常遇到的问题，主要原因有 3 点：
- 超时时间设置过短：若诊断仪指定的超时时间（如 1000ms）太短，操作未完成就超时；
解决：请求时指定更长的超时时间（如 10000ms），或使用 ECU 默认的较长超时值。
- 诊断仪未发送心跳请求：调试时忘记在超时前发送请求，导致计时器到期；
解决：在诊断工具（如 CANoe）中设置 “自动心跳”，每隔超时时间的 70% 发送一次请求（如 5000ms 超时，每 3500ms 发送一次0x10 0x02）。
- ECU 故障导致超时计时器异常：ECU 内部程序 BUG，导致计时器提前到期；
解决：读取 ECU 的内部日志（如通过 22 服务读 DID），排查是否有软件故障；若有，升级 ECU 固件。
3. 不同总线下 10 服务的差异（CAN vs 以太网）
虽然 10 服务的核心逻辑在 CAN 和以太网中一致，但存在 2 个关键差异：
对比维度 | CAN 总线（ISO 14229-2） | 以太网（ISO 14229-3） |
传输长度 | 单帧最多 8 字节，超时参数只能传 2 字节（最大 65535ms） | 支持多帧传输，超时参数可传 4 字节（最大 4294967295ms） |
会话标识 | 依赖 CAN ID 区分诊断节点 | 依赖 IP 地址 + 端口区分诊断节点 |
超时机制 | 仅 ECU 侧计时 | 诊断仪和 ECU 双向计时，需同步 |
注意：以太网下的 10 服务
若在以太网中使用 10 服务，指定超时时间时可设置更长的值（如 30 分钟 = 1800000ms），适合长时间的刷写或调试操作；但需确保诊断仪和 ECU 的计时同步，否则会出现 “诊断仪认为未超时，ECU 已切回默认会话” 的问题。
六、总结：10 服务的核心价值与学习建议
10 服务看似简单（只是切换会话），却是 UDS 诊断的 “地基”——所有高权限诊断操作的前提，都是通过 10 服务打开对应 “会话大门”。其核心价值在于：
- 安全：避免 ECU 在正常行驶时暴露高权限接口，降低被误操作或攻击的风险；
- 灵活：按需切换会话，平衡 “功能需求” 与 “安全节能”；
- 标准化：不同厂商的 ECU 都遵循同一套会话切换规则，诊断仪可通用。
对于学习 10 服务，建议从 “实战” 入手：
- 用 CANoe 或诊断仪（如 Vector VN1630）连接 ECU，实际发送0x10 0x02请求，观察响应；
- 故意触发超时（如不发送心跳），看 ECU 是否切回默认会话；
- 模拟 NRC 场景（如不验证安全就进编程会话），熟悉不同 NRC 码的排查流程。
如果在实际操作中遇到 “会话切换失败”“超时异常” 等问题，欢迎在评论区留言，我们一起拆解解决方案！