ISO/PAS 27145-4:2006

PUBLICLY ISO/PAS
AVAILABLE 27145-4
SPECIFICATION
First edition
2006-09-15
Road vehicles — Implementation of
WWH-OBD communication
requirements —
Part 4:
Connection between vehicle and test
equipment
Véhicules routiers — Mise en application des exigences de
communication WWH-OBD —
Partie 4: Connexion entre véhicule et équipement d'essai

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

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 2
4 Symbols and abbreviated terms . 2
5 Conventions . 3
6 Vehicle and external test equipment connection requirements . 4
6.1 Overview . 4
7 CAN based wired connection . 4
7.1 Initialization sequence. 4
7.1.1 External test equipment error detection provisions . 6
7.1.2 11 bit CAN identifier verification procedure . 7
7.1.3 29 bit CAN identifier verification procedure .10
7.2 Application layer. 13
7.2.1 Diagnostic protocol communication types. 14
7.2.2 Diagnostic protocol timing parameters. 14
7.2.3 Timing performance requirements . 16
7.3 Presentation layer. 17
7.4 Session layer. 17
7.5 Network layer . 18
7.5.1 Addressing formats. 18
7.5.2 Data link layer interface . 18
7.5.3 Maximum number of WWH-OBD ECUs . 21
7.5.4 Functional addressing. 21
7.5.5 Physical addressing . 22
7.5.6 Network layer timing parameter values. 23
7.5.7 Definition of network layer parameter values. 24
7.6 Data link layer. 24
7.7 Physical layer. 25
7.7.1 Diagnostic connector . 25
7.7.2 External test equipment baud-rates. 25
7.7.3 External test equipment CAN bit timing. 25
7.7.4 External test equipment . 27
Bibliography . 32

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.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
⎯ an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
⎯ an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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/PAS 27145-4 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO/PAS 27145 consists of the following parts, under the general title Road vehicles — Implementation of
WWH-OBD communication requirements:
⎯ Part 1: General information and use case definition
⎯ Part 2: Common emissions-related data dictionary
⎯ Part 3: Common message dictionary
⎯ Part 4: Connection between vehicle and test equipment
NOTE ISO/PAS 27145-4 will be extended as necessary upon introduction of additional communication media as
noted in the scope of this document.

iv © ISO 2006 – All rights reserved

Introduction
This document set defines the communication between a vehicle's OBD system and test equipment
implemented within the scope of the WWH-OBD GTR (World Wide Harmonized On-Board Diagnostics Global
Technical Regulations).
It has been established in order to apply the unified diagnostic services (specified in ISO 14229-1) to WWH
OBD systems.
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. When
mapped on this model, the services specified by ISO/PAS 27145 are broken into:
⎯ Diagnostic application (layer 7), specified in ISO/PAS 27145-3;
⎯ Presentation layer (layer 6), specified in ISO/PAS 27145-2;
⎯ Session layer services (layer 5), specified in ISO/PAS 27145-4;
⎯ Transport layer services (layer 4), specified in ISO ISO/PAS 27145-4;
⎯ Network layer services (layer 3), specified in ISO ISO/PAS 27145-4;
⎯ Data link layer (layer 2), specified in ISO/PAS 27145-4; and
⎯ Physical layer (layer 1), specified in ISO/PAS 27145-4;
in accordance with Table 1.
Table 1 — Enhanced and WWH-OBD diagnostic specifications applicable to the OSI layers
Implementation of WWH-OBD communication
Applicability OSI 7 layers
requirements, e.g. emissions-related UDS
Application (layer 7) ISO/PAS 27145-3 / ISO 14229-1
Presentation (layer 6) ISO/PAS 27145-2
Session (layer 5)
Seven layers
according to
Transport (layer 4)
ISO/IEC 7498-1 and
ISO/IEC 10731
ISO/PAS 27145-4
Network (layer 3)
Data link (layer 2)
Physical (layer 1)
PUBLICLY AVAILABLE SPECIFICATION ISO/PAS 27145-4:2006(E)

Road vehicles — Implementation of WWH-OBD communication
requirements —
Part 4:
Connection between vehicle and test equipment
1 Scope
ISO/PAS 27145 is intended to become the single communication standard for access to OBD-related
information. To allow for a smooth migration from the existing communication standards to this future
worldwide standardized communication standard, the initial communication concept will be based on CAN. In
a second step, ISO/PAS 27145 will be extended to define the world-wide harmonized OBD communication
standard based on existing industry communications standards (e.g. Internet Protocol) over Ethernet. Due to
the usage of standard network layer protocols, future extensions to optional physical layers (e.g. wireless) are
possible.
This part of ISO/PAS 27145 defines the requirements to successfully establish, maintain and terminate
communication with a vehicle that implements the requirements of the WWH-OBD global technical regulation.
This requires plug-and-play communication capabilities of the vehicle as well as any test equipment that
intends to establish communication with a vehicle. This document details all the OSI layer requirements to
achieve this goal.
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 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model —Part 1:
The Basic Model
ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model —
Conventions for the definition of OSI services
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-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements
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 — Diagnostics on Controller Area Networks (CAN) — Part 2: Network layer
services
ISO 15765-3, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 3: Implementation of
unified diagnostic services (UDS on CAN)
ISO 15765-4, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 4: Requirements for
emissions-related systems
ISO/PAS 27145-1, Road vehicles — Implementation of WWH-OBD communication requirements — Part 1:
General information and use case definition
ISO/PAS 27145-2, Road vehicles — Implementation of WWH-OBD communication requirements — Part 2:
Common emissions-related data dictionary
ISO/PAS 27145-3, Road vehicles — Implementation of WWH-OBD communication requirements — Part 3:
Common message dictionary
IEEE 802.3, IEEE Standard for Information technology — Telecommunications and information exchange
between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense
multiple access with collision detection (CSMA/CD) access method and physical layer specifications
3 Terms and definitions
For the purposes of this document, the terms and definitions given in given in ISO/PAS 27145-1 apply.
4 Symbols and abbreviated terms
C , C capacitance of a.c. termination
AC1 AC2
C capacitance of d.c. termination
DC
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
L max. cable length between OBD connector and external test equipment
CABLE
R , R resistance of a.c. termination
AC1 AC2
R , R resistance of d.c. termination
DC1 DC2
t timing segment 1
SEG1
t timing segment 2
SEG2
t synchronization segment
SYNCSEG
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 equipment
TOOL
cable delay)
2 © ISO 2006 – All rights reserved

t external-test-equipment cable propagation delay (without external test equipment CAN
CABLE
interface delay)
t time quantum
Q
∆f oscillator tolerance
ECU electronic control unit
OBD on-board diagnostics
Prop_Seg propagation segment
Phase_Seg1 phase segment 1
Phase_Seg2 phase segment 2
SA source address
SJW synchronization jump width
SP nominal sample point
Sync_Seg synchronization segment
TA target address
WWH-OBD World wide harmonized OBD
5 Conventions
ISO/PAS 27145 is based on the conventions specified in the O.S.I. Service Conventions (ISO/IEC 10731) as
they apply for diagnostic services. Therefore the requirements for the individual OSI layers are defined in the
sub-clauses listed in Table 2 — Requirements and applicable sub-clauses for the O.S.I. layers.
Table 2 — Requirements and applicable sub-clauses for the O.S.I. layers
Applicability OSI 7 layers Applicable sub-clause for CAN
Application (layer 7) 7.2
Presentation (layer 6) 7.3
Session (layer 5) 7.4
Seven layer
according to Transport (layer 4)
7.5
ISO/IEC 10731
Network (layer 3)
Data link (layer 2) 7.6
Physical (layer 1) 7.7
6 Vehicle and external test equipment connection requirements
6.1 Overview
To provide a future oriented, long-term stable communication standard which is based on existing industry
communication standards, while allowing for backward-compatibility to existing automotive networks,
ISO/PAS 27145 is designed to support different types of connections between external test equipment and a
vehicle. Regardless of the underlying physical layer, data link and network layer the remaining parts of
ISO/PAS 27145 remain unaltered.
a) Controller Area Network based wired connection (section 7)
This is the type of connection which describes the usage of the WWH-OBD communication services on
existing ISO15765-4 compliant vehicle interface. It has been defined to allow for a smooth migration from
a CAN-based vehicle interface to an Ethernet-based connection to a vehicle.
b) TCP/IP over Ethernet wired connection
This is the long-term type of connection which utilizes the Internet Protocol as network layer on a Fast
Ethernet (IEEE 802.3) connection.
This type of connection is not defined yet in ISO/PAS 27145-4 but will be contained in future versions of
this standard.
7 CAN based wired connection
7.1 Initialization sequence
The external test equipment shall support the initialization sequence as specified in this part of
ISO/PAS 27145. Figure 1 — Initialization sequence overview provides an overview of the CAN initialization
sequence. The following descriptions of the external test equipment initialization sequence make use of the
off-page-connectors A to G as shown in Figure 1 — Initialization sequence overview to reference certain entry
and exit points.
4 © ISO 2006 – All rights reserved

baudrateRecord Start
Initialization sequence
A
Transmit
error
Functional 11 bit CAN identifier
request message
Tx done
C
11 bit CAN
IDs verified
11 bit CAN identifier
response handling
No response
D
Transmit
error
Functional 29 bit CAN identifier
request message
Tx done
E
29 bit CAN
IDs verified
29 bit CAN identifier
response handling
No response
F G
Perform ISO15765-4 / SAE
J1939-73 init sequence at
ISO/PAS 27145-4 Not ISO/PAS 27145-4
current baudrate
compliant compliant
Figure 1 — Initialization sequence overview
The purpose of the external test equipment initialization sequence is to automatically detect whether the
vehicle supports WWH-OBD or legislated ISO 15765-4 diagnostic communication on CAN using the physical
layer specified in section 7.7. In addition the specific CAN configuration used for communication is determined
(specific communication baud-rate, CAN identifier format). Furthermore, the initialization sequence determines
the V-OBD system's ECUs (based on the CAN-IDs as defined in section 7.5.2.2) expected to respond to
ISO/PAS 27145-3 service 0x12 requests. The individual steps to be performed by the external test equipment
are defined in greater detail in Figure 2 — Functional 11 bit CAN identifier request transmission, Figure 3 —
11 bit CAN identifier response handling, Figure 4 — 29 bit CAN identifier request transmission and Figure 5 —
29 bit CAN identifier response handling. The same letters are used for off-page connectors (e.g. details for off-
page connector A are described in Figure 2 — Functional 11 bit CAN identifier request transmission).
NOTE For each WWH-OBD diagnostic service that requires the determination of “supported” information, the
external test equipment has to update its list of expected responding WWH-OBD ECUs prior to any data parameter
requests (see ISO/PAS 27145-2 and ISO/PAS 27145-3 for the corresponding services and data identifiers).
The external test equipment shall support to perform the initialization sequence at multiple CAN baud-rates
sequentially using one of the following baud-rates (also referred to as baudrateRecord) at a time:
⎯ 250 kBit/s
⎯ 500 kBit/s
The parameter baudrateRecord shall be used to specify the baud-rate to be used for the initialization. If the
baudrateRecord parameter contains a single baud-rate, then a single baud-rate initialization sequence shall
be performed using the specified single baud-rate (e.g. 500 kBit/s). If the baudrateRecord parameter contains
multiple baud-rates, then a multiple baud-rate initialization sequence including a baud-rate detection
procedure shall be performed using the specified multiple baud-rates (e.g. 250 kBit/s and 500 kBit/s).
By default the baudrateRecord contains all baud-rates specified in 7.7.2. The default content of the parameter
baudrateRecord can be superseded by any other list of baud-rates, e.g. single 500 kBit/s baud-rate as
specified in 8.3.3. For legislated-OBD baud-rates, the external test equipment shall use the appropriate CAN
bit timing parameter values defined in 7.7.3.
The external test equipment initialization sequence contains provisions for legacy vehicles using either CAN
(same or different physical layer as defined for WWH-OBD) or a different protocol (non-CAN) on the CAN pins
of the ISO 15031-3 diagnostic connector. This is to prevent legacy communication networks from being
disturbed by ISO/PAS 27145-compliant external test-equipment.
The initialization sequence is designed to support detection of the following CAN-identifier structures:
a) 11 bit CAN identifier verification procedure (see section 7.1.2), and
b) 29 bit CAN identifier verification procedure (see 7.1.3).
7.1.1 External test equipment error detection provisions
Where a vehicle uses CAN with a physical layer different from that specified for WWH-OBD (see section 7.7)
or a non-CAN protocol on the CAN pins of the OBD connector, the transmit procedure given as follows shall
guarantee that in all cases the external test equipment will detect that the vehicle does not support CAN as
specified for WWH-OBD and will stop the transmission of the request message immediately.
Where the vehicle uses CAN and the physical layer according to section 7.7, the transmit procedure given as
follows shall guarantee that in all cases the external test equipment will detect that it uses the wrong baud-rate
or the wrong physical layer configuration for the transmission of the request message and will stop disturbing
the CAN bus or whatever the vehicle's physical layer is 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 OBD ECU(s) reach critical values.
6 © ISO 2006 – All rights reserved

To achieve this, the external test equipment shall support the following features.
⎯ Possibility to stop sending immediately 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.
NOTE The second provision implies that the external test equipment can not 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).
7.1.2 11 bit CAN identifier verification procedure
7.1.2.1 Request message transmit procedure
The purpose of the 11 bit CAN identifier verification procedure is to determine whether 11 bit CAN identifiers
are being used in legislated-OBD communication and, if multiple baud-rates are specified in the
baudrateRecord parameter, to determine the baud-rate to be used for communication.
The procedure shall be performed as defined in Figure 2 — Functional 11 bit CAN identifier request
transmission.
a) The external test equipment shall set up its CAN interface using the first baud-rate contained in the
baudrateRecord. It shall use the CAN bit timing parameter values defined for this baud-rate (see section
7.7.3).
b) 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 0x12 and the desired
FunctionalGroupID (e.g. “Emissions system” or “Overall roadworthiness”) as specified in ISO/PAS 27145-3
using the WWH-OBD 11 bit functional request CAN identifier as defined in section 7.5.2.2.2.
c) 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 to off-page connector C.
d) If an acknowledge check error is detected, then the external test equipment shall continue to retry the
transmission of the request message until the timeout N_As (25 ms) has elapsed.
e) If any other CAN error occurred, or an acknowledge check error occurred after the N_As timeout (25 ms)
has elapsed, then the external test equipment shall disconnect its CAN Interface from the CAN bus. It
shall check whether more baud-rates are contained in the baudrateRecord. If no further baud-rate is
contained in the baudrateRecord, it shall indicate that the request was not transmitted successfully
(off-page connector G).
f) If the end of the baudrateRecord is not reached, the external test equipment shall set up its CAN interface
using the next baud-rate in the baudrateRecord. Following the CAN interface set-up, the external test
equipment shall restart the transmission of the request message (off-page connector B).
baudrateRecord
A
(a) Setup baudrate of the CAN interface to
first baudrate in the baudrateRecord
(f) Setup baudrate of the CAN Interface to
B
next baudrate in the baudrateRecord
(b) Transmit request message:
functional 11 bit request CAN Identifier,
Service $12, FunctionalGroupID for
desired functional GTR module as
specified in ISO27145-3
(c) (d) (e)
CAN error
YES ACK error NO
detected?
- Disconnect from
CAN bus
- Reset CAN
NO YES
Controller
End of
Timeout N_As
Tx done ? NO YES baudrateRecord NO
elapsed ?
reached ?
YES NO YES
C G
Transmit done Transmit error
Figure 2 — Functional 11 bit CAN identifier request transmission
8 © ISO 2006 – All rights reserved

7.1.2.2 Response handling procedure
The response handling procedure shall be used to receive 11 bit CAN identifier response messages from
WWH-OBD related ECUs and also to indicate when no response message have been received. If WWH-OBD
related ECUs are detected this procedure also builds the list of available ECUs on the WWH-OBD compliant
vehicle.
The response handling procedure shall be performed as defined in Figure 3 — 11 bit CAN identifier response
handling immediately after the 11 bit CAN identifier request message transmit procedure.
a) If the transmission of the request message was successful (off-page connector C), the external test
equipment shall start the P2 (see 7.2.2) application timer and listen for the physical response
CAN_Client
CAN identifiers as defined in section 7.5.2.2.2.
b) If the external test equipment detects a P2 timeout then no response message has been started and
CAN
the external test equipment has verified that 11 bit CAN identifiers are not used for WWH-OBD
communication (off-page connector D). In addition the external test equipment has determined that the
vehicle supports CAN, using the specified physical layer and one of the baud-rates contained in the
baudrateRecord array.
c) The start of a response message can either be the reception of a FirstFrame or SingleFrame which uses
one of the specified 11 bit physical response CAN identifiers (see section 7.5.2.2.2). 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 according to section 7.2.1, which use one of the specified 11 bit
CAN_Client
physical response CAN identifiers.
d) When all started response messages are completely received (positive and negative responses) and the
P2 application timer has elapsed, then the external test equipment shall analyse whether
CAN_Client
negative responses have been received. If one or more of the received response messages are negative
response messages with response code 0x21 (busyRepeatRequest), the external test equipment shall
start the 11 bit request transmission sequence (off-page connector B) again after a minimum delay of
200 ms. If the negative response(s) appear(s) on six (6) subsequent sequences the external test
equipment shall assume that the vehicle is not compliant with ISO/PAS 27145 (off-page connector G).
This implies that a WWH-OBD-compliant system shall provide a positive response within a maximum of
5 retries (1000 ms). If all ECUs respond with any other negative response code or all ECUs respond with
a response which can not be interpreted according to ISO/PAS 27145-3 the external test equipment shall
also assume that the vehicle is not compliant with ISO/PAS 27145 (off-page connector G).
e) If no negative response was detected according to step (d), the external test equipment has verified that
the vehicle supports 11 bit CAN identifiers for WWH-OBD communication. The external test equipment
shall build a list of the detected WWH-OBD related ECUs, which responded to the requested
FunctionalGroupID, based on the received physical responses. This list shall then be populated with the
ECU specific diagnostic protocol version (refer to ISO/PAS 27145-3) and capabilities according to section
7.2. This step finishes the initialization sequence (off-page connector F).
C
(a) Start P2
CAN_Client
timer
(b) (c)
Receive response(s)
P2
CAN_Client
YES
timeout ?
NO
P2 timeout
CAN_Client
Response
NO YES and all started responses NO
started ?
completed?
YES
(e) (d)
11 bit CAN identifiers
Busy
selected
RepeatRequest Max. number of
YES NO
neg. response ? retries exceeded?
NO YES
Build list with detected ECUs
Any other
based on physical responses
NO negative YES
for further physical
response?
communication
F G B D
ISO 27145-3 on 11 bit
CAN Id detected
Figure 3 — 11 bit CAN identifier response handling
7.1.3 29 bit CAN identifier verification procedure
7.1.3.1 Request message transmit procedure
The purpose of the 29 bit CAN identifier verification procedure is to determine whether 29 bit CAN identifiers
are being used for WWH-OBD communication. The same requirements as specified in section 7.1.1 apply to
the external test equipment when transmitting this request message. The procedure shall be performed as
shown in Figure 4 — 29 bit CAN identifier request transmission.
10 © ISO 2006 – All rights reserved

a) If the external test equipment reaches this point in the initialization sequence, this means that the CAN
baud-rate is already configured based on the previously performed 11 bit CAN identifier verification
procedure. The external test equipment shall transmit a functionally addressed request message with
service 0x12 and the desired FunctionalGroupID (e.g. “Emissions system” or “Overall roadworthiness”) as
specified in ISO/PAS 27145-3 using the WWH-OBD 29 bit functional request CAN identifier as defined in
7.5.2.2.3.
b) The external test equipment shall check for any CAN errors. If the request message is successfully
transmitted onto the CAN bus, the external test equipment shall indicate a successful transmission and
proceed to off-page connector E.
c) If an acknowledge check error is detected, then the external test equipment shall continue to retry the
transmission of the request message until the timeout N_As (25 ms) has elapsed.
d) If any other CAN error occurred, or an acknowledge check error occurred after the N_As timeout (25 ms)
has elapsed, then the external test equipment shall disconnect its CAN Interface from the CAN bus and
indicate that the request was not transmitted successfully (off-page connector G).

D
(a) Transmit request message:
functional 29 bit request CAN Identifier,
Service $12, FunctionalGroupID for
desired functional GTR module as
specified in ISO27145-3
(b) (c) (d)
CAN error
YES ACK error NO
detected?
NO YES
- Disconnect from
Timeout N_As CAN bus
Tx done ? NO YES
(25ms) elapsed ? -Reset CAN
Controller
YES NO
E G
Transmit done Transmit error
Figure 4 — 29 bit CAN identifier request transmission
7.1.3.2 Response handling procedure
The response handling procedure shall be used to receive 29 bit CAN identifier response messages from
WWH-OBD related ECUs and also to indicate when no response messages have been received. In case
WWH-OBD related ECUs are detected this procedure also builds the list of available ECUs on the WWH-OBD
compliant vehicle.
The 29 bit response handling shall be performed as defined in Figure 5 — 29 bit CAN identifier response
handling immediately after the 29 bit CAN identifier request message transmit procedure.

E
(a) Start P2
CAN_Client
timer
(b) (c)
Receive response(s)
P2
CAN_Client
YES
timeout ?
NO
P2 timeout
CAN_Client
Response
NO YES and all started responses NO
started ?
completed?
YES
(e) (d)
29 bit CAN identifiers
Busy
selected
RepeatRequest Max. number of
YES NO
neg. response ? retries exceeded?
NO YES
Build list with detected ECUs
Any other
based on physical responses
NO negative YES
for further physical
response?
communication
F G D G
ISO 27145-3 on 29 bit Continue with
CAN ID detected ISO15765-4 and
SAE J1939-73
initialization
Figure 5 — 29 bit CAN identifier response handling
12 © ISO 2006 – All rights reserved

a) If the transmission of the request message was successful (off-page connector E), the external test
equipment shall start the P2 (see 7.2.2) application timer and listen for the physical response
CAN_Client
CAN identifiers as defined in section 7.5.2.2.2.
b) If the external test equipment detects a P2 timeout then no response message has been started and
CAN
the external test equipment has verified that 29 bit CAN identifiers are not used for WWH-OBD
communication (off-page connector G). The external test equipment may now proceed to the ISO 15765-4
initialization with the currently active baud-rate from the baudrateRecord to detect any legislated-OBD
compliant ECUs. This allows for an optimized initialization sequence of ISO 15765-4 and ISO/PAS 27145
compliant external test equipment since the correct baud-rate has already been detected. Furthermore
the external test equipment may proceed to detect any SAE J1939-73 compliant ECUs.
c) The start of a response message can either be the reception of a FirstFrame or SingleFrame which uses
one of the specified 29 bit physical response CAN identifiers (see section 7.5.2.2.3). 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 according to section 7.2.1, which use one of the specified 29 bit
CAN_Client
physical response CAN identifiers.
d) When all started response messages are completely received (positive and negative responses) and the
P2 application timer has elapsed, then the external test equipment shall analyse whether
CAN_Client
negative responses have been received. If one or more of the received response messages are negative
response messages with response code 0x21 (busyRepeatRequest), the external test equipment shall
restart the request transmission sequence (off-page connector D) again after a minimum delay of 200 ms.
If the negative response(s) appear(s) on six (6) subsequent sequences the external test equipment shall
assume that the vehicle is not compliant with ISO/PAS 27145 (off-page connector G). This implies that a
WWH-OBD-compliant system shall provide a positive response within a maximum of 5 retries (1000 ms).
If all ECUs respond with any other negative response code or all ECUs respond with a response which
can not be interpreted according to ISO/PAS 27145-3 the external test equipment shall also assume that
the vehicle is not compliant with ISO/PAS 27145 (off-page connector G).
e) If no negative response was detected according to step (d), the external test equipment has verified that
the vehicle supports 29 bit CAN identifiers for WWH-OBD communication. The external test equipment
shall build a list of the detected WWH-OBD related ECUs which responded to the requested
FunctionalGroupID based on the received physical responses. This list shall then be populated with the
ECU specific diagnostic protocol version (refer to ISO/PAS 27145-3) and capabilities according to section
7.2. This step finishes the initialization sequence (off-page connector F).
7.2 Application layer
The application layer for the diagnostic services which are utilized to convert diagnostic data shall be
implemented as defined in reference ISO/PAS 27145-3.
Each WWH-OBD compliant ECU shall implement the diagnostic service “Read Protocol Identification” defined
in ISO/PAS 27145-3. When an ECU does not support the requested Functional Group Identification, the ECU
shall not respond to a functionally addressed request for this service according to ISO/PAS 27145-3. Other
diagnostic services defined in ISO/PAS 27145-3 shall be implemented based on the WWH-OBD related
ECU's capabilities.
NOTE This service is necessary to provide a consistent identification method for the external test equipment to
determine and adapt to the protocol version and the functional groups of the WWH-OBD compliant ECUs.
An ISO/PAS 27145 compliant vehicle shall only respond to ISO/PAS 27145-3 requests from external test
equipment. It shall not respond to ISO 15031-5 diagnostic protocol requests concurrently.
The external test equipment shall be capable of supporting a list of detected WWH-OBD related ECUs
(generated during initialization sequence as defined in section 7.1.2.2 and 7.1.3.2) and the specific supported
protocol version and features according to ISO/PAS 27145-2 and ISO/PAS 27145-3. The minimum supported
attributes per ECU in that list are:
⎯ Protocol version information (ISO/PAS 27145-3)
⎯ Functional Group Identifiers
⎯ Supported Unified Data Identifiers
This list is necessary for the external test equipment to:
⎯ be capable to separate responses to functionally addressed requests for emissions related ECUs from
ECUs which are compliant to a different WWH-OBD GTR module;
⎯ take advantage of the possibility to transmit long physically addressed request messages (compared to
functionally addressed messages) during WWH-OBD related communication.
7.2.1 Diagnostic protocol communication types
The following communication types shall be supported for the diagnostic protocol implementation for WWH-
OBD on CAN:
a) physical communication
b) functional communication
According to section 7.4 of this document all WWH-OBD communication is performed in the default session.
Consequently the following sections of ISO 15765-3 apply for WWH-OBD communication on CAN:
⎯ 6.3.5.1.1 Physical communication during defaultSession
⎯ 6.3.5.1.2 Physical communication during defaultSession with enhanced response timing
⎯ 6.3.5.2.1 Functional communication during defaultSession
⎯ 6.3.5.2.2 Functional communication during defaultSession with enhanced response timing
⎯ 6.3.5.3 Minimum time between client request messages
Each diagnostic service specified in ISO/PAS 27145-3 can either be transmitted functionally or physically by
the external test equipment.
NOTE Larger diagnostic requests (longer than 7 bytes) must be transmitted using physical addressing (e.g. the
request of multiple UDIDs from one ECU) while short diagnostic requests (equal to or smaller than 7 bytes) which are
supported by most ECUs can be transmitted using functional addressing.
7.2.2 Diagnostic protocol timing parameters
For all diagnostic services specified in ISO/PAS 27145-3, the possibility of requesting an enhanced response-
timing window by the server via a negative response message, including a response code 0x78
(requestCorrectlyReceived-ResponsePending), shall be supported.
Session layer timing handling is not required for WWH-OBD communication as only the defaultSession is
used for the services define in ISO/PAS 27145-3.
The application layer timing parameter values of an ECU for the default diagnostic session shall be in
accordance with Table 3 — Application layer timing parameter definitions for the defaultSession.
14 © ISO 2006 – All rights reserved

Table 3 — Application layer timing parameter definitions for the defaultSession
Timing Description Type min max
Parameter
Timeout for the client to wait after the successful
transmission of a request message (indicated via
N_USData.con) for the start of incoming response Timer reload

a
P2 50 ms N/A
CAN_Client
messages (N_USDataFirstFrame.ind of a multi- value
frame message or N_USData.ind of a SingleFrame
message).
Enhanced timeout for the client to wait after the
reception of a negative response message with
response code 0x78 (indicated via N_USData.ind) Timer reload
b
P2* 5000 ms N/A
CAN_Client
for the start of incoming response messages value
(N_USDataFirstFrame.ind of a multi-frame message
or N_USData.ind of a SingleFrame message).
Performance requirement for the server to start with
Performance
P2 the response message after the reception of a 0 ms 40 ms
CAN_Server
requirement
request message (indicated via N_USData.ind).
Performance requirement for the server to start wi
...