2.10 DTC状态字节——症状的八种状态

一个字节，八种生命状态

在UDS里，每一个DTC都配有一个Status Byte（状态字节）。这一个字节的八位各自含义不同——它们一起表达了“这个故障从发现到确认到最终清除“的全生命周期。

Bit 7    Bit 6    Bit 5    Bit 4    Bit 3        Bit 2      Bit 1    Bit 0
┌──────┬──────┬──────┬──────┬──────┬──────────┬──────────┬──────────┬──────────┐
│warning│test  │test  │test  │con  │pending   │testFailed│test      │test      │
│Indic  │NotCmp│Failed│NotCmp│firmed│DTC       │ThisOperat│NotComplet│Failed    │
│Request│ThisOp│Since │Since │DTC   │          │Cycle     │SinceLast │          │
│       │Cycle │LastCl│LastCl│      │          │          │Clear     │          │
│       │      │ear   │ear   │      │          │          │          │          │
└──────┴──────┴──────┴──────┴──────┴──────────┴──────────┴──────────┴──────────┘

注意：上图中bit7在左、bit0在右，下表从bit0开始逐行解释——两个方向相反，读表时请注意对应。

生命周期的状态转移图

以一次传感器故障为例：

T=0    服务诊断监控器启动检查
      testNotCompletedSinceLastClear=1
      testNotCompletedThisOperationCycle=1

T=10s  诊断监控器通过检测——未发现故障
      testNotCompletedSinceLastClear→0 (已检测过)
      testNotCompletedThisOperationCycle→0 (本周期已检测过)

T=300s 传感器对地短路，ADC值跳至最低
      诊断监控器在检测窗口内捕捉到异常
      testFailed→1
      testFailedThisOperationCycle→1
      pendingDTC→1

T=320s 驾驶循环结束——ECU熄火
      testFailedThisOperationCycle 会在下一次ECU启动时清零
      pendingDTC 继续保留

T=10s  第二个驾驶循环启动
      testFailedThisOperationCycle→1 (新周期第二次testFailed会再置1)
      pendingDTC保持1 (上个周期失败，本周期未检测完——仍为待确认)
      检测完成后如果继续失败: testFailed保持1
      confirmedDTC→1 (满足确认条件)

T=600s 维修站清除DTC → ClearDiagnosticInformation(0x14)
      confirmedDTC→0
      testFailedSinceLastClear→0
      testNotCompletedSinceLastClear→1 (重置——重新开始检测)

核心洞察：DTC的8位Status不是随机决定要不要点亮MIL灯的参数——它实现了一个全自动的Debounce(消抖)+确认+老化的状态机。一次颠簸导致传感器连接松动不一定是真故障——pendingDTC提供了“先观察、别急着存档“的过渡态。连续两个行驶循环才确认——这是“下次再看看“的设计——是保守且正确的。

常见状态字节值速查

在实际调试中，你更多看到的是完整的状态字节数值而不是逐位拆解。下面是几个最常见的值：

DTC的老化机制（Aging）

DTC被确认后并非永远存在——UDS和OBD-II都定义了DTC老化机制：

1. 暖化(Warm-Up)循环老化：经过40个暖化循环（OBD-II法规值，UDS无硬性规定，取决于OEM配置），如果故障不再出现，confirmedDTC自动清零。
2. 清除指令触发：通过0x14服务主动清除。
3. 老化的意义：老化机制防止了“多年前修好的故障码还挂在存储器里“的尴尬——ECU的存储器空间有限，只有真正活跃的故障才有资格占用存储资源。

核心洞察：老化机制是DTC管理里最被低估的安全网。想象一辆车开了十年——如果不老化，DTC表里会塞满几百条历史故障记录。老化让ECU的故障存储器成为一个滑动窗口——永远只保留最近的相关故障。

状态字节与0x19子功能的配合

DTC的状态字节直接决定了0x19各种子功能的返回结果。当你向ECU发送带有DTCStatusMask的查询时：

DTCStatusMask = 0x09 (bit0=testFailed + bit3=confirmedDTC)

ECU内部过滤逻辑:
  for each DTC:
      if (dtc.statusByte & mask) != 0:
          加入响应列表

  → 只返回"当前失败且已确认"的DTC

这个掩码机制让0x19能做到精细的筛选——你不需要“拿出所有DTC再自己过滤“——ECU帮你过滤好了。

OBD-II与UDS的DTC状态字节有轻微差异：OBD-II的状态字节更偏向排放法规场景（如MIL亮灯条件更严格），而UDS的状态字节更通用。但核心生命周期——testFailed→pending→confirmed→清除/老化——是两者共享的。

本篇小结

1. DTC状态字节的8位分别编码了从“首次检测到故障“到“确认“到“请求亮灯“到“诊断清除“的完整生命周期。
2. pendingDTC是UDS最被低估的位——它为“暂存未确认的故障“创建了缓冲，避免了颠簸/临时短路被当成Confirmed DTC成为永久记录。
3. confirmedDTC是DTC的“存档标记“——它表示故障已经稳定重复地出现在多个操作周期中——不是一个暂时的电路接触不良。
4. warningIndicatorRequested不自动等于MIL灯亮——它仅是“ECU请求“，最终决定由灯控制模块做出。
5. DTC老化机制确保故障存储器是一个滑动窗口——经过一定数量的暖化循环（OBD-II规定为40个，UDS由OEM自行配置）未复现的故障自动清除，防止历史记录无限堆积。
6. DTCStatusMask是0x19子功能与状态字节之间的桥梁——通过位掩码过滤，ECU只返回符合条件的状态行。

【下集预告】：症状记下来了——治好了怎么办？得清除DTC。0x14 ClearDiagnosticInformation。不是删除某一个DTC——而是一口气清除整组DTC、相关的快照数据、冻结帧和扩展记录。但是！镜像内存的记录不会被清除——这是法律留下的永久痕迹。