文章目录一、为什么说 0x22 是 UDS 最重要的服务二、0x22 服务基础它到底读什么三个关键特性三、报文格式详解逐字节拆解3.1 请求报文常用 DID 定义表3.2 肯定响应报文3.3 否定响应报文四、实战示例读取 ECU 软硬件版本号第一步诊断仪发送请求第二步ECU 返回肯定响应第三步解析数据五、NRC 错误处理7 种错误码全解析NRC 错误码一览表NRC 检查优先级六、0x22 服务测试六大关注点1、ECU 版本正确性问题2、无效 DID 处理问题3、会话模式问题4、安全依赖问题5、数据一致性问题6、ECU 处理性能问题七、总结一张表回顾 0x22 核心UDS 诊断协议系列 · 核心必读从报文格式到实战测试一篇文章讲透 UDS 中使用频率最高的服务一、为什么说 0x22 是 UDS 最重要的服务做车载测试的同学注意了——如果你只能学一个 UDS 服务那必须是0x22 ReadDataByIdentifier。为什么因为它是整个 UDS 诊断体系中使用频率最高、覆盖场景最广的核心服务。无论是读取 ECU 软硬件版本号、查询标定参数、还是获取系统运行状态都离不开它。UDSUnified Diagnostic Services统一诊断服务协议定义了 26 种服务覆盖诊断管理、数据传输、故障诊断、输入输出控制、例程控制和上传下载六大类。而0x22 ReadDataByIdentifier属于数据传输大类是其中最核心的数据读取服务。图 10x22 在 UDS 服务家族中的位置——数据传输大类中的核心服务为什么说它最重要三个原因1. 使用频率最高几乎每次诊断会话的第一步都是用 0x22 读取 ECU 版本信息确认通信对象正确。它是所有测试的起手式。2. 覆盖数据最广从软硬件版本号、零件编号、序列号到标定参数、传感器值、运行状态——ECU 里几乎所有可读数据都通过 0x22 获取。3. 学习价值最大0x22 涉及 DID 概念、报文格式、多帧传输、NRC 错误处理、会话权限、安全解锁等 UDS 核心机制掌握它等于掌握了 UDS 的半壁江山。二、0x22 服务基础它到底读什么0x22 服务全称ReadDataByIdentifier——按标识符读取数据也就是我们常说的读 DID 信息。DIDData Identifier数据标识符是一个 2 字节的编号相当于每个数据的门牌号诊断仪告诉 ECU “我要读 0xF190”ECU 就把 0xF190 对应的数据返回来。图 20x22 ReadDataByIdentifier 服务全景——三大数据类型一览0x22 能读取的数据dataRecord主要分为三大类数据类型典型 DID 示例说明内部数据0xF190 零件编号、0xF187 序列号、0xF195 Boot软件版本、0xF196 应用软件版本ECU 的身份证信息软硬件版本号、序列号等标定参数各 OEM 自定义ECU 内部的标定值、配置参数、阈值设定等系统状态各 OEM 自定义诊断结果、传感器值、ECU 运行状态等动态数据三个关键特性特性一支持一次请求多个 DID22 服务允许诊断仪在一条请求报文中同时携带多个 DIDECU 会依次返回每个 DID 的数据大大提高读取效率。特性二DID 允许重复请求如果请求中出现了重复的 DIDECU 也会重复响应该 DID 的数据内容。协议层面不做去重。特性三DID 数量有限制协议提到 ECU 可限制同时请求的 DID 数量但未给出具体值。一般 OEM 会限制为 3 或 5 个。如果请求出错可能收到两种 NRCNRC 0x13请求报文长度超过 ECU 处理能力NRC 0x14ECU 响应数据过长所有 DID 数据加起来超过 ECU 能力三、报文格式详解逐字节拆解0x22 的报文分为请求报文、肯定响应报文和否定响应报文三种。下面我们逐字节拆解。图 30x22 服务三种报文格式总览——请求、肯定响应、否定响应3.1 请求报文诊断仪向 ECU 发送的请求报文格式如下byte 0byte 1byte 2byte 3byte 4-5byte 6-7PCI22DID_HDID_LDID_2(HL)Padding单帧标识SID 0x22数据标识符 DID2字节/组可多组填充 FF关键点说明byte 0PCICAN 总线协议控制信息。如果是单帧高 4 位为 0低 4 位为数据长度如02表示 2 字节数据。byte 1SID固定为0x22标识这是 ReadDataByIdentifier 服务。byte 2-3DID数据标识符的高字节和低字节。例如F1 90表示 DID 0xF190零件编号。多 DID如果要一次读多个 DID就接着写DID2_H DID2_L DID3_H DID3_L ...。PaddingCAN 报文不足 8 字节时用0xFF填充。常用 DID 定义表DID名称说明0xF190零件编号Part NumberECU 的零件标识0xF187ECU 序列号每个 ECU 的唯一序列号0xF191供应商编号ECU 制造商标识0xF195Boot 软件版本号Bootloader 版本信息0xF196应用软件版本号Application Software 版本信息0xF197应用软件版本号名称版本号的字符串表示0xF198Boot 软件版本号名称Bootloader 版本号字符串3.2 肯定响应报文ECU 成功读取到 DID 数据后返回肯定响应byte 0byte 1byte 2byte 3byte 4-5byte 6~NPCI62DID_HDID_LDID回显DataRecord单帧/多帧0x22 0x40请求DID回显多DID时DID指向的数据关键点说明byte 1响应 SID肯定响应 SID 请求 SID 0x40所以0x22 0x40 0x62。这是 UDS 协议的通用规则所有服务都遵循。byte 2-3DID 回显ECU 会把请求中的 DID 原样回显告诉你我返回的是这个 DID 的数据。byte 6~NDataRecordDID 对应的实际数据内容长度由 DID 定义决定。如果是多 DID 请求则DID1数据 DID2数据 ...依次排列。多帧传输数据超过 8 字节怎么办CAN 总线单帧最多传 8 字节数据。如果 ECU 响应数据超过 8 字节比如读取零件编号字符串就需要使用 ISO-TP 多帧传输首帧First Frame 流控帧Flow Control 连续帧Consecutive Frame。这个过程对诊断仪是透明的但抓包时你会看到多帧交互。3.3 否定响应报文当 ECU 无法处理请求时返回否定响应NRCNegative Response Codebyte 0byte 1byte 2byte 3byte 4-7PCI7F22NRCPadding单帧标识否定响应SID原服务SID错误码填充FF关键点说明byte 1固定0x7F标识这是否定响应。byte 2原服务 SID告诉你是哪个服务出错了这里是0x22。byte 3NRC具体的错误码告诉你为什么出错。这是排查问题的关键。四、实战示例读取 ECU 软硬件版本号说了这么多格式不如来一个真实案例。假设我们要读取 ECU 的零件编号DID 0xF190整个交互过程如下图 40x22 实战示例——从请求发起到数据解析的完整流程第一步诊断仪发送请求Tx: 03 22 F1 90 FF FF FF FF解读03 单帧3 字节数据 →22 SID →F1 90 DID 0xF190零件编号→ 剩余填充FF。第二步ECU 返回肯定响应Rx: 10 0E 62 F1 90 34 31 54 ← 首帧 21 42 2D 30 30 31 32 33 ← 连续帧 1 22 34 00 00 00 00 00 00 ← 连续帧 2解读10 0E 首帧总数据长度 14 字节62 肯定响应 SID0x22 0x40F1 90 DID 回显34 31 54 42 2D 30 30 31 32 33 34 ASCII 编码的零件编号 “41TB-001234”第三步解析数据将响应中的 DataRecord 部分34 31 54 42 2D 30 30 31 32 33 34按 ASCII 解码得到零件编号字符串“41TB-001234”。同理可以读取更多 DIDDID 0xF187 → 序列号 “SN202401150001”DID 0xF195 → Boot 软件版本 “V1.2.0”DID 0xF196 → 应用软件版本 “V2.3.1”测试时建议一次性读取这些版本信息确认 ECU 版本正确后再进行后续测试。五、NRC 错误处理7 种错误码全解析0x22 服务支持 7 种 NRC否定响应码。ECU 在收到请求后会按照固定的优先级顺序进行检查一旦某项检查不通过就立即返回对应的 NRC。图 50x22 服务 NRC 错误处理流程——ECU 的 7 步检查链NRC 错误码一览表NRC名称含义触发场景0x11serviceNotSupported服务不支持ECU 根本不支持 0x22 服务0x7FserviceNotSupportedInActiveSession当前会话不支持0x22 仅在特定会话模式下可用0x13incorrectMessageLengthOrInvalidFormat报文长度或格式错误请求报文长度不正确、DID 不是偶数对等0x14responseTooLong响应数据过长请求的多个 DID 数据总量超过 ECU 响应能力0x22conditionsNotCorrect条件不满足ECU 当前运行状态不允许读取该 DID如正在刷写中0x31requestOutOfRangeDID 不支持请求的 DID 未定义或超出 ECU 支持范围0x33securityAccessDenied安全访问被拒该 DID 需要先通过 0x27 安全解锁才能读取NRC 检查优先级ECU 收到 0x22 请求后会按照以下优先级依次检查图 5 详细流程优先级 1-2协议层校验先检查 ECU 是否支持 0x22 服务NRC 0x11再检查当前会话是否支持NRC 0x7F。优先级 3-4格式/数量校验检查报文长度是否正确NRC 0x13再检查 DID 数量是否超限NRC 0x14。优先级 5-7功能/运行时校验检查安全解锁状态NRC 0x33检查 DID 是否支持NRC 0x31最后检查执行条件NRC 0x22。NRC 优先级的重要性理解 NRC 优先级对测试至关重要。例如如果某个 DID 既需要在非默认会话下读取又需要安全解锁那么在默认会话且未解锁时发送请求ECU 会优先返回 NRC 0x7F会话不支持而不是 NRC 0x33安全访问被拒。测试时需要逐级满足前置条件才能测到后续的 NRC。六、0x22 服务测试六大关注点22 服务对照项目的诊断规范用起来很简单但实际测试中还是会遇到一些典型问题。以下六大测试关注点是实战经验的总结每个都是容易踩坑的地方。图 60x22 服务测试六大关注点——实战踩坑经验总结1、ECU 版本正确性问题不论是功能测试、协议测试还是诊断本身的测试测试前用 22 服务读取 ECU 软硬件版本号是一个必要习惯。别等问题查了一圈最后发现是版本不对导致的。一句话先读版本再开测。2、无效 DID 处理问题注意验证 DID 的边界值0x0000和0xFFFF以及 ECU 不支持的 DID 编号。预期行为是返回 NRC 0x31requestOutOfRange而不是挂死或返回错误数据。3、会话模式问题某些 DID 只能在非默认会话如扩展会话、编程会话下读取。测试时需要在默认会话和非默认会话下分别测试验证 DID 的读取权限是否符合诊断规范定义。4、安全依赖问题某些 DID 需要先通过 0x27 安全访问SecurityAccess解锁后才能读取。测试时需要在未解锁和解锁两种状态下都执行测试未解锁时应返回 NRC 0x33解锁后应正常返回数据。5、数据一致性问题对于 ECU 内部的变化数据如传感器值、运行状态需要先做仿真输入再通过 0x22 读取验证返回数据与仿真输入的实时一致性。防止出现读了但数据不对的隐蔽问题。6、ECU 处理性能问题当同时请求多个 DID 时注意验证 ECU 的响应时间参数 P2server服务端响应时间。确保 ECU 的处理性能满足规范要求不会因为多 DID 请求导致超时。一般要求 P2server 不超过 50ms具体值参照 OEM 规范。七、总结一张表回顾 0x22 核心维度核心要点服务定位UDS 中使用频率最高的数据读取服务按 DID 标识符读取 ECU 数据数据类型内部数据版本号/序列号 标定参数 系统状态请求格式SID(0x22) DID_H DID_L [DID2_H DID2_L …]肯定响应SID(0x62) DID回显 DataRecord否定响应0x7F 0x22 NRC7种错误码测试要点版本验证、DID边界值、会话权限、安全解锁、数据一致性、响应性能个人理解有误指正本文基于 ISO 14229-1 协议和实际测试经验整理部分内容为个人理解。如有错误欢迎指正。更多协议细节请查阅 ISO 14229-1 协议原文。本文基于 ISO 14229-1 协议整理仅供学习交流