維修技師要替一顆高效能控制器更新軟體時，若更新檔有數百 MB，只靠 Classical CAN 慢慢傳送，等待時間可能成為整個維修流程的瓶頸。

如果車輛本來就有 Automotive Ethernet，診斷工具便可以先透過 IP 找到車輛，再建立 TCP 連線，啟用通往目標 ECU 的診斷路徑，最後傳送 Day 08 學過的 UDS 訊息。

這段互動可以先簡化成：

診斷工具
  → 透過 UDP 找到 DoIP Entity
  → 建立 TCP 連線
  → 完成 Routing Activation
  → 傳送承載 UDS 的 DoIP Diagnostic Message
  → DoIP Gateway 將訊息送往目標 ECU

這就是 **DoIP（Diagnostic communication over Internet Protocol，透過網際網路協定進行診斷通訊）**要處理的事情。

今天的核心問題是：UDS 搬到 Ethernet／IP 後，診斷工具如何找到車輛、啟用路由，再把訊息送到正確的 ECU？

今天的學習目標

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

1. 說明 DoIP、UDS、TCP／UDP、IP 與 Ethernet 的分工
2. 分辨 Tester、DoIP Entity／Gateway 與目標 ECU 的角色
3. 解釋 Vehicle Discovery 與 Routing Activation 的用途
4. 看懂 DoIP Generic Header、Payload Type 與 Logical Address
5. 說明 DoIP Positive ACK 為什麼不等於 UDS Positive Response
6. 找出 DoIP 診斷路徑中的資安邊界與必要控制

DoIP 是什麼？

DoIP 是 ISO 13400 系列定義的 IP-based 車輛診斷通訊。

現行的 ISO 13400-2:2025 規範 Client DoIP Entity 與車內 Server 之間，如何使用 IP、TCP 與 UDP 建立、維持及路由診斷通訊。

它涵蓋的核心能力包括：

• IP 位址配置與車輛網路整合
• Vehicle Announcement 與 Vehicle Discovery
• 建立及維持連線
• Routing Activation 與 Gateway 控制
• 將診斷資料路由到車內子系統
• 連線中斷與格式錯誤等異常處理

因此 DoIP 不是「把 UDS bytes 丟進一條 TCP 連線」這麼簡單。
它還定義了工具如何發現車輛、辨識 DoIP Entity、啟用診斷路徑，以及如何確認診斷訊息已被 DoIP 層接收或拒絕。

名稱裡有 Internet，不代表車輛直接暴露在公網

DoIP 的 IP 指 Internet Protocol，也就是使用 IP 的定址與傳輸生態系。

它可以運作在維修廠的區域網路、車輛與診斷工具之間的直連網路，或車內 Automotive Ethernet 上。
光看見 DoIP，不能推論車輛一定能從公開 Internet 直接連入。

能否遠端到達 DoIP 服務，仍取決於實際架構：

• 車輛是否有對外網路路徑
• Router、Gateway 與 Firewall 如何設定
• 診斷服務綁定在哪一個介面與網段
• 遠端診斷是否需要 VPN、TLS、憑證或後端授權

所以「使用 IP」和「可由全世界連線」是兩件不同的事。

為什麼診斷要從 CAN 走向 Ethernet？

Day 08 的 UDS on CAN 常透過 ISO-TP，把較長的 UDS 訊息拆成多個 CAN Frame。
這種方式很成熟，也能服務大量既有 ECU，但軟體映像與診斷資料持續增大後，頻寬與更新時間會變得更重要。

DoIP 的價值可以從四個方向理解：

這張表不是在說 DoIP 會取代所有 DoCAN。

DoIP Gateway 後方仍可能連著 CAN／CAN FD ECU，於是診斷資料到了 Gateway 後，還要再轉成 UDS on CAN。
這時 Ethernet 只加快工具到 Gateway 的一段路徑，端到端速度仍可能受下游網路、ECU Flash 速度與安全驗證流程限制。

DoIP 提供高頻寬診斷路徑的可能性，不代表每一顆 ECU 的更新都會自動變快。

把 DoIP 放回分層架構

Day 08 曾把 UDS、ISO-TP 與 CAN 分開。
今天保留 UDS 這個服務語言，把下層換成 DoIP 與 TCP／IP：

圖 1：UDS 定義診斷服務語意，DoIP 負責 IP-based 診斷承載、發現與路由，TCP／UDP、IP 及 Ethernet 則處理各自的傳輸層次。實際下游網路依車款而異

ISO 14229-2 讓 UDS Session Layer 和特定 Transport Protocol 解耦，因此同一個 0x22 ReadDataByIdentifier 可以走 DoCAN，也可以走 DoIP。

真正改變的是外層包裝與傳送路徑，不是 0x22 的服務語意。

三個角色：Tester、DoIP Entity 與目標 ECU

一條 DoIP 診斷路徑至少會看見三種角色。

1. External Test Equipment／Tester

Tester 是外部診斷工具，也就是 DoIP Client。

它可能是維修電腦、產線測試設備或已取得授權的工程工具，負責：

• 取得自己的 IP 設定
• 發現或選擇車輛
• 建立 TCP 連線
• 提出 Routing Activation Request
• 傳送 UDS Request 並解析 Response

2. DoIP Entity

DoIP Entity 是支援 DoIP Protocol 的車內節點。

它可能是：

• DoIP Gateway：接收外部診斷訊息，再路由到其他 ECU 或車載網路
• DoIP Node：本身就是診斷訊息的終點，不再替其他節點轉送

實際車輛常讓中央 Gateway 或高效能控制器扮演 DoIP Entity，但不能只靠產品名稱判斷它是 Gateway 還是 Node。

3. Diagnostic Server／目標 ECU

目標 ECU 是實際處理 UDS Request 的 Server。

它可能直接支援 DoIP，也可能位於 DoIP Gateway 後方的 CAN／CAN FD 網路。
所以 Tester 建立連線的 IP 對象，不一定就是最後處理 0x22 或 0x34 的那顆 ECU。

IP Address 與 Logical Address 不一樣

DoIP 同時出現兩種容易混淆的位址。

假設 Tester 連到一個 DoIP Gateway，接著想讀取 Gateway 後方的 ADAS ECU：

目的 IP Address
  → 把 packet 送到 DoIP Gateway

DoIP Target Address
  → 告訴 Gateway 這筆診斷訊息要交給哪個 Logical ECU

IP Address 不能取代 DoIP Logical Address，Logical Address 也不是 Ethernet MAC Address。

這種分工讓一個 DoIP Gateway 可以代表多個車內診斷節點對外提供路由，也讓 Gateway 有機會依來源、目標與服務建立存取規則。

UDP 與 TCP 各自做什麼？

DoIP 沒有只選一種 Transport Protocol。

IANA 將 UDP port 13400 登記為 doip-disc，也就是 DoIP Discovery。
TCP port 13400 則登記為 doip-data。

可以先用下面的表格建立分工：

UDP 沒有先建立 Session 的握手，因此適合讓工具在本地診斷網路尋找車輛。
但 UDP 本身不保證抵達、順序或不重複，應用層仍要處理 timeout、重試與重複訊息。

TCP 會先建立連線，並提供有序及可靠傳輸。
但 TCP 的「可靠」指 byte stream 傳送，不代表對端身分可信，也不代表資料已加密或獲得診斷授權。

一次 DoIP 診斷如何開始？

從工具接上診斷網路到讀取 ECU 資料，可以拆成六個階段：

圖 2：DoIP 先用 UDP 發現車輛，再建立 TCP 連線並完成 Routing Activation，之後才交換 Diagnostic Message。Routing Activation 不會取代 UDS Session 與 SecurityAccess

1. 準備實體連線與 IP 設定

Tester 與車輛先建立 Ethernet Link，再取得可互通的 IP 設定。

IP 位址可能由不同機制配置，實際流程要看車輛、測試設備與使用情境。
若 IP 子網路、VLAN 或實體 Link 都不通，後面的 DoIP Discovery 當然不會成功。

ISO 13400-3:2016 定義一種以 IEEE 802.3 100BASE-TX 為基礎的有線車輛介面，ISO 13400-4:2016 則規範以 ISO 15031-3 診斷接頭為基礎的高速 Ethernet Connector 要求與兩種 pin assignment。

不過，這不表示每一個實際車內 DoIP Link 都只能使用同一種外觀、PHY 或線束配置。
分析車輛時仍要確認實際 Connector、Activation Line、PHY 與網路拓樸。

2. 使用 UDP 完成 Vehicle Discovery

Tester 可以送出 Vehicle Identification Request，DoIP Entity 再以 Vehicle Identification Response 回覆。

車輛也可以主動送出 Vehicle Announcement。
Identification Response／Announcement 可提供 VIN、DoIP Entity Logical Address 與 EID 等識別資訊，讓工具知道網路上有哪些可選擇的車輛或診斷入口。

Discovery 回覆的意義是「找到一個 DoIP Entity」，不是已經取得診斷權限。

3. 建立 TCP 連線

Tester 選定 DoIP Entity 後，建立到 DoIP TCP port 的連線。

TCP 連線成功只能證明兩端已建立 Transport Layer 通道。
DoIP Entity 還沒有因此承諾替這個 Tester 路由所有診斷訊息。

4. 完成 Routing Activation

Tester 在 TCP 連線上送出 Routing Activation Request，其中包含 Tester 的 Logical Address 與 Activation Type 等資料。

DoIP Entity 會依規則檢查這次要求，可能還要配合 OEM-specific authentication 或 confirmation。
接受後才回傳成功的 Routing Activation Response，讓該 TCP 連線進入可路由診斷訊息的狀態。

Routing Activation 的用途是啟用 DoIP 診斷路徑，它不等於：

• 已進入 UDS Extended 或 Programming Session
• 已通過 0x27 SecurityAccess
• 已取得每一顆 ECU 的所有診斷權限
• 後續訊息已經加密

換句話說，DoIP Routing Activation 與 UDS Diagnostic Session 位於不同層次。

5. 交換 Diagnostic Message

路由啟用後，Tester 才在 TCP 連線上傳送 Payload Type 0x8001 的 DoIP Diagnostic Message。

Diagnostic Message Payload 先放入：

1. 2 bytes Source Address
2. 2 bytes Target Address
3. 後續的 User Data，也就是 UDS 等診斷資料

例如，下面是概念化的 UDS Request：

DoIP Source Address：0x0E80  教學用 Tester 位址
DoIP Target Address：0x1001  教學用 ECU 位址
UDS User Data      ：22 F1 90

22 F1 90 仍然是 Day 08 學過的 ReadDataByIdentifier，要求讀取 DID 0xF190。
前面的 Source／Target Address 則讓 DoIP Entity 知道訊息從哪裡來、要送到哪一個診斷節點。

回應方向會反過來：

DoIP Source Address：0x1001
DoIP Target Address：0x0E80
UDS User Data      ：62 F1 90 ...

以上 Logical Address 只用於教學，不代表任何特定車款的實際配置。

6. 維持與結束連線

DoIP Entity 可以使用 Alive Check 確認已連線的 Tester 是否仍然存在，也會依連線狀態與資源限制管理 Socket。

診斷結束、TCP 連線關閉或網路中斷後，相關 DoIP 路由狀態也要正確清理。
UDS Session 與 Security Level 是否一併失效，則要再依 ECU 與整體診斷架構確認，不能只靠 TCP Socket 狀態推論。

DoIP Generic Header 長什麼樣子？

每一筆 DoIP Message 前面都有 8 bytes 的 Generic Header：

Inverse Protocol Version 是格式檢查，不是密碼學完整性保護。
攻擊者若能建立任意 DoIP Message，也能計算正確的反碼。

常見 Payload Type 可以整理成：

這張表用來建立封包閱讀順序，不是所有版本與實作細節的完整清單。
遇到封包時，仍要先確認採用的 ISO 13400 版本與實際車輛設定。

DoIP Positive ACK 不等於 UDS Positive Response

這是 DoIP 初學最容易混淆的地方。

假設 Tester 送出一筆 0x8001 Diagnostic Message，DoIP Entity 回覆 0x8002 Diagnostic Message Positive Acknowledgement。

這項 ACK 提供的是 DoIP 層的早期回饋，表示診斷訊息已由 DoIP Entity 接收並能交給內部 ECU，或已送往目標網路。
它不代表目標 ECU 已接受 UDS 服務。

真正的 UDS 結果還要等另一筆 0x8001 Diagnostic Message 回來，檢查其中的 UDS User Data：

DoIP 0x8002 Positive ACK
  → DoIP 層接受這筆診斷訊息

DoIP 0x8001，UDS User Data = 62 F1 90 ...
  → ECU 對 0x22 回傳 UDS Positive Response

DoIP 0x8001，UDS User Data = 7F 22 31
  → ECU 對 0x22 回傳 UDS Negative Response

因此，一次完整分析要分開看三件事：

Gateway 可能還要把 DoIP 轉回 DoCAN

假設中央 Gateway 支援 DoIP，但目標 Body ECU 只有 CAN 介面，資料路徑可能是：

Tester
  → Ethernet／IP／TCP
  → DoIP Gateway
  → 解析 DoIP Source／Target Address
  → 映射到允許的 CAN addressing
  → ISO-TP／CAN
  → Body ECU 的 UDS Server

Gateway 不只是做格式轉換。
它還應該確認：

• 這個 Tester 是否可以到達該 Target Address
• Routing Activation Type 是否允許這條路徑
• 哪些 UDS Service 可以跨越網域
• 診斷流量的頻率與大小是否合理
• 車輛狀態是否允許高風險操作
• 下游 ECU 沒有回應或傳輸錯誤時如何回報

如果 Gateway 只把每一筆外部 DoIP Message 無條件轉成 CAN，它就會把 Ethernet 診斷入口擴大成車內控制網路的直接入口。

DoIP 帶來哪些資安問題？

DoIP 使用成熟的 Ethernet／IP 技術，代表防禦者可以運用 Switch、VLAN、Firewall、TLS 與網路監控，也代表熟悉的 IP 攻擊面會一起進入車載診斷環境。

1. Discovery 會揭露哪些資訊？

Vehicle Identification Response 可能包含 VIN、Logical Address 與 EID 等資料。
如果未受信任的裝置能進入診斷網段，它可能先利用 Discovery 盤點可見車輛與 DoIP Entity。

分析時要確認：

• 哪些實體介面與 VLAN 可以送出 Discovery
• 車輛在什麼狀態下會回覆
• 回覆資訊是否超出使用情境所需
• 是否能偵測異常掃描與大量 Request

2. Routing Activation 是控制點，但不是唯一防線

Routing Activation 決定一條 TCP 連線能否進入可路由診斷訊息的狀態。
系統應限制允許的 Tester Logical Address、Activation Type、並行連線與目標路徑，必要時加入 authentication／confirmation。

不過，Gateway 接受 Routing Activation 後，目標 ECU 仍要保留自己的 Session、Security Level、車輛條件與服務權限檢查。

3. TCP 不提供機密性與身分驗證

TCP 可以重傳遺失資料並維持順序，但基礎 TCP 不會自動加密 UDS Payload，也不會替 Tester 提供密碼學身分證明。

ISO 13400-2:2025 將 TLS 列為可選能力。
是否使用 TLS、如何管理憑證，以及哪些路徑允許 unsecured DoIP，都要由實際架構與威脅模型決定。

即使使用 TLS，也不代表工作已經結束。
系統仍要處理憑證生命週期、私鑰保護、撤銷、時間來源、Cipher 設定與授權映射。

4. 高頻寬也可能放大可用性風險

DoIP 可以承載比 Classical CAN 更大量的診斷資料，但 Socket、Buffer、Gateway 路由與下游 CAN 仍有資源上限。

異常連線或大量 Diagnostic Message 可能消耗：

• TCP Connection 與 DoIP Socket
• Gateway Buffer 與 CPU
• 下游 CAN Bus 頻寬
• ECU 診斷工作與 Flash 資源

因此需要連線數限制、Payload Length 檢查、timeout、rate limiting、異常流量監控與可復原的錯誤處理。

5. IP 分區不能只停在 VLAN 標籤

VLAN 能協助分區與轉送，但 VLAN tag 本身不是可信身分。

DoIP 診斷區域還要搭配：

• Switch ingress filtering
• Router／Firewall allowlist
• Tester 與憑證授權
• DoIP Source／Target Address 驗證
• UDS Service 與車輛狀態限制
• 完整的診斷事件紀錄

防護重點不是「因為用了 Ethernet，所以套一台 Firewall 就好」，而是把網路層、DoIP 路由與 ECU 服務權限串成多層控制。

用 ECU 軟體更新串起整條路徑

回到文章開頭，一次概念性的 DoIP 更新流程可能是：

1. 維修工具接上已授權的 Ethernet 診斷網路
2. 透過 UDP Vehicle Discovery 找到正確車輛
3. 建立 TCP 連線並完成 Routing Activation
4. 選擇目標 ECU 的 Logical Address
5. 使用 UDS 讀取 ECU 身分與目前軟體版本
6. 進入 Programming Session，完成必要授權
7. 驗證更新檔來源、完整性與車輛前置條件
8. 透過 UDS Download／Transfer Services 傳送資料
9. ECU 驗證、寫入並回報結果
10. 工具再次讀取版本，保存操作紀錄並安全結束診斷

這條流程不是任何特定車款的原廠更新程序，也不能取代 Service Manual。

它要表達的是，DoIP 解決「如何找到入口並把診斷資料送到目標」，UDS 解決「要求 ECU 做什麼」，更新安全則還需要簽章驗證、Anti-rollback、穩定供電與失敗復原等機制。

DoIP 傳得快，不等於更新檔可信，也不等於 ECU 能安全承受中斷。

今日實作：解讀一段 DoIP 事件紀錄

下面是一段只用於教學的已授權測試台事件紀錄。
Logical Address、VIN 與 ECU 配置都是虛構資料：

1. UDP  0x0001  Vehicle Identification Request
2. UDP  0x0004  Vehicle Identification Response
                 VIN=TESTVIN1234567890, DoIP Entity=0x0E00

3. TCP           Connection established to DoIP Entity
4. TCP  0x0005  Routing Activation Request, Tester=0x0E80
5. TCP  0x0006  Routing Activation Response, code=0x10

6. TCP  0x8001  Source=0x0E80, Target=0x1001, UDS=22 F1 90
7. TCP  0x8002  Diagnostic Message Positive Acknowledgement
8. TCP  0x8001  Source=0x1001, Target=0x0E80, UDS=7F 22 33

請先回答：

1. 哪兩筆訊息完成 Vehicle Discovery？
2. 哪一筆表示 DoIP 診斷路由已啟用？
3. 0x0E80 與 0x1001 分別扮演什麼角色？
4. 0x8002 能否證明 ECU 已成功讀出 DID？
5. 最後的 7F 22 33 屬於 DoIP 錯誤，還是 UDS Negative Response？
6. 下一步應該檢查哪一類存取條件？

先停在這裡，不要急著往下滑！
請先把 UDP／TCP、DoIP Payload Type、Logical Address 與 UDS SID 分層標出，再往下對照作者的示範答案。

作者示範答案

第 1 筆是 Vehicle Identification Request，第 2 筆是 Vehicle Identification Response，兩者透過 UDP 完成 Discovery。

第 3 筆只表示 TCP 連線已建立。
直到第 5 筆收到成功的 Routing Activation Response，這條 Socket 才進入可路由診斷訊息的狀態。

最後一筆仍封裝在 Payload Type 0x8001 裡，真正的拒絕原因位於 UDS User Data。
因此它不是 DoIP Generic Header 錯誤，也不是 Routing Activation 失敗。

下一步應依 ECU 診斷規格確認目前 Diagnostic Session、需要的 Security Level、車輛前置條件與 Gateway Policy。
不能因為看見 0x33 就直接反覆嘗試 seed／key，也不能假設通過某一個 Security Level 後，其他 DID 或 ECU 都會開放。

這份紀錄只示範協定分層，不代表任何特定車款採用相同 VIN、Logical Address、Routing Activation 或診斷權限。

安全與法律提醒： DoIP Discovery、Routing Activation 與診斷服務測試只應在模擬環境、隔離測試台或明確取得授權的設備上進行。
不要掃描道路車輛、維修廠網路、他人的設備或公共基礎設施，也不要在車輛行駛時操作診斷工具。

今日重點

• DoIP 是 ISO 13400 定義的 IP-based 診斷通訊，不代表車輛直接暴露在公開 Internet
• UDS 定義診斷服務語意，DoIP 負責 Vehicle Discovery、Routing Activation 與診斷路由
• UDP 常用於 Discovery 與簡短狀態交換，TCP 則承載 Routing Activation 與持續的 Diagnostic Message
• IP Address 把 packet 送到 DoIP Entity，Logical Address 則標示診斷訊息的來源與目標節點
• Routing Activation 只啟用 DoIP 診斷路徑，不會取代 UDS Session、SecurityAccess 與車輛條件檢查
• DoIP Message 使用 8-byte Generic Header，再依 Payload Type 放入不同內容
• DoIP 0x8002 Positive ACK 不等於 UDS Positive Response，真正服務結果要看回傳的 UDS User Data
• DoIP Gateway 後方仍可能是 CAN／CAN FD，端到端效能與權限要看完整路徑
• TCP 不自動提供加密或身分驗證，ISO 13400-2:2025 中的 TLS 仍是可選能力
• DoIP 防護要結合網路分區、Routing Policy、ECU 權限、流量限制與事件紀錄

明日預告

走完 OBD-II、UDS 與 DoIP 後，我們已經從實體診斷接口一路走到 Ethernet／IP。

Day 10 將正式從車內走向車外，介紹 V2X 的 V2V、V2I、V2P 與 V2N，看看車輛如何和其他車輛、道路設施、行人裝置及網路服務交換資訊。

參考資料

• ISO：ISO 13400-2:2025 — DoIP transport protocol and network layer services
• ISO：ISO 13400-3:2016 — Wired vehicle interface based on IEEE 802.3
• ISO：ISO 13400-4:2016 — Ethernet-based high-speed data link connector
• ISO：ISO 14229-2:2021 — UDS session layer services
• AUTOSAR：Specification of Diagnostic over IP，Classic Platform R24-11
• AUTOSAR：Requirements on Diagnostics，Foundation R25-11
• IANA：Service Name and Transport Protocol Port Number Registry