DTC服务（0x14 0x19 0x85）

DTC相关的服务有ReadDTCInformation (19) service，ControlDTCSetting (85) service和ReadDTCInformation (19) service

ReadDTCInformation (19) service

该服务允许客户端从车辆内任意一台服务器或一组服务器中读取驻留在服务器中的诊断故障代码( DTC )信息的状态。除非特定SubFunction另有要求，服务器应返回所有DTC信息(如排放相关和非排放相关)。此服务可以让客户端做到以下几点：
-检索与客户端定义的DTC状态掩码相匹配的DTC数量；
-检索与客户端定义的DTC状态掩码匹配的所有DTC列表；
-检索与客户端定义的DTC状态掩码匹配的特定功能组内的DTC列表；
-检索所有具有"永久性DTC "状态的DTC；
-检索与客户端定义的DTC相关的DTC快照数据(有时也被称为冻结框架)：DTC快照是与DTC相关的特定数据记录，存储在服务器的内存中。DTC快照的典型用途是在检测到系统故障时存储数据。DTC快照将作为系统故障发生时刻的数据值快照。存储在DTC快照中的数据参数应与DTC相关联。DTC的具体数据参数意在方便技术员的故障隔离过程；
-为客户端定义的DTCExtD检索支持特定DTCExtensionDataRecord的所有DTC的列表
-从DTC内存中检索与客户端定义的DTC和状态掩码组合相关的DTCExtension Data。DTCExtension Data由与DTC相关的扩展状态信息组成。
DTCExtensedData包含DTC参数值，这些参数值在请求时已被标识。例如，DTCExtension Data的一个典型用途是存储与DTC相关的动态数据：

• DTC B1故障指示器计数器，该计数器表示在发生故障时OBD系统已运行的时间量(发动机工作小时数)；
• DTC发生计数器，计数" testFailed "中已报告的驾驶循环次数；
• DTC老化计数器，统计自故障最近一次发生故障以来的行驶工况数，不包括试验未报告" testPassed “或” testFailed "的行驶工况；
• OBD (例如,如果驾驶循环可以在无故障模式下执行,直到"检查引擎"灯被关闭为止的剩余驾驶循环数)专用计数器；-末次发生时间(等)；
• 测试失败计数器，计数报告的’ testFailed ‘和可能的其他计数器，如果验证是分几个步骤进行的；-未完成的测试计数器，统计自测试最新完成(即由于测试报告了’ testPassed ‘或’ testFailed ')以来的驾驶循环次数；
• -检索与客户定义的严重性掩码匹配的DTC数量；-检索与客户端定义的严重度掩码记录匹配的DTC列表；-为客户端定义的DTC检索严重性信息；
  -检索服务器支持的所有DTC的状态；
• 检索服务器故障的第1个DTC；
• 在服务器内部检索最近失败的DTC；
• 检索服务器确认的第一个DTC；
• 在服务器内检索最近确认的DTC；
• 检索所有当前已经或尚未被检测为"待定"或"已确认"的"预失效" DTC；
• 从DTC内存中检索与客户端定义的DTCExtension Data相关的DTCExtension Data记录状态；
• 从用户定义的DTC内存中检索出与客户端定义的DTC状态掩码相匹配的DTC列表；
• 针对客户端定义的DTC掩码检索用户定义的DTC内存DTCExtensedData记录数据；
• 从用户定义的DTC内存中检索客户端定义的DTC掩码的用户定义的DTC内存DTCSnapshotRecord数据；
• 为客户端定义的DTCReadinessGroupIdentifier检索DTC信息。

该服务使用子功能来确定客户端请求的是哪种类型的诊断信息。关于每个子功能参数的更多细节将在下面的子句中提供。这项服务使用了以下术语：

• 启用标准：服务器/车辆制造商/系统供应商特定的标准，用于控制当服务器实际执行特定的内部诊断。
• 测试通过标准：服务器/车辆制造商/系统供应商特定的条件，
• 测试失败标准：服务器/车辆制造商/系统供应商特定的失败条件，定义，一个被诊断的系统是否已经失败的测试。-确认失败标准：服务器/车辆制造商/系统供应商特定的失败条件，定义，一个被诊断的系统是否被确定的问题(确认)，保证DTC记录存储在长时记忆中。
• 发生计数器：由某些服务器维护的计数器，记录一个给定的DTC测试报告的唯一发生的实例的数量。
• 老化：某些服务器评估每个内部诊断的过去结果，以确定确认的DTC是否可以从长时记忆中清除，例如在校准的无故障周期数的情况下。
  除了读取DTCSnapshotRecords外，一个给定的DTC值(例如080511)不应该在读取DTC信息的正响应中报告一次以上，其中响应可能包含同一个DTC的多个DTCSnapshotRecords。当使用分页缓冲处理读取DTCs (特别是对于子功能= reportDTCByStatusMask)时，有可能在创建响应的同时减少DTCs的数量。在这种情况下，响应应填写DTC 00000016和DTC状态0016。客户端应将这些DTC视为不存在于响应消息中。IMPORTANT - 服务器和客户端应满足8.7中规定的请求和响应消息行为。

1、检索与客户端定义的状态掩码(子功能= 0116 reportNumberOfDTCByStatusMask )匹配的DTC数量
客户端可以通过发送该服务的请求，并将子功能设置为reportNumberOfDTCByStatusMask，来检索与客户端定义的状态掩码匹配的DTC数量。对该请求的响应包含DTCStatusAvailabilityMask，它提供了服务器支持的用于掩码目的的DTC状态位的指示。在DTCStatusAvailabilityMask之后，响应包含DTCFormatIdentifier，它报告了关于DTC格式和编码的信息。DTCFormatIdentifier后面跟着DTCCount参数，DTCCount参数是一个2字节的无符号数字，包含服务器内存中基于客户端提供的状态掩码可用的DTC数量。
2、检索与客户端定义的状态掩码(子功能= 0216 reportDTCByStatusMask )匹配的DTC列表
客户端可以通过发送带有子功能字节集的请求来报告DTCByStatusMask，从而检索满足客户端定义的状态掩码的DTC列表。这个子功能允许客户端请求服务器报告所有" testFailed " OR “确认” OR "等"测试失败"的DTC。
评估应做如下工作：服务器应在客户端请求中指定的掩码与服务器支持的每个DTC相关联的实际状态之间执行一个按位的逻辑AND - ing操作。除DTCStatusAvailabilityMask外，服务器还需返回所有与操作结果为非零(即: ( statusOfDTC & DTCStatusMask )) ! = 0的DTC。如果客户端指定了一个包含服务器不支持的比特的状态掩码，那么服务器应该只使用它所支持的比特来处理DTC信息。如果服务器中没有DTC符合客户端请求中规定的屏蔽条件，则在正响应消息中的DTCStatusAvailabilityMask字节后面不提供DTC或状态信息。当客户端成功请求ClearDiagnosticInformation时，需要清除DTC状态信息(请参见D.2中的DTC状态位定义，以获得对DTC状态位的进一步描述)
3、检索DTCS快照记录标识(子功能= 0316举报DTCS快照识别)
客户端通过向该服务发送请求，设置子功能报告DTCSnapshotIdentification，可以为捕获的所有DTCSnapshot记录检索DTCSnapshot记录标识信息。服务器对所有存储的DTCS快照记录返回DTCS快照记录标识信息列表。服务器在单个DTCS快照记录的响应消息中放置的每一项都应该包含一个DTCRecord [包含DTC编号(高、中、低字节)]和DTCS快照记录编号。如果为单个DTC存储多个DTCSnapshot记录，则服务器应为每个事件在响应中放置一个项目，为每个事件(用于后期对记录数据的检索)使用不同的DTCSnapshot记录编号。

服务器可以支持单个DTC存储多个DTCS快照记录，以跟踪每个DTC发生时存在的情况。该功能的支持，"发生"标准的定义，以及需要支持的DTCS快照记录的数量由系统供应商/车辆制造商定义。

当客户端成功请求ClearDiagnostic信息时，DTCS快照记录标识信息应被清除。在内存溢出(存储的DTC和DTCSnapshot数据的内存空间完全占用在服务器中)的情况下，由车辆制造商负责指定存储的DTC和DTCSnapshot数据的删除规则。
4、为客户端定义的DTC掩码(子功能= 0416 reportDTCSnapshotRecordByDTCNumber)检索DTCSnapshot记录数据
客户端可以通过向子功能设置为reportDTCSnapshotRecordByDTCNumber的服务发送请求，结合DTCSnapshot记录编号来检索客户端定义的DTCMaskRecord捕获的DTCSnapshot记录数据。服务器通过其支持的DTC搜索与客户端(包含DTC编号(高、中、低字节))指定的DTCMaskRecord的精确匹配)。客户端请求中提供的UserDefDTCSnapshotRecordNumber参数应指定请求DTCSnapshot记录数据的指定DTC的特定发生。注1 UserDefDTCSnapshotRecordNumber与DTCStoredDataRecordNumber不共享相同的地址空间。
如果服务器支持为单个DTC (该功能的支持由系统供应商/车辆制造商定义)存储多个DTCSnapshot记录的能力，那么建议服务器也实现reportDTCSnapshotIdentification子功能参数。建议客户端在通过reportDTCSnapshotRecordByDTCNumber请求请求特定DTCSnapshotRecordNumber之前，首先请求使用子功能参数reportDTCSnapshotIdentification存储的DTCSnapshot记录的标识。
还建议支持子功能参数报告DTCSnapshotRecordIdentification，以便给客户端直接识别存储的DTCSnapshot记录的机会，而不是通过服务器所有存储的DTC进行解析，以确定是否存储了DTCSnapshot记录。系统供应商/车辆制造商有责任定义在这些服务器中捕获的DTCS快照记录是否存储与故障发生信息相关的数据，作为ECU文档的一部分。
如果客户端定义的DTCMaskRecord和DTCSnapshotRecordNumber参数( DTCSnapshotRecordNumber不等FF16)发生故障，服务器将根据DTC编号和状态Of DTC返回一个预定义的DTCSnapshotRecord响应客户端请求。注2确切的失效准则由系统供应商/车辆制造商定义。
DTCS快照记录可能包含多个数据参数，可用于重建故障发生时的车辆状态( e.g. B + , RPM ,时间戳)。汽车制造商应定义DTCS快照记录的格式和内容。DTCSnapshotRecord中报告的数据首先包含一个DataIdentifier，用于识别后面的数据。这种数据标识符/数据组合可以在DTCSnapshotRecord中重复。DTCSnapshotRecord中一个或多个数据标识符的使用允许单个DTC存储不同类型的DTCSnapshotRecord，以应对不同的故障发生。在每个DTCSnapshotRecord中应该提供一个参数，该参数表示每个DTCSnapshotRecord中包含的记录DataIdentifier的数量，以辅助数据检索。
除客户端将UserDefDTCSnapshotRecordNumber设置为FF16外，服务器应在单个响应消息中报告一条DTCSnapshot记录，因为这将导致服务器以单个响应消息中存储为客户端定义的DTCMaskRecord的所有DTCSnapshot记录进行响应。DTCAndStatusRecord只包含在响应消息中的一次。如果客户端在请求中对DTCSnapshotRecordNumber参数使用了FF16，则服务器应按数字升序报告针对特定DTC捕获的所有DTCSnapshot记录。
如果客户端指定的DTCMaskRecord或DTCSnapshotRecordNumber参数无效或服务器不支持，服务器应消极响应。这与客户端指定的DTCMaskRecord和/或DTCSnapshotRecordNumber参数确实有效并得到服务器支持，但没有与之关联的DTCSnapshot数据(例如,对于指定的DTC或记录编号,从未发生过故障事件)的情况有所不同。服务器应发送仅包含DTCAndStatusRecord [请求的DTC号码(高、中、低字节)加上状态OFDTC的回声]的正响应。
当客户端成功请求ClearDiagnosticInformation时，DTCS快照信息应被清除。在内存溢出(存储的DTC和DTCsnapshot数据的内存空间完全占用在服务器中)的情况下，由车辆制造商负责指定存储的DTC和DTCSnapshot数据的删除规则。
5、为客户端定义的记录号(子功能= 05 16 reportDTCStored DataByRecordNumber )检索DTCStored Data记录数据
客户端通过向DTCStored DataRecordNumber发送该服务的请求，并将子功能设置为reportDTCStored DataByRecordNumber，即可获取捕获的DTCStored Data记录数据。服务器通过其存储的DTCStoredData记录进行搜索，以匹配客户端提供的记录编号。
DTCStored DataRecordNumber不与DTCSnapshotRecordNumber共享同一地址空间。
系统供应商/车辆制造商有责任确定在这些服务器中捕获的DTCStored Data记录是否存储了与首次或最近发生的故障相关的数据。注：确切的失效准则由系统供应商/车辆制造商定义。
DTCStored Data记录可能包含多个数据参数，可用于重构故障发生时的车辆状态( e.g. B + , RPM ,时间戳)。
汽车生产商应明确DTCS存储数据记录的格式和内容。DTCStored DataRecord中报告的数据首先包含一个数据标识符，用于识别后面的数据。这种数据标识符/数据组合可以在DTCStored DataRecord中重复。在DTCStoredDataRecord中使用一个或多个数据标识符，允许单个DTC针对不同的故障发生存储不同类型的DTCStoredDataRecord。为了辅助数据检索，每个DTCStored DataRecord应提供一个参数，该参数表示每个DTCStored DataRecord中包含的记录DataIdentifier的数量。
除客户端已将DTCStoredDataRecordNumber设置为FF16外，服务器应在单个响应消息中报告一个DTCStoredDataRecord，因为这将导致服务器响应存储在单个响应消息中的所有DTCStoredDataRecord。
如果客户端请求按记录编号上报所有DTCStored DataRecord，则每个存储的DTCStored DataRecord的响应消息中都要重复DTCAndStatusRecord。如果客户端指定的DTCStoredDataRecordNumber参数无效或服务器不支持，则服务器负响应。这与客户端指定的DTCStored DataRecordNumber参数确实有效并得到服务器支持，但没有与之关联的DTCStored DataRecord数据(例如,因为对于指定的记录编号从未发生过故障事件)的情况有所不同。在这种情况下，服务器需要发送只包含DTCStored DataRecordNumber (请求记录编号的回声)的正响应。
DTCStoredDataRecord 信息应在客户端发出成功的 ClearDiagnosticInformation 请求后清除。车辆制造商有责任指定在内存溢出（服务器中存储的 DTC 和 DTCStoredDataRecord 数据的内存空间完全被占用）情况下删除存储的 DTC 和 DTCStoredDataRecord 数据的规则。
6、检索客户端定义的 DTC 掩码和客户端定义的 DTCExtendedData 记录号的 DTCExtendedData 记录数据（子功能 = 0616 reportDTCExtDataRecordByDTCNumber
客户端可以通过发送对此服务的请求并将子函数设置为reportDTCExtDataRecordByDTCNumber，来检索客户端定义的DTCMaskRecord 的DTCExtendedData 以及DTCExtendedData 记录号。服务器应在其支持的 DTC 中搜索与客户端指定的 DTCMaskRecord 的精确匹配[包含 DTC 编号（高、中、低字节）]。在这种情况下，客户端请求中提供的 DTCExtDataRecordNumber 参数应指定正在请求 DTCExtendData 的指定 DTC 的特定 DTCExtendedData 记录。
除了 DTC 编号和 statusOfDTC 之外，服务器还应返回单个预定义的 DTCExtendedData 记录以响应客户端的请求（DTCExtDataRecordNumber 不等于 FE16 或 FF16）。
车辆制造商应定义 DTCExtDataRecord 的格式和内容。 DTCExtDataRecord 中报告的数据结构由 DTCExtDataRecordNumber 定义，其方式与记录 DataIdentifier 中的数据定义类似。响应中可以包括多个 DTCExtDataRecordNumber 和关联的 DTCExtDataRecord。使用一个或多个 DTCExtDataRecordNumber 允许为单个 DTC 存储不同类型的 DTCExtDataRecord。
服务器应在单个响应消息中报告一个 DTCExtendedData 记录，除非客户端已将 DTCExtDataRecordNumber 设置为 FE16 或 FF16，因为这将导致服务器在单个响应消息中使用为客户端定义的 DTCMaskRecord 存储的所有 DTCExtendedData 记录进行响应。
如果客户端指定的 DTCMaskRecord 或 DTCExtDataRecordNumber 参数无效或服务器不支持，服务器应做出否定响应。这包括客户端发送 FE16 的 DTCExtDataRecordNumber，但服务器不支持 OBD 扩展数据记录（9016 到 EF16）的情况。这应与客户端指定的 DTCMaskRecord 和/或 DTCExtDataRecordNumber 参数确实有效并受服务器支持，但没有与其关联的 DTC 扩展数据的情况不同（例如，由于扩展数据的内存溢出）。在通过 DTCNumber 报告 DTCExtDataRecord 的情况下，服务器应发送仅包含 DTCAndStatusRecord [请求的 DTC 编号（高、中和低字节）的回显加上 statusOfDTC] 的肯定响应。
11.2.1 中规定了在接收到 ClearDiagnosticInformation 服务时清除 DTCExtendedData 信息。车辆制造商有责任规定在内存溢出（服务器中存储的 DTC 和 DTC 扩展数据的内存空间完全被占用）的情况下删除存储的 DTC 和 DTC 扩展数据的规则。

7、检索与客户端定义的严重性掩码记录匹配的 DTC 数量（SubFunction = 07 reportNumberOfDTCBySeverityMaskRecord
客户端可以通过发送对此服务的请求（并将 SubFunction 设置为 reportNumberOfDTCBySeverityMaskRecord）来检索与客户端定义的严重性状态掩码记录匹配的 DTC 数量的计数。服务器应扫描所有支持的 DTC，在客户端指定的掩码记录与每个存储的 DTC 的实际信息之间执行按位逻辑与运算。
(((statusOfDTC & DTCStatusMask) != 0) && ((severity & DTCSeverityMask) != 0)) == TRUE 对于每个产生 TRUE 结果的 AND 运算，服务器应将计数器加 1。如果客户端指定如果掩码记录中的状态掩码包含服务器不支持的位，则服务器应仅使用其支持的位来处理 DTC 信息。一旦检查完所有支持的 DTC，服务器应将 DTCStatusAvailabilityMask 和结果 2 字节计数返回给客户端。
如果服务器内没有 DTC 与客户端请求中指定的掩码标准相匹配，则服务器返回给客户端的计数应为 0。报告的与 DTC 状态掩码匹配的 DTC 数量在请求发出时的时间点有效。制成。报告的 DTC 数量与通过子功能 reportDTCByStatusMask 读取的实际 DTC 列表之间没有关系，因为读取 DTC 的请求是在不同的时间点完成的。
8、检索与客户端定义的严重性掩码记录匹配的严重性和功能单元信息（SubFunction = 08 16 reportDTCBySeverityMaskRecord）
客户端可以检索 DTC 严重性和功能单元信息的列表，这些信息通过发送带有设置为 reportDTCBySeverityMaskRecord 的 SubFunction 字节的请求来满足客户端定义的严重性掩码记录。该子功能允许客户端请求服务器报告具有特定严重性和状态（“测试失败”或“已确认”或“等”）的所有 DTC。评估应按如下方式进行。
服务器应在客户端请求中指定的 DTCSeverityMask 和 DTCStatusMask 以及与服务器支持的每个 DTC 关联的实际 DTCSeverity 和 statusOfDTC 之间执行按位逻辑 AND 运算。
除了 DTCStatusAvailabilityMask 之外，服务器还应返回 AND 运算结果为 TRUE 的所有 DTC。
(((statusOfDTC & DTCStatusMask) !=0) && ((severity & DTCSeverityMask) != 0)) == TRUE 如果客户端在掩码记录中指定的状态掩码包含服务器不支持的位，则服务器应仅使用其支持的位来处理 DTC 信息。如果服务器内没有 DTC 与客户端请求中指定的屏蔽标准相匹配，则在肯定响应消息中的 DTCStatusAvailabilityMask 字节之后不应提供任何 DTC 或状态信息。

9、检索客户端定义的 DTC 的严重性和功能单元信息（SubFunction = 09 16 reportSeverityInformationOfDTC
客户端可以通过发送对此服务的请求（并将 SubFunction 设置为 reportSeverityInformationOfDTC）来检索客户端定义的 DTCMaskRecord 的严重性和功能单元信息。服务器应在其支持的 DTC 中搜索与客户端指定的 DTCMaskRecord 的精确匹配[包含 DTC 编号（高、中、低字节）]。

10、检索服务器支持的所有 DTC 的状态（子功能 = 0A16 reportSupportedDTC） 客户端可以通过发送以下请求来检索服务器支持的所有 DTC 的状态：
客户端可以通过发送此服务的子功能设置为reportSupportedDTCs 的请求来检索服务器支持的所有DTC 的状态。对此请求的响应包含 DTCStatusAvailabilityMask，它提供服务器支持用于屏蔽目的的 DTC 状态位的指示。在 DTCStatusAvailabilityMask 之后，响应还包含 listOfDTCAndStatusRecord，其中包含服务器支持的每个诊断故障代码的 DTC 编号和相关状态。
11、检索第一个/最近失败的 DTC（SubFunction = 0B16 reportFirstTestFailedDTC、SubFunction = 0D 16 reportMostRecentTestFailedDTC）
客户端可以通过发送 SubFunction 字节分别设置为“reportFirstTestFailedDTC”或“reportMostRecentTestFailedDTC”的请求，从服务器检索第一个/最近失败的 DTC。与 DTCStatusAvailabilityMask 一起，服务器应将第一个或最近失败的 DTC 编号和相关状态返回给客户端。
如果自上次客户端请求服务器清除诊断信息以来没有记录任何失败的 DTC，则在肯定响应消息中的 DTCStatusAvailabilityMask 字节之后不应提供 DTC/状态信息。此外，如果自上次客户端请求服务器清除诊断信息以来只有一个 DTC 的状态失败，则应将一个失败的 DTC 返回给来自客户端的 reportFirstTestFailedDTC 和 reportMostRecentTestFailedDTC 请求。第一个/最近失败的 DTC 的记录应独立于已确认的 DTC 的老化过程
如上所述，应根据客户端成功的 ClearDiagnosticInformation 请求清除第一个/最近失败的 DTC 信息（请参阅 D.2 中的 DTC 状态位定义，以获取有关在接收 ClearDiagnosticInformation 服务请求的情况下 DTC 状态位处理的进一步描述）。服务器）。

12、检索第一个/最近检测到的确认 DTC（SubFunction = 0C16 reportFirstConfirmedDTC、SubFunction = 0E 16 reportMostRecentConfirmedDTC）
客户端可以通过发送 SubFunction 字节分别设置为“reportFirstConfirmedDTC”或“reportMostRecentConfirmedDTC”的请求，从服务器检索第一个/最近确认的 DTC。与 DTCStatusAvailabilityMask 一起，服务器应将第一个或最近确认的 DTC 编号和相关状态返回给客户端。
响应消息中的 DTCStatusAvailabilityMask 字节之后不应提供 DTC/状态信息。此外，如果自上次客户端请求服务器清除诊断信息以来仅确认了 1 个 DTC，则应将一个确认的 DTC 返回给来自客户端的 reportFirstConfirmedDTC 和 reportMostRecentConfirmedDTC 请求。
如果 DTC 在过去的某个时间点失败，但随后在客户端请求之前满足老化标准，则应保留第一个确认的 DTC 的记录（无论在该 DTC 之后确认的任何其他 DTC）。上述 DTC 已确认）。类似地，如果 DTC 在过去的某一时刻被确认，但随后在客户端请求之前满足老化标准（假设在之后没有其他 DTC 被确认），则应保留最近确认的 DTC 的记录。上述 DTC 失败）。
如上所述，第一个/最近确认的 DTC 信息应在客户端发出成功的 ClearDiagnosticInformation 请求后清除

13、检索“预失败”DTC 状态列表（子功能 = 1416 reportDTCFaultDetectio n-Counter
客户端可以检索所有当前“失败前”DTC 的列表，这些 DTC 在客户端发出请求时已被检测为“待定”或“已确认”。 DTCFaultDetectionCounter 的目的是一种简单方法，用于识别无法通过特定 DTC 的 statusOfDTC 字节识别/读取的日益增长或间歇性问题。 DTCFaultDetectionCounter 的内部实现应是车辆制造商特定的。 “故障前”DTC 的用例是在制造工厂测试 DTC 期间加速故障检测，这些 DTC 需要制造测试无法接受的成熟时间。维修或安装新组件后，服务具有类似的用例。

14、检索具有“永久 DTC”状态的 DTC 列表（子功能 = 1516 reportDTCWithPermanentStatus）
客户端可以检索具有“永久 DTC”状态的 DTC 列表，如 3.12 中所述。子功能 1516 将来将被子功能 55 16 取代。如果需要永久 DTC 实施，建议使用 5516 子功能。

15、检索客户端定义的 DTCExtendedData 记录号的 DTCExtendedData 记录数据（SubFunction = 16 16 reportDTCExtDataRecordByRecordNumber）
客户端可以通过发送对此服务的请求并将子函数设置为reportDTCExtDataRecordByRecordNumber 来检索客户端定义的DTCExtendedData 记录号的DTCExtendedData。服务器应搜索所有支持的 DTC，以确保与客户端指定的 DTCExtDataRecordNumber 完全匹配。在这种情况下，客户端请求中提供的 DTCExtDataRecordNumber 参数应为正在请求 DTCExtendData 的所有支持的 DTC 指定特定的 DTCExtendedData 记录。
服务器应返回 DTCExtendedData 记录以及每个支持的 DTC 的 DTC 编号和 statusOfDTC，其中包含所请求的 DTCExtDataRecordNumber 的数据。
车辆制造商应定义 DTCExtDataRecord 的格式和内容。 DTCExtDataRecord 中报告的数据结构由 DTCExtDataRecordNumber 定义，其方式与记录 DataIdentifier 中的数据定义类似。
如果客户端指定的 DTCExtDataRecordNumber 参数无效或服务器不支持，服务器应做出否定响应。
11.2.1 中规定了在接收到 ClearDiagnosticInformation 服务时清除 DTCExtendedData 信息。车辆制造商有责任规定在内存溢出（服务器中存储的 DTC 和 DTC 扩展数据的内存空间完全被占用）的情况下删除存储的 DTC 和 DTC 扩展数据的规则。

16、从服务器的用户定义的 DTC 内存中检索与客户端定义的 DTC 状态掩码匹配的 DTC 列表 (SubFunction = 17 16 reportUserDefMemoryDTCByStatusMask)
客户端可以从用户定义的存储器中检索 DTC 列表，通过发送将 SubFunction 字节设置为 reportUserDefMemoryDTCByStatusMask 的请求来满足客户端定义的状态掩码。该子函数允许客户端请求服务器报告所有“testFailed”或“confirmed”或“etc”的DTC。来自用户定义的内存。
评估应按如下方式完成：服务器应在客户端请求中指定的掩码和与该用户定义的存储器中服务器支持的每个 DTC 相关的实际状态之间执行按位逻辑 AND 运算。除了 DTCStatusAvailabilityMask 之外，服务器还应返回该特定内存中 AND 运算结果非零（即 (statusOfDTC & DTCStatusMask) != 0）的所有 DTC。如果客户端指定的状态掩码包含服务器不支持的位，则服务器应仅使用其支持的位来处理 DTC 信息。如果服务器内没有 DTC 与该特定内存中客户端请求中指定的屏蔽标准相匹配，则在肯定响应消息中的 DTCStatusAvailabilityMask 字节之后不应提供任何 DTC 或状态信息。
DTC 状态信息应通过服务 1416 ClearDTC 服务（将 memorySelection 参数设置为适用的存储器）或通过制造商特定条件（例如来自客户端的例行控制请求）来清除。

17、DTC 状态信息应通过服务 1416 ClearDTC 服务（将 memorySelection 参数设置为适用的存储器）或通过制造商特定条件（例如来自客户端的例行控制请求）来清除
客户端可以检索所有当前“失败前”DTC 的列表，这些 DTC 在客户端发出请求时已被检测为“待定”或“已确认”。 DTCFaultDetectionCounter 的目的是一种简单方法，用于识别无法通过特定 DTC 的 statusOfDTC 字节识别/读取的日益增长或间歇性问题。 DTCFaultDetectionCounter 的内部实现应是车辆制造商特定的。 “故障前”DTC 的用例是在制造工厂测试 DTC 期间加速故障检测，这些 DTC 需要制造测试无法接受的成熟时间。维修或安装新组件后，服务具有类似的用例
18、检索具有“永久 DTC”状态的 DTC 列表（子功能 = 1516 reportDTCWithPermanentStatus）
客户端可以检索具有“永久 DTC”状态的 DTC 列表，如 3.12 中所述。子功能 1516 将来将被子功能 55 16 取代。如果需要永久 DTC 实施，建议使用 5516 子功能。

19、检索客户端定义的 DTCExtendedData 记录号的 DTCExtendedData 记录数据 (SubFunction = 16 16 reportDTCExtDataRecordByRecordNumber
客户端可以通过发送对此服务的请求并将子函数设置为reportDTCExtDataRecordByRecordNumber 来检索客户端定义的DTCExtendedData 记录号的DTCExtendedData。服务器应搜索所有支持的 DTC，以确保与客户端指定的 DTCExtDataRecordNumber 完全匹配。在这种情况下，客户端请求中提供的 DTCExtDataRecordNumber 参数应为正在请求 DTCExtendData 的所有支持的 DTC 指定特定的 DTCExtendedData 记录。
服务器应返回 DTCExtendedData 记录以及每个支持的 DTC 的 DTC 编号和 statusOfDTC，其中包含所请求的 DTCExtDataRecordNumber 的数据。
车辆制造商应定义 DTCExtDataRecord 的格式和内容。 DTCExtDataRecord 中报告的数据结构由 DTCExtDataRecordNumber 定义，其方式与记录 DataIdentifier 中的数据定义类似。
如果客户端指定的 DTCExtDataRecordNumber 参数无效或服务器不支持，服务器应做出否定响应。
11.2.1 中规定了在接收到 ClearDiagnosticInformation 服务时清除 DTCExtendedData 信息。车辆制造商有责任规定在内存溢出（服务器中存储的 DTC 和 DTC 扩展数据的内存空间完全被占用）的情况下删除存储的 DTC 和 DTC 扩展数据的规则。

20、从服务器的用户定义的 DTC 内存中检索与客户端定义的 DTC 状态掩码相匹配的 DTC 列表 (SubFunction = 17 16 reportUserDefMemoryDTCByStatusMask) 客户端可以从用户定义中检索 DTC 列表
客户端可以从用户定义的存储器中检索 DTC 列表，通过发送将 SubFunction 字节设置为 reportUserDefMemoryDTCByStatusMask 的请求来满足客户端定义的状态掩码。该子函数允许客户端请求服务器报告所有“testFailed”或“confirmed”或“etc”的DTC。来自用户定义的内存。
评估应按如下方式完成：服务器应在客户端请求中指定的掩码和与该用户定义的存储器中服务器支持的每个 DTC 相关的实际状态之间执行按位逻辑 AND 运算。除了 DTCStatusAvailabilityMask 之外，服务器还应返回该特定内存中 AND 运算结果非零（即 (statusOfDTC & DTCStatusMask) != 0）的所有 DTC。如果客户端指定的状态掩码包含服务器不支持的位，则服务器应仅使用其支持的位来处理 DTC 信息。如果服务器内没有 DTC 与该特定内存中客户端请求中指定的屏蔽标准相匹配，则在肯定响应消息中的 DTCStatusAvailabilityMask 字节之后不应提供任何 DTC 或状态信息。
DTC 状态信息应通过服务 1416 ClearDTC 服务（将 memorySelection 参数设置为适用的存储器）或通过制造商特定条件（例如来自客户端的例行控制请求）来清除。
21、从 DTC 用户定义内存中检索客户端定义的 DTC 掩码和客户端定义的 DTCSnapshotNumber 的用户定义内存 DTCSnapshot 记录数据 (SubFunction = 18 16 reportUserDefMemoryDTCSnapshotRecordByDTCNumber)
客户端可以通过发送对此服务的请求并将子函数设置为reportUserDefMemoryDTCSnapshotRecordByDTCNumber，来检索客户端定义的DTCMaskRecord 的捕获的DTCSnapshot 记录数据以及DTCSnapshot 记录号和用户定义的内存标识符。服务器应在其支持的 DTC 中搜索与客户端指定的 DTCMaskRecord 的精确匹配[包含 DTC 编号（高、中、低字节）]。客户端请求中提供的 DTCSnapshotRecordNumber 参数应指定指定 DTC 的特定出现以及为其请求 DTCSnapshot 记录数据的已定义内存。
注 1：DTCSnapshotRecordNumber 不与 DTCStoredDataRecordNumber 共享相同的地址空间。
系统供应商/车辆制造商应负责定义在此类服务器中捕获的 DTCSnapshot 记录是否存储与第一次或最近发生故障相关的数据。
如果已识别出客户端定义的 DTCMaskRecord 和 UserDefDTCSnapshotRecordNumber 参数（UserDefDTCSnapshotRecordNumber 不等于 FF16）和该特定记忆。
注 2：确切的失效标准由系统供应商/车辆制造商定义。
DTCSnapshot 记录可能包含多个数据参数，可用于重建故障发生时的车辆状况（例如 B+、RPM、时间戳）。
车辆制造商应在用户定义的存储器中定义 DTCSnapshotRecord 的格式和内容（即 DTCSnapshotRecord 的内容在不同存储器之间可以不同）记录。 DTCSnapshotRecord 中报告的数据首先包含一个 dataIdentifier 来标识后面的数据。该数据标识符/数据组合可以在 DTCSnapshotRecord 内重复。用户定义存储器中的 DTCSnapshotRecord 中的一个或多个数据标识符的使用允许针对不同的故障发生情况为单个 DTC 存储不同类型的 DTCSnapshotRecord。每个 DTCSnapshotRecord 应提供一个参数，指示每个 DTCSnapshotRecord 中包含的记录数据标识符的数量，以帮助数据检索。
服务器应在单个响应消息中报告一个 DTCSnapshot 记录，除非客户端已将 UserDefDTCSnapshotRecordNumber 设置为 FF16，因为这将导致服务器使用为客户端定义的 DTCMaskRecord 和用户定义的内存存储的所有 DTCSnapshot 记录进行响应。响应消息。 DTCAndStatusRecord 仅在响应消息中包含一次。
如果客户端指定的 DTCMaskRecord、UserDefDTCSnapshotRecordNumber、UserDefMemory 参数无效或服务器不支持，服务器应做出否定响应。这与以下情况不同：客户端指定的 DTCMaskRecord 和/或 UserDefDTCSnapshotRecordNumber 参数确实有效并且受服务器针对该特定内存的支持，但没有与其关联的 DTCSnapshot 数据（例如，因为从未发生故障事件）对于指定的 DTC 或记录号）。服务器应发送仅包含 DTCAndStatusRecord [请求的 DTC 编号（高、中、低字节）加上 statusOfDTC 的回显] 的肯定响应。
应根据来自客户端的制造商特定条件（例如例行控制）请求清除 DTCSnapshot 信息。车辆制造商有责任指定在内存溢出时删除存储的 DTC 和 DTCSnapshot 数据的规则（存储的 DTC 和 DTCSnapshot 数据的存储空间完全占用服务器中特定内存的存储空间）。

22、从 DTC 内存中检索客户端定义的 DTC 掩码和客户端定义的 DTCExtendedData 记录号的用户定义内存 DTCExtendedData 记录数据（SubFunction = 19 16 reportUserDefMemoryDTCExtDataRecordByDTCNumber）
客户端可以通过发送对此服务的请求并将子函数设置为reportUserDefMemoryDTCExtDataRecordByDTCNumber，来检索客户端定义的DTCMaskRecord 的DTCExtendedData 以及DTCExtendedData 记录号和UserDefMemoryIdenitfier。服务器应在其支持的 DTC 中搜索与客户端指定的 DTCMaskRecord [包含 DTC 编号（高、中、低字节）] 和 UserDefMemoryIdentifier 的精确匹配。在这种情况下，客户端请求中提供的 DTCExtDataRecordNumber 参数应指定正在请求 DTCExtendData 的指定 DTC 的特定 DTCExtendedData 记录。
除了 DTC 编号和 statusOfDTC 之外，服务器还应返回单个预定义的 DTCExtendedData 记录以响应客户端的请求（DTCExtDataRecordNumber 不等于 FE16 或 FF16）。
车辆制造商应定义 UserDefDTCExtDataRecord 的格式和内容。 DTCExtDataRecord 中报告的数据结构由特定用户定义存储器的 DTCExtDataRecordNumber 定义，其方式与记录 DataIdentifier 中的数据定义类似。响应中可以包括多个 DTCExtDataRecordNumber 和关联的 DTCExtDataRecord。使用一个或多个 DTCExtDataRecordNumber 允许为单个 DTC 存储不同类型的 DTCExtDataRecord。
服务器应在单个响应消息中报告一个 DTCExtendedData 记录，除非客户端已将 DTCExtDataRecordNumber 设置为 FE16 或 FF16，因为这将导致服务器使用在用户定义的内存中为客户端定义的 DTCMaskRecord 存储的所有 DTCExtendedData 记录进行响应。单个响应消息。
如果客户端指定的 DTCMaskRecord 或 DTCExtDataRecordNumber 参数无效或不受服务器支持或不在该特定内存中，服务器应做出否定响应。这应与客户端指定的 DTCMaskRecord 和/或 DTCExtDataRecordNumber 参数确实有效并受服务器支持，但没有与其关联的 DTC 扩展数据的情况不同（例如，由于扩展数据的内存溢出）。在通过 DTCNumber 报告 DTCExtDataRecord 的情况下，服务器应发送仅包含 DTCAndStatusRecord [请求的 DTC 编号（高、中和低字节）的回显加上 statusOfDTC] 的肯定响应。
应根据制造商特定条件通过服务 1416 Clear DiagnosticInformation（将内存选择参数设置为适用的内存）或通过来自客户端的例行控制请求来清除 DTCExtendedDataRecord 信息

23、检索支持特定 DTCExtendedDataRecord 的所有 DTC 的列表（SubFunction = 1A 16 reportSupportedDTCExtDataRecord）
客户端可以通过发送对此服务的请求（并将子函数设置为reportDTCExtendedDatatIdentification）来检索支持特定DTCExtendedDataRecord 的所有DTC 的列表。服务器应搜索其支持的 DTC。如果 DTC 支持请求的 DTCExtendedDataRecordNumber，则应将其包含在响应中。除了 DTC 编号和 DTC 状态之外，服务器还应返回该 DTC 的 DTCExtendedDataRecordNumber。如果客户端指定的 DTCExtendedDataRecord 参数无效或服务器不支持，服务器应做出否定响应。

24、从与客户端定义的状态掩码匹配的功能组中检索 VOBD DTC 列表（子功能 = 42 16 报告WWWHOBDDTCByMaskRecord）
ISO 271453[22] 中定义了 DTCSeverityMask（具有严重性和类别）的实现和使用

25、检索具有“永久 DTC”状态的 VOBD DTC 列表（子功能 = 5516 报告WWHOBDDTCWithPermanentStatus）
客户端可以检索具有“永久 DTC”状态的 VOBD DTC 列表，如 3.12 中所述。

26、检索客户端定义的 DTCReadinessGroupIdentifier 的 DTC 信息（SubFunction = 56 16 reportDTCInformationByDTCReadinessGroupIdentifier）
客户端可以通过发送此服务的请求来检索客户端定义的 DTC 就绪组标识符的 DTC 信息，并将子功能设置为reportDTCInformationByDTCReadinessGroupIdentifer。服务器应搜索其支持的 DTC，以查找与客户端指定的 DTCReadinessGroupIdentifier 的精确匹配。除了 DTC 编号和 DTC 状态之外，服务器还应返回这些 DTC 的 DTCReadinessGroupIdentifier。
如果客户端指定的 DTCReadinessGroupIdentifier 参数无效或服务器不支持，服务器应做出否定响应。

ControlDTCSetting (0x85) service

在UDS（Unified Diagnostic Services）中，85服务是一种诊断服务，其主要功能是用于读取和清除故障码（Diagnostic Trouble Codes，简称DTC）。这项服务允许用户通过诊断工具与车辆的电子控制单元（ECU）进行通信，并获取存储在ECU中的故障码信息。用户可以使用85服务来诊断车辆的故障，并清除已解决的故障码。这有助于确保车辆的正常运行和维护。

客户端应使用ControlDTCSetting服务停止或恢复服务器中DTC状态位的更新。在ReadDTCInformation (比特的定义参见D.2)的某些子函数的正响应的statusOfDTC参数中报告DTC状态位。ControlDTCSetting请求消息可用于停止单个服务器或一组服务器中DTC状态位的更新。如果被寻址的服务器不能停止DTC状态位的更新，它应该以一个ControlDTCSetting负响应消息响应，表明拒绝的原因。
当服务器接受子功能值为DTCSettingType = off的ControlDTCSetting请求时，服务器应暂停对DTC状态位(即冻结电流值)的任何更新，直到再次启用该功能。一旦在子功能设置为" on “的情况下执行ControlDTCSetting请求，或者在(例如会话层超时到defaultSession , ECU重置等。)情况下转换到不支持ControlDTCSetting的会话，DTC状态位信息的更新将继续。如果请求的子功能设置为"开"或"关”，即使请求的DTC设置状态已经处于活动状态，在活动会话中支持该服务，服务器仍应发送积极的响应。
如果客户端发送了ClearDiagnosticInformation ( 14 )服务，ControlDTCSetting不禁止重置服务器的DTC状态位。各DTC状态位的行为按照D.2、图D.1 ~图D.8中的定义执行。DTC状态位记录了相对于代表特定故障状态的数字标识符( DTC )的某些信息。控制DTCSetting只切换DTC状态位更新的开/关。控制DTCSetting服务并不是要导致故障监控被关闭，也不是要导致failuresoft策略被禁用。不建议将failuresoft或failuresafe策略直接与DTC状态位(例如,一个被接受的Clear Diagnostic Information请求并不直接移除任何活动故障软件)相关联或耦合。

支持的字服务。

85服务会用到功能寻址，在做ECU升级的情况，以广播的形式，在总线上发送85请求（28服务），关闭DTC存储和报告。

正响应

负响应

ClearDiagnosticInformation (14) service

清除某个DTC或者某类DTC
当 ClearDiagnosticInformation 服务处理完成时，服务器应发送肯定响应。即使没有存储 DTC，服务器也应发送肯定响应。如果服务器支持内存中 DTC 状态信息的多个副本（例如 RAM 中的一份副本和 EEPROM 中的一份副本）

服务器应清除 ReadDTCInformation 状态报告服务使用的副本。额外的副本，例如长期存储器中的备份副本根据适当的备份策略（例如在电源锁存阶段）进行更新。
注意：如果电源锁存阶段受到干扰（例如，电源锁存阶段电池断开），可能会导致数据不一致。
各个 DTC 状态位的行为应根据 D.2、图 D.1 至图 D.8 中的定义来实现
客户端的请求消息中包含一个参数。参数 groupOfDTC 允许客户端清除一组 DTC（例如动力总成、车身、底盘等）或特定 DTC。详细信息请参阅 D.1。除非另有说明，服务器应从内存中清除所请求组的排放相关和非排放相关的 DTC 信息。
通过该服务重置/清除的 DTC 信息包括但不限于以下内容： — DTC 状态字节（参见 12.3 中的 ReadDTCInformation 服务）， — 捕获的 DTC 快照数据（DTCSnapshotData，参见 12.3 中的 ReadDTCInformation 服务）， — 捕获的 DTC 扩展数据（ DTCExtendedData，参见 12.3 中的 ReadDTCInformation 服务）， — 其他 DTC 相关数据，例如第一个/最近的 DTC、标志、计数器、定时器等特定于 DTC 的数据。

文章来源地址https://www.toymoban.com/news/detail-639142.html

到了这里，关于DTC服务（0x14 0x19 0x85）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！