本文主要是介绍如何理解汽车诊断中的，诊断故障代码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诊断
（1）：先介绍DTC的组成，格式，和编码转换关系
1.1DTC基本格式（故障内码）
UDS诊断中，DTC故障内码，分为三个字节，分为高中低三个字节
如我们读取DTC时，会直接读取到三个字节的十六进制数字 如依次从高字节到低字节为
0x43 0xE7 0x11 ,叫做故障内码，或我自己称为DTCraw值
1.2DTC编码规则（其实也是叫做故障码表示字符）
有一定测试校验的朋友应该知道，我们常看到的DTC(如：P0 4 15 27)是这样，那么三位十六进制数，一定是存在于我们常见格式，有确定的一种映射关系。
其中DTC Hight 指示三个方面的信息
1：指示DTC所指示的系统 + DTC是否是ISO定义的类型还是制造商自定义的DTC + 错误子类型
1.1：指示DTC所指示的系统
汽车按制造和通讯，将汽车总体分为四个部分，1：动力系统域 。2：车身域（包括，大屏，BCM，座椅，电动后尾门之类）3：车载底盘（abs+emp等）4：通讯部分
DTC最高字节，的最高两位。指示的就是DTC属于哪个系统
| 0x00 | P:Powertrain动力 系统 |
| 0x01 | C:chassis底盘系统 |
| 0x10 | B:Body车身系统 |
| 0x11 | U:Network网络 |
如果不好记：可以按照下面方法记住：PCB(印刷电路板)+U(有)吗？
1.2 指示DTC是制造商定义还是ISO/SAE定义的故障
此处是DTC High Byte的bit5&bit4
| 0x00 | ISOSAE标准定义故障码，此处表示的是 国际标准组织和SAE定义的标准故障码。此处需注意，并没有强制规定，必须满足 |
| 0x01 | 制造商自定义类型故障码（主要由主机厂和供应商决定） |
| 0x10 | ISOSAE保留码 |
| 0x11 | ISOSAE保留码 |
还需要说明两点：
1：很多资料说 0x10到0x11是IS0/SAE Controller，其实更准确的是理解为ISOSAE保留码，只是ISO/SAE保留，本意是留着为了未来扩展使用。他即不许别人用，目前他自己也没用上。
2：powertrain动力域，或chassis底盘域，因为制造条件更为苛刻，故ISO/SAE强制规定了一些DTC是必须要满足要求的。
而车身域，制造要求不是那么高！基本都是制造商自定义的，即基本都是B1开头。此处又引出一个新问题，对于车身域的DTC，浪费了一个bit位。导致理论上车身域DTC数量比其他域（如powertrain车身域）少一半。
1.3 错误子类型（或叫做错误子系统）
我通过查阅资料，只查找到网络域和动力域，和底盘域，暂时没有找到对其子系统的划分规则。
而对于网络域：
- 0代表网络电器
- 1，2代表网络通讯
- 3代表网络软件
- 4，5代表网络数据
需要解释：最常见的是1,2代表节点之间失去通讯（如ECU1与ECU2,他们提供0x001和0x002相互通讯，且都是循环帧，此类帧暂时可命名为通讯帧，用户需要定义多长时间未收到通讯帧，如100ms未收到，则报出此DTC）。4,5代表网络数据无效或错误。
0：是代表网络电器自身故障（如短路，短路啥的），网络电器是指，网关，交换器，等用于转发，寻址，路由的机器
3：是代表网络与机器不匹配。
注意：网络域虽然是划分为一个独立的域，但是他存储的实体，依然是一个个独立的控制器，U开头的DTC,是存在于车身域，动力域，车身域的各个实物上控制器上的。
下面以三个实例说明
- U0101，前三个字符按照上述说明解析，后两字符01代表的具体故障对象和类型是与TCM通讯丢失
- U0302，后两字符02代表的具体故障对象和类型是与变速器控制模块软件不兼容，这里是不兼容，的意思：软件中配置的DTC格式和软件生成的DTC格式不兼容。
- U0405，后两字符05代表的具体故障对象和类型是从巡航控制模块接收到的数据无效
此三个DTC都是ISO/SAE定义的。
对于动力域：它是由若干个实物组成的子系统，来划分的
0：表示燃油和空气计量辅助排放控制整个系统；
1：表示燃油和空气计量系统；
2：表示燃油和空气计量系统（喷油器）
3：表示点火系统；
4：表示废气控制系统；
5：表示巡航、怠速控制系统；
6：车载电脑和输出信号；
7：传动系统控制；
8：传动系统控制；
对于车身域和底盘域，ISO/SAE也规定了，一部分代码，按照图中的显示表示，最多车身域和底盘域能划分为15个子系统。但是现在不知道，子系统是如何划分的。按照一般经验，子系统不应该由ISO/SAE规定，因为不同的车型，具有不同的配置，应该根据项目来实际定义。
附录1：
附录为部分ISO/SAE的标准化代码。
附录2：
1.4DTC的MiddleByte字节
Middle其实是最复杂的，我查阅了很多资料。很多都没有详细介绍。甚至没有介绍。
要了解清楚DTCMiddleByte,先要了解一个概念：有效表示的DTC，
所谓有效DTC，就是包含有效信息的字节
第一种：前两字节包含了有效信息，第三个字节LowByte不包含任何信息，填充00，此情况下，MiddleByte包含了，错误具体类型，但是具体格式，没有任何规范强制规定。
第二种：DTC的三个Byte都包含，有效信息。则MiddleByte则指示的是子系统（如车身域的BCM行车电脑），它控制器上挂载了很多负载，如各种各样的电机，车灯，传感器，继电器等很多负载
加上他自身各种DTC需要检测和存储，导致此模块其实需要的DTC数量非常巨大。如 B14(4代表BCM)XX XX,是不能包含所有DTC的。于是MiddleByte,就起到了划分子系统的目的。将BCM的单块，划分为车窗电机模块MiddleByte=01，车锁电机模块MiddleByte=02，车外灯模块MiddleByte=03.。。。。。。
1.5 DTC的LowByte
DTCLowByte则是描述故障种类和子类型，该部分内容遵循ISO 15031-6；对于不需要该字节信息的DTC，可填充为0x00。
格式说明：DTC 故障类型由 16 (实际上只有10个类型，另外两个是预留)个不同的DTCFailureCategory（故障类别）组成，而每个类别与 16 个DTCFailureSubtype(子类型故障)相关联。
表格 ：DTCFailureCategory（故障类别）组成
| 0 | 一般故障信息-该类别包括所有其他类别，当该故障类别中的故障是唯一的（不适用于通过分配新的子类型进行标准化）或当检测到的故障最好由该故障类别内的两个或多个子类型描述时使用。（也就是说单需要比较特殊的类型时会将放在此类型） | ||
| 1 | 一般电气故障-这一类别包括标准接线故障模式（即短路和开路）和与欧姆定律相关的直流电（DC）量。 | ||
| 2 | 一般信号故障-这一类别包括与振幅、频率或变化率和波形相关的数量。注意此处的信号 并不是指总线上的信号（DBC文件定义的信号）是指PWM等外接信号的输入。如果网络上电平信号。出现故障。该由子系统 | ||
| 3 | FM（调频）/PWM（脉宽调制）故障-此类故障包括与控制模块的调频（FM）和脉宽调制（PWM）输入和输出有关的故障。该类别还包括位置由计数决定的故障。 | ||
| 4 | 系统内部故障——这一类别包括与存储器、软件和内部电路相关的故障，需要更换部件（控制模块、传感器等）。 | ||
| 5 | 系统编程故障——这一类别包括与操作软件、校准和选项相关的故障，这些故障可通过配置/编程系统的一部分（控制模块、传感器等）来修复。 | ||
| 6 | 基于算法的故障-这一类别包括基于比较两个或多个输入参数的合理性或将单个参数与时间本身进行比较的故障。 | ||
| 7 | 机械故障-这一类别包括由于响应控制模块相关输入/受控输出的不当运动而检测到的故障。 | ||
| 8 | 总线信号/消息故障-这一类别包括与总线硬件和信号完整性相关的故障。当信号的物理输入位于一个控制模块中，而另一控制模块诊断电路或由于报告的电路故障而禁止操作时，也会使用此类别。 | ||
| 9 | 部件故障-此类别包括与部件故障相关的故障（包括参数故障、性能装配故障和操作环境故障） | ||
| A-E | ISO/SAE保留-此值范围由ISO 15031的这一部分保留，以备将来扩展。 | ||
| F | 特定于车辆制造商/系统供应商-这一点：车辆制造商/供应商使用的车辆。 | ||
10个DTCFailureCategory每一个又对应16个DTCFailureSubtype，故理论上有10*16=160个子类型故障。
我节选DTCFailureCategory=00时的，DTCFailureSubtype
表格：DTCFailureCategory=00的 DTCFailureSubtype 分类
| DTCFailureCategory:00一般故障信息 | ||||
| 0 | 也就是，不需要lowByte来指示错误类型，对应的，Category也必须是00 | |||
| 1 | 一般电气故障-此Subtype用于无法分配给特定Category的一般电气故障（类别信息而无子类型信息，例如DTC（011501）：P0115发动机冷却液温度传感器电路-一般电气故障）。 也就是说，即使是Category=0也是能够分配子类型的，可以看做是ISO/SAE的拓展 | |||
| 2 | 一般信号故障-此Subtype用于无法分配给特定Category的一般信号故障（类别信息，无子类型信息，例如DTC（014802）：P0148燃油输送错误-一般信号故障）。 | |||
| 3 | FM（调频）/PWM（脉宽调制）故障—此Subtype用于无法分配给特定Category的FMPWM故障。 | |||
| 4 | 系统内部故障-此Subtype用于无法分配给特定Category的控制模块内部故障。 | |||
| 5 | 系统编程故障-此Subtype用于无法分配给特定Category的系统编程故障。 | |||
| 6 | 基于算法的失败-此Subtype用于无法分配给特定Category的基于算法的故障。 | |||
| 7 | 机械故障-此Subtype用于无法指定给特定Category的机械故障 | |||
| 8 | 总线信号/消息故障--此Subtype用于无法分配给特定Category的总线信号/信息故障 | |||
| 9 | 组件故障-此Subtype用于无法分配给特定Category的组件故障 | |||
| A-F | ISO/SAE保留此值范围为SO 15031，以备将来扩展 | |||
仔细观察，发现所有子类中都有“此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 分类
| General signal failures | ||||
| 0 | ISO/SAE保留-此值由ISO 15031的此部分保留，以供将来扩展 | |||
| 1 | 信号振幅最小此子类型用于控制模块测量到的信号电压低于指定范围，但不一定是对地短路（例如低增益）的故障。 | |||
| 2 | 信号振幅最大值此子类型用于控制模块测量到的信号电压高于指定范围，但不一定是对蓄电池短路（例如增益过高）的故障。 | |||
| 3 | 信号一直处于低位-此子类型用于控制模块测量到的信号在预期转换时保持低位的故障 | |||
| 4 | 信号一直处于高位-此子类型用于控制模块测量到的信号在预期转换时保持高位的故障 | |||
| 5 | 信号形状/波形故障-此子类型用于信号形状（振幅相对于时间的曲线图）不正确的故障，例如电路阻抗不正确。 | |||
| 6 | 低于阈值的信号变化率——此子类型用于信号转换速度慢于合理允许的故障。 | |||
| 7 | 高于阈值的信号变化率——此子类型用于信号转换速度超过合理允许的故障。 | |||
| 8 | 信号偏置电平超出范围/调零故障-此子类型用于控制模块向叠加有信号电压的电路（如氧传感器电路）施加偏置电压的故障。此子类型也用于控制模块将零信号电平施加到叠加有信号电压的电路的故障（例如，对氧传感器电路的偏置电压，或在车辆静止时对横向加速器传感器模块的滤波数字m/sec2信号）。 | |||
| 9 | 信号无效-此子类型用于在给定操作条件下信号值不合理的故障。 | |||
| A-E | ISO/SAE保留-此值范围由SO 15031的此部分保留，以备将来扩展。 | |||
| F | 信号不稳定-此子类型用于信号暂时不可信（时间不够长而不连续）的故障。 | |||
（2）：介绍DTC状态码的结构，的组成，和格式
| 故障状态码格式和应用说明 | ||||||
| bit | 英文简要描述 | 描述 | ||||
| Bit0 | TestFailed | 置1代表，请求时刻测试结果为失败，表示当前结果为故障状态 | ||||
| Bit1 | TestFailedThisOperationCycle | 置1代表，在当前点火循环或检测周期内，至少失败过1次。 | ||||
| Bit2 | PendingDTC | 置1代表，在当前或者上一个点火循环测试结果不为失败 | ||||
| Bit3 | ConfirmedDTC | 置1代表，请求时刻DTC被确认，一般确认是在一个点火周期 内发生错误1次，表示存在历史故障 | ||||
| Bit4 | TestNotCompletedSinceLastCycle | 置1代表，自上次清除DTC之后测试结果已完成，DTC检测尚 未完成 | ||||
| Bit5 | TestFailedSinceLastCycle | 置1代表，自上次清除DTC后测试失败，DTC为故障状态 | ||||
| Bit6 | TestNoCompletedThisOperationCycle | 置1代表，当前操作循环测试还没有完成，DTC检测还未完成 | ||||
| Bit7 | WarningIndicatorRequest | 置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
清除DTC之后，故障检测是否失败
0：没有失败，1：失败过
注意0的情况下，也可能是故障检测没有完成。
7:bit 6，testNotCompletedThisOperationCycle
当前循环，是否完成过故障检测
0：完成了，1：没有完成
8:bit 7，warningIndicatorRequested，
ECU是否请求点亮警告灯
0：没有请求，1：请求了
DTC检测过程中，还需要理解以下术语
（1）使能标准：DTC检测需要特定的条件，
（3）：DTC的ExtenedInformation（额外扩展信息）和snapshoot（快照信息介绍）
额外扩展信息的主要用途是保存，DTC相关的动态数据
1：DTC发生计数器
2：当前阈值
3：上次发生时间
4： “错误验证”计数器（记录检测失败的次数）
5：测试未完成 计数器
6：错误发生计数器
7：DTC老化计数器
必须解释以下几个概念：
（4）snapshoot（快照信息）
Snapshot是针对DTC存在的。即Snapshot是与特定的某个DTC是关联的。其也是保存在模块的非易失性存储器中。
ISO14229未定义DTC Snapshot的内容，但DTC Snapshot的主要用途是在检测到系统故障时保存数据。主要有制造商根据可能会影响DTC的各种因素（如：车速，模块电压，发生时间，及其他因素）
此外，规范也未规定，DTC在什么状态（如：penging confirm才能记录snapshot，由制造商来确定）
一个DTC可以被多次检测到（如在不同的点火循环都被检测到），则可以记录若干个DTC，每个DTC都可以有一个识别ID。
下图是关于DTC检测的规范和方法总结
诊断自恢复：指的是老化（aging),需要设置老化检测计数器和阈值，每次operateCycle，错误不存在，该计数器+1，当计数器超过阈值时。系统会清除掉该DTC。
（5）：介绍14229-1中，uds中关于DTC服务
5.1:介绍14服务
客户端使用清除诊断信息服务
14服务没有子功能，只能对特定DTC/特定DTC组/DTC组进行清除，清除DTC后，该DTC相关的扩展信息，也会被清除。
否定响应码支持
参数定义：
14服务是否支持物理寻址和功能寻址（无强制规定，需制造商自己定义）
执行服务，是否需要安全等级解锁(未规定)，但是如果需要解锁（27），必须支持33,34,35NRC
5.2 介绍19服务
19服务一般有以下6个子功能，比较常见。实际上ISO14229中规定的子功能有11个。
| 0x19 | ReadDTCInformation | 0x01 ReportNumberOfDTCByStatusMask |
| 0x02 ReportDTCByStatusMask | ||
| 0x04 ReportDTCSnapshotRecordByDTCNumber | ||
| 0x06 ReportDTCExtendedDataRecordByDTCNumber | ||
| 0x0A ReportSupportedDTC | ||
| 0x03 获取DTC快照记录ID |
5.2.1 介绍ReportNumberOfDTCByStatusMask19 01
通过状态掩码去查找与其相匹配的故障个数，格式如下
通常我们可以通过此服务，来确定各种类型DTC的数量，比如查找PendingDTC的数量，confirmDTC的数量，来确定总体车DTC的分布情况。
第3个字节，表示服务器，支持的状态掩码。也就是服务器支持哪些状态的DTC,如一些项目就不支持Pending类型的DTC。
肯定respond中的第4个字节，是表示DTC的格式，不同标准的DTC格式是不同的。
5和6字节是表示数量：如 DTCCount=500=0x1F4 ,5字节=0x01,6字节=0xf4。需要注意
5.2.2通过状态掩码报告 DTC （19h 02h）
肯定响应前三个字节，和19 01服务一样。7字节、11字节，是针对每一个DTC的状态码，指示其状态。注意帧顺序中的低字节代表DTC的HighDTC。表格中的DTC默认为14229-1中定义的3字节DTC。
5.2.3 通过 DTC 码报告 DTCSnapshotID 记录（19h 03h）
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按照升序存储。
5.2.4 通过 DTC 码报告 DTCSnapshot 记录（19h 04h）
这个是比较复杂的，
5.2.4 – 通过 DTC 码报告 DTC 扩展数据记录（19h 06h）
请求
请求报文中#6字节，ExtDataRecordNumber值（Hex） 说明
0 不可用（保留）
01~8F 请求服务器报告汽车制造商指定存储的DTCExtendedData（DTC扩展数据）记录。
90~EF 请求服务器报告法定OBD存储的DTCExtendedData（DTC扩展数据）记录。
F0~FD 保留
FE 请求服务器报告单条响应消息中所有法定OBD存储的DTCExtendedData（DTC扩展数据）记录。
FF 请求服务器报告单条响应消息中所有存储的DTCExtendedData（DTC扩展数据）记录。
（6）简单介绍OBD诊断与UDS诊断的不同
1：执行标准不同 OBD应用层，执行的是ISO15031系列标准(WWH-OBD执行的是ISO27145)
2：uds应用层，执行的是ISO14229系列标准
3：故障代码长度不同；OBD是2字节，UDS是3字节。
后面有时间会详细解释不同之处。
这篇关于如何理解汽车诊断中的，诊断故障代码DTC的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
