大家好，我是嵌入式老林，从事嵌入式软件开发多年，今天分享的内容是UDS诊断读取DTC信息0X19服务介绍，希望能对你有所帮助

前言：之前有粉丝私信我说要看诊断19服务的文章，也答应了更新。最近一个月忙于项目，一直没时间写，有空的时候也很累，就拖到现在才写完，在这里说一声抱歉了。

一、读取DTC信息服务

19服务（ReadDTCInformation）：用于读取ECU的故障信息，该服务允许客户端从任何服务器或车辆内的一组服务器读取服务器驻留的诊断故障代码（DTC）信息的状态。除非特定子功能另有要求，否则服务器应返回所有DTC信息。

简单点说就是，当ECU发生故障时，可通19服务读取ECU发生的故障类型，是否为当前发生的故障，该故障的快照信息等

二、数据格式

2.1 请求报文格式

19服务可以说是UDS里面最复杂的一个服务了，子功能有27个（0X01~0X19、0X42、0X55），其请求格式前两个字节都是服务ID和子功能，后面部分会因子功能的不同，稍有不同。详细的格式如下：

格式1：

[SID] + [sub-function] + [DTCStatusMask]

格式2：

[SID] + [sub-function] + [DTCMaskRecord] + [DTCSnapshotRecordNumber]

格式3：

[SID] + [sub-function] + [DTCStoredDataRecordNumber]

格式4：

[SID] + [sub-function] + [DTCMaskRecord] + [DTCExtDataRecordNumber]

格式5：

[SID] + [sub-function] + [DTCSeverityMaskRecord]

格式6：

[SID] + [sub-function] + [DTCMaskRecord]

格式7：

[SID] + [sub-function]

格式8：

[SID] + [sub-function] + [DTCExtDataRecordNumber]

格式9：

[SID] + [sub-function] + [DTCStatusMask] + [MemorySelection]

格式10：

[SID] + [sub-function] + [DTCMaskRecord] + [DTCSnapshotRecordNumber] + [MemorySelection]

格式11：

[SID] + [sub-function] + [DTCMaskRecord] + [DTCExtDataRecordNumber] + [MemorySelection]

格式12：

[SID] + [sub-function] + [FunctionalGroupIdentifier] + [DTCSeverityMaskRecord]

格式13：

[SID] + [sub-function] + [FunctionalGroupIdentifier]

2.2 子功能介绍

19服务支持的子功能如下，看到这么多的子功能，是不是都吓怕了，都不太想看了，没事的，一般工作中不会都用到，常用的子功能就01,02,04,06,0A，后面介绍一下这几个常用的子功能

2.3 肯定响应报文格式

肯定响应的格式和其他服务有点不太一样，19服务的肯定响应格式很多，取决于请求响应的子功能是什么类型

格式1：

[SID + 0X40] + [reportType] + [DTCStatusAvailabilityMask] + [DTCFormatIdentifier] + [DTCCount]

格式2：

[SID + 0X40] + [reportType] + [DTCStatusAvailabilityMask] + [DTCAndStatusRecord]

格式3：

[SID + 0X40] + [reportType] + [DTCRecord#1] + [DTCSnapshotRecordNumber#1] + [DTCRecord#m] + [DTCSnapshotRecordNumber#m]

这里解释一下DTCRecord#1和 DTCSnapshotRecordNumber#1，表示当DTC快照记录只有一个时才会出现，而DTC快照记录有多个时，用DTCRecord#m和 DTCSnapshotRecordNumber#m表示。

格式4：

[SID + 0X40] + [reportType] + [DTCAndStatusRecord] + [DTCSnapshotRecordNumber#1] + [DTCSnapshotRecordNumberOfIdentifiers#1] + [DTCSnapshotRecord#1] + [DTCSnapshotRecordNumber#x] + [DTCSnapshotRecordNumberOfIdentifiers#x] + [DTCSnapshotRecord#x]

格式5：

[SID + 0X40] + [reportType] + [DTCStoredDataRecordNumber#1] + [DTCAndStatusRecord#1] + [DTCStoredDataRecordNumberOfIdentifiers#1] + [DTCStoredDataRecord#1] + [DTCStoredDataRecordNumber#x] + [DTCAndStatusRecord#x] + [DTCStoredDataRecordNumberOfIdentifiers#x] + [DTCStoredDataRecord#x]

格式6：

[SID + 0X40] + [reportType] + [DTCAndStatusRecord] + [DTCExtDataRecordNumber#1] + [DTCExtDataRecord#1] + [DTCExtDataRecordNumber#x] + [DTCExtDataRecord#x]

格式7：

[SID + 0X40] + [reportType] + [DTCStatusAvailabilityMask] + [DTCAndSeverityRecord]

格式8：

[SID + 0X40] + [reportType] + [DTCFaultDetectionCounterRecord]

格式9：

[SID + 0X40] + [reportType] + [DTCExtDataRecordNumber] + [DTCAndStatusRecord#1] + [DTCExtDataRecord#1] + [DTCAndStatusRecord#x] + [DTCExtDataRecord#x]

格式10：

[SID + 0X40] + [reportType] + [MemorySelection] + [DTCStatusAvailabilityMask] + [DTCAndStatusRecord]

格式11：

[SID + 0X40] + [reportType] + [MemorySelection] + [DTCAndStatusRecord] + [DTCSnapshotRecordNumber#1] + [DTCSnapshotRecordNumberOfIdentifiers#1] + [DTCSnapshotRecord#1] + [DTCSnapshotRecordNumber#x] + [DTCSnapshotRecordNumberOfIdentifiers#x] + [DTCSnapshotRecord#x]

格式12：

[SID + 0X40] + [reportType] + [MemorySelection] + [DTCAndStatusRecord] + [DTCExtDataRecordNumber#1] + [DTCExtDataRecord#1] + [DTCExtDataRecord#x]

格式13：

[SID + 0X40] + [reportType] + [FunctionalGroupIdentifier] + [DTCStatusAvailabilityMask] + [DTCSeverityAvailabilityMask] + [DTCFormatIdentifier] + [DTCAndSeverityRecord]

格式14：

[SID + 0X40] + [reportType] + [FunctionalGroupIdentifier] + [DTCStatusAvailabilityMask] + [DTCFormatIdentifier] + [DTCAndStatusRecord]

2.4 否定响应报文格式

否定响应的格式和其他服务也是一样的，很简单

格式：[0X7F] + [SID] + [NRC]

支持的NRC

2.5 状态掩码

状态掩码由八个DTC状态位组成，占一字节。不是所有的bit都支持，具体看客户需求，一般诊断调查表中会给出具体支持哪些bit

bit0：testFailed

“0” = DTC测试的最新结果表明未检测到故障。
“1” = DTC测试的最新结果表明检测到故障。

最近一次执行test的结果，test失败置1，但是它不一定被ECU存储到EEprom中；只有当bit2或bit3被置1时DTC才会被存储。test通过或者清除了DTC则置0

bit1：testFailedThisMonitoringCycle

“0” = 当前测试周期内，DTC测试的结果表明未检测到故障或清除了DTC信息。
“1” = 当前测试周期内，DTC测试的结果表明检测到故障。

当新的检测循环开始时，或调用了14服务后，这个位需要置0。如果该位置1，那么一直保持置1状态直到新的检测循环开始，因此bit1可以理解为当前DTC

bit2：pendingDTC

“0” = 在完成测试且未检测到故障的操作循环后或调用ClearDiagnosticInformation服务时，该位应设置为0。

“1” = 如果在当前操作循环中检测到故障，则该位应设置为1并锁定。

DTC并不是一达到触发位就会被报出来的，而是故障出现一段时间后才会被确认，而中间的这个状态就用bit2位来表示，bit2位其实是表示DTC处于testFailed和confirmedDTC之间的一个状态，因此bit2位又可被称为待定DTC。当某个DTC刚达到判定条件的时候，bit2被置1，若一段时间后故障条件不满足了，则bit2置0；若一段时间后故障仍然存在，那么bit3就要置1了。

bit3：confirmedDTC

“0” = 自上次调用ClearDiagnosticInformation后，或在满足故障诊断码的老化条件（或由于故障记忆溢出而清除了故障诊断码）后，从未确认过故障诊断码。

“1” = 自上次调用ClearDiagnosticInformation后至少确认一次的DTC，且尚未满足老化标准

当bit3置1时，说明故障已经发生了一段时间，也就是bit2至少有一次被置1了。需要注意的是，bit3置1的时候，DTC被存储在EEprom中，但并不代表现在故障还存在，可理解为历史故障。

bit4：testNotCompletedSinceLastClear

“0” = 自上次清除诊断信息以来，DTC测试至少返回一次测试结果（无论通过或失败）。

“1” = 自上次清除诊断信息后，DTC测试尚未运行到完成。

不是所有的DTC测试都是从上电就开始，所以该位用来表示上次调用14服务清除诊断消息后，是否进行过完整的test。如果进行了完整的test，无论结果如何，都置0，否则置1。

bit5：testFailedSinceLastClear

“0” = 自上次清除诊断信息后，DTC测试未显示失败结果。如果满足老化阈值或发生故障记忆溢出，则车辆制造商应负责将该位重置为零（“0”）。

“1” = 自上次清除诊断信息以来，DTC测试至少返回一次失败结果。

该位表示在上次调用14服务清除后DTC后，若test DTC未进行测试或者测试了但结果是pass时置0，如果test运行完成并且返回结果为fail，那么该位置1。在调用14服务清除DTC后需要置0。bit4和bit5通常一起使用。

bit6：testNotCompletedThisOperationCycle

bit6表示在当前检测循环周期过程中DTC test是否完成，若完成了置0；未完成，或调用ClearDiagnosticDTC，需要置1。

bit7：warningIndicatorRequested

该位报告警告指示，比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示，如果没有和DTC相关的警告存在，该位应置0；

如果该DTC有相关警告指示，bit3置1的时候，bit7也要置1。在调用14服务清除DTC后需要置0

2.6 快照数据

快照数据为发生某一故障时记录的当时的环境信息，一般是DTC的电压、发动机转速、时间戳、温度、车速等，从而使工程师在ECU出现故障时能及时了解车辆的历史和实时故障信息

1）全局快照：

指整车层面需要强制支持的快照信息，包含的DID主要是车速，时间，位置等内容。

全局快照和Snapshot Record Num(快照记录号)关联，且所有的DTC默认需要全部支持。

2）局部快照

指控制器不同的DTC故障码支持的快照信息不一样，存在多种DID的组合方式，此部分由DRE/供应商自定义。

局部快照信息仅和DTC关联，即哪一个DTC支持哪一个局部快照组。

2.7快照记录号

DTC快照记录号的英文全称为DTC Snapshot Record Number。在读取快照记录时，就需要使用到DTC快照记录编号。

需要注意的是：一个快照记录号可以包含多个快照记录。

一般在开发当中定义以下三个DTC快照记录号：

1) 0x01 故障第一次发生时的快照信息

2) 0x02 故障最近一次发生时的快照信息

3) 0xFF 表示支持的所有DTC Snapshot Record Number支持的快照记录。

2.8 扩展数据

Extended Data：即为在故障发生时其他的辅助信息，如aged counter(老化计数器) 、Fault Counter(故障计数器)以及event id(事件ID)等

三、举例

3.1 子功能01

01子功能：根据状态掩码报告诊断故障代码(DTC)数量。

就是返回和状态掩码相匹配的DTC数量，如果发送的故障，没有和状态掩码匹配，也不会计入到诊断故障码数量里面。状态掩码在项目中客户会提供的，每个客户需要支持的状态掩码可能不一样。

回顾一下19 01的请求格式和正响应格式：

请求格式：[SID] + [sub-function] + [DTCStatusMask]

正响应格式：[SID + 0X40] + [reportType] + [DTCStatusAvailabilityMask] + [DTCFormatIdentifier] + [DTCCount]

下面例子的DTC状态可用掩码为0B

第一个回复的是否定响应，NRC为13，长度错误，因为项目代码中，会先判断长度是否为3，也就是SID + sub-function + DTCStatusMask，长度不为3则直接回复NRC

第二个发送的请求是：03 19 01 01，后面的4个字节是上位机的填充位。状态掩码为01 ，表示测试失败，如果有测试失败的DTC产生，且和支持的状态掩码相匹配，则收到的正响应里面DTCCount的值就不为0

来看一个产生了DTC的例子：

这是产生了过压故障时，通过19 01读取的结果，可以看到红框两个字节的值为1，就产生了1个故障，而且和状态掩码也匹配

再来看一个产生了DTC，但读取不到DTC数量的例子：

下面的例子也是在产生过压故障时，读取的结果。只不过和支持的状态掩码不匹配，前面我们说了可用状态掩码为0B，转换为二进制就是 0000 1011，0x04 & 0x0B为0

3.2 子功能02

根据状态掩码报告诊断故障代码：

红框中的前3个字节为过压的诊断故障码，最后一个字节0B为DTC的状态

否定响应的例子：

多发了一个字节的数据，报长度不正确的NRC

3.3 子功能04

根据诊断故障代码报告诊断故障代码快照记录：

回顾一下请求格式：

[SID] + [sub-function] + [DTCMaskRecord] + [DTCSnapshotRecordNumber]

即F0 03 16是DTCMaskRecord，即DTC；02是DTC快照记录编号

回复的正响应格式：

DTCAndStatusRecord：红框里面的，即DTC和DTC的状态

DTCSnapshotRecordNumber：02

后面的就是快照记录信息

3.4 子功能06

请求格式：[SID] + [sub-function] + [DTCMaskRecord] + [DTCExtDataRecordNumber]

DTCMaskRecord：这个就是由DTC的三个字节组成，此处为F0 03 16

DTCExtDataRecordNumber：01

响应格式：[SID + 0X40] + [reportType] + [DTCAndStatusRecord] + [DTCExtDataRecordNumber#1] + [DTCExtDataRecord#1] + [DTCExtDataRecordNumber#x] + [DTCExtDataRecord#x]

DTCAndStatusRecord：F0 03 16 0B

DTCExtDataRecordNumber：01

DTCExtDataRecord：05 00 00 00