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

ICS29.200

K81

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

GB/T27930.2—XXXX

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

的數(shù)字通信協(xié)議第2部分ChaoJi系統(tǒng)

Communicationprotocolsbetweenoff-boardconductivechargerandelectricvehicle

Part2ChaoJiSystem

點擊此處添加與國際標(biāo)準(zhǔn)一致性程度的標(biāo)識

（征求意見稿）

XXXX—XX—XX發(fā)布XXXX—XX—實施

前言

本文件按照GB/T1.1—2020《標(biāo)準(zhǔn)化工作導(dǎo)則第1部分：標(biāo)準(zhǔn)化文件的結(jié)構(gòu)和起草規(guī)則》的規(guī)定

起草。

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

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

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

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

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

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

本文件主要起草單位：。

本文件主要起草人：。

II

GB/T27930.2—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—202X附錄D規(guī)定的充電模式4的充電機與車輛之間的通信，也適

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

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

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

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

文件。

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

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

GB/T18487.1—202X電動汽車傳導(dǎo)充電系統(tǒng)第1部分通用要求（征求意見稿）

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

絞線（RecommentedpracticeforserialcontrolandcommunicationvehiclenetworkPart11:Physicallayer–

250Kbits/s,twistedshieldedpair）

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

雙絞線（RecommentedpracticeforserialcontrolandcommunicationvehiclenetworkPart15:Physicallayer

–250Kbits/s,Un—ShieldedTwistedPair）

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

practiceforserialcontrolandcommunicationvehiclenetworkPart21:Datalinklayer）

3術(shù)語和定義

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

3.1

幀frame

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

3.2

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

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

束（EndofFrame，簡稱EOF）結(jié)尾。

3.3

1

GB/T27930.2—xxxx

報文CANmessage

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

據(jù)幀”。

3.4

標(biāo)識符identifier

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

3.5

擴展幀extendedframe

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

3.6

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

在標(biāo)識符中一個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ù)組標(biāo)識parametergroupidentification(PGI)

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

3.9

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

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

3.10

電子控制單元electroniccontrolunit(ECU)

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

3.11

功能模塊functionmodule

車輛與充電機的能量交互過程中的某個業(yè)務(wù)功能。

3.12

必須項功能模塊mandatoryfunctionmodule

一個完整的能量交互過程必須具有的功能模塊。

3.13

可選項功能模塊optionalfunctionmodule

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

3.14

可重載功能模塊overridefunctionmodule

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

3.15

功能代碼functioncode(FC)

為功能模塊分配的編號。

3.16

功能描述碼functiondescriptioncode(FDC)

為具備特定功能的功能模塊實例分配的編號。

3.17

2

GB/T27930.2—xxxx

信息幀informationframe(IF)

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

3.18

控制幀controlframe(CF)

數(shù)據(jù)鏈路層上用于進行流量控制、差錯管理、接收確認(rèn)的CAN數(shù)據(jù)幀。

3.19

多信息幀傳輸方式Multi—messageframetransportmode

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

3.20

長消息longmessage

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

3.21

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

采用自動重傳請求方式傳輸?shù)南?，包括需要確認(rèn)的短消息和長消息。

3.22

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

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

4縮略語

LM長消息longmessage

RM需要確認(rèn)的消息reliablemessage

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

URM不需要確認(rèn)的消息unreliablemessage

RM_SM_ACK需要確認(rèn)的短消息應(yīng)答確認(rèn)reliableshortmessageacknowledge

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

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

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

5總則

5.1充電機與車輛之間的通信網(wǎng)絡(luò)基于CAN。

5.2充電機與車輛之間的充電通信過程由完成不同業(yè)務(wù)功能的功能模塊按序組成，具體信息交互報

文、交互過程由功能模塊的FDC決定。

5.3充電信息交互報文包括各功能模塊FDC規(guī)定的報文（見附錄A）及公共報文（見附錄B），基

本充電應(yīng)用場景的信息交互過程詳見附錄C。

6物理層

本文件采用的CAN通信總線網(wǎng)絡(luò)物理層應(yīng)符合SAEJ1939-11:2006（屏蔽雙絞線）或SAEJ1939-

15:2018（非屏蔽雙絞線）中關(guān)于物理層的規(guī)定。本文件充電機與車輛的通信應(yīng)使用獨立的CAN總線，

3

GB/T27930.2—xxxx

并應(yīng)支持SECC、EVCC、適配器通信控制器（VehicleAdaptorCommunicationController，以下簡稱VACC）

三個節(jié)點，通信速率采用250kbit/s。雙絞線滿足SAEJ1939—11中5.2.1表7的要求，終端電阻滿足SAE

J1939—11:2006中5.2.3的要求。

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

7.1幀格式

采用本文件的設(shè)備應(yīng)使用CAN擴展幀的29位標(biāo)識符，具體每個位分配的相應(yīng)定義應(yīng)符合SAE

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

7.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

注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)的消息類型。

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

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

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

7.3協(xié)議數(shù)據(jù)單元(PDU)格式

選用SAEJ1939—21:2006中定義的PDU1格式。

7.4地址的分配

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

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

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

表2地址分配

節(jié)點首選地址

SECC95(5F)

EVCC37(25H)

VACC96(60H)

4

GB/T27930.2—xxxx

7.5幀類型

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

8版本協(xié)商

8.1總體描述

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

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

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

序號項目描述信息

1名稱版本協(xié)商

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

通信鏈路建立后，由充電機發(fā)起通信協(xié)議版本協(xié)商過程，車輛檢測是否

支持充電機發(fā)送的版本，并返回協(xié)商結(jié)果：

a)充電機側(cè)

充電機首先發(fā)送其支持的最高協(xié)議版本號進行協(xié)商，如果充電機接收到

“協(xié)商成功”信息，進入應(yīng)用層信息交互過程；如果充電機接收到“協(xié)商失

敗”信息，通信結(jié)束，退出充電過程；如果充電機接收到“繼續(xù)協(xié)商”以及

“車輛期望的版本號”信息，按照以下原則處理：

——如果充電機支持車輛期望的版本，則發(fā)送該版本號，等待車輛發(fā)

送“協(xié)商成功”信息；

——如果充電機不支持車輛期望的版本，且充電機不支持低于車輛當(dāng)

前期望值的版本，則充電機發(fā)送版本號為0的版本信息報文，等

待車輛發(fā)送“協(xié)商失敗”信息；

3描述

——如果充電機不支持車輛期望的版本，但充電機支持低于車輛當(dāng)前

期望值的版本，則充電機發(fā)送“比車輛期望值低的最高版本號”

的版本信息，繼續(xù)協(xié)商。

b)車輛側(cè)

車輛接收充電機協(xié)商版本信息，按照以下原則處理：

——如果車輛支持充電機的協(xié)商版本，則返回“協(xié)商成功”信息；

——如果車輛不支持充電機的協(xié)商版本，且不支持低于充電機當(dāng)前協(xié)

商值的版本，則車輛返回“協(xié)商失敗”信息，通信結(jié)束，退出充電

過程；

——如果車輛不支持充電機的協(xié)商版本，但支持比充電機當(dāng)前協(xié)商值

低的版本，則車輛返回“繼續(xù)協(xié)商”信息，同時發(fā)送“比充電機當(dāng)

前協(xié)商值低的最高版本號”進行協(xié)商。

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

5其他說明充電機和車輛可支持多個版本的通信協(xié)議，只有雙方都支持相同的版

5

GB/T27930.2—xxxx

序號項目描述信息

本，版本協(xié)商才能成功。

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

——當(dāng)前版本的CAN類型為CAN2.0，同時預(yù)留CANFD，CANXL的

應(yīng)用；

——當(dāng)通信協(xié)議有結(jié)構(gòu)性的變化時（如功能模塊的組成發(fā)生變化），更

新主版本號；

——當(dāng)通信協(xié)議有較大的功能變化，但不影響通信協(xié)議的結(jié)構(gòu)，更新

次版本號；

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

本號為0。

a)協(xié)商成功：車輛和充電機支持相同的版本，車輛發(fā)送“協(xié)商成功”信息，

雙方按照協(xié)商一致的版本進行信息交互。

6結(jié)束條件b)協(xié)商失敗，包括：

——版本協(xié)商失敗，車輛發(fā)送“協(xié)商失敗”信息，退出充電過程。

——版本協(xié)商超時，車輛發(fā)送“協(xié)商失敗”信息，退出充電過程。

8.2報文定義

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

本報文”、“車輛協(xié)商結(jié)果報文”，其幀格式定義如表4，表5所示，參數(shù)類型定義詳見附錄A。

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

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

0x250x5F

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

(目的地址)(源地址)

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

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

0x5F0x25

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

(目的地址)(源地址)

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

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

1CAN類型1字節(jié)BYTECANType充電機CAN類型，當(dāng)前版本的CAN類型為

6

GB/T27930.2—xxxx

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

CAN2.0。

充電機協(xié)商的協(xié)議版本號，本文件規(guī)定當(dāng)前版

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

本號為V2.0.0。

3預(yù)留1字節(jié)BYTEReservedType車輛不判斷該值

4預(yù)留1字節(jié)BYTEReservedType車輛不判斷該值

5預(yù)留1字節(jié)BYTEReservedType車輛不判斷該值

校驗碼，采用校驗和法計算報文第1個字節(jié)到

6校驗碼1字節(jié)BYTECheckcodeType第7個字節(jié)的校驗碼（如果校驗和的數(shù)值超過

0xFF，則將其補碼作為校驗和）

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

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

車輛CAN類型，當(dāng)前版本的CAN類型為

1CAN類型1字節(jié)BYTECANType

CAN2.0。

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

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

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

車輛期望或協(xié)商一致的版本號：

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

值為雙方協(xié)商一致的版本號；

——如果車輛協(xié)商結(jié)果為“繼續(xù)協(xié)商”，值

3期望版本3字節(jié)BYTE[3]ProtocolVersionType

為車輛期望的版本號；

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

為0xFFFFFF，此時充電機不判斷該

值。

4預(yù)留1字節(jié)BYTEReservedType充電機不判斷該值。

5預(yù)留1字節(jié)BYTEReservedType充電機不判斷該值

校驗碼，采用校驗和法計算報文第1個字節(jié)到

6校驗碼1字節(jié)BYTECheckcodeType第7個字節(jié)的校驗碼（如果校驗和的數(shù)值超過

0xFF，則將其補碼作為校驗和）

8.3報文交互過程

車輛和充電機物理連接完成，充電機閉合S1開關(guān)后應(yīng)在1s內(nèi)發(fā)送“充電機協(xié)議版本報文”。充電

機首先發(fā)送其支持的最高協(xié)議版本號，車輛接收后檢查自身支持的版本號并返回協(xié)商結(jié)果。如果“繼續(xù)

協(xié)商”，雙方繼續(xù)以較低的版本號進行協(xié)商；如果“協(xié)商成功”，雙方按照協(xié)商一致的版本進行信息交

互；如果“協(xié)商失敗”，雙方退出充電過程。

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

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

7

GB/T27930.2—xxxx

觸發(fā)條件

充電機接收接收接收

T1定時器到T2定時器到

“協(xié)商成功”“協(xié)商失敗”“繼續(xù)協(xié)商”

發(fā)送CvList（Ns）

S0

隊列報文，進入————

初始狀態(tài)

S1

根據(jù)車輛“期望版本號”信息調(diào)

S1發(fā)送CvList（Ns）

狀進入S2進入S3整Ns指向并發(fā)送CvList（Ns）進入S3

協(xié)商中隊列報文，保持S1

態(tài)隊列報文（詳見表3），保持S1

S2

關(guān)閉T1，T2定時器，進入功能協(xié)商模塊

協(xié)商成功

S3

關(guān)閉T1，T2定時器，退出充電過程

協(xié)商失敗

注1：T1為充電機發(fā)送版本信息報文的周期定時器，充電機發(fā)送CvList（Ns）隊列報文后重置T1定時器，周期為50ms

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

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

注4：表中未列舉的報文，如版本協(xié)商報文以外的或不滿足交互順序的版本內(nèi)容等均為非法報文，充電機不作任何處理

注5：.—表示充電機不作任何處理

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

觸發(fā)條件

接收到“版本信息報文”

車輛不支持充電機的協(xié)商版不支持充電機的協(xié)商版

T2定時器到

支持充電機的本，但支持比充電機當(dāng)前本，且不支持低于充電機

協(xié)商版本協(xié)商值低的版本當(dāng)前協(xié)商值的版本

發(fā)送“繼續(xù)協(xié)商”信息，

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

S1發(fā)送“協(xié)商成功”信息，發(fā)送“比充電機當(dāng)前協(xié)商發(fā)送“協(xié)商失敗”信息，

敗”信息，進

協(xié)商中進入S2值低的最高版本號”，保持進入S3

入S3

狀S1

態(tài)S2

關(guān)閉T2定時器，進入功能協(xié)商階段

協(xié)商成功

S3

關(guān)閉T2定時器，退出充電過程

協(xié)商失敗

注1：T2為版本協(xié)商超時定時器，當(dāng)車輛檢測到S1閉合后啟動T2定時器，默認(rèn)為5s

注2：表中未列舉的報文，如版本協(xié)商報文以外的或不滿足交互順序的版本內(nèi)容等均為非法報文，車輛不作任何處理

注3：—表示車輛不作任何處理

9傳輸層

9.1消息類型

8

GB/T27930.2—xxxx

本文件規(guī)定的消息類型包括需要確認(rèn)的消息、不需要確認(rèn)的消息。需要確認(rèn)的消息為上層應(yīng)用提供

可靠性傳輸服務(wù)，按照消息長度分為需要確認(rèn)的短消息（消息長度小于等于8字節(jié)）和長消息（消息長

度大于8字節(jié)），長消息按照多信息幀傳輸方式傳輸。不需要確認(rèn)的消息則是面向簡單不可靠信息的傳

輸服務(wù)，消息長度小于等于8字節(jié)。

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

不需要確認(rèn)的消息無需接收方應(yīng)答確認(rèn)，上層應(yīng)用中需周期發(fā)送的報文通常定義為該消息類型。不

需要確認(rèn)的消息的信息幀格式如表10所示。

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

協(xié)議數(shù)

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

據(jù)單元

占位

311888

（bit）

目的源

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

地址地址

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

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

發(fā)送方發(fā)送需要確認(rèn)的短消息的信息幀后，如果沒有接收到應(yīng)答確認(rèn)幀，應(yīng)進行重發(fā)，重發(fā)次數(shù)默

認(rèn)為4（具體參考第10章具體要求）。如果發(fā)送方完成最大重發(fā)次數(shù)后仍然沒有接收到確認(rèn)信息，發(fā)送

方應(yīng)該放棄進一步嘗試，重發(fā)的時間間隔為250ms。需要確認(rèn)的短消息信息幀格式如表11所示，應(yīng)答確

認(rèn)幀的格式定義如表12所示。

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

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

目的源

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

地址地址

表12需要確認(rèn)的短消息的應(yīng)答確認(rèn)幀格式

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

0x0目的源

定義000x37010xFF0xFF0xFF0xFF0xFF0xFF

3地址地址

9.3.2長消息

9

GB/T27930.2—xxxx

長消息的傳輸應(yīng)遵循9.4規(guī)定的多信息幀傳輸方式，其信息幀格式定義如表13所示。

表13長消息的信息幀格式

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

總字

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

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

地址地址

幀序號：>0遵循應(yīng)用層定義，最后一幀不足8字節(jié)的，填充0xFF。

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

注2：總幀數(shù)為組成應(yīng)用層報文的所有幀數(shù)

注3：總字節(jié)數(shù)為組成應(yīng)用層報文的總長度

長消息的控制幀用于差錯控制、流量控制及應(yīng)答確認(rèn)，包括3類：

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

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

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

其中LM_ACK，LM_EndofACK是接收方對發(fā)送方的控制幀，LM_NACK是接收方或發(fā)送方發(fā)送給

對方的控制幀。長消息的控制幀格式定義如表14所示。

表14長消息的控制幀格式

協(xié)議數(shù)

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

據(jù)單元

占位

31188888888888

（bit）

待接收待接

LM_

起始幀收總0xFF0xFF0xFF0xFF0xFF

ACK：1

序號幀數(shù)

目的源

定義0x03000x37LM_

地址地址0xFF0xFF0xFF0xFF0xFF0xFF0xFF

NACK：2

LM_Endo接收的接收的

0xFF0xFF0xFF0xFF

fACK：3總幀數(shù)總字節(jié)數(shù)

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

9.4多信息幀傳輸方式

9.4.1原則

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

9.4.2分包重組

10

GB/T27930.2—xxxx

發(fā)送方首先將長消息其拆分為多個信息幀，在建立連接后按序進行傳輸。接收方接收到所有的數(shù)據(jù)

幀后再重組成原始信息。

9.4.2.1信息幀

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

（序號為0的信息幀，僅僅用于建立連接），信息幀應(yīng)從編號1開始按序進行發(fā)送，最長的數(shù)據(jù)長度是1785

個字節(jié)。當(dāng)發(fā)送方請求建立長消息傳輸?shù)奶摂M連接時，首先發(fā)送幀序號為0的信息幀，在收到接收方的

應(yīng)答確認(rèn)后，按要求發(fā)送信息幀。

每個信息幀（除了最后一個信息幀）都裝載著應(yīng)用層數(shù)據(jù)中的7個字節(jié)，最后一個信息幀的數(shù)據(jù)域

的8個字節(jié)包含：信息幀的序號和至少一個字節(jié)的應(yīng)用層數(shù)據(jù)，未使用的字節(jié)全部設(shè)置為0xFF。

9.4.2.2數(shù)據(jù)傳輸

信息幀之間的發(fā)送間隔時間LMS_T1應(yīng)不大于10ms。由于無法區(qū)分幀序號相同的不同長消息的信息

幀，因此只允許在同一時間建立一個虛擬連接，即只有當(dāng)發(fā)送方或接收方發(fā)送長消息放棄連接確認(rèn)或接

收方發(fā)送長消息接收結(jié)束確認(rèn)，才能建立新的虛擬連接。

9.4.2.2信息幀重組

信息幀接收完成后，接收方接收完成所有信息幀后，應(yīng)按照幀序號從小到大將其重組回原始信息。

9.4.3連接管理

虛擬連接是指在通信過程中，為了傳送長消息，在兩個節(jié)點間建立的臨時連接，連接管理規(guī)定了虛

擬連接的建立、使用和關(guān)閉。

9.4.3.1總則

本文件只支持點到點的長消息傳輸，其連接管理應(yīng)遵循以下原則：

——虛擬連接建立前，收發(fā)雙方應(yīng)確認(rèn)記錄幀序號的計數(shù)器為0，其中發(fā)送計數(shù)器用于記錄下次要

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

——發(fā)送方發(fā)送幀序號為0的信息幀作為連接建立的請求，接收方應(yīng)答確認(rèn)后，連接建立；

——連接建立后，發(fā)送方按照接收方的應(yīng)答確認(rèn)發(fā)送信息幀，發(fā)送結(jié)束后等待接收方的下一個應(yīng)答

確認(rèn)；

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

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

9.4.3.2連接的建立

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

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

息應(yīng)答確認(rèn)幀LM_ACK，且LM_ACK中應(yīng)包含接收方待接收的起始幀序號、待接收總幀數(shù)，發(fā)送方接收

到應(yīng)答確認(rèn)幀LM_ACK，連接建立完成，之后接接收方應(yīng)從序號為1的信息幀開始接收；如果接收方缺

少資源或存儲空間，可拒絕建立連接，此時應(yīng)發(fā)送放棄連接確認(rèn)LM_NACK，連接建立失敗。

9.4.3.3數(shù)據(jù)傳輸

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

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

幀幀序號，發(fā)送方按要求發(fā)送信息幀（接收方每發(fā)送一次LM_ACK，接收方響應(yīng)一次），接收方收到該

報文后不做處理。

11

GB/T27930.2—xxxx

9.4.3.4連接的關(guān)閉

接收方接收到所有信息幀后，應(yīng)發(fā)送消息結(jié)束確認(rèn)LM_EndofACK，通知發(fā)送者連接關(guān)閉。

在傳輸過程中，接收方和發(fā)送方均可發(fā)送LM_NACK終止傳輸，收到LM_NACK后雙方退出長消息

的傳輸，連接關(guān)閉，接收方不對收到的報文作處理。

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

長消息的連接關(guān)閉，包括以下情形：

a）發(fā)送方：

——完成整個長消息的數(shù)據(jù)傳輸且接收到LM_EndofACK

——發(fā)送LM_NACK

——接收LM_NACK

b）接收方：

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

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

——接收LM_NACK；

9.4.3.5連接的超時

——接收方接收到一個信息幀后，若LMS_T2時間內(nèi)未接收到下一個信息幀即為超時，超時后發(fā)送

LM_ACK通知發(fā)送方重發(fā)，連續(xù)出現(xiàn)3次超時后發(fā)送LM_NACK放棄連接。

——接收方發(fā)送LM_ACK后，若LMS_T2時間內(nèi)未接收到正確幀序號的信息幀即為超時，超時后發(fā)

送LM_ACK通知發(fā)送方重發(fā)，連續(xù)出現(xiàn)3次超時后發(fā)送LM_NACK放棄連接。

——發(fā)送方發(fā)送幀序號為0的信息幀后，若LMS_T2時間內(nèi)未接收到接收方的確認(rèn)消息即為超時，超

時后重發(fā)幀序號為0的信息幀，連續(xù)出現(xiàn)3次超時后發(fā)送LM_NACK放棄連接；

——發(fā)送方發(fā)送完成本次需要傳輸?shù)娜啃畔?，若LMS_T2內(nèi)未接收到接收方的確認(rèn)消息

（LM_ACK或LM_EndofACK）即為超時，超時后發(fā)送方重發(fā)本次傳輸?shù)淖詈笠粠?，連續(xù)出現(xiàn)

3次超時后發(fā)送LM_NACK放棄連接；

——發(fā)送方從發(fā)送幀序號為0的信息幀后，傳輸整個長消息的時間大于LMS_T3即為超時，超時后發(fā)

送方發(fā)送LM_NACK放棄連接。

LMS_T2=100ms

LMS_T3=10000ms

多信息幀傳輸方式的完整狀態(tài)轉(zhuǎn)換過程如表15，表16所示。

12