ISO 15765-3:2004

Road vehicles - Diagnostics on Controller Area Networks (CAN) - Part 3: Implementation of unified diagnostic services (UDS on CAN)

ISO 15765-3:2004 specifies the implementation of a common set of unified diagnostic services (UDS), in accordance with ISO 14229-1, on controller area networks (CAN) as specified in ISO 11898. It gives the diagnostic services and server memory programming requirements for all in-vehicle servers connected to a CAN network and external test equipment. It does not specify any requirement for the in-vehicle CAN bus architecture.

Véhicules routiers — Diagnostic sur gestionnaire de réseau de communication (CAN) — Partie 3: Mise en oeuvre des services de diagnostic unifiés (SDU sur CAN)

General Information

• Status: Withdrawn
• Publication Date: 05-Oct-2004
• Withdrawal Date: 05-Oct-2004
• ICS: 43.040.15 - Car informatics. On board computer systems
• ICS: 43.180 - Diagnostic, maintenance and test equipment
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 2 - Vehicle diagnostic protocols
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 17-Feb-2016
• Completion Date: 13-Dec-2025

Relations

• Consolidated By: ISO 10821:2005/Amd 1:2009 - Industrial sewing machines - Safety requirements for sewing machines, units and systems - Amendment 1
• Effective Date: 06-Jun-2022
• Revised: ISO 14229-3:2012 - Road vehicles - Unified diagnostic services (UDS) - Part 3: Unified diagnostic services on CAN implementation (UDSonCAN)
• Effective Date: 15-Dec-2012

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15765-3
First edition
2004-10-15
Road vehicles — Diagnostics on
Controller Area Networks (CAN) —
Part 3:
Implementation of unified diagnostic
services (UDS on CAN)
Véhicules routiers — Diagnostic sur gestionnaire de réseau de
communication (CAN) —
Partie 3: Mise en œuvre des services de diagnostic unifiés (SDU sur
CAN)
Reference number
©
ISO 2004
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2004
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2004 – All rights reserved

Contents Page
Foreword. v
Introduction . vi
1 Scope. 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms. 2
4 Conventions . 2
5 Unified diagnostic services (UDS) applicability to OSI model . 2
6 Application and session layers . 2
6.1 Application layer services. 2
6.2 Application layer protocol. 2
6.3 Application layer and diagnostic session management timing. 2
6.3.1 General. 2
6.3.2 Application layer timing parameter definitions . 4
6.3.3 Session layer timing parameter definitions . 6
6.3.4 Client and server timer resource requirements. 6
6.3.5 Detailed timing parameter descriptions . 9
6.3.6 Error handling . 27
7 Network layer interface. 29
7.1 General information . 29
7.2 FlowControl N_PCI parameter definition.29
7.3 Mapping of A_PDU onto N_PDU for message transmission. 29
7.4 Mapping of N_PDU onto A_PDU for message reception. 29
8 Standardized diagnostic CAN identifiers .30
8.1 Legislated 11 bit OBD CAN identifiers. 30
8.2 Legislated 29 bit OBD CAN identifiers. 30
8.3 Enhanced diagnostics 29 bit CAN identifiers . 30
8.3.1 General information . 30
8.3.2 Structure of 29 bit CAN identifier . 31
8.3.3 Structure of address . 33
8.3.4 Message retrieval . 35
8.3.5 Routing. 36
9 Diagnostic services implementation. 40
9.1 Unified diagnostic services overview . 40
9.2 Diagnostic and communication control functional unit . 42
9.2.1 DiagnosticSessionControl (10 hex) service. 42
9.2.2 ECUReset (11 hex) service. 42
9.2.3 SecurityAccess (27 hex) service . 43
9.2.4 CommunicationControl (28 hex) service . 43
9.2.5 TesterPresent (3E hex) service. 43
9.2.6 SecuredDataTransmission (84 hex) service. 44
9.2.7 ControlDTCSetting (85 hex) service. 44
9.2.8 ResponseOnEvent (86 hex) service . 44
9.2.9 LinkControl (87 hex) service. 47
9.3 Data transmission functional unit . 47
9.3.1 ReadDataByIdentifier (22 hex) service. 47
9.3.2 ReadMemoryByAddress (23 hex) service . 47
9.3.3 ReadScalingDataByIdentifier(24 hex) service. 48
9.3.4 ReadDataByPeriodicIdentifier (2A hex) service .48
9.3.5 DynamicallyDefineDataIdentifier (2C hex) service.54
9.3.6 WriteDataByIdentifier (2E hex) service .54
9.3.7 WriteMemoryByAddress (3D hex) service.54
9.4 Stored data transmission functional unit .54
9.4.1 ReadDTCInformation (19 hex) service .54
9.4.2 ClearDiagnosticInformation (14 hex) service .56
9.5 Input/Output control functional unit.56
9.5.1 InputOutputControlByIdentifier (2F hex) service.56
9.6 Remote activation of routine functional unit.56
9.6.1 RoutineControl (31 hex) service .56
9.7 Upload/Download functional unit .57
9.7.1 RequestDownload (34 hex) service.57
9.7.2 RequestUpload (35 hex) service.57
9.7.3 TransferData (36 hex) service .57
9.7.4 RequestTransferExit (37 hex) service .57
10 Non-volatile server memory programming process.58
10.1 General information .58
10.2 Detailed programming sequence.61
10.2.1 Programming phase #1 — Download of application software and/or application data.61
10.2.2 Programming phase #2 — Server configuration.66
10.3 Server reprogramming requirements.69
10.3.1 Programmable servers and their categories .69
10.3.2 Requirements for all servers to support programming.70
10.3.3 Requirements for programmable servers to support programming .70
10.3.4 Software, data identification and fingerprints.74
10.3.5 Server routine access .77
10.4 Non-volatile server memory programming message flow examples .78
10.4.1 General information .78
10.4.2 Programming phase #1 — Pre-Programming step.78
10.4.3 Programming phase #1 — Programming step .79
10.4.4 Programming phase #1 — Post-Programming step.86
Annex A (normative) Network configuration dataIdentifier definitions .87
Bibliography.92

iv © ISO 2004 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 15765-3 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 15765 consists of the following parts, under the general title Road vehicles — Diagnostics on Controller
Area Networks (CAN):
 Part 1: General information
 Part 2: Network layer services
 Part 3: Implementation of unified diagnostic services (UDS on CAN)
 Part 4: Requirements for emissions-related systems

Introduction
This part of ISO 15765 has been established in order to enable the implementation of unified diagnostic
services, as specified in ISO 14229-1, on controller area networks (UDS on CAN).
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model specified in
ISO/IEC 7498 and ISO/IEC 10731, which structures communication systems into seven layers. When mapped
on this model, the services specified by ISO 15765 are divided into
 unified diagnostic services (layer 7), specified in this part of ISO 15765,
 network layer services (layer 3), specified in ISO 15765-2,
 CAN services (layers 1 and 2), specified in ISO 11898,
in accordance with Table 1.
Table 1 — Enhanced and legislated OBD diagnostic specifications applicable to the OSI layers
Open Systems Vehicle manufacturer enhanced Legislated on-board
Interconnection diagnostics diagnostics
(OSI) layers (OBD)
Diagnostic application User defined ISO 15031-5
Application layer ISO 15765-3 ISO 15031-5
Presentation layer N/A N/A
Session layer ISO 15765-3 N/A
Transport layer N/A N/A
Network layer ISO 15765-2 ISO 15765-4
Data link layer ISO 11898-1 ISO 15765-4
Physical layer User defined ISO 15765-4

vi © ISO 2004 – All rights reserved

INTERNATIONAL STANDARD ISO 15765-3:2004(E)

Road vehicles — Diagnostics on Controller Area Networks
(CAN) —
Part 3:
Implementation of unified diagnostic services (UDS on CAN)
1 Scope
This part of ISO 15765 specifies the implementation of a common set of unified diagnostic services (UDS), in
accordance with ISO 14229-1, on controller area networks (CAN) in road vehicles as specified in ISO 11898.
It gives the diagnostic services and server memory programming requirements for all in-vehicle servers
connected to a CAN network and external test equipment. It does not specify any requirement for the in-
vehicle CAN bus architecture.
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
ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical
signalling
ISO 11898-2, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit
ISO 11898-3, Road vehicles — Controller area network (CAN) — Part 3: Low-speed, fault-tolerant, medium
1)
dependent interface
ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for emissions-related
1)
diagnostics — Part 6: Diagnostic trouble code definitions
ISO 15765-1, Road vehicles — Diagnostics on controller area network (CAN) — Part 1: General information
ISO 15765-2, Road vehicles — Diagnostics on controller area network (CAN) — Part 2: Network layer
1)
service
ISO 15765-4, Road vehicles — Diagnostics on controller area network (CAN) — Part 4: Requirements for
1)
emissions-related systems
SAE J1939-21, Recommended practice for a serial control and communications vehicle network — Data link
2)
layer
1) To be published.
2) Society of Automotive Engineers standard.
3 Terms, definitions and abbreviated terms
For the purposes of this document, the terms and definitions given in ISO 14229-1, ISO 15765-1 and
ISO 15765-2 and the following abbreviated terms apply.
DA destination address
ID identifier
DLC data length code
GW gateway
LSB least significant bit
MSB most significant bit
NA network address
SA source address
SM subnet mask
TOS type of service
4 Conventions
This part of ISO 15765 is based on conventions defined in ISO 14229-1, which are guided by OSI Service
Conventions (see ISO/TR 8509) as they apply for diagnostic services.
5 Unified diagnostic services (UDS) applicability to OSI model
See Figure 1.
6 Application and session layers
6.1 Application layer services
This part of ISO 15765 uses the application layer services as defined in ISO 14229-1 for client-server based
systems to perform functions such as test, inspection, monitoring, diagnosis or programming of on-board
vehicle servers.
6.2 Application layer protocol
This part of ISO 15765 uses the application layer protocol as defined in ISO 14229-1.
6.3 Application layer and diagnostic session management timing
IMPORTANT — Any N_USData.indication with not equal to N_OK that is generated in the
server shall not result in a response message from the server application.
6.3.1 General
The following specifies the application layer and session layer timing parameters and how they are handled
for the client and the server.
2 © ISO 2004 – All rights reserved

Figure 1 — Implementation of UDS on CAN in OSI model
The following communication scenarios shall be distinguished from one another:
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 response code 78 hex, shall be considered.
The network layer services as defined in ISO 15765-2 are used to perform the application layer and diagnostic
session management timing in the client and the server.
6.3.2 Application layer timing parameter definitions
The application layer timing parameter values for the default diagnostic session shall be in accordance with
Table 2.
Table 2 — Application layer timing parameter definitions for the defaultSession
Timing Description Type Min. Max.
parameter
Timeout for the client to wait after the successful Timer reload
transmission of a request message (indicated via value P2
CAN_Server_max
a
P2 N_USData.con) for the start of incoming response + N/A
CAN_Client
messages (N_USDataFirstFrame.ind of a multi-frame ∆P2
CAN
message or N_USData.ind of a SingleFrame message).
Enhanced timeout for the client to wait after the reception Timer reload
of a negative response message with response code 78 value
P2*
CAN_Server_max
hex (indicated via N_USData.ind) for the start of incoming
b
P2* + N/A
CAN_Client
response messages (N_USDataFirstFrame.ind of a multi-
∆P2
CAN_rsp
frame message or N_USData.ind of a SingleFrame
message).
Performance requirement for the server to start with the Performance
P2 response message after the reception of a request requirement0 50 ms
CAN_Server
message (indicated via N_USData.ind).
Performance requirement for the server to start with the Performance
response message after the transmission of a negative requirement
c
P2* 0 5000 ms
CAN_Server
response message (indicated via N_USData.con) with
response code 78 hex (enhanced response timing).
Minimum time for the client to wait after the successful Timer reload
transmission of a physically addressed request message value
d
P3 (indicated via N_USData.con) with no response required P2 N/A
CAN_Client_Phys CAN_Server_max
before it can transmit the next physically addressed
request message (see 6.3.5.3).
Minimum time for the client to wait after the successful Timer reload
transmission of a functionally addressed request message value
(indicated via N_USData.con) before it can transmit the
d
P3 next functionally addressed request message in case no P2 N/A
CAN_Client_Func CAN_Server_max
response is required or the requested data is only
supported by a subset of the functionally addressed
servers (see 6.3.5.3).
a
The maximum time a client waits for a response message to start is at the discretion of the client, provided that P2 is
CAN_Client
greater than the specified minimum value of P2 .
CAN_Client
b
The value that a client uses for P2* is at the discretion of the client, provided it is greater than the specified minimum
CAN_Client
value of P2*
CAN_Client.
c
During the enhanced response timing, the minimum time between the transmission of consecutive negative messages, each with
response code 78 hex, shall be ½ P2* , with a maximum tolerance of ± 20% of P2* .
CAN_Server_max CAN_Server_max.
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
4 © ISO 2004 – All rights reserved

The parameter ∆P2 considers any system network design-dependent delays such as delays introduced by
CAN
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
a) the number of gateways involved,
b) CAN frame transmission time (baud rate),
c) CAN bus utilization, and
d) the CAN device driver implementation method (polling vs interrupt) and processing time of the network
layer.
The value of ∆P2 is divided into the time to transmit the request to the addressed server and the time to
CAN
transmit the response to the client:
∆P2 = ∆P2 + ∆P2
CAN CAN_Req CAN_Rsp
Figure 2 provides an example of how ∆P2 can be composed.
CAN
Figure 2 — Example for ∆∆∆∆P2 — SingleFrame request and response message
CAN
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.
6.3.3 Session layer timing parameter definitions
When a diagnostic session other than the defaultSession is started, then a session handling is required which
is achieved via the session layer timing parameter given in Table 3.
Table 3 — Session layer timing parameter definitions
Recommended Timeout
Timing
timeout
Description Type
parameter
ms ms
Time between functionally addressed TesterPresent (3E
hex) request messages transmitted by the client to keep a
Timer
diagnostic session other than the defaultSession active in
S3 reload 2 000 ms 4 000 ms
Client
multiple servers (functional communication) or maximum
value
time between physically transmitted request messages to a
single server (physical communication).
Time for the server to keep a diagnostic session other than Timer
S3 the defaultSession active while not receiving any diagnostic reload N/A 5 000 ms
Server
request message. value
Furthermore, the server might change its application layer timings P2 and P2* when
CAN_Server CAN_Server
transitioning into a non-default session in order to achieve a certain performance or to compensate restrictions
which might apply during a non-default diagnostic session. The applicable timing parameters for a non-default
diagnostic session are reported in the DiagnosticSessionControl positive response message in the case
where a response is required to be transmitted (see service description in 9.2.1) or have to be known in
advance by the client in case no response is required to be transmitted. When the client starts a non-default
session functionally, then it shall adapt to the timing parameters of the responding servers.
Table 4 defines the conditions for the client and the server to start/restart its S3 /S3 timer. For the
Client Server
client a periodically transmitted functionally addressed TesterPresent (3E hex) request message shall be
distinguished from a sequentially transmitted physically addressed TesterPresent (3E hex) request message,
which is only transmitted in case of the absence of any other diagnostic request message. For the server
there is no need to distinguish between that kind of TesterPresent (3E hex) handling. Furthermore, Table 4
shows that the S3 timer handling is based on the network layer service primitives, which means that the
Server
S3 timer is also restarted upon the reception of a diagnostic request message that is not supported by
Server
the server.
6.3.4 Client and server timer resource requirements
The timer resource required for the client and the server to fulfil the above given timing requirements during
the default session and any non-default session shall be in accordance with Tables 5 and 6 list. During a non-
default session, the additional timer resource requirements given in Table 6 shall apply for the client and the
server.
6 © ISO 2004 – All rights reserved

Table 4 — Session layer timing start/stop conditions for the client and the server
Timing Action Physical and functional communication, Physical communication only,
Parameter using functionally addressed, using a physically addressed,
periodically transmitted sequentially transmitted
TesterPresent request message TesterPresent request message
N_USData.con that indicates the
completion of the DiagnosticSessionControl
N_USData.con that indicates the
(10 hex) request message in case no
completion of the DiagnosticSessionControl
response is required.
Initial
(10 hex) request message. This is only true
start
N_USData.ind that indicates the reception
for if the session type is a non-default
of the DiagnosticSessionControl (10 hex)
session.
response message in case a response is
required.
S3 N_USData.con that indicates the
Client
completion of any request message in case
no response is required.
N_USData.con that indicates the
completion of the functionally addressed
N_USData.ind that indicates the reception
Subsequent
TesterPresent (3E hex) request message,
of any response message in case a
start
which is transmitted each time the S3
response is required.
Client
timer times out.
N_USData.ind that indicates an error during
the reception of a multi-frame response
message.
N_USData.con that indicates the completion of the transmission of a
DiagnosticSessionControl positive response message for a transition from the default
session to a non-default session, in case a response message is required.
Initial start
Successful completion of the requested action of the service DiagnosticSessionControl
(10 hex) for a transition from the default session to a non-default session, in case no
response message is required/allowed.
N_USDataFirstFrame.ind that indicates the start of a multi-frame request message or
Subsequent
N_USData.ind that indicates the reception of any SingleFrame request message. If the
stop
defaultSession is active, the S3 timer is disabled.
Server
N_USData.con that indicates the completion of any response message that concludes a
S3 service execution (final response message) in case a response message is
Server
required/allowed to be transmitted (this includes positive and negative response
messages). A negative response with response code 78 hex does not restart the S3
Server
timer.
Completion of the requested action (service conclusion) in case no response message
Subsequent
(positive and negative) is required/allowed.
start
N_USData.ind that indicates an error during the reception of a multi-frame request
message.
See 6.3.5.4 for further details regarding the S3 handling in the server when the server
Server
is requested to transmit unsolicited response message such as periodic data or responses
based on an event.
Table 5 — Timer resources requirements during defaultSession
Timing Client Server
parameter
A single timer is required for each logical
communication channel (physical and
P2 functional communication), e.g. each point-to- N/A
CAN_Client
point communication requires a separate
communication channel.
An optional timer might be required for the
enhanced response timing in order to ensure that
P2 N/A subsequent negative response messages with
CAN_Server
response code 78 hex are transmitted prior to the
expiration of P2* .
CAN_Server
A single timer is required per logical physical
P3 N/A
CAN_Physical
communication channel.
A single timer is required per logical functional
P3 N/A
CAN_Functional
communication channel.
Table 6 — Additional timer resources requirements during non-defaultSession
Timing Parameter Client Server
A single timer is required when using a periodically
transmitted, functionally addressed TesterPresent
(3E) hex request message to keep the servers in a N/A
non-defaultSession. There is no need for additional
timers per activated diagnostic sessions.
S3
Client A single timer is required for each point-to-point
communication channel when using a sequentially
transmitted, physically addressed TesterPresent

(3E) hex request message to keep a single server in
a non-defaultSession in case of the absence of
another diagnostic request message then.
A single timer is required in the server,
S3 N/A because only a single diagnostic session
Server
can be active at a time in a single server.

8 © ISO 2004 – All rights reserved

6.3.5 Detailed timing parameter descriptions
6.3.5.1 Physical communication
6.3.5.1.1 Physical communication during defaultSession
Figure 3 graphically depicts the timing handling in the client and the server for a physically addressed request
message during the default session.

a
The diagnostic application of the client starts the transmission of the request message by issuing a N_USData.req to
its network layer. The network layer transmits the request message to the server. The request message can either be a
single-frame message or a multi-frame message.
b
In the case of a multi-frame message, the start of the request is indicated in the server via N_USDataFF.ind that is
issued by its network layer.
c
The completion of the request message is indicated in the client via N_USData.con. When receiving the
N_USData.con the client starts its P2 timer, using the default reload value P2 . The value of the
CAN_Client CAN_Client
P2 timer shall consider any latency that is involved based on the vehicle network design (communication over
CAN_Client
gateways, bus bandwidth, etc.). For simplicity, the figure assumes that the client and the server are located on the same
network.
d
The completion of the request message is indicated in the server via the N_USData.ind.
e
The server is required to start with its response message within P2 after the reception of N_USData.ind.
CAN_Server
This means that, in the case of a multi-frame response message, the FirstFrame shall be sent within P2 and, for
CAN_Server
single-frame response messages, that the SingleFrame shall be sent within P2 .
CAN_Server
f
In the case of a multi-frame response message, the reception of the FirstFrame is indicated in the client via the
N_USDataFF.ind of its network layer. When receiving the FirstFrame indication, the client stops its P2 timer.
CAN_Client
g
The network layer will generate a final N_USData.ind in case the complete message is received or an error occurred
during the reception. In case of a single-frame response message, the reception of the SingleFrame is indicated in the
client via a single N_USData.ind. When receiving this single frame indication, the client stops its P2 timer.
CAN_Client
h
The completion of the response message is indicated in the server via N_USData.con.
Figure 3 — Physical communication during default session
6.3.5.1.2 Physical communication during defaultSession with enhanced response timing
Figure 4 graphically depicts the timing handling in the client and the server for a physically addressed request
message during the default session and the request of the server for an enhanced response timing (negative
response code 78 hex handling).

a
The diagnostic application of the client starts the transmission of the request message by issuing a N_USData.req to
its network layer. The network layer transmits the request message to the server. The request message can either be a
single-frame or multi-frame message.
b
In the case of a multi-frame message, the start of the request is indicated in the server via N_USDataFF.ind that is
issued by its network layer.
c
The completion of the request message is indicated in the client via N_Usdata.con. When receiving the
N_USData.con, the client starts its P2 timer, using the default reload value P2 . The value of the
CAN_Client CAN_Client
P2 timer shall consider any latency that is involved based on the vehicle network design (e.g. communication
CAN_Client
over gateways, bus bandwidth, etc.). For simplicity, the figure assumes that the client and the server are located on the
same network.
d
The completion of the request message is indicated in the server via N_USData.ind.
10 © ISO 2004 – All rights reserved

e
The server is required to start with its response message within P2 after the reception of N_USData.ind.
CAN_Server
This means that, in the case of a multi-frame response message, the FirstFrame shall be sent within P2 and, for
CAN_Server
single-frame response messages, that the SingleFrame shall be sent within P2 .
CAN_Server
f
In case the server cannot provide the requested information within the P2 response timing, it can request an
CAN_Server
enhanced response timing window by sending a negative response message including response code 78 hex. Upon
reception of the negative response message within the client, the client network layer generates a N_USData.ind. The
reception of a negative response message with response code 78 hex causes the client to restart its P2 timer,
CAN_Client
but using the enhanced reload value P2* .
CAN_Client
g
The server is required to start with its response message within the enhanced P2 (P2* ) following
CAN_Server CAN_Server
the N_USData.con of the transmitted negative response message. In case the server can still not provide the requested
information within the enhanced P2* , then a further negative response message including response code 78 hex
CAN_Server
can be sent by the server. This will cause the client to restart its P2 timer, using the enhanced reload value
CAN_Client
P2* . For simplicity, the figure only shows a single negative response message with response code 78 hex.
CAN_Client
h
Once the server can provide the requested information (positive or negative response other than response code 78
hex), it starts with its final response message.
i
In the case of a multi-frame final response message, the reception of the FirstFrame is indicated in the client via the
N_USDataFF.ind of the network layer. When receiving the FirstFrame indication, the client stops its P2 timer.
CAN_Client
j
The network layer of the client will generate a final N_USData.ind in case the complete message is received or an
error occurred during the reception. In the case of a single-frame response message, the reception of the SingleFrame is
indicated in the client via a single N_USData.ind. When receiving this single-frame indication, the client stops its
P2 timer.
CAN_Client
k
The completion of the transmission will also be indicated in the server via N_USData.con.
Figure 4 — Physical communication during non-default session — Enhanced response timing

6.3.5.1.3 Physical communication during a non-default session
6.3.5.1.3.1 Functionally addressed TesterPresent (3E hex) message
Figure 5 graphically depicts the timing handling in the client and the server when performing physical
communication during a non-default session (e.g. programmingSession) and using a functionally addressed,
periodically transmitted TesterPresent (3E hex) request message that does not require a response message
from the server.
The handling of the P2 and P2 timing is identical to the handling as described in 6.3.5.1.1
CAN_Client CAN_Server
and 6.3.5.1.2. The only exception is that the reload values on the client side and the resulting time where the
server shall send its final response time might differ. This is based on the transition into a session other than
the default session where different P2 timing parameters might apply (see DiagnosticSessionControl
CAN_Client
(10 hex) service in 9.2.1 for details on how the timing parameters are reported to the client).
12 © ISO 2004 – All rights reserved

a
The diagnostic application of the client starts the transmission of the DiagnosticSessionControl (10 hex) request
message by issuing a N_USData.req to its network layer. The network layer transmits the request message to the server.
b
The request message is a single-frame message. Its completion is indicated in the client via the N_USData.con. Now
the response timing as described in 6.3.5.1.1 and 6.3.5.1.2 applies. The generated N_USData.con in the client causes the
start of the S3 timer (session timer).
Client
c
The completion of the request message is indicated in the server via the N_USData.ind. Now the response timing as
described in 6.3.5.1.1 and 6.3.5.1.2 applies.
d
For the figure given, it is assumed that the client requires a response from the server. The server shall transmit the
DiagnosticSessionControl (10 hex) positive response message.
e
The completion of the transmission of the response message is indicated in the server via N_USData.con. Now the
server starts its S3 timer, which keeps the activated non-default session active as long as it does not time out. It is
Server
the client's responsibility to ensure that the S3 timer is reset prior to its timeout to keep the server in the non-default
Server
session.
f
Once the S3 timer is started in the client, this causes the transmission of a functionally addressed TesterPresent
Client
(3E hex) request message, which does not require a response message, each time the S3 timer times out.
Client
g
Upon the indication of the completed transmission of the TesterPresent (3E hex) request message via N_USData.con
of its network layer, the client once again starts its S3 timer. This means that the functionally addressed TesterPresent
Client
(3E hex) request message is sent on a periodic basis every time S3 times out.
Client
h
Any time the server is in the process of handling any diagnostic service, it stops its S3 timer.
Server
i
When the diagnostic service is completely processed, then the server restarts its S3 timer. This means that any
Server
diagnostic service, including TesterPresent (3E hex), resets the S3 timer. A diagnostic service is meant to be in
Server
progress any time between the start of the reception of the request message (N_USDataFF.ind or N_USData.ind receive)
and the completion of the transmission of the final response message, where a response message is required, or the
completion of any action that is caused by the request, where no response message is required (point in time reached that
would cause the start of the response message).
j
Any TesterPresent (3E hex) request message that is received during processing another request message can be
ignored by the server, because it has already stopped its S3 timer and will restart it once the service that is in

Server
progress is processed completely.
Figure 5 — Physical communication during non-default session – functionally addressed
TesterPresent
6.3.5.1.3.2 Physically addressed TesterPresent (3E hex) message
Figure 6 graphically depicts the timing handling in the client and the server when performing physical
communication during a non-default session (e.g. programmingSession) and using a physically addressed
TesterPresent (3E hex) request message that requires a response message from the server to keep the
diagnostic session active in case of the absence of any other diagnostic service.

14 © ISO 2004 – All rights reserved

a
The diagnostic application of the client starts the transmission of the DiagnosticSessionControl (10 hex) request
message by issuing a N_USData.req to its network layer. The net
...