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

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

In an industry like Automotive, the value-chain is tightly-coupled and multiple stakeholders are involved in design and development of any product.

From component suppliers to Tier-I/Tier-II electronics suppliers to product engineering services providers to OEMs’ (didn’t we mention that the value-chain is also very exhaustive)

In such a tight-knit industry, where the overall success is defined by the efficiency at all the levels of the supply chain, Standardization in the processes of operations, design and development methods is an absolute must.

The goal of this Standardization is to enable forward and backward compatibility, across the supply-chain.

Hence, one will observe abundance of this much needed standardization, across the automotive industry, in avatars like AUTOSAR Architecture, ISO Standards and more.

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.

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.

This entry was posted in Embedded Blog, Blog by Embitel. Bookmark the permalink

Sep 20 2019
Related Posts

ASK OUR EXPERTS

captcha

 I agree to allow this website to store my submitted data. This data can be used only for responding to my query and/or send related information about technology services and solutions.

FEATURED WHITEPAPER

12 design strategies to develop an "In-Vehicle Infotainment " system

RELATED SERVICES
 

Car HUD (Heads-up Display)

Go-to-market in 6 months with our automotive grade hardware and software design


Automotive Control Units

Electronic Control Units (ECU) development services for Body Control Modules (BCM), Powertrain, Chassis and Infotainment


AUTOSAR Software Services

AUTOSAR MCAL development, RTE and BSW integration, Application Layer development, Tools configuration and code generation


CUSTOMER SUCCESS STORIES
 
J1939-stack

J1939 Stack for advanced EPS system

Find out how J1939 stack resolved on-chip memory issue for an Automotive Tier-I supplier


connected-car

Software re-engineering | Telematics applications

Modular architecture re-design across fleet management product lines - GPS fleet security, vehicle and trailer tracking


IoT

IoT based Home Automation system

Design and development – Sensor Networks, Custom IoT gateway, Cloud and Mobile App