KopherBit
Diagnostics

ODX-D Driven UDS Testing: From Database Import to ISO 14229-1 Test Case Generation

A walkthrough of using ODX-D as the single source of truth for UDS testing — PDX import, ISO 14229 service tree rendering, ENV-DATA-DESC driven DTC snapshot decoding, and ISO 14229-1 test case generation in KITE UDS Tester.

Why diagnostic testing needs ODX

Diagnostic deliverables from OEMs and Tier-1 suppliers are most often packaged as ODX (Open Diagnostic Data Exchange, ISO 22901-1). ODX is the ASAM XML data model that describes the diagnostic capability of an ECU, so that “which UDS services, which DIDs, which DTCs, and how to decode the responses” becomes machine-readable — instead of a PDF plus an Excel sheet that engineering and validation try to keep in sync. For a diagnostic tool, ODX is the single source of truth for both the test cases and the HMI.

KITE UDS Tester takes ODX-D as input. The in-tree odx-parser crate parses it and drives the ISO 14229 service tree, the DID editor, DTC snapshot decoding, and ISO 14229-1 style test case generation.

The ODX family: ODX-D, ODX-F, ODX-V, and the PDX container

The ODX specification is split into several subsets, each focused on a different stage:

  • ODX-D (Diagnostic): describes the diagnostic capability of an ECU — DIAG-LAYER, DIAG-SERVICE, DOP (Data Object Property), ENV-DATA-DESC, DTC-DOPS, etc. This is the part diagnostic tools rely on most, and the part KITE UDS Tester ingests directly.
  • ODX-F (Flash): describes the segments / blocks / verification flow of a flash session, used by KITE Reflasher.
  • ODX-V (Vehicle): vehicle topology, ECU base variant mapping, used for cross-ECU bus planning.
  • ODX-C / ODX-CS / ODX-FD: communication parameters, shared databases, and other supplements.

In practice OEMs ship the above bundled inside a PDX (Product Data eXchange) container — a ZIP with an index.xml. KITE UDS Tester can load the .odx-d directly out of a PDX, and also accepts a standalone .odx-d file.

Key elements of ODX-D

Understanding the following elements covers most UDS testing needs:

  • DIAG-LAYER: describes the diagnostic hierarchy of an ECU variant (base variant, ECU shared data, protocol layer).
  • DIAG-SERVICE: maps to a UDS service and its request / positive / negative response structure.
  • REQUEST / POS-RESPONSE / NEG-RESPONSE: bit-level descriptions of requests and responses, with PARAM entries that reference DOPs.
  • DOP: physical representation and unit conversion rules (scaling, offset, unit, text-table, etc.).
  • ENV-DATA-DESC / ENV-DATA: structural description of environment data (snapshot / freeze frame), the core of DTC snapshot decoding.
  • COMPARAM-SPEC: communication parameters such as ISO-TP STmin, BS, P2/P2*, addressing mode.

KITE UDS Tester maps the model above into a React tree structure rendered by OdxTreePanel.

Parsing the ISO 14229 service tree from ODX

odx-parser walks every DIAG-SERVICE of every DIAG-LAYER, extracts the SID, and groups it by ISO 14229 service category — 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), and Upload / Download (0x34, 0x35, 0x36, 0x37, 0x38).

Clicking a node loads that service’s REQUEST structure and assembles a hex preview from the PARAM order. For DID services such as 0x22 ReadDataByIdentifier, the DID list itself becomes children of the tree, so an engineer simply picks a DID and sends.

How ENV-DATA-DESC drives DTC snapshot decoding

The 0x19 ReadDTCInformation subfunctions 0x04 reportDTCSnapshotRecordByDTCNumber and 0x06 reportDTCExtDataRecordByDTCNumber return raw bytes — practically unreadable without ODX decoding. This is where ENV-DATA-DESC earns its keep.

  • status mask: use 0x01 / 0x02 first to get the DTC list and per-DTC status byte (each bit represents testFailed, confirmedDTC, warningIndicatorRequested, etc.).
  • snapshot record: when a DTC is set, the ECU stores the environmental signals at that moment (engine speed, voltage, temperature, vehicle speed). ENV-DATA-DESC describes the PARAM structure and DOP of each snapshot record; KITE UDS Tester uses it to break the raw bytes into named, scaled, unit-bearing physical values.
  • extended data: occurrence counter, aging counter, aged counter, etc., decoded by EXT-DATA-DESC.

Without ENV-DATA-DESC the DTC report is hex; with it, an engineer reads “DTC P0606 latched at EngineSpeed = 4250 rpm, CoolantTemp = 105 °C”.

Generating ISO 14229-1 test cases from ODX-D

KITE UDS Tester’s generate_uds_tests walks the parsed DIAG-LAYER and emits an ISO 14229-1 style test suite covering common compliance angles:

  • supportedDIDs scan: send 0x22 for every DID declared in ODX, expect a positive response, compare length against the DOP.
  • sessionTransition matrix: send 0x10 for every (current session, target session) pair and verify allowed / denied transitions against the ODX STATE-CHART.
  • securityAccess seed/key: for every security level declared in ODX, request the seed, call the external DLL to compute the key, send it back, and verify the positive response.
  • routineControl three-step: for every routine, send start / stop / requestResults and verify response shape.
  • NRC handling: deliberately send under wrong preconditions (no session, no security) and verify the ECU returns the expected NRC such as 0x33 securityAccessDenied or 0x7F serviceNotSupportedInActiveSession.

Each test case carries a precondition_sequence — for example [0x10 extendedSession → 0x27 level1 → 0x3E tester present] — that the runner sends automatically before executing the case. The concept comes from Vector CANoe.DiVa’s UDSTestSeq.xml; KITE UDS Tester uses the same data structure so engineers familiar with the DiVa workflow can pick it up directly.

Test results, NRC decoding, and HTML reports

Each case is tracked through a pending → running → passed / failed / skipped state machine. On failed, the last response is handed to the NRC decoder, which translates 0x7F xx NRC into a readable name (conditionsNotCorrect, requestSequenceError, subFunctionNotSupported, etc.) and writes it into the trace.

After the run, tauriSaveHtmlReport bundles:

  • the test case tree with per-case status
  • the full request / response trace (timestamp, direction, hex)
  • the NRC decode summary
  • environment metadata (ODX version, hardware config, CAN IDs)

The result is a single self-contained .html file with an inline print-to-PDF action and @media print styles, ready for archival or attachment to a release record.

Doing it in KITE UDS Tester

End-to-end:

  1. Load the ODX: drop .odx-d or .pdx into OdxTreePanel.
  2. Configure hardware: pick Vector / Kvaser / PCAN / ZLG in HardwareConfigPanel, set channel and baud rate, enable autoTesterPresent.
  3. Explore interactively: pick a service node from the tree, build the request in UdsServicePanel, send.
  4. Generate tests: call generate_test_project to derive a test project from the ODX, inspect it in UdsTestPanel.
  5. Run: use runCase / runGroup / runAll, watch ResponseHistoryPanel.
  6. Export: call tauriSaveHtmlReport, get a self-contained HTML, print-to-PDF when you need a hard copy.

The whole flow stays inside the app — no jumping out to CANoe / DiVa.

FAQ

Why no CDD support? Vector CANdela Studio (CDD) is another mainstream diagnostic description format, but its schema is proprietary; KITE UDS Tester only supports the open ODX standard (ISO 22901-1). If you only have a CDD, use CANdelaStudio’s ODX export to convert to ODX-D first.

How do I do multi-ECU testing? The tool binds one diagnostic session (one pair of physical request / response CAN IDs) at a time. The recommended pattern for multi-ECU testing is to export a test project per ECU, run each in sequence, and merge the reports; for automated runs, drive the sequence from CI according to the vehicle topology.

Is the response history persisted? The response log is in-memory; only the HTML report is the persistence path. For long recording sessions, export immediately after each run. Persistent session storage is still on the roadmap.

Summary

ODX-D pulls “what an ECU should support” out of PDFs and into structured data; ENV-DATA-DESC makes DTC snapshots decodable; and ISO 14229-1 templates let you generate test cases and HTML reports automatically — that is the workflow KITE UDS Tester aims to land. For diagnostics and validation engineers, it means the manual hand-off between supplier delivery and compliance sign-off shrinks dramatically.

Back to Knowledge Base