李玉蘭，李開成，李驍宇，陳思捷，劉木齊

（1.北京交通大學 電子信息工程學院，北京 100044；2.北京交通大學 軌道交通運行控制系統(tǒng)國家工程研究中心，北京 100044）

隨著城市軌道交通的發(fā)展，CBTC–基于通信的列車運行控制系統(tǒng)得到廣泛應用。由于用于CBTC系統(tǒng)設備研發(fā)和生產(chǎn)的統(tǒng)一規(guī)范還有待完善，使得各個廠商生產(chǎn)的設備之間存在較大差別，很多不同廠商的設備之間往往不能直接進行通信。在實際應用中，對于具體線路所使用的相關設備通常來自于不同的廠商，同時在實驗室進行仿真實驗時，也希望利用不同廠商的設備搭建一套CBTC最小系統(tǒng)。然而采用直接修改廠商設備接口以使各設備之間接口匹配的方式開發(fā)難度大、工期長。因此，設計可以用于CBTC系統(tǒng)各關鍵設備之間接口協(xié)議轉換的接口轉換應用層系統(tǒng)非常有意義。

本設計采用C#做后臺代碼開發(fā)工具，結合具體線路中參與運行的設備數(shù)量多，設備之間交互信息量大的實際特點，實現(xiàn)一種高效、實時的CBTC系統(tǒng)各個設備之間接口協(xié)議轉換的接口轉換應用層系統(tǒng)。

1 北京地鐵運營仿真實驗室設備簡介

CBTC系統(tǒng)是基于通信的列車運行控制系統(tǒng)。一個典型的CBTC系統(tǒng)包括：列車自動監(jiān)督系統(tǒng)（ATS，Automatic Train Supervision）、數(shù)據(jù)庫存儲單元（DSU，Database Storage Unit）、區(qū)域控制器（ZC，Zone Controller）、計算機聯(lián)鎖CI，Computer Interlocking）、車載控制器（VOBC，Vehicle 0n Board Controller）和數(shù)據(jù)通信系統(tǒng)（DCS，Data Communication System），包括骨干網(wǎng)、網(wǎng)絡交換機、無線接入點以及車載移動無線設備。

北京地鐵運營仿真實驗室是利用北京地鐵亦莊線數(shù)據(jù)搭建的一套CBTC最小系統(tǒng)，系統(tǒng)關鍵設備信息交互圖如圖1所示。

圖1 CBTC系統(tǒng)關鍵設備信息交互圖

在搭建的最小系統(tǒng)中，既有真實設備，也有仿真設備。仿真設備和仿真設備、仿真設備和真實設備、真實設備和仿真設備之間均存在信息交互。根據(jù)搭建系統(tǒng)所選擇廠商的設備特點，圖1中用虛線連接的部分在系統(tǒng)中不能直接通信，實線連接的部分可以直接通信。

在一套CBTC系統(tǒng)中CI、ZC、ATS、VOBC這4個子系統(tǒng)之間均存在信息交互，而接口轉換系統(tǒng)的作用即為保證各個子系統(tǒng)之間信息交互正常。

2 接口轉換系統(tǒng)設計

為了使系統(tǒng)正常運行，必須使不能直接通信的設備接口相互匹配。采用增加中間層（接口轉換系統(tǒng)層）的方式，不僅開發(fā)難度小、工期短，還可以提高系統(tǒng)的可擴展性和可維護性。因此接口轉換系統(tǒng)的開發(fā)將為CBTC最小系統(tǒng)的搭建，提供切實可行的方案。

為了使整個CBTC系統(tǒng)具有良好的可擴展性和可維護性，系統(tǒng)內(nèi)部所有交互的信息均通過接口轉換系統(tǒng)進行分發(fā)和處理。本文主要論述與CBTC系統(tǒng)中存在信息交互的CI、ATS、ZC和VOBC這4個核心子系統(tǒng)之間的信息交互。

接口轉換系統(tǒng)由消息收發(fā)模塊和消息處理模塊兩個部分組成，即應用層和網(wǎng)絡層兩個部分。系統(tǒng)的整體結構如圖2所示。

系統(tǒng)消息交互流程為：由消息發(fā)送方設備（如CI）對應的數(shù)據(jù)網(wǎng)絡層設備（CI數(shù)據(jù)網(wǎng)絡層）接收原始消息，并將接收到的消息送入應用層進行處理，應用層將處理后的消息發(fā)送給接收方對應的數(shù)據(jù)網(wǎng)絡層（如ATS數(shù)據(jù)網(wǎng)絡層），再由數(shù)據(jù)網(wǎng)絡層設備發(fā)送給對應的接收設備。

采用此分布式結構，可以將消息的收發(fā)環(huán)節(jié)和處理環(huán)節(jié)分開，使得在調(diào)試和維護的過程中便于故障定位，提高系統(tǒng)可維護性。同時使接口轉換系統(tǒng)不受外圍設備數(shù)量和類型的影響。外圍設備數(shù)量的增加，只是帶來接口轉換系統(tǒng)處理消息量的增加，而外圍設備類型的增加，只需要在原有接口轉換系統(tǒng)的基礎上增加該設備類型對應的網(wǎng)絡層設備和應用層處理子模塊即可，提高了系統(tǒng)的可擴展性和實用性。

本文主要針對接口轉換系統(tǒng)的應用層進行設計和實現(xiàn)，以下簡稱應用層。

圖2 系統(tǒng)整體結構圖

3 應用層系統(tǒng)設計

應用層采用C#做后臺代碼開發(fā)工具，和網(wǎng)絡層之間采用TCP/UDP協(xié)議進行通信。應用層由消息接收模塊、消息處理模塊和消息發(fā)送模塊組成。其系統(tǒng)工作流程如圖3所示。

3.1 消息接收模塊

消息接收模塊采用TCP/UDP協(xié)議實時接收來自網(wǎng)絡層的消息。可行的消息接收方案有兩種。

（1）采用多線程技術

當有消息到達時立即接收并存儲；沒有消息到達時，應用層正常的對接收到的消息進行后續(xù)處理。

（2）采用單條消息處理機制

接收到一條消息時，立即對該條消息進行處理，并在將接收到的消息發(fā)送給網(wǎng)絡層之后，再接收下一條消息。

采用多線程技術，易使系統(tǒng)陷入死循環(huán)，且在滿足系統(tǒng)要求的前提下，處理機制比采用單條消息處理的機制復雜。所以在本設計中采用方案2的消息處理機制。

圖3 系統(tǒng)工作流程圖

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

圖4 單條消息處理機制工作流程圖

3.2 消息處理模塊

消息處理模塊根據(jù)要搭建的CBTC系統(tǒng)要求，將接收到的原始消息，按照一定的規(guī)則進行處理，使其能被該條消息的接收設備所識別，從而保證CBTC系統(tǒng)各個設備之間通信正常。

在一套完整的CBTC系統(tǒng)中，參與工作的子系統(tǒng)多，交互的消息量大，使得消息處理模塊作為應用層系統(tǒng)的核心模塊，必須具備合理的消息處理機制，以快速、準確的對消息進行處理，同時還應具備一定的通用性和可擴展性，便于系統(tǒng)升級和后期維護。

同種類型的仿真設備和真實設備在與其它設備進行信息交互時，消息的內(nèi)容和格式可能有所不同，從而需要應用層設備對其采用不同的處理機制。如ATS設備和仿真CI之間可以直接通信，而和真實CI之間不可以直接通信。所以對于消息處理模塊，在對接收到的原始消息進行處理時，需要同時考慮消息方向，和與該條消息相關的發(fā)送設備和接收設備是仿真設備還是真實設備，從而選擇正確的消息處理機制。

為了使消息處理模塊滿足性能要求，同時能有效地根據(jù)消息特征選擇處理機制，將消息處理模塊分為消息分類子模塊、ATS_CI消息處理子模塊、ATS_VOBC消息處理子模塊 、ATS_ZC消息處理子模塊、CI_ZC消息處理子模塊、CI_VOBC消息處理子模塊、ZC_VOBC消息處理子模塊、CI_CI消息處理子模塊8個子模塊。

在消息分類子模塊中，首先根據(jù)消息的發(fā)送方設備和接收方設備類型，選擇正確的處理機制，確定消息被送往的子模塊。若消息由ATS發(fā)往CI，則該條消息將被送到ATS_CI消息處理子模塊中進一步處理。

在消息處理子模塊中完成對消息的解包、處理、組包操作，完成協(xié)議轉換。

將消息處理模塊進行子模塊劃分，應用層系統(tǒng)在數(shù)據(jù)處理的過程中即可以根據(jù)消息的來源和消息的去向靈活選擇用于對消息進行處理的模塊和處理方式。同時，當外部設備類型和數(shù)量增加時，只需要增加相應的消息處理子模塊即可。

3.3 消息發(fā)送模塊

消息發(fā)送模塊采用TCP/UDP協(xié)議將轉換完成后的消息發(fā)送給網(wǎng)絡層，即系統(tǒng)根據(jù)消息的方向，從配置文件中找到網(wǎng)絡層設備所在的IP和端口，并將轉換完成后的消息利用TCP/UDP協(xié)議發(fā)往該端口，完成消息的發(fā)送。

4 應用層系統(tǒng)測試

在北京地鐵運營仿真實驗室平臺的基礎上，結合接口轉換器應用層和網(wǎng)絡層，對應用層系統(tǒng)的性能進行測試。

應用層系統(tǒng)測試指標主要有丟包率、誤組包率和時延。根據(jù)搭建的最小系統(tǒng)的要求，應用層系統(tǒng)應滿足的性能指標如表1所示。

表1 系統(tǒng)性能指標

其中亦莊線CBTC仿真實驗室系統(tǒng)各設備周期如表2所示。

表2 亦莊線CBTC仿真實驗室系統(tǒng)設備周期

在測試過程中系統(tǒng)各設備之間信息交互正常，各個設備均處于正常工作狀態(tài)。統(tǒng)計各設備之間信息交互50 000次所得的丟包率、誤組包率和時延測試結果如表3所示，時延測試柱狀圖如圖5所示。

從系統(tǒng)測試的統(tǒng)計結果可以看出，接口轉換應用層系統(tǒng)的最大丟包率為0.06‰（不包含由網(wǎng)絡本身引起的丟包），即50 000條消息中，有3條消息被丟包，滿足系統(tǒng)性能要求。誤組包率為0。延時時間和消息包的長度，處理過程的復雜度以及處理CPU時間等均有關，從測試結果可以看出，系統(tǒng)最大時延出現(xiàn)在CI->ATS的過程中，這是由于在一條由CI->ATS的消息中，所包含的數(shù)據(jù)量最多，處理過程也最復雜。而對于ZC->ATS、VOBC->ZC、ZC->VOBC等過程，數(shù)據(jù)量小，數(shù)據(jù)量變化不大，也基本不需要處理，所以時延最小，且時延最大值和平均值相等。應用層時延滿足系統(tǒng)性能需求。從系統(tǒng)的測試結果可以說明接口轉換應用層系統(tǒng)滿足設計要求。

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

圖5 時延測試結果柱狀圖

5 結束語

本文在北京地鐵運營仿真實驗室平臺的基礎上，設計和實現(xiàn)了接口轉換器應用層系統(tǒng)。系統(tǒng)具有消息收發(fā)和協(xié)議轉換功能，能對接收到的交互信息按照用戶需求進行協(xié)議轉換，使CBTC系統(tǒng)各個設備之間正常通信，保證系統(tǒng)運行正常。

通過對系統(tǒng)的測試可以看出，系統(tǒng)在丟包率、誤組包率和時延等方面均滿足設計要求。且所設計的系統(tǒng)結構簡單，能靈活應對外圍設備數(shù)量和類型的變化，具有良好的通用性、可擴展性和可維護性。

[1]郜春海．基于通信的軌道交通列車運行控制系統(tǒng)[J].現(xiàn)代城市軌道交通，2007（2）： 7-10．

[2]王 偉. CBTC 測試平臺關鍵問題研究[D].北京：北京交通大學，2008．

[3]郜春海，黃友能．CBTC 仿真測試系統(tǒng)研究報告[R].北京：北京交通大學CBTC 課題組，2007．

[4]郜春海，唐 濤.基于通信的城軌CBTC 系統(tǒng)研究報告[R].北京：北京交通大學運輸自動化所CBTC 課題組，2007.

[5]陳鋒華，劉 嶺，徐 松. 基于通信的列車控制（CBTC）系統(tǒng)[J]. 鐵路通信信號工程，2005（1）：40-42.

[6]陳祥獻，王 東，黃 濤. CBTC系統(tǒng)仿真測試平臺設計[J]. 鐵路計算機應用，2010，20（8）：50-56.

[7]王 偉，張建明. 基于最小系統(tǒng)的CBTC仿真測試平臺[J].都市快軌交通，2011，24（4）：33-36.