一種基于組播報文的安全協(xié)議性能分析方法*

劉 娜

(遼寧經(jīng)濟職業(yè)技術(shù)學(xué)院,110122,沈陽∥講師)

?

一種基于組播報文的安全協(xié)議性能分析方法*

劉 娜

(遼寧經(jīng)濟職業(yè)技術(shù)學(xué)院,110122,沈陽∥講師)

區(qū)域控制中心(ZC)子系統(tǒng)內(nèi)部安全協(xié)議是基于通信的列車控制(CBTC)系統(tǒng)成敗的關(guān)鍵。設(shè)計了ZC內(nèi)部安全協(xié)議組播發(fā)送方式及確認機制,提出了組播報文的安全確認流程。利用網(wǎng)絡(luò)仿真工具(OPNET)建立安全協(xié)議多線程模型,根據(jù)ZC的實際運行情況對通信過程進行仿真,結(jié)果表明組播發(fā)送方式減小了近50%的通信延時。

軌道交通; 基于通信的列車控制系統(tǒng); 安全協(xié)議; 組播報文

Author′s address Liaoning Economic Vocational Technological Institute,110122,Shenyang,China

在基于通信的列車控制(CBTC)系統(tǒng)中,區(qū)域控制器(ZC)向列車直接下達移動授權(quán)(MA)是重要的行車運行安全防護措施?；?×2取2冗余結(jié)構(gòu)的ZC安全平臺內(nèi)部的安全協(xié)議是確保系統(tǒng)正常運行的關(guān)鍵因素[1]。

為了降低成本和縮短研發(fā)周期,通常選擇在價格低廉的現(xiàn)貨供應(yīng)商品(COTS)上構(gòu)建故障安全硬實時通信網(wǎng)絡(luò)[2]。然而,以太網(wǎng)等COTS網(wǎng)絡(luò)的通信時間缺乏確定性,同時也缺乏能保障消息可靠傳輸?shù)目煽啃詸C制,需要在不可信傳輸設(shè)備上增加安全相關(guān)傳輸功能,并保證報文最大延時滿足安全時限。

文獻[3]設(shè)計了一種時間觸發(fā)以太網(wǎng)(time-triggered ethernet),利用發(fā)送時間窗口概念來協(xié)調(diào)各個發(fā)送節(jié)點,避免沖突,減小了報文的平均延時。文獻[4]還分析了COTS以太網(wǎng)作為安全關(guān)鍵實時網(wǎng)絡(luò)的可行性,但他們都是在基于碰撞檢測機制的共享式以太網(wǎng)上建立時間觸發(fā)協(xié)議。協(xié)議中的仲裁機制在減小沖突和提高通信確定性的同時,也降低了傳輸效率。存儲轉(zhuǎn)發(fā)式以太網(wǎng)不再受限于沖突,明顯地減小了報文的延時,更加適合應(yīng)用于工業(yè)實時網(wǎng)絡(luò)[5]。文獻[7]利用模型檢驗工具(SPIN)對安全通信協(xié)議進行形式化建模,驗證了安全協(xié)議不存在死鎖與活鎖,且滿足時序邏輯公式描述的安全屬性,但是缺乏對安全協(xié)議通信延時等性能的分析[6]。文獻[7]設(shè)計了基于交換式以太網(wǎng)的適合ZC內(nèi)部冗余結(jié)構(gòu)的安全協(xié)議,但缺乏組播報文的相關(guān)設(shè)計和分析。為了提高通信效率,本文對該協(xié)議進行擴展,設(shè)計有關(guān)組播報文的安全確認機制,并通過仿真對組播報文的性能進行分析。

1 ZC內(nèi)部網(wǎng)絡(luò)安全協(xié)議

1.1 ZC子系統(tǒng)內(nèi)部網(wǎng)絡(luò)拓撲結(jié)構(gòu)及協(xié)議層次

ZC子系統(tǒng)包含2個通信控制器和4個主機,以星型拓撲的形式相連接。交換式以太網(wǎng)傳輸速率為100 Mbit/s,節(jié)點發(fā)送數(shù)據(jù)時不再受限于CSMA/CD協(xié)議[8]。為了提高協(xié)議效率,同時滿足安全需求,選擇在不可信傳輸層UDP協(xié)議上增加安全相關(guān)功能[9],其層次如圖1所示。

圖1 安全協(xié)議層次結(jié)構(gòu)

分組幀模塊負責(zé)將超長應(yīng)用報文進行分幀和組幀,安全時間模塊負責(zé)根據(jù)內(nèi)網(wǎng)報文類型和時間戳來判斷報文的時間安全性。序列號、CRC校驗、源目的地址標識等安全技術(shù)是安全鏈路層檢查報文合法性的手段。安全協(xié)議規(guī)定[10]接收方收到數(shù)據(jù)報文后,需要根據(jù)報文目的地址判斷合法性,如果報文合法則回復(fù)ACK報文,發(fā)送方接收到ACK確認之

后確認數(shù)據(jù)報文已經(jīng)安全到達。發(fā)送方發(fā)送報文后,需等待接收方返回的ACK確認消息,超時未收到則重新發(fā)送,從而實現(xiàn)對內(nèi)網(wǎng)報文的選擇重傳。

1.2 組播報文的安全應(yīng)答方式設(shè)計

組播是將1個分組的多個拷貝發(fā)送給所有可能目標地址的選定子集的技術(shù)。VxWorks操作系統(tǒng)傳輸層UDP協(xié)議的Socket相關(guān)API函數(shù)支持組播功能。接收方通過調(diào)用相應(yīng)API函數(shù)將自身IP地址加入到1個組播組,發(fā)送方將報文發(fā)送到這個組播組后,事先加入到該組中的所有接收方均可收到相同的報文。

CBTC系統(tǒng)運行過程中,ZC子系統(tǒng)管轄范圍內(nèi)的車載控制器(VOBC)子系統(tǒng)周期性地向ZC發(fā)送位置報告等報文。這些外網(wǎng)報文發(fā)送到ZC的2×2取2安全計算機平臺的通信控制器上,轉(zhuǎn)化成內(nèi)網(wǎng)報文后,再由通信控制器通過點對點的方式向4個主機發(fā)送,這一過程可用組播方式優(yōu)化。

圖2給出了組播報文應(yīng)答過程的統(tǒng)一建模語言(UML)描述。通信控制器接收到外網(wǎng)報文后,用1個組播報文將這個外網(wǎng)報文轉(zhuǎn)發(fā)給4個主機,并啟動重傳計時器。主機收到組播報文并驗證目的地址合法性之后,需向通信控制器回復(fù)ACK應(yīng)答報文。規(guī)定在5 ms之內(nèi),通信控制器應(yīng)能收齊全部4個應(yīng)答報文,并取消重傳計時器,超時未收到則需采用點對點的通信方式進行選擇重傳。

圖2 組播報文的點對點重傳過程

2 ZC內(nèi)部網(wǎng)絡(luò)通信協(xié)議建模

2.1 層次化模型架構(gòu)

利用網(wǎng)絡(luò)仿真軟件OPNET Modeler 10.0進行建模,其總體模型層次架構(gòu)如圖3所示,頂層為網(wǎng)絡(luò)模型,向下依次是節(jié)點模型和進程模型。內(nèi)部網(wǎng)絡(luò)節(jié)點的節(jié)點模型主要包括模擬通信緩沖的隊列和功能模塊。模塊之間的接口采用OPNET隊列模塊模擬,模塊內(nèi)部功能采用有限狀態(tài)機(FSM)模擬,其中安全傳輸與流量控制模塊是ZC內(nèi)部安全協(xié)議的核心。下面重點介紹該模塊中的FSM模型。

按照任務(wù)優(yōu)先處理隊首數(shù)據(jù)包的原則,基于排隊論建立節(jié)點模型,仿真時隊列中被阻塞報文的延時時間按泊松分布設(shè)定。

圖3 層次化模型架構(gòu)

2.2 核心模塊中的進程模型

ZC內(nèi)部網(wǎng)絡(luò)的安全傳輸層和流量控制層通過發(fā)送、接收、重發(fā)等任務(wù)實現(xiàn),其中接收任務(wù)具有最高的優(yōu)先級,重發(fā)等任務(wù)優(yōu)先級次之。VxWorks操作系統(tǒng)中的任務(wù)經(jīng)過初始化之后就處于阻塞狀態(tài),

等待事件觸發(fā)執(zhí)行,然后循環(huán)阻塞。任務(wù)之間有傳遞消息的機制,如信號量與消息隊列等。OPNET的進程模型具備循環(huán)阻塞和事件觸發(fā)執(zhí)行機制,其自帶的進程間通信機制[11]可有效模擬ZC子系統(tǒng)采用的VxWorks實時操作系統(tǒng)中的任務(wù)通信方式,可真實客觀地反映CBTC系統(tǒng)中ZC子系統(tǒng)的運行情況?；谶@些特點,利用OPNET進程對實際通信相關(guān)任務(wù)進行仿真,利用OPNET自帶的FSM建模工具描述任務(wù)的行為。接收、發(fā)送和重發(fā)進程的FSM分別如圖4、5、6所示,相應(yīng)符號的描述如表1所示。

圖4 接收進程的FSM

圖5 發(fā)送進程的FSM

3 仿真分析

對于安全協(xié)議來說報文的延時是非常重要的指標,協(xié)議須保證隊尾報文延時滿足安全時限。如果超出重發(fā)時限沒有收到應(yīng)答報文,發(fā)送方安全鏈路層采取超時重發(fā)策略。為了測試組播方式對報文延時的影響,按表1中的參數(shù)進行仿真測試。測試采用1個發(fā)送方和4個接收方,為了避免發(fā)送窗口對報文的延時產(chǎn)生影響,發(fā)送窗口要足夠大(設(shè)為50個報文)。仿真時間以200 ms為周期,測試10 min。每個周期起始時,模擬發(fā)送方應(yīng)用層向分幀隊列發(fā)送n個200字節(jié)的應(yīng)用報文,規(guī)定n小于50,分別用組播和點對點的方式將數(shù)據(jù)發(fā)送到4個接收方,記錄接收方收到的4n個報文從發(fā)送方應(yīng)用層到接收方應(yīng)用層的平均延時,然后再對3 000個周期的報文平均延時取平均,仿真結(jié)果如圖7所示。

圖6 重發(fā)進程的FSM

進程狀態(tài)狀態(tài)描述接收進程INIT接收進程相關(guān)資源初始化IDLE等待接收接收socket緩沖隊列中的內(nèi)網(wǎng)幀ACK_proc應(yīng)答幀處理過程,通知重發(fā)進程DATA_proc非應(yīng)答幀處理過程發(fā)送進程INIT初始化發(fā)送進程相關(guān)資源nD_nW無數(shù)據(jù)_有發(fā)送窗口等待狀態(tài)Ew+Uw-可用窗口數(shù)加1,以用窗口數(shù)減1nD_nW無數(shù)據(jù)_無發(fā)送窗口等待狀態(tài)Qd++隊列中的數(shù)據(jù)數(shù)量加1snd_1發(fā)送窗口數(shù)量大于1時,將數(shù)據(jù)發(fā)送到socket發(fā)送緩沖snd_2發(fā)送窗口數(shù)量等于1時,將數(shù)據(jù)發(fā)送到socket發(fā)送緩沖eD_nW隊列中有數(shù)據(jù)_無發(fā)送窗口等待狀態(tài)重發(fā)進程INIT初始化重發(fā)進程相關(guān)資源IDLE無數(shù)據(jù)_有發(fā)送窗口等待狀態(tài)ACK_treat對應(yīng)答幀進行處理time_out數(shù)據(jù)超時warning_sys重發(fā)次數(shù)大于3次,向平臺報錯resend對消息進行重發(fā)

從圖7中可以看出,利用組播方式進行發(fā)送,可以減小報文的平均延時,而且隨著應(yīng)用輸入報文數(shù)量的增加,組播方式下報文的平均延時增長的速度小于點對點方式,當應(yīng)用輸入報文數(shù)量增加到5個時,組播方式下報文的平均延時已經(jīng)減小到點對點方式下的50%。利用OPNET提供的鏈路使用率統(tǒng)計變量進行觀察,發(fā)現(xiàn)通信鏈路上通信控制器到交換機方向,選擇組播發(fā)送方式的使用率僅為點對點發(fā)送方式的25%。

圖7 組播方式和點對點方式報文的平均延時

4 結(jié)語

本文提出了基于UML的安全協(xié)議組播報文的安全確認機制和一種利用OPNET的實時操作系統(tǒng)組播協(xié)議的建模思想。通過仿真研究,證明了支持組播的安全協(xié)議可以減小報文的延時。報文延時的減小,可以降低超時重發(fā)的概率,更有利于提高安全協(xié)議的性能。

[1] 馬連川,高倍力.基于通信的列車控制系統(tǒng)移動數(shù)據(jù)通信關(guān)鍵問題的探討[J].鐵道學(xué)報,2005,27(2):114.

[2] FETZER C,CRISTLAN F.Fail-awareness:An approach to construct fail-Safe systems[J].Real-time Systems,2003,24(2):203.

[3] KOPETZ H,GRILLINGER P,STEINHAMMER K.The Time-triggered ethernet (TTE) design[C]∥8th IEEE International Symposium on Object-oriented Real-time Distributed Computing(ISORC).Washington:IEEE Society,2005:22.

[4] 楊仕平,桑楠,熊光澤.基于Ethernet技術(shù)的安全關(guān)鍵實時網(wǎng)絡(luò)[J].軟件學(xué)報,2005,16(1):121.

[5] LEE K C,LEE S.Performance evaluation of switched Ethernet for real-time industrial communications[J].Computer Standards & Interfaces,2002,24(5):411.[6] ZHANG Y,TANG T,LI K P,et al.Formal verification of safety protocol in train control system[J].Science in China Series E:Technological Sciences,2011,54(11):3078.

[7] 張巖,唐濤,馬連川,等.基于交換式以太網(wǎng)安全通信協(xié)議的模型和仿真研究[J].鐵道學(xué)報,2010,32(3):43.

[8] IEEE Standard 802.3u.Media access control (MAC) parameters,physical layer,medium attachment units,and repeater for 100 Mb/s operation,type 100BASE-T[S].1995.

[9] IEC 62280-1.Railway applications-communication,signalling and processing systems.Part 1:Safety-related communication in closed transmission systems[S].2001.

[10] Wu J H,Zheng G.Real-time performance analysis of industrial embedded control systems using switched ethernet[C].∥IEEE International Conference on Networking,Sensing and Control.London:IEEE Society,2007:64.

Analyzing Method for Safety Protocol Performance Based on Multicast Packets

LIU Na

Safety protocol of zone controller (ZC) subsystem in communication based train control (CBTC) system is a key factor that determines whether the system is successful or not. A multicast sending and acknowledging method for safety protocol inner ZC is designed, the safety acknowledgement process for multicast packet is developed.Then,OPNET Modeler 10.0 is used to build a multi-task module of the safety protocol, and the communication process is simulated basing on the real running situation of ZC. The results show that the delay of the safety protocol based on multicast is about 50% lower than that of the protocol not based on multicast.

rail transit; communication based train control(CBTC); safety protocal; multicast packet

*中國鐵道科學(xué)研究院基金項目(2013YJ105)

U 231.7; TN 915.04

10.16037/j.1007-869x.2016.08.000

2015-01-05)