ISO 14229-2:2013

INTERNATIONAL ISO
STANDARD 14229-2
First edition
2013-02-15

Road vehicles— Unified diagnostic
services (UDS) —
Part 2:
Session layer services
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 2: Séquence des couches de services




Reference number
ISO 14229-2:2013(E)
©
ISO 2013

---------------------- Page: 1 ----------------------
ISO 14229-2:2013(E)

COPYRIGHT PROTECTED DOCUMENT


©  ISO 2013
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 2013 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 14229-2:2013(E)
Contents Page
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Conventions . 2
5 Document overview . 3
6 Session layer services . 4
6.1 General . 4
6.2 Specification of session layer service primitives . 6
6.3 Session data unit specification . 7
7 Timing parameter definition . 9
7.1 General application timing considerations. 9
7.2 Application timing parameter definitions – defaultSession . 10
7.3 Example for P4Server without enhanced response timing . 15
7.4 Example for P4Server with enhanced response timing . 16
7.5 Session timing parameter definitions for the non-default session . 17
7.6 Client and server timer resource requirements . 19
7.7 Error handling . 20
8 Timing handling during communication . 21
8.1 Physical communication . 21
8.2 Functional communication . 29
8.3 Minimum time between client request messages . 36
Annex A (normative) T_PDU interface . 43
Annex B (informative) Vehicle diagnostic OSI layer architecture examples . 44
B.1 Vehicle diagnostic OSI layer gateway example . 44
B.2 Vehicle diagnostic OSI layer CAN router example . 45
B.3 Vehicle diagnostic OSI layer CAN switch example . 46
Bibliography . 47

© ISO 2013 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 14229-2:2013(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 14229-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 14229 consists of the following parts, under the general title Road vehicles — Unified diagnostic services
(UDS):
 Part 1: Specification and requirements
 Part 2: Session layer services
 Part 3: Unified diagnostic services on CAN implementation (UDSonCAN)
 Part 4: Unified diagnostic services on FlexRay implementation (UDSonFR)
 Part 5: Unified diagnostic services on Internet Protocol implementation (UDSonIP)
 Part 6: Unified diagnostic services on K-Line implementation (UDSonK-Line)
The following part is under preparation:
 Part 7: Unified diagnostic services on Local Interconnect Network implementation (UDSonLIN)
The titles of future parts will be drafted as follows:
 Part n: Unified diagnostic services on … implementation (UDSon…)
iv © ISO 2013 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 14229-2:2013(E)
Introduction
ISO 14229 has been established in order to define common requirements for diagnostic systems that are
independent of the underlying serial data link.
To achieve this, ISO 14229 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 the following layers in accordance with Table 1:
 Application layer (layer 7), unified diagnostic services specified in ISO 14229-1, ISO 14229-3 UDSonCAN,
ISO 14229-4 UDSonFR, ISO 14229-5 UDSonIP, ISO 14229-6 UDSonK-Line, ISO 14229-7 UDSonLIN,
further standards and ISO 27145-3 WWH-OBD.
 Presentation layer (layer 6), vehicle manufacturer specific, ISO 27145-2 WWH-OBD.
 Session layer services (layer 5) specified in this part of ISO 14229.
 Transport layer services (layer 4), specified in ISO 15765-2 DoCAN, ISO 10681-2 Communication on
FlexRay, ISO 13400-2 DoIP, ISO 27145-4 WWH-OBD.
 Network layer services (layer 3), specified in ISO 15765-2 DoCAN, ISO 10681-2 Communication on
FlexRay, ISO 13400-2 DoIP, ISO 27145-4 WWH-OBD.
 Data link layer (layer 2), specified in ISO 11898-1, ISO 11898-2, ISO 17458-2, ISO 13400-3, IEEE 802.3,
ISO 14230-2 and further standards, ISO 27145-4 WWH-OBD.
 Physical layer (layer 1), specified in ISO 11898-1, ISO 11898-2, ISO 17458-4, ISO 13400-3, IEEE 802.3,
ISO 14230-1, further standards, ISO 27145-4 WWH-OBD.
Table 1 — Example of diagnostic/programming specifications applicable to the OSI layers
OSI seven WWH-OBD
Applicability Enhanced diagnostics services
layer
ISO 14229-1, ISO 14229-3 UDSonCAN, ISO 14229-4 UDSonFR, ISO
Application
ISO 14229-5 UDSonIP, ISO 14229-6 UDSonK-Line, ISO 14229-7 27145-3
(layer 7)
UDSonLIN, further standards
Presentation ISO
vehicle manufacturer specific
(layer 6) 27145-2
Seven layer
Session
ISO 14229-2
according to
(layer 5)
ISO/IEC
Transport further
7498-1
(layer 4) standards
and
ISO ISO ISO Not
ISO/IEC
15765-2 10681-2 13400-2 applicable
Network further
10731
(layer 3) standards
ISO
27145-4
Data link ISO ISO further
ISO ISO
(layer 2) 17458-2 14230-2 standards
11898-1, 13400-3,
ISO IEEE
Physical ISO ISO further
11898-2 802.3
(layer 1) 17458-4 14230-1 standards

© ISO 2013 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 14229-2:2013(E)

vi © ISO 2013 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 14229-2:2013(E)

Road vehicles — Unified diagnostic services (UDS) — Part 2:
Session layer services
1 Scope
This part of ISO 14229 specifies data link independent requirements of session layer services.
This part of ISO 14229 specifies common session layer services to provide independence between unified
diagnostic services (ISO 14229-1) and all transport protocols and network layer services (e.g. ISO 15765-2
DoCAN, ISO 10681-2 Communication on FlexRay, ISO 13400 DoIP, ISO 14230-2 DoK-Line, etc.)
This part of ISO 14229 specifies a common service primitive interface between OSI layer 4 (Transport) and
layer 5 (Session) via so-called service request/confirmation/indication primitives. This interface allows
seamless implementation of ISO 14229-1 Unified diagnostic services (UDS) with any communication protocol
titled "DoXYZ / CoXYZ" like ISO 15765 DoCAN – Diagnostic communication over Controller Area Network,
ISO 13400 DoIP, ISO 10681 Communication over FlexRay, ISO 14230 DoK-Line.
ISO 15031 (emissions-related OBD) and ISO 27145 (WWH-OBD) support the standardized service primitive
interface.
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-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
gateway
networking device that transfers the PDU on different OSI layers
EXAMPLE A network device that enables communication between control module networks that use different
communication protocols, different communication rates, etc. That includes, but is not limited to, gateway functionalities
like bridge, switch, router or application layer routing.
© ISO 2013 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO 14229-2:2013(E)
3.1.2
router
networking device that transfers the PDU on OSI layers 3 and 4
3.1.3
switch
networking device that transfers the PDU on OSI layer 2
3.2 Abbreviated terms
CDD common data dictionary
CMD common message dictionary
DSC diagnostic session control
ECU electronic control unit
OSI open systems interconnection
S_AE session layer address extension
S_SA session layer source address
S_Data session layer data transfer service name
SI service identifier
SOM start of message
S_Mtype session layer message type
S_PDU session layer protocol data unit
S_TA session layer target address
S_TAtype session layer target address type
4 Conventions
This part of ISO 14229 is guided by the conventions discussed in the OSI Service Conventions
(ISO 10731:1994) as they apply to the 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.
2 © ISO 2013 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 14229-2:2013(E)
5 Document overview
Figure 1 illustrates implementations of ISO 14229-2 onto various protocols.

Figure 1 — Implementation of UDS document reference according to OSI model
© ISO 2013 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO 14229-2:2013(E)
6 Session layer services
6.1 General
The service interface defines a set of services that are needed to access the functions offered by the session
layer, i.e. transmission/reception of data and setting of protocol parameters.
All session layer services have the same general structure. The service primitives define how a service user
(e.g. diagnostic application) cooperates with a service provider (e.g. session layer). To define the services,
three types of service primitives are specified:
 a service request primitive S_Data.request, used by the higher application layer to pass control
information or data required to be transmitted to the session layer (i.e. the service provider is being
requested by the service user to process control information or to transmit data);
 a service indication primitive S_Data.indication, used by the session layer to pass status information and
received data to the higher application layer (i.e. the service user is being informed by the service
provider about an internal event of the session layer or the service request of a peer protocol layer entity
service user);
 a service confirmation primitive S_Data.confirm used by the session layer to pass status information to
the application layer (i.e. the service user is being informed by service provider about the result of a
preceding service request of the service user);
All session layer services have the same general format. Service primitives are written in the form:
service_name.type (
parameter A,
parameter B,
parameter C
[, parameter X, .]
)
Where:
 "service_name" is the name of the service (e.g. S_Data),
 "type" indicates the type of the service primitive (e.g. request, indication, confirm),
 "parameter A, ." is the S_PDU (Session layer Protocol Data Unit) as a list of values passed by the
service primitive (e.g. addressing information, Data, Length, Result),
 "parameter A, parameter B, parameter C" are mandatory parameters that shall be included in all service
calls,
 "[parameter X]" is an optional parameter that is included if specific conditions are fulfilled.
4 © ISO 2013 – All rights reserved

---------------------- Page: 10 ----------------------
Message
ISO 14229-2:2013(E)
Figure 2 shows the session layer service primitives for a single frame message.


Figure 2 — Session layer service primitives – Single frame message

Figure 3 shows the session layer service primitives for a multiple frame message, if the transport/network
layer supports the T_DataSOM.ind interfaces.

Sender Sender Receiver Receiver
time
Application Layer Session Layer Session Layer
Application Layer
1
S_Data.req
T_Data.req
T_DataSOM.ind
S_Data.con T_Data.con T_Data.ind S_Data.ind

Key

1
optional, i.e. the transport/network layer supports the T_DataSOM.ind interfaces
Figure 3 — Session layer service primitives – Multiple frame message

The following communication scenarios shall be distinguished:
a) physical communication during
1) default session, and
2) non-default session — session handling required;
b) functional communication during
1) default session, and
2) non-default session — session handling required.
© ISO 2013 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO 14229-2:2013(E)
For all cases, the possibility of requesting an enhanced response-timing window by the server via a negative
response message, including a negative response code 0x78, shall be considered. The transport/network
layer services as defined in different ISO standards (e.g. ISO 15765-2 DoCAN or ISO 10681-2 CoFR) are
used to perform the diagnostic session management timing in the client and the server.
6.2 Specification of session layer service primitives
6.2.1 General
In order to describe the function of the session layer, services provided to higher layers and the internal
operations of the session layer have to be considered.
6.2.2 S_Data.request
The service primitive requests transmission of S_Data with S_Length number of bytes from the sender to the
receiver peer entities identified by the address information in S_SA, S_TA, S_TAtype, and S_AE. Each time
the S_Data.request service is called, the session layer shall signal the completion (or failure) of the message
transmission to the service user by means of the issuing of an S_Data.confirm service call.
S_Data.request (
S_Mtype,
S_SA,
S_TA,
S_TAtype,
[S_AE],
S_Data [Data#1, Data#2, …, Data#n ],
S_Length
)
6.2.3 S_Data.confirm
The S_Data.confirm service is issued by the session layer. The service primitive confirms the completion of an
S_Data.request service identified by the address information in S_SA, S_TA, S_TAtype, and S_AE. The
parameter S_Result provides the status of the service request.
S_Data.confirm (
S_Mtype,
S_SA,
S_TA,
S_TAtype,
[S_AE],
S_Result
)
6.2.4 S_Data.indication
The S_Data.indication service is issued by the session layer. The service primitive indicates S_Result events
and delivers S_Data with S_Length bytes received from a peer protocol entity identified by the address
information in S_SA, S_TA, S_TAtype to the adjacent upper layer.
6 © ISO 2013 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 14229-2:2013(E)
The parameters S_Data and S_Length are only valid if S_Result equals S_OK.
S_Data.indication (
S_Mtype,
S_SA,
S_TA,
S_TAtype,
[S_AE],
 S_Data [Data#1, Data#2, …, Data#n],
S_Length,
S_Result
)
6.3 Session data unit specification
6.3.1 S_Mtype, Session layer message type
Type: enumeration
Range: diagnostics, remote diagnostics
Description:
The parameter Mtype shall be used to identify the type and range of address information parameters included
in a service call. This part of ISO 14229 specifies a range of two values for this parameter. The intention is
that users of the document can extend the range of values by specifying other types and combinations of
address information parameters to be used with the transport/network layer protocol specified in this
document. For each such new range of address information, a new value for the Mtype parameter shall be
specified to identify the new address information.
 If S_Mtype = diagnostics, then the address information shall consist of the parameters S_SA, S_TA, and
S_TAtype.
 If S_Mtype = remote diagnostics, then the address information shall consist of the parameters S_SA,
S_TA, S_TAtype, and S_AE.
6.3.2 S_SA, Session layer source address
Type: 2 byte unsigned integer value
Range: 0x0000 – 0xFFFF
Description:
S_SA parameter shall be used to encode the sending session layer protocol entity. The parameter S_SA shall
be used to encode client and server identifiers.
6.3.3 S_TA, Session layer target address
Type: 2 byte unsigned integer value
Range: 0x0000 – 0xFFFF
Description:
S_TA parameter shall be used to encode the receiving session layer protocol entity. The parameter S_TA
shall be used to encode client and server identifiers.
© ISO 2013 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO 14229-2:2013(E)
6.3.4 S_TAtype, Session layer target address type
Type: enumeration
Range: physical, functional
Description:
The parameter S_TAtype is a configuration attribute to the S_TA parameter. It shall be used to encode the
communication model used by the communicating peer entities of the communication layer. Two
communication models are specified: '1 to 1' communication, called physical addressing, and '1 to n'
communication, called functional addressing.
 Physical addressing (1-to-1 communication) shall be supported for all types of session layer messages.
 Functional addressing (1-to-n communication) shall be supported. The transport/network layer
requirements may restrict the usage of functional addressing (e.g. SingleFrame on CAN data link layer).
6.3.5 S_AE, Session layer Address Extension (optional parameter)
Type: 2 byte unsigned integer value
Range: 0x0000 - 0xFFFF
Description:
The S_AE parameter is used to extend the available address range for large networks, and to encode both
sending and receiving transport/network layer entities of subnets other than the local network where the
communication takes place. S_AE is only part of the addressing information if Mtype is set to remote
diagnostics.
6.3.6 S_Length
Type:  4 Byte
Range:  0x0000 0000 – 0xFFFF FFFF
Description: This parameter includes the length of data to be transmitted/received.
6.3.7 S_Data
Type:  string of bytes
Range:  not applicable
Description: This parameter includes all data to be exchanged by the higher layer entities.
6.3.8 S_Result
Type:  enumeration
Range:  S_OK, S_NOK
Description: This parameter contains the status related to the outcome of a service execution.
8 © ISO 2013 – All rights reserved

---------------------- Page: 14 ----------------------
ISO 14229-2:2013(E)
6.3.9 Mapping of S_PDU onto T_PDU and vice versa for message transmission
The parameters of the session layer protocol data unit defined to request the transmission of a diagnostic
service request/response are mapped as follows onto the parameters of the transport/network layer protocol
data unit for the transmission of a message in the client/server.
The parameters of the transport/network layer protocol data unit defined for the reception of a message are
mapped as follows onto the parameters of the session layer protocol data unit for the indication of the
reception of a diagnostic response/request.
The transport/network layer confirmation of the successful transmission of the message (T_Data.con) is
forwarded to the application, because it is needed in the application for starting those actions, which shall be
executed immediately after the transmission of the request/response message (e.g. ECUReset,
BaudrateChange, etc.).
The transport/network layer indication for the reception of a StartOfMessage T_PDU (T_DataSOM.ind) is not
forwarded to the application layer, because it is only used within the session layer to perform the session layer
timing (see clause 7). Therefore, no mapping of the T_DataSOM.ind T_PDU onto an S_PDU is defined.
Table 2 defines the mapping of Session layer S_PDU onto Transport/Network layer T_PDU and vice versa.
Table 2 — Mapping of Session layer S_PDU onto Transport/Network layer T_PDU and vice versa
S_PDU parameter Description T_PDU parameter Description
(Session layer Protocol (Transport/Network layer
Data Unit) Protocol Data Unit)
S_Mtype Session layer Message T_Mtype Transport/Network layer
type Message type
S_SA Session layer Source T_SA Transport/Network layer Source
Address Address
S_TA Session layer Target T_TA Transport/Network layer Target
Address Address
S_TAtype Session layer Target T_TAtype Transport/Network layer Target
Address type Address type
a a
Session layer Address Transport/Network layer
S_AE  T_AE
Extension Address Extension
S_Data[1] – S_Data[n] Session layer Data T_Data[1] – T_Data[n] Transport/Network layer
Application Data
S_Length Session layer Data T_Length Transport/Network layer Data
Length Length
S_Result Session layer Result T_Result Transport/Network layer Result
a
If Mtype = diagnostics, then the address information shall consist of the parameters SA, TA, and TAtype.
If Mtype = remote diagnostics, then the address information shall consist of the parameters SA, TA, TAtype, and AE.

7 Timing parameter definition
7.1 General application timing considerations
7.1.1 Server
A server uses a single application timer (P2 ) implementation which is triggered (started and stopped) by
Server
the T_Data service primitive interface (T_Data.ind, T_Data.con, T_Data.req).
© ISO 2013 – All rights reserved 9

---------------------- Page: 15 ----------------------
ISO 14229-2:2013(E)
The P2 application timer is loaded with a P2 /P2* parameter value. Both parameters and
Server Server_max Server_max
values are specified in this part of ISO 14229 (see definition in Table 3 and parameter value in Table 4).
The timing parameter P4 is the time between the reception of a request (T_Data.indication) and the start
Server
of transmission of the final response (T_Data.request). A final response is a positive response or a negative
response other than negative response code 0x78 "requestCorrectlyReceived-ResponsePending". In case of
a request to schedule periodic responses, the initial USDT positive or negative response that indicates the
acceptance or non-acceptance of the request to schedule periodic responses shall be considered the final
response. P4 is a performance requirement. P4 is the maximum value of P4 . If P4 is
Server Server_max Server Server_max
the same as P2 , this means that a negative response with negative response code 0x78 is not
Server_max
allowed for that service or data.
These requirements are applicable only to services that are supported by the server/ECU. Unsupported
services shall always utilize a P4 value equal to P2 (i.e., NRC 0x78 not allowed).
Server_max Server_max
7.1.2 Client
A client uses a single application timer (P ) implementation which is triggered (started, reloaded, and
Client
stopped) by the T_Data service primitive interface (T_Data.con, T_DataSOM.ind, T_Data.ind).
The P application timer is always loaded with a P2 /P2* for all protocols which in principle
Client Client_max Client_max
support a T_DataSOM.ind service primitive (e.g. DoCAN). The P application timer is always loaded with a
Client
P6 /P6* parameter value for all protocols which in principle support a T_Data.ind service
Client_max Client_max
primitive only (e.g. DoIP).
The P application timer is started, whenever the client application layer receives a T_Data.con service
Client
primitive. Depending on the protocol type (with T_DataSOM.ind or without T_DataSOM.ind) it is loaded with a
P2 or a P6 parameter value.
Client_max Client_max
Depending on the protocol type (with T_DataSOM.ind or without T_DataSOM.ind) the P application timer
Client
is stopped, either when the T_DataSOM.ind or the T_Data.ind service primitive is received by the application.
For protocols which support T_DataSOM.ind the client application verifies the correct application timing by
comparing its actual P application timer with the P2 parameter value. If T_DataSOM.ind or
Client Client_max
T_Data.ind is received while P is smaller or equal to P2 the timing fulfils the requirements
Client Client_max
established by this standard. If no .ind is received while P is smaller or equal to P2 an error
Client Client_max
condition is detected. This shall be flagged to the application layer with the parameters included in either
T_DataSOM.ind or the T_Data.ind service primitive.
For protocols which support T_Data.ind only the client application verifies the correct application timing by
comparing its actual P application timer with the P6 parameter value. If T_Data.ind is received
Client Client_max
while P is smaller or equal to P6 the timing fulfils the requirements established by this part of
Client Client_max
ISO 14229. If no .ind is received while P is smaller or equal to P6 an error condition is detected.
Client Client_max
This shall be flagged to the application layer with the parameters included in the T_Data.ind service primitive.
All parameters and values are specified in this part of ISO 14229 (see definition in Table 3 and parameter
values in Table 4).
7.2 Application timing parameter definitions – defaultSession
A server shall always start the defaultSession when powered up. If no other diagnostic session is started, then
the defaultSession shall be run as long as the server is powered. The timing parameter definitions for the
defaultSession shall be in accordance with Table 3 and the definitions for the values shall be in accordance
with Table 4.
10 © ISO 2013 – All rights reserved

---------------------- Page: 16 ----------------------
ISO 14229-2:2013(E)
Table 3 — Message timing param
...