引擎燈亮了，維修廠拿一支診斷儀插到方向盤下方的接頭，螢幕跳出「P0301」。這支儀器在跟車講什麼語言？那串代碼怎麼解？以及——為什麼原廠的診斷電腦看得到的東西，通用診斷儀看不到？這三個問題背後，是兩套並存的診斷體系。
OBD-II：法規要求的「公開頻道」
OBD-II（On-Board Diagnostics 第二代）是排放法規的產物：法規要求任何人（車主、獨立維修廠、驗車單位）都能用標準工具讀到與排放相關的資訊。所以它的三個特徵都來自「公開」：
- 接頭標準化：統一的 16 腳位診斷座，位置在駕駛座附近
- 代碼標準化：故障碼（DTC）的編碼規則全球一致
- 服務標準化：以「模式（Mode）」定義的一組標準查詢
故障碼 P0301 怎麼拆
OBD-II 的 DTC 是「一個字母＋四個數字」：
| 位置 | 意義 | 例：P0301 |
|---|---|---|
| 第 1 碼（字母） | 系統：P 動力、B 車身、C 底盤、U 網路 | P＝動力系統 |
| 第 2 碼 | 0＝SAE 標準碼、1＝車廠自訂碼 | 0＝標準碼 |
| 第 3 碼 | 子系統（燃油、點火、排放⋯） | 3＝點火系統 |
| 第 4–5 碼 | 具體故障 | 01＝第一缸失火 |
所以 P0301 讀作：動力系統／標準碼／點火／第一缸失火。第 2 碼是重點——0 開頭全球查得到，1 開頭要看各車廠的資料。
常用模式速查
| 模式 | 用途 | 常見情境 |
|---|---|---|
| Mode $01 | 讀即時資料（轉速、水溫、感知器電壓） | 邊開邊看數值 |
| Mode $02 | 讀凍結畫面（故障當下的快照） | 還原故障情境 |
| Mode $03 | 讀已確認的故障碼 | 引擎燈亮了查原因 |
| Mode $04 | 清除故障碼與凍結畫面 | 修完復歸 |
| Mode $09 | 讀車輛資訊（VIN 等） | 驗車、報告 |
那 UDS 是什麼？原廠的「全功能頻道」
OBD-II 只覆蓋法規要求的排放相關範圍。車上其他幾十顆 ECU 的完整診斷——讀寫組態、安全存取、韌體刷寫、全部 DTC 與快照——走的是 UDS（ISO 14229），也就是原廠與供應商工程端用的協定：
| OBD-II | UDS | |
|---|---|---|
| 目的 | 法規（排放監控） | 工程（開發、產線、售後全功能） |
| 範圍 | 排放相關系統 | 整車所有 ECU |
| 代碼 | 5 碼標準 DTC | 3 位元組 DTC＋狀態位元＋快照 |
| 存取控制 | 無（就是要公開） | 會話＋安全存取（種子—金鑰） |
| 能做的事 | 讀值、讀碼、清碼 | 加上：寫入、例程、刷寫韌體 |
兩套體系共用同一個接頭、常常共存在同一顆 ECU 裡——通用診斷儀講 OBD-II，原廠診斷電腦講 UDS。這就是「原廠看得到、通用儀器看不到」的原因：不是藏起來，是走不同協定、過不同的存取控制。
UDS 的會話、服務與安全存取怎麼運作，我們在 UDS 是什麼 有完整的服務地圖；DTC 在工程端怎麼被設定與測試，見行車資料怎麼錄才有用的觸發一節。
工程視角的三個提醒
- 「清碼」不等於「修好」——DTC 有成熟化機制，條件再次成立就會回來；工程端關心的是「什麼操作條件讓它被設定」，這才是測試案例的素材
- U 開頭的碼越來越重要——網路通訊故障（某顆 ECU 失聯）在區域架構下會是大宗，除錯要回到匯流排層（見 CAN 錯誤訊框從哪來）
- 診斷測試要自動化——一顆 ECU 數百個 DTC，每個都有設定條件、成熟化、老化邏輯要驗，人工按診斷儀跑不完
下一步
從 DTC 設計、診斷規格（CDD）到自動化驗證，歐特莫夫（Vector Informatik 合作夥伴）協助把診斷這條鏈建成可回歸的測試資產。
- 📄 解決方案：UDS 功能設計與驗證、ECU 參數診斷與校正
- 📬 預約一次現況盤點