UDS 功能設計與驗證技術解決方案
一顆 ECU 的 UDS 診斷服務動輒數百個，規格卻常散在 Word 與 Excel 裡——設計、實作、測試、產線各拿一份，改一次就對不齊。歐特莫夫（Vector Informatik 合作夥伴）的做法，是把診斷規格收斂成一份以 CDD 為核心的「單一真相來源」，讓規格定義、自動化測試、實車驗證到產線刷寫全部從同一份資料出發、符合 ISO 14229，並能一路延伸到服務導向的 SOVD。
以 CDD 為核心的 UDS 診斷工具鏈
這條鏈要解決的核心問題，是「規格與實作對不齊」。只要源頭用 CDD 建成單一真相來源，下游的標準化、測試、實車驗證與刷寫，就都從同一份資料長出來——改一次、全鏈同步。
用 CDD 建立診斷規格的單一真相來源——服務、DTC、資料識別碼一次定義，設計端與實作端共用同一份資料，不再靠 Word／Excel 各自維護。
把 CDD 標準化成國際標準 ODX／PDX，供跨工具、跨供應商交換；同一份定義也能延伸成 SOVD 的資料來源。
讀取診斷描述自動生成 UDS 測試案例（含邊界條件與錯誤回應），在 CANoe 執行，達到高覆蓋率的自動化回歸測試；規格改版就重新生成，不必人工逐條追。
直覺的車輛診斷儀，用 ODX／CDD 自動配置，在實車環境做最終的功能確認與系統整合驗證。
一套介面涵蓋 CAN 到 DoIP 的 ECU 刷寫，驗證 Bootloader 與 OTA／售後更新的可靠度。
MICROSAR
把 CDD 導入 AUTOSAR 診斷模組（Dcm／Dem），自動生成符合規範的嵌入式程式碼，讓同一份規格直接落地成 ECU 程式。
- 規格改一次，測試、實作與售後全鏈同步，不再各自漂移
- 回歸測試只跑「受影響的功能」，把時間花在刀口上
- 覆蓋率由工具保證，診斷軟體品質可追溯、可交付
- 既有 CDD 資產可延伸到 SOVD，不必為新架構重做一次
為什麼這樣架：技術判斷與往前一步
什麼是 UDS 診斷流程？CDD 又扮演什麼角色？
UDS 統一診斷服務是現代車輛電子控制單元 (ECU) 與外部診斷設備溝通的通用語言，亦即 ISO 14229 標準。而在歐特莫夫的解決方案中，「CDD」指的是 CANdela Diagnostic Description，它不僅是一個檔案格式，更是整個開發流程的大腦。 這套流程改變了傳統依賴 Word 或 Excel 管理診斷表的模式，將所有診斷參數、服務與時序要求資料化。透過以 CDD 為核心的開發模式，我們能讓設計端、實作端與測試端使用同一份資料語言，徹底解決了跨部門溝通時資訊不同步的痛點，特別適用於電動車 (EV) 與自駕車等電子架構複雜的領域。
往前一步：從 UDS 到 SOVD（服務導向診斷）
🔍 點圖可放大看清楚
本圖比較 UDS 與 SOVD 的溝通方式、定位對象、前置條件與適用場景，並說明既有的 CDD 資產如何延伸到服務導向架構。
當電子架構出現高效能運算平台、功能被做成服務、或需要遠端與雲端診斷時，以單顆 ECU 為單位的請求／回應模式會愈做愈吃力。SOVD（Service Oriented Vehicle Diagnostics，服務導向車輛診斷）就是為此而生——它把診斷能力以服務的形式提供，定位對象從「某顆 ECU」變成「某個功能或實體」，被診斷端也具備自我描述能力，降低了對預先載入診斷資料庫的依賴。 重點是：SOVD 不是要取代 UDS。車上會長期同時存在傳統 ECU 與高效能平台，兩種診斷方式並存才是現實。歐特莫夫的角色，是協助您判斷什麼時候該開始，以及怎麼讓既有的診斷資產延伸過去、而不是重做一次。
既有的 CDD 資產是基礎，不是包袱
過去在 CANdelaStudio 累積的診斷規格不必推翻重做。CANdelaStudio 可匯出 SOVD API 相關資料，並支援 SOVD 樣板的編輯，讓同一份診斷定義同時服務兩種架構。
兩邊的對應關係要能被檢查
SOVD 與 UDS 之間的轉換最容易在細節上出錯。ODX Studio 提供對應的檢查規則，可在交付前找出對不上的地方，而不是等到整合測試才發現。
延伸到 SDV 的車端取數
服務化之後，診斷與量測的邊界會變模糊。車端的資料收集可透過 XCP、SOME/IP 與 SOVD 等方式取數，讓同一套資料同時服務診斷、量測與雲端分析。
什麼時候該開始評估
若您的下一代架構已規劃高效能運算平台、服務導向通訊或遠端診斷，就值得開始評估。反之，以傳統 ECU 為主的專案，UDS 仍是最直接有效的做法——歐特莫夫會據實建議，不會為了新技術而推新技術。
歐特莫夫怎麼協助你導入 UDS 診斷
我們把 UDS 功能設計與驗證劃分成四個階段，從零開始協助你建起以 CDD 為核心的診斷系統：
架構定義與規格數位化
我們協助客戶分析 OEM 的診斷需求表 (Diagnostic Specification)，並將其轉化為機器可讀的 CDD 或 ODX 資料庫。在此階段，我們會定義好故障碼 (DTC)、資料流 (Data Identifier) 以及安全存取 (Security Access) 的具體參數，為後續開發打下標準化基礎。
自動化程式碼生成與整合
利用已定義的資料庫，我們協助導入自動化程式碼生成技術。透過工具鏈將診斷邏輯直接轉換為符合 AUTOSAR 標準的程式碼模組，並整合至 ECU 的基礎軟體中。這不僅加快了實作速度，更確保了程式碼邏輯嚴格遵循設計規範。
基於變更的智慧驗證
在驗證階段，我們採用優化的回歸測試策略：用 CANdelaStudio 的版本比對功能識別診斷規範（CDD）的變更，並在 CANoe.DiVa 中針對受影響的功能做針對性的測試生成。這對開發週期緊湊的專案至關重要，能有效聚焦測試重點，大幅節省不必要的回歸測試時間。
實車驗證與售後支援
開發完成後，我們用 Indigo 與 vFlash 進行實車環境下的診斷功能確認與軟體刷寫測試，確保 ECU 在真實車輛網路中的表現穩定；並協助產出售後維修用的診斷資料包，讓售後端的診斷儀能正確解讀車輛資訊。
常見問題
UDS 和 SOVD 差在哪？要現在就換嗎？
UDS（ISO 14229）是以單顆 ECU 為單位的請求／回應診斷；SOVD 則把診斷以服務形式提供、以功能或實體為單位，適合高效能運算平台與遠端／雲端診斷。SOVD 不是取代 UDS——兩者會長期並存。以傳統 ECU 為主的專案，UDS 仍最直接；若下一代架構已規劃高效能平台或服務化，就值得開始評估。
一定要用 CDD 嗎？現有的 Word／Excel 規格怎麼辦？
不一定，但強烈建議。把規格收斂成 CDD（單一真相來源）後，測試、實作與售後才能從同一份資料出發、改一次全鏈同步。現有的 Word／Excel 規格可由歐特莫夫協助數位化成 CDD，不必從零重來。
導入這套流程大概要多久？
依 ECU 數量、診斷規格複雜度與現有資產狀況而定。歐特莫夫通常先做一次現況盤點，再分「規格數位化 → 自動化測試 → 實車驗證」階段導入，讓你在每個階段都有可驗收的成果，而不是一次到位。
這套方案支援哪些傳輸層與協定？
應用層以 UDS（ISO 14229）為主，並涵蓋 OBD 等；傳輸層支援 CAN／CAN FD、DoIP、K-Line 等，並可延伸到服務導向的 SOVD。實際範圍會依你的專案與 ECU 配置確認。