In this part of our seminar on diagnostic systems in cars, we will deal with applications for measurement, calibration and diagnostics. In view of the ISO / OSI layer model we are moving above the actual model on the level of applications.

Open System Interconnection (OSI) Schichtenmodell (ISO 1978)

Plays an important role in this field, ASAM (Association for Standardization of Automation and Measuring Systems). It was founded in 1991 as an initiative by car manufacturers in conjunction with their key suppliers. Meanwhile, ASAM has over 120 member companies, including all major vehicle manufacturers, their suppliers and a number of tool manufacturers. The organization aims to standards for the measurement and calibration, that is for application and diagnostics to create.

The area of ​​the ASAM standards can be divided into two broad themes:

The first is ACID AE - AE stands for Automotive Electronics. This is about the part of the application and diagnostic tools, which represent the actual interface to the vehicle. So essentially the bus protocols and the overlying layers, which communicates with and applied. The tools used for this purpose - the main group of these standards - run under the name of MCD (Measurement Calibration and Diagnosis).

In the following part of the seminar we will discuss in more detail and in particular the diagnosis relevant parts of ASAM AE.

The second major section comprises ACID CAT - CAT stands for Computer Aided Testing. This involves the control and automation of test rigs. This part is of minor importance.

Overview ASAM AE MCD D (MVCI)

The basic idea can be described best when we are on the following image the structure of a typical ASAM look at calibration and diagnostic system:

Overview MVCI server (ASAM AE MCD D)

At the top of the test and diagnostic applications are to be seen at the bottom of the ECU in the vehicle, connected via a bus system. The application system itself is a hardware, called the Vehicle Communication Interface, short VCI to the bus system and coupled to the vehicle. The interface to the bus interface is defined in the plane MCD 1st As for the bus interface is programming, inter alia, the D-PDU API (API = Application Programming Interface), which is standardized in ISO 22900-2.

Above that is a run-time system that should make the application and diagnosis of the underlying hardware independent. This runtime interface is standardized in ISO 22900 and is referred to as MVCI runtime system. Other terms for this are MVCI server, ASAM 3D server or just D-Server.

Relevant to the diagnosis of vehicles and control device-specific data are not part of the runtime system, but have been transferred to a database. The format of this database is described at the level MCD 2nd It is standardized in ISO 22901-1 and better known by its abbreviation: ODX (Open Data eXchange Diagnostics).

Above that is the ASAM MCD 3rd layer This is the programming interface through which the runtime system is programmed. This layer is commonly referred to as D-Server API.

Let's look at how a typical application or diagnostic application could run in the MCD system. It begins with the question that is made at the level of application, for example: "What is the current engine speed". Given the test and diagnosis application calls on the D-Server API MCD level 3 to a function with which this request is made on the test system. The test system now knows that it needs to send a bus messages to the control unit in the vehicle. It knows not yet what. Therefore it is looked up in the diagnostics database, like the short bus messages PDU (Protocol Data Unit) is to read the speed. This bus messages is described in the database and is returned to the runtime system. The runtime system again they are over the next 1 MCD interface (D-PDU API) to the bus interface. From the bus interface the message is then sent over the bus system as a diagnostic request to the controller. For the test area, it would be according to the application request. The controller responds with an appropriate response, which in turn is received by the vehicle interface and the MCD 1 layer extracted and prepared as a response message. Typically, the speed is returned as the ECU-specific hexadecimal value. The user would like to see the speed in revolutions per minute. It must thus making a conversion. How this conversion takes place, as the ECU-specific hexadecimal values ​​are converted to the physical speed value is, again in the database. Therefore, the received response message is implemented via the database and into a real physical speed converted and finally sent to the MCD 3 layer to the test and diagnostic application to the top.

We have covered so primarily to three different levels or areas of responsibility, the ASAM tried. The first is the bus interface to the bus system within the vehicle. This is the first layer MCD The idea of ​​using standardized interfaces various bus interfaces of different manufacturer and / or exchange is able to.

The second level relates to the data. The database of a vehicle model is composed of the individual records of the various control devices. These are usually provided by different suppliers and will be available throughout the entire life cycle of a vehicle consistent and reusable. In another part of the seminar will be discussed in detail on the standard used here ODX. MC for the area, so the application data format ASAP is second

The third level is the run-time system. Encapsulates all the runtime system for sending, receiving and converting the necessary algorithms. The corresponding API is the diagnostic application or applications to access the database and run-time functions.

We are in the following sections in greater detail to each level 1 to MCD MCD 3rd

Timeline

As we have previously seen the ASAM initiative has existed since the early 90s. So there is a correspondingly long history and a number of versions of the various protocol layers that have arisen more or less parallel and serial.

ASAM Timeline

Let's start with the application protocol CCP (CAN Calibration Protocol), developed in the early 90's, when CAN was used for the first time for the application. This is now at version 2.2. The designated successor to the CAN Calibration Protocol XCP (Extended Calibration Protocol), is now available in version 1.1. The interface to the bus system is not that old: The D-PDU API has been created in the second half of this decade.

For the on-board communication you have with ASAM also put up a specification rail. Under the heading FIBEX trying there, the bus messages, the signals and the topology of the on-board network to describe the vehicle. ASAP2 (A2L), there is now in version 1.6. The records for the diagnosis are a little younger. ODX here is now an ISO standard. In the programming level to the test application or application in MC was already standardized relatively early. For the diagnosis (MCD 3D) until this decade.