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

中華人民共和國國家標準

GB/T27930—xxxx

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

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

ChaoJi充電系統(tǒng)

Communicationprotocolsbetweenoff-boardconductivecharger

andelectricvehiclePart2：ChaoJiSystem

（征求意見稿）

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

前言

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

分：

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

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

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

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

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

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

本部分起草單位：。

本部分主要起草人：。

II

GB/T27930-xxxx

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

ChaoJi充電系統(tǒng)

1范圍

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

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

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

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

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

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

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

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

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

件。

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

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

GBT18487.1電動汽車傳導(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

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

3.2

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

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

3.3

CAN報文CANmessage

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

1

GB/T27930-xxxx

3.4

標識符identifier

CAN仲裁域的標識部分。

3.5

擴展幀extendedframe

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

3.6

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

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

3.7

參數(shù)組parametergroup(PG)

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

3.8

參數(shù)組標識parametergroupidentification(PGI)

用于唯一標識一個參數(shù)組的一個字節(jié)。

3.9

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

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

3.10

傳輸協(xié)議transportprotocol

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

3.11

電子控制單元electroniccontrolunit(ECU)

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

3.12

功能模塊functionmodule

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

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

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

3.19

控制幀controlframe(CF)

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

3.20

多信息幀傳輸方式

使用自動重傳請求方式傳輸具有幀編號的一幀或多幀數(shù)據(jù)的方式。

3.21

長消息longmessage

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

3.22

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

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

3.23

需要確認的短消息reliableshortmessage

采用自動重傳請求方式傳輸不具有幀編號的單幀數(shù)據(jù)。

3.24

不需要確認的短消息unreliableshortmessage

不需要自動重傳請求方式傳輸不具有幀編號的單幀數(shù)據(jù)。

4縮略語

LM長消息longmessage

SM短消息shortmessage

SM_RM需要確認的短消息reliableshortmessage

SM_URM不需要確認的短消息unreliableshortmessage

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

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

LM_NACK長消息放棄連接確認longframenegativeacknowledge

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

5物理層

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

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

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

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

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

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

6.1幀格式

3

GB/T27930-xxxx

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

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

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

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

優(yōu)先權(quán)，擴展數(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為擴展數(shù)據(jù)頁：備今后擴展使用，本部分中為0。

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

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

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

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

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

6.3地址分配

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

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

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

表2地址分配

節(jié)點首選地址

SECC86(56H)

EVCC244(F4H)

VACC201(C9H)

6.4幀類型

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

7版本協(xié)商

7.1總體描述

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

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

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

序號項目描述信息

1名稱版本協(xié)商

2目標充電機和車輛協(xié)商決定通信協(xié)議版本號。

4

GB/T27930-xxxx

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

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

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

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

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

給充電機；

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

連同期望的版本號一起返回給充電機；

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

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

商失敗；

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

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

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

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

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

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

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

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

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

-臨時版本僅用于示范項目和測試臨時用途，正式發(fā)布的版本中臨時版本號為0。

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

互。

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

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

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

7.2報文定義

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

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

表4充電機協(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充電機協(xié)議版本數(shù)據(jù)域內(nèi)容

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

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

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

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

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

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

前版本號。

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

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

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

報文校驗碼，從第1個字節(jié)至第7個字節(jié)的累加

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

和

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

序號參數(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é)商一致的版本號。

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

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

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

的版本號；

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

0xFFFFFF；

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

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

6校驗碼1字節(jié)BYTECheckcodeType報文校驗碼，第1個字節(jié)至第7個字節(jié)的累加和

7.3報文交互過程

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

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

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

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

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

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

觸發(fā)條件

充電機T1定時器接收接收接收T2定時收到

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

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

6

GB/T27930-xxxx

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

入S1

根據(jù)車輛“期望

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

整Ns指向（如

果支持，則Ns

指向該版本號，進入S3，

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

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

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

向等于前一個T2

更低版本，如

Ns已為第一個

則Ns不變），保

持S1

S2

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

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

的版本

進入功能協(xié)商）

S3

------

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

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

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

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

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

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

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

觸發(fā)條件

接收到CvList接收到

車輛收到

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

非法幀

本號號本號報文”

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

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

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

成功”，進--

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

入S2

本號

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

狀

S2發(fā)送“協(xié)商商”，版本號為發(fā)送“協(xié)商失進入發(fā)送“協(xié)商失敗”,

態(tài)-

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

本號，進入S1

發(fā)送

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

“協(xié)商失-

（協(xié)商失?。┦　睌　睌　苯K止

敗”

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

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

注3：-表示充電機不作任何處理

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

7

GB/T27930-xxxx

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

充電機電動汽車

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

版本號設(shè)為其支

持的最高版本

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

版本報文

是否收到

超時否

超時處理充電機協(xié)議版本

報文

是

是否支持接收的

發(fā)送的版本改為

版本號是

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

持的最高版本，

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

否

當(dāng)前版本

接收的版本號是

是否低于車輛支持

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

否

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

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

果報文

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

超時處理

結(jié)果報文

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

協(xié)商

是

是否

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

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

否

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

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

8傳輸層

8.1消息類型

8.1.1分類

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

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

輸服務(wù)，不需要確認的短消息則面向簡單不可靠信息的傳輸服務(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）

總字

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

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

地址地址

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

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

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

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

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

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

-長消息放棄連接確認LM_NACK

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

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

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

表11長消息的控制幀格式

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

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

據(jù)單元P

占位

31188888888888

（bit）

待接收

待接收

目LM_ACK：1起始幀0xFF0xFF0xFF0xFF0xFF

源總幀數(shù)

的序號

定義3000x04地

地LM_NACK：20xFF0xFF0xFF0xFF0xFF0xFF0xFF

址

址接收的接收的

LM_EndACK：30xFF0xFF0xFF0xFF

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

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

8.1.3需要確認的短消息

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

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

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

式定義如表13所示。

表12需要確認的短消息的信息幀格式

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

目的源

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

地址地址

9

GB/T27930-xxxx

表13需要確認的短消息的控制幀格式

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

源

0x0目的

定義000x04地010xFF0xFF0xFF0xFF0xFF0xFF

3地址

址

8.1.4不需要確認的短消息

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

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

表14不需要確認的短消息的信息幀定義

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

目的源

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

地址地址

8.2多信息幀傳輸方式

8.2.1原則

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

8.2.2分包重組

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

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

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

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

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

（2）序號

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

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

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

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

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

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

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

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

10

GB/T27930-xxxx

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

8.2.3連接管理

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

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

（1）原則

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

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

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

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

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

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

-只支持點到點的長消息傳輸。

（2）連接的建立

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

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

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

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

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

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

失敗。

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

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

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

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

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

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

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

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

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

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

丟棄。

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

包括：

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

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

b．發(fā)送LM_NACK；

c．接收LM_NACK；

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

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

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

c．接收LM_NACK；

（5）連接的超時

11

GB/T27930-xxxx

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

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