OEM 用 Word 發診斷規格、Tier 1 逐條人工實作，對不齊幾乎是必然。本文從實際痛點出發，拆解 CANdelaStudio 如何用 CDD 把 UDS（ISO 14229）診斷規格變成可驗證、可自動生成測試與程式碼的單一來源，並輸出 ODX（ASAM MCD-2 D）、AUTOSAR DEXT、A2L，附診斷開發鏈架構圖與格式對照表。
診斷規格以 Word 與 Excel 流轉時，設計、實作、測試與產線各持一份，版本一多就對不齊——整合測試時才發現規格與實作不一致，是診斷開發最常見的返工原因。CANdelaStudio 以 CDD 作為診斷規格的單一真相來源：規格在同一份資料裡定義、演進，下游的測試與刷寫全部由它導出。
診斷規格為什麼總對不齊：把它當文件，而不是資料
追根究柢，痛點的源頭其實只有一個：當診斷規格以 Word 或 PDF 的形式存在，它就只是一份「給人看的文件」，而不是一份「給工具用的資料」。這個看似無害的差別，會一路衍生出四種後果：
- 無法自動比對：規格與實作到底一不一致，只能靠人逐條核對——而人，一定會有看漏的時候。
- 無法自動生成：測試腳本、ECU 程式碼、診斷儀資料庫，全都得有人重新讀一次規格、再手動做一次。
- 版本一亂就各說各話：規格改了一版，下游的測試、燒錄、售後各自更新的時機不同步，資料立刻開始漂移。
- 知識鎖在個人腦裡：舊專案的建模決策沒有被結構化保存，資深工程師一離職，經驗就跟著離開。
換句話說，只要規格還停留在「文件」的層次，這些問題就無法從根本解決。真正的解法，是讓規格升級成「資料」。
CANdelaStudio 怎麼解：用 CDD 建立單一真相來源
CANdelaStudio 是 Vector 用來建立與編輯正規化 ECU 診斷規格的工具。它的核心，是把厚重的紙本規格轉化成一份機器可讀的資料庫——CDD（CANdela Diagnostic Description）。
CDD 之於診斷，就像 DBC 之於 CAN 訊號：它是整個診斷世界的單一真相來源（Single Source of Truth）。
如上圖，CDD 一次建模、多格式輸出，往下游餵給整條開發鏈。這正是它的價值所在：只要規格在源頭做對了，下游的 ODX、測試、燒錄才有可能對得起來。
CDD 一次建模，多格式輸出（ODX／DEXT／A2L）
同一份 CDD，可以依照不同下游的需求，輸出成不同格式：
| 輸出格式 | 給誰用 | 用途 |
|---|---|---|
| ODX（匯出 2.2／2.1／2.0.1；匯入 2.2／2.0.1） | 跨工具、跨供應商 | 國際標準（ISO 22901-1）的診斷資料交換 |
| AUTOSAR DEXT | 基礎軟體團隊 | 匯入 DaVinci Configurator 自動配置 Dcm／Dem |
| A2L／CDI | 量測標定、應用工具 | 與 CANape、Indigo 等對接 |
| 規格文件（RTF／PDF） | 供應商、稽核 | 從同一份資料產出給人看的規格書 |
關鍵在於「同一份來源」——不是四份各自維護的文件，而是一個源頭生成四種輸出。規格只要改一處，全鏈路重新生成，資料不再各自漂移。
CDD 與 ODX 差在哪：一個建模、一個交換
很多人第一次接觸會困惑：既然有國際標準 ODX，為什麼還要 CDD？其實兩者分工明確，並不衝突：
| 面向 | CDD（CANdelaStudio 原生格式） | ODX（ISO 22901-1 國際標準） |
|---|---|---|
| 性質 | Vector 格式、業界事實標準 | 開放的國際標準 |
| 最強的地方 | 建模、編輯、範本繼承最完整 | 跨工具、跨供應商交換 |
| 典型用途 | 從零建立與長期維護診斷規格 | 把規格交付給不同廠商與工具鏈 |
| 一句話定位 | 用來建模 | 用來交換 |
從零建立、長期維護診斷規格 → 用 CDD（CANdelaStudio）；要跨工具、跨供應商交換 → 用 ODX。一句話：用 CDD 建模、用 ODX 交換。
用診斷範本（.cddt）把一致性變成強制規則
CANdelaStudio 的診斷範本（.cddt），讓 OEM 可以把「所有 ECU 都必須遵守的規則」定義成一套模板——例如強制每顆 ECU 都要支援讀取 VIN 的服務、每個變體（Variant）都繼承同一套基礎診斷行為。
這一步的意義，是把「一致性」從「靠工程師自律」變成「由工具強制」。也唯有如此，整車平台上幾十顆 ECU 的診斷行為，才有辦法真正統一起來。
AI 強化搜尋：讓「考古」不再只能問資深工程師
還記得前面那個「打開舊 CDD 卻找不到東西」的痛點嗎？CANdelaStudio 25 的 AI Feature 正是為它而生。它透過 MCP Server，把 CANdelaStudio 的說明文件與 CDD 檔案接給相容的 AI 客戶端（例如 VS Code 裡的 GitHub Copilot）：
- Smart Help：直接用問的，就能得到操作與流程的答案（「怎麼建立屬性」「如何匯出某個 Variant」），不必再一頁頁翻手冊。
- Smart Suggestions：依據專案既有的 CDD 風格，有脈絡地建議該如何建立新的診斷資料——不是憑空亂猜，而是照著你這個專案的慣例走。
還有一個對企業特別重要的設計：MCP Server 對 CDD 是唯讀的，而且可以獨立於圖形介面運行。 也就是說，AI 只負責分析與輔助，不會直接改動診斷資料——資料安全與流程可控性，因此得以完整保留。
常見問題釐清
CANdelaStudio 是什麼？
CANdelaStudio 是 Vector 用來建立與編輯正規化 ECU 診斷規格的工具。它產出的原生格式是 CDD（CANdela Diagnostic Description），扮演診斷世界的單一真相來源，往下可輸出 ODX、AUTOSAR DEXT、A2L 等格式。
CDD 和 ODX 到底差在哪？
一句話：用 CDD 建模、用 ODX 交換。CDD 是 CANdelaStudio 的原生格式（Vector 格式、事實標準），建模體驗與範本機制最完整；ODX 則是國際標準（ISO 22901-1），專門用於跨工具、跨供應商的資料交換。上方對照表有完整比較。
CANdelaStudio 涵蓋哪些診斷協定？
應用層支援 UDS（ISO 14229）、OBD 與 KWP2000；傳輸層支援 CAN／CAN FD、DoIP、K-Line 與 FlexRay，並朝服務導向診斷（SOVD）延伸。也就是說，既有的 CDD 資產可以延伸到服務化架構，不必為了新架構整套重建。
規格和程式碼，要怎麼保持一致？
CDD 匯入 DaVinci Configurator 後，可自動配置 AUTOSAR 的 Dcm，也能編輯 Dem／FIM 的內容——讓診斷規格與基礎軟體設定同源。這一段正是實作端最容易誤解、也最該交給工具自動化的環節。
Session、SecurityAccess 這類狀態機也能描述嗎？
可以。服務之間的依賴關係、Session 與安全存取的轉換條件，都能明確定義並以狀態機呈現。把這些規則放進 CDD，就等於少了一個「實作端各自解讀」的對不齊來源。
下一步
把診斷規格，變成整條開發鏈的單一真相來源
從規格、實作、測試到售後，診斷這條鏈最怕的就是四端各看各的文件。歐特莫夫（Vector Informatik 合作夥伴）以 CANdelaStudio 為核心，協助你把診斷規格建成可驗證、可自動生成、可延伸到 SOVD 的單一來源，並在導入時把 AI 強化搜尋一起規劃進團隊的工作流。