诊断2F和14，19服务概述

本文主要是介绍诊断2F和14，19服务概述，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

关于2F

关于抑制位

关于14服务

通过本服务重置/清除的DTC信息包括但不限于以下各项数据：
1，DTC状态字节（见0x19服务那章的02子服务）
2，捕获的DTC快照数据（见0x19服务那章的04子服务）
3，捕获的DTC扩展数据（见0x19服务那章的06子服务）
4，其他特定于DTC的相关数据，如最近的DTC，标志，计数器，计时器等

第一个字节就是SID，
后边的三个字节用于标识将要被删除的DTC种类，UDS规定用FF FF FF表示所有种类的DTC，由厂家自定义代表Powertrain、Chassis、、Body、Network Communication等种类DTC的值。
通常博主在工作中，该服务请求请求报文为14 FF FF FF：清除所有存储的DTC信息。

0x14服务就是清除存储的DTC故障数据。强调下，当我们使用该服务清除了那些过去发生的DTC故障（即满足DTC状态掩码0x08），则使用19 02服务读取DTC状态信息的时候，满足0x08状态掩码的DTC信息会被清除，19 02不该再读出该掩码状态的DTC信息。

关于19服务

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

在0x19服务中一般的使用顺序

1\0x19服务01子服务

通过状态掩码去查找与其相匹配的故障个数。

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

收到请求后ECU响应的格式如下：

DTC状态掩码参数包含8个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

2、0x19服务02子服务

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

收到请求后，ECU的响应报文格式如下：

3、0x19服务04子服务

为了方便找到故障的原因，在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因。请求格式如下：

其中，DTCSnapshotRecordNumber表示DTC快照记录码，占一个字节，表示特定的 DTC快照数据记录编号。例如当我们需要记录某个DTC第一次发生（假设用1表示）和最近一次发生的快照数据时（假设用2表示）；那么当DTCSnapshotRecordNumber为1时，则表示请求该DTC第一次发生时的快照信息。

如果ECU支持多个DTC快照数据记录，那么该纪录码应使用0x01~0xFE范围内的数值。当该参数值为FF（Hex）时，要求ECU一次性报告所有存储的DTC快照数据记录。

收到请求后，ECU的响应报文格式如下：

如上，响应报文中DTCSnapshotRecordNumber表示返回的是该DTC的哪一个快照记录；DTCSnapshotRecordNumberOfIdentifiers表示快照信息中定义的成员量；如定义的快照数据有四项信息，则该值为4。

4、0x19服务06子服务

扩展信息，用于记录故障的一些其他信息，比如故障发生的次数、老化次数、已老化次数等。06服务就是用于请求指定故障码（DTC）的扩展信息。请求格式如下：

收到报文

5、0x19服务0A子服务

该服务用于请求所有支持的DTC信息（3个字节的DTC标识符加1个字节的DTC状态位），其响应报文与02服务一致；但要区分，该服务返回的是所有DTC的信息；而02服务是返回与请求时状态掩码相与不为“0”的DTC信息。请求格式如下：

报文举例

Tx:    1670397598419    1734 19 01 AF 
Rx:    1670397598419    173C 59 01 AF 01 00 02 
Tx:    1670397598420    1734 19 02 AF 
Rx:    1670397598421    173C 59 02 AF 01 FF FF FF 11 FF FF FF 
Tx:    1670397598422    1734 19 04 01 FF FF FF 
Rx:    1670397598422    173C 7F 19 11 
Tx:    1670400684182    1734 19 01 AF 
Rx:    1670400684186    173C 59 01 89 00 00 1A 
Tx:    1670400684188    1734 19 02 AF 
Rx:    1670400684200    173C 59 02 89 D1 22 87 89 55 04 96 89 D1 00 87 89 D1 01 87 89 D1 04 87 89 D1 05 87 89 D1 06 87 89 D1 07 87 89 D1 09 87 89 D1 10 87 89 D1 12 87 89 D1 13 87 89 D1 14 87 89 D1 15 87 89 D1 16 87 89 D1 17 87 89 D1 19 87 89 D1 20 87 89 D1 21 87 09 D1 23 87 89 D1 24 87 09 D1 25 87 89 D1 26 87 89 D1 27 87 89 D1 28 87 09 D3 70 13 08 
Tx:    1670400684202    1734 19 04 D1 22 87 FF 
Rx:    1670400684216    173C 59 04 D1 22 87 89 
Tx:    1670400684217    1734 19 04 55 04 96 FF 
Rx:    1670400684240    173C 59 04 55 04 96 89 01 0C 0B 00 FF FF 0B 01 00 0A 00 0A 0B 02 FF FF FF FF FF FF 0B 03 FF FF FF FF 0B 04 00 01 01 00 00 00 00 01 01 00 00 00 0B 05 FF FF FF FF 0B 04 00 01 01 00 00 00 00 01 01 00 00 00 0B 01 00 0A 00 0A 0B 05 FF FF FF FF 0B 02 FF FF FF FF FF FF 0B 03 FF FF FF FF 0B 00 FF FF 
Tx:    1670400684241    1734 19 04 D1 00 87 FF 
Rx:    1670400684256    173C 59 04 D1 00 87 89

UDS报文解读举例

客户端向服务器请求：06 19 06 XX XX XX FF 00