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

2 Normative references

ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
ISO 11898-2, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 15031-3, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 3: Diagnostic connector and related electrical circuits: Specification and use
ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services

3 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1, ISO 11898-1, ISO 11898-2, ISO 15765-2 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/

3.1 OBDonEDS

on-board diagnostics on emission diagnostic service
application protocol request and response messages defined in ISO 15031-5/SAE J1979[4] dedicated to the diagnostics of emissions-related systems

3.2 OBDonUDS

on-board diagnostics on unified diagnostic service
application protocol request and response messages defined in the ISO 14229 series and in ISO 27145-3 or SAE J1979-2[5] dedicated to the diagnostics of emissions-related systems

4 Symbols and abbreviated terms

4.1 Symbols

— empty table cell or feature undefined
B block size
C , C capacitance of AC termination
AC1 AC2
C capacitance between CAN_H and ground potential
CAN_H
C capacitance between CAN_L and ground potential
CAN_L
C capacitance between CAN_H and CAN_L
DIFF
ΔO oscillator frequency tolerance
F consecutive frame
F flow control frame
F first frame
F frame flow status
F single frame
l maximum cable length between diagnostic link connector and external test
CABLE
equipment
R , R resistance of AC termination
AC1 AC2
t bit time
BIT
t receive bit time
BIT_RX
t transmit bit time
BIT_TX
t external test equipment CAN interface propagation delay (without external test
ETE
equipment cable delay)
t external test equipment cable propagation delay (without external test equip-
ETE_CABLE
ment CAN interface delay)
t network layer timeout value (see ISO 15765-2)
N_Ar
t network layer timeout value (see ISO 15765-2)
N_As
t network layer timeout value (see ISO 15765-2)
N_Br
t network layer timeout value (see ISO 15765-2)
N_Bs
t network layer timeout value (see ISO 15765-2)
N_Cs
t network layer timeout value (see ISO 15765-2)
N_Cr
t client application wait time on server response on CAN
P2_CAN_Client
t timeout value of the client application to receive a response on a request mes-
P2_CAN_Client_Max
sage
t is the performance timing of the server to prepare the response information
P2_CAN_Server
t is the timeout value of the server to respond on a request message
P2_CAN_Server_Max
t nominal sample point position time
t timing segment 1
SEG1
t timing segment 2
SEG2
t resynchronization jump width time
SJW
t synchronization segment time
SYNCSEG
t frame separation time
STmin
t time quantum

4.2 Abbreviated terms

CAN controller area network
CBFF Classical Base Frame Format
DID data identifier
DLC data length code
DoCAN diagnostic communication over CAN
ECU electronic control unit
ECM engine control module
ETE external test equipment
OBD on-board diagnostics
PID parameter identifier
PhaseSeg1 phase segment 1
PhaseSeg2 phase segment 2
PropSeg propagation segment
SA source address
SJW synchronisation jump width
SP nominal sample point
SyncSeg synchronization segment
TA target address
TCM transmission control module

5 Conventions

This document is based on OSI service conventions as specified in ISO/IEC 10731.

6 Application

6.1 Vehicle communication initialisation sequence

6.1.1 OBDonUDS protocol identification

Vehicles that support OBDonUDS shall have ECUs that reply to the functional request service identifier
22 and DID F810 for protocol identification.

6.1.2 OBDonEDS protocol identification

Vehicles that support OBDonEDS shall have ECUs that reply to the functional request service identifier
01 and PID 00 for protocol identification.

6.1.3 Others

Vehicles that do not respond to either request (6.1.1, 6.1.2) do not support OBD diagnostics specified in
this document.

6.2 External test equipment communication initialisation sequence

The external test equipment shall support the initialisation sequence specified in this document.
The purpose of the external test equipment initialisation sequence is to automatically detect whether the vehicle supports OBDonUDS or OBDonEDS using CAN as the physical layer specified in Clause 12.
Furthermore, the initialisation sequence determines the communication conformance status of vehicles
by analysing their responses as specified in 6.1.1 and 6.1.2.
For each OBDonUDS or OBDonEDS service that requires the determination of “supported” information,
the external test equipment updates its list of expected responding ECUs prior to any data parameter
requests.
The external test equipment initialisation sequence supports single bit rate initialisation (e.g.
500 kbit/s) and multiple bit rate initialisation (e.g. 250 kbit/s and 500 kbit/s) and is separated into the following tests:
a) 11-bit CAN identifier validation (see 6.4.1 and 6.4.2);
b) 29-bit CAN identifier validation (see 6.4.1 and 6.4.2).
The external test equipment initialisation sequence shall contain provisions for legacy vehicles using
either CAN or a non-CAN protocol on the CAN pins of the ISO 15031-3 diagnostic link connector.

6.3 Bit rate validation procedure

6.3.1 bitrateRecord

The parameter “bitrateRecord” contains the bit rates as specified in 12.2.
The bitrateRecord shall be used to specify the type of initialisation to be performed. If the bitrateRecord
parameter contains a single bit rate, then a single bit rate initialisation sequence shall be performed
using the specified single bit rate (e.g. 500 kbit/s). If the bitrateRecord parameter contains multiple bit
rates, then a multiple bit rate initialisation sequence shall be performed including a bit rate detection
procedure as defined in Figure 2.
Figure 2 shall be performed using the specified multiple bit rates (e.g. 250 kbit/s and 500 kbit/s). The external test equipment shall use the appropriate CAN bit timing parameter values specified in 12.3.

6.3.2 Bit rate validation

If multiple bit rates are specified in the bitrateRecord parameter, the procedure as defined in Figure 2
shall be used to determine the bit rate to be used in communication with the vehicle's emissions-related
system.
The external test equipment shall set up its CAN interface using the first bit rate contained in the
bitrateRecord. It shall use the CAN bit timing parameter values specified for this bit rate (see 6.3).
Following the CAN interface setup, the external test equipment shall connect to the CAN network and transmit
a functionally addressed request message with service identifier 01 and PID "supported PIDs" using the
OBDonEDS 11-bit functional request CAN identifier as defined in 10.5.2.
NOTE The immediate transmission is needed in order to activate the CAN error frame monitoring, since
initialising the CAN controller at the wrong bit rate without transmitting any data can leave the CAN controller
in a state of generating error frames on the CAN network.
The external test equipment shall check for any CAN error frame. If the request message is successfully
transmitted onto the CAN network, the external test equipment shall indicate a successful transmission and proceed with the validation of the CAN identifier as specified in 6.4.1.
If an acknowledge (ACK) check error is detected, then the external test equipment shall continue to retry the transmission of the request message until the t timeout has elapsed.
N_As
If any other CAN error frame occurred, or an acknowledge check error still occurs after the t timeout has
N_As
elapsed, then the external test equipment shall stop CAN communication on the CAN network.
Proceed with sequence according to Figure 3, key 'a'.
The external test equipment shall check whether more bit rates are contained in the bitrateRecord. If the end
of the bitrateRecord is not reached, the external test equipment shall set up its CAN interface using the next
bit rate in the bitrateRecord and restart the bit rate validation at key 'a' in Figure 2. If no further bit rate is
contained in the bitrateRecord, it shall be assumed that the request was not transmitted successfully. This
indicates that the vehicle does not comply with this document.
Figure 2 — Perform bit rate validation

6.3.3 External test equipment error detection provisions Where the vehicle uses a physical layer different from that specified for OBDonEDS and OBDonUDS

(see Clause 12) or a non-CAN protocol on the CAN pins of the diagnostic link connector, the transmit
procedure, specified in this document, shall guarantee that in all cases, the external test equipment shall detect that the vehicle does not support CAN as specified for OBDonUDS or OBDonEDS and shall stop the transmission of the request message immediately.
Where the vehicle uses CAN and the physical layer in accordance with Clause 12, the transmit
procedure given as follows shall guarantee that in all cases, the external test equipment shall detect
that it uses the wrong bit rate for the transmission of the request message and shall stop disturbing
the CAN network. Under normal in-vehicle conditions (i.e. no error frames shall occur during in-vehicle
communication when the external test equipment is disconnected), the external test equipment shall
stop communication on the CAN network prior to the situation where the internal error counters of the
OBDonUDS or OBDonEDS ECU(s) reach critical values.
To achieve this, the external test equipment shall implement the following provisions:
— possibility to immediately stop sending during transmission of any CAN frame;
— the CAN interface should be disconnected within 12 µs from reception of a data frame error
signal. The maximum time for the disconnection is 100 µs;
— with the CAN interface disconnected, the external test equipment shall not be able to transmit
dominant bits on the CAN network;
— possibility to immediately detect any CAN error frame on the CAN network.
The second provision implies that the external test equipment cannot solely rely on the usual CAN
controller error handling since it does most likely flag a CAN error frame only after the “bus-off” state
has been reached (refer to ISO 11898-1 for further details).

6.4 CAN identifier validation procedure

6.4.1 CAN identifier validation procedure OBDonEDS

A functionally addressed service identifier 01 and PID 00 request using the OBDonEDS 11-bit
functional request CAN identifier, as defined in 10.5.2, shall be transmitted.
The response handling procedure shall be used to receive response messages mapped to data frames
in CBFF from the OBDonEDS ECU(s) or to indicate that no response message is received. If OBDonEDS-
related ECUs are detected, this procedure also builds the list of supported ECUs on the OBDonEDS-
conformant vehicle.
The response validation procedure shall be performed as specified in Figure 3, after the 11-bit CAN
identifier request message transmit procedure (see Figure 2) has succeeded (“OK”).
If the transmission of the previously transmitted request message was successful (“OK”), the external test
equipment shall start the P application timer and listen for the physical response CAN identifiers
2_CAN_Client
as defined in 10.5.
If the external test equipment determines a t timeout and no response message has been started,
P2_CAN_Client
then the external test equipment has verified that 11-bit or 29-bit CAN identifiers

Bibliography

[1] ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services
[2] ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 5: Emissions-related diagnostic services
[3] ISO 27145-3, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 3: Common message dictionary
[4] SAE J1979, E/E Diagnostic Test Modes — OBDonEDS
[5] SAE J1979-2, E/E Diagnostic Test Modes — OBDonUDS
[6] SAE J1979-DA, Digital Annex of E/E Diagnostic Test Modes
[7] SAE J2178-1, Class B data communication network messages detailed header formats and physical address assignments

参考資料

@kazuo_reve 自動車の故障診断に関連するプログラマーになりたての方が参照するとよさそうな情報

@kazuo_reve AUTOSARのClassic PlatformとAdaptive PlatformにおけるDiagnosticsの違いを整理

自己参照

ISO Diag規格類　調査中

ISO/IEC OSIに学ぶ

ISO 14229-1:2020 Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer

@kazuo_reveさんの「自動車の故障診断に関連するプログラマーになりたての方が参照するとよさそうな情報」の読み方

@kazuo_reve「AUTOSARのClassic PlatformとAdaptive PlatformにおけるDiagnosticsの違いを整理」で慌てて

＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞

#文書履歴
ver. 0.01 初稿 20220204