汽车诊断之UDS入门-0x19(ReadDTCInformation)服务概述

该服务可使client读取车内某个或某些ECU内部DTC信息的状态，除非有特殊的子功能需求，ECU应返回所有的DTC信息（例如排放相关或者排放无关）。该服务允许client的行为如下：

1.通过检索client定义的DTC状态掩码（status mask)获取对应的DTC数量；

2.获取client定义的DTC状态掩码（status mask)对应的DTC列表；

3.获取client定义的DTC状态掩码（status mask)对应的某个功能组内的DTC列表；

4.获取“固定DTC(permanent DTC)”状态的所有DTC;

5.获取client定义的DTC相关的快照数据（有时也被称为冻结帧(freeze fames)）：快照是存储在ECU内存中DTC相关的某些数据的记录，快照常用来在系统故障发生时存储数据值，这些存储的数据-参数旨在帮助技术人员检修时减少错误的故障隔离操作;

6.获取client定义的DTC扩展数据记录条目(DTCExtDataRecordNumber)相关的DTC扩展数据记录（DTCExtendedDataRecord)列表；

7.获取DTC内存中client定义的DTC和状态掩码（status mask) 组合相关的DTC扩展数据(DTCExtendedData)，DTC扩展数据(DTCExtendedData)由DTC相关的扩展状态信息组成。DTC扩展数据包括DTC参数值，该参数值在请求发出时被定义。DTC扩展数据通常用来存储DTC相关的动态数据，例如：

-DTC B1故障指示计数，传输当故障发生时OBD系统已经工作的时长（发动机工作小时数）；

-DTC发生计数，“testFailed"被报告时的驾驶周期(driving cycle)数；

-DTC老化计数，计数自故障最近一次发生以来的驾驶周期(driving cycle)数，不包括测试未报告“testPass”或“testFailed”的驾驶周期(driving cycle)数；

-OBD专用计数器（例如如果在无故障模式(fault free mode)下可以开启驾驶周期，直至”发动机检查“指示灯灭掉时剩余的驾驶周期数量）；

-上次发生故障时的时间等；

-测试失败(testFailed)计数，记录报告的“testFailed”数量，如果验证过程分为多个步骤，则可能还有其它的计数器；

-未完成的测试计数，记录自测试完成以来的驾驶周期（即自测试报告”testPass”或“testFailed”）

-检索client定义的严重度掩码对应的DTC数量；

-检索client定义的严重度掩码记录对应的DTC列表；

-检索client定义的DTC严重度信息；

-检索ECU支持的所有DTC状态；

-检索ECU失败的第一次DTC；

-检索ECU最近一次失败的DTC；

-检索ECU确认的第一次DTC；

-检索ECU内部最近一次确认的DTC；

-检索所有当下预失败（prefailed)DTC，这些DTC已被或者未被检测为“待定（pending）"或”确定(confirmation)";

-检索DTC内存中client定义的DTC扩展数据记录状态相关的DTC扩展数据；

-检索用户定义DTC内存中的DTC列表匹配client定义的DTC状态掩码；

-检索用户定义DTC内存中的DTC扩展数据记录来获取client定义的DTC状态掩码；

-从用户定义的 DTC 内存中获取用户定义的 DTC 内存DTC快照记录( DTCSnapshotRecord )数据，以获取client定义的 DTC 掩码；

-检索DTC信息获取client定义的DTCReadinessGroupIdentifier.

0x19服务使用子功能来确认client是在请求哪种类型的诊断信息。各子功能参数对应的更多的细节见下方的子条款。

— Enable criteria: Server/vehicle manufacturer/system supplier specific criteria used to control when the server actually performs a particular internal diagnostic.

ECU/整车厂/系统供应商定义的标准，用来控制ECU实际内部诊断执行。

— Test pass criteria: Server/vehicle manufacturer/system supplier specific conditions, that define, whether a system being diagnosed is functioning properly within normal, acceptable operating ranges (e.g. no failures exist and the diagnosed system is classified as “OK”).

ECU/整车厂/系统供应商定义的在正常、可接受操作范围内系统是否诊断为功能正常的条件（如没有故障产生且诊断系统划分为“OK”）。

— Test failure criteria: Server/vehicle manufacturer/system supplier specific failure conditions that define, whether a system being diagnosed has failed the test.

ECU/整车厂/系统供应商定义的系统是否诊断为测试failed的条件。

— Confirmed failure criteria: Server/vehicle manufacturer/system supplier specific failure conditions that define whether the system being diagnosed is definitively problematic (confirmed), warranting storage of the DTC record in long term memory.

ECU/整车厂/系统供应商定义的failure条件，用来确定被诊断的系统是否有确认的问题，并保证将DTC记录在长期存储器进行存储。

— Occurrence counter: A counter maintained by certain servers that records the number of instances in which a given DTC test reported a unique occurrence of a test failure.

由某些ECU维护的计数器，用于记录给定DTC测试报告某个特定测试failure发生的次数。

— Aging: A process whereby certain servers evaluate past results of each internal diagnostic to determine if a confirmed DTC can be cleared from long-term memory, for example in the event of a calibrated number of failure free cycles.

某些ECU通过该过程评估每个内部诊断过去的结果，以确定是否可以从长期存储器中清除已确认的 DTC ，例如经过标定的无故障循环次数的情况下。

A given DTC value (e.g. 08051116) shall never be reported more than once in a positive response to readDTCInformation with the exception of reading DTCSnapshotRecords, where the response may contain multiple DTCSnapshotRecords for the same DTC.

给定的 DTC 值 (例如 08051116) 在对 0x19 readDTCInformation 作出积极响应时，不得多次报告，但读取 DTCSnapshotRecords 除外，因为该响应可能包含同一 DTC 的多个 DTCSnapshotRecords。

When using paged-buffer-handling to read DTCs (especially for SubFunction = reportDTCByStatusMask), it is possible that the number of DTCs can decrease while creating the response. In such a case the response shall be filled up with DTC 00000016 and DTC status 0016. The client shall treat these DTCs as not present in the response message.
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 8.7.

当使用分页缓冲区处理读取 DTC (特别是对于子功能 = reportDTCByStatusMask) 时，创建响应时， DTC 的数量可能会减少。 在这种情况下，响应应填充 DTC 00000016 和 DTC status 0016。 client 应将这些 DTC 视为响应消息中不存在。
重要—ECU和client应满足 8.7 中定义的请求和响应消息行为。

0x19 0x01 通过检索client定义的DTC状态掩码（status mask)获取对应的DTC数量

Subfunction=01 reportNumberOfDTCByStatusMask

Response:

DTCStatusAvailabilityMask: ECU支持的DTC status bits indication

DTCFormatIdentifier:DTC 格式和编码

DTCCount:2个字节的无符号数，基于client提供的状态掩码，ECU内存中可用的DTC数量。

0x19 0x02 通过检索client定义的DTC状态掩码（status mask)获取对应的DTC列表

Subfunction=02 reportDTCByStatusMask

ECU应将client端请求中定义的掩码和ECU支持的每个DTC相关的实际的状态按位进行逻辑“与”运算。如果运算结果不是0（即statusOfDTC&DTCStatusMask)!=0),除DTCStatusAvailabilityMask之外，ECU应返回所有DTC。

如果client定义的状态掩码包含ECU不支持的位，ECU应只使用字节支持的位来处理DTC信息。如果ECU内部没有和client请求中定义的掩码规则匹配的DTC，则在肯定响应中，应没有DTC或状态信息在DTCStatusAvailabilityMask字节后被提供。

当成功收到client端发送的清除诊断信息ClearDiagnosticInformation的请求时，DTC状态信息应被清除。

0x19 0x03 获取DTC快照记录ID

Subfunction=03 reportDTCSnapshotIdentification

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 0x04 通过检索client定义的DTC mask获取DTCSnapshotRecordData

Subfunction=04 reportDTCSnapshotRecordByDTCNumber

该子功能可使client通过DTCSnapshot record number和DTCMaskRecord获得捕获的DTCSnapshot record data.

ECU应通过它支持的DTC来获取与之匹配的由client端定义的DTCMaskRecord(包括DTC number(high,middle,low byte))，client端请求中的UserDefDTCSnapshotRecordNumber参数应清楚定义请求的是某个DTC的哪个DTCSnapshot record data。

注意 1 ：UserDefDTCSnapshotRecordNumber 参数与DTCStoredDataRecordNumber参数并不共享同样的地址。

如果ECU可支持对单个DTC存储多个DTCSnapshot records（该功能由系统供应商或整车厂定义）。ECU推荐client首先使用Subfunction=03 reportDTCSnapshotIdentification请求DTCSnapshotIdentification，然后再使用Subfunction=04 reportDTCSnapshotRecordByDTCNumber请求DTCSnapshotRecordNumber。

Subfunction=03 reportDTCSnapshotIdentification可使client识别ECU存储的DTCSnapshot records而不用解析ECU所有存储的DTC来确定某个DTCSnapshot记录是否被存储。

系统供应商 / 整车厂应负责定义在这些ECU中捕获的 DTCSnapshot 记录是否存储与故障发生信息相关的数据，作为 ECU 文档的一部分。

如果client定义的DTCMaskRecord 和DTCSnapshotRecordNumber参数的故障被识别，ECU应和DTC number、statusDTC 一起返回1个单独预定义的DTCSnapshotRecord来响应client的请求。

注意 2 ：故障的准则应由系统供应商或整车厂定义

DTCSnapshot record可能包含多个可以用来重现故障发生时车辆状态（例如B+,RPM,时间戳）的data-parameters 。

整车厂应定义DTCSnapshotRecord的格式和内容。DTCSnapshotRecord报告的数据包含1个用来识别后续数据的dataIdentifier.这个dataIdentifier/data组合在DTCSnapshotRecord内部可能被重复。DTCSnapshotRecord内部1个或多个dataIdentifier的使用允许对1个DTC故障多次发生时存储不同类型的DTCSnapshotRecords.各DTCSnapshotRecord内指示record DataIdentifier数量的参数应和DTCSnapshotRecord一起提供来支持数据的检索。

ECU应在1个单独的响应信息中报告1个DTCSnapshot记录，除非client已将UserDefDTCSnapshotRecordNumber 设置为0xFF，因为这将导致ECU在1个单独的响应消息中响应client定义的DTCMaskRecord对应的ECU存储的所有DTCSnapshot record。DTCAndStatusRecord在响应消息中仅包含一次。如果client在请求中将DTCSnapshotRecordNumber参数已经设置为0xFF，ECU应按照数字升序报告某个DTC捕获的所有DTCSnapshot 记录。

当client定义的DTCMaskRecord或DTCSnapshotRecordNumber参数无效或这ECU不支持时，ECU应给出负响应。当client定义的DTCMaskRecord和/或DTCSnapshotRecordNumber参数有效且被ECU支持，但是没有相关的DTCSnapshot数据（例如对于某个DTC或者record number,故障事件从未发生），ECU应给出仅包含DTCAndStatusRecord（echo of 请求的DTC number(high,middle,low byte)加上statusodDTC）正响应。

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

0x19 0x06 通过client定义的DTC mask和DTCExtendedData record number获取DTC扩展记录数据

Subfunction=06 reportDTCExtDataRecordByDTCNumber

ECU应检索其支持且与client定义的DTCMaskRecord匹配的DTC（包含DTC number(高，中，低 byte))，client请求中的DTCExtDataRecordNumber参数应定义某个DTC的某条DTCExtendedData记录。

除了DTC number和StatusOfDTC以外，ECU还应返回1条单独预定义的DTCExtendedData记录响应client的请求（DTCExtDataRecordNumber不等于0xFE或0xFF）

整车厂应定义DTCExtDataRecord的格式和内容。DTCExtDataRecord报告的数据结构由DTCExtDataRecordNumber定义，定义方式与record DataIdentifier中数据的定义类似。响应中可能包含多个DTCExtDataRecordNumber及相关的DTCExtDataRecord。单个或多个DTCExtDataRecordNumber允许存储1个DTC不同类型的DTCExtDataRecords。

ECU应在单个响应消息中报告1个DTCExtendedData记录，除非DTCExtDataRecordNumber已经被设置为0xFE或0xFF,这将造成ECU在1个单独的响应消息中包含与client请求的DTCMaskRecord相关的所有存储的DTCExtendedData记录。

如果client定义的DTCMaskRecord或者DTCExtDataRecordNumber参数无效或者ECU不支持，ECU应给出负响应。该情形包含如果client发送的DTCExtDataRecordNumber参数是0xFE,但是没有ECU支持的OBD扩展数据记录（0x90-0xEF)。这区别于client定义的DTCMaskRecord或者DTCExtDataRecordNumber参数有效且ECU支持，但是没有与之相关的DTC扩展数据（例如扩展数据内存溢出）。ECU应给出仅包含DTCAndStatusRecord（echo of 请求的DTC number(high,middle,low byte)加上statusodDTC）正响应。

client成功发出 ClearDiagnosticInformation 请求后，应清除 DTCExtendedData 信息。 整车厂需要定义清楚删除已存储 DTC 和 DTCExtended数据的规则以防内存溢出。

0x19 0x0A 检索ECU支持的所有DTC

Subfunction=0A reportSupportedDTC该子功能的响应包含DTCStatusAvailabilityMask，来指示ECU支持的DTC状态位，除此之外，还包含listOfDTCAndStatusRecord，该参数包含ECU支持的所有DTC的DTC数量和相关的状态。