ASAM MCD-2 D

The diagnostic functions of early ECUs were usually just implemented in software and documented as part of the software documentation, typically as a control-flow-oriented description. In the beginning of the 90^th, Daimler commissioned the development of a Diagnostics runtime system, called CAESAR/Diogenes. The system required for the first time a data-oriented description of Diagnostics functions and communication. This was the foundation of the development of the ODX Standard (Open Data Diagnostics Exchange Format), which got later the official name ASAM MCD-2 D. After several years of development with multiple non-public versions, ODX version 1.2.2 was published by ASAM in December 2000 as the first public release.

This release contained the Diagnostics communication Data Model and first attempts to describe ECU memory programming (Flash). Release 2.0 then mostly completed the Data Model for ECU memory programming. The Data Model got extended by vehicle identification information, network topology and the diagnostic plug pin-out (VehicleInfo). The latest release, ASAM MCD-2 D version 2.2 adopted the communication parameters from ISO 22900-2 (Comparam), included support for Variant coding (ECUConfig) and functional Diagnostics (FunctionDictionary).

At the beginning of the computerization of cars, the development process for diagnostic functions and communication mostly consisted of writing code and documentation. Diagnostics got re-implemented multiple times in every new ECU project, in every test system, in every production system and in every workshop system. Besides the extra efforts of multiple implementations of the same diagnostic features, this caused inconsistencies, frequent communication errors and other costly time and quality issues. Furthermore, Diagnostics specs were written in Word, PDF or proprietary ASCII formats, which were not machine-readable. Consequently, the relevant data had to be manually entered into tools of the ECU life-cycle. This waste effort multiplied, when distributed development groups within an OEM, or various suppliers and engineering providers of different companies are involved in the development life-cycle. This process of multiple implementation of the same functionality and multiple Specification sources and formats for the same system was highly error-prone, expensive and impeded fast development cycles. Variants made this process even more complex. And pushing change requests through such a development process that is already in full swing quickly turned out as a mission impossible.

The main motivation for ASAM MCD-2 D was to consolidate all Diagnostics Specification data of an ECU or ECU network into one location, give it clear semantics that are understandable by all involved parties and make the Specification machine-readable. This is achieved with the Diagnostics Data Model of ASAM MCD-2 D and its serialization into the ODX data description file. The Diagnostics system of a vehicle and its ECUs can be defined in one central location, exchanged via one standardized and machine-readable file and is the basis for all engineering activities at ECU development, production and service. Furthermore, ODX-specifications guarantee long-term availability of the data. It is very likely that computer systems are still able to import, process, understand and work with the data from ODX-files in the coming 10 to 20 years due to a stable and carefully advanced Standard .

With ODX, the distribution of Diagnostics Specification is streamlined between different engineering centers of an OEM, its ECU suppliers and engineering service providers, manufacturing, dealerships, service franchises and diagnostic engineering tools makers. Since they are all based upon the same Standard, the same information in the same data representation format can be distributed. This takes away the waste effort of converting specifications to different formats, manual implementation efforts of processes that could otherwise be automated, handling of multiple description formats for the same information and the necessary error resolution efforts that come along with those extra working steps.

ASAM MCD-2 D opened new markets for automotive suppliers and engineering providers. Diagnostics development turned from projects to products. Instead of writing software and developing tools for each OEM, suppliers could now develop products that can be used by all OEMs. This significantly reduced development and tooling costs for OEM and increased the profit margins for suppliers through scalable product sales.

The Standard ODX can be employed throughout the complete vehicle-Diagnostics life-cycle, which is development, manufacturing and service.

During development, the OEM works together with an ECU system supplier and potentially with other engineering service suppliers. OEMs typically have a cross-platform strategy for the Diagnostics capabilities of their vehicle platforms, which represent an OEM-wide Standard to be implemented in each vehicle. The goal of such a strategy is to have as little variation in the diagnostic capabilities of vehicles as possible, to promote reuse and to reduce the overall costs of Diagnostics development. To meet this goal, OEMs use ODX during the authoring process of Diagnostics data. It is common practice on the OEM side to set up an ODX-compliant toolchain with an Diagnostics Database at its core in each engineering center. This Database contains the complete Diagnostics data for ECUs and vehicles. Data is exchanged between the databases via the standardized ODX or PDX files. This allows to synchronize cross-vehicle platform ECU Diagnostics development at different engineering centers and to ensure that company standards are followed. ODX/PDX-files are also used in a manufacturer-supplier relationship to exchange Diagnostics specifications and to ensure that the supplied ECU software meets the Specification.

ECU system suppliers and engineering service providers are typically at the receiving end of exchanged Diagnostics data. They use ODX to extract requirements to be implemented in the diagnostic software and to configure development and test tools. For example, ODX is used for configuring the automatic generation of source code for diagnostic kernel software components, which automatically setup the protocol stack and diagnostic parameters. Test tools can be automatically configured with test cases to verify the diagnostic behavior of ECUs. The Diagnostics documentation may be automatically generated based upon ODX data. Since this process can be highly automated via machine-readable ODX-files, there is little room for errors, misunderstandings or inconsistencies. The likelihood is high that suppliers deliver software that is compliant to the OEM's Specification.

Once diagnostic development is near its end, the diagnostic data is released for use for manufacturing and service. Manufacturing uses the data to setup End-of-Line test equipment. The service department generates the service documentation and the ODX runtime format for workshop testers. The latter is used by dealerships and service workshops to program existing diagnostic devices for access to the diagnostic system of the vehicle. One single File Format is used for various diagnostic service systems.

ODX is most commonly used in the automotive industry, primarily by passenger car manufacturers, commercial truck makers, but also by construction- and off-road vehicle makers and in the shipbuilding industry. Some non-automotive use of ODX is known, such as for the development of heating systems for buildings.

The main part of the ODX Standard contains the definition of Diagnostics communication between one or several ECUs of a vehicle and an external device, such as a Diagnostic Tester or D-server. The Standard covers several use-cases.

The most frequent functionality in the field of Diagnostics is service-oriented communication. The external device sends a message with a service ID (SID) and related parameters to the ECU. The parameters might be a local ID (LID), common ID (CID), parameter ID (PID) or a memory address and number of bytes. The parameters define what is being requested, e.g. engine speed or a readout of a specific memory address section. The ECU responds with a message to the external device. It contains a SID and typically repeats the requested parameters, which allows the external device to link responses to requests. The response message then contains more  parameters, which contain the requested data, e.g. the current value of the engine speed or the content of the requested memory section. This kind of communication is specified via theDataStream package of the diagnostic communication Data Model.

A special Use-Case within the service-oriented communication is to read out diagnostic trouble codes (DTC) and related environmental data from the ECU's memory. This allows DTC-handling as defined in KWP 2000 (ISO 14230) or UDS (ISO 14229).

Closely related to service-oriented messages are dynamically defined messages. They allow to configure the requested data during runtime. Some protocols such as KWP 2000 (ISO 14230) and UDS (ISO 14229) allow dynamically defined massages. This kind of communication is specified via the DynDefined package of the diagnostic communication Data Model.

Besides service-oriented messages, ODX also allows to specify access to ECU data based upon variable identifiers (aka labels). This access method is similar to how Calibration systems access Measurement variables and Calibration parameters in the ECU memory. This kind of communication is specified via the DiagnosticVariable package of the diagnostic communication Data Model.

ODX does not specify communication protocols, but the Data Model of ODX contains parameters of communication protocols. They are typically used to configure the protocol stack of external devices and define the behavior or Real-Time performance of a protocol. The communication parameters are specified via the Comparam package of the diagnostic communication Data Model.

ODX further supports dynamic diagnostic responses and variable length parameter. Diagnostic states, state transitions and authenticated access can be defined. The Data Model also contains a description of the network topology and vehicle identification information.

The packages of the Data Model for Diagnostics communication are briefly described in the following table.

One use case of data transfer between an external device and an ECU is the programming or (partial) reprogramming of ECUs, called ECU memory programming. ODX allows to describe the information needed for the programming procedure. The Standard is aligned to ISO 14229-1 and 14230, which define flash jobs in detail. A diagnostic application can use the ODX information to initiate such a flash job. The Data Model contains all needed information for this purpose.

The main description element of the ODX model for ECU memory programming is the ECU memory object (ECU-MEM). It contains the logical description of data blocks (DATABLOCK) with references to the actual data that is to be written into flash memory (FLASHDATA). The Data Model also may contain a description of the memory layout (PHYS-MEM), which enables the Diagnostic Tester to check, whether the data blocks actually fit into available memory. Further security means are available, e.g. identification labels and signatures that can be used to make sure that the data to be flashed is compatible with the data in the ECU.

The ECU memory object furthermore contain sessions (SESSION). They are the objects that can be chosen for ECU memory programming. Each session references one or more data blocks to be written to the ECU memory. Identification labels ensure that sessions are compatible to the target device. The session also holds information about how to perform checksum calculations to check the integrity of the flashed data. Sessions may also define an upload of data blocks from the ECU memory to the external diagnostic device. The data is then written to a file.

The data definition for ECU memory programming is contained in one package of the ODX Data Model, which is described in the following table.

One specific Use-Case of ECU memory programming is the configuration of an ECU, which is also commonly called "Variant coding" in the automotive industry. Here, the Diagnostics bus is used to set specific variants, e.g. to handle different car configurations or to configure the car for export to a specific country. ECUs are typically configured End-of-Line during the production process of the car. The configuration may also be changed via a Diagnostic Tester after production in a workshop. ECU configurations are specified via the ECUConfig package of the ODX Data Model. The package contains variants in configuration records (CONFIG-RECORD), which are programmed into the ECU's flash memory.

The data definition for ECU configuration is contained in one package of the ODX Data Model, which is described in the following table.

Besides flashing ECU configurations into memory, it is important that diagnostic testers are able to identify the variants that are implemented in an ECU. ODX allows to specify ECU variants (ECU-Variant), pattern and matching parameters, which identify specific ECU variants. A Diagnostic Tester can read out the ECU configuration via regular diagnostic commands and compare the returned data with the Variant identification contained in ECU-VARIANTs. Once a match is found, the Diagnostic Tester reports that Variant to the user. ECU variants and how to identify them is specified in the DiagLayerStructure package of the ODX Data Model.

The basic features of the ODX Data Model, - Diagnostics communication,  ECU memory programming and ECU configuration -, mostly focus on the diagnostic functions of a single ECU. However, the diagnostic functions in modern vehicles are increasingly distributed across multiple ECUs. The diagnostic requests have to be send to several ECUs and their responses may need to be consolidated into one result to be displayed in the Diagnostic Tester. This is called "function-oriented Diagnostics" or "functional Diagnostics", as opposed to "communication-based Diagnostics" described in the earlier chapters.

The FunctionDictionary package of the ODX Data Model allows to specify functional Diagnostics. Diagnostic functions are organized in the Data Model as hierarchical function node groups (FUNCTION-NODE-GROUP) and function nodes (FUNCTION-NODE). A function node represents a diagnostic function. This node contains references to existing diagnostic objects of ECUs, such as diagnostic messages (DIAG-COMM), data structures (TABLE-ROW), diagnostic trouble codes (DTC) and associated environment data (ENV-DATA). A function node is essentially a mapping of one diagnostic function to individual messages and data pertaining to different ECUs.

A function dictionary does not specify new diagnostic capabilities of ECUs. It just bundles existing diagnostic messages and data of ECUs and makes them selectable in an Diagnostic Tester as one diagnostic function. This way the user of a Diagnostic Tester can carry out Diagnostics on a functional level and does not have to understand or handle the diagnostic communication with each individual ECU that is involved in this function.

ASAM MCD-2 D defines together with the other standards ASAM MCD-3 D, ISO 22900-2 (D-PDU API) and ISO 22900-3 (D-Server API) an architecture for fully automated access to vehicle Diagnostics in all phases of the ECU's life-cycle, i.e. during development, testing, production and service.

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

The first versions of ODX were just used as an exchange format between proprietary systems. OEMs initially kept their own description formats and Diagnostics data bases. Gradually, German OEM adopted the ODX Data Model, ODX methods and related ISO standards for their ECUs. ASAM MCD-2 D is today fully accepted by all major German OEMs and Tier-1s and a Standard component in the development of Diagnostics software and systems. Other European OEMs followed gradually with lesser adoption rates. Asian OEMs just start to use ODX whereas American OEMs have not yet shown any significant use of the Standard in their development or production processes.

OEMs employing ASAM MCD-2 D have reported considerably reduced development times of diagnostic functions, reduced setup times in the production of new models, highly reduced vehicle communication problems with diagnostic testers and much better support for vehicle variants.

The Standard includes the following deliverables:

• Standard documents
• Schema files
• Communication parameter specifications for KWP 2000 on CAN, KWP 2000 on K-Line and UDS on CAN
• Authoring guidelines for ODX files

• Datenkommunikation im Automobil: Grundlagen, Bussysteme, Protokolle und Anwendungen; Christoph Marscholik, Peter Subke; Hüthig-Verlag; 2007; ISBN: 3778529692
• Road Vehicles - Diagnostic Communication; Christoph Marscholik, Peter Subke; University Science Press; 2009; ISBN: 8131807347
• ASAM ODX; Stefan Bienk; IEEE/ICSE; 2008; ISBN: 9781605580791