儀表板上的引擎故障燈亮起後，維修技師通常不會立刻拆開引擎。

他可能先把 Scan Tool 接到駕駛座附近的診斷接口，讀取故障碼、監測狀態與即時資料，再決定下一步要檢查哪個系統。

這段互動可以先簡化成：

Scan Tool
  → 車上的 16-pin 診斷接口
  → CAN 或其他受支援的診斷通訊
  → OBD 系統回傳標準化資料
  → 工具顯示故障碼、監測狀態或即時數值

看起來只是「插上接頭、讀出資料」，背後其實疊了好幾層標準。
接頭的形狀、使用哪些接腳、資料如何在 CAN 上傳送，以及某個 byte 代表什麼，各自由不同規格處理。

今天要回答的核心問題就是：OBD-II、16-pin DLC、CAN 診斷與 PID 到底是什麼關係？

今天的學習目標

讀完這篇文章，你應該能夠：

1. 說明 OBD-II 的目的與標準化範圍
2. 分辨 OBD-II、DLC、Scan Tool 與診斷協定
3. 找出 16-pin DLC 上和 CAN 診斷相關的接腳
4. 解釋 Service／Mode、PID、DTC 與 Readiness 的差異
5. 看懂一組簡化的 OBD-II over CAN 請求與回應
6. 說明為什麼接上診斷接口不等於取得所有 ECU 權限

OBD-II 不是一個讀取「全車祕密」的萬用插座

OBD 是 On-Board Diagnostics 的縮寫，可以翻成車載診斷。
OBD-II 則是第二代車載診斷要求與相關標準形成的診斷框架。

它的制度背景和排放監測密切相關。
以美國輕型車為例，1996 model year 起的適用車輛必須具備 OBD 系統，持續監測特定引擎與排放控制功能，並在偵測到符合條件的故障時保存資訊及點亮 Malfunction Indicator Light（MIL，故障指示燈）。

不同地區、車種與年份的法規適用範圍不完全相同，所以不能把「美國 1996 年」直接當成全世界所有車輛的共同起點。

OBD-II 提供的典型資訊包括：

• 目前的排放／動力相關資料
• Diagnostic Trouble Code（DTC，診斷故障碼）
• Freeze Frame（凍結資料），也就是故障被記錄時的部分運轉狀態
• Readiness Monitor（就緒監測）狀態
• MIL 狀態與部分車輛識別資訊

這些資料能協助檢驗與維修，卻不代表通用 Scan Tool 必須看得到座椅位置、車門控制、ADAS 內部資料或每一個 ECU 的廠商專用功能。

OBD-II 的「標準化」重點，是讓通用外部測試設備可以取得法規要求的最低診斷資訊，不是把車內所有資料與控制功能全部公開成同一套介面。

先把四個常被混用的名詞分開

日常討論常把車上的插座、藍牙轉接器與手機 App 全部叫作 OBD-II。
要看懂診斷資料，最好先把它們拆開：

DLC 是 Data Link Connector 的縮寫。
你看到的梯形 16-pin 診斷接口，常依 SAE J1962／ISO 15031-3 的要求設計。

圖 1：外部設備端的 OBD-II 接頭外觀示例，車輛端接口的位置、固定方式與周圍飾板會依車款而異
圖片來源：Alain Van den Hende Wikimedia Commons，CC BY-SA 4.0

這張照片展示的是一種外部設備接頭，不代表所有 Scan Tool 或車輛端接口都有相同外殼與線材。

16-pin DLC 上有哪些重要接腳？

16 個位置不代表 16 個接腳都會在每一台車上使用。
不同診斷通訊會使用不同接腳，標準也保留部分位置供特定用途配置。

先記住和常見乘用車 OBD-II 診斷最有關的幾組：

看到 pin 6 與 pin 14 有端子，是判斷車輛可能支援 CAN 診斷的線索，但外觀檢查不是完整的協定確認程序。
也不要用探針任意短接接腳，pin 16 帶有車輛電源，錯誤接線可能損壞設備或影響車輛系統。

美國聯邦規定自 2008 model year 起，適用的輕型車與輕型卡車要以 ISO 15765-4 支援標準化的車內到車外 OBD 通訊。
1996 到 2007 model year 的適用車輛則可能使用 SAE J1850、ISO 9141-2、ISO 14230-4 或 CAN，因此「有 OBD-II」不等於「一定在 CAN 上」。

OBD-II over CAN 疊了哪些層？

當 Scan Tool 經由 CAN 讀取 OBD 資料時，可以把路徑拆成幾層：

圖 2：OBD-II over CAN 的簡化資料路徑。DLC、CAN 傳輸與 OBD Service／PID 分別處理不同層次，實際 Gateway 與 ECU 配置依車款而異

ISO 15765-4 特別說明，它不規定車內 CAN 網路架構。
也就是說，標準要求外部設備能經由 DLC 完成必要通訊，但車內可能是診斷 CAN 直接連到相關 ECU，也可能先經過 Gateway 再轉送。

所以更精確的概念路徑可能是：

Scan Tool
  → DLC pin 6／14
  → 診斷 CAN
  → Gateway 的診斷路由與存取規則
  → 支援該項 OBD 資料的 ECU
  → 回應沿原路返回 Scan Tool

這也是為什麼兩台都有 16-pin DLC 的車，內部網路架構仍可能完全不同。

Service、PID、DTC 與 Readiness 不一樣

打開 OBD 工具後，最常看到的名詞不只一個。

Service／Mode：這次想做哪一類診斷操作？

較早的教材常使用 Mode 這個名稱，現行文件也常稱為 Diagnostic Service。
本文的傳統 OBD-II 範例使用一個 byte 表示 Service。

這張表只列出常見用途，不是所有 Service 的完整規格。
其中 $04 不是單純讀資料，還可能清除故障資訊並重設部分監測狀態，所以不應把任何 OBD 工具都當成唯讀設備。

PID：在這個 Service 裡想讀哪一項參數？

PID 是 Parameter ID 的縮寫，可以理解為參數識別碼。

在傳統 Service $01 中，工具會用 PID 指定要讀取的目前資料，例如：

並非每台車都要支援每一個可能的 PID。
工具應先確認支援 bitmap，再向車輛請求適用的參數，也要依對應資料定義解碼，不能只看到 PID 名稱就假設一定會有回應。

DTC：系統記錄了哪一類故障？

DTC 是 Diagnostic Trouble Code 的縮寫。
它是系統在符合特定故障判定條件後保存的診斷代碼，例如常見的 Pxxxx 類型。

DTC 和 PID 的用途不同：

PID → 這次想讀哪一項資料
DTC → 系統已記錄哪一類故障

讀到 DTC 只能指出診斷方向，不能只憑代碼就判定某個零件一定損壞。
線路、接頭、供電、感測器、執行器與軟體判定條件都可能影響結果，仍要配合維修程序確認根因。

Readiness：監測程序完成了嗎？

Readiness Monitor 用來表示相關車載監測是否已在需要的條件下完成。

Not Complete 不等於已經找到故障。
它可能代表清除診斷資訊或斷電後，車輛尚未完成所需的 driving cycle 與監測條件。

因此這三種資訊不能混在一起：

看懂一組車速 PID 的 CAN 請求與回應

下面使用常見的 11-bit CAN addressing 與傳統 SAE J1979 Service $01 做教學示範。
先假設 Scan Tool 要讀取 PID $0D，也就是車速。

請求 Frame 可以寫成：

CAN ID：0x7DF
Data  ：02 01 0D 00 00 00 00 00

0x7DF 是常見的 functional request CAN Identifier，代表請求可能由支援該服務的節點處理。
它不是 PID，也不是固定代表某一顆 ECU 的來源地址。

假設其中一個 ECU 回應：

CAN ID：0x7E8
Data  ：03 41 0D 30 00 00 00 00

PID $0D 的單位是 km/h，raw byte 0x30 等於十進位 48，因此本例回報：

車速 = 48 km/h

這裡有四個不能跳過的限制：

1. 0x7DF 與 0x7E8 是 CAN Identifier，$01 與 $0D 則位於 Data Field 的診斷內容
2. 0x7E8 只是這個 11-bit 教學情境中的一個回應 ID，其他 ECU 可能使用其他回應 ID，29-bit addressing 的格式也不同
3. 這筆回應代表 ECU 回報 48 km/h，不等於獨立量測已證明車輛真實速度正好是 48 km/h
4. 一般 OBD 工具顯示的數值，通常已替使用者處理 CAN、ISO-TP 與換算公式

這個例子也把 Day 04 的 CAN Frame 和今天的 OBD 資料接起來：

CAN Identifier
  → 負責 Frame 標籤與仲裁

Data Field 裡的 ISO-TP／OBD 內容
  → 表達訊息長度、Service、PID 與參數資料

不要把 PID $0D 誤認成 CAN ID 0x00D，它們位於不同層次。

讀 PID 和監聽車內 CAN 訊息不一樣

OBD PID 通常採用請求／回應模式：工具詢問一個受支援參數，ECU 再回傳標準化資料。

Day 03 到 Day 05 看到的一般車內 CAN 訊息，則可能由 ECU 週期性廣播，Identifier 與 signal 定義也可能屬於車廠或特定車系。

因此，手機 App 顯示標準車速 PID，不代表它已經找到車內儀表使用的原始車速 CAN signal。
兩者可能來自相關資料，卻不是同一個 Identifier 或同一層語意。

接上 DLC，為什麼不等於取得所有 ECU 權限？

DLC 提供的是一個接觸車輛診斷通訊的入口。
真正能到達哪個 ECU、使用哪項服務及執行什麼操作，仍取決於車輛架構與存取控制。

可能影響結果的條件包括：

• 車輛是否透過 Gateway 隔離診斷接口與不同網路區域
• Gateway 是否只轉送允許的 Address、Service 與資料方向
• ECU 目前處於哪一個 Diagnostic Session
• 特定操作是否需要 Security Access、憑證或其他授權程序
• 車輛狀態是否允許該操作，例如點火狀態、車速與電壓條件
• 工具讀取的是標準 OBD 資料，還是車廠增強型診斷功能

通用 OBD-II 資訊、車廠增強型診斷與 ECU 工程功能不是同一個權限等級。
某個便宜轉接器能讀取 PID $0D，不能據此推論它能重新刷寫煞車 ECU 或控制所有致動器。

反過來也不能因為通用 OBD 功能有限，就說 DLC 沒有資安價值。
如果車輛的 Gateway 規則過於寬鬆，或外接設備本身存在弱點，這個實體入口仍可能成為攻擊路徑的一部分。

從資安角度看 OBD-II 與外接轉接器

先沿用 Day 01 的三個名詞：

看見 DLC 不等於已經找到弱點。
仍要確認攻擊者需要實體接觸還是能透過無線連線，外接設備能送出哪些訊息，以及車內還有哪些 Gateway 與 ECU 控制。

長期插在車上的 Bluetooth／Wi-Fi OBD 轉接器，還會把短暫的實體維修入口變成持續存在的無線與軟體入口。
選用與使用時至少要注意：

• 產品是否有清楚的配對、更新與弱點修補機制
• 預設密碼或固定 PIN 是否能被更改
• App 要求的帳號、定位與雲端權限是否合理
• 不使用時是否真的需要讓轉接器留在車上
• 外接設備待機耗電是否可能造成電瓶負擔
• 工具是否會發出清除 DTC 或其他會改變狀態的命令

這些問題不是在宣稱所有 OBD 轉接器都有漏洞，而是在把一個硬體接口擴展成完整的外接設備攻擊面。

一個容易忽略的版本邊界：傳統 OBD 與 OBDonUDS

本文用 Service $01、PID $0D 與 0x7DF 的常見 11-bit CAN 範例建立基礎概念。
這套傳統 SAE J1979／ISO 15031-5 方式仍廣泛出現在教材、工具與既有車輛中。

新一代規範也已導入 OBDonUDS，以 SAE J1979-2 與相關文件定義法規 OBD 如何使用 UDS 架構，並可承載於 DoCAN 或 DoIP。

所以面對實車或封包紀錄時，要先確認：

1. 適用的地區、法規、車種與 model year
2. 車輛使用傳統 OBD Service／PID，還是 OBDonUDS
3. 診斷承載在 CAN、Ethernet／DoIP 或其他通道
4. 工具顯示的是標準 OBD 資料，還是車廠增強型資料

Day 08 會先介紹 Unified Diagnostic Services（UDS）的 Session、ReadData 與 SecurityAccess，再到 Day 09 把診斷搬到 Ethernet／DoIP 上。

今日實作：解讀一組 OBD 車速資料

下面是一組只用於教學的已授權測試台紀錄：

can0  7DF  [8]  02 01 0D 00 00 00 00 00
can0  7E8  [8]  03 41 0D 2A 00 00 00 00

請先回答：

1. 哪一筆是請求，哪一筆是回應？
2. 請求的 Service 與 PID 是什麼？
3. 回應中的 $41 代表什麼？
4. raw value $2A 換算後的車速是多少？
5. 這兩行能否證明車速感測器完全正常，或證明工具可以存取所有 ECU？
6. 如果要盤點資安邊界，還需要確認哪些架構資訊？

先停在這裡，不要急著往下滑！
請先把 CAN Identifier、ISO-TP 長度、Service、PID 與 raw value 分層標出，再往下對照作者的示範答案。

作者示範答案

第一筆使用 0x7DF，Data 中包含 Service $01 與 PID $0D，所以是讀取目前車速資料的 functional request。

第二筆使用 0x7E8，Data 中的 $41 是 Service $01 的 positive response，後面的 $0D 表示回覆車速 PID。

$2A 是十六進位：

0x2A = 42
車速 = 42 km/h

這兩行能證明的是：在這個教學情境中，有節點對車速 PID 請求回傳了 42 km/h。
它們不能單獨證明感測器、資料來源與實際車速完全一致，也不能證明工具具有其他 ECU 或其他診斷服務的權限。

如果要分析資安邊界，還要確認 DLC 連到哪一個網路、是否經過 Gateway、哪些 ECU 能回應、允許哪些 Service，以及外接轉接器有沒有無線與雲端功能。

這份答案使用教學用紀錄，不代表任何特定車款的實際 Gateway、CAN ID 或診斷權限配置。

安全與法律提醒： 診斷訊息擷取與傳送只應在模擬環境、隔離測試台或明確取得授權的設備上進行。
不要對道路車輛、他人的設備或公共基礎設施進行未授權測試，也不要在車輛行駛時操作測試工具。

今日重點

• OBD-II 的標準化核心是法規要求的排放／動力相關診斷資訊，不是整台車所有內部資料
• DLC 是外部設備與車輛之間的實體／電氣接口，常見車輛端具有 16 個接腳位置
• ISO 15765-4 的 CAN 診斷通常使用 pin 6 的 CAN_H 與 pin 14 的 CAN_L
• 美國 2008 model year 起的適用輕型車以 ISO 15765-4 支援標準化 OBD 通訊，較早車輛可能使用其他協定
• Service 表示診斷操作類型，PID 指定資料參數，DTC 記錄故障類型，Readiness 表示監測是否完成
• CAN Identifier 與 Data Field 裡的 Service／PID 位於不同層次，PID $0D 不是 CAN ID 0x00D
• 讀到 OBD 回應不等於已證明感測值真實，也不等於取得所有 ECU 權限
• DLC 是攻擊面，不是漏洞宣判，仍要分析外接設備、Gateway、診斷服務與授權條件
• 新車還可能使用 OBDonUDS，分析前要先確認車款、年份、法規與實際協定

明日預告

今天我們從 OBD-II 看見了標準化診斷資料，也知道 DLC 只是入口，真正的權限仍由 Gateway、ECU 與診斷服務共同決定。

Day 08 將介紹 UDS，看看維修工具如何切換 Diagnostic Session、使用 ReadData 讀取資料，以及為什麼某些服務還要通過 SecurityAccess。

參考資料

• U.S. EPA：OBD Frequently Asked Questions
• U.S. Code of Federal Regulations：40 CFR § 86.1806-05
• ISO：ISO 15031-3:2023 — Diagnostic connector and related electrical circuits
• SAE International：SAE J1962 — Diagnostic Connector
• ISO：ISO 15765-2:2024 — DoCAN transport protocol and network layer services
• ISO：ISO 15765-4:2021 — DoCAN requirements for emissions-related systems
• ISO：ISO 15031-5:2015 — Emissions-related diagnostic services
• SAE International：SAE J1979 — E/E Diagnostic Test Modes
• SAE International：SAE J1979-DA — Digital Annex of E/E Diagnostic Test Modes
• SAE International：SAE J1979-2 — OBDonUDS