ChinaAutoRegs｜GB/T 27930.2-202X英文版翻译 非车载传导式充电机与电动汽车之间的数 字通信协议 第2部分：用于GB/T 20234.3的通信协议
Digital communication protocols between off-board conductive charger and electric vehicle—Part 2: Communication protocols for GB/T 20234.3
关联标准：
GB/T 27930-2023 英文版 非车载传导式充电机与电动汽车之间的数字通信协议
Digital communication protocols between off-board conductive charger and electric vehicle
目次
前言 III
1 范围 1
2 规范性引用文件 1
3 术语和定义 1
4 缩略语 3
5 总则 3
6 物理层 4
7 数据链路层 4
7 . 1 总体要求 4
8 .2版本协商 5
8 传输层 13
8.1 概述 13
8.2 2不需要确认的短消息 14
8.3 需要确认的短消息 14
8.4 长消息 14
汽5 多信息帧传输方式 15
9 应用层 23
9. 1 总体要求 23
9.2 通信过程 24
9. 3 公共报文 25
10 超时 29
10. L 概述 29
10.2数据链路层和传输层超时 29
10. 3应用层功能模块超时 29
附录A （规范性） 应用场景的实现 30
A.1 充电应用场景 30
A.2 充放电应用场景 31
附录B （规范性）功能协商功能模块 33
8.1 总体要求 33
8.2 报文定义 33
8.3 报文交互过程 35
附录C （规范性）参数配置功能模块 40
C.1 概述 40
C.2充电模式参数配置（FDC=1） 40
C.3充放电模式参数配置（FDC=2） 43
附录D （规范性）鉴权功能模块 49
D.1 概述 49
D.2 扫码/刷卡（FDC=1） 49
D.3 EVIN 鉴权（FDC=2） 54
D.4云端鉴权一桩识别码（FDC=3） 59
附录E （规范性）预约充电功能模块 66
E.1 概述 66
E.2车辆定义预约开始时间（FDC=1） 66
附录F （规范性）输出回路检测功能模块 75
F.1 概述 75
F.2 输出回路检测（FDC=1） 75
附录G （规范性）供电模式功能模块 82
G.1 概述 82
G.2 恒压供电模式（FDC=1） 82
附录H （规范性）预充及能量传输模块 92
H.1 概述 92
H.2充电模式预充及能量传输（FDC=1） 92
H.3充放电模式预充及能量传输（FDC=2） 105
附录I（规范性）结束功能模块 127
1.1 概述 127
1.2 结束（FDC=1） 127
附录J （规范性）报文周期及功能模块超时 134
附录K （规范性）退出方式 142
附录L （规范性）参数类型表 145
附录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
1 范围
本文件规定了用于GB/T 20234. 3直流充电接口的电动汽车直流充电通信控制器与非车载传导式充 电机充电通信控制器之间基于控制器局域网的物理层、数据链路层、传输层及应用层的通信协议。
本文件适用于直流充电接口符合GB/T 20234.3的电动汽车（可简称车辆）与非车载传导式充电机 （可简称充电机）之间的直流充电通信。
本文件适用于直流控制导引电路与控制原理等充电功能符合GB/T 18487.5的直流充电系统。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， 仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 文件。
GB/T 1988—1998 信息技术 信息交换用七位编码字符集
GB 16735道路车辆 车辆识别代号（VIN）
GB 18030—2022 信息技术 中文编码字符集
GB/T 18487.5电动汽车传导充电系统 第5部分：用于GB/T 20234.3的直流充电系统
GB/T 19596 电动汽车术语
GB/T 20234.3 电动汽车传导充电用连接装置 第3部分：直流充电接口
GB/T 29317 电动汽车充换电设施术语
3 术语和定义
GB/T 19596和GB/T 29317界定的以及下列术语和定义适用于本文件。
3. 1
帧 frame
组成一个完整信息的一系列数据位。
3. 2
CAN 数据帧 CAN data frame
用于传输数据的CAN协议所必需的有序位域，以帧起始（SOF）开始，帧结束（EOF）结尾。
3. 3
CAN 报文 CAN message
发送或接收参数组及其参数数据的一个实例，一个CAN报文的发送可能需要交互一个或多个CAN数 据帧。
3.4
标识符 identifier
CAN仲裁域的标识部分。
3.5
扩展帧 extended frame
CAN2.0B规范中定义的使用29位标识符的CAN数据帧。
3. 6
优先权 priority
在标识符中一个3位的域，设置传输过程的仲裁优先级，最高优先权为0级，最低优先权为7级。
3.7
参数组 parameter group; (PG)
在应用层传输的参数集合，分为命令类和信息类。
3. 8
参数组标识 parameter group identification; (PGI)
用于唯一标识一个参数组的一个字节。
3.9
协议数据单元 protocol data unit; (PDU)
一种特定的CAN数据帧格式。
3. 10
功能模块 function module
由充电通信交互过程划分的若干个可定义的、具有特定业务功能的最小单元。
3. 11
可配置功能模块 override function module
可重新定义和替换的功能模块。
3. 12
功能代码 function code; (FC)
为功能模块分配的编号。
3. 13
功能描述码 function description code; (FDC)
为同一功能模块不同实现方式分配的编号。
3. 14
信息帧 information frame
数据链路层上用于传输有效信息或数据的CAN数据帧。
3. 15
控制帧 control frame
数据链路层上用于进行流量控制和差错管理的CAN数据帧。
3. 16
长消息 long message
采用多信息帧传输方式传输的消息。
3. 17
需要确认的短消息 reliable short message
采用自动重传请求方式传输不具有帧编号的单帧数据。
3. 18
不需要确认的短消息 unreliable short message
不需要自动重传请求方式传输不具有帧编号的单帧数据。
3 . 19
公共报文 publ ic message
满足发送条件时，在应用层各功能模块均可交互的报文。
4 缩略语
下列缩略语适用于本文件。
CAN：控制器局域网(Controller Area Network)
EVCC：车辆充电通信控制器(Electric Vehicle Communication Controller)
SECC：充电机充电通信控制器(Supply Equipment Communication Controller)
CP：控制导引(Control Pilot)
TL： 传输层 (Transport Layer)
LM：长消息(Long Message)
SM：短消息(Short Message)
SM_RM：需要确认的短消息(Reliable Short Message)
SM_URM：不需要确认的短消息(Unreliable Short Message)
SM_ACK：短消息应答确认消息(Short Message Acknowledgment)
LM_ACK：长消息应答确认(Long Message Acknowledgment)
LM_NACK：长消息放弃连接确认(Long Message Negative Acknowledgment)
LM_EndofACK：长消息接收结束确认(Long Message End of Acknowledgment)
5 总则
5. 1本文件规定的数字通信协议适用的充电接口应符合GB/T 20234.3。
5.2 本文件规定的数字通信协议适用的直流充电系统应符合GB/T 18487.5。
5.3 车辆与充电机之间的通信网络基于CAN2. 0B协议，通信模型分为物理层（按第6章）、数据链路 层（按第7章）、传输层（按第8章）和应用层（按第9章）。协议架构分层模型见图1。
各层定义和要求 实现方式 层间接口关系
应用层
传输层
数据 链路层
物理层
注1：实现方式、层间接口关系不在本文件规定范围内。
注2：“上层”或“上层应用”用于描述当前层以上层级。
注3：本文件规定的通信协议应用层要求同样适用于CAN FD、CAN XL等协议。CAN FD、CAN XL为未来功能预留，实现 方式未在本文件中规定。
图1 协议架构分层模型
5.4 车辆与充电机之间的充电通信过程由完成不同业务功能的功能模块组成，充电和充放电应用场景 的功能模块应符合附录A的规定。
5. 5具体功能模块的信息交互报文、交互过程应符合附录B〜附录I的规定。应按9.3.1的阶段确认 完成应用层各功能模块间的确认和连接，用于确认下一个阶段的FC和FDC。
5. 6报文周期及功能模块超时应符合附录J的规定。退出方式应符合附录K的规定。参数类型表应符 合附录L的规定。
5.7 通信过程自物理连接完成后立即进入版本协商阶段。版本协商完成后，根据协商结果确认选择协 商一致的版本进行充电。通信协议具备向下兼容（兼容旧版本）能力，通信流程通过版本协商跳转进入 向下兼容的通信协议。向下兼容的通信协议应符合附录M的规定。
5.8 本文件规定的通信协议版本号为V2.0.0,主版本号和次版本号由本文件定义，临时版本号仅用于 企业的内部开发。
注： 企业内部开发意味着采用自定义临时版本号的车辆或充电机不在市场流通。产品开发阶段的企业外部验证或示 范活动采用自定义临时版本号时，通过在本文件归口的标准化机构备案临时版本号能避免临时版本号无序使用。
5.9 使用状态表定义充电机和车辆的交互状态转换方式，状态表左侧列为充电机或车辆在当前通信流 程的状态，上方表头为触发状态跳转的条件。通信协议转换应符合状态转换表的要求。
注： 流程图给出了车桩交互状态和功能跳转的图形化示意，便于文件使用者的快速理解。
6 物理层
6. 1车辆与充电机的通信应使用独立的CAN总线，支持EVCC和SECC共2个节点，通信速率采用250 kbit/s。
注： 车辆对外直流放电模式中使用的电缆组件可能具备通信节点。
6.2 CAN通信网络宜使用屏蔽双绞线进行组网和布线，CAN通讯线屏蔽层宜在充电机侧接地。
7 数据链路层
7.1 总体要求
7.1.1 帧格式
应使用29位标识符的CAN扩展帧。
7.1.2 协议数据单元
协议数据单元由优先权、扩展数据页、数据页、PDU格式、PDU特定格式、源地址和数据域共七个部 分组成，应符合表1的规定。
表1 协议数据单元
8.5 多信息帧传输方式
8.5.1 原则
长消息传输控制的主要功能为分包重组和连接管理。
8.5.2 分包重组
8.5.2.1 重组方式
发送方首先将长消息拆分为多个信息帧，在建立连接后按序进行传输。接收方接收到所有的信息帧 数据后再重组成原始信息。
8.5.2.2 信息帧
每个信息帧应能被识别和重组，信息帧数据域的首字节定义为信息帧的帧序号，序号范围为1〜255 (序号为0的信息帧仅用于建立连接)，信息帧应从编号1开始按序进行发送，最长的数据长度是1785字 节。当发送方请求建立长消息传输的虚拟连接时，首先发送帧序号为0的信息帧，在收到接收方应答确 认后，按要求发送信息帧。
每个信息帧（除了最后1个信息帧和用于建立连接帧序号为0的信息帧）都装载着应用层数据的7个 字节，最后1个信息帧的数据域的8个字节包含：信息帧的序号和至少一个字节的应用层数据，未使用的 字节全部设置为0xFF。
8.5.2.3 帧序号
传输层在拆装时给信息帧分配帧序号，接收方接收后，利用帧序号把信息帧重组回原始信息。信息 帧从编号为1的信息帧开始按编号递增顺序发送。序号为0的信息帧不含应用层数据，仅用于建立虚拟连 接。
8.5.2.4 数据传输
信息帧之间的发送间隔时间LMS_T1应不小于5 ms且不大于10 ms。同一时间只允许建立一个虚拟连 接，即只有当发送方或接收方发送长消息放弃连接确认或接收方发送长消息接收结束确认，才能建立新 的虚拟连接。
注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的长消息后，可选择接收或者拒绝建立连接。如果选择接收，应 发送长消息应答确认帧LM_ACK，且LM_ACK中应包含接收方待接收的起始帧序号、待接收总帧数。连接 建立后，接收方应从序号为1的信息帧开始接收。
8.5.3.3.3 如果发送方接收到LM_ACK，连接建立完成。
8.5.3.3.4 如果接收方缺少资源或存储空间，可拒绝建立连接，此时应发送放弃连接确认 LM_NACK， 连接建立失败。
8.5.3.4 数据传输
8.5.3. 4.1发送方接收到LM_ACK后开始数据传输。接收方负责调整节点之间的数据流控制，如果接收 方需要暂停数据流，可使用LM_ACK将待接收总帧数置为1,待接收起始帧序号置为已接收的最后一帧 的帧序号，发送方重复发送此帧内容（即接收方重复接收上一组最后一帧报文），接收方收到该报文后 不做处理。当接收方恢复数据流时，则将LM_ACK中“待接收起始序号”置为前一次接收到的下一帧帧 序号,按照自身接收和处理能力重置“待接收总帧数”,直至完成所有信息帧的接收。
8.5.3. 4.2如果接收方决定终止传输，应发送LM_NACK，发送方收到LM_NACK后终止长消息的传输。
8.5.3.5 连接的关闭
8.5.3.5.1 在传输没有错误的情况下,当接收到所有信息帧后,接收方应发送消息结束确认 LM_EndofACK，通知发送者连接关闭。
8.5.3.5.2 5.2长消息传输过程中，发送方或接收方可在任何时候使用LM_NACK终止连接。如果接收方没 有可用资源处理消息，可以通过发送LM_NACK放弃连接。当接收到LM_NACK时，所有已传送信息帧将被 丢弃。
8.5.3.5.3 任一方发生传输故障（如连续出现3次同类型的连接超时）都会导致连接关闭。长消息的 连接关闭,包括以下方面：
a） 发送方在以下情况下,可以认为连接被关闭：
1）完成整个长消息的数据传输且接收到LM_EndofACK；
2）发送LM_NACK （如发送方希望提早停止通讯、超时等）；
3）接收 LM_NACK。
b） 接收方在以下情况下,可以认为连接被关闭：
1）完成整个长消息的数据传输后发送了 LM_EndofACK；
2）发送LM_NACK （如接收方缺少资源或存储空间）；
3）接收 LM_NACK。
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放弃连接。
8.5.3. 6.6发送方从发送帧序号为0的信息帧后，传输整个长消息的时间大于LMS_T3即为超时，超时 后发送LM_NACK放弃连接。
8.5.3. 6.7 LMS_T2为100 ms，LMS_T3默认为10 000 ms，如果应用层未规定总发送时间，长消息应在 LMS_T3时间内传输完成，否则以应用层规定为准。
8.5.3.6.8 长消息发送的完整状态转换过程应符合表15和表16的规定，报文交互流程示意见图3。
应用层
9.1 总体要求
9.1.1 采用参数组标识（PGI）对参数组进行编号，各节点根据PGI来识别报文内容。
9.1.2 通信双方应按实际数据发送报文，除非另有规定。
9.1.3 接收方接收到非本文件定义的报文，或超出数据范围或标准未规定的参数值时，应忽略该信息，
除非另有规定。
9.1.4 接收方接收到的参数值为“预留”值或“无效”值时，应不处理该参数。
9.1.5 传输的数据类型应符合表17的规定，应采用小端模式来传递数字信息。
9.1.6 各功能模块状态转换表中发送“报文名称_报文内容”报文为应用层发送至传输层，应用层状态
跳转可不依赖于传输层是否收到接收方控制应答。成功发送“报文名称_报文内容”报文为应用层发送 报文至传输层并接收到接收方控制应答报文。除非另有规定。
9.1.7 应用层接收到传输层传输失败，应按附录K “方式3-故障停机”退出。应用层接收到数据链路 层或传输层超时，未触发应用层报文或功能模块超时时，可再次尝试，若应用层超时，应按附录K故障 停机退出。
9.1.8 功能模块交互流程示意图仅用于对业务流程的理解，未体现阶段超时或交互双方在本功能模块 主业务，没有表述需要中止充电或响应对方中止充电的情况。
9.1.9 参数类型应符合表L.1的规定。
9.2通信过程
9.2.1 充电通信过程由多个功能模块按序组成，各功能模块对应的功能代码（FC）应符合表18的规 定。一个完整的充电通信过程应包括所有必需项功能模块（一个完整的充电通信交互过程中必需的功能 模块）以及零个或多个可选项功能模块，应符合图4的规定。
9.2.2 除功能协商外，其他功能模块都可以进行配置以实现不同的应用，各功能模块的不同应用通过 功能描述码（FDC）区分，每个可配置功能模块（可重新定义和替换的功能模块）支持的FDC上限为8 个。
注： 功能协商的内容未来发生变化时，通信协议的主版本号将进行变更。
9.2.3 通信过程中，应保证信息交互的同步性，如无特殊要求，在完成功能模块的信息交互后，如需 进入下一阶段，应首先按9.3.1的要求进行阶段确认，保证进入下一功能的通信信息在FC及FDC上的 一致性，其中不可配置的功能模块FDC固定为0x01。
注：功能协商功能模块FDC为不可配置。
图4 功能模块类型
9.2.4 通信过程中，充电机判断需要发送中止报文，根据表L.4的中止原因发送中止报文并通过阶段 确认请求报文进入结束阶段。充电机收到车辆中止报文（不包含充电机主动中止）或开关S2断开，发 送“中止—车辆主动中止”报文，根据表L.4的中止原因发送中止报文并通过阶段确认请求报文进入结 束阶段。
9.2.5 通信过程中，车辆判断需要发送中止报文，根据表L.4的中止原因发送中止报文并通过阶段确 认请求报文进入结束阶段。车辆收到充电机中止报文（不包含车辆主动中止）或S1断开，发送“中止 .充电机主动中止”报文，根据表L.4的中止原因发送中止报文并通过阶段确认请求报文进入结束阶段。
9.2.6 中止过程中，充电机和车辆应根据表L.4确认中止退出方式，对应的退出方式按附录K和GB/T 18487.5 进行。中止过程发生不低于现中止退出方式优先级的故障，应更新中止原因后重发中止报文， 双方根据优先级最高的方式进行退出。
9.2.7 发起/等待阶段确认请求进入结束阶段前，充电机/车辆应关闭阶段超时定时器以外已开启的报文发送/超时定时器，阶段超时定时器应在退出本阶段前关闭。
9.3公共报文
9.3.1 阶段确认
在进入可配置功能模块前，充电机与车辆应在上一阶段结束时，根据功能协商结果确认即将进入的 FC和FDC与预期保持一致。充电机首先发送下一个需要执行的功能模块的对应FDC,若车辆返回阶段确认 成功信息，双方进入下一个FDC的执行；若车辆返回阶段确认失败信息，双方退出充电过程。
阶段确认过程是充电机和车辆信息交互同步的基础，其报文定义和信息交互过程应固定不变。阶段 确认报文信息类型应符合表19的规定，报文数据格式与内容应分别符合表20和表21的规定。阶段确认的 完整状态转换应符合表22和表23的规定。
任取样页验证译文质量。
提供正规增值税数电发票。
请联系手机/微信: 13306496964/QQ：564965870/Email: standardtrans@foxmail.com 获取完整译文。
本英文译本为纯人工专业精翻版本，保证语法术语准确率和专业度！
专业源于专注|ChinaAutoRegs 始终专注于汽车标准翻译领域！迄今为止已翻译上千个国内外汽车标准法规！独家打造千万级汽车专业术语库和记忆库。