Skip to product information
1 of 10

PayPal, credit cards. Download editable-PDF and invoice in 1 second!

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

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

Regular price $485.00 USD
Regular price Sale price $485.00 USD
Sale Sold out
Shipping calculated at checkout.
Quotation: In 1-minute, 24-hr self-service. Click here GB/T 39851.3-2021 to get it for Purchase Approval, Bank TT...

GB/T 39851.3-2021: Road vehicles -- Diagnostic communication over Controller Area Network (DoCAN) -- Part 3: Requirements for emissions-related systems

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 de...

View full details