网站地图 | Tags | 热门标准 | 最新标准 | 订阅

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

  • 名  称:GB/T 27930.2-2024 非车载传导式充电机与电动汽车之间的数字通信协议 第2部分:用于GB/T 20234.3的通信协议 - 下载地址2
  • 下载地址:[下载地址2]
  • 提 取 码
  • 浏览次数:3
下载帮助: 发表评论 加入收藏夹 错误报告目录
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
新闻评论(共有 0 条评论)

资料介绍

  ICS 43. 120 CCS T 35

  中 华 人 民 共 和 国 国 家 标 准

  GB/T 27930.2—2024

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

  的数字通信协议 第 2 部分:用于

  GB/T20234. 3 的通信协议

  Digitalcommunication protocolsbetween off-board conductivechargerand electricvehicle—Part2:Communication protocolsforGB/T20234.3

  2024-12-31发布 2024-12-31实施

  国家市场监督管理总局国家标准化管理委员会

  

  发

  

  布

  GB/T 27930.2—2024

  目 次

  前言 Ⅲ

  引言 Ⅳ

  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/T 27930.2—2024

  C(C).. 3 充放电模式参数配(2 充电模式参数配置)置(F2)… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… 4(4)6(2)

  附录 D (规范性) 鉴权功能模块 52

  D. 1 通则 52

  ... -桩(2()…C(…)=…3……) ………… ……… ……… ……… ……… ……… ……… ……… ……… ………………… ……… ……… ……… ……… ……… ……… ……… ……… ……… ……… ……… ……… ………

  附录 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(H).. 3 充放电模式预充及能量传(2 充电模式预充及能量传输)输(F2…) ………………………………………………………………………………………………………………… 10(9)5(3)

  附录 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/T 27930.2—2024

  前 言

  本文件按照 GB/T 1. 1—2020《标准化工作导则 第 1部分 :标准化文件的结构和起草规则》的规定起草 。

  本文件是 GB/T 27930的第 2部分 。GB/T 27930已经发布了以下部分 :

  — 非车载传导式充电机与电动汽车之间的数字通信协议 ;

  — 非车载传导式充电机与电动汽车之间的数字通信协议 第 2 部分 : 用于 GB/T 20234. 3 的通信协议 。

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

  本文件由中华人民共和国工业和信息化部提出 。

  本文件由全国汽车标准化技术委员会(SAC/TC114)归 口 。

  本文件起草单位 : 中国汽车技术研究中心有限公司 、比亚迪汽车工业有限公司 、华为数字能源技术有限公司 、北汽福田汽车股份有限公司 、广汽埃安新能源汽车股份有限公司 、广州小鹏汽车科技有限公司 、蔚来汽车科技(安徽)有限公司 、深圳市车电网络有限公司 、广州巨湾技研有限公司 、深蓝汽车科技有限公司 、领充新能源科技有限公司 、中汽研新能源汽车检验中心(天津)有限公司 、特来电新能源股份有限公司 、天津平高易电科技有限公司 、合肥国轩高科动力能源有限公司 、深圳巴斯巴科技发展有限公司 、杭州中恒电气股份有限公司 、宁德时代新能源科技股份有限公司 、中汽研汽车检验中心(广州) 有限公司 、湖南京能新能源科技有限公司 、北京车和家汽车科技有限公司 、吉利汽车研究院(宁波) 有限公司 、绿能慧充数字技术有限公司 、梅赛德斯一奔驰(中国)投资有限公司 、深圳市欧澄电气有限公司 、中国第一汽车集团有限公司 、重庆长安汽车股份有限公司 、威凯检测技术有限公司 、中石油昆仑网联电能科技有限公司 、长城汽车股份有限公司 、开迈斯新能源科技有限公司 、长园深瑞能源技术有限公司 、沃尔沃汽车(亚太)投资控股有限公司 。

  本文件主要起草 人 : 廉 玉 波 、徐 枭 、赵 颖 、李 津 、邵 长 宏 、韩 忠 华 、郑 天 雷 、廖 梦 雄 、王 芳 、赵 绿 化 、兰海波 、柳邵辉 、刘 庆 荣 、邱 鹏 、李 骁 、孙 茂 建 、程 浩 、王 兵 、王 春 生 、彭 文 科 、邱 石 军 、樊 彬 、李 川 、谭 易 、魏俊生 、方灵珊 、何 源 、郑 祥 杰 、冯 斌 、孙 小 文 、季 学 彬 、朱 健 强 、李 恩 虎 、荣 超 、廖 超 、田 宇 威 、谷 兆 宁 、巩慧蛟 、吕国伟 、吕 玉 华 、李 亮 、姜 毅 、谢 娜 、梁 士 福 、武 亨 、姜 瑞 、陈 基 永 、周 安 健 、闫 磊 、房 凯 龙 、高 峰 、王超 、王婧雅 、杨俊 、许青松 、柳志民 。

  Ⅲ

  GB/T 27930.2—2024

  引 言

  随着电动汽车相关产业与消费市场规模的快速扩大 ,行业迫切需求大功率充电 、即插即充 、预约充电 、放电等新充电功能 ,直流充电通信协议标准亟待升级 。本文件规定了用于 GB/T 20234. 3 直流充电接口的非车载传导式充电机与电动汽车之间的直流充电通信协议 ,具体给出了通信协议的物理层 、数据链路层 、传输层和应用层的详细内容 。本文件规定的直流通信协议进一步提升了充电的安全性 、兼容性与便捷性 ,从而引导电动汽车相关产业的高质量发展 。

  GB/T 27930拟由 2个部分构成 。

  — 第 1部分 :用于 GB/T 20234. 3 和 GB/T 20234. 4 的通信协议 。 目 的在于确立 GB/T 20234. 3和 GB/T 20234. 4直流充电接口所应用的数字通信数据链路层 、传输层和应用层等内容 。

  — 第 2部分 :用于 GB/T 20234. 3 的通信协议 。 目的在于确立 GB/T 20234. 3 直流充电接口所应用的数字通信数据链路层 、传输层和应用层等内容 ,用于实现大功率充电 、即插即充 、预约充电 、放电等数字通信 。

  Ⅳ

  GB/T 27930.2—2024

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

  的数字通信协议 第 2 部分:用于

  GB/T20234.3 的通信协议

  1 范围

  本文件规定了用于 GB/T 20234. 3 直流充电接口的电动汽车直流充电通信控制器与非车载传导式充电机充电通信控制器之间基于控制器局域网的物理层 、数据链路层 、传输层及应用层的通信协议 。

  本文件适用于直流控制导引电路与控制原理符合 GB/T 18487. 5 的电动汽车(简称 “车辆 ”) 与非车载传导式充电机(简称 “充电机 ”)之间的数字通信 。

  2 规范性引用文件

  下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款 。其中 , 注 日期的引用文件 ,仅该日期对应的版本适用于本文件 ;不注日期的引用文件 ,其最新版本(包括所有的修改单) 适用于本文件 。

  GB/T 1988 信息技术 信息交换用七位编码字符集

  GB 16735 道路车辆 车辆识别代号(VIN)

  GB 18030 信息技术 中文编码字符集

  GB/T 18487. 5 电动汽车传导充电系统 第 5部分 :用于 GB/T 20234. 3 的直流充电系统GB/T 19596 电动汽车术语

  GB/T 20234. 3 电动汽车传导充电用连接装置 第 3部分 :直流充电接 口

  GB/T 27930—2023 非车载传导式充电机与电动汽车之间的数字通信协议

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

  3 术语和定义

  GB/T 19596、GB/T 27930—2023和 GB/T 29317界定的以及下列术语和定义适用于本文件 。 3. 1

  功能模块 function module

  由充电通信交互过程划分的若干个可定义的 、具有特定业务功能的最小单元 。

  3.2

  公共报文 publicmessage

  满足发送条件时 ,在应用层各功能模块均可交互的报文 。

  4 缩略语

  下列缩略语适用于本文件 。

  CAN:控制器局域网(Controller Area Network)

  1

  GB/T 27930.2—2024

  CP:控制导引(ControlPilot)

  EVCC:车辆充电通信控制器(Electric Vehicle Communication Controller)

  LM :长消息(Long Message)

  LM_ACK:长消息应答确认(Long Message Acknowledgment)

  LM_EndofACK:长消息接收结束确认(Long Message End ofAcknowledgment)

  LM_NACK:长消息放弃连接确认(Long Message Negative Acknowledgment)

  SECC:充电机充电通信控制器(Supply EquipmentCommunication Controller)

  SM :短消息(ShortMessage)

  SM_ACK:短消息应答确认消息(ShortMessage Acknowledgment)

  SM_RM :需要确认的短消息(Reliable ShortMessage)

  SM_URM :不需要确认的短消息(Unreliable ShortMessage)

  TL:传输层(TransportLayer)

  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(CAN FD) 、扩展长度 CAN(CAN XL) 等协议 。

  CAN FD、CAN XL为未来功能预留 ,实现方式未在本文件中规定 。

  图 1 协议架构分层模型

  5.4 车辆与充电机之间的通信过程由不同功能模块组成 ,充电和充放电应用场景的功能模块应符合附录A 的规定 。

  5.5 功能模块的信息交互报文 、交互过程应符合附录 B~ 附录 I的规定 。应用层各功能模块间的确认和连接应按 9. 3. 1 阶段确认的要求完成 。

  2

  GB/T 27930.2—2024

  5.6 报文周期及功能模块超时应符合附录 J 的规定 。退出方式应符合附录 K 的规定 。参数类型表应符合附录 L 的规定 。

  5.7 通信过程自物理连接完成后应立即进入版本协商阶段 。版本协商完成后 ,应根据协商结果确认选择协商一致的版本进行充电 。通信协议具备向下兼容(兼容旧版本)能力 ,通信流程通过版本协商跳转进入向下兼容的通信协议 。 向下兼容的通信协议应符合附录 M 的规定 。

  5. 8 本文件规定的通信协议版本号为 V2. 0. 0,主版本号和次版本号由本文件定义 , 临时版本号仅用于企业的内部开发 。

  注 : 企业内部开发意味着采用 自定义临时版本号的车辆或充电机不在市场流通 。产品开发阶段的企业外部验证或示范活动采用 自定义临时版本号时 ,通过在本文件归 口 的 标 准 化 机 构 备 案 临 时 版 本 号 以 避 免 临 时 版 本 号 无 序使用 。

  5.9 通信交互应符合状态转换表的要求 。

  注 1: 状态转换表定义了充电机和车辆的交互状态转换方式 。状态转换表左侧列为充电机或车辆在当前 通 信 流 程的状态 ,上方表头为触发状态跳转的条件 。

  注 2: 流程图给出了车辆和充电机(简称 “车桩 ”)交互状态和功能跳转的图形化示意 ,便于文件使用者的快速理解 。

  6 物理层

  车辆与充电机之间的通信物理层应符合 GB/T 27930—2023第 13章的规定 。其中 ,物理层应使用独立的 CAN 总线 ,支持 EVCC和 SECC共 2个节点 。

  7 数据链路层

  7. 1 总体要求

  7. 1. 1 帧格式

  车辆与充电机之间的通信帧格式应符合 GB/T 27930—2023中 14. 1 的规定 。

  7. 1.2 协议数据单元

  协议数据单元由优先权 、扩展数据页 、数据页 、PDU 格式 、PDU 特定格式 、源地址和数据域共 7 个部分组成 ,应符合表 1 的规定 。

  表 1 协议数据单元

  …

  P

  EDP

  DP

  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/T 27930.2—2024

  7. 1.3 协议数据单元格式

  协议数据单元格式应符合 GB/T 27930—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/T 18487. 5) ,通信链路建立之后 ,双方进行通信协议版本协商 , 向对方发送己方支持的最高协议版本号(版本的比较即数字的大 小 比 较) 并 读 取 对 方 判 断 结 果 , 版 本 协 商应满足以下要求 。

  — 如对方发送协商成功且协商版本一致 ,或对方发送协商失败 ,则结束协商 。

  — 如对方发送继续协商 ,则判断接收版本是否支持 ,支持则发送协商成功并将协议版本修改为协商版本 。

  — 如不支持该版本且低于对方发送的版本 ,则保持当前版本并 “继续协商 ”。

  — 如不支持该版本且高于对方版本但有低于对方发 送 的 版 本 ,则 根 据 “期 望 版 本 号 ”调 整 协 议 版本指向低于对方期望版本中最高的版本 ,发送协议版本并 “继续协商 ”。

  — 如接收版本已低于最低版本 ,则发送 “协商失败 ”。

  版本协商成功后 ,车辆持续发送 “协商成功 ”,直到充电机发送下一阶段报文 。充电机在接收车辆发送 “协商成功 ”且版本不低于 V2. 0. 0后进入功能协商阶段 。

  满足以下任一情况 ,双方进入附录 M通信流程(不需发送阶段确认报文) :

  — 协商失败 ;

  — 从己方首次发送版本协商报文超过 10 s;

  — 车辆收到 CHM/CRM报文 ;

  — 版本协商成功且协商成功版本低于 V2. 0. 0。

  进入附录 M通信流程后 ,充电机应符合 GB/T 18487. 5 的规定 ,车辆应等待充电机闭合辅源及发送 CHM/CRM报文

  4

  GB/T 27930.2—2024

  表 3 版本协商总体要求 (续)

  序号

  项 目

  要求

  4

  前置条件

  确认物理连接完成 ,通信链路建立后同时开始 。

  在辅源或报文唤醒车辆后 ,充电机应重新发起版本协商(仅适用于自动重连或重启充电)

  5

  协议版本

  充电机和车辆宜支持多个版 本 的 通 信 协 议 。协 商 成 功 时 , 双 方 支 持 相 同 的 协 议 版 本 , 否 则 协 商失败 。

  通信协议版本号由 CAN类型 、主版本号 、次版本号 、临时版本号组成 ,应满足以下要求 :

  — 当前 CAN类型为 CAN2. 0B, 同时预留 CAN FD、CAN XL 的应用 ;

  — 主版本号在通信协议有结构性变化(如功能模块有变化)时更新 ;

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

  — 临时版本号仅用于企业内部的示范 、测试等临时用途 ,正式发布的版本中临时版本号为 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/T 27930.2—2024

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

  序号

  参数内容

  长度

  数据类型

  参数类型

  描述与要求

  1

  CAN类型

  1 字节

  BYTE

  CANType

  充电机 CAN类型 :

  0x00:CAN2. 0B;

  0x01:CAN FD;

  0x02:CAN XL。

  当前版本 采 用 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/T 18487. 5 中 旧 版 本 充 电 机 控 制 导 引电路 ;

  0x02:GB/T 18487. 5。

  接收方不以该值判定协商结果

  5

  传输层版本

  1 字节

  BYTE

  TLVersionType

  充电机传输层版本 :

  0x01:第 8章 ;

  0xFF:其他 。

  接收 方 不 以 该 值 判 定 协 商 结 果 , 高 版 本 兼 容 低版本

  6

  预留

  1 字节

  BYTE

  ReservedType

  接收方不判断该值 ,默认填充 0xFF

  6

  GB/T 27930.2—2024

  表 7 车辆版本协商数据域内容

  序号

  参数内容

  长度

  数据类型

  参数类型

  描述与要求

  1

  CAN类型

  1 字节

  BYTE

  CANType

  车辆 CAN类型 :

  0x00:CAN2. 0B;

  0x01:CAN FD;

  0x02:CAN XL。

  当前版本 采 用 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/T 18487. 5 中 旧 版 本 车 辆 控 制 导 引电路 ;

  0x02:GB/T 18487. 5。

  接收方不以该值判定协商结果

  5

  传输层版本

  1 字节

  BYTE

  TLVersionType

  车辆传输层版本 :

  0x01:第 8章 ;

  0xFF:其他 。

  接收 方 不 以 该 值 判 定 协 商 结 果 , 高 版 本 兼 容 低版本

  6

  预留

  1 字节

  BYTE

  ReservedType

  接收方不判断该值 ,默认填充 0xFF

  7.2.3 报文交互过程

  7.2.3. 1 物理连接完成或车桩被唤醒后 1 s 内(不包括预约到时唤醒) ,充电机和车辆分别向对方发送其支持的最高协议版本号和 “继续协商 ”状态 , 接收并检查 自身支持的协议版本号返回版本协商结果 。若为 “继续协商 ”,则继续以较低的协议版本号进行协商 ;若为 “协商成功 ”且协议版本不低于 V2. 0. 0,则按照协商一致的版 本 的 通 信 协 议 进 行 信 息 交 互 ; 若 为 “协 商 失 败 ”、超 时 或 “协 商 成 功 ”且 协 议 版 本 为V1. 1. 0,则按附录 M通信 。

  7.2.3.2 版本协商的完整状态转换过程应符合表 8 和表 9 的规定 ,报文交互流程示意见图 2。

  7

  GB/T 27930. 2— 2024

  8

  表 8 版本协商充电机状态转换表

  充电机

  触发条件

  物理连接完成

  T1 到时

  接收“车辆版本协商 "

  充电机故障应中止充电或车辆断开 S2

  Touto到时

  接收“协商成功 "

  接收“协商失败 "

  接收“继续协商 "

  版本不一致

  版本 一致且为v1 . 1 . o

  版本 一致且 ≥ v2 . o. o

  有相同

  的版本号

  版本低于车辆

  版本高于车辆

  有更低的版本号

  无更低的版本号

  状态

  So

  初始化

  发送“充电机版本协商-继续协商 - 协议 版 本 号 = CVList (Ns) " , 打 开T1 , Touto 定 时 器 , 进入 S1

  —

  —

  —

  —

  —

  —

  —

  —

  —

  —

  —

  S1

  协商中

  —

  发送“ 充 电 机 版

  本协商 " , 协议版本 号 = CVList ( Ns ) 报 文 , 保持 S1

  协商结果 = “ 继 续协商 " ,保持 S1

  协商结果 = “ 协 商成功 " ,进入 S2

  协商结果 = “ 协 商成功 " ,进入 S3

  进入 S4

  协商结果 = “ 协 商成功 " , Ns 指

  向该版

  本 , 保持 S1

  保持 S1

  根据 车 辆“ 期望版 本 号 " 信息调 整 Ns 指向低于车辆期望版本中最高的 版 本 , 保持 S1

  进入 S4

  进入 S5

  进入 S4

  S2

  附录 M

  协商成功

  发送“协商成功 " , 关闭 T1 、Touto , 进行附录 M通信

  S3成功

  发送“协商成功 " , 关闭 T1 、Touto , 进入功能协商

  S4

  协商失败

  发送“协商失败 " , 关闭 T1 、Touto , 进行附录 M通信

  S5

  退出充电

  结束通信 , 退出充电流程

  表 8 版本协商充电机状态转换表 (续)

  充电机

  触发条件

  物理连接完成

  T1 到时

  接收“车辆版本协商 ”

  充电机故障应中止充电或车辆断开 S2

  Tout0到时

  接收“协商成功 ”

  接收“协商失败 ”

  接收“继续协商 ”

  版本不一致

  版本 一致且为v1 . 1 . 0

  版本 一致且 ≥ v2 . 0 . 0

  有相同

  的版本号

  版本低于车辆

  版本高于车辆

  有更低的版本号

  无更低的版本号

  转换要求:

  1) Tout0 为版本协商阶段超时定时器 , 当充电机首次发送版本协商报文时开启 Tout0 定时器 , 超时时间为 10 s ;

  2) T1 为充电机发送“充电机版本协商”定时器 , 充电机发送 CVList(Ns)队列报文后重置 T1 定时器 , 周期为 50 ms ;

  3) CVList为充电机支持的协议版本队列 , 版本号从小到大排列 , Ns 为版本号索引 , 初始值指向最高版本号 ;

  4) “ —”表示充电机不作任何处理

  9

  GB/T 27930. 2— 20

  表 9 版本协商车辆状态转换表

  充电机

  触发条件

  物理连接完成

  T1 到时

  接收“充电机版本协商 ”

  接收

  CHM/CRM

  车辆故障应中止充电或充电机断开 S1

  Tout0到时

  接收“协商成功 ”

  接收“协商失败 ”

  接收“继续协商 ”

  版本不一致

  版本 一致且为v1 . 1 . 0

  版本 一致且 ≥ v2 . 0 . 0

  有相同

  的版本号

  版本低于车辆

  版本高于车辆

  有更低的版本号

  无更低的版本号

  状 态

  S0

  初始化

  发送“ 车 辆 版 本 协商 — 继续协商 — 协议版 本 号 = EVList (Ns) ”, 打 开 T1 、 Tout0 定 时 器 , 进入 S1

  —

  —

  —

  —

  —

  —

  —

  —

  —

  进入 S4

  —

  —

  24

  GB/T 27930. 2— 2024

  10

  表 9 版本协商车辆状态转换表 (续)

  充电机

  触发条件

  物理连接完成

  T1 到时

  接收“充电机版本协商 ”

  接收

  CHM/CRM

  车辆故障应中止充电或充电机断开 S1

  Touto到时

  接收“协商成功 ”

  接收“协商失败 ”

  接收“继续协商 ”

  版本不一致

  版本 一致且为v1 . 1 . o

  版本 一致且 ≥ v2 . o. o

  有相同

  的版本号

  版本低于车辆

  版本高于车辆

  有更低的版本号

  无更低的版本号

  状 态

  S1

  协商中

  —

  发送“ 车 辆 版本协商”' 协议版 本 号 = EVList(Ns)报文 ' 保持 S1

  协商结

  果 =“继

  续协

  商”' 保

  持 S1

  协商结

  果 =“协

  商成

  功”' 进

  入 S2

  协商结

  果 =“协

  商成

  功”' 进

  入 S3

  进入 S4

  协商结

  果 =“协

  商成

  功”' Ns

  指向该

  版本 ' 保

  持 S1

  保持 S1

  根据充电机

  “ 期望版本号 ”

  信息调整 Ns

  指向低于充

  电机期望版

  本中最高的版本 ' 保持 S1

  进入 S4

  进入 S4

  进入 S5

  进入S4

  S2

  附录 M

  协商成功

  发送“协商成功”' 关闭 T1 、Touto ' 进行附录 M通信

  S3成功

  持续发送“协商成功”' 进入功能协商阶段 ' 关闭 Touto ' 收到“充电机支持功能”后关闭 T1

  S4

  协商失败

  发送“协商失败”' 关闭 T1 、Touto ' 进行附录 M通信

  S5

  退出充电

  结束通信 ' 退出充电流程

  转换要求:

  1) Touto 为版本协商超时定时器 ' 当车辆首次发送版本协商报文时开启 Touto 定时器 ' 超时时间为 1o s ;

  2) T1 为车辆发送“车辆版本协商”定时器 ' 物理连接后启动 T1 定时器 ' 车辆发送 EVList 队列报文后重置 ' 周期 5o ms ;

  3) EVList为车辆支持的协议版本队列 ' 版本号从小到大排列 ' Ns 为版本号索引 ' 初始值指向最高版本号 ;

  4) “ —”表示车辆不作任何处理

  GB/T 27930.2—2024

  注 : 虚线框内容见功能协商阶段判断 。

  图 2 版本协商交互流程示意图

  8 传输层

  8. 1 通则

  8. 1. 1 传输层负责数据传输 、流量控制 、分组传输与接收帧顺序检查等 。

  8. 1.2 传输层消息类型包括不需要确认的短消息 、需要确认的短消息和长消息 ,具体为 :

  — 不需要确认的短消息 :消息长度不大于 8字节 ,面向简单不可靠信息的传输服务 ;

  11

  GB/T 27930.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)要求接收方应答确认 。若发送方没有接收到确认信息 , 发送方应进一步尝试 ,重发的时间间隔为 50 ms,直至达到应用层总发送时间 。需要确认的短消息的信息帧格式应符合表 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

  目的地址

  源地址

  0x00

  0x01

  被确认短消

  息参数组

  标识(应用

  层首字节)

  0xFF

  0xFF

  0xFF

  0xFF

  0xFF

  8.4 长消息

  8.4. 1 长 消 息 (LM) 的 传 输 应 符 合 8. 5 规 定 的 多 信 息 帧 传 输 方 式 , 其 信 息 帧 格 式 定 义 应 符 合 表 13

  12

  GB/T 27930.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

  总帧数

  总字节数

  0xFF

  0xFF

  0xFF

  0xFF

  帧序号 :>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

  待接收起始帧序号

  待接收总帧数

  0xFF

  0xFF

  0xFF

  0xFF

  0xFF

  LM_NACK:2

  0xFF

  0xFF

  0xFF

  0xFF

  0xFF

  0xFF

  0xFF

  LM_EndofACK:

  3

  接收的总帧数

  接收的总字节数

  0xFF

  0xFF

  0xFF

  0xFF

  LM_ACK(n,k)表示待接收起始帧序号为 n,待接收总帧数为 k 的长消息应答确认控制帧 。 k 为能接收的信息帧的帧数(取接收能力和剩余发送帧的二者较小值)

  8.5 多信息帧传输方式

  8.5. 1 功能分类

  长消息传输控制的主要功能为分包重组和连接管理 。

  8.5.2 分包重组

  8.5.2. 1 重组方式

  发送方首先将长消息拆分为多个信息帧 ,在建立连接后按序进行传输 。接收方接收到所有的信息

  13

  GB/T 27930.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) 应不小于 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 的长消息后 ,可选择接收或者拒绝建立连接 。若选择接收 ,应发送

  14

  GB/T 27930.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_End- ofACK,通知发送方连接关闭 。

  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/T 27930.2—2024

  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。

  16

  GB/T 27930. 2— 20

  表 15 发送方状态转换表

  发送方

  触发条件

  收到发送长消息的任务

  收到报文

  发送周期 LMS-T1 计时到

  接收报文超时 LMS-T2 计时到

  数据传输超时 LMS-T3计时到或主动中止传输

  LM-ACK(n, k)

  LM-

  NACK

  LM-

  Endof

  ACK

  当前发送帧非接收方请求的最后一帧报文且长消息未传送完毕 send-cnt< k—1 且 n+send-cnt

  -

  当前发送帧为接收方请求的最后一帧且长消息未传送完毕 send-cnt≥k—1且 n+send-cnt<

  lm tfra

  -

  当前发送帧

  为长消息最

  后一帧或已发送完毕

  n+send cnt -

  ≥lm tfra

  -

  err cnt<2 -

  err cnt≥2 -

  状 态

  S0空闲

  发送 LM(0) , err-cnt=0,开启 LMS- T2 、 LMS- T3 , 进入 S1

  —

  —

  —

  —

  —

  —

  —

  —

  —

  S1

  连接建立

  保 存 k , err - cnt 清 零 , send - cnt 清 零 , LMS- T1 开 启, LMS- T2 关闭 ,进入 S2

  进入 S5

  err - cnt 加1,发 送 LM

  ( 0 ) , 重 置LMS - T2 ,保持 S1

  发 送 LM - NACK,进入 S5

  发 送 LM - NACK, 进入 S5

  S2

  数据传输

  —

  保存 k,根 据 应 答 调 整发送 LM 的包序号为 n (不发送 报 文) , err- cnt清 零 , send - cnt 清 零 , LMS- T1 开 启, LMS- T2 关闭,保持 S2

  进入 S5

  —

  发送 LM(n+ send -cnt) , send- cnt 加

  1 , LMS- T1 重 置 ,保持 S2

  发送 LM(n+ send -cnt) , send- cnt 加

  1 , LMS- T1 关 闭 , LMS- T2 开 启, 进入 S3

  发 送 LM

  (lm - tfra) , send- cnt 加

  1 , LMS- T1关闭, LMS- T2 开 启,进入 S4

  —

  —

  发 送 LM - NACK, 进入 S5

  17

  24

  GB/T 27930. 2— 2024

  18

  表 15 发送方状态转换表 (续)

  发送方

  触发条件

  收到发送长消息的任务

  收到报文

  发送周期 LMS-T1 计时到

  接收报文超时 LMS-T2 计时到

  数据传输超时 LMS-T3计时到或主动中止传输

  LM-ACK(n, k)

  LM-

  NACK

  LM-

  Endof

  ACK

  当前发送帧非接收

  方请求的最后一帧

  报文且长消息未传

  送完毕 send-cnt<

  k—1 且 n+send-cnt

  -

  当前发送帧为接收方请求的最后一帧且长消息未传送完毕 send-cnt≥k—1且 n+send-cnt<

  lm tfra

  -

  当前发送帧

  为长消息最

  后一帧或已发送完毕

  n+send cnt -

  ≥lm tfra

  -

  err cnt<2 -

  err cnt≥2 -

  状 态

  S3

  等待应

  答确认

  保存 k,根 据 应 答 调 整发送 LM 的包序号为 n (不发送 报 文) , err- cnt清 零 , send - cnt 清 零 , LMS- T1 开 启, LMS- T2 关闭,进入 S2

  进入 S5

  err - cnt 加1,发 送 LM ( n + k —

  1 ) , 保 持

  S3 , 重 置LMS T2

  -

  发 送 LM - NACK,进入 S5

  发 送 LM - NACK, 进入 S5

  S4

  等待结

  束确认

  —

  根据应答调整发送 LM的包 序 号 为 n(不 发 送报 文) , err - cnt 清 零 , send - cnt 清 零 , LMS- T1 开 启, LMS- T2 关闭 ,进入 S2

  进入 S5

  进入 S5

  —

  —

  —

  err - cnt 加1,发 送 LM (lm - tfra) ,保持 S4 , 重置 LMS-T2

  发 送 LM - NACK,进入 S5

  发 送 LM - NACK, 进入 S5

  S5

  连接关闭

  关闭 LMS-T1 、LMS-T2 、LMS-T3 定时器 , err-cnt、send-cnt清零,进入空闲状态

  其中 :

  1) err-cnt为接收超时计数 ;

  2) send-cnt为一次传输中发送帧数计数器,初始值为 0,每发送完成一帧,计数器加 1 ;

  3) LMS-T1 为一次传输中信息帧按序发送时间间隔,5 ms≤LMS-T1≤10 ms,每个信息帧发送后重置 ;

  4) LMS-T2 为接收信息帧或控制帧超时计时器,超时时间为 100 ms ;

  5) LMS-T3 为长消息传输计时器,发送首帧 LM(0)报文开启,默认 10 s,如应用层定义报文总发送时间,则以应用层定义为准 ;

  6) lm-tfra为长消息发送总帧数

  19

  GB/T 27930. 2— 20

  表 16 接收方状态转换表

  接收方

  触发条件

  收到报文 LM(0)

  LM(i)

  LM N -

  ACK

  接收报文超时 LMS-T2 计时到

  暂停接收

  数据传输超时

  LMS T3 -

  计时到或主动中止传输

  长消息已接收完

  recv tfra

  -

  =lm tfra

  -

  接收帧序号不连续

  接收请求的最后一帧 i =

  recv-no+1 且 recv-num≥k—1

  未接收完

  i = recv no+ -

  1 且 recv-num

  recv tfra+1 -

  -

  收到重复

  报文 i<

  recv no+1

  -

  漏收报文

  i>recv no -

  +1 且

  recv tfra

  -

  -

  接收长消息最后一帧

  recv tfra+1 -

  =lm tfra -

  非长消息最后一帧

  recv tfra+1 -

  -

  err cnt

  -

  <2

  err cnt

  -

  ≥2

  状 态

  S0空闲

  保 存 lm - tfra, 发 送LM- ACK( 1 , k) , 开启 LMS- T2 、LMS- T3 , recv - no 清 零 , recv- num 清 零 , recv -tfra清零 , err-cnt 清零,进入 S1

  —

  —

  —

  —

  —

  —

  —

  —

  —

  —

  —

  S1接收数据

  保 存 lm - tfra, 发 送LM- ACK( 1 , k) , 重置 LMS-T2 , recv- no清 零 , recv - num 清零 , recv-tfra 清零,保持 S1

  recv tfra

  -

  置为 lm - tfra,发送

  LM End-

  -

  ofACK,

  进入 S2

  发送 LM-

  ACK( recv

  - no + 1 ,

  k ) , recv - num清零,保持 S1

  recv-tfra 置为lm- tfra, 发 送

  LM End-

  -

  ofACK,进入S2

  重 置 LMS - T2 , err-cnt 清0 , recv - no 置为 i,发送 LM - ACK(i + 1 ,

  k) , recv - num清 零 , recv - tfra 加 1 , 保持 S1

  重置 LMS- T2 , err - cnt清 0 , recv - no 置 为 i , recv num

  -

  加 1 , recv - tfra加 1,保持 S1

  进入 S2

  重置 LMS

  - T2 , err - cnt 加 1 ,发送 LM- ACK(recv

  - no + 1 , k ) , 保持 S1

  发 送LM

  - NACK,进入 S2

  重置 LMS - T2 , err - cnt 清 0 ,发送 LM- ACK(recv

  - no , 1 ) ,保持 S1

  发送LM -NACK,进入S2

  S2

  连接

  关闭

  连接关闭,所有计数器(recv-no, recv-num, err-cnt)清零,所有定时器(LMS-T2, LMS-T3)关闭

  24

  GB/T 27930. 2— 2024

  20

  表 16 接收方状态转换表 (续)

  接收方

  触发条件

  收到报文 LM(0)

  LM(i)

  LM N —

  ACK

  接收报文超时 LMS—T2 计时到

  暂停接收

  数据传输超时

  LMS T3 —

  计时到或主动中止传输

  长消息已接收完

  recv tfra

  —

  =lm tfra

  接收帧序号不连续

  接收请求的最后一帧 i =

  recv—n0+1 且 recv—num≥k—1

  未接收完

  i = recv n0+

  1 且 recv—num

  recv tfra+1

  —

  收到重复

  报文 i<

  recv n0+1

  —

  漏收报文

  i>recv n0 —

  +1 且

  recv tfra

  —

  —

  接收长消息最后一帧

  recv tfra+1

  =lm tfra —

  非长消息最后一帧

  recv tfra+1

  —

  err cnt

  —

  <2

  err cnt

  —

  ≥2

  其中 :

  1) err—cnt为接收超时计数 ;

  2) recv—n0 为接收信息帧帧号 ;

  3) recv—num 为当前请求接收有效信息帧帧数 ;

  4) recv—tfra为当前连接接收总的有效信息帧帧数 ;

  5) LMS—T2 为接收信息帧或控制帧超时计时器,超时时间为 100 ms ;

  6) LMS—T3 为长消息传输计时器,接收首帧 LM(0)报文开启,默认 10 s,如应用层定义报文总发送时间,则以应用层定义为准 ;

  7) lm—tfra为长消息组成应用层的总帧数

  GB/T 27930.2—2024

  注 : SntCnt、RcvCnt分别为发送方计数器和接收方计数器 。

  图 3 长消息交互示例

  9 应用层

  9. 1 总体要求

  9. 1. 1 应用层报文应采用参数组标识(PGI)对参数组进行编号 ,各节点根据 PGI识别报文内容 。

  21

  GB/T 27930.2—2024

  9. 1.2 通信双方应按实际数据发送报文 ,除非另有规定 。

  9. 1.3 接收方接收到非本文件定义的报文 、本文件未规定的参数值或参数值超出本文件规定数据范围时 ,应忽略该信息 ,除非另有规定 。

  9. 1.4 接收方接收到的参数值为本文件定义的 “预留 ”值或 “无效 ”值时 ,应不处理该参数 。

  9. 1.5 传输的数据类型应符合表 17的规定 ,应采用小端模式传递数字信息 。

  9. 1.6 各功能模块状态

29139382529
下载排行 | 下载帮助 | 下载声明 | 信息反馈 | 网站地图  360book | 联系我们谢谢