ISO 14229-1:2006

Road vehicles - Unified diagnostic services (UDS) - Part 1: Specification and requirements

ISO 14229:2006 specifies data link independent requirements of diagnostic services, which allow a diagnostic tester (client) to control diagnostic functions in an on-vehicle Electronic Control Unit (server) such as an electronic fuel injection, automatic gear box, anti-lock braking system, etc. connected on a serial data link embedded in a road vehicle. It specifies generic services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission on the data link. ISO 14229:2006 does not apply to non-diagnostic message transmission, or to use of the communication data link between two Electronic Control Units. It does not specify any implementation requirements. The vehicle diagnostic architecture of ISO 14229:2006 applies to a single tester (client) that may be temporarily or permanently connected to the on-vehicle diagnostic data link and several on-vehicle Electronic Control Units (servers) connected directly or indirectly.

Véhicules routiers — Services de diagnostic unifiés (SDU) — Partie 1: Spécification et exigences

General Information

• Status: Withdrawn
• Publication Date: 27-Nov-2006
• Withdrawal Date: 27-Nov-2006
• ICS: 43.180 - Diagnostic, maintenance and test equipment
• Technical Committee: ISO/TC 22 - Road vehicles
• Drafting Committee: ISO/TC 22 - Road vehicles
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 15-Mar-2013
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 14229-1:2013 - Road vehicles - Unified diagnostic services (UDS) - Part 1: Specification and requirements
• Effective Date: 26-Sep-2009
• Revises: ISO 14229:1998 - Road vehicles - Diagnostic systems - Diagnostic services specification
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 14229-1
First edition
2006-12-01
Corrected version
2007-04-15
Road vehicles — Unified diagnostic
services (UDS) —
Part 1:
Specification and requirements
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 1:
Spécification et exigences
Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2006
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 [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2006 – All rights reserved

Contents Page
Foreword. v
Introduction . vi
1 Scope . 1
2 Normative references . 2
3 Terms and definitions. 3
4 Symbols and abbreviated terms . 5
5 Conventions . 5
6 Application layer services . 6
6.1 General. 6
6.2 Format description of application layer services. 8
6.3 Format description of standard service primitives . 8
6.4 Format description of remote service primitives . 10
6.5 Service data unit specification . 13
7 Application layer protocol . 19
7.1 General definition . 19
7.2 Protocol data unit specification . 19
7.3 Application protocol control information. 19
7.4 Negative response/confirmation service primitive . 21
7.5 Server response implementation rules .22
8 Service description conventions . 29
8.1 Service description. 29
8.2 Request message . 30
8.3 Positive response message. 32
8.4 Supported negative response codes (NRC_) . 34
8.5 Message flow examples . 34
9 Diagnostic and communication management functional unit . 36
9.1 Overview . 36
9.2 DiagnosticSessionControl (10 hex) service. 36
9.3 ECUReset (11 hex) service . 42
9.4 SecurityAccess (27 hex) service . 45
9.5 CommunicationControl (28 hex) service. 52
9.6 TesterPresent (3E hex) service . 55
9.7 AccessTimingParameter (83 hex) service. 58
9.8 SecuredDataTransmission (84 hex) service . 63
9.9 ControlDTCSetting (85 hex) service . 69
9.10 ResponseOnEvent (86 hex) service. 73
9.11 LinkControl (87 hex) service. 91
10 Data transmission functional unit. 97
10.1 Overview . 97
10.2 ReadDataByIdentifier (22 hex) service . 97
10.3 ReadMemoryByAddress (23 hex) service . 102
10.4 ReadScalingDataByIdentifier (24 hex) service . 106
10.5 ReadDataByPeriodicIdentifier (2A hex) service . 112
10.6 DynamicallyDefineDataIdentifier (2C hex) service . 123
10.7 WriteDataByIdentifier (2E hex) service. 143
10.8 WriteMemoryByAddress (3D hex) service . 146
11 Stored data transmission functional unit . 152
11.1 Overview . 152
11.2 ClearDiagnosticInformation (14 hex) service. 152
11.3 ReadDTCInformation (19 hex) service . 154
12 InputOutput control functional unit. 208
12.1 Overview . 208
12.2 InputOutputControlByIdentifier (2F hex) service. 209
13 Remote activation of routine functional unit. 224
13.1 Overview . 224
13.2 RoutineControl (31 hex) service. 225
14 Upload download functional unit . 231
14.1 Overview . 231
14.2 RequestDownload (34 hex) service. 231
14.3 RequestUpload (35 hex) service. 234
14.4 TransferData (36 hex) service. 237
14.5 RequestTransferExit (37 hex) service. 242
Annex A (informative) Global parameter definitions. 250
Annex B (normative) Diagnostic and communication management functional unit data parameter
definitions . 257
Annex C (normative) Data transmission functional unit data parameter definitions. 259
Annex D (normative) Stored data transmission functional unit data parameter definitions. 272
Annex E (normative) Input output control functional unit data parameter definitions. 289
Annex F (normative) Remote activation of routine functional unit data parameter definitions. 290
Annex G (informative) Examples for addressAndLengthFormatIdentifier parameter values . 291
Bibliography . 293

iv © ISO 2006 – 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 14229-1 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
This first edition of ISO 14229-1 cancels and replaces ISO 14229:1998, which has been technically revised.
ISO 14229 consists of the following parts, under the general title Road vehicles — Unified diagnostic services
(UDS):
⎯ Part 1: Specification and requirements
The following part is under preparation:
⎯ Part 2: Session layer services
This corrected version of ISO 14229-1:2006 incorporates the following corrections:
⎯ the document reference number, title and edition have been changed from “ISO 14229:2006, Road
vehicles — Unified diagnostic services (UDS) — Specification and requirements, Second edition” to
“ISO 14229-1:2006, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and
requirements, First edition” throughout the document;
⎯ mention of "Part 2: Lager services" has been added to the Foreword.
Introduction
This part of ISO 14229 has been established in order to define common requirements for diagnostic systems,
whatever the serial data link is.
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance
with ISO 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers. When
mapped on this model, the services used by a diagnostic tester (client) and an Electronic Control Unit (ECU,
server) are broken into:
⎯ unified diagnostic services (layer 7); and
⎯ communication services (layers 1 to 6).
NOTE The diagnostic services in this part of ISO 14229 are implemented in various applications, e.g. ISO 16844 (all
parts), ISO 11992 (all parts), ISO 9141 (all parts), ISO 14230 (all parts), etc. Future modifications to this part of ISO 14229
will provide long-term backward compatibility with the implementation standards as described above.
Table 1 — Example of diagnostic/programming specifications applicable to the OSI layers
Applicability OSI layer Enhanced diagnostics services (non-emissions-related)
Application (layer 7) ISO 14229-1/ISO 15765-3/ISO 11992-4 ISO 14229-1/further standards
Presentation (layer 6) — —
Seven layers
Session (layer 5) ISO 15765-3/ISO 11992-4 further standards
according to
ISO/IEC 7498-1
Transport (layer 4) ISO 15765-2/ISO 11992-4 further standards
and
Network (layer 3) ISO 15765-2/ISO 11992-4 further standards
ISO/IEC 10731
Data link (layer 2) ISO 11898/ISO 11992-1/SAE J1939-15 further standards
Physical (layer 1) ISO 11898/ISO 11992-1/SAE J1939-15 further standards

Figure 1 shows an example of the possible future implementation of this part of ISO 14229 onto various data
links.
Figure 1 — Available International Standards and possible future implementations of this part of
ISO 14229
vi © ISO 2006 – All rights reserved

INTERNATIONAL STANDARD ISO 14229-1:2006(E)

Road vehicles — Unified diagnostic services (UDS) —
Specification and requirements
Part 1:
Specification and requirements
1 Scope
This part of ISO 14229 specifies data link independent requirements of diagnostic services, which allow a
diagnostic tester (client) to control diagnostic functions in an on-vehicle Electronic Control Unit (server) such
as an electronic fuel injection, automatic gear box, anti-lock braking system, etc. connected on a serial data
link embedded in a road vehicle. It specifies generic services which allow the diagnostic tester (client) to stop
or to resume non-diagnostic message transmission on the data link. This part of ISO 14229 does not apply to
non-diagnostic message transmission or to use of the communication data link between two Electronic Control
Units. It does not specify any implementation requirements.
The vehicle diagnostic architecture of this part of ISO 14229 applies to:
⎯ a single tester (client) that may be temporarily or permanently connected to the on-vehicle diagnostic data
link; and
⎯ several on-vehicle Electronic Control Units (servers) connected directly or indirectly.

Figure 2 — Vehicle diagnostic architecture
In Figure 2:
⎯ For vehicle 1, the servers are connected over an internal data link and indirectly connected to the
diagnostic data link through a gateway. This part of ISO 14229 applies to the diagnostic communications
over the diagnostic data link; the diagnostic communications over the internal data link may conform to
this part of ISO 14229 or to another protocol.
⎯ For vehicle 2, the servers are directly connected to the diagnostic data link.
⎯ For vehicle 3, the servers are directly connected to the diagnostic data link through a gateway (same as
vehicle 2) and vehicle 4 connects its server/gateway directly to the vehicle 3 server/gateway.
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 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic
Model
ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model —
Conventions for the definition of OSI services
ISO 11898 (all parts), Road vehicles — Controller area network (CAN)
ISO 11992-1, Road vehicles — Interchange of digital information on electrical connections between towing
and towed vehicles — Part 1: Physical and data-link layers
ISO 11992-4, Road vehicles — Interchange of digital information on electrical connections between towing
and towed vehicles — Part 4: Diagnostics
ISO 14230 (all parts), Road vehicles — Diagnostic systems — Keyword Protocol 2000
ISO 15765-2, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 2: Network layer
services
ISO 15765-3, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 3: Implementation of
unified diagnostic services (UDS on CAN)
ISO/TR 15031-2, Road vehicles — Communication between vehicle and external equipment for emissions-
related diagnostics — Part 2: Terms, definitions, abbreviations and acronyms
ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for emissions-related
diagnostics — Part 5: Emissions-related diagnostic services
ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for emissions-related
diagnostics — Part 6: Diagnostic trouble code definitions
ISO 15031-7, Road vehicles — Communication between vehicle and external equipment for emissions-related
diagnostics — Part 7: Data link security
ISO 15764, Road vehicles — Extended data link security
2 © ISO 2006 – All rights reserved

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
integer type
simple type with distinguished values which are the positive and the negative whole numbers
NOTE The range of integer type is not specified within this document.
3.2
diagnostic trouble code
numerical common identifier for a fault condition identified by the on-board diagnostic system
3.3
diagnostic service
information exchange initiated by a client in order to require diagnostic information from a server and/or to
modify its behaviour for diagnostic purposes
3.4
client
function that is part of the tester and that makes use of the diagnostic services
NOTE A tester normally makes use of other functions such as database management, specific interpretation, human-
machine interface.
3.5
server
function that is part of an electronic control unit and that provides the diagnostic services
NOTE This part of ISO 14229 differentiates between the server (i.e. the function) and the electronic control unit so
that it remains independent from the implementation.
3.6
tester
system that controls functions such as test, inspection, monitoring or diagnosis of an on-vehicle electronic
control unit and which may be dedicated to a specific type of operator (e.g. a scan tool dedicated to garage
mechanics or a test tool dedicated to assembly plant agents)
NOTE The tester is also referenced as the client.
3.7
diagnostic data
data that is located in the memory of an electronic control unit which may be inspected and/or possibly
modified by the tester (diagnostic data includes analogue inputs and outputs, digital inputs and outputs,
intermediate values and various status information)
EXAMPLES Examples of diagnostic data include vehicle speed, throttle angle, mirror position, system status, etc.
Three types of values are defined for diagnostic data:
⎯ the current value: the value currently used by (or resulting from) the normal operation of the electronic control unit;
⎯ a stored value: an internal copy of the current value made at specific moments, e.g. when a malfunction occurs or
periodically (this copy is made under the control of the electronic control unit);
⎯ a static value: e.g. VIN; the server is not obliged to keep internal copies of its data for diagnostic purposes, in which
case the tester may only request the current value.
3.8
diagnostic session
current mode of the server, which affects the level of diagnostic functionality
NOTE Defining a repair shop or development testing session selects different server functionality (e.g. access to all
memory locations may only be allowed in the development testing session).
3.9
diagnostic routine
routine that is embedded in an electronic control unit and that may be started by a server upon a request from
the client
NOTE It could either run instead of a normal operating program or run concurrently to the normal operating program.
In the first case, normal operation of the ECU is not possible. In the second case, multiple diagnostic routines may be
enabled that run while all other parts of the electronic control unit are functioning normally.
3.10
record
one or more diagnostic data elements that are referred to together by a single means of identification
NOTE A snapshot including various input/output data and trouble codes is an example of a record.
3.11
security
as used in this part of ISO 14229, security access method that satisfies the requirements for tamper protection
as specified in ISO 15031-7
3.12
functional unit
set of functionally close or complementary diagnostic services
3.13
local server
server that is connected to the same local network as the client and is part of the same address space as the
client
3.14
local client
client that is connected to the same local network as the server and is part of the same address space as the
server
3.15
remote server
server that is not directly connected to the main diagnostic network
NOTE 1 A remote server is identified by means of a remote network address. Remote network addresses represent an
own network address space that is independent from the addresses on the main network.
NOTE 2 A remote server is reached via a local server on the main network. Each local server on the main network can
act as a gate to one independent set of remote servers. A pair of addresses will therefore always identify a remote server:
a local address that identifies the gate to the remote network and a remote address identifying the remote server itself.
3.16
remote client
client that is not directly connected to the main diagnostic network
NOTE A remote client is identified by means of a remote network address. Remote network addresses represent an
own address space that is independent from the addresses on the main network.
4 © ISO 2006 – All rights reserved

3.17
permanent DTC
stored in NVRAM and not erasable by any test equipment command or by disconnecting power to the
on-board computer
4 Symbols and abbreviated terms
A_PCI Application layer Protocol Control Information
A_PDU Application layer Protocol Data Unit
A_SDU Application layer Service Data Unit
ECU Electronic Control Unit
NOTE An ECU contains at least one server. Systems considered as Electronic Control Units include anti-lock braking
system (ABS), engine management system, etc.
NR_SI Negative Response Service Identifier
OBD On-Board Diagnostic
OSI Open Systems Interconnection
RA Remote Address
SA Source Address
SI Service Identifier
TA Target Address
TA_type Target Address type
5 Conventions
This part of ISO 14229 is guided by the conventions discussed in the OSI Service Conventions (ISO 10731)
as they apply to diagnostic services. These conventions specify the interactions between the service user and
the service provider. Information is passed between the service user and the service provider by service
primitives, which may convey parameters.
The distinction between service and protocol is summarized in Figure 3.
This part of ISO 14229 defines both, confirmed and unconfirmed services.
⎯ Confirmed services use the six (6) service primitives, request, req_confirm, indication, response,
rsp_confirm and confirmation.
⎯ Unconfirmed services use only the request, req_confirm and indication service primitives.
For all services defined in this part of ISO 14229, the request and indication service primitives always have the
same format and parameters. Consequently, for all services the response and confirmation service primitives
(except req_confirm and rsp_confirm) always have the same format and parameters. When the service
primitives are defined in this part of ISO 14229, only the request and response service primitives are listed.
Figure 3 — The services and the protocol
6 Application layer services
6.1 General
Application layer services are usually referred to as diagnostic services. The application layer services are
used in client-server-based systems to perform functions such as test, inspection, monitoring or diagnosis of
on-board vehicle servers. The client, usually referred to as an External Test Equipment, uses the application
layer services to request diagnostic functions to be performed in one or more servers. The server, usually a
function that is part of an ECU, uses the application layer services to send response data, provided by the
requested diagnostic service, back to the client. The client is usually an off-board tester but can, in some
systems, also be an on-board tester. The usage of application layer services is independent from the client
being an off-board or on-board tester. It is possible to have more than one client in the same vehicle system.
The service access point of the diagnostics application layer provides a number of services that all have the
same general structure. For each service, six (6) service primitives are specified:
⎯ a service request primitive, used by the client function in the diagnostic tester application to pass data
about a requested diagnostic service to the diagnostics application layer;
⎯ a service request-confirmation primitive, used by the client function in the diagnostic tester application
to indicate that the data passed in the service request primitive is completely transferred to the server;
⎯ a service indication primitive, used by the diagnostics application layer to pass data to the server
function of the ECU diagnostic application;
⎯ a service response primitive, used by the server function in the ECU diagnostic application to pass
response data provided by the requested diagnostic service to the diagnostics application layer;
6 © ISO 2006 – All rights reserved

⎯ a service response-confirmation primitive, used by the server function in the ECU diagnostic
application to indicate that the data passed in the service response primitive is completely transferred to
the client;
⎯ a service confirmation primitive, used by the diagnostics application layer to pass data to the client
function in the diagnostic tester application.

Figure 4 — Application layer service primitives — confirmed service

Figure 5 — Application layer service primitives — unconfirmed service
For a given service, the request primitive and the indication primitive always have the same service data unit.
This part of ISO 14229 will only list and specify the parameters of the service data unit belonging to each
service request primitive. The user shall assume exactly the same parameters for each corresponding service
indication primitive.
For a given service, the response primitive and the confirmation primitive always have the same service data
unit. This part of ISO 14229 only lists and specifies the parameters of the service data unit belonging to each
service response primitive. The user shall assume exactly the same parameters for each corresponding
service confirmation primitive.
For each service response primitive (and corresponding service confirmation primitive), two different service
data units (two sets of parameters) will be specified. One set of parameters shall be used in a positive service
response primitive if the requested diagnostic service can be successfully performed by the server function in
the ECU diagnostic application. The other set of parameters (the negative response service data unit) shall be
used if the requested diagnostic service fails or cannot be completed in time by the server function in the ECU
diagnostic application.
For a given service, the request-confirmation primitive and the response-confirmation primitive always have
the same service data unit. The purpose of these service primitives is to indicate the completion of an earlier
request or response service primitive invocation. The service descriptions in this part of ISO 14229 do not
make use of those service primitives, but the data link specific implementation documents might use them to
define e.g. service execution reference points (e.g. the ECUReset service would reset the ECU after the
response has been completely transmitted to the client, which is indicated in the server by the service
response-confirm primitive).
6.2 Format description of application layer services
Application layer services can have two different formats depending on how the vehicle diagnostic system is
configured.
If the vehicle system is configured as a single (one logical) diagnostic network where all clients and servers
are connected directly, then the default (also called normal or standard) format of application layer services
shall be used. This format is compatible with the diagnostic system formats used on data links such as K- and
L-lines. The default application layer services format is specified in 6.3.
The remote format of application layer services shall be used in vehicle systems implementing the concept of
local servers and remote servers. The remote format has one additional address parameter called remote
address. The remote format is used to access servers that are not directly connected to the main diagnostic
network in the vehicle. The remote format for application layer services is specified in 6.4.
6.3 Format description of standard service primitives
6.3.1 General definition
All application layer services have the same general format. Service primitives are written in the form:
service_name.type (
parameter A, parameter B, parameter C
[,parameter 1, .]
)
where:
⎯ “service_name” is the name of the diagnostic service (e.g. DiagnosticSessionControl);
⎯ “type” indicates the type of the service primitive (e.g. request);
⎯ “parameter A, .” is the A_SDU as a list of values passed by the service primitive (addressing
information);
⎯ “parameter A, parameter B, parameter C” are mandatory parameters that shall be included in all service
calls;
⎯ “[,parameter 1, .]” are parameters that depend on the specific service (e.g. parameter 1 can be the
diagnosticSession for the DiagnosticSessionControl service). The brackets indicate that this part of the
parameter list may be empty.
8 © ISO 2006 – All rights reserved

6.3.2 Service request and service indication primitives
For each application layer service, service request and service indication primitives are specified according to
the following general format:
service_name.request (
SA,
TA,
TA_type
[,parameter 1, .]
)
The request primitive is used by the client function in the diagnostic tester application to initiate the service
and pass data about the requested diagnostic service to the application layer.
service_name.indication (
SA,
TA,
TA_type
[,parameter 1, .]
)
The indication primitive is used by the application layer to indicate an internal event which is significant to the
ECU diagnostic application and to pass data about the requested diagnostic service to the server function of
the ECU diagnostic application.
The request and indication primitives of a specific application layer service always have the same parameters
and parameter values. This means that the values of individual parameters shall not be changed by the
communicating peer protocol entities of the application layer when the data is transmitted from the client to the
server. The same values that are passed by the client function in the client application to the application layer
in the service request call shall be received by the server function of the diagnostic application from the
service indication of the peer application layer.
6.3.3 Service response and service confirm primitives
For each confirmed application layer service, service response and service confirm primitives are specified
according to the following general format:
service_name.response (
SA,
TA,
TA_type,
Result
[,parameter 1, .]
)
The response primitive is used by the server function in the ECU diagnostic application, to initiate the service
and pass response data provided by the requested diagnostic service to the application layer.
service_name.confirm (
SA,
TA,
TA_type,
Result
[,parameter 1, .]
)
The confirm primitive is used by the application layer to indicate an internal event which is significant to the
client application and to pass results of an associated previous service request to the client function in the
diagnostic tester application. It does not necessarily indicate any activity at the remote peer interface, e.g. if
the requested service is not supported by the server or if the communication is broken.
The response and confirm primitives of a specific application layer service always have the same parameters
and parameter values. This means that the values of individual parameters shall not be changed by the
communicating peer protocol entities of the application layer when the data is transmitted from the server to
the client. The same values that are passed by the server function of the ECU diagnostic application to the
application layer in the service response call shall be received by the client function in the diagnostic tester
application from the service confirmation of the peer application layer.
For each response and confirm primitive two different service data units (two sets of parameters) will be
specified.
⎯ A positive response and positive confirm primitive shall be used with the first service data unit if the
requested diagnostic service could be successfully performed by the server function in the ECU.
⎯ A negative response and confirm primitive shall be used with the second service data unit if the requested
diagnostic service failed or could not be completed in time by the server function in the ECU.
6.3.4 Service request-confirm and service response-confirm primitives
For each application layer service, service request-confirm and service response-confirm primitives are
specified according to the following general format:
service_name.req_confirm (
SA,
TA,
TA_type,
Result
)
The request-confirm primitive is used by the application layer to indicate an internal event, which is significant
to the client application, and pass results of an associated previous service request to the client function in the
diagnostic tester application.
service_name.rsp_confirm (
SA,
TA,
TA_type,
Result
)
The response-confirm primitive is used by the application layer to indicate an internal event, which is
significant to the server application, and pass results of an associated previous service response to the server
function in the ECU application.
6.4 Format description of remote service primitives
6.4.1 General definition
Diagnostic communication between a local client and a remote server can take place if the remote format of
application layer services is used. All definitions made for the default format of application layer services shall
be applicable also for the remote format of application layer services with the addition of one more addressing
parameter.
10 © ISO 2006 – All rights reserved

Diagnostic communication can take place between a local client on the main network and one or more remote
servers on a remote network. Communication can also take place between a remote client on a remote
network and one or more local servers on the main network.
Diagnostic communication cannot take place between any combination of clients and servers on two different
remote networks.
All remote format application layer services have the same general format. Service primitives are written in the
form:
service_name.type (
parameter A, parameter B, parameter C,
parameter D
[,parameter 1, .]
)
where:
⎯ “service_name” is the name of the diagnostic service (e.g. DiagnosticSessionControl);
⎯ “type” indicates the type of the service primitive (e.g. request);
⎯ “parameter A, .” is the A_SDU as a list of values passed by the service primitive (addressing
information);
⎯ “parameter A, parameter B, parameter C” are mandatory parameters that shall be included in all service
calls;
⎯ “parameter D” is an additional parameter that is only used in vehicles implementing the concept of remote
servers (remote address);
⎯ “[,parameter 1, .]” are parameters that depend on the specific service (e.g. parameter 1 can be the
diagnosticSession for the DiagnosticSessionControl service). The brackets indicate that this part of the
parameter list may be empty.
6.4.2 Remote service request and service indication primitives
For each remote format application layer service, service request and service indication primitives are
specified according to the following general format:
service_name.request (
SA,
TA,
TA_type
[,RA]
[,parameter 1, .]
)
The request primitive is used by the local client function in the client application, to initiate the service and
pass data about the requested diagnostic service to the application layer.
service_name.indication (
SA,
TA,
TA_type
[,RA]
[,parameter 1, .]
)
The indication primitive is used by the remote application layer to indicate an internal event which is significant
to the ECU diagnostic application and to pass data about the requested diagnostic service to the remote
server function of the ECU diagnostic application.
The request and indication primitive of a specific application layer service always have the same parameters
and parameter values. This means that the values of individual parameters shall not be changed by the
communicating peer protocol entities of the application layer when the data is transmitted from the client to the
server. The same values that are passed by the client function in the diagnostic tester application to the
application layer in the service request call shall be received by the server function of the ECU application
from the service indication of the peer application layer.
NOTE For clarity, the text assumes communication between a local client and one or more remote server. The
protocol also supports communication between a remote client and one or more local servers using the same remote
format application layer services.
6.4.3 Remote service response and service confirm primitives
For each remote format application layer service, service response and service confirm primitives are
specified according to the following general format:
service_name.response (
SA,
TA,
TA_type,
[RA,]
Result
[,parameter 1, .]
)
The response primitive is used by the remote server function in the ECU diagnostic application, to initiate the
service and pass response data provided by the requested diagnostic service to the application layer.
service_name.confirm (
SA,
TA,
TA_type,
[RA,]
Result
[,parameter 1, .]
)
The confirm primitive is used by the local application layer to indicate an internal event which is significant to
the client application and to pass results of an associated previous service request to the client function in the
ECU application. It does not necessarily indicate any activity at the remote peer interface, e.g. if the requested
service is not supported by the server or if the communication is broken.
The response and confirm primitive of a specific application layer service always has the same parameters
and parameter values. This means that the values of individual parameters shall not be changed by the
communicating peer protocol entities of the application layer when the data is transmitted from the server to
the client. The same values that are passed by the server function of the ECU diagnostic application to the
application layer in the service response call shall be received by the client function in the diagnostic tester
application from the service confirmation of the peer application layer.
For each response and confirm primitive, two different service data units (two sets of parameters) will be
specified.
⎯ A positive response and positive confirm primitive shall be used with the first service data unit if the
requested diagnostic service could be successfully performed by the server function in the ECU.
12 © ISO 2006 – All rights reserved

⎯ A negative response and confirm primitive shall be used with the second service data unit if the requested
diagnostic service fail
...