文章目录

前言
一、理论描述
- 1.服务分类
- 2.状态掩码
二、操作步骤
- 1.请求
- 2.回复
总结

->返回总目录<-

前言

简称： “ReadDTCInformation”，读取DTC信息
功能： 用户通过请求该服务，读取ECU的故障诊断码(DTC)信息，服务的sub-function代表了各式各样读取DTC的方法，UDS给19服务的sub-function从0x00到0x19进行了明确定义。
通俗解释：例如ECU功能工作电压一般在6V~18.5V之间。当软件通过ADC采样发现该模拟量通道输入电压低于6V时候，会经过一段时间的软件消抖后记录该供电电压欠压故障码，并通过0x19的子服务类型读取出来。如（是否为当前正在发生的故障，记录该故障那一时刻的其他快照信息，如车速，IGN状态等）。

一、理论描述

1.服务分类

0x01 reportNumberOfDTCByStatusMask（读取客户端定义状态掩码匹配的DTC（Diagnostic Trouble Code）数量）
0x02 reportDTCByStatusMask（读取客户端定义状态掩码匹配的DTC）
0x04 reportDTCSnapshotRecordByDTCNumber（检索客户端定义DTC掩码的记录数据(快照)如发生某一故障记录DTC时的车速，电源电压状态等）
0x06 reportDTCExtDataRecordByDTCNumber（读取某个DTC及其相关的环境数据，环境数据包括DTC状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此DTC产生时的测量数据。）
0x0A reportSupportedDTC（读取ECU支持的所有DTC的状态，包含支持的各个DTC编号以及相关状态）

博主在工作中基本上只用到这些sub-function，如果想了解所有的，大家可以参考规范手册哦！

2.状态掩码

由八个DTC状态位组成，占一字节。应用于请求消息中，以便客户端为状态与DTC状态掩码相匹配的DTC请求DTC信息。
bit 0 : testFailed
指示最近执行test的结果，test失败置1，但是它不一定被ECU存储到EEprom中，只有当bit2或bit3被置1时DTC才会被存储。test通过则置0，如果调用了14服务清除DTC的话，也需要重新置0

“0”= DTC测试的最新结果表明未检测到故障。
“1”= DTC测试的最新结果表明了一个成熟的失败结果。

bit1：testFailedThisMonitoringCycle
该位表示在当前test中，诊断test是否已经报告了一个testFailed结果。当新的检测循环开始时，这个位需要置0，在调用了14服务后也需要置0。如果该位置1，那么一直保持置1状态直到新的检测循环开始，因此bit1可以理解为当前DTC。如果bit2和bit3通常一起使用。

“0”= testFailed:在当前操作周期内或在当前操作周期内调用ClearDiagnosticInformation后，尚未报告testFailed结果。
“1”= testFailed:在当前操作周期中至少报告了一次testFailed结果。

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

“0”= 在完成测试完成且未检测到故障的操作循环后或调用ClearDiagnosticInformation服务时，该位应设置为0。
“1”= 如果在当前操作循环中检测到故障，则该位应设置为1并锁定。

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

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

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

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

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

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

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

“0”= DTC测试在当前驾驶循环期间（或自上次在当前操作循环期间清除诊断信息以来）完成。
“1”= 此操作循环（或自上次清除此操作循环的诊断信息后），DTC测试尚未运行到完成。

bit7：warningIndicatorRequested
该位报告警告指示，比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示，如果没有和DTC相关的警告存在，该位应置0；如果该DTC有相关警告指示，bit3置1的时候，bit7也要置1。在调用14服务清除DTC后需要置0

举个栗子：博主项目中基本上都是状态掩码设置为0x09,即上图标红位置1。启用第0位和第3位（软件中配置）。当某一DTC发生且一直保持，则在ECU回复报文中的状态掩码字节为0x09。若该DTC发生过了，并且在我请求19服务时候已经不发生了，那么ECU回复报文中的状态掩码字节就变成了0x08（testFailed位不满足，置0）。

二、操作步骤

1.请求

19 01 / 19 02

如状态掩码设置为0x09，则图中第三个字节XX应该为09

19 04

该服务请求报文分为四段，在UDS中，每个DTC都有个名称–DTCMaskRecord。我们举个栗子，假设转向灯故障码名称设定为0xC14041。快照包含电源电压状态，车速信息。则该请求报文应为：19 04 C1 40 41 FF （读取转向灯故障发生时的快照信息）， FF代表读取所有快照数据。

19 06

同理19 04服务，区别在于最后一个字节是DTCExtDataRecordNumber（DTC扩展数据记录编号），读取所有也设置为FF。按照上面转向灯故障的例子，扩展数据包含该故障发生次数。则该请求报文应为：19 06 C1 40 41 FF （读取转向灯故障发生次数信息）

19 0A

发送指令19 0A ，读取ECU支持的所有DTC列表以及各DTC的状态。

2.回复

1）积极响应

19 01

哇，请求报文辣么简约，ECU回复这么长。 ~~“有我在！别害怕”
解析：前两个字节就不解析了，看过之前的文章就知道了。
DTCStatusMask： （这一项客户会告诉你他的要求，莫担心）就是我们上面所说设置的状态掩码，我们就用0x09作为状态掩码。
标准上是DTCStatusAvailabilityMask，开发中都是我们设置好的掩码，可以理解成同一个数据09.只是为了筛选DTC的状态08 / 09

DTCFormatIdentifier： 故障码格式标识符，也就是说客户选择哪个标准的格式，如下图，我们选择SAE_J2012-DA_DTCFormat_00， 0x00。

DTCCount： 满足DTCStatusMask的DTC个数。

综上所述ECU回复报文如下图所示：

19 02

DTCAndStatusRecord： 满足DTCStatusMask 0x09（当前故障）的DTC以及状态。如：故障码0xC14041,0xC14042两个故障都正在发生。则ECU回复 59 02 09 C1 40 41 09 C1 40 42 09 （这种情况ECU回复的是多帧数据，下图仅供参考）如下图是发生一个故障时候的回复格式
。
~

19 04

举例读取转向灯故障码0xC14041发生时的快照数据
DTCAndStatusRecord ：C1 40 41 09，其中09为设置的状态掩码
DTC快照记录组号： 占一字节，标准中要求的组号，就是为了分类下。
快照DID个数： 占一字节，该组号中的快照DID个数。
快照DID： 占两字节，每个快照数据都有它的ID。
快照DID的数据： 该快照具体的数据，具体占字节数，看客户要求的快照数据占多少字节。
我们假设快照记录组号为01，该组中有两个快照DID：0x0112电源电压，0x0113车辆启动按钮状态。则ECU回复数据如下：
59 04 (C1 40 41) 09 01 02 (01 12) 00 78 (01 13) 01 当转向灯发生故障时，电源电压为12V供电（0x0078转换十进制为120）。
启动按钮按下（01）.

19 06

DTC扩展数据组号： 分类作用
扩展数据： 具体记录该故障时保存的数据，如发生故障次数。

我们假设DTC扩展数据组号为01，该组中有一个扩展数据：故障发生次数。则ECU回复数据如下：
59 06 (C1 40 41) 09 01 05。表示，故障C1 40 41发生了5次。

2）否定响应：

总结

是不是发现0x19服务相比较之前的服务要复杂些。的确如此。稳住！我们能赢。下一章0x14服务见~

->返回总目录<-

【UDS】ISO14229之0x19服务相关推荐

UDS的0x19服务介绍
什么是 UDS? UEI (Unified Diagnostic Services,统一诊断服务) 是一种在车辆电子控制单元 (ECU) 之间交换诊断信息的标准通信协议,它是OBD-II的某些扩展.利 ...
跟我学UDS(ISO14229) ———— 0x19 服务参数介绍
相关链接:跟我学UDS(ISO14229) ---- 0x19(ReadDTCInformation) 目录 DTCStatusMask 工作状态 bit 作用说明切换逻辑 DTCExtendedD ...
【UDS】ISO14229之0x14服务
文章目录前言一.理论描述二.使用步骤 1.请求 2.响应总结 ->返回总目录<- 前言简称: "ClearDiagnosticInformation",清除D ...
跟我学UDS(ISO14229) ———— 0x11(ECUReset)
0x11(ECUReset)服务的主要作用是使用ECUReset服务来请求服务器重置.该服务根据嵌入在ECUReset请求消息中的resetType参数值的内容,请求服务器有效地执行服务器重置. 在服 ...
【车载开发系列】UDS诊断---链接控制服务（$0x87）
[车载开发系列]UDS诊断-链接控制服务($0x87) 诊断---链接控制服务($0x87) [车载开发系列]UDS诊断---链接控制服务($0x87) 一.概念定义二.应用场景三.报文格式 1) ...
【UDS】ISO14229之0x27服务
文章目录前言一.理论描述二.使用步骤 1.总述 2.请求 3.响应总结 ->返回总目录<- 前言简称: "SecurityAccess",安全访问功能: 由 ...
【UDS】ISO14229之0x3E服务
文章目录前言一.理论描述二.使用步骤 1.请求 2.响应总结 ->返回总目录<- 前言简称: "TesterPresent",测试工具保持连接服务功能: 此 ...
【UDS】ISO14229之0x2F服务
文章目录前言一.理论描述二.使用步骤 1.请求 2.响应总结 ->返回总目录<- 前言简称: "InputOutputControlByIdentifier" ...
【UDS】ISO14229之0x28服务
文章目录前言一.理论描述二.使用步骤 1.请求 2.响应总结 ->返回总目录<- 前言简称: "CommunicationControl",通信控制功能: ...

【UDS】ISO14229之0x19服务