GBT27930電動(dòng)汽車非車載充電機(jī)與電池理系統(tǒng)的通信協(xié)議第2部分：ChaoJi充電系統(tǒng)

中華人民共和國國家標(biāo)準(zhǔn)

GB/T27930—xxxx

電動(dòng)汽車非車載傳導(dǎo)式充電機(jī)與車輛

之間的數(shù)字通信協(xié)議第2部分：

ChaoJi充電系統(tǒng)

Communicationprotocolsbetweenoff-boardconductivecharger

andelectricvehiclePart2：ChaoJiSystem

（征求意見稿）

××××-××-××發(fā)布××××-××-××實(shí)施

前言

GB/T27930《電動(dòng)汽車非車載傳導(dǎo)式充電機(jī)與車輛之間的數(shù)字通信協(xié)議》分為2個(gè)部

分：

——第1部分：GB/T2015系統(tǒng)；

——第2部分：ChaoJi充電系統(tǒng)

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

本部分按照GB/T1.1—2020的規(guī)定起草。

請(qǐng)注意本部分的某些內(nèi)容可能涉及專利。本部分的發(fā)布機(jī)構(gòu)不承擔(dān)識(shí)別專利的責(zé)任。

本部分由中國電力企業(yè)聯(lián)合會(huì)提出并歸口。

本部分起草單位：。

本部分主要起草人：。

II

GB/T27930-xxxx

電動(dòng)汽車非車載傳導(dǎo)式充電機(jī)與車輛之間的數(shù)字通信協(xié)議第2部分

ChaoJi充電系統(tǒng)

1范圍

本部分規(guī)定了電動(dòng)汽車非車載傳導(dǎo)式充電機(jī)（以下簡(jiǎn)稱充電機(jī)）充電通信控制器（SupplyEquipment

CommunicationController，以下簡(jiǎn)稱SECC）與車輛充電通信控制器（ElectricVehicleCommunication

Controller，以下簡(jiǎn)稱EVCC）之間基于控制器局域網(wǎng)（ControlAreaNetwork，以下簡(jiǎn)稱CAN）的通信物

理層、數(shù)據(jù)鏈路層及應(yīng)用層的定義。

本部分適用于采用GB/T18487.1附錄D規(guī)定的充電模式4的充電機(jī)與車輛之間的通信，也適用于充電機(jī)

與具有充電控制功能的車輛電子控制單元之間的通信。

2規(guī)范性引用文件

下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中，注日期的引用文件，

僅該日期對(duì)應(yīng)的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文

件。

GB/T19596電動(dòng)汽車術(shù)語

GB/T29317電動(dòng)汽車充換電設(shè)施術(shù)語

GBT18487.1電動(dòng)汽車傳導(dǎo)充電系統(tǒng)第1部分通用要求

ISO11898-1:2003道路車輛控制器局域網(wǎng)絡(luò)第1部分：數(shù)據(jù)鏈路層和物理信令（Roadvehicle–Control

areanetwork(CAN)Part1:Datalinklayerandphysicalsignaling）

SAEJ1939-11:2006商用車控制系統(tǒng)局域網(wǎng)CAN通信協(xié)議第11部分：物理層，250K比特/秒，屏蔽雙絞

線（RecommentedpracticeforserialcontrolandcommunicationvehiclenetworkPart11:Physicallayer–250K

bits/s,twistedshieldedpair）

SAEJ1939-21:2006商用車控制系統(tǒng)局域網(wǎng)CAN通信協(xié)議第21部分：數(shù)據(jù)鏈路層（Recommendedpractice

forserialcontrolandcommunicationvehiclenetworkPart21:Datalinklayer）

3術(shù)語和定義

GB/T19596、GB/T29317界定的以及下列術(shù)語和定義適用于本部分。

3.1

幀frame

組成一個(gè)完整信息的一系列數(shù)據(jù)位。

3.2

CAN數(shù)據(jù)幀CANdataframe

用于傳輸數(shù)據(jù)的CAN協(xié)議所必需的有序位域，以幀起始（SOF）開始，幀結(jié)束（EOF）結(jié)尾。

3.3

CAN報(bào)文CANmessage

發(fā)送或接收參數(shù)組及其參數(shù)數(shù)據(jù)的一個(gè)實(shí)例，一個(gè)報(bào)文的發(fā)送可能需要交互一個(gè)或多個(gè)CAN數(shù)據(jù)幀。

1

GB/T27930-xxxx

3.4

標(biāo)識(shí)符identifier

CAN仲裁域的標(biāo)識(shí)部分。

3.5

擴(kuò)展幀extendedframe

CAN2.0B規(guī)范中定義的使用29位標(biāo)識(shí)符的CAN數(shù)據(jù)幀。

3.6

優(yōu)先權(quán)priority

在標(biāo)識(shí)符中一個(gè)3位的域，設(shè)置傳輸過程的仲裁優(yōu)先級(jí)，最高優(yōu)先權(quán)為0級(jí)，最低優(yōu)先權(quán)為7級(jí)。

3.7

參數(shù)組parametergroup(PG)

在應(yīng)用層傳輸?shù)膮?shù)集合，分為命令類和信息類。

3.8

參數(shù)組標(biāo)識(shí)parametergroupidentification(PGI)

用于唯一標(biāo)識(shí)一個(gè)參數(shù)組的一個(gè)字節(jié)。

3.9

協(xié)議數(shù)據(jù)單元protocoldataunit(PDU)

一種特定的CAN數(shù)據(jù)幀格式。

3.10

傳輸協(xié)議transportprotocol

基于數(shù)據(jù)鏈路層上用于傳輸數(shù)據(jù)的一種機(jī)制。

3.11

電子控制單元electroniccontrolunit(ECU)

電子控制單元，即車載電腦，由微控制器和外圍電路組成。

3.12

功能模塊functionmodule

電動(dòng)汽車與充電設(shè)施間能量交互過程中的某個(gè)業(yè)務(wù)功能。

3.13

必須項(xiàng)功能模塊mandatoryfunctionmodule

一個(gè)完整的能量交互過程中必須具有的功能模塊。

3.14

可選項(xiàng)功能模塊optionalfunctionmodule

一個(gè)完整的能量交互過程中可選擇具有的功能模塊。

3.15

可重載功能模塊（overridefunctionmodule）

可被重新定義或替換的功能模塊。

3.16

功能代碼functioncode(FC)

為功能模塊分配的編號(hào)。

3.17

功能描述碼functiondescriptioncode(FDC)

功能模塊具備特定功能的編號(hào)。

3.18

信息幀informationframe(IF)

2

GB/T27930-xxxx

數(shù)據(jù)鏈路層上用于傳輸有效信息或數(shù)據(jù)的CAN數(shù)據(jù)幀。

3.19

控制幀controlframe(CF)

數(shù)據(jù)鏈路層上用于進(jìn)行流量控制和差錯(cuò)管理的CAN數(shù)據(jù)幀。

3.20

多信息幀傳輸方式

使用自動(dòng)重傳請(qǐng)求方式傳輸具有幀編號(hào)的一幀或多幀數(shù)據(jù)的方式。

3.21

長消息longmessage

采用多信息幀傳輸方式傳輸?shù)南ⅰ?/p>

3.22

充電服務(wù)內(nèi)容chargingservice

由充電場(chǎng)景和充電功能共同決定的充電應(yīng)用。

3.23

需要確認(rèn)的短消息reliableshortmessage

采用自動(dòng)重傳請(qǐng)求方式傳輸不具有幀編號(hào)的單幀數(shù)據(jù)。

3.24

不需要確認(rèn)的短消息unreliableshortmessage

不需要自動(dòng)重傳請(qǐng)求方式傳輸不具有幀編號(hào)的單幀數(shù)據(jù)。

4縮略語

LM長消息longmessage

SM短消息shortmessage

SM_RM需要確認(rèn)的短消息reliableshortmessage

SM_URM不需要確認(rèn)的短消息unreliableshortmessage

SM_ACK短消息應(yīng)答確認(rèn)消息shortframeacknowledge

LM_ACK長消息應(yīng)答確認(rèn)longframeacknowledge

LM_NACK長消息放棄連接確認(rèn)longframenegativeacknowledge

LM_EndACK長消息接收結(jié)束確認(rèn)longframeendofacknowledge

5物理層

本部分采用的CAN通信網(wǎng)絡(luò)物理層應(yīng)符合SAEJ1939-11:2006、SAEJ1939-11:2006中關(guān)于物理層的規(guī)

定，使用獨(dú)立的CAN總線，并應(yīng)支持SECC、EVCC、適配器通信控制器（VehicleAdaptorCommunication

Controller，以下簡(jiǎn)稱VACC）三個(gè)節(jié)點(diǎn)，通信速率采用250kbit/s。

為了減少外界干擾對(duì)總線通信的影響，本部分采用的CAN通信網(wǎng)絡(luò)應(yīng)使用屏蔽雙絞線進(jìn)行組網(wǎng)和布線，

CAN通訊線屏蔽層宜在充電機(jī)側(cè)接地，相應(yīng)的車輛側(cè)CAN通訊線屏蔽層也宜在CAN總線端部接地。

6數(shù)據(jù)鏈路層

6.1幀格式

3

GB/T27930-xxxx

采用本部分的設(shè)備應(yīng)使用CAN擴(kuò)展幀的29位標(biāo)識(shí)符，具體每個(gè)位分配的相應(yīng)定義應(yīng)符合SAEJ1939-

21:2006中的相關(guān)規(guī)定。

6.2協(xié)議數(shù)據(jù)單元

每個(gè)CAN數(shù)據(jù)幀包含一個(gè)單一的協(xié)議數(shù)據(jù)單元（PDU），見表1。協(xié)議數(shù)據(jù)單元由七部分組成，分別是

優(yōu)先權(quán)，擴(kuò)展數(shù)據(jù)頁，數(shù)據(jù)頁，PDU格式，PDU特定，源地址和數(shù)據(jù)域。

表1協(xié)議數(shù)據(jù)單元

D…

EDP

PPPFPSSADATA

3118880-64

數(shù)據(jù)格式要求：

1）P為優(yōu)先權(quán)：從最高0設(shè)置到最低7。

2）EDP為擴(kuò)展數(shù)據(jù)頁：備今后擴(kuò)展使用，本部分中為0。

3）DP為數(shù)據(jù)頁：用來選擇參數(shù)組描述的輔助頁，本部分中為0。

4）PF為PDU格式消息類型：用來確定PDU的格式，以及數(shù)據(jù)域?qū)?yīng)的參數(shù)組編號(hào)。

5）PS為PDU特定格式：PS值取決于PDU格式。本部分中采用PDU1格式，PS值為目標(biāo)地址。

6）SA為源地址：數(shù)據(jù)幀的源地址。

7）DATA為數(shù)據(jù)域：不同消息類型的的數(shù)據(jù)域定義詳見本部分8.2的規(guī)定。

6.3地址分配

網(wǎng)絡(luò)地址用于保證信息標(biāo)識(shí)符的唯一性以及表明信息的來源。SECC、EVCC和適配器定義為不可配置

地址，即該地址固定在ECU的程序代碼中，包括服務(wù)工具在內(nèi)的任何手段都不能改變其源地址。SECC、

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

表2地址分配

節(jié)點(diǎn)首選地址

SECC86(56H)

EVCC244(F4H)

VACC201(C9H)

6.4幀類型

本部分規(guī)定的幀類型包括信息幀、控制幀2類。

7版本協(xié)商

7.1總體描述

版本協(xié)商是通信協(xié)議的引導(dǎo)部分，協(xié)商原則、報(bào)文定義和信息交互過程固定不變。版本協(xié)商過程中，

充電機(jī)和車輛通過協(xié)商決定通信協(xié)議版本號(hào)。版本協(xié)商的具體描述如表3所示。

表3版本協(xié)商總體描述

序號(hào)項(xiàng)目描述信息

1名稱版本協(xié)商

2目標(biāo)充電機(jī)和車輛協(xié)商決定通信協(xié)議版本號(hào)。

4

GB/T27930-xxxx

通信鏈路建立之后，雙方進(jìn)行通信協(xié)議版本協(xié)商，車輛檢測(cè)是否支持充電機(jī)發(fā)送

的版本，返回協(xié)商結(jié)果。

充電機(jī)首先應(yīng)發(fā)送其支持的最高協(xié)議版本號(hào)：

-如果車輛支持該版本并確定以該版本進(jìn)行通信，返回“協(xié)商成功”信息給充電機(jī)；

-如果車輛不支持該版本且該版本低于車輛支持的最低版本，返回“協(xié)商失敗”信息

給充電機(jī)；

3描述-如果車輛不支持該版本且該版本高于車輛支持的最低版本，將“繼續(xù)協(xié)商”信息，

連同期望的版本號(hào)一起返回給充電機(jī)；

充電機(jī)接收到“繼續(xù)協(xié)商”信息后，

-如果當(dāng)前發(fā)送版本已是充電機(jī)支持的最低版本，繼續(xù)發(fā)送當(dāng)前版本，等待超時(shí)協(xié)

商失敗；

-如果充電機(jī)支持車輛期望的版本，則發(fā)送該版本號(hào)，協(xié)商成功；

如果樁不支持車輛期望的版本，則發(fā)送比當(dāng)前版本低的最高版本，繼續(xù)協(xié)商。

4前置條件物理連接完成，通信鏈路建立。

為了提高兼容性，充電機(jī)和車輛可支持多個(gè)版本的通信協(xié)議。協(xié)商成功時(shí)，雙方

支持相同的協(xié)議版本，否則協(xié)商失敗。

通信協(xié)議版本號(hào)由CAN類型、主版本號(hào)、次版本號(hào)、臨時(shí)版本號(hào)組成。

5要求-當(dāng)前CAN類型為CAN2.0，同時(shí)可支持未來擴(kuò)展至CANFD，CANXL等；

-一般來說，主版本號(hào)在通信協(xié)議有結(jié)構(gòu)性的變化（如功能模塊有變化）時(shí)更新；

-次版本號(hào)在通信協(xié)議有較大功能變化時(shí)更新；

-臨時(shí)版本僅用于示范項(xiàng)目和測(cè)試臨時(shí)用途，正式發(fā)布的版本中臨時(shí)版本號(hào)為0。

協(xié)商成功：車輛發(fā)送“協(xié)商成功”，雙方按照協(xié)商一致的協(xié)議版本進(jìn)行信息交

互。

6結(jié)束條件協(xié)商失?。喊?，

-版本協(xié)商失敗，車輛發(fā)送“協(xié)商失敗”，雙方退出本次通信過程；

-版本協(xié)商超時(shí)，車輛發(fā)送“協(xié)商失敗”，雙方退出本次通信過程。

7.2報(bào)文定義

版本協(xié)商的交互報(bào)文的數(shù)據(jù)鏈路層應(yīng)滿足本部分第6章的規(guī)定。版本協(xié)商過程包括“充電機(jī)協(xié)議版本”

“車輛協(xié)商結(jié)果”報(bào)文，其幀格式定義如表4，表5所示。

表4充電機(jī)協(xié)議版本幀格式

協(xié)議數(shù)

PEDPDPPFPSSA數(shù)據(jù)域

據(jù)單元

占位

31188888888888

（bit）

0xF40x56

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

（目的地址）（源地址）

表5車輛協(xié)商結(jié)果幀格式

協(xié)議數(shù)

PEDPDPPFPSSA數(shù)據(jù)域

據(jù)單元

占位

31188888888888

（bit）

5

GB/T27930-xxxx

0x560xF4

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

（目的地址）（源地址）

表6充電機(jī)協(xié)議版本數(shù)據(jù)域內(nèi)容

序號(hào)參數(shù)內(nèi)容長度數(shù)據(jù)類型參數(shù)類型描述與要求

1CAN類型1字節(jié)BYTECANType充電機(jī)CAN類型，當(dāng)前版本采用CAN2.0通信。

充電機(jī)支持的協(xié)議版本號(hào)，本部分規(guī)定當(dāng)前版本

為V2.0.0，如果車輛的協(xié)商結(jié)果為“繼續(xù)協(xié)商”，

2協(xié)議版本號(hào)3字節(jié)BYTE[3]ProtocolVersionType

而充電機(jī)沒有其他可支持的版本，則繼續(xù)發(fā)送當(dāng)

前版本號(hào)。

3預(yù)留1字節(jié)BYTEReservedType接收方不判斷該值

4預(yù)留1字節(jié)BYTEReservedType接收方不判斷該值

5預(yù)留1字節(jié)BYTEReservedType接收方不判斷該值

報(bào)文校驗(yàn)碼，從第1個(gè)字節(jié)至第7個(gè)字節(jié)的累加

6校驗(yàn)碼1字節(jié)BYTECheckcodeType

和

表7車輛協(xié)商結(jié)果數(shù)據(jù)域內(nèi)容

序號(hào)參數(shù)內(nèi)容長度數(shù)據(jù)類型參數(shù)類型描述與要求

1CAN類型1字節(jié)BYTECANType車輛CAN類型，當(dāng)前版本采用CAN2.0通信。

車輛版本協(xié)商結(jié)果，包括“繼續(xù)協(xié)商”，“協(xié)商成

2協(xié)商結(jié)果1字節(jié)BYTEVersionResultType

功”，“協(xié)商失敗”。

車輛期望或協(xié)商一致的版本號(hào)。

如果車輛協(xié)商結(jié)果為“協(xié)商成功”時(shí)，值為雙方

協(xié)商一致的版本號(hào)；

3協(xié)商版本號(hào)3字節(jié)BYTE[3]ProtocolVersionType如果車輛協(xié)商結(jié)果為“繼續(xù)協(xié)商”，值為車輛期望

的版本號(hào)；

如果車輛協(xié)商結(jié)果為“協(xié)商失敗”值為

0xFFFFFF；

4預(yù)留1字節(jié)BYTEReservedType接收方不判斷該值。

5預(yù)留1字節(jié)BYTEReservedType接收方不判斷該值

6校驗(yàn)碼1字節(jié)BYTECheckcodeType報(bào)文校驗(yàn)碼，第1個(gè)字節(jié)至第7個(gè)字節(jié)的累加和

7.3報(bào)文交互過程

物理連接完成，充電機(jī)閉合S1后開始發(fā)送“充電機(jī)協(xié)議版本”報(bào)文。充電機(jī)首先發(fā)送其支持的最高

協(xié)議版本號(hào)，車輛接收并檢查自身支持的版本號(hào)返回版本協(xié)商結(jié)果。如果“繼續(xù)協(xié)商”，雙方繼續(xù)以較低的

協(xié)議版本號(hào)進(jìn)行協(xié)商；如果“協(xié)商成功”，雙方按照協(xié)商一致的版本的通信協(xié)議進(jìn)行信息交互；如果“協(xié)

商失敗”，雙方退出本次通信過程。

完整的狀態(tài)轉(zhuǎn)換過程如表8，表9所示。

表8充電機(jī)狀態(tài)轉(zhuǎn)換表

觸發(fā)條件

充電機(jī)T1定時(shí)器接收接收接收T2定時(shí)收到

到“協(xié)商成功”“協(xié)商失敗”“繼續(xù)協(xié)商”器到非法幀

狀S0發(fā)送CvList-----

6

GB/T27930-xxxx

態(tài)(初始狀態(tài))（Ns），進(jìn)

入S1

根據(jù)車輛“期望

版本號(hào)”信息調(diào)

整Ns指向（如

果支持，則Ns

指向該版本號(hào)，進(jìn)入S3，

S1發(fā)送CvList關(guān)閉T1,T2，進(jìn)關(guān)閉T1,T2進(jìn)

如不支持，則指關(guān)閉T1，-

（協(xié)商中）（Ns）入S2入S3

向等于前一個(gè)T2

更低版本，如

Ns已為第一個(gè)

則Ns不變），保

持S1

S2

發(fā)送協(xié)商成功

（協(xié)商成功，-進(jìn)入功能協(xié)商進(jìn)入S3--

的版本

進(jìn)入功能協(xié)商）

S3

------

（協(xié)商失敗，終止）

注1：.T1為充電機(jī)發(fā)送定時(shí)器，當(dāng)S1合上后啟動(dòng)T1定時(shí)器，周期50ms

注2：.T2為版本協(xié)商超時(shí)定時(shí)器，當(dāng)S1合上后啟動(dòng)T2定時(shí)器，默認(rèn)為5s

注3：CVList：充電機(jī)支持的協(xié)議版本隊(duì)列，版本號(hào)從小到大排列，Ns為計(jì)數(shù)器，初始值指向最高版本號(hào)

注4：.-表示充電機(jī)不作任何處理

注5：非法幀為表中未列舉的所有報(bào)文，包括版本協(xié)商報(bào)文以外的其他報(bào)文或不滿足交互原則的版本內(nèi)容等。

表9車輛狀態(tài)轉(zhuǎn)換表

觸發(fā)條件

接收到CvList接收到

車輛收到

有相同的版有更低的版本沒有更低的版“功能協(xié)商T2定時(shí)器到

非法幀

本號(hào)號(hào)本號(hào)報(bào)文”

發(fā)送“繼續(xù)協(xié)

發(fā)送“協(xié)商

S1商”，版本號(hào)為發(fā)送“協(xié)商失發(fā)送“協(xié)商失敗”,

成功”，進(jìn)--

（協(xié)商中）最接近的低版敗”，進(jìn)入S3終止

入S2

本號(hào)

發(fā)送“繼續(xù)協(xié)

狀

S2發(fā)送“協(xié)商商”，版本號(hào)為發(fā)送“協(xié)商失進(jìn)入發(fā)送“協(xié)商失敗”,

態(tài)-

（協(xié)商成功）成功”最接近的低版敗”，進(jìn)入S3功能協(xié)商終止

本號(hào)，進(jìn)入S1

發(fā)送

S3發(fā)送“協(xié)商發(fā)送“協(xié)商失發(fā)送“協(xié)商失發(fā)送“協(xié)商失敗”,

“協(xié)商失-

（協(xié)商失敗）失敗”敗”敗”終止

敗”

注1：T2為版本協(xié)商超時(shí)定時(shí)器，當(dāng)S1合上后啟動(dòng)T2定時(shí)器，默認(rèn)為5s

注2：CVList：充電機(jī)支持的協(xié)議版本隊(duì)列，版本號(hào)從小到大排列，Ns為計(jì)數(shù)器，初始值指向最高版本號(hào)

注3：-表示充電機(jī)不作任何處理

注4：非法幀為所有狀態(tài)表未列舉的報(bào)文，如版本協(xié)商報(bào)文以外的其他報(bào)文或不滿足交互原則的版本內(nèi)容。

7

GB/T27930-xxxx

圖1給出了版本協(xié)商的報(bào)文交互過程。

充電機(jī)電動(dòng)汽車

開始版本交互開始版本交互

版本號(hào)設(shè)為其支

持的最高版本

發(fā)送充電機(jī)協(xié)議

版本報(bào)文

是否收到

超時(shí)否

超時(shí)處理充電機(jī)協(xié)議版本

報(bào)文

是

是否支持接收的

發(fā)送的版本改為

版本號(hào)是

低于當(dāng)前版本支協(xié)商成功

持的最高版本，

若無則繼續(xù)發(fā)送

否

當(dāng)前版本

接收的版本號(hào)是

是否低于車輛支持

最低版本協(xié)商失敗

否

繼續(xù)協(xié)商

發(fā)送車輛協(xié)商結(jié)

果報(bào)文

否是否收到協(xié)商超時(shí)

超時(shí)處理

結(jié)果報(bào)文

協(xié)商結(jié)果是否繼續(xù)是

協(xié)商

是

是否

接收協(xié)商結(jié)果

是否繼續(xù)協(xié)商

否

版本協(xié)商結(jié)束版本協(xié)商結(jié)束

圖1版本協(xié)商報(bào)文交互

8傳輸層

8.1消息類型

8.1.1分類

傳輸層負(fù)責(zé)數(shù)據(jù)傳輸和流量控制，如流量控制、分組編號(hào)與順序檢查等。本部分規(guī)定的消息類型包括

長消息、需要確認(rèn)的短消息、不需要確認(rèn)的短消息。長消息、需要確認(rèn)的短消息為上層應(yīng)用提供可靠性傳

輸服務(wù)，不需要確認(rèn)的短消息則面向簡(jiǎn)單不可靠信息的傳輸服務(wù)。

8.1.2長消息

8

GB/T27930-xxxx

長消息(LM)的發(fā)送應(yīng)遵循8.2規(guī)定的多信息幀傳輸方式，其信息幀格式定義如表10所示。

表10長消息的信息幀格式

協(xié)議數(shù)

PEDPDPPFPSSA數(shù)據(jù)域

據(jù)單元

占位

31188888888888

（bit）

總字

目的源幀的序號(hào)：0總幀數(shù)0xFF0xFF0xFF0xFF

定義0x06000x01節(jié)數(shù)

地址地址

幀的序號(hào)：>0應(yīng)用層參數(shù)組，最后一幀不足8字節(jié)的，填充0xFF

注1：為了描述方便，通常用LM（0）表示幀序號(hào)為0的長消息信息幀；LM（n）表示幀序號(hào)為n（n>0）的長消息信息幀。

注2：總幀數(shù)為包括LM（0）和應(yīng)用層參數(shù)組在內(nèi)傳輸?shù)乃袔瑪?shù)。

注3：總字節(jié)數(shù)為長消息應(yīng)用層參數(shù)組長度，不含幀序號(hào)、不含最后一幀不足8字節(jié)填充的0xFF

長消息的控制幀用于差錯(cuò)控制和流量控制，包括3類：

-長消息應(yīng)答確認(rèn)LM_ACK

-長消息放棄連接確認(rèn)LM_NACK

-長消息接收結(jié)束確認(rèn)LM_EndACK

其中LM_ACK，LM_EndACK是接收方對(duì)發(fā)送方的確認(rèn)響應(yīng)，LM_NACK是接收方或發(fā)送方發(fā)送給對(duì)

方的放棄連接確認(rèn)。長消息的控制幀格式定義如表11所示。

表11長消息的控制幀格式

協(xié)議數(shù)D

PEDPPFPSSA數(shù)據(jù)域

據(jù)單元P

占位

31188888888888

（bit）

待接收

待接收

目LM_ACK：1起始幀0xFF0xFF0xFF0xFF0xFF

源總幀數(shù)

的序號(hào)

定義3000x04地

地LM_NACK：20xFF0xFF0xFF0xFF0xFF0xFF0xFF

址

址接收的接收的

LM_EndACK：30xFF0xFF0xFF0xFF

總幀數(shù)總字節(jié)數(shù)

注1：為了描述方便，通常用LM_ACK（n,k）表示待接收起始幀序號(hào)為n，待接收總幀數(shù)為k的長消息應(yīng)答確認(rèn)控制幀。

8.1.3需要確認(rèn)的短消息

需要確認(rèn)的短消息(SM_RM)要求接收方應(yīng)答確認(rèn)。一個(gè)需要確認(rèn)的短消息的重發(fā)次數(shù)應(yīng)限制在3次，

即總的發(fā)送次數(shù)最多為4次。如果發(fā)送方在發(fā)送4次后仍然沒有接收到確認(rèn)信息，發(fā)送方應(yīng)該放棄進(jìn)一步嘗

試，重發(fā)的時(shí)間間隔為100ms~250ms。需要確認(rèn)的短消息消息幀格式如表12所示，應(yīng)答確認(rèn)（控制幀）格

式定義如表13所示。

表12需要確認(rèn)的短消息的信息幀格式

協(xié)議數(shù)

PEDPDPPFPSSA數(shù)據(jù)域

據(jù)單元

占位

31188888888888

（bit）

目的源

定義0x04000x02遵循應(yīng)用層定義，不足8字節(jié)的填充0xFF。

地址地址

9

GB/T27930-xxxx

表13需要確認(rèn)的短消息的控制幀格式

協(xié)議數(shù)

PEDPDPPFPSSA數(shù)據(jù)域

據(jù)單元

占位

31188888888888

（bit）

源

0x0目的

定義000x04地010xFF0xFF0xFF0xFF0xFF0xFF

3地址

址

8.1.4不需要確認(rèn)的短消息

不需要確認(rèn)的短消息(SM_URM)無需接收方應(yīng)答確認(rèn)，上層應(yīng)用中循環(huán)發(fā)送的報(bào)文通常為不需要確認(rèn)

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

表14不需要確認(rèn)的短消息的信息幀定義

協(xié)議數(shù)

PDPDPPFPSSA數(shù)據(jù)域

據(jù)單元

占位

31188888888888

（bit）

目的源

定義0x06000x03遵循應(yīng)用層定義，不足8字節(jié)的填充0xFF。

地址地址

8.2多信息幀傳輸方式

8.2.1原則

長消息的傳輸控制分為兩個(gè)主要功能：分包重組以及連接管理。

8.2.2分包重組

當(dāng)長消息的數(shù)據(jù)域長度大于8字節(jié)時(shí)，發(fā)送方應(yīng)將其拆分為若干個(gè)小的數(shù)據(jù)幀，然后按序逐一傳輸。接

收方接收到所有的數(shù)據(jù)幀后再重組成原始信息。

（1）數(shù)據(jù)幀

為了保證每個(gè)數(shù)據(jù)幀能被識(shí)別和重組，信息幀數(shù)據(jù)域的首字節(jié)定義為數(shù)據(jù)幀的序號(hào)，序號(hào)范圍為1~255，

因此最長的數(shù)據(jù)長度是1785個(gè)字節(jié)。數(shù)據(jù)幀序號(hào)為0時(shí)，表示發(fā)送方請(qǐng)求建立長消息傳輸?shù)奶摂M連接。

（2）序號(hào)

序號(hào)是在拆裝時(shí)分配給數(shù)據(jù)幀的，接收方接收后，利用序號(hào)把數(shù)據(jù)幀重組回原始信息。數(shù)據(jù)幀從編號(hào)

為１的數(shù)據(jù)幀開始按編號(hào)遞增順序發(fā)送。

（3）數(shù)據(jù)拆裝

數(shù)據(jù)拆裝用于數(shù)據(jù)域大于8字節(jié)的消息。信息的數(shù)據(jù)幀發(fā)送間隔時(shí)間LMS_T1應(yīng)小于10ms（待討論）。

接收者應(yīng)確定這些數(shù)據(jù)幀具有相同的參數(shù)標(biāo)識(shí)。

每個(gè)數(shù)據(jù)幀（除了最后一個(gè)數(shù)據(jù)幀）都裝載著原始數(shù)據(jù)中的7個(gè)字節(jié)，最后一個(gè)數(shù)據(jù)幀的數(shù)據(jù)域的8個(gè)

字節(jié)包含：數(shù)據(jù)幀的序號(hào)和至少一個(gè)字節(jié)的參數(shù)數(shù)據(jù)，未使用的字節(jié)全部設(shè)置為“FF”。

（4）數(shù)據(jù)重組

10

GB/T27930-xxxx

數(shù)據(jù)幀被陸續(xù)地接收后，接收方將會(huì)按照序號(hào)順序重新組合成長消息。

8.2.3連接管理

連接管理規(guī)定了長消息傳輸時(shí)節(jié)點(diǎn)之間虛擬連接的建立、使用和關(guān)閉。虛擬連接，是指在通信過程中，

為了傳送一條長消息，在兩個(gè)節(jié)點(diǎn)間建立的臨時(shí)連接。

（1）原則

-每次發(fā)送長消息之前收發(fā)雙方都需要重置用于記錄幀序號(hào)的計(jì)數(shù)器，對(duì)于發(fā)送方，計(jì)數(shù)器用于記錄

下次要發(fā)送的幀序號(hào)，對(duì)于接收方，計(jì)數(shù)器用于記錄下次要接收的幀序號(hào)。

-發(fā)送方發(fā)送幀序號(hào)為0的數(shù)據(jù)幀作為連接建立的起始，接收方應(yīng)答確認(rèn)。

-連接建立后，發(fā)送方按照接收方的應(yīng)答確認(rèn)來發(fā)送數(shù)據(jù)幀，發(fā)送完畢后等待接收方的應(yīng)答確認(rèn)。

-發(fā)送方、接收方不支持同時(shí)建立兩個(gè)及以上的連接。

-當(dāng)連續(xù)出現(xiàn)3次同類型的連接超時(shí)后，應(yīng)返回“發(fā)送失敗”信息至應(yīng)用層。

-只支持點(diǎn)到點(diǎn)的長消息傳輸。

（2）連接的建立

發(fā)送方請(qǐng)求發(fā)送長消息時(shí)，幀的幀序號(hào)為0，包含了長消息的總幀數(shù)和總字節(jié)數(shù)。

接收方接收到幀序號(hào)為0的長消息后，可以選擇接收或者拒絕建立連接。如果選擇接收，應(yīng)發(fā)送長消息

應(yīng)答確認(rèn)LM_ACK。LM_ACK包含了接收方待接收的起始幀序號(hào)、待接收總幀數(shù)。連接建立后，接收方應(yīng)

從序號(hào)為1的數(shù)據(jù)幀開始接收。

如果發(fā)送方接收到LM_ACK，連接建立完成。

如果接收方缺少資源或存儲(chǔ)空間，可拒絕建立連接，此時(shí)應(yīng)發(fā)送放棄連接確認(rèn)LM_NACK，連接建立

失敗。

（3）數(shù)據(jù)傳輸

發(fā)送方接收到LM_ACK后開始數(shù)據(jù)傳輸。接收方負(fù)責(zé)調(diào)整節(jié)點(diǎn)之間的數(shù)據(jù)流控制，如果接收方需要暫

停數(shù)據(jù)流，可使用LM_ACK將待接收總幀數(shù)置為1，待接收起始幀序號(hào)置為已接收的最后一幀的幀序號(hào)，

發(fā)送方重復(fù)發(fā)送此幀內(nèi)容（即重復(fù)接收上一組最后一幀報(bào)文），接收方收到該報(bào)文后不做處理。

如果接收方?jīng)Q定終止傳輸，應(yīng)發(fā)送LM_NACK，發(fā)送方收到LM_NACK后終止長消息的傳輸。

（4）連接的關(guān)閉

在傳輸沒有錯(cuò)誤的情況下，當(dāng)接收到所有數(shù)據(jù)幀后，接收方將發(fā)送消息結(jié)束確認(rèn)LM_EndACK，通知

發(fā)送者連接關(guān)閉。

長消息傳輸過程中，發(fā)送方或接收方可在任何時(shí)候使用LM_NACK終止連接。例如，如果接收方?jīng)]有

可用資源處理消息，可以通過發(fā)送LM_NACK放棄連接。當(dāng)接收到LM_NACK時(shí)，所有已傳送數(shù)據(jù)幀將被

丟棄。

任一方發(fā)生傳輸故障（例如連續(xù)出現(xiàn)3次同類型的連接超時(shí)）都會(huì)導(dǎo)致連接關(guān)閉。長消息的連接關(guān)閉，

包括：

1）發(fā)送方在以下情況下，可以認(rèn)為連接被關(guān)閉：

a．完成整個(gè)長消息的數(shù)據(jù)傳輸且接收到LM_EndACK；

b．發(fā)送LM_NACK；

c．接收LM_NACK；

2）接收方在以下情況下，可以認(rèn)為連接被關(guān)閉：

a．完成整個(gè)長消息的數(shù)據(jù)傳輸后發(fā)送了LM_EndACK；

b．發(fā)送LM_NACK（如發(fā)送方希望提早停止通訊，超時(shí)等等）；

c．接收LM_NACK；

（5）連接的超時(shí)

11

GB/T27930-xxxx

-接收方接收到一個(gè)數(shù)據(jù)幀后，若LMS_T2內(nèi)未接收到下一個(gè)數(shù)據(jù)幀即為超時(shí)，超時(shí)后發(fā)送LM_ACK

通知發(fā)送方重發(fā)，總共3次超