KopherBit
診断通信

ODX-D 駆動の UDS テスト：データベース取り込みから ISO 14229-1 テストケース生成まで

ODX-D を UDS テストの単一ソースとして活用する手順を解説。PDX 取り込み、ISO 14229 サービスツリー描画、ENV-DATA-DESC による DTC スナップショット デコード、そして KITE UDS Tester での ISO 14229-1 テストケース自動生成までを取り上げます。

なぜ診断テストには ODX が必要なのか

OEM や Tier-1 サプライヤからの診断成果物は、多くの場合 ODX (Open Diagnostic Data Exchange, ISO 22901-1) として納品されます。ODX は ECU の診断能力を記述する ASAM の XML データ モデルであり、「ECU はどの UDS サービス、どの DID、どの DTC をサポートし、レスポンスをどうデコードするか」を機械可読な形にすることを目的としています。これにより、PDF と 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 サービスとその request / positive / negative response 構造に対応します。
  • REQUEST / POS-RESPONSE / NEG-RESPONSE：リクエストとレスポンスのビット レベル記述で、DOP を参照する PARAM を含みます。
  • 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）。

各ノードをクリックすると、そのサービスの 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 一覧と DTC 毎の status byte を取得します（各ビットが 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) も主流の診断記述フォーマットですが、スキーマがプロプライエタリです。KITE UDS Tester はオープンな ODX 標準（ISO 22901-1）のみをサポートします。手元に CDD しかない場合は、CANdelaStudio の ODX エクスポート機能で ODX-D に変換してから読み込んでください。

マルチ ECU テストはどう行いますか？ 本ツールは一度に 1 つの診断セッション（1 組の physical request / response CAN ID）をバインドします。マルチ ECU テストの推奨パターンは、ECU 毎にテスト プロジェクトをエクスポートし、順次実行してレポートを統合することです。自動化シナリオでは、車両トポロジに従って CI から順序を駆動します。

レスポンス履歴は永続化されますか？ レスポンス ログはインメモリで、HTML レポートのみが永続化パスです。長時間の記録が必要な場合は、各実行直後にエクスポートしてください。永続的なセッション ストレージはまだロードマップ評価中です。

まとめ

ODX-D は「ECU が何をサポートすべきか」を PDF から構造化データへ引き戻し、ENV-DATA-DESC によって DTC スナップショットがデコード可能になり、ISO 14229-1 テンプレートでテストケースと HTML レポートを自動生成できる — これが KITE UDS Tester が定着させたいワークフローです。診断と検証のエンジニアにとっては、サプライヤ納品からコンプライアンス サインオフまでの手作業の引き渡しが大幅に減ることを意味します。

技術ナレッジへ戻る