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 2013
©  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

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

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

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
(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

vi © ISO 2013 – All rights reserved

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.
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

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
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

Message
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
S_Data.req
T_Data.req
T_DataSOM.ind
S_Data.con T_Data.con T_Data.ind S_Data.ind

Key
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.
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

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.
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

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).
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

Table 3 — Message timing parameter definitions for the defaultSession
Timing Description Type
parameter
The ∆P2 parameter is defined to be the worst case vehicle network design-dependent Performance
requirement
message transmission delay such as delays introduced by gateways and bus-load
dependent arbitration. The value of ∆P2 is divided into the time to transmit the request to
∆P2
the addressed server/ECU (∆P2 ) and in case the protocol supports T_DataSOM.ind
request
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).
The ∆P6 parameter is defined to be the worst case vehicle network design-dependent Performance
requirement
message transmission delay such as delays introduced by gateways and bus-load
dependent arbitration. The value of ∆P6 is divided into the time to transmit the request to
∆P6 the addressed server/ECU (∆P6 ) and the time to transmit the complete response to
request
the client/tester (∆P6 ). The ∆P6 is independent of whether a protocol supports a
response
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 after the Performance
P2
Server
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 Timer reload
P2 (indicated via T_Data.con) for the start of incoming response messages (indicated via value
Client
T_DataSOM.ind of a multi-frame message or T_Data.ind of a SingleFrame message).
Timeout for the client to wait after the successful transmission of a request message Timer reload
P6 (indicated via T_Data.con) for the complete reception of the corresponding response value
Client
message (indicated via T_Data.ind) e.g. ISO 13400 DoIP.
Performance requirement for the server to start with the response message after the Performance
P2* transmission of a negative response message (indicated via T_Data.con) with negative requirement
Server
response code 0x78 (enhanced response timing).
Enhanced timeout for the client to wait after the reception of a negative response Timer reload
message with negative response code 0x78 (indicated via T_Data.ind) for the start of value
P2*
Client
incoming response messages (indicated via T_DataSOM.ind of a multi-frame message or
T_Data.ind of a SingleFrame message).
Enhanced timeout for the client to wait after the reception of a negative response Timer reload
message with negative response code 0x78 (indicated via T_Data.ind) for the complete value
P6*
Client
reception of the corresponding response messages (indicated via T_Data.ind) e.g.
ISO 13400 DoIP.
Minimum time for the client to wait after the successful transmission of a physically Timer reload
P3 addressed request message (indicated via T_Data.con) with no response required before value
Client_Phys
it can transmit the next physically addressed request message (see Figure 19).
Minimum time for the client to wait after the successful transmission of a functionally Timer reload
addressed request message (indicated via T_Data.con) before it can transmit the next value
P3
Client_Func
functionally addressed request message in case no response is required or the requested
data is only supported by a subset of the functionally addressed servers (see 8.3).
This is the time between the reception of a request (T_Data.indication) and the start of the Performance
P4
Server
transmission of the final response (T_Data.request) at the server side. requirement

Each server/ECU shall be able to process a new request message immediately after the successful
transmission of a response message (T_Data.con) 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.
Table 4 — Message timing parameter value definitions for the defaultSession
Timing parameter Minimum Maximum
vehicle manufacturer specific value
∆P2 0 ms
∆P2 + ∆P2
request response
vehicle manufacturer specific value
∆P6 0 ms
∆P6 + ∆P6
request response
server specific value
P2 0 ms
Server
recommended value: 50 ms
a)
P2 P2 + ∆P2 ---
Client Server_max max
a)
P6 P2 + ∆P6 ---
Client Server_max max
server specific value
b)
P2* 0 ms
Server
recommended value: 5 000 ms
c)
P2* P2* + ∆P2 ---
Client Server_max response
c)
P6* + ∆P6 ---
Client P2*Server_max response
d)
P3 P2 + ∆P2 ---
Client_Phys Server_max max
d)
P3 ---
Client_Func P2Server_max + ∆P2max
As defined by leglislation for OBD diagnostic use cases.
P4 P2
Server Server
Vehicle manufacturer specific value for enhanced diagnostic use
cases.
a
The maximum time a client waits for a response message is at the discretion of the client, provided that P2 / P6 is greater
Client Client
than the specified minimum value of P2 / P6 .
Client Client
b
During the enhanced response timing, the minimum time between the transmission of consecutive negative messages (each with
negative response code 0x78) shall be 0.3 * P2* , in order to avoid flooding the data link with unnecessary negative response
Server_max
code 0x78 messages.
c
The maximum value that a client uses for P2* / P6* is at the discretion of the client, provided it is greater than the specified
Client Client
minimum value of P2* / P6* .
Client 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 S3 timing is kept active in the server(s).
Server
The parameter ∆P2/∆P6 considers any system network design-dependent delays such as delays introduced
by gateways and bus bandwidth plus a safety margin (e.g. 50 % of worst case). The worst-case scenario
(transmission time necessary for one “round trip” from client to server and back from server to client), based
on system design, is impacted by
 the number of gateways involved,
 frame transmission time (baud rate),
 bus utilization, and
 the device driver implementation method (polling vs. interrupt) and processing time of the
transport/network layer.
The value of ∆P2/∆P6 is divided into the time to transmit the request to the addressed server and the time to
transmit the response to the client:
∆P2 = ∆P2 + ∆P2
Request Response
∆P6 = ∆P6 + ∆P6
Request Response
12 © ISO 2013 – All rights reserved

Figure 4 and Figure 5 provides an example of how ∆P2 and ∆P6 can be composed.

Key
1 Client T_Data.req: diagnostic application issues a request message to the transport/network layer.
2 Server T_DataSOM.ind: transport/network layer issues to diagnostic application the StartOfMessage of the request message.
3 Client T_Data.con: transport/network layer issues to diagnostic application the confirmation of the completion of the request
message. Client starts its P timer using the default reload value P2 = P2 . The value of the P timer shall consider
Client Client Client_max Client
any latency that is involved based on the vehicle network design (communication over gateways, bus bandwidth, etc.).
4 Server T_Data.ind: transport/network layer issues to diagnostic application the completion of the request message. Server starts
the P2 timer using the default value of P2 = P2 .
Server Server Server_max
5 Server T_Data.req: diagnostic application has prepared the response message and issues a T_Data.req to transport/network layer
within P2Server. Server stops the P2Server timer.
6 Client T_DataSOM.ind: transport/network layer issues to diagnostic application the StartOfMessage of the response message.
Client stops its P timer.
Client
7 Server T_Data.con: transport/network layer issues to diagnostic application the completion of the response message.
8 Client T_Data.ind: transport/network layer issues a T_Data.ind to diagnostic application to confirm the completion of the response
message.
Figure 4 — Example for ∆P2 and ∆P6 – Response message with SOM.ind

Key
1 Client T_Data.req: diagnostic application issues a request message to the transport/network layer.
2 Server T_DataSOM.ind: transport/network layer issues to diagnostic application the StartOfMessage of the request message.
3 Client T_Data.con: transport/network layer issues to diagnostic application the confirmation of the completion of the request
message. Client starts its P timer using the default reload value P6 = P6 . The value of the P timer shall consider
Client Client Client_max Client
any latency that is involved based on the vehicle network design (communication over gateways, bus bandwidth, etc.).
4 Server T_Data.ind: transport/network layer issues to diagnostic application the completion of the request message. Server starts
the P2 timer using the default value of P2 = P2 .
Server Server Server_max
5 Server T_Data.req: diagnostic application has prepared the response message and issues a T_Data.req to transport/network layer
within P2 . Server stops the P2 timer.
Server Server
6 Server T_Data.con: transport/network layer issues to diagnostic application the completion of the response message.
7 Client T_Data.ind: transport/network layer issues a T_Data.ind to diagnostic application to confirm the completion of the response
message. Client stops its P timer.
Client
Figure 5 — Example for ∆P2 and ∆P6 – Response message without SOM.ind

NOTE For the sake of simplicity in describing the timing parameters, in all the figures that follow it is assumed that
the client and the server are located on the same network. All descriptions and figures are presented in a time-related
sequential order.
14 © ISO 2013 – All rights reserved

7.3 Example for P4Server without enhanced response timing
Figure 6 shows an example where P4 P2 . In this scenario the server response performance timing
Server = Server
parameter indicates that no negative responses including NRC 0x78 are allowed.

Key
1 Client T_Data.req: diagnostic application issues a request message to the transport/network layer.
2 Server T_Data.ind: transport/network layer issues to diagnostic application the completion of the request message. Server starts
the P2 timer using the default value of P2 = P2 and the P4 timer using the default value of P4 = P4 .
Server Server Server_max Server Server Server_max
If P4 = P2 applies for a certain T_Data.ind, the server shall ensure that the final positive or negative response is started
Server Server
prior to P2 timer expiration (i.e. no negative responses with NRC 0x78 are allowed).
Server
Client T_Data.con: transport/network layer issues to diagnostic application the confirmation of the completion of the request
message. Client starts its P timer using the default reload value P2 = P2 . The value of the P timer shall consider
Client Client Client_max Client
any latency that is involved based on the vehicle network design (communication over gateways, bus bandwidth, etc.).
3 Server T_Data.req: diagnostic application has prepared the response message and issues a T_Data.req to transport/network layer
within P2 . Server stops the P2 timer.
Server Server
The P4 performance timer is stopped.
Server
4 Client T_DataSOM.ind: transport/network layer issues to diagnostic application the reception of a StartOfMessage. Client stops
the P timer.
Client
5 Server T_Data.con: transport/network layer issues to diagnostic application the completion of the response message.
Client T_Data.ind: transport/network layer issues to diagnostic application the completion of the response message.
Figure 6 — Example for P4 without enhanced response timing
Server
neg. response response
NRC=0x78 message
request
7.4 Example for P4Server with enhanced response timing
Figure 7 shows an example where P4Server > P2Server. In this scenario the server response performance
timing parameter indicates that negative responses including NRC 0x78 are allowed as long as P4 is not
Server
exceeded.
Start
Client Server
T_Data T_Data
P Stop
Client
(with
P4
Server
SOM.ind)
P2
Server performance
1 .req
P2
Server P4
P2 Server
Client
2 .con .ind
3 .ind .req
P2* P2*
Client Server
4 .ind .con
5 .req
6 SOM.ind
7 .ind .con
time time
Key
1 Client T_Data.req: diagnostic application issues a request message to the transport/network layer.
2 Server T_Data.ind: transport/network layer issues to diagnostic application the completion of the request message. Server starts
the P2Server timer using the default value of P2Server = P2Server_max and the P4Server timer using the default value of P4Server = P4Server_max.
If P4 > P2 applies for a certain T_Data.ind, the server shall ensure that the final positive or negative response is started
Server Server
prior to P2 timer expiration (i.e. negative responses with NRC 0x78 are allowed as long as P4 is not exceeded).
Server Server
Client T_Data.con: transport/network layer issues to diagnostic application the confirmation of the completion of the request
message. Client starts its P timer using the default reload value P2 = P2 . The value of the P timer shall consider
Client Client Client_max Client
any latency that is involved based on the vehicle network design (communication over gateways, bus bandwidth, etc.).
3 Server T_Data.req: diagnostic application does not have the positive response message ready and issues negative response
message with NRC = 0x78 by a T_Data.req to transport/network layer within P2 . Server stops the P2 timer.
Server Server
Client T_Data.ind: transport/network layer issues to diagnostic application the reception of a response message. Client stops the
PClient timer.
4 Server T_Data.con: transport/network layer issues to diagnostic application the completion of the response message. Server
starts the P2 timer using the value of P2* = P2* (default enhanced timing).
Server Server Server_max
16 © ISO 2013 – All rights reserved

In case the server can still not provide the requested information within the enhanced P2* , then a further negative response
Server
message including negative response code 0x78 can be sent by the server. This will cause the client to restart its P timer, using
...