DTC的全称是Diagnostic Trouble Code，即诊断故障码，它是由车载诊断系统识别的故障状态的数字通用标识符。 怎么去理解呢？可以去想象一个场景，如果我们的汽车在运行时出现的故障，我们很大可能会送去维修。那么维修人员如何快速的定位到汽车出现故障的地方呢？这时候他们就会使用专业的诊断仪器直接读取出当前车辆的故障码。他们之所以能读出故障码是因为汽车的车载控制器会时刻监控汽车的运行情况，在发现汽车故障的时候会将相关信息进行存储，维修人员通过诊断仪向汽车发送19服务（请求读取故障信息）的请求，车载控制器就会反馈对应的故障信息，而故障码DTC就是这些故障信息的身份ID。

DTC由三部分组成：DTC High Byte、DTC Middle Byte、DTC Low Byte(采用ISO15031-6定义的标准)。其中DTC High Byte、DTC Middle Byte这两个字节表示故障内码，对应5位标准故障码。下表为故障内码和5位标准码的位置对应关系。 下图时每一位故障标准故障码所代表的含义及分类。

DTC Low Byte 描述了故障种类和子类型，该部分遵循ISO 15031-6，常见的timeout就用0x87来表示，一般对于排放相关的ECU的DTC最低字节均为0x00，而对于非排放相关的ECU则需要参考ISO标准来定义。

举例： 如P010016，第一位是P代表此故障码和动力系统相关，第二位是0.第三位是1，表示燃油和空气供应的测量相关，第四位和第五位是都是0，第六位和第七位16则是DTCLowByte的内容。

P010016： 二进制表示为：0000 0001 0000 0000 0001 0000 十六进制表示：0x10010

这一小节介绍与 19服务（ReadDTCIninformation ）一起使用的 DTCStatusMask / statusOfDTC 参数的映射。每个服务器都应遵循下表中定义的存储位打包 DTC 状态信息的约定。位域的实际用法应在实施标准中定义。

TestFailed 位的状态不应直接链接到与监视器状态关联的故障安全行为。这意味着为了触发与某个监视器的状态相关的故障安全行为，需要维护一组单独的状态位。车辆制造商应定义是否以及如何应用和实施DTC状态和故障安全相关监视器状态之间的任何同步机制。

在诊断系统设计时，我们需要设置每一个DTC的"故障恢复条件"。简单的理解就是满足一定的条件，系统会认为从故障中恢复。 例如：欠电压故障（又称“电压过低故障”） 故障的设置条件：Voltage < 9V；t > 500ms。 故障的恢复条件：9.5V < Voltage < 18V；t > 500ms。 我们认为达到故障的恢复条件即为TestPassed。那么问题来了：是不是达到了这个条件，系统就会清除这个DTC呢？答案是否定的。故障的设置条件中需要增加一个自恢复（self-healing）的条件。原因是，车辆行驶的过程中所记录的DTC，并不会一直被记录下去，而是需要通过一个过程。当一直处于TestPassed，才可将这个DTC清除掉，这个过程的结果被称为self-healing，而这个过程，我们就叫做DTC的老化。

DTC的老化是一个过程，这个过程是以循环周期作为单位。有几种周期被采用：

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