診斷從 CAN 搬到乙太網之後，那套熟悉的 UDS 服務並沒有消失——它被裝進 DoIP（Diagnostics over IP，ISO 13400） 的信封裡，跑在 TCP/IP 上。刷寫大檔時 DoIP 的頻寬優勢明顯，但除錯工具也跟著換：以前看 CANoe 的 Trace，現在你會需要 Wireshark。這篇給一張抓包時看得懂的地圖。
本文是 UDS 是什麼 的傳輸層深入篇。UDS 是「說什麼」，DoIP 是「怎麼在乙太網上送」。
DoIP 的三段流程
一次 DoIP 診斷從連上網到送出第一個 UDS 請求，要走三段：
| 階段 | 做什麼 | 傳輸 |
|---|---|---|
| 1. 車輛宣告／識別 | 測試端找車、車回報自己的邏輯位址與 VIN | UDP（廣播） |
| 2. 路由啟動（Routing Activation） | 建立 TCP 連線並「登記」——沒這一步，診斷訊息會被拒 | TCP |
| 3. 診斷訊息 | UDS 請求／回應包在 DoIP 標頭裡收送 | TCP |
最常見的坑在第 2 段：TCP 連上了不代表能診斷——DoIP 要求先成功「路由啟動」，ECU 才接受後續的診斷訊息。抓包看到「TCP 連上、UDS 卻沒反應」，先檢查路由啟動有沒有成功、回應碼是什麼。
DoIP 標頭的關鍵欄位
每個 DoIP 封包都有一個標頭，除錯時最常看這幾格：
- Payload Type：這個封包是哪一種（車輛宣告、路由啟動請求／回應、診斷訊息、診斷回應確認…）
- Source Address / Target Address：邏輯位址——不是 IP，是診斷世界裡的 ECU 編號（例如測試端 0x0E80、閘道 0x1601）。一台車多顆 ECU 共用一個 DoIP 閘道時，就靠這組位址分辨要跟誰講話
- Payload Length：後面的資料長度
Wireshark 抓包速查
Wireshark 內建 DoIP 解析器，封包列的 Protocol 欄會直接標 DoIP／UDS。常用過濾語法：
doip 只看 DoIP 封包
doip.payload.type == 0x8001 只看診斷訊息
uds 只看解出來的 UDS 層
doip.source_address == 0x0e80 只看某個來源邏輯位址
doip.target_address == 0x1601 只看發給某顆 ECU 的實用技巧：把 Source Address 與 Target Address 用「Apply as Column」拉成欄位，一整條刷寫序列就能一眼看出「誰對誰、走到哪一步」。要對照 UDS 服務碼，展開封包裡的 UDS 層即可——0x34 請求下載、0x36 傳資料、0x37 結束，刷寫三部曲會清楚排列。
DoIP 特有的除錯情境
| 症狀 | 先查什麼 |
|---|---|
| 找不到車 | UDP 車輛宣告有沒有發、防火牆／網段對不對 |
| TCP 連上但診斷無回應 | 路由啟動回應碼（0x10 成功；其他值查原因） |
| 大檔刷寫中途斷 | TCP 重傳、視窗大小、逾時設定；DoIP 的存活檢查（alive check） |
| 多 ECU 時發錯對象 | Target Address 邏輯位址對不對 |
| 診斷正常但偶爾逾時 | 與一般乙太網流量搶頻寬？QoS／VLAN 隔離 |
最後這一條是 DoIP 相對 CAN 診斷的新變數：診斷流量現在跟其他乙太網服務共享實體網路，負載下的行為要專門驗——這也是為什麼車載乙太網的驗證要分實體層、協定層、服務層三層來看（見 100BASE-T1 是什麼）。
下一步
從 DoIP 診斷、乙太網一致性到刷寫流程驗證，歐特莫夫（Vector Informatik 合作夥伴）以 CANoe.Ethernet 把協定與封包放進同一個分析環境。
- 📄 解決方案：UDS 功能設計與驗證、車用乙太網路自動化驗證
- 📬 預約一次現況盤點