ISO 14229-2:2021
(Main)Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
This document specifies common session layer services and requirements to provide independence between unified diagnostic services (ISO 14229-1) and all transport protocols and network layer services (e.g. ISO 13400-2 DoIP, ISO 15765-2 DoCAN, ISO 10681-2 communication on FlexRay, ISO 14230-2 DoK-Line, and ISO 20794-3 CXPI). This document specifies a common service primitive interface between OSI layer 5 (session) and layer 4 (transport) via so-called service request/indication/confirmation primitives.
Véhicules routiers — Services de diagnostic unifiés (SDU) — Partie 2: Services de la couche session
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 14229-2
Second edition
2021-10
Road vehicles — Unified diagnostic
services (UDS) —
Part 2:
Session layer services
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 2: Services de la couche session
Reference number
ISO 14229-2:2021(E)
© ISO 2021
---------------------- Page: 1 ----------------------
ISO 14229-2:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 14229-2:2021(E)
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.2
4.1 Symbols . 2
4.2 Abbreviated terms . 2
5 Conventions . 2
6 Session layer services . 2
6.1 Service interface . 2
6.2 Service interface parameters . 3
6.3 Service interface primitives . 3
7 Service interface (SI) definition from application layer to session layer.4
7.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface . 4
7.2 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping . 5
7.3 SI — S_PDU mapping onto T_PDU and vice versa for message transmission . 5
7.4 SI — S_Data.req. 6
7.5 SI — S_Data.ind . 7
7.6 SI — S_Data.conf . 7
8 Service primitive parameters (SPP) . 7
8.1 SPP – General . 7
8.2 SPP – Data type definitions . 7
8.3 SPP – S_Mtype, session layer message type . 7
8.4 SPP – S_TAtype, session layer target address type . 8
8.5 SPP – S_TA, session layer target address . 8
8.6 SPP – S_SA, session layer source address . 8
8.7 SPP – S_AE, session layer address extension . 8
8.8 SPP – S_Length, session layer length of S_Data . 8
8.9 SPP – S_Data, session layer data of PDU . 9
8.10 SPP – S_Result, session layer result . 9
9 Timing parameter definition . .9
9.1 General application timing considerations . 9
9.1.1 Server . 9
9.1.2 Client . 10
9.2 Application timing parameter definitions – defaultSession . 11
9.3 Example for t without enhanced response timing . 16
P4_Server
9.4 Example for t with enhanced response timing . 17
P4_Server
9.5 Session timing parameter definitions for the non-default session . 19
9.6 Client and server timer resource requirements . 20
9.7 Error handling . 21
10 Timing handling during communication .23
10.1 Physical communication . 23
10.1.1 Physical communication during defaultSession – without SOM.ind .23
10.1.2 Physical communication during defaultSession – with SOM.ind . 24
10.1.3 Physical communication during defaultSession with enhanced response
timing . 24
10.1.4 Physical communication during a non-default session . 26
10.2 Functional communication . 31
10.2.1 Functional communication during defaultSession – without SOM.ind . 31
iii
© ISO 2021 – All rights reserved
---------------------- Page: 3 ----------------------
ISO 14229-2:2021(E)
10.2.2 Functional communication during defaultSession – with SOM.ind . 32
10.2.3 Functional communication during defaultSession with enhanced response
timing – with SOM.ind . 33
10.2.4 Functional communication during non-default session – with SOM.ind .36
10.3 Minimum time between client request messages .40
Annex A (normative) T_PDU interface.48
Annex B (informative) Vehicle diagnostic OSI layer architecture examples .49
Bibliography .53
iv
© ISO 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 14229-2:2021(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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
This second edition cancels and replaces the first edition (ISO 14229-2:2013), which has been technically
revised.
The main changes are as follows:
— restructuration of the document;
— introduction of requirement numbers and names;
— technical content improvements based on implementation feedback from the automotive industry.
A list of all parts in the ISO 14229 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
© ISO 2021 – All rights reserved
---------------------- Page: 5 ----------------------
ISO 14229-2:2021(E)
Introduction
The ISO 14229 series has been established in order to define common requirements for diagnostic
systems, whatever the serial data link is.
To achieve this, the ISO 14229 series is based on the Open Systems Interconnection (OSI) Basic Reference
[1]
Model in accordance with ISO/IEC 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 structured into the following layers:
— application layer (layer 7) specified in ISO 14229-1;
— presentation layer (layer 6) specified in ISO 14229-1;
— session layer services (layer 5) specified in this document (ISO 14229-2).
Figure 1 illustrates the ISO 14229 series reference according to OSI model.
Figure 1 — ISO 14229 series reference according to OSI model
vi
© ISO 2021 – All rights reserved
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 14229-2:2021(E)
Road vehicles — Unified diagnostic services (UDS) —
Part 2:
Session layer services
1 Scope
This document specifies common session layer services and requirements to provide independence
between unified diagnostic services (ISO 14229-1) and all transport protocols and network layer
services (e.g. ISO 13400-2 DoIP, ISO 15765-2 DoCAN, ISO 10681-2 communication on FlexRay, ISO 14230-
2 DoK-Line, and ISO 20794-3 CXPI).
This document specifies a common service primitive interface between OSI layer 5 (session) and layer 4
(transport) via so-called service request/indication/confirmation primitives.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14229-1, ISO/IEC 7498-1 and
the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
gateway
networking device that transfers the PDU on different OSI layers
EXAMPLE A network device that enables communication between control module networks that uses
different communication protocols, different communication rates, etc. and that includes, but is not limited to,
gateway functionalities like bridge, switch (3.3), router (3.2) or application layer routing.
3.2
router
networking device that transfers the PDU on OSI layers 3 and 4
3.3
switch
networking device that transfers the PDU on OSI layer 2
1
© ISO 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 14229-2:2021(E)
4 Symbols and abbreviated terms
4.1 Symbols
— empty cell/undefined
t time
4.2 Abbreviated terms
Diag diagnostics
ECU electronic control unit
N/A not applicable
OSI open systems interconnection
RDiag remote diagnostics
S_AE session layer address extension
S_Data session layer data transfer service name
S_Length session layer length of data
S_Mtype session layer message type
S_PDU session layer protocol data unit
S_SA session layer source address
S_TA session layer target address
S_TAtype session layer target address type
SecureDiag secure diagnostics
SecureRDiag secure remote diagnostics
SI service identifier
SOM start of message
SPP service primitive parameter
5 Conventions
[1]
This document is based on the OSI service conventions as specified in ISO/IEC 10731 .
Annex B describes vehicle diagnostic OSI layer architecture examples.
6 Session layer services
6.1 Service interface
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.
2
© ISO 2021 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 14229-2:2021(E)
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).
6.2 Service interface parameters
The 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 are included in all service
calls, “[parameter X]” is an optional parameter that is included if specific conditions are fulfilled.
6.3 Service interface primitives
Figure 2 shows the session layer service primitives of a message transmission with a T_Data.ind
reception at the session layer of the receiver side from the lower OSI layer.
Figure 2 — Session layer service primitives – T_Data.ind message reception
Figure 3 shows the session layer service primitives of a message transmission with a T_DataSOM.ind
reception at the beginning of the message and a T_Data.ind reception at the end of the message at the
session layer of the receiver side from the lower OSI layer.
3
© ISO 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 14229-2:2021(E)
Key
1 transport layer StartOfMessage data indication, e.g. ISO 15765-2
Figure 3 — Session layer service primitives – T_DataSOM.ind and T_Data.ind reception
The following communication scenarios are 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.
7 Service interface (SI) definition from application layer to session layer
7.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface
The service interface defines the service and parameter mapping from the application layer to the
session layer.
Figure 4 shows the S_Data.req, S_Data.ind, and S_Data.conf service interface.
4
© ISO 2021 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 14229-2:2021(E)
Key
1 service access point
2 read back from N-layer service provider
Figure 4 — S_Data.req and S_Data.ind service interface
7.2 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping
This requirement specifies the application service interface and parameter mapping between the
session layer and the lower OSI layers.
REQ 0.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping
The S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping shall be implemented as
specified in Table 1.
Table 1 — S_Data.req and S_Data.ind service interface parameter mapping
Application layer Session layer A_Data.req, A_Data.ind and A_Data.conf parameter valid-
ity
(service user) (service provider) .req .ind .conf
A_Mtype S_Mtype
X X X
A_AI[TAtype] S_AI[TAtype]
X X X
A_AI[TA] S_AI[TA]
X X X
A_AI[SA] S_AI[SA]
X X X
A_AI[AE] S_AI[AE]
X X X
A_Length S_Length
X X —
A_Data S_Data
X X —
A_Result S_Result
— X X
Key
X = supported
— = not supported
7.3 SI — S_PDU mapping 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 onto the parameters of the transport layer protocol
5
© ISO 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 14229-2:2021(E)
data unit for the transmission of a message in the client/server. Annex A specifies the T_PDU interface
and shall be followed.
The parameters of the transport 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 confirmation/
indication of the reception of a diagnostic response/request.
The transport layer confirmation of the successful transmission of the message (T_Data.conf) 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,
bit rate change).
The transport layer indication for the reception of a StartOfMessage T_PDU (T_DataSOM.ind), e.g.
ISO 15765-2 is not forwarded to the application layer, because it is only used within the session layer
to perform the session layer timing (see Clause 9). 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 layer T_PDU and vice versa.
Table 2 — Mapping of session layer S_PDU onto transport layer T_PDU and vice versa
S_PDU parameter Description T_PDU parameter Description
(session layer pro- (transport layer pro-
tocol data unit) tocol data unit)
S_Mtype T_Ptype
Session layer message type Transport layer segment type
S_AI[TAtype] T_AI[TAtype]
Session layer target address Transport layer target address
type type
S_AI[SA] T_AI[SA]
Session layer source address Transport layer source address
S_AI[TA] T_AI[TA]
Session layer target address Transport layer target address
a a
S_AI[AE] Session layer address exten- T_AI[AE] Transport layer address exten-
sion sion
S_Data[1] – S_ Session layer data T_Data[1] – T_
Transport layer data
Data[n] Data[n]
S_Length T_Length
Session layer data length Transport layer data length
S_Result T_Result
Session layer result Transport layer result
a
If Mtype = diagnostics/secure diagnostics, then the address information shall consist of the parameters SA, TA and
TAtype.
If Mtype = remote diagnostics/secure remote diagnostics, then the address information shall consist of the parameters
SA, TA, TAtype, and AE.
7.4 SI — S_Data.req
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_AI[TAtype], S_AI[SA], S_
AI[TA], and S_AI[AE].
If the S_Data.req service is called, the session layer signals the completion (or failure) of the message
transmission to the service user by means of the issuing of an S_Data.conf service call.
S_Data.req (
S_Mtype,
S_AI[TAtype],
S_AI[SA],
S_AI[TA],
[S_AI[AE]],
S_Data[Data#1, Data#2, …, Data#n],
S_Length
)
6
© ISO 2021 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 14229-2:2021(E)
7.5 SI — S_Data.ind
The S_Data.indication service is issued by the session layer. The service primitive shall indicate S_
Result events and delivers S_Data with S_Length bytes received from a peer protocol entity identified
by the address information in S_AI[TAtype], S_AI[SA], S_AI[TA], and S_AI[AE] to the adjacent upper
layer. The parameters S_Data and S_Length shall only be valid if S_Result equals S_OK.
S_Data.ind (
S_Mtype,
S_AI[TAtype],
S_AI[SA],
S_AI[TA],
[S_AI[AE]],
S_Data[Data#1, Data#2, …, Data#n],
S_Length,
S_Result
)
7.6 SI — S_Data.conf
The S_Data.conf service is issued by the session layer. The service primitive confirms the completion
of an S_Data.req service identified by the address information in S_AI[TAtype], S_AI[SA], S_AI[TA],
and S_AI[AE]. The parameter S_Result provides the status of the service request.
S_Data.conf (
S_Mtype,
S_AI[TAtype],
S_AI[SA],
S_AI[TA],
[S_AI[AE]],
S_Result
)
8 Service primitive parameters (SPP)
8.1 SPP – General
Clause 8 specifies the service primitive parameters and data types, which are used by the application
layer services.
8.2 SPP – Data type definitions
REQ 0.2 SPP – Data type definitions
The data types shall be in accordance to:
— Enum = 8-bit enumeration,
— Unsigned Byte = 8-bit unsigned numeric value,
— Unsigned Word = 16-bit unsigned numeric value,
— Unsigned Long = 32-bit unsigned numeric value,
— Byte Array = sequence of 8-bit aligned data,
— Bit String = 8-bit binary coded.
8.3 SPP – S_Mtype, session layer message type
The parameter S_Mtype is used to identify the type and range of address information parameters
included in a service call. This document specifies a range of two values for this parameter.
7
© ISO 2021 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 14229-2:2021(E)
REQ 0.3 SPP – S_Mtype, session layer message type
The S_Mtype parameter shall be of data type Enum and shall be used to identify the message type and range of
address information included in a service call.
— If S_Mtype = diagnostics (Diag)/secure diagnostics (SecureDiag), then the address information shall
consist of the parameters S_SA, S_TA and S_TAtype.
— If S_Mtype = remote diagnostics (RDiag)/secure remote diagnostics (SecureRDiag), then the address
information shall consist of the parameters S_SA, S_TA, S_TAtype and S_AE.
Range: [Diag, RDiag, SecureDiag, SecureRDiag]
8.4 SPP – S_TAtype, session layer target address type
The parameter S_TAtype is a configuration attribute to the S_TA parameter. It is used to encode the
communication model used by the communicating peer entities. Two communication models are
specified: '1 to 1' communication, called physical addressing, and '1 to n' communication, called
functional addressing.
REQ 0.4 SPP – S_TAtype, session layer target address type
The S_TAtype parameter shall be of data type Enum and shall be used to identify the target address type to be
used with the request address.
Range: [physical, functional]
8.5 SPP – S_TA, session layer target address
S_TA parameter is used to encode the receiving session layer protocol entity. The parameter S_TA is
used to encode client and server identifiers.
REQ 0.5 SPP – S_TA, session layer target address
The S_TA parameter shall be of data type Unsigned Word and shall contain the target address of the node.
Range: [0000 to FFFF ]
16 16
8.6 SPP – S_SA, session layer source address
S_SA parameter is used to encode the sending session layer protocol entity. The parameter S_SA is used
to enco
...
INTERNATIONAL ISO
STANDARD 14229-2
Second edition
Road vehicles — Unified diagnostic
services (UDS) —
Part 2:
Session layer services
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 2: Services de la couche session
PROOF/ÉPREUVE
Reference number
ISO 14229-2:2021(E)
©
ISO 2021
---------------------- Page: 1 ----------------------
ISO 14229-2:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 14229-2:2021(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 2
4.1 Symbols . 2
4.2 Abbreviated terms . 2
5 Conventions . 2
6 Session layer services . 2
6.1 Service interface . 2
6.2 Service interface parameters . 3
6.3 Service interface primitives . 3
7 Service interface (SI) definition from application layer to session layer .4
7.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface . 4
7.2 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping . 5
7.3 SI — S_PDU mapping onto T_PDU and vice versa for message transmission . 5
7.4 SI — S_Data.req. 6
7.5 SI — S_Data.ind . 6
7.6 SI — S_Data.conf . 7
8 Service primitive parameters (SPP) . 7
8.1 SPP – General . 7
8.2 SPP – Data type definitions . 7
8.3 SPP – S_Mtype, session layer message type . 7
8.4 SPP – S_TAtype, session layer target address type . 8
8.5 SPP – S_TA, session layer target address . 8
8.6 SPP – S_SA, session layer source address . 8
8.7 SPP – S_AE, session layer address extension . 8
8.8 SPP – S_Length, session layer length of S_Data . 9
8.9 SPP – S_Data, session layer data of PDU . 9
8.10 SPP – S_Result, session layer result . 9
9 Timing parameter definition . 9
9.1 General application timing considerations . 9
9.1.1 Server . 9
9.1.2 Client .10
9.2 Application timing parameter definitions – defaultSession .11
9.3 Example for t without enhanced response timing .16
P4_Server
9.4 Example for t with enhanced response timing .17
P4_Server
9.5 Session timing parameter definitions for the non-default session .19
9.6 Client and server timer resource requirements .21
9.7 Error handling .21
10 Timing handling during communication .23
10.1 Physical communication .23
10.1.1 Physical communication during defaultSession – without SOM.ind .23
10.1.2 Physical communication during defaultSession – with SOM.ind .24
10.1.3 Physical communication during defaultSession with enhanced response
timing . .24
10.1.4 Physical communication during a non-default session .26
10.2 Functional communication .31
10.2.1 Functional communication during defaultSession – without SOM.ind .31
© ISO 2021 – All rights reserved PROOF/ÉPREUVE iii
---------------------- Page: 3 ----------------------
ISO 14229-2:2021(E)
10.2.2 Functional communication during defaultSession – with SOM.ind .32
10.2.3 Functional communication during defaultSession with enhanced
response timing – with SOM.ind .33
10.2.4 Functional communication during non-default session – with SOM.ind .36
10.3 Minimum time between client request messages .40
Annex A (normative) T_PDU interface .48
Annex B (informative) Vehicle diagnostic OSI layer architecture examples .49
Bibliography .53
iv PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 14229-2:2021(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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
This second edition cancels and replaces the first edition (ISO 14229-2:2013), which has been technically
revised.
The main changes compared to the previous edition are as follows:
— restructuration of the document;
— introduction of requirement numbers and names;
— technical content improvements based on implementation feedback from the automotive industry.
A list of all parts in the ISO 14229 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
© ISO 2021 – All rights reserved PROOF/ÉPREUVE v
---------------------- Page: 5 ----------------------
ISO 14229-2:2021(E)
Introduction
The ISO 14229 series has been established in order to define common requirements for diagnostic
systems, whatever the serial data link is.
To achieve this, the ISO 14229 series is based on the Open Systems Interconnection (OSI) Basic Reference
[1]
Model in accordance with ISO/IEC 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 structured into the following layers:
— application layer (layer 7) specified in ISO 14229-1;
— presentation layer (layer 6) specified in ISO 14229-1;
— session layer services (layer 5) specified in this document (ISO 14229-2).
Figure 1 illustrates the ISO 14229 series reference according to OSI model.
Figure 1 — ISO 14229 series reference according to OSI model
vi PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 14229-2:2021(E)
Road vehicles — Unified diagnostic services (UDS) —
Part 2:
Session layer services
1 Scope
This document specifies common session layer services and requirements to provide independence
between unified diagnostic services (ISO 14229-1) and all transport protocols and network layer
services (e.g. ISO 13400-2 DoIP, ISO 15765-2 DoCAN, ISO 10681-2 communication on FlexRay,
ISO 14230-2 DoK-Line, and ISO 20794-3 CXPI).
This document specifies a common service primitive interface between OSI layer 5 (session) and layer 4
(transport) via so-called service request/indication/confirmation primitives.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14229-1, ISO/IEC 7498-1 and
the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
gateway
networking device that transfers the PDU on different OSI layers
EXAMPLE A network device that enables communication between control module networks that uses
different communication protocols, different communication rates, etc. and that includes, but is not limited to,
gateway functionalities like bridge, switch (3.3), router (3.2) or application layer routing.
3.2
router
networking device that transfers the PDU on OSI layers 3 and 4
3.3
switch
networking device that transfers the PDU on OSI layer 2
© ISO 2021 – All rights reserved PROOF/ÉPREUVE 1
---------------------- Page: 7 ----------------------
ISO 14229-2:2021(E)
4 Symbols and abbreviated terms
4.1 Symbols
— empty cell/undefined
t time
4.2 Abbreviated terms
Diag diagnostics
ECU electronic control unit
N/A not applicable
OSI open systems interconnection
RDiag remote diagnostics
S_AE session layer address extension
S_Data session layer data transfer service name
S_Length session layer length of data
S_Mtype session layer message type
S_PDU session layer protocol data unit
S_SA session layer source address
S_TA session layer target address
S_TAtype session layer target address type
SecureDiag secure diagnostics
SecureRDiag secure remote diagnostics
SI service identifier
SOM start of message
SPP service primitive parameter
5 Conventions
[1]
This document is based on the OSI service conventions as specified in ISO/IEC 10731 .
Annex B describes vehicle diagnostic OSI layer architecture examples.
6 Session layer services
6.1 Service interface
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.
2 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 14229-2:2021(E)
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).
6.2 Service interface parameters
The 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 are included in all service
calls, “[parameter X]” is an optional parameter that is included if specific conditions are fulfilled.
6.3 Service interface primitives
Figure 2 shows the session layer service primitives of a message transmission with a T_Data.ind
reception at the session layer of the receiver side from the lower OSI layer.
Figure 2 — Session layer service primitives – T_Data.ind message reception
Figure 3 shows the session layer service primitives of a message transmission with a T_DataSOM.ind
reception at the beginning of the message and a T_Data.ind reception at the end of the message at the
session layer of the receiver side from the lower OSI layer.
© ISO 2021 – All rights reserved PROOF/ÉPREUVE 3
---------------------- Page: 9 ----------------------
ISO 14229-2:2021(E)
Key
1 transport layer StartOfMessage data indication, e.g. ISO 15765-2
Figure 3 — Session layer service primitives – T_DataSOM.ind and T_Data.ind reception
The following communication scenarios are 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.
7 Service interface (SI) definition from application layer to session layer
7.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface
The service interface defines the service and parameter mapping from the application layer to the
session layer.
Figure 4 shows the S_Data.req, S_Data.ind, and S_Data.conf service interface.
4 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 14229-2:2021(E)
Key
1 service access point
2 read back from N-layer service provider
Figure 4 — S_Data.req and S_Data.ind service interface
7.2 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping
This requirement specifies the application service interface and parameter mapping between the
session layer and the lower OSI layers.
REQ 0.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping
The S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping shall be implemented as
specified in Table 1.
Table 1 — S_Data.req and S_Data.ind service interface parameter mapping
Application layer Session layer A_Data.req and A_Data.ind parameter validity
(service user) (service provider) .req .ind .conf
A_Mtype S_Mtype
X X X
A_AI[TAtype] S_AI[TAtype]
X X X
A_AI[TA] S_AI[TA]
X X X
A_AI[SA] S_AI[SA]
X X X
A_AI[AE] S_AI[AE]
X X X
A_Length S_Length
X X —
A_Data S_Data
X X —
A_Result S_Result
— X X
Key
X = supported
— = not supported
7.3 SI — S_PDU mapping 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 onto the parameters of the transport layer protocol
data unit for the transmission of a message in the client/server. Annex A specifies the T_PDU interface
and shall be followed.
© ISO 2021 – All rights reserved PROOF/ÉPREUVE 5
---------------------- Page: 11 ----------------------
ISO 14229-2:2021(E)
The parameters of the transport 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 confirmation/
indication of the reception of a diagnostic response/request.
The transport layer confirmation of the successful transmission of the message (T_Data.conf) 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,
bit rate change).
The transport layer indication for the reception of a StartOfMessage T_PDU (T_DataSOM.ind), e.g.
ISO 15765-2 is not forwarded to the application layer, because it is only used within the session layer
to perform the session layer timing (see Clause 9). 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 layer T_PDU and vice versa.
Table 2 — Mapping of session layer S_PDU onto transport layer T_PDU and vice versa
S_PDU parameter Description T_PDU parameter Description
(session layer pro- (transport layer pro-
tocol data unit) tocol data unit)
S_Mtype T_Ptype
Session layer message type Transport layer segment type
S_AI[TAtype] T_AI[TAtype]
Session layer target address Transport layer target address
type type
S_AI[SA] T_AI[SA]
Session layer source address Transport layer source address
S_AI[TA] T_AI[TA]
Session layer target address Transport layer target address
a a
S_AI[AE] Session layer address exten- T_AI[AE] Transport layer address exten-
sion sion
S_Data[1] – S_ Session layer data T_Data[1] – T_
Transport layer data
Data[n] Data[n]
S_Length T_Length
Session layer data length Transport layer data length
S_Result T_Result
Session layer result Transport layer result
a
If Mtype = diagnostics/secure diagnostics, then the address information shall consist of the parameters SA, TA and
TAtype.
If Mtype = remote diagnostics/secure remote diagnostics, then the address information shall consist of the parameters
SA, TA, TAtype, and AE.
7.4 SI — S_Data.req
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_AI[TAtype], S_AI[SA], S_
AI[TA], and S_AI[AE].
If the S_Data.req service is called, the session layer signals the completion (or failure) of the message
transmission to the service user by means of the issuing of an S_Data.conf service call.
S_Data.req (
S_Mtype,
S_AI[TAtype],
S_AI[SA],
S_AI[TA],
[S_AI[AE]],
S_Data[Data#1, Data#2, …, Data#n],
S_Length
)
7.5 SI — S_Data.ind
The S_Data.indication service is issued by the session layer. The service primitive shall indicate S_
Result events and delivers S_Data with S_Length bytes received from a peer protocol entity identified
6 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 14229-2:2021(E)
by the address information in S_AI[TAtype], S_AI[SA], S_AI[TA], and S_AI[AE] to the adjacent upper
layer. The parameters S_Data and S_Length shall only be valid if S_Result equals S_OK.
S_Data.ind (
S_Mtype,
S_AI[TAtype],
S_AI[SA],
S_AI[TA],
[S_AI[AE]],
S_Data[Data#1, Data#2, …, Data#n],
S_Length,
S_Result
)
7.6 SI — S_Data.conf
The S_Data.conf service is issued by the session layer. The service primitive confirms the completion
of an S_Data.req service identified by the address information in S_AI[TAtype], S_AI[SA], S_AI[TA],
and S_AI[AE]. The parameter S_Result provides the status of the service request.
S_Data.conf (
S_Mtype,
S_AI[TAtype],
S_AI[SA],
S_AI[TA],
[S_AI[AE]],
S_Result
)
8 Service primitive parameters (SPP)
8.1 SPP – General
Clause 8 specifies the service primitive parameters and data types, which are used by the application
layer services.
8.2 SPP – Data type definitions
REQ 0.2 SPP – Data type definitions
The data types shall be in accordance to:
— Enum = 8-bit enumeration,
— Unsigned Byte = 8-bit unsigned numeric value,
— Unsigned Word = 16-bit unsigned numeric value,
— Unsigned Long = 32-bit unsigned numeric value,
— Byte Array = sequence of 8-bit aligned data,
— Bit String = 8-bit binary coded.
8.3 SPP – S_Mtype, session layer message type
The parameter S_Mtype is used to identify the type and range of address information parameters
included in a service call. This document specifies a range of two values for this parameter.
REQ 0.3 SPP – S_Mtype, session layer message type
The S_Mtype parameter shall be of data type Enum and shall be used to identify the message type and range of
address information included in a service call.
© ISO 2021 – All rights reserved PROOF/ÉPREUVE 7
---------------------- Page: 13 ----------------------
ISO 14229-2:2021(E)
REQ 0.3 SPP – S_Mtype, session layer message type
— If S_Mtype = diagnostics (Diag)/secure diagnostics (SecureDiag), then the address information shall
consist of the parameters S_SA, S_TA and S_TAtype.
— If S_Mtype = remote diagnostics (RDiag)/secure remote diagnostics (SecureRDiag), then the address
information shall consist of the parameters S_SA, S_TA, S_TAtype and S_AE.
Range: [Diag, RDiag, SecureDiag, SecureRDiag]
8.4 SPP – S_TAtype, session layer target address type
The parameter S_TAtype is a configuration attribute to the S_TA parameter. It is used to encode the
communication model used by the communicating peer entities. Two communication models are
specified: '1 to 1' communication, called physical addressing, and '1 to n' communication, called
functional addressing.
REQ 0.4 SPP – S_TAtype, session layer target address type
The S_TAtype parameter shall be of data type Enum and shall be used to identify the target address type to be
used with the request address.
Range: [physical, functional]
8.5 SPP – S_TA, session layer target address
S_TA parameter is used to encode the receiving session layer protocol entity. The parameter S_TA is
used to encode client and server identifiers.
REQ 0.5 SPP – S_TA, session layer target address
The S_TA para
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.