UDS $19 服務詳解：DTC 狀態位元組與子功能怎麼用

0x19 ReadDTCInformation 是 UDS 裡子功能最多、也最能體現「診斷」二字的服務。多數人只用過「把碼讀出來」，但 $19 真正的價值在狀態位元組與環境資料——它們回答的不是「有沒有故障」，而是「這個故障走到生命週期的哪一步、發生當下世界長什麼樣」。

本文是 UDS 是什麼的深入篇。UDS 的 DTC 是 3 位元組（High/Middle/Low），與 OBD-II 的 5 碼格式不同——兩者的關係見 OBD2 是什麼。

先懂狀態位元組：一個 DTC 的八個開關

每個 DTC 都帶著一個 8 位元的狀態位元組（DTC Status Byte），每一位元回答一個問題：

位元	名稱	回答的問題
bit 0	testFailed	此刻測試是失敗的嗎？
bit 1	testFailedThisOperationCycle	這個點火週期內失敗過嗎？
bit 2	pendingDTC	待定中（失敗過但還沒確認）？
bit 3	confirmedDTC	已確認（達到成熟化條件）？
bit 4	testNotCompletedSinceLastClear	清碼後這個測試還沒跑完過？
bit 5	testFailedSinceLastClear	清碼後失敗過嗎？
bit 6	testNotCompletedThisOperationCycle	本週期測試還沒跑完？
bit 7	warningIndicatorRequested	要求點亮警示燈嗎？

三個實務推論：

testFailed=0 不代表沒問題——可能是條件還沒到（testNotCompleted），「沒測」與「測過沒事」是兩回事
pending → confirmed 是成熟化機制：偶發一次不立刻定罪，連續幾個週期都失敗才確認——這套「防抖」邏輯正是測試要驗的重點
讀 DTC 時下的**狀態遮罩（Status Mask）**就是對這 8 位元做篩選：遮罩 0x08 ＝只要 confirmed 的

子功能地圖：常用的七個

子功能	名稱	用途
0x01	reportNumberOfDTCByStatusMask	符合遮罩的 DTC 有幾個（先問數量再撈明細）
0x02	reportDTCByStatusMask	依遮罩列出 DTC ＋狀態（最常用）
0x04	reportDTCSnapshotRecordByDTCNumber	讀快照（故障當下的環境資料）
0x06	reportDTCExtDataRecordByDTCNumber	讀擴充資料（發生次數、老化計數器等）
0x0A	reportSupportedDTC	這顆 ECU 支援哪些 DTC（測試的母集合）
0x14	reportDTCFaultDetectionCounter	故障偵測計數器（走向成熟的過程值）
0x03	reportDTCSnapshotIdentification	有哪些快照可讀

**快照（Snapshot／Freeze Frame）**是除錯金礦：DTC 確認的那一刻，ECU 把預先定義的一組環境值（車速、電壓、溫度、運轉狀態）凍結存檔。三個月後客訴進來，快照就是「案發現場的照片」。**擴充資料（Extended Data）**則記錄生命週期統計——發生次數、老化倒數（healing counter）——判斷「偶發還是慢性」靠它。

測試視角：$19 案例最常漏的四件事

成熟化與去成熟化路徑：注入故障 N 個週期 → confirmed；恢復正常 M 個週期 → 老化清除。N 與 M 的邊界（N-1 個週期會怎樣？）是規格對不對得上實作的試金石
快照內容的正確性：不只驗「讀得到」，要驗凍結的值是不是故障當下的值（時序問題會凍到錯的瞬間）
遮罩組合：0x02 帶不同遮罩的回應集合要互相一致（pending ∪ confirmed ⊆ supported）
與 $14 清碼的互動：清碼後所有狀態位元的重置行為、testNotCompletedSinceLastClear 的翻轉

一顆 ECU 幾百個 DTC，每個都有這套生命週期——這就是 $19 測試必須從 CDD 規格自動生成的原因（CANoe.DiVa 的做法），人工窮舉在數學上就不可行。

下一步

從 DTC 規格定義（CDD）到 $19 全子功能的自動化驗證，歐特莫夫（Vector Informatik 合作夥伴）協助把診斷測試建成可回歸的資產。

📄 解決方案：UDS 功能設計與驗證
📬 預約一次現況盤點