ODX (Open Diagnostic Data Exchange)

What is ODX?

ODX is a data model in XML that describes the diagnostic communication of an ECU so that tools can work with it without ECU-specific code. Its main content is organised in diagnostic layers that inherit from each other: PROTOCOL, FUNCTIONAL-GROUP, BASE-VARIANT and ECU-VARIANT, plus ECU-SHARED-DATA for common definitions. Each layer contains DIAG-SERVICE elements with their REQUEST, POS-RESPONSE and NEG-RESPONSE structures, and data object properties (DOPs) with computation methods that turn bytes into physical values and units.

For example, the ODX entry for a ReadDataByIdentifier service tells a tool that request 22 F1 8C reads the ECU serial number, that the response 62 F1 8C is followed by ASCII bytes, and in which sessions the service is allowed.

Where is it defined?

ASAM defines ODX as MCD-2 D; ISO 22901-1 publishes the data model as an international standard. The file types include .odx-d for diagnostic layers, .odx-c and .odx-cs for communication parameters and .odx-f for flash data. The UDS content it describes comes from ISO 14229-1.

What it means in practice

ODX is the closest thing to a specification of the diagnostic interface that a test team usually gets. It names data identifiers and routines, shows which ones are meant to be writable and which session or security level each service needs. That makes it the reference for two security questions: does the ECU enforce what the file says, and does the ECU expose anything the file does not mention?

We regularly see both kinds of gap. Data identifiers marked as read-only in the description accept writes, and services restricted to the extended session in the file answer in the default session. Undocumented identifiers are often leftovers from development that nobody reviewed.

How AutoST tests it

AutoST imports ODX and CDD files. The diagnostics engine uses them to name the data identifiers found during enumeration and to scan the routine identifiers the file lists, including write probing that checks whether write access is enforced as documented. Identifiers that answer but are not in the file appear as separate findings.

Common misunderstandings

ODX is a description, not a security policy. An ECU does not read its ODX file at runtime, so the file can be correct while the implementation is not. And not every supplier delivers complete ODX: a partial file still helps, but the enumeration has to fill the gaps.