What is ODX? The ISO 22901 diagnostic data layer, and PDX

ODX stands for Open Diagnostic data eXchange. It is an XML-based data model for describing everything a tester needs to know to diagnose an electronic control unit (ECU): the available diagnostic services, the structure of their requests and responses, diagnostic trouble codes (DTCs), data and identification parameters, variant-coding data, and the communication parameters that configure the link to the ECU.

ODX is standardised twice over, which is why you see two names for the same thing. It is published by ASAM as ASAM MCD-2 D, and by ISO as ISO 22901-1, first released in 2008. The widely deployed format version is ODX 2.2. Both names refer to the same specification, so 'ODX', 'ISO 22901' and 'ASAM MCD-2 D' are effectively interchangeable in conversation.

Before ODX, an ECU's diagnostic definition lived in proprietary databases, spreadsheets and vendor-specific tool formats. The same fault definitions and service descriptions had to be re-authored for every tester, every production line and every workshop tool. That is slow, error-prone, and locks an organisation into one toolchain.

The explicit purpose of ISO 22901-1 is to make diagnostic data independent of the testing hardware and the protocol software of any particular test-equipment supplier. Author the description once, in a standard form, and any compliant runtime, from the development bench to the after-sales scan tool, can read it and talk to the ECU correctly. That single source of truth is also how an OEM and an ECU supplier, or two OEMs in a joint programme, exchange diagnostic definitions without translation.

This is the distinction that matters most, and the one most often blurred. UDS (Unified Diagnostic Services, ISO 14229) is the on-the-wire protocol: the client-server request and response bytes a tester and ECU actually exchange, such as ReadDataByIdentifier (0x22) or ReadDTCInformation (0x19). UDS defines the grammar of the conversation.

ODX is the formal description of what to send and how to interpret what comes back. UDS tells you that 0x22 followed by a two-byte identifier returns some bytes; ODX tells you which identifier means 'battery voltage', that the response is a 16-bit value, the scaling and unit to apply, and the human-readable label. Put plainly: UDS is the language, ODX is the dictionary and phrasebook for a specific ECU. A tester needs both.

ODX is organised to avoid repeating data. Diagnostic descriptions are arranged as diagnostic layers in a hierarchy, typically Protocol, Functional Group, Base Variant and ECU Variant, with shared-data layers acting as libraries. Lower, more specific layers inherit from higher, more general ones via references (PARENT-REF), and can selectively exclude what does not apply. Define a service once on the base variant and every ECU variant inherits it.

Communication parameters live in their own category, COMPARAM, which configures the protocol stack and timing behaviour for the link, kept separate from the service definitions themselves. ODX content is split across files by category, for example a DIAG-LAYER-CONTAINER for the diagnostic description and a COMPARAM-SPEC for the comms parameters.

PDX (Packaged ODX) is the delivery format. It is a single ZIP-based container that bundles all the related ODX XML files and their referenced data into one versioned, portable package, so the complete description of an ECU or a vehicle moves around as one artefact rather than a loose pile of files.

The hard part of ODX is not the format, it is the lifecycle. The ODX description has to track the ECU it describes across development, calibration, production and years of after-sales service. Every time firmware changes a DTC, adds a data identifier, alters scaling or renumbers a service, the description must change with it, or it drifts out of truth.

Drift is silent and expensive. When the description and the ECU disagree, every downstream tool that trusts the ODX, from the end-of-line tester to the workshop diagnostic, reads the wrong values, misses faults or fails to communicate at all. Authoring ODX correctly, validating it against the standard, and keeping it consistent across hundreds of variants and revisions is precisely the discipline that off-board diagnostics authoring environments such as Diadrom's Diag Studio exist to support.