引入接口中間件的基于通信的列車控制系統仿真＊

朱 麟 徐中偉 喻 鋼 朱 龍

（同濟大學電子與信息工程學院，201804，上海∥第一作者，碩士研究生）

基于通信的列車控制（Communications－Based Train Control，簡為CBTC）系統包含了大量厚重的信息資源，以及各種監控數據、龐大的通信網絡、各種數據庫系統。然而，由于這些系統建設和實施數據管理系統的階段性、技術性以及其他因素的影響，導致大量數據的存貯方式不同，各系統自成體系、各自為政，無法實現系統間信息的交互和融合，形成了一個個的信息孤島。解決各系統間信息的有效、可靠、實時通信，成為CBTC系統需要解決的重要問題之一。

早期的CBTC接口仿真系統采用統一的接口規范來約束各子系統的信息格式。這在一定程度上雖然解決了CBTC各子系統信息聚合與交互問題，但由于CBTC系統自身龐大的信息體系，各子系統需要添加自身冗余信息接口龐大，無形中增加了CBTC系統的復雜程度和消耗。此外，由于子系統需要花費冗余的時間對傳遞的信息進行格式轉換，降低了信息交互的可靠性和有效性，很難真正實現CBTC系統各子系統間信息的無縫傳遞，降低了系統傳遞消息的效率，額外增加系統的負擔。

針對CBTC接口仿真系統現存的信息交互的問題以及如何有效地解決上述問題，提出一種新的接口信息傳遞模式——接口中間件。接口中間件技術是建立在分布對象中間件（Distributed Object Middleware）的基本架構上，提出適合CBTC系統接口信息交互的異步通信模式：通信雙方并不直接交互，而是基于代理（中間件）對象進行交互，接口中間件負責對所要傳遞的信息進行格式統一，協議轉換，旨在解決在分布式異構網絡環境下信息系統集成的異構性、可重用性、互操作性問題［3］。

1 接口中間件技術

接口中間件采用分布式對象中間件基本架構，其核心是對象請求代理。它的作用在于提供一個通信框架，透明地在異構的分布計算環境中傳遞對象請求。對象請求代理是對象總線，它定義了異構環境下對象透明地發送請求和接收響應的基本機制。對象請求代理使對象可以透明地向其他對象發出請求或接受其他對象（這些對象可以既位于本地也可以位于遠程機器上）的響應，并且攔截請求調用，負責找到可以實現請求的對象、傳送參數、調用相應的方法、返回結果等。客戶對象并不知道同服務器對象通信、激活或存儲服務器對象的機制，也不必知道服務器對象位于何處、它是用何種語言實現的、使用什么操作系統或其它不屬于對象接口的系統成分，這些工作由對象請求代理透明地完成［1］。

分布式體系結構能夠很好地將分布式對象技術和網絡結合起來，使得應用跨越不同的網絡體系結構、不同的操作系統，不同的編程語言進行相互通信，使網絡的“互連”特性真正成為現實［2］。

1.1 接口中間件對象與接口定義語言

中間件對象是能夠放在忘了任何位置的智能實體。它們包裝成二進制組件，可以通過方法調用來訪問這些組件。用來創建服務器對象的語言和編譯器都對客戶完全透明。客戶不需要知道分布式對象駐留在何處或者運行在什么操作系統上，它可以是在同一進程中，或者位于網絡中的某臺機器上。并且客戶不需要知道服務器對象是如何實現的。

支持中間件對象的關鍵技術是接口定義語言（IDL）方法。中間件采用IDL合同來規定一個組件的邊界以及它與潛在客戶的合同接口。中間件接口定義是定義語言而非編程語言，它純粹是說明性的。這意味著它沒有提供任何實現細節，只能用來定義接口和數據結構。程序員可以用本機語言生成系統處理中間件對象，IDL向駐留在中間件總線上的所有服務器和組件提供了與操作系統和程序設計語言無關的接口，它允許用不同程序設計語言編寫的客戶機和服務器對象能夠操作。中間件將接口與實現分開，提供了中性語言的數據類型，從而使跨語言和操作系統邊界調用對象成為可能［1］。

1.2 接口中間件體系結構

接口中間件主要由三部分組成（見圖1）：事件請求部分，事件響應部分和對象請求中介（ORB）。對象請求中介即對象總線，通過它，各個對象可以透明地向本地或遠端的其他對象發出事件請求／接收事件響應。客戶并不知道聯系、激活或存儲對象的具體機制，這些工作都由對象請求中介來完成，它是在對象之間建立請求或響應關系。通過對象請求中介，事件請求對象可以調用事件響應對象上的方法，這個事件響應對象可以在同一機器上，也可以在網絡的另一邊。對象請求中介負責尋找可以執行該請求的對象，傳遞參數，調用方法，最后返回處理結果。事件請求對象不需要知道對象的位置、程序設計語言、操作系統或不屬于對象接口的任何其他系統特征。與傳統的客戶機／服務器系統不同的是，對象請求中介上的對象關系是不確定的，它既可以作為客戶來發出事件請求，也可以作為服務器來進行事件響應，使系統結構靈活，功能強大。

圖1 接口中間件系統圖

接口中間件屏蔽了客戶機／服務器實現細節，以事件請求和事件響應來區分所需操作的對象，減輕了用戶的負擔，將所需要的工作交給對象請求中介來做，使系統流程更清晰，增加了系統消息處理與聚合的可靠性與有效性。

2 CBTC接口仿真系統設計

2.1 CBTC系統及接口仿真概況

CBTC系統是一個龐大的系統，它打破了傳統基于軌道電路列車控制系統的限制，提高軌道運輸基礎設施的使用效率，使用軌旁以及車載關鍵處理器處理列車狀態數據和控制數據，提供連續的列車自動防護，列車自動運行以及列車自動監督功能。CBTC系統的整體架構如圖2，主要由軌旁運行控制系統和車載子系統這兩個集成的子系統構成，此外還包括各類需要進行信息交互的其他控制系統如聯鎖、站臺信息系統、ATS（列車自動運行監控）系統等等。這里以軌旁運行控制系統為研究對象。全文中所提的CBTC接口系統，即為與軌旁運行控制系統以及與之相關的部分。

CBTC系統在打破原有運控系統架構的同時，帶來的卻是系統的安全隱患。雖然系統控制人員對CBTC系統各個環節都給予了足夠的重視，但是數據傳遞的滯后和信息的不透明依然存在。系統繁雜的信息交互主要存在于其接口系統。軌旁運控系統需要對軌道線路上的各種信息進行采集和處理，并將信息及時地反應給車載與列車控制中心。應答器、計軸、信號機、道岔等設備之間繁雜的交互信息需要由軌道旁路實時地反映給軌道旁路運控系統。系統應用框架如圖2。

圖2 系統應用框架

軌旁運行控制系統作為核心系統，需要與其他系統有實時的信息交互，包括與聯鎖系統設備單元狀態信息，外部數字輸入單元狀態，與ATS系統之間有關臨時限速TSR和跳停信息的交互，也包括單元信息的交互，與站臺系統之間有關緊急停車按鈕EMP（緊急停車按鈕）、PSD（站臺屏蔽門）信息的交互，與中央服務和診斷系統之間的關于診斷和故障的信息等等。軌旁運行控制系統需要對上述信息進行處理并將其分類存儲，當其他系統需要對其中信息發出請求時，再轉發給該系統。這樣的系統結構與信息處理方式無疑加大了軌旁運行控制系統自身的負擔，也不利于各CBTC系統間信息的交互。

引入接口中間件，將軌旁運行控制系統與聯鎖、ATS、軌旁服務與診斷等系統進行的交互信息一并交給接口中間件處理，由其負責處理CBTC系統各部分對信息的請求與響應，統一對信息結構和類型進行轉換以及相應的邏輯處理，使系統各部分無需考慮信息傳遞的結構、傳遞方式等各方面的因素。對信息進行模塊化的處理，減少了系統內的冗余代碼和信息處理的時間損耗，以及各系統自身負擔，提高信息采集的準確性，以及信息處理的實時性［4］。

2.2 CBTC接口仿真設計

在引入接口中間件之后，CBTC接口仿真系統可分為三層：軌旁控制管理層（軌旁運行控制系統），基于接口中間件的分布對象中間件層和設備控制層。軌旁控制管理層負責向接口中間件提出信息請求，并等待接口中間件反饋自身所需的信息；設備控制層則是將底層各應用設備的實時數據傳輸給中間件，并對底層各種設備進行總控。

接口中間件位于軌旁控制管理層和設備控制層之間。對軌旁控制管理層來說，接口中間件通過ORB接口和IDL樁接收來自軌旁控制系統所需信息的請求。這里不涉及控制器種類、現場總線和通信協議不同的影響，這使得軌旁控制管理應用與管理層通信模塊相互透明，功能相互獨立。對設備控制層來說，接口中間件通過ORB接口和對象適配器與其他各種類控制器交換數據，這很自然地屏蔽了分布式環境中各種網絡協議、硬件體系結構、操作系統、數據庫等方面的差異性，在異構環境中實現對象互操作，并協調操作的一致性和完整性。其系統架構如圖3。

圖3 接口仿真系統框架

從圖3可以看出，系統還具有良好的擴展性。當設備控制層增加設備時，只需在接口中間件中配置新的對象參數；當管理層增加應用時，只需在IDL樁中添加合適的訂閱記錄即可，軌旁運行控制系統無需添加冗余的代碼對所添加的新設備進行實時數據的采集。

2.3 CBTC接口仿真實現

在系統中，接口中間件負責對數據進行采集與處理，因此負責與外部設備信息交互的IDL接口定義尤為重要。IDL不是編程語言，只能用來定義接口，而不是去實現某個接口。此外，IDL獨立于任何編程語言，但可以將它映射為其他常用的語言：IDL編譯器將服務對象（軌旁運行控制系統和設備控制層）接口的請求IDL消息轉換為具體實現語言的碼根和框架。碼根為接口中的每一個操作（方法）提供一種虛實現，它負責將編程語言轉化為IDL描述語言，發送到對象服務端，并對對象實現的返回進行解碼，將處理結果（消息信息）或異常信息反饋出來；框架則是提供了一個為指定的接口編寫即對象實現代碼的框架，對系統請求進行解碼，定位符合要求的對象，并將執行結果或異常信息進行解碼后返回系統。軌道旁路設備管理層通過接口中的請求消息事件創建一個請求事件，在這個調用請求中包含目標對象引用、方法名、參數表，所需信息等等。設備控制層則通過IDL接口提供對象方法的實現及返回結果。

簡單的IDL接口原理如圖4所示。

圖4 系統IDL接口原理圖

事件響應端支持事件通知和使能事件兩個接口，而事件請求端有請求事件消息接口。事件響應端和事件請求端都應支持建立連接和斷開連接的操作。事件請求端應支持事件傳遞時的屬性通用事件頭，如事件標志、類型名稱、事件源標志；另外，這個接口允許（事件體中）附帶一個參數快速地傳給指定的事件。如果應用中需要傳遞更多的參數，應該定義一個新的接口并繼承這個父接口。

因此，根據分布對象中間件接口的標準定義，CBTC系統仿真接口定義如下：

上述定義中，EventContent定義了事件的結構，它由事件號以及事件所屬類型和時間來源三部分組成。EventRequest接口定義了事件請求和事件發布兩個接口。其中事件請求接口中包括事件請求函數和事件請求退出函數，當事件請求者需要訪問某數據時，它通過事件請求函數向中間件提出申請，當獲得相應的信息時調用自身退出函數關閉自身請求。EventBrocase接口是由對象注冊和對象注銷兩個函數構成，事件請求者在請求之前需要向中間件進行使能注冊，得到中間件的認可后方可對中間件包含的各類信息進行訪問。這樣做提高了整個系統的安全性，能夠防止其他無權事件請求者的惡意訪問。

在本系統中，一個事件請求者（軌旁運行控制系統）和一個事件提供者（設備控制端）無須保持聯系，彼此是匿名的，它們只需與處于它們之間的分布式對象中間件保持聯系。通過合適的通信安全協議，如一個可靠的多播協議等，它們與中間件進行信息事件請求和響應，這樣不僅解耦了通信雙方，還大大提高了匹配速度。另外，中間件的過濾器可以合并和刪除冗余的請求條件，使中間件的效率提高。

在通信系統中，一個事件提供者需要分布對象中間件來發布事件，一個事件發布的格式是類型名稱和屬性（參數名稱）。一個事件請求者需要找到相應的對象中間件來接收事件。對于標準事件，中間件接口定義如下：

上述定義中，EventReflection接口中定義了新增設備和刪減設備的函數，這樣方便系統對設備進行管理，也使系統具有相當好的擴展性，方便系統操作。Pxy接口中繼承了EventRequest和EventBrocast這兩個接口，并新增了一個返回值為布爾類型的查找函數，使中間件能夠系統地對自身所存儲的信息進行管理。

2.4 CBTC接口仿真系統應用實例

CBTC系統正常運行時，軌旁運行控制系統向中間件提出請求，要求獲得軌道上各類信息（信號機、道岔、軌道等）；分布對象中間件收到請求經過驗證后，根據請求在自身的存儲器中搜索相應的信息，搜到后反饋給軌旁運行控制系統；軌旁運行控制系統將接收到的信息加以處理后顯示在自身的界面顯示上，如圖5。

圖5 軌旁運行控制系統設備信息顯示界面

設備控制層則是實時將自身的數據反饋給中間件，實現數據的實時更新。以設備狀態為例，設備的狀態是由一個或多個二進制碼表示的，如圖6所示。

3 結語

分布式對象中間件在CBTC接口仿真系統的應用研究是一個全新的課題，是實現接口數據傳輸有效性、通用性、實時性的重要實現方式之一。

CBTC系統間的大量厚重的相互通信的各類信息資源、各種監控數據和各種系統數據，可由分布中間件集中處理。而分布式對象中間件是位于硬件、操作系統平臺和應用程序之間的通用服務系統，可實現不同硬件和操作系統平臺上的數據共享和應用互操作。利用此技術可為CBTC系統信息交互問題開辟新的思路，從理論上完美地解決CBTC系統中的問題，根本上改變了軌道交通運行控制的運作模式，大幅度提高了系統的效率，具有很好的發展前景，以及很好的可行性和實際應用性。

［1］潘浩.分布式對象中間件結構與性能的研究［D］.河北：河北燕山大學，2001.

［2］吳泉源，賈焰，周斌.分布對象中間件Starbus［J］.計算機工程與應用，2002，16（3）：195.

［3］梅宏.軟件中間件技術現狀及發展［D］.北京：北京大學信息科學技術學院軟件研究所，2004.

［4］閆曉芬，郭銀章.基于P／S模式的分布對象中間件異步通信接口［J］.計算機工程，2009，6（3）：125.

［5］符春，繆力，徐藝.中間件技術在汽車客運聯網售票系統中的應用［J］.電腦知識與技術，2010，6（2）：1219.

［6］蔡增玉，甘勇.一種基于中間件的可信軟件保護模型［J］.計算機應用與軟件，2010，27（3）：71.

［7］Marko C，Mavko B.A dynamic fault tree［J］.Reliability Engineering and System Safety，2002，75（1）：83.