UDS诊断服务-14服务

一、14 服务是什么为什么它是维修闭环的收尾步0x14 的作用只有一句话按掩码清除 ECU 中存储的 DTC及其关联数据。没有它修完故障后会发生什么历史 DTC 一直留在 ECU 里下次诊断时历史故障与新故障混在一起技师难以判断故障统计、保修数据把已修复的问题计入未解决故障数据失真某些法规场景排放相关需要已清除 DTC的明确记录来重置监测器readiness状态。但先纠正两个流行误解⚠️误解 114 服务能隐藏没修好的故障。不能。DTC 被清除后若故障仍然存在ECU 会在下一个检测周期重新点亮该 DTC——清了又亮恰恰是提醒你没修干净而不是服务失败。⚠️误解 2复位11 服务能清故障码。不能。DTC 存于 NVM任何复位都清不掉清 DTC 只有 0x14 一条路。二、报文格式简单到只有 4 个字节核心认知0x14 没有子功能这是本文最重要的一句话。ISO 14229-1 中 ClearDiagnosticInformation 的请求结构是字节字段说明1SID固定 0x142–4DTCMask3 字节从第 2 字节起就是掩码不是子功能标准定义了两个确定的掩码语义0xFFFFFF清除 ECU 中所有可清除的 DTC任意精确的 3 字节 DTC 编号只清除该单个 DTC。中间地带如按系统分组清除属于OEM 自定义掩码的组语义要查各家的诊断规范标准不作保证。经典报文示例14 FF FF FF → 清除全部 DTC最常用维修收尾标配 14 00 03 01 → 只清除 P03013 字节 DTC 编号⚠️ 网上常见的14 01 00 00 00 00 00 00所谓子功能 0x01 清全部在真实 ECU 上会被解析为清除 DTC 0x010000——和清全部毫无关系。这类报文基本可以断定抄自错误资料。⚠️ 顺便正因为没有子功能字节0x14 也不存在抑制正响应位suppressBit 是子功能的 bit7。14 81这种写法不成立。肯定响应只有一个字节54 → 清除成功没有任何附加参数没有子功能回显、没有已清除数量、没有未清除列表——在任何传输层上都没有CAN 或 DoIP 都一样。想要细节清除前后各读一次 19 服务自己对比。否定响应7F 14 NRC三、清除语义删 DTC 时关联数据一并删除原文类资料常见的0x01 只清 DTC快照和统计要另发命令清——错的。清除某个 DTC 时它关联的存储信息一并清除包括故障快照freeze frame扩展数据老化计数器、发生次数、故障出现/消失时间等该 DTC 的状态历史。也就是说不存在只清快照只清统计数据的独立命令。如果清除后19读出的统计归零了那是清 DTC 连带清除的正常结果不需要额外的子功能。永久 DTC14 服务清不掉这是设计不是 Bug排放相关的永久 DTCpermanent DTC是法规如 OBD II、欧标 EOBD强制要求的特殊类型0x14无权删除它只有在故障真实修复、相关监测器重新通过后ECU 才会自动清除目的防止清码蒙混——清完码就以为车没毛病。读永久 DTC 用19 19reportEmissionRelatedDTCWithPermanentStatus。清了又亮是正常现象故障未修复时执行 0x14DTC 记录被清掉 → ECU 下个检测周期重新检测到故障 → DTC 重新点亮。这不是否定响应不是服务失败而是系统按设计工作。所以清除前请务必确认故障已修复用 19 服务核实状态。四、权限会话与安全是 OEM 策略不是标准强制ISO 14229-1没有规定0x14 必须在扩展/编程会话也没有强制安全访问。实际生态是清 DTC 是维修高频操作很多 OEM 在默认会话就放行 0x14部分 OEM尤其新能源核心 ECUBMS/VCU会加会话限制或 27 服务安全锁——以诊断规范CDD/ODX为准。对应的否定响应也要用对会话不允许 →0x7FserviceNotSupportedInActiveSession安全锁未解开 →0x33securityAccessDenied。⚠️ 常见错误写法默认会话下返回7F 14 33本质是会话权限不足——会话问题报 0x33 是把两个 NRC 混为一谈。五、标准操作流程准备 → 清除 → 验证1. 19 02 statusMask 读取 DTC确认目标故障已修复状态不再 testFailed 2. 可选19 01 记录清除前数量留档备份 3. 14 FF FF FF 清除全部或 14 xx xx xx 清单个 4. 收到 54 清除成功 5. 19 01 / 19 02 二次验证DTC 应消失永久 DTC 除外验证要点肯定响应 ≠ 万事大吉必须用 19 服务复核若 DTC 立刻重现 → 故障未真正修复回到第 1 步若残留的是永久 DTC → 检查修复情况与监测器状态等待 ECU 自动清除19 01的正确响应形如59 01 statusMask DTCFormatIdentifier DTC数量2字节例如清除成功且无 DTC 时约等于59 01 08 00 00 00。⚠️ 注意19 04是 reportDTCSnapshotRecordByDTCNumber按 DTC 号读快照不是读历史故障码。验证清除结果请用19 01数量或19 02按状态掩码。六、NRC 速查表NRC标准名称典型场景处理0x11serviceNotSupportedECU 不支持 0x14罕见查规范确认0x13incorrectMessageLengthOrInvalidFormat报文不是 4 字节如漏掉掩码字节检查帧格式0x31requestOutOfRange掩码值不在支持范围如 OEM 不支持某分组掩码改用 0xFFFFFF 或查规范0x33securityAccessDeniedOEM 加了安全锁且未解锁先做 27 服务0x7FserviceNotSupportedInActiveSession当前会话不允许清除切换会话后重试0x22conditionsNotCorrect通用条件不满足检查整车/ECU 前提条件0x78requestCorrectlyReceived-ResponsePending已收到请稍候不要重发在 P2* 内等最终响应0x81rpmTooHigh发动机转速过高时不允许清除OEM 条件降低转速/稳定工况后重试0x85engineRunTimeTooLow发动机运行时间过短OEM 条件等待条件满足高频误读提醒0x11 是服务不支持不是子功能不支持——0x14 压根没有子功能0x81 是rpmTooHigh与故障未修复无关0x85 是engineRunTimeTooLow不是通用当前状态不允许。七、传输层CAN 与 DoIP 没有任何差异这是另一处重灾区必须澄清DTCMask 在任何传输层都是 3 字节。14 FF FF FF是 4 字节经典 CAN 单帧8 字节装得绰绰有余——所谓CAN 因单帧限制无法清单个 DTC完全说反了清单个 DTC14 xx xx xx同样是 4 字节单帧CAN/DoIP 表现一致响应在任何传输层都只有54。DoIP 不会返回已清除数量或未清除列表那是虚构的标准编号别再写错标准内容ISO 14229-1应用层服务定义本文主体ISO 14229-2会话层服务ISO 14229-3UDS on CANISO 14229-5UDS on IPISO 13400DoIP基于 IP 的诊断传输/网络层 那2 字节掩码的说法从哪来的答案是KWP2000ISO 14230时代的老格式。如果你的资料里出现0x14 的子功能 2 字节掩码基本可以判定是 KWP 与 UDS 混写或凭空编造。八、实战 Checklist✅ 清除前先用 19 服务读取并备份故障记录14 清掉的数据无法通过 UDS 恢复✅ 确认目标故障已修复状态掩码不再 testFailed再清除✅ 清除后用19 01/19 02二次验证别只看54✅ 清了又亮 → 故障没修干净回头查硬件/软件✅ 永久 DTC 清不掉 → 查修复与监测器状态等 ECU 自动清除❌ 不要找子功能——0x14 没有❌ 不要期待响应里带清除数量九、总结14 服务的正确画像格式极简14 3 字节掩码响应54无子功能、无抑制位、无附加反馈语义清晰清 DTC 时快照与扩展数据一并清除永久 DTC 由 ECU 自管故障未修复则清了会再亮权限宽松标准不设门槛会话/安全限制全看 OEM 规范跨传输层一致CAN 与 DoIP 下报文与响应完全相同。一句话记住14 FF FF FF收 54再用 19 验证——这就是 14 服务的全部实战。