ISO 15765-4:2021

Road vehicles - Diagnostic communication over Controller Area Network (DoCAN) - Part 4: Requirements for emissions-related systems

This document specifies requirements for CAN-based communication systems between the in-vehicle network and the diagnostic link connector of the vehicle. This document does not specify any requirements related to the in-vehicle CAN network architecture. This document specifies the requirements to enable the in-vehicle CAN-based communication systems to establish, maintain, and terminate communication with the devices connected to the diagnostic link connector.

Véhicules routiers — Diagnostic sur gestionnaire de réseau de communication (DoCAN) — Partie 4: Exigences applicables aux systèmes associés aux émissions

General Information

• Status: Published
• Publication Date: 29-Jul-2021
• 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: 6060 - International Standard published
• Start Date: 30-Jul-2021
• Due Date: 29-Apr-2022
• Completion Date: 30-Jul-2021

Relations

• Revises: ISO 15765-4:2016 - Road vehicles - Diagnostic communication over Controller Area Network (DoCAN) - Part 4: Requirements for emissions-related systems
• Effective Date: 23-Apr-2020

Overview

ISO 15765-4:2021 - part of the ISO 15765 series on Diagnostic communication over Controller Area Network (DoCAN) - defines requirements for CAN‑based communication between a vehicle’s in‑vehicle network and the diagnostic link connector, specifically for emissions‑related systems. It specifies how CAN‑based systems should establish, maintain and terminate diagnostic communication with devices connected to the diagnostic link connector. The document does not prescribe in‑vehicle CAN network architecture; instead it focuses on protocol, timing, addressing and test‑equipment requirements needed to ensure interoperable emissions diagnostics.

Key Topics and Technical Requirements

• Scope of DoCAN for emissions: Requirements specific to On‑Board Diagnostics using OBDonUDS and OBDonEDS application protocols for emissions systems.
• OSI layering mapped to DoCAN: Requirements and framework for the Application, Session, Transport, Network, Data Link and Physical layers (layers 7–1 as applicable).
• Protocol identification: Procedures for vehicle and external test equipment to identify OBDonUDS and OBDonEDS operation modes.
• Bit rate validation: Procedures and records to validate CAN bit rates (including nominal bit rates such as 250 kbit/s and 500 kbit/s) and external test equipment timing.
• CAN identifier validation and addressing: Rules for mapping diagnostic addresses, functional vs. physical addressing, and handling of 11‑bit and 29‑bit CAN identifiers.
• Timing and flow control: Network layer timing parameters, flow control definitions and updated timeout values (notably changed timeout values to 33 ms in this edition).
• External test equipment (ETE) requirements: Electrical and cable parameters, interface propagation delays, and error detection provisions for diagnostic tools.
• Support for ECUNAME reporting: Requirements for reporting ECU identity strings to assist diagnostics and test equipment.
• Document changes in 2021 edition: Technical revisions include renaming of time‑related parameters and clarifications on acceptance of physically addressed request messages.

Applications - Who Uses ISO 15765-4:2021

• Automotive OEMs and ECU suppliers implementing compliant emissions diagnostic interfaces.
• Diagnostic tool and external test equipment manufacturers ensuring interoperability with vehicle diagnostics.
• Emissions testing labs and regulatory bodies verifying OBD communications during vehicle approval and inspection.
• Automotive test engineers and system integrators designing CAN‑based diagnostic links for emissions systems.

Practical benefits include standardized OBD communications for emissions compliance, reliable tool‑to‑vehicle interoperability, and clear electrical/timing requirements for test and service equipment.

Related Standards

• ISO 15765-2 (Transport protocol & network layer services)
• ISO 11898-1 / ISO 11898-2 (CAN data link and physical signalling)
• ISO 14229-2 (UDS session services)
• ISO 15031-3 (Diagnostic connector and related circuits)

Keywords: ISO 15765-4:2021, DoCAN, Diagnostic communication over CAN, OBDonUDS, OBDonEDS, emissions-related systems, diagnostic link connector, CAN identifier validation, bit rate validation, external test equipment.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15765-4
Fourth edition
2021-07
Road vehicles — Diagnostic
communication over Controller Area
Network (DoCAN) —
Part 4:
Requirements for emissions-related
systems
Véhicules routiers — Diagnostic sur gestionnaire de réseau de
communication (DoCAN) —
Partie 4: Exigences applicables aux systèmes associés aux émissions
Reference number
©
ISO 2021
© 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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved

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 . 3
5 Conventions . 4
6 Application . 4
6.1 Vehicle communication initialisation sequence . 4
6.1.1 OBDonUDS protocol identification . 4
6.1.2 OBDonEDS protocol identification . 4
6.1.3 Others . 4
6.2 External test equipment communication initialisation sequence . 4
6.3 Bit rate validation procedure . 5
6.3.1 bitrateRecord . 5
6.3.2 Bit rate validation . 5
6.3.3 External test equipment error detection provisions . 6
6.4 CAN identifier validation procedure . 7
6.4.1 CAN identifier validation procedure OBDonEDS . 7
6.4.2 CAN identifier validation procedure OBDonUDS . 9
6.5 Support of ECUNAME reporting.11
7 Application layer (AL) .11
8 Session layer (SL) .12
9 Transport layer (TL) .12
10 Network layer (NL) .12
10.1 General .12
10.2 Parameter definitions .12
10.2.1 Timing parameter values .12
10.2.2 Definition of flow control parameter values .13
10.2.3 Maximum number of OBDonUDS or OBDonEDS ECUs .14
10.3 Addressing formats .15
10.3.1 Normal and normal fixed addressing format .15
10.3.2 Functional addressing .15
10.3.3 Physical addressing .15
10.4 CAN identifier requirements .16
10.4.1 External test equipment .16
10.4.2 OBDonUDS or OBDonEDS server/ECU .16
10.5 Mapping of diagnostic addresses .16
10.5.1 OBDonUDS/OBDonEDS CAN identifiers .16
10.5.2 11-bit CAN identifiers .17
10.5.3 29-bit CAN identifiers .18
11 Data link layer (DLL) .18
12 Physical layer (PHY) .18
12.1 General .18
12.2 Bit rates .19
12.3 CAN bit timing .19
12.3.1 Parameter values .19
12.3.2 Nominal bit rate 250 kbit/s .20
12.3.3 Nominal bit rate 500 kbit/s .20
12.4 External test equipment .21
12.4.1 Electrical parameters .21
12.4.2 Cable parameters . .24
Bibliography .25
iv © ISO 2021 – 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.
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 fourth edition cancels and replaces the third edition (ISO 15765-4:2016), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— changed all time-related parameters to t ;
Parameter_Name
— corrected all occurrences of ⊣⫤ P2 and changed to Δt ;
CAN_max P2_CAN_Client_Max
— Clause 6 title has been changed to application;
— subclause 6.1 title has been changed to vehicle communication initialisation sequence;
— subclause 6.2 title has been changed to external test equipment communication initialisation
sequence;
— changed N_As to t and changed timeout value to 33 ms;
N_As
— changed N_Ar to t and changed timeout value to 33 ms;
N_Ar
— added clarification in 10.3.3 regarding the acceptance of physically addressed request messages.
A list of all parts in the ISO 15765 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.
Introduction
This document has been established in order to define common requirements for vehicle diagnostic
systems implemented on a controller area network (CAN) communication link, as specified in
ISO 11898-1 and ISO 11898-2. Although primarily intended for diagnostic systems, it also meets
requirements from other CAN-based systems needing a network layer protocol.
To achieve this, it is based on the Open Systems Interconnection (OSI) basic reference model specified
in ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers.
When mapped on this model, the application protocol and lower OSI layers framework requirements
specified/referenced in the ISO 15765 series are structured according to Figure 1.
Figure 1 illustrates a standards-based documentation concept, which consists of the lower OSI layers
framework, which specifies requirements related to the transport layer, network layer, data link layer
and physical layer standards of the OSI layers 4, 3, 2, and 1.
Figure 1 — DoCAN related OSI layers framework
vi © ISO 2021 – All rights reserved

INTERNATIONAL STANDARD ISO 15765-4:2021(E)
Road vehicles — Diagnostic communication over
Controller Area Network (DoCAN) —
Part 4:
Requirements for emissions-related systems
1 Scope
This document specifies requirements for CAN-based communication systems between the in-
vehicle network and the diagnostic link connector of the vehicle. This document does not specify
any requirements related to the in-vehicle CAN network architecture. This document specifies the
requirements to enable the in-vehicle CAN-based communication systems to establish, maintain, and
terminate communication with the devices connected to the diagnostic link connector.
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 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 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 15031-3, Road vehicles — Communication between vehicle and external equipment for emissions-
related diagnostics — Part 3: Diagnostic connector and related electrical circuits: Specification and use
ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2:
Transport protocol and network layer services
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1, ISO 11898-1,
ISO 11898-2, ISO 15765-2 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
OBDonEDS
on-board diagnostics on emission diagnostic service
[4]
application protocol request and response messages defined in ISO 15031-5/SAE J1979 dedicated to
the diagnostics of emissions-related systems
3.2
OBDonUDS
on-board diagnostics on unified diagnostic service
application protocol request and response messages defined in the ISO 14229 series and in ISO 27145-3
[5]
or SAE J1979-2 dedicated to the diagnostics of emissions-related systems
4 Symbols and abbreviated terms
4.1 Symbols
— empty table cell or feature undefined
B block size
S
C , C capacitance of AC termination
AC1 AC2
C capacitance between CAN_H and ground potential
CAN_H
C capacitance between CAN_L and ground potential
CAN_L
C capacitance between CAN_H and CAN_L
DIFF
ΔO oscillator frequency tolerance
F
F consecutive frame
CF
F flow control frame
FC
F first frame
FF
F frame flow status
FS
F single frame
SF
l maximum cable length between diagnostic link connector and external test
CABLE
equipment
R , R resistance of AC termination
AC1 AC2
t bit time
BIT
t receive bit time
BIT_RX
t transmit bit time
BIT_TX
t external test equipment CAN interface propagation delay (without external test
ETE
equipment cable delay)
t external test equipment cable propagation delay (without external test equip-
ETE_CABLE
ment CAN interface delay)
t network layer timeout value (see ISO 15765-2)
N_Ar
t network layer timeout value (see ISO 15765-2)
N_As
t network layer timeout value (see ISO 15765-2)
N_Br
t network layer timeout value (see ISO 15765-2)
N_Bs
2 © ISO 2021 – All rights reserved

t network layer timeout value (see ISO 15765-2)
N_Cs
t network layer timeout value (see ISO 15765-2)
N_Cr
t client application wait time on server response on CAN
P2_CAN_Client
t timeout value of the client application to receive a response on a request mes-
P2_CAN_Client_Max
sage
t is the performance timing of the server to prepare the response information
P2_CAN_Server
t is the timeout value of the server to respond on a request message
P2_CAN_Server_Max
t nominal sample point position time
SP
t timing segment 1
SEG1
t timing segment 2
SEG2
t resynchronization jump width time
SJW
t synchronization segment time
SYNCSEG
t frame separation time
STmin
t time quantum
Q
4.2 Abbreviated terms
CAN controller area network
CBFF Classical Base Frame Format
DID data identifier
DLC data length code
DoCAN diagnostic communication over CAN
ECU electronic control unit
ECM engine control module
ETE external test equipment
OBD on-board diagnostics
PID parameter identifier
PhaseSeg1 phase segment 1
PhaseSeg2 phase segment 2
PropSeg propagation segment
SA source address
SJW synchronisation jump width
SP nominal sample point
SyncSeg synchronization segment
TA target address
TCM transmission control module
5 Conventions
This document is based on OSI service conventions as specified in ISO/IEC 10731.
6 Application
6.1 Vehicle communication initialisation sequence
6.1.1 OBDonUDS protocol identification
Vehicles that support OBDonUDS shall have ECUs that reply to the functional request service identifier
22 and DID F810 for protocol identification.
16 16
6.1.2 OBDonEDS protocol identification
Vehicles that support OBDonEDS shall have ECUs that reply to the functional request service identifier
01 and PID 00 for protocol identification.
16 16
6.1.3 Others
Vehicles that do not respond to either request (6.1.1, 6.1.2) do not support OBD diagnostics specified in
this document.
6.2 External test equipment communication initialisation sequence
The external test equipment shall support the initialisation sequence specified in this document.
The purpose of the external test equipment initialisation sequence is to automatically detect whether
the vehicle supports OBDonUDS or OBDonEDS using CAN as the physical layer specified in Clause 12.
Furthermore, the initialisation sequence determines the communication conformance status of vehicles
by analysing their responses as specified in 6.1.1 and 6.1.2.
For each OBDonUDS or OBDonEDS service that requires the determination of “supported” information,
the external test equipment updates its list of expected responding ECUs prior to any data parameter
requests.
The external test equipment initialisation sequence supports single bit rate initialisation (e.g.
500 kbit/s) and multiple bit rate initialisation (e.g. 250 kbit/s and 500 kbit/s) and is separated into the
following tests:
a) 11-bit CAN identifier validation (see 6.4.1 and 6.4.2);
b) 29-bit CAN identifier validation (see 6.4.1 and 6.4.2).
The external test equipment initialisation sequence shall contain provisions for legacy vehicles using
either CAN or a non-CAN protocol on the CAN pins of the ISO 15031-3 diagnostic link connector.
4 © ISO 2021 – All rights reserved

6.3 Bit rate validation procedure
6.3.1 bitrateRecord
The parameter “bitrateRecord” contains the bit rates as specified in 12.2.
The bitrateRecord shall be used to specify the type of initialisation to be performed. If the bitrateRecord
parameter contains a single bit rate, then a single bit rate initialisation sequence shall be performed
using the specified single bit rate (e.g. 500 kbit/s). If the bitrateRecord parameter contains multiple bit
rates, then a multiple bit rate initialisation sequence shall be performed including a bit rate detection
procedure as defined in Figure 2.
Figure 2 shall be performed using the specified multiple bit rates (e.g. 250 kbit/s and 500 kbit/s). The
external test equipment shall use the appropriate CAN bit timing parameter values specified in 12.3.
6.3.2 Bit rate validation
If multiple bit rates are specified in the bitrateRecord parameter, the procedure as defined in Figure 2
shall be used to determine the bit rate to be used in communication with the vehicle's emissions-related
system.
The external test equipment shall set up its CAN interface using the first bit rate contained in the
bitrateRecord. It shall use the CAN bit timing parameter values specified for this bit rate (see 6.3).
Key
a
Following the CAN interface setup, the external test equipment shall connect to the CAN network and transmit
a functionally addressed request message with service identifier 01 and PID "supported PIDs" using the
OBDonEDS 11-bit functional request CAN identifier as defined in 10.5.2.
NOTE The immediate transmission is needed in order to activate the CAN error frame monitoring, since
initialising the CAN controller at the wrong bit rate without transmitting any data can leave the CAN controller
in a state of generating error frames on the CAN network.
b
The external test equipment shall check for any CAN error frame. If the request message is successfully
transmitted onto the CAN network, the external test equipment shall indicate a successful transmission and
proceed with the validation of the CAN identifier as specified in 6.4.1.
c
If an acknowledge (ACK) check error is detected, then the external test equipment shall continue to retry the
transmission of the request message until the t timeout has elapsed.
N_As
d
If any other CAN error frame occurred, or an acknowledge check error still occurs after the t timeout has
N_As
elapsed, then the external test equipment shall stop CAN communication on the CAN network.
e
Proceed with sequence according to Figure 3, key 'a'.
f
The external test equipment shall check whether more bit rates are contained in the bitrateRecord. If the end
of the bitrateRecord is not reached, the external test equipment shall set up its CAN interface using the next
bit rate in the bitrateRecord and restart the bit rate validation at key 'a' in Figure 2. If no further bit rate is
contained in the bitrateRecord, it shall be assumed that the request was not transmitted successfully. This
indicates that the vehicle does not comply with this document.
Figure 2 — Perform bit rate validation
6.3.3 External test equipment error detection provisions
Where the vehicle uses a physical layer different from that specified for OBDonEDS and OBDonUDS
(see Clause 12) or a non-CAN protocol on the CAN pins of the diagnostic link connector, the transmit
procedure, specified in this document, shall guarantee that in all cases, the external test equipment
6 © ISO 2021 – All rights reserved

shall detect that the vehicle does not support CAN as specified for OBDonUDS or OBDonEDS and shall
stop the transmission of the request message immediately.
Where the vehicle uses CAN and the physical layer in accordance with Clause 12, the transmit
procedure given as follows shall guarantee that in all cases, the external test equipment shall detect
that it uses the wrong bit rate for the transmission of the request message and shall stop disturbing
the CAN network. Under normal in-vehicle conditions (i.e. no error frames shall occur during in-vehicle
communication when the external test equipment is disconnected), the external test equipment shall
stop communication on the CAN network prior to the situation where the internal error counters of the
OBDonUDS or OBDonEDS ECU(s) reach critical values.
To achieve this, the external test equipment shall implement the following provisions:
— possibility to immediately stop sending during transmission of any CAN frame;
— the CAN interface should be disconnected within 12 µs from reception of a data frame error
signal. The maximum time for the disconnection is 100 µs;
— with the CAN interface disconnected, the external test equipment shall not be able to transmit
dominant bits on the CAN network;
— possibility to immediately detect any CAN error frame on the CAN network.
The second provision implies that the external test equipment cannot solely rely on the usual CAN
controller error handling since it does most likely flag a CAN error frame only after the “bus-off” state
has been reached (refer to ISO 11898-1 for further details).
6.4 CAN identifier validation procedure
6.4.1 CAN identifier validation procedure OBDonEDS
A functionally addressed service identifier 01 and PID 00 request using the OBDonEDS 11-bit
16 16
functional request CAN identifier, as defined in 10.5.2, shall be transmitted.
The response handling procedure shall be used to receive response messages mapped to data frames
in CBFF from the OBDonEDS ECU(s) or to indicate that no response message is received. If OBDonEDS-
related ECUs are detected, this procedure also builds the list of supported ECUs on the OBDonEDS-
conformant vehicle.
The response validation procedure shall be performed as specified in Figure 3, after the 11-bit CAN
identifier request message transmit procedure (see Figure 2) has succeeded (“OK”).
Key
a
If the transmission of the previously transmitted request message was successful (“OK”), the external test
equipment shall start the P application timer and listen for the physical response CAN identifiers
2_CAN_Client
as defined in 10.5.
b
If the external test equipment determines a t timeout and no response message has been started,
P2_CAN_Client
then the external test equipment has verified that 11-bit or 29-bit CAN identifiers (whichever was used in the
previously transmitted request message) are not used for OBDonEDS communication. In addition, this means
that the external test equipment has determined that the vehicle supports CAN, using the specified physical
layer and the currently selected bit rate contained in the bitrateRecord parameter.
c
The start of a response message can either be the reception of a FirstFrame or SingleFrame, which uses
one of the specified OBDonEDS 11-bit or 29-bit CAN identifiers (whichever was used in the former request
message). If at least one response message is started, then the external test equipment shall continue to
receive this previously started response message (only applies to multiple frame response messages) and
shall accept further response messages, within t , which use one of the specified 11-bit or 29-bit
P2_CAN_Client
physical response CAN identifiers (whichever was used in the former request message).
8 © ISO 2021 – All rights reserved

d
When all started response messages are completely received (positive and negative responses) and the t
P2_
application timer has elapsed, the external test equipment shall analyse whether negative responses
CAN_Client
have been received.
If one or more of the received response messages are negative responses to the previously transmitted
request with response code 21 (busyRepeatRequest), the external test equipment shall restart the response
validation procedure at key 'a' after a minimum delay of 200 ms. If the negative response(s) appear(s) on six
subsequent sequences, the external test equipment shall assume that the vehicle is not conformant with
OBDonEDS. This implies that an OBDonEDS-conformant system shall provide a positive response within a
maximum of five retries.
Assuming that each negative response with NRC 21 is received before t elapses, the total time
16 P2_CAN_Client
available for the vehicle to correctly respond results in 1 250 ms.
If an OBDonEDS ECU responds with any other negative response code or an OBDonEDS ECU responds with
a response, which cannot be interpreted according to OBDonEDS, the external test equipment shall assume
that the vehicle is not conformant with OBDonEDS (“NOT OK”).
If an OBDonEDS ECU responds with a positive response message the PDU shall at least indicate one supported
PID, which the external test equipment shall interpret that the vehicle is conformant with OBDonEDS (“OK”).
e
If no negative or invalid response was detected in accordance with key 'd', the external test equipment has
verified that the vehicle supports 11-bit or 29-bit CAN identifiers (whichever was used in the former request
message) for OBDonEDS communication. The external test equipment shall build a list of the detected
OBDonEDS-related ECUs, which responded to the request message of service identifier 01 and PID
“supported PIDs" 00 based on the received physical responses. This key finishes the initialisation sequence
and verifies the vehicle's conformance with this document.
f
If the support of 11-bit CAN identifiers for OBDonEDS communication cannot be verified, a functionally
addressed request message with service identifier 01 and PID "supported PIDs" 00 , using the
16 16
OBDonEDS 29-bit functional request CAN identifier as defined in 10.5.3, shall be transmitted and the
response validation procedure shall be repeated as defined in Figure 3. If no support of 11-bit and 29-bit CAN
identifiers for OBDonEDS communication can be verified, the detection of OBDonUDS-conformant ECUs shall
be performed as specified in Figure 4.
g
Vehicle is OBDonEDS-conformant with this document.
Figure 3 — Perform OBDonEDS response validation
6.4.2 CAN identifier validation procedure OBDonUDS
A functionally addressed service identifier 22 and DID F810 (protocol identification) request using
16 16
the OBDonUDS 11-bit functional request CAN identifier, as defined in 10.5.2, shall be transmitted.
The response handling procedure shall be used to receive response messages mapped to data frames
in CBFF from the OBDonUDS ECU(s) or to indicate that no response message is received. If OBDonUDS-
related ECUs are detected, this procedure also builds the list of supported ECUs on the OBDonUDS-
conformant vehicle.
The response validation procedure shall be performed as specified in Figure 4, after the 11-bit CAN
identifier request message transmit procedure (see Figure 2) has succeeded (“OK”).
Key
a
If the transmission of the previous OBDonEDS request message (as defined in Figure 2) was successful, the
external test equipment shall start the t application timer and listen for the physical response CAN
P2_CAN_Client
identifiers as defined in 10.5.
b
If the external test equipment determines a t timeout, then no response message has been started
P2_CAN_Client
and the external test equipment has verified that 11-bit or 29-bit CAN identifiers (whichever was used in the
previously transmitted request message) are not used for OBDonUDS communication.
c
The start of a response message can either be the reception of a FirstFrame or SingleFrame, which uses one of
the specified OBDonUDS 11-bit or 29-bit CAN identifiers (whichever was used in the former request message).
If at least one response message is started, then the external test equipment shall continue to receive this
previously started response message (only applies to multiple frame response messages) and shall accept
further response messages, within t , which use one of the specified 11-bit or 29-bit physical response
P2_CAN_Client
CAN identifiers (whichever was used in the former request message).
10 © ISO 2021 – All rights reserved

d
When all started response messages are completely received (positive and negative responses) and the t
P2_
application timer has elapsed, the external test equipment shall analyse whether negative responses
CAN_Client
have been received. If one or more of the received response messages are negative responses to the previously
transmitted request messages with response code 21 (busyRepeatRequest), the external test equipment
shall restart the response validation procedure at key 'a' after a minimum delay of 200 ms. If the negative
response(s) appear(s) on six subsequent sequences, the external test equipment shall assume that the vehicle
is not conformant with OBDonUDS. This implies that an OBDonUDS-conformant system shall provide a positive
response within a maximum of five retries.
Assuming that each negative response with NRC 21 is received before t elapses, the total time
16 P2_CAN_Client
available for the vehicle to correctly respond results in 1 250 ms.
If an OBDonUDS ECU responds with any other negative response code or a OBDonUDS ECU responds with
a response, which cannot be interpreted in accordance with OBDonUDS, the external test equipment shall
assume that the vehicle is not conformant with OBDonUDS.
e
If no negative or invalid response was detected in accordance with key 'd', the external test equipment has
verified that the vehicle supports 11-bit or 29-bit CAN identifiers (whichever was used in the former request
message) for OBDonUDS communication. The external test equipment shall build a list of the detected
OBDonUDS-related ECUs which responded to the request message of service identifier 22 and DID F810
16 16
and then read supported DIDs using F400 based on the received physical responses.
If the list contains at least one OBDonUDS-conformant ECU, the initialisation sequence is finished and it is
verified that the vehicle is OBDonUDS-conformant.
If this list does not contain at least one OBDonUDS-conformant ECU, it shall be assumed that the vehicle does
not support the CAN identifier used in the previously transmitted request. At least one ECU shall provide a
positive answer with a content different to 00 to be conformant with OBDonUDS.
f
If the support of 11-bit CAN identifiers for OBDonUDS communication cannot be verified (“NOT OK”), a
functionally addressed request message with service identifier 22 and DID F810 using the OBDonUDS 29-
16 16
bit functional request CAN identifier as defined in 10.5.3 shall be transmitted. After successful transmission of
the request, the external test equipment shall repeat the response validation sequence as specified in Figure 4.
If neither a 11-bit nor a 29-bit CAN identifier can be verified as supported, it shall be assumed that the vehicle
is not conformant with OBDonUDS (“NOT OK”).
g
Vehicle is OBDonUDS-conformant with this document.
Figure 4 — Perform OBDonUDS response validation
6.5 Support of ECUNAME reporting
Each OBD-conformant server/ECU, which responds to external test equipment requests, is required to
[6]
support the InfoType "ECUNAME" (see SAE J1979-DA ). The mapping between a server/ECU address
and the name (ECUNAME) of the server/ECU shall be performed by the external test equipment. This
[7]
requirement is intended to replace the recommendation from Table 8 referencing SAE J2178-1 .
7 Application layer (AL)
The application layer is the seventh level of the seven-layer OSI model. It interfaces directly to and
performs common application services for the application processes. It also issues requests to the
presentation layer.
The application layer for the emissions-related diagnostic services shall be implemented as defined in
the following:
— OBDonEDS: on-board diagnostics on emissions-related diagnostic services;
— OBDonUDS: on-board diagnostics on unified diagnostic services.
A vehicle, which complies with OBDonEDS or OBDonUDS shall respond to requests from the external
test equipment.
The external test equipment shall be capable of supporting a list of detected OBDonEDS- or OBDonUDS-
related ECUs (generated during the initialisation sequence as defined in Clause 6).
8 Session layer (SL)
The session layer service requirements specified in ISO 14229-2 shall be followed.
All OBDonEDS or OBDonUDS communication shall take place during the default diagnostic session.
There shall always be exactly one diagnostic session active in an OBD-related ECU. An OBDonEDS
or OBDonUDS ECU shall always start the default diagnostic session when powered up. If no other
diagnostic session is started, then the default diagnostic session shall run as long as the OBDonEDS or
OBDonUDS ECU is powered.
An OBDonEDS or OBDonUDS ECU shall be capable of providing all diagnostic functionality defined for
OBDonEDS or OBDonUDS in the default diagnostic session and under normal operating conditions.
It is not required to send any diagnostic service to the OBDonEDS or OBDonUDS ECU(s) to keep the
default diagnostic session active.
9 Transport layer (TL)
The requirements of ISO 15765-2 are applicable for OBD purposes with the exception that CAN FD
capabilities are not allowed.
The FirstFrame escape sequence is only allowed for OBDonUDS.
10 Network layer (NL)
10.1 General
The network layer of the external test equipment and the OBDonUDS- or OBDonEDS-conformant vehicle
ECU(s) (from the external test equipment point of view) shall be in accordance with ISO 15765-2 and
the restrictions/additions given in 10.2 to 10.5.
10.2 Parameter definitions
10.2.1 Timing parameter values
Table 1 specifies the network layer timing parameters to be used by the external test equipment and
the OBD-conformant vehicle for OBDonUDS or OBDonEDS communication.
The listed performance requirement values are the binding communication requirements for the
external test equipment and the OBDonUDS or OBDonEDS ECU(s) considered as being OBD-conformant.
The timeout values are defined to be higher than the values for the performance requirements in order
to overcome communication conditions where the performance requirement absolutely cannot be met
(owing to external conditions such as high bus load).
Table 1 — Network layer timeout and performance requirement values
Parameter Timeout value Performance requirement value
t /t 33 ms —
N_As N_Ar
t 75 ms —
N_Bs
t — (t + t ) < 33 ms
N_Br N_Br N_Ar
t — (t + t ) < 50 ms
N_Cs N_Cs N_As
t 150 ms —
N_Cr
12 © ISO 2021 – All rights reserved

A detailed description of the network layer timing parameter values can be found in ISO 15765-2. Due
to application layer timing requirements, Formula (1) specifies the performance requirement for the
transmission of a single frame or the first frame of a response message.
tt≥+ t (1)
PC22__AN Server__MaxP CANS_ erverN_As
where
t is the maximum timeout value of the server to respond on a request message;
P2_CAN_Server_Max
t is the performance timing of the server to prepare the response information;
P2_CAN_Server
t is the network layer timeout value.
N_As
10.2.2 Definition of flow control parameter values
10.2.2.1 Flow control parameters
The BlockSize (B ) and SeparationTime (t ) parameter values are limited for the external test
S STmin
equipment and the server/ECU. The test equipment shall support the parameter values contained in the
FlowControl frame.
This implies that the external test equipment shall use these values when transmitting FlowControl
frames.
10.2.2.2 External test equipment
The external test equipment shall use the following network layer parameter values specified in Table 2
for its FlowControl frames sent in response to the reception of a FirstFrame.
Table 2 — External test equipment flow control parameter values
Parameter Name Value Description
No FlowControl wait frames are allowed for OBDonEDS/ OBDo-
nUDS. The FlowControl frame sent by the external test equipment
WaitFrame following the FirstFrame of a response message shall contain the
W 0
WFTmax
Transmission FlowStatus (F ) set to 0, which forces the ECU to start immediately
FS
after the reception of the FlowControl frame with the transmission
of the ConsecutiveFrame(s).
A single FlowControl frame shall be transmitted by the external
test equipment for the duration of a segmented message transfer.
B BlockSize 0
S
This unique FlowControl frame shall follow the FirstFrame of a
response message.
This value allows the ECU to send ConsecutiveFrames, following the
t SeparationTime 0 FlowControl frame sent by the external test equipment as fast as
STmin
possible.
If a reduced implementation of the ISO 15765-2 network layer is done in an OBDonUDS or OBDonEDS ECU, covering only
the above listed FlowControl frame parameter values (B , t ), then any FlowControl frame received during OBDonUDS
S STmin
or OBDonEDS communication and using different FlowCont
...