• Class structure
• Example procedure in the Job Processor
• Typical program flow
• Development of diagnostic applications

Let us turn now to the actual diagnostic tester. The basic idea of ​​ASAM was to develop standardized data formats and a runtime system for the implementation of an application and diagnostic system. The implementation of such a runtime system for the field of diagnosis is the so-called MCD 3D Server the d stands for diagnosis. Therefore, one often says D-Server or ODX kernel. It is standardized in ISO 22900 and is there under the name MVCI server that is also used here.

Standardized diagnostic runtime system according to ISO 22900

In the figure we see the construction of such a runtime system in detail. From above, the actual diagnostic application that is the graphical interface of the diagnostic tester offers the MVCI runtime system, a standardized programming interface, an API (Application Programming Interface). Go down to the vehicle uses the runtime environment, the D-PDU API to access the bus interface (VCI) access. The configuration of the runtime system via the appropriate ODX record.

Internal structure of a MVCI diagnostic system according ISO 22900

Within the runtime system for the so-called Data Processor is responsible for accessing the actual record. That is, the programmer does not interact directly with the ODX data, but uses functions to have access to the record. Communication with the bus interface is performed by the so-called Communication-Processor within the runtime system. The sequence of single ECU job done in the job-processor, while flash jobs are handled by the so-called flash-data-processor. For all of these elements exist in the server API and corresponding function groups corresponding function calls.

Class structure

Now consider the class structure of the MCD-run-time system is necessary for the programming API, so the user is important. You will see a twofold. On the one hand, it is encapsulated data objects, ie classes, the ODX data. On the other hand there is the runtime objects that contain essentially the methods and activities to perform certain functions on that data. Between the data objects and runtime objects is the Logical Link Table, which contains the information about the logical connections of the diagnostic tests on the individual control units. The logical links can access three different class structures. In the area of ​​application, there are the so-called collector classes, the classes are encapsulated, the measured data and the handling of the data. For the adjustment of the Characteristics of data are provided, the adjustable parameters, curves, maps included. For diagnosis, it is the class structure MCD Diag-Com-primitives, which encapsulates the diagnostic services and diagnostic procedures such as single-ECU-jobs, multiple jobs, etc. ECU.

MVCI basic structure of a diagnostic system according to ISO 22900

We deal here not with the field measurement and calibration (MC), but only with the diagnosis (D). Although ASAM MCD 3 with the claim actually raises both the diagnosis and the field of measurement and calibration, thus covering the test area, there are historical reasons, two different worlds. So far, this harmonization has not succeeded.

Timeline ASAM AE MCD

Example procedure in the Job Processor

As a first example of how to use a diagnostic application, the runtime system, here is the call of a multiple-ECU-jobs are considered. The application uses such as a call to the ExecuteSync MULTIPLE ECU job as an argument. The runtime system will, if not already done so, initialize the Java Virtual Machine. Then they will access the class file in which the actual job, the program code of the job is stored. This code is then run the appropriate diagnostic services to the runtime system and communicate with the controller. The runtime system receives the corresponding response from the control unit, processes it and returns the result back through a MCDResult object to the application.

Example procedure at JOB PROCESSOR

Typical program flow

A typical program sequence is as follows, shown at left: First you must initialize the MCD system. Then you charge a specific project. Thus, the record from the ODX database is loaded. Then, a vehicle is, so type model year, then opened and a logical link. Now the diagnostic services are created and executed. The results are typically processed in a loop and in the end the whole object structure cleaned up. In the figure on the right you will find the reduced program code for the above example.

Schematic Programming sequence

Development of diagnostic applications

The previously described standards for the description of the diagnostic data and a diagnostic run time system are certainly a step in the right direction and in light of the growing complexity in automotive diagnostics to replace. However, this is only one side of the coin. Modern vehicle diagnostics is not only composed of individual services, but many thousands of processes associated with the server and MVCI ODX not be mapped.

OTX-designer of the company emotive GmbH

This closes the gap in the ISO 13209 standard exchange formats for diagnostic sequences OTX, on which is received in the next chapter.