【科普系列】DTC深度剖析

 

作者 | 寒月

小编 | CRYSTAL

DTC作为汽车故障诊断的核心标识，如同车辆的“医疗档案”，可以让工程师精准定位故障。从简单的传感器故障到复杂的网络通信问题，DTC系统通过精密的编码规则、状态管理和老化机制，构建了一套完整的故障生命周期管理体系。本文内容基于ISO14229-1和ISO15031-6规范创建，详细介绍了DTC组成格式、DTC状态位、DTC状态置位的算法、DTC的老化机制。
 

DTC定义

 

DTC：Diagnostic Trouble Code，诊断故障码，是故障类型的身份ID号码，用于汽车故障时对故障部位及原因的排查。

当ECU检测到一个故障时，其将在存储器中存储对应的一个代码，此代码被称为故障代码。除故障代码外，ECU还可能存储与此故障相关的故障状态、快照信息及扩展信息。

 

DTC的组成

 

 

基本格式

 

其中，DTC High Byte和DTC Middle Byte这两个字节表示故障内码，DTC Low Byte表示故障类型。

 

01

 

故障内码与5位标准故障码的对应关系

 

DTCHighByte、DTCMiddleByte这两个字节表示故障内码，对应5位标准故障码（第一位是字母，后面四位是数字）。

示例："B123416"这个故障码中的"B1234"为故障内码；最后面的"16"则是DTCLowByte的内容。故障内码与5位标准故障码的位置对应关系如下：

● 第一位长度2个bit（Bit15~14）是字母，表示故障所属系统；有如下的四种情况：

● 第二位长度2个Bit（Bit13~12）是数字，表示故障类型（用的哪种法规）；有如下的四种情况：

● 第三位长度4个Bit（Bit11~8）是数字，表示故障所属的子系统，按照4个Bit解析成1个16进制字符

● 第四和第五位长度8个Bit（Bit7~0），分别按照4个Bit解析成2个16进制字符，是数字，表示具体故障对象和类型

 

02

 

故障种类和子类型DTCLowByte

 

DTCLowByte这个字节表示Failure Type Byte(FTB)，包含Failure Category和Failure Sub Type两个部分（ISO 15031-6中的DTCLowByte表示Failure Type Byte(FTB)，而ISO 14229-1中的DTC LowByte表示ID序号）。具体种类和类型在ISO15031-6中详细定义。

ISO 14229-1中DTCLowByte定义

故障种类：

ISO 14229-1中故障类型定义

 

基本概念

 

 

操作循环（OperationCycle）

 

各种操作循环是计算周期相关状态信息（如testCompleteThisOperationCycle）的基础，定义了测试的开始和结束条件，OperationCycle开始时开始检测故障，结束时停止检测。

 

确认阈值(Confirmation Threshold)

 

确认此故障一直存在的Operation Clycle个数，将其认定为历史故障（ConfirmedDTC），在老化(aging)或手动清除前confirmed DTC状态位会一直存储在EEPROM。

 

老化计数器（AgingCounter）

 

老化计数器用于特定诊断故障代码的测试都没有失败（testFailed）的连续操作循环的计数。当一个OpreationCycle没有检测到testFailed，AgingCounter就会自加1，同时DTC status的bit0就会清0。该数值应存储于EEPROM。如果在一个操作循环中有任何已失败的测试结果出现，则老化计数器将重置为“0”。

 

老化阈值（Aging Threshold）

 

在制造商或法规规定的操作循环内，特定诊断故障代码的测试未出现“失败”结果，这个规定的操作循环的次数就称为老化阈值。DTC的Confirmed状态位将会被清除，同时DTC从non-volatile内存中清除。也就是说此故障已经完成了老化，可以自愈。

 

DTC状态位

 

从汽车ECU中读取储存的DTC故障码时，除了故障码本身，还可以读出很多其它的信息，包括优先级、发生次数计数器、发生时的里程和时间，以及本节中所讲的状态位（DTC status）。

这个状态位包含1个byte，这里面的8个bit都有各自的含义，但是这8个bit不一定都要使用，各个主机厂可以根据自己的需求使用其中的几个，也可以全部使用。下图是UDS对DTC status这8个bit的定义。

 

bit0：testFailed（当前故障）

 

通常来说，ECU会周期地检测故障是否存在，如果在最近一次的测试中，测试结果为失败，则相应DTC的这一个状态位就要被置1，表示出错。但是它不一定被ECU存储到non-volatile memory中，只有当pendingDTC或confirmedDTC被置1时DTC才会被存储。当错误消失或者诊断仪执行了清除DTC指令时，testFailed会再次被置0。

testFailed状态位置位算法：

ISO 14229-1中testFailed状态位置位示意图

● 置1：表示该DTC此时发生了故障

● 清0：a）testPass；b）14服务清除DTC

 

bit1：testFailedThisOperationCycle

 

这个bit用于标识某个DTC在当前的OperationCycle中是否出现过testFailed置1的情况，即是否出现过错误。OperationCycle的起始点是ECU通过网络管理唤醒到ECU通过网络管理进入睡眠，对于没有网络管理的ECU，这个起始点就是KL15通断。通过bit0我们无法判断某个DTC是否出现过，比如，当前testFailed=0，说明当前这个DTC没有出错，如果testFailedThisOperationCycle=1的话，就说明这个DTC在当前这个OperationCycle中出过错，但是当前错误又消失了。

testFailedThisOperationCycle状态位置位算法：

ISO 14229-1中testFailedThisOperationCycle状态位置位示意图

● 置1：在当前的操作循环内，该DTC发生过故障

● 清0：a）开启新的操作循环；b）14服务清除DTC

 

bit2：pendingDTC

 

根据规范的解释，pendingDTC=1表示某个DTC在当前或者上一个OperationCycle中是否出现过。pendingDTC位其实是位于testFailed和confirmedDTC之间的一个状态，有的DTC被确认的判定条件比较严苛，需要在多个OperationCycle中出现才可以被判定为confirmed的状态，此时就需要借助于pendingDTC位了。pendingDTC=1的时候，DTC就要被存储下来了。如果当前OperationCycle中故障发生，pendingDTC=1，但是在下一个OperationCycle中，故障没有了，pendingDTC仍然为1，再下一个OperationCycle中，故障仍然不存在，那么pendingDTC就可以置0了。

pendingDTC状态位置位算法：

ISO 14229-1中pendingDTC状态位置位示意图

● 置1：原本无故障，但在上一次或当前操作循环中出现一次测试结果为Failed

● 清0：a）在上一个操作循环和当前操作循环均未发生故障（pending被置位后，需要连续两次OperateCycle没有监测到故障）；b）14服务清除DTC

 

bit3：confirmedDTC（历史故障）
 

当confirmedDTC=1时，则说明某个DTC已经被存储到ECU的non-volatile memory中，说明这个DTC曾经满足了被confirmed的条件。但是请注意，confirmedDTC=1时，并不意味着当前这个DTC仍然出错，如果confirmedDTC=1，但testFailed=0，则说明这个DTC表示的故障目前已经消失了。

confirmedDTC状态位置位算法：

ISO 14229-1中confirmedDTC状态位置位示意图

● 置1：满足confirmed条件（几个连续的操作循环检测到故障），此时该DTC已被存储至EEPROM中

● 清0：a）当操作循环次数已满足老化阈值；b）14服务清除DTC；c）故障记忆溢出

 

bit4：testNotCompletedSinceLastClear

 

这个bit用于表示，自从上次调用了清除DTC的服务之后，是否成功地执行了对某个DTC的测试（不管测试结果是什么，只关心是否测了）。因为很多DTC的测试也是需要满足某些边界条件的，并不是ECU上电就一定会对DTC进行检测。

testNotCompletedSinceLastClear状态位置位算法：

ISO 14229-1中testNotCompletedSinceLastClear状态位置位示意图

● 置1：自从清DTC之后还没有完成过针对该DTC的测试

● 清0：自从清DTC之后已经完成过针对该DTC的测试
 

bit5：testFailedSinceLastClear

 

这个位与bit1:testFailedThisOperationCycle有些类似，后者表示某个DTC在当前的OperationCycle中是否出现过testFailed置1的情况，而testFailedSinceLastClear表示的是在上次执行过清除DTC之后某个DTC是否出过错。

testFailedSinceLastClear状态位置位算法：

ISO 14229-1中testFailedSinceLastClear状态位置位示意图

● 置1：自上次清除诊断信息以来，DTC测试至少返回了一次失败的结果

● 清0：a）满足老化阈值；b）故障记忆溢出；c）清除DTC后
 

bit6：testNotCompletedThisOperationCycle

 

这个位与bit4：testNotCompletedSinceLastClear类似，后者表示自从上次调用了清除DTC的服务之后，是否成功地执行了对某个DTC的测试。而testNotCompletedThisOperationCycle则表示在当前OperationCycle中是否成功地执行了对某个DTC的测试。

testNotCompletedThisOperationCycle状态位置位算法：

ISO 14229-1中testNotCompletedThisOperationCycle状态位置位示意图

● 置1：a）指示DTC测试在当前操作循环内尚未运行完毕；b）14服务清除DTC

● 清0：测试运行并且通过或失败；

 

bit7：warningIndicatorRequested

 

某些比较严重的DTC会与用户可见的警告指示相关联，比如仪表上的报警灯，或者是文字，或者是声音。这个warningIndicatorRequested就用于此类DTC。如果这个DTC不支持警告指示，则这个位永远置0。

warningIndicatorRequested状态位置位算法：

ISO 14229-1中WarningIndicatorRequested状态位置位示意图

● 置1：ECU请求激活警告指示

● 清0：ECU不请求激活警告指示

 

DTCAging（DTC老化）

 

DTC诊断故障代码一旦生成，将会一直保留，直到通过发送诊断指令清除，或者通过诊断故障代码老化机制确定此故障不复存在。当一直处于TestPassed，可将这个DTC清除掉，这个过程的结果被称为self-healing，而这个过程，我们就叫做DTC的老化。

在诊断自恢复过程中，往往会定义30个或40个循环周期作为自恢复的条件。原因是：在一个相对较长的过程中，如果车辆没有发生这个故障，可以认为这个故障是一个偶发的现象，也可以认为现在的车辆处于一个相对稳定的状态，因而，可以将这个故障码清除。

 

DTC AgingCounter例子

 

ISO 14229-1中DTC AgingCounter示例

1

DTCAging计数器在完成测试未失败的第一个操作循环后递增为1，DTCAging计数器开始计数的条件是：testFailed=0,PendingDTC=0,ComfiredDTC=1。

2

pendingDTC=0的条件是在一个操作循环后测试完成且未失败（testNotCompletedThisOperationCycle=0，tesetFailed=0，tesetFailedThisOperationCycle=0）。如果ECU不支持掉电顺序（即在关闭点火开关时立即断电），则将无法检测到操作循环的结束。因此，在下一个操作循环开始时将pendingDTC设置为零也是有效的。

3

DTCAging计数器在完成测试未失败的第二个操作循环后递增为2。testNotCompleted-ThisOperationCycle=0，tesetFailed=0。

4

DTCAging计数器继续递增，因为测试在这些操作循环中没有失败。tesetFailed=0。

5

当完全满足老化标准时（例如，DTCAging计数器达到特定值），confirmedDTC设置为零，DTC会从内存中清除掉。

6

DTCAging计数器达到最大值（例如40），此时confirmedDTC被清除。

7

车辆制造商有责任指定testFailedSinceLastClear位是否通过老化标准或由于故障存储器溢出而重置。

 

通过本文的系统性介绍，我们全面解析了DTC从编码规则、状态管理到老化清除的完整生命周期。DTC不仅是简单的故障代码，更是连接车辆故障现象与根本原因的桥梁。掌握DTC的运作机制，就如同拥有了诊断汽车电子系统的“解码器”，能够从海量故障数据中提取有价值的信息，为故障排查、系统优化和品质提升提供坚实的数据支撑。

北汇信息在汽车诊断领域拥有深厚的技术积累，依托与多家主流OEM的长期合作，深入理解DTC在实际车型中的应用与诊断需求，积累了丰富的故障诊断测试经验。如您有相关测试或诊断开发需求，欢迎随时与我们联系。

 

参考文献：

[1] Road vehicles — Unified diagnostic services (UDS) — Part 1:Application layer

[2] Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics Part 6: Diagnostic trouble code definitions