KopherBit
診斷通訊

ODX-D 驅動的 UDS 測試：從資料庫匯入到 ISO 14229-1 測試案例產生

介紹如何以 ODX-D 作為 UDS 測試的單一事實來源，從 PDX 匯入、ISO 14229 服務樹渲染、ENV-DATA-DESC 驅動的 DTC 快照解碼，到 ISO 14229-1 測試案例自動產生與 HTML 報告匯出，並對應到 KITE UDS Tester 的實際操作流程。

為什麼診斷測試需要 ODX

OEM 與 Tier-1 的診斷需求多半以 ODX (Open Diagnostic Data Exchange, ISO 22901-1) 形式交付。ODX 是 ASAM 標準中描述 ECU 診斷能力的 XML 資料模型，目的是讓「ECU 支援哪些 UDS 服務、哪些 DID、哪些 DTC、回應如何解碼」這件事可被機器讀取，避免再用文件 + Excel 維護一份「誰應該支援什麼」。對於診斷工具而言，ODX 就是測試案例與 HMI 的單一事實來源。

KITE UDS Tester 採用 ODX-D 作為輸入，由內建的 odx-parser crate 解析後，驅動 ISO 14229 服務樹、DID 編輯器、DTC 快照解碼，與 ISO 14229-1 風格的測試案例產生。

ODX 家族：ODX-D、ODX-F、ODX-V 與 PDX 容器

ODX 規範拆成多個子集合，每一份檔案聚焦於不同階段：

  • ODX-D (Diagnostic)：描述 ECU 的診斷能力 — DIAG-LAYER、DIAG-SERVICE、DOP (Data Object Property)、ENV-DATA-DESC、DTC-DOPS 等。這是診斷工具最常用的部份，KITE UDS Tester 直接吃這個。
  • ODX-F (Flash)：描述 flash session 的 segment / block / verify 流程，由 KITE Reflasher 端使用。
  • ODX-V (Vehicle)：車輛拓撲、ECU base variant 對應，用於跨 ECU 的 BUS 規劃。
  • ODX-C / ODX-CS / ODX-FD：通訊參數、共用資料庫等補充。

實務上 OEM 會將上述檔案打包成 PDX (Product Data eXchange)，本質是含 index.xml 的 ZIP。KITE UDS Tester 支援直接從 PDX 取出 .odx-d 載入，也支援未壓縮的單一 .odx-d 檔案。

ODX-D 中的關鍵元素

理解下列幾個元素，幾乎可以覆蓋大部分 UDS 測試需求：

  • DIAG-LAYER：描述某個 ECU variant 的診斷階層（base variant、ECU shared data、protocol layer）。
  • DIAG-SERVICE：對應一支 UDS service 與其 request / positive / negative 結構。
  • REQUEST / POS-RESPONSE / NEG-RESPONSE：請求與回應的位元層描述，內含 PARAM 與其 DOP 引用。
  • DOP：資料的物理表示與單位轉換規則（scaling, offset, unit, text-table 等）。
  • ENV-DATA-DESC / ENV-DATA：環境資料 (Snapshot / Freeze Frame) 的結構描述，是 DTC 快照解碼的核心。
  • COMPARAM-SPEC：通訊參數，例如 ISO-TP 的 STmin、BS、P2/P2*、addressing mode。

KITE UDS Tester 將上述模型映射成 React 樹狀結構，以 OdxTreePanel 呈現。

從 ODX 解析 ISO 14229 服務樹並渲染

odx-parser 走訪每一個 DIAG-LAYER 的 DIAG-SERVICE，抽出 SID 後依 ISO 14229 的服務分類分組 — Diagnostic & Communication Management（0x10、0x11、0x27、0x28、0x3E、0x83、0x84、0x85、0x86、0x87）、Data Transmission（0x22、0x23、0x24、0x2A、0x2C、0x2E、0x3D）、Stored Data Transmission（0x14、0x19）、Input Output Control（0x2F）、Routine（0x31）、Upload / Download（0x34、0x35、0x36、0x37、0x38）。

每個節點點擊後會載入該 service 的 REQUEST 結構，並依 PARAM 順序組成 hex 預覽。對 0x22 ReadDataByIdentifier 等 DID 服務，DID 列表本身就是樹的子節點，工程師只需挑一支 DID 就能直接送出。

ENV-DATA-DESC 如何驅動 DTC 快照解碼

0x19 ReadDTCInformation 的子功能 0x04 reportDTCSnapshotRecordByDTCNumber 與 0x06 reportDTCExtDataRecordByDTCNumber 回傳的是 raw bytes，沒有 ODX 解碼幾乎是無法閱讀的二進位區塊。這正是 ENV-DATA-DESC 介入的地方。

  • status mask：先以 0x01 / 0x02 取得 DTC 列表與其 status byte（每個 bit 對應 testFailed、confirmedDTC、warningIndicatorRequested 等）。
  • snapshot record：DTC 命中時 ECU 會儲存當下的環境訊號（轉速、電壓、溫度、車速等）。ENV-DATA-DESC 描述每筆 snapshot 的 PARAM 結構與其 DOP，KITE UDS Tester 依此把 raw bytes 拆成有名稱、有單位、有縮放後的物理值。
  • extended data：例如 occurrence counter、aging counter、aged counter 等，由 EXT-DATA-DESC 解碼。

少了 ENV-DATA-DESC，DTC 報告就只能呈現 hex；有了它，工程師才能直接看到「DTC P0606 觸發時 EngineSpeed = 4250 rpm、CoolantTemp = 105 °C」。

從 ODX-D 自動產生 ISO 14229-1 測試案例

KITE UDS Tester 的 generate_uds_tests 走訪解析後的 DIAG-LAYER 並產生 ISO 14229-1 風格的測試套件，覆蓋常見的合規面：

  • supportedDIDs scan：對每一個 ODX 中宣告的 DID 發 0x22，預期 positive response，比對長度與 DOP。
  • sessionTransition matrix：對每一組 (current session, target session) 發 0x10，驗證允許 / 拒絕的轉換是否符合 ODX STATE-CHART。
  • securityAccess seed/key：依 ODX 列出的 security level 取 seed、呼叫外部 DLL 算 key、送回後驗證 positive response。
  • routineControl 三步：對每一支 routine 發 start / stop / requestResults，驗證回應結構。
  • NRC handling：刻意在錯誤前置條件（無 session、無 security）下發送，驗證 ECU 是否回 0x33 securityAccessDenied、0x7F serviceNotSupportedInActiveSession 等預期 NRC。

每個測試案例攜帶一個 precondition_sequence —例如 [0x10 extendedSession → 0x27 level1 → 0x3E tester present] — 由 runner 在執行該案例前自動發送。這個概念來自 Vector CANoe.DiVa 的 UDSTestSeq.xml，KITE UDS Tester 採同樣的資料結構，方便既有 DiVa 流程的工程師直接接手。

測試結果、NRC 解碼與 HTML 報告

每個案例以 pending → running → passed / failed / skipped 的狀態機追蹤。failed 時會把該案例的最後一筆回應交給 NRC 解碼器，把 0x7F xx NRC 翻成可讀名稱（conditionsNotCorrect、requestSequenceError、subFunctionNotSupported 等）並寫入 trace。

執行完成後，tauriSaveHtmlReport 會打包：

  • 測試案例樹與每筆狀態
  • 完整的請求 / 回應 trace（含 timestamp、direction、hex）
  • NRC 解碼摘要
  • 環境資訊（ODX 版本、硬體配置、CAN ID）

成品為單一 .html 檔，內建 print-to-PDF 動作與 @media print 樣式，可直接歸檔或附在版本紀錄。

在 KITE UDS Tester 上的實際操作

完整流程：

  1. 載入 ODX：將 .odx-d 或 .pdx 拖入 OdxTreePanel。
  2. 設定硬體：在 HardwareConfigPanel 選擇 Vector / Kvaser / PCAN / ZLG，填入 channel 與 baud rate，啟用 autoTesterPresent。
  3. 互動探索：點選樹中的 service 節點，於 UdsServicePanel 組請求並送出。
  4. 產生測試：執行 generate_test_project 由 ODX 產生測試專案，於 UdsTestPanel 檢視。
  5. 執行：以 runCase / runGroup / runAll 跑測試，觀察 ResponseHistoryPanel。
  6. 匯出報告：呼叫 tauriSaveHtmlReport，得到自包含 HTML，需要紙本時直接 print-to-PDF。

整個過程不需要離開應用程式，也不需要切換到 CANoe / DiVa 等外部工具。

常見問題

為何不支援 CDD？ Vector CANdela Studio (CDD) 是另一套主流診斷描述格式，但其 schema 為私有；KITE UDS Tester 目前僅支援開放的 ODX 標準（ISO 22901-1）。如果手上只有 CDD，建議透過 CANdelaStudio 的 ODX 匯出功能轉成 ODX-D 後再載入。

多 ECU 測試怎麼做？ 本工具一次綁定一個診斷會話（一組 physical request / response CAN ID）。多 ECU 測試的建議做法是把每顆 ECU 的測試專案分別匯出，逐一執行並合併報告；自動化情境則由 CI 端依車輛拓撲依序呼叫。

回應歷史會持久化嗎？ 回應 log 為記憶體內，僅 HTML 報告為持久化路徑。若需要長時間錄製，請在每次執行結束後立即匯出。持久化會話儲存仍在 roadmap 評估中。

小結

ODX-D 把「ECU 該支援什麼」從 PDF 拉回到結構化資料，搭配 ENV-DATA-DESC 讓 DTC 快照可被解碼，再用 ISO 14229-1 模板自動產生測試案例與 HTML 報告 — 這就是 KITE UDS Tester 想要落地的工作流程。對診斷與驗證工程師而言，這意味著從供應商交付到合規簽核之間的人工搬運可以大幅降低。

返回技術知識庫