GB/T 27930.2-2024Digital communication protocols between off-board conductive charger and electric vehicle - Part 2: Communication protocols for GB/T 20234.3 (English PDF)

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

7.2 Version negotiation

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. The current version uses CAN2.0B communication. The receiver does not use this value to determine the negotiation result. The higher version is compatible Negotiation result BYTE VersionResultType Charger version negotiation result: "negotiation succeeded", the value is the version number agreed upon by both parties. […]

8.1 General

Version set to be the highest version supported Version set to be the highest version supported No No No Timeout Yes Yes Yes Yes No No Whether it supports receiving vehicle version number negotiation negotiation version number Version comparison Yes Higher than A1 without lower version Yes Version comparison Charger negotiation result = “negotiation s Higher ucceeded” Negotiation with lower than A2 Lower than A2 version = received version version Higher than A1 with lower version Lower than A1 No No Yes Yes Stop sending A1 after sending at least 1 frame A1 Stop sending A2 receiving charger Whether it supports Send at least 1 frame; stop sending A2 after negotiation failure Timeout, 10 s from the sending of first No Timeout, or receive CHM/CRM Timeout, 10 s from the sending of first frame A1 Version negotiation ends Version negotiation ends Judged based on function negotiation timeout Appendix M Timeout, 10 s from the sending of first frame A1 Whether it receives “charger support function” message Whether it receives the A2 of “negotiation succeeded” “Negotiation succeeded” and version number ≥ 2.0. […]

8.5 Multi-information frame transmission mode

8.5.2 Packet reassembly

8.5.3 Connection management

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.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. […]

9.3 Public messages

10.1 Overview

The timeout of the message is divided into the following two types:

- Data link layer and transport layer message timeout;

- Function module (specific FDC) timeout defined by the application layer.

10.2 Data link layer and transport layer timeout

10.2.1 For unreliable short message, unless otherwise specified, they shall be sent according to the message cycle time period specified by the application layer. See Table J.1 for the start and end sending conditions.

10.2.2 For reliable short message, if no acknowledgement frame is received, the information frame shall be sent repeatedly according to the interval specified in 8.3,

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.

A.1 Charging application scenarios

A.1.1 The information interaction during the charging process consists of multiple function modules in sequence. By configuring different instances of override function modules, the application of different charging functional scenarios can be realized.

A.1.2 The information interaction process of a typical basic charging application scenario shall comply with the provisions of Figure A.1, where the shaded part is the minimum set for realizing basic charging.

A.2 Charging & discharging application scenario

A.2.1 In the process of discharging in the charging & discharging scenario, during the interaction of parameter configuration, pre-charge and energy transfer function modules, the charger and vehicle shall be able to complete the charging and discharging functions of the vehicle and the charger; other function modules are consistent with the charging scenario. A.2.2 The information interaction process of a typical basic charging & discharging application scenario shall comply with the provisions of Figure A.2, where the shaded part is the minimum set for realizing basic charging and discharging. The charging and discharging function module type shall comply with the provisions of Figure A.3. […]

B.2 General requirements

The general requirements of the function negotiation function module shall comply with the provisions of Table B.1. After the version negotiation is successful, the charger and the vehicle negotiate FC and FDC. The charger sends all the FCs and corresponding FDCs it supports to the vehicle. 4 Precondition Version negotiation is successful and the protocol version is not lower than V2.0.0 Negotiation process The charger sends all the FCs and corresponding FDCs it supports to the vehicle; the charger can support multiple FDCs under one FC; the mandatory function module supports at least one FDC. The vehicle selects the FDC according to its own strategy. There is no more than one negotiation result FDC on the same FC. If both parties support the same FDC on a certain function module, the negotiation is successful in this function module; if both parties do not have a common FDC on a certain function module, the negotiation fails in this function module. information according to the successfully negotiated function module and corresponding FDC; […]

C.1 Overview

The parameter configuration function module (FC=0x20) is an overridable mandatory function module. During the interaction process of the parameter configuration function module, the charger and the vehicle determine whether the basic parameters match.

C.2 Charging mode parameter configuration (FDC=1)