14229协议常用的诊断服务介绍0x19服务介绍

1.请求消息定义

①0x1901/0x1902


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


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

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


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

2.子功能定义

注意：支持子功能且支持抑制肯定响应指示位
以下为常用子功能详解

DTCStatusMask

DTC状态掩码包含8个（8）DTC状态位。这8个位的定义可以在下图中找到。此字节用于请求消息中，以允许客户端为其状态与DTC状态掩码相匹配的DTC请求DTC信息。如果任何一个DTC实际状态掩码被设置为“1”，则DTC状态掩码与实际状态不匹配，则发生匹配）。如果客户端指定了一个包含服务器不支持的位的状态掩码，则服务器应仅使用它所支持的位来处理DTC信息

3.肯定响应消息定义

①1901的肯定响应


DTCStatusMask： （这一项客户会告诉你他的要求，莫担心）就是我们上面所说设置
的状态掩码，我们就用0x09作为状态掩码。
标准上是DTCStatusAvailabilityMask，开发中都是我们设置好的掩码，可以理解成同一个数据09.只是为了筛选DTC的状态08 / 09
DTCFormatIdentifier： 故障码格式标识符，也就是说客户选择哪个标准的格式，如下图，我们选择SAE_J2012-DA_DTCFormat_00， 0x00

DTCCount： 满足DTCStatusMask的DTC个数。
综上所述ECU回复报文如下图所示：

②1902/0A的肯定响应

DTCStatusMask： （这一项客户会告诉你他的要求，莫担心）就是我们上面所说设置的状态掩码，我们就用0x09作为状态掩码。
DTCAndStatusRecord： 满足DTCStatusMask 0x09（当前故障）的DTC以及状态。如：故障码0xC14041,0xC14042两个故障都正在发生。则ECU回复 59 02 09 C1 40 41 09 C1 40 42 09 （这种情况ECU回复的是多帧数据，下图仅供参考）

如下图是发生一个故障时候的回复格式

③1904的肯定响应

举例读取转向灯故障码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）

④1906的肯定响应
DTC扩展数据组号： 分类作用
扩展数据： 具体记录该故障时保存的数据，如发生故障次数。我们假设DTC扩展数据组号为01，该组中有一个扩展数据：故障发生次数。则ECU回复数据如下：59 06 (C1 40 41) 09 01 05。表示，故障C1 40 41发生了5次

4.否定响应消息定义

否定响应消息分为三个部分，
第一部分是固定的0x7F（1个字节）；
第二部分是SID（1个字节），这里就是0x19；
第三部分是NRC

5.Temp

6.服务描述

此服务允许客户端从任何服务器或车辆内的服务器组读取服务器驻留的诊断故障代码(DTC)信息的状态。除非特定的子功能另有要求，服务器应返回所有的DTC信息（例如，与排放相关的和非排放相关的）。此服务允许客户端执行以下操作：
1.检索与客户端定义的DTC状态掩码相匹配的dtc数量。
2.检索与客户端定义的DTC状态掩码相匹配的所有dtc的列表。
3.检索匹配客户端定义的DTC状态掩码的特定功能组中的dtc列表。
4.检索所有具有“永久DTC”状态的dtc。
5.检索与客户端定义的DTC相关联的DTCs快照数据（有时称为冻结帧）：DTC快照是与DTC相关联的特定数据记录，它们存储在服务器的内存中。DTC快照的典型用法是在检测到系统故障时存储数据。DTC快照将作为来自系统故障发生时的数据值的快照。存储在DTC快照中的数据参数应与DTC进行关联。DTC特定的数据参数旨在简化技术人员的故障隔离过程。
6.从DTC内存或DTC镜像内存中检索与客户端定义的DTC和状态掩码组合相关联的数据。数据由与DTC关联的扩展状态信息组成。数据包含DTC参数值，它们在请求时已被识别。数据的典型用途是存储与DTC相关的动态数据。
7.检索服务器支持的所有dtc的状态。
8.DTC发生计数器，计数已报告的“测试失败”的驾驶周期数。
9.DTC老化计数器，计数故障最近失败后的驾驶周期数，不包括测试未报告“测试通过”或“测试失败”的驾驶周期。
10.OBD的特定计数器（例如，如果可以在无故障模式下执行驱动循环，则在“检查发动机”灯关闭之前剩余的驱动周期数）。
11.最后一次发生的时间（等）。
12.测试失败的计数器，报告的“测试失败”的计数数和可能的其他计数器。
13.未完成的测试计数器，计数自测试最近完成以来的驾驶周期数（即，由于测试报告“测试通过”或“测试失败”）。
14.检索与客户端定义的严重性掩码相匹配的dtc的数量。
15.检索与客户端定义的严重性掩码记录相匹配的dtc列表。
16.检索客户端定义的DTC的严重性信息。
17.DTCB1故障指示器计数器，表示OBD系统在故障激活时运行的时间（发动机运行小时数）。
18.检索服务器失败的第一个DTC。
19.在服务器内检索最近失败的DTC。
20.检索由服务器确认的第一个DTC。
21.在服务器内检索最近确认的DTC。
22.从与客户端定义的DTC状态掩码相匹配的DTC镜像内存中检索dtc列表。
23.从DTC镜像内存中检索客户端定义的DTC掩码和客户端定义的DTC扩展器的数据记录号的数据记录数据。
24.从符合客户端定义的DTC状态掩码的DTC镜像内存中检索匹配的DTC数。
25.检索与客户端定义的DTC状态掩码相匹配的“仅”与排放相关的OBDdtc的数量。与排放相关的OBDdtc会导致故障指示器被打开/显示一条消息。
26.检索与客户端定义的DTC状态掩码相匹配的“仅”与排放相关的OBDdtc的状态。与排放相关的OBDdtc会导致故障指示器被打开/显示一条消息。
27.检索所有已经或尚未被检测为“待定”或“已确认”的当前“预失败”dtc。
28.从DTC内存中检索与客户端定义的DTC扩展数据记录状态关联的数据。
29.从与客户端定义的DTC状态掩码相匹配的用户定义的DTC内存中检索dtc列表。
30.从用户定义的DTC镜像内存中检索用户定义的DTC内存掩码和客户端定义的DTC掩码和客户端定义的DTC的数据记录数据。
31.从用户定义的DTC内存中检索客户端定义的DTC掩码的用户定义的DTC内存的记录数据。
此服务使用子函数来确定客户端请求的类型的诊断信息。关于每个子函数参数的进一步细节将在以下子条款中提供。
本服务使用了以下条款：
1.Enable Criteria:服务器/车辆制造商/系统供应商的特定标准，用于控制服务器何时实际执行特定的内部诊断。
2.Test Pass Criteria:服务器/车辆制造商/系统供应商的特定条件，定义一个被诊断的系统是否在正常、可接受的操作范围内正常运行（例如，不存在故障，被诊断的系统被归类为“正常”）。
3.Test Failure Criteria:服务器/车辆制造商/系统供应商的特定故障条件，定义了被诊断的系统是否未能通过测试。
4.Confirmed Failure Criteria:服务器/车辆制造商/系统供应商的特定故障条件，它定义了被诊断的系统是否确实存在问题（已确认），从而保证将DTC记录存储在长期内存中。
5.Occurrence Counter:由某些服务器维护的一种计数器，它记录给定的DTC测试报告的唯一发生测试失败的实例数。
6.Aging:一种过程，其中某些服务器评估每个内部诊断的过去结果，以确定已确定的DTC是否可以从长期内存中清除，例如，在校准的无故障周期数的情况下。
一个给定的DTC值(例如，0x080511)不得在对读取DTC信息的积极响应中报告超过一次，除了读取DTCC快照记录，其中响应可能包含同一DTC的多个DTCS快照记录。
当使用页面缓冲区处理读取故障诊断码时(特别是对于子函数=报告DTCBy状态掩码)，在创建响应时，故障诊断码的数量可能会减少。在这种情况下，响应应填写DTC0x000000和DTC状态0x00。客户应将这些dtc视为在响应消息中不存在
A 检索与客户端定义的状态掩码匹配的DTC数（子函数=0x01报告编号为=状态掩码）
客户端可以通过将子函数设置为reportNumberOfDTCByStatusMask.的该服务发送请求来检索与客户端定义的状态掩
码匹配的dtc数对此请求的响应包含DTCStatusAvailabilityMask，，它提供了服务器支持的用于屏蔽目的的DTC状态位的指示。在DTC状态可用性掩码之后，响应包含DTC格式标识符，它报告有关DTC格式和编码的信息。DTC格式标识符后面是DTCCount参数，这是一个2字节的无符号数字，包含基于客户端提供的状态掩码的服务器内存中可用的DTC数量。
子函数reportNumberOfMirrorMemoryDTCByStatusMask与子函数reportNumberOfDTCByStatusMask具有相同的功能，不同之处在于它返回DTC镜像内存中返回dtc的数量。
B 检索与客户端定义的状态掩码匹配的dtc列表（子函数=0x02报告DTC通过状态掩码）
客户端可以通过发送一个子函数字节设置为报告的status掩码的请求来满足客户端定义的状态掩码。这个子功能允许客户端请求服务器报告“测试失败”或“确认为“或”等的所有dtc。
C 检索客户端定义的DTC掩码的DTCS快照记录数据(子函数=0x04报告DTCSDTC快照记录编号)
客户端可以通过发送子函数设置为reportDTCSnapshotRecordByDTCNumber.的此服务请求，为客户端定义的DTCMask记录号一起检索捕获的DTCS快照记录数据服务器应在其支持的dtc中搜索与客户端指定的DTCMask记录(包含DTC号（高、中、低字节）)的精确匹配。客户端请求中提供的DTCS快照记录数参数应指定正在请求DTC快照记录数据的指定DTC的特定出现情况。
DTCS快照和记录号码不与数据记录号码共享相同的地址空间。
如果服务器支持为单个DTC存储多个DTCS快照记录（支持此功能将由系统供应商/车辆制造商定义），则建议服务器同时实现reportDTCSnapshotIdentification子功能参数。建议客户端首先请求识别使用子函数参数reportDTCSnapshotIdentification存储的DTCS快照记录，然后通过reportDTCSnapshotRecordByDTCNumber请求请求一个特定的DTCS快照记录号。
还建议支持子函数参数reportDTCSnapshotRecordIdentification，以便让客户机有机会直接识别存储的DTCS快照记录，而不是通过服务器的所有存储dtc进行解析，以确定是否存储了DTCS快照记录。
系统供应商/车辆制造商有责任定义在这些服务器中捕获的DTCS快照记录是否存储与故障发生信息相关的数据，作为ECU文件的一部分。
如果客户端定义的DTCMask记录和DTCS快照记录数参数(DTCSDTC和记录编号不等于0xFF)，服务器应返回单个预定义的DTCS快照记录。
确切的故障标准应由系统供应商/车辆制造商确定。
DTCS快照记录可能包含多个数据参数，可用于重建故障发生时的车辆状况(例如，B+、RPM、时间戳)。
车辆制造商应定义该数据采集记录的格式和内容。在dtcs网络网络记录中报告的数据首先包含一个数据标识符，以标识下面的数据。这个数据标识符/数据组合可以在dtcs快照记录中重复。在DTCS快照记录中使用一个或多个数据标识符允许为不同的故障发生DTC存储不同类型的DTCS快照记录。每个DTCS快照记录应提供一个参数，指示每个DTCS快照记录中包含的记录数据标识符的数量，以协助数据检索。
服务器应在单个响应消息中报告一条DTCS快照记录，但客户端已将DTCS快照记录数设置为0xFF，因为这将导致服务器在单个响应消息中响应为客户端定义的DTCMask记录存储的所有DTCS快照记录。DTC和n状态记录只包含在响应消息中一次。如果客户端在其请求中对参数DTCS快照记录数使用了0xFF，则服务器应按数字升序报告为特定DTC捕获的所有DTCS快照记录。
如果客户端指定的DTCMask记录或DTCS网络记录数参数无效或服务器不支持，则服务器应进行负响应。这将区别于客户端指定的DTCMask记录和/或DTCS快照记录数参数确实有效且服务器支持，但没有与之关联的DTCS快照数据（例如，因为指定的DTC或记录号从未发生过故障事件）。服务器应发送只包含DTCand状态记录(响应所请求的DTC号（高、中、低字节）和DTC状态)的肯定响应。
在客户成功请求清除诊断信息时，应清除DTCS快照信息。车辆制造商负责指定在内存溢出(服务器中存储dtc和DTC快照数据的内存空间)时删除存储dtc和DTCC快照数据的规则。
D 检索客户端定义的DTC掩码和客户端定义的DTC扩展数据的数据记录数据号(子函数=0x06报告DTCExt数据记录ByDTC编号)
客户端可以通过发送子函数设置为reportDTCExtDataRecordByDTCNumber.的此服务请求，来检索客户端定义的扩展扩展记录和DTC扩展数据记录号的DTC扩展数据服务器应在其支持的dtc中搜索与客户端指定的DTCMask记录(包含DTC号（高、中、低字节）)的精确匹配。在这种情况下，客户端请求中提供的DTC扩展数据记录数参数应指定正在请求DTC扩展数据的指定DTC的特定DTC扩展数据记录。
连同DTC号和DTC状态，服务器应返回一个预定义的DTC扩展数据记录，以响应客户端的请求(DTCExt数据记录号不等于0xFE或0xFF)。
车辆制造商应定义DTC出口数据记录的格式和内容。DTCExt数据记录中报告的数据的结构由DTCExt数据记录号定义，其方式与记录数据标识符中的数据定义类似。响应中可能包含多个DTCExt数据记录号和相关的DTCExt数据记录。使用一个或多个DTCExt数据记录号允许为单个DTC存储不同类型的DTCExt数据记录。
服务器应在单个响应消息中报告一个DTC扩展数据记录，但客户端已将DTCExtDAT记录数设置为0xFE或0xFF，因为这将导致服务器在单个响应消息中响应为客户端定义的DTC扩展记录存储的所有数据记录。
如果客户端指定的DTCMask记录或DTCExt数据记录数参数无效或服务器不支持，则服务器应进行否定响应。这包括客户端发送的DTCExt数据记录数为0xFE的情况，但服务器不支持OBD扩展数据记录(0x90-0xEF)。这与客户端指定的DTCMask记录和/或DTCExt数据记录数参数确实是有效的并且由服务器支持，但没有与其关联的DTC扩展数据（例如，由于扩展数据的内存溢出）的情况有所不同。如果是reportDTCExtDataRecordByDTCNumber，服务器应发送只包含DTC和n状态记录(请求的DTC号（高、中、低字节）和DTC状态)的肯定响应。