李玉蘭,李開成,李驍宇,陳思捷,劉木齊
(1.北京交通大學 電子信息工程學院,北京 100044;2.北京交通大學 軌道交通運行控制系統國家工程研究中心,北京 100044)
隨著城市軌道交通的發展,CBTC–基于通信的列車運行控制系統得到廣泛應用。由于用于CBTC系統設備研發和生產的統一規范還有待完善,使得各個廠商生產的設備之間存在較大差別,很多不同廠商的設備之間往往不能直接進行通信。在實際應用中,對于具體線路所使用的相關設備通常來自于不同的廠商,同時在實驗室進行仿真實驗時,也希望利用不同廠商的設備搭建一套CBTC最小系統。然而采用直接修改廠商設備接口以使各設備之間接口匹配的方式開發難度大、工期長。因此,設計可以用于CBTC系統各關鍵設備之間接口協議轉換的接口轉換應用層系統非常有意義。
本設計采用C#做后臺代碼開發工具,結合具體線路中參與運行的設備數量多,設備之間交互信息量大的實際特點,實現一種高效、實時的CBTC系統各個設備之間接口協議轉換的接口轉換應用層系統。
CBTC系統是基于通信的列車運行控制系統。一個典型的CBTC系統包括:列車自動監督系統(ATS,Automatic Train Supervision)、數據庫存儲單元(DSU,Database Storage Unit)、區域控制器(ZC,Zone Controller)、計算機聯鎖CI,Computer Interlocking)、車載控制器(VOBC,Vehicle 0n Board Controller)和數據通信系統(DCS,Data Communication System),包括骨干網、網絡交換機、無線接入點以及車載移動無線設備。
北京地鐵運營仿真實驗室是利用北京地鐵亦莊線數據搭建的一套CBTC最小系統,系統關鍵設備信息交互圖如圖1所示。

圖1 CBTC系統關鍵設備信息交互圖
在搭建的最小系統中,既有真實設備,也有仿真設備。仿真設備和仿真設備、仿真設備和真實設備、真實設備和仿真設備之間均存在信息交互。根據搭建系統所選擇廠商的設備特點,圖1中用虛線連接的部分在系統中不能直接通信,實線連接的部分可以直接通信。
在一套CBTC系統中CI、ZC、ATS、VOBC這4個子系統之間均存在信息交互,而接口轉換系統的作用即為保證各個子系統之間信息交互正常。
為了使系統正常運行,必須使不能直接通信的設備接口相互匹配。采用增加中間層(接口轉換系統層)的方式,不僅開發難度小、工期短,還可以提高系統的可擴展性和可維護性。因此接口轉換系統的開發將為CBTC最小系統的搭建,提供切實可行的方案。
為了使整個CBTC系統具有良好的可擴展性和可維護性,系統內部所有交互的信息均通過接口轉換系統進行分發和處理。本文主要論述與CBTC系統中存在信息交互的CI、ATS、ZC和VOBC這4個核心子系統之間的信息交互。
接口轉換系統由消息收發模塊和消息處理模塊兩個部分組成,即應用層和網絡層兩個部分。系統的整體結構如圖2所示。
系統消息交互流程為:由消息發送方設備(如CI)對應的數據網絡層設備(CI數據網絡層)接收原始消息,并將接收到的消息送入應用層進行處理,應用層將處理后的消息發送給接收方對應的數據網絡層(如ATS數據網絡層),再由數據網絡層設備發送給對應的接收設備。
采用此分布式結構,可以將消息的收發環節和處理環節分開,使得在調試和維護的過程中便于故障定位,提高系統可維護性。同時使接口轉換系統不受外圍設備數量和類型的影響。外圍設備數量的增加,只是帶來接口轉換系統處理消息量的增加,而外圍設備類型的增加,只需要在原有接口轉換系統的基礎上增加該設備類型對應的網絡層設備和應用層處理子模塊即可,提高了系統的可擴展性和實用性。
本文主要針對接口轉換系統的應用層進行設計和實現,以下簡稱應用層。

圖2 系統整體結構圖
應用層采用C#做后臺代碼開發工具,和網絡層之間采用TCP/UDP協議進行通信。應用層由消息接收模塊、消息處理模塊和消息發送模塊組成。其系統工作流程如圖3所示。
消息接收模塊采用TCP/UDP協議實時接收來自網絡層的消息。可行的消息接收方案有兩種。
(1)采用多線程技術
當有消息到達時立即接收并存儲;沒有消息到達時,應用層正常的對接收到的消息進行后續處理。
(2)采用單條消息處理機制
接收到一條消息時,立即對該條消息進行處理,并在將接收到的消息發送給網絡層之后,再接收下一條消息。
采用多線程技術,易使系統陷入死循環,且在滿足系統要求的前提下,處理機制比采用單條消息處理的機制復雜。所以在本設計中采用方案2的消息處理機制。

圖3 系統工作流程圖
單條消息處理機制的工作流程如圖4所示。

圖4 單條消息處理機制工作流程圖
消息處理模塊根據要搭建的CBTC系統要求,將接收到的原始消息,按照一定的規則進行處理,使其能被該條消息的接收設備所識別,從而保證CBTC系統各個設備之間通信正常。
在一套完整的CBTC系統中,參與工作的子系統多,交互的消息量大,使得消息處理模塊作為應用層系統的核心模塊,必須具備合理的消息處理機制,以快速、準確的對消息進行處理,同時還應具備一定的通用性和可擴展性,便于系統升級和后期維護。
同種類型的仿真設備和真實設備在與其它設備進行信息交互時,消息的內容和格式可能有所不同,從而需要應用層設備對其采用不同的處理機制。如ATS設備和仿真CI之間可以直接通信,而和真實CI之間不可以直接通信。所以對于消息處理模塊,在對接收到的原始消息進行處理時,需要同時考慮消息方向,和與該條消息相關的發送設備和接收設備是仿真設備還是真實設備,從而選擇正確的消息處理機制。
為了使消息處理模塊滿足性能要求,同時能有效地根據消息特征選擇處理機制,將消息處理模塊分為消息分類子模塊、ATS_CI消息處理子模塊、ATS_VOBC消息處理子模塊 、ATS_ZC消息處理子模塊、CI_ZC消息處理子模塊、CI_VOBC消息處理子模塊、ZC_VOBC消息處理子模塊、CI_CI消息處理子模塊8個子模塊。
在消息分類子模塊中,首先根據消息的發送方設備和接收方設備類型,選擇正確的處理機制,確定消息被送往的子模塊。若消息由ATS發往CI,則該條消息將被送到ATS_CI消息處理子模塊中進一步處理。
在消息處理子模塊中完成對消息的解包、處理、組包操作,完成協議轉換。
將消息處理模塊進行子模塊劃分,應用層系統在數據處理的過程中即可以根據消息的來源和消息的去向靈活選擇用于對消息進行處理的模塊和處理方式。同時,當外部設備類型和數量增加時,只需要增加相應的消息處理子模塊即可。
消息發送模塊采用TCP/UDP協議將轉換完成后的消息發送給網絡層,即系統根據消息的方向,從配置文件中找到網絡層設備所在的IP和端口,并將轉換完成后的消息利用TCP/UDP協議發往該端口,完成消息的發送。
在北京地鐵運營仿真實驗室平臺的基礎上,結合接口轉換器應用層和網絡層,對應用層系統的性能進行測試。
應用層系統測試指標主要有丟包率、誤組包率和時延。根據搭建的最小系統的要求,應用層系統應滿足的性能指標如表1所示。

表1 系統性能指標
其中亦莊線CBTC仿真實驗室系統各設備周期如表2所示。

表2 亦莊線CBTC仿真實驗室系統設備周期
在測試過程中系統各設備之間信息交互正常,各個設備均處于正常工作狀態。統計各設備之間信息交互50 000次所得的丟包率、誤組包率和時延測試結果如表3所示,時延測試柱狀圖如圖5所示。
從系統測試的統計結果可以看出,接口轉換應用層系統的最大丟包率為0.06‰(不包含由網絡本身引起的丟包),即50 000條消息中,有3條消息被丟包,滿足系統性能要求。誤組包率為0。延時時間和消息包的長度,處理過程的復雜度以及處理CPU時間等均有關,從測試結果可以看出,系統最大時延出現在CI->ATS的過程中,這是由于在一條由CI->ATS的消息中,所包含的數據量最多,處理過程也最復雜。而對于ZC->ATS、VOBC->ZC、ZC->VOBC等過程,數據量小,數據量變化不大,也基本不需要處理,所以時延最小,且時延最大值和平均值相等。應用層時延滿足系統性能需求。從系統的測試結果可以說明接口轉換應用層系統滿足設計要求。

表3 丟包率、誤組包率和時延測試結果

圖5 時延測試結果柱狀圖
本文在北京地鐵運營仿真實驗室平臺的基礎上,設計和實現了接口轉換器應用層系統。系統具有消息收發和協議轉換功能,能對接收到的交互信息按照用戶需求進行協議轉換,使CBTC系統各個設備之間正常通信,保證系統運行正常。
通過對系統的測試可以看出,系統在丟包率、誤組包率和時延等方面均滿足設計要求。且所設計的系統結構簡單,能靈活應對外圍設備數量和類型的變化,具有良好的通用性、可擴展性和可維護性。
[1]郜春海.基于通信的軌道交通列車運行控制系統[J].現代城市軌道交通,2007(2): 7-10.
[2]王 偉. CBTC 測試平臺關鍵問題研究[D].北京:北京交通大學,2008.
[3]郜春海,黃友能.CBTC 仿真測試系統研究報告[R].北京:北京交通大學CBTC 課題組,2007.
[4]郜春海,唐 濤.基于通信的城軌CBTC 系統研究報告[R].北京:北京交通大學運輸自動化所CBTC 課題組,2007.
[5]陳鋒華,劉 嶺,徐 松. 基于通信的列車控制(CBTC)系統[J]. 鐵路通信信號工程,2005(1):40-42.
[6]陳祥獻,王 東,黃 濤. CBTC系統仿真測試平臺設計[J]. 鐵路計算機應用,2010,20(8):50-56.
[7]王 偉,張建明. 基于最小系統的CBTC仿真測試平臺[J].都市快軌交通,2011,24(4):33-36.