GB/T 27930.2-2024 PDF English
Search result: GB/T 27930.2-2024
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | 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 |
PDF Preview: GB/T 27930.2-2024
GB/T 27930.2-2024: PDF in English (GBT 27930.2-2024) GB/T 27930.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
7.1 General requirements... 11
7.2 Version negotiation... 12
8 Transport layer... 22
8.1 General... 22
8.2 Unreliable short message... 23
8.3 Reliable short message... 23
8.4 Long message... 24
8.5 Multi-information frame transmission mode... 26
9 Application layer... 39
9.1 General requirements... 39
9.2 Communication process... 40
9.3 Public messages... 43
10 Timeout... 54
10.1 Overview... 54
10.2 Data link layer and transport layer timeout... 54
10.3 Application layer function module timeout... 55
Appendix A (Normative) Implementation of application scenarios... 56
A.1 Charging application scenarios... 56
A.2 Charging & discharging application scenario... 57
Appendix B (Normative) Function negotiation function module... 60
B.1 Overview... 60
B.2 General requirements... 60
B.3 Message definition... 61
B.4 Message interaction process... 64
Appendix C (Normative) Parameter configuration function module... 68
C.1 Overview... 68
C.2 Charging mode parameter configuration (FDC=1)... 68
C.3 Charging and discharging mode parameter configuration (FDC=2)... 74
Appendix D (Normative) Authentication function module... 83
Digital communication protocols between off-board
conductive charger and electric vehicle - Part 2.
Communication protocols for GB/T 20234.3
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
functions; the implementation method is not specified in this document.
Figure 1 -- Protocol architecture layered model
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.
5.9 The communication interaction shall comply with the requirements of the status
transition table.
Note 1.The status transition table defines the interaction status transition between the charger
and the vehicle. The left side of the status transition table lists the status of the charger
or vehicle in the current communication process, and the upper header is the condition
that triggers the status jump.
Note 2.The flowchart provides a graphical representation of the interaction status and function
jumps between the vehicle and the charger (referred to as "vehicle-charger"), which
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.
8.5.3.5.3 The connection closure of a long message shall include the following aspects.
a) The sender can consider the connection to be closed in the following cases.
1) Complete the data transmission of the entire long message and receive
LM_EndofACK;
2) Send LM_NACK (such as the sender wants to stop communication early,
timeout, etc.);
3) Receive LM_NACK.
b) The receiver can consider the connection to be closed in the following cases.
1) Send LM_EndofACK after completing the data transmission of the entire long
message;
2) Send LM_NACK (such as the receiver lacks resources or storage space);
3) Receive LM_NACK.
Note. A transmission failure occurring on the sender or receiver (such as 3 consecutive
connection timeouts of the same type) will result in the connection being closed.
8.5.3.6 Connection timeout
8.5.3.6.1 After the receiver receives an information frame, if the timeout timer for
receiving information frames or control frames (LMS_T2) does not receive the next
information frame within the time limit, it is timeout. After the timeout, it will send
LM_ACK to notify the sender to resend. After 3 consecutive timeouts, it will send
LM_NACK to abandon the connection.
8.5.3.6.2 After the receiver sends LM_ACK, if it does not receive an information frame
with the correct frame sequence number within LMS_T2, it will time out. After the
timeout, it will send LM_ACK to notify the sender to resend. After 3 consecutive
timeouts, it will send LM_NACK to abandon the connection.
8.5.3.6.3 After the receiver receives an information frame with a frame sequence
number of 0, if the time for receiving the entire long message is greater than the long
message transmission timer (LMS_T3), it is a timeout. After the timeout, it will send
LM_NACK to abandon the connection.
8.5.3.6.4 After the sender sends an information frame with a frame number of 0, if it
does not receive an acknowledgement message from the receiver within LMS_T2, it
will time out. After the timeout, it will resend the information frame with a frame
number of 0.After 3 consecutive timeouts, it will send LM_NACK to abandon the
connection.
8.5.3.6.5 After the sender sends all the information frames that need to be transmitted
this time, if it does not receive an acknowledgement message (LM_ACK or
LM_EndofACK) from the receiver within LMS_T2, it will time out. After the timeout,
the sender will resend the last frame of this transmission. After 3 consecutive timeouts,
it will send LM_NACK to abandon the connection.
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.
and the sending of information frames shall be stopped according to the total sending
time specified by the application layer.
10.2.3 For long message, the timeout and retransmission time shall comply with the
provisions of 8.5.3.If the transport layer fails to transmit, the application layer can
establish a retransmission mechanism within the timeout range of the current function
module. Before retransmission, it shall ensure that the virtual connection is in a closed
state (the sender/receiver actively sends LM_NACK). The total sending time and phase
timeout shall comply with the provisions of Table J.1.
10.2.4 The timeout period for version negotiation shall comply with the provisions of
Table J.2.
10.3 Application layer function module timeout
10.3.1 Each FDC shall define a separate function interaction timeout period unless
otherwise specified. Within the FDC function interaction timeout period, the charger
and the vehicle complete the information interaction and the functions specified by FDC.
Note. For non-override function modules, they can be regarded as function modules with one
and only one FDC.
10.3.2 In addition to function negotiation, the charger shall initiate a phase
acknowledgement before entering each function module. Unless otherwise specified,
the timeout start time of the charger side is the "vehicle acknowledgement
result_acknowledgement succeeded" message received from the current FDC. If the
"vehicle acknowledgement result_acknowledgement succeeded" message or other
message indicating the end of the interaction of identification information is not
received within the timeout period of the current function module, the charger enters
the timeout process and exits the communication process; unless otherwise specified,
the timeout start time of the vehicle in FDC is the vehicle successfully sending the
"vehicle acknowledgement result_acknowledgement succeeded" message. If the
function and phase acknowledgement of the current function module are not completed
within the timeout period, the vehicle enters the timeout process and exits the
communication.
Note. For the timeout of the function negotiation module, see Table B.5 and Table B.6.
10.3.3 The timeout time of the FDC defined by the application layer shall comply with
the provisions of Table J.2.
Appendix M
(Normative)
Backward compatible communication protocol
M.1 General
M.1.1 The charger and/or vehicle shall perform version negotiation according to 7.2.
During the version negotiation phase, if the protocol version number of "negotiation
failed", timeout or "negotiation succeeded" is V1.1.0, communication shall be carried
out according to this Appendix.
M.1.2 The communication network between the charger and the vehicle adopts the
CAN2.0B communication protocol. For the charging process, refer to M.8.
M.1.3 The CAN communication network between the charger and the vehicle shall
consist of two nodes, the charger and the vehicle.
M.1.4 Data information transmission adopts the format of sending the low byte first.
M.1.5 The current value during the vehicle charging process is negative.
M.1.6 The charger and the vehicle shall not send messages, which are not specified in
this document. When the charger and the vehicle receive messages not specified in this
document, they shall not process them.
M.1.7 The transition relationship between the data value and the physical quantity in
the message is. Physical quantity = resolution × data value + offset.
M.1.8 The charger and the vehicle implementing this Appendix should have backward
compatibility.
M.2 Physical layer
The physical layer of communication between the charger and the vehicle shall comply
with the provisions of Chapter 6.
Note. The 50 kbit/s communication rate adopted by the manufacturer after consensus is
applicable to special occasions with harsh communication environment (such as
commercial vehicle charging stations with long communication distances).
M.3 Data link layer
M.3.1 Frame format
The communication frame format between the charger and the vehicle shall comply
with the provisions of 7.1.1.
M.3.2 Protocol data unit
command, request, broadcast/response, acknowledgement, group function.
M.4 Application layer
M.4.1 The application layer uses the form of parameter and parameter group definition.
M.4.2 PGN is used to number parameter groups; each node identifies the content of the
data packet based on PGN.
M.4.3 Data is sent in a periodic and event-driven manner.
M.4.4 If multiple PGN data need to be sent to implement a function, multiple PGN
messages of the definition must be received at the same time, to determine that the
function is sent successfully.
M.4.5 When defining a new parameter group, try to put parameters with the same
function, parameters with the same or similar sending cycles, parameters belonging to
the same subsystem in the same parameter; at the same time, the new parameter group
shall make full use of the 8-byte data width, try to put related parameters in the same
group, consider scalability, reserve some bytes or bits for future modifications.
M.4.6 When modifying the parameter group defined in M.6, the definition of the
defined bytes or bits shall not be modified; the newly added parameters shall be related
to the original parameters in the parameter group; irrelevant parameters shall not be
added to the defined PGN to save the number of PGNs.
M.4.7 Parameter options are divided into mandatory items and optional items. The
mandatory item parameters shall send the actual data in the format specified in this
document; the optional item parameters can send the actual data or fill all bits with 1 in
the format specified in this document. For all contents in the same message that are
optional, the sender may not send the message. If it is sent, the actual data or all bits
shall be filled with 1 in the format specified in this document.
M.4.8 The message length and required content and format shall be sent in accordance
with the provisions of this appendix, and the undefined bits or reserved bits in the
specified message length shall be filled with 1.
M.4.9 "Untrusted status" is the content sent to maintain the communication link, when
the sender cannot obtain or clarify the current status. The receiver shall ignore and not
process the information.
M.5 Overall charging process
The entire charging process includes 6 phases. physical connection completion and
version negotiation, low-voltage auxiliary power-on, charging handshake phase,
charging parameter configuration phase, charging phase and charging end phase. After
the physical connection is completed and the version is negotiated and the low-voltage
auxiliary power-on is conducted, the communication is carried out according to this
Appendix. At each phase of the communication, if the charger and the vehicle do not
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|