D-Server – ISO 22900-3

The introduction of ISO 22900-3 (ASAM MCD-3 D) was intended to define a universal programming interface for vehicle diagnostics across various applications. Vehicle diagnostics include, among other things, the following tasks:

• Reading the emissions-related data,
• Analysis of the error memory of individual control units,
• Configuration and calibration of control units,
• Software Update.

In the early days of vehicle diagnostics (late 1980s to mid-1990s), all of these scenarios were implemented using OEM-specific methods. As part of the standardization process, two key areas were standardized first: vehicle description (data base) and data transport (transport or protocol layer).

• The vehicle description has been standardized in ISO 22901-1 (ASAM MCD-2 D) using the newly introduced ODX format.
• Access to the protocol layer via a universal API has been standardized in ISO 22900-2.

The interface between the vehicle description and the transport layer is the D-server (also known as the MVCI server or MVCI kernel) introduced in ISO 22900-3.

The following diagram shows the simplified process by which an application can use the D-server to run a diagnostic service.

Access to the individual elements (vehicle types, control units, diagnostic services, and their parameters) is provided via the names of these elements as defined in the ODX specification. The application can access the individual request/response parameters directly. These are available not only as raw data but also as appropriately converted physical values, including units. The D-server performs the conversion based on the ODX data. A D-server can also be used to search and display ODX data without active communication with a vehicle. D-server objects are thus broadly divided into two groups: database objects and runtime objects.

Database objects are created from the ODX data and serve as templates. Runtime objects are created from the corresponding database templates, usually only when a connection to the D-PDU API exists. These objects are required for active communication with the control units.

Features

• Symbolic Access
• Supports automatic ECU variant detection and selection
• Auxiliary Classes for ECU Variant Coding
• Auxiliary Classes for flashing ECUs (software update)
• Reloadability of Flash Data and ECU Configuration Data
• Runtime system for executing complex processes/jobs (see below)
• Simultaneous Use of Multiple VCIs
• Parallel Communication with Multiple ECUs via a VCI
• Synchronous, asynchronous, cyclic, and repetitive diagnostic service execution
• Events
• Object-Oriented Programming Interface
• Error Handling by Intercepting Exceptions

In addition to the simple diagnostic services that can be mapped using a D-PDU API ComPrimitive, a D-Server offers the ability to group complex processes—such as flashing—into a so-called job. Most implementations allow users to describe such complex diagnostic processes in Java using the D-Server JNI. This approach is specified in ISO 22900-3. In this context, a D-server can use a Java Virtual Machine at runtime to interpret the Java jobs.

ISO 22900-3 (ASAM MCD-3 D) defines an object-oriented programming interface for vehicle diagnostics. The definition of the programming interface is vendor-neutral, so it can be implemented in any object-oriented programming language. It is typically implemented in Java and C++.