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 的數據。