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 22900-3:2012(E)
©
ISO 2012

---------------------- Page: 1 ----------------------
ISO 22900-3:2012(E)

COPYRIGHT PROTECTED DOCUMENT


©  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

---------------------- Page: 2 ----------------------
ISO 22900-3:2012(E)
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
© ISO 2012 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 22900-3:2012(E)
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

---------------------- Page: 4 ----------------------
ISO 22900-3:2012(E)
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)
© ISO 2012 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 22900-3:2012(E)
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

---------------------- Page: 6 ----------------------
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
© ISO 2012 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO 22900-3:2012(E)
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

---------------------- Page: 8 ----------------------
ISO 22900-3:2012(E)
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.
© ISO 2012 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO 22900-3:2012(E)
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

---------------------- Page: 10 ----------------------
ISO 22900-3:2012(E)
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.
© ISO 2012 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO 22900-3:2012(E)
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

---------------------- Page: 12 ----------------------
ISO 22900-3:2012(E)
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”.
© ISO 2012 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO 22900-3:2012(E)
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 functionaliti
...