19服务读故障码信息

青城i

已于 2024-08-29 10:19:50 修改

阅读量1.4k

点赞数 23

文章标签：车载系统

于 2024-08-29 10:18:13 首次发布

本文链接：https://blog.csdn.net/qingchengi/article/details/141671641

版权

19服务读故障码信息

19服务作用是允许外部诊断仪（Client）通过该服务读取存储在ECU芯片内的故障码（DTC）状态信息。

1、简介

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

19服务最常用的几个子功能：

2、DTC状态位

2.1 bit 0 : testFailed

通常来说，ECU内部以循环的方式不断地针对预先定义好的错误路径进行测试，如果在最近的一次测试中，在某个错误路径中发现了故障，则相应DTC的这一个状态位就要被置1，表征出错。此时DTC的testFailed位被置1，但是它不一定被ECU存储到non-volatile memory中，只有当pendingDTC或confirmedDTC被置1时DTC才会被存储。而pendingDTC或confirmedDTC被置1的条件应该是检测到错误出现的次数或时间满足某个预定义的门限。当错误消失或者诊断仪执行了清除DTC指令时，testFailed会再次被置为0。

testFailed = 1：表示当前结果为故障状态。

testFailed = 0：表示当前结果为非故障状态。

2.2 bit 1 :testFailedThisOperationCycle

这个bit用于标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况，即是否出现过错误。operation cycle的起始点是ECU通过网络管理唤醒到ECU通过网络管理进入睡眠，对于没有网络管理的ECU，这个起始点就是KL15通断。通过bit 0我们无法判断某个DTC是否出现过，比如，当前testFailed = 0，说明当前这个DTC没有出错，如果testFailedThisOperationCycle = 1的话，就说明这个DTC在当前这个operation cycle中出过错，但是当前错误又消失了。

testFailedThisOperationCycle = 1：表示当前操作循环中至少检测到一次故障。

testFailedThisOperationCycle = 0：表示当前操作循环中未检测到故障。

2.3 bit 2 : pendingDTC

根据规范的解释，pendingDTC = 1表示某个DTC在当前或者上一个operation cycle中是否出现过。pendingDTC位其实是位于testFailed和confirmedDTC之间的一个状态，有的DTC被确认的判定条件比较严苛，需要在多个operation cycle中出现才可以被判定为confirmed的状态，此时就需要借助于pendingDTC位了。pendingDTC = 1的时候，DTC就要被存储下来了，如果接下来的两个operation cycle中这个DTC都还存在，那么confirmedDTC就要置1了。如果当前operation cycle中，故障发生，pendingDTC = 1，但是在下一个operation cycle中，故障没有了，pendingDTC 仍然为 1，再下一个operation cycle中，故障仍然不存在，那么pendingDTC 就可以置0了。

pendingDTC = 1：表示当前操作循环或上个完整的操作循环期间至少检测到一次故障（确定DTC）。

pendingDTC = 0：表示当前操作循环或上个完整的操作循环期间未检测到故障（未确定DTC）。

2.4 bit 3 : confirmedDTC

当confirmedDTC = 1时，则说明某个DTC已经被存储到ECU的non-volatile memory中，说明这个DTC曾经满足了被confirmed的条件。但是请注意，confirmedDTC = 1时，并不意味着当前这个DTC仍然出错，如果confirmedDTC = 1，但testFailed = 0，则说明这个DTC表示的故障目前已经消失了。将confirmedDTC 重新置0的方法只有删除DTC，UDS用0x14服务，OBD用0x04服务。

confirmedDTC = 1：表示存在历史故障。

confirmedDTC = 0：表示不存在历史故障。

2.5 bit 4 : testNotCompletedSinceLastClear

这个bit用于标识，自从上次调用了清理DTC的服务（UDS用0x14服务，OBD用0x04服务）之后，是否成功地执行了对某个DTC的测试（不管测试结果是什么，只关心是否测了）。因为很多DTC的测试也是需要满足某些边界条件的，并不是ECU上电就一定会对DTC进行检测。

testNotCompletedSinceLastClear = 1 : 自从清理DTC之后还没有完成过针对该DTC的测试。

testNotCompletedSinceLastClear = 0 : 自从清理DTC之后已经完成过针对该DTC的测试。

2.6 bit 5 : testFailedSinceLastClear

这个位与bit 1 :testFailedThisOperationCycle有些类似，后者标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况，而testFailedSinceLastClear标识的是在上次执行过清理DTC之后某个DTC是否出过错。

testFailedSinceLastClear = 0 ，自从清理DTC之后该DTC没有出过错。

testFailedSinceLastClear = 1，自从清理DTC之后该DTC出过至少一次错。

2.7 bit 6 : testNotCompletedThisOperationCycle

这个位与bit 4 : testNotCompletedSinceLastClear类似，后者标识自从上次调用了清理DTC的服务之后，是否成功地执行了对某个DTC的测试。而 testNotCompletedThisOperationCycle则标识在当前operation cycle中是否成功地执行了对某个DTC的测试。

testNotCompletedThisOperationCycle = 1 ：在当前operation cycle中还没在完成过针对该DTC的测试。

testNotCompletedThisOperationCycle = 0 ：在当前operation cycle中已经完成过针对该DTC的测试。

2.8 bit 7 : warningIndicatorRequested

某些比较严重的DTC会与用户可见的警告指示相关联，比如仪表上的报警灯，或者是文字，或者是声音。这个warningIndicatorRequested就用于此类DTC。

warningIndicatorRequested = 1 ： ECU请求激活警告指示。

warningIndicatorRequested = 0： ECU不请求激活警告指示。

3、reportNumberOfDTCByStatusMask（19 01）

3.1 服务概述

通过该服务诊断仪能够请求ECU中DTC状态与DTC状态掩码相匹配的故障码个数。简单来说就是通过状态掩码去读取DTC数量。

3.2 报文

3.2.1 请求报文定义

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

3.2.2 肯定响应

DTCStatusAvailabilityMask（1Byte）：用于表示目标ECU支持的状态位，跟DTCStatusMask结构一样，8个bit，bit值为0表示目标ECU不支持这个状态位，为1则表示支持。跟请求中的DTC状态掩码没有关系！！

DTCFormatIdentifier（1Byte）：指示了目标ECU所用的DTC的格式，一个ECU只能使用一种格式。具体有以下几种：

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

3.3报文解析

3.3.1格式及内容

发送： 19 +01+DTCStatusMask（DTC状态掩码）

正响应： 59+01+DTCStatusAvailabilityMask+DTC格式+DTCCount

注：DTCStatusAvailabilityMask是ECU支持的状态掩码，不能根据请求中的DTC状态掩码变化，容易误解为要返回的ECU支持的状态掩码和请求中的状态掩码做与运算后的结果。

3.3.2 通信示例

从相与结果可以看出有两个非0结果，所以DTCCount为2。

4、reportDTCByStatusMask（19 02）

4.1 服务概述

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

4.2 报文

4.2.1 请求报文定义

19 02 请求报文格式与19 01 格式相同。

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

4.2.2 肯定响应

相对于19 01，新增了一种参数类型：

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

4.3报文解析

4.3.1格式及内容

发送： 19 +02+DTCStatusMask（状态掩码）

正响应： 59+02+DTCStatusAvailabilityMask（ECU支持的状态掩码）+DTC故障码+状态位

4.3.2 通信示例

4.3.3 具体实例

810001：低压故障

810002：通讯故障

发送：19 02 09

收到：59 02 FF 81 00 01 2C 81 00 02 2F

可以从回复中看出存在历史的低压故障和当前的通讯故障

（1）低压故障

2C ：0010 1100

DTCStatusMask：0000 1001（09）

2C& DTCStatusMask （09）: 0000 1000

bite 0（testFailed）为0——当前无故障状态（false）

bite3（confirmedDTC）为1——存在历史故障（true）

（2）通讯故障

2F：0010 1111

DTCStatusMask：0000 1001（09）

2F& DTCStatusMask （09）: 0000 1001

bite 0（testFailed）为1——当前故障状态（ture）

bite3（confirmedDTC）为1——存在历史故障（true）

5、reportDTCSnapshotRecordByDTCNumber（19 04）

5.1服务概述

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

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

5.2 报文

5.2.1 请求报文定义

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

DTCSnapshotRecordNumber（1Byte）：表示特定的DTC快照数据记录编号。DTC快照可以分为不同的组，每个组包含不同的快照信息，并使用快照记录编号区分每个组。这个参数就是表示请求的是哪组快照。例如当我们需要记录某个DTC第一次发生（假设编号为1）和最近一次发生的快照数据时（假设编号为2）；那么当DTCSnapshotRecordNum

ber为1时，则表示请求该DTC第一次发生时的快照信息。

这个编号需要目标ECU提前定义，比如该参数设置为0xFF，则表示读取所有的快照数据组。取值情况及对应含义在标准中的预定义情况如下所示：

4.2.2 肯定响应

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

tData（标准中没有这个称呼），他由以下三部分组成：

DTCSnapshotRecordNumber（1Byte）：第几组快照记录数据，其取值符合19 04请求中的第六个字节含义。

DTCSnapshotRecordNumberOfIdentifiers（1Byte）：对应快照信息中记录的信息条目的数量。

DTCSnapshotRecord（不定长）：每个信息条目成员的ID信息（DID）及其相应数据。

5.3报文解析

5.3.1格式及内容

发送：19 +04+DTC故障码+快照记录码

正响应：59+04+DTC故障码+DTC状态位+快照记录码+快照信息个数+快照DID+对应的快照DID数据…

5.3.2 通信示例

5.3.3 Tips📌

（1）如果诊断仪请求的DTC或快照数据编号是目标ECU不支持的，属于参数错误，目标ECU应回NRC 0x31；

（2）如果DTC和快照记录编号都受支持，但目标ECU中当前没有存储这个DTC的快照信息（例如这个DTC对应的故障没有发生），那么ECU应返回肯定响应，但响应只包含59 04+DTC+DTC状态，不包含后面携带的快照记录信息。

6、rreportDTCExtDataRecordByDTCNumber（19 06）

6.1服务概述

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

6.2 报文

6.2.1 请求报文定义

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

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

6.2.2 肯定响应

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

DTCExtDataRecordNumber（1Byte）：标识是哪一个扩展记录数据，其取值符合19 06请求中的第六个字节含义。

DTCExtDataRecord（不定长）：每个信息条目成员的ID信息（DID）及其相应数据。