GB/T 27930.2-2024 非车载传导式充电机与电动汽车之间的数字通信协议 第2部分：用于GB/T 20234.3的通信协议

ICS43.120
CCS T35
中华人民共和国国家标准
GB/T27930.2—2024
非车载传导式充电机与电动汽车之间
的数字通信协议 第2部分:用于
GB/T20234.3的通信协议
Digitalcommunicationprotocolsbetweenoff-boardconductivechargerand
electricvehicle—Part2:CommunicationprotocolsforGB/T20234.3
2024-12-31发布2024-12-31实施
国家市场监督管理总局
国家标准化管理委员会发布

目 次
前言………………………………………………………………………………………………………… Ⅲ
引言………………………………………………………………………………………………………… Ⅳ
1 范围……………………………………………………………………………………………………… 1
2 规范性引用文件………………………………………………………………………………………… 1
3 术语和定义……………………………………………………………………………………………… 1
4 缩略语…………………………………………………………………………………………………… 1
5 总体要求………………………………………………………………………………………………… 2
6 物理层…………………………………………………………………………………………………… 3
7 数据链路层……………………………………………………………………………………………… 3
7.1 总体要求…………………………………………………………………………………………… 3
7.2 版本协商…………………………………………………………………………………………… 4
8 传输层…………………………………………………………………………………………………… 11
8.1 通则………………………………………………………………………………………………… 11
8.2 不需要确认的短消息……………………………………………………………………………… 12
8.3 需要确认的短消息………………………………………………………………………………… 12
8.4 长消息……………………………………………………………………………………………… 12
8.5 多信息帧传输方式………………………………………………………………………………… 13
9 应用层…………………………………………………………………………………………………… 21
9.1 总体要求…………………………………………………………………………………………… 21
9.2 通信过程…………………………………………………………………………………………… 22
9.3 公共报文…………………………………………………………………………………………… 24
10 超时…………………………………………………………………………………………………… 30
10.1 概述……………………………………………………………………………………………… 30
10.2 数据链路层和传输层超时……………………………………………………………………… 30
10.3 应用层功能模块超时…………………………………………………………………………… 30
附录A (规范性) 应用场景的实现……………………………………………………………………… 32
A.1 充电应用场景…………………………………………………………………………………… 32
A.2 充放电应用场景………………………………………………………………………………… 33
附录B(规范性) 功能协商功能模块…………………………………………………………………… 35
B.1 概述………………………………………………………………………………………………… 35
B.2 总体要求…………………………………………………………………………………………… 35
B.3 报文定义…………………………………………………………………………………………… 35
B.4 报文交互过程……………………………………………………………………………………… 38
附录C(规范性) 参数配置功能模块…………………………………………………………………… 42
C.1 概述………………………………………………………………………………………………… 42
Ⅰ
GB/T27930.2—2024
C.2 充电模式参数配置(FDC=1)…………………………………………………………………… 42
C.3 充放电模式参数配置(FDC=2)………………………………………………………………… 46
附录D(规范性) 鉴权功能模块………………………………………………………………………… 52
D.1 通则………………………………………………………………………………………………… 52
D.2 扫码/刷卡(FDC=1)……………………………………………………………………………… 52
D.3 EVIN鉴权(FDC=2) …………………………………………………………………………… 57
D.4 云端鉴权-桩识别码(FDC=3)…………………………………………………………………… 62
附录E(规范性) 预约充电功能模块…………………………………………………………………… 68
E.1 通则………………………………………………………………………………………………… 68
E.2 车辆定义预约开始时间(FDC=1)……………………………………………………………… 68
附录F(规范性) 输出回路检测功能模块……………………………………………………………… 77
F.1 通则………………………………………………………………………………………………… 77
F.2 输出回路检测(FDC=1)………………………………………………………………………… 77
附录G (规范性) 供电模式功能模块…………………………………………………………………… 84
G.1 通则……………………………………………………………………………………………… 84
G.2 恒压供电模式(FDC=1)………………………………………………………………………… 84
附录H (规范性) 预充及能量传输模块………………………………………………………………… 93
H.1 通则……………………………………………………………………………………………… 93
H.2 充电模式预充及能量传输(FDC=1)…………………………………………………………… 93
H.3 充放电模式预充及能量传输(FDC=2) ……………………………………………………… 105
附录I(规范性) 结束功能模块………………………………………………………………………… 126
I.1 概述……………………………………………………………………………………………… 126
I.2 结束(FDC=1)…………………………………………………………………………………… 126
附录J(规范性) 报文周期及功能模块超时…………………………………………………………… 133
附录K (规范性) 退出方式…………………………………………………………………………… 141
附录L(规范性) 参数类型表………………………………………………………………………… 144
附录M (规范性) 向下兼容的通信协议……………………………………………………………… 155
M.1 通则……………………………………………………………………………………………… 155
M.2 物理层…………………………………………………………………………………………… 155
M.3 数据链路层……………………………………………………………………………………… 155
M.4 应用层…………………………………………………………………………………………… 156
M.5 充电总体流程…………………………………………………………………………………… 157
M.6 报文分类………………………………………………………………………………………… 157
M.7 报文格式和内容………………………………………………………………………………… 159
M.8 充电流程………………………………………………………………………………………… 172
M.9 报文开始发送条件和结束发送条件…………………………………………………………… 178
参考文献…………………………………………………………………………………………………… 180
Ⅱ
GB/T27930.2—2024
前 言
本文件按照GB/T1.1—2020《标准化工作导则 第1部分:标准化文件的结构和起草规则》的规定
起草。
本 文件是GB/T27930的第2部分。GB/T27930已经发布了以下部分:
———非车载传导式充电机与电动汽车之间的数字通信协议;
———非车载传导式充电机与电动汽车之间的数字通信协议 第2部分:用于GB/T20234.3的通
信协议。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由中华人民共和国工业和信息化部提出。
本文件由全国汽车标准化技术委员会(SAC/TC114)归口。
本文件起草单位:中国汽车技术研究中心有限公司、比亚迪汽车工业有限公司、华为数字能源技术
有限公司、北汽福田汽车股份有限公司、广汽埃安新能源汽车股份有限公司、广州小鹏汽车科技有限公
司、蔚来汽车科技(安徽)有限公司、深圳市车电网络有限公司、广州巨湾技研有限公司、深蓝汽车科技有
限公司、领充新能源科技有限公司、中汽研新能源汽车检验中心(天津)有限公司、特来电新能源股份有
限公司、天津平高易电科技有限公司、合肥国轩高科动力能源有限公司、深圳巴斯巴科技发展有限公司、
杭州中恒电气股份有限公司、宁德时代新能源科技股份有限公司、中汽研汽车检验中心(广州)有限公
司、湖南京能新能源科技有限公司、北京车和家汽车科技有限公司、吉利汽车研究院(宁波)有限公司、
绿能慧充数字技术有限公司、梅赛德斯一奔驰(中国)投资有限公司、深圳市欧澄电气有限公司、中国第
一汽车集团有限公司、重庆长安汽车股份有限公司、威凯检测技术有限公司、中石油昆仑网联电能科技
有限公司、长城汽车股份有限公司、开迈斯新能源科技有限公司、长园深瑞能源技术有限公司、沃尔沃汽
车(亚太)投资控股有限公司。
本文件主要起草人:廉玉波、徐枭、赵颖、李津、邵长宏、韩忠华、郑天雷、廖梦雄、王芳、赵绿化、
兰海波、柳邵辉、刘庆荣、邱鹏、李骁、孙茂建、程浩、王兵、王春生、彭文科、邱石军、樊彬、李川、谭易、
魏俊生、方灵珊、何源、郑祥杰、冯斌、孙小文、季学彬、朱健强、李恩虎、荣超、廖超、田宇威、谷兆宁、
巩慧蛟、吕国伟、吕玉华、李亮、姜毅、谢娜、梁士福、武亨、姜瑞、陈基永、周安健、闫磊、房凯龙、高峰、
王超、王婧雅、杨俊、许青松、柳志民。
Ⅲ
GB/T27930.2—2024
引 言
随着电动汽车相关产业与消费市场规模的快速扩大,行业迫切需求大功率充电、即插即充、预约充
电、放电等新充电功能,直流充电通信协议标准亟待升级。本文件规定了用于GB/T20234.3直流充电
接口的非车载传导式充电机与电动汽车之间的直流充电通信协议,具体给出了通信协议的物理层、数据
链路层、传输层和应用层的详细内容。本文件规定的直流通信协议进一步提升了充电的安全性、兼容性
与便捷性,从而引导电动汽车相关产业的高质量发展。
GB/T27930拟由2个部分构成。
———第1部分:用于GB/T20234.3和GB/T20234.4的通信协议。目的在于确立GB/T20234.3
和GB/T20234.4直流充电接口所应用的数字通信数据链路层、传输层和应用层等内容。
———第2部分:用于GB/T20234.3的通信协议。目的在于确立GB/T20234.3直流充电接口所应
用的数字通信数据链路层、传输层和应用层等内容,用于实现大功率充电、即插即充、预约充
电、放电等数字通信。
Ⅳ
GB/T27930.2—2024
非车载传导式充电机与电动汽车之间
的数字通信协议 第2部分:用于
GB/T20234.3的通信协议
1 范围
本文件规定了用于GB/T20234.3直流充电接口的电动汽车直流充电通信控制器与非车载传导式
充电机充电通信控制器之间基于控制器局域网的物理层、数据链路层、传输层及应用层的通信协议。
本文件适用于直流控制导引电路与控制原理符合GB/T18487.5的电动汽车(简称“车辆”)与非车
载传导式充电机(简称“充电机”)之间的数字通信。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文
件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于
本文件。
GB/T1988 信息技术 信息交换用七位编码字符集
GB16735 道路车辆 车辆识别代号(VIN)
GB18030 信息技术 中文编码字符集
GB/T18487.5 电动汽车传导充电系统 第5部分:用于GB/T20234.3的直流充电系统
GB/T19596 电动汽车术语
GB/T20234.3 电动汽车传导充电用连接装置 第3部分:直流充电接口
GB/T27930—2023 非车载传导式充电机与电动汽车之间的数字通信协议
GB/T29317 电动汽车充换电设施术语
3 术语和定义
GB/T19596、GB/T27930—2023和GB/T29317界定的以及下列术语和定义适用于本文件。
3.1
功能模块 functionmodule
由充电通信交互过程划分的若干个可定义的、具有特定业务功能的最小单元。
3.2
公共报文 publicmessage
满足发送条件时,在应用层各功能模块均可交互的报文。
4 缩略语
下列缩略语适用于本文件。
CAN:控制器局域网(ControllerAreaNetwork)
1
GB/T27930.2—2024
CP:控制导引(ControlPilot)
EVCC:车辆充电通信控制器(ElectricVehicleCommunicationController)
LM:长消息(LongMessage)
LM_ACK:长消息应答确认(LongMessageAcknowledgment)
LM_EndofACK:长消息接收结束确认(LongMessageEndofAcknowledgment)
LM_NACK:长消息放弃连接确认(LongMessageNegativeAcknowledgment)
SECC:充电机充电通信控制器(SupplyEquipmentCommunicationController)
SM:短消息(ShortMessage)
SM_ACK:短消息应答确认消息(ShortMessageAcknowledgment)
SM_RM:需要确认的短消息(ReliableShortMessage)
SM_URM:不需要确认的短消息(UnreliableShortMessage)
TL:传输层(TransportLayer)
5 总体要求
5.1 本文件规定的数字通信协议适用的充电接口应符合GB/T20234.3。
5.2 本文件规定的数字通信协议适用的直流充电系统应符合GB/T18487.5。
5.3 车辆与充电机之间的通信网络基于CAN2.0B协议,通信模型分为物理层、数据链路层、传输层和
应用层,分别按第6章、第7章、第8章和第9章的规定。协议架构分层模型见图1。
注1:实现方式、层间接口关系不在本文件规定范围内。
注2:“上层”或“上层应用”用于描述当前层以上层级。
注3:本文件规定的通信协议应用层要求同样适用于可变速率CAN(CANFD)、扩展长度CAN(CANXL)等协议。
CANFD、CANXL为未来功能预留,实现方式未在本文件中规定。
图1 协议架构分层模型
5.4 车辆与充电机之间的通信过程由不同功能模块组成,充电和充放电应用场景的功能模块应符合
附录A 的规定。
5.5 功能模块的信息交互报文、交互过程应符合附录B~附录I的规定。应用层各功能模块间的确认
和连接应按9.3.1阶段确认的要求完成。
2
GB/T27930.2—2024
5.6 报文周期及功能模块超时应符合附录J的规定。退出方式应符合附录K 的规定。参数类型表应
符合附录L的规定。
5.7 通信过程自物理连接完成后应立即进入版本协商阶段。版本协商完成后,应根据协商结果确认选
择协商一致的版本进行充电。通信协议具备向下兼容(兼容旧版本)能力,通信流程通过版本协商跳转
进入向下兼容的通信协议。向下兼容的通信协议应符合附录M 的规定。
5.8 本文件规定的通信协议版本号为V2.0.0,主版本号和次版本号由本文件定义,临时版本号仅用于
企业的内部开发。
注:企业内部开发意味着采用自定义临时版本号的车辆或充电机不在市场流通。产品开发阶段的企业外部验证或
示范活动采用自定义临时版本号时,通过在本文件归口的标准化机构备案临时版本号以避免临时版本号无序
使用。
5.9 通信交互应符合状态转换表的要求。
注1:状态转换表定义了充电机和车辆的交互状态转换方式。状态转换表左侧列为充电机或车辆在当前通信流程
的状态,上方表头为触发状态跳转的条件。
注2:流程图给出了车辆和充电机(简称“车桩”)交互状态和功能跳转的图形化示意,便于文件使用者的快速理解。
6 物理层
车辆与充电机之间的通信物理层应符合GB/T27930—2023第13章的规定。其中,物理层应使用
独立的CAN 总线,支持EVCC和SECC共2个节点。
7 数据链路层
7.1 总体要求
7.1.1 帧格式
车辆与充电机之间的通信帧格式应符合GB/T27930—2023中14.1的规定。
7.1.2 协议数据单元
协议数据单元由优先权、扩展数据页、数据页、PDU 格式、PDU 特定格式、源地址和数据域共7个
部分组成,应符合表1的规定。
表1 协议数据单元
…
P EDPDP PF PS SA DATA
3 1 1 8 8 8 0~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) 本表第三行表示位数
3
GB/T27930.2—2024
7.1.3 协议数据单元格式
协议数据单元格式应符合GB/T27930—2023中14.3的规定。
7.1.4 地址分配
EVCC和SECC应定义为不可配置地址且为定值,包括服务工具在内的任何手段都不能改变其源
地址。EVCC和SECC的地址分配应符合表2的要求。
注:网络地址用于保证信息标识符的唯一性以及表明信息的来源。
表2 地址分配
序号节点地址
1 EVCC 244(F4H)
2 SECC 86(56H)
注:本文件统一分配通信节点地址。
7.2 版本协商
7.2.1 总体要求
充电机和车辆应通过协商决定本次交互的通信协议版本。版本协商的协商原则、报文定义和信息
交互过程应固定不变。版本协商总体要求应符合表3的规定。
表3 版本协商总体要求
序号项目要求
1 名称版本协商
2 目标充电机和车辆协商决定通信协议版本
3 描述
确认物理连接完成(按GB/T18487.5),通信链路建立之后,双方进行通信协议版本协商,向对方
发送己方支持的最高协议版本号(版本的比较即数字的大小比较)并读取对方判断结果,版本协商
应满足以下要求。
———如对方发送协商成功且协商版本一致,或对方发送协商失败,则结束协商。
———如对方发送继续协商,则判断接收版本是否支持,支持则发送协商成功并将协议版本修改为协
商版本。
———如不支持该版本且低于对方发送的版本,则保持当前版本并“继续协商”。
———如不支持该版本且高于对方版本但有低于对方发送的版本,则根据“期望版本号”调整协议版
本指向低于对方期望版本中最高的版本,发送协议版本并“继续协商”。
———如接收版本已低于最低版本,则发送“协商失败”。
版本协商成功后,车辆持续发送“协商成功”,直到充电机发送下一阶段报文。充电机在接收车辆
发送“协商成功”且版本不低于V2.0.0后进入功能协商阶段。
满足以下任一情况,双方进入附录M 通信流程(不需发送阶段确认报文):
———协商失败;
———从己方首次发送版本协商报文超过10s;
———车辆收到CHM/CRM 报文;
———版本协商成功且协商成功版本低于V2.0.0。
进入附录M 通信流程后,充电机应符合GB/T18487.5的规定,车辆应等待充电机闭合辅源及发
送CHM/CRM 报文
4
GB/T27930.2—2024
表3 版本协商总体要求(续)
序号项目要求
4 前置条件 确认物理连接完成,通信链路建立后同时开始。
在辅源或报文唤醒车辆后,充电机应重新发起版本协商(仅适用于自动重连或重启充电)
5 协议版本
充电机和车辆宜支持多个版本的通信协议。协商成功时,双方支持相同的协议版本,否则协商
失败。
通信协议版本号由CAN类型、主版本号、次版本号、临时版本号组成,应满足以下要求:
———当前CAN类型为CAN2.0B,同时预留CANFD、CANXL的应用;
———主版本号在通信协议有结构性变化(如功能模块有变化)时更新;
———次版本号在通信协议有较大功能变化时更新;
———临时版本号仅用于企业内部的示范、测试等临时用途,正式发布的版本中临时版本号为0
6 结束条件
协商成功条件包括:
———版本协商成功,版本低于V2.0.0(如V1.1.0),充电机根据自身需求适时提供辅源,双方按照
附录M 进行信息交互;
———版本协商成功,版本不低于V2.0.0,双方发送“协商成功”,双方按照协商一致的协议版本进
行信息交互。
协商失败条件包括:
———版本协商失败,充电机或车辆发送“协商失败”,双方按附录M 进行通信;
———版本协商超时,充电机或车辆发送“协商失败”,双方按附录M 进行通信。
退出条件包括:
———在版本协商时,充电机可断开开关S1,双方停止通信,退出充电流程;
———在版本协商时,车辆可断开开关S2,双方停止通信,退出充电流程
7.2.2 报文定义
版本协商交互报文的数据链路层应满足7.1的规定。版本协商包括“充电机版本协商”和“车辆版
本协商”报文,其帧格式定义应分别符合表4和表5的规定,数据域内容应分别符合表6和表7的规定。
表4 充电机版本协商帧格式
协议数据单元P EDP DP PF PS SA 数据域
占位
bit 3 1 1 8 8 8 8 8 8 8 8 8 8 8
定义0x03 0 0 0x38 0xF4
(目的地址)
0x56
(源地址) 应符合表6
表5 车辆版本协商帧格式
协议数据单元P EDP DP PF PS SA 数据域
占位
bit 3 1 1 8 8 8 8 8 8 8 8 8 8 8
定义0x03 0 0 0x39 0x56
(目的地址)
0xF4
(源地址) 应符合表7
5
GB/T27930.2—2024
表6 充电机版本协商数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 CAN类型1字节BYTE CANType
充电机CAN类型:
0x00:CAN2.0B;
0x01:CANFD;
0x02:CANXL。
当前版本采用CAN2.0B通信。接收方不以该值
判定协商结果,高版本兼容低版本
2 协商结果1字节BYTE VersionResultType
充电机版本协商结果:
0x00:继续协商;
0x01:协商成功;
0x02:协商失败
3 协议版本号3字节BYTE[3] ProtocolVersionType
充电机期望或协商一致的版本号。
BYTE1:主版本号;
BYTE2:次版本号;
BYTE3:临时版本号。
如:BYTE1:0x01,BYTE2:0x02,BYTE3:0x03,则
版本号为V1.2.3。
若充电机协商结果为“协商成功”,值为双方协商
一致的版本号。
若充电机协商结果为“继续协商”,值为充电机期
望的版本号。
若充电机协商结果为“协商失败”,值
为0xFFFFFF
4 控制导引版本1字节BYTE CPVersionType
充电机控制导引版本:
0x01:GB/T18487.5 中旧版本充电机控制导引
电路;
0x02:GB/T18487.5。
接收方不以该值判定协商结果
5 传输层版本1字节BYTE TLVersionType
充电机传输层版本:
0x01:第8章;
0xFF:其他。
接收方不以该值判定协商结果,高版本兼容低
版本
6 预留1字节BYTE ReservedType 接收方不判断该值,默认填充0xFF
6
GB/T27930.2—2024
表7 车辆版本协商数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 CAN类型1字节BYTE CANType
车辆CAN类型:
0x00:CAN2.0B;
0x01:CANFD;
0x02:CANXL。
当前版本采用CAN2.0B通信。接收方不以该值
判定协商结果,高版本兼容低版本
2 协商结果1字节BYTE VersionResultType
车辆版本协商结果:
0x00:继续协商;
0x01:协商成功;
0x02:协商失败
3 协议版本号3字节BYTE[3] ProtocolVersionType
车辆期望或协商一致的版本号。
BYTE1:主版本号;
BYTE2:次版本号;
BYTE3:临时版本号。
如:BYTE1:0x01,BYTE2:0x02,BYTE3:0x03,则
版本号为V1.2.3。
若车辆协商结果为“协商成功”,值为双方协商一
致的版本号。
若车辆协商结果为“继续协商”,值为车辆期望的
版本号。
若车辆协商结果为“协商失败”,值为0xFFFFFF
4 控制导引版本1字节BYTE CPVersionType
车辆控制导引版本:
0x01:GB/T18487.5 中旧版本车辆控制导引
电路;
0x02:GB/T18487.5。
接收方不以该值判定协商结果
5 传输层版本1字节BYTE TLVersionType
车辆传输层版本:
0x01:第8章;
0xFF:其他。
接收方不以该值判定协商结果,高版本兼容低
版本
6 预留1字节BYTE ReservedType 接收方不判断该值,默认填充0xFF
7.2.3 报文交互过程
7.2.3.1 物理连接完成或车桩被唤醒后1s内(不包括预约到时唤醒),充电机和车辆分别向对方发送
其支持的最高协议版本号和“继续协商”状态,接收并检查自身支持的协议版本号返回版本协商结果。
若为“继续协商”,则继续以较低的协议版本号进行协商;若为“协商成功”且协议版本不低于V2.0.0,则
按照协商一致的版本的通信协议进行信息交互;若为“协商失败”、超时或“协商成功”且协议版本为
V1.1.0,则按附录M 通信。
7.2.3.2 版本协商的完整状态转换过程应符合表8和表9的规定,报文交互流程示意见图2。
7
GB/T27930.2—2024
!!!"#$%&'()*+,!
!"#
$%&'
()*+,- !"./
+0!123456"
+0!56-7"
348
9:
349
:;<
#"$"$%
349
:;"
#&$%$%
+0!5
6=>"
+0!?@56"
ABC
D34
E
34F
G12
34HG12
AIFD
34E
JIFD
34E
!"#K
LMNO
!"P1
2QR'&
!()*%
./
ST
'%
UVW
%X!!"#3456#
?@56#5Y34E
+,-./0*$10%"&Z R
!"&!()*% [ / \&]
^'"
' ' ' ' ' ' ' ' ' ' '
'"
56N
'
%X!!"#3
456"&5Y3
4 E + ,-./0*
$10%_ `&a
b'"
56c
d +
!? @
56"&
ab'"
56c
d +
!5 6
-7"&
]^'&
56c
d +
!5 6
-7"&
]^'2
]^'3
56c
d +
!5 6
-7"&
10 e
fg3
4&a
b'"
ab'"
hi12!j
k34E"l
mno 10e
fFG12j
k34NpH
D 3 4&a
b'"
]^'3 ]^'4 ]^'3
'&
qr 5
56-7
%X!56-7"&st!"(!()*%&]uqr 5 vl
'2
-7
%X!56-7"&st!"(!()*%&]^7w56
'3
56=>
%X!56=>"&st!"(!()*%&]uqr 5 vl
'4
xy!"
czvl&xy!"{|
8
GB/T27930.2—2024
!!!"#$%&'()*+,! !!"
"#$
%&'(
)*+,-. !"/0
,1#234567$
,1#67.8$
459
:;
45:
;<=
#"$"$%
45:
;<"
#&$%$%
,1#6
7>?$
,1#@!67$
ABC
D45
E
45F
G23
45HG23
AIFD
45E
JIFD
45E
"#$K
LMNO
"#P2
3QR'&
!()*%
/0
!STUV%
!""!!()*%=4567WXY0Z0[&\"#$]^&_4567`a0Rb!()*%Z0[&Y00c="%+'
!&"!!"="#$&_#"#$4567$Z0[&"#$&_,-./+*!0+"de`afgh!"Z0[&ij=1%2+'
!3"!,-./+*="#$klD6m45de&45Eno/pqe&0+=45Ers&tuvwxyH45E'
!4"!#($z{"#$9|}~*
!"!"#$%-.)*+,!
"#$
%&'(
)*+,-. !"/0
,1#"#$4567$
,1#67.8$
459
:;
45:
;<=
#"$"$%
45:
;<"
#&$%$%
,1#6
7>?$
,1#@!67$
ABC
D45
E
45F
G23
45HG23
AIFD
45E
JIFD
45E
,1
,56),76
23KL
MNO"
#P"#
$QR'"
!()*%
/0
€

'%
tu‚
&_#23456
7*@!67*6m
4 5 E 8 9-./+*
!0+"$&ƒ R !"+
!()*% Z 0 [&„
…'"
( ( ( ( ( ( ( ( ( „…'4 ( (
9
GB/T27930.2—2024
!!!"#$%&'()*+! !!"
"#$
%&'(
)*+,-. !"/0
,1#"#$2345$
,1#45.6$
237
89
238
9:;
#"$"$%
238
9:"
#&$%$%
,1#4
5<=$
,1#>!45$
?@A
B23
C
23D
EFG
23HEFG
?IDB
23C
JIDB
23C
,1
'()%'*)
FGKL
MNO"
#P"#
$QR+"
!,-.%
/0
S
T
+"
45N
&
&U#FG2
345$'4V
2 3 C /
01234.!54"W
X'YZ+"
45[
\/#>
!4
5$'Y
Z+"
45[
\/#4
5.
6$']
^+&
45[
\/#4
5.
6$']
^+6
]^+7
45[
\/#4
5.
6$'54
_`a
23'Y
Z+"
YZ+"
bc"#$
#de23C$
fghi 54
_`DE"
#$de2
3NjHB
23'YZ+"
]^+7 ]^+7 ]^+8
]^
+7
+&
kl )
45.6
&U#45.6$'mn!"(!,-.%']okl ) pf
+6
.6
Z!&U#45.6$']^6q45rs'mn!,-.%'1/#"#$tZ6q$umn!"
+7
45<=
&U#45<=$'mn!"(!,-.%']okl ) pf
+8
vw"#
[xpf'vw"#yz
!{|}~)
!""!!,-.%;23450€0'‚FGƒ„&U2345WX0R…!,-.%€0'00†;"%4*
!&"!!";FG&U#FG2345$€0')*+,u…‡!"€0'FG&U01234.ˆ‰WXuŠ‹'Œd8%94*
!6"!01234.;FGtZB4V23ˆ‰'23CŽ/‰'54;23C‘’'“”•_`jH23C*
!7"!#&$–—FG7˜™š›*
10
GB/T27930.2—2024
注:虚线框内容见功能协商阶段判断。
图2 版本协商交互流程示意图
8 传输层
8.1 通则
8.1.1 传输层负责数据传输、流量控制、分组传输与接收帧顺序检查等。
8.1.2 传输层消息类型包括不需要确认的短消息、需要确认的短消息和长消息,具体为:
———不需要确认的短消息:消息长度不大于8字节,面向简单不可靠信息的传输服务;
11
GB/T27930.2—2024
———需要确认的短消息:消息长度不大于8字节,由传输层为上层应用提供可靠性传输服务,包括
流量控制和传输结果上报;
———长消息:消息长度大于8字节,由传输层为上层应用提供可靠性传输服务,包括流量控制、分组
传输、接收帧顺序检查、传输结果上报。
8.1.3 接收方应忽略非本文件定义的消息,除非另有规定。
8.2 不需要确认的短消息
不需要确认的短消息(SM_URM)无需接收方应答确认,其信息帧格式应符合表10的规定。
注1:上层应用中周期发送的报文通常为不需要确认的短消息。
注2:若采用轮询方式接收报文,可能出现同种消息类型报文不能全部接收的异常情况。
表10 不需要确认的短消息的信息帧定义
协议数据单元P EDP DP PF PS SA 数据域
占位
bit 3 1 1 8 8 8 8 8 8 8 8 8 8 8
定义0x06 0 0 0x36 目的地址源地址符合应用层规定,不足8字节的填充0xFF
8.3 需要确认的短消息
需要确认的短消息(SM_RM)要求接收方应答确认。若发送方没有接收到确认信息,发送方应进
一步尝试,重发的时间间隔为50ms,直至达到应用层总发送时间。需要确认的短消息的信息帧格式应
符合表11的规定,控制帧(应答确认)格式定义应符合表12的规定。
注:多条需要确认的短消息同时发送时,通过控制帧中的被确认短消息参数组标识来识别控制帧与需要确认的短
消息的对应关系。
表11 需要确认的短消息的信息帧格式
协议数据单元P EDP DP PF PS SA 数据域
占位
bit 3 1 1 8 8 8 8 8 8 8 8 8 8 8
定义0x04 0 0 0x35 目的地址源地址符合应用层规定,不足8字节的填充0xFF
表12 需要确认的短消息的控制帧(应答确认)格式
协议数据单元P EDP DP PF PS SA 数据域
占位
bit 3 1 1 8 8 8 8 8 8 8 8 8 8 8
定义0x03 0 0 0x37 目的地址源地址0x000x01
被确认短消
息参数组
标识(应用
层首字节)
0xFF0xFF0xFF0xFF 0xFF
8.4 长消息
8.4.1 长消息(LM)的传输应符合8.5规定的多信息帧传输方式,其信息帧格式定义应符合表13
12
GB/T27930.2—2024
的规定。
表13 长消息的信息帧格式
协议数据单元P EDP DP PF PS SA 数据域
占位
bit 3 1 1 8 8 8 8 8 8 8 8 8 8 8
定义0x06 0 0 0x34 目的地址源地址
帧序号:0 总帧数总字节数0xFF0xFF0xFF0xFF
帧序号:>0 应用层参数组,最后一帧
不足8字节的,填充0xFF
LM(0)表示帧序号为0的长消息信息帧;LM(i)表示帧序号为i(i>0)的长消息信息帧。
总帧数为包括应用层参数组在内传输的所有帧数,不包括LM(0)。
总字节数为长消息应用层参数组长度,不含帧序号,不含最后一帧不足8字节填充的0xFF。应采用小端模式来传
递总字节数
8.4.2 长消息(LM)的控制帧用于差错控制和流量控制,包括长消息应答确认(LM_ACK)、长消息放弃
连接确认(LM_NACK)和长消息接收结束确认(LM_EndofACK)。其中,LM_ACK、LM_EndofACK
是接收方对发送方的确认响应,LM_NACK是接收方或发送方发送给对方的放弃连接确认。长消息的
控制帧格式定义应符合表14的规定。
表14 长消息的控制帧格式
协议数
据单元P EDP DP PF PS SA 数据域
占位
bit 3 1 1 8 8 8 8 8 8 8 8 8 8 8
定义0x03 0 0 0x37 目的
地址
源地
址
LM_ACK:1 待接收起
始帧序号
待接收
总帧数0xFF0xFF0xFF0xFF0xFF
LM_NACK:2 0xFF 0xFF 0xFF0xFF0xFF0xFF0xFF
LM_EndofACK:
3
接收的
总帧数
接收的总字节数0xFF0xFF0xFF0xFF
LM_ACK(n,k)表示待接收起始帧序号为n,待接收总帧数为k 的长消息应答确认控制帧。
k 为能接收的信息帧的帧数(取接收能力和剩余发送帧的二者较小值)
8.5 多信息帧传输方式
8.5.1 功能分类
长消息传输控制的主要功能为分包重组和连接管理。
8.5.2 分包重组
8.5.2.1 重组方式
发送方首先将长消息拆分为多个信息帧,在建立连接后按序进行传输。接收方接收到所有的信息
13
GB/T27930.2—2024
帧数据后再重组成原始信息。
8.5.2.2 信息帧
每个信息帧应能被识别和重组,信息帧数据域的首字节定义为信息帧的帧序号,序号范围为1~
255(序号为0的信息帧仅用于建立连接),信息帧应从编号1开始按序进行发送,最长的数据长度是1
785字节。当发送方请求建立长消息传输的虚拟连接时,首先发送帧序号为0的信息帧,在收到接收方
应答确认后,按要求发送信息帧。
每个信息帧(除了最后1个信息帧和用于建立连接帧序号为0的信息帧)都装载着应用层数据的7
个字节,最后1个信息帧的数据域的8个字节包含:信息帧的序号和至少1个字节的应用层数据,未使
用的字节全部设置为0xFF。
8.5.2.3 帧序号
传输层在拆装时给信息帧分配帧序号,接收方接收后,利用帧序号把信息帧重组回原始信息。信息
帧从编号为1的信息帧开始按编号递增顺序发送。序号为0的信息帧不含应用层数据,仅用于建立虚
拟连接。
8.5.2.4 数据传输
信息帧之间的发送间隔时间(LMS_T1)应不小于5ms且不大于10ms。同一时间只允许建立一
个虚拟连接,即只有当发送方或接收方发送长消息放弃连接确认或接收方发送长消息接收结束确认,才
能建立新的虚拟连接。
注1:在通信过程中,为了传送长消息,在两个节点间建立的临时连接,即虚拟连接。
注2:同一时间建立一个以上的虚拟连接时,无法区分帧序号相同的不同长消息的信息帧。
8.5.2.5 信息帧重组
接收方完成所有信息帧接收后,应按照帧序号从小到大将其重组回原始信息。
8.5.3 连接管理
8.5.3.1 概述
连接管理包括虚拟连接的建立、使用和关闭。
8.5.3.2 总体要求
8.5.3.2.1 虚拟连接建立前,收发双方应确认记录帧序号的计数器为0,其中发送方计数器用于记录下
次要发送的帧序号,接收方计数器用于记录下次要接收的起始帧序号。
8.5.3.2.2 发送方发送帧序号为0的信息帧作为连接建立的请求,接收方应答确认后,连接建立。
8.5.3.2.3 连接建立后,发送方按照接收方的应答确认发送信息帧,发送结束后等待接收方的下一个应
答确认。
8.5.3.2.4 发送方、接收方不支持同时建立两个及以上的虚拟连接。
8.5.3.2.5 发送方发生传输异常(如连续出现3次同类型的连接超时),应返回“发送失败”信息至应
用层。
8.5.3.3 连接的建立
8.5.3.3.1 发送方请求发送长消息时,信息帧帧序号为0,且包含长消息的总帧数和总字节数。
8.5.3.3.2 接收方接收到帧序号为0的长消息后,可选择接收或者拒绝建立连接。若选择接收,应发送
14
GB/T27930.2—2024
长消息应答确认帧LM_ACK,且LM_ACK 中应包含接收方待接收的起始帧序号、待接收总帧数。连
接建立后,接收方应从序号为1的信息帧开始接收。
8.5.3.3.3 若发送方接收到LM_ACK,连接建立完成。
8.5.3.3.4 若接收方缺少资源或存储空间,可拒绝建立连接,此时应发送放弃连接确认LM_NACK,连
接建立失败。
8.5.3.4 数据传输
发送方接收到LM_ACK后开始数据传输。接收方负责调整节点之间的数据流控制,若接收方需
要暂停数据流,应重复发送LM_ACK将待接收总帧数置为1,待接收起始帧序号置为已接收的最后一
帧的帧序号,发送方重复发送此帧内容(即接收方重复接收上一组最后一帧报文),接收方收到该报文后
不做处理。当接收方恢复数据流时,则将LM_ACK 中“待接收起始序号”置为前一次接收到的下一帧
帧序号,按照自身接收和处理能力重置“待接收总帧数”,直至完成所有信息帧的接收。
8.5.3.5 连接的关闭
8.5.3.5.1 在传输没有错误的情况下,当接收到所有信息帧后,接收方应发送消息结束确认LM_EndofACK,
通知发送方连接关闭。
8.5.3.5.2 长消息传输过程中,发送方或接收方可在任何时候使用LM_NACK 终止连接。若接收方没
有可用资源处理消息,可通过发送LM_NACK放弃连接。当发送或接收到LM_NACK时,所有已传送
信息帧应被丢弃。
8.5.3.5.3 长消息的连接关闭,应包括以下方面。
a) 发送方在以下情况下,可认为连接被关闭:
1) 完成整个长消息的数据传输且接收到LM_EndofACK;
2) 发送LM_NACK(如发送方希望提早停止通信、超时等);
3) 接收LM_NACK。
b) 接收方在以下情况下,可认为连接被关闭:
1) 完成整个长消息的数据传输后发送了LM_EndofACK;
2) 发送LM_NACK(如接收方缺少资源或存储空间);
3) 接收LM_NACK。
注:发送方或接收方发生传输故障(如连续出现3次同类型的连接超时)会导致连接关闭。
8.5.3.6 连接的超时
8.5.3.6.1 接收方接收到一个信息帧后,若接收信息帧或控制帧超时定时器(LMS_T2)时间内未接收
到下一个信息帧即为超时,超时后发送LM_ACK 通知发送方重发,连续出现3次超时后发送LM_
NACK放弃连接。
8.5.3.6.2 接收方发送LM_ACK后,若LMS_T2时间内未接收到正确帧序号的信息帧即为超时,超时
后发送LM_ACK通知发送方重发,连续出现3次超时后发送LM_NACK放弃连接。
8.5.3.6.3 接收方接收到帧序号为0的信息帧后,接收整个长消息的时间大于长消息传输定时器
(LMS_T3)即为超时,超时后发送LM_NACK放弃连接。
8.5.3.6.4 发送方发送帧序号为0的信息帧后,若LMS_T2时间内未接收到接收方的确认消息即为超
时,超时后重发帧序号为0的信息帧,连续出现3次超时后发送LM_NACK放弃连接。
8.5.3.6.5 发送方发送完成本次需要传输的全部信息帧后,若LMS_T2时间内未接收到接收方的确认
消息(LM_ACK 或LM_EndofACK)即为超时,超时后发送方重发本次传输的最后一帧,连续出现3次
超时后发送LM_NACK放弃连接。
15
GB/T27930.2—2024
8.5.3.6.6 发送方从发送帧序号为0的信息帧后,传输整个长消息的时间大于LMS_T3即为超时,超时
后发送LM_NACK放弃连接。
8.5.3.6.7 LMS_T2应为100ms,LMS_T3应为10000ms,若应用层未规定总发送时间,长消息应在
LMS_T3时间内传输完成,否则以应用层规定为准。
8.5.3.6.8 长消息发送的完整状态转换过程应符合表15和表16的规定,报文交互流程示意见图3。
16
GB/T27930.2—2024
!!"!"#$%&'(!
!"#
$!%&
'(!")
*+,-.
'(/0 !"12!"#!$%34(
5'/064
!"#!$&34(
!"!'()"!#"$ !"!
*'()
!"!
+,-./
'()
78!"9:5'
#;<,=>?9
/0@)*+AB
"CD01,-!2,3"
"4%@!501,-!2,3
"67!3/89
78!"9E5'
#;<,=>?9
@)*+AB"C
D01,-!2,3#"4%
@!501,-!2,3"
67!3/89
78!"9
E)*+=
>?9FG
!"CD
!501,-!2,3
#67!3/89
188!2,3"& 188!2,3#&
HIBJ6
4!"#!$:
34(FK
LMNBJ
O
P
#;
QR
!" !"";$#
188!2,3<;#S
T !"#!$&%
!"#!$:#U
V#%
& & & & & & & & &
#%
W5XY
&
Z["#188!2,3\]#
01,-!2,3\ ]#!"#!
$%S T#!"#!$& ^
_#UV#&
UV#= & & & &
188!2,3 `
%#!" !"
";$#a b
!"#! $&#
Zc#%
!" !"
!*'()#
UV#=
! " !" !
*'()# U
V#=
#&
HIBJ
&
Z["#dIefgh
!" !" ,ijkE!
"l!"/0$#188!2,3
\]#01,-!2,3\ ]#
!"#!$% S T#!"#!
$&^_#Zc#&
UV#= &
!" !""!501,-
!2,3$#01,-!2,3`
%#!"#!$%ab#
Zc#&
!" !""!501,-
!2,3$#01,-!2,3`
%#!"#!$%^_#
!"#!$&ST#U
V#:
! " !"
"67!3/89$#
01,-!2,3`
%#!"#!$%
^_#!"#!
$&ST#U
V#>
& &
! " !" !
*'()# U
V#=
17
GB/T27930.2—2024
!!"!"#$%&'(! !!"
"#$
%"&'
()"#*
+,-./
()01 "#23!"##$%45)
6(0175
!"##$&45)
!"#'()!!$"" !"#
*'()
!"#
+,-./
'()
89"#:;6(
$<=->?@:
01A*+,BC
#DE01,-#2,3"
"4%A!501,-#2,3
"67#3/89
89"#:F6(
$<=->?@:
A*+,BC#D
E01,-#2,3#"4%
A!501,-#2,3"
67#3/89
89"#:
F*+,>
?@:GH
"#DE
!501,-#2,3
#67#3/89
188#2,3"& 188#2,3#&
IJCK7
5!"##$:
45)GL
MNOCK
P
Q
#:
RST
UVW
%
XY"$ZJTU[\
"#!" -]^_F!
!`"#01"$188#2,3
ab$01,-#2,3a b$
!"##$% c d$!"##
$&ef$gh#&
gh#; % % % %
188#2,3 i
%$"# !"
!! 5" 4
%"$ X j
#:$ k l
!"##$&
"# !"
#*'()$
gh#;
" # !" #
*'()$ g
h#;
#<
RSm
nVW
%
ZJTU[\"# !"
-]^_F!!`"#
01"$188#2,3a b$
01,-#2,3a b$!"##
$%c d$!"##$& e
f$gh#&
gh#; gh#; % % %
188#2,3 i
%$"# !"
!67#3/89"$
Xj#<$k
l!"##$&
"# !"
#*'()$
gh#;
" # !" #
*'()$ g
h#;
#;
o6ef
ef!"##$%&!"##$&&!"##$:p5q$188#2,3&01,-#2,3ab$ghrsPQ
!tN'
!%"!188#2,3F6(754I(
!&"!01,-#2,3F@uCKN"#:I4Iq$vwxF=$y"#Dz@:$4Iqi%(
!:"!!"##$%F@uCKN{,:|^"#5}}~$;70$!"##$%$%=70$y{,:"#?kl(
!<"!!"##$&F6({,:G€:7545q$755}F%==70(
!;"!!"##$:F*+,CK45q$"#‚:!"!="01cd$ƒW%=0$„T…†p‡01ˆ"#5}$‰ŠT…†p‡F‹(
!>"!67#3/89F*+,"#ˆ:I
18
GB/T27930.2—2024
!!"!"#$%&'(!
!"#
$%&'
"()*!"!#"
!"!!"
+,-.
!"/
$%&'#()$*
+,-#()$*
!"012345
!"6789:;0!+
$%&'#./01<$%&'#.2-""31
"(=>
)*!#
$%&'#./01
?")*
!$$%&'#./
01<
$%&'#()$*
#,-#()$*
!"+,-
9:;0
$%&'#()$*01
+,-#()$*
@+,-9
:;0
$%&'#()$*01
#,-#()$*
A!"/
!+$%&'#./0
1<$%&'#.2-
#"31<
$%&'#()$*01
#,-#()$*
!"#4
567
!")*BC
!"8#9:DC(
%$$#&.(
#:
%$$#&.(
":
EF!"
GHI
JBC
!"8#9;
DC(
KLM
NOIJ
P
Q
8#
RS
TU,-#()$*$% V
!"#567!1$""$W
X !"8#9:%!"8#
9;$$%&'#./ Y Z$
$%&'#.2- YZ$$%&'
#()$*YZ$%$$#&.(Y
Z$[\81
& & & & & & & & & & &
81
!"
GH
TU,-#()$*$% V
!"#567!1$""$=
]!"8#9:$$%&'#./
Y Z$$%&'#.2- Y
Z$$%&'#()$*YZ$T
^81
$%&'#()$*
]_,-#
()$*$%V
!"#<.=>
/)567$
[\8:
&
%V !"#
567!$%&'
#./01$
""$$%&'#
.2-YZ$
T^81
$%&'#()$*]_
,-#()$*$%V
!" # <.=>
/)567$[\
8:
= ] !"8#
9:$%$$#&.(Y
#$$%&'#./]
_!$%V!"
#567!!01$
""$$%&'#.2-
Y Z$$%&' #
()$* ` 1$T
^81
=] !"8#
9:$%$$#&.(
Y #$$%&'#
./] _!$
$%&' # .2-
` 1$$%&'#
()$*`1$T
^81
[\8:
=]!"8
#9:$%$$#
&.(` 1$
%V!"#
567!$%&'
#./01$
" "$ T
^81
% V
!" #
4567$
[\8:
=]!"8
#9:$%$$#
&.(Y #$
%V!"#
567!$%&'
#./$1"$
T^81
%V!"
#4567$
[\8:
8:
4!
ab
4!ab$cdDGe!$%&'#./$$%&'#.2-$%$$#&.("YZ$cdfCe!!"8#9:$!"8#9;"ab
19
GB/T27930.2—2024
!!"!"#$%&'(! !!"
"#$
%&'(
#)*+!"!#"
!"!!"
,-./
"#0
$%&'#()$*
+,-#()$*
"#12345!
"#6789:;1!+
$%&'#./01<$%&'#.2-""31
#)=>
*+!#
$%&'#./01
?#*+
!$$%&'#./
01<
$%&'#()$*
#,-#()$*
"#,-.
9:;1
$%&'#()$*01
+,-#()$*
@,-.9
:;1
$%&'#()$*01
#,-#()$*
A"#0
!+$%&'#./0
1<$%&'#.2-
#"31<
$%&'#()$*01
#,-#()$*
!"#4
567
"#*+BC
!"8#9:DC)
%$$#&.(
#:
%$$#&.(
":
EF"#
GHI
JBC
!"8#9;
DC)
KLM
NOIJ
!PN$
!1"!%$$#&.(Q"#BCDG%
!:"!$%&'#./Q"#R.113%
!;"!$%&'#.2-QST67"#UVR.11G%
!<"!$%&'#()$*QST5""#W8UVR.11G%
!="!!"8#9:Q"#R.1KXY1BCDCZ&BCC[Q1##->%
!?"!!"8#9;Q,-.IJDCZ&"#\1!"!#"*+]^&_`1#>&abcdef*+W&gC[&hibcdefQj%
!@"!,-#()$*Q,-.klbcd8W1G
20
GB/T27930.2—2024
注:SntCnt、RcvCnt分别为发送方计数器和接收方计数器。
图3 长消息交互示例
9 应用层
9.1 总体要求
9.1.1 应用层报文应采用参数组标识(PGI)对参数组进行编号,各节点根据PGI识别报文内容。
21
GB/T27930.2—2024
9.1.2 通信双方应按实际数据发送报文,除非另有规定。
9.1.3 接收方接收到非本文件定义的报文、本文件未规定的参数值或参数值超出本文件规定数据范围
时,应忽略该信息,除非另有规定。
9.1.4 接收方接收到的参数值为本文件定义的“预留”值或“无效”值时,应不处理该参数。
9.1.5 传输的数据类型应符合表17的规定,应采用小端模式传递数字信息。
9.1.6 各功能模块状态转换表中发送“报文名称_报文内容”报文为应用层发送至传输层,应用层状态
跳转可不依赖于传输层是否收到接收方控制应答。成功发送“报文名称_报文内容”报文为应用层发送
报文至传输层并接收到接收方控制应答报文。除非另有规定。
9.1.7 应用层接收到传输层传输失败,应按附录K故障停机退出。应用层接收到数据链路层或传输层
超时,未触发应用层报文或功能模块超时时,可再次尝试发送,若应用层超时,应按附录K 故障停机
退出。
9.1.8 功能模块交互流程示意图仅用于对业务流程的理解,未体现阶段超时或交互双方在本功能模块
主业务,没有表述需要中止充电或响应对方中止充电的情况。
9.1.9 各功能模块状态表表头中的接收“阶段请求”、接收“车辆确认结果”触发条件仅表示进入阶段确
认子流程,阶段确认子流程应按9.3.1。
9.1.10 参数类型应符合表L.1的规定。
表17 数据类型
数据类型描述及要求
BYTE 无符号单字节整型(字节,8位)
WORD 无符号双字节整型(字,16位)
DWORD 无符号四字节整型(双字,32位)
BYTE[n] n 字节
STRING 若无数据则放一个0终止符,编码应符合GB/T1988;含汉字时,编码应符合GB18030
9.2 通信过程
9.2.1 充电通信过程由多个功能模块按序组成,各功能模块对应的功能代码(FC)应符合表18的规定。
一个完整的充电通信过程应包括所有必需项功能模块以及零个或多个可选项功能模块。功能模块类型
及其通信过程应符合图4的规定。
9.2.2 除功能协商外,其他功能模块都可进行重载以实现不同的应用,各功能模块的不同应用通过功
能描述码(FDC)区分,每个可重载功能模块(可重新定义和替换的功能模块)支持的FDC上限为8个。
不可重载的功能模块FDC固定为0x01。
注:功能协商功能模块FDC 定义为不可重载。功能协商的内容未来发生变化时,通信协议的主版本号将进行
变更。
9.2.3 通信过程中,应保证信息交互的同步性。在完成功能模块的信息交互后,如需进入下一阶段,应
首先按9.3.1的要求进行阶段确认,保证进入下一功能的通信信息在FC及FDC上的一致性,除非另有
规定。
22
GB/T27930.2—2024
表18 组成充电通信过程的功能模块
功能模块名称
功能代码
(FC) 描述功能模块类型a
是否
可重载
功能协商0x10 本次充电所实现的相关功能的交互和确认必需项否
参数配置0x20 基本充/放电参数的交互必需项是
鉴权0x30 车辆和/或充电机身份交互和确认可选项是
预约0x40 启动输出回路检测功能模块时间点的交互和确认可选项是
输出回路检测0x50 实现充电机的绝缘检测(包括泄放)、短路检测、粘连检测
等功能
必需项是
供电模式0x60 充电机在充电前应车辆要求,提供指定的供电方式,多用
于动力蓄电池(即可充电储能系统)加热等功能
可选项是
预充及能量传输0x70
包括预充和能量传输两个过程,预充是充电机为避免对
动力蓄电池等车内组件造成电能冲击在能量传输前所执
行的相关操作,能量传输包括启动至结束充电和/或放电
的全过程
必需项是
结束0x80 完成能量传输后所执行的相关操作,如车辆接触器粘连
检测、充电过程统计等相关信息的交互
必需项是
a 必需项和可选项功能模块信息在充电流程的功能协商阶段应交互。某一可选项功能模块在特定应用场景中可
能成为必需项。如鉴权是非限制场所使用的充电机的必需项,车辆应在该充电流程中选择进行鉴权模块,否则
将导致充电失败。
图4 功能模块类型
9.2.4 通信过程中,充电机判断需要发送中止报文,根据表L.4的中止原因成功发送中止报文后通过
阶段确认请求报文进入结束阶段。充电机收到车辆中止报文(不包含充电机主动中止)或开关S2断
开,成功发送“中止_车辆主动中止”报文后通过阶段确认请求报文进入结束阶段。
9.2.5 通信过程中,车辆判断需要发送中止报文,根据表L.4的中止原因发送中止报文并通过阶段确
认请求报文进入结束阶段。车辆收到充电机中止报文(不包含车辆主动中止)或开关S1断开,发送“中
止_充电机主动中止”报文,通过阶段确认请求报文进入结束阶段。
23
GB/T27930.2—2024
9.2.6 中止过程中,充电机和车辆应根据表L.4确认中止退出方式,对应的退出方式按附录K 和
GB/T18487.5进行。中止过程发生不低于现中止退出方式优先级的故障,应更新中止原因后重发中止
报文,双方根据优先级最高的方式进行退出。
9.2.7 发起或等待阶段确认请求进入结束阶段前,充电机和车辆应关闭除阶段超时定时器以外已开启
的本功能模块报文发送和/或超时定时器,在退出当前阶段前应关闭阶段超时定时器。
9.3 公共报文
9.3.1 阶段确认
在进入可重载功能模块前,充电机与车辆应在上一阶段结束时,根据功能协商结果确认即将进入的
FC和FDC同预期保持一致。充电机首先发送下一个需要执行的功能模块的对应FDC,若车辆返回阶
段确认成功信息,双方进入下一个FDC的执行;若车辆返回阶段确认失败信息,双方退出充电过程。
阶段确认过程是充电机和车辆信息交互同步的基础,其报文定义和信息交互过程应固定不变。阶
段确认报文信息类型应符合表19的规定,报文数据格式与内容应分别符合表20和表21的规定。阶段
确认的完整状态转换应符合表22和表23的规定。
表19 阶段确认报文
参数组标识报文描述信息类型周期时间总发送时间/ms 源地址-目的地址
0x01 阶段请求需要确认的短消息— 1000 充电机-车辆
0x02 车辆确认结果需要确认的短消息— 1000 车辆-充电机
表20 阶段请求报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x01
2 阶段信息2字节WORD PhaseType
即将进入功能模块的FC及FDC:
BYTE1:功能代码(FC),定义按表18;
BYTE2:功能描述码(FDC),定义按L.3;
FDC:数据分辨率:1/位;0偏移量;数据范围1~8
表21 车辆确认结果报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x02
2 阶段确认1字节BYTE PhaseACKType
车辆确认信息:
0x00:确认失败(FC或FDC不一致);
0xAA:确认成功(FC或FDC一致)
24
GB/T27930.2—2024
!!!!"#$%&'()*+,!
!"#
$%&'
()*+,-
./!01,-23"
./!0145"6
78!"97
:;<=>?*+@A##$%&'BA
*+,-4!"#CDEF
%G45HI
,-
J<
,-KL
M()N
2O*+
M()
2O*+
/!45$
!"#PQ
45"6M
R()2O
ST M()N2O*+ M()2O*+
M()N
2O*+
M()2O
*+UVW
XYZ[\
]^_:;
VWXY
ST
`
a
!'
bc
d
%Gef()
< = > ? g
!*+hi"%
9 7 #$%&'%
()!(
& & & & & & & & & &
!(
jk
,-
&
()
!"
J<%G!4
5$*+,-
KL"l%mn
#$%&'%% G
2 O > ? g
!*+hi"o
pq!(
% G !4
5 $ * +
, - K
L "% (
)!)
pq!(
J<%G!4
5$01PQ
4 5"'m n
#$%&'%% G
2 O > ? g
!*+hi"o
pq!(
J<%G!45$*+
@ A (: ; * + @
A)"#!45$01,
- 2 3 H I @ A
(#$%&'@A)"l%m
n #$%&'%% G 2 O
>?g!*+hi"o
pq!(
%G!45$*+
@A(:;*+
@A)"#!45$
01,-23H
I @ A (#$%&'
@A)"%()!)
J<%G4
5 H I l%
mn #$%&'%
%G2O>
?g !* +
hi"o p
q!(
%G45H
I%pq!(
pq
!(
!"J< 8r#$%&'%()st<=>?
!)KL 8r#$%&'%u.B6%Wg45HI4VWXYZ[\vwXYxJVW%y5HIz{(|}~€()2O%]t‚ƒ„y#Q…A†)
!S4*
!()!#$%&'‡!"#ˆ*+,-@A‰AŠ%R!"#%G‹*+g!*+hi"l7Œ%@AA†‡(*':;<=>?*+@A‰AŠ7Œ%Ž:;*+@A‰
AŠ%6‘8r:;<=>?*+@A‰AŠ%Ž*+,-g*+@A‰AŠ+
!")!!&"’“!"#]…”•–—
25
GB/T27930.2—2024
!!"!"#$%&'()*+!
!"
#$%&
'()
*+,
-./01!)*23"
-.!/0145"6
78!"97
:;<=>?)*@A##$%&'BA !"CDEF$G45HI
JKL/
01$G
M()6
(*)
()6(*)
JNO
()$(*)
PNO
-.B!4
5%!"QR
45"6ST
'(UV
WX
S'(Y
UV)*
S'(
UV)*
S'(Y
UV)*
S'(UV
)*Z[\
]^_`a
Jbc:;
[\]^
WX
d
e
!'
fgh
97#$%&'&
'(!"
' ' ' ' ' ' ' ' ' '
!"
ij
+,
'
$ G !!
"+,U
k % + ,
lm"&n
L!"
o p q r () 6
(*)&s<t$g
!!"+,Uk%+
,s<"'( !+&
ut$G!!"+
,Uk%+,lm"
nL!"
$ G !!
"+,U
k % + ,
s<"&'
(!+
nL!"
$G!45%
/01QR
4 5"(o
v #$%&'&
ij-.U
V > ? M
!)*23"
wnL!"
$G!45%)*@
A ): ; ) * @
A*"#!45%)*
2 3 H I @ A
)#$%&'@A*"&o
v #$%&'&i j -
.UV>?M!)
*23"wnL!"
$G!45%)*
@A):;)*
@A*"#!45%
)*23HI@
A)#$%&'@A*"&
'(!,
$G45H
I& o v
#$%&'& i
j-.UV
>?M !)
*23"&n
L!"
$G45H
I&nL!"
nL
!"
!+s< 8x#$%&'&+,s<&'()*yz{|M<=>?)()-(*)*
!,lm 8x#$%&'&}-B6$\M45HI4[\]^_`a~]^€s[\&5HI‚ƒ
!W4+
!"*!#$%&'„!"…)*+,@AqA†&T!"+,'()*+,A7‡&@AAˆ„".&‰:;<=>?)*@AqA†7‡&tŠ‹:;)*@AqA†&6Œ8
x:;<=>?)*@AqA†&tŠ‹)*+,M)*@AqA†,
!+*!!'"|!"JŽ‘’,
!,*!opqr“!"T.B)*23HI4()”(*)•!"<=–—+,UkHI4MUkJ˜A&!"opCD™uš'()*23HI4M()”(*)
26
GB/T27930.2—2024
9.3.2 中止报文
在充电过程中若需要退出通信流程,应发送中止报文提供中止原因,其报文定义和信息交互过程固
定不变。中止报文信息类型应符合表24的规定,报文数据格式与内容应符合表25和表26的规定。
表24 中止报文
参数组标识报文描述信息类型周期时间总发送时间/ms 源地址-目的地址
0x03 充电机中止需要确认的短消息— 1000 充电机-车辆
0x04 车辆中止需要确认的短消息— 1000 车辆-充电机
表25 充电机中止报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x03
2 充电机中止类型1字节BYTE EndCodeType 充电机中止类型按表L.4
3 充电机中止原因2字节BYTE[2] EndReasonType 充电机中止原因按表L.4
4 请求重连1字节BYTE RepeatType
请求进行重连充电(不影响重新启动):
0x00:不请求重连充电;
0xAA:请求重连充电;
0xFF:无效(车辆主动中止,充电机响应车辆
中止时发送)
表26 车辆中止报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x04
2 车辆中止类型1字节BYTE EndCodeType 车辆中止类型按表L.4
3 车辆中止原因2字节BYTE[2] EndReasonType 车辆中止原因按表L.4
4 请求重连1字节BYTE RepeatType
请求进行重连充电(不影响重新启动):
0x00:不请求重连充电;
0xAA:请求重连充电;
0xFF:无效(充电机主动中止,车辆响应充电
机中止时发送)
9.3.3 接触器状态报文
版本协商成功后,车辆接口未断开连接且充电机和车辆未处于休眠状态,当充电机接触器K1、K2
和车辆供电回路接触器K5、K6状态发生变化时,更新并周期发送相应报文。接触器状态报文信息类型
应符合表27的规定,报文数据格式与内容应符合表28和表29的规定。
注:预充电阶段对接触器的状态要求与充电机或车辆发送的接触器状态报文内容发生矛盾时,车桩逻辑功能由制
造厂自定义。
27
GB/T27930.2—2024
表27 接触器状态报文
参数组标识报文描述信息类型周期时间总发送时间/ms 源地址-目的地址
0x05 直流供电回路
接触器状态
不需要确认
的短消息
直流供电回路接触器状态
未变化时以1000ms周期
发送;发生变化时以50ms
周期连续发送3帧
— 充电机-车辆
0x06 车辆供电回路
接触器状态
不需要确认
的短消息
车辆供电回路接触器状态
未变化时以1000ms周期
发送;发生变化时以50ms
周期连续发送3帧
— 车辆-充电机
1000ms周期时间与50ms周期时间的计时逻辑相互独立
表28 直流供电回路接触器状态报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x05
2 接触器状态1字节BYTE ContactStatusType
直流供电回路接触器K1状态信息:
0x00:断开;
0xAA:闭合;
0xFF:不可信(初始化或接触器动作无法确
认状态时发送)
3 接触器状态1字节BYTE ContactStatusType
直流供电回路接触器K2状态信息:
0x00:断开;
0xAA:闭合;
0xFF:不可信(初始化或接触器动作无法确
认状态时发送)
表29 车辆供电回路接触器状态报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x06
2 接触器状态1字节BYTE ContactStatusType
车辆供电回路接触器K5状态信息:
0x00:断开;
0xAA:闭合;
0xFF:不可信(初始化或接触器动作无法确
认状态时发送)
3 接触器状态1字节BYTE ContactStatusType
车辆供电回路接触器K6状态信息:
0x00:断开;
0xAA:闭合;
0xFF:不可信(初始化或接触器动作无法确
认状态时发送)
28
GB/T27930.2—2024
9.3.4 电子锁状态报文
版本协商成功后,车辆接口未断开连接且充电机未处于休眠状态,当充电机电子锁状态发生变化
时,更新并周期发送相应报文。电子锁状态报文信息类型应符合表30的规定,报文数据格式与内容应
符合表31的规定。
注:充电阶段对电子锁状态的要求与充电机发送的电子锁状态报文内容发生矛盾时,车辆逻辑功能由制造厂自
定义。
表30 电子锁状态报文
参数组标识报文描述信息类型周期时间总发送时间/ms 源地址-目的地址
0x07 充电机电子
锁状态
不需要确认
的短消息
充电机电子锁状态未变化
时以1000ms周期发送;
发生变化时以50ms周期
连续发送3帧
— 充电机-车辆
表31 充电机电子锁状态报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x07
2 电子锁状态1字节BYTE LatchingStatusType
充电机电子锁状态信息:
0x00:未锁止;
0xAA:锁止;
0xFF:不可信(初始化或电子锁动作无法确
认状态时发送)
9.3.5 唤醒报文
充电机和车辆处于休眠或交互结束时,如车辆接口未断开连接,可通过唤醒报文唤醒对方。当充电
机唤醒车辆时,应闭合辅源接触器K3、K4并同时发送“充电机唤醒”报文,直到收到车辆发送“车辆唤
醒”报文且唤醒标识为唤醒。当车辆唤醒充电机时,应发送“车辆唤醒”报文,直到收到充电机发送“充电
机唤醒”报文且唤醒标识为唤醒。唤醒报文信息类型应符合表32的规定,报文数据格式与内容应符合
表33和表34的规定。
注:发送唤醒报文后未收到对方唤醒标识为唤醒的唤醒报文时,以50ms周期重发唤醒报文直到到达总发送时
间,以提高唤醒成功率。
表32 唤醒报文
参数组标识报文描述信息类型周期时间总发送时间/ms 源地址-目的地址
0x08 充电机唤醒需要确认的短消息— 10000 充电机-车辆
0x09 车辆唤醒需要确认的短消息— 10000 车辆-充电机
29
GB/T27930.2—2024
表33 充电机唤醒报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x08
2 唤醒标识1字节BYTE WakeupType
充电机唤醒标识:
0x00:无效(仅用于充电机未被完全唤醒时响
应对方报文);
0xAA:唤醒
表34 车辆唤醒报文数据域内容
序号参数内容长度数据类型参数类型描述与要求
1 参数组标识1字节BYTE PIDType 定值:0x09
2 唤醒标识1字节BYTE WakeupType
车辆唤醒标识:
0x00:无效(仅用于车辆未被完全唤醒时响应
对方报文);
0xAA:唤醒
10 超时
10.1 概述
超时类型分为以下两种:
———数据链路层和传输层的报文超时;
———应用层定义的功能模块(特定FDC)超时。
10.2 数据链路层和传输层超时
10.2.1 对于不需要确认的短消息,应按照应用层规定的报文周期时间周期发送,除非另有规定。起始
和截止发送条件按表J.1。
10.2.2 对于需要确认的短消息,若未接收到确认帧,应按照8.3规定的间隔时间重复发送信息帧,按应
用层规定的总发送时间停止发送信息帧。
10.2.3 对于长消息的报文,其超时和重发时间应符合8.5.3的规定。若传输层传输失败,应用层可在
当前功能模块超时范围内建立重发机制,重发前应确定虚拟连接处于关闭状态(发送方/接收方主动发
送LM_NACK)。总发送时间及阶段超时按表J.1。
10.2.4 版本协商的超时时间应符合表J.2的规定。
10.3 应用层功能模块超时
10.3.1 每个FDC都应单独定义功能交互超时时间,除非另有规定。在FDC 的功能交互超时时间
内,充电机和车辆完成信息交互及FDC规定的功能。
注:对不可重载的功能模块,视同有且只有一个FDC的功能模块。
10.3.2 除功能协商外,每进入一个功能模块前,应由充电机发起阶段确认。充电机侧的超时计时起始
时间为接收到当前FDC的“车辆确认结果_确认成功”报文,若在当前功能模块超时时间内未接收到准
备进入功能模块“车辆确认结果_确认成功”报文或其他标识信息交互结束的报文,充电机进入超时处理
30
GB/T27930.2—2024
并退出本次通信流程,除非另有规定。FDC中车辆的超时计时起始时间为车辆成功发送“车辆确认结
果_确认成功”报文,若在超时时间内未完成当前功能模块的功能及阶段确认,车辆进入超时处理并退出
本次通信,除非另有规定。
注:功能协商模块超时见表B.5和表B.6。
10.3.3 应用层定义的FDC的超时时间应符合表J.2的规定。
31
GB/T27930.2—2024
附 录 A
(规范性)
应用场景的实现
A.1 充电应用场景
A.1.1 充电过程中的信息交互由多个功能模块按序组成。通过配置可重载功能模块的不同实例,实现
不同充电功能场景的应用。
A.1.2 典型的基本充电应用场景的信息交互过程应符合图A.1的规定,其中阴影部分为实现基本充电
的最小集合。
图A.1 基本充电应用场景的实现
32
GB/T27930.2—2024
A.2 充放电应用场景
A.2.1 充放电场景下,在参数配置、预充及能量传输功能模块交互过程中,充电机和车辆应能完成车辆
与充电机充放电的功能,其他功能模块与充电场景一致。
A.2.2 典型的基本充放电应用场景的信息交互过程应符合图A.2的规定,其中阴影部分为实现基本充
放电的最小集合。充放电模式切换流程应符合图A.3的规定。
图A.2 充放电应用场景的实现
33
GB/T27930.2</t$g