How OTX and ODX Are Enhancing Automotive OTA Diagnostics

Today, technicians interact with vehicles using on-site diagnostics tools. These interactions are supported by standards like those for ODX and OTX files. These files, which both original equipment manufacturers (OEMs) and electronic control unit (ECU) suppliers develop, define key types of operations, including firmware updates, standardized diagnostics, and custom diagnostics and commands.

In the future, OEMs and service technicians will use remote access to numerous vehicle systems for these purposes and even for repairs. For drivers this means less travel to the dealership—comparable to the many doctor’s visits that have been replaced by telemedicine. But while the physician still asks questions about subjective patient perceptions, modern motor vehicles allow the retrieval of quantified data.

With Sibros’ solutions, standardized definitions such as ODX and OTX can be leveraged to enhance OEM workflows via remote access. This article will dive deeper into the details of ODX and OTX, use cases, challenges the industry faces, and what has to be provided to really harness these standards.

What is ODX and OTX?

An Open Diagnostics eXchange (ODX) file—as defined in ISO 22901—functions as a specification for an ECU. It describes how to interact with the Unified Diagnostic Services (UDS) interface of an ECU. It can, for example, contain the information about what Data Identifiers (DIDs) and Diagnostic Trouble Codes (DTCs) are available. An ODX file may be ingested by an ODX tool that decodes it into human-readable services such as “read serial number”, “read battery voltage”, or “clear faults”.

An Open Test sequence eXchange (OTX) file—as defined in ISO 13209—is essentially a script that describes a sequence of operations. For example, an OTX file may contain a firmware update sequence with a series of flow control statements (if, while), timing statements (wait), and action statements (UDS requests). 

ODX and OTX are different ISO standards but are well-paired in practice because ODX defines how to interact with an ECU, while OTX contains sequences that can be executed based on a corresponding ODX. Sometimes multiple ODX files are grouped in a binary archive known as a PDX (Packaged ODX) file. 

Both ODX and OTX files are typically created by the ECU firmware developer, utilizing expensive software. They are stored in XML format and may be divided into multiple files to be used by onsite tools running specialized software.

Why ODX and OTX?

ODX and OTX are standardized ways for software tools to interact with ECUs. OEMs and suppliers share ODX and OTX files as a means for developers, manufacturers, and dealerships to communicate with ECUs.

A supplier, for example, can ship their ECUs along with ODX and OTX files, and an automaker can integrate the supplied files into an end-of-line (EOL) tester. This may include processes like the validation of vehicle attributes, identification of faults, or firmware updates. 

The Industry Challenge

ODX and OTX are commonly used by out-of-vehicle tools, for example automation software which runs on a desktop or mobile OS (like Windows or Android) and executes ODX operations or OTX sequences through a Vehicle Communication Interface (VCI). One major obstacle is that ODX/OTX is still performed using a VCI tool that is plugged into the vehicle. This need of physical access to the vehicle is not only a bottleneck, but a cost and pain point. Additionally, there is no option of monitoring on an ongoing basis. If we compare this to wearing a heart rate monitor, it would mean only being able to see the data when in the doctor’s office.

‍

‍

Given that connected vehicle development means an ever increasing number of electric and electronic functions and higher volumes of software, the ability to send commands to vehicles regardless of location and time becomes ever more vital. With the potential of 70+ ECUs and a considerable number of sensors available for data collection, an approach confined to the service bay is untenable. The limitations and delays for commands, data collection and subsequent analysis have the potential to be detrimental for profits, costs, innovation, performance, driver satisfaction, safety and security. They are roadblocks that need to be removed. 

The ideal scenario is that commands can be exercised at all times, with the only constraints being those related to safety and security, such as the state of the vehicle and, in certain cases, driver consent. This includes the ability to log data in real time and transmit it to the cloud, as well as to remit, exercise, and confirm commands—all without delay.

The goal is clear, to reach individual ECUs in a vehicle with minimum latency. To do this, ODX and OTX files should be uploaded and managed in the cloud, with operations triggered through a Web Portal, and in-vehicle components then executing commands, diagnostics operations, and firmware updates.

Remote ODX/PDX Workflow

With Sibros, users can perform ODX and OTX functionality over the air through our Web Portal. Instead of hooking up an out-of-vehicle tool to the VCI, the in-vehicle components Deep Updater and Command Manager execute UDS requests to any ECU in the vehicle.

Sibros’ Command Manager is designed to handle ODX and OTX files, among other file and data types. After the user defines commands and command sequences, the cloud stores and parses these files and presents a list of commands and sequences on the Web Portal that can be executed on the vehicle.

Sibros Deep Updater accepts OTX files containing firmware update sequences. These files are stored in the cloud and relevant firmware update sequences are sent to the vehicle along with the firmware package.

‍

Let’s have a closer look at the processes for these two applications. 

Process for Commands

The process for commands includes the following steps:

• Upload ODX files associated with a data mapping ID.
• On upload, the cloud performs precondition checks to validate the ODX files.
• The cloud parses uploaded ODX files that are associated with the vehicle’s data mapping ID and presents a list of available commands on the Web Portal.

‍

Process for Updates

To update an ECU, the Deep Updater requires an update sequence and a firmware image to flash. With an OTX file, an update sequence can be defined through the order of the UDS requests, conditional branching operations depending on response(s), and timing (such as a periodic request at a defined rate).

The process then comprises the following steps:

• Upload of OTX files that define a firmware update sequence and map the file to an ECU and a firmware version.
• The cloud performs precondition checks to validate the OTX files.
• On a firmware update deployment, the cloud provides an accessible database of firmware update sequences to Deep Updater.

              - On request, the cloud serializes the firmware update sequence to a format suitable for the in-vehicle OTX interpreter.

Potential of ODX/OTX

ODX and OTX are helpful tools that complement each other and provide the advantages of standardization. However, as with any tool, their benefit depends on use cases. If reduced to the service bay or a physical hardware connection, the options remain limited. With over-the-air solutions, like those provided by Sibros, hundreds of use cases for commands, logging, and updating are easily achievable. To learn more about Sibros or schedule a demo, please contact us today.