GB/T 39851.3-2021 English PDF (GB/T39851.3-2021)

GB/T 39851.3-2021: Road vehicles - Diagnostic communication over Controller Area Network (DoCAN) - Part 3: Requirements for emissions-related systems
Delivery: 9 seconds. Download (& Email) true-PDF + Invoice.
Get Quotation: Click GB/T 39851.3-2021 (Self-service in 1-minute)
Historical versions (Master-website): GB/T 39851.3-2021
Preview True-PDF (Reload/Scroll-down if blank)

GB/T 39851.3-2021
GB
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 43.040
CCS T 35
Road vehicles - Diagnostic communication over
Controller Area Network (DoCAN) - Part 3:
Requirements for emissions-related systems
[ISO 15765-4:2016, Road vehicles - Diagnostic communication over
Controller Area Network (DoCAN) - Part 4: Requirements for emissions-
related systems, MOD]
ISSUED ON: OCTOBER 11, 2021
IMPLEMENTED ON: MAY 01, 2022
Issued by: State Administration for Market Regulation;
Standardization Administration of the People’s Republic of
China.
Road vehicles - Diagnostic communication over
Controller Area Network (DoCAN) - Part 3:
Requirements for emissions-related systems
1 Scope
This document 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 GB/T 39851.2, ISO 11898-1 and ISO 11898-2.
This document 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 document details all of the OSI layer
requirements to achieve this goal.
This document 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 document is the entry point for DoCAN (Diagnostic communication over
Controller Area Network). 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:
-- OBD:ISO 15031(all parts);
-- WWH-OBD:ISO 27145(all parts).
2 Normative references
The following documents, in whole or in part, are normatively referenced in this
document and are indispensable for its application. For dated references, only
the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
GB/T 39851.2, Road vehicles - Diagnostic communication over Controller
Area Network (DoCAN) - Part 2: Transport protocol and network layer
services (GB/T 39851.2-2021, ISO 15765-2:2016, MOD)
ISO 11898-1, Road vehicles - Controller area network (CAN) - Part 1: Data
link layer and physical signaling
ISO 11898-2, Road vehicles - Controller area network (CAN) - Part 2: High-
speed medium access unit
BS: Block Size
CAN: Controller Area Network
CF: Consecutive Frame
DLC: CAN frame data link layer Data Length Code
DoCAN: Diagnostic communication over Controller Area Network
ECU: Electronic Control Unit
ECM: Engine Control Module
FC: FlowControl
FF: FirstFrame
FS: FlowStatus
OBD: On-Board Diagnostics
SA: Source Address
SF: SingleFrame
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
This document is based on the conventions specified in the OSI Service
Conventions (ISO/IEC 10731) as they apply for diagnostic services.
5 Document overview
Figure 1 illustrates the most applicable application implementations utilizing the
DoCAN protocol.
6 External test equipment initialization sequence
6.1 General
The external test equipment shall support the initialization sequence specified
in this document (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 analyzing their responses to
-- ISO 15031-5 service 0116 0016 (PID supported) requests; or
-- ISO 27145-3 service 2216 F816 1016 (DID protocol identification) request
with a positive response.
Only vehicles that follow the WWH-OBD regimen will have ECUs that reply to
the functional request service 2216 DID F81016 for protocol identification.
Vehicles that respond only to the functional request service 0116 PID 0016
support earlier OBD communication methods. Vehicles that do not respond to
either request do not support regulated OBD diagnostics described in 6.3.
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/WWHOBD 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 (see 6.2.2) (e.g.,
250 kbit/s and 500 kbit/s) and is separated into the following tests:
a) 11 bit CAN identifier validation;
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.
Key
1) Following the CAN interface setup, the external test equipment shall connect
to the CAN bus and immediately transmit a functionally addressed request
message with service 0116 (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 document nor ISO 27145-
4.
Figure 3 — Perform baudrate validation
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
document 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 shall 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 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 Figure
3) has succeeded (“OK”).
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 P2CAN_Client, which use one of the specified 11 bit
or 29 bit physical response CAN identifiers (whichever was used in the
former request message).
4) When all started response messages are completely received (positive and
negative responses) and the P2CAN_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
2116 (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 2116 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 0116 and read supported PIDs based on the received
physical responses. This step finishes the initialization sequence and verifies
the vehicle’s compliance with this document.
6) If the support of 11 bit CAN identifiers for legislated OBD communication
cannot be verified, a functionally addressed request message with service
0116 (read supported PIDs) using the legislated OBD 29 bit functional request
CAN identifier as defined in 10.5.2, 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.
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
P2CAN_Client (see ISO 27145-3) application timer and listen for the physical
response CAN identifiers as defined in 10.5.
2) If the external test equipment determines a P2CAN timeout, then no response
message has been started and the external test equipment has verified that
11 bit or 29 bit CAN identifiers (whichever was used in the previously
transmitted request message) are not used for 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 1...