Powered by Google www.ChineseStandard.net Database: 189759 (16 Jun 2024)

GB/T 27930-2023 PDF in English


GB/T 27930-2023 (GB/T27930-2023, GBT 27930-2023, GBT27930-2023)
Standard IDContents [version]USDSTEP2[PDF] delivered inName of Chinese StandardStatus
GB/T 27930-2023English1805 Add to Cart 0-9 seconds. Auto-delivery. Digital communication protocols between off-board conductive charger and electric vehicle Valid

PDF Preview

Standards related to: GB/T 27930-2023

GB/T 27930-2023: PDF in English (GBT 27930-2023)

GB/T 27930-2023
ChaoJi-1 (Chinese standard GB/T) and compatible CHAdeMO-3.1 (Japanese standard, joint-development with Chinese standard) are consisted of 3 standards. It is suitable for high, medium and low power charging (up to 1.2MW) to meet the needs of safe and fast electric-vehicle charging.

GB
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 29.200
CCS K 81
Replacing GB/T 27930-2015
Digital communication protocols between off-board
conductive charger and electric vehicle
ISSUED ON: SEPTEMBER 07, 2023
IMPLEMENTED ON: APRIL 01, 2024
Issued by: Status Administration for Market Regulation.
Standardization Administration of PRC.
Table of Contents
Foreword ... 4
1 Scope ... 7
2 Normative references ... 7
3 Terms and definitions ... 8
4 Abbreviations ... 13
5 General principles of category A systems ... 13
6 Category A system physical layer ... 14
7 Category A system data link layer ... 14
8 Category A system application layer ... 15
9 Overall charging process of category A system... 16
10 Message classification of category A system ... 17
11 Message format and content of category A system ... 20
12 General principles of category B systems ... 37
13 Physical layer of category B system ... 39
14 Data link layer of category B system ... 39
15 Transport layer of category B system ... 48
16 Application layer of category B system ... 62
17 Timeout of category B system ... 69
Appendix A (Normative) Communication process of category A system ... 70
Appendix B (Informative) Start sending conditions and end sending conditions of
category A system message ... 79
Appendix C (Normative) Function negotiation function module ... 81
Appendix D (Normative) Parameter configuration function module ... 87
Appendix E (Normative) Authentication function module ... 93
Appendix F (Normative) Reservation function module ... 104
Appendix G (Normative) System self-check function module ... 117
Appendix H (Normative) Power supply mode function module ... 123
Appendix I (Normative) Precharge and energy transfer function module ... 137
Appendix J (Normative) Service statistics function module ... 160
Appendix K (Informative) Realization of basic charging application scenarios ... 163
Appendix L (Informative) Realization of charging & discharging application scenarios
... 165
Appendix M (Normative) Parameter type table ... 168
Appendix N (Informative) Realization of adaptor communication ... 173
Digital communication protocols between off-board
conductive charger and electric vehicle
1 Scope
This document specifies the definitions and requirements of the controller area network
(CAN)-based communication physical layer, data link layer, transport layer, application
layer, between the off-board conductive charger's (hereinafter referred to as "charger")
equipment communication controller (SECC) and electric vehicle communication
controller (EVCC).
This document applies to the communication -- between the charger or the charger &
discharger using charging mode 4 and the electric vehicle. It also applies to the
communication -- between the charger or charger & discharger and the electronic
control unit of the electric vehicle with charging control function. Electric vehicle
communication controllers include but are not limited to battery management systems
(BMS), as well as in-vehicle systems that need to communicate with the charger to
achieve other special functions.
Chapters 5 ~ 11 of this document apply to the charging system, which is specified in
Appendix B of GB/T 18487.1-2023 (hereinafter referred to as “category A system").
Chapters 101 ~ 106 apply to the charging system, which is specified in Appendix C of
GB/T 18487.1-2023, as well as the charging & discharging system, which is defined in
Appendix E (hereinafter referred to as "category B system").
"Vehicle" in this document specifically refers to “electric vehicle”.
2 Normative references
The contents of the following documents constitute essential provisions of this
document through normative references in the text. Among them, for dated reference
documents, only the version corresponding to the date applies to this document; for
undated reference documents, the latest version (including all amendments) applies to
this document.
GB/T 18487.1-2023 Electric vehicle conductive charging system - Part 1: General
requirements
GB/T 19596 Terminology of electric vehicles
GB/T 29317 Terminology of electric vehicle charging/battery swap infrastructure
Extended vehicle identification number; EVIN
Vehicle identification number (VIN code), or a vehicle identifier with the words I,
O, Q designed, to identify vehicle identity information.
Note: Standards related to extended vehicle identification numbers are under consideration.
4 Abbreviations
The following abbreviations apply to this document.
LM_ACK: Long message acknowledgement
LM_EndofACK: Long message end of acknowledge
LM_NACK: Long message negative acknowledge
RM_SM_ACK: Reliable short message acknowledge
5 General principles of category A systems
5.1 The communication network between the charger and the vehicle is based on
CAN2.0B.
5.2 The CAN communication network, between the charger and the vehicle, shall be
composed of two nodes: the charger and the vehicle. In order to achieve the
compatibility solution of Appendix G of GB/T 18487.1-2023, adaptor nodes can be
added to the communication network; however, between each node, there shall be no
conflicts in addresses, PGNs, etc.
5.3 Data information transmission adopts the format of low byte sent first.
5.4 The current value during vehicle charging is negative. In public stations, when the
vehicle/charger receives a charging current value, which is outside the range of -400 A
~ 0 A, the charging process shall be exited. In private stations, the charger and vehicle
can be subject to the negotiation, according to private agreement.
5.5 In public stations, messages not specified in this document shall not appear on the
communication network, between chargers and vehicles. Messages, which are not
specified in this document and received by the charger or vehicle, will not be processed.
5.6 The conversion relationship between the data value and the physical quantity in the
message is: physical quantity = Resolution × Data value + Offset.
5.7 Chargers and vehicles, that implement this document, shall have forward
compatibility.
data packet, based on PGN.
8.3 Use periodic sending and event-driven methods to send data.
8.4 If multiple PGN data need to be sent to implement a function, all the defined
multiple PGN messages must be received, to determine whether the function is
successfully sent.
8.5 When defining a new parameter group, try to put parameters with the same function,
parameters with the same or similar transmission cycle, parameters belonging to the
same subsystem in the same parameter group. At the same time, the new parameter
group must make full use of the data width in 8 bytes; try to put related parameters in
the same group; consider extendibility; reserve some bytes or bits for future
modifications.
8.6 When modifying the parameter group defined in Chapter 10, the newly added
parameters must be related to the original parameters in the parameter group. Irrelevant
parameters shall not be added to the defined PGN in order to save the number of PGN.
8.7 Parameter options are divided into mandatory items and optional items. The
mandatory item parameters shall send actual data, according to the format specified in
this document. Optional item parameters can send actual data, according to the format
specified in this document, OR all bits shall be filled with 1 and sent. For all contents
in the same message which are optional. the sender does not need to send the message.
If it is sent, the actual data shall be sent in the format specified in this document. The
optional item parameters that do not send the actual data are filled with 1.
8.8 The message shall be sent according to the length specified in this document; the
undefined bits in the specified length shall be filled with 1.
8.9 "Untrusted status" is content sent in order to maintain the communication link, when
the sender cannot obtain or clarify the current status. The receiver shall ignore and not
process the information.
9 Overall charging process of category A system
The entire charging process includes six phases: physical connection completion, low-
voltage auxiliary power-on, charging handshake phase, charging parameter
configuration phase, charging phase, charging end phase, as shown in Figure 1. After
the physical connection and the low-voltage auxiliary power-on is completed, the two
parties start communication. At each phase of communication, if the charger and the
vehicle do not receive each other's message OR do not receive the correct message
within the specified time, it is determined to be timeout (timeout means that the other
party's complete data packet or correct data packet is not received within the specified
time), the communication process shall comply with the requirements of Appendix A.
< 00>: = The charger temperature is normal; < 01>: = The charger is overtemperature;
< 10>: = Untrusted status;
Bits 3 ~ 4: Charging connector failure
< 00>: = Charging connector is normal; < 01>: = Charging connector fault; < 10>: =
Untrusted status;
Bits 5 ~ 6: Charger internal over-temperature fault
< 00>: = The internal temperature of the charger is normal; < 01>: = The internal of
the charger is overtemperature; < 10>: = Untrusted status;
Bits 7 ~ 8: The required power cannot be transferred
< 00>: = Power transmission is normal; < 01>: Power cannot be transmitted; < 10>:
= Untrusted status;
Bits 9 ~ 10: Charger emergency stop failure
< 00>: = Normal; < 01>: = Charger emergency stop; < 10>: = Untrusted status;
Bits 11 ~ 12: Other faults
< 00>: = Normal; < 01>: = Fault; < 10>: = Untrusted status.
Bits 13 ~ 14: Self-check faults (including faults that occur during self-check, such
as insulation detection, short circuit test, adhesion detection, etc.)
< 00>: = Normal; < 01>: = Fault; < 10>: = Untrusted status.
Bits 15 ~ 16: Pre-charge fault (including pre-charge voltage mismatch, pre-charge
fault, etc.)
< 00>: = Normal; < 01>: = Fault; < 10>: = Untrusted status.
3) Reasons for SPN3523 charger suspension charging error
Bits 1 ~ 2: Current mismatch
< 00>: = Current matching; < 01>: = Current mismatch; < 10>: = Untrusted status;
Bits 3 ~ 4: Abnormal voltage
< 00>: = Normal; < 01>: = Abnormal voltage; < 10>: = Untrusted status.
Bits 5 ~ 6: Charging parameters mismatch
< 00>: = Parameter match; < 01>: = Parameter mismatch; < 10>: = Untrusted status.
LMS_T1 between information frames shall be between 1 ms ~ 10 ms.
15.4.1.7 The "starting frame number to receive" as received by the sender and the
"frame sequence number" as received by the receiver shall be less than or equal to the
maximum frame sequence number. Otherwise, the sender or receiver sends LM_NACK
and returns "sending failure" information to the application layer. The application layer
determines the processing method.
15.4.1.8 Both the sender and the receiver can send LM_NACK, to actively terminate
the transmission. After receiving LM_NACK, both parties exit the transmission of long
messages; the connection is closed; the receiver does not process the received message.
15.4.1.9 When three consecutive connection timeouts of the same type occur, the sender
and/or receiver shall send LM_NACK to close the connection; return a "sending
failure" message to the application layer, which will decide whether to resend.
15.4.1.10 Since the information frames of different long messages, which have the same
frame sequence number, cannot be distinguished, only one connection is allowed to be
established at the same time, that is, a new connection can be established, only when
the sender or receiver sends LM_NACK or the receiver sends LM_EndofACK.
15.4.2 Packet reorganization
15.4.2.1 The data length of a long message is greater than 8 bytes; it needs to be split
into multiple information frames when sending: In order to ensure that the information
frame can be identified and reorganized, the first byte of the information frame data
field is defined as the frame serial number of the information frame, the serial number
range is 1 ~ 255. The remaining 7 bytes in the data field are used to load the content,
which is defined by the application layer message structure (if the data field of the last
frame is less than 8 bytes, it is filled with 0xFF).
15.4.2.2 After receiving all information frames, the receiver shall reorganize them back
to the original information, according to the frame sequence number from small to large
(starting from 1).
15.4.3 Connection management
15.4.3.1 Overview
The connection in the multi-information frame transmission mode is a temporary link,
which is established between two nodes, for the purpose of transmitting long messages.
The connection management specifies the establishment of the connection (see
15.4.3.2), data transmission (see 15.4.3.3), the closing of the connection (see 15.4.3.3).
See 15.4.3.4). The long message transmission, which is specified in this document, is
point-to-point; its connection management includes:
- Before the connection is established, both the sender and the receiver shall confirm
that the counter recording the frame sequence number is 0, where the sender
counter is used to record the frame sequence number to be sent next; the receiver
counter is used to record the starting frame sequence number to be received next
time;
- The sender sends an information frame, which has a frame number 0, to request to
establish a connection. After the receiver responds and confirms, the connection is
successfully established;
- After the connection is established, the sender sends the information frame
according to the received response acknowledgement; after the transmission is
completed, it waits for the receiver's next response acknowledgement or end
acknowledgement.
15.4.3.2 Establishment of connection
The sender sends an information frame, which has a frame number 0, to request to
establish a connection. The receiver can choose to receive or refuse to establish a
connection:
- If the receiver chooses to receive, it shall send LM_ACK; meanwhile the LM_ACK
shall contain the receiver's "starting frame number to be received", "total number
of frames to be received". The connection is established successfully;
- When the receiver cannot receive the information frame, due to lack of resources
or storage space, it shall send LM_NACK to refuse to establish the connection. The
establishment of connection fails.
15.4.3.3 Data transmission
15.4.3.3.1 During the data transmission process, the receiver adjusts the data flow
control between nodes, by setting the "starting frame number to be received" and "total
number of frames to be received" of LM_ACK. The sender sends data as required.
15.4.3.3.2 The requirements for pausing and resuming data flow are as follows:
- When the receiver pauses the data stream, the "total number of frames to be
received" in LM_ACK shall be set to 1; the "starting frame number to be received"
shall be set to the last frame number of the previous reception. The sender shall
send the information frame as required (each time the receiver sends LM_ACK,
the sender responds once); the receiver does not process the data frame after
receiving it;
- When the receiver resumes the data flow, it will set the "starting frame number to
be received" in LM_ACK to the frame number of the next frame previously
received; reset the "total number of frames to be received" according to its own
receiving and processing capabilities, until finishing the reception of all
information frames.
15.4.3.4 Closing of connection
The sender's connection closure includes the following situations:
- Complete the data transmission of the entire long message and receive
LM_EndofACK;
- Actively send LM_NACK (for example, the sender actively terminates the
transmission before the transmission is completed, or three consecutive connection
timeouts of the same type cause transmission failure, etc.);
- Receive LM_NACK.
The receiver's connection closure includes the following situations:
- Send LM_EndofACK, after completing the data transmission of the entire long
message;
- Send LM_NACK (if the receiver wants to stop communication early, three
consecutive connection timeouts of the same type cause transmission failure, etc.);
- Receive LM_NACK.
15.4.3.5 Connection timeout
Timeouts during long message transmission include the following situations.
- After the receiver sends LM_ACK, if the information frame with the correct frame
sequence number is not received within the LMS_T2 time, it is a timeout. After the
timeout, an LM_ACK is sent to notify the sender to resend. After three consecutive
timeouts, an LM_NACK is sent to close the connection.
- When the receiver has continuously received information frames, if the next
information frame is not received within LMS_T2 time, after receiving an
information frame, it is a timeout. After the timeout, an LM_ACK is sent, to notify
the sender to resend. After three consecutive timeouts, an LM_NACK is sent to
close the connection.
- When the sender requests to establish a connection, if no response
acknowledgement from the receiver is received, within LMS_T2 time after sending
the information frame, which has a frame number 0, it is a timeout. After the
timeout, the sender resends the information frame, which has a frame number 0.
After 3 consecutive occurrences of timeout, it sends the LM_NACK, to close the
connection.
- After the sender completes all the information frames, that need to be transmitted
- When the receiver receives a message, that is not listed in the status transition table
or does not satisfy the message interaction sequence (such as receiving messages
from other functional modules in one functional module), the message will not be
processed.
- When the receiver receives "reserved" parameters, the "reserved" data will not be
processed.
- If a charging abnormality occurs in the vehicle or charger, a suspension message
consistent with the cause of the suspension shall be sent; the current charging
communication process shall be exited or the phase acknowledgement process of
the next functional module FDC shall be entered. When receiving the suspension
message, the vehicle or charger shall perform the charging suspension process, in
accordance with the requirements of C.4.9, C.4.10, C.4.11 in GB/T 18487.1-2023;
the current charging communication process shall be exited or the phase
acknowledgement process of the next functional module FDC shall be entered.
- When the vehicle or charger receives the other party's suspension message during
the execution of function negotiation, parameter configuration, authentication
function module FDC, if there are no special requirements, it shall turn off all
timers and exit the current charging communication process. If during execution of
reservation, system self-check, power supply mode, pre-charging and energy
transfer function module FDC, it receives the other party's suspension message,
meanwhile the "service statistics" function module negotiation is successful during
function negotiation, it will transfer to the execution of the "service statistics"
function module FDC.
- If the vehicle or charger encounters an abnormality in the execution of function
negotiation, parameter configuration, authentication function module FDC, it sends
a suspension message. If there are no special requirements, it shall turn off all
timers and exit the current charging communication process. If abnormality occurs
during the execution of reservation, system self-check, power supply mode, pre-
charging and energy transfer function module FDC, meanwhile the "service
statistics" function module negotiation is successful during function negotiation,
then after sending the suspension message, it shall transfer to the execution of the
"service statistics" function module FDC.
16.3.5 When the application layer hands over the message to be sent to the transport
layer, it defines it as "reliable message" and "unreliable message", according to
application requirements. For "unreliable messages", it may specify the "periodic
sending time" parameter. For "reliable messages", it may specify the "maximum
sending time".
16.3.6 After receiving the "sending failure" information uploaded by the bottom layer,
the application layer shall interrupt the current application, perform operations such as
suspending charging and restarting the charging module.
to the provisions of B.4.3 in GB/T 18487.1-2023.
d In addition to meeting the requirements of GB/T 18487.1-2023, the basis for charging
parameter matching shall also be defined by the charging operator. Other matching
conditions can also be defined by the charging operator.
e Whether the vehicle performs time synchronized operations is determined by its own
working mode or working conditions.
f After updating the parameters of the BCP message, the vehicle should send at least 2 more
frames of BCP messages with updated parameters.
g After receiving the BRO message, the charger shall judge again whether the charging
parameters are appropriate, based on the last BCP message received.
h In order to ensure compatibility, before the charger receives the BSM message, charging
shall not be suspended due to the BSM message timeout. If the charger does not receive
the next frame of BSM message, for more than 5 seconds after receiving the BSM message,
it is a timeout error. In this case, the charger shall send an error message to end charging;
meanwhile it shall not reconnect, without re-plugging and unplugging the gun.
i The charging end conditions of the charger include the preset conditions being met (time,
amount, SOC, etc.), the operator making a stop process (pressing the stop button, swiping
the card for settlement, etc.), other end conditions specified in GB/T 18487.1-2023.
j The charging end conditions of the vehicle include the battery being fully charged and other
end conditions, which are specified in GB/T 18487.1-2023.
k If the vehicle stops charging after receiving the CST message, the vehicle shall stop sending
BST messages after sending 5 to 10 frames of BST messages; send BSD messages
periodically. If the vehicle actively stops charging, it shall stop sending BST messages
after receiving the CST message; send BSD messages periodically.
l If the charger stops charging after receiving the BST message, the charger sends CST
messages periodically and determines whether to receive the BSD message at the same
time. If the charger actively stops charging, it shall continue to determine whether to
receive the BSD message, after receiving the BST message.
Figure A.1 -- Normal charging communication flow chart (continued)
A.2 Message timeout processing flow of category A system
The message timeout communication process of category A system is as shown in
Figure A.2 ~ Figure A.3.
......
 
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.