UDS 是什麼？從診斷會話到安全存取，一張服務地圖看懂 ISO 14229

維修站的診斷儀、產線的刷寫站、開發桌上的測試腳本，對 ECU 講的其實是同一種語言：UDS（Unified Diagnostic Services，ISO 14229）。它是請求／回應式的服務協定——測試端發一個服務請求，ECU 回肯定或否定回應。看懂三個概念，整套協定就有了地圖。

概念一：會話（Session）決定你能做什麼

ECU 開機後處於預設會話，只開放基本服務。要做進階的事，先用 0x10 DiagnosticSessionControl 切換：

• 預設會話：讀資料、讀故障碼等日常操作
• 延伸會話：開放寫入、例程控制等工程操作
• 程式更新會話（programmingSession）：允許刷寫韌體

會話有「保鮮期」：一段時間沒有通訊就退回預設會話，所以長時間操作要週期性發 0x3E TesterPresent 保持連線。很多「操作到一半失敗」的案例，其實只是會話逾時退出了。

概念二：服務（SID）是動詞

常用服務一張表：

資料的「名詞」則是 DID（Data Identifier）：一顆量產 ECU 動輒數百個 DID，每個都有格式、長度、存取條件——這正是後面要談自動化的原因。

概念三：否定回應（NRC）是 ECU 的「不要」

請求被拒時，ECU 回 0x7F ＋ 原服務 ＋ NRC。幾個天天見面的 NRC：

• 0x33 securityAccessDenied——先過安全存取再來
• 0x22 conditionsNotCorrect——條件不對（車速不為零、電壓不對等）
• 0x13 incorrectMessageLengthOrInvalidFormat——長度或格式錯
• 0x78 requestCorrectlyReceived-ResponsePending——不是錯誤，是「收到了，讓我算一下」，測試端要延長等待而不是判失敗

把 0x78 誤判成失敗，是診斷測試腳本最經典的 bug。

安全存取：種子與金鑰

寫入與刷寫這類敏感操作，前置是 0x27 SecurityAccess 的挑戰—回應流程：

1. 測試端請求種子（Seed）
2. ECU 回一組隨機種子
3. 測試端用保密演算法算出**金鑰（Key）**送回
4. ECU 驗證通過，解鎖對應等級

演算法錯、等級對不上、嘗試次數超限被鎖定與延遲懲罰——這一段的邊界條件特別多，也特別值得自動化覆蓋。

為什麼一定要自動化

數百個 DID × 多個會話 × 安全等級 × 正反向案例，人工點診斷儀是跑不完的。成熟的做法是把診斷規格放進單一資料來源（CDD 檔，由 CANdelaStudio 維護），測試（CANoe.DiVa 可由 CDD 自動生成案例）、量產刷寫、售後診斷儀全部從同一份規格出發——規格改一次，四端同步，而不是四份文件各自漂移。

傳輸層方面，UDS 同時跑在 CAN（DoCAN）與乙太網（DoIP）上，刷寫大檔時 DoIP 的頻寬優勢明顯；再往前看，SOVD 正在把診斷介面帶向 HTTP／REST 的方向，但服務語意的骨架仍是 UDS——現在打好的基礎不會白費。

延伸閱讀：CANdelaStudio：診斷規格的單一真相來源、ODXStudio 與 ODX 標準

下一步

診斷這條鏈從規格、實作、測試到量產刷寫，最怕四端各看各的文件。歐特莫夫（Vector Informatik 合作夥伴）協助建立以 CDD 為核心的診斷開發與自動化驗證流程。

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