目录
1.概述
2.1 DTC描述
2.1.1DTC的严重性和类的定义
2.1.2公约和定义
2.1.3DTC状态位定义
2.1.3.1 testFailed
2.1.4DTC状态位定义
2.1.5 DTC格式标识符定义
3.清除诊断信息(0x14)服务
3.1服务描述
3.2请求消息[报文]
3.2.1请求消息定义
3.2.2请求消息子函数参数$Level(LEV_)定义
3.2.3请求消息数据-参数定义
3.3肯定响应
3.3.1肯定响应消息定义
3.3.2受支持的否定响应代码(NRC_)
4.读DTC信息(0x19)服务
4.1服务描述
4.2 检索与客户端定义的状态掩码匹配的DTC数(子函数=0x01报告编号为=状态掩码)
4.3 检索与客户端定义的状态掩码匹配的dtc列表(子函数=0x02报告DTC通过状态掩码)
4.4 检索DTCS快照记录标识(子函数=0x03报告DTCS快照标识)
4.5 检索客户端定义的DTC掩码的DTCS快照记录数据(子函数=0x04报告DTCSDTC快照记录编号)
4.6 检索客户端定义的记录号的数据记录数据(子函数=0x05报告DTC存储的数据记录号)
4.7 检索客户端定义的DTC掩码和客户端定义的DTC扩展数据的数据记录数据号(子函数=0x06报告DTCExt数据记录ByDTC编号)
4.8 检索与客户端定义的严重性掩码记录匹配的DTC数(子函数=0x07报告编号的大小标记记录)
4.9 检索与客户端定义的严重性掩码记录匹配的严重性和功能单元信息(子功能=0x08报告DTC的严重性模拟记录)
4.10 检索客户端定义的DTC的严重性和功能单元信息(子功能=0x09报告严重信息)
4.11 检索第一次/最近失败的DTC(子功能=0x0B报告第一次故障DTC,子功能=0x0D报告当前当前故障DTC)
4.12 检索第一个/最近检测到的确认的DTC(子功能=0x0C报告首先确认DTC,子功能=0x0E报告首先最近确认DTC)
4.13 从与客户端定义的状态掩码匹配的服务器DTC镜像内存中检索dtc列表(子函数=0x0F报告m镜像内存由状态掩码)
4.14 从DTC镜像内存中检索客户端定义的DTC掩码和客户端定义的数据记录数据(子函数=0x10reportMirrorMemoryDTCExtDataRecordByDTCNumber)
4.15 检索与客户端定义的状态掩码匹配的镜像内存DTC数(子函数=0x11报告编号为镜像内存DTC通过状态掩码)
4.16 检索与客户端定义的状态掩码匹配的“仅与排放相关的OBD”故障诊断码的数量(子功能=0x12报告编号发射值obDDTCBy状态掩码)
4.17 检索与客户端定义的状态掩码匹配的“仅与排放相关的OBD”dtc列表(子功能=0x13报告-发射sOBDDTCBy状态掩码)
4.18 检索“预失败”的DTC状态列表(子函数=0x14报告-dtc故障检测计数器)
4.19 检索具有“永久DTC”状态的DTC列表(子功能=0x15报告-具有永久状态的DTC)
4.20 检索客户端定义的DTC扩展数据记录号的数据记录数据(子函数=0x16报告DTCExt数据记录按记录编号)
4.21 从匹配客户端定义的状态掩码的功能组中检索WWH-OBDdtc列表(子函数=0x42报告-WWHOBDDTCByMaskRecord)
4.22 检索具有“永久DTC”状态的WWH-OBDDTC列表(子功能=0x55报告-WWHOBDDTC具有永久状态)
4.23 从服务器的用户定义的DTC内存中检索与客户端定义的DTC状态掩码匹配的dtc列表(子函数=0x17报告用户删除DTC通过状态掩码)
4.24 从DTC用户定义的内存中检索客户端定义的DTC掩码和客户端定义的DTCS快照记录数据(子函数=0x18reportUserDefMemoryDTCSnapshotRecordByDTCNumber)
4.25 检索用户定义的内存中客户端定义的DTC掩码和客户端定义的数据记录数据(子函数=0x19reportUserDefMemoryDTCExtDataRecordByDTCNumber)
4.26 请求消息[报文]
4.26.1 请求消息定义
4.26.2 请求消息子函数参数$Level(LEV_)定义
4.26.2 请求消息数据-参数定义
4.27 肯定响应消息
4.27.1 肯定响应消息定义
4.27.2 肯定响应消息数据参数定义
4.28 受支持的否定响应代码(NRC_)
清除诊断信息:允许客户端清除服务器上的诊断信息(包括dtc、捕获的数据等)。
读取DTC信息:允许客户端向服务器请求诊断信息(包括dtc、捕获的数据等)。
客户端的请求消息包含一个参数。参数组ofDTC允许客户端清除一组DTC(例如,动力传动系统、车身、底盘等),或者是一个特定的DTC。详情请参见上表。除非另有说明,服务器应从所请求组的内存中清除与排放相关和非排放相关的DTC信息。
此子句定义了在读取DTC信息服务中使用的DTC状态掩码/状态中的DTC参数的映射。每个服务器应遵守下表中定义的位打包DTC状态信息的约定。应在实施标准中定义位字段的实际使用情况。
测试故障位的状态不应直接与与监控器状态相关联的故障安全行为相关联。这意味着为了触发与某个监视器的状态相关联的故障安全行为,需要维护一组单独的状态位。车辆制造商应定义是否以及如何应用和实施DTC状态和故障安全相关监控状态之间的任何同步机制。
下面是用于描述DTC状态位定义的定义列表:
Test:测试是一种车载诊断软件算法,它通常在单个操作周期内确定组件或系统的故障状态。有些测试在一个操作周期中只运行一次。其他测试可以运行每个程序循环,每隔几毫秒采样一次。测试的最终结果代表一个完全成熟/合格的条件(即通过或失败)。指需要在特定时间内出现失败条件或在组件失败之前评估额外的合理性检查的测试,只有在满足所有成熟条件之后才会返回“失败”条件。每个DTC都与一个表示可检测的故障症状的测试相关联。
Test Sample:当测试运行条件满足时,测试样本表示来自DTC测试执行的单个实例的“pass”或“fail”结果。这代表了一个单一的样本,因此通常不是一个完全成熟/合格的条件。对于支持DTC故障检测计数器的ECU,代表故障的测试样本将增加DTC故障检测计数器,而代表通过的测试样本将减少DTC故障检测计数器。
Complete:完成表明测试能够确定当前操作周期中是否存在故障或不存在故障(完成并不意味着失败)。
Test results: 当测试运行或完成后,它可能会向内部故障处理程序指示以下结果:
1.PreFailed: 此状态可用于ecu中的测试,以表明该测试目前正在成熟的故障条件。该信息的一 个用例是在制造中加快优化工作流程的故障检测,同时在现场保持容错能力。
2.Failed:此状态在测试运行到其完成后可用,并表示有一个完全成熟的失败状态。
3.Passed:此状态在测试运行到其完成后可用,并表明系统或组件没有失败。
Failure:障是指组件或系统无法满足其预期的功能。当检测到故障条件足够的时间时,会发生故障,这意味着测试返回“失败”结果。术语"failure" 和"malfunction" 是可以互换的。
Monitor:监视器由一个或多个测试组成,用于确定一个组件或系统的正常功能。
Monitoring cycle:监控周期是监视器完整运行的时间。这是制造商定义的一组条件,在此期间,监视器的测试可以运行。一个监视周期可以在一个操作周期中执行几次,或在多个操作周期中执行一次。
Operation Cycle:操作周期定义了监视器运行的开始和结束条件。在一个运行周期中,可能已完成多个监控周期(不管其测试结果如何)。一个ECU可以支持几个操作周期。对于车身和底盘ECU,由制造商确定操作周期(例如,通电和关闭ECU之间或点火打开和点火关闭之间的时间)。对于动力传动系ECU,还有一个定义操作周期的附加标准。与排放相关的动力系统ECUs使用一个发动机运行或发动机关闭的时间段来定义一个操作周期,这被称为驱动周期。如果一个DTC状态位的复位条件与操作周期的开始相关联,那么它也可以被认为是前一个周期的结束(即,并不总是能够区分每个操作周期的开始和结束)。对于与排放有关的监测人员,运行周期的开始和结束的标准由立法规定。
Pending:失败的挂起状态定义为在当前操作周期或最后一个完成的操作周期中报告此测试的“Failed”结果的测试。一旦测试报告了此失败的完整操作周期的“Passed”条件,即置状态。
Confirmation Threshold:确认的失败状态定义为在测试运行完成的给定操作周期数内为此测试报告“失败”的测试。通常对于非OBD用例,操作周期的阈值被定义为1。对于OBD用例,这个阈值通常大于1。实现可以使用Trip计数器(参见图D.9)作为的触发器将已确认的状态从0更改为1。行程计数器计数发生故障的操作周期(驱动周期)的次数。如果计数器达到阈值(例如,2个驱动周期),则确认的位从0变为1。
Aging Threshold:DTC的老化被定义为一个测试报告没有“Failed”结果为给定数量的汽车制造商或监管定义操作cylces和车辆制造商特定如果各自的周期触发增加老化计数器取决于测试是否运行完成周期。实现可以使用一个老化计数器,(见下图)作为一个触发器,将已确认的状态从1更改为0,并从非易失性存储器中删除DTC信息。老化计数器计算满足上述标准的周期次数(例如,预热周期)。如果该计数器达到阈值(例如,40个预热周期),则确认的位将从1变为0。
Driving cycle:用于与排放相关的ecu的一种特定类型的操作循环。详情请参见“操作周期”。在与排放相关的ECUs中,只支持一个运行周期,这与立法规定的驱动周期相同。
Monitor Level Enable Conditions: 允许监控器运行和报告测试结果的标准/条件。
DTC Status Update Condition: 监视器允许更新所有DTC状态位的状态(例如,控制DTCS设置类型不等于‘关闭“)。此通用条件适用于所有DTC状态位转换,触发的状态位重置除外。
DTC Storage Condition: 由车辆制造商定义的条件,指示能够更新的相关DTC状态位和相关DTC数据(如DTC扩展或快照数据)是否被更新并存储在非易失性存储器中。
该位元应表示最近执行的测试的结果。逻辑“1”应表示最后一次测试失败,表示失败已完全成熟。如果最近执行的测试结果返回“pass”结果,表示满足所有不成熟条件,则重置为逻辑“0”。额外的复位条件可以由车辆制造商/实施机构来定义
IF (initializationFlag_TF == FALSE)
Set initializationFlag_TF = TRUE
Set testFailed = 0
IF ((most recent test result == PASSED) OR
(ClearDiagnosticInformation requested == TRUE) OR
(vehicle manufacturer/implementation reset conditions satisfied))
Set testFailed = 0
ELSE IF (most recent test result == FAILED)
Set testFailed = 1
定义DTC状态位“0”测试失败的逻辑
此位应指示诊断测试是否在当前操作周期中的任何时候报告了测试失败结果(或在当前操作周期中和最后一次呼叫清除诊断信息之后报告了测试失败结果)。当启动新的操作周期或调用清除诊断信息后,重置为逻辑“0”。如果此位设置为逻辑“1”,则它将保持“1”,直到开始新的操作周期。
IF (initializationFlag_TFTOC == FALSE)
Set initializationFlag_TFTOC = TRUE
Set testFailedThisOperationCycle = 0
Set lastOperationCycle = currentOperationCycle
IF ((currentOperationCycle != lastOperationCycle) OR
(ClearDiagnosticInformation requested == TRUE))
Set lastOperationCycle = currentOperationCycle
Set testFailedThisOperationCycle = 0
ELSE IF (most recent test result == FAILED)
Set testFailedThisOperationCycle = 1
定义DTC状态位“1”测试失败此操作周期逻辑。
IF (initializationFlag_PDTC == FALSE)
Set initializationFlag_PDTC = TRUE
Set pendingDTC = 0
IF (ClearDiagnosticInformation requested == TRUE)
Set pendingDTC = 0
ELSE IF (most recent test result == FAILED)
Set pendingDTC = 1
ELSE IF ((currentOperationCycle == stop) AND
(testNotCompletedThisOperationCycle == 0) AND
(testFailedThisOperationCycle == 0))
Set pendingDTC = 0
定义DTC状态位“2”挂起DTC逻辑
2.1.3.4 confirmedDTC
该位应指示是否检测到故障足够的时间,以保证希望DTC存储在长期内存中。已确认的DTC并不总是表明在请求时存在故障。(测试失败可用于确定在发出请求时是否存在故障)。在调用清除诊断信息或满足老化阈值后,重置为逻辑“0”(例如,40个发动机预热而没有检测到其他故障)。此外,当与此DTC相关的故障记录被根据车辆制造商特定的故障内存溢出要求的新DTC覆盖时,此位将被重置。DTC确认阈值和老化阈值由车辆制造商定义,或由车载诊断法规强制规定。
IF (initializationFlag_CDTC == FALSE)
Set initializationFlag_CDTC = TRUE
Set confirmedDTC = 0
Set confirmStage = INITIAL_MONITOR
IF (confirmStage == INITIAL_MONITOR)
IF (confirmation threshold == TRUE)
Set confirmedDTC = 1
Reset aging status
Set confirmStage = AGING_MONITOR
ELSE
Set confirmedDTC = 0
IF (confirmStage == AGING_MONITOR)
IF ((ClearDiagnosticInformation requested == TRUE) OR
(aging threshold satisfied == TRUE))
Set confirmedDTC = 0
Set confirmStage = INITIAL_MONITOR
ELSE IF (most recent test result == FAILED)
Reset aging status
ELSE
Update aging status as appropriate
定义DTC状态位“3”已确认的DTC逻辑
IF (initializationFlag_TNCSLC == FALSE)
Set initializationFlag_TNCSLC = TRUE
Set testNotCompletedSinceLastClear = 1
IF (ClearDiagnosticInformation requested = TRUE)
Set testNotCompletedSinceLastClear = 1
ELSE IF ((most recent test result = PASSED) OR (most recent test result =
FAILED))
Set testNotCompletedSinceLastClear = 0
定义DTC状态位“4”测试未完成逻辑
2.1.3.6 testFailedSinceLastClear
此位应指示自上次调用清除诊断信息以来,DTC测试是否已完成,但结果失败(即,这是一个锁定测试失败,此操作周期=‘1’)。零(“0”)应表示测试未运行或DTC测试已运行并通过(但从未失败)。如果测试运行并失败,则钻头应保持锁定在“1”处。车辆制造商有责任指定该位是通过老化标准复位还是由于故障内存溢出而复位。
IF (initializationFlag_TFSLC == FALSE)
Set initializationFlag_TFSLC = TRUE
Set testFailedSinceLastClear = 0
IF (ClearDiagnosticInformation requested == TRUE)
/* optional: OR (aging threshold satisfied == TRUE)
/* optional: OR (overflow criteria satisfied == TRUE)
Set testFailedSinceLastClear = 0
ELSE IF (most recent test result == FAILED)
Set testFailedSinceLastClear = 1
定义DTC状态位“5”测试失败,包括DTC清除逻辑
2.1.3.7 testNotCompletedThisOperationCycle
该位应指示DTC测试是否曾在当前运行周期中运行和完成(或在最后一次调用清除诊断信息后在当前运行周期中完成)。逻辑“1”应表示DTC测试在当前运行周期中尚未运行到完成。如果测试运行并通过或失败,则位应设置(并锁定)为“0”,直到新的操作周期开始。
IF (initializationFlag_TNCTOC == FALSE)
Set initializationFlag_TNCTOC = TRUE
Set testNotCompletedThisOperationCycle = 1
Set lastOperationCycle = currentOperationCycle
IF (ClearDiagnosticInformation requested == TRUE)
Set testNotCompletedThisOperationCycle = 1
ELSE IF (currentOperationCycle != lastOperationCycle)
Set lastOperationCycle = currentOperationCycle
Set testNotCompletedThisOperationCycle = 1
ELSE IF ((most recent test result == PASSED) OR
(most recent test result == FAILED))
Set testNotCompletedThisOperationCycle = 0
定义DTC状态位“6”测试未完成此操作循环逻辑
在调用以清除诊断信息后,请重置为逻辑“0”。某些ecu可能会锁定当前操作周期中与特定已确认的故障相关联的故障安全策略。如果在调用清除诊断信息后,由于此锁存的故障安全而仍然请求警告指示器,则不应将此位清除为逻辑“0”。相反,这个位将保持设置为逻辑“1”,直到故障安全策略不再活动(例如,测试完成并通过)。其他复位条件应由车辆制造商/实施机构确定。
IF (initializationFlag_WIR == FALSE)
Set initializationFlag_WIR = TRUE
Set warningIndicatorRequested = 0
IF (((ClearDiagnosticInformation requested == TRUE) OR (TestResult == Passed)
OR (vehicle manufacturer or implementation-specific warning indicator
disable criteria are satisfied))
AND ((warning indicator not requested on due to latched failsafe for
particular DTC) OR (warning indicator not requested on by legislation)))
Set warningIndicatorRequested = 0
ELSE IF (((TestResult == Failed) AND (warning indicator exists for the
particular DTC)
AND ((confirmedDTC == 1)
OR (vehicle manufacturer or implementation-specific warning indicator
enable criteria are satisfied)))
Set warningIndicatorRequested = 1
定义DTC状态位“7”警告指示器请求的逻辑
该字节包含DTC的严重性和DTC的类信息。DTCSeverityMask/DTCSeeverity字节以上表中定义的1字节值报告。1字节值的可选上3位(第7-5位)用于表示DTC的严重性信息。如果服务器不支持,则这些位应设置为“0”。1字节值的强制下5位(第4-0位)用于表示DTC类信息。
DTC严重性位定义定义了位状态,以报告系统(例如车辆)操作员要采取的建议操作。上表中定义了DTC的严重性状态位。
此参数值定义了服务器报告的DTC的格式。一个给定的服务器应只支持一个DTC格式标识符。
1. 0x00 SAE_J2012-DA_DTCFormat_00 :此参数值标识服务器在ISO15031-6规范中定义的所报告的DTC格式。
2.0x01 ISO_14229-1_DTCFormat :此参数值标识服务器报告的由参数DTC表中定义的DTC格式。
3.0x02 SAE_J1939-73_DTCFormat :此参数值标识了在SAEJ1939-73中定义的服务器报告的DTC格式。
4.0x03 ISO_11992-4_DTCFormat :此参数值标识了在ISO11992-4规范中定义的服务器报告的DTC格式。
5.0x04 SAE_J2012-DA_DTCFormat_04 :此参数值标识了在ISO27145-2规范中定义的服务器报告的DTC格式。
6.0x05-0xFF ISO/SAE reserved :此文档保留此值以供将来定义。
客户端使用清除诊断信息服务来清除一个或多个服务器内存中的诊断信息。
当清除诊断信息服务完成处理时,服务器应发送积极响应。即使没有存储dtc,服务器也应发送肯定响应。如果服务器支持内存中多个DTC状态信息的副本(例如RAM的一个副本和EEPROM的一个副本),服务器应清除ReadDTC信息状态报告服务使用的副本。其他副本,例如长期内存中的备份副本,会根据适当的备份策略进行更新(例如在电源锁存阶段)。如果电源锁存器相位受到干扰(例如,电池在电源锁存器相位中断开连接),这可能会导致数据不一致。
通过此服务重置/清除的DTC信息包括但不限于以下内容:
1.DTC状态字节
2.捕获的DTC快照数据
3.捕获的DTC扩展数据
4.其他DTC相关数据,如第一/最近的DTC、标志、计数器、计时器等。特定于dtc的
存储在服务器中可选使用的DTC镜像内存中的任何DTC信息都不受此服务的影响。
此服务不使用任何子函数参数。
本服务应执行以下否定响应代码。下表记录了每个响应代码发生的情况。如果错误场景适用于服务器,则应使用所列出的否定响应。
NRC处理清晰的诊断信息服务
此服务允许客户端从任何服务器或车辆内的服务器组读取服务器驻留的诊断故障代码(DTC)信息的状态。除非特定的子功能另有要求,服务器应返回所有的DTC信息(例如,与排放相关的和非排放相关的)。此服务允许客户端执行以下操作:
1.检索与客户端定义的DTC状态掩码相匹配的dtc数量。
2.检索与客户端定义的DTC状态掩码相匹配的所有dtc的列表。
3.检索匹配客户端定义的DTC状态掩码的特定功能组中的dtc列表。
4.检索所有具有“永久DTC”状态的dtc。
5.检索与客户端定义的DTC相关联的DTCs快照数据(有时称为冻结帧):DTC快照是与DTC相关联的特定数据记录,它们存储在服务器的内存中。DTC快照的典型用法是在检测到系统故障时存储数据。DTC快照将作为来自系统故障发生时的数据值的快照。存储在DTC快照中的数据参数应与DTC进行关联。DTC特定的数据参数旨在简化技术人员的故障隔离过程。
6.从DTC内存或DTC镜像内存中检索与客户端定义的DTC和状态掩码组合相关联的数据。数据由与DTC关联的扩展状态信息组成。数据包含DTC参数值,它们在请求时已被识别。数据的典型用途是存储与DTC相关的动态数据。
7.DTCB1故障指示器计数器,表示OBD系统在故障激活时运行的时间(发动机运行小时数)。
8.DTC发生计数器,计数已报告的“测试失败”的驾驶周期数。
9.DTC老化计数器,计数故障最近失败后的驾驶周期数,不包括测试未报告“测试通过”或“测试失败”的驾驶周期。
10.OBD的特定计数器(例如,如果可以在无故障模式下执行驱动循环,则在“检查发动机”灯关闭之前剩余的驱动周期数)。
11.最后一次发生的时间(等)。
12.测试失败的计数器,报告的“测试失败”的计数数和可能的其他计数器。
13.未完成的测试计数器,计数自测试最近完成以来的驾驶周期数(即,由于测试报告“测试通过” 或“测试失败”)。
14.检索与客户端定义的严重性掩码相匹配的dtc的数量。
15.检索与客户端定义的严重性掩码记录相匹配的dtc列表。
16.检索客户端定义的DTC的严重性信息。
17.检索服务器支持的所有dtc的状态。
18.检索服务器失败的第一个DTC。
19.在服务器内检索最近失败的DTC。
20.检索由服务器确认的第一个DTC。
21.在服务器内检索最近确认的DTC。
22.从与客户端定义的DTC状态掩码相匹配的DTC镜像内存中检索dtc列表。
23.从DTC镜像内存中检索客户端定义的DTC掩码和客户端定义的DTC扩展器的数据记录号的数据记录数据。
24.从符合客户端定义的DTC状态掩码的DTC镜像内存中检索匹配的DTC数。
25.检索与客户端定义的DTC状态掩码相匹配的“仅”与排放相关的OBDdtc的数量。与排放相关的OBDdtc会导致故障指示器被打开/显示一条消息。
26.检索与客户端定义的DTC状态掩码相匹配的“仅”与排放相关的OBDdtc的状态。与排放相关的OBDdtc会导致故障指示器被打开/显示一条消息。
27.检索所有已经或尚未被检测为“待定”或“已确认”的当前“预失败”dtc。
28.从DTC内存中检索与客户端定义的DTC扩展数据记录状态关联的数据。
29.从与客户端定义的DTC状态掩码相匹配的用户定义的DTC内存中检索dtc列表。
30.从用户定义的DTC镜像内存中检索用户定义的DTC内存掩码和客户端定义的DTC掩码和客户端定义的DTC的数据记录数据。
31.从用户定义的DTC内存中检索客户端定义的DTC掩码的用户定义的DTC内存的记录数据。
此服务使用子函数来确定客户端请求的类型的诊断信息。关于每个子函数参数的进一步细节将在以下子条款中提供。
本服务使用了以下条款:
1.Enable Criteria:服务器/车辆制造商/系统供应商的特定标准,用于控制服务器何时实际执行特定的内部诊断。
2.Test Pass Criteria:服务器/车辆制造商/系统供应商的特定条件,定义一个被诊断的系统是否在正常、可接受的操作范围内正常运行(例如,不存在故障,被诊断的系统被归类为“正常”)。
3.Test Failure Criteria:服务器/车辆制造商/系统供应商的特定故障条件,定义了被诊断的系统是否未能通过测试。
4.Confirmed Failure Criteria:服务器/车辆制造商/系统供应商的特定故障条件,它定义了被诊断的系统是否确实存在问题(已确认),从而保证将DTC记录存储在长期内存中。
5.Occurrence Counter:由某些服务器维护的一种计数器,它记录给定的DTC测试报告的唯一发生测试失败的实例数。
6.Aging:一种过程,其中某些服务器评估每个内部诊断的过去结果,以确定已确定的DTC是否可以从长期内存中清除,例如,在校准的无故障周期数的情况下。
一个给定的DTC值(例如,0x080511)不得在对读取DTC信息的积极响应中报告超过一次,除了读取DTCC快照记录,其中响应可能包含同一DTC的多个DTCS快照记录。
当使用页面缓冲区处理读取故障诊断码时(特别是对于子函数=报告DTCBy状态掩码),在创建响应时,故障诊断码的数量可能会减少。在这种情况下,响应应填写DTC0x000000和DTC状态0x00。客户应将这些dtc视为在响应消息中不存在。
客户端可以通过将子函数设置为reportNumberOfDTCByStatusMask.的该服务发送请求来检索与客户端定义的状态掩码匹配的dtc数对此请求的响应包含DTCStatusAvailabilityMask,,它提供了服务器支持的用于屏蔽目的的DTC状态位的指示。在DTC状态可用性掩码之后,响应包含DTC格式标识符,它报告有关DTC格式和编码的信息。DTC格式标识符后面是DTCCount参数,这是一个2字节的无符号数字,包含基于客户端提供的状态掩码的服务器内存中可用的DTC数量。
子函数reportNumberOfMirrorMemoryDTCByStatusMask与子函数reportNumberOfDTCByStatusMask具有相同的功能,不同之处在于它返回DTC镜像内存中返回dtc的数量。
客户端可以通过发送一个子函数字节设置为报告的status掩码的请求来满足客户端定义的状态掩码。这个子功能允许客户端请求服务器报告“测试失败”或“确认为“或”等的所有dtc。
评估应如下:服务器应在客户端请求中指定的掩码与服务器支持的每个DTC相关的实际状态之间执行位逻辑与操作。除DTCStatusAvailabilityMask,之外,服务器还应返回所有与操作结果非零的DTC(即(DTC和DTC状态掩码)!=0)。如果客户端指定了一个包含服务器不支持的位的状态掩码,则服务器应仅使用它所支持的位来处理DTC信息。如果服务器内没有dtc匹配掩蔽条件在客户端请求中指定的是,不得在正响应消息中的DTC状态可用性掩码字节之后提供任何DTC或状态信息。
在客户端成功发出DTC状态诊断信息请求时,应清除DTC状态信息(在服务器中接收到DTC诊断信息服务请求时,关于DTC状态位处理的进一步描述,(请参见下图中的DTC状态位定义)。
客户端可以通过发送一个将子函数设置为reportDTCSnapshotIdentification.的对此服务的请求,来检索所有捕获的DTCS快照记录的DTCS快照记录标识信息服务器应返回所有存储的DTCS快照记录的DTCS快照记录标识信息列表。服务器在单个DTCS快照记录的响应消息中的每个项应包含DTCRecord(包含DTC编号(高、中、低字节))和DTCS快照记录编号。如果为单个DTC存储了多个DTCS快照记录,那么服务器应在每次事件的响应中放置一个项,为每次事件使用不同的DTCS快照记录号(用于以后检索记录数据)。
服务器可以支持为单个DTC存储多个DTCS快照记录,以跟踪每次DTC出现时出现的条件。支持此功能、“发生”标准的定义以及要支持的DTCS快照记录的数量应由系统供应商/车辆制造商来定义。
应根据客户的成功请求清除DTCS快照记录识别信息。车辆制造商负责指定删除存储溢出(内存空间完全占用存储Dtc和DTCS快照数据)时存储Dtc和DTCS快照数据的规则。
客户端可以通过发送子函数设置为reportDTCSnapshotRecordByDTCNumber.的此服务请求,为客户端定义的DTCMask记录号一起检索捕获的DTCS快照记录数据服务器应在其支持的dtc中搜索与客户端指定的DTCMask记录(包含DTC号(高、中、低字节))的精确匹配。客户端请求中提供的DTCS快照记录数参数应指定正在请求DTCS快照记录数据的指定DTC的特定出现情况。
DTCS快照和记录号码不与数据记录号码共享相同的地址空间。
如果服务器支持为单个DTC存储多个DTCS快照记录(支持此功能将由系统供应商/车辆制造商定义),则建议服务器同时实现reportDTCSnapshotIdentification子功能参数。建议客户端首先请求识别使用子函数参数reportDTCSnapshotIdentification存储的DTCS快照记录,然后通过reportDTCSnapshotRecordByDTCNumber请求请求一个特定的DTCS快照记录号。
还建议支持子函数参数reportDTCSnapshotRecordIdentification,以便让客户机有机会直接识别存储的DTCS快照记录,而不是通过服务器的所有存储dtc进行解析,以确定是否存储了DTCS快照记录。
系统供应商/车辆制造商有责任定义在这些服务器中捕获的DTCS快照记录是否存储与故障发生信息相关的数据,作为ECU文件的一部分。
如果客户端定义的DTCMask记录和DTCS快照记录数参数(DTCSDTC和记录编号不等于0xFF),服务器应返回单个预定义的DTCS快照记录。
确切的故障标准应由系统供应商/车辆制造商确定。
DTCS快照记录可能包含多个数据参数,可用于重建故障发生时的车辆状况(例如,B+、RPM、时间戳)。
车辆制造商应定义该数据采集记录的格式和内容。在dtcs网络网络记录中报告的数据首先包含一个数据标识符,以标识下面的数据。这个数据标识符/数据组合可以在dtcs快照记录中重复。在DTCS快照记录中使用一个或多个数据标识符允许为不同的故障发生DTC存储不同类型的DTCS快照记录。每个DTCS快照记录应提供一个参数,指示每个DTCS快照记录中包含的记录数据标识符的数量,以协助数据检索。
服务器应在单个响应消息中报告一条DTCS快照记录,但客户端已将DTCS快照记录数设置为0xFF,因为这将导致服务器在单个响应消息中响应为客户端定义的DTCMask记录存储的所有DTCS快照记录。DTC和n状态记录只包含在响应消息中一次。如果客户端在其请求中对参数DTCS快照记录数使用了0xFF,则服务器应按数字升序报告为特定DTC捕获的所有DTCS快照记录。
如果客户端指定的DTCMask记录或DTCS网络记录数参数无效或服务器不支持,则服务器应进行负响应。这将区别于客户端指定的DTCMask记录和/或DTCS快照记录数参数确实有效且服务器支持,但没有与之关联的DTCS快照数据(例如,因为指定的DTC或记录号从未发生过故障事件)。服务器应发送只包含DTCand状态记录(响应所请求的DTC号(高、中、低字节)和DTC状态)的肯定响应。
在客户成功请求清除诊断信息时,应清除DTCS快照信息。车辆制造商负责指定在内存溢出(服务器中存储dtc和DTC快照数据的内存空间)时删除存储dtc和DTCC快照数据的规则。
客户端可以通过发送一个将子函数设置为reportDTCStoredDataByRecordNumber.的此服务的请求,来检索捕获的DTC存储器的数据记录数据服务器应搜索其存储的dtc存储数据记录,以确定与客户端提供的记录编号是否匹配。
DTC存储号与DTCSNAP和记录号不共享相同的地址空间。
系统供应商/车辆制造商有责任定义在该等服务器中捕获的dtc存储数据记录是否存储与第一次或最近发生故障相关的数据。
确切的故障标准应由系统供应商/车辆制造商确定。
dtc存储数据记录可能包含多个数据参数,可用于重构故障发生时的车辆状况(如B+、RPM、时间戳)。
车辆制造商应定义dtc存储器和数据记录器编号的格式和内容。在数据数据记录中报告的数据首先包含一个数据标识符来标识下面的数据。这个数据标识符/数据组合可以在dtc存储的数据记录中重复。在DTC存储数据记录中使用一个或多个数据标识符允许为不同的故障发生为一个DTC存储不同类型的DTC存储数据记录。每个数据存储数据记录中应包含一个参数,指示每个数据存储数据记录中包含的记录数据标识符的数量,以协助数据检索。
服务器应在单个响应消息中报告一个DTC存储器数据记录,但客户端已将DTC存储器数据记录号设置为0xFF,因为这将导致服务器响应存储在单个响应消息中的所有DTC存储器数据记录。
如果客户端请求按记录号报告所有DTC存储数据记录,则必须在每个存储的响应消息中重复DTC存储数据记录。
如果客户端指定的dtc存储器数据记录数参数无效或服务器不支持,则服务器应进行否定响应。这与客户端指定的数据记录号参数确实有效且由服务器支持,但没有与之关联的数据数据记录数据的情况有所不同(例如,因为指定的记录号从未发生过故障事件)。服务器应发送只包含DTC存储器数据记录号的肯定响应(与所请求的记录号的肯定响应)。
根据客户的清除诊断信息请求成功,应清除数据记录信息。车辆制造商在内存溢出的情况下,有责任规定已存储DTC和已存储数据的删除规则。
客户端可以通过发送子函数设置为reportDTCExtDataRecordByDTCNumber.的此服务请求,来检索客户端定义的扩展扩展记录和DTC扩展数据记录号的DTC扩展数据服务器应在其支持的dtc中搜索与客户端指定的DTCMask记录(包含DTC号(高、中、低字节))的精确匹配。在这种情况下,客户端请求中提供的DTC扩展数据记录数参数应指定正在请求DTC扩展数据的指定DTC的特定DTC扩展数据记录。
连同DTC号和DTC状态,服务器应返回一个预定义的DTC扩展数据记录,以响应客户端的请求(DTCExt数据记录号不等于0xFE或0xFF)。
车辆制造商应定义DTC出口数据记录的格式和内容。DTCExt数据记录中报告的数据的结构由DTCExt数据记录号定义,其方式与记录数据标识符中的数据定义类似。响应中可能包含多个DTCExt数据记录号和相关的DTCExt数据记录。使用一个或多个DTCExt数据记录号允许为单个DTC存储不同类型的DTCExt数据记录。
服务器应在单个响应消息中报告一个DTC扩展数据记录,但客户端已将DTCExtDAT记录数设置为0xFE或0xFF,因为这将导致服务器在单个响应消息中响应为客户端定义的DTC扩展记录存储的所有数据记录。
如果客户端指定的DTCMask记录或DTCExt数据记录数参数无效或服务器不支持,则服务器应进行否定响应。这包括客户端发送的DTCExt数据记录数为0xFE的情况,但服务器不支持OBD扩展数据记录(0x90-0xEF)。这与客户端指定的DTCMask记录和/或DTCExt数据记录数参数确实是有效的并且由服务器支持,但没有与其关联的DTC扩展数据(例如,由于扩展数据的内存溢出)的情况有所不同。如果是reportDTCExtDataRecordByDTCNumber,服务器应发送只包含DTC和n状态记录(请求的DTC号(高、中、低字节)和DTC状态)的肯定响应。
车辆制造商有责任指定在内存溢出时删除存储dtc和DTC扩展数据的存储dtc和DTC扩展数据的规则。
客户端可以通过将子函数设置为reportNumberOfDTCBySeverityMaskRecord.的此服务请求来检索与客户端定义的严重状态掩码记录匹配的dtc数服务器应扫描所有受支持的dtc,在客户端指定的掩码记录与每个存储的DTC的实际信息之间执行位级逻辑与化操作。
(((statusOfDTC & DTCStatusMask) != 0) && ((severity & DTCSeverityMask) != 0)) == TRUE
对于每个产生真实结果的与操作,服务器应将计数器增加1。如果客户端在掩码记录中指定了一个包含服务器不支持的位的状态掩码,则服务器应仅使用它所支持的位来处理DTC信息。一旦检查了所有支持的DTC一次,服务器将向客户端返回DTC状态可用性掩码,并返回由此产生的2字节计数。
如果服务器内没有dtc与客户端请求中指定的屏蔽条件相匹配,则服务器返回给客户端的计数应为0。报告的与DTC状态掩码相匹配的dtc数量对于发出请求时的时间点有效。报告的DTC数量与通过子功能报告DTCBy统计读取的实际DTC列表之间没有关系,因为读取DTC的请求是在不同的时间点完成的。
客户端可以检索DTC严重性和功能单元信息的列表,通过发送一个将子函数字节设置为reportDTCBySeverityMaskRecord.的请求,从而满足客户端定义的严重性掩码记录这个子功能允许客户端请求服务器报告所有具有一定严重性和状态为“测试失败”或“或”等的dtc。评估应按如下方式进行:
服务器应在客户端请求中指定的DTCS级别掩码和实际的DTC状态掩码以及与服务器支持的每个DTC关联的实际DTCS级别和状态之间执行位级逻辑和化操作。
除DTCStatusAvailabilityMask,服务器外,应返回与操作结果为真的所有dtc外。
客户端可以通过发送具有子功能设置为reportSeverityInformationOfDTC.的对此服务的请求来检索客户端定义的DTCMask记录的严重性和功能单元信息服务器应在其支持的dtc中搜索与客户端指定的DTCMask记录(包含DTC号(高、中、低字节))的精确匹配。
客户端可以通过发送对此服务的请求,并将子功能设置为报告“已支持的dtc”,来检索服务器支持的所有dtc的状态。对此请求的响应包含DTCStatusAvailabilityMask,,它提供了服务器支持的用于屏蔽目的的DTC状态位的指示。在DTC状态可用性掩码之后,响应还包含DTC和状态记录列表,其中包含服务器支持的每个诊断故障代码的DTC号和相关状态。
客户端可以通过发送子函数字节设置为“报告DTC”或“报告”的请求,从服务器检索第一个/最近失败的DTC。与DTCStatusAvailabilityMask,一起,服务器应将第一个或最近失败的DTC号和相关状态返回给客户端。
如果自客户端上次请求服务器清除诊断信息以来没有记录故障DTC,则不应在正响应消息中的DTC状态可用性字节之后提供DTC/状态信息。此外,如果自上次客户端请求服务器清除诊断信息以来,只有一个DTC失败,则一个失败的DTC将返回给第一个报告和来自客户端的reportMostRecentTestFailedDTC请求。
第一次/最近失败DTC的记录应独立于确认dtc的老化过程。
如上所述,在客户端发出成功的DTC诊断信息请求时,应清除第一个/最近失败的DTC信息(在服务器中接收到DTC诊断信息服务请求时的DTC状态位定义,请参见D.2中关于DTC状态位处理的进一步描述)。
客户端可以通过发送子函数字节设置为“报告首次确认”的请求,从服务器检索第一个/最近确认的DTC。与DTCStatusAvailabilityMask,一起,服务器应返回第一个或最近确认的DTC号和相关状态给客户端。
如果自客户端上次请求服务器清除诊断信息以来没有记录已确认的DTC,则不应在正响应消息中的DTC状态可用性屏蔽字节之后提供DTC/状态信息。此外,如果自上次客户端请求服务器清除诊断信息以来,只有1个DTC被确认,则一个被确认的DTC将返回给来自客户端的报告第一确认DTC和reportMostRecentConfirmedDTC请求。
第一个确认DTC的记录应保存在DTC失败的过去,但随后满足老化标准之前的时间请求的客户端(无论任何其他dtc成为确认上述DTC成为确认)。同样,最近确认的DTC的记录应保存在过去确认,但随后满足客户请求之前的老化标准(假设没有其他dtc在上述DTC失败后得到确认)。
如上所述,在客户提出成功的明确诊断信息请求时,应清除第一次/最近确认的DTC信息。
子函数reportMirrorMemoryDTCByStatusMask的处理与为报告DTC的状态掩码定义的处理相同,除了所有的状态掩码检查都是使用存储在服务器的DTC镜像内存中的DTC执行的。DTC镜像内存是服务器中的另一个可选错误内存,清除诊断信息(0x14)服务无法擦除它。DTC镜像内存镜像正常DTC内存,可以使用正常错误内存。
子函数reportMirrorMemoryDTCExtDataRecordByDTCNumber的处理与为reportDTCExtDataRecordByDTCNumber,定义的处理相同,只是数据是从DTC镜像内存中检索出来的。DTC镜像内存是服务器中的另一个可选错误内存,清除诊断信息(0x14)服务无法擦除它。DTC镜像内存镜像正常DTC内存,可以使用正常错误内存。
客户端可以通过将子函数设置为reportNumberOfMirrorMemoryDTCByStatusMask.的此服务请求来检索与客户端定义的状态掩码匹配的镜像内存dtc数量的计数对此请求的响应包含DTCStatusAvailabilityMask,,它提供了服务器支持的用于屏蔽目的的DTC状态位的指示。在DTC状态可用性掩码之后,响应包含DTC格式标识符,它报告有关DTC格式和编码的信息。DTC格式标识符后面是DTCCount参数,这是一个2字节的无符号数字,根据客户端提供的状态掩码包含服务器内存中可用的DTC数量。
客户端可以通过将子函数设置为reportNumberOfEmissionsOBDDTCByStatusMask.的此服务请求,检索与客户端定义的状态掩码匹配的“仅与排放相关的OBD”dtc的数量对此请求的响应包含DTCStatusAvailabilityMask,,它提供了服务器支持的用于屏蔽目的的DTC状态位的指示。在DTC状态可用性掩码之后,响应包含DTC格式标识符,它报告有关DTC格式和编码的信息。DTC格式标识符后面是DTCCount参数,该参数是一个2字节的无符号数字,其中包含基于客户端提供的状态掩码,在服务器内存中可用的“仅与排放相关的OBD”DTC的数量。
客户端可以检索一个“仅与排放相关的OBD”dtc列表,它们通过发送一个将子函数字节设置为reportEmissionsOBDDTCByStatusMask.的请求来满足客户端定义的状态掩码这个子功能允许客户端请求服务器报告所有“测试失败”或“确认”“或“等的OBD”dtc。评估应按照如下方式进行:服务器应在客户端请求中指定的掩码与服务器支持的每个“排放相关OBD”DTC相关的实际状态之间执行位级逻辑与化操作。除DTCStatusAvailabilityMask,外,服务器还应返回所有与零的“排放相关的OBD”DTC(即(DTC和DTC状态掩码)!=0)。如果客户端指定了一个包含服务器不支持的位的状态掩码,则服务器应仅使用它所支持的位来处理DTC信息。如果服务器内没有“与排放相关的OBD”DTC与客户端请求中指定的屏蔽条件相匹配,则不应在正响应消息中的DTC状态可用性屏蔽字节之后提供任何DTC或状态信息。
在客户端发出成功的DTC诊断信息请求时,应清除“排放相关的OBD”DTC状态信息(在服务器中接收到DTC诊断信息服务请求时的DTC状态位定义。
客户端可以检索所有当前“预失败”dtc的列表,这些dtc在客户端请求时已被检测为“挂起”或“确认”。DTC故障检测计数器的目的是一种简单的方法,可以识别一个特定DTC的状态无法识别/读取DTC字节的不断增长或间歇性问题。故障检测计数器的内部实施应特定于车辆制造商。“预失败”dtc的用例是在制造工厂的测试期间加快故障检测,这需要制造测试不可接受的成熟时间。在修复或安装新组件后,服务也有类似的用例。
客户端可以检索“永久DTC”状态的dtc列表。
客户端可以通过将子函数设置为reportDTCExtDataRecordByRecordNumber.发送此服务的请求,检索客户端定义的DTC扩展数据记录号服务器应搜索所有支持的dtc,以确定与客户端指定的DTCExt数据记录号的准确匹配。在这种情况下,客户端请求中提供的DTCExt数据记录数参数应为正在被请求的所有受支持的DTC指定一个特定的DTC扩展数据记录。
服务器应返回一个DTC扩展数据记录,以及每个受支持的DTC的DTC号和状态,其中包含所请求的DTCExt数据记录号的数据。
车辆制造商应定义DTC出口数据记录的格式和内容。DTCExt数据记录中报告的数据的结构由DTCExt数据记录号定义,其方式与记录数据标识符中的数据定义类似。
如果客户端指定的DTCExtData记录数参数无效或服务器不支持,则服务器应进行负响应。
接收确定诊断信息服务时的数据信息的清除规定。车辆制造商有责任指定在内存溢出时删除存储dtc和DTC扩展数据的存储dtc和DTC扩展数据)的规则。
面具(具有严重级别和级别)的实现和使用在ISO°27145-3[17]中定义。
客户端可以检索具有“永久DTC”状态的WWH-OBDdtc列表。
客户端可以从用户定义的内存中检索dtc列表,它通过发送一个将子函数字节设置为reportUserDefMemoryDTCByStatusMask.的请求来满足客户端定义的状态掩码这个子函数允许客户端请求服务器报告所有“测试失败”或“确认为“或”等的dtc。来自用户定义的内存。
评估应按照如下方式进行:服务器应在客户端请求中指定的掩码与服务器在该用户定义的内存中支持的每个DTC相关的实际状态之间执行位级逻辑与化操作。除DTCStatusAvailabilityMask,之外,服务器还应返回该特定内存中与操作结果非零(即(状态DTC和DTC状态掩码)!=0)的所有DTC。如果客户端指定了一个包含服务器不支持的位的状态掩码,则服务器应仅使用它所支持的位来处理DTC信息。如果服务器内没有DTC匹配该特定内存中客户端请求中指定的屏蔽条件,则不应在正响应消息中的DTC状态可用性屏蔽字节之后提供任何DTC或状态信息。
DTC状态信息不应在客户的成功请求下清除清除诊断信息,而应由制造商特定的常规控制清除。
客户端可以通过发送子函数设置为reportUserDefMemoryDTCSnapshotRecordByDTCNumber.的此服务请求,检索客户端定义的DTCS快照记录号和用户定义的DTCS快照记录数据服务器应在其支持的dtc中搜索与客户端指定的DTCMask记录(包含DTC号(高、中、低字节))的精确匹配。客户端请求中提供的DTCS快照记录数参数应指定指定DTC的特定出现情况和正在请求DTCS快照记录数据的已定义内存。
DTCS快照和记录器号与DTC存储器和数据记录器号不共享相同的地址空间。
系统供应商/车辆制造商有责任定义在这些服务器中捕获的DTCS快照记录是否存储与第一次或最近发生故障相关的数据。
如果对客户端定义的DTC,服务器应返回一个预定义的DTCSNES记录数参数和DTCS的故障,以响应客户端的请求。
确切的故障标准应由系统供应商/车辆制造商确定。
DTCS快照记录可能包含多个数据参数,可用于重建故障发生时的车辆状况(例如,B+、RPM、时间戳)。
车辆制造商应在用户定义的内存中定义DTCS快照记录的格式和内容(即DTCS快照记录的内容可能是不同的内存记录)的格式和内容。在dtcs网络网络记录中报告的数据首先包含一个数据标识符,以标识下面的数据。这个数据标识符/数据组合可以在dtcs快照记录中重复。在用户定义的内存中使用DTCS快照记录中的一个或多个数据标识符允许为不同的故障发生DTC存储不同类型的DTCS快照记录。每个DTCS快照记录应提供一个参数,指示每个DTCS快照记录中包含的记录数据标识符的数量,以协助数据检索。
服务器应在单个响应消息中报告一个DTCS快照记录,但客户端已设置DTCS快照记录数为0xFF,因为这将导致服务器响应客户端定义的所有DTCS快照记录和用户定义的响应消息。DTC和n状态记录只包含在响应消息中一次。
如果客户端指定的DTCMask记录、DTCS网照记录号、用户内存参数无效或服务器不支持,服务器应进行负响应。这是区别于DTCMask记录和/或DTCS快照记录数参数指定的客户端确实是有效的和服务器支持的特定内存,但没有相关的DTCS快照数据(例如,因为失败事件发生指定的DTC或记录号码)。服务器应发送只包含DTCand状态记录(所请求的DTC号(高、中、低字节)的回声加上DTC的状态)的正响应。
DTCS快照信息应根据客户提出的制造商特定条件(如常规控制)要求进行清除。车辆制造商有责任指定在存储溢出时删除存储Dtc和DTCS快照数据的存储Dtc和DTC快照数据的规则。
客户端可以通过发送子函数设置为reportUserDefMemoryDTCExtDataRecordByDTCNumber.的此服务请求,检索客户端定义的数据、DTC扩展数据记录号和用户的DTC扩展数据服务器应在其支持的dtc中搜索与客户端指定的DTC记录(包含DTC号(高、中、低字节))和用户的内存标识符的精确匹配。在这种情况下,客户端请求中提供的DTC扩展数据记录数参数应指定正在请求DTC扩展数据的指定DTC的特定DTC扩展数据记录。
除了DTC号和DTC状态,服务器应返回一个预定义的DTC扩展数据记录,以响应客户端的请求(DTCExt数据记录号不等于0xFE或0xFF)。
车辆制造商应定义用户定义数据记录的格式和内容。DTCExt数据记录中报告的数据的结构由特定用户定义的内存定义,其方式与记录数据标识符中的数据定义类似。响应中可能包含多个DTCExt数据记录号和相关的DTCExt数据记录。使用一个或多个DTCExt数据记录号允许为单个DTC存储不同类型的DTCExt数据记录。
服务器应报告一个DTC扩展D数据记录,除了客户端设置DTCExT数据记录编号0xFE或0xFF,因为这将导致服务器响应所有DTC扩展数据记录的用户定义的内存存储在一个响应消息。
如果客户端指定的DTCMask记录或DTCExtData记录数参数无效或服务器不支持或不在该特定内存中,则服务器应进行负响应。这与客户端指定的DTCMask记录和/或DTCExt数据记录数参数确实是有效的并且由服务器支持,但没有与其关联的DTC扩展数据(例如,由于扩展数据的内存溢出)的情况有所不同。如果是reportDTCExtDataRecordByDTCNumber,服务器应发送只包含DTC和n状态记录(请求的DTC号(高、中、低字节)和DTC状态)的正响应。
车辆制造商有责任指定在用户定义的内存中删除存储的dtc和DTC扩展数据的规则。
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
根据所使用的子函数参数定义读取dtc信息请求消息的结构
此服务使用子函数参数来选择下表中指定的DTC报告类型之一。可能级别的解释和使用详细说明如下(抑制p指示位(位7)未显示)。
4.26.2.2 DTCMaskRecord [DTCHighByte, DTCMiddleByte, DTCLowByte]
DTCMaskRecord是一个3字节的值,包含DTC高字节、DTCMiddlebyte字节和低字节,它们共同代表服务器支持的特定诊断故障代码的唯一标识号。3字节DTC号的定义允许用几种方式编码DTC信息。这两者都可以做到
1. 根据ISO15031-6[12]规范,使用DTC高字节、DTC中字节、中字节和DTCLow字节进行解码。此格式由DTC格式标识符=SAE_J2012-DA_DTCFormat_00标识。
2.通过根据ISO14229的这部分使用DTCHighebyte和DTCLowByte的解码,该部分没有指定任何解码方法,因此允许车辆制造商定义的解码方法。此格式由DTC格式标识符=ISO_14229-1_DTCFormat标识。
3.根据SAEJ1939-73[19]规范,对DTC高字节、数字字节、中间字节和DTCLow字节进行解码。此格式由DTC格式标识符=SAE_J1939-73_DTCFormat标识。
4.根据ISO11992-4[5]规范,使用DTC高字节、DTC中字节、中字节和DTCLow字节的解码。此格式由DTC格式标识符=ISO_11992-4_DTCFormat标识。
5.根据ISO27145-2[16]规范,使用DTC高字节、DTC中字节、中字节和DTCLow字节进行解码。该格式由DTC格式标识符=SAE_J2012-DA_WWH-OBD_DTCFormat标识。
4.26.2.3 DTCSnapshotRecordNumber
DTCS快照记录数是一个1字节的值,指示通过reportDTCSnapshotByDTCNumber子函数为客户端定义的reportDTCSnapshotByDTCNumber数据记录请求的特定DTCS快照数据记录的数量。DTCS快照数据记录号0x00应保留用于立法目的(例如,WWH-OBD)。在0x01至0xFE范围内的DTCS快照记录应可用于车辆制造商的特定使用。值为0xFF,请求服务器一次报告所有存储的DTCS快照数据记录。
4.26.2.4 DTCStoredDataRecordNumber
DTC存储数据记录数是一个1字节的值,指示通过reportDTCStoredDataByRecordNumber子函数请求的特定DTC存储数据记录的数量。0x00应用于法律用途。dtc存储器在0x01到0xFE范围内的数据记录应可用于车辆制造商的特定使用。值0xFF请求服务器一次报告所有存储的dtc存储数据记录。
4.26.2.5 DTCExtDataRecordNumber
DTCExt数据记录数是一个1字节的值,指示通过reportDTCExtDataRecordByDTCNumber和reportDTCExtDataRecordByRecordNumber子函数为客户端定义的数据数据记录请求的特定DTC扩展数据记录的数量。对于与排放相关的服务器(与OBD兼容的ECUs),应保留DTCExt数据记录号0x00,以备将来的OBD使用。保留以下DTCExtData记录编号范围:
1.SO/SAE保留的值为0x00。
2.值0x01-0x8F请求服务器报告车辆制造商特定的存储的DTCExtended数据记录。
3.值0x90-0xEF请求服务器报告立法的OBD存储的DTC扩展数据记录。
4.ISO/SAE保留了0xF0-0xFD的值,用于将来报告单个响应消息中的组。
5.值0xFE请求服务器在单个响应消息中报告所有立法的OBD存储的DTC扩展数据记录。
6.值0xFF请求服务器在单个响应消息中报告所有存储的DTCexd数据记录。
4.26.2.6 DTCSeverityMaskRecord [DTCSeverityMask, DTCStatusMask]
状态记录是一个2字节的值,包含DTCSeveverity掩码和DTC状态掩码(参见上面文档)。
4.26.2.7 DTCSeverityMask
DTCS重要级别掩码包含三个DTC严重性位。这三个位中的每个位的定义都可以在上面文档找到。此字节用于请求消息中,允许客户端为其严重性定义与DTCS级别的数据掩码匹配的dtc请求DTC信息。如果任何一个DTC实际严重性位设置为“1”,并且DTCSA中相应的严重性位也设置为“1”(例如,如果DTCS实际严重性位逻辑匹配,且DTC实际严重性结果非零,则发生匹配)。
4.26.2.8 FunctionalGroupIdentifier
引入了功能群标识符来区分由许多不同的ecu组成的电气架构中不同的功能系统组之间的测试设备发送的命令。如果一个ECU已经实现了排放系统的软件以及其他可能在I/M测试期间进行检查的系统,则必须只报告所请求的功能系统组的DTC信息。I/M测试应该不会因为另一个功能系统组存储了DTC信息而失败。功能组标识符在函数组标识符定义中指定。
对服务ReadDTC信息请求的积极响应)取决于服务请求中的子功能。
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
定义子函数参数的肯定响应消息格式
4.27.2.1 reportType
该参数是在来自客户端的请求消息中提供的子函数参数的第6-0位的映射。
4.27.2.2 DTCAndSeverityRecord
此参数记录包含SAE_J2012-DA_DTCFormat_00、D-1_DTCFormat、DTC功能单元、SAE_J2012字节、SAE_J1939-73_DTCFormat)、DSO11992-4DTC格式或SAE_J2012-DA_DTCFormat_04的一个或多个组。
故障控制级别识别了故障对车辆操作和/或系统功能的重要性,并允许向驾驶员显示建议的操作。dtcs严重度的定义见D.3。DTC功能单元是一个1字节的值,它标识报告DTC的相应基本车辆/系统功能。DTC功能单元的定义是具体实施的,应在各自的实施标准中规定。
DTCHighhByte、DTCMiddleByte和DTCLowByte一起表示服务器支持的特定诊断故障代码的唯一标识号。DTCHighh字节和DTCMiddle字节表示被诊断的电路或系统。DTCLowByte表示电路或系统中的故障类型(例如,传感器开路、传感器对地短路、基于算法的故障等)。该定义可以在ISO°15031-6[12]规范中找到。
此参数记录包含一个或多个DTCS严重度、DTC功能单元、SPN(可疑参数编号)、FMI(故障模式标识符)和OC(发生计数器)的分组。SPN、FMI和OC在SAEJ1939[18]中定义。
4.27.2.3 DTCAndStatusRecord
此参数记录包含ISO_14229-1_DTCFormat、SAE_J2012-DA_DTCFormat_00、SAE_J1939-73_DTCFormat、SAE_J2012-DA_DTCFormat_04或ISO_11992-4_DTCFormat的DTC高字节、中间字节和状态组。SAE_J1939-73_DTCFormat支持SPN(可疑参数编号)、FMI(故障模式标识符)和OC(事件计数器)参数。SPN、FMI和OC在SAEJ1939中都有定义。
DTCHighhByte、DTCMiddleByte和DTCLowByte一起表示服务器支持的特定诊断故障代码的唯一标识号。3字节DTC号的编码可以完成:
1.根据ISO15031-6[12]规范,使用DTC高字节、DTC中字节、中字节和DTCLow字节进行解码。此格式由DTC格式标识符=SAE_J2012-DA_DTCFormat_00标识。
2.通过根据ISO14229-1规范对DTCHigileByte和DTCLowByte进行解码,该规范没有指定任何解码方法,因此允许车辆制造商定义的解码方法。该格式由DTC格式标识符=ISO_14229-1_DTCFormat标识。
3.根据SAEJ1939-73[19]规范,对DTC高字节、数字字节、中间字节和DTCLow字节进行解码。该格式由DTC格式标识符=SAE_J1939-73_DTCFormat标识。
4.根据ISO11992-4[5]规范,使用DTC高字节、DTC中字节、中字节和DTCLow字节的解码。此格式由DTC格式标识符=ISO_11992-4_DTCFormat标识。
5.根据ISO27145-2[16]规范,使用DTC高字节、DTC中字节、中字节和DTCLow字节进行解码。此格式由DTC格式标识符=SAE_2012-DA_WWHOBD_DTCFormat标识。
4.27.2.4 DTCRecord
此参数记录包含DTCH字节、DTCmiddle字节和DTCLow字节的一个或多个组。DTCCecord的解释取决于本表中定义的DTC格式标识符参数中包含的值。
4.27.2.5 StatusOfDTC
一个特定的DTC的状态(例如,测试失败了此操作周期等)。dtc字节状态中包含的位的定义可以在本规范的D.2中找到。服务器不支持的位应报告为“0”。
4.27.2.6 DTCStatusAvailabilityMask
其位的定义与dtc的状态相同,并表示服务器支持的状态位。服务器不支持的位应设置为“0”。每个支持的位应针对服务器支持的每个DTC实现(用值“1”表示)。
4.27.2.7 DTCFormatIdentifier
这个1字节的参数值定义了服务器报告的DTC的格式:
1.SAE_J2012-DA_DTCFormat_00:此参数值标识了在ISO15031-6[12]规范中定义的服务器报告的DTC格式。
2.ISO_14229-1_DTCFormat:此参数值标识服务器报告的由参数DTCAndDTC记录在此表中定义的状态格式。
3.SAE_J1939-73_DTCFormat:此参数值标识服务器在SAEJ1939-73[19]中定义的格式所报告的DTC格式。
4.ISO_11992-4_DTCFormat:此参数值标识了在ISO11992-4[5]规范中定义的服务器报告的DTC格式。
5.SAE_J2012-DA_DTCFormat_04:此参数值标识了在ISO27145-2[16]规范中定义的服务器报告的DTC格式。
DTC格式标识符字节中包含的字节值的定义可以在本文中找到。一个给定的服务器应只支持一个DTC格式标识符。
4.27.2.8 DTCCount
这个2字节参数统称为响应reportNumberOfDTCByStatusMask或reportNumberOfMirrorMemoryDTC请求发送的高字节和DTCCount低字节参数。DTCCount提供了与客户端请求中定义的DTCStatusMask相匹配的Dtc数量的计数。
4.27.2.9 DTCSnapshotRecordNumber
reportDTCSnapshotRecordByDTCNumber请求中客户端指定的DTCS快照记录数参数的回波,或存储的DTCS快照记录的实际DTCS快照记录号。
4.27.2.10 DTCSnapshotRecordNumberOfIdentifiers
这个单字节参数显示DTCSnapshot记录后面的数据标识符的数量。应使用0x00表示相应的DTCS网络照记录中包含了未定义数量的数据标识符(例如,主要用例是DTCS网络照记录包含超过255个数据标识符时)。
4.27.2.11 DTCSnapshotRecord
系统快照记录包含来自系统故障发生时的数据值的快照。
4.27.2.12 DTCStoredDataRecord
dtc存储数据记录包含从系统故障发生时开始的数据值冻结帧。
4.27.2.13 DTCStoredDataRecordNumber
reportDTCStoredDataByRecordNumber请求中客户端指定的DTC存储数据记录号参数的回波,或存储的DTC存储数据记录的实际数据记录号。
4.27.2.14 DTCStoredDataRecordNumberOfIdentifiers
这个单字节参数显示了dtc存储和数据记录后面的数据标识符的数量。
4.27.2.15 DTCExtDataRecordNumber
客户端在reportDTCExtDataRecordByDTCNumber或reportDTCExtDataRecordByRecordNumber请求中指定的DTCExt数据记录号参数的回声,或存储的DTC扩展数据记录的实际DTCExt数据记录号。
4.27.2.16 DTCExtDataRecord
DTCExtDataRecort是服务器特定的信息块,可能包含与DTC相关的扩展状态信息。数据包含DTC参数值,它们在请求时已被识别。
4.27.2.17 DTCFaultDetectionCounterRecord
DTCFaultDetectionCounterRecord是一个包含一个或多个DTC号和DTC特定的DTCFaultDetectionCounterRecord故障检测计数器参数值的记录。
4.27.2.18 DTCFaultDetectionCounter
DTC故障检测计数器报告一个DTC的故障检测计数数。
4.27.2.19 FunctionalGroupIdentifier
包含功能系统组(DTC)的单字节标识符与制动器、排放、乘员约束、轮胎充气、前向/外部照明等有关。
4.27.2.21 MemorySelection
此参数是在来自客户端的请求消息中提供的内存选择参数的映射。
本服务应执行以下否定响应代码。下表中记录了每个响应代码发生的情况。如果错误场景适用于服务器,则应使用所列出的否定响应。