Embitel

Search
Close this search box.

What is Open Diagnostics eXchange (ODX) and How It Enables Standardization in UDS Based Vehicle Diagnostics

Standardization in the processes of operations, design and development methods is an absolute must in an industry as diverse as automotive.

Multiple stakeholders from tier-1 suppliers to technology providers lend their expertise in development of an automotive module. A jazzy infotainment system that you see in a car has OS from one vendor and communications handled by another. One aspect that binds each of the stakeholder is standardization. And similar to every module, ECU diagnostics also needs standardization.

Going back to the example of the infotainment system, whether it’s the operating system or the communication module, if there is one thing that is common to both is diagnostics. These modules will face compatibility issues if common diagnostics practices are not followed. This is where ODX comes as the perfect solution.

Based on XML, ODX provides a standard that describe diagnostic data in an OEM agnostic format. And not only does ODX describe the diagnostics data in a standardized manner, it also makes it super easy to exchange. Doesn’t it sound smooth and seamless?

In this blog, we will throw some light on standardization in Vehicle Diagnostics and how ODX (Open Diagnostic eXchange) Format is the hero of this standardization.

What is ODX format?

The ODX format is standardized in ISO 22901 Standard and is an XML-based ASAM standard for describing ECU (electronic control unit) diagnostic data.

Using this uniform OEM-independent format, OEMs’, ECU Suppliers (Tier-I Suppliers), and testing equipment manufacturers can describe and exchange ECU diagnostic data, without any compatibility issues.

Whenever distributed teams are involved in projects, this standard becomes a good choice for exchanging relevant diagnostic information. This enables all the stakeholders to use the shared diagnostic data across geographies.

Open Diagnostics eXchange

Understanding the Structure of the ODX Data Model

At the foundation of ODX lies a data model which is formally specified using UML class diagrams. Once specified, the data model is mapped to XML. This ODX data model is partitioned into four main areas:

  • Diagnostics Communication: Communication between an external device and an ECU or a group of ECUs to enquire diagnostic information and/or to modify the ECU’s behavior for diagnostic purposes.
  • ECU Memory Programming: Read or write access to the ECU’s flash memory.
  • ECU Configuration: Data records and their properties for ECU variant coding.
  • Function Dictionary: Mapping of individual ECU diagnostic messages and data for the purpose to carry out diagnostics on a functional level.

ODX is independent of vehicle diagnostic protocols. It is compatible with most diagnostic protocols in the automotive industry and is specifically used with KWP 2000 (ISO 14230), UDS (ISO 14229), SAE J1939 protocols.

The need for a standardized Diagnostic Specifications format

In the automotive sector, a Diagnostic Design Specification is a document which describes ‘how diagnostics will be implemented in the systems being developed by an organization’.

This is the reference vehicle diagnostics related document used at every stage of development, right from high-level design to system testing.

Traditionally, the diagnostic functions of early ECUs were straightaway implemented in the software and documented as part of the software documentation.

However, this trend has now changed, and diagnostic specifications are before the onset of product development.

A well designed system is always backed by clearly stated diagnostic specifications. ECU diagnostic specifications are expected to be clearly defined for the software development teams

Since the advanced electronics have increasingly made ECU a complex system, the need for automating this process of drafting diagnostics specifications was felt.

In addition to this, more often than not, OEMs’ relied on either basic document formats like DOCX, XLSX, PDF, or proprietary documentation formats to share diagnostic specifications with the software development teams.

This problem multiples further when distributed development groups within an OEM are involved or various suppliers/engineering providers are involved.

To better streamline the operations and also introduce automation, the need for a standardized approach was felt. This standardized would let the diagnostics specifications be automatically entered into the configuration tools of the ECU life-cycle. This need for standardization triggered the development of the ODX standard format (Open Diagnostics Exchange Format) which was formally released in December 2000.

How is ODX Generated?

The generation of ODX can be understood by looking at the first cross-OEM ODX project that was carried out between two leading vehicle manufacturers from 2003 to 2006. The CANdela tool chain was used in the project and it involved two vehicle models. The following procedure was followed:

  1. CANdelaStudio was used to create the diagnostic descriptions based on a given template (OEM1)
  2. Thereafter, ODX data was exported using CANdelaStudio
  3. Then the supplier used CANdito / CANoe to perform diagnostic testing of the ECU and parameterized it using CANdela CDD data
  4. Finally, the tester was parameterized with ODX data during in-vehicle diagnostic testing (OEM 2)

This project was carried out using ODX version 2.0.1.

How ODX Aids in Configuration of UDS Services?

Manual configuration of UDS protocol services, diagnostics specifications (provided by the OEM) can be very time consuming and may suffer from the risk of manual errors.

With the advent of ODX, automated tools are also available, that facilitate the configuration of UDS protocol stack.

The diagnostic specifications are provided as input to the ODX tools to generate XML-based ODX files. These files then can be referred to during the development, testing, and validation phases.

The ODX files can also be used to automatically generate configuration files (.c and .h files), required for UDS diagnostic specifications.

Benefits of ODX for the Automotive Industry

Because of the uniformity it brings in the different phases of vehicle diagnostics configuration, OEMs, suppliers and technology providers observe a wide range of benefits

  • The description of ECU diagnostics data can be done in a standardized format
  • The same ODX file can be shared within development, production, service, and validation teams, so that all teams have a single source of information and everything happens in a smooth manner without any discrepancies
  • The ODX file’s XML description can be used to generate documentation
  • Diagnostic data verification takes lesser time and effort
  • Lesser number of errors as a standard diagnostics data format is used across the teams

In order for the OEMs and the product engineering service teams to use ODX format with ease, there are several tools to choose from. Irrespective of how ODX format is implemented for vehicle diagnostics (UDS), it is going to bring in the much needed standardization among the automotive stakeholders. It is also likely to expedite the process of vehicle diagnostics configuration by automating it.

Vaibhav

About the Author

Vaibhav is a digital-marketing professional with a deep-rooted interest in everything automotive. Regular collaborations with automotive tech guys keep him apprised of all new trends in the automotive industry. Besides digital marketing, Vaibhav is fond of writing and music.

Scroll to Top