The ODX ISO 22901-1 (Open Diagnostic data eXchange) standard describes an XML format for exchanging diagnostic data. The ODX format contains both diagnostic specifics and flash data for individual ECUs as well as information for accessing the entire vehicle network. The data is usually processed on a D-Server in accordance with ISO 22900-3.

What does ODX stand for?

ODX stands for O pen D iagnostic data e X change and describes an XML format for exchanging diagnostic data. It contains both diagnostic specifics and flash data for individual ECUs, as well as information on accessing the entire vehicle network. The ODX standard is specified in ISO 22901-1.

ODX ISO 22901-1 – Open Diagnostic data eXchange – ASAM MCD-2 D

Standardized Exchange of Diagnostic Data Based on ODX

The ODX standard according to ISO 22901-1 (Open Diagnostic data eXchange) describes the exchange of diagnostic information during the entire ECU life cycle. This includes the entire diagnostic capabilities of a vehicle, i.e. the diagnostic services including their parameterization and the results received from the ECUs. The hexadecimal communication data is converted into physical values.

ODX data is described in XML format regardless of the manufacturer, buses or protocols. This makes it easy to generate a readable specification, e.g. as a PDF. The data is processed in test systems via a D-Server in accordance with ISO 22900-3, so ODX data enables an executable specification.

Users and Benefits

The use of ODX data extends across all phases of a product, from development to the workshop, but also from the control unit to the entire vehicle. All information is up to date because variant management is part of the standard. Seamless communication and the exchange of data is ensured at all times: between OEM, supplier and tool user, but also between the specialist departments in development, production and after-sales service. ODX offers a range of benefits for all users:

Cost savings thanks to manufacturer-independent data format
Machine and human readability
Freedom from redundancy
Time savings thanks to single source
Avoidance of misunderstandings
Enabling clear release management

Use Cases and Areas of Application

By using the ODX standard, several use cases can be covered:

Specification of the diagnostic scope of ECUs and vehicles
Tool parameterization including the description of communication parameters for various diagnostic protocols
Data storage and documentation of the diagnostic scope over the entire life cycle of the product - no information is lost
Organized data exchange between OEM and supplier, as well as within an OEM

ODX is used for all diagnostic-relevant functions:

Fault memory operations
Flash programming
Variant coding
Measurement via diagnostics
Actuator test of the ECUs

A typical application scenario for ODX data could be as follows: First, OEM-specific specifications are generated in the ODX data via an editor. These are transferred to the ECU manufacturer as a specification. The Tier1 adds ECU-specific information, e.g. conversions from hex values to physical values. The resulting ODX data can then be used by both the ECU supplier and the vehicle manufacturer for testing in an MVCI server-based test system.

Illustration of ODX Data Creation via an Authoring Tool and Use in a Diagnostic Tester

Implementation

The ODX data is technically implemented in XML format. As a rule, an ODX data record describes an entire vehicle, whereby each control unit and each control unit variant is described in its own XML file. In addition, the protocols and vehicle functions used, which are addressed via a functional address, are managed in separate files. There are also some special file types:

For flash programming to describe the memory layout and programming logic
For variant coding and the generation of coding strings
Libraries for the description of fixed or recurring descriptions

The XML files can be exchanged and managed individually or combined in a PDX container.
The files describe a hierarchy in which the underlying level always knows all the information. It goes from the protocol via the functional group to the control unit and the control unit variant. As only changes need to be described, redundant information is avoided. This saves effort and storage space.

The individual files describe the diagnostic communication, which is made up of the following elements:

Communication parameters of the diagnostic protocols
Diagnostic services consisting of requests and responses
Parameterization of the diagnostic services via service parameters
Results of the diagnostics (response parameters)
Fault codes (Diagnostic Trouble Codes, DTCs)
Diagnostic sequences (in JAVA)

Technical Implementation of ODX: From ECU Variants to ECU to Functional Group to Protocol

Softing Experience

Softing Automotive has not only actively driven standardization since the beginning, but also implemented the standard from the very beginning. This is why we claim to be the supplier with the greatest experience. Using the ODX description as a basis, we have realized numerous solutions for a whole range of different applications, e.g. editors, creation systems for test environments, checkers etc. In addition, we have immense experience in consulting, and in defining and implementing ODX processes and in the necessary migration scenarios.

ODX Solutions

Products
Softing DTS.venice	ODX Data Editor and Checker
Softing SDE	Implementation of the standards ODX v2.0.1 and ODX v2.2 (access via ASAM MCD-2D v3.0)
Softing DTS.automation	Simple access to ODX data for testing and automation systems with the technologies COM/DCOM, OPC, LabView
Softing DTS.monaco	Application-oriented development tester for validating ECU functions on the basis of ODX
Softing TDX	For the development of workshop testers based on ODX
Softing TCS	Diagnostic simulation with the possibility of automatic creation of simulations based on the specification