DTC 19服务学习2

news2024/10/1 12:16:54

紧跟上篇
0x04 reportDTCSnapshotRecordByDTCNumber
通过DTC和快照序列来获取DTC快照记录。

适用以下假设：
— 服务器支持存储给定 DTC 的两个 DTCSnapshot 记录的能力。
— 此示例假定是上一个示例的延续。
— 假设服务器请求服务器存储的 DTC 编号 123456 的两个 DTCSnapshot 记录中的第二个（请参阅前面的示例，其中将 02 的 DTCSnapshotRecordCount 返回给客户端）。
— 假设 DTC 123456 的 statusOfDTC 为 24，并且每次出现 DTC 时都会捕获以下环境数据。
— DTCSnapshot 记录数据通过数据标识符 4711 引用。
直接看例子

本例中同样假设DTCSnapshotRecordNumber对服务端来说是唯一的(这里唯一的意思是说对于任何DTC，只要有Snapshotrecord,则DTCSnapshotRecordNumber就会累加一个）。实际情况中可能有不同的定义方式，比如可以对每一个DTC都有一个DTCSnapshotRecordNumber序列，或者对某几个DTC有一个DTCSnapshotRecordNumber的序列。
上图响应信息中，byte 7 (DTCSnapshotRecordNumber)为DTCSnapshot的序号, 当DTCSnapshotRecordNumber为全局唯一时， reportDTCSnapshotRecordByDTCNumber以及下一节要介绍的reportDTCStoredDataByRecordNumber都可用，但是当DTCSnapshotRecordNumber不是全局唯一时，下一节要介绍的reportDTCStoredDataByRecordNumber功能就不可用，因为这时候给定一个DTCSnapshotRecordNumber不能唯一的确定是哪一个DTC的DTCSnapshotRecord。
响应信息中，byte 8 (DTCSnapshotRecordNumberOfIdentifiers)为 dataIdentifier的序号，此例中只有一个dataIdentifier (0x4711), 所以DTCSnapshotRecordNumberOfIdentifiers的值为0x01,若有多个dataIdentifier,其值会继续增加下去。
dataIdentifier是数据ID，dataIdentifer 与 Snapshot record的内容相关联:一个dataIdentifier对应一组Snapshot record content。当一个dataIdentifier 只涉及到所有数据中的一部分数据，而又需要所有数据时，就需要多个dataIdentifier。
ISO14229中并没有对dataidentifier的长度(本例中2个字节)以及DTCSnapshotRecord内容的长度(本例中5个字节)做强制规定。

0x06 reportDTCExtDataRecordByDTCNumber
reportDTCExtendedDataRecordByDTCNumber,它的功能是根据客户端请求的DTC，返回一个DTCExtendedDataRecord。其功能与reportDTCSnapshotRecordByDTCNumber类似，区别只是reportDTCSnapshotRecordByDTCNumber返回的是DTCSnapshotRecord 而reportDTCExtDataRecordByDTCNumber返回的是DTCExtendedDataRecord。与reportDTCSnapshotRecordByDTCNumber一样，客户端请求是发送的DTCNumber叫做DTCMaskRecord,实际并没有”Mask”的功能，服务端会查找与DTCMaskRecord完全匹配的DTC。

通常情况下(客户端请求时的DTCExtDataRecordNumber不等于0xFE或0xFF，注意这点ISO14229(2013)与ISO14229(2006)不同，ISO14229(2006)只有不等于0xFF这一个例外), 服务端只会返回客户端1条预定义的DTCExtendedData 记录,否则服务端会返回存储的所有DTCExtendedData records。 DTCExtDataRecord(ISO14229(2006)此处名称为DTCExtendedDataRecord)的格式与内容由整车厂定义， DTCExtDataRecord中的数据结构由DTCExtDataRecordNumber定义，定义方式与reportDTCSnapshotRecordByDTCNumber中的dataIdentifier相似。

如果客户端请求的DTCMaskRecord 或者 DTCExtDataRecordNumber不可用或者服务端不支持，服务端会否定响应。关于否定响应ISO14229(2006)与ISO14229(2013)也有不同， ISO14229(2013)中规定，如果客户端请求DTCExtDataRecordNumber为0xFE,但是服务端不支持OBD相关的扩展数据(0x90-0xEF)时同样会产生否定响应。

使用ISO14229中的例子,做如下假设:

对于某个给定的DTC，服务端最多只能存储2个DTCExtendedData。
假设客户端请求DTC(0x123456)所有可用的DTCExtendedData。
假设DTC(0x123456)的statusOfDTC 为0x24,且随后的扩展数据是可用的。
DTCExtendedData通过DTCExtDataRecordNumbers 0x05 和0x10引用,这两个

客户端请求信息中DTCExtDataRecordNumber的值为0xFF,表示请求所有符合条件的记录，服务端将返回所有可用的(本例子中2个)DTCExtendedData。

与reportDTCSnapshotRecordByDTCNumber中的DTCSnapshotRecord类似，ISO14229中也未对reportDTCExtDataRecordByDTCNumber中的DTCExtDataRecord长度做强制规定，虽然本例中的长度为1个字节，但是具体长度整车厂可以自行定义,更加灵活的是，不同的DTCExtDataRecord的长度也不必完全一致(本例中都为1个字节)。

0x0A reportSupportedDTCs
这个相对比较好理解，报告所有支持的DTC，用于获取ECU支持的所有DTC

DTC有0x123456 状态码是0x24，0x234505,status：0, 0xABCD01,status:0x2F。

0x42 reportWWHOBDDTCByStatusMask
WWHOBDDTC是一种车辆故障码的标准格式,它的全称是:

World-Wide Harmonized On-Board Diagnostic Diagnostic Trouble Code

可以翻译为:全球统一的车载诊断故障码。

WWHOBDDTC规定了车辆故障码的标准化格式,目的是为了实现不同车型和不同车辆制造商之间故障码的统一和兼容。

具体来说,WWHOBDDTC格式的故障码由五个部分组成:

P - 表示故障码系统,如P0xxx表示引擎系统故障码。

B - 表示故障码种类,如P0101表示燃油系统故障码。

X - 表示故障码具体代码,如P0101表示燃油系统稀释度传感器故障。

Y - 表示故障次序,如重复故障则编号增加。

Z - 表示车系或发动机型号,如丰田卡罗拉则填写TMC。

采用这个标准格式后,无论什么车型出现什么故障码,它的含义和定位都将是统一和通用的。这对维修技术人员和故障诊断工具来说都很重要,有利于快速准确地诊断问题。WWHOBDDTC目前已成为车辆故障码的国际标准。

此示例演示了用于确认 DTC（DTC 状态掩码 08）的 reportWWWHOBDDTCByMaskRecord SubFunction 参数的用法。该车辆使用 CAN 总线连接两个排放相关服务端（ECU）。
客户端使用以下请求参数设置：
—FunctionalGroupIdentifier = 33（排放系统组），
—DTCSeverityMaskRecord.DTCSeverityMask = FF（报告具有任何严重性和类别状态的 DTC）
—DTCSeverityMaskRecord.DTCStatusMask = 08（报告已确认 DTC 状态 = ’ 的 DTC） 1’）。
服务器支持以下设置：
— FunctionGroupIdentifier = 3316（排放系统组）
— DTCStatusAvailabilityMask = FF16
— DTCSeverityAvailabilityMask = FF16
— DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_04 = 04。

在以下示例中，服务器 #1 仅报告 DTC P2522-1F A/C 请求“B” - 电路间歇性 (25221F)，因为 2F (0010 1111) 的 statusOfDTC 与客户端定义的状态掩码 08(0000 1000) 匹配。服务器 #2 报告 DTC P0235-12 涡轮增压器/增压器升压传感器“A”电路对电池短路，因为 2E(0010 1110) 的 statusOfDTC 与客户端定义的状态掩码 08(0000 1000)匹配。