GB/T 39851.3-2021 PDF in English
GB/T 39851.3-2021 (GB/T39851.3-2021, GBT 39851.3-2021, GBT39851.3-2021)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GB/T 39851.3-2021 | English | 485 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Road vehicles -- Diagnostic communication over Controller Area Network (DoCAN) -- Part 3: Requirements for emissions-related systems
| Valid |
Standards related to (historical): GB/T 39851.3-2021
PDF Preview
GB/T 39851.3-2021: PDF in English (GBT 39851.3-2021) 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 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 27145-3. This implies that a legislated WWH-OBD-compliant system
shall provide a positive response within a maximum of five retries.
Assuming that each negative response with NRC 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 WWH-OBD ECU responds with any other
negative response code or a legislated WWH-OBD ECU responds with a
response which cannot be interpreted in accordance with ISO 27145-3, the
external test equipment shall assume that the vehicle is not compliant with
ISO 27145-3.
5) If no negative or invalid response was detected in accordance with step (4),
the external test equipment has verified that the vehicle supports 11 bit or 29
bit CAN identifiers (whichever was used in the former request message) for
legislated WWH-OBD communication. The external test equipment shall
build a list of the detected legislated WWH ‑OBD-related ECUs which
responded to the request message of service 2216 F81016 and then read
supported PIDs based on the received physical responses.
If the list contains at least one WWH-OBD-compliant ECU, the initialization
sequence is finished and it is verified that the vehicle is ISO 27145-4
compliant.
If this list does not contain at least one WWH-OBD-compliant ECU, it shall
be assumed that the vehicle does not support the CAN identifier used in the
previously transmitted request
6) If the support of 11 bit CAN identifiers for legislated WWH-OBD
communication cannot be verified (“NOT OK”), a functionally addressed
request message with service 2216 (read supported PIDs) using the
legislated WWH-OBD 29 bit functional request CAN identifier as defined in
10.5.2 shall be transmitted. After successful transmission of the request, the
external test equipment shall repeat the response validation sequence as
specified in Figure 5. If neither a 11 bit nor a 29 bit CAN identifier can be
verified as supported, it shall be assumed that the vehicle is not compliant
with ISO 27145 (“NOT OK”).
7) Vehicle is ISO 27145-4 compliant.
Figure 5 — Perform ISO 27145-3 WWH-OBD response validation
7 Application layer
The application layer is the seventh level of the seven-layer OSI model. It
interfaces directly to and performs common application services for the
application processes. It also issues requests to the presentation layer.
The application layer for the emissions-related diagnostic services shall be
implemented as defined in the following:
— legislated OBD: diagnostic services as defined in ISO 15031-5;
— legislated WWH-OBD: diagnostic services as defined in ISO 27145-3.
A vehicle which complies with
— legislated OBD shall respond to ISO 15031-5 requests from the external
test equipment, and
— legislated WWH-OBD shall respond to ISO 27145-3 requests from the
external test equipment.
The external test equipment shall be capable of supporting a list of detected
legislated OBD/WWH‑OBD‑related ECUs (generated during the initialization
sequence as defined in Clause 6).
8 Session layer
ISO 14229-2 defines the session layer service requirements.
b) 500 kbit/s.
12.3 External test equipment CAN bit timing
12.3.1 CAN bit timing parameter values
The specified CAN bit timing parameter values apply to the external test
equipment. The legislated OBD/WWH-OBD ‑ compliant vehicle may use
different CAN bit timing parameter values to achieve its legislated OBD/WWH-
OBD‑compliant baudrate, however, it shall be able to communicate with the
defined external test equipment.
The following specifies the required CAN bit timing parameter settings for the
external test equipment based on the timing parameter definitions given in ISO
11898-1. All requirements are specified for operation at 250 kbit/s and 500 kbit/s.
The bit timing is according to ISO 11898-1. The CAN controller shall support
the protocol specifications CAN 2.0A (standard format) and CAN 2.0B passive
(29 bit ID extended format) and shall be in accordance with ISO 11898-1.
For example, the enhanced protocol for higher clock tolerance shall be
supported (e.g., tolerate 2 bit message intermission) and extended frame
messages shall not be disturbed unless bit errors are detected.
The CAN bit timing parameter values used in GB/T 39851.2 are based on
equivalent terms in ISO 11898-1:
—tSYNCSEG =Sync_Seg =1×tQ;
—tSEG1 =Prop_Seg+Phase_Seg1 =tBIT-tSYNCSEG-tSEG2;
—tSEG2 =Phase_Seg2;
—tSJW =resynchronization jump width;
—tBIT =tB (nominal bit time);
—tQ =time quantum;
—SP =nominal sample point position =(1-tSEG2/tBIT)×100%.
Compliance with the nominal bit time tolerance requirement given in this
document is directly dependent on the CAN system clock tolerance of the
external test equipment and the programmed nominal bit time value. In a typical
CAN controller, the nominal bit time value must be an integer multiple of its
system clock periods. When the programmable nominal bit time value is set
exactly to the required nominal bit time value, accuracy is only affected by the
system clock tolerance. Otherwise, the accuracy is dependent upon both the
deviation of the programmed bit time value from the nominal bit time value and
the system clock tolerance. The contributions from drift or ageing of the system
clock source and from the inability to achieve the desired nominal bit time value
are additive. The bit time tolerance specification must be met after consideration
of both.
Figure 8 illustrates the partitioning of the CAN bit time.
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|