【ISO14229_UDS_0x19服务详解】

目录

1、0x19服务(ReadDTCInformation,读取DTC信息服务)

  Service description:
  0x19服务(ReadDTCInformation,读取DTC信息服务)允许客户端读取服务端中存留的诊断故障代码(DTC)信息的状态,可以是车辆上的一个或一组服务端。 除非特定子函数另有要求,服务端应返回所有DTC信息(例如排放相关和非排放相关)。该服务允许客户端执行如下操作:
  — 获取与客户端定义故障码状态掩码相匹配的DTC数量;
  — 获取与客户端定义故障码状态掩码相匹配的所有DTC列表;
  — 获取与客户端定义故障码状态掩码相匹配的特定功能组内的DTC列表;
  — 获取所有带有“永久故障码”状态的DTC;
  — 获取故障码快照数据(有时也会叫冻结帧):故障码快照数据(DTC Snapshots)是存储在服务端内存中,并与故障码相关的具体数据记录。故障码快照数据(DTC Snapshots) 的主要用处就是一旦检测到系统故障便存储数据。系统故障发生瞬间,一系列的数据值便会被冻结(快照)下来,这就是快照数据承担的角色。冻结哪些数据与DTC相关,其指定的快照信息可以帮助技术人员迅速地排查故障。
  — 从DTC内存或DTC镜像内存中,获取客户端定义的DTC和状态掩码组合相关的DTCExtendedData。诊断故障码扩展数据(DTCExtendedData)由与故障码相关的扩展状态信息组成。DTCExtendedData包含了DTC参数值,这在请求时刻就已经确定的。DTCExtendedData的典型用法就是用来存储与故障码相关的动态数据,如:
    — DTC B1故障指示器计数器,表示OBD系统在故障发生时运行的时间(发动机工作小时数);
    — 故障码发生次数,统计在驾驶循环中故障码状态位Bit1(“TestFailed”)被上报的次数;
    — 故障码老化次数,自故障码最近一次失效以来统计驾驶循环的次数,排除未报出"testPassed" 或者 "testFailed"的驾驶循环;
    — OBD特定计数器(例如,如果驾驶循环可以在无故障模式下进行,则在“检查发动机”灯关闭之前剩余的驾驶循环数);
    — 最近发生时间;
    — 测试失效次数,统计"testFailed"汇报次数;
    — 未完成次数、故障测试最近一个完成后驾驶循环的次数;
  — 获取与客户端定义严重等级掩码相匹配的故障码数量;
  — 获取与客户端定义严重等级记录相匹配的故障码列表;
  — 获取与客户端定义故障码的严重等级信息;
  — 获取服务端支持的所有故障码状态;
  — 获取服务端第一个失效的故障码;
  — 获取最近失效的故障码;
  — 获取第一个确认的故障码;
  — 获取最近确认的故障码;
  — 获取在DTC镜像内存中与客户端定义DTC状态掩码匹配的DTC列表;
  — 从DTC镜像内存中,获取客户端定义的DTC掩码的扩展数据记录、客户端定义扩展数据记录的数量;
  — 从DTC镜像内存中,获取客户端定义DTC状态掩码的DTC数量;
  — 仅获取与客户端定义的DTC状态掩码相匹配的排放相关的OBD DTC数量;如果检测到与排放相关的OBD DTC,则会导致故障指示灯打开/文言提示;
  — 仅获取与客户端定义的DTC状态掩码相匹配的排放相关的OBD DTC状态;如果检测到与排放相关的OBD DTC,则会导致故障指示灯打开/文言提示;
  — 获取所有当前“prefailed”的DTC,不管有没有被检测为“pending”或者“confirmed”;
  — 从DTC内存中,获取与客户端定义DTC扩展数据记录状态相关的DTCExtendedData;
  — 从用户自定义的DTC内存中,获取与客户端定义DTC状态掩码相匹配的DTC列表;
  — 从用户自定义的DTC镜像内存中,获取与客户端定义DTC掩码以及客户端定义DTCExtendedData记录数量的DTCExtendedData;
  —从用户定义的DTC内存中获取与客户端定义DTC掩码相匹配的DTCSnapshotRecord数据
  该服务使用子函数去决定客户端正在请求哪种类型的诊断信息。关于每个子函数参数的更多细节在以下小节中提供。
  本服务使用以下条款:
  — Enable Criteria:车辆制造商/系统供应商特定的标准,用于控制服务端何时执行特定的内部诊断;
  — Test Pass Criteria:车辆制造商/系统供应商特定的条件,定义被诊断的系统是否在正常且可接受的操作范围内运行(例如,没有故障存在,被诊断的系统被分类为“OK”)。;
  — Test Failure Criteria:车辆制造商/系统供应商特定的故障条件,定义被诊断的系统是否未通过测试。
  — Confirmed Failure Criteria:车辆制造商/系统供应商特定的故障条件,确定被诊断的系统是否确实存在问题(确认),保证将DTC记录存储在长期记忆中。
  — Occurrence Counter:故障发生计数器,统计DTC汇报“testFailed”实例数;
  — Aging:服务端评估过去每次内部诊断的结果,以确定是否可以从内存中清除已确认故障码的过程。
  给定DTC值(如,0x080511)永远不会在readDTCInformation的肯定应答中报告超过一次,除了读取DTCSnapshotRecords,其中应答报文中同一个DTC可能会包含多个DTCSnapshotRecords。
  当使用分页缓冲处理读取DTC时(特别是对于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 reportDTCWithPermanentStatus(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请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2






sub-function = [ reportType =
  reportNumberOfDTCByStatusMask
  reportDTCByStatusMask
  reportMirrorMemoryDTCByStatusMask
  reportNumberOfMirrorMemoryDTCByStatusMask
  reportNumberOfEmissionsOBDDTCByStatusMask
  reportEmissionsOBDDTCByStatusMask ]
M







0x01
0x02
0x0F
0x11
0x12
0x13
#3DTCStatusMaskM0x00 – 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#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
#6DTCSnapshotRecordNumberC0x00 - 0xFF

  C:DTCMaskRecord记录和DTCSnapshotRecordNumber参数只有在子函数参数等于reportDTCSnapshotRecordByDTCNumber的情况下才会出现。
  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2
sub-function = [ reportType =
       reportDTCStoredDataByRecordNumber ]
M

0x05
#3DTCStoredDataRecordNumberM0x00 - 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#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
#6DTCExtDataRecordNumberM0x00 - 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2

sub-function = [ reportType =
  reportNumberOfDTCBySeverityMaskRecord
  reportDTCBySeverityMaskRecord ]
M


0x07
0x08

#3
#4
DTCSeverityMaskRecord[] = [
          DTCSeverityMask
          DTCStatusMask ]

M
M

0x00 - 0xFF
0x00 - 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2
sub-function = [ reportType =
       reportDTCExtDataRecordByDTCNumber
M

0x09

#3
#4
#5
DTCMaskRecord[] = [
          DTCHighByte
          DTCMiddleByte
          DTCLowByte ]

M
M
M

0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2







sub-function = [ reportType =
       reportSupportedDTC
       reportFirstTestFailedDTC
       reportFirstConfirmedDTC
       reportMostRecentTestFailedDTC
       reportMostRecentConfirmedDTC
       reportDTCFaultDetectionCounter
       reportDTCWithPermanentStatus ]
M








0x0A
0x0B
0x0C
0x0D
0x0E
0x14
0x15

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2
sub-function = [ reportType =
       reportDTCExtDataRecordByRecordNumber]
M

0x16
#3DTCExtDataRecordNumberM0x00 - 0xEF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2

sub-function = [ reportType =
       reportUserDefMemoryDTCByStatusMask
M


0x17
#3DTCStatusMaskM0x00 - 0xEF
#4MemorySelectionM0x00 – 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2
sub-function = [ reportType =
       reportUserDefMemoryDTCSnapshotRecordByDTCNumber]
M

0x18

#3
#4
#5
DTCMaskRecord[] = [
          DTCHighByte
          DTCMiddleByte
          DTCLowByte ]

M
M
M

0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF
#6DTCSnapshotRecordNumberM0x00 - 0xFF
#7MemorySelectionM0x00 - 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2
sub-function = [ reportType =
       reportUserDefMemoryDTCExtDataRecordByDTCNumber]
M

0x19

#3
#4
#5
DTCMaskRecord[] = [
          DTCHighByte
          DTCMiddleByte
          DTCLowByte ]

M
M
M

0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF
#6DTCExtDataRecordNumberM0x00 - 0xFF
#7MemorySelectionM0x00 - 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2

sub-function = [ reportType =
       reportWWHOBDDTCByMaskRecord ]
M


0x42
#3FunctionalGroupIdentifierM0x00 - 0xFF

#4
#5
DTCSeverityMaskRecord[] = [
          DTCSeverityMask
          DTCStatusMask ]

M
M

0x00 - 0xFF
0x00 - 0xFF

  基于下面使用的子函数参数,下表定义了ReadDTCInformation请求报文的结构:

字节序号参数值约定字节值
#1ReadDTCInformation Request SIDM0x19
#2

sub-function = [ reportType =
       reportWWHOBDDTCWithPermanentStatus ]
M


0x55
#3FunctionalGroupIdentifierM0x00 - 0xFF

2.2 请求报文中子函数参数定义

  该服务使用子函数参数从下表中来选择所指定DTC的汇报类型。下面详细介绍了子函数参数的解释和用法。

Bits 6 – 0Description约定
0x00ISOSAEReserved
ISO保留
M
0x01reportNumberOfDTCByStatusMask
该参数指定了服务端应该发送给客户端的DTC数量,这些DTC与客户端所定义的状态掩码需要相匹配。
U
0x02reportDTCByStatusMask
该参数指定了服务端应该发送给客户端的DTC列表和相应故障状态,这些DTC与客户端所定义的状态掩码需要相匹配。
U
0x03reportDTCSnapshotIdentification
该参数指定了服务端应该发送给客户端的所有的DTCSnapshot数据记录标识符(DTC number(s) and DTCSnapshot record number(s))
U
0x04reportDTCSnapshotRecordByDTCNumber
该参数指定了服务端应该发送给客户端的DTCSnapshot record(s)记录,这些数据记录与客户端定义的DTC编号和DTCSnapshot记录编号有关(当记录编号为0xFF,表示为所有的记录)
U
0x05reportDTCStoredDataByRecordNumber
该参数指定了服务端应该发送给客户端的DTCStoredDatarecord(s),这些数据记录与客户端定义的DTCStoredData record number有关(当记录编号为0xFF,表示为所有的记录)
U
0x06reportDTCExtDataRecordByDTCNumber
该参数指定了服务端应该发送给客户端的DTCExtendedData record(s),这些扩展数据记录与客户端定义的DTC number 和 DTCExtendedData record number有关(当记录编号为0xFF,表示为所有的记录;当记录编号为0xFE,表示为所有的OBD记录)
U
0x07reportNumberOfDTCBySeverityMaskRecord
该参数指定了服务端应该发送给客户端的DTC数量,这些DTC与客户端定义的severity mask record相匹配
U
0x08reportDTCBySeverityMaskRecord
该参数指定了服务端应该发送给客户端的DTC列表和相应的状态,这些DTC与客户端定义的severity mask record相匹配
U
0x09reportSeverityInformationOfDTC
该参数指定了服务端应该发送给客户端的在请求报文中指定DTC的严重信息
U
0x0AreportSupportedDTC
该参数指定了服务端应该发送给客户端的服务端所支持的所有的DTC列表和相应的状态
U
0x0BreportFirstTestFailedDTC
该参数指定了服务端应该发送给客户端服务端检测到的第一个失效的DTC,自从上次清除诊断信息以来。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。
U
0x0CreportFirstConfirmedDTC
该参数指定了服务端应该发送给客户端服务端检测到的第一个确认的DTC,自从上次清除诊断信息以来。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。(例如,如果一个DTC老化到允许其状态被重置,那么第一个确认的DTC记录将继续由服务端保存,而不管之后是否有任何其他的DTC被确认)
U
0x0DreportMostRecentTestFailedDTC
该参数指定了服务端应该发送给客户端服务端检测到的最近一次失效的DTC,自从上次清除诊断信息以来。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。
U
0x0EreportMostRecentConfirmedDTC
该参数指定了服务端应该发送给客户端服务端检测到的最近一次确认的DTC,自从上次清除诊断信息以来。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。注意,通过此子函数参数报告的信息应与DTC是否被确认或老化无关。(例如,如果一个DTC老化到允许其状态被重置,那么第一个确认的DTC记录将继续由服务端保存,而不管之后是否有任何其他的DTC被确认)
U
0x0FreportMirrorMemoryDTCByStatusMask
该参数指定了服务端从镜像内存中应该发送给客户端DTC列表和相应状态,其与状态掩码相匹配
U
0x10reportMirrorMemoryDTCExtDataRecordByDTCNumber
该参数指定了服务端从镜像内存中应该发送给客户端DTCExtendedData record(s),其与客户端定义的DTC编号和DTCExtendedData record number相关(0xFF表示所有的记录, 0xFE表示所有的OBD记录 )
U
0x11reportNumberOfMirrorMemoryDTCByStatusMask
该参数指定了服务端从镜像内存中应该发送给客户端DTC的数量,其与客户端定义的状态掩码相匹配
U
0x12reportNumberOfEmissionsOBDDTCByStatusMask
该参数指定了服务端应该发送给客户端与排放相关的OBD DTC的数量,其与客户端定义的状态掩码相匹配。汇报的OBD DTC数量仅应是那些必须符合排放相关法律要求的dtc数量。
U
0x13reportEmissionsOBDDTCByStatusMask
该参数指定了服务端应该发送给客户端与排放相关的OBD DTC和相应的状态,其与客户端定义的状态掩码相匹配。汇报的OBD DTC列表仅应是那些必须符合排放相关法律要求的dtc数量。
U
0x14reportDTCFaultDetectionCounter
  该参数指定了服务端应该发送给客户端当前“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
0x15reportDTCWithPermanentStatus
该参数指定了服务端应该发送给客户端带有"permanent DTC"状态的DCT列表。
U
0x16reportDTCExtDataRecordByRecordNumber
该参数指定了服务端应该发送给客户端DTCExtendedData records,其与客户端定义的小于0xF0的DTCExtendedData record number。
U
0x17reportUserDefMemoryDTCByStatusMask
该参数指定了服务端从用户自定义的DTC内存中应该发送给客户端DTC列表和相应的状态,其与客户端定义的状态掩码相匹配。
U
0x18reportUserDefMemoryDTCSnapshotRecordByDTCNumber
该参数指定了服务端从用户自定义的DTC内存中应该发送给客户端DTCSnapshot record(s),其与客户端定义的DTC编号和DTCSnapshot record number相匹配(0xFF表示所有的记录)。
U
0x19reportUserDefMemoryDTCExtDataRecordByDTCNumber
该参数指定了服务端从用户自定义的DTC内存中应该发送给客户端DTCExtendedData record(s),其与客户端定义的DTC编号和DTCExtendedData record number相匹配(0xFF表示所有的记录)。
U
0x1A - 0x41ISOSAEReserved
ISO保留
U
0x42reportWWHOBDDTCByMaskRecord
该参数指定了服务端应该发送给客户端WWH OBD DTC列表和相应状态以及严重等级信息,其与客户端定义的状态掩码和严重记录相匹配
U
0x43 - 0x54ISOSAEReserved
ISO保留
U
0x55reportWWHOBDDTCWithPermanentStatus
该参数指定了服务端应该发送给客户端带有"permanent DTC"状态的WWH OBD DTC列表
U
0x56 - 0x7FISOSAEReserved
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

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2




reportType = [
  reportNumberOfDTCByStatusMask
  reportNumberOfDTCBySeverityMaskRecord
  reportNumberOfMirrorMemoryDTCByStatusMask
  reportNumberOfEmissionsOBDDTCByStatusMask
M





0x01
0x07
0x11
0x12
#3DTCStatusAvailabilityMaskM0x00 - 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

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2




reportType = [
  reportDTCByStatusMask
  reportSupportedDTCs
  reportFirstTestFailedDTC
  reportFirstConfirmedDTC
  reportMostRecentTestFailedDTC
  reportMostRecentConfirmedDTC
  reportMirrorMemoryDTCByStatusMask
  reportEmissionsOBDDTCByStatusMask
  reportDTCWithPermanentStatus ]
M










0x02
0x0A
0x0B
0x0C
0x0D
0x0E
0x0F
0x13
0x15
#3DTCStatusAvailabilityMaskM0x00 - 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信息可以汇报时,参数才会出现。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#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
#6DTCSnapshotRecordNumber#1C10x00 - 0xFF
.
.
.
.
.
.
.
.

#n-3
#n-2
#n-1
DTCRecord[]#m = [
        DTCHighByte#m
        DTCMiddleByte#m
        DTCLowByte#m ]

C2
C2
C2

0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF
#nDTCSnapshotRecordNumber#mC20x00 - 0xFF

  C1:DTCRecord和DTCSnapshotRecordNumber参数只有在至少一个DTCSnapshot记录可用时才会出现。
  C2:DTCRecord和DTCSnapshotRecordNumber参数只有在多个DTCSnapshot记录可用时才会出现。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#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
#7DTCSnapshotRecordNumber#1C10x00 - 0xFF
#8DTCSnapshotRecordNumberOfIdentifiers#1C10x00 - 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
.
.
.
.
.
.
.
.
#tDTCSnapshotRecordNumber#xC30x00 - 0xFF
#t+1DTCSnapshotRecordNumberOfIdentifiers#xC30x00 - 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组合才存在。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2

reportType = [
      reportDTCStoredDataByRecordNumber ]
M


0x05
#3DTCStoredDataRecordNumber#1M0x00 - 0xFF

#4
#5
#6
#7
DTCAndStatusRecord[]#1 = [
        DTCHighByte
        DTCMiddleByte
        DTCLowByte
        statusOfDTC ]

C1
C1
C1
C1

0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF
#8DTCStoredDataRecordNumberOfIdentifiers#1C10x00 - 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
.
.
.
.
.
.
.
.
#tDTCStoredDataRecordNumber#xC30x00 - 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+5DTCStoredDataRecordNumberOfIdentifiers#xC30x00 - 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组合才存在。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#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
#7DTCExtDataRecordNumber#1C10x00 - 0xFD

#8
.
.
#8+(p-1)
DTCExtDataRecord[]#1 = [
      extendedData#1 byte#1
      .
      .
      extendedData#1 byte#p ]

C1
C1
C1

0x00 - 0xFF
.
.
0x00 - 0xFF
.
.
.
.
.
.
.
.
#tDTCExtDataRecordNumber#xC20x00 – 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才存在。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2


reportType = [
      reportDTCBySeverityMaskRecord
      reportSeverityInformationOfDTC ]
M



0x08
0x09
#3DTCStatusAvailabilityMaskM0x00 – 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才存在。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#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时,才会出现此参数记录。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2

reportType = [
      reportDTCExtDataRecordByRecordNumber]
M


0x16
#3ReadDTCInformation Response SIDM0x00 – 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参数才会出现。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2

reportType = [
      reportUserDefMemoryDTCByStatusMask]
M


0x17
#3MemorySelectionM0x00- 0xFF
#4DTCStatusAvailabilityMaskM0x00- 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信息可用时才会出现。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2

reportType = [
      reportUserDefMemoryDTCSnapshotRecordByDTCNumber ]
M


0x18
#3MemorySelectionM0x00- 0xFF

#4
#5
#6
#7
DTCAndStatusRecord[] = [
        DTCHighByte
        DTCMiddleByte
        DTCLowByte
        statusOfDTC ]

M
M
M
M

0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF
0x01 - 0xFF
#8DTCSnapshotRecordNumber#1C10x00- 0xFF
#9DTCSnapshotRecordNumberOfIdentifiers#1C10x00- 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
.
.
.
.
.
.
.
.
#tDTCSnapshotRecordNumber#xC30x00- 0xFF
#t+1DTCSnapshotRecordNumberOfIdentifiers#xC30x00- 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)并且有多个记录可供报告时才存在。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2

reportType = [
      reportUserDefMemoryDTCExtDataRecordByDTCNumber ]
M


0x19
#3MemorySelectionM0x00 – 0xFF

#4
#5
#6
#7
DTCAndStatusRecord[] = [
        DTCHighByte
        DTCMiddleByte
        DTCLowByte
        statusOfDTC ]

M
M
M
M

0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF
0x00 - 0xFF
#8DTCExtDataRecordNumber#1C10x00-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)并且有多条记录可供报告时才存在。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2

reportType = [
      reportWWHOBDDTCByMaskRecord ]
M


0x42
#3FunctionalGroupIdentifierM0x00 – 0xFF
#4DTCStatusAvailabilityMaskM0x00 – 0xFF
#5DTCSeverityAvailabilityMaskM0x00 – 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信息可用时才会出现。

  以下子函数参数的格式,其肯定应答报文定义见下表。

字节序号参数值约定字节值
#1ReadDTCInformation Response SIDM0x59
#2

reportType = [
      reportWWHOBDDTCWithPermanentStatus ]
M


0x55
#3FunctionalGroupIdentifierM0x00 – 0xFF
#4DTCStatusAvailabilityMaskM0x00 – 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描述
0x12sub-functionNotSupported
如果不支持子功能参数,则发送此NRC。
0x13incorrectMessageLengthOrInvalidFormat
当消息长度不正确时,会发送该NRC
0x31requestOutOfRange
当出现以下情况时,会发送该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 nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试并未完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  假设DTC P0A9B-17,表示为混合动力电池传感器电压超限,故障码状态位statusOfDTC为0x26,二进制为 0010 0110;
  下表定义了故障码状态位statusOfDTC = 0x26的含义:

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  假设DTC P2522-1F,表示为A/C请求B 线路中断,故障码状态位statusOfDTC为0x2F,二进制为 0010 1111;
  下表定义了故障码状态位statusOfDTC = 0x2F的含义:

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed01请求时刻,DTC已失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  在如下案例中,只有DTC P2522-1F 即A/C 请求“B” - 线路中断,状态掩码为0x2F,能够与客户端所定义的状态掩码0x08相匹配。即Bit7 = 1。下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCByStatusMask,请求消息流案例#1。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportNumberOfDTCByStatusMask,
               suppressPosRspMsgIndicationBit = FALSE
0x01
#3DTCStatusMask0x08

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCByStatusMask,肯定应答报文案例#1。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportNumberOfDTCByStatusMask0x01
#3DTCStatusAvailabilityMask0x2F
#4DTCFormatIdentifier = ISO_14229-1_DTCFormat0x01
#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 nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试并未完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  假设DTC P2522-1F,表示为混合动力电池传感器电压超限,故障码状态位statusOfDTC为0x26,二进制为 0010 0110;
  下表定义了故障码状态位statusOfDTC = 0x26的含义:

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  假设DTC P2522-1F,表示为A/C请求B 线路中断,故障码状态位statusOfDTC为0x00,二进制为 0000 0000;
  下表定义了故障码状态位statusOfDTC = 0x00的含义:

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00请求时刻,DTC未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC20当前或者上一个操作循环,DTC未失效
confirmedDTC30请求时刻,DTC未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear50自从上一次故障码被清除后,故障码从未失效
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  在如下案例中,只有DTC P0805-11 即离合器位置传感器短地,状态掩码为0x2F,二进制为 0010 1111;
  下表定义了故障码状态位statusOfDTC = 0x2F的含义:

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed01请求时刻,DTC已失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  在如下案例中,DTCs P0A9B-17 (0x0A9B17) 和 P0805-11 (0x080511)返回给客户端的请求。DTC P2522-1F (0x25221F)没有返回,是因其状态掩码为0x00与如下案例请求报文中定义的状态掩码0x84不匹配。服务端应该绕过那些它不支持的状态位的屏蔽。
  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,请求报文案例#2。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportDTCByStatusMask,
               suppressPosRspMsgIndicationBit = FALSE
0x02
#3DTCStatusMask0x84

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,肯定应答报文案例#2。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCByStatusMask0x02
#3DTCStatusAvailabilityMask0x7F

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 nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试并未完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  假设DTC P0A9B-17,表示为混合动力温度传感器 - 电流电压超限,故障码状态位statusOfDTC为0x00,二进制为 0000 0000;
  下表定义了故障码状态位statusOfDTC = 0x00的含义:

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00请求时刻,DTC未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC20当前或者上一个操作循环,DTC未失效
confirmedDTC30请求时刻,DTC未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear50自从上一次故障码被清除后,故障码从未失效
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  客户端请求服务端reportByStatusMask所有 bit 0 (TestFailed)设置为逻辑’ 1 '的DTC。

  在如下案例中,以上没有一个DTC可以应答服务端的请求,因为没有一个DTC在请求时刻已经失效了。
  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,请求报文案例#3。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportDTCByStatusMask,
               suppressPosRspMsgIndicationBit = FALSE
0x02
#3DTCStatusMask0x01

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,肯定应答报文案例#3。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCByStatusMask0x02
#3DTCStatusAvailabilityMask0x7F

Example #4 - ReadDTCInformation, sub-function = reportDTCSnapshotIdentification

  这个例子展示了子函数参数为reportDTCSnapshotIdentification的使用方法。
  有如下假设:
  — 服务端有能力支持对给定的DTC存储两条DTCSnapshot记录;
  — 服务端应该表明两条DTCSnapshot记录是为当前编号为0x123456的DTC存储的。出于本例的目的,假设该DTC发生了三次(由于服务端缺乏存储空间,因此只存储第一个和最近的DTCSnapshot记录);
  — 所有的DTCSnapshot都按升序存储;

  在如下案例中,有3个DTCSnapshot记录应答了客户端的请求。
  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCSnapshotIdentification,请求报文案例#4。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportDTCSnapshotIdentification,
               suppressPosRspMsgIndicationBit = FALSE
0x03

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCSnapshotIdentification,肯定应答报文案例#4。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCSnapshotIdentification0x03
#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 ByteDTCSnapshot Record ContentsByte Value
#1DTCSnapshotRecord [ data#1 ] = ECT (Engine Coolant Temperature)0xA6
#2DTCSnapshotRecord [ data#2 ] = TP (Throttle Position)0x66
#3DTCSnapshotRecord [ data#3 ] = RPM (Engine Speed)0x07
#4DTCSnapshotRecord [ data#4 ] = RPM (Engine Speed)0x50
#5DTCSnapshotRecord [ data#5 ] = MAP (Manifold Absolute Pressure)0x20

  在如下案例中,根据客户端的reportDTCSnapshotRecordByDTCNumber请求,一条DTCSnapshot记录被返回。
  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCSnapshotRecordByDTCNumber,请求报文案例#5。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportDTCSnapshotRecordByDTCNumber,
               suppressPosRspMsgIndicationBit = FALSE
0x04
#3
#4
#5
DTCMaskRecord [ DTCHighByte ]
DTCMaskRecord [ DTCMiddleByte ]
DTCMaskRecord [ DTCLowByte ]
0x12
0x34
0x56
#6DTCSnapshotRecordNumber0x02

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCSnapshotRecordByDTCNumber,肯定应答报文案例#5。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCSnapshotRecordByDTCNumber0x04
#3
#4
#5
#6
DTCAndStatusRecord#1 [ DTCHighByte ]
DTCAndStatusRecord#1 [ DTCMiddleByte ]
DTCAndStatusRecord#1 [ DTCLowByte ]
DTCSnapshotRecordNumber#1
0x12
0x34
0x56
0x24
#7DTCSnapshotRecordNumber0x02
#8DTCSnapshotRecordNumberOfIdentifiers0x01
#9dataIdentifier [ byte#1 ] (MSB)0x47
#10dataIdentifier [ 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 ByteDTCSnapshot Record ContentsByte Value
#1DTCStoredDatatRecord [ data#1 ] = ECT (Engine Coolant Temperature)0xA6
#2DTCStoredDatatRecord [ data#2 ] = TP (Throttle Position)0x66
#3DTCStoredDatatRecord [ data#3 ] = RPM (Engine Speed)0x07
#4DTCStoredDatatRecord [ data#4 ] = RPM (Engine Speed)0x50
#5DTCStoredDatatRecord [ data#5 ] = MAP (Manifold Absolute Pressure)0x20

  在如下案例中,请求了DTCStoredDatatRecord记录编号2,服务端返回了DTC和DTCStoredData的记录内容。
  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCStoredDataByRecordNumber,请求报文案例#6。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportDTCStoredDataByRecordNumber,
               suppressPosRspMsgIndicationBit = FALSE
0x05
#3DTCStoredDataRecordNumber0x02

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCStoredDataByRecordNumber,肯定应答报文案例#6。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCStoredDataByRecordNumber0x05
#3DTCStoredDataRecordNumber0x02
#4
#5
#6
#7
DTCAndStatusRecord [ DTCHighByte ]
DTCAndStatusRecord [ DTCMiddleByte ]
DTCAndStatusRecord [ DTCLowByte ]
DTCSnapshotRecordNumber
0x12
0x34
0x56
0x24
#8DTCStoredDataRecordNumberOfIdentifiers0x01
#9dataIdentifier [ byte#1 ] (MSB)0x47
#10dataIdentifier [ 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 ByteDTCExtDataRecord Contents for DTCExtDataRecordNumber 0x05Byte Value
#1暖机循环计数 – 自从DTC命令MIL灯关闭以来,暖机循环的次数0x17

  DTCExtDataRecordNumber为0x10的内容:

Data ByteDTCExtDataRecord Contents for DTCExtDataRecordNumber 0x10Byte Value
#1故障码失效检测计数 – 每次故障码测试检测到了故障时会增加,测试汇报无故障时会降低0x17

  在如下案例中,客户端请求了一个DTCMaskRecord,其中包含了DTC码和一个值为0xFF的DTCExtDataRecordNumber(汇报所有的DTCExtDataRecords)。服务端返回了两条DTCExtDataRecords,其已经被客户端提交的DTC码记录下来。
  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCExtDataRecordByDTCNumber,请求报文案例#7。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportDTCExtDataRecordByDTCNumber,
               suppressPosRspMsgIndicationBit = FALSE
0x06
#3
#4
#5
DTCMaskRecord [ DTCHighByte ]
DTCMaskRecord [ DTCMiddleByte ]
DTCMaskRecord [ DTCLowByte ]
0x12
0x34
0x56
#6DTCExtDataRecordNumber0xFF

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCExtDataRecordByDTCNumber,肯定应答报文案例#7。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCExtDataRecordByDTCNumber0x06
#3
#4
#5
#6
DTCAndStatusRecord [ DTCHighByte ]
DTCAndStatusRecord [ DTCMiddleByte ]
DTCAndStatusRecord [ DTCLowByte ]
DTCAndStatusRecord [ statusOfDTC ]
0x12
0x34
0x56
0x24
#7DTCExtDataRecordNumber0x05
#8DTCExtDataRecord [ byte#1 ]0x17
#10DTCExtDataRecord [ byte#1 ]0x10
#11DTCExtDataRecord [ 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 nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试并未完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  假设有DTC 0x25221F,表示A/C线路中断,其状态为0x00(二进制为0000 0000),DTCFunctionalUnit = 0x10,DTCSeverity = 0x20:
  下表定义了故障码状态位statusOfDTC = 0x00的含义:

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00请求时刻,DTC未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC20当前或者上一个操作循环,DTC未失效
confirmedDTC30请求时刻,DTC未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear50自从上一次故障码被清除后,故障码从未失效
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  假设有DTC 0x080511,表示离合器位置传感器短地,其状态为0x2F(二进制为0010 1111),DTCFunctionalUnit = 0x10,DTCSeverity = 0x40:
  下表定义了故障码状态位statusOfDTC = 0x00的含义:

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed01请求时刻,DTC已失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  在如下案例中,由于DTC 0x080511与客户端定义的严重性掩码记录0xC001(DTCSeverityMask = 0xC0,DTCStatusMask = 0x01)相匹配。
  下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCBySeverityMaskRecord,请求报文案例#8。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportNumberOfDTCBySeverityMaskRecord,
               suppressPosRspMsgIndicationBit = FALSE
0x07
#3DTCSeverityMaskRecord(DTCSeverityMask)0xC0
#4DTCSeverityMaskRecord(DTCStatusMask)0x01

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfDTCBySeverityMaskRecord,肯定应答报文案例#8。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportNumberOfDTCBySeverityMaskRecord0x07
#3DTCStatusAvailabilityMask0x09
#4DTCFormatIdentifier = ISO_14229-1_DTCFormat0x01
#5DTCCount [ DTCCountHighByte ]0x00
#6DTCCount [ 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 ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportDTCBySeverityMaskRecord,
               suppressPosRspMsgIndicationBit = FALSE
0x08
#3DTCSeverityMaskRecord(DTCSeverityMask)0xC0
#4DTCSeverityMaskRecord(DTCStatusMask)0x01

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCBySeverityMaskRecord,肯定应答报文案例#9。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCBySeverityMaskRecord0x08
#3DTCStatusAvailabilityMask0x7F
#4DTCSeverityRecord#1 [ DTCSeverity ]0x40
#5DTCSeverityRecord#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 ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportSeverityInformationOfDTC,
               suppressPosRspMsgIndicationBit = FALSE
0x09
#3DTCMaskRecord [ DTCHighByte ]0x08
#4DTCMaskRecord [ DTCMiddleByte ]0x05
#5DTCMaskRecord [ DTCLowByte ]0x11

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportSeverityInformationOfDTC,肯定应答报文案例#10。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCBySeverityMaskRecord0x09
#3DTCStatusAvailabilityMask0x7F
#4DTCSeverityRecord [ DTCSeverity ]0x40
#5DTCSeverityRecord [ DTCFunctionalUnit ]0x10
#6DTCSeverityRecord [ DTCHighByte ]0x08
#7DTCSeverityRecord [ DTCMiddleByte ]0x05
#8DTCSeverityRecord [ DTCLowByte ]0x11
#9DTCSeverityRecord [ statusOfDTC ]0x2F

Example #11 - ReadDTCInformation, sub-function = reportSupportedDTCs

  这个例子展示了子函数参数为reportSupportedDTCs的使用方法。
  本案例中假设如下:
  — 服务端支持三种DTC(为了简单起见),在客户端请求时刻有如下状态。
  — DTC 0x123456,其状态为0x24(0010 0100)。

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试并未完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

   DTC 0x123456,其状态为0x00(0000 0000)。

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed01请求时刻,DTC已失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

   DTC 0xABCD01,其状态为0x2F(0010 1111)。

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed01请求时刻,DTC已失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  如下案例中,以上3个DTC都可被客户端返回。下表定义了读取故障码信息服务,子函数设置为sub-function = reportSupportedDTCs,请求报文案例#11。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportSupportedDTCs,
               suppressPosRspMsgIndicationBit = FALSE
0x0A

  下表定义了读取故障码信息服务,子函数设置为sub-function = readSupportedDTCs,肯定应答报文案例#11。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = readSupportedDTCs0x0A
#3DTCStatusAvailabilityMask0x7F
#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 nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试并未完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  如下案例中,DTC 0x123456可被客户端返回。下表定义了读取故障码信息服务,子函数设置为reportFirstTestFailedDTC,请求报文案例#12。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportFirstTestFailedDTC,
               suppressPosRspMsgIndicationBit = FALSE
0x0B

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportFirstTestFailedDTC,肯定应答报文案例#12。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportFirstTestFailedDTC0x0B
#3DTCStatusAvailabilityMask0xFF
#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 nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC30请求时刻,DTC并未确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试并未完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  如下案例中,DTC 0x123456可被客户端返回。下表定义了读取故障码信息服务,子函数设置为reportFirstTestFailedDTC,请求报文案例#13。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportFirstTestFailedDTC,
               suppressPosRspMsgIndicationBit = FALSE
0x0B

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportFirstTestFailedDTC,肯定应答报文案例#13。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportFirstTestFailedDTC0x0B
#3DTCStatusAvailabilityMask0xFF

Example #14 - ReadDTCInformation, sub-function = reportNumberOfEmissionsOBDDTCByStatusMask

  这个例子展示了子函数参数为reportNumberOfEmissionsOBDDTCByStatusMask的使用方法,和不同的屏蔽规则。
  出于屏蔽目的,服务端支持所有的状态位。服务端支持三种与排放相关的OBD DTC(出于简单考虑),在客户端请求时有如下的状态。
  与排放相关的 OBD DTC P0005-00 燃油关闭阀控制开路(0x000500),其状态位为0xAE(1010 1110)。

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested71服务端请求指示灯点亮

  与排放相关的 OBD DTC P022F-00 内部冷却器旁路控制电流过高 (0x022F00),其状态位为0xAC(1010 1100)。

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00请求时刻,DTC并未失效
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已完成
warningIndicatorRequested71服务端请求指示灯点亮

  与排放相关的 OBD DTC P0A09-00 DCDC转换器状态电流过低 (0x0A0900),其状态位为0xAF(1010 1111)。

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed01请求时刻,DTC已失效
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40自从上一次故障码被清除后,一次完整的DTC测试已完成
testFailedSinceLastClear51自从上一次故障码被清除后,故障码至少失效一次
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已完成
warningIndicatorRequested71服务端请求指示灯点亮

  如下案例中,总计数量3被客户端返回,因为所有的DTC与客户端定义的状态掩码0x08(0000 1000)相匹配。下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfEmissionsOBD-DTCByStatusMask,肯定应答报文案例#14。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportNumberOfEmissionsOBDDTCByStatusMask,
               suppressPosRspMsgIndicationBit = FALSE
0x12
#3DTCStatusMask0x08

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportNumberOfEmissionsOBD-DTCByStatusMask,肯定应答报文案例#14。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportNumberOfEmissionsOBDDTCByStatusMask0x12
#3DTCStatusAvailabilityMask0xFF
#4DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_000x00
#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 ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportEmissionsOBDDTCByStatusMask,
               suppressPosRspMsgIndicationBit = FALSE
0x13
#3DTCStatusMask0x80

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,肯定应答报文案例#15。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportEmissionsOBDDTCByStatusMask0x13
#3DTCStatusAvailabilityMask0xFF
#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 nameBit #Bit stateDescription
testFailed00未应用
testFailedThisOperationCycle10当前操作循环,DTC从未失效
pendingDTC20当前或者上一个操作循环,DTC未失效
confirmedDTC30请求时刻,DTC未确认
testNotCompletedSinceLastClear40未应用
testFailedSinceLastClear50未应用
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested70服务端没有请求指示灯点亮

  DTC P0180-17 油液温度传感器 - 电压超限(0x018017),其状态为0x8E(1000 1110)。

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00未应用
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40未应用
testFailedSinceLastClear50未应用
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested71服务端没有请求指示灯点亮

  DTC P0190-1D 燃油轨压力传感器 - 电流超限(0x01901D),其状态为0x8E(1000 1110)。

statusOfDTC: bit field nameBit #Bit stateDescription
testFailed00未应用
testFailedThisOperationCycle11当前操作循环,DTC已失效
pendingDTC21当前或者上一个操作循环,DTC失效
confirmedDTC31请求时刻,DTC已确认
testNotCompletedSinceLastClear40未应用
testFailedSinceLastClear50未应用
testNotCompletedThisOperationCycle60这个操作循环,DTC测试已经完成
warningIndicatorRequested71服务端没有请求指示灯点亮

  在如下案例中,P0180-17 (0x018017) 和 P0190-1D (0x01901D)被返回给客户端的请求。
  下表定义了读取故障码信息服务,子函数设置为sub-function = reportEmissionsOBDDTCByStatusMask,肯定应答报文案例#16。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportEmissionsOBDDTCByStatusMask,
               suppressPosRspMsgIndicationBit = FALSE
0x13
#3DTCStatusMask0x88

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCByStatusMask,肯定应答报文案例#16。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportEmissionsOBDDTCByStatusMask0x13
#3DTCStatusAvailabilityMask0xCE
#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 ByteDTCExtDataRecord Contents for DTCExtDataRecordNumber 0x05Byte Value
#1暖机循环次数 - 自从DTC请求MIL灯关闭,暖机循环的次数0x17

              DTCExtDataRecordNumber 0x05 content for DTC 0x234561

Data ByteDTCExtDataRecord Contents for DTCExtDataRecordNumber 0x05Byte Value
#1暖机循环次数 - 自从DTC请求MIL灯关闭,暖机循环的次数0x79

  在如下案例中,客户端请求的DTCMaskRecord,包括了DTC编号,值为0x05的DTCExtDataRecordNumber(汇报所有的DTCExtDataRecords)。服务端返回了2个DTC。下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCExtDataRecordByRecordNumber,肯定应答报文案例#17。由客户端发往服务端,消息类型为请求。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportDTCExtDataRecordByRecordNumber,
               suppressPosRspMsgIndicationBit = FALSE
0x16
#3DTCExtDataRecordNumber0x05

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportDTCExtDataRecordByRecordNumber,肯定应答报文案例#17。由服务端发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportDTCExtDataRecordByRecordNumber0x16
#3
#4
#5
#6
DTCAndStatusRecord [ DTCHighByte ]
DTCAndStatusRecord [ DTCMiddleByte ]
DTCAndStatusRecord [ DTCLowByte ]
DTCAndStatusRecord [ statusOfDTC ]
0x12
0x34
0x56
0x24
#7DTCExtDataRecordNumber0x05
#8DTCExtDataRecord [ byte#1 ]0x17
#9DTCAndStatusRecord [ DTCHighByte ]0x23
#10DTCAndStatusRecord [ DTCMiddleByte ]0x45
#11DTCAndStatusRecord [ DTCLowByte ]0x61
#12DTCAndStatusRecord [ DTCLowByte ]0x24
#13DTCExtDataRecordNumber0x05
#14DTCExtDataRecord [ 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 ByteDescriptionByte Value
#1ReadDTCInformation Request SID0x19
#2sub-function = reportWWHOBDDTCByMaskRecord,
               suppressPosRspMsgIndicationBit = FALSE
0x42
#3FunctionalGroupIdentifier
(FunctionalGroupIdentifier=emissions=0x33)
0x33

#4DTCSeverityMaskRecord[] = [ DTCStatusMask ]0x08
#5DTCSeverityMaskRecord[] = [ DTCSeverityMask ]0xFF

  下表定义了读取故障码信息服务,子函数设置为sub-function = reportWWHOBDDTCByStatusMask,肯定应答报文案例#18。由服务端#1发往客户端,消息类型为应答。

A_Data ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportWWHOBDDTCByMaskRecord0x42
#3FunctionalGroupIdentifier
(FunctionalGroupIdentifier=emissions=0x33)
0x33

#4DTCStatusAvailabilityMask0xFF
#5DTCSeverityAvailabilityMask0xFF
#6DTCFormatIdentifier = [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 ByteDescriptionByte Value
#1ReadDTCInformation Response SID0x59
#2reportType = reportWWHOBDDTCByMaskRecord0x42
#3FunctionalGroupIdentifier
(FunctionalGroupIdentifier=emissions=0x33)
0x33

#4DTCStatusAvailabilityMask0xFF
#5DTCSeverityAvailabilityMask0xFF
#6DTCFormatIdentifier = [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

返回UDS诊断服务功能单元介绍目录

  • 2
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: iso-14229是一项用于汽车电子系统通信的协议,其全称为ISO14229 Unified Diagnostic Services(UDS)on Controller Area Network(CAN)。该协议旨在为车辆的诊断、维护和修复提供标准化的方法。ISO 14229定义了诊断服务和通信的标准化消息格式,包括诊断数据、错误码、故障清除等,以使不同车辆的系统实现得到统一和互操作性。 ISO14229 UDS协议栈是用于实现ISO 14229诊断协议的软件组件。该协议栈的实现可分为物理层和软件层两个部分,其中物理层是指使用CAN总线对车辆的执行单元进行通信,而软件层则是指实现ISO 14229标准的协议堆栈。该协议栈具有标准化、可重用和可配置的特点,可在不同的客户平台上使用。 ISO 14229的文档是对该协议的规范和说明,包括协议的基本架构、消息格式、错误码表、会话层和传输层的细节等。该文档是实现ISO 14229协议的必要依据,可用于开发UDS协议栈的开发人员和车辆诊断工程师。 源码.zip则是UDS协议栈的实现源代码,包括物理层和软件层代码。开发人员可根据该源码了解UDS协议栈的实现细节和技术实现,并根据需求进行二次开发。 综上所述,ISO-14229_14229_UDS协议栈_UDS-ISO-14229_ISO14229文档_ISO 14229_源码.zip等组件,是用于实现汽车电子系统诊断的标准化协议,可为车辆的维护和修复提供规范的方法。开发人员和车辆诊断工程师可根据这些组件进行UDS协议栈的开发和实现。 ### 回答2: ISO-14229是用于诊断汽车电子控制单元(ECU)的标准协议。该协议旨在提供一种标准化的方法,让技术人员可以使用相同的工具和流程诊断不同制造商的汽车。 14229 UDS是该标准的通信协议栈。UDS指协议栈中定义的通用诊断服务,该服务可用于访问ECU的内部数据和状态。ISO14229文档提供了UDS协议栈的详细规范,以及相关的数据格式和命令集合。 此外,文档和源代码可以帮助工程师实现符合ISO-14229标准的诊断工具或ECU,提高汽车诊断系统的质量和效率。源码.zip则是UDS协议栈的代码包。 总之,ISO-14229标准和UDS协议栈提供了一种标准化的、可靠的汽车诊断协议。它们有助于提高汽车技术人员的工作效率,同时减少汽车诊断工具和软件的开发成本。 ### 回答3: ISO-14229是一种用于汽车电子系统的通讯协议。它定义了诊断通信的规范和协议,允许车辆厂商和供应商使用这些规范和协议来开发和测试车载电子控制单元。其中,UDS协议栈是实现ISO-14229的关键技术之一,能够为客户端提供远程访问ECEs的可能性。 ISO-14229规定了接口:UDS(Unified Diagnostic Service),用于与电子控制单元(ECU)之间进行通讯。 UDS协议栈则实现了UDS协议的接口,可以自动进行诊断和测试,发生故障时还能产生错误报告。 相应地, ISO14229文档描述了在ISO14229-1文档中定义的UDS协议的特定应用,与ISO15765-2的特定要求相结合。 它还包括了EVITA Light文档中的安全方面。 源码.zip文件则包含了UDS协议栈的源代码,可以在开发与应用中使用,实现对汽车电子控制单元的简便对话操作。 总之,ISO-14229及其UDS协议栈实现了车载控制电子单元的标准化通讯,可简化车辆诊断和维护过程,提高效率和可靠性。同时,相应的规范、文档和源代码也为相关人员提供了方便和支持。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值