UDS诊断服务-11服务
一、11 服务是什么？为什么需要它？
先建立核心认知：ECU 的"复位"不是单一操作，而是按场景分级的"可控重置"。
典型场景：
- 刷写后生效：新固件写入 Flash 后，必须复位才能跳转加载新程序；
- 参数生效：通过 2E 服务修改的标定/配置项，很多需要重启后才被重新读取；
- 异常恢复：软件死锁、任务卡死时，远程复位比"拔保险、断蓄电池"高效且安全；
- 电源管理：常电 ECU 的休眠/下电准备，也需要标准化指令配合。
11 服务的价值在于：复位前 ECU 可以收尾任务、保存关键数据后再重启（注意：这是好的实现应有的行为，属于 OEM 实现要求，而非标准强制义务），避免了粗暴断电的风险；复位后按预设流程自动恢复，无需人工干预。
先澄清两个流传甚广的误解：
⚠️误区 1：复位会清故障码。不会。已确认的 DTC 存在 NVM 里，复位清不掉；清 DTC 是0x14服务的职责。
⚠️误区 2：硬复位会丢标定数据。写入 NVM/EEPROM 的数据任何复位都丢不了；丢的只有 RAM 数据。如果"复位后校准丢了"，那是因为数据压根没落盘——是实现问题，不是 11 服务的锅。
二、子功能详解：旧标准 3 种，新标准 5 种
ISO 14229-1:2013 只定义了 3 个子功能；2020/2023 版扩充为 5 个。正确对应关系如下：
| 子功能 | 标准名称 | 核心含义 | 典型场景 |
|---|---|---|---|
| 0x01 | hardReset（硬复位） | 模拟"断电→重新上电"的完整过程，复位最深 | 刷写后加载新程序、软件完全卡死 |
| 0x02 | keyOffOnReset（钥匙循环复位） | 模拟点火开关 OFF→ON 一个完整循环，ECU 像经历了一次真实钥匙循环一样走初始化流程 | 需要"重新上电点火"效果的场景 |
| 0x03 | softReset（软复位） | 纯软件级重启，不模拟掉电、也不模拟钥匙循环，速度最快 | 参数生效、软件异常恢复、在线调试 |
| 0x04 | enableRapidPowerShutDown（使能快速下电） | 使能"快速下电/快速休眠"机制（2020 版新增） | 整车能量管理需要快速切断常电 ECU 供电前 |
| 0x05 | disableRapidPowerShutDown（禁用快速下电） | 撤销快速下电状态，恢复正常电源管理 | 取消 0x04 的效果 |
| 0x06–0x3F | ISO 保留 | — | — |
| 0x40–0x5F | 车辆制造商自定义 | OEM 可自行定义（如某些厂的"应用层复位"就定义在这里） | 见各厂诊断规范 |
三个复位类型的正确理解
- hardReset：模拟完整掉电上电，硬件寄存器、软件状态全部重来。复位期间 ECU 离线，刷写后必用。
- keyOffOnReset：注意，它不是"只复位与点火相关的模块"，而是让 ECU整体按一次钥匙循环的流程重新初始化。对没有点火信号的常电 ECU（如 BMS）通常无意义，请求会吃 NRC。
- softReset：只重启软件，最快最"轻"，适合调试期反复使用。
复位深度大致为：hardReset ≥ keyOffOnReset > softReset。
0x04 / 0x05：最容易被写错的一对
这两个子功能是被误解的重灾区，常被误写成"睡眠模式复位"和"应用层复位"——都是错的。
它们是一对电源管理开关，而不是"复位动作"：
- 背景：KL30 常电/电池供电的 ECU 在整车下电后仍带电，必须靠自己进入休眠来降低静态功耗；
- 0x04 的作用：让 ECU 尽快完成数据保存、任务收尾，进入"可以立即安全下电/强制休眠"的就绪状态，配合整车能量管理/网络管理快速断电省电；
- 0x05 的作用：撤销该状态，恢复正常电源管理逻辑。
⚠️ 所以 0x04/0x05不在"复位深度"这条轴上。如果你真的需要"只重启应用层、保持通信不离线"这类行为，去查 OEM 在0x40–0x5F 自定义区间里的定义，而不是套用 0x04/0x05。
另外：并非所有 ECU 都支持全部子功能。支持矩阵以各项目的诊断规范（CDD/ODX）为准，别拿标准表硬套实车。
三、通信格式：请求、响应与抑制位
请求帧（2 字节，CAN 单帧即可）
11 01 → 硬复位 11 02 → 钥匙循环复位 11 03 → 软复位 11 04 → 使能快速下电 11 05 → 禁用快速下电肯定响应
51 xx （xx 与请求子功能一致）关键点：这个响应是在 ECU 执行复位"之前"发出的，含义是"请求已确认，我马上开始复位"。
抑制位（suppressPosRspMsgIndicationBit）
子功能的 bit7 置 1 时，ECU 不回复肯定响应：
11 81 → 硬复位，且不要正响应此时 ECU 直接复位，总线上一个响应都没有。功能寻址批量复位时常用，可避免多节点同时回复造成的响应风暴。
否定响应
7F 11 NRC⚠️ 辟谣：不存在"复位后确认响应"
很多文章画了"复位前响应 + 复位后确认响应"两张图，这是错的。标准时序只有一次响应：
诊断仪 ECU |---- 11 01 ----------------->| |<--- 51 01 ------------------| ← 唯一响应，复位前发出 | | ECU 离线、重启（总线静默） | | 重启完成，进入 defaultSession | （等待 T_reset，OEM 定义） | |---- 3E 00 / 10 03 --------->| ← 诊断仪主动轮询确认"复活" |<--- 肯定响应 ---------------|道理很简单：ECU 复位后已经"失忆"，不可能记得还要补发一条51 xx。所谓"复位后确认"，本质是诊断仪等待一段时间后主动探测。
四、实战流程：以"刷写后硬复位"为例
1. 10 02 进入编程会话 2. 27 xx 安全解锁 3. 34/36/37 完成刷写 4. 11 01 请求硬复位 5. 收到 51 01 （复位前响应） 6. 总线静默，等待 ECU 重启（时长查诊断规范） 7. ECU 以 defaultSession 重启上线 8. 诊断仪发 3E 00 / 10 03 确认在线 9. 按需重新建立会话与安全等级，继续后续作业两个必记要点：
- 复位会清空会话等级和安全等级。复位后 ECU 回到默认会话、未解锁状态，高权限操作前必须重新
10 xx+27 xx； - 等待时间 T_reset 是 OEM 定义量（标准只规定 P2/P2* 等响应时间窗）。"软复位 300ms、硬复位 2s"这类数字只能作经验参考，代码里务必做成可配置参数。
五、NRC 速查表：别再望文生义
| NRC | 标准名称 | 典型场景 | 正确处理 |
|---|---|---|---|
| 0x12 | subFunctionNotSupported | 向无点火信号的 BMS 发11 02 | 查规范确认支持的子功能 |
| 0x7E | subFunctionNotSupportedInActiveSession | 子功能支持，但当前会话不允许 | 先切换会话再重试 |
| 0x13 | incorrectMessageLengthOrInvalidFormat | 报文长度/格式错 | 检查帧格式 |
| 0x31 | requestOutOfRange | 子功能写了保留值（如 0x20） | 核对取值 |
| 0x22 | conditionsNotCorrect | 通用"条件不满足" | 检查整车/ECU 状态 |
| 0x33 | securityAccessDenied | 未解锁 | 先做 27 服务 |
| 0x78 | requestCorrectlyReceived-ResponsePending | "已收到，请稍候" | 不要重发！在 P2* 内等最终响应 |
| 0x83 | engineIsRunning | 发动机运行中不允许复位 | 确认安全前提条件 |
| 0x85 | engineRunTimeTooLow | 发动机运行时间太短 | 等待条件满足后重试 |
常见误读纠正：
- 0x11是 serviceNotSupported（整个服务不支持）；"子功能不支持"是0x12；
- 0x22是 conditionsNotCorrect，不是"参数错误"——参数格式错用 0x13、取值超范围用 0x31；
- 0x85是 engineRunTimeTooLow，不是笼统的"当前状态不允许"；
- 0x78不是失败，是"请稍等"的握手信号，正确姿势是等待最终响应，而不是当作超时重发。
六、不同总线传输：先把标准编号用对
| 标准 | 内容 |
|---|---|
| ISO 14229-1 | 应用层服务定义（本文主体） |
| ISO 14229-2 | 会话层服务 |
| ISO 14229-3 | UDS on CAN |
| ISO 14229-5 | UDS on IP |
| ISO 13400（DoIP） | 基于 IP 的诊断传输/网络层 |
复位后的"复活"差异：
- CAN：ECU 重启后直接参与总线通信，诊断仪轮询
3E/10确认即可； - DoIP：ECU 重启后需重建网络栈——IP 就绪、TCP 重连、重新路由激活——复活确认时间通常更长。排查顺序：先 ping 链路 → 再查路由激活 → 最后才怀疑 ECU 本身。
七、实战 Checklist
- ✅ 复位前确认整车处于安全状态（驻车、低速等），具体前提以 OEM 规范为准；
- ✅ 复位前保存需要的数据（故障日志、实时快照等）；
- ✅ 复位后重新建立会话与安全等级；
- ✅ 等待时间可配置，数值查诊断规范；
- ✅ 收到 0x78 耐心等待最终响应；
- ❌ 不要期待"复位后确认响应"；
- ❌ 不要期待复位清 DTC（用 0x14）；
- ❌ 不要把 0x04/0x05 写成"睡眠复位/应用层复位"。
八、总结
11 服务看似"重启"二字，细节全在标准里：
- 子功能：新版共 5 个——hardReset / keyOffOnReset / softReset / enableRapidPowerShutDown / disableRapidPowerShutDown，其中 0x04/0x05 是快速下电开关对，不是复位动作；
- 响应：只有一次肯定响应，且在复位前发出；复位后 ECU 以默认会话上线，由诊断仪主动确认复活；
- NRC：按标准名称查表，别按字面猜；
- 一切 OEM 定义量（复位时长、支持矩阵、安全前提）以项目诊断规范为准。
读标准、查规范、少背"口诀"——这才是诊断开发的正确打开方式。踩过文中这些坑的朋友，欢迎评论区交流！