GB/T 27930.2-2024 PDF English
US$2630.00 · In stock · Download in 9 secondsGB/T 27930.2-2024: Digital communication protocols between off-board conductive charger and electric vehicle - Part 2: Communication protocols for GB/T 20234.3 Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See step-by-step procedureStatus: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivery | Name of Chinese Standard | Status |
| GB/T 27930.2-2024 | English | 2630 |
Add to Cart
|
0-9 seconds. Auto-delivery
|
Digital communication protocols between off-board conductive charger and electric vehicle - Part 2: Communication protocols for GB/T 20234.3
| Valid |
Excerpted PDFs (Download full copy in 9 seconds upon purchase)PDF Preview: GB/T 27930.2-2024
GB/T 27930.2-2024: Digital communication protocols between off-board conductive charger and electric vehicle - Part 2: Communication protocols for GB/T 20234.3
---This is an excerpt. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.), auto-downloaded/delivered in 9 seconds, can be purchased online: https://www.ChineseStandard.net/PDF.aspx/GBT27930.2-2024
GB
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 43.120
CCS T 35
Digital communication protocols between off-board
conductive charger and electric vehicle - Part 2.
Communication protocols for GB/T 20234.3
Issued on: 2024-12-31
Implemented on: 2024-12-31
Issued by. State Administration for Market Regulation;
National Standardization Administration.
Table of Contents
Foreword... 4
Introduction... 6
1 Scope... 7
2 Normative references... 7
3 Terms and definitions... 8
4 Abbreviated terms... 8
5 General requirements... 9
6 Physical layer... 11
7 Data link layer... 11
8 Transport layer... 22
9 Application layer... 39
10 Timeout... 54
1 Scope
This document specifies the communication protocol based on the physical layer, data
link layer, transport layer, application layer of the controller area network, between the
electric vehicle DC charging communication controller for the GB/T 20234.3 DC
charging interface and the non-vehicle conductive charger charging communication
controller.
This document applies to digital communication between electric vehicle (referred to
as "vehicle") and off-board conductive charger (referred to as "charger") whose DC
control pilot circuits and control principles comply with GB/T 18487.5.
2 Normative references
The contents of the following documents constitute essential clauses of this document
through normative references in the text. Among them, for dated references, only the
version corresponding to that date applies to this document; for undated references, the
latest version (including all amendments) applies to this document.
GB/T 1988, Information technology - 7-bit Coded character set for information
interchange
GB 16735, Road vehicle - Vehicle identification number (VIN)
GB 18030, Information technology - Chinese coded character set
GB/T 18487.5, Electric vehicle conductive charging system - Part 5.DC charging
system for GB/T 20234.3
GB/T 19596, Terminology of electric vehicles
GB/T 20234.3, Connection set for conductive charging of electric vehicles - Part 3.
DC charging coupler
GB/T 27930-2023, Digital communication protocols between off-board conductive
charger and electric vehicle
GB/T 29317, Terminology of electric vehicle charging/battery swap infrastructure
3 Terms and definitions
For the purpose of this document, the following terms and definitions, as well as those
given in GB/T 19596, GB/T 27930-2023 and GB/T 29317, apply.
3.1
function module
Several definable minimum units with specific business functions divided by the
charging communication interaction process.
3.2
public message
When the sending conditions are met, the message which can be exchanged by each
function module in the application layer.
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
CAN. Controller Area Network
CP. Control Pilot
EVCC. Electric Vehicle Communication Controller
LM. Long Message
LM_ACK. Long Message Acknowledgment
LM_EndofACK. Long Message End of Acknowledgment
LM_NACK. Long Message Negative Acknowledgment
SECC. Supply Equipment Communication Controller
SM. Short Message
SM_ACK. Short Message Acknowledgment
SM_RM. Reliable Short Message
SM_URM. Unreliable Short Message
TL. Transport Layer
5 General requirements
5.1 The charging interface applicable to the digital communication protocol specified
in this document shall comply with GB/T 20234.3.
5.2 The DC charging system applicable to the digital communication protocol specified
in this document shall comply with GB/T 18487.5.
5.3 The communication network between the vehicle and the charger is based on the
CAN2.0B protocol. The communication model is divided into physical layer, data link
layer, transport layer, and application layer, as specified in Chapter 6, Chapter 7,
Chapter 8 and Chapter 9 respectively. The protocol architecture layered model is shown
in Figure 1.
5.4 The communication process between the vehicle and the charger consists of
different function modules. The function modules of the charging and charging &
discharging application scenarios shall comply with the provisions of Appendix A.
5.5 The information interaction messages and interaction processes of function modules
shall comply with the provisions of Appendix B ~ Appendix I. The acknowledgement
and connection between the function modules of the application layer shall be
completed according to the phase acknowledgement of 9.3.1.
5.6 The message cycle and function module timeout shall comply with the provisions
of Appendix J. The exit method shall comply with the provisions of Appendix K. The
parameter type table shall comply with the provisions of Appendix L.
5.7 The communication process enters the version negotiation phase immediately after
the physical connection is completed. After the version negotiation is completed, the
version agreed upon by the negotiation result shall be confirmed for charging. The
communication protocol has the ability to be backward compatible (compatible with
old versions); the communication process jumps to the backward compatible
communication protocol through version negotiation. The backward compatible
communication protocol shall comply with the provisions of Appendix M.
5.8 The communication protocol version number specified in this document is V2.0.0.
The major version number and minor version number are defined by this document,
whilst the temporary version number is only used for internal development of the
enterprise.
Note. Internal development of the enterprise means that the vehicle or charger using the
customized temporary version number is not circulated in the market. When the
enterprise's external verification or demonstration activities in the product development
phase use the customized temporary version number, the temporary version number
can be filed with the standardization organization under the jurisdiction of this
document, to avoid the disorderly use of the temporary version number.
6 Physical layer
The physical layer of communication between the vehicle and the charger shall comply
with the provisions of Chapter 13 of GB/T 27930-2023.Among them, the physical layer
shall use an independent CAN bus to support 2 nodes, EVCC and SECC.
7 Data link layer
7.1 General requirements
7.1.1 Frame format
The frame format of communication between the vehicle and the charger shall comply
with the provisions of 14.1 of GB/T 27930-2023.
7.1.2 Protocol data unit
The protocol data unit consists of 7 parts, namely priority, extended data page, data
page, PDU format, PDU specific format, source address, data field, which shall comply
with the provisions of Table 1.
7.1.3 Protocol data unit format
The protocol data unit format shall comply with the provisions of 14.3 of GB/T 27930-
2023.
7.1.4 Address allocation
EVCC and SECC shall be defined as non-configurable address and fixed value, whose
source address cannot be changed by any means including service tools. The address
allocation of EVCC and SECC shall comply with the requirements of Table 2.
Note. Network address is used to ensure the uniqueness of information identifier and to
indicate the source of information.
7.2 Version negotiation
7.2.1 General requirements
The charger and the vehicle shall determine the communication protocol version for
this interaction through negotiation. The negotiation principles, message definitions,
and information exchange process of version negotiation shall remain unchanged. The
overall requirements for version negotiation shall comply with the requirements in
Table 3.
7.2.2 Message definition
The data link layer of the version negotiation interaction message shall meet the
requirements of 7.1.Version negotiation includes "charger version negotiation" and
"vehicle version negotiation" messages. The frame format definition shall comply with
the provisions of Table 4 and Table 5; the data field content shall comply with the
provisions of Table 6 and Table 7.
8 Transport layer
8.1 General
8.1.1 The transport layer is responsible for data transmission, flow control, packet
transmission and reception frame sequence checking, etc.
8.1.2 The types of transport layer messages include unreliable short message, reliable
short message, long messages, with details shown as follows.
8.1.3 The receiver shall ignore messages not defined in this document unless otherwise
specified.
8.2 Unreliable short message
Unreliable short message (SM_URM) does not require the receiver to respond and
confirm. Its information frame format shall comply with the provisions of Table 10.
8.3 Reliable short message
Reliable short message (SM_RM) requires the receiver to respond and confirm. If the
sender does not receive the acknowledgement information, the sender shall make
further attempts, with a retransmission interval of 50 ms until the total transmission
time of the application layer is reached. The message frame format of the reliable short
message shall comply with the provisions of Table 11; the control frame
(acknowledgement) format definition shall comply with the provisions of Table 12.
Note. When multiple reliable short messages are sent simultaneously, the corresponding
relationship between the control frame and the reliable short message is identified by
the acknowledged short message parameter group identification in the control frame.
8.4 Long message
8.4.1 The transmission of long messages (LM) shall comply with the multi-information
frame transmission mode as specified in 8.5; the information frame format definition
shall comply with the provisions of Table 13.
8.4.2 The control frame of the long message is used for error control and flow control,
including long message acknowledgement (LM_ACK), long message negative
acknowledgement (LM_NACK), long message end of acknowledgement
(LM_EndofACK). Among them, LM_ACK and LM_EndofACK are the receiver's
acknowledgement to the sender; LM_NACK is the receiver or sender's negative
acknowledgement of the connection sent to the other party. The control frame format
definition of the long message shall comply with the provisions of Table 14.
8.5 Multi-information frame transmission mode
8.5.1 Function classification
The main functions of long message transmission control are packet reassembly and
connection management.
8.5.2 Packet reassembly
8.5.2.1 Reassembly method
The sender first splits the long message into multiple information frames and transmits
them in sequence after establishing the connection. The receiver reassembles them into
the original information after receiving all the information frame data.
8.5.2.2 Information frame
Each information frame shall be identifiable and reassembled. The first byte of the
information frame data field is defined as the frame number of the information frame.
The sequence number range is 1 ~ 255 (the information frame with sequence number 0
is only used to establish a connection). The information frame shall be sent in sequence
starting from number 1.The longest data length is 1 785 bytes. When the sender
requests to establish a virtual connection for long message transmission, it first sends
the information frame with frame sequence number 0.After receiving the receiver's
acknowledgement, it sends the information frame as required.
Each information frame (except the last information frame and the information frame
with sequence number 0 used to establish a connection) is loaded with 7 bytes of
application layer data. The 8 bytes of the data field of the last information frame contain.
the sequence number of the information frame and at least one byte of application layer
data. All unused bytes are set to 0xFF.
8.5.2.3 Frame sequence number
The transport layer assigns frame sequence numbers to information frames during
disassembly and assembly. After receiving, the receiver uses the frame sequence
number to reassemble the information frame back to the original information.
Information frames are sent in ascending order starting from information frame
numbered 1.Information frames with sequence number 0 do not contain application
layer data; they are only used to establish virtual connections.
8.5.2.4 Data transmission
The transmission interval LMS_T1 between information frames shall be no less than 5
ms and no more than 10 ms. Only one virtual connection is allowed to be established at
the same time, that is, a new virtual connection can only be established when the sender
or receiver sends a long message negative acknowledgement or the receiver sends a
long message end of acknowledgement.
Note 1.During the communication process, a temporary connection is established between
two nodes to transmit long messages, i.e. a virtual connection.
Note 2.When more than one virtual connection is established at the same time, it is
impossible to distinguish information frames of different long messages with the same
frame number.
8.5.2.5 Information frame reassembly
After the receiver completes the reception of all information frames, it shall reassemble
them back to the original information in order of frame number from small to large.
8.5.3 Connection management
8.5.3.1 Overview
Connection management includes the establishment, use, and closing of virtual
connections.
8.5.3.2 General requirements
8.5.3.2.1 Before the virtual connection is established, the sender and receiver shall
confirm that the counter recording the frame number is 0, where the sender's counter is
used to record the frame number to be sent next time, the receiver's counter is used to
record the starting frame number to be received next time.
8.5.3.2.2 The sender sends an information frame with a frame number of 0 as a request
for connection establishment. After the receiver acknowledges, the connection is
established.
8.5.3.2.3 After the connection is established, the sender sends the information frame
according to the receiver's acknowledgement; waits for the next acknowledgement from
the receiver after the sending is completed.
8.5.3.2.4 The sender and the receiver do not support the establishment of two or more
virtual connections at the same time.
8.5.3.2.5 If a transmission exception occurs on the sender (e.g. the same type of
connection timeout occurs 3 times in a row), the "failed to send" message shall be
returned to the application layer.
8.5.3.3 Connection establishment
8.5.3.3.1 When the sender requests to send a long message, the information frame
number is 0, which contains the total number of frames and total number of bytes of the
long message.
8.5.3.3.2 After the receiver receives the long message with frame number 0, it can
choose to receive or refuse to establish the connection. If it chooses to receive, it shall
send a long message acknowledgement frame LM_ACK, wherein the LM_ACK shall
contain the starting frame number and total number of frames to be received by the
receiver. After the connection is established, the receiver shall start receiving the
information frame with sequence number 1.
8.5.3.3.3 If the sender receives LM_ACK, the connection establishment is complete.
8.5.3.3.4 If the receiver lacks resources or storage space, it can refuse to establish a
connection. At this time, it shall send a connection abandonment acknowledgement
LM_NACK, then the connection establishment fails.
8.5.3.4 Data transmission
The sender starts data transmission after receiving LM_ACK. The receiver is
responsible for adjusting the data flow control between nodes. If the receiver needs to
suspend the data flow, it can use LM_ACK to set the total number of frames to be
received to 1; the start frame sequence number to be received is set to the frame
sequence number of the last frame received. The sender repeats sending this frame
content (that is, the receiver repeats receiving the last frame message of the previous
group); the receiver does not process it after receiving the message. When the receiver
resumes the data flow, the "starting sequence number to be received" in LM_ACK is
set to the frame number of the next frame received last time; the "total number of frames
to be received" is reset according to its own receiving and processing capabilities, until
all information frames are received.
8.5.3.5 Connection closure
8.5.3.5.1 In the case of no error in the transmission, when all information frames are
received, the receiver shall send a message end of acknowledgement LM_EndofACK,
to notify the sender that the connection is closed.
8.5.3.5.2 During the transmission of a long message, the sender or receiver can use
LM_NACK to terminate the connection at any time. If the receiver does not have
available resources to process the message, it can abandon the connection by sending
LM_NACK. When LM_NACK is received, all transmitted information frames will be
discarded.
9 Application layer
9.1 General requirements
9.1.1 Parameter group identification (PGI) is used to number parameter groups; each
node identifies the message content according to PGI.
9.1.2 Both communicating parties shall send messages according to actual data, unless
otherwise specified.
9.1.3 When the receiver receives a message not defined in this document, a parameter
value not specified in this document, or a parameter value outside the data range
specified in this document, the receiver shall ignore the information unless otherwise
specified.
9.1.4 When the parameter value received by the receiver is a "reserved" value or an
"invalid" value as defined in this document, the parameter shall not be processed.
9.1.5 The data type transmitted shall comply with the provisions of Table 17; the little-
endian mode shall be used to transmit digital information.
9.1.6 The "message name_message content" message sent in each function module
status transition table is sent by the application layer to the transport layer; the
application layer status jump may not depend on whether the transport layer receives
the control response of the receiver. The successful sending of the "message
name_message content" message means that the application layer sends the message to
the transport layer and receives the control response message of the receiver, unless
otherwise specified.
9.1.7 If the application layer receives a transmission failure from the transport layer, it
shall exit according to Appendix K fault shutdown. When the application layer receives
a data link layer or transport layer timeout and does not trigger an application layer
message or a function module timeout, it can try again. If the application layer times
out, it shall exit according to Appendix K fault shutdown.
9.1.8 The function module interaction flow diagram is only used to understand the
business process. It does not reflect the phase timeout or the main business of the two
parties in this function module. It does not express the need to stop charging or respond
to the other party's suspension of charging.
9.1.9 The trigger conditions of receiving "phase request" and receiving "vehicle
acknowledgement result" in the header of each function module status table only
indicate the entry into the phase acknowledgement sub-process, and the phase
acknowledgement sub-process shall be in accordance with 9.3.1.
9.1.10 The parameter type shall comply with the provisions of Table L.1.
9.2 Communication process
9.2.1 The charging communication process consists of multiple function modules in
sequence. The function code (FC) corresponding to each function module shall comply
with the provisions of Table 18.A complete charging communication process shall
include all mandatory function modules and zero or more optional function modules.
The function module types and their communication processes shall comply with the
provisions of Figure 4.
9.2.2 Except for function negotiation, other function modules can be configured to
realize different applications. Different applications of each function module are
distinguished by function description code (FDC). The upper limit of FDC supported
by each override function module (function module that can be redefined and replaced)
is 8.The FDC of non-overridable function modules is fixed to 0x01.
Note. The function negotiation function module FDC is defined as non-overridable. When
the content of function negotiation changes in the future, the main version number of
the communication protocol will be changed.
......
Source: Above contents are excerpted from the full-copy PDF -- translated/reviewed by: www.ChineseStandard.net / Wayne Zheng et al.
Tips & Frequently Asked QuestionsQuestion 1: How long will the true-PDF of English version of GB/T 27930.2-2024 be delivered?Answer: The full copy PDF of English version of GB/T 27930.2-2024 can be downloaded in 9 seconds, and it will also be emailed to you in 9 seconds (double mechanisms to ensure the delivery reliably), with PDF-invoice. Question 2: Can I share the purchased PDF of GB/T 27930.2-2024_English with my colleagues?Answer: Yes. The purchased PDF of GB/T 27930.2-2024_English will be deemed to be sold to your employer/organization who actually paid for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. www.ChineseStandard.us -- GB/T 27930.2-2024 -- Click this link and select your country/currency to pay, the exact amount in your currency will be printed on the invoice. Full PDF will also be downloaded/emailed in 9 seconds. How to buy and download a true PDF of English version of GB/T 27930.2-2024?A step-by-step guide to download PDF of GB/T 27930.2-2024_EnglishStep 1: Visit website https://www.ChineseStandard.net (Pay in USD), or https://www.ChineseStandard.us (Pay in any currencies such as Euro, KRW, JPY, AUD).
Step 2: Search keyword "GB/T 27930.2-2024".
Step 3: Click "Add to Cart". If multiple PDFs are required, repeat steps 2 and 3 to add up to 12 PDFs to cart.
Step 4: Select payment option (Via payment agents Stripe or PayPal).
Step 5: Customize Tax Invoice -- Fill up your email etc.
Step 6: Click "Checkout".
Step 7: Make payment by credit card, PayPal, Google Pay etc. After the payment is completed and in 9 seconds, you will receive 2 emails attached with the purchased PDFs and PDF-invoice, respectively.
Step 8: Optional -- Go to download PDF.
Step 9: Optional -- Click Open/Download PDF to download PDFs and invoice.
See screenshots for above steps: Steps 1~3 Steps 4~6 Step 7 Step 8 Step 9
|