ISO 22900-3:2012

INTERNATIONAL ISO
STANDARD 22900-3
Second edition
2012-12-01
Road vehicles — Modular vehicle
communication interface (MVCI) —
Part 3:
Diagnostic server application
programming interface (D-Server API)
Véhicules routiers — Interface de communication modulaire du véhicule
(MVCI) —
Partie 3: Interface pour la programmation des applications du serveur
de diagnostic (D-Server API)
Reference number
©
ISO 2012
©  ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1  Scope . 1
2  Normative references . 1
3  Terms, definitions, symbols and abbreviated terms . 1
3.1  Terms and definitions . 1
3.2  Symbols . 3
3.3  Abbreviated terms . 4
4  Conventions . 5
4.1  General . 5
4.2  Typographical conventions and mnemonics . 5
4.3  Sequence diagrams . 6
4.4  Stereotypes . 6
5  Specification release version information . 6
6  Structure of a MVCI diagnostic server . 6
7  Diagnostic server . 10
7.1  MCD system object . 10
7.2  Description of terms . 11
7.3  Version information retrieval . 16
7.4  States of the MCD system . 16
7.5  State changes . 19
7.6  Project configuration . 19
7.7  Interface structure of server API . 21
7.8  Collections . 46
7.9  Registering/deregistering of the EventHandler . 50
7.10  MCD value . 51
7.11  Use cases . 54
8  Function block Diagnostic in detail . 60
8.1  Constraints . 60
8.2  System Properties . 70
8.3  Diagnostic DiagComPrimitives and Services . 71
8.4  Suppress positive response . 101
8.5  eEND_OF_PDU as RequestParameter . 102
8.6  Variable length parameters . 104
8.7  Variant identification . 106
8.8  Use cases . 117
8.9  Read DTC . 135
8.10  Logical Link . 144
8.11  Functional addressing . 156
8.12  Tables . 158
8.13  Dynamically Defined Identifiers (DynId) . 168
8.14  Internationalization . 179
8.15  Special Data Groups . 179
8.16  ECU (re-) programming . 181
8.17  Handling binary flash data . 188
8.18  Library. 190
8.19  Jobs . 191
8.20  ECU configuration . 212
8.21  Audiences and additional audiences . 229
8.22  ECU states . 231
8.23  Function dictionary . 234
8.24  Sub-Component data model description . 242
8.25  Monitoring vehicle bus traffic . 244
8.26  Support of VCI module selection and other VCI module features according to ISO 22900-2 . 246
8.27  Handling DoIP entities . 255
8.28  Mapping of D-PDU API methods . 258
9  Error Codes . 263
9.1  Principle . 263
9.2  Description of the errors . 265
Annex A (normative) Value reading and setting by string . 267
A.1  Datatype conversion into Unicode2 string . 267
A.2  Representation floating numbers . 267
A.3  Normalized floating-point numbers . 268
Annex B (normative) System parameter . 269
B.1  Overview . 269
B.2  Description of the system parameters . 270
Annex C (normative) Overview optional functionalities . 272
Annex D (informative) Monitoring message format . 278
D.1  General . 278
D.2  CAN format . 278
D.3  K-Line Format . 279
D.4  DoIP Format . 280
Bibliography . 281

iv © ISO 2012 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 22900-3 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
This second edition cancels and replaces the first edition (ISO 22900-3:2009), which has been technically
revised.
ISO 22900 consists of the following parts, under the general title Road vehicles — Modular vehicle
communication interface (MVCI):
 Part 1: Hardware design requirements
 Part 2: Diagnostic protocol data unit application programming interface (D-PDU API)
 Part 3: Diagnostic server application programming interface (D-Server API)
Introduction
0.1 Overview
This part of ISO 22900 has been established in order to define a universal application programmer interface of
a vehicle communication server application. Today's situation in the automotive market requires different
vehicle communication interfaces for different vehicle OEMs supporting multiple communication protocols.
However, until today, many vehicle communication interfaces are incompatible with regard to interoperability
with multiple communication applications and vehicle communication protocols.
Implementation of the MVCI diagnostic server concept supports overall cost reduction to the end user
because, for example, a single diagnostic or programming application will support many vehicle
communication interfaces supporting different communication protocols and different vehicle communication
modules of different vendors at one time.
A vehicle communication application compliant with this part of ISO 22900 supports a protocol independent D-
PDU API (Protocol Data Unit Application Programming Interface) as specified in ISO 22900-2. The server
application will need to be configured with vehicle- and ECU-specific information. This is accomplished by
supporting the ODX data format (Open Diagnostic Exchange format) as specified in ISO 22901-1.
A server compliant with this part of ISO 22900 supports the function block Diagnostics (D). A compliant server
also supports Job-Language (Java) and may support optional features like ECU (re)programming. The
defined object-oriented API provides for a simple, time saving and efficient interchangeability of different
servers.
The client application and the communication server do not necessarily need to run on the same computer. A
remote use via an interface may also be envisaged and is supported by the design of the server API. This
[10] [11]
interface is provided for ASAM GDI, COM/DCOM [Technology Reference COM-IDL], for C++
[12]
[Technology Reference C++] and for Java [Technology Reference Java].
0.2 ASAM e.V. implementation reference documents
This part of ISO 22900 references several ASAM e.V. documents which contain the Technology Reference
Mapping Rules for COM-IDL, C++ and Java.
The following ASAM documents are relevant for the implementation of this part of ISO 22900:
[10]
 ASAM Technology Reference COM-IDL, COM-IDL Technology Reference Mapping Rules :
this document describes the platform, programming language and linking mechanisms for the
implementation of the generic object model in COM-IDL.
[11]
 ASAM Technology Reference C++, C++ Technology Reference Mapping Rules :
this document describes the platform, programming language and linking mechanisms for the
implementation of the generic object model in C++.
[12]
 ASAM Technology Reference Java, Java Technology Reference Mapping Rules :
this document describes the platform, programming language and linking mechanisms for the
implementation of the generic object model in Java.
vi © ISO 2012 – All rights reserved

INTERNATIONAL STANDARD ISO 22900-3:2012(E)

Road vehicles — Modular vehicle communication interface
(MVCI) —
Part 3:
Diagnostic server application programming interface (D-Server
API)
1 Scope
This part of ISO 22900 focuses on the description of an object-oriented programming interface. The objective
is the ability to implement server applications, used during the design, production and maintenance phase of
a vehicle communication system, compatible to each other and thus exchangeable. From a user’s
perspective, access and integration of on-board control units is provided by a corresponding application, the
communication server and a VCI module for diagnostics. The user is granted access for the handling of
control units (ECUs) in vehicles for the diagnostic services.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 14229 (all parts), Road vehicles — Unified diagnostic services (UDS)
ISO 14230-3, Road vehicles — Diagnostic systems — Keyword protocol 2000
ISO 15765 (all parts), Road vehicles — Diagnostic communication over Controller Area Network (DoCAN)
ISO 22901-1, Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification
ISO 22900-2, Road vehicles — Modular vehicle communication interface (MVCI) —Part 2: Diagnostic protocol
data unit application programming interface (D-PDU API)
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
AccessKey
path identifier through the inheritance hierarchy as defined in ISO 22901-1 ODX to a diagnostic data element
3.1.2
ancestor object
parent object
located above in the object hierarchy with respect to a given object
3.1.3
descendant object
child object
object, located below in the object hierarchy with respect to a given object
3.1.4
FlashJob
new class derived from MCDJob which is used to start FlashSessions within the MVCI diagnostic server
NOTE This information is provided by the databases. At the runtime object it is possible to set the FlashSession that
has to be flashed by this service. Only one session can be set for one job. The application can access the priority defined
in the database for every FlashSession and sort the sessions according to this priority.
The job interface of flash jobs (MCDFlashJob) extends the job interface of normal diagnostic jobs (MCDSingleECUJob) by
a session object, i.e. its method prototype is extended as follows:
JobName(.,MCDDbFlashSession session)
3.1.5
FlashKey
unique identification for a flash session
3.1.6
FlashSessionClass
user-defined collection of FlashSessions, which can be used to separate FlashSessions for different tasks
(e.g. sessions for data, sessions for boot, or sessions for code and data)
3.1.7
FlashSession
smallest unit that can be flashed separately by the MVCI diagnostic server, and which may consist of several
data blocks
3.1.8
functional class
set of diagnostic services
3.1.9
function dictionary
hierarchical function catalog to organize external test equipment user interfaces (available at MCDDbProject):
 references to one or several ECUs and their diagnostic data content relevant for that function;
 references to services/jobs to make functions “executable”;
 definition of function input and output parameters with optional references to parameters of related
services
3.1.10
interface connector
connector at the vehicle’s end of the interface cable between the vehicle and the communication device
3.1.11
job
sequence of diagnostic services and other jobs with a control flow
2 © ISO 2012 – All rights reserved

3.1.12
location
set of diagnostic data valid on a given hierarchical level of inheritance according to ISO 22901-1 ODX
NOTE The following locations exist:
 Multiple ECU Job,
 Protocol,
 Functional Group,
 ECU Base Variant,
 ECU Variant.
3.1.13
Logical Link
set of data, identifying the physical line, the interface and protocol used for an ECU
3.1.14
physical interface link
physical connection between the VCI connector of a VCI and the interface connector
3.1.15
physical link
physical vehicle link connected to a physical interface link, so it is the connection from the interface of the
diagnostic server to the ECU in the vehicle
3.1.16
physical vehicle link
unique bus system in a vehicle, so it is the connection between the vehicle connector and the ECU
3.1.17
priority
term used by test systems to decide in which order the sessions have to be flashed
3.1.18
project
pool of diagnostic data
NOTE References between such data are resolvable inside this same project.
3.1.19
sub component
ECU sub functionality or components
EXAMPLE LIN-slaves (available at MCDDbLocation).
3.1.20
vehicle connector
connector on a vehicle providing access to the bus systems in the vehicle
3.2 Symbols
Figure 1 shows the legend of hierarchical models.
color print black/white print
blue black
white white
yellow grey
green dark grey
yellow grey
green dark grey
Figure 1 — Legend of hierarchical models
3.3 Abbreviated terms
API Application Programmers Interface
ASAM Association for Standardisation of Automation and Measuring Systems
ASCII American Standard for Character Information Interchange
AUSY AUtomation SYstem
CAN Controller Area Network
COM/DCOM Distributed Component Object Model
CORBA Common Object Request Broker Architecture
CRC Cyclic Redundancy Check
D Diagnostics
Diag Diagnostic
DLL Dynamic Link Library
DoCAN Diagnostic communication over CAN
DOP diagnostic Data Object Property
DoIP Diagnostic Over Internet Protocol
DTC Diagnostic Trouble Code
DTD Document Type Definition
DynID Dynamically Defined Identifiers
ECU Electronic Control Unit
ECU MEM Electronic Control Unit MEMory
ERD Entity Relationship Diagram
IDL Interface Description Language
4 © ISO 2012 – All rights reserved

JAVA RMI JAVA Remote Method Invocation
KWP KeyWord Protocol
LIN Local Interconnect Network
MCD Measurement Calibration Diagnostic
MDF Module Description File
MVCI Modular Vehicle Communication Interface
ODX Open Diagnostic data eXchange
OEM Original Equipment Manufacturer
PC Personal Computer
PDU Protocol Data Unit
SDG Special Data Groups
SI Système International d'unités
UDS Unified Diagnostic Services
UTC Coordinated Universal Time
VI Variant Identification
VIS Variant Identification and Selection
VIT VehicleInformationTable
XML eXtended Markup Language
4 Conventions
4.1 General
This part of ISO 22900 is based on the conventions discussed in the OSI Service Conventions
(ISO/IEC 10731:1994) as they apply for diagnostic services.
4.2 Typographical conventions and mnemonics
Normal text of the specification is presented like this.
Source code and technical artifacts within the text are presented like this.
Diagrams that denote interaction sequences, relationships or dependencies between interfaces are presented
using the Unified Modeling Language’s (UML) convention.
The name of each interface and each class defined by this part of ISO 22900 shall use the prefix of the
stereotype, e.g. “D”.
The leading letter of each method and each parameter is small.
The leading word of each method shall be a verb.
The letter “_” is not allowed in interface names, method names and parameter names, but it is allowed for
constants.
The leading letter of each constant is “e” and behind this the name is written in capital letters.
ODX element names are written in upper cases, e.g. SHORT-NAME. MVCI diagnostic server Names are
written in mixed fixed, e.g. MCDDbProject.
4.3 Sequence diagrams
With the help of Sequence Diagrams the interactive use of the API and the sequences for certain general
cases are presented in chronological order.
The sequence diagrams are oriented according to the presentation in UML and are structured as follows. The
chronological sequence arises while reading from top downwards. The commentary column, in which single
activities are commented, is placed at the left margin. Within the sequence diagram the Client application is
shown on the left; if necessary for the respective case, the EventHandler is shown there as well. The API
objects necessary for the respective case are located to the right of the Client (with or without EventHandler).
If necessary, the MVCI diagnostic server is presented at the right, outside.
Not all API objects possible for the respective instant of time are shown; instead, only those of relevance for
the respective case are shown. The thin line leading down vertically from the objects represents the life line,
the wider sections on it represent activities of the object.
The black horizontal arrows between the single objects, Client and MVCI diagnostic server represent the
actions necessary for the respective case. The object to which the arrow points at will execute the action. The
grey horizontal arrows represent the return of objects.
4.4 Stereotypes
Stereotypes are abbreviation characters which are used in MVCI diagnostic servers to mark the affiliation of
statements, interfaces and methods to one of the possible parts.
Table 1 defines the stereotypes which are used in MVCI diagnostic servers.
Table 1 — Stereotypes
Stereotype Usage of method and class is in following Function Blocks allowed
<> Measurement, Calibration and Diagnostic
<> Diagnosis
<> Methods with this stereotype can only be used inside of Diagnostic Job. These methods are not
available for use at the API.
5 Specification release version information
The specification release version of this part of ISO 22900 is: 3.0.0.
6 Structure of a MVCI diagnostic server
Each server is divided into the functional block "D" (Diagnostic) and the database.
6 © ISO 2012 – All rights reserved

Figure 2 shows the architecture of an MVCI diagnostic server.
Client Application
Communication Services
GDI, COM/DCOM, Java RMI, C++
Communication Services
MCD-3 D Object Model
Job Processor
Flash Data Processor
Database
(ODX)
Data Processor
Job
Communication Processor
Job
XYZ
ABC
D-PDU API
D-PDU API
MVCI
Protocol Module
Software
any
diagnosis protocol
ECU
ECU
ECU
Figure 2 — Architecture of an MVCI diagnostic server
With the help of a server the control units are optimally adapted to the relevant requirements for their use in
vehicles. This procedure is often referred to as “Applying”.
The following features (interfaces and methods) are optional:
 MCDDbProjectConfiguration,
 ECU Configuration,
 ECU Reprogramming (Flash),
 DynID,
 Monitoring,
 System properties,
 Function dictionary,
 SubComponents,
 Audiences,
 ECU state,
 Multiple ECU Jobs,
 PDU Time stamps,
 Library concept,
 DoIP,
 PDU API support,
 the concept of System generated Vehicle Information table.
Optional means that the runtime, as well as the database part of the model, do not have to be implemented by
a diagnostic server that is omitting the feature in question. When a client application calls a method that is part
of an optional feature, the diagnostic server should return an empty collection if the return type of the method
is inheriting from MCDCollection. Otherwise, such a method call should throw an MCDSystemException
of type eSYSTEM_METHOD_NOT_SUPPORTED. In the case of support of optional features these have to be
implemented completely. An overview of methods which belong to optional functionalities can be found in
Annex C.
The number of control units applied in vehicles is continuously increasing. The capabilities of the single control
unit concerning diagnosis become available for the server by means of control unit description files (Data
Description Interface). The control unit description files represent a manufacturer independent data exchange
format, which means that any server may handle the data out of a control unit description file. All configuration
data of the diagnostic server, the internal data of ECUs or ECU nets and the communication methods for the
ECU access are stored in the ODX database. This database is server and operating system independent and
therefore allows data to be exchanged between vehicle manufacturers and ECU suppliers.
An application can read out all data from the database that is necessary to drive the MVCI diagnostic server;
this means only the MVCI diagnostic server can access the information of the separate control unit description
files comprised within one database. With this, at the same time the consistency of the information between
AUSY and MVCI diagnostic server is guaranteed.
Also, a decoupling from the used data description exchange format (XML) takes place.
8 © ISO 2012 – All rights reserved

The MVCI diagnostic server has to manage the database and to provide the required and necessary
information for the single MVCI diagnostic server objects. The database does not belong to one specific MVCI
diagnostic server object, but is available within the whole diagnostic server. The organization of the object or
reference allocation is solved implementation specifically by the diagnostic server.
The object model supports Single Client Systems, to provide for a simple use for this most typical and most
frequently occurring application case. This means that no client references are included within the single
objects. The administration of the client references is done by the diagnostic server and has to be solved
implementation specifically.
The object model has been designed in a technology and programming language independent way. It may be
used remotely as well as locally.
The object model of MVCI diagnostic server enables the linking of MVCI diagnostic servers to automation
systems. The objective of this linking is the remote control of the MVCI diagnostic server in test stands. By
means of the object model, the functionality, which means the interfaces with accompanying methods, are
standardized. The communication has to be realized via the particular implementation of the object model for
the used platform, programming language and linking mechanisms.
Among others the following are realized:
 ASAM GDI,
 JAVA,
 COM/DCOM and
 C++.
The necessary specifications for this will be described and published in separate documents. For this process
design patterns and mapping rules are defined and published.
All other specifications will be set up and realized implementation specifically by the respective system
provider.
Within the function block diagnostic a breaking down into characteristic sub tasks will take place, which are
shown in the following:
The Communication Processor is responsible for generating and analysing request and response telegrams
to ECUs. This processor handles all protocol-specific tasks like timings, creation of protocol headers and
checksums, etc. Diagnostic protocol specification is (at the moment) not a task of ASAM, because this is
covered by ISO activities according to ISO 14230-3 KWP 2000, ISO 14229 UDS and ISO 15765 DoCAN.
Nevertheless, the communication processor shall be parameterized via Communication Parameters. The
Communication Processor is an interface (the only one) to the ECU.
The Data Processor is responsible for the supply of parameters and results on a physical level. By means of
the Data Processor all necessary information is fetched from the database. Additionally, the Data Processor
converts ECU answers from hexadecimal representation into a physical or any text representation and vice
versa. The Data Processor is an interface (the only one) to the ODX database and offers an ODX library to the
Job Processor. The Data processor also handles Jobs, as they are stored in the ODX database.
The Flash Data Processor is responsible for the loading of programs and data in ECUs. The flash data is
part of the database. The Flash Data Processor provides access to the ASAM MCD2-ECU-MEM which
contains all information about physical/logical data-/code-layout and possible combinations of data and code
segments and more. The Flash Data Processor is an interface (the only one) to the flash data and offers a
flash library (flash object) to the Job Processor.
The Job Processor is responsible for the execution of service sequences and only uses objects of the ASAM
MVCI diagnostic server API. Via the Job Processor all processors may be accessed. The Jobs are part of the
database. The Job Processor is based on the ODX format. The Job Processor provides several libraries for
standardized access to the Communication Processor, Data Processor, Flash Data Processor and to the Job
Processor itself. The Job Processor uses the same objects to interact with the different Processors like the
ASAM MVCI diagnostic server API to insure consistency between ASAM MVCI diagnostic server API and Job
Processor. The Job Processor gets its code to be executed from the Data Processor. The Data Processor
itself reads the ODX database file.
7 Diagnostic server
7.1 MCD system object
The server interface is a client’s first access point to the MVCI diagnostic server. From this every interface is
reachable. Each client gets its own MCDSystem object (implements the MCDSystem interface) from the
MVCI diagnostic server. But all clients work on the same project and database. The project has the
connection to a special part of the whole database and this part will be made available after selecting the
project. The selection of another project at the same time is not allowed and will throw an exception.
Figure 3 shows the system scheduling.
Client
MCDSystem
MCDDbProject
Selected
MCDProject
Job Processor
Flash Data Processor
Data Processor
Communication Processor
MVCI diagnostic server
Figure 3 — System scheduling
10 © ISO 2012 – All rights reserved

The diagrams specified in this part of ISO 22900 always refer to the representation within the client and are
not designed for MultiClient scenarios.
7.2 Description of terms
7.2.1 General
This section describes the most important terms in more detail. A brief definition is included in 3.1. For each
term which is directly related to an ISO 22901-1 ODX element, the corresponding ODX element name is given
in parentheses.
7.2.2 Access key (AccessKey)
By means of the AccessKey, the access position within the inheritance hierarchy of the ODX diag layers is
identified.
One AccessKey element is composed of the type information [ElementIdentifier] embedded in square
brackets followed by the short name of the element instance. That is, the AccessKey is a sequence of tuples
of ElementIdentifier and short name. The allowed combinations of ElementIdentifiers are defined by the
Locations. AccessKeys are unique within one database.
Table 2 defines the ElementIdentifiers.
Table 2 — ElementIdentifiers
ElementIdentifiers
[MultipleEcuJob]
[Protocol]
[FunctionalGroup]
[EcuBaseVariant]
[EcuVariant]
For every element accessed via an AccessKey there is a LongName and a Description. LongName and
Description shall be in UNICODE.
7.2.3 Functional Class (FUNCTIONAL-CLASS)
Functional classes are groups of services (freely definable). A service can be part of multiple functional
classes but can have only one semantics. A functional class is an arbitrary, user definable group of services.
7.2.4 Job (SINGLE-ECU-JOB, MULTIPLE-ECU-JOB)
Sequence of diagnostic services and other jobs with control flow inside job, based on received results. Use
cases for jobs are ECU (re)programming, Encryption of seed key algorithm and gateway tests.
7.2.5 Location
A Location represents a hierarchical level for diagnostic Services.
The following locations are permitted:
 [D] Multiple ECU Job,
 [D] Protocol,
 [D] Functional Group,
 [D] ECU Base Variant,
 [D] ECU Variant.
The location is the access point to data base specific definitions (meta information) , e.g. available Services,
DiagComPrimitives, CompuMethods.
Figure 4 shows the location hierarchy of ASAM MCD database.
[Protocol] [MultipleECUJob]
[FunctionalGroup] [ECUBaseVariant]
[ECUVariant]
Figure 4 — Location hierarchy of ASAM MCD database
Each Location is addressed by means of an AccesKey. The following AccessKeys of possible Locations in the
hierarchical system are allowed:
12 © ISO 2012 – All rights reserved

 [Protocol]Instancename
 [Protocol]Instancename.[FunctionalGroup]Instancename
 [Protocol]Instancename.[EcuBaseVariant]Instancename
 [Protocol]Instancename.[EcuBaseVariant]Instancename.[EcuVariant]Instancename
 [MultipleEcuJob]MultipleECUJob
Figure 5 shows the AccessKey example.
UDS KWP2000
Protocol
FlashProgramming
InteriorBus
Functional Group
InteriorLight
DoorLeft
DoorLeftStep1 DoorLeftStep2
ECU BaseVariant
Figure 5 — AccessKey example
Resulting AccessKeys:
 [Protocol]UDS,
 [Protocol]UDS.[FunctionalGroup]InteriorBus,
 [Protocol]UDS.[FunctionalGroup]FlashProgramming,
 [Protocol]UDS.[EcuBaseVariant]DoorLeft,
 [Protocol]UDS.[EcuBaseVariant]DoorLeft.[EcuVariant]DoorLeftStep1,
 [Protocol]UDS.[EcuBaseVariant]DoorLeft.[EcuVariant]DoorLeftStep2,
 [Protocol]UDS.[EcuBaseVariant]InteriorLight,
 [Protocol]KWP2000.[EcuBaseVariant]InteriorLight,
 [Protocol]KWP2000;
7.2.6 Logical Link (LOGICAL-LINK)
A Logical Link is a logical connection to ECUs. Normally this is only one ECU, but in cases of a Functional
Group it can be more than one ECU. The Logical Link is represented by a short name. Information about a
Logical Link is contained in the Logical Link Table. Elements of this table are the AccessKey and the Physical
Vehicle Link or Interface. Logical Links are used to access the same ECU on different ways, or access more
than one ECU instance on different links. For more details see Clause 8.
7.2.7 Physical Interface Link
A Physical Interface Link is a logical connection between MVCI diagnostic server and Interface Connector.
The Physical Interface Link is represented by a short name. Information about a Physical Interface Link is
contained in the Interface Connector Information Table. In this table the description of the Interface connector
is included. The available Physical interface links are defined by the available interfaces of a MVCI diagnostic
server.
The Interface Connector Information Table has an entry for each Physical Interface Link and one connector
for this Link.
The Interface Connector Information Table uses the standardized short name of a Physical Link.
14 © ISO 2012 – All rights reserved

7.2.8 Physical Link
A physical Link is a Physical Vehicle Link connected to a Physical Interface Link, so it is the connection from
the interface of the MVCI diagnostic server to the ECU in the vehicle.
Figure 6 shows the overall scheme between different links and tables in D.
Vehicle Information
Table
MVCI diagnostic server API
Vehicle
Logical
MVCI diagnostic server
Connector
Link
D-PDU API
Information
MVCI MVCI
Table
Table
Protocol Protocol
Module A Module B
Protocol
Module
Interface
Connector
Connector
Information CAN HI
MVCI
Table
Protocol
CAN LO
Module
Connector
Pin
KLine 1
Accesskey
ECU
KLine 2
Vehicle
Physical Link
Connector
Interface
Physical Interface Link
Connector
Physical
VehicleLink
Interface Connector Pin
Figure 6 — Overall scheme between different links and tables in D
The pins of the Vehicle Connector are connected to identical pins of the Interface connector.
7.2.9 Physical Vehicle Link (PHYSICAL-VEHICLE-LINK)
The physical vehicle link describes the unique bus system in a vehicle, so it is the connection between the
vehicle connector and the ECU. The physical vehicle link is represented by a short name. Information about a
vehicle link is contained in the Vehicle Connector Information Table. In this table the Vehicle Connector
Information is included.
The Vehicle Connector Information Table has an entry for each Physical Vehicle Link and one or more Vehicle
Connectors (Pins) for this Link.
The available Physical vehicle links are defined by the vehicle.
7.2.10 Project
A project is a logical grouping for defined test installations selected by the user. Within a project, all
information necessary for a test installation has to be contained. It is only permitted to work within one project,
which has to be considered for the logical grouping (e.g. two model series within one project). It is for this
reason that the project tuple is not part of the AccessKey.
At project level, the forming of manufacturer-specific hierarchies is possible, as for this level no
standardization takes place.
Typically, a project contains:
~
~
~
~
 all static database information (Diagnosis Services, .),
 jobs,
 flash containers, and
 configuration files.
Within the MVCI diagnostic server, first the selection of a project out of the list of the existing projects takes
place, before any database information can be accessed. Because of this mechanism only one project can be
active.
The database of a project is not restricted to a physical file.
7.3 Version information retrieval
The method MCDSystem::getASAMMCDVersion():MCDVersion returns the ASAM release number
of the interface. For this specification it is the major value 3 and the minor value 0 defined.
MCDSystem::getVersion():MCDVersion returns the tool version.
The method
The technology version number is available via the interface
MCDSystem::getInterfaceNumber():A_UINT32.
The version number of the model (specification) and the version number of the reference implementations are
kept synchronous. The so-called “interface number (IFN)” is used as a build number for the reference
implementati
...