GBT27930电动汽车非车载充电机与电池理系统的通信协议第2部分：ChaoJi充电系统

中华人民共和国国家标准

GB/T27930—xxxx

电动汽车非车载传导式充电机与车辆

之间的数字通信协议第2部分：

ChaoJi充电系统

Communicationprotocolsbetweenoff-boardconductivecharger

andelectricvehiclePart2：ChaoJiSystem

（征求意见稿）

××××-××-××发布××××-××-××实施

前言

GB/T27930《电动汽车非车载传导式充电机与车辆之间的数字通信协议》分为2个部

分：

——第1部分：GB/T2015系统；

——第2部分：ChaoJi充电系统

本部分为GB/T27930的第2部分。

本部分按照GB/T1.1—2020的规定起草。

请注意本部分的某些内容可能涉及专利。本部分的发布机构不承担识别专利的责任。

本部分由中国电力企业联合会提出并归口。

本部分起草单位：。

本部分主要起草人：。

II

GB/T27930-xxxx

电动汽车非车载传导式充电机与车辆之间的数字通信协议第2部分

ChaoJi充电系统

1范围

本部分规定了电动汽车非车载传导式充电机（以下简称充电机）充电通信控制器（SupplyEquipment

CommunicationController，以下简称SECC）与车辆充电通信控制器（ElectricVehicleCommunication

Controller，以下简称EVCC）之间基于控制器局域网（ControlAreaNetwork，以下简称CAN）的通信物

理层、数据链路层及应用层的定义。

本部分适用于采用GB/T18487.1附录D规定的充电模式4的充电机与车辆之间的通信，也适用于充电机

与具有充电控制功能的车辆电子控制单元之间的通信。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文

件。

GB/T19596电动汽车术语

GB/T29317电动汽车充换电设施术语

GBT18487.1电动汽车传导充电系统第1部分通用要求

ISO11898-1:2003道路车辆控制器局域网络第1部分：数据链路层和物理信令（Roadvehicle–Control

areanetwork(CAN)Part1:Datalinklayerandphysicalsignaling）

SAEJ1939-11:2006商用车控制系统局域网CAN通信协议第11部分：物理层，250K比特/秒，屏蔽双绞

线（RecommentedpracticeforserialcontrolandcommunicationvehiclenetworkPart11:Physicallayer–250K

bits/s,twistedshieldedpair）

SAEJ1939-21:2006商用车控制系统局域网CAN通信协议第21部分：数据链路层（Recommendedpractice

forserialcontrolandcommunicationvehiclenetworkPart21:Datalinklayer）

3术语和定义

GB/T19596、GB/T29317界定的以及下列术语和定义适用于本部分。

3.1

帧frame

组成一个完整信息的一系列数据位。

3.2

CAN数据帧CANdataframe

用于传输数据的CAN协议所必需的有序位域，以帧起始（SOF）开始，帧结束（EOF）结尾。

3.3

CAN报文CANmessage

发送或接收参数组及其参数数据的一个实例，一个报文的发送可能需要交互一个或多个CAN数据帧。

1

GB/T27930-xxxx

3.4

标识符identifier

CAN仲裁域的标识部分。

3.5

扩展帧extendedframe

CAN2.0B规范中定义的使用29位标识符的CAN数据帧。

3.6

优先权priority

在标识符中一个3位的域，设置传输过程的仲裁优先级，最高优先权为0级，最低优先权为7级。

3.7

参数组parametergroup(PG)

在应用层传输的参数集合，分为命令类和信息类。

3.8

参数组标识parametergroupidentification(PGI)

用于唯一标识一个参数组的一个字节。

3.9

协议数据单元protocoldataunit(PDU)

一种特定的CAN数据帧格式。

3.10

传输协议transportprotocol

基于数据链路层上用于传输数据的一种机制。

3.11

电子控制单元electroniccontrolunit(ECU)

电子控制单元，即车载电脑，由微控制器和外围电路组成。

3.12

功能模块functionmodule

电动汽车与充电设施间能量交互过程中的某个业务功能。

3.13

必须项功能模块mandatoryfunctionmodule

一个完整的能量交互过程中必须具有的功能模块。

3.14

可选项功能模块optionalfunctionmodule

一个完整的能量交互过程中可选择具有的功能模块。

3.15

可重载功能模块（overridefunctionmodule）

可被重新定义或替换的功能模块。

3.16

功能代码functioncode(FC)

为功能模块分配的编号。

3.17

功能描述码functiondescriptioncode(FDC)

功能模块具备特定功能的编号。

3.18

信息帧informationframe(IF)

2

GB/T27930-xxxx

数据链路层上用于传输有效信息或数据的CAN数据帧。

3.19

控制帧controlframe(CF)

数据链路层上用于进行流量控制和差错管理的CAN数据帧。

3.20

多信息帧传输方式

使用自动重传请求方式传输具有帧编号的一帧或多帧数据的方式。

3.21

长消息longmessage

采用多信息帧传输方式传输的消息。

3.22

充电服务内容chargingservice

由充电场景和充电功能共同决定的充电应用。

3.23

需要确认的短消息reliableshortmessage

采用自动重传请求方式传输不具有帧编号的单帧数据。

3.24

不需要确认的短消息unreliableshortmessage

不需要自动重传请求方式传输不具有帧编号的单帧数据。

4缩略语

LM长消息longmessage

SM短消息shortmessage

SM_RM需要确认的短消息reliableshortmessage

SM_URM不需要确认的短消息unreliableshortmessage

SM_ACK短消息应答确认消息shortframeacknowledge

LM_ACK长消息应答确认longframeacknowledge

LM_NACK长消息放弃连接确认longframenegativeacknowledge

LM_EndACK长消息接收结束确认longframeendofacknowledge

5物理层

本部分采用的CAN通信网络物理层应符合SAEJ1939-11:2006、SAEJ1939-11:2006中关于物理层的规

定，使用独立的CAN总线，并应支持SECC、EVCC、适配器通信控制器（VehicleAdaptorCommunication

Controller，以下简称VACC）三个节点，通信速率采用250kbit/s。

为了减少外界干扰对总线通信的影响，本部分采用的CAN通信网络应使用屏蔽双绞线进行组网和布线，

CAN通讯线屏蔽层宜在充电机侧接地，相应的车辆侧CAN通讯线屏蔽层也宜在CAN总线端部接地。

6数据链路层

6.1帧格式

3

GB/T27930-xxxx

采用本部分的设备应使用CAN扩展帧的29位标识符，具体每个位分配的相应定义应符合SAEJ1939-

21:2006中的相关规定。

6.2协议数据单元

每个CAN数据帧包含一个单一的协议数据单元（PDU），见表1。协议数据单元由七部分组成，分别是

优先权，扩展数据页，数据页，PDU格式，PDU特定，源地址和数据域。

表1协议数据单元

D…

EDP

PPPFPSSADATA

3118880-64

数据格式要求：

1）P为优先权：从最高0设置到最低7。

2）EDP为扩展数据页：备今后扩展使用，本部分中为0。

3）DP为数据页：用来选择参数组描述的辅助页，本部分中为0。

4）PF为PDU格式消息类型：用来确定PDU的格式，以及数据域对应的参数组编号。

5）PS为PDU特定格式：PS值取决于PDU格式。本部分中采用PDU1格式，PS值为目标地址。

6）SA为源地址：数据帧的源地址。

7）DATA为数据域：不同消息类型的的数据域定义详见本部分8.2的规定。

6.3地址分配

网络地址用于保证信息标识符的唯一性以及表明信息的来源。SECC、EVCC和适配器定义为不可配置

地址，即该地址固定在ECU的程序代码中，包括服务工具在内的任何手段都不能改变其源地址。SECC、

EVCC和VACC的地址分配如表2所示。

表2地址分配

节点首选地址

SECC86(56H)

EVCC244(F4H)

VACC201(C9H)

6.4帧类型

本部分规定的帧类型包括信息帧、控制帧2类。

7版本协商

7.1总体描述

版本协商是通信协议的引导部分，协商原则、报文定义和信息交互过程固定不变。版本协商过程中，

充电机和车辆通过协商决定通信协议版本号。版本协商的具体描述如表3所示。

表3版本协商总体描述

序号项目描述信息

1名称版本协商

2目标充电机和车辆协商决定通信协议版本号。

4

GB/T27930-xxxx

通信链路建立之后，双方进行通信协议版本协商，车辆检测是否支持充电机发送

的版本，返回协商结果。

充电机首先应发送其支持的最高协议版本号：

-如果车辆支持该版本并确定以该版本进行通信，返回“协商成功”信息给充电机；

-如果车辆不支持该版本且该版本低于车辆支持的最低版本，返回“协商失败”信息

给充电机；

3描述-如果车辆不支持该版本且该版本高于车辆支持的最低版本，将“继续协商”信息，

连同期望的版本号一起返回给充电机；

充电机接收到“继续协商”信息后，

-如果当前发送版本已是充电机支持的最低版本，继续发送当前版本，等待超时协

商失败；

-如果充电机支持车辆期望的版本，则发送该版本号，协商成功；

如果桩不支持车辆期望的版本，则发送比当前版本低的最高版本，继续协商。

4前置条件物理连接完成，通信链路建立。

为了提高兼容性，充电机和车辆可支持多个版本的通信协议。协商成功时，双方

支持相同的协议版本，否则协商失败。

通信协议版本号由CAN类型、主版本号、次版本号、临时版本号组成。

5要求-当前CAN类型为CAN2.0，同时可支持未来扩展至CANFD，CANXL等；

-一般来说，主版本号在通信协议有结构性的变化（如功能模块有变化）时更新；

-次版本号在通信协议有较大功能变化时更新；

-临时版本仅用于示范项目和测试临时用途，正式发布的版本中临时版本号为0。

协商成功：车辆发送“协商成功”，双方按照协商一致的协议版本进行信息交

互。

6结束条件协商失败：包括，

-版本协商失败，车辆发送“协商失败”，双方退出本次通信过程；

-版本协商超时，车辆发送“协商失败”，双方退出本次通信过程。

7.2报文定义

版本协商的交互报文的数据链路层应满足本部分第6章的规定。版本协商过程包括“充电机协议版本”

“车辆协商结果”报文，其帧格式定义如表4，表5所示。

表4充电机协议版本帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

0xF40x56

定义0x03000x3C遵循表6的定义。

（目的地址）（源地址）

表5车辆协商结果帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

5

GB/T27930-xxxx

0x560xF4

定义0x03000x3C遵循表7的定义。

（目的地址）（源地址）

表6充电机协议版本数据域内容

序号参数内容长度数据类型参数类型描述与要求

1CAN类型1字节BYTECANType充电机CAN类型，当前版本采用CAN2.0通信。

充电机支持的协议版本号，本部分规定当前版本

为V2.0.0，如果车辆的协商结果为“继续协商”，

2协议版本号3字节BYTE[3]ProtocolVersionType

而充电机没有其他可支持的版本，则继续发送当

前版本号。

3预留1字节BYTEReservedType接收方不判断该值

4预留1字节BYTEReservedType接收方不判断该值

5预留1字节BYTEReservedType接收方不判断该值

报文校验码，从第1个字节至第7个字节的累加

6校验码1字节BYTECheckcodeType

和

表7车辆协商结果数据域内容

序号参数内容长度数据类型参数类型描述与要求

1CAN类型1字节BYTECANType车辆CAN类型，当前版本采用CAN2.0通信。

车辆版本协商结果，包括“继续协商”，“协商成

2协商结果1字节BYTEVersionResultType

功”，“协商失败”。

车辆期望或协商一致的版本号。

如果车辆协商结果为“协商成功”时，值为双方

协商一致的版本号；

3协商版本号3字节BYTE[3]ProtocolVersionType如果车辆协商结果为“继续协商”，值为车辆期望

的版本号；

如果车辆协商结果为“协商失败”值为

0xFFFFFF；

4预留1字节BYTEReservedType接收方不判断该值。

5预留1字节BYTEReservedType接收方不判断该值

6校验码1字节BYTECheckcodeType报文校验码，第1个字节至第7个字节的累加和

7.3报文交互过程

物理连接完成，充电机闭合S1后开始发送“充电机协议版本”报文。充电机首先发送其支持的最高

协议版本号，车辆接收并检查自身支持的版本号返回版本协商结果。如果“继续协商”，双方继续以较低的

协议版本号进行协商；如果“协商成功”，双方按照协商一致的版本的通信协议进行信息交互；如果“协

商失败”，双方退出本次通信过程。

完整的状态转换过程如表8，表9所示。

表8充电机状态转换表

触发条件

充电机T1定时器接收接收接收T2定时收到

到“协商成功”“协商失败”“继续协商”器到非法帧

状S0发送CvList-----

6

GB/T27930-xxxx

态(初始状态)（Ns），进

入S1

根据车辆“期望

版本号”信息调

整Ns指向（如

果支持，则Ns

指向该版本号，进入S3，

S1发送CvList关闭T1,T2，进关闭T1,T2进

如不支持，则指关闭T1，-

（协商中）（Ns）入S2入S3

向等于前一个T2

更低版本，如

Ns已为第一个

则Ns不变），保

持S1

S2

发送协商成功

（协商成功，-进入功能协商进入S3--

的版本

进入功能协商）

S3

------

（协商失败，终止）

注1：.T1为充电机发送定时器，当S1合上后启动T1定时器，周期50ms

注2：.T2为版本协商超时定时器，当S1合上后启动T2定时器，默认为5s

注3：CVList：充电机支持的协议版本队列，版本号从小到大排列，Ns为计数器，初始值指向最高版本号

注4：.-表示充电机不作任何处理

注5：非法帧为表中未列举的所有报文，包括版本协商报文以外的其他报文或不满足交互原则的版本内容等。

表9车辆状态转换表

触发条件

接收到CvList接收到

车辆收到

有相同的版有更低的版本没有更低的版“功能协商T2定时器到

非法帧

本号号本号报文”

发送“继续协

发送“协商

S1商”，版本号为发送“协商失发送“协商失败”,

成功”，进--

（协商中）最接近的低版败”，进入S3终止

入S2

本号

发送“继续协

状

S2发送“协商商”，版本号为发送“协商失进入发送“协商失败”,

态-

（协商成功）成功”最接近的低版败”，进入S3功能协商终止

本号，进入S1

发送

S3发送“协商发送“协商失发送“协商失发送“协商失败”,

“协商失-

（协商失败）失败”败”败”终止

败”

注1：T2为版本协商超时定时器，当S1合上后启动T2定时器，默认为5s

注2：CVList：充电机支持的协议版本队列，版本号从小到大排列，Ns为计数器，初始值指向最高版本号

注3：-表示充电机不作任何处理

注4：非法帧为所有状态表未列举的报文，如版本协商报文以外的其他报文或不满足交互原则的版本内容。

7

GB/T27930-xxxx

图1给出了版本协商的报文交互过程。

充电机电动汽车

开始版本交互开始版本交互

版本号设为其支

持的最高版本

发送充电机协议

版本报文

是否收到

超时否

超时处理充电机协议版本

报文

是

是否支持接收的

发送的版本改为

版本号是

低于当前版本支协商成功

持的最高版本，

若无则继续发送

否

当前版本

接收的版本号是

是否低于车辆支持

最低版本协商失败

否

继续协商

发送车辆协商结

果报文

否是否收到协商超时

超时处理

结果报文

协商结果是否继续是

协商

是

是否

接收协商结果

是否继续协商

否

版本协商结束版本协商结束

图1版本协商报文交互

8传输层

8.1消息类型

8.1.1分类

传输层负责数据传输和流量控制，如流量控制、分组编号与顺序检查等。本部分规定的消息类型包括

长消息、需要确认的短消息、不需要确认的短消息。长消息、需要确认的短消息为上层应用提供可靠性传

输服务，不需要确认的短消息则面向简单不可靠信息的传输服务。

8.1.2长消息

8

GB/T27930-xxxx

长消息(LM)的发送应遵循8.2规定的多信息帧传输方式，其信息帧格式定义如表10所示。

表10长消息的信息帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

总字

目的源帧的序号：0总帧数0xFF0xFF0xFF0xFF

定义0x06000x01节数

地址地址

帧的序号：>0应用层参数组，最后一帧不足8字节的，填充0xFF

注1：为了描述方便，通常用LM（0）表示帧序号为0的长消息信息帧；LM（n）表示帧序号为n（n>0）的长消息信息帧。

注2：总帧数为包括LM（0）和应用层参数组在内传输的所有帧数。

注3：总字节数为长消息应用层参数组长度，不含帧序号、不含最后一帧不足8字节填充的0xFF

长消息的控制帧用于差错控制和流量控制，包括3类：

-长消息应答确认LM_ACK

-长消息放弃连接确认LM_NACK

-长消息接收结束确认LM_EndACK

其中LM_ACK，LM_EndACK是接收方对发送方的确认响应，LM_NACK是接收方或发送方发送给对

方的放弃连接确认。长消息的控制帧格式定义如表11所示。

表11长消息的控制帧格式

协议数D

PEDPPFPSSA数据域

据单元P

占位

31188888888888

（bit）

待接收

待接收

目LM_ACK：1起始帧0xFF0xFF0xFF0xFF0xFF

源总帧数

的序号

定义3000x04地

地LM_NACK：20xFF0xFF0xFF0xFF0xFF0xFF0xFF

址

址接收的接收的

LM_EndACK：30xFF0xFF0xFF0xFF

总帧数总字节数

注1：为了描述方便，通常用LM_ACK（n,k）表示待接收起始帧序号为n，待接收总帧数为k的长消息应答确认控制帧。

8.1.3需要确认的短消息

需要确认的短消息(SM_RM)要求接收方应答确认。一个需要确认的短消息的重发次数应限制在3次，

即总的发送次数最多为4次。如果发送方在发送4次后仍然没有接收到确认信息，发送方应该放弃进一步尝

试，重发的时间间隔为100ms~250ms。需要确认的短消息消息帧格式如表12所示，应答确认（控制帧）格

式定义如表13所示。

表12需要确认的短消息的信息帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

目的源

定义0x04000x02遵循应用层定义，不足8字节的填充0xFF。

地址地址

9

GB/T27930-xxxx

表13需要确认的短消息的控制帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

源

0x0目的

定义000x04地010xFF0xFF0xFF0xFF0xFF0xFF

3地址

址

8.1.4不需要确认的短消息

不需要确认的短消息(SM_URM)无需接收方应答确认，上层应用中循环发送的报文通常为不需要确认

的短消息。其信息帧格式如表14所示。

表14不需要确认的短消息的信息帧定义

协议数

PDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

目的源

定义0x06000x03遵循应用层定义，不足8字节的填充0xFF。

地址地址

8.2多信息帧传输方式

8.2.1原则

长消息的传输控制分为两个主要功能：分包重组以及连接管理。

8.2.2分包重组

当长消息的数据域长度大于8字节时，发送方应将其拆分为若干个小的数据帧，然后按序逐一传输。接

收方接收到所有的数据帧后再重组成原始信息。

（1）数据帧

为了保证每个数据帧能被识别和重组，信息帧数据域的首字节定义为数据帧的序号，序号范围为1~255，

因此最长的数据长度是1785个字节。数据帧序号为0时，表示发送方请求建立长消息传输的虚拟连接。

（2）序号

序号是在拆装时分配给数据帧的，接收方接收后，利用序号把数据帧重组回原始信息。数据帧从编号

为１的数据帧开始按编号递增顺序发送。

（3）数据拆装

数据拆装用于数据域大于8字节的消息。信息的数据帧发送间隔时间LMS_T1应小于10ms（待讨论）。

接收者应确定这些数据帧具有相同的参数标识。

每个数据帧（除了最后一个数据帧）都装载着原始数据中的7个字节，最后一个数据帧的数据域的8个

字节包含：数据帧的序号和至少一个字节的参数数据，未使用的字节全部设置为“FF”。

（4）数据重组

10

GB/T27930-xxxx

数据帧被陆续地接收后，接收方将会按照序号顺序重新组合成长消息。

8.2.3连接管理

连接管理规定了长消息传输时节点之间虚拟连接的建立、使用和关闭。虚拟连接，是指在通信过程中，

为了传送一条长消息，在两个节点间建立的临时连接。

（1）原则

-每次发送长消息之前收发双方都需要重置用于记录帧序号的计数器，对于发送方，计数器用于记录

下次要发送的帧序号，对于接收方，计数器用于记录下次要接收的帧序号。

-发送方发送帧序号为0的数据帧作为连接建立的起始，接收方应答确认。

-连接建立后，发送方按照接收方的应答确认来发送数据帧，发送完毕后等待接收方的应答确认。

-发送方、接收方不支持同时建立两个及以上的连接。

-当连续出现3次同类型的连接超时后，应返回“发送失败”信息至应用层。

-只支持点到点的长消息传输。

（2）连接的建立

发送方请求发送长消息时，帧的帧序号为0，包含了长消息的总帧数和总字节数。

接收方接收到帧序号为0的长消息后，可以选择接收或者拒绝建立连接。如果选择接收，应发送长消息

应答确认LM_ACK。LM_ACK包含了接收方待接收的起始帧序号、待接收总帧数。连接建立后，接收方应

从序号为1的数据帧开始接收。

如果发送方接收到LM_ACK，连接建立完成。

如果接收方缺少资源或存储空间，可拒绝建立连接，此时应发送放弃连接确认LM_NACK，连接建立

失败。

（3）数据传输

发送方接收到LM_ACK后开始数据传输。接收方负责调整节点之间的数据流控制，如果接收方需要暂

停数据流，可使用LM_ACK将待接收总帧数置为1，待接收起始帧序号置为已接收的最后一帧的帧序号，

发送方重复发送此帧内容（即重复接收上一组最后一帧报文），接收方收到该报文后不做处理。

如果接收方决定终止传输，应发送LM_NACK，发送方收到LM_NACK后终止长消息的传输。

（4）连接的关闭

在传输没有错误的情况下，当接收到所有数据帧后，接收方将发送消息结束确认LM_EndACK，通知

发送者连接关闭。

长消息传输过程中，发送方或接收方可在任何时候使用LM_NACK终止连接。例如，如果接收方没有

可用资源处理消息，可以通过发送LM_NACK放弃连接。当接收到LM_NACK时，所有已传送数据帧将被

丢弃。

任一方发生传输故障（例如连续出现3次同类型的连接超时）都会导致连接关闭。长消息的连接关闭，

包括：

1）发送方在以下情况下，可以认为连接被关闭：

a．完成整个长消息的数据传输且接收到LM_EndACK；

b．发送LM_NACK；

c．接收LM_NACK；

2）接收方在以下情况下，可以认为连接被关闭：

a．完成整个长消息的数据传输后发送了LM_EndACK；

b．发送LM_NACK（如发送方希望提早停止通讯，超时等等）；

c．接收LM_NACK；

（5）连接的超时

11

GB/T27930-xxxx

-接收方接收到一个数据帧后，若LMS_T2内未接收到下一个数据帧即为超时，超时后发送LM_ACK

通知发送方重发，总共3次超