ODX ( O pen D iagnostic Data e X change) is a data model for describing the diagnostic support [1] of a vehicle using the XML language. The ODX data model was created to unify the presentation of diagnostic data during the development, production and operation of a vehicle and is defined in ISO 22901-1.
Content
History
Work on the ODX standard began in 2002 by a group of ASAM specialists : Association_for_Standardisation_of_Automation_and_Measuring_Systems ASAM . The first version of the standard was published in 2004, it is called ASAM MCD-2D and is a specification of the ODX format version 2.0. Initially, the ODX format was intended to parameterize diagnostic scanners . The ODX file contained all the diagnostic information for the individual electronic control units and the vehicle as a whole.
Work on the standard continued in subsequent years, so in 2005 ODX 2.0.1 was developed, and in 2006 ODX 2.1.0.
In the future, the technical committee of the International Organization for Standardization is involved in the work on the standard . As a result of joint work in 2008, ODX version 2.2.0 is created, which is fixed by the ASAM standard and the international standard ISO 22901-1.
Scope
ODX offers a single way of presenting data that is used at all stages of a car’s life cycle by its participants such as a manufacturer of electronic control units , a car manufacturer, and a service center. ODX provides the ability to automate part of the operations at the stages of development, production and maintenance of a car. ODX also creates conditions for the reuse of previously created projects and the rapid transfer from one platform to another.
Consider the main applications of ODX for each of the participants in the life cycle of a car:
The manufacturer of electronic control units uses ODX in the following cases:
- automatic configuration of the code generator for the software of electronic control units ,
- automatic configuration of test systems used in testing electronic control units ,
- automatic generation of specifications for the diagnostic support of electronic control units ,
- reuse of previously created diagnostic support in new products.
The automaker uses ODX in the following cases:
- creation of initial requirements for diagnostic software in the form of ODX,
- automatic configuration of test systems for checking the declared diagnostic functionality of electronic control units ,
- automatic generation of service documentation, which usually reflects the relationship between the identified malfunctions and their causes.
Service centers use ODX to parameterize diagnostic scanners during vehicle maintenance.
Contents
The information presented in the ODX data model is divided into blocks called packages. The purpose, content and relationships of the packages are defined in the framework of the standard. The following is a brief description of the main packages.
| Package | Description |
|---|---|
| DiagLayerStructure | The DiagLayerStructure package defines a hierarchical data model that includes four levels:
This model also includes a data warehouse for sharing from different levels. |
| Comparam | The Comparam package contains parameters that determine the timings and behavior of the diagnostic connection. The parameters depend on the protocol used. They are used to configure the puncture stack of external devices such as D-servers. ODX provides the definition of communication parameters for KWP 2000 on CAN, KWP 2000 on K-Line and UDS on CAN. |
| VehicleInfo | The VehicleInfo package defines data that describes the vehicle and access to its diagnostic interface. In the first case, this is information about the manufacturer, model and type of car. In the second case, the pinout of the diagnostic connector, the logical connection with the gateway controller or a separate computer, and a protocol with its communication parameters are described. |
| DataStream | The DataStream package defines the connection between the diagnostic tester and the computer based on services and procedures. Services are activated by the diagnostic tester via messages. The message contains the SID (Service Identifier) and associated parameter values. The computer responds with a message. This message also contains SID and parameters. The procedure is used for more complex tasks and contains one or more services. Messages in the DataStream packet are defined at the bit precision level. The data requested from the computer is contained in the messages and can be encoded. Data can be interpreted and converted to the desired physical quantities using information from DOP (data object properties). |
| Dataparameter | The DataParameter package defines simple and complex data objects in the diagnostic data stream. Simple data objects can be scalar values or trouble codes. Complex data objects combine simple data structures, multiplexed data, outlier data, fields, and tables. Simple data is described through DOP, which includes data types, conversion (scaling) methods, units of measure, range boundaries, and other properties. The DataParameter package also defines the "packaging" of data in the protocol data unit (PDU) and retrieval from it. |
| Dyndefined | The DynDefined package contains a description of the data that can be determined during operation - dynamically determined data. Such data includes existing values. This connection method is often used when the configuration of the car can change during or after production. In addition, dynamically determined data allows you to combine various information into one message and transmit it at the request of a diagnostic scanner. This approach reduces the load on the data bus, since all the necessary information is transmitted in one message. This package contains information used by services to identify and read dynamically defined data. |
| DataTypes | The DataTypes package contains the data types used to describe the elements of the UML data model. This package does not define parameter data types. |
| Session security | The SessionSecurity package defines a state machine that handles two aspects of a diagnostic connection:
This model defines diagnostic sessions, safe states, and methods for transitioning between diagnostic sessions and access authentication. |
| Admininformation | The AdminInformation package provides information used in the development of diagnostic software. Administrative information can be attached to each element of the data model. It may contain the name of the specialist responsible for this element, information about his company, revision history of the element, data associated with the version control system and special data determined by the development company. |
Notes
- ↑ GOST 20911-89 "Technical diagnostics. Terms and Definitions"
Links
- Christoph R., Klaus B. 2006 ODX in Practice. Experiences, challenges and potential, Technical Article, Vector Informatik GmbH
- Christoph R., Klaus B., Oliver G. 2011 The Standard Mix does it: Diagnostics with AUTOSAR and ODX - Part 2: ODX in the AUTOSAR Development Process, Translation of a German publication in Hanser Automotive, 11/2011
- Official ISO site
- The official website of ISO in Russia
- ASAM MCD-2 D