WithODX (Open Diagnostic data eXchange) is a unified, for in ISO 22901 (ASAM MCD 2D) standardized description format diagnostic data. ODX describes the development of diagnostic services with the appropriate parameters conversion methods, units, variants, etc. On the basis of a standardized Diagnostic runtime system (MVCI server or D-Server, ISO 22900), a diagnostic tester will be built, configured by this ODX record. The user of this system have a result by the internal structure of the diagnostic communication such as the transport used and diagnostic protocols take care of anything. He looks for the database interface of the D-Server API (ISO 22900-3) first, the control unit version, then the appropriate service bedatet him, sending him to a function call to the control unit and evaluates the returned response, see Fig.

Design and operation of a standardized diagnostic runtime system (MVCI)

Such diagnostic runtime systems are available from several vendors, such as: PRODIS.MCD of DSA, DTS-COS Softing or own development of several vehicle manufacturers. ODX can be described only the diagnostic information used for communication of a diagnostic tester with one or more control devices required.

In practice, a diagnostic tool in the development, production and service, however, significantly more tasks. Troubleshooting in the workshop requires the combination of the diagnostic data with the troubleshooting instructions and spare parts data banks of the vehicle manufacturer. All diagnostic steps and the resulting data must be recorded and managed. Only the interaction of several diagnostic services are fully functional tests can be applied, vehicle components taught for a replacement or software updates to the vehicle controller are performed. A diagnostic sequence therefore describes the various interactions between a user (development, production or technical staff), the diagnostic tester, the control units and possibly the external measurement, see Fig.

Diagnostic sequence in interaction with users and vehicle interaction

Such diagnostic procedures were defined in the past, usually within the control device specifications in prose. A development engineer is then often these processes by writing code to (for example, as a Java job within ODX) tester-specific. Because of the differing requirements in the development, production and service processes that were often implemented several times. In addition, in the implementation of revised conditions or from the experience of development engineers often made changes to the previously specified procedures.

Considering also that today there are hundreds per vehicle model to several thousand in some cases very complex diagnostic sequences, it is clear that the information is on the right, proven diagnostic procedures for a business of strategic importance. This knowledge must be stored reliably and reusable. OTX is to support here as a single, standardized exchange format of the specification, through implementation, to the construction of diagnostic sequences. It must be consistently used by the vehicle manufacturer on its supplier from development to production and workshop organization are, see Fig.

Application of OTX in the diagnostic process chain