汽车诊断中常说的DTC是什么？

汽车诊断中常说的DTC是什么？

1.DTC的定义

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

2.DTC的组成

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

3.DTC状态掩码和DTC状态位定义

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

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

3.1 DTC状态位

位名称定义简单理解bit 0testFailed指示最近执行test的结果，test失败（Failed）置1。test通过（Passed）则置0，如果调用了14服务清除DTC的话，也需要重新置0。最近的一次测试是否失败，0：没有失败，1：失败了bit 1testFailedThisOperationCycle该位表示在当前test中，诊断test是否已经报告了一个testFailed结果。在当前操作循环内的测试结果，该操作循环内只要发生过Failed，则置"1"; 开始新的操作循环或发送清故障码服务后，置"0"。当前循环，故障检测是否失败。0：没有失败，1：失败了至少一次bit 2pendingDTC在当前操作循环或上一个完成的操作循环内，测试是否报告过"Failed"; 该状态位只在测试运行和操作循环完成且在该操作循环内从未"Failed"过或发送清故障码服务后才置0；如果在当前操作循环内未完成测试，则状态不变。是否有待处理的故障，0：没有，1：有bit 3confirmedDTC表示故障是否检测到足够的次数，以保证DTC存储到long-term memory中。若足够，则置"1"; 其为1的时候并不意味着此刻故障存在（testFailed 可用于确定请求时是否存在故障）。发送清除故障码或达到aging阈值（40个warm-ups循环里未检测到故障）则置"0"。故障是否确认，0：没有确认，1：确认了bit 4testNotCompletedSinceLastClear表示一个DTC测试从上次清故障码开始，是否运行过或完成过测试；若没有，则置"1";否则置"0"；清故障码置"1"。清除DTC之后，是否完成过故障检测，0：完成了，1：没有完成bit 5testFailedSinceLastClear表示一个DTC测试从上次清故障码开始，是否测试失败过；若没有，则置"0"；否则置"1"；清故障码置"0"。清除DTC之后，故障检测是否失败，0：没有失败，1：失败过，0的情况下，也可能是故障检测没有完成。bit 6testNotCompletedThisOperationCycle表示一个DTC测试在当前操作循环内是否运行完成；若没完成，置"1"；否则，置"0"; 开始新的操作循环或清故障码后则置"1"。当前循环，是否完成过故障检测，0：完成了，1：没有完成bit 7warningIndicatorRequested报告与特定DTC相关的任何警告指示器的状态；没有警告，则置"0",有警告,则置"1"；如果有警告，则confirmedDTC也应设置为1；清故障码或满足制造商定义的要求，则置"0"。ECU是否请求点亮警告灯 0：没有请求，1：请求了

3.2 DTC Aging (DTC 老化)

此段转载于
漫谈DTC之DTC老化 - 东信创智的文章 - 知乎
https://zhuanlan.zhihu.com/p/76717524

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

3.2.1 DTC设计条件

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

上下电作为一 个循环周期；
warm-up作为一个循环周期。
注：warm-up是指发动机预热达到某个预设温度。warm-up循环一般是针对排放相关DTC所设定的循环周期。

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

3.2.2 DTCAgingCounter例子

1. DTCAging计数器在完成测试未失败的操作周期后递增，DTCAging计数器开始计数的条件是：testFailed=0,PendingDTC= 0,ComfiredDTC=1。
2. pendingDTC=0的条件是在一个操作周期后测试完成且未失败（testNotCompleted-ThisOperationCycle = 0，tesetFailed = 0，tesetFailed-ThisOperationCycle=0）。如果ECU不支持掉电顺序（即在关闭点火开关时立即关闭），则将无法检测到操作周期的结束。因此，在下一个操作周期开始时将pendingDTC设置为零也是有效的。
3. DTCAging计数器在完成测试未失败的操作周期后递增。ttestNotCompleted-ThisOperationCycle = 0，tesetFailed = 0。
4. DTCAging计数器继续递增，因为测试在这些操作周期中没有失败。tesetFailed = 0。
5. 当完全满足老化标准时（例如，DTCAging计数器达到特定值），confirmedDTC 设置为零，DTC会从内存中清除掉。
6. DTCAging计数器达到最大值（例如，40），此时confirmedDTC 被清除。
7. 车辆制造商有责任指定testFailedSinceLastClear位是否通过老化标准或由于故障存储器溢出而重置。