ISO 14229-2:2021

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 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
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
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
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
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
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
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.
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.
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.
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
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
)
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.
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 encode client and server identifiers.
REQ 0.6 SPP – S_SA, session layer source address
The S_SA parameter shall be of data type Unsigned Word and shall contain the source address of the node.
Range: [0000  to FFFF ]
16 16
8.7 SPP – S_AE, session layer address extension
S_AE parameter is used to encode the sending session layer protocol entity. The parameter S_AE is used
to encode client and server identifiers.
REQ 0.7 SPP – S_AE, session layer address extension
The S_AE parameter shall be of data type Unsigned Word and shall contain the extended address of the node.
Range: [0000  to FFFF ]
16 16
8.8 SPP – S_Length, session layer length of S_Data
This parameter includes the length of data to be transmitted/received.
REQ 0.8 SPP – S_Length, session layer length of S_Data
The S_Length parameter shall be of data type Unsigned Long and shall contain the length of the S_Data to be
transmitted/received.
Range: [0000 0000  to FFFF FFFF ]
16 16
8.9 SPP – S_Data, session layer data of PDU
This parameter includes data to be exchanged by the higher OSI layer entities.
REQ 0.9 SPP – S_Data, session layer data of PDU
The S_Data parameter shall be of data type Byte Array and shall contain the message data content of the
request or response message to be transmitted/received.
Range: [00  to FF ]
16 16
8.10 SPP – S_Result, session layer result
This parameter contains the status related to the outcome of a service execution.
REQ 0.10 SPP – S_Result, session layer result
The S_Result parameter shall be of data type Enum and shall contain the status relating to the outcome of a
service execution (request field and response field sequence). If two or more errors are discovered at the same
time, then the application layer entity shall set the appropriate error bit in the Result parameter.
Range: [OK, ERR_.]
The result OK shall be issued to the service user when the service execution is successfully completed. The OK
shall be issued to a service user on both, the sender and receiver side.
The ERR_. shall be issued to the service user when an error is detected by a lower layer (provider). The
ERR_. shall be issued to the service user on both, the sender and receiver side.
9 Timing parameter definition
9.1 General application timing considerations
9.1.1 Server
REQ 5.1 Timing parameter definition – Server – t
P2_Server
A server shall use a single application timer (t ) implementation, which is triggered (started and
P2_Server
stopped) by the T_Data service primitive interface (T_Data.req, T_Data.conf, T_DataSOM.ind, T_Data.
ind).
REQ 5.2 Timing parameter definition – Server – t /t
P2_Server_Max P2*_Server_Max
The t application timer shall be loaded with a t /t parameter value. Both
P2_Server P2_ServerMax P2*_Server_Max
_
parameters and values are specified in Table 3 and in Table 4.

REQ 5.3 Timing parameter definition – Server – t
P4_Server
The parameter t is a performance requirement and shall be the time between the reception of a re-
P4_Server
quest (T_Data.ind) and the start of transmission of the final response (T_Data.req).
The timing parameter t is a performance parameter.
P4
REQ 5.4 Timing parameter definition – Server – t
P4_Server_Max
The parameter t shall be the maximum value of t and if t is the same as t
P4_Server_Max P4_Server P4_Server_Max P2_
, this shall be interpreted as that a negative response with negative response code 78 “requestCor-
Server_Max 16
rectlyReceived-ResponsePending” is not allowed for the service in progress.

REQ 5.5 Timing parameter definition – Server – Final response
A final response shall be a positive response or a negative response with a negative response code other than
78 “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 is considered
the final response.
REQ 5.6 Timing parameter definition – Server – Service not supported
Services not supported by the server shall utilize a t value equal to t . A negative re-
P4_Server_Max P2_Server_Max
sponse with a negative response code 78 “requestCorrectlyReceived-ResponsePending” shall not be allowed.
9.1.2 Client
REQ 5.7 Timing parameter definition – Client – t
P_Client
A client shall use a single application timer (t ) implementation which is triggered (started, reloaded,
P_Client
and stopped) by the T_Data service primitive interface (T_Data.req, T_Data.conf, T_DataSOM.ind, T_
Data.ind).
REQ 5.8 Timing parameter definition – Client – t /t
P2_Client_Max P2*_Client_Max
The t application timer shall be loaded with a t /t for protocols, which sup-
P_Client P2_Client_Max P2*_Client_Max
port a T_DataSOM.ind service primitive (e.g. ISO 15765 DoCAN).

REQ 5.9 Timing parameter definition – Client – t start
P_Client
The t application timer shall be started, whenever the client application layer receives a T_Data.conf
P_Client
service primitive. Depending on the protocol type (with T_DataSOM.ind or without T_DataSOM.ind) the t
P_
application timer shall be loaded with a t or a t parameter value.
Client P2_Client_Max P6_Client_Max

REQ 5.10 Timing parameter definition – Client – t stop
P_Client
Depending on the protocol type (with T_DataSOM.ind or without T_DataSOM.ind) the t application
P_Client
timer shall be stopped, either when the T_DataSOM.ind or the T_Data.ind service primitive is received by the
application.
REQ 5.11 Timing parameter definition – Client – t /t
P6_Client_Max P6*_Client_Max
The t application timer shall be loaded with a t /t for protocols, which do not
P_Client P6_Client_Max P6*_Client_Max
support a T_DataSOM.ind service primitive (e.g. ISO 13400 DoIP).

REQ 5.12 Timing parameter definition – Client – Error condition detection
If no ".ind" is received while t is smaller or equal to t an error condition shall be detected.
P_Client P2_Client_Max
REQ 5.13 Timing parameter definition – Client – Error indication to application layer
The error condition shall be flagged to the application layer with the parameters included in either T_
DataSOM.ind or the T_Data.ind service primitive.

REQ 5.14 Timing parameter definition – Client – Application layer protocols with support of T_
DataSOM.ind
For application layer protocols, which support T_DataSOM.ind, the client application shall verify the correct
application timing by comparing its actual t application timer value with the t parameter
P_Client P2_Client_Max
value.
If T_DataSOM.ind or T_Data.ind is received while t is smaller or equal to t the timing
P_Client P2_Client_Max
fulfils the requirements established by this document.
REQ 5.15 Timing parameter definition – Client – Application layer protocols with no support of T_
DataSOM.ind
For application layer protocols, which only support T_Data.ind, the client application shall verify the correct
application timing by comparing its actual t application timer value with the t parameter
P_Client P6_Client_Max
value.
If T_Data.ind is received while t is smaller or equal to t the timing fulfils the
P_Client P6_Client_Max
requirements established by this document.
REQ 5.16 Timing parameter definition – Client – Error condition detection and reporting
If no indication (.ind) is received while t is smaller or equal to t an error condition shall be
P_Client P6_Client_Max
detected and shall be flagged to the application layer with the parameters included in the T_Data.ind service
primitive.
9.2 Application timing parameter definitions – defaultSession
REQ 5.17 Timing parameter definition – defaultSession start
A server shall start the defaultSession when powered up.

REQ 5.18 Timing parameter definition – Timing parameter definition of defaultSession
The timing parameter definitions shall be in accordance with Table 3.

Table 3 — Message timing parameter definitions for the defaultSession
Timing pa- Definition Type
rameter
The Δt parameter is defined to be the worst-case vehicle network design-de-
P2
pendent message transmission delay such as delays introduced by gateways
and bus-load dependent arbitration. The value of Δt is divided into the time to
P2
Performance
Δt
transmit the request to the addressed server/ECU (Δt ) and in case the
P2
P2_Request
requirement
protocol supports T_DataSOM.ind till the start of the response transmission
indicated by T_DataSOM.ind or T_Data.ind if the response is a single frame
message (e.g. ISO 15765 DoCAN).
Table 3 (continued)
Timing pa- Definition Type
rameter
The Δt parameter is defined to be the worst-case vehicle network design-de-
P6
pendent message transmission delay such as delays introduced by gateways
and bus-load dependent arbitration. The value of Δt is divided into the time to
P6
Performance
Δt transmit the request to the addressed server/ECU (Δt ) and the time to
P6
P6_Request
requirement
transmit the complete response to the client/tester (Δt ). The Δt is
P6_Response P6
independent of whether a protocol supports a T_DataSOM.ind (e.g. ISO 15765
DoCAN) or does not support a T_DataSOM.ind (e.g. ISO 13400 DoIP).
Performance requirement for the server to start with the response message Performance
t
P2_Server
after the reception of a request message (indicated via T_Data.ind). requirement
Timeout for the client to wait after the successful transmission of a request
message (indicated via T_Data.conf) for the start of incoming response mes- Timer reload
t
P2_Client
sages (indicated via T_DataSOM.ind of a multi-frame message or T_Data.ind value
of a SingleFrame message).
Timeout for the client to wait after the successful transmission of a request
Timer reload
t
message (indicated via T_Data.conf) for the complete reception of the corre-
P6_Client
value
sponding response message (indicated via T_Data.ind) e.g. ISO 13400.
Performance requirement for the server to start with the response message
Performance
t
after the transmission of a negative response message (indicated via T_Data.
P2*_Server
requirement
conf) with negative response code 78 (enhanced response timing).
Enhanced timeout for the client to wait after the reception of a negative re-
sponse message with negative response code 78 (indicated via T_Data.ind) Timer reload
t
P2*_Client
for the start of incoming response messages (indicated via T_DataSOM.ind of a value
multi-frame message or T_Data.ind of a SingleFrame message).
Enhanced timeout for the client to wait after the reception of a negative re-
sponse message with negative response code 78 (indicated via T_Data.ind) Timer reload
t
P6*_Client
for the complete reception of the corresponding response messages (indicated value
via T_Data.ind), e.g. ISO 13400 DoIP.
Minimum time for the client to wait after the successful transmission of a
physically-addressed request message (indicated via T_Data.conf) with no Timer reload
t
P3_Client_Phys
response required before it can transmit the next physically-addressed request value
message (see Figure 20).
Minimum time for the client to wait after the successful transmission of a func-
tionally-addressed request message (indicated via T_Data.conf) before it can
Timer reload
t
transmit the next functionally-addressed request message in case no response
P3_Client_Func
value
is required or the requested data are only supported by a subset of the function-
ally-addressed servers (see 10.3).
This is the time between the reception of a request (T_Data.ind) and the start Performance
t
P4_Server
of the transmission of the final response (T_Data.req) at the server side. requirement

REQ 5.19 Timing parameter definition – New request message transmission
Each server/ECU shall be able to process a new request message immediately after the successful transmission
of a response message (T_Data.conf) from the preceding request message.
An exception to this requirement may be granted by the vehicle manufacturer for some use cases,
where the server/ECU requires additional time after the execution of the previous service request, e.g.
EcuReset service.
REQ 5.20 Timing parameter definition – Message timing parameter value specification of default-
Session
The timing parameter values for the defaultSession shall be in accordance with Table 4.
Table 4 — Message timing parameter value specification for the defaultSession
Timing parameter Minimum Maximum
Δt 0 ms vehicle manufacturer specific value: see Formula (1)
P2
Δt
0 ms vehicle manufacturer specific value: see Formula (2)
P6
t
0 ms server specific value: recommended value = 50 ms
P2_Server
a
t t  + Δt —
P2_Client P2_Server_Max P2_Max
a
t t  + Δt —
P6_Client P2_Server_Max P6_Max
b
t 0 ms server specific value: recommended value = 5 000 ms
P2*_Server
c
t t  + Δt —
P2*_Client P2*_Server_Max P2_Response
c
t t  + Δt —
P6*_Client P2*_Server_Max P6_Response
d
t t  + Δt —
P3_Client_Phys P2_Server_Max P2_Max
d
t t  + Δt —
P3_Client_Func P2_Server_Max P2_Max
e
t t  + Δt —
P3_Client_Phys P2_Server_Max P6_Max
e
t t  + Δt —
P3_Client_Func P2_Server_Max P6_Max
As defined by regulation for OBD diagnostic use cases.
t t
P4_Server P2_Server
Vehicle manufacturer specific value for enhanced diag-
nostic use cases.
a
The maximum time a client waits for a response message is at the discretion of the client, provided that t /
P2_Client
t is greater than the specified minimum value of t /t .
P6_Client P2_Client P6_Client
b
During the enhanced response timing, the minimum time between the transmission of consecutive negative messages
(each with negative response code 78 ) shall be 0,3 × t , in order to avoid flooding the data link with
16 P2*_Server_Max
unnecessary negative response code 78 messages.
c
The maximum value that a client uses for t /t   is at the discretion of the client, provided it is
P2*_Client P6*_Client
greater than the specified minimum value of t /t .
P2*_Client P6*_Client
d
The maximum time a client waits until it transmits the next request message is at the discretion of the client, provided
that for non-default sessions the t  timing is kept active in the server(s).
S3_Server
e
The maximum time a client waits until it transmits the next request message is at the discretion of the client, provided
that for non-default sessions the t timing is kept active in the server(s).
S3_Server
REQ 5.21 Timing parameter definition – Δt /Δt definition
P2 P6
The parameters Δt /Δt shall
...