Tip：本文描述中但凡涉及到其他UDS服务的，将陆续提供链接跳转方式以便快速了解他们。（各服务介绍持续更新中…）

学习UDS基础知识以及其他相关内容？>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<

一、简介

《UDS协议从入门到精通》系列——图解0x19：读取故障码信息
Tip：学习该服务前建议先阅读《到底什么是DTC？》
  0x19服务是子服务类型最多，也是最复杂的以及最重要诊断服务之一，同时也是最能体现“诊断”一词的服务。通过对DTC相关内容的学习我们知道：通过DTC及其附属信息，我们可以了解到目标ECU何时何地何种场景下发生了什么样的错误，这些信息存储在目标ECU的故障存储器中，0x19服务存在的意义就是可以通过不同的子功能来读取目标ECU中存储的这些故障信息（可以理解为通过各种过滤规则读取这些故障信息）。

  下表罗列了该服务最常用的几个子功能（推荐按顺序阅读）：

sub-function	功能简述
0x01：reportNumberOfDTCByStatusMask	检索匹配状态掩码的DTC数
0x02：reportDTCByStatusMask	检索匹配状态掩码的DTC列表
0x04：reportDTCSnapshotRecordByDTCNumber	检索匹配DTC状态掩码的DTCSnapshot记录数据
0x06：reportDTCExtDataRecordByDTCNumber	根据客户定义的DTC掩码和DTCExtendedData记录编号检索DTCExtendedData记录数据
0x0A：reportSupportedDTC	检索目标ECU支持的所有DTC的状态

Tip1：该服务目的是从目标ECU中读取故障信息，因此禁止肯定响应是没有意义的，所以SPR位通常都为0。

二、常用子功能介绍

2.1 reportNumberOfDTCByStatusMask（19 01）

  DTC状态（DTC status）是DTC的关键附属信息之一，如果我们想知道符合特定的DTC状态的DTC数量，就需要通过sub-function为01的请求，所说的这个特定的DTC状态就叫做DTC状态掩码（DTC Status Mask）。

  在该子服务中，该掩码作为请求参数给到目标ECU，目标ECU将其与自身存储的DTC的Status进行“与”运算，并返回"与"运算之后结果不为0的DTC的数量（比如某故障码的实际状态位为“1”，请求信息的DTC状态掩码中的相应位也为“1”，与运算得1，认为两者匹配，此时符合DTC状态的DTC数量+1）。通过该子功能，Tester能够得知目标ECU中DTC状态与DTC状态掩码相匹配的DTC个数。

  DTC的Status用一个byte表示，其中的8个bit分别代表DTC的不同状态，比如，bit0 表示这个是否检测到了这个DTC对应的故障，bit3表示这个DTC是否已经被confirm了，如果DTC的状态是confirm，则说明该DTC已经被ECU存储下来了。更多关于DTC Status的内容参考这篇文章：《到底什么是DTC？》

  2.1.1 数据包格式

——请求格式

  DTCStatusMask（1Byte）：DTC状态掩码，Server收到该请求后，将筛选符合该掩码的DTC数量。

——肯定响应

  DTCStatusAvailabilityMask（1Byte）：用于表示目标ECU支持的状态位，跟DTCStatusMask结构一样，8个bit，bit值为0表示目标ECU不支持这个状态位，为1则表示支持。跟请求中的DTC状态掩码没有关系！！
  DTCFormatIdentifier（1Byte）：指示了目标ECU所用的DTC的格式，一个ECU只能使用一种格式。具体有以下几种：

DTCFormatIdentifier 取值	含义
0x00	SAE_J2012-DA_DTCFormat_00（在ISO 15031-6中定义的格式）
0x01	ISO_14229-1_DTCFormat（在ISO 14229-1中定义的格式）
0x02	SAE_J1939-73_DTCFormat（在SAE J1939-73中定义的格式）
0x03	ISO_11992-4_DTCFormat（在ISO 11992-4中定义的格式）
0x04	SAE_J2012-DA_DTCFormat_04（在ISO 27145-2中定义的格式）
0x05 - 0xFF	保留未使用

  DTCCount（2Byte）：表示符合请求中DTC状态掩码的DTC数量。

——否定响应

  可能出现的NRC及其含义如下，该服务其他子功能对应的否定响应也都是一样的，后面就不再赘述了：

NRC	含义
0x12	sub-function不受支持
0x13	消息长度错误
0x31	请求参数不受支持，参数错误

  2.1.2 通信示例

  假设有以下一些前置背景：

① 请求消息中设置的状态掩码DTCStatusMask 8个bit为：0000 0001（十六进制0x01）；
② 目标ECU的 DTCStatusAvailabilityMask为：1111 1111（十六进制0xFF，即支持所有状态位）；
③ 目标ECU DTCFormatIdentifier为：0x00（即目标ECU使用的DTC格式遵循标准J2012-DATACF00）
④ 假设目标ECU中存储了四个DTC，对应的DTC状态位（8个bit）取值如下所示：
  DTC1：0010 1111
  DTC2：0010 1111
  DTC3：0010 1100
  DTC4：0010 1110

2.2 reportDTCByStatusMask（19 02）

  该子功能用于读取符合特定条件的DTC列表，这个特定条件仍然是DTC状态掩码（参见对19 01的描述），该掩码作为请求参数给到目标ECU，目标ECU将其与自身存储的DTC的Status进行“与”运算，并返回"与"运算之后结果不为0的DTC列表（回复匹配的DTC本身而非数量）。

  2.2.1 数据包格式

——请求格式

  请求包中的各个参数与19 01中个参数功能一致，不再赘述。

——肯定响应

  相对于19 01，新增了一种参数类型：
  DTCAndStatusRecord（不定长：n*4Byte）：包含一条条DTC及其状态。对于大部分定义DTC格式的标准来说，每条记录的格式为 “DTC高字节+DTC中字节+DTC低字节+DTC相应状态”。

  2.2.2 通信示例

  沿用19 01中通信示例的部分背景，假设如下：

① 请求读取所有状态为active的DTC的数量，即请求消息中设置的DTCStatusMask 8个bit为：0000 0001（十六进制0x01）；
② 目标ECU的 DTCStatusAvailabilityMask为：1111 1111（十六进制0xFF，即支持所有状态位）；
③ 假设目标ECU中存储了四个DTC，对应的DTC状态位（8个bit）取值如下所示：
  DTC1：0010 1111
  DTC2：0010 1111
  DTC3：0010 1100
  DTC4：0010 1110

2.3 reportDTCSnapshotRecordByDTCNumber（19 04）

  为了方便快速定位故障，目标ECU会记录故障发生时候的快照信息（也称冻结帧）。DTC快照信息（Snapshot Record）就类似照相机一样，在故障发生的时刻，对整车信息按下快门，做个记录，以便后续分析问题。常见一些数据有：故障发生时的时间戳、ECU电压值、电流值、温度或者由故障Event引起的相应DTC等等。关于DTC快照的更多内容，建议先阅读《到底什么是DTC？》

  通过04子功能，目标ECU根据请求中指定的故障码（DTC），查找并返回其对应的快照信息，来分析故障原因。

  2.3.1 数据包格式

——请求格式

  DTCMaskRecord（1Byte）：DTC掩码（实际上就是某个具体DTC），目标ECU会查找跟这个值匹配的DTC。（注意该参数跟DTCStatusMask没有任何关系，别看花眼了）

  DTCSnapshotRecordNumber（1Byte）：表示特定的DTC快照数据记录编号。DTC快照可以分为不同的组，每个组包含不同的快照信息，并使用快照记录编号区分每个组。这个参数就是表示请求的是哪组快照。例如当我们需要记录某个DTC第一次发生（假设编号为1）和最近一次发生的快照数据时（假设编号为2）；那么当DTCSnapshotRecordNumber为1时，则表示请求该DTC第一次发生时的快照信息。
  这个编号需要目标ECU提前定义，比如该参数设置为0xFF，则表示读取所有的快照数据组。取值情况及对应含义在标准中的预定义情况如下所示：

取值	含义
0x00	保留用于法定目的(如WWH-OBD)
0x01 - 0xFE	供车辆制造商使用
0xFF	一次性报告所有存储的DTCSnapshot数据记录

——肯定响应

  相对于之前的子功能，在响应的最后，携带了一个或多个快照数据（比如请求中的DTCSnapshotRecordNumber为0xFF，则表示读取所有的快照数据组，这里就会返回所有的快照数据），每个快照数据组的构成如上图大方框所示，这里我们把它称为DTCSnapshotData（标准中没有这个称呼），他由以下三部分组成：

  DTCSnapshotRecordNumber（1Byte）：第几组快照记录数据，其取值符合19 04请求中的第六个字节含义。
  DTCSnapshotRecordNumberOfIdentifiers（1Byte）：对应快照信息中记录的信息条目的数量。
  DTCSnapshotRecord（不定长）：每个信息条目成员的ID信息（DID）及其相应数据。

Tips：
  ① 如果诊断仪请求的DTC或快照数据编号是目标ECU不支持的，属于参数错误，目标ECU应回NRC 0x31；
  ② 如果DTC和快照记录编号都受支持，但目标ECU中当前没有存储这个DTC的快照信息（例如这个DTC对应的故障没有发生），那么ECU应返回肯定响应，但响应只包含59 04+DTC+DTC状态，不包含后面携带的快照记录信息。

  2.3.2 通信示例

2.4 reportDTCExtDataRecordByDTCNumber（19 06）

  除了前面的快照信息，一般还会再定义一个扩展信息，用于记录故障的一些其他信息，比如故障发生的次数、老化次数、已老化次数等。通过06子功能，目标ECU根据请求中指定的故障码（DTC），查找并返回其对应的扩展信息，来分析故障原因。

  2.4.1 数据包格式

——请求格式

  此时parameter为4个byte，前三个byte用于标识我们要读取的DTC，第四个byte用于标识要读取的环境数据的范围，UDS规定使用0xFF来表示读取所有的扩展帧数据，各厂家可以要根据自己的需求定义其他的值来代表要读取的扩展数据的范围。环境数据包括DTC状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此DTC产生时的其他测量数据。

  DTCExtDataRecordNumber（1Byte）：扩展数据记录码，该参数用于指定要获取的特定扩展数据记录。取值情况及对应含义如下所示：

取值	含义
0x00	保留用于法定目的(如WWH-OBD)
0x01 - 0xFE	供车辆制造商使用
0xFF	一次性报告所有存储的DTC扩展数据记录

——肯定响应

  与前面的19 04十分类似，在响应的最后，携带了一个或多个扩展数据（比如请求中的DTCExtDataRecordNumber为0xFF，则表示读取所有的扩展数据记录，这里就会返回所有的扩展数据），每个扩展数据记录（扩展帧）的构成如上图所示，这里我们把它称为DTCExtData（标准中没有这个称呼），他由以下两部分组成：

  DTCExtDataRecordNumber（1Byte）：标识是哪一个扩展记录数据，其取值符合19 06请求中的第六个字节含义。
  DTCExtDataRecord（不定长）：每个信息条目成员的ID信息（DID）及其相应数据。

  2.4.2 通信示例

  假设存在如下测试背景：

① 目标ECU中DTC 0x123456存储了两条扩展帧数据，两个扩展帧的记录编号及其对应数据分别是 0x05 – 0x17 和 0x10 – 0x79;
② 当前这个DTC的状态是：0010 0100（十六进制0x24）；
③ 请求读取DTC 0x123456的所有扩展数据；

2.5 reportSupportedDTC（19 0A）

  检索目标ECU所有支持的DTC信息（3字节的DTC标识符+1字节的DTC状态位），其响应报文与02服务一致；但要区分，该服务返回的是所有DTC的信息；而02服务是返回与请求时状态掩码相与不为0 的DTC信息。
  注意：不论DTC状态如何，故障是否发生，都要返回。通常用来测试ECU中实际支持的DTC和预定义的DTC列表是否相符。

  2.5.1 数据包格式

——请求格式

  请求格式很简单，不需要什么额外的信息参数。

——肯定响应

  响应格式和19 02保持一致，详细解释可以直接参考19 02的响应格式。

  2.5.2 通信示例

  通信示例可以直接参考19 02通信示例。

>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<