ISO 15031-5:2006

INTERNATIONAL ISO
STANDARD 15031-5
First edition
2006-01-15
Road vehicles — Communication
between vehicle and external equipment
for emissions-related diagnostics —
Part 5:
Emissions-related diagnostic services
Véhicules routiers — Communications entre un véhicule et un
équipement externe pour le diagnostic relatif aux émissions —
Partie 5: Services de diagnostic relatif aux émissions

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 2005
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 . 4
5 Technical requirements . 4
5.1 General requirements. 4
5.2 Diagnostic service requirements . 4
5.3 Diagnostic message format. 25
5.4 Allowance for expansion and enhanced diagnostic services . 29
5.5 Definition of PIDs for Services $01 and $02.29
5.6 Format of data to be displayed. 29
6 Diagnostic service definition for ISO 9141-2, ISO 14230-4, and SAE J1850. 31
6.1 Service $01 — Request current powertrain diagnostic data. 31
6.2 Service $02 — Request powertrain freeze frame data. 35
6.3 Service $03 — Request emission-related diagnostic trouble codes. 39
6.4 Service $04 — Clear/reset emission-related diagnostic information . 44
6.5 Service $05 — Request oxygen sensor monitoring test results . 46
6.6 Service $06 — Request on-board monitoring test results for specific monitored systems. 51
6.7 Service $07 - Request emission-related diagnostic trouble codes detected during current
or last completed driving cycle . 56
6.8 Service $08 — Request control of on-board system, test or component. 57
6.9 Service $09 — Request vehicle information . 60
7 Diagnostic service definition for ISO 15765-4 . 73
7.1 Service $01 — Request current powertrain diagnostic data. 73
7.2 Service $02 — Request powertrain freeze frame data. 79
7.3 Service $03 — Request emission-related diagnostic trouble codes. 84
7.4 Service $04 — Clear/reset emission-related diagnostic information . 87
7.5 Service $05 — Request oxygen sensor monitoring test results . 88
7.6 Service $06 — Request on-board monitoring test results for specific monitored systems. 89
7.7 Service $07 — Request emission-related diagnostic trouble codes detected during
current or last completed driving cycle. 99
7.8 Service $08 — Request control of on-board system, test or component. 100
7.9 Service $09 — Request vehicle information . 104
Annex A (normative) PID (Parameter ID)/OBDMID (On-Board Monitor ID)/TID (Test ID)/INFOTYPE
supported definition . 114
Annex B (normative) PIDs (Parameter ID) for Services $01 and $02 scaling and definition. 115
Annex C (normative) TIDs (Test ID) scaling description. 148
Annex D (normative) OBDMIDs (On-Board Diagnostic Monitor ID) definition for Service $06 . 149
Annex E (normative) Unit and Scaling definition for Service $06. 154
Annex F (normative) TIDs (Test ID) for Service $08 scaling and definition . 177
Annex G (normative) INFOTYPEs for Service $09 scaling and definition. 178
Bibliography . 185

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 15031-5 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronical equipment.
ISO 15031 consists of the following parts, under the general title Road vehicles — Communication between
vehicle and external equipment for emissions-related diagnostics:
⎯ Part 1: General information
⎯ Part 2: Terms, definitions, abbreviations and acronyms
⎯ Part 3: Diagnostic connector and related electrical circuits, specification and use
⎯ Part 4: External test equipment
⎯ Part 5: Emissions-related diagnostic services
⎯ Part 6: Diagnostic trouble code definitions
⎯ Part 7: Data link security
iv © ISO 2006 – All rights reserved

Introduction
ISO 15031 consists of a number of parts which, taken together, provide a coherent self-consistent set of
specifications to facilitate emissions-related diagnostics. Parts 2 through 7 are based on SAE recommended
practices. This part is based on SAE J1979 SEP97 (E/E Diagnostic Test Modes).
ISO 15031-1 provides an introduction to the series of International Standards.
This part of ISO 15031 is based on the Open Systems Interconnection (OSI) Basic Reference Model in
accordance with ISO/IEC 7498 and ISO/IEC 10731, which structures communication systems into seven
layers as shown in the table below.
Table 1 — Applicability and relationship between documents
Applicability OSI 7 layer Emissions-related diagnostics
ISO 11898,
Physical (layer 1) ISO 9141-2 ISO 14230-1 SAE J1850
ISO 15765-4
ISO 11898,
Data link (layer 2) ISO 9141-2 ISO 14230-2 SAE J1850
ISO 15765-4
Seven layer
ISO 15765-2,
according to
Network (layer 3) — — —
ISO 15765-4
ISO/IEC 7498
and
Transport (layer 4) — — — —
ISO/IEC 10731
Session (layer 5) — — — ISO 15765-4
Presentation (layer 6) — — — —
Application (layer 7) ISO 15031-5 ISO 15031-5 ISO 15031-5 ISO 15031-5

INTERNATIONAL STANDARD ISO 15031-5:2006(E)

Road vehicles — Communication between vehicle and external
equipment for emissions-related diagnostics —
Part 5:
Emissions-related diagnostic services
1 Scope
This part of ISO 15031 specifies diagnostic services and functionally addressed request/response messages
required to be supported by motor vehicles and external test equipment for diagnostic purposes which pertain
to motor vehicle emission-related data. Any external test equipment meeting the requirements of ISO 15031-4
use these messages to retrieve emissions-related information from the vehicle.
Each section of this part of ISO 15031, which specifies additional detail to existing sections of ISO 9141-2,
ISO 14230-4, SAE J1850, and ISO 15765-4 supersede those specifications.
NOTE This part of ISO 15031 provides the mechanism to satisfy the requirements included in the country-specific
regulations and not all capabilities included in this document are required by the country-specific regulations. This part of
ISO 15031 also is not considered a final authority for interpretation of the regulations, so readers should determine the
applicability of capabilities defined in this document for their specific needs.
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 9141-2, Road vehicles — Diagnostic systems — Part 2: CARB requirements for interchange of digital
information
ISO 9141-2/Amendment 1, Road vehicles — Diagnostic systems — Part 2: CARB requirements for
interchange of digital information
ISO 14230-4, Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 4: Requirements for
emission-related systems
ISO 15031-1, Road vehicles — Communication between vehicle and external equipment for emissions-related
diagnostics — Part 1: General information
ISO/TS 15031-2, Road vehicles — Communication between vehicle and external equipment for emissions-
related diagnostics — Part 2: Terms, definitions, abbreviations and acronyms
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-4, Road vehicles — Communication between vehicle and external equipment for emissions-related
diagnostics — Part 4: External test equipment
ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for emissions-related
diagnostics — Part 6: Diagnostic trouble code definitions
ISO 15765-2, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 2: Network layer
services
ISO 15765-4, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 4: Requirements for
emissions-related systems
SAE J1850: MAY2001,Class B Data Communications Network Interface
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 15031-2 and the following apply.
3.1
absolute throttle position sensor
value intended to represent the throttle opening
NOTE For systems where the output is proportional to the input voltage, this value is the percent of maximum input
signal. For systems where the output is inversely proportional to the input voltage, this value is 100 % minus the percent of
maximum input signal. Throttle position at idle usually indicates greater than 0 %, and throttle position at wide open throttle
usually indicates less than 100 %.
3.2
bank
specific group of cylinders sharing a common control sensor, bank 1 always containing cylinder number 1,
bank 2 the opposite bank
NOTE If there is only one bank, bank #1 DTCs is used, and the word bank may be omitted. With a single “bank”
system utilising multiple sensors, bank #1 DTCs is used identifying the sensors as #1, #2, #3 in order as they move further
away from the cylinder(s).
3.3
base fuel schedule
the fuel calibration schedule programmed into the Powertrain Control Module or PROM when manufactured or
when updated by some off-board source, prior to any learned on-board correction
3.4
Calculated Load Value
for spark ignition engines, typically an indication of the current airflow divided by peak airflow at wide open
throttle as a function of rpm, where airflow is corrected for altitude and ambient temperature
NOTE 1 This definition provides a unit-less number, and provides the service technician with an indication of the
percent engine capacity that is being used.
NOTE 2 For diesel applications, the calculated load value shall be determined by substituting fuelflow in place of
airflow in the calculation.
3.5
client
function that is part of the tester and that makes use of the diagnostic services
NOTE A tester normally makes use of other functions such as data base management, specific interpretation,
man-machine interface.
3.6
continuous monitoring
sampling at a rate no less than two samples per second
2 © ISO 2006 – All rights reserved

3.7
convention
Cvt
column integrated in each message table which marks each parameter included
NOTE The following conventions are used: C = Conditional: the parameter marked “C” in a request/response
message is present only under a condition specified in the bottom row of the message table. M = Mandatory: the
parameter marked “M” in a request/response message table is always present. U = User optional: the parameter marked
“U” in a request/response message table is or is not supplied, depending on dynamic usage by the manufacturer. The
convention recommends a mnemonic, which might be used for implementation. In no case is the specified mnemonic a
mandatory requirement for any implementation.
3.8
Electronic Control Unit
ECU
generic term for any electronic control unit
3.9
Fuel Trim
FT
feedback adjustments to the base fuel schedule
NOTE Short-term fuel trim refers to dynamic or instantaneous adjustments. Long-term fuel trim refers to much more
gradual adjustments to the fuel calibration schedule than short-term trim adjustments. These long-term adjustments
compensate for vehicle differences and gradual changes that occur over time.
3.10
negative numbers
signed binary, the most significant bit (MSB) of the binary number used to indicate positive (0) / negative (1)
NOTE 1 2s complement: negative numbers are represented by complementing the binary number and then adding 1.
EXAMPLE – 0,99 = 8001 hex = 1000 0000 0000 0001 binary
0 = 0000 hex = 0000 0000 0000 0000 binary
+ 0,99 = 7FFF hex = 0111 1111 1111 1111 binary
NOTE 2 (– 0,99) + (+ 0,99) = 0.
3.11
number
expressed by this symbol “#”
3.12
P2, P3 timing parameter
application timing parameters for the ECU(s) and the external test equipment
3.13
server
function that is part of an electronic control unit that provides the diagnostic services
NOTE This part of ISO 15031 differentiates between the server (i.e. the function) and the electronic control unit so
that this document remains independent from the implementation.
3.14
service
information exchange initiated by a client (external test equipment) in order to require diagnostic information
from a server (ECU) and/or to modify its behaviour for diagnostic purpose
NOTE This is also the equivalent of test mode or mode.
4 Symbols and abbreviated terms
CVN Calibration Verification Number
ECM Engine Control Module
ISR Interrupt Service Routine
LSB Least Significant Bit
MSB Most Significant Bit
NRC Negative Response Code
PCM Powertrain Control Module
SI International System of Units
TCM Transmission Control Module
5 Technical requirements
5.1 General requirements
The requirements specified in this clause are necessary to ensure proper operation of both the external test
equipment and the vehicle during diagnostic procedures. External test equipment, when using messages
specified, shall not affect normal operation of the emission control system.
5.2 Diagnostic service requirements
5.2.1 Multiple responses to a single data request
The request messages are functional messages, which means the external test equipment will request data
without knowledge of which ECU(s) on the vehicle will respond. In some vehicles, multiple ECUs may respond
with the information requested. Any external test equipment requesting information shall therefore have
provisions for receiving multiple responses.
IMPORTANT — All emissions-related OBD ECUs which at least support one of the services defined in
this part of ISO 15031 shall support service $01 and PID $00. Service $01 with PID $00 is defined as the
universal “initialization/keep alive/ping” message for all emissions-related OBD ECUs.
5.2.2 Application timing parameter definition
5.2.2.1 Overview
The definition of P2 and P3 is included in this clause. A subscript is added to each timing parameter to identify
the protocol:
⎯ P2 P3 : P2, P3 for ISO 9141-2 and ISO 14230-4 protocols
K-line, K-line
⎯ P2 : P2 for SAE J1850 protocol
J1850
⎯ P2 : P2 for ISO 15765-4 protocol
CAN
IMPORTANT — It is the vehicle manufacturer’s responsibility to specify a shorter P2 timing window
than specified in this part of ISO 15031 for each emission-related server/ECU in the vehicle to make
sure that network topology delays of the vehicle architecture are considered.
4 © ISO 2006 – All rights reserved

5.2.2.2 Definition for ISO 9141-2
For ISO 9141-2 interfaces, Data Link Layer response time requirements (P1, P4) are specified in ISO 9141-2.
Table 2 specifies the application timing parameter values for P2 and P3.
Table 2 — Definition ISO 9141-2 application timing parameter values
Parameter Minimum Maximum Description
value value (ms)
(ms)
Time between external test equipment request message and the successful
P2 25 50
K-line
transmission of the ECU(s) response message(s). Each OBD ECU shall start
Key Bytes:
sending its response message within P2 after the request message has been
K-line
$08 $08
correctly received. Subsequent response messages shall also be transmitted
within P2 of the previous response message for multiple message responses.
K-line
Time between external test equipment request message and the successful
P2 0 50
K-line
transmission of the ECU response message(s). The OBD ECU shall start sending
Key Bytes:
its response message within P2 after the request message has been
K-line
$94 $94
correctly received. Subsequent response messages shall also be transmitted
within P2 of the previous response message for multiple message responses.
K-line
Time between the end of an ECU(s) successful transmission of response
P3 55 5000
K-line
message(s) and start of new external test equipment request message. The
external test equipment may send a new request message if all response
messages related to the previously sent request message have been received
and if P3 minimum time expired.
K-line
ECU implementation guideline: TX (transmit) and RX (receive) line are connected.
Each transmitted byte is read back by the receiver in the ECU. Upon the reception
of a received byte, e.g. last byte of a request message (checksum) from the
tester, the ECU shall reset the P3 timer value to zero. If the ECU supports the
request message, it will start transmitting the response message within the P2
timing window. Each transmitted byte will cause the P3 timer value to be reset. If
the ECU does not support the request and does not send a response message
then in a single OBD ECU system the P3 is started with the last byte received of
the request message. In a multiple OBD ECU system a response message by any
one or more ECUs shall cause the P3 timer value to be reset in all ECUs including
any ECU not supporting the request message.

5.2.2.3 Definition for ISO 14230-4
For ISO 14230-4 interfaces, Data Link Layer response time requirements are specified in ISO 14230-4.
Table 3 specifies the application timing parameter values for P2 and P3.
Table 3 — Definitions of ISO 14230-4 application timing parameter values
Parameter Minimum Maximum Description
value value
(ms) (ms)
P2 25 50 Time between external test equipment request message and the successful
K-line
transmission of the ECU(s) response message(s). Each OBD ECU shall start
sending its response message within P2 after the request message has been
K-line
correctly received. Subsequent response messages shall also be transmitted
within P2 of the previous response message for multiple message responses.
K-line
P3 55 5000 Time between the end of an ECU(s) successful transmission of response
K-line
message(s) and start of new external test equipment request message. The
external test equipment may send a new request message if all response
messages related to the previously sent request message have been received
and if P3 minimum time expired.
K-line
ECU implementation guideline: TX (transmit) and RX (receive) line are connected.
Each transmitted byte is read back by the receiver in the ECU. Upon the reception
of a received byte, e.g. last byte of a request message (checksum) from the
tester, the ECU shall reset the P3 timer value to zero. If the ECU supports the
request message, it will start transmitting the response message within the P2
timing window. Each transmitted byte will cause the P3 timer value to be reset. If
the ECU does not support the request and does not send a response message,
then in a single OBD ECU system the P3 is started with the last byte received of
the request message. In a multiple OBD ECU system, a response message by
any one or more ECUs shall cause the P3 timer value to be reset in all ECUs
including any ECU not supporting the request message.

5.2.2.4 Implementation guidance example for ISO 9141-2 and ISO 14230-4 protocols
This subclause provides an implementation example for client/external test equipment and server/ECU. It is
assumed that the client (external test equipment) communicates to a vehicle with two (2) emission-related
OBD servers (ECUs). The client requests a CVN, which is only supported by server #1 (ECU #1) with two (2)
response messages. Server #2 (ECU #2) is not flash programmable. Figure 1 graphically depicts the timing
handling in the client and two (2) servers for a functionally addressed request message. A description follows
the figure that references the points marked in Figure 1.
From a server point of view, there is no difference in the timing handling compared to a physically addressed
request message. The server shall reset the P3 timer value on each received byte regardless of whether
K-line
the byte is part of a request message or a response message from any another server or an echo from its
transmit line. There are several methods of how a server could implement the timing handling. The
implementation of timing parameters is not part of this International Standard but an important system supplier
responsibility. Some general server timing parameter implementation guidelines are described in this
subclause. The server time stamps each receiver interrupt event and restarts/resets the P3 timer or
K-line_server
timing value, e.g. ISR time stamps received byte, and processing of the received information is performed
outside the ISR. For simplification of the diagram, the Figure 1 only shows a P3 restart after the
K-line_server
reception of the first byte and last byte (checksum) of a received message. The P3 restart is
K-line_server
required on each received byte. The received message can be either a request message from the client or a
response message from any other server connected and initialized by the 33 hex address. If the server has
received a complete message, it compares the target address with the 33 hex address.

6 © ISO 2006 – All rights reserved

Figure 1 — ISO 9141-2 and ISO 14230-4 protocol client and server timing behaviour
Figure 1 shows the client and two (2) initialized servers connected via K-line (either ISO 9141-2 or
ISO 14230-4 protocol). The relevant events for the client and both servers are marked and described.
a) The diagnostic application of the client starts the transmission of a functionally addressed request
message by issuing a DL_Data.request to its data link layer. The data link layer transmits the request
message to the servers.
b) Both servers and the client receive a byte of a message via a receive interrupt by the UART. The ISR
(Interrupt Service Routine) either restarts the P2 /P3 timers or time stamps the received byte.
K-line K-line
c) The completion of the request message is indicated in the client with DL_Data.confirmation. When
receiving the DL_Data.confirmation, the client starts its P2 and P3 timer, using the default reload
K-line K-line
values P2 and P3 .
K-line_max K-line_max
d) If the last message byte is received, each server checks whether the received message includes a target
address which matches the 33 hex address. If the result is a match (server #1 and #2), then the
completion of the request message is indicated in the servers via DL_Data.indication and each server
determines whether it supports the request and has a message available to respond with. If a server
determines that the address in the received message is different from 33 hex, or if the address is a match
but no response needs to be sent (server #2), the P2 timer is stopped. Since the P3 timer has
K-line
already been restarted, no further action is required. If a response message is available and has to be
sent (server #1, but not server #2), then the transmission of the response message shall be started after
P2 timing is expired.
K-line_min
e) Server #1 starts the response message by indicating a DL_Data.request from the application to the data
link layer and at the same time stops its P2 timer.
K-line
f) Both servers and the client receive a byte of a message via a receive interrupt by the UART. The ISR
(Interrupt Service Routine) restarts the P2 /P3 timers or time stamps the received byte and the
K-line K-line
client issues a DL_Data_FB.indication to the application layer.
g) The completion of the response message is indicated in the client with DL_Data.indication. When
receiving the DL_Data.indication, the client starts its P2 and P3 timer, using the default reload
K-line K-line
values P2 and P3 .
K-line_max K-line_max
h) Both servers have received the last byte of a message via a receive interrupt by the UART. The ISR
(Interrupt Service Routine) either resets the P2 /P3 timers or time stamps the received byte. The
K-line K-line
completion of the response message (e.g. length and checksum check) is indicated in server #1 via
DL_Data.confirmation. If server #1 does not want to send further response messages, it stops its P2 timer.
In server #2 the message is received and the P3 timer is restarted, but no DL_Data.indication is
K-line
forwarded to the application because the target address does not match the 33 hex (target address of this
message is the tester address F1 hex).
i) The client application detects a P2 timeout, which indicates that all response messages from all
K-line_max
servers are received.
j) The client application indicates that P3 is reached and that the P3 timing window is now
K-line_min K-line
open to send a new request message [see a)].
5.2.2.5 Definition for SAE J1850
For SAE J1850 network interfaces, the on-board systems shall respond to a request within P2 of a
J1850
request or a previous response message. With multiple response messages possible from a single request
message, this allows as much time as is necessary for all ECUs to access the data link and transmit their
response message(s). If there is no response message within this time period, the external test equipment
can either assume no response message will be received, or if a response message has already been
received, that no more response messages will be received. The application timing parameter value P2 is
J1850
specified in Table 4.
Table 4 — Definition of SAE J1850 application timing parameter values
Parameter Minimum Maximum Description
value value
(ms) (ms)
P2 0 100 Time between external test equipment request message and the successful
J1850
transmission of the ECU(s) response message(s). Each OBD ECU shall
attempt to send its response message (or at least the first of multiple response
messages) within P2 after the request message has been correctly
J1850
received. Subsequent response messages shall also be transmitted within
P2 of the previous response message for multiple message responses.
J1850
8 © ISO 2006 – All rights reserved

5.2.2.6 Definition for ISO 15765-4
For CAN bus systems based on ISO 15765-4, the (all) responding ECU(s) of the on-board system shall
respond to a request message within P2 . The table below specifies the application timing parameter
CAN
values for P2.
Table 5 — Definition of ISO 15765-4 application timing parameter values
Parameter Minimum Maximum Description
value value
(ms) (ms)
P2 0 50 Time between external test equipment request message and the receipt of all
CAN
unsegmented response messages and all first frames of segmented response
message(s).
In case the vehicle’s network architecture uses a gateway to report emissions-
related diagnostic data, all unsegmented response messages and all first
frames of segmented response message(s) shall be received by the external
test equipment within P2 .
CAN
P2* 0 5000 Time between the successful reception of a negative response message with
CAN
response code $78 and the next response message (positive or negative
message).
A negative response message with NRC 78 hex shall not be used as a
response message to a service $01 request.
5.2.2.7 Implementation guidance example for ISO 15765-4 protocol
5.2.2.7.1 Functional OBD communication during defaultSession
Figure 2 graphically depicts the timing handling in the client and two (2) servers for a functionally addressed
request message during the default session. A description follows the figure that references the points marked
in Figure 2.
Figure 2 — Functional OBD communication: Default response timing
From a server point of view, there is no difference in the timing handling compared to a physically addressed
request message, but the client shall handle the timing differently compared with physical communication.
a) The diagnostic application of the client starts the transmission of a functionally addressed request
message by issuing an N_USData.req to its network layer. The network layer transmits the request
message to the servers. A functionally addressed request message shall only be a single-frame message.
b) The completion of the request message is indicated in the client via N_USData.con. When receiving the
N_USData.con, the client starts its P2 timer, using the default reload value P2 . For simplicity,
CAN CAN
Figure 2 assumes that the client and the server are located on the same network.
c) The completion of the request message is indicated in the servers via N_USData.ind.
d) The functionally addressed servers are required to start with their response messages within P2 after
CAN
the reception of N_USData.ind. This means that in case of multi-frame response messages, the
FirstFrame shall be sent within P2 and, for single-frame response messages, that the SingleFrame
CAN
shall be sent within P2 .
CAN
e) In case of a multi-frame response message, the reception of the FirstFrame from any server is indicated
in the client via the N_USDataFF.ind of the network layer. A single-frame response message is indicated
via N_USData.ind.
f) When receiving the FirstFrame/SingleFrame indication of an incoming response message, the client
either stops its P2 in case it knows the servers to be expected to respond and all servers have
CAN
responded, or keeps the P2 running if the client does not know the servers to be expected to respond
CAN
(client awaits the start of further response messages). The network layer of the client will generate a final
N_USData.ind in case the complete message is received or an error occurred during the reception. The
reception of a final N_USData.ind of a multi-frame message in the client will not have any influence on the
P2 timer.
CAN
10 © ISO 2006 – All rights reserved

g) The completion of the transmission of the response message will also be indicated in the servers via
N_USData.con.
5.2.2.7.2 Functional OBD communication during defaultSession with enhanced response timing
Figure 3 graphically depicts the timing handling in the client and two (2) servers for a functionally addressed
request message during the default session, where one server requests an enhanced response timing via a
negative response message including response code 78 hex. A description follows the figure that references
the points marked in Figure 3.

Figure 3 — Functional OBD communication – enhanced response timing
From a server point of view, there is no difference in the timing handling compared to a physically addressed
request message that requires enhanced response timing, but the client shall handle the timing differently
compared with physical communication.
a) The diagnostic application of the client starts the transmission of the functionally addressed request
message by issuing a N_USData.req to its network layer. The network layer transmits the request
message to the servers. A functionally addressed request message shall only be a single-frame message.
b) The completion of the request message is indicated in the client via N_USData.con. When receiving
N_USData.con, the client starts its P2 timer, using the default reload value P2 . For the response
CAN CAN
message, the value of the P2 timer shall consider any latency that is involved based on the vehicle
CAN
network design (e.g. communication over gateways, bus bandwidth, etc.). For simplicity, the figure
assumes that the client and the server are located on the same network.
c) The completion of the request message is indicated in the servers via N_USData.ind.
d) The functionally addressed servers shall start with their response messages within P2 after the
CAN
reception of N_USData.ind. This means that in case of a multi-frame response messages, the FirstFrame
shall be sent within P2 and for single-frame response messages, that the SingleFrame shall be sent
CAN
within P2 . In case any of the addressed servers cannot provide the requested information within the
CAN
P2 response timing, it can request an enhanced response-timing window by sending a negative
CAN
response message including response code 78 hex (this is not allowed for service $01).
e) Upon the reception of the negative response message within the client, the client network layer generates
a N_USData.ind. The reception of a negative response message with response code 78 hex causes the
client to continue its P2 timer in order to observe other servers to respond within P2 . In addition,
CAN CAN
the client establishes an enhanced P2* timer for observation of further server #1 response(s). The
CAN
client shall store a server identification in a list of pending response messages. Once a server that is
stored as pending in the client starts with its final response message (positive response message or
negative response message including a response code other than 78 hex), it is deleted from the list of
pending response messages. For simplicity, Figure 5 only shows a single negative response message
including response code 78 hex from server #1.
f) Server #2 transmits a FirstFrame of a multi-frame response message within P2* . The reception of the
CAN
FirstFrame is indicated in the client network layer by a N_USDataFF.ind. Figure 5 shows when the client
receives the start of the response message of the second server.
g) Server #1 previously indicated to the client (e) enhanced response timing. Once server #1 can provide
the requested information, it starts with its final response message by issuing a N_USData.req to its
network layer. If server #1 can still not provide the requested information within the enhanced P2* ,
CAN
then a further negative response message including response code 78 hex can be sent. This will cause
the client to reload its P2* timer value again. A negative response message including response code
CAN
78 hex from a server that is already stored in the list of pending response messages has no affect to the
client internal list of pending response message.
h) Server #1 transmits a FirstFrame of a multi-frame response message within P2* . The reception of the
CAN
FirstFrame is indicated in the client network layer by a N_USDataFF.ind. Figure 5 shows when the client
receives the start of the response message of the server #1. The client removes server #1 from the
internal list of pending response messages.
i) The client network layer will generate a N_USData.ind.
j) The server network layer will generate a N_USData.con based on the completion of the transmission.
5.2.3 Minimum time between requests from external test equipment
5.2.3.1 ISO 9141-2, ISO 14230-4 — Minimum time between requests from external test equipment
For ISO 9141-2 (K-line) interfaces, the required times between request messages are specified in ISO 9141-2.
12 © ISO 2006 – All rights reserved

For ISO 14230-4 (K-line) interfaces, the required times between request messages are specified in
ISO 14230-4. Figure 4 shows an example of a request message followed by four (4) response messages and
another request message.
Figure 4 — ISO 9141-2 (Key Bytes: $08 $08) and ISO 14230-4 application timing parameter overview
5.2.3.2 SAE J1850 — Minimum time between requests from external test equipment
For SAE J1850 network interfaces, an external test equipment shall always wait for a response message from
the previous request, or “no response” time-out before sending another request message. If the number of
response messages is known and all response messages have been received, then the external test
equipment is permitted to send the next request message immediately. If the number of response messages
is not known, then the external test equipment shall wait at least P2 maximum time.
J1850
Figure 5 shows an example of a request message followed by four (4) response messages and another
request message.
Figure 5 — SAE J1850 application timing parameter overview
5.2.3.3 ISO 15765-4 — Minimum time between requests from external test equipment
For ISO 15765-4 network interfaces, the external test equipment may send a new request message
immediately after it has determined that all responses related to the previously sent request message have
been received. If the external test equipment does not know whether it has received all response messages,
(e.g. after sending the initial OBD request message: Service $01, PID $00), it shall wait (P2 maximum)
CAN
after the last request (if no responses are sent) or the last response message. The timer P2 of the external
CAN
test equipment starts with the confirmation of a successful transmission of the request message.
Figure 6 shows an example of a request message followed by three (3) single-frame response messages and
another request message.
14 © ISO 2006 – All rights reserved

Figure 6 — ISO 15765-4 application timing parameter (Single Frame Response Messages) overview
Figure 7 shows an example of a request message followed by two (2) single frames, one (1) multiple frame
response message and another request message. The next request message can be sent immediately by the
external test equipment after completion of all response messages in case the transmission of the response
messages takes longer than P2 even if the external test equipment does not know the number of
CAN
responding ECUs.
Figure 7 — ISO 15765-4 application timing parameter (Single and Multiple Frame Response Messages
not finished within P2 ) overview
CAN
NOTE The Network Layer timing parameters for the multiple frame response are not shown. Network Layer timing
requirements for legislated diagnostic messages are sp
...