ODX: one diagnostic truth for the vehicle's whole life

What state of the art looks like in diagnostic data

Every vehicle programme produces two things that must agree for as long as the vehicle exists: the software in the ECUs, and the description that tells every tool how to talk to it.

ODX, the Open Diagnostic data eXchange format (ISO 22901-1, published by ASAM as MCD-2 D), is that description in a standard, vendor-neutral form. It says which diagnostic services an ECU offers, how requests and responses are built, what every fault code and data value means, how the ECU is coded and how it is programmed. Author it once, and the engineering tester, the end-of-line station, the workshop tool and the cloud service all read the same truth.

The leading programmes treat that description as a product in its own right: authored before or alongside the software, validated automatically, versioned with each release and delivered to every consumer from one source. The rest treat it as documentation, written after the fact, and pay for it in every tool downstream.

Who this is for. Anyone who owns diagnostics in a vehicle programme, whoever supplies the tools: what is settled, what it costs, and what is still open.

One description, every tool that touches the vehicle

Diagnostic data is consumed far beyond the team that writes it. Each consumer trusts it without checking, so an error travels everywhere at once.

Consumer	What it reads from the description	What breaks when it drifts
Engineering testers	Services, data identifiers, scaling, security access	Wrong values on the bench; bugs reported against the wrong component
Test automation, CI and HIL	Expected requests, responses and fault behaviour	Tests pass against the description and fail in the vehicle, or the reverse
End-of-line production	Programming sequences, variant coding, identification	Stopped lines, mis-coded vehicles, rework after the gate
Workshops and after-sales	Fault codes, guided fault tracing, software download	No-fault-found repairs, parts swapped on guesswork, repeat visits
Remote and cloud diagnostics	Fault and data definitions for fleet monitoring	Fleet dashboards that report what the ECU never said

The description must follow every update

A vehicle is updated many times in service. Each update can change a fault code, a data identifier or a programming step. If the description does not move with it, every tool above is now describing a vehicle that no longer exists.

Drift is silent

Nothing crashes when the description is wrong. A value is scaled incorrectly, a fault is never shown, a coding byte is written to the wrong place. The cost shows up weeks later, as workshop time and warranty, far from the change that caused it.

Where to start. Ask one question: can you show, for any software version in the field, the exact diagnostic description that matches it? If the answer takes more than a minute, the description is documentation, not a product.

The standards are settled. The practice is not.

The core of the diagnostic data stack has been standardised for well over a decade. What varies between programmes is how faithfully it is used.

Standard	What it defines	What it means in practice
ISO 22901-1 (ODX)	The data model for ECU diagnostic and programming data, in XML. ODX 2.2.0 (ASAM MCD-2 D) dates from 2008; the ISO edition was last confirmed in 2025.	A stable target. The format is not the risk; how it is authored and maintained is.
ISO 22901-2	Emissions-related on-board diagnostic data described in ODX.	Regulated data in the same format as the rest.
ISO 22900-2 (D-PDU API)	The interface between diagnostic software and the vehicle communication interface.	Interface hardware can be swapped without touching the diagnostic data.
ISO 22900-3 (D-server API, ASAM MCD-3 D)	The application interface to the diagnostic runtime that interprets ODX.	Applications call services by name; the server builds the bytes from ODX.
ISO 13209 (OTX)	A standard format for diagnostic and test sequences.	Guided fault tracing and test procedures become portable, like the data they use.
ISO 14229 (UDS) and ISO 13400 (DoIP)	The diagnostic protocol and its transport over IP.	The conversation that ODX describes.
ISO 17978 (SOVD)	Service-oriented vehicle diagnostics: a REST API for classic ECUs and high-performance computers, published 2026.	A new interface on top. Classic ECUs behind it still need a description.

Observation 1 · The format is old, and that is a strength. Programmes that drift rarely do so because of the standard. They drift because of the process around it.

Observation 2 · Interoperability is earned, not given. Tool vendors extend ODX in their own ways, through special data groups and ODX jobs, the executable code (often Java) that a description can carry. A description that only opens cleanly in one tool has quietly lost the independence that was the point of the standard.

Inside ODX: layers, inheritance and one package

ODX is built to avoid saying the same thing twice. Diagnostic content is arranged in layers, and each layer inherits from its parent layers. Define a service once, and every variant below gets it.

Diagnostic layers · general to specific

1

Protocol. The diagnostic protocol and its communication parameters (COMPARAM): timing, addressing, transport.

inherited by

2

Functional group. What a family of ECUs has in common, for example every body controller.

Shared libraries

ECU shared data. Reusable definitions any layer can inherit from: units, data types, common services.

inherited by

3

Base variant. One ECU type: its services, data identifiers, fault codes and coding.

inherited by

4

ECU variant. One hardware or software variant: only what differs from the base, and what it excludes.

Identified at runtime

Variant identification. The tool reads the ECU and selects the matching variant automatically.

• Inheritance is the whole point. A fleet with hundreds of variants stays maintainable only if variants state their differences and nothing else.
• Communication parameters live apart from the services, so one service description serves several transports.
• Variant identification lets a tool recognise exactly which variant it is talking to before it trusts any value.

More than fault codes: the ODX family

ODX is a family of related descriptions, usually named after their file categories. Most programmes start with ODX-D and discover the others when production, software download and the workshop need them.

Part of the model	What it describes
ODX-D · Diagnostic layers	Services, requests and responses, data identifiers, scaling and units, fault codes, security access
ODX-C · Communication parameters	Protocol and transport settings for each link to the ECU
ODX-F · ECU memory programming	Flash sessions, memory layout and data blocks: the metadata a software download needs
ODX-E · ECU configuration	Variant coding: the configuration records that adapt one ECU to one vehicle
ODX-M · Multiple-ECU jobs	Diagnostic jobs that span several ECUs, such as a vehicle-wide fault read
ODX-FD · Function dictionary	Vehicle functions mapped onto the ECUs that implement them
ODX-V · Vehicle information	The vehicle’s topology: which ECUs it has, and how to reach them through its gateways and networks
PDX package	One ZIP-based container that ships a complete, consistent set of ODX files as a single versioned artefact

Six ways diagnostic data goes wrong

None of these is exotic. Most programmes recognise at least three.

Pattern	What happens	What it costs
Written after the software	The description documents the ECU instead of specifying it, always one release behind	Every tool lags the vehicle; errors are found by the people who use the tools
Copied variants	New variants are copies, not inheritors; a fix is applied to some copies and not others	Hundreds of near-identical files that disagree in small ways nobody can see
Tool dialect	Vendor-specific extensions, special data groups and proprietary ODX jobs carry real meaning; the description only works in one tool	Lock-in by stealth, and a migration project when the tool or supplier changes
Valid but wrong	The file passes the XML schema but breaks the semantic rules, or simply disagrees with the ECU	The checker says green; the vehicle says otherwise
No link to the software baseline	Nobody can say which description matches which software version in the field	After-sales tools guess; update campaigns cannot be checked against the vehicle
Handoff without acceptance	Suppliers deliver ODX at milestones, and it is accepted because it opens	Errors surface at integration or in the workshop, when they are most expensive

The common root. In every pattern, the description is treated as an output of the work instead of an input to it.

Lessons from real integrations

The patterns above are well known. These six are less often written down. They come from ODX import, export and integration work in vehicle programmes between 2019 and 2026, anonymised: parsers built against real files, PDX packages unpacked and merged, and diagnostic data used to drive tests.

1. ODX-compliant does not mean interoperable

Files from different authoring tools followed the same standard and still placed the same information in different places: the definition of a data identifier, for example, sat in one structure in one tool’s output and another structure in the next. Every parser that read both had to be adapted. Standard compliance is necessary and not sufficient. Add an implementation profile that says how your programme uses ODX, reference datasets that every tool must read identically, and validation rules that enforce both.

2. The package is part of the integration

Much of the integration effort came before a single diagnostic value was read: unpacking PDX packages, handling several ODX files in one package, resolving the references between them and merging files into one consistent set. Treat packaging, its structure and its validation as part of the diagnostic data process, not as a delivery detail.

3. Version mapping outweighs the format

Several ECU versions can share one description. A new software version does not always need a new one; a changed diagnostic interface does. The tester has to identify the installed version and select the matching description. Manage ECU hardware version, software version, bootloader, variant and description version as separate identities with a defined link between them. Correct ODX files give wrong answers if the tool picks the wrong one.

4. The aftermarket has more configurations than the factory

5

valid configurations left the factory

12

valid configurations in the aftermarket, after upgrades and part replacements

Software updates, replaced ECUs and spare parts multiply the combinations a workshop meets years after production. Diagnostic data has to follow the vehicle as it is, identified at the workshop, not the vehicle as it was built.

5. The description can write the tests

When the description already defines every service, parameter and fault code, it can generate the tests that check the ECU against it: that every defined object is present and answers as described, and that nothing answers that should not. Tie each result to the version of the description it was run against, and release verification becomes evidence rather than a checklist.

6. Diagnostics and software download share one source

The same identification, flash metadata, memory layout and configuration serve fault tracing, variant coding and software download. ODX-F and ODX-V carry what download and routing need; diagnostic data, protocol stack and interface hardware (UDS, a VCI, an SAE J2534 pass-thru) work together. Programmes that keep diagnostics and software lifecycle management apart end up maintaining the same facts twice.

The lesson behind the lessons. None of these problems is in the XML. They sit in the conventions, packages, versions and identities around it, which is where a programme’s governance has to reach.

What works: treat diagnostic data like code

The programmes that keep their diagnostics truthful use the same disciplines they already apply to software.

Specify first

The description is written as the ECU’s diagnostic specification, before or alongside the software, not reverse-engineered from it. The ECU team implements against it; the test team tests against it.

One source, many outputs

Engineering testers, end-of-line sequences, workshop content, test cases and documentation are generated from the same source. Nothing downstream is authored by hand twice.

Validate on every change

Schema validation is the floor, not the ceiling. ISO 22901-1 includes checker rules for the semantics, and programmes add their own: naming, ranges, coverage, forbidden extensions. All of it runs automatically, on every change, like a compiler.

Test the description against the ECU

The strongest check is the simplest: send what the description says to the ECU, or to its software-in-the-loop build, and compare. Run it in CI on every software change, so drift is caught by a red build rather than by a technician.

Release it with the software

Every software release is bound to the description that matches it, versioned and traceable to the software baseline. That is not always a new description: several ECU versions often share one, and a new one is needed when the diagnostic interface changes. In the field, the identified software version selects the description, not the other way round.

Every release, the same four steps

A diagnostic description is only as trustworthy as the pipeline that produces it. After authoring, every step is a check, and the package moves on only when it passes.

Source1

Author. One vendor-neutral ODX source, under version control, specified with the software.

Every change

2

Validate. Schema, ODX checker rules and the programme's own rules.

3

Test against the ECU. Requests and responses compared with the real or simulated ECU.

4

Package and release. A PDX bound to the software baseline, delivered to every consumer.

Four decisions every programme faces

Which tool owns the source. Pick an authoring environment that reads and writes standard ODX without hidden meaning in extensions. The test: export, re-import elsewhere, and compare.

How variants are modelled. Decide the layer structure early. Restructuring inheritance after hundreds of variants exist is one of the most expensive refactors in diagnostics.

Where the rules live. Write programme rules as executable checks, not as a style guide. A rule nobody runs is a wish.

How the field finds the right version. Agree how a tool maps an identified ECU software version to its description, and test that mapping as part of the release.

The supplier handoff decides the quality

In most programmes, much of the diagnostic description comes from ECU suppliers. That makes the handoff the point where quality is won or lost.

What to require at every delivery

1. Standard ODX 2.2.0 and a PDX package, with a statement of which software versions it covers, without required vendor extensions, and with the source of every ODX job included.
2. A validation report from automated checks: schema, ODX checker rules and the programme’s own rules.
3. Proof against the ECU: test results showing that the description matches the delivered software.
4. Traceability from the description version to the software version and to the change request that caused it.
5. A change log that names what changed in services, data identifiers, fault codes, coding and programming.

What to do on receipt

Run the same checks again, automatically, before the description is merged into the vehicle baseline. Accept on evidence, not on the fact that a file opens.

Long-life fleets: own the description, not the tool

Defence vehicles, buses, trucks and special vehicles stay in service for decades. Over that time the original tools, interfaces and often the original suppliers are replaced. The diagnostic description is the one asset that has to survive all of them.

What changes over thirty years

The interface hardware, the operating system of the tester, the authoring tool, the supplier of each ECU and, sometimes, the company that built the vehicle. Each change is a chance to lose diagnostic capability that nobody will rebuild.

Many heavy and defence vehicles are also built on truck platforms that use SAE J1939 diagnostics alongside or instead of UDS. Check early how your authoring tools and testers represent those ECUs, because ODX practice is most mature for UDS.

What should not change

The vendor-neutral description of every ECU and every variant in the fleet, owned by the operator or the programme, validated, and readable by any compliant tool. With that baseline, a replaced tool is a procurement decision. Without it, it is a re-engineering project.

Ownership is written into the contract: the PDX for every release as a named deliverable, with the right to use and modify it, and escrow where a supplier may not last as long as the fleet.

Rule of thumb. If a supplier’s diagnostic tool disappeared tomorrow, could another tool diagnose your fleet from the data you own? If not, you own a licence, not your diagnostics.

ODX in the SOVD era

SOVD, now the ISO 17978 series, gives the vehicle a modern REST interface for diagnostics, with targets that describe their own capabilities at runtime. It is often read as the end of ODX. In practice it changes where the description is used, not whether it is needed.

Question	Classic ECU	High-performance computer
How it is diagnosed	UDS over CAN or DoIP	SOVD natively, over HTTP and REST
Where its capabilities are described	Statically, in ODX shipped as PDX	At runtime, in an OpenAPI description served by the target
What SOVD changes	A Classic Diagnostic Adapter can expose it through the SOVD API, but still needs a description of its UDS services to do so	The interface and the description move into the vehicle
How long it matters	As long as the ECU is in service, often decades	From the platform generation that introduces it

Plan for both, from one source. Most vehicles will carry classic ECUs and high-performance computers side by side for years. The programmes that cope best keep one diagnostic source and generate both the ODX for classic ECUs and the content their SOVD layer serves.

What works well, and what it costs

An honest view of current practice, for anyone deciding what to adopt and what to watch.

Area	What works well	Limitations and cost
ODX as the single source	One description serves every tool from development to the workshop.	Needs an owner, and an authoring environment that respects the standard.
Layered variants	Hundreds of variants stay maintainable through inheritance.	The structure must be designed early. Restructuring later is expensive.
Automated validation	Catches structural and semantic errors in minutes.	Rules must be written, maintained and actually enforced.
Testing against the ECU	Proves the description matches the software, on every change.	Needs ECU access, a simulator or a software-in-the-loop build in the pipeline.
A PDX bound to every release	One versioned artefact, traceable to the software it describes.	Several ECU versions may share one description; that mapping must be designed and tested.
Supplier deliveries in ODX	Comparable deliveries across suppliers and programmes.	Suppliers interpret the standard differently; acceptance takes real effort.
SOVD alongside ODX	A modern interface without abandoning classic ECUs.	Two descriptions to keep consistent, unless both come from one source.

Bottom line. The cost and the risk sit in the lifecycle around it: authoring discipline, validation, release and supplier acceptance.

From copies to one baseline: where to start

Few programmes start from a clean sheet. Most have descriptions in several tools and formats, copied variants and a field fleet that has to keep working while things change. The path below works without stopping delivery.

1. Take stock

List every ECU, every variant and where its description lives: which tool, which format, who maintains it, which tools read it. Then pick a handful of software versions in the field and check whether you can find the exact description each one uses. The gaps you find are the plan.

2. Write the rules down, and run them

Agree an implementation profile for how your programme uses ODX, a reference dataset every tool must read identically, and the validation rules that enforce both. Run them on the descriptions you have today, before changing anything, so you know where you start. Test the current authoring tool the same way: export, re-import elsewhere, compare.

3. Restructure where it pays

Start with the ECU family that has the most copied variants. Rebuild it as one base variant with variants that state only their differences, then prove that nothing changed: every request and response from the new structure compared with the old, and with the ECU. One family done well becomes the template for the rest.

4. Bind it to releases and suppliers

Introduce the mapping from software version to description, release the PDX through the pipeline, and put the delivery requirements into supplier contracts at the next sourcing decision rather than all at once.

Start where the copies are. The family with the most copied variants usually pays back first: fewer files, fewer silent disagreements, and a structure the next programme can reuse.

Clear on the format, still open on the lifecycle

Where practice is settled, and where it is still moving.

Settled practice

• One vendor-neutral diagnostic description per ECU, in ODX, shipped as PDX.
• Layered variants with inheritance instead of copies.
• Automated validation beyond the schema, on every change.
• The description bound to the software versions it describes, and traceable to them.
• Interface hardware and runtime separated from the data, through the ISO 22900 MVCI standards (D-PDU API and D-server API).

Open challenges

1. Coexistence with SOVD. Keeping ODX and SOVD content consistent across mixed architectures, ideally from one source, is still largely solved programme by programme.
2. Tool dialects. Vendor extensions still erode interoperability. The industry lacks a common, practical conformance test for ODX round-tripping between tools.
3. Diagnostics after updates. As software updates multiply over the air, the description must follow every update in the field, and tools must always select the right version.
4. AI on diagnostic data. AI assistants for fault tracing are only as good as the data they retrieve from. A validated ODX baseline becomes the ground truth that keeps them honest and traceable.
5. Security information. Descriptions define how security access and authentication are performed, but keys and certificates must never travel with them. Keeping that boundary clean as workflows automate needs deliberate design.

Teams that start now can adopt the settled practice as it is, and design for the open questions instead of retrofitting them.

How we can help

Diadrom is a Gothenburg-based software company specialising in diagnostics, embedded software and lifecycle governance for mission-critical systems. Founded in 1999, ISO 9001 and ISO 14001 certified, listed on NGM Nordic SME (DIAH).

• Diagnostic data review. A practitioner review of your ODX baseline, variant structure, validation and release process against current practice.
• ODX authoring. DiagStudio, our ODX (ISO 22901) authoring environment.
• Test automation. Diagnostic regression tests in CI and on HIL rigs, configured in Diadrom Dolphin.
• Workshops. Sessions on ODX, PDX and SOVD, led by engineers who build and ship diagnostic systems.

Where this paper comes from

The lessons in section 06 come from Diadrom’s own ODX work since 2019: ODX import and export, extraction of data identifiers and fault codes from production files, PDX handling, and diagnostic data used to drive test automation.

Where DiagStudio has run

NDS, built on DiagStudio, was rolled out to all NEVS and Saab workshops in more than 60 markets. Lynk & Co builds new diagnostic services on licensed DiagStudio modules, serving Lynk & Co and Lotus. The NEVS case and the Lynk & Co case describe both.

Contact. Viktor Eliasson, CEO · info@diadrom.se · +46 733 31 11 15

Sources

• ISO 22901-1:2008, Road vehicles: Open diagnostic data exchange (ODX), Part 1: Data model specification. Last confirmed 2025. iso.org
• ISO 22901-2:2011, Open diagnostic data exchange (ODX), Part 2: Emissions-related diagnostic data. iso.org
• ASAM MCD-2 D (ODX), version 2.2.0, released 18 May 2008. asam.net
• ISO 17978-1, -2 and -3:2026, Service-oriented vehicle diagnostics (SOVD). iso.org
• ISO 22900-2, D-PDU API, and ISO 22900-3, D-server API: Modular vehicle communication interface (MVCI). iso.org
• ISO 14229-1, Unified diagnostic services (UDS), and ISO 13400-2, Diagnostic communication over Internet Protocol (DoIP). iso.org
• ISO 13209, Open Test sequence eXchange format (OTX). iso.org
• What is ODX? The ISO 22901 diagnostic data layer, and PDX. Jonas Hellberg.
• SOVD vs UDS: diagnostics for the software-defined vehicle.
• Automating UDS diagnostic verification in CI and on HIL.
• Through-life defence diagnostics for long-life systems.
• ECU baseline, variant coding and configuration management.