ISO 15765-4:2016

DRAFT INTERNATIONAL STANDARD
ISO/DIS 15765-4
ISO/TC 22/SC 3 Secretariat: DIN
Voting begins on: Voting terminates on:
2015-03-19 2015-06-19
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) —
PartieParte 4: Exigences applicables aux systèmes associés aux émissions
ICS: 43.040.15
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 15765-4:2015(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO 2015

ISO/DIS 15765-4:2015(E)
© ISO 2015
All rights reserved. Unless otherwise specified, 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
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 2015 – All rights reserved

ISO/DIS 15765-4
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Symbols . 2
3.3 Abbreviated terms . 3
4 Conventions . 3
5 Document overview . 4
6 External test equipment initialization sequence . 5
6.1 General . 5
6.2 Baudrate validation procedure . 7
6.2.1 BaudrateRecord . 7
6.2.2 Baudrate validation . 7
6.2.3 External test equipment error detection provisions . 9
6.3 CAN identifier validation procedure . 9
6.3.1 CAN identifier validation procedure OBD . 9
6.3.2 CAN identifier validation procedure WWH-OBD . 11
7 Application layer . 13
8 Session layer . 14
9 Transport protocol layer . 14
10 Network layer . 14
10.1 General . 14
10.2 Network layer parameters. 14
10.2.1 Timing parameter values . 14
10.2.2 Definition of Flow Control parameter values . 15
10.2.3 Maximum number of legislated OBD/WWH-OBD ECUs . 16
10.3 Addressing formats . 17
10.3.1 Normal and fixed addressing format . 17
10.3.2 Functional addressing . 17
10.3.3 Physical addressing . 17
10.4 CAN identifier requirements . 18
10.4.1 External test equipment . 18
10.4.2 Legislated OBD/WWH-OBD server/ECU . 18
10.5 Mapping of diagnostic addresses . 19
10.5.1 Legislated OBD/WWH-OBD CAN identifiers . 19
10.5.2 11 bit CAN identifiers . 20
10.5.3 29 bit CAN identifiers . 20
10.6 Support of ECUNAME reporting . 21
11 Each legislated OBD-compliant server/ECU, which responds to external test equipment
compliant to either ISO 15031-4/SAE J1978 or ISO 27145-6 requests, is required to
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 requirement is intended to replace the recommendation
from Table 8 in ISO 15765-4 referencing SAE J2178.Data link layer . 21
ISO/DIS 15765-4
12 Physical layer . 21
12.1 General . 21
12.2 External test equipment baudrates . 21
12.3 External test equipment CAN bit timing . 22
12.3.1 CAN bit timing parameter values . 22
12.3.2 Nominal baudrate 250 kBit/s . 23
12.3.3 Nominal baudrate 500 kBit/s . 23
12.4 External test equipment . 24
12.4.1 General . 24
12.4.2 CAN interface . 25
12.4.3 External test equipment cable . 27
Bibliography . 29

iv © ISO 2014 – All rights reserved

ISO/DIS 15765-4
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-4 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
This third edition cancels and replaces the second edition (ISO 15765-4:2013) of which has been technically
revised.
ISO 15765 consists of the following parts, under the general title Road vehicles — Diagnostic communication
over Controller Area Network (DoCAN):
 Part 1: General information and use case definition
 Part 2: Transport protocol and network layer services
1)
 Part 3: Implementation of unified diagnostic services (UDS on CAN)
 Part 4: Requirements for emissions-related systems

1) ISO 15765-3 has benn replaced by ISO 14229-3.
ISO/DIS 15765-4
Introduction
This part of ISO 15765 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.
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, in
accordance with ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven
layers as shown in Table 1.
Table 1 — Enhanced and legislated OBD diagnostic specifications applicable to the OSI layers
Vehicle manufacturer Legislated OBD Legislated WWH-OBD
Applicability OSI 7 layers
enhanced diagnostics (on-board diagnostics) (on-board diagnostics)
ISO 14229-1,
Application (layer 7) ISO 15031-5 ISO 27145-3, ISO 14229-1
ISO 14229-3
ISO 15031-2, ISO 15031-5,
ISO/PAS 27145-2, SAE 1930-DA,
ISO 15031-6,
Vehicle manufacturer SAE J1979-DA, SAE J2012-DA,
Presentation (layer 6) SAE J1930-DA,
specific SAE J1939 Appendix C (SPN),
SAE J1979-DA,
Seven layers SAE J1939-73 Appendix A (FMI)
SAE J2012-DA
according to
ISO/IEC 7498-1
Session (layer 5) ISO 14229-2 ISO 14229-2
and
Transport protocol
ISO/IEC 10731
ISO 15765-4,
(layer 4)
ISO 15765-2 ISO 15765-2,
ISO 15765-2
ISO 15765-4,
Network (layer 3)
ISO 27145-4
ISO 11898-2
Data link (layer 2) ISO 11898-1 ISO 15765-4,
ISO 11898-1,
Physical (layer 1) User defined
ISO 11898-2
The application layer services covered by ISO 14229-3 have been defined in compliance with diagnostic
services established in ISO 14229-1 and ISO 15031-5, but are not limited to use only with them.
The transport protocol and network layer services covered by this part of ISO 15765 have been defined to be
independent of the physical layer implemented, and a physical layer is only specified for legislated on-board
diagnostics (OBD).
For other application areas, ISO 15765 can be used with any CAN physical layer.

vi © ISO 2014 – All rights reserved

DRAFT INTERNATIONAL STANDARD ISO/DIS 15765-4

Road vehicles — Diagnostic communication over Controller
Area Network (DoCAN) — Part 4: Requirements for emissions-
related systems
1 Scope
This part of ISO 15765 specifies requirements for controller area networks (CAN) where one or more
controllers comply with on-board diagnostics (OBD) or world-wide harmonized on-board diagnostics
(WWH-OBD) regulations. The network presumes the use of an external test equipment for inspection and
repair diagnostics, as defined by the regulations. The CAN network requirements for the vehicle and the
external test equipment are based on the specifications of ISO 15765-2, ISO 11898-1 and ISO 11898-2.
This part of ISO 15765 places restrictions on those International Standards for the fulfilment of the regulations.
It does not specify in-vehicle CAN bus architecture, but seeks to ensure that the vehicle's regulated CAN
communications comply with external test equipment requirements.
This part of ISO 15765 defines the requirements to successfully establish, maintain and terminate
communication with a vehicle that implements the requirements of the OBD/WWH-OBD regulations.
Plug-and-play communication capabilities among vehicles and test equipment are defined to assure the
interoperation of external test equipment and vehicles. This part of ISO 15765 details all of the OSI layer
requirements to achieve this goal.
This part of ISO 15765 is the entry point for DoCAN (Diagnostic communication over CAN). Based on the
results of the initialization, the external test equipment determines which protocol and diagnostic services are
supported by the vehicle's emissions-related system:
 legislated OBD: ISO 15031 (all parts),
 legislated WWH-OBD: ISO 27145 (all parts).
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 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 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 15031-5, Road vehicles — Communication between vehicle and external equipment for emissions-related
diagnostics — Part 5: Emissions-related diagnostic services
ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Networks (DoCAN) — Part 2:
Transport protocol and network layer services
ISO/DIS 15765-4
ISO 27145-3, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics
(WWH-OBD) communication requirements — Part 3: Common message dictionary
ISO 27145-4, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics
(WWH-OBD) communication requirements — Part 4: Connection between vehicle and test equipment
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 15765-2 apply.
3.2 Symbols
Symbol Definition Unit
C , C capacitance of a.c. termination F
AC1 AC2
C capacitance between CAN_H and ground potential F
CAN_H
C capacitance between CAN_L and ground potential F
CAN_L
C capacitance between CAN_H and CAN_L F
DIFF
Δf oscillator tolerance Hz
l maximum cable length between OBD/WWH-OBD connector and external test m
CABLE
equipment
Prop_Seg propagation segment
Phase_Seg1 phase segment 1
Phase_Seg2 phase segment 2
R , RA resistance of a.c. termination Ω
AC1 C2
Sync_Seg synchronization segment
t bit time µs
BIT
t receive bit time µs
BIT_RX
t transmit bit time µs
BIT_TX
t external-test-equipment cable propagation delay (without external test equipment µs
CABLE
CAN interface delay)
t timing segment 1 µs
SEG1
t timing segment 2 µs
SEG2
t resynchronization jump with µs
SJW
t synchronization segment µs
SYNCSEG
ISO/DIS 15765-4
Symbol Definition Unit
t external test equipment CAN interface propagation delay (without external test µs
TOOL
equipment cable delay)
t time quantum µs
Q
3.3 Abbreviated terms
BS block size
CAN controller area networks
CF consecutive frame
DLC data length code
DoCAN diagnostic communication over CAN
ECU electronic control unit
ECM engine control module
FC flow control
FF first frame
FS flow status
OBD on-board diagnostics
SA source address
SF single frame
SJW synchronization jump width
SP nominal sample point
TA target address
TCM transmission control module
WWH-OBD world-wide harmonized on-board diagnostics
4 Conventions
ISO 15765 is based on the conventions specified in the OSI Service Conventions (ISO/IEC 10731:1994) as
they apply for diagnostic services.
ISO/DIS 15765-4
5 Document overview
Figure 1 illustrates the most applicable application implementations utilizing the DoCAN protocol.
ISO 15765-1
DoCAN
General information and
use case definition
Enhanced
Emissions-
WWH-OBD
Diagnostics
related OBD
ISO 14229-1 UDS ISO 15031-5
ISO 14229-3 ISO 27145-3
Specification and Emissions-related
OSI Layer 7
UDSonCAN WWH-OBD
requirements OBD services
Application
Vehicle ISO 15031-2, -5, -6
ISO 27145-2
Manufacturer Emissions-related
OSI Layer 6
WWH-OBD
specific OBD data definition
Presentation
ISO 14229-2 UDS
ISO 14229-2 UDS
1 : 1
Session layer
OSI Layer 5
Session layer services
services
Session
Standardized Service Primitive Interface
CAN diagnostic communication protocol (DoCAN)
ISO 27145-4 ISO 15765-4
WWH-OBD DoCAN
OSI Layer 4 ISO 15765-2 DoCAN
Transport
Part 2:
Transport
protocol
ISO 15765-2 ISO 15765-2
and
DoCAN DoCAN
network
layer services
OSI Layer 3
Network
ISO 11898-1 CAN ISO 11898-1 CAN
ISO 11898-1 CAN
Data link layer Data link layer
Data link layer and
OSI Layer 2
and physical and physical
physical signalling
Data Link
signalling signalling
ISO 11898 CAN
ISO 11898 CAN ISO 11898 CAN
ISO 11898 CAN
Part 3: LS, FT,
Part 2: High- Part 2: High-
Part 2: High-speed
OSI Layer 1
medium dependent
speed medium speed medium
medium access unit
Physical
Interface
access unit access unit
Figure 1 — Diagnostic communication over CAN document reference according to OSI model
according to OSI model
ISO/DIS 15765-4
6 External test equipment initialization sequence
6.1 General
The external test equipment shall support the initialization sequence specified in this part of ISO 15765.
See Figure 2.
The purpose of the external test equipment initialization sequence is to automatically detect whether the
vehicle supports legislated OBD or WWH-OBD on CAN using the physical layer specified in Clause 12.
Furthermore, the initialization sequence determines the communication compliance status of vehicles by
analysing their responses to:
 ISO 15031-5 service 01 00 (PID supported) requests, or
16 16
 ISO 27145-3 service 22 F810 (DID protocol identification) request with a positive response.
16 16
Only vehicles that follow the WWH-OBD regimen will have ECUs that reply to the functional request service
22 DID F810 for protocol identification. Vehicles that respond only to the functional request service 01
16 16 16
PID 00 support earlier OBD communication methods. Vehicles that do not respond to either request do not
support regulated OBD diagnostics under this part of ISO 15765. Subclause 6.3 describes this procedure.
For each legislated OBD/WWH-OBD service that requires the determination of “supported” information, the
external test equipment has to update its list of expected responding legislated OBD/WWH-OBD ECUs prior
to any data parameter requests. For applicable services see either ISO 15031-5 (for legislated OBD) or
ISO 27145-3 (for legislated WWH-OBD).
The external test equipment initialization sequence supports single baudrate initialization (e.g. 500 kBit/s) and
multiple baudrate initialization (e.g. 250 kBit/s and 500 kBit/s) and is separated into the following tests:
a) 11 bit CAN identifier validation, and
b) 29 bit CAN identifier validation.
NOTE See 6.2.2.
The external test equipment initialization sequence contains provisions for legacy vehicles using either CAN
(same or different physical layer as defined for legislated OBD/WWH-OBD) or a different protocol (non-CAN)
on the CAN pins of the ISO 15031-3 diagnostic connector.

ISO/DIS 15765-4
Start
Initialization sequence
Connect External Test Equipment to
OBD/WWH-OBD Diagnostic
Connector
set first baudrate
Set baudrate of the CAN interface to
baudrate of baudrateRecord
next
baudrate
Perform baudrate validation NOT OK
Select next
(11 bit CAN-ID, Service 0x01, PID 0x00)
baudrate
Refer to figure 3
OK
no futher
baudrate
available
OK Perform ISO 15031-5 OBD response
validation (11 bit CAN-ID)
Refer to figure 4
NOT OK
Transmit ISO 15031-5 OBD request
(29 bit CAN-ID, Service 0x01, PID 0x00)
OK Perform ISO 15031-5 OBD response
validation (29 bit CAN-ID)
Refer to figure 4
NOT OK
Only if supported by
external test equipment
Transmit ISO 27145-3 WWH-OBD request
(11 bit CAN-ID, Service 0x22, DID 0xF810)
OK Perform ISO 27145-3 WWH-OBD
response validation (11 bit CAN-ID)
Refer to figure 5
NOT OK
Transmit ISO 27145-3 WWH-OBD request
(29 bit CAN-ID, Service 0x22, DID 0xF810)
NOT OK
OK Perform ISO 27145-3 WWH-OBD
response validation (29 bit CAN-ID)
Refer to figure 5
ISO 15765-4 ISO 27145-4 Not ISO 15765-4 compliant
compliant compliant Not ISO 27145-4 compliant

Figure 2 — Initialization sequence overview

ISO/DIS 15765-4
Subclauses 6.2 and 6.3 describe the external test equipment initialization to determine baudrate and CAN
identifier (11 bit or 29 bit) for OBD (ISO 15031) and WWH-OBD (ISO 27145).
6.2 Baudrate validation procedure
6.2.1 BaudrateRecord
By default, the parameter “baudrateRecord” contains all baudrates specified in 12.3. The content of the
baudrateRecord can be superseded by any other list of baudrates, e.g. single 500 kBit/s baudrate as specified
in 12.3.3.
The baudrateRecord shall be used to specify the type of initialization to be performed. If the baudrateRecord
parameter contains a single baudrate, then a single-baudrate initialization sequence shall be performed using
the specified single baudrate (e.g. 500 kBit/s). If the baudrateRecord parameter contains multiple baudrates,
then a multiple-baudrate initialization sequence shall be performed including a baudrate detection procedure
as defined in Figure 4.
Figure 3 shall be performed using the specified multiple baudrates (e.g. 250 kBit/s and 500 kBit/s). For
legislated OBD/WWH-OBD baudrates, the external test equipment shall use the appropriate CAN bit timing
parameter values defined in 12.3.
6.2.2 Baudrate validation
If multiple baudrates are specified in the baudrateRecord parameter, the procedure as defined in Figure 3
shall be used to determine the baudrate to be used in communication with the vehicle.
The external test equipment shall set up its CAN interface using the first baudrate contained in the
baudrateRecord. It shall use the CAN bit timing parameter values defined for this baudrate (see 12.3).

ISO/DIS 15765-4
Perform baudrate validation
(1) Transmit request message:
functional 11 bit request CAN
Identifier, Service 0x01, PID 0x00 as
specified in ISO 15031-5
(2) (3) (4)
Any
other
error
YES
CAN error
ACK error ?
detected ?
NO YES
- Disconnect from
NO YES
Timeout N_As CAN bus
Tx done ?
(25ms) elapsed ? - Reset CAN
Controller
YES NO
(5) OK (6) NOT OK
1 Following the CAN interface set-up, the external test equipment shall connect to the CAN bus and immediately
transmit a functionally addressed request message with service 01 (read supported PIDs) using the legislated
OBD/WWH-OBD 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 monitoring as specified further
down, since initializing the CAN controller at the wrong baudrate without transmitting any data can leave the CAN
controller in a state of generating error frames on the CAN bus.
2 The external test equipment shall check for any CAN error. If the request message is successfully transmitted onto the
CAN bus, the external test equipment shall indicate a successful transmission and proceed with the validation of the
CAN identifier as specified in 6.3.
3 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 25 ms timeout (N_As) has elapsed.
4 If any other CAN error occurred, or an acknowledge check error still occurs after the 25 ms (N_As) timeout has
elapsed, then the external test equipment shall disconnect its CAN interface from the CAN bus.
5 Proceed with sequence according to Figure 4.
6 The external test equipment shall check whether more baudrates are contained in the baudrateRecord. If the end of
the baudrateRecord is not reached, the external test equipment shall set up its CAN interface using the next baudrate
in the baudrateRecord and restart the baudrate validation at step (1) in Figure 3. If no further baudrate is contained in
the baudrateRecord, it shall be assumed that the request was not transmitted successfully. This indicates that the
vehicle complies with neither this part of ISO 15765 nor ISO 27145-4.
Figure 3 — Perform baudrate validation
ISO/DIS 15765-4
6.2.3 External test equipment error detection provisions
Where the vehicle uses a CAN with a physical layer different from that specified for OBD/WWH-OBD (see
Clause 12) or a non-CAN protocol on the CAN pins of the OBD/WWH-OBD connector, the transmit procedure
specified in this part of ISO 15765 shall guarantee that in all cases, the external test equipment will detect that
the vehicle does not support CAN as specified for legislated OBD/WWH-OBD and will 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 will detect that it uses the wrong
baudrate for the transmission of the request message and will stop disturbing the CAN bus immediately.
Under normal in-vehicle conditions (i.e. no error frames during in-vehicle communication when the external
test equipment is disconnected), the external test equipment will disable its CAN interface prior to the situation
where the internal error counters of the legislated OBD/WWH-OBD 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 bus 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 bus;
 Possibility to immediately detect any frame error on the CAN bus.
The second provision implies that the external test equipment cannot solely rely on the usual CAN controller
error handling since it will most likely flag a frame error only after the “bus-off” state has been reached (refer to
ISO 11898-1 for further details).
6.3 CAN identifier validation procedure
6.3.1 CAN identifier validation procedure OBD
The response handling procedure shall be used to receive 11 bit CAN identifier response messages from
legislated OBD ECU(s) or to indicate that no response message has been received. If legislated OBD-related
ECUs are detected, this procedure also builds the list of available ECUs on the legislated OBD-compliant
vehicle.
The response validation procedure shall be performed as defined in Figure 4, after the 11 bit CAN identifier
request message transmit procedure (see 6.2.2, Figure 3) has succeeded (“OK”).

ISO/DIS 15765-4
Perform ISO 15031-5 OBD response validation
(1) Start P2 Retransmit request
CAN_Client
timer message
(2) (3)
YES
P2
CAN_Client
Receive response(s)
timeout ?
NO
NO NO
P2 timeout
CAN_Client
Response
and all started responses
started ?
completed ?
YES
YES
(5) (4)
NO
Busy
Max. number
YES
RepeatRequest
of retries
neg. response ?
exceeded ?
NO YES
Build list with detected ECUs
Any other
YES
based on physical responses
negative
for further functional
response ?
communication
NO
YES
NO
Valid positive
response ?
(6) NOT OK (7) OK
Figure 4 (continued)
ISO/DIS 15765-4
1 If the transmission of the previously transmitted request message was successful (“OK”), the external test equipment
shall start the P2 (see ISO 15031-5) application timer and listen for the physical response CAN identifiers as
CAN_Client
defined in 10.5.
2 If the external test equipment determines a P2 timeout and no response message has been started, then the
CAN
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 legislated OBD 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 baudrate contained in the baudrateRecord parameter.
3 The start of a response message can either be the reception of a FirstFrame or SingleFrame which uses one of the
specified legislated OBD 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 P2 , which use one of the specified 11 bit or 29 bit physical response CAN identifiers
CAN_Client
(whichever was used in the former request message).
4 When all started response messages are completely received (positive and negative responses) and the P2
CAN_Client
application timer has elapsed, the external test equipment shall analyse whether negative responses 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 step (1) 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 compliant with ISO 15031-5. This implies that a legislated
OBD-compliant system shall provide a positive response within a maximum of five retries.
Assuming that each negative response with NRC 21 is received shortly before P2 elapses, the total time available
for the vehicle to correctly respond results in 1 250 ms.
If a legislated OBD ECU responds with any other negative response code or a legislated OBD ECU responds with a
response which cannot be interpreted according to ISO 15031-5, the external test equipment shall assume that the
vehicle is not compliant with ISO 15031-5 (“NOT OK”).
5 If no negative or invalid response was detected in accordance with step (4), 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
legislated OBD communication. The external test equipment shall build a list of the detected legislated OBD-related
ECUs which responded to the request message of service 01 and read supported PIDs based on the received
physical responses. This step finishes the initialization sequence and verifies the vehicle's compliance with this part of
ISO 15765.
6 If the support of 11 bit CAN identifiers for legislated OBD communication cannot be verified, a functionally addressed
request message with service 01 (read supported PIDs) using the legislated OBD 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 4. If no support of 11 bit and 29 bit CAN identifiers for legislated OBD communication can be verified, the
detection of WWH-OBD-compliant ECUs shall be performed as specified in Figure 5.
7 Vehicle is compliant with this part of ISO 15765.
Figure 4 — Perform ISO 15031-5 OBD response validation
6.3.2 CAN identifier validation procedure WWH-OBD
A functionally addressed service 22 F810 (protocol identification) request using the legislated WWH-OBD
16 16
11 bit functional request CAN identifier, as defined in 10.5.2, shall be transmitted and the response validation
procedure shall be performed as defined in Figure 5.

ISO/DIS 15765-4
Perform ISO 27145-3 WWH-OBD response validation
(1) Start P2 Retransmit request
CAN_Client
timer message
(2) (3)
YES
P2
CAN_Client
Receive response(s)
timeout ?
NO
NO NO
P2 timeout
CAN_Client
Response
and all started responses
started ?
completed ?
YES
YES
(5) (4)
NO
Busy
Build list of ECUs supporting Max. number
YES
RepeatRequest
DID 0xF810 based on physical of retries
neg. response ?
responses for further physical
exceeded ?
communication
NO YES
Any other
YES
negative
response ?
NO
At least one
NO
WWH-OBD compliant
YES
NO
ECU detected ? Valid positive
response ?
YES
(6) NOT OK (7) OK
Figure 5 (continued)
ISO/DIS 15765-4
1 If the transmission of the previous WWH-OBD request message (as defined in Figure 2) was successful, the external
test equipment shall start the P2 (see ISO 27145-3) application timer and listen for the physical response
CAN_Client
CAN identifiers as defined in 10.5.
2 If the external test equipment determines a P2 timeout then no response message has been started and the
CAN
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 legislated WWH-OBD communication.
3 The start of a response message can either be the reception of a FirstFrame or SingleFrame which uses one of the
specified legislated WWH-OBD 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 P2 , which use one of the specified 11 bit or 29 bit physical response CAN identifiers
CAN_Client
(whichever was used in the former request message).
4 When all started response messages are completely received (positive and negative responses) and the P2
CAN_Client
application timer has elapsed, the external test equipment shall analyse whether negative responses 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 step (1) 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 compliant with
ISO 27145-3. This implies that a legislated WWH-OBD-compliant system shall provide a positive response within a
maximum of five retries.
Assuming that each negative response with NRC 21 is received shortly before P2 elapses, the total time available
for the vehicle to correctly respond results in 1 250 ms.
If a legislated WWH-OBD ECU responds with any other negative response code or a legislated WWH-OBD ECU
responds with a response which cannot be interpreted in accordance with ISO 27145-3, the external test equipment
shall assume that the vehicle is not compliant with ISO 27145-3.
5 If no negative or invalid response was detected in accordance with step (4), 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
legislated WWH-OBD communication. The external test equipment shall build a list of the detected legislated
WWH-OBD-related ECUs which responded to the request message of service 22 F810 and then read supported
16 16
DIDs based on the received physical responses.
If the list contains at least one WWH-OBD-compliant ECU, the initialization sequence is finished and it is verified that
the vehicle is ISO 27145-4-compliant.
If this list does not contain at least one WWH-OBD-compliant ECU, it shall be assumed that the vehicle does not
support the CAN identifier used in the previously transmitted request.
6 If the support of 11 bit CAN identifiers for legislated WWH-OBD communication cannot be verified (“NOT OK”), a
functionally addressed request message with service 22 (read supported PIDs) using the legislated WWH-OBD
29 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 5. 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 compliant
with ISO 27145 (“NOT OK”).
7 Vehicle is ISO 27145-4-compliant.
Figure 5 — Perform ISO 27145-3 WWH-OBD response validation
7 Application layer
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:
 legislated OBD: diagnostic services as defined in ISO 15031-5;
 legislated WWH-OBD: diagnostic services as defined in ISO 27145-3.
A vehicle which complies with:
 legislated OBD shall respond to ISO 15031-5 requests from the external test equipment;
ISO/DIS 15765-4
 legislated WWH-OBD shall respond to ISO 27145-3 requests from the external test equipment.
The external test equipment shall be capable of supporting a list of detected legislated
OBD/WWH-OBD-related ECUs (generated during the initialization sequence as defined in Clause 6).
8 Session layer
ISO 14229-2 defines the session layer service requirements.
All legislated OBD/WWH-OBD communication shall take place during the default diagnostic session.
There shall always be exactly one diagnostic session active in a legislated OBD-related ECU. A legislated
OBD/WWH-OBD 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 legislated
OBD/WWH-OBD ECU is powered.
A legislated OBD/WWH-OBD ECU shall be capable of providing all diagnostic functionality defined for
legislated OBD/WWH-OBD in the default diagnostic session and under normal operating conditions.
There is no need for any diagnostic service to be sent to the legislated OBD/WWH-OBD ECU(s) to keep the
default diagnostic session active.
9 Transport protocol layer
The requirements of ISO 15765-2 are applicable for legislated OBD purposes with the exception that CAN FD
is not allowed. In addition, the FirstFrame escape sequence is only allowed when ISO 14229-1 UDS services
are used for legislated OBD.
10 Network layer
10.1 General
The network layer of the external test equipment and the legislated OBD/WWH-OBD-compliant 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 Network layer parameters
10.2.1 Timing parameter values
Table 2 specifies the network layer timing parameters to be used by the external test equipment and the
legislated OBD-compliant vehicle (from the external test equipment point of view) for legislated
OBD/WWH-OBD communication.
The listed performance requirement values are the binding communication requirements for the external test
equipment and the legislated OBD/WWH-OBD ECU(s) considered as being legislated OBD-compliant. 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).
---
...