跟我学UDS(ISO14229) |
您所在的位置：网站首页 › 故障码B1153 › 跟我学UDS(ISO14229) |
跟我学UDS(ISO14229)
|
该服务允许客户端从服务器请求诊断信息（包括 DTC，捕获的数据等）。该服务允许客户端从车辆内的任何服务器或服务器组读取服务器驻留诊断故障代码（DTC）信息的状态。 除非另有说明，否则服务器应返回与排放有关的 DTC 信息和与排放无关的 DTC 信息。 该服务允许客户端执行以下操作： —— 检索与客户端定义的 DTC 状态掩码匹配的 DTC 数量（在请求时）； —— 检索与客户端定义的 DTC 状态掩码匹配的所有 DTC 的列表； —— 检索与客户端定义的 DTC 和状态掩码组合相关联的 DTC Snapshot 数据； —— 从 DTC 内存或 DTC 镜像内存中检索与客户端定义的 DTC 和状态掩码组合相关联的 DTC 扩展数据； —— DTC 发生计数器； —— 当前阈值； —— last 最后一次出现的时间； —— 故障验证计数器 —— 未完成的测试计数器 —— 故障发生计数器 —— DTC老化计数器 —— 特定于OBD的计数器 —— 检索与客户端定义的严重性掩码匹配的 DTC 数量（在请求时）； —— 检索与客户端定义的严重性掩码记录匹配的 DTC 列表； —— 检索客户定义的故障诊断代码的严重性信息； —— 检索服务器支持的所有 DTC 的状态； —— 检索服务器失败的第一个故障诊断代码； —— 检索服务器内最近发生故障的 DTC； —— 检索服务器确认的第一个故障码； —— 检索服务器中最近确认的故障诊断代码； —— 从 DTC 镜像存储器中检索与客户端定义的 DTC 状态掩码匹配的 DTC 列表； —— 从 DTC 镜像存储器中检索客户端定义的 DTC 掩码的镜像存储器 DTC Extended Data 记录数据和客户端定义的DTC Extended Data 记录号； —— 从与客户端定义的 DTC 状态掩码匹配的 DTC 镜像存储器中检索 DTC 的数量； —— 检索与客户端定义的 DTC 状态掩码匹配的“仅”与排放相关的 OBD DTC 的数量 —— 检索所有当前已被或尚未被检测为“待定”或“已确认”的“合格的”故障诊断代码； —— 检索所有具有“ permanentDTC”状态的 DTC（这些 DTC 先前已由 clearDiagnosticInformation 服务清除，但保留在服务器的非易失性存储器中，直到成功通过每个 DTC 的相应监视器为止。） 该服务使用子功能来确定客户端请求的诊断信息类型。有关每个子功能参数的更多详细信息，请参见以下条款: 通过与客户端定义的状态掩码来索引匹配的 DTC 数量 客户端可以通过发送对该服务的请求并将子功能设置为 reportNumberOfDTCByStatusMask 来检索与客户端定义的状态掩码匹配的 DTC 数量。 对此请求的响应包含 DTCStatusAvailabilityMask，它提供服务器支持用于屏蔽目的的 DTC 状态位的指示。 在 DTCStatusAvailabilityMask 之后，响应包含 DTCFormatIdentifier ，该报告报告有关 DTC 格式和编码的信息。 DTCFormatIdentifier 之后是 DTCCount 参数，该参数是一个两字节的无符号数字，其中包含基于客户端提供的状态掩码的服务器内存中可用的 DTC 数量。子功能 reportNumberOfMirrorMemoryDTCByStatusMask 具有与子功能 reportNumberOfDTCByStatusMask 相同的功能，不同之处在于它从 DTC 镜像存储器中返回 DTC 的数量通过与客户端定义的状态掩码来索引匹配的 DTC 列表 客户端可以通过发送带有设置为 reportDTCByStatusMask 的子功能字节的请求来检索满足客户端定义的状态掩码的 DTC 列表。此子功能允许客户端请求服务器报告 “ testFailed” 或 “ confirmed” 或 “ etc” 的所有DTC。服务器应在客户端请求中指定的掩码和与服务器支持的每个 DTC 关联的实际状态之间执行按位逻辑“与”运算。除了DTCStatusAvailabilityMask，服务器还应返回所有 AND 运算结果为非零的 DTC。 也就是 statusOfDTC 与DTCStatusMask 执行逻辑与的运算之后，不为 0]。如果客户端指定的状态掩码包含服务器不支持的位，则服务器应仅使用其支持的位来处理 DTC 信息。如果服务器中没有 DTC 符合客户端请求中指定的屏蔽标准，则在肯定响应消息中的 DTCStatusAvailabilityMask 字节之后，不得提供DTC或状态信息。在客户端成功发出 ClearDiagnosticInformation 请求后，应清除 DTC 状态信息。索引 DTCSnapshot 记录标识 客户端可以通过发送子功能设置为 reportDTCSnapshotIdentification 的请求来检索所有捕获的 DTCSnapshot 记录标识信息。服务器应返回所有已存储 DTCSnapshot 记录的 DTCSnapshot 记录标识信息列表。服务器在响应消息中为单个 DTCSnapshot 记录放置的每个项目都应包含一个DTCRecord [包含 DTC 编号（高，中，低字节）]和 DTCSnapshot 记录编号。如果为单个 DTC 存储了多个DTCSnapshot 记录，则服务器应为每个事件在响应中放置一项，并为每个事件使用不同的 DTCSnapshot 记录号（用于以后检索记录数据）。客户端成功发出 ClearDiagnosticInformation 请求后，应清除 DTCSnapshot 记录标识信息。 主车厂需要定义清楚：当内存溢出的清楚出现时，删除已存储 DTC 和 DTCSnapshot 数据的规则。通过客户端定义的 DTC 掩码和/或客户端定义的 DTCSnapshot 记录号来索引DTCSnapshot记录数据 客户端只能通过发送对此服务的请求并将子功能设置为 reportDTCSnapshotRecordByDTCNumber 或 reportDTCSnapshotRecordByRecordNumber 来检索客户端定义的 DTCMaskRecord 的捕获的 DTCSnapshot 记录数据以及 DTCSnapshot记录号。 如果是 reportDTCSnapshotRecordByDTCNumber，则服务器应在其支持的DTC中搜索与客户端指定的 DTCMaskRecord 的完全匹配 [包含 DTC 编号（高，中，低字节）]。 在这种情况下，客户请求中提供的 DTCSnapshotRecordNumber 参数应指定请求 DTCSnapshot 记录数据的特定 DTC 的特定出现。 如果是 reportDTCSnapshotRecordByRecordNumber ，则服务器应在其存储的 DTCSnapshot 记录中搜索与客户端提供的记录号的匹配项。检索客户端定义的DTC掩码的DTCExtendedData记录数据和客户端定义的DTCExtendedData记录号 客户端可以通过发送对此服务的请求并将子功能设置为reportDTCExtendedDataRecordByDTCNumber来检索客户端定义的DTCMaskRecord的DTCExtendedData以及DTCExtendedData记录号。 服务器应通过其支持的DTC搜索与客户端指定的DTCMaskRecord完全匹配[包含DTC编号（高，中，低字节）]。 在这种情况下，客户请求中提供的DTCExtendedDataRecordNumber参数应指定要为其请求DTCExtendedData的指定DTC的特定DTCExtendedData记录。检索与客户端定义的严重性掩码记录匹配的DTC数量 客户端可以通过发送对此服务的请求并将子功能设置为reportNumberOfDTCBySeverityMaskRecord，来检索与客户端定义的严重性状态掩码记录匹配的DTC数量的计数。服务器应扫描所有受支持的DTC，在客户端指定的掩码记录与每个存储的DTC的实际信息之间执行按位逻辑“与”运算。具体的运算表达式如下：((statusOfDTC & DTCStatusMask) & (severity & DTCSeverityMask)) != 0检索与客户端定义的严重性掩码记录匹配的严重性和功能单元信息 客户端可以通过发送带有设置为 reportDTCBySeverityMaskRecord 的子功能字节的请求来检索DTC严重性和功能单元信息的列表，该列表满足客户端定义的严重性掩码记录。此子功能允许客户端请求服务器报告具有“ testFailed”或“ confirmed”或“ etc”等严重性和状态的所有DTC。服务器支持的每个DTC应在客户端请求中指定的DTCSeverityMask和DTCStatusMask与关联的实际DTCSeverity和statusOfDTC之间执行按位逻辑“与”运算。除DTCStatusAvailabilityMask外，服务器还应返回所有AND运算结果为非零的DTC，运算关系如下： （（statusOfDTC＆DTCStatusMask）＆（severity＆DTCSeverityMask））！= 0检索客户端定义的DTC的严重性和功能单元信息 客户端可以通过发送对此服务的请求并将子功能设置为reportSeverityInformationOfDTC，来检索客户端定义的DTCMaskRecord的严重性和功能单元信息。 服务器应通过其支持的DTC搜索与客户端指定的DTCMaskRecord完全匹配[包含DTC编号（高，中，低字节）]。检索服务器支持的所有DTC的状态 客户端可以通过发送对该服务的请求并将其子功能设置为reportSupportedDTC，来检索服务器支持的所有DTC的状态。 此请求的响应包含 DTCStatusAvailabilityMask，它提供服务器支持用于屏蔽目的的DTC状态位的指示。 在DTCStatusAvailabilityMask之后，响应还包含listOfDTCAndStatusRecord，该列表包含服务器支持的每个诊断故障代码的DTC编号和相关状态。检索第一个/最近失败的DTC 客户端可以通过发送请求，并将子功能字节分别设置为“ reportFirstTestFailedDTC”或“ reportMostRecentTestFailedDTC”，从服务器检索 第一个/最近失败的DTC。 服务器应与DTCStatusAvailabilityMask一起，将第一个或最近失败的DTC编号以及相关状态返回给客户端。如果自客户端上次请求服务器清除诊断信息以来没有记录失败的DTC，则在肯定响应消息中的DTCStatusAvailabilityMask字节之后，不得提供DTC 状态信息。 另外，如果自客户上次请求服务器清除诊断信息以来仅一个DTC发生故障，则应将唯一的故障DTC返回到来自客户端的reportFirstTestFailedDTC和reportMostRecentTestFailedDTC请求。检索第一个/最近检测到的已确认DTC 客户端可以通过发送请求并将子功能字节分别设置为“ reportFirstConfirmedDTC”或“ reportMostRecentConfirmedDTC”来从服务器检索第一个/最近确认的DTC。 服务器应与DTCStatusAvailabilityMask一起，将第一个或最近确认的DTC编号以及相关状态返回给客户端。如果自从上次客户端请求服务器清除诊断信息以来没有记录任何确认的DTC，则在肯定响应消息中的DTCStatusAvailabilityMask字节之后，不得提供DTC /状态信息。 此外，如果自客户上次请求服务器清除诊断信息以来仅确认了一个DTC，则唯一确认的DTC应予以确认。从服务器DTC镜像内存中检索与客户端定义的状态掩码匹配的DTC列表 子功能reportMirrorMemoryDTCByStatusMask的处理与为reportDTCByStatusMask定义的处理相同，除了所有状态掩码检查都是使用存储在服务器的DTC镜像存储器中的DTC执行的。 DTC镜像存储器是服务器中的附加可选错误存储器，不能通过ClearDiagnosticInformation（0x14）服务擦除。 DTC镜像存储器镜像普通DTC存储器，例如，如果删除了普通错误存储器，则可以使用DTC镜像存储器。从DTC镜像存储器中检索客户端定义的DTC掩码的镜像存储器DTCExtendedData记录数据和客户端定义的DTCExtendedData记录号 子功能reportMirrorMemoryDTCExtendedDataRecordByDTCNumber的处理与为reportDTCExtendedDataRecordByDTCNumber定义的处理相同，除了从DTC镜像存储器中检索数据外。 DTC镜像存储器是服务器中的附加可选错误存储器，不能通过ClearDiagnosticInformation（0x14）服务擦除。 DTC镜像存储器镜像普通DTC存储器，例如，如果删除了普通错误存储器，则可以使用DTC镜像存储器。检索与客户端定义的状态掩码匹配的镜像存储器DTC的数量 客户端可以通过发送对此服务的请求并将子功能设置为ReportNumberOfMirrorMemoryDTCByStatusMask，来检索与客户端定义的状态掩码匹配的镜像内存DTC的数量的计数。对此请求的响应包含DTCStatusAvailabilityMask，它提供服务器支持用于屏蔽目的的DTC状态位的指示。 在DTCStatusAvailabilityMask之后，响应包含DTCFormatIdentifier，该报告报告有关DTC格式和编码的信息。 DTCFormatIdentifier之后是DTCCount参数，该参数是一个两字节的无符号数字，其中包含基于客户端提供的状态掩码的服务器内存中可用的DTC数量。检索与客户端定义的状态掩码匹配的“仅与排放有关的OBD”故障诊断代码的数量 客户端可以通过发送对子服务设置为reportNumberOfEmissionsRelatedOBDDTCByStatusMask的子功能的此服务请求，来检索与客户端定义的状态掩码匹配的“仅与排放有关的OBD” DTC数量的计数。 对此请求的响应包含DTCStatusAvailabilityMask，它提供服务器支持用于屏蔽目的的DTC状态位的指示。 在DTCStatusAvailabilityMask之后，响应包含DTCFormatIdentifier，该报告报告有关DTC格式和编码的信息。 DTCFormatIdentifier之后是DTCCount参数，该参数是一个两字节的无符号数字，其中包含基于客户端提供的状态掩码的服务器内存中可用的“仅与排放有关的OBD” DTC数量。检索与客户端定义的状态掩码匹配的“仅与排放有关的OBD” DTC的列表 客户端可以通过发送带有设置为reportEmissionsRelatedOBDDTCByStatusMask的子功能字节的请求，来检索满足客户端定义的状态掩码的“仅与排放有关的OBD” DTC的列表。此子功能允许客户端请求服务器报告所有“ testFailed”或“ confirmed”或“ etc”的“与排放有关的OBD” DTC。评估应如下进行。服务器应在客户端请求中指定的掩码与服务器支持的每个“排放相关OBD” DTC关联的实际状态之间执行按位逻辑“与”运算。除了DTCStatusAvailabilityMask，服务器还应返回所有“与”相关的“与OBD”的DTC，其“与”运算的结果不为零。 （statusOfDTC和DTCStatusMask）！= 0]。如果客户端指定的状态掩码包含服务器不支持的位，则服务器应仅使用其支持的位来处理DTC信息。如果服务器内没有“排放相关的OBD” DTC与客户端请求中指定的屏蔽标准相匹配，则在肯定响应消息中的DTCStatusAvailabilityMask字节之后，不得提供任何DTC或状态信息。客户端发出成功的ClearDiagnosticInformation请求后，应清除“与排放有关的OBD” DTC状态信息。检索“失败的” DTC状态列表 客户可以在客户请求时检索所有当前“已失效” DTC的列表，这些列表已经或尚未被检测为“待定”或“已确认”。 DTCFaultDetectionCounter的目的是一种简单的方法，用于识别无法通过特定DTC的statusOfDTC字节识别/读取的增长或间歇性问题。 DTCFaultDetectionCounter的内部实现应特定于车辆制造商。 使用“故障前” DTC可以加快在制造工厂进行测试期间针对故障诊断所需的成熟时间，而这些故障需要成熟时间，而这些时间是制造测试所无法接受的。 维修或安装新组件后，该服务具有类似的用例。检索具有“ permanentDTC”状态的DTC列表 客户端可以检索“ permanentDTC”状态的列表。 状态为“ permanentDTC”的DTC先前已由clearDiagnosticInformation服务清除，但保留在服务器的非易失性存储器中，直到成功通过每个DTC的相应监视器为止。永久故障码应存储在非易失性存储器中。 这些DTC不能通过任何测试设备（例如车载测试仪，非车载测试仪）清除。 OBD系统应通过完成并通过车载监控器自行清除这些故障诊断代码。 这样可以避免仅通过断开电池来清除DTC的情况。确认的故障诊断码应不迟于点火循环结束时作为永久故障诊断码存储，并随后在确认的故障诊断码一直指示故障指示器亮起的所有时间（例如当前发生故障的系统，但不在40个预热周期的自我修复过程中）。 诊断请求格式参数 sub-function 为 reportNumberOfDTCByStatusMask / reportByStatusMask / reportMirrorMemoryDTCByStatusMask / reportNumberOfMirrorMemoryDTCByStatusMask / reportNumberOfEmissionsRelatedOBDDTCByStatusMask /reportEmissionsRelatedOBDDTCByStatusMask时，请求命令的格式如下： 具体的格式，需要依据请求中的 sub-function 的值来一一对应。 参数 sub-function 的值为 reportNumberOfDTCByStatusMask / reportNumberOfDTCBySeverityMaskRecord / reportNumberOfMirrorMemoryDTCByStatusMask / reportNumberOfEmissionsRelatedOBDDTCByStatusMask 时，诊断响应的格式如下： 具体的NRC码如下： |
参数 sub-function 为 reportDTCSnapshotIdentification / reportDTCSnapshotRecordByDTCNumber时，请求命令的格式如下： 
参数 sub-function 为 reportDTCSnapshotByRecordNumber 时，请求命令的格式如下： 
参数 sub-function 为 reportDTCExtendedDataRecordByDTCNumber / reportMirrorMemoryDTCExtendedDataRecordByDTCNumber 时，请求命令的格式如下： 
参数 sub-function 为 reportNumberOfDTCBySeverityMaskRecord / reportDTCSeverityInformation 时，请求命令的格式如下： 
参数 sub-function 为 reportSeverityInformationOfDTC 时，请求命令的格式如下： 
参数 sub-function 为 reportSupportedDTC / reportFirstTestFailedDTC / reportFirstConfirmedDTC / reportMostRecentTestFailedDTC / reportMostRecentConfirmedDTC / reportDTCFaultDetectionCounter / reportDTCWithPermanentStatus 时，请求命令的格式如下： 
这里可以明显的感受到，对于0x19服务来说，存在 sub-function 参数。并且对于参数值的不同，诊断请求的格式也是存在着较大的区别的。 这里还是相对 sub-function 参数做一个更详细的介绍和解释：
参数 sub-function 的值为 reportDTCByStatusMask /reportSupportedDTCs / reportFirstTestFailedDTC / reportFirstConfirmedDTC / reportMostRecentTestFailedDTC / reportMostRecentConfirmedDTC / reportMirrorMemoryDTCByStatusMask / reportEmissionsRelatedOBDDTCByStatusMask / reportDTCWithPermanentStatus 时，诊断响应的格式如下： 
参数 sub-function 的值为 reportSnapshotIdentification 时，诊断响应的格式如下： 
参数 sub-function 的值为 reportDTCSnapshotRecordByDTCNumber 时，诊断响应的格式如下： 
参数 sub-function 的值为 reportDTCSnapshotRecordByRecordNumber 时，诊断响应的格式如下： 
参数 sub-function 的值为 reportDTCExtendedDataRecordByDTCNumber / reportMirrorMemoryDTCExtendedDataRecordByDTCNumber 时，诊断响应的格式如下： 
参数 sub-function 的值为 reportDTCBySeverityMaskRecord / reportSeverityInformationOfDTC 时，诊断响应的格式如下： 
参数 sub-function 的值为 reportDTCFaultDetectionCounter 时，诊断响应的格式如下： 
【本文地址】
今日新闻 |
推荐新闻 |