【车载开发系列】UDS诊断---读取DTC信息（$0x19）-Toy模板网

这篇具有很好参考价值的文章主要介绍了【车载开发系列】UDS诊断---读取DTC信息（$0x19）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

【车载开发系列】UDS诊断—读取DTC信息（$0x19）

一.概念定义

UDS可以简单理解为一套完整的通讯协议框架，其目的在于规范各种行车电脑和ECU之间的通讯。0x19服务其实是读取DTC信息的服务。

1）DTC概念

故障存储相关的0x19和0x14服务。
当系统检测到了一个错误或者是一个故障发生的时候，会将相对应的数值故障码进行存储，那么这个对应的数值故障码，我们称之为故障码，就是DTC。
一个DTC可以反应出一个故障发生的具体位置，和这个故障发生原因和类型，我们通过读取的DTC信息，可以为维修提供一些依据。除此以外还有与法律有关的故障，比如说排放有关的，在未来还会有安全相关的故障

2）故障类型

在很多国际标准里面都定义了DTC的格式。比如说UDS里定义DTC由3个字节组成，而ISO 15031-6里定义了DTC格式由“两个字节根基+一个字节的故障类型”组成。有95%用到的DTC格式都是ISO 15031-6里定义的DTC的故障类型和格式

3）快照数据

快照数据是指当这个错误发生，或者当这个DTC存储的时候，记录的一些环境数据，比如说车速，水温，发动机转数等这些数据，从而我们读取这些数据之后，能够更好的判断DTC产生的原因以及发生故障原因。

二.DTC相关子功能

在14229-1中定义的19服务读取DTC信息里，定义28个Subfunction，根据不同的Subfunction来获取不同的诊断信息

Hex(位 6-0)	描述	Description
0x01	通过状态掩码报告 DTC 数目	reportNumberOfDTCByStatusMask
0x02	通过状态掩码报告 DTC	reportDTCByStatusMask
0x04	通过 DTC 码报告 DTCSnapshot 记录	reportDTCSnapshotRecordByDTCNumber
0x06	通过DTC码报告 DTC 扩展数据记录	reportDTCExtendedDataRecordByDTCNumber
0x0A	报告支持的 DTC	reportSupportedDTC

1）匹配故障个数（0x01）

通过状态掩码去查找与其相匹配的故障个数。
通过该服务诊断仪能够请求ECU中DTC状态与DTC状态掩码相匹配的故障码个数。
如果某一个故障码的实际状态位为“1”，并且DTC状态掩码中的相应位也为“1”，那么就认为该故障码的状态与DTC状态掩码相匹配（即：如果DTC状态掩码字节与DTC实际状态字节进行逻辑“位与”运算后的结果为非零值，那么两者就相匹配）；此时则将故障数+1。如果客户端定义了一个状态掩码，其中包含ECU不支持的位，那么ECU仅使用本身支持的位进行处理故障信息。

2）DTC的状态码获取（0x02）

按照定义的状态掩码的形式去查找匹配的故障，将匹配的DTC标识符（3个字节）、DTC状态（1个字节）信息返回。01子服务只统计与状态掩码相匹配的DTC个数，02子服务则会将这些匹配的DTC信息返回。

3）读取DTC的快照数据（0x04）

为了方便找到故障的原因，在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据。
在14229里定义的数据叫做快照数据；在Autosar里定义的数据叫做冻结帧，其实他们指的是一类数据。

4）获取DTC扩展数据（0x06）

19 06是来获取DTC存储的时候一些扩展数据，这个数据常用的比如说有一些计数器，比如说老化计数器，这样的数据。

5）请求支持的DTC信息（0x0A）

19 0A是来读取这个ECU所支持的全部的DTC。其响应报文与02服务一致；但要区分，该服务返回的是所有DTC的信息，ECU支持的哪些DTC是在ECU诊断规范的时候已经定义好的，所以我们通过19 0A读取的DTC是这个ECU应该支持的所有的DTC，即使这个DTC没有产生，也能够被读取的；
而02服务是返回与请求时状态掩码相与不为“0”的DTC信息。

三.报文格式

1）SubFunction$0x01和$0x02的场合

$0x01是通过状态掩码报告DTC数目服务。
$0x02是通过状态掩码报告DTC子功能服务。

1.请求报文

SubFunction为01，02的场合的请求如下：
ReportNumberOfDTCByStatusMask就是Subfunction01，返回通过状态掩码报告DTC的数目。
ReportDTCByStatusMask就是Subfunction02。返回通过状态掩码报告DTC。
读取dtc的命令,# 汽车嵌入式---UDS诊断,网络协议,网络

2.$0x01肯定响应报文

DTCStatusAvailabilityMask用于表示ECU支持的DTC状态位。“通过状态掩码报告DTC数目”子功能服务，诊断工具可以获取与诊断工具状态掩码匹配的DTC的数目。
DTCFormatIdentifier是格式标识符，报告了DTC格式及解
码方法的信息
DTCCount是一个 2 字节无符号数，表示ECU内存储的与诊断工具定义的状态掩码匹配的DTC的数目，也就是我们想要查询的结果。

3.$0x02肯定响应报文

ECU须将诊断工具请求的 DTC 状态掩码与它支持的各个DTC实际状态进行“位与”逻辑运算。ECU 将不仅返回 DTC 状态有效掩码，还有所有“与”运算结果为非零的所有DTC。读取dtc的命令,# 汽车嵌入式---UDS诊断,网络协议,网络
C1：此参数只在有可以报告的 DTC 信息时存在。
C2：此参数只在需要报告的 DTC 信息多于一个时存在。

4.否定响应报文

所有的SubFunction的场合的否定响应是一致的。具体如下：
读取dtc的命令,# 汽车嵌入式---UDS诊断,网络协议,网络

2）SubFunction$0x04的场合

19+04+DTC故障码(3位)+快照记录码(1位)
59+04+DTC故障码(3位)+DTC状态位(1位)+快照记录码(1位)+快照信息个数+快照DID+对应的快照DID数据…

1.请求报文

ReportDTCSnapshotRecordByDTCNumber就是Subfunction04，通过DTC报告DTCSnapshot记录。
DTCMaskRecord是DTC快照记录码，占用了3个字节，记录要请求的第几个快照信息。
最后一位是ReportDTCSnapshotRecordByDTCNumber表示返回的数据是对应请求中的DTCSnapshot快照记录码，占一个字节，标识特定的DTC快照数据记录编号。0x00是保留位，0xFF是代表所有组。0x01-0xFE是其的范围。

2.肯定响应

一个DTC 存储多个SnapshotRecords的典型应用是用于存储 DTC 多次发生时记录的数据，这些数据体现了（每次）发生时的整车状况。
如果参数DTCMaskRecord或DTCSnapshotRecordNumber无效或不被ECU支持，ECU应发送否定响应。

C1：此参数只在有可以报告的 DTC 信息时存在。
C2：此参数只在需要报告的 DTC 信息多于一个时存在。

3）SubFunction$0x06的场合

客户端向服务器请求：06 19 06 XX XX XX FF 00
服务器向客户端回复：10 11 59 06 XX XX XX 10；
第一个字节的前四位“1”：
表示该帧为首帧，意味着服务器将等待客户端回复控制帧，以继续发送其余数据
第一个字节的后四位和第二个字节的八个位组成的12位编码：“011”
为当前数据流的总字节数，此处表示有当前数据流中有17个有效字节
第三个字节开始的59 06：
表示0x19服务06子服务的响应。
第五个字节开始XX XX XX：
DTC码和客户端请求的DTC码一致。
最后一个字节10：
当前DTC的状态位。

1.请求报文

ReportDTCExtendedDataRecordByDTCNumber就是SubFunction06。
DTCMaskRecord是DTC掩码记录，DTC记录包含 DTC 高字节, DTC中间字节和DTC低字节，或者依照SAEJ1939格式的DTC。DTC高字节, DTC中字节和DTC低字结合起来代表一个唯一的ECU支持的诊断故障码的标识码。如果ECU内DTC的值与 DTC 掩码记录相等（精确匹配需求），则与其匹配
DTCExtendedDataRecordNumber表示向服务器获取该DTC的所有的扩展数据

2.肯定响应

DTCAndStatusRecord由三个字节所构成，包含了DTC码和ECU支持的DTC状态记录。
DTCExtendedDataRecordNumber就是DTC扩展数据记录号码，占用1字节，用于表示 DTC 对应的扩展数据记录号码。0x00和0xFF不使用之外，其他的值定义是由车厂决定的。
DTCExtendedDataRecord就是具体的报告DTC扩展数据记录的内容。