如何理解汽车诊断中的，诊断故障代码DTC

       DTC(Diagnostic Trouble Code)全称诊断故障代码，是汽车诊断中非常重要的一个分支技术。也可以说是非常重要的组成部分。在uds 诊断和OBD诊断都是不可或缺的组成部分。充分理解DTC对于汽车开发过程也是必不可少的。

      本文主要说明UDS下的诊断故障代码，即理解UDS下的DTC，OBD下的DTC会简单介绍。本文的结构如下：

（1）：先介绍DTC的故障内码组成，格式，和编码转换关系（编码关系是重点，）

（2）：介绍DTC状态码的结构，的组成，和格式

（3）：DTC的ExtenedInformation（额外信息）和snapshoot（快照信息介绍）

（4）：介绍14229-1中，uds中关于DTC服务（14（清除DTC）,19（读取DTC）,85(控制DTC存   储)， 31（因为31服务可以对E2存储器产生影响，故有可能对DTC的存储和读取产生影响，当实际上是一种错误），设计时应该避免31服务对DTC存储产生影响）。

（5)：简单介绍OBD诊断

       UDS诊断中，DTC故障内码，分为三个字节，分为高中低三个字节

      如我们读取DTC时，会直接读取到三个字节的十六进制数字 如依次从高字节到低字节为

0x43 0xE7 0x11 ,叫做故障内码，或我自己称为DTCraw值

      有一定测试校验的朋友应该知道，我们常看到的DTC(如：P0 4 15 27)是这样，那么三位十六进制数，一定是存在于我们常见格式，有确定的一种映射关系。

其中DTC Hight 指示三个方面的信息

1：指示DTC所指示的系统 + DTC是否是ISO定义的类型还是制造商自定义的DTC + 错误子类型

     汽车按制造和通讯，将汽车总体分为四个部分，1：动力系统域EMC,排气系统等。。） 。2：车身域（包括，大屏，BCM，座椅，电动后尾门之类）3：车载底盘（abs+emp等）4：通讯部分

    DTC最高字节，的最高两位。指示的就是DTC属于哪个系统

U:Network网络

     如果不好记：可以按照下面方法记住：PCB(印刷电路板)+U(有)吗？

     此处是DTC High Byte的bit5&bit4

还需要说明两点：

1：很多资料说 0x10到0x11是IS0/SAE Controller，其实更准确的是理解为ISOSAE保留码，只是ISO/SAE保留，本意是留着为了未来扩展使用。他即不许别人用，目前他自己也没用上。

2：powertrain动力域，或chassis底盘域，因为制造条件更为苛刻，故ISO/SAE强制规定了一些DTC是必须要满足要求的。

而车身域，制造要求不是那么高！基本都是制造商自定义的，即基本都是B1开头。此处又引出一个新问题，对于车身域的DTC，浪费了一个bit位。导致理论上车身域DTC数量比其他域（如powertrain车身域）少一半。

故大家看到故障代码时，前两位时，就可以知道所属系统和代码是否是ISO强制定义的,另外需要说明，如开头的故障码，属于动力域，ISO定义的故障码，一般ISO定义的故障码都是比较重要的，如果出现此类故障码，应该谨慎的对待。

     我通过查阅资料，只查找到网络域和动力域，和底盘域，暂时没有找到对其子系统的划分规则。

而对于网络域：

     需要解释：最常见的是1,2代表节点之间失去通讯（如ECU1与ECU2,他们提供0x001和0x002相互通讯，且都是循环帧，此类帧暂时可命名为通讯帧，用户需要定义多长时间未收到通讯帧，如100ms未收到，则报出此DTC）。4,5代表网络数据无效或错误。

0：是代表网络电器自身故障（如短路，短路啥的），网络电器是指，网关，交换器，等用于转发，寻址，路由的机器

3：是代表网络与机器不匹配。

     注意：网络域虽然是划分为一个独立的域，但是他存储的实体，依然是一个个独立的控制器，U开头的DTC,是存在于车身域，动力域，车身域的各个实物上控制器上的。

下面以三个实例说明

此三个DTC都是ISO/SAE定义的。

对于动力域：它是由若干个实物组成的子系统，来划分的

0：表示燃油和空气计量辅助排放控制整个系统； 1：表示燃油和空气计量系统； 2：表示燃油和空气计量系统（喷油器） 3：表示点火系统； 4：表示废气控制系统； 5：表示巡航、怠速控制系统； 6：车载电脑和输出信号； 7：传动系统控制； 8：传动系统控制；

       对于车身域和底盘域，ISO/SAE也规定了，一部分代码，按照图中的显示表示，最多车身域和底盘域能划分为15个子系统。但是现在不知道，子系统是如何划分的。按照一般经验，子系统不应该由ISO/SAE规定，因为不同的车型，具有不同的配置，应该根据项目来实际定义。

附录1：

附录为部分ISO/SAE的标准化代码。

附录2：

       Middle其实是最复杂的，我查阅了很多资料。很多都没有详细介绍。甚至没有介绍。

要了解清楚DTCMiddleByte,先要了解一个概念：有效表示的DTC，

所谓有效DTC，就是包含有效信息的字节

第一种：前两字节包含了有效信息，第三个字节LowByte不包含任何信息，填充00，此情况下，MiddleByte包含了，错误具体类型，但是具体格式，没有任何规范强制规定。

第二种：DTC的三个Byte都包含，有效信息。则MiddleByte则指示的是子系统（如车身域的BCM行车电脑），它控制器上挂载了很多负载，如各种各样的电机，车灯，传感器，继电器等很多负载

加上他自身各种DTC需要检测和存储，导致此模块其实需要的DTC数量非常巨大。如 B14(4代表BCM)XX ,是不能包含所有DTC的。于是MiddleByte,就起到了划分子系统的目的。将BCM的单块，划分为车窗电机模块MiddleByte=01，车锁电机模块MiddleByte=02，车外灯模块MiddleByte=03.。。。。。。

      DTCLowByte则是描述故障种类和子类型，该部分内容遵循ISO 15031-6；对于不需要该字节信息的DTC，可填充为0x00。

格式说明：DTC 故障类型由 16 (实际上只有10个类型，另外两个bit是预留)个不同的DTCFailureCategory（故障类别）组成，而每个类别与 16 个DTCFailureSubtype(子类型故障)相关联。

     表格  ：DTCFailureCategory（故障类别）组成

 10个DTCFailureCategory每一个又对应16个DTCFailureSubtype，故理论上有10*16=160个子类型故障。

我节选DTCFailureCategory=00时的，DTCFailureSubtype

                      表格：DTCFailureCategory=00的 DTCFailureSubtype 分类

 仔细观察，发现所有子类中都有“此Subtype用于无法分配给特定Category的”这句话该如何理解”

这基本是对于ISO/SAE规定的标准DTC而言的。一开始ISO(国际标准化组织)/SAE(【美国】汽车工程师协会)规定了powertrain域的很多DTC,这些DTC，都没使用LowByte。ISO/SAE认为这些故障码已经足够指示清楚DTC错误的类型了。可是随着技术发展和车型功能的增加。原先两字节的DTC已经无法指示清楚，DTC发生的具体位置和错误原因。故工程师们又引入第三个字节来，以此来增加信息含量。

但是又出现了新问题，原先2Byte的DTC，如何适应和兼容3Byte的DTC。

于是工程师们又想出了两个方法：

1：对于不需要第3Byte指示信息的2ByteDTC，第3Byte直接使用00，填充

2：对于那些因为技术发展，不能准确表达含义的2ByteDTC，Low高4bit，直接设置为0，低4bit，可以设置为上图的各种类型。如会出现P013401的故障码

     表格：DTCFailureCategory=02的 DTCFailureSubtype 分类

置1代表，请求时刻DTC被确认，一般确认是在一个点火周期

内发生错误1次，表示存在历史故障

置1代表，自上次清除DTC之后测试结果已完成，DTC检测尚

未完成

置1代表，故障指示请求，1表示特定的DTC警告指示灯亮，

或触发相应的帧发送。这里指示灯，大概率是指的是仪表盘

上的故障指示灯。

 DTC故障码的状态位,也被称为DTC状态掩码。

是对DTC的重要补充和说明。因为DTC除了指示错误出现的严重度和错误出现的地方，是没有其他信息的。

我们判断一个故障的严重性，还要根据故障出现的次数来确定，如一个故障只出现一次，之后再也没有出现过，首先得确定这是不是可能是一个偶发错误，这个错误可能是因为外接干扰或其他很低概率事件导致。如果一个故障每次都能检测到。这大概率能够确定，这是一个错误。

下面对表中的一些名词作出解释

1：当前点火循环或检测周期；点火循环是指一次OFF->ACC->ON->IGN->OFF的循环。检测周期：是指测试方式，一般DTC的检测都是周期检测。

2：TestFailed：

表示测试时刻，故障是存在的。此位是一般应用于测试，如：B141321代表ECU模块的KL30电压值过高。当我们直接将KL30电压的调节到18V时，TestFailed置1。则知道该DTC判断的阈值为：电压>18V。

3：TestFailedThisOperationCycle

就是记录当前cycle中是否发生过故障检测失败的情况，每次进入新的cycle都会先置0。请求时刻故障不一定出现，但是该故障在本次点火循环中已经被检测到了。且本DTC还没有被划分到ConfirmedDTC。

4：ConfirmedDTC(确认DTC)

ConfirmedDTC=1时，对于一些确认要求比较严格的DTC，是需要几个连续的OperationCycle中监测到，此ConfirmedDTC位才会置1。

故障的确认是指故障发生的次数超过设定的阈值（此阈值规范没有强制规定，由制造商确定），对于non-OBD（OBD和non-OBD是指控制器负责的部件是否与车辆排放相关，常见的OBD控制器有发动机控制器，变速箱控制器等）的控制器，这个值是1，那么在这种情况下，当DTC pending的时候，也就相当于confirmed了。

5：PendingDTC（挂起DTC）

PendingDTC=1，表示该DTC在当前循环或上一个循环中出现过。代码实现中，即存在一个计数器，在整个Operation Cycle持续监测，如果该计数器检测到故障DTC，计数器+1，同时PendingDTC置1。

注意：对于非Powertrain域的模块，pending=confirm。

pending和confirm清零的步骤和逻辑。

**pending故障清0的逻辑：（1）首次OperateCycle循环，故障被检测到，pending置1，第二次循环故障没有被检测到，pending依然置1。第3次OperateCycle循环，依然故障没有被检测到。

即pending被置位后，需要连续两次OperateCycle没有监测到故障，pending故障清0。此外14服务清除后，pending也会清0。

**confirm清0，逻辑，当Confirm置1后，

6:bit 5，testFailedSinceLastClear

0：没有失败，1：失败过

注意0的情况下，也可能是故障检测没有完成。

7:bit 6，testNotCompletedThisOperationCycle

0：完成了，1：没有完成

8:bit 7，warningIndicatorRequested，

0：没有请求，1：请求了

DTC检测过程中，还需要理解以下术语

（1）使能标准：DTC检测需要特定的条件，

额外扩展信息的主要用途是保存，DTC相关的动态数据

1：DTC发生计数器

2：当前阈值

3：上次发生时间

4： “错误验证”计数器（记录检测失败的次数）

5：测试未完成 计数器

6：错误发生计数器

7：DTC老化计数器

必须解释以下几个概念：

Snapshot是针对DTC存在的。即Snapshot是与特定的某个DTC是关联的。其也是保存在模块的非易失性存储器中。

ISO14229未定义DTC Snapshot的内容，但DTC Snapshot的主要用途是在检测到系统故障时保存数据。主要有制造商根据可能会影响DTC的各种因素（如：车速，模块电压，发生时间，及其他因素）

此外，规范也未规定，DTC在什么状态（如：penging confirm才能记录snapshot，由制造商来确定）

一个DTC可以被多次检测到（如在不同的点火循环都被检测到），则可以记录若干个DTC，每个DTC都可以有一个识别ID。

下图是关于DTC检测的规范和方法总结

诊断自恢复：指的是老化（aging),需要设置老化检测计数器和阈值，每次operateCycle，错误不存在，该计数器+1，当计数器超过阈值时。系统会清除掉该DTC。

客户端使用清除诊断信息服务

14服务没有子功能，只能对特定DTC/特定DTC组/DTC组进行清除，清除DTC后，该DTC相关的扩展信息，也会被清除。

否定响应码支持

参数定义：

14服务是否支持物理寻址和功能寻址（无强制规定，需制造商自己定义）

执行服务，是否需要安全等级解锁(未规定)，但是如果需要解锁（27），必须支持33,34,35NRC

此外，还需知道的是，根据目前项目经验而言：可以执行针对某个独立DTC的清除

如  14  32 45 16 就是清除单个DTC的服务。

问题1：14服务清除DTC后，DTC相关的拓展信息和快照信息会不会被清除掉？

19服务一般有以下6个子功能，比较常见。实际上ISO14229中规定的子功能有11个。

通过状态掩码去查找与其相匹配的故障个数，格式如下

通常我们可以通过此服务，来确定各种类型DTC的数量，比如查找PendingDTC的数量，confirmDTC的数量，来确定总体车DTC的分布情况。

第3个字节，表示服务器，支持的状态掩码。也就是服务器支持哪些状态的DTC,如一些项目就不支持Pending类型的DTC。

肯定respond中的第4个字节，是表示DTC的格式，不同标准的DTC格式是不同的。

5和6字节是表示数量：如 DTCCount=500=0x1F4 ,5字节=0x01,6字节=0xf4。需要注意

这也是我们最经常遇到的一种服务，

肯定响应前三个字节，和19 01服务一样。7字节、11字节，是针对每一个DTC的状态码，指示其状态。注意帧顺序中的低字节代表DTC的HighDTC。表格中的DTC默认为14229-1中定义的3字节DTC。

client可以通过该子功能请求来检索所有捕获的 DTC快照记录的ID信息。服务器应返回所有已存储 DTC快照记录的 ID信息列表。服务器在响应消息中为单个 DTCSnapshot 记录放置的每个项目都应包含一个DTCRecord [包含 DTC number（high，middle，low字节）]和 DTCSnapshot record number。如果为单个 DTC 存储了多个DTCSnapshot 记录，则ECU应在每次响应时使用1个不同的DTCSnapshot record number（便于后续的查询）来表示。

ECU可支持对单个DTC存储多个DTCSnapshot records来跟踪每次DTC发生时的环境条件。DTCSnapshot records数量应被系统供应商或整车厂定义。

客户端成功发出 ClearDiagnosticInformation 请求后，应清除 DTCSnapshot 记录ID信息。 整车厂需要定义清楚删除已存储 DTC 和 DTCSnapshot 数据的规则以防内存溢出。

0x19 0x03举例： 假设 1.对于某个给定的DTC，ECU支持存储2个DTCSnapshot records； 2.ECU应表明对于DTC 123456，当前存储有2条DTCSnapshot records，DTC已发生3次（此时由于ECU内存不足，仅存储第一次和最后一次DTCSnapshot record） 3.ECU应表明DTC 789ABC，当前存储有1条DTCSnapshot record。 4.所有的DTCSnapshot records按照升序存储。

这个是比较复杂的，

请求

请求报文中#6字节，ExtDataRecordNumber值（Hex）    说明 0    不可用（保留） 01~8F    请求服务器报告汽车制造商指定存储的DTCExtendedData（DTC扩展数据）记录。 90~EF    请求服务器报告法定OBD存储的DTCExtendedData（DTC扩展数据）记录。 F0~FD    保留 FE    请求服务器报告单条响应消息中所有法定OBD存储的DTCExtendedData（DTC扩展数据）记录。 FF    请求服务器报告单条响应消息中所有存储的DTCExtendedData（DTC扩展数据）记录。

1：执行标准不同 OBD应用层，执行的是ISO15031系列标准(WWH-OBD执行的是ISO27145)

2：uds应用层，执行的是ISO14229系列标准

3：故障代码长度不同；OBD是2字节，UDS是3字节。

后面有时间会详细解释不同之处。