UDS 功能設計與驗證技術解決方案
提供基於 UDS 診斷功能設計與驗證全方位解決方案。透過 CDD 核心資料驅動，實現從規格定義、自動化測試到實車驗證的無縫整合，確保符合 ISO 14229 標準並大幅縮短開發週期。
CANdelaStudio：診斷 CDD 找不到屬性？AI 用問的直接給答案
歐特莫夫獨立製作影片；Vector 與 CANoe、CANalyzer、CANape 等為 Vector Informatik GmbH 之商標。
ODX 是什麼？三種診斷格式兜不起來？一份國際標準檔全打通
歐特莫夫獨立製作影片；Vector 與 CANoe、CANalyzer、CANape 等為 Vector Informatik GmbH 之商標。
01 我們的技術方法
- 診斷需求定義與資料庫建立
- 運用 CANdelaStudio AI 強化搜尋（Smart Help／Smart Suggestions）快速查找診斷服務與屬性、加速診斷資料建立
- 診斷協定一致性測試
- Bootloader 與刷寫測試
- 自動化回歸測試
02 使用的核心工具
我們利用業界標準的 Vector 工具來執行此解決方案：
診斷需求規格定義工具。產出 CDD 檔案作為單一資料源，確保後續開發流程一致性。
開放式診斷資料交換格式編輯平台。處理符合國際標準的 ODX 資料，促進供應鏈資料交換。
自動化驗證工具。自動生成測試案例，模擬邊界條件與通訊場景，檢測軟體缺陷。
ECU 程式刷寫工具。支援多種介面與規範，確保韌體寫入的正確性與效率。
直觀的車輛診斷儀。無需深入了解協定即可快速讀取車輛狀態與檢視故障碼。
符合 AUTOSAR 標準的診斷模組。導入診斷參數，自動生成嵌入式程式碼。
03 技術難點
什麼是 UDS 診斷流程？
UDS 統一診斷服務是現代車輛電子控制單元 (ECU) 與外部診斷設備溝通的通用語言，亦即 ISO 14229 標準。而在歐特莫夫的解決方案中，「CDD」指的是 CANdela Diagnostic Description，它不僅是一個檔案格式，更是整個開發流程的大腦。 這套流程改變了傳統依賴 Word 或 Excel 管理診斷表的模式，將所有診斷參數、服務與時序要求資料化。透過以 CDD 為核心的開發模式，我們能讓設計端、實作端與測試端使用同一份資料語言，徹底解決了跨部門溝通時資訊不同步的痛點，特別適用於電動車 (EV) 與自駕車等電子架構複雜的領域。
核心功能與技術優勢
需求定義 (Specify)
使用 CANdelaStudio 進行可視化編輯，精確定義診斷服務、DTC 與資料流，建立單一且標準化的診斷資料源（Single Source of Truth）。
測試 (Test)
利用 CANoe.DiVa 讀取 CDD 規格，自動產生包含邊界條件與錯誤注入的測試腳本，實現高覆蓋率的自動化回歸測試。
驗證 (Validate)
結合 Indigo 診斷儀與實車環境，進行最終的功能確認與系統整合驗證，確保在真實車輛網路中的通訊品質與診斷正確性。
軟體升級 (Software Upgrade)
針對 ECU 韌體更新需求，提供完整的 Bootloader 驗證方案與 vFlash 高速刷寫工具，確保 OTA 與售後更新的可靠度。
診斷實現 (Implement)
基於 AUTOSAR 架構，將 CDD 檔案導入 MICROSAR DIAG 診斷模組，自動生成符合規範的嵌入式程式碼，大幅縮短開發工時。
往前看一步：UDS 之外的 SOVD
本圖比較 UDS 與 SOVD 的溝通方式、定位對象、前置條件與適用場景，並說明既有的 CDD 資產如何延伸到服務導向架構。
當電子架構出現高效能運算平台、功能被做成服務、或需要遠端與雲端診斷時，以單顆 ECU 為單位的請求／回應模式會愈做愈吃力。**SOVD（Service Oriented Vehicle Diagnostics，服務導向車輛診斷）**就是為此而生——它把診斷能力以服務的形式提供，定位對象從「某顆 ECU」變成「某個功能或實體」，被診斷端也具備自我描述能力，降低了對預先載入診斷資料庫的依賴。 重點是：**SOVD 不是要取代 UDS**。車上會長期同時存在傳統 ECU 與高效能平台，兩種診斷方式並存才是現實。歐特莫夫的角色，是協助您判斷什麼時候該開始，以及怎麼讓既有的診斷資產延伸過去、而不是重做一次。
既有的 CDD 資產是基礎，不是包袱
過去在 CANdelaStudio 累積的診斷規格不必推翻重做。CANdelaStudio 可匯出 SOVD API 相關資料，並支援 SOVD 樣板的編輯，讓同一份診斷定義同時服務兩種架構。
兩邊的對應關係要能被檢查
SOVD 與 UDS 之間的轉換最容易在細節上出錯。ODXStudio 提供對應的檢查規則，可在交付前找出對不上的地方，而不是等到整合測試才發現。
延伸到 SDV 的車端取數
服務化之後，診斷與量測的邊界會變模糊。車端的資料收集可透過 XCP、SOME/IP 與 SOVD 等方式取數，讓同一套資料同時服務診斷、量測與雲端分析。
什麼時候該開始評估
若您的下一代架構已規劃高效能運算平台、服務導向通訊或遠端診斷，就值得開始評估。反之，以傳統 ECU 為主的專案，UDS 仍是最直接有效的做法——歐特莫夫會據實建議，不會為了新技術而推新技術。
歐特莫夫的技術服務流程
我們將 UDS 功能設計與驗證劃分為四個精密的執行階段，協助客戶從零開始構建高品質的診斷系統：
架構定義與規格數位化
我們協助客戶分析 OEM 的診斷需求表 (Diagnostic Specification)，並將其轉化為機器可讀的 CDD 或 ODX 資料庫。在此階段，我們會定義好故障碼 (DTC)、資料流 (Data Identifier) 以及安全存取 (Security Access) 的具體參數，為後續開發打下標準化基礎。
自動化程式碼生成與整合
利用已定義的資料庫，我們協助導入自動化程式碼生成技術。透過工具鏈將診斷邏輯直接轉換為符合 AUTOSAR 標準的程式碼模組，並整合至 ECU 的基礎軟體中。這不僅加快了實作速度，更確保了程式碼邏輯嚴格遵循設計規範。
基於變更的智慧驗證
在驗證階段，我們採用優化的回歸測試策略。利用 CANdelaStudio 的版本比對功能識別診斷規範（CDD）的變更，並在 CANoe.DiVa 中針對受影響的功能配置特定的測試範圍（或：進行針對性的測試生成）。這對於開發週期緊湊的專案至關重要，能有效聚焦測試重點，大幅節省不必要的回歸測試時間
實車驗證與售後支援
開發完成後，我們利用 Indigo 與 vFlash 進行實車環境下的診斷功能確認與軟體刷寫測試，確保 ECU 在真實車輛網路中的表現穩定。此外，我們能協助產出用於售後維修的診斷資料包，確保售後服務端的診斷儀能正確解讀車輛資訊。