目录
- 1、0x19服务(ReadDTCInformation,读取DTC信息服务)
- 1.1 reportNumberOfDTCByStatusMask(sub-function = 0x01)
- 1.2 reportDTCByStatusMask(sub-function = 0x02)
- 1.3 reportDTCSnapshotIdentification(sub-function = 0x03)
- 1.4 reportDTCSnapshotRecordByDTCNumber(sub-function = 0x04)
- 1.5 reportDTCStoredDataByRecordNumber(sub-function = 0x05)
- 1.6 reportDTCExtDataRecordByDTCNumber(sub-function = 0x06)
- 1.7 reportNumberOfDTCBySeverityMaskRecord(sub-function = 0x07)
- 1.8 reportDTCBySeverityMaskRecord(sub-function = 0x08)
- 1.9 reportSeverityInformationOfDTC(sub-function = 0x09)
- 1.10 reportSupportedDTC(sub-function = 0x0A)
- 1.11 reportFirstTestFailedDTC(sub-function = 0x0B),reportMostRecentTestFailedDTC(sub-function = 0x0D)
- 1.12 reportFirstConfirmedDTC(sub-function = 0x0C),reportMostRecentConfirmedDTC(sub-function = 0x0E)
- 1.13 reportMirrorMemoryDTCByStatusMask(sub-function = 0x0F)
- 1.14 reportMirrorMemoryDTCExtDataRecordByDTCNumber(sub-function = 0x10)
- 1.15 reportNumberOfMirrorMemoryDTCByStatusMask(sub-function = 0x11)
- 1.16 reportNumberOfEmissionsOBDDTCByStatusMask(sub-function = 0x12)
- 1.17 reportEmissionsOBDDTCByStatusMask(sub-function = 0x13)
- 1.18 reportDTCFaultDetectionCounter(sub-function = 0x14)
- 1.19 reportDTCWithPermanentStatus(sub-function = 0x15)
- 1.20 reportDTCExtDataRecordByRecordNumber(sub-function = 0x16)
- 1.21 reportWWHOBDDTCByMaskRecord(sub-function = 0x42)
- 1.22 reportWWHOBDDTCWithPermanentStatus(sub-function = 0x55)
- 1.23 reportUserDefMemoryDTCByStatusMask(sub-function = 0x17)
- 1.24 reportUserDefMemoryDTCSnapshotRecordByDTCNumber(sub-function = 0x18)
- 1.25 reportUserDefMemoryDTCExtDataRecordByDTCNumber(sub-function = 0x19)
- 2、请求报文格式
- 3、肯定应答报文
- 4、支持的否定应答码(NRC_)
- 5、0x19服务(ReadDTCInformation,读取故障码信息服务)案例说明
- Example #1 - ReadDTCInformation, sub-function = reportNumberOfDTCByStatusMask
- Example #2 - ReadDTCInformation, sub-function = reportDTCByStatusMask,matching DTCs returned
- Example #3 - ReadDTCInformation, sub-function = reportDTCByStatusMask,no matching DTCs returned
- Example #4 - ReadDTCInformation, sub-function = reportDTCSnapshotIdentification
- Example #5 - ReadDTCInformation, sub-function = reportDTCSnapshotRecord-ByDTCNumber
- Example #6 - ReadDTCInformation, sub-function = reportDTCStoredDataByRecordNumber
- Example #7 - ReadDTCInformation, sub-function = reportDTCExtDataRecordByDTCNumber
- Example #8 - ReadDTCInformation, sub-function = reportNumberOfDTCBySeverityMaskRecord
- Example #9 - ReadDTCInformation, sub-function = reportDTCBySeverityMaskRecord
- Example #10 - ReadDTCInformation, sub-function = reportSeverityInformationOfDTC
- Example #11 - ReadDTCInformation, sub-function = reportSupportedDTCs
- Example #12 - ReadDTCInformation, sub-function = reportFirstTestFailedDTC,information available
- Example #13 - ReadDTCInformation, sub-function = reportFirstTestFailedDTC,no information available
- Example #14 - ReadDTCInformation, sub-function = reportNumberOfEmissionsOBDDTCByStatusMask
- Example #15 - ReadDTCInformation, sub-function = reportEmissionsOBDDTCByStatusMask,all matching OBD DTCs returned
- Example #16 - ReadDTCInformation, sub-function = reportEmissionsOBDDTCByStatusMask(confirmedDTC and warningIndicatorRequested),matching DTCs returned
- Example #17 - ReadDTCInformation, sub-function = reportDTCExtDataRecordByRecordNumber
- Example #18 - ReadDTCInformation, sub-function = reportWWHOBDDTCByMaskRecord
1、0x19服务(ReadDTCInformation,读取DTC信息服务)
Service description:
0x19服务(ReadDTCInformation,读取DTC信息服务)允许客户端读取 ECU 中存留的诊断故障代码(DTC)的相关信息。除非特定子函数另有要求,服务端应返回所有DTC信息(例如排放相关和非排放相关)。0x19 服务允许 ECU 执行如下操作:
— 获取与客户端定义故障码状态掩码(DTC Status Mask)相匹配的 DTC 数量;
— 获取与客户端定义故障码状态掩码(DTC Status Mask)相匹配的所有 DTC 列表;
— 获取与客户端定义故障码状态掩码(DTC Status Mask)相匹配的特定功能组内的 DTC 列表;
— 获取所有带有“永久故障码”状态的 DTC;
— 获取故障码快照数据(有时也会叫冻结帧):故障码快照数据(DTC Snapshots)是与 DTC 相关的一些指定的数据记录,一般存储在 ECU 内存中。故障码快照数据(DTC Snapshots) 的主要用处:一旦检测到系统故障便存储与该故障相关的数据。在故障发生瞬间,一系列的数据值便会被冻结(快照)下来,这就是快照数据(DTC Snapshots)所承担的角色。DTC Snapshots 中的数据应与 DTC 相关,这些快照信息可以帮助技术人员迅速地排查故障。
— 客户端定义好 DTC 和状态掩码,即可从 DTC 内存或 DTC 镜像内存中获取相关的 DTCExtendedData 。扩展数据( DTCExtendedData ) 由扩展状态信息组成。DTCExtendedData 包含了 DTC 故障码本身。DTCExtendedData 的典型用法就是用来存储与 DTC 相关的动态变化的数据,如:
— 系统在故障发生时运行的时间(如,发动机工作的小时数);
— 故障码发生次数,统计在若干驾驶循环中,故障检测结果为(“TestFailed”)的次数;
— 故障码老化次数,自故障码最近一次失效(“testFailed”)以来统计驾驶循环的次数,不包括那些没有汇报出 “testPassed” 或者 “testFailed” 的驾驶循环;
— OBD 相关的特定计数器;
— 最近发生时间;
— 测试失败(“testFailed”)次数,统计 “testFailed” 的汇报次数;
— 未完成的测试次数、自最近一次测试完成后的驾驶循环次数;
— 获取与客户端定义严重等级掩码(severity mask)相匹配的故障码数量;
— 获取与客户端定义严重等级掩码记录(severity mask record)相匹配的故障码列表;
— 获取与指定故障码的严重等级信息;
— 获取 ECU 支持的所有故障码的状态信息;
— 获取 ECU 第一个失效的故障码;
— 获取 ECU 最近一次失效的故障码;
— 获取第一个确认(Confirmed)的故障码;
— 获取最近确认的故障码;
— 获取在 DTC 镜像内存中与客户端所指定的 DTC 状态掩码相匹配的 DTC 列表;
— 从DTC镜像内存中,获取客户端定义的DTC掩码的扩展数据记录、客户端定义扩展数据记录的数量;
— 从 DTC 镜像内存中,获取客户端定义 DTC 状态掩码的DTC数量;
— 根据 DTC 状态掩码,获取排放相关的 DTC 数量;如果检测到与排放相关的 OBD DTC,则会导致故障指示灯打开或者是消息提示;
— 根据 DTC 状态掩码,获取排放相关的 OBD DTC 状态信息;如果检测到与排放相关的OBD DTC,则会导致故障指示灯打开或者是消息提示;
— 获取所有当前 “prefailed” 的 DTC,不管有没有被被检测为 “pending” 或者 “confirmed” ;
— 获取 DTCExtendedData ;
— 从用户自定义的 DTC 内存中,获取与客户端指定的 DTC 状态掩码相匹配的 DTC 列表;
— 从用户自定义的 DTC 镜像内存中,获取与客户端指定的 DTC 掩码以及DTCExtendedData record number 相匹配的 DTCExtendedData record data;
—从用户定义的 DTC 内存中获取与客户端指定的 DTC 状态掩码相匹配的DTCSnapshotRecord 数据;
该服务使用子函数去决定客户端正在请求哪种类型的诊断信息。关于每个子函数参数的更多细节在下文中提供。
本服务使用以下条例:
— Enable Criteria:车辆制造商/系统供应商制定标准,用于控制 ECU 何时执行指定的内部诊断;
— Test Pass Criteria:车辆制造商/系统供应商制定标准,用于定义被诊断的系统是否在正常且可接受的操作范围内运行(例如,没有故障存在,被诊断的系统被分类为 “OK” );
— Test Failure Criteria:车辆制造商/系统供应商制定失效条件,用于定义被诊断的系统是否测试失效;
— Confirmed Failure Criteria:车辆制造商/系统供应商制定失效条件,被用于定义被诊断的系统是否确实存在问题(“confirmed”),保证将 DTC 信息存储在长期记忆中;
— Occurrence Counter:故障发生计数器,统计 DTC 汇报“testFailed”实例数;
— Aging:ECU 评估过去每一次内部诊断的结果,以确定是否可以从内存中清除掉已确认故障码的过程。
给定DTC值(如,0x080511)永远不会在 readDTCInformation 的肯定应答报文中报告超过一次,除了读取 DTCSnapshotRecords ,其中应答报文中同一个 DTC 可能会包含多条 DTCSnapshotRecords 。
当使用分页缓冲处理读取 DTCs 时(特别是对于 subfunction = reportDTCByStatusMask),在开始准备应答报文回复时,DTC 的数量有可能会减少。在这种情况下,应答报文应该用 DTC = 0x000000 和 DTC 状态 = 0x00 字节来填充。客户端应将这些 DTC 视为不存在于应答报文中。
1.1 reportNumberOfDTCByStatusMask(sub-function = 0x01)
客户端可以通过将子函数设置为reportNumberOfDTCByStatusMask,发送请求来获取与客户端定义故障码的状态掩码相匹配的DTC数量。对该请求的应答中包含了DTCStatusAvailabilityMask,它提供了服务端支持的用于屏蔽目的的DTC状态位指示。在DTCStatusAvailabilityMask之后,应答包含了DTCFormatIdentifier,它报告有关DTC格式化和编码的信息。DTCFormatIdentifier后面跟着DTCCount参数,该参数是一个2字节的无符号数字,包含了在内存中基于客户端提供的状态掩码可获取到的DTC数量。
子函数reportNumberOfMirrorMemoryDTCByStatusMask与子函数reportNumberOfDTCByStatusMask具有相同的功能,不同之处在于它返回DTC镜像内存的DTC数量。
1.2 reportDTCByStatusMask(sub-function = 0x02)
客户端可以获取满足客户端定义的状态掩码的DTC列表,方法是发送一个带有子函数字节集reportDTCByStatusMask的请求。这个子函数允许客户端请求服务端报告所有“testFailed”或“confirmed”或“等等”的DTC。
评估过程如下:在客户端请求中指定的掩码与服务端支持的每个DTC对应的实际状态之间,服务端会进行逐位逻辑与运算。除了DTCStatusAvailabilityMask之外,服务端应该返回所有与运算结果为非零的DTC(即(statusOfDTC & DTCStatusMask) != 0)。如果客户端指定的状态掩码包含服务器不支持的位,那么服务端应该只使用它支持的位来处理DTC信息。如果服务端内没有DTC匹配客户端请求中指定的掩码标准,则在肯定应答报文中的DTCStatusAvailabilityMask字节之后不提供DTC或状态信息。
在客户端ClearDiagnosticInformation请求成功后,DTC状态信息将被清除。
1.3 reportDTCSnapshotIdentification(sub-function = 0x03)
客户端可以为所有捕获的DTCSnapshot记录获取DTCSnapshot记录的标识信息,方法是向该服务发送一个请求,子函数设置为reportDTCSnapshotIdentification。服务端会为所有的所有存储的DTCSnapshot记录,返回DTCSnapshot记录标识的信息列表。服务端在单个DTCSnapshot记录的应答报文中所放置的每个项,都应包含一个DTCRecord(其中包含DTC编号(高、中、低字节))和DTCSnapshot记录编号。如果为单个DTC存储多个DTCSnapshot记录,则服务端应在每次发生的响应中放置一个条目,对每次发生使用不同的DTCSnapshot记录号(用于以后获取记录数据)。
Note:服务端可以支持为单个DTC存储多个DTCSnapshot记录,以跟踪每次DTC出现时的条件。对该功能的支持、“发生”标准的定义以及支持的DTCSnapshot记录的数量应由系统供应商/车辆制造商定义。
DTCSnapshot记录标志信息应在客户端成功请求0x14服务,ClearDiagnosticInformation请求后清除。存储的DTC和DTCSnapshot数据在内存溢出(存储的DTC和DTCSnapshot数据的内存空间在服务端上被完全占用)时删除的规则由汽车制造商负责。
1.4 reportDTCSnapshotRecordByDTCNumber(sub-function = 0x04)
客户端可以为客户端定义的DTCMaskRecord和DTCSnapshot记录次数,获取捕获的DTCSnapshot记录数据,方法是发送此服务的请求,并且将子函数设置为reportDTCSnapshotRecordByDTCNumber。服务端将在其支持的DTC中搜索与客户端指定的DTCMaskRecord(包含DTC编号号(高、中、低字节))精确匹配的DTCMaskRecord。客户端请求中提供的DTCSnapshotRecordNumber参数,应该去指定具体DTC的出现次数。
NOTE 1:DTCSnapshotRecordNumber不与DTCStoredDataRecordNumber共享相同的地址空间。
如果服务端支持为单个DTC存储多个DTCSnapshot记录的能力(对该功能的支持将由系统供应商/车辆制造商定义),那么建议服务端也实现reportDTCSnapshotIdentification子函数参数。建议客户端在通过reportDTCSnapshotRecordByDTCNumber请求特定的DTCSnapshotRecordNumber之前,首先使用子函数参数reportDTCSnapshotIdentification请求存储DTCSnapshot记录的标识。
还建议支持子函数参数reportDTCSnapshotRecordIdentification,以便让客户端有机会直接识别存储的DTCSnapshot记录,而不是通过解析服务器的所有存储的dtc来确定是否存储了DTCSnapshot记录。
系统供应商/车辆制造商应负责定义在此类服务器中捕获的DTCSnapshot记录是否存储与故障发生信息相关的数据,并将其作为ECU文档的一部分。
如果客户端定义的DTCMaskRecord和DTCSnapshotRecordNumber参数(DTCSnapshotRecordNumber不等于0xFF)已经确定失败,服务端应返回单个预定义的DTCSnapshotRecord来响应客户端的请求。
NOTE 2:准确的失效标准应该由系统供应商/车辆制造商来定义。
DTCSnapshot记录可能包含多个数据参数,可用于重建故障发生时的车辆状况(例如B+, RPM,时间戳)。
DTCSnapshotRecord的格式和内容由车辆制造商自行定义。DTCSnapshotRecord中报告的数据首先包含一个数据标识符,用于标识后面的数据。这个数据标识符/数据组合可以在DTCSnapshotRecord中重复。在DTCSnapshotRecord中使用一个或多个数据标识符允许为单个DTC存储不同类型的DTCSnapshotRecords,以应对不同的故障发生。每个DTCSnapshotRecord应提供一个参数,该参数指示每个DTCSnapshotRecord中包含的记录数据标识符的数量,以协助数据检索。
服务端应在单个应答报文中报告一条DTCSnapshot记录,除非客户端已将DTCSnapshotRecordNumber设置为0xFF,因为这将导致服务端在单个应答报文中响应为客户端定义的DTCMaskRecord存储的所有DTCSnapshot记录。DTCAndStatusRecord在应答报文中只包含一次。如果客户端在其请求中设置参数DTCSnapshotRecordNumber为0xFF,则服务端应以数字升序的方式去汇报为特定DTC捕获的所有DTCSnapshot记录。
如果客户端指定的DTCMaskRecord或DTCSnapshotRecordNumber参数无效或服务端不支持,服务端将否定应答。这与客户端指定的DTCMaskRecord和/或DTCSnapshotRecordNumber参数确实有效并被服务端支持,但没有与DTC关联的DTCSnapshot数据(例如,因为指定的DTC或记录编号从未发生失效事件)的这种情况有所区别。服务端应该发送肯定应答,只包含DTCAndStatusRecord(请求的DTC编号(高、中、低字节)加上DTC状态)。
DTCSnapshot信息应在客户端成功发出ClearDiagnosticInformation请求后清除。存储的DTC和DTCSnapshot数据在内存溢出(存储的DTC和DTCSnapshot数据的内存空间在服务端上被完全占用)时的删除规则由汽车制造商负责。
1.5 reportDTCStoredDataByRecordNumber(sub-function = 0x05)
客户端可以通过将子函数设置为reportDTCStoredDataByRecordNumber,并使用该服务发送请求来获取捕获到的DTCStoredData记录数据。服务端将在其存储的DTCStoredData记录中获取与客户端提供的记录编号相匹配的记录。
DTCStoredDataRecordNumber与DTCSnapshotRecordNumber处于不同的地址空间。
系统供应商/车辆制造商应负责定义在服务端中捕获的DTCStoredData记录是否存储与首次或最近发生的故障相关的数据。
DTCStoredData记录可能包含多个数据参数,可用于重建故障发生时的车辆状况(例如B+, RPM,时间戳)。
车辆制造商应定义DTCStoredDataRecordNumber的格式和内容。DTCStoredDataRecord中报告的数据首先包含一个数据标识符,用于标识后面的数据。这个数据标识符/数据组合可以在DTCStoredDataRecord中重复。对于不同故障发生时,在DTCStoredDataRecord中使用一个或多个数据标识符去存储不同类型的数据。每个DTCStoredDataRecord应提供一个参数,该参数指示每个DTCStoredDataRecord中包含的记录数据标识符的数量,以协助数据获取。
服务端应在单个应答报文中报告一个DTCStoredDataRecord,除非客户端已将DTCStoredDataRecordNumber设置为0xFF,因为这将导致服务端在单个应答报文中对所有的DTCStoredDataRecords进行响应。
如果客户端通过记录编号去请求汇报所有的DTCStoredDataRecords,那么对于每一个存储的DTCStoredDataRecord都需要去重复DTCAndStatusRecord。
如果客户端指定的DTCStoredDataRecordNumber参数无效或服务端不支持,服务器将否定应答。这与客户端指定的DTCStoredDataRecordNumber参数确实有效并得到服务端支持,但没有与DTC相关联的DTCStoredDataRecord数据(例如,因为指定的记录号从未发生过失败事件)的情况有所不同。服务端应发送只包含DTCStoredDataRecordNumber(请求的记录编号)的肯定应答。
DTCStoredDataRecord信息应在客户端成功发出ClearDiagnosticInformation请求后清除。在内存溢出(用于存储DTC和DTCStoredDataRecord数据的内存空间在服务端中被完全占用)的情况下,车辆制造商有责任指定删除存储DTC和DTCStoredDataRecord数据的规则。
1.6 reportDTCExtDataRecordByDTCNumber(sub-function = 0x06)
客户端可以根据客户端定义的DTCMaskRecord和DTCExtendedData记录编号,来获取DTCExtendedData,方法是发送该服务的请求,并将子函数集设置为reportDTCExtDataRecordByDTCNumber。服务端将在其支持的DTC中搜索与客户端指定的DTCMaskRecord(包含DTC号(高、中、低字节))相匹配的DTCMaskRecord。在这种情况下,客户端请求中提供的DTCExtDataRecordNumber参数中应该要指定DTC的特定DTCExtendedData记录。
使用DTC码和状态,服务端应返回一个预定义DTCExtendedData记录,来响应客户端的请求(DTCExtDataRecordNumber不等于0xFE或0xFF)。
车辆制造商应定义DTCExtDataRecord的格式和内容。DTCExtDataRecord中报告的数据结构由DTCExtDataRecordNumber以类似于记录DataIdentifier中的数据定义的方式定义。响应中可能包含多个DTCExtDataRecordNumbers和关联的DTCExtDataRecords。使用一个或多个DTCExtDataRecordNumbers允许为单个DTC存储不同类型的DTCExtDataRecords。
服务端应该在单个应答报文中报告一条DTCExtendedData记录,除非客户端将DTCExtDataRecordNumber设置为0xFE或0xFF,因为这将导致服务器在单个响应消息中使用为客户端定义的DTCMaskRecord存储的所有DTCExtendedData记录进行响应。
如果客户端指定的DTCMaskRecord或DTCExtDataRecordNumber参数无效或服务端不支持,服务端将否定应答。这包括客户端发送0xFE的DTCExtDataRecordNumber,但服务端不支持OBD扩展数据记录(0x90 - 0xEF)的情况。这与客户端指定的DTCMaskRecord和/或DTCExtDataRecordNumber参数确实有效并被服务器支持,但是没有与DTC相关的DTC扩展数据(例如,由于扩展数据的内存溢出)的情况有所区别。在reportDTCExtDataRecordByDTCNumber的情况下,服务端应发送只包含DTCAndStatusRecord(请求的DTC号(高、中、低字节)加上DTC状态)的肯定应答。
在接收ClearDiagnosticInformation服务时清除DTCExtendedData信息,见0x14服务。存储的DTC和DTC扩展数据在内存溢出(存储的DTC和DTC扩展数据的内存空间在服务器上被完全占用)时,删除规则由汽车制造商负责。
1.7 reportNumberOfDTCBySeverityMaskRecord(sub-function = 0x07)
客户端可以通过将子函数设置为reportNumberOfDTCBySeverityMaskRecord发送此服务的请求来获取匹配客户端定义的严重性状态掩码记录的DTC数量。服务端扫描所有支持的DTC,在客户端指定的掩码记录与存储的每个DTC的实际信息之间进行逐位逻辑与运算。
(((statusOfDTC & DTCStatusMask) != 0) && ((severity & DTCSeverityMask) != 0)) == TRUE
对于每个产生TRUE结果的AND操作,服务器将计数器增加1。如果客户端在掩码记录中指定了包含服务端不支持位的状态掩码,那么服务端将只使用它支持的位来处理DTC信息。一旦所有支持的DTC都被检查一次,服务器将返回DTCStatusAvailabilityMask和2字节的结果计数给客户端。
NOTE 如果服务端内没有DTC符合客户端请求中指定的掩码标准,则服务端返回给客户端的计数为0。与DTC状态掩码相匹配的DTC报告数量在发出请求的时间点上是有效的。报告的DTC数量和通过子函数reportDTCByStatusMask读取的实际DTC列表之间没有关系,因为读取DTC的请求是在不同的时间点完成的。
1.8 reportDTCBySeverityMaskRecord(sub-function = 0x08)
通过发送带有子函数字节集= reportDTCBySeverityMaskRecord的请求,客户端可以获取DTC严重性和功能单元信息的列表,这些信息满足客户端定义的严重性掩码记录。此子函数允许客户端请求服务端报告具有一定严重性和状态的所有DTC,如“testFailed”或“confirmed”或“等”。评估方法如下:
服务端将拿客户端请求指定的DTCSeverityMask和DTCStatusMask,与服务端支持的每个DTC实际相关联的DTCSeverity和statusOfDTC之间执行逐位逻辑与运算。
除了DTCStatusAvailabilityMask之外,服务端还应该返回所有与操作结果为TRUE的dtc。
(((statusOfDTC & DTCStatusMask) !=0) && ((severity & DTCSeverityMask) != 0)) == TRUE
如果客户端在指定的掩码记录中包含了服务端不支持位的状态掩码,那么服务端将只使用它支持的位来处理DTC信息。如果服务端内没有DTC与客户端请求中指定的掩码标准相匹配,则在肯定应答报文中的DTCStatusAvailabilityMask字节之后不提供DTC或状态信息。
1.9 reportSeverityInformationOfDTC(sub-function = 0x09)
客户端可以为客户端定义的DTCMaskRecord获取严重性和功能单元信息,方法是发送将子功能集设置为reportSeverityInformationOfDTC的服务请求。服务端将在其支持的DTC中获取与客户端指定的DTCMaskRecord(包含DTC号(高、中、低字节))相匹配的DTCMaskRecord。
1.10 reportSupportedDTC(sub-function = 0x0A)
客户端可以通过将子函数集设置为reportsupporteddtc的服务发送请求来检索服务器支持的所有dtc的状态。对该请求的响应包含dtcstatusavailabilityymask,它提供了服务器支持的用于屏蔽目的的DTC状态位的指示。在dtcstatusavailabilityymask之后,响应还包含listOfDTCAndStatusRecord,其中包含服务器支持的每个诊断故障代码的DTC编号和相关状态。
1.11 reportFirstTestFailedDTC(sub-function = 0x0B),reportMostRecentTestFailedDTC(sub-function = 0x0D)
客户端可以通过发送一个请求,将子函数分别设置为“reportFirstTestFailedDTC”或“reportMostRecentTestFailedDTC”,从服务端获取第一个/最近一次失败的DTC。采用DTCStatusAvailabilityMask,服务端应该将第一个或最近失败的DTC码和相关状态返回给客户端。
如果自上次客户端请求服务端清除诊断信息以来,没有记录下失效的DTC,则在肯定应答报文中的DTCStatusAvailabilityMask字节之后,不会有DTC /状态信息。此外,如果自上次客户端请求服务端清除诊断信息以来,只有一个DTC发生故障,则都需要将这个失效的DTC返回给来自于客户端请求的reportFirstTestFailedDTC和reportMostRecentTestFailedDTC。
第一次/最近一次失效的DTC,应独立于已确认DTC的老化过程。
如上所述,第一次/最近一次失败的DTC信息应在客户端使用0x14服务(ClearDiagnosticInformation)请求成功后被清除。
1.12 reportFirstConfirmedDTC(sub-function = 0x0C),reportMostRecentConfirmedDTC(sub-function = 0x0E)
客户端可以通过发送子函数字节集分别为“reportFirstConfirmedDTC”或“reportMostRecentConfirmedDTC”的请求,从服务端获取第一个/最近一次确认的DTC。通过DTCStatusAvailabilityMask,服务端应该返回第一个或最近确认的DTC码和相关状态给客户端。
如果自上次客户端请求服务端清除诊断信息以来,没有记录下确认的DTC,则在肯定应答报文中的DTCStatusAvailabilityMask字节之后不提供DTC /状态信息。此外,如果自上次客户端请求服务端清除诊断信息后,只有1个DTC被确认,则应将确认的DTC返回给来自客户端的reportFirstConfirmedDTC和reportMostRecentConfirmedDTC请求。
在过去的某个时间点,如果DTC失效,但在客户提出请求(即汇报第一/最近一次DTC请求)之前又满足了故障码的老化标准(无论在上述DTC确认之后是否有其他DTC确认),则应保留第一次确认的DTC记录。同样,如果DTC在过去某个时间点被确认,但在客户请求之前满足老化标准(假设在上述DTC失效后没有其他DTC被确认),则应保留最近确认的DTC记录。
如上所述,首次/最近确认的DTC信息,应在客户成功请求ClearDiagnosticInformation后清除。
1.13 reportMirrorMemoryDTCByStatusMask(sub-function = 0x0F)
子函数reportMirrorMemoryDTCByStatusMask的处理与子函数为reportDTCByStatusMask所定义的处理相同,除了所有状态掩码的检查都是使用存储在服务端DTC镜像内存中的DTC执行的。DTC镜像内存是服务器中一个额外的可选错误内存,它不能被ClearDiagnosticInformation (0x14)服务擦除。DTC镜像内存是正常DTC内存的镜像,可以在正常错误内存被擦除的情况下使用。
1.14 reportMirrorMemoryDTCExtDataRecordByDTCNumber(sub-function = 0x10)
子函数reportMirrorMemoryDTCExtDataRecordByDTCNumber的处理与子函数为reportDTCExtDataRecordByDTCNumber所定义的处理相同,除了数据是从DTC镜像内存中检索出来这一点不同外。DTC镜像内存是服务端中一个额外的可选错误内存,它不能被ClearDiagnosticInformation (0x14)服务擦除。DTC镜像内存是正常DTC内存的镜像,可以在正常错误内存被擦除的情况下使用。
1.15 reportNumberOfMirrorMemoryDTCByStatusMask(sub-function = 0x11)
客户端可以通过将子函数设置为reportNumberOfMirrorMemoryDTCByStatusMask发送此服务的请求,来获取与客户端定义的状态掩码相匹配的镜像内存DTC的数量。对该请求的响应包含了DTCStatusAvailabilityMask,它提供了服务端支持的用于屏蔽目的的DTC状态位的指示。在DTCStatusAvailabilityMask之后,应答包含了DTCFormatIdentifier,它报告了有关DTC格式和编码的信息。DTCFormatIdentifier后面跟着DTCCount参数,该参数是一个2字节的无符号数,包含了基于客户端提供的状态掩码的服务端内存中可获取的DTC数量。
1.16 reportNumberOfEmissionsOBDDTCByStatusMask(sub-function = 0x12)
客户端可以通过将子函数集设置为reportNumberOfEmissionsOBDDTCByStatusMask的服务发送请求,来获取与客户端定义的状态掩码相匹配的“仅与排放相关的OBD”的DTC数量。对该请求的响应包含了DTCStatusAvailabilityMask,它提供了服务端支持的用于屏蔽目的的DTC状态位的指示。在DTCStatusAvailabilityMask之后,响应包含了DTCFormatIdentifier,它报告了有关DTC格式化和编码的信息。DTCFormatIdentifier之后是DTCCount参数,该参数是一个2字节的无符号数,包含了基于客户端提供的状态掩码在服务端内存中可用的“仅与发射相关的OBD”的DTC数量。
1.17 reportEmissionsOBDDTCByStatusMask(sub-function = 0x13)
客户端可以获取索“仅与排放相关的OBD”的DTC列表,它通过发送子函数字节集为reportEmissionsOBDDTCByStatusMask的请求,来满足客户端所定义的状态掩码。此子函数允许客户端去请求服务端报告所有的“testFailed”或“confirmed”或“etc”的“与排放相关的OBD”的DTC。评估过程如下:服务端对客户端请求报文中的掩码与服务端支持的每个“与排放相关的OBD”的DTC所对应的实际状态进行逐位逻辑与运算。除了DTCStatusAvailabilityMask之外,服务端应该返回所有结果为非零(即(statusOfDTC & DTCStatusMask) != 0)的“与排放相关的OBD”的DTC。如果客户端指定的状态掩码包含了服务端所不支持的位,那么服务端应该只使用它支持的位来处理DTC信息。如果服务端内没有“与排放相关的OBD”DTC,符合客户端请求中指定的屏蔽标准,则在肯定应答报文中的DTCStatusAvailabilityMask字节之后不提供DTC或状态信息。“与排放相关的OBD”的DTC状态信息应在客户端成功提出ClearDiagnosticInformation请求后清除。
1.18 reportDTCFaultDetectionCounter(sub-function = 0x14)
客户端可以获取当前所有“prefailed”的DTC列表,这些DTC在客户端请求时已经或尚未被检测为“pending”或“confirmed”。DTCFaultDetectionCounter的目的是,作为一个简单的方法,来识别一个不能被特定DTC的statusOfDTC字节所识别/读取到的增长性或间歇性的问题。DTCFaultDetectionCounter的内部实现应该是由汽车制造商指定。“prefailed”DTC的使用案例是在制造工厂测试过程中加速对DTC的故障检测,而往往这些DTC在制造测试中的确认成熟时间都是无法接受的。在维修或安装新组件后的服务也有类似的用例。
1.19 reportDTCWithPermanentStatus(sub-function = 0x15)
客户端可以获取具有“永久DTC”状态的DTC列表。
1.20 reportDTCExtDataRecordByRecordNumber(sub-function = 0x16)
客户端可以为客户端所定义的DTCExtendedData记录编号来获取DTCExtendedData,方法是发送该服务的请求,并将子函数设置为reportDTCExtDataRecordByRecordNumber。服务端将在所有支持的DTC中搜索与客户端指定的DTCExtDataRecordNumber精确匹配的DTC。在这种情况下,客户端请求中所提供的DTCExtDataRecordNumber参数,应该所有支持的DTC指定一个特定的DTCExtendedData记录。
服务端应该返回一个DTCExtendedData记录,以及包含请求DTCExtDataRecordNumber数据的每个支持DTC的DTC编号和statusOfDTC。
车辆制造商应定义DTCExtDataRecord的格式和内容。DTCExtDataRecord中报告的数据结构由DTCExtDataRecordNumber以类似于DataIdentifier记录中的数据定义的方式来定义。
如果客户端指定的DTCExtDataRecordNumber参数无效或服务端不支持,服务端将否定应答。
在接收到ClearDiagnosticInformation服务时,将会清除DTCExtendedData信息。存储的DTC和DTC的扩展数据在内存溢出(存储的DTC和DTC的扩展数据的内存空间在服务端上被完全占用)时,删除规则由汽车制造商负责。
1.21 reportWWHOBDDTCByMaskRecord(sub-function = 0x42)
DTCSeverityMask(带有严重性和类)的实现和使用在ISO 27145-3中定义。
1.22 reportWWHOBDDTCWithPermanentStatus(sub-function = 0x55)
客户端可以获取“永久DTC”状态的WWH-OBD DTCs列表。
1.23 reportUserDefMemoryDTCByStatusMask(sub-function = 0x17)
客户端可以从用户定义的内存中检索DTC列表,通过发送带有子函数字节集为reportUserDefMemoryDTCByStatusMask的请求,来满足客户端定义的状态掩码。这个子函数允许客户端请求服务端从用户定义的内存中,报告所有“testFailed”或“confirmed”或“etc”的DTC。
计算过程如下:服务端在客户端请求中指定的掩码与用户定义内存中服务端支持的每个DTC的实际状态之间执行逐位逻辑与运算。除了DTCStatusAvailabilityMask之外,服务端还应该返回所有与运算结果为非零的DTC(即statusOfDTC & DTCStatusMask) != 0)。如果客户端指定的状态掩码包含服务端不支持的位,那么服务端将只使用它支持的位来处理DTC信息。在特定的内存中,如果服务端内没有DTC与客户端请求中所指定的屏蔽标准相匹配的话,则在肯定应答报文中的DTCStatusAvailabilityMask字节后面是不应该提供DTC或状态信息的。
DTC状态信息不应在客户端执行ClearDiagnosticInformation服务的请求成功后清除,而应由制造商指定的常规控制去清除。
1.24 reportUserDefMemoryDTCSnapshotRecordByDTCNumber(sub-function = 0x18)
客户端可以为客户端定义的DTCMaskRecord以及DTCSnapshot记录编号和用户定义的内存标识符来获取捕获的DTCSnapshot记录数据,方法是发送此服务的请求,子函数集设置为reportUserDefMemoryDTCSnapshotRecordByDTCNumber。服务端将在其支持的DTC中搜索与客户端指定的DTCMaskRecord(包含DTC号(高、中、低字节))精确匹配的DTCMaskRecord。客户端请求中提供的DTCSnapshotRecordNumber参数,应指定请求DTCSnapshot记录数据中的具体DTC和定义内存的特定发生。
NOTE 1 DTCSnapshotRecordNumber和DTCStoredDataRecordNumber不共享同一个地址空间。
系统供应商/车辆制造商应负责定义在此类服务端中捕获的DTCSnapshot记录是否存储与首次或最近发生的故障相关的数据。
通过DTC编号和statusOfDTC,如果客户端定义的DTCMaskRecord和DTCSnapshotRecordNumber参数(DTCSnapshotRecordNumber不等于0xFF)和特定的内存已经确定失败,服务端应该从特定的用户内存中来返回一个预定义的DTCSnapshotRecord,来响应客户端的请求。
NOTE 2 准确的失效标准应由系统供应商/车辆制造商定义。
DTCSnapshot记录可能包含多个数据参数,可用于重建故障发生时的车辆状况(例如B+, RPM,时间戳)。
车辆制造商应在用户自定义内存中定义DTCSnapshotRecord的格式和内容记录(即不同内存中DTCSnapshotRecords的内容可以不同)。DTCSnapshotRecord中数据中首先包含一个数据标识符,用于标识后面的数据。这个数据标识符/数据组合可以在DTCSnapshotRecord中重复。在用户定义内存中的DTCSnapshotRecord中使用一个或多个数据标识符,允许为单个DTC存储不同类型的DTCSnapshotRecords,以应对不同的故障发生。每个DTCSnapshotRecord应提供一个参数,该参数指示每个DTCSnapshotRecord中包含的记录数据标识符的数量,以协助数据获取。
服务端应在单个应答报文中报告一条DTCSnapshot记录,除非客户端已将DTCSnapshotRecordNumber设置为0xFF,因为这将导致服务端在单个应答报文中使用为客户端定义的DTCMaskRecord和用户定义的内存存储中的所有DTCSnapshot记录进行响应。DTCAndStatusRecord在应答报文中只包含一次。
如果客户端指定的DTCMaskRecord、DTCSnapshotRecordNumber、UserDefMemory参数无效或服务器不支持,服务器将否定应答。这与客户端指定的DTCMaskRecord和/或DTCSnapshotRecordNumber参数确实有效并由服务器支持该特定内存,但没有与之关联的DTCSnapshot数据(例如,因为指定的DTC或记录号从未发生失败事件)的情况有所区别。服务端应该发送肯定应答,只包含DTCAndStatusRecord(请求的DTC号(高、中、低字节)加上statusOfDTC)。
DTCSnapshot信息应根据客户提出的制造商特定条件(如例程控制)要求予以清除。在内存溢出(用于存储DTC和DTCSnapshot数据的内存空间在服务端上被完全占用)的情况下,车辆制造商有责任指定删除存储DTC和DTCSnapshot数据的规则。
1.25 reportUserDefMemoryDTCExtDataRecordByDTCNumber(sub-function = 0x19)
客户端可以为客户端定义的DTCMaskRecord和DTCExtendedData记录编号以及UserDefMemoryIdenitfier一起检索DTCExtendedData,方法是发送该服务的请求,子函数设置为reportUserDefMemoryDTCExtDataRecordByDTCNumber。服务端将在它支持的DTC中搜索与客户端指定的DTCMaskRecord(包含DTC编号(高、中、低字节))和UserDefMemoryIdentifier精确匹配的DTC。在这种情况下,客户端请求中提供的DTCExtDataRecordNumber参数应指定请求DTCExtendedData的指定DTC的特定DTCExtendedData记录。
通过DTC编号和statusOfDTC,服务端应返回一个单一的预定义DTCExtendedData记录以响应客户端的请求(DTCExtDataRecordNumber不等于0xFE或0xFF)。
车辆制造商应定义UserDefDTCExtDataRecord的格式和内容。DTCExtDataRecord中报告的数据结构由DTCExtDataRecordNumber为特定用户定义的内存定义,其方式与记录DataIdentifier中的数据定义类似。响应中可能包含多个DTCExtDataRecordNumbers和关联的DTCExtDataRecords。使用一个或多个DTCExtDataRecordNumbers,允许为单个DTC存储不同类型的DTCExtDataRecords。
服务端应在单个应答报文中报告一条DTCExtendedData记录,除非客户端已将DTCExtDataRecordNumber设置为0xFE或0xFF,因为这将导致服务端在单个响应消息中使用为客户端定义的DTCMaskRecord存储的所有DTCExtendedData记录进行响应。
如果客户端指定的DTCMaskRecord或DTCExtDataRecordNumber参数无效或服务端不支持,或不在指定的内存中,服务端将否定应答。这与客户端指定的DTCMaskRecord和/或DTCExtDataRecordNumber参数确实有效且受服务器支持,但没有DTC扩展数据的情况有所区别。在reportDTCExtDataRecordByDTCNumber的情况下,服务端应发送只包含DTCAndStatusRecord(请求的DTC号(高、中、低字节)的回声加上状态ofdtc)的肯定应答。
车辆制造商有责任指定删除用户定义内存中存储的DTC和DTC扩展数据的规则。
2、请求报文格式
2.1 请求报文定义
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportNumberOfDTCByStatusMask reportDTCByStatusMask reportMirrorMemoryDTCByStatusMask reportNumberOfMirrorMemoryDTCByStatusMask reportNumberOfEmissionsOBDDTCByStatusMask reportEmissionsOBDDTCByStatusMask ] | M | 0x01 0x02 0x0F 0x11 0x12 0x13 |
#3 | DTCStatusMask | M | 0x00 – 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportDTCSnapshotIdentification reportDTCSnapshotRecordByDTCNumber ] | M | 0x03 0x04 |
#3 #4 #5 | DTCMaskRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte ] | C C C | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#6 | DTCSnapshotRecordNumber | C | 0x00 - 0xFF |
C:DTCMaskRecord记录和DTCSnapshotRecordNumber参数只有在子函数参数等于reportDTCSnapshotRecordByDTCNumber的情况下才会出现。
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportDTCStoredDataByRecordNumber ] | M | 0x05 |
#3 | DTCStoredDataRecordNumber | M | 0x00 - 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportDTCExtDataRecordByDTCNumber reportMirrorMemoryDTCExtDataRecordByDTCNumber ] | M | 0x06 0x10 |
#3 #4 #5 | DTCMaskRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte ] | M M M | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#6 | DTCExtDataRecordNumber | M | 0x00 - 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportNumberOfDTCBySeverityMaskRecord reportDTCBySeverityMaskRecord ] | M | 0x07 0x08 |
#3 #4 | DTCSeverityMaskRecord[] = [ DTCSeverityMask DTCStatusMask ] | M M | 0x00 - 0xFF 0x00 - 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportDTCExtDataRecordByDTCNumber | M | 0x09 |
#3 #4 #5 | DTCMaskRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte ] | M M M | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportSupportedDTC reportFirstTestFailedDTC reportFirstConfirmedDTC reportMostRecentTestFailedDTC reportMostRecentConfirmedDTC reportDTCFaultDetectionCounter reportDTCWithPermanentStatus ] | M | 0x0A 0x0B 0x0C 0x0D 0x0E 0x14 0x15 |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportDTCExtDataRecordByRecordNumber] | M | 0x16 |
#3 | DTCExtDataRecordNumber | M | 0x00 - 0xEF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportUserDefMemoryDTCByStatusMask | M | 0x17 |
#3 | DTCStatusMask | M | 0x00 - 0xEF |
#4 | MemorySelection | M | 0x00 – 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportUserDefMemoryDTCSnapshotRecordByDTCNumber] | M | 0x18 |
#3 #4 #5 | DTCMaskRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte ] | M M M | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#6 | DTCSnapshotRecordNumber | M | 0x00 - 0xFF |
#7 | MemorySelection | M | 0x00 - 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportUserDefMemoryDTCExtDataRecordByDTCNumber] | M | 0x19 |
#3 #4 #5 | DTCMaskRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte ] | M M M | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#6 | DTCExtDataRecordNumber | M | 0x00 - 0xFF |
#7 | MemorySelection | M | 0x00 - 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportWWHOBDDTCByMaskRecord ] | M | 0x42 |
#3 | FunctionalGroupIdentifier | M | 0x00 - 0xFF |
#4 #5 | DTCSeverityMaskRecord[] = [ DTCSeverityMask DTCStatusMask ] | M M | 0x00 - 0xFF 0x00 - 0xFF |
基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Request SID | M | 0x19 |
#2 | sub-function = [ reportType = reportWWHOBDDTCWithPermanentStatus ] | M | 0x55 |
#3 | FunctionalGroupIdentifier | M | 0x00 - 0xFF |
2.2 请求报文中子函数参数定义
该服务使用子函数参数从下表中来选择所指定DTC的汇报类型。下面详细介绍了子函数参数的解释和用法。
Bits 6 – 0 | Description | 约定 |
---|---|---|
0x00 | ISOSAEReserved ISO保留 | M |
0x01 | reportNumberOfDTCByStatusMask 该参数指定了服务端应该发送给客户端的DTC数量,这些DTC与客户端所定义的状态掩码需要相匹配。 | U |
0x02 | reportDTCByStatusMask 该参数指定了服务端应该发送给客户端的DTC列表和相应故障状态,这些DTC与客户端所定义的状态掩码需要相匹配。 | U |
0x03 | reportDTCSnapshotIdentification 该参数指定了服务端应该发送给客户端的所有的DTCSnapshot数据记录标识符(DTC number(s) and DTCSnapshot record number(s)) | U |
0x04 | reportDTCSnapshotRecordByDTCNumber 该参数指定了服务端应该发送给客户端的DTCSnapshot record(s)记录,这些数据记录与客户端定义的DTC编号和DTCSnapshot记录编号有关(当记录编号为0xFF,表示为所有的记录) | U |
0x05 | reportDTCStoredDataByRecordNumber 该参数指定了服务端应该发送给客户端的DTCStoredDatarecord(s),这些数据记录与客户端定义的DTCStoredData record number有关(当记录编号为0xFF,表示为所有的记录) | U |
0x06 | reportDTCExtDataRecordByDTCNumber 该参数指定了服务端应该发送给客户端的DTCExtendedData record(s),这些扩展数据记录与客户端定义的DTC number 和 DTCExtendedData record number有关(当记录编号为0xFF,表示为所有的记录;当记录编号为0xFE,表示为所有的OBD记录) | U |
0x07 | reportNumberOfDTCBySeverityMaskRecord 该参数指定了服务端应该发送给客户端的DTC数量,这些DTC与客户端定义的severity mask record相匹配 | U |
0x08 | reportDTCBySeverityMaskRecord 该参数指定了服务端应该发送给客户端的DTC列表和相应的状态,这些DTC与客户端定义的severity mask record相匹配 | U |
0x09 | reportSeverityInformationOfDTC 该参数指定了服务端应该发送给客户端的在请求报文中指定DTC的严重信息 | U |
0x0A | reportSupportedDTC 该参数指定了服务端应该发送给客户端的服务端所支持的所有的DTC列表和相应的状态 | U |
0x0B | reportFirstTestFailedDTC 该参数指定了服务端应该发送给客户端服务端检测到的第一个失效的DTC,自从上次清除诊断信息以来。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。 | U |
0x0C | reportFirstConfirmedDTC 该参数指定了服务端应该发送给客户端服务端检测到的第一个确认的DTC,自从上次清除诊断信息以来。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。(例如,如果一个DTC老化到允许其状态被重置,那么第一个确认的DTC记录将继续由服务端保存,而不管之后是否有任何其他的DTC被确认) | U |
0x0D | reportMostRecentTestFailedDTC 该参数指定了服务端应该发送给客户端服务端检测到的最近一次失效的DTC,自从上次清除诊断信息以来。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。 | U |
0x0E | reportMostRecentConfirmedDTC 该参数指定了服务端应该发送给客户端服务端检测到的最近一次确认的DTC,自从上次清除诊断信息以来。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。(例如,如果一个DTC老化到允许其状态被重置,那么第一个确认的DTC记录将继续由服务端保存,而不管之后是否有任何其他的DTC被确认) | U |
0x0F | reportMirrorMemoryDTCByStatusMask 该参数指定了服务端从镜像内存中应该发送给客户端DTC列表和相应状态,其与状态掩码相匹配 | U |
0x10 | reportMirrorMemoryDTCExtDataRecordByDTCNumber 该参数指定了服务端从镜像内存中应该发送给客户端DTCExtendedData record(s),其与客户端定义的DTC编号和DTCExtendedData record number相关(0xFF表示所有的记录, 0xFE表示所有的OBD记录 ) | U |
0x11 | reportNumberOfMirrorMemoryDTCByStatusMask 该参数指定了服务端从镜像内存中应该发送给客户端DTC的数量,其与客户端定义的状态掩码相匹配 | U |
0x12 | reportNumberOfEmissionsOBDDTCByStatusMask 该参数指定了服务端应该发送给客户端与排放相关的OBD DTC的数量,其与客户端定义的状态掩码相匹配。汇报的OBD DTC数量仅应是那些必须符合排放相关法律要求的dtc数量。 | U |
0x13 | reportEmissionsOBDDTCByStatusMask 该参数指定了服务端应该发送给客户端与排放相关的OBD DTC和相应的状态,其与客户端定义的状态掩码相匹配。汇报的OBD DTC列表仅应是那些必须符合排放相关法律要求的dtc数量。 | U |
0x14 | reportDTCFaultDetectionCounter 该参数指定了服务端应该发送给客户端当前“prefailed”的DTC,其状态已经或者未被检测为。汇报的OBD DTC列表仅应是那些必须符合排放相关法律要求的dtc数量。 DTCFaultDetectionCounter的目的是作为一个简单的方法,来识别一个不能被特定DTC的statusOfDTC字节识别或者读取的增长或间歇性问题。DTCFaultDetectionCounter的内部实现应该是特定于汽车制造商的(例如,字节数,有符号与无符号等),但报告的值应该是一个缩放的1字节有符号值,这样+127 (0x7F)代表测试结果“failed”,任何其他非零的正值代表测试结果“prefailed”。然而,DTCFaultDetectionCounter值为+127的DTC不应根据以下规定汇报。DTCFaultDetectionCounter应按车辆制造商指定的步长递增,每次测试逻辑运行时,并指示该测试运行为失败。 报告的DTCFaultDetectionCounter值大于零且小于+127(即0x01 - 0x7E)表明DTC使能条件得到满足,并且未完成的测试结果至少在一个条件或阈值中预失效。 只有DTCFaultDetectionCounters的非零正值小于+127 (0x7F)的DTC才会被报告。 DTCFaultDetectionCounter应按车辆制造商指定的步长递减,每次测试逻辑运行时,并指示该测试运行为通过。如果DTCFaultDetectionCounter减少到零或以下,DTC将不再在肯定应答报文中报告。DTCFaultDetectionCounter的值在操作循环之间不会被保留。 如果收到ClearDiagnosticInformation服务请求,所有DTC的DTCFaultDetectionCounter值将重置为零。附加复位条件由车辆制造商规定。 | U |
0x15 | reportDTCWithPermanentStatus 该参数指定了服务端应该发送给客户端带有"permanent DTC"状态的DCT列表。 | U |
0x16 | reportDTCExtDataRecordByRecordNumber 该参数指定了服务端应该发送给客户端DTCExtendedData records,其与客户端定义的小于0xF0的DTCExtendedData record number。 | U |
0x17 | reportUserDefMemoryDTCByStatusMask 该参数指定了服务端从用户自定义的DTC内存中应该发送给客户端DTC列表和相应的状态,其与客户端定义的状态掩码相匹配。 | U |
0x18 | reportUserDefMemoryDTCSnapshotRecordByDTCNumber 该参数指定了服务端从用户自定义的DTC内存中应该发送给客户端DTCSnapshot record(s),其与客户端定义的DTC编号和DTCSnapshot record number相匹配(0xFF表示所有的记录)。 | U |
0x19 | reportUserDefMemoryDTCExtDataRecordByDTCNumber 该参数指定了服务端从用户自定义的DTC内存中应该发送给客户端DTCExtendedData record(s),其与客户端定义的DTC编号和DTCExtendedData record number相匹配(0xFF表示所有的记录)。 | U |
0x1A - 0x41 | ISOSAEReserved ISO保留 | U |
0x42 | reportWWHOBDDTCByMaskRecord 该参数指定了服务端应该发送给客户端WWH OBD DTC列表和相应状态以及严重等级信息,其与客户端定义的状态掩码和严重记录相匹配 | U |
0x43 - 0x54 | ISOSAEReserved ISO保留 | U |
0x55 | reportWWHOBDDTCWithPermanentStatus 该参数指定了服务端应该发送给客户端带有"permanent DTC"状态的WWH OBD DTC列表 | U |
0x56 - 0x7F | ISOSAEReserved ISO保留 | U |
2.3 请求报文中数据参数定义
该服务在请求报文中的数据参数定义如下表所示:
定义 |
---|
DTCStatusMask DTCStatusMask包含DTC的8个状态位。请求报文中使用的该字节,允许客户端请求状态与DTCStatusMask相匹配的DTC信息。如果DTC实际状态位中的任何一个被设置为“1”,DTCStatusMask中相应的状态位也被设置为“1”,则DTC状态与DTCStatusMask相匹配(即,如果DTCStatusMask与DTC实际状态按位逻辑与,结果非零,则匹配已经发生)。如果客户端指定的状态掩码包含了服务端不支持的位,那么服务端将只使用它支持的位来处理DTC信息。 |
DTCMaskRecord [DTCHighByte, DTCMiddleByte, DTCLowByte] DTCMaskRecord是一个3个字节的值,包含了DTCHighByte, DTCMiddleByte 和 DTCLowByte,其组合在一起表示了服务端所支持的指定诊断故障码的唯一标识符。 3个字节的DTC编号的定义允许对DTC信息进行多种编码方式。 — 根据ISO 15031-6规范中使用的DTCHighByte, DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_00标识; — 根据ISO 14229部分使用的DTCHighByte, DTCMiddleByte和DTCLowByte的解码,ISO 14229没有指定任何的解码方式,因此允许车辆制造厂商去指定解码方式。该格式由DTCFormatIdentifier = ISO_14229-1_DTCFormat标识; — 根据SAE J1939-73技术规范使用的DTCHighByte, DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = SAE_J1939-73_DTCFormat标识; — 根据ISO 11992-4技术规范使用的DTCHighByte, DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = ISO_11992-4_DTCFormat标识; — 根据ISO 27145-2技术规范使用的DTCHighByte, DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = SAE_J2012-DA_WWH-OBD_DTCFormat标识; |
DTCSnapshotRecordNumber DTCSnapshotRecordNumber是一个字节值,表示了指定的DTCSnapshot数据记录的编号,其通过客户端定义的DTCMaskRecord,并设置子函数为reportDTCSnapshotByDTCNumber来请求。DTCSnapshot数据记录编号0x00应保留用于立法目的(如,OBD相关)。从0x01 到 0xFE范围内的DTCSnapshot数据记录编号值,是车辆制造厂商指定使用范围。)值0xFF表示请求客户端一次性去汇报所有存储的DTCSnapshot数据记录。 |
DTCStoredDataRecordNumber DTCStoredDataRecordNumber是一个字节值,表示了指定的DTCStoredDataRecord数据记录的编号,其通过子函数为reportDTCStoredDataByRecordNumber来请求。DTCStoredDataRecordNumber数据记录编号0x00应保留用于立法目的。从0x01 到 0xFE范围内的DTCStoredData数据记录编号值,是车辆制造厂商指定使用范围。值0xFF表示请求客户端一次性去汇报所有存储的DTCStoredData数据记录。 |
DTCExtDataRecordNumber DTCExtDataRecordNumber是一个字节值,表示了指定的DTCExtDataRecord记录的编号,客户端定义DTCMaskRecord,并通过子函数为reportDTCExtDataRecordByDTCNumber和reportDTCExtDataRecordByRecordNumber来请求。对于与排放相关的服务端(OBD兼容的ecu), DTCExtDataRecordNumber 0x00应保留以供将来OBD使用。 DTCExtDataRecordNumber保留如下范围: — 0x00由ISO/SAE保留; — 0x01 - 0x8F请求服务端汇报车辆制造厂商指定存储的DTCExtendedData记录; — 0x90 - 0xEF请求服务端汇报合法OBD存储的DTCExtendedData记录; — 0xF0 - 0xFD由ISO/SAE为将来在单个应答报文中以组形式汇报使用; — 0xFE请求客户端在单条应答报文中汇报所有的合法的OBD存储DTCExtendedData记录; — 0xFF请求客户端在单条应答报文中汇报所有的存储DTCExtendedData记录; |
DTCSeverityMaskRecord [DTCSeverityMask, DTCStatusMask] DTCSeverityMaskRecord是一个2字节值,包含了DTCSeverityMask和DTCStatusMask。 |
DTCSeverityMask DTCSeverityMask包含三个DTC严重性位。这三个位的定义可以在14229规范的D.3部分找到。这个字节在请求消息中使用,允许客户端请求严重性定义与DTCSeverityMask相匹配的DTC信息。如果DTC的任何一个实际的严重性位被设置为“1”,而且DTCSeverityMask中相应的严重性位也被设置为“1”,则定义为DTCSeverityMask的严重性与DTCSeverityMask匹配(即,如果DTCSeverityMask是按位逻辑与DTC的实际严重性和结果非零,则表示相匹配)。 |
FunctionalGroupIdentifier 在由许多不同ECU组成的电气体系结构中,会引入FunctionalGroupIdentifier来区分测试设备在不同功能系统组之间发送的命令。如果ECU安装了排放系统的软件,以及在I/M测试中可能被检测的其他系统,那么只汇报所要求的功能系统组的DTC信息是很重要的。一个I/M测试不应该因为另一个功能系统组存储了DTC信息而失败。FunctionalGroupIdentifiers在14229规范的D.5部分指定。 |
MemorySelection 当检索DTC时,该参数将用于寻址各自的用户定义的DTC内存。 |
3、肯定应答报文
3.1 肯定应答报文格式定义
0x19服务(ReadDTCInformation)应答报文的格式取决于子函数功能,以下子函数参数格式,其肯定应答报文定义见下表。
sub-function = reportNumberOfDTCByStatusMask
sub-function = reportNumberOfDTCBySeverityMaskRecord
sub-function = reportNumberOfMirrorMemoryDTCByStatusMask
sub-function = reportNumberOfEmissionsOBDDTCByStatusMask
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportNumberOfDTCByStatusMask reportNumberOfDTCBySeverityMaskRecord reportNumberOfMirrorMemoryDTCByStatusMask reportNumberOfEmissionsOBDDTCByStatusMask | M | 0x01 0x07 0x11 0x12 |
#3 | DTCStatusAvailabilityMask | M | 0x00 - 0xFF |
#4 | DTCFormatIdentifier = [ SAE_J2012-DA_DTCFormat_00 ISO_14229-1_DTCFormat SAE_J1939-73_DTCFormat ISO_11992-4_DTCFormat SAE_J2012-DA_DTCFormat_04 ] | M | 0x00 0x01 0x02 0x03 0x04 |
#5 #6 | DTCCount[] = [ DTCCountHighByte DTCCountHighByte | M M | 0x00 – 0xFF 0x00 – 0xFF |
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportDTCByStatusMask reportSupportedDTCs reportFirstTestFailedDTC reportFirstConfirmedDTC reportMostRecentTestFailedDTC reportMostRecentConfirmedDTC reportMirrorMemoryDTCByStatusMask reportEmissionsOBDDTCByStatusMask reportDTCWithPermanentStatus ] | M | 0x02 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x13 0x15 |
#3 | DTCStatusAvailabilityMask | M | 0x00 - 0xFF |
#4 #5 #6 #7 #8 #9 #10 #11 . . #n-3 #n-2 #n-1 #n | DTCAndStatusRecord[] = [ DTCHighByte#1 DTCMiddleByte#1 DTCLowByte#1 statusOfDTC#1 DTCHighByte#2 DTCMiddleByte#2 DTCLowByte#2 statusOfDTC#2 . . DTCHighByte#m DTCMiddleByte#m DTCLowByte#m statusOfDTC#m | C1 C1 C1 C1 C2 C2 C2 C2 . . C2 C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
C1:当DTC信息可汇报时,参数才会出现。
C2:当reportType = reportSupportedDTCs, reportDTCByStatusMask, reportMirrorMemoryDTCByStatusMask, reportEmissionsOBDDTCByStatusMask, reportDTCWithPermanentStatus,并且超过一个DTC信息可以汇报时,参数才会出现。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportDTCSnapshotIdentification ] | M | 0x03 |
#3 #4 #5 | DTCRecord[]#1 = [ DTCHighByte#1 DTCMiddleByte#1 DTCLowByte#1 ] | C1 C1 C1 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#6 | DTCSnapshotRecordNumber#1 | C1 | 0x00 - 0xFF |
. . | . . | . . | . . |
#n-3 #n-2 #n-1 | DTCRecord[]#m = [ DTCHighByte#m DTCMiddleByte#m DTCLowByte#m ] | C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#n | DTCSnapshotRecordNumber#m | C2 | 0x00 - 0xFF |
C1:DTCRecord和DTCSnapshotRecordNumber参数只有在至少一个DTCSnapshot记录可用时才会出现。
C2:DTCRecord和DTCSnapshotRecordNumber参数只有在多个DTCSnapshot记录可用时才会出现。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportDTCSnapshotRecordByDTCNumber ] | M | 0x04 |
#3 #4 #5 #6 | DTCAndStatusRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] | M M M M | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#7 | DTCSnapshotRecordNumber#1 | C1 | 0x00 - 0xFF |
#8 | DTCSnapshotRecordNumberOfIdentifiers#1 | C1 | 0x00 - 0xFF |
#9 #10 #11 . . # 11+(p-1) . . #r-(m-1)-2 #r-(m-1)-1 #r-(m-1) . . #r | DTCSnapshotRecord[]#1 = [ dataIdentifier#1 byte#1 (MSB) dataIdentifier#1 byte#2 (LSB) snapshotData#1 byte#1 . . snapshotData#1 byte#p . . dataIdentifier#w byte#1 (MSB) dataIdentifier#w byte#2 (LSB) snapshotData#w byte#1 . . snapshotData#w byte#m ] | C1 C1 C1 C1 C1 . . C2 C2 C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF |
. . | . . | . . | . . |
#t | DTCSnapshotRecordNumber#x | C3 | 0x00 - 0xFF |
#t+1 | DTCSnapshotRecordNumberOfIdentifiers#x | C3 | 0x00 - 0xFF |
#t+2 #t+3 #t+5 . . # t+5+(p-1) . . #n-(u-1)-2 #n-(u-1)-1 #n-(u-1) . . #n | DTCSnapshotRecord[]#x = [ dataIdentifier#1 byte#1 (MSB) dataIdentifier#1 byte#2 (LSB) snapshotData#1 byte#1 . . snapshotData#1 byte#p . . dataIdentifier#w byte#1 (MSB) dataIdentifier#w byte#2 (LSB) snapshotData#w byte#1 . . snapshotData#w byte#u ] | C3 C3 C3 C3 C3 . . C4 C4 C4 C4 C4 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF |
C1:在至少有一条DTCSnapshot记录可供汇报时,DTCSnapshotRecordNumber和DTCSnapshotRecord参数中的第一个dataIdentifier/snapshotData组合才会出现。
C2/C4:在单个DTCSnapshotRecord中,有多个dataIdentifier/snapshotData组合允许出现。例如,单个dataIdentifier只引用数据的一个完整部分的情况。当dataIdentifier引用一个数据块时,可以使用单个dataIdentifier/snapshotData组合。
C3:仅在请求报告所有记录(DTCSnapshotRecordNumber在请求中设置为0xFF)并且有多个记录可供报告时,DTCSnapshotRecordNumber和DTCSnapshotRecord参数中的第一个dataIdentifier/snapshotData组合才存在。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportDTCStoredDataByRecordNumber ] | M | 0x05 |
#3 | DTCStoredDataRecordNumber#1 | M | 0x00 - 0xFF |
#4 #5 #6 #7 | DTCAndStatusRecord[]#1 = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] | C1 C1 C1 C1 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#8 | DTCStoredDataRecordNumberOfIdentifiers#1 | C1 | 0x00 - 0xFF |
#9 #10 #11 . . # 11+(p-1) . . #r-(m-1)-2 #r-(m-1)-1 #r-(m-1) . . #r | DTCSnapshotRecord[]#1 = [ dataIdentifier#1 byte#1 (MSB) dataIdentifier#1 byte#2 (LSB) DTCstoredData#1 byte#1 . . DTCstoredData#1 byte#p . . dataIdentifier#w byte#1 (MSB) dataIdentifier#w byte#2 (LSB) DTCstoredData#w byte#1 . . DTCstoredData#w byte#m ] | C1 C1 C1 . . C1 . . C2 C2 C2 . . C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF |
. . | . . | . . | . . |
#t | DTCStoredDataRecordNumber#x | C3 | 0x00 - 0xFF |
#t+1 #t+2 #t+3 #t+4 | DTCAndStatusRecord[]#1 = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] | C3 C3 C3 C3 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#t+5 | DTCStoredDataRecordNumberOfIdentifiers#x | C3 | 0x00 - 0xFF |
#t+6 #t+7 #t+8 . . #t+8+(p-1) . . #n-(u-1)-2 #n-(u-1)-1 #n-(u-1) . . #n | DTCStoredDataRecord[]#x = [ dataIdentifier#1 byte#1 (MSB) dataIdentifier#1 byte#2 (LSB) DTCstoredData#1 byte#1 . . DTCstoredDataa#1 byte#p . . dataIdentifier#w byte#1 (MSB) dataIdentifier#w byte#2 (LSB) DTCstoredData#w byte#1 . . DTCstoredData#w byte#u ] | C3 C3 C3 . . C3 . . C4 C4 C4 . . C4 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF |
C1:只有在至少有一条DTCStoredData记录可供报告时,DTCStoredDataRecord参数中的DTCAndStatusRecord和第一个dataIdentifier/DTCStoredData组合才会出现。
C2/C4:在单个DTCStoredDataRecord中,有多个dataIdentifier/DTCStoredData组合允许出现。例如,单个dataIdentifier只引用数据的一个完整部分的情况。当dataIdentifier引用一个数据块时,可以使用单个dataIdentifier/DTCStoredData组合。
C3:仅在请求报告所有记录(DTCStoredDataRecordNumber在请求中设置为0xFF)并且有多个记录可供报告时,DTCSnapshotRecordNumber和DTCSnapshotRecord参数中的第一个dataIdentifier/DTCStoredData组合才存在。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportDTCExtDataRecordByDTCNumber reportMirrorMemoryDTCExtDataRecordByDTCNumber ] | M | 0x06 0x10 |
#3 #4 #5 #6 | DTCAndStatusRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] | M M M M | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#7 | DTCExtDataRecordNumber#1 | C1 | 0x00 - 0xFD |
#8 . . #8+(p-1) | DTCExtDataRecord[]#1 = [ extendedData#1 byte#1 . . extendedData#1 byte#p ] | C1 C1 C1 | 0x00 - 0xFF . . 0x00 - 0xFF |
. . | . . | . . | . . |
#t | DTCExtDataRecordNumber#x | C2 | 0x00 – 0xFD |
#t+1 . . #t+1+(q-1) | DTCExtDataRecord[]#x = [ extendedData#x byte#1 . . extendedData#x byte#q ] | C2 C2 C2 | 0x00 - 0xFF . . 0x00 - 0xFF |
C1:只有在至少有一个DTCExtDataRecord可用时,DTCExtDataRecord参数中的DTCExtDataRecord number和extendedData才会出现。
C2:在请求报告所有记录(DTCExtDataRecordNumber在请求中设置为0xFE或0xFF)并且有多条记录可供报告时,DTCExtDataRecord参数中的DTCExtDataRecordNumber和extendedData才存在。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportDTCBySeverityMaskRecord reportSeverityInformationOfDTC ] | M | 0x08 0x09 |
#3 | DTCStatusAvailabilityMask | M | 0x00 – 0xFF |
#4 #5 #6 #7 #8 #9 . . #n-5 #n-4 #n-3 #n-2 #n-1 #n | DTCAndSeverityRecord[] = [ DTCSeverity#1 DTCFunctionalUnit#1 DTCHighByte#1 DTCMiddleByte#1 DTCLowByte#1 statusOfDTC#1 . . DTCSeverity#m DTCFunctionalUnit#m DTCHighByte#m DTCMiddleByte#m DTCLowByte#m statusOfDTC#m ] | C1 C1 C1 C1 C1 C1 . . C2 C2 C2 C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
C1:在reportDTCBySeverityMaskRecord的情况下,如果至少有一个DTC与客户端定义的DTC严重性掩码相匹配,则必须存在此参数。在reportSeverityInformationOfDTC的情况下,如果服务端支持请求消息中指定的DTC,则必须存在此参数。
C2:在请求报告所有记录(DTCExtDataRecordNumber在请求中设置为0xFE或0xFF)并且有多条记录可供报告时,DTCExtDataRecord参数中的DTCExtDataRecordNumber和extendedData才存在。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportDTCFaultDetectionCounter] | M | 0x14 |
#3 #4 #5 #6 #7 #8 #9 #10 #n-3 #n-2 #n-1 #n | DTCFaultDetectionCounterRecord[] = [ DTCHighByte#1 DTCMiddleByte#1 DTCLowByte#1 DTCFaultDetectionCounter#1 DTCHighByte#2 DTCMiddleByte#2 DTCLowByte#2 DTCFaultDetectionCounter#2 . . DTCHighByte#2 DTCMiddleByte#2 DTCLowByte#2 DTCFaultDetectionCounter#2 ] | C1 C1 C1 C1 C2 C2 C2 C2 . . C2 C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x01 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x01 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x01 - 0xFF |
C1:至少一个DTC的DTCFaultDetectionCounter小于0x7F的正值时,该参数才会出现。
C2:只有当多个DTC的DTCFaultDetectionCounter的正值小于0x7F时,才会出现此参数记录。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportDTCExtDataRecordByRecordNumber] | M | 0x16 |
#3 | ReadDTCInformation Response SID | M | 0x00 – 0xEF |
#4 #5 #6 #7 | DTCFaultDetectionCounterRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] | C1 C1 C1 C1 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#8 . . ##8+(p-1) | DTCExtDataRecord[]#1= [ extendedData#1 byte#1 . . extendedData#1 byte#p ] | C1 . . C1 | 0x00 - 0xFF . . 0x00 - 0xFF |
. . | . . | . . | . . |
#t #t+1 #t+2 #t+3 | DTCAndStatusRecord[]#x = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] | C2 . . C2 | 0x00 - 0xFF . . 0x00 - 0xFF |
C1:至少有一个DTCExtDataRecord可用时,DTCAndStatusRecord和DTCExtDataRecord参数才会出现。
C2:在多个DTCExtDataRecord可用时,DTCAndStatusRecord和DTCExtDataRecord参数才会出现。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportUserDefMemoryDTCByStatusMask] | M | 0x17 |
#3 | MemorySelection | M | 0x00- 0xFF |
#4 | DTCStatusAvailabilityMask | M | 0x00- 0xFF |
#5 #6 #7 #8 #9 #10 #11 #12 . . #n-3 #n-2 #n-1 #n | DTCAndStatusRecord[] = [ DTCHighByte#1 DTCMiddleByte#1 DTCLowByte#1 statusOfDTC#1 DTCHighByte#2 DTCMiddleByte#2 DTCLowByte#2 statusOfDTC#2 . . DTCHighByte#m DTCMiddleByte#m DTCLowByte#m statusOfDTC#m ] | C1 C1 C1 C1 C2 C2 C2 C2 . . C2 C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x01 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x01 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x01 - 0xFF |
C1:这个参数只有在DTC信息可用时才会出现。
C2:这个参数只有在多个DTC信息可用时才会出现。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportUserDefMemoryDTCSnapshotRecordByDTCNumber ] | M | 0x18 |
#3 | MemorySelection | M | 0x00- 0xFF |
#4 #5 #6 #7 | DTCAndStatusRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] | M M M M | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x01 - 0xFF |
#8 | DTCSnapshotRecordNumber#1 | C1 | 0x00- 0xFF |
#9 | DTCSnapshotRecordNumberOfIdentifiers#1 | C1 | 0x00- 0xFF |
#10 #11 #12 . . #12+(p-1) . . #r-(m-1)-2 #r-(m-1)-1 #r-(m-1) . . #r | DTCSnapshotRecord[]#1 = [ dataIdentifier#1 byte#1 (MSB) dataIdentifier#1 byte#2 (LSB) snapshotData#1 byte#1 . . snapshotData#1 byte#p . . dataIdentifier#w byte#1 (MSB) dataIdentifier#w byte#2 (LSB) snapshotData#w byte#1 . . snapshotData#w byte#m ] | C3 C3 C3 C1 C1 . . C2 C2 C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF |
. . | . . | . . | . . |
#t | DTCSnapshotRecordNumber#x | C3 | 0x00- 0xFF |
#t+1 | DTCSnapshotRecordNumberOfIdentifiers#x | C3 | 0x00- 0xFF |
#t+2 #t+3 #t+5 . . #t+5+(p-1) . . #n-(u-1)-2 #n-(u-1)-1 #n-(u-1) . . #n | DTCSnapshotRecord[]#x = [ dataIdentifier#1 byte#1 (MSB) dataIdentifier#1 byte#2 (LSB) snapshotData#1 byte#1 . . snapshotData#1 byte#p . . dataIdentifier#w byte#1 (MSB) dataIdentifier#w byte#2 (LSB) snapshotData#w byte#1 . . snapshotData#w byte#u ] | C3 C3 C3 C3 C3 . . C4 C4 C4 C4 C4 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF |
C1:在至少有一条DTCSnapshot记录可供汇报时,DTCSnapshotRecordNumber和DTCSnapshotRecord参数中的第一个dataIdentifier/snapshotData组合只有才会出现。
C2/C4:有多个dataIdentifier/snapshotData组合允许出现在单个DTCSnapshotRecord中。例如,单个dataIdentifier只引用数据的一个完整部分的情况。当dataIdentifier引用一个数据块时,可以使用单个dataIdentifier/snapshotData组合。
C2/C4:DTCSnapshotRecordNumber和DTCSnapshotRecord参数中的第一个dataIdentifier/snapshotData组合仅在请求报告所有记录(DTCSnapshotRecordNumber在请求中设置为0xFF)并且有多个记录可供报告时才存在。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportUserDefMemoryDTCExtDataRecordByDTCNumber ] | M | 0x19 |
#3 | MemorySelection | M | 0x00 – 0xFF |
#4 #5 #6 #7 | DTCAndStatusRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] | M M M M | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
#8 | DTCExtDataRecordNumber#1 | C1 | 0x00-0xFE |
#9 . . #9+(p-1) | DTCExtDataRecord[]#1 = [ extendedData#1 byte#1 . . extendedData#1 byte#p ] | C1 C1 C1 | 0x00 - 0xFF . . 0x00 - 0xFF |
. . | . . | . . | . . |
#t+1 . . #t+1+(p-1) | DTCExtDataRecord[]#x = [ extendedData#x byte#1 . . extendedData#x byte#q ] | C2 C2 C2 | 0x00 - 0xFF . . 0x00 - 0xFF |
C1:DTCExtDataRecord参数中的DTCExtDataRecord number和extendedData只有在至少有一个DTCExtDataRecord可用时才会出现。
C2:DTCExtDataRecord参数中的DTCExtDataRecordNumber和extendedData仅在请求报告所有记录(DTCExtDataRecordNumber在请求中设置为0xFE或0xFF)并且有多条记录可供报告时才存在。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportWWHOBDDTCByMaskRecord ] | M | 0x42 |
#3 | FunctionalGroupIdentifier | M | 0x00 – 0xFF |
#4 | DTCStatusAvailabilityMask | M | 0x00 – 0xFF |
#5 | DTCSeverityAvailabilityMask | M | 0x00 – 0xFF |
#6 | DTCFormatIdentifier = [ SAE_J2012-DA_DTCFormat_04 SAE_J1939-73_DTCFormat ] | M | 0x04 0x02 |
#7 #8 #9 #10 #11 #12 . . #n-3 #n-2 #n-1 #n | DTCAndStatusRecord[] = [ DTCSeverity#1 DTCHighByte#1 (MSB) DTCMiddleByte#1 DTCLowByte#1 statusOfDTC#1 . . DTCSeverity#m DTCHighByte#m (MSB) DTCMiddleByte#m DTCLowByte#m statusOfDTC#m | C1 C1 C1 C1 C1 . . C2 C2 C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
C1:这个参数只有在DTC信息可用时才会出现。
C2:这个参数只有在多个DTC信息可用时才会出现。
以下子函数参数的格式,其肯定应答报文定义见下表。
字节序号 | 参数值 | 约定 | 字节值 |
---|---|---|---|
#1 | ReadDTCInformation Response SID | M | 0x59 |
#2 | reportType = [ reportWWHOBDDTCWithPermanentStatus ] | M | 0x55 |
#3 | FunctionalGroupIdentifier | M | 0x00 – 0xFF |
#4 | DTCStatusAvailabilityMask | M | 0x00 – 0xFF |
#5 | DTCFormatIdentifier = [ SAE_J2012-DA_DTCFormat_04 SAE_J1939-73_DTCFormat ] | M | 0x04 0x02 |
#6 #7 #8 #9 . . #n-3 #n-2 #n-1 #n | DTCAndStatusRecord[] = [ DTCHighByte#1 (MSB) DTCMiddleByte#1 DTCLowByte#1 statusOfDTC#1 . . DTCHighByte#m (MSB) DTCMiddleByte#m DTCLowByte#m statusOfDTC#m | C1 C1 C1 C1 . . C2 C2 C2 C2 | 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF . . 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF 0x00 - 0xFF |
C1:这个参数只有在DTC信息可用时才会出现。
C2:这个参数只有在多个DTC信息可用时才会出现。
3.2 肯定应答报文数据参数定义
下表指定了肯定应答报文中的数据参数。
定义 |
---|
reportType 该参数是来自客户端请求报文中提供的子函数参数的6 - 0位。 |
DTCAndSeverityRecord 该参数记录包含SAE_J2012-DA_DTCFormat_00、ISO_14229-1_DTCFormat、SAE_J1939-73_DTCFormat、ISO11992-4DTCFormat或SAE_J2012-DA_DTCFormat_04的DTCSeverity、DTCFunctionalUnit、DTCHighByte、DTCMiddleByte、DTCLowByte和statusOfDTC的一个或多个分组。 DTCSeverity识别了故障对车辆运行或系统功能的重要性,并允许向驾驶员显示建议的操作。DTCFuncitonalUnit是一个1字节的值,它标识了汇报DTC的相应的基本车辆/系统功能。DTCFunctionalUnit的定义应在相应的实施标准中规定。 DTCHighByte、DTCMiddleByte和DTCLowByte组合在一起,表示了服务端所支持的特定诊断故障代码的唯一标识号。DTCHighByte和DTCMiddleByte表示正在诊断的电路或系统。DTCLowByte表示电路或系统中的故障类型(例如,传感器开路,传感器接地短路,基于算法的故障等)。该定义可在ISO°15031-6规范中找到。 该参数记录包含了SAE_J1939-73_DTCFormat的DTCSeverity、DTCFunctionalUnit、SPN (Suspect parameter Number)、FMI (Failure Mode Identifier)和OC (Occurrence Counter) 的一个或多个分组。SPN、FMI和OC在SAE J1939中有定义。 |
DTCAndStatusRecord 该参数记录包含ISO_14229-1_DTCFormat、SAE_J2012-DA_DTCFormat_00、SAE_J1939-73_DTCFormat、SAE_J2012-DA_DTCFormat_04或ISO_11992-4_DTCFormat中DTCHighByte、DTCMiddleByte、DTCLowByte和statusOfDTC的一个或多个分组。SAE_J1939-73_DTCFormat支持SPN (Suspect Parameter Number)、FMI (Failure Mode Identifier)和OC (Occurrence Counter)参数。SPN、FMI和OC在SAE J1939中定义。 DTCHighByte、DTCMiddleByte和DTCLowByte一起表示服务端支持的特定诊断故障代码的唯一标识号。3个字节DTC数的编码可以通过以下方式完成: 根据ISO 15031-6规范,使用DTCHighByte、DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_00或者 根据ISO 14229-1规范,使用DTCHighByte、DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = ISO_14229-1_DTCFormat 或 根据SAE J1939-73规范,使用DTCHighByte、DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = ISO_14229-1_DTCFormat 根据ISO 11992-4规范,使用DTCHighByte、DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = ISO_11992-4_DTCFormat 根据ISO 27145-2规范,使用DTCHighByte、DTCMiddleByte和DTCLowByte的解码。该格式由DTCFormatIdentifier = SAE_2012-DA_WWHOBD_DTCFormat |
DTCRecord 该参数记录包含一组或多组的DTCHighByte、DTCMiddleByte和DTCLowByte。DTCRecord的解释取决于表中定义的DTCFormatIdentifier参数中所包含的值。 |
StatusOfDTC 特定DTC的状态(例如,此操作循环的测试失败,等等)。statusOfDTC字节中包含的位定义可以在本规范的D.2中找到。服务端不支持的位将报告为“0”。 |
DTCStatusAvailabilityMask 一个字节,它的位定义与statusOfDTC相同,并表示服务端支持的状态位。服务端不支持的位设置为“0”。每个支持的位(由值“1”表示)应该为服务端支持的每个DTC实现。 |
DTCFormatIdentifier 这个1字节参数值定义了服务端汇报的DTC格式。 — SAE_J2012-DA_DTCFormat_00:该参数值标识了由服务端汇报的DTC格式,该格式在ISO 15031-6规范中定义。 — ISO_14229-1_DTCFormat:该参数值标识了服务端汇报的DTC格式,在该表中由DTCAndStatusRecord参数定义。 — SAE_J1939-73_DTCFormat:该参数值标识了服务端汇报的DTC格式,该格式在SAE J1939-73规范中定义。 — ISO_11992-4_DTCFormat:该参数值标识了服务端汇报的DTC格式,该格式在ISO 11992-4规范中定义。 — SAE_J2012-DA_DTCFormat_04:该参数值标识了服务端汇报的DTC格式,该格式在ISO 27145-2规范中定义。 DTCFormatIdentifier字节中包含的字节值的定义可以在本规范的D.部分找到。一个给定的服务端应该只支持一个DTCFormatIdentifier。 |
DTCCount 这个2字节的参数共同引用了DTCCountHighByte和DTCCountLowByte的参数,这些参数是在响应reportNumberOfDTCByStatusMask或reportNumberOfMirrorMemoryDTC请求时发送的。DTCCount提供与客户端请求中定义的DTCStatusMask相匹配的DTC数量的计数。 |
DTCSnapshotRecordNumber 要么是客户端在reportDTCSnapshotRecordByDTCNumber请求中指定的DTCSnapshotRecordNumber参数,要么是存储DTCSnapshot记录的实际DTCSnapshotRecordNumber。 |
DTCSnapshotRecordNumberOfIdentifiers 这个单字节参数显示紧跟其后的DTCSnapshotRecord中的数据标识符的数量。值0x00应用于表示在相应的DTCSnapshotRecord中包含未定义数量的数据标识符(例如,主要用例是DTCSnapshotRecord包含超过255个数据标识符)。 |
DTCSnapshotRecord DTCSnapshotRecord包含从系统故障发生时的数据值快照。 |
DTCStoredDataRecord DTCStoredDataRecord包含系统故障发生时的数据值的冻结帧。 |
DTCStoredDataRecordNumber 要么是客户端在reportDTCStoredDataByRecordNumber请求中指定的DTCStoredDataRecordNumber参数,要么是存储的DTCStoredDataRecord的实际DTCStoredDataRecordNumber。 |
DTCStoredDataRecordNumberOfIdentifiers 这个单字节参数显示紧跟其后的DTCStoredDataRecord中的数据标识符的数量。 |
DTCExtDataRecordNumber 客户端在reportDTCExtDataRecordByDTCNumber或reportDTCExtDataRecordByRecordNumber请求中指定的DTCExtDataRecordNumber参数的回显,或者存储的DTCExtendedData记录的实际DTCExtDataRecordNumber。 |
DTCExtDataRecord DTCExtDataRecord是服务端的一个特定的信息块,它可能包含与DTC相关的扩展状态信息。DTCExtendedData包含DTC参数值,这些值在请求时已经确定。 |
DTCFaultDetectionCounterRecord DTCFaultDetectionCounterRecord是一条包含一个或多个DTC编号和DTC具体的DTCFaultDetectionCounter参数值的记录。 |
DTCFaultDetectionCounter DTCFaultDetectionCounter用于统计DTC的故障检测次数。 |
FunctionalGroupIdentifier 一个单字节标识符,包含与DTC相关的功能系统组,例如刹车、排放、乘员约束、轮胎充气、前/外照明等。数值在D.5中定义。 |
DTCSeverityAvailabilityMask 一个字节,其位定义与DTCSeverity相同,并表示服务端支持的严重性位。服务端不支持的位设置为“0”。 |
MemorySelection 该参数是来自客户端请求消息中提供的MemorySelection参数的回显。 |
4、支持的否定应答码(NRC_)
本服务实施了如下否定响应代码,下表记录了每个否定应答码发生的情况,如果服务端在错误场景使用了该服务,则应使用如下列出的否定响应码。
NRC | 描述 |
---|---|
0x12 | sub-functionNotSupported 如果不支持子功能参数,则发送此NRC。 |
0x13 | incorrectMessageLengthOrInvalidFormat 当消息长度不正确时,会发送该NRC |
0x31 | requestOutOfRange 当出现以下情况时,会发送该NRC: — 客户端指定了一个服务端无法识别的DTCMaskRecord; — 客户端指定的DTCSnapshotRecordNumber / DTCExtDataRecordNumber无效。注意,这与服务端支持的DTCSnapshotRecordNumber和DTCMaskRecord的组合或DTCExtDataRecordNumber和DTCMaskRecord组合的情况有所区别,但当前没有与之关联的数据(即,没有数据需要肯定应答); — 客户端指定了服务端无法识别的FunctionalGroupIdentifier; — MemorySelection标识符无法被服务端识别; |
5、0x19服务(ReadDTCInformation,读取故障码信息服务)案例说明
Example #1 - ReadDTCInformation, sub-function = reportNumberOfDTCByStatusMask
这个例子演示了子函数参数为reportNumberOfDTCByStatusMask的使用方法,其中已确认的DTC (DTC的状态掩码为0x08),以及各种屏蔽案例。此服务端的DTCStatusAvailabilityMask = 0x2F。
服务端总共支持三种DTC(为了简单起见),它们在客户端请求时具有以下状态:
假设DTC P0805-11,表示为离合器位置传感器电流短地,故障码状态位statusOfDTC为0x24,二进制为 0010 0100;
下表定义了故障码状态位statusOfDTC = 0x24的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试并未完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
假设DTC P0A9B-17,表示为混合动力电池传感器电压超限,故障码状态位statusOfDTC为0x26,二进制为 0010 0110;
下表定义了故障码状态位statusOfDTC = 0x26的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
假设DTC P2522-1F,表示为A/C请求B 线路中断,故障码状态位statusOfDTC为0x2F,二进制为 0010 1111;
下表定义了故障码状态位statusOfDTC = 0x2F的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 1 | 请求时刻,DTC已失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
在如下案例中,只有DTC P2522-1F 即A/C 请求“B” - 线路中断,状态掩码为0x2F,能够与客户端所定义的状态掩码0x08相匹配。即Bit7 = 1。下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCByStatusMask,请求消息流案例#1。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportNumberOfDTCByStatusMask, suppressPosRspMsgIndicationBit = FALSE | 0x01 |
#3 | DTCStatusMask | 0x08 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCByStatusMask,肯定应答报文案例#1。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportNumberOfDTCByStatusMask | 0x01 |
#3 | DTCStatusAvailabilityMask | 0x2F |
#4 | DTCFormatIdentifier = ISO_14229-1_DTCFormat | 0x01 |
#5 #6 | DTCCount [ DTCCountHighByte ] DTCCount [ DTCCountLowByte ] | 0x00 0x01 |
Example #2 - ReadDTCInformation, sub-function = reportDTCByStatusMask,matching DTCs returned
这个例子展示了子函数参数为reportDTCByStatusMask的使用方法,有不支持掩码位时不同的掩码匹配规则。这个例子也适用于子函数参数为reportMirrorMemoryDTCByStatusMask和子函数参数为reportUserDefMemoryDTCByStatusMask的情况,对存储在DTC镜像内存或用户自定义内存中的DTC,这种状态掩码的检查机制是不执行的。
假设服务端总共可以支持三种DTC(为了简单起见),它们在客户端请求时具有以下状态:
假设DTC P0A9B-17,表示为混合动力温度传感器 - 电流电压超限,故障码状态位statusOfDTC为0x24,二进制为 0010 0100;
下表定义了故障码状态位statusOfDTC = 0x24的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试并未完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
假设DTC P2522-1F,表示为混合动力电池传感器电压超限,故障码状态位statusOfDTC为0x26,二进制为 0010 0110;
下表定义了故障码状态位statusOfDTC = 0x26的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
假设DTC P2522-1F,表示为A/C请求B 线路中断,故障码状态位statusOfDTC为0x00,二进制为 0000 0000;
下表定义了故障码状态位statusOfDTC = 0x00的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 0 | 当前或者上一个操作循环,DTC未失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 0 | 自从上一次故障码被清除后,故障码从未失效 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
在如下案例中,只有DTC P0805-11 即离合器位置传感器短地,状态掩码为0x2F,二进制为 0010 1111;
下表定义了故障码状态位statusOfDTC = 0x2F的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 1 | 请求时刻,DTC已失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
在如下案例中,DTCs P0A9B-17 (0x0A9B17) 和 P0805-11 (0x080511)返回给客户端的请求。DTC P2522-1F (0x25221F)没有返回,是因其状态掩码为0x00与如下案例请求报文中定义的状态掩码0x84不匹配。服务端应该绕过那些它不支持的状态位的屏蔽。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,请求报文案例#2。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportDTCByStatusMask, suppressPosRspMsgIndicationBit = FALSE | 0x02 |
#3 | DTCStatusMask | 0x84 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,肯定应答报文案例#2。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCByStatusMask | 0x02 |
#3 | DTCStatusAvailabilityMask | 0x7F |
Example #3 - ReadDTCInformation, sub-function = reportDTCByStatusMask,no matching DTCs returned
这个例子展示了子函数参数为reportDTCByStatusMask的使用方法,在案例中没有DTC与客户端定义的DTCStatusMask相匹配的情况。
假设服务端总共可以支持两种DTC(为了简单起见),它们在客户端请求时具有以下状态:
假设DTC P2522-1F,表示为A/C请求“B” 线路中断,故障码状态位statusOfDTC为0x24,二进制为 0010 0100;
下表定义了故障码状态位statusOfDTC = 0x24的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试并未完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
假设DTC P0A9B-17,表示为混合动力温度传感器 - 电流电压超限,故障码状态位statusOfDTC为0x00,二进制为 0000 0000;
下表定义了故障码状态位statusOfDTC = 0x00的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 0 | 当前或者上一个操作循环,DTC未失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 0 | 自从上一次故障码被清除后,故障码从未失效 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
客户端请求服务端reportByStatusMask所有 bit 0 (TestFailed)设置为逻辑’ 1 '的DTC。
在如下案例中,以上没有一个DTC可以应答服务端的请求,因为没有一个DTC在请求时刻已经失效了。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,请求报文案例#3。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportDTCByStatusMask, suppressPosRspMsgIndicationBit = FALSE | 0x02 |
#3 | DTCStatusMask | 0x01 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,肯定应答报文案例#3。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCByStatusMask | 0x02 |
#3 | DTCStatusAvailabilityMask | 0x7F |
Example #4 - ReadDTCInformation, sub-function = reportDTCSnapshotIdentification
这个例子展示了子函数参数为reportDTCSnapshotIdentification的使用方法。
有如下假设:
— 服务端有能力支持对给定的DTC存储两条DTCSnapshot记录;
— 服务端应该表明两条DTCSnapshot记录是为当前编号为0x123456的DTC存储的。出于本例的目的,假设该DTC发生了三次(由于服务端缺乏存储空间,因此只存储第一个和最近的DTCSnapshot记录);
— 所有的DTCSnapshot都按升序存储;
在如下案例中,有3个DTCSnapshot记录应答了客户端的请求。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCSnapshotIdentification,请求报文案例#4。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportDTCSnapshotIdentification, suppressPosRspMsgIndicationBit = FALSE | 0x03 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCSnapshotIdentification,肯定应答报文案例#4。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCSnapshotIdentification | 0x03 |
#3 #4 #5 #6 | DTCAndStatusRecord#1 [ DTCHighByte ] DTCAndStatusRecord#1 [ DTCMiddleByte ] DTCAndStatusRecord#1 [ DTCLowByte ] DTCSnapshotRecordNumber#1 | 0x12 0x34 0x56 0x01 |
#7 #8 #9 #10 | DTCAndStatusRecord#2 [ DTCHighByte ] DTCAndStatusRecord#2 [ DTCMiddleByte ] DTCAndStatusRecord#2 [ DTCLowByte ] DTCSnapshotRecordNumber#2 | 0x12 0x34 0x56 0x02 |
#11 #12 #13 #14 | DTCAndStatusRecord#3 [ DTCHighByte ] DTCAndStatusRecord#3 [ DTCMiddleByte ] DTCAndStatusRecord#3 [ DTCLowByte ] DTCSnapshotRecordNumber#3 | 0x78 0x9A 0xBC 0x01 |
Example #5 - ReadDTCInformation, sub-function = reportDTCSnapshotRecord-ByDTCNumber
这个例子展示了子函数参数为reportDTCSnapshotRecordByDTCNumber的使用方法。这个例子也适用于子函数参数为reportUserDefMemory- DTCSnapshotRecordByDTCNumber,只不过检查是使用存储在用户自定义内存中的DTC执行的。
有如下假设:
— 服务端有能力支持对给定的DTC存储两条DTCSnapshot记录;
— 此示例之前案例的延续;
— 假设服务端请求的是存储的编号为0x123456的DTC对应两条DTCSnapshot记录的第二个;
— 假设DTC为0x123456,其状态掩码为0x24,每次故障码发生时以下的环境数据会被捕获到;
— DTCSnapshot记录数据通过DID 0x4711被引用;
下表记录了DTCSnapshot记录的内容:
Data Byte | DTCSnapshot Record Contents | Byte Value |
---|---|---|
#1 | DTCSnapshotRecord [ data#1 ] = ECT (Engine Coolant Temperature) | 0xA6 |
#2 | DTCSnapshotRecord [ data#2 ] = TP (Throttle Position) | 0x66 |
#3 | DTCSnapshotRecord [ data#3 ] = RPM (Engine Speed) | 0x07 |
#4 | DTCSnapshotRecord [ data#4 ] = RPM (Engine Speed) | 0x50 |
#5 | DTCSnapshotRecord [ data#5 ] = MAP (Manifold Absolute Pressure) | 0x20 |
在如下案例中,根据客户端的reportDTCSnapshotRecordByDTCNumber请求,一条DTCSnapshot记录被返回。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCSnapshotRecordByDTCNumber,请求报文案例#5。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportDTCSnapshotRecordByDTCNumber, suppressPosRspMsgIndicationBit = FALSE | 0x04 |
#3 #4 #5 | DTCMaskRecord [ DTCHighByte ] DTCMaskRecord [ DTCMiddleByte ] DTCMaskRecord [ DTCLowByte ] | 0x12 0x34 0x56 |
#6 | DTCSnapshotRecordNumber | 0x02 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCSnapshotRecordByDTCNumber,肯定应答报文案例#5。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCSnapshotRecordByDTCNumber | 0x04 |
#3 #4 #5 #6 | DTCAndStatusRecord#1 [ DTCHighByte ] DTCAndStatusRecord#1 [ DTCMiddleByte ] DTCAndStatusRecord#1 [ DTCLowByte ] DTCSnapshotRecordNumber#1 | 0x12 0x34 0x56 0x24 |
#7 | DTCSnapshotRecordNumber | 0x02 |
#8 | DTCSnapshotRecordNumberOfIdentifiers | 0x01 |
#9 | dataIdentifier [ byte#1 ] (MSB) | 0x47 |
#10 | dataIdentifier [ byte#2 ] (LSB) | 0x11 |
#11 #12 #13 #14 #15 | DTCSnapshotRecord [ data#1 ] = ECT DTCSnapshotRecord [ data#2 ] = TP DTCSnapshotRecord [ data#3 ] = RPM DTCSnapshotRecord [ data#4 ] = RPM DTCSnapshotRecord [ data#5 ] = MAP | 0xA6 0x66 0x07 0x50 0x20 |
Example #6 - ReadDTCInformation, sub-function = reportDTCStoredDataByRecordNumber
这个例子展示了子函数参数为reportDTCStoredDataByRecordNumber的使用方法。
有如下假设:
— 对给定DTC,服务端有能力支持存储两条DTCStoredDataRecords;
— 此示例假设是前一个示例的延续;
— 对于0x123456的DTC,假设服务端请求的是服务端存储的两条DTCStoredDataRecords的第二个;
— 假设DTC为0x123456,其状态掩码为0x24,每次故障码发生时以下的环境数据会被捕获到;
— DTCStoredData记录数据通过DID 0x4711被引用;
下表定义了DTCStoredData记录的内容:
Data Byte | DTCSnapshot Record Contents | Byte Value |
---|---|---|
#1 | DTCStoredDatatRecord [ data#1 ] = ECT (Engine Coolant Temperature) | 0xA6 |
#2 | DTCStoredDatatRecord [ data#2 ] = TP (Throttle Position) | 0x66 |
#3 | DTCStoredDatatRecord [ data#3 ] = RPM (Engine Speed) | 0x07 |
#4 | DTCStoredDatatRecord [ data#4 ] = RPM (Engine Speed) | 0x50 |
#5 | DTCStoredDatatRecord [ data#5 ] = MAP (Manifold Absolute Pressure) | 0x20 |
在如下案例中,请求了DTCStoredDatatRecord记录编号2,服务端返回了DTC和DTCStoredData的记录内容。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCStoredDataByRecordNumber,请求报文案例#6。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportDTCStoredDataByRecordNumber, suppressPosRspMsgIndicationBit = FALSE | 0x05 |
#3 | DTCStoredDataRecordNumber | 0x02 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCStoredDataByRecordNumber,肯定应答报文案例#6。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCStoredDataByRecordNumber | 0x05 |
#3 | DTCStoredDataRecordNumber | 0x02 |
#4 #5 #6 #7 | DTCAndStatusRecord [ DTCHighByte ] DTCAndStatusRecord [ DTCMiddleByte ] DTCAndStatusRecord [ DTCLowByte ] DTCSnapshotRecordNumber | 0x12 0x34 0x56 0x24 |
#8 | DTCStoredDataRecordNumberOfIdentifiers | 0x01 |
#9 | dataIdentifier [ byte#1 ] (MSB) | 0x47 |
#10 | dataIdentifier [ byte#2 ] (LSB) | 0x11 |
#11 #12 #13 #14 #15 | DTCSnapshotRecord [ data#1 ] = ECT DTCSnapshotRecord [ data#2 ] = TP DTCSnapshotRecord [ data#3 ] = RPM DTCSnapshotRecord [ data#4 ] = RPM DTCSnapshotRecord [ data#5 ] = MAP | 0xA6 0x66 0x07 0x50 0x20 |
Example #7 - ReadDTCInformation, sub-function = reportDTCExtDataRecordByDTCNumber
这个例子展示了子函数参数为reportDTCStoredDataByRecordNumber的使用方法。这个案例也同样适用于子函数参数为reportUserDefMemoryDTCExtDataRecordByDTCNumber,只不过检查是用存储在用户定义内存中的DTC执行的。
有如下假设:
— 对给定DTC,服务端有能力支持存储两条DTCExtendedData;
— 对于0x123456的DTC,服务端可以获取存储在服务端中所有可获得的DTCExtendedData记录;
— 假设DTC为0x123456,其状态掩码为0x24,以下的扩展数据对于此DTC都是可获得的;
— DTCExtendedData通过DTCExtDataRecordNumbers 0x05和0x10引用;
DTCExtDataRecordNumber为0x05的内容:
Data Byte | DTCExtDataRecord Contents for DTCExtDataRecordNumber 0x05 | Byte Value |
---|---|---|
#1 | 暖机循环计数 – 自从DTC命令MIL灯关闭以来,暖机循环的次数 | 0x17 |
DTCExtDataRecordNumber为0x10的内容:
Data Byte | DTCExtDataRecord Contents for DTCExtDataRecordNumber 0x10 | Byte Value |
---|---|---|
#1 | 故障码失效检测计数 – 每次故障码测试检测到了故障时会增加,测试汇报无故障时会降低 | 0x17 |
在如下案例中,客户端请求了一个DTCMaskRecord,其中包含了DTC码和一个值为0xFF的DTCExtDataRecordNumber(汇报所有的DTCExtDataRecords)。服务端返回了两条DTCExtDataRecords,其已经被客户端提交的DTC码记录下来。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCExtDataRecordByDTCNumber,请求报文案例#7。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportDTCExtDataRecordByDTCNumber, suppressPosRspMsgIndicationBit = FALSE | 0x06 |
#3 #4 #5 | DTCMaskRecord [ DTCHighByte ] DTCMaskRecord [ DTCMiddleByte ] DTCMaskRecord [ DTCLowByte ] | 0x12 0x34 0x56 |
#6 | DTCExtDataRecordNumber | 0xFF |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCExtDataRecordByDTCNumber,肯定应答报文案例#7。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCExtDataRecordByDTCNumber | 0x06 |
#3 #4 #5 #6 | DTCAndStatusRecord [ DTCHighByte ] DTCAndStatusRecord [ DTCMiddleByte ] DTCAndStatusRecord [ DTCLowByte ] DTCAndStatusRecord [ statusOfDTC ] | 0x12 0x34 0x56 0x24 |
#7 | DTCExtDataRecordNumber | 0x05 |
#8 | DTCExtDataRecord [ byte#1 ] | 0x17 |
#10 | DTCExtDataRecord [ byte#1 ] | 0x10 |
#11 | DTCExtDataRecord [ byte#1 ] | 0x79 |
Example #8 - ReadDTCInformation, sub-function = reportNumberOfDTCBySeverityMaskRecord
这个例子展示了子函数参数为reportNumberOfDTCBySeverityMaskRecord的使用方法。
当客户端请求时,服务端支持3个有以下状态的DTC。
假设有DTC 0x0A9B17,表示动力电池温度传感器电压超限,其状态为0x24(二进制为0010 0100),DTCFunctionalUnit = 0x10,DTCSeverity = 0x20:
下表定义了故障码状态位statusOfDTC = 0x24的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试并未完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
假设有DTC 0x25221F,表示A/C线路中断,其状态为0x00(二进制为0000 0000),DTCFunctionalUnit = 0x10,DTCSeverity = 0x20:
下表定义了故障码状态位statusOfDTC = 0x00的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 0 | 当前或者上一个操作循环,DTC未失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 0 | 自从上一次故障码被清除后,故障码从未失效 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
假设有DTC 0x080511,表示离合器位置传感器短地,其状态为0x2F(二进制为0010 1111),DTCFunctionalUnit = 0x10,DTCSeverity = 0x40:
下表定义了故障码状态位statusOfDTC = 0x00的含义:
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 1 | 请求时刻,DTC已失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
在如下案例中,由于DTC 0x080511与客户端定义的严重性掩码记录0xC001(DTCSeverityMask = 0xC0,DTCStatusMask = 0x01)相匹配。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCBySeverityMaskRecord,请求报文案例#8。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportNumberOfDTCBySeverityMaskRecord, suppressPosRspMsgIndicationBit = FALSE | 0x07 |
#3 | DTCSeverityMaskRecord(DTCSeverityMask) | 0xC0 |
#4 | DTCSeverityMaskRecord(DTCStatusMask) | 0x01 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCBySeverityMaskRecord,肯定应答报文案例#8。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportNumberOfDTCBySeverityMaskRecord | 0x07 |
#3 | DTCStatusAvailabilityMask | 0x09 |
#4 | DTCFormatIdentifier = ISO_14229-1_DTCFormat | 0x01 |
#5 | DTCCount [ DTCCountHighByte ] | 0x00 |
#6 | DTCCount [ DTCCountLowByte ] | 0x01 |
Example #9 - ReadDTCInformation, sub-function = reportDTCBySeverityMaskRecord
在如下案例中,由于DTC 0x080511与客户端定义的严重性掩码记录0xC001(DTCSeverityMask = 0xC0,DTCStatusMask = 0x01)相匹配,DTC 0x080511被汇报给客户端。DTC 0x080511的严重性为0x40(01xx xxxx)。服务端支持所有用于屏蔽目的的状态位,除了bit7代表的“warningIndicatorRequested”。注意:只有严重性掩码的bit7 到 bit5是有效的。
在如下案例中,一条DTCSeverityRecord应答了客户端的请求。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCBySeverityMaskRecord,请求报文案例#9。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportDTCBySeverityMaskRecord, suppressPosRspMsgIndicationBit = FALSE | 0x08 |
#3 | DTCSeverityMaskRecord(DTCSeverityMask) | 0xC0 |
#4 | DTCSeverityMaskRecord(DTCStatusMask) | 0x01 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCBySeverityMaskRecord,肯定应答报文案例#9。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCBySeverityMaskRecord | 0x08 |
#3 | DTCStatusAvailabilityMask | 0x7F |
#4 | DTCSeverityRecord#1 [ DTCSeverity ] | 0x40 |
#5 | DTCSeverityRecord#1 [ DTCFunctionalUnit ] | 0x10 |
#6 #7 #8 #9 | DTCAndStatusRecord [ DTCHighByte ] DTCAndStatusRecord [ DTCMiddleByte ] DTCAndStatusRecord [ DTCLowByte ] DTCAndStatusRecord [ statusOfDTC ] | 0x80 0x05 0x11 0x2F |
Example #10 - ReadDTCInformation, sub-function = reportSeverityInformationOfDTC
这个例子展示了子函数参数为reportSeverityInformationOfDTC的使用方法。
在如下案例中,由于DTC 0x080511与客户端定义的掩码记录0xC001(DTCSeverityMask = 0xC0,DTCStatusMask = 0x01)相匹配,DTC 0x080511被汇报给客户端。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportSeverityInformationOfDTC,请求报文案例#10。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportSeverityInformationOfDTC, suppressPosRspMsgIndicationBit = FALSE | 0x09 |
#3 | DTCMaskRecord [ DTCHighByte ] | 0x08 |
#4 | DTCMaskRecord [ DTCMiddleByte ] | 0x05 |
#5 | DTCMaskRecord [ DTCLowByte ] | 0x11 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportSeverityInformationOfDTC,肯定应答报文案例#10。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCBySeverityMaskRecord | 0x09 |
#3 | DTCStatusAvailabilityMask | 0x7F |
#4 | DTCSeverityRecord [ DTCSeverity ] | 0x40 |
#5 | DTCSeverityRecord [ DTCFunctionalUnit ] | 0x10 |
#6 | DTCSeverityRecord [ DTCHighByte ] | 0x08 |
#7 | DTCSeverityRecord [ DTCMiddleByte ] | 0x05 |
#8 | DTCSeverityRecord [ DTCLowByte ] | 0x11 |
#9 | DTCSeverityRecord [ statusOfDTC ] | 0x2F |
Example #11 - ReadDTCInformation, sub-function = reportSupportedDTCs
这个例子展示了子函数参数为reportSupportedDTCs的使用方法。
本案例中假设如下:
— 服务端支持三种DTC(为了简单起见),在客户端请求时刻有如下状态。
— DTC 0x123456,其状态为0x24(0010 0100)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试并未完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
DTC 0x123456,其状态为0x00(0000 0000)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 1 | 请求时刻,DTC已失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
DTC 0xABCD01,其状态为0x2F(0010 1111)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 1 | 请求时刻,DTC已失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
如下案例中,以上3个DTC都可被客户端返回。下表定义了读取故障码信息服务,子函数设置为sub-function = reportSupportedDTCs,请求报文案例#11。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportSupportedDTCs, suppressPosRspMsgIndicationBit = FALSE | 0x0A |
下表定义了读取故障码信息服务,子函数设置为sub-function = readSupportedDTCs,肯定应答报文案例#11。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = readSupportedDTCs | 0x0A |
#3 | DTCStatusAvailabilityMask | 0x7F |
#4 #5 #6 #7 | DTCAndStatusRecord#1 [ DTCHighByte ] DTCAndStatusRecord#1 [ DTCMiddleByte ] DTCAndStatusRecord#1 [ DTCLowByte ] DTCAndStatusRecord#1 [ statusOfDTC ] | 0x12 0x34 0x56 0x24 |
#8 #9 #10 #11 | DTCAndStatusRecord#2 [ DTCHighByte ] DTCAndStatusRecord#2 [ DTCMiddleByte ] DTCAndStatusRecord#2 [ DTCLowByte ] DTCAndStatusRecord#2 [ statusOfDTC ] | 0x23 0x45 0x05 0x00 |
#12 #13 #14 #15 | DTCAndStatusRecord#3 [ DTCHighByte ] DTCAndStatusRecord#3 [ DTCMiddleByte ] DTCAndStatusRecord#3 [ DTCLowByte ] DTCAndStatusRecord#3 [ statusOfDTC ] | 0xAB 0xCD 0x01 0x2F |
Example #12 - ReadDTCInformation, sub-function = reportFirstTestFailedDTC,information available
这个例子展示了子函数参数为reportFirstTestFailedDTC的使用方法,假设自从上次请求清除故障信息以来,至少有一个失效的DTC发生。
自从上次请求清除故障信息以来,确实只有一个失效DTC发生,那么服务端请求reportMostRecentTestFailedDTC会返回同样的信息。
在这个案例中,响应reportFirstTestFailedDTC返回的DTC状态在请求时不再是当前状态(在请求服务端汇报最近失效/确认的DTC,会发生同样的现象。)
在如下案例中,请求/应答的总体格式也可以应用到子函数参数为reportFirstConfirmedDTC,reportMostRecentTestFailedDTC,reportMostRecentConfirmedDTC。
本案例中假设如下:
— 自从上次请求清除故障信息以来,至少有一个失效DTC发生。
— 出于屏蔽目的,服务端支持所有的状态位。
— 自上次故障码清除以来,DTC 0x123456为检测到的第一个失效的DTC。
— DTC 0x123456,状态为0x26。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试并未完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
如下案例中,DTC 0x123456可被客户端返回。下表定义了读取故障码信息服务,子函数设置为reportFirstTestFailedDTC,请求报文案例#12。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportFirstTestFailedDTC, suppressPosRspMsgIndicationBit = FALSE | 0x0B |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportFirstTestFailedDTC,肯定应答报文案例#12。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportFirstTestFailedDTC | 0x0B |
#3 | DTCStatusAvailabilityMask | 0xFF |
#4 #5 #6 #7 | DTCAndStatusRecord#1 [ DTCHighByte ] DTCAndStatusRecord#1 [ DTCMiddleByte ] DTCAndStatusRecord#1 [ DTCLowByte ] DTCAndStatusRecord#1 [ statusOfDTC ] | 0x12 0x34 0x56 0x26 |
Example #13 - ReadDTCInformation, sub-function = reportFirstTestFailedDTC,no information available
这个例子展示了子函数参数为reportFirstTestFailedDTC的使用方法,假设自从上次请求清除故障信息以来,没有一个失效的DTC发生。
在如下案例中,请求/应答的总体格式也可以应用到子函数参数为reportFirstConfirmedDTC,reportMostRecentTestFailedDTC,reportMostRecentConfirmedDTC。
本案例中假设如下:
— 自从上次请求清除故障信息以来,没有一个失效DTC发生。
— 出于屏蔽目的,服务端支持所有的状态位。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC并未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试并未完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
如下案例中,DTC 0x123456可被客户端返回。下表定义了读取故障码信息服务,子函数设置为reportFirstTestFailedDTC,请求报文案例#13。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportFirstTestFailedDTC, suppressPosRspMsgIndicationBit = FALSE | 0x0B |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportFirstTestFailedDTC,肯定应答报文案例#13。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportFirstTestFailedDTC | 0x0B |
#3 | DTCStatusAvailabilityMask | 0xFF |
Example #14 - ReadDTCInformation, sub-function = reportNumberOfEmissionsOBDDTCByStatusMask
这个例子展示了子函数参数为reportNumberOfEmissionsOBDDTCByStatusMask的使用方法,和不同的屏蔽规则。
出于屏蔽目的,服务端支持所有的状态位。服务端支持三种与排放相关的OBD DTC(出于简单考虑),在客户端请求时有如下的状态。
与排放相关的 OBD DTC P0005-00 燃油关闭阀控制开路(0x000500),其状态位为0xAE(1010 1110)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 1 | 服务端请求指示灯点亮 |
与排放相关的 OBD DTC P022F-00 内部冷却器旁路控制电流过高 (0x022F00),其状态位为0xAC(1010 1100)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 请求时刻,DTC并未失效 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已完成 |
warningIndicatorRequested | 7 | 1 | 服务端请求指示灯点亮 |
与排放相关的 OBD DTC P0A09-00 DCDC转换器状态电流过低 (0x0A0900),其状态位为0xAF(1010 1111)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 1 | 请求时刻,DTC已失效 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 自从上一次故障码被清除后,一次完整的DTC测试已完成 |
testFailedSinceLastClear | 5 | 1 | 自从上一次故障码被清除后,故障码至少失效一次 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已完成 |
warningIndicatorRequested | 7 | 1 | 服务端请求指示灯点亮 |
如下案例中,总计数量3被客户端返回,因为所有的DTC与客户端定义的状态掩码0x08(0000 1000)相匹配。下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfEmissionsOBD-DTCByStatusMask,肯定应答报文案例#14。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportNumberOfEmissionsOBDDTCByStatusMask, suppressPosRspMsgIndicationBit = FALSE | 0x12 |
#3 | DTCStatusMask | 0x08 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfEmissionsOBD-DTCByStatusMask,肯定应答报文案例#14。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportNumberOfEmissionsOBDDTCByStatusMask | 0x12 |
#3 | DTCStatusAvailabilityMask | 0xFF |
#4 | DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_00 | 0x00 |
#5 #6 | DTCCount [ DTCCountHighByte ] DTCCount [ DTCCountLowByte ] | 0x00 0x03 |
Example #15 - ReadDTCInformation, sub-function = reportEmissionsOBDDTCByStatusMask,all matching OBD DTCs returned
这个例子展示了子函数参数为reportEmissionsOBDDTCByStatusMask的使用方法,和不同的屏蔽规则。
出于屏蔽目的,服务端支持所有的状态位。服务端支持三种DTC(出于简单考虑)。
在以下案例中,与排放相关的 OBD DTC P0005-AE 燃油关闭阀控制开路(0x000500),DTC P022F-00 内部冷却器旁路控制电流过高 (0x022F00),DTC P0A09-00 DCDC转换器状态电流过低 (0x0A0900)被返回给客户端的请求,因为所有的DTC与客户端定义的状态掩码0x80(1000 0000)相匹配。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportEmissionsOBDDTCByStatusMask,肯定应答报文案例#15。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportEmissionsOBDDTCByStatusMask, suppressPosRspMsgIndicationBit = FALSE | 0x13 |
#3 | DTCStatusMask | 0x80 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,肯定应答报文案例#15。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportEmissionsOBDDTCByStatusMask | 0x13 |
#3 | DTCStatusAvailabilityMask | 0xFF |
#4 #5 #6 #7 | DTCAndStatusRecord#1 [ DTCHighByte ] DTCAndStatusRecord#1 [ DTCMiddleByte ] DTCAndStatusRecord#1 [ DTCLowByte ] DTCAndStatusRecord#1 [ statusOfDTC ] | 0x00 0x05 0x00 0xAE |
#8 #9 #10 #11 | DTCAndStatusRecord#2 [ DTCHighByte ] DTCAndStatusRecord#2 [ DTCMiddleByte ] DTCAndStatusRecord#2 [ DTCLowByte ] DTCAndStatusRecord#2 [ statusOfDTC ] | 0x02 0x2F 0x00 0xAC |
#12 #13 #14 #15 | DTCAndStatusRecord#3 [ DTCHighByte ] DTCAndStatusRecord#3 [ DTCMiddleByte ] DTCAndStatusRecord#3 [ DTCLowByte ] DTCAndStatusRecord#3 [ statusOfDTC ] | 0x0A 0x09 0x00 0xAF |
Example #16 - ReadDTCInformation, sub-function = reportEmissionsOBDDTCByStatusMask(confirmedDTC and warningIndicatorRequested),matching DTCs returned
这个例子展示了子函数参数为reportEmissionsOBDDTCByStatusMask的使用方法和屏蔽规则:请求服务端去汇报排放相关的并且状态为"confirmedDTC"和"warningIndicatorRequested (MIL = ON)“和不支持的掩码位的OBD DTC。
出于屏蔽目的,服务端不支持bit 0 (testFailed),bit 4 (testNotCompletedSinceLastClear)和bit 5(testFailedSinceLastClear),因此DTCStatusAvailabilityMask的值为0xCE (1100 1110)。
客户端使用DTC状态掩码值为0x88 (1000 1000),因为只有状态"confirmedDTC = 1” 和 "warningIndicatorRequested = 1"的DTC应该被展示给技术人员。服务端出于简化考虑支持总共三个DTC,其在客户端请求时有如下状态:
DTC P010A-14 质量或体积空气流量 - 短地或开路(0x010A14),其状态为0x00(0000 0000)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 未应用 |
testFailedThisOperationCycle | 1 | 0 | 当前操作循环,DTC从未失效 |
pendingDTC | 2 | 0 | 当前或者上一个操作循环,DTC未失效 |
confirmedDTC | 3 | 0 | 请求时刻,DTC未确认 |
testNotCompletedSinceLastClear | 4 | 0 | 未应用 |
testFailedSinceLastClear | 5 | 0 | 未应用 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 0 | 服务端没有请求指示灯点亮 |
DTC P0180-17 油液温度传感器 - 电压超限(0x018017),其状态为0x8E(1000 1110)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 未应用 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 未应用 |
testFailedSinceLastClear | 5 | 0 | 未应用 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 1 | 服务端没有请求指示灯点亮 |
DTC P0190-1D 燃油轨压力传感器 - 电流超限(0x01901D),其状态为0x8E(1000 1110)。
statusOfDTC: bit field name | Bit # | Bit state | Description |
---|---|---|---|
testFailed | 0 | 0 | 未应用 |
testFailedThisOperationCycle | 1 | 1 | 当前操作循环,DTC已失效 |
pendingDTC | 2 | 1 | 当前或者上一个操作循环,DTC失效 |
confirmedDTC | 3 | 1 | 请求时刻,DTC已确认 |
testNotCompletedSinceLastClear | 4 | 0 | 未应用 |
testFailedSinceLastClear | 5 | 0 | 未应用 |
testNotCompletedThisOperationCycle | 6 | 0 | 这个操作循环,DTC测试已经完成 |
warningIndicatorRequested | 7 | 1 | 服务端没有请求指示灯点亮 |
在如下案例中,P0180-17 (0x018017) 和 P0190-1D (0x01901D)被返回给客户端的请求。
下表定义了读取故障码信息服务,子函数设置为sub-function = reportEmissionsOBDDTCByStatusMask,肯定应答报文案例#16。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportEmissionsOBDDTCByStatusMask, suppressPosRspMsgIndicationBit = FALSE | 0x13 |
#3 | DTCStatusMask | 0x88 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,肯定应答报文案例#16。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportEmissionsOBDDTCByStatusMask | 0x13 |
#3 | DTCStatusAvailabilityMask | 0xCE |
#8 #9 #10 #11 | DTCAndStatusRecord#1 [ DTCHighByte ] DTCAndStatusRecord#1 [ DTCMiddleByte ] DTCAndStatusRecord#1 [ DTCLowByte ] DTCAndStatusRecord#1 [ statusOfDTC ] | 0x01 0x80 0x17 0x8E |
#12 #13 #14 #15 | DTCAndStatusRecord#2 [ DTCHighByte ] DTCAndStatusRecord#2 [ DTCMiddleByte ] DTCAndStatusRecord#2 [ DTCLowByte ] DTCAndStatusRecord#2 [ statusOfDTC ] | 0x01 0x90 0x1D 0x8E |
Example #17 - ReadDTCInformation, sub-function = reportDTCExtDataRecordByRecordNumber
这个例子展示了子函数参数为reportDTCExtDataRecordByRecordNumber的使用方法。
有如下假设:
a) 服务端有能力支持存储两个DTCExtendedData记录,对于所有的DTC;
b) 对于Record number 0x05,假设服务端请求所有可获得的DTCExtendedData记录;
c) 假设DTC 0x123456,其状态为0x24,并且以下扩展数据可被DTC获取;
d) DTCExtendedData通过DTCExtDataRecordNumber 0x05引用;
e) 假设DTC 0x234561,其状态为0x24,并且以下扩展数据可被DTC获取;
f) DTCExtendedData通过DTCExtDataRecordNumber 0x05引用;
DTCExtDataRecordNumber 0x05 content for DTC 0x123456
Data Byte | DTCExtDataRecord Contents for DTCExtDataRecordNumber 0x05 | Byte Value |
---|---|---|
#1 | 暖机循环次数 - 自从DTC请求MIL灯关闭,暖机循环的次数 | 0x17 |
DTCExtDataRecordNumber 0x05 content for DTC 0x234561
Data Byte | DTCExtDataRecord Contents for DTCExtDataRecordNumber 0x05 | Byte Value |
---|---|---|
#1 | 暖机循环次数 - 自从DTC请求MIL灯关闭,暖机循环的次数 | 0x79 |
在如下案例中,客户端请求的DTCMaskRecord,包括了DTC编号,值为0x05的DTCExtDataRecordNumber(汇报所有的DTCExtDataRecords)。服务端返回了2个DTC。下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCExtDataRecordByRecordNumber,肯定应答报文案例#17。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportDTCExtDataRecordByRecordNumber, suppressPosRspMsgIndicationBit = FALSE | 0x16 |
#3 | DTCExtDataRecordNumber | 0x05 |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCExtDataRecordByRecordNumber,肯定应答报文案例#17。由服务端发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportDTCExtDataRecordByRecordNumber | 0x16 |
#3 #4 #5 #6 | DTCAndStatusRecord [ DTCHighByte ] DTCAndStatusRecord [ DTCMiddleByte ] DTCAndStatusRecord [ DTCLowByte ] DTCAndStatusRecord [ statusOfDTC ] | 0x12 0x34 0x56 0x24 |
#7 | DTCExtDataRecordNumber | 0x05 |
#8 | DTCExtDataRecord [ byte#1 ] | 0x17 |
#9 | DTCAndStatusRecord [ DTCHighByte ] | 0x23 |
#10 | DTCAndStatusRecord [ DTCMiddleByte ] | 0x45 |
#11 | DTCAndStatusRecord [ DTCLowByte ] | 0x61 |
#12 | DTCAndStatusRecord [ DTCLowByte ] | 0x24 |
#13 | DTCExtDataRecordNumber | 0x05 |
#14 | DTCExtDataRecord [ byte#1 ] | 0x79 |
Example #18 - ReadDTCInformation, sub-function = reportWWHOBDDTCByMaskRecord
这个例子展示了子函数参数为reportWWHOBDDTCByMaskRecord的使用方法,对于确认的DTC(DTC 状态掩码为0x08),车辆使用CAN总线,其连接了两个排放相关的服务端。
客户端使用了如下请求参数设置:
— FunctionalGroupIdentifier = 0x33(排放系统组);
— DTCSeverityMaskRecord.DTCSeverityMask = 0xFF(汇报任何严重和等级状态的DTC);
— DTCSeverityMaskRecord.DTCStatusMask = 0x08(confirmedDTC status = '1’的DTC);
服务端支持如下设置:
— FunctionalGroupIdentifier = 0x33(排放系统组);
— DTCStatusAvailabilityMask = 0xFF;
— DTCSeverityAvailabilityMask = 0xFF;
— DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_04 = 0x04;
Example #1中的所有假设都应用了。在如下案例中,服务端 #1只汇报DTC P2522-1F,因为其状态为0x2F(0010 1111),与客户端定义的状态掩码0x08(0000 1000)相匹配。服务端 #2汇报了DTC P0235-12,因为其状态为0x2E(0010 1110),与客户端定义的状态掩码0x08(0000 1000)相匹配。下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCByStatusMask,肯定应答报文案例#18。由客户端发往服务端,消息类型为请求。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | sub-function = reportWWHOBDDTCByMaskRecord, suppressPosRspMsgIndicationBit = FALSE | 0x42 |
#3 | FunctionalGroupIdentifier (FunctionalGroupIdentifier=emissions=0x33) | 0x33 |
#4 | DTCSeverityMaskRecord[] = [ DTCStatusMask ] | 0x08 |
#5 | DTCSeverityMaskRecord[] = [ DTCSeverityMask ] | 0xFF |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportWWHOBDDTCByStatusMask,肯定应答报文案例#18。由服务端#1发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportWWHOBDDTCByMaskRecord | 0x42 |
#3 | FunctionalGroupIdentifier (FunctionalGroupIdentifier=emissions=0x33) | 0x33 |
#4 | DTCStatusAvailabilityMask | 0xFF |
#5 | DTCSeverityAvailabilityMask | 0xFF |
#6 | DTCFormatIdentifier = [SAE_J2012-DA_DTCFormat_04] | 0x04 |
#7 #8 #9 #10 #11 | DTCAndSeverityRecord[ DTCSeverity#1 ] DTCAndSeverityRecord[ DTCHighByte#1 ] DTCAndSeverityRecord[ DTCMiddleByte#1 ] DTCAndSeverityRecord[ DTCLowByte#1 ] DTCAndSeverityRecord[ statusOfDTC#1 ] | 0x20 0x25 0x22 0x1F 0x2F |
下表定义了读取故障码信息服务,子函数设置为sub-function = reportOBDDTCByStatusMask,肯定应答报文案例#18。由服务端#2发往客户端,消息类型为应答。
A_Data Byte | Description | Byte Value |
---|---|---|
#1 | ReadDTCInformation Response SID | 0x59 |
#2 | reportType = reportWWHOBDDTCByMaskRecord | 0x42 |
#3 | FunctionalGroupIdentifier (FunctionalGroupIdentifier=emissions=0x33) | 0x33 |
#4 | DTCStatusAvailabilityMask | 0xFF |
#5 | DTCSeverityAvailabilityMask | 0xFF |
#6 | DTCFormatIdentifier = [SAE_J2012-DA_DTCFormat_04] | 0x04 |
#7 #8 #9 #10 #11 | DTCAndSeverityRecord[ DTCSeverity#1 ] DTCAndSeverityRecord[ DTCHighByte#1 ] DTCAndSeverityRecord[ DTCMiddleByte#1 ] DTCAndSeverityRecord[ DTCLowByte#1 ] DTCAndSeverityRecord[ statusOfDTC#1 ] | 0x20 0x02 0x35 0x12 0x2E |