在汽车电子开发中，诊断协议（UDS，Unified Diagnostic Services）是连接工程师与车辆的“语言”。 当车辆出现故障，维修人员用诊断仪一查，就能立刻知道“哪儿出了问题”——这背后依赖的就是 UDS 协议中的 0x19 服务（ReadDTCInformation）。
今天，我们就来深入浅出地讲清楚：
📌 0x19 服务是干什么的
📡 它有哪些子功能（Sub-function）
🧠 典型的请求与响应格式
⚡ 工程实践中如何使用
0x19 是什么？为什么重要？
0x19 是什么？为什么重要？
在 UDS 协议中，0x19 服务的全称是 ReadDTCInformation，用于读取 ECU 中存储的各种诊断故障码（DTC, Diagnostic Trouble Codes）以及相关的状态信息。
👉 简单来说，它是“车辆告诉你哪里坏了”的核心服务。 例如：
发动机出现故障灯（MIL）
变速箱出现异常
车辆某个传感器状态不对
这些信息都会以 DTC 的形式被记录在 ECU 里，而 0x19 就是读取这些信息的“接口”。
根据 ISO 14229-1 标准，0x19 服务属于 “存储数据传输功能单元”
0x19 的基本结构
UDS 协议的每一个服务，报文结构都分为：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
响应报文则以 0x59 开头（0x19 + 0x40），后跟子功能和返回的数据。
0x19 的主要子功能详解
0x19 服务功能强大，子功能种类也不少。常用的包括：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
👉 其中最常用的是 0x01、0x02、0x0A，用于快速读取故障数量、故障码列表，以及支持的 DTC。
一个例子看懂请求与响应
假设我们要读取“所有当前处于激活状态的 DTC 列表”，可以使用子功能 0x02：时序图
请求报文：
19 02 FF
解释：
0x19：服务 ID
0x02：子功能 ID（按状态掩码读取 DTC 列表）
0xFF：状态掩码（表示匹配所有状态）
响应报文：
59 02 00 03 11 22 33 55 66 77 88 99 AA
解释：
0x59：正响应（0x19 + 0x40）
0x02：子功能回显
0x0003：有 3 条 DTC
接下来每个 DTC 占 4 个字节（3 字节 DTC + 1 字节状态）
👉 工具接收到这个报文后，就可以解析出 DTC 代码，显示给维修人员。
DTC 状态掩码是怎么回事？
DTC 的“状态”是 ECU 用一个字节（8 位）来表示该故障的当前状态，比如：
是否当前激活
是否曾经出现过
MIL 灯是否亮起
是否已经老化（aging） 等等
在请求 0x19 时，状态掩码用来筛选想要的 DTC，比如：
0x02 表示“测试失败”状态
0x08 表示“确认 DTC”
0xFF 表示“所有匹配”
这样我们可以灵活地按需要读取不同类别的 DTC 信息。
工程小抄
-
先 0x10 进合适会话（例如扩展会话）再发 0x19，避免被会话权限限制。
-
状态掩码先用 FF 做全量获取，再在上位机侧过滤，方便调试；投产时按需收敛位。
-
按功能组查询（如排放 0xFFFF33、安全 0xFFFFD0），提升定位效率；全量为 0xFFFFFF。
-
快照/扩展数据记录号：0x00 常为保留，项目内定义自 0x01 起。
-
永久 DTC：别忘了 0x19 的“永久状态”读取与法规自检通过条件的联动。