楊 將,鄧永祁,鄧國知
(湖南中車時代通信信號有限公司,長沙 410005)
隨著科學技術不斷發展與創新,鐵路的信息化已逐漸走向成熟,在此背景下,綜合型、企業級系統應用進一步深化。在中國國家鐵路集團有限公司發布的《鐵路信息化總體規劃》及《鐵路“十三五”發展規劃》中提到,到2020 年,將在全路建成具有中國特色的鐵路運輸信息系統,鐵路建設的加快已然導致鐵路信息化建設的加快。目前LKJ 設備運行監測管理系統(LMD 系統)已完成車地數據傳輸、采集、分析和應用于一體,具備海量數據的獲取能力。為進一步深化服務能力,建立集監測、控制和管理決策為一體的智能化信息系統。LMD 系統在保持LAIS 系統基本結構、應用功能和技術體系完整性的基礎上,通過對既有LAIS 車載設備改造或采用TSC2 設備,建立互聯網環境中云數據中心的數據接收、處理、分發機制等,實現LKJ 設備運行狀態和數據版本運用狀態的實時監測和管理,并為鐵路運輸及相關作業提供管理信息支持,確保LKJ 系統設備的穩定運行和安全風險的有效管控。
LMD 系統通過遠程無線傳輸裝置實現實時監測機車運行狀態、車載設備質量、LKJ 數據版本、數據換裝、機車檢測與檢修狀態。系統地面服務器與車載終端進行實時海量的數據交互,隨著鐵路局機車數量、系統功能與交互數據量不斷增加,數據庫訪問操作頻率上升,導致數據庫與系統性能出現瓶頸,車地數據交互隊列堵塞與系統訪問卡頓。因此,本文設計基于RMI 分布式技術的LMD 系統性能優化與實現,應用RMI 分布式技術,提升系統數據交互操作性能、訪問體驗。
LMD 系統技術結構共分為6 層,可視層、控制層、業務層、支撐層、數據層以及基礎設施層。如圖1 所示,可視層主要采用BootStrap 前端框架、Html5、Javascript 和css3 技術,在Web 端實現數據渲染。控制層通過攔截分發器轉發前端發送的請求,并把業務層處理完的響應返回到前端,其通過數據適配插件適配表現層與業務層的差異。業務層Spring 為后臺提供事務與Bean 管理接口,通過IOC 的注解方式實現Bean 的解析和管理。在支撐層部署分布式RMI 服務,為業務層與數據層之間的高并發數據交互與訪問提供高效服務。同時,借助Spring 的優勢,系統降低了業務對象替換的復雜性,提高了組件之間的解耦。基于Hibernate 框架的支撐層通過水平和垂直分庫支持大數據量處理。

圖1 LMD系統技術架構圖Fig.1 Technological architecture diagram of LMD system
遠程方法調用(Remote Method Invocation,RMI)是J2EE 中一項非常重要的技術,能夠實現遠程過程調用 (Remote Procedure Call,RPC),便于Java 分布式應用程序開發,高吞吐業務功能解耦與分布式部署。
它使得Java 程序之間能夠實現靈活的、可擴展的分布式通信。RMI 允許對象存在于多個指定地址空間,分布在不同的Java 虛擬機上。每個指定地址空間可以在同一計算機上或網上的不同計算機上。RMI 為Java 對象的分布式計算提供了一個簡單而直接的模型,可以把代理和業務邏輯遷移到最具有存在意義的網絡節點上。
如圖2 所示,為提升系統數據交互操作性能、訪問體驗,以RMI 分布式技術部署車地數據交互服務、機車運行數據服務、機車定位糾偏服務、車載設備監測服務。車地數據交互服務作為地面通信軟件的載體不斷接收大量機車運行數據、車載設備運行數據和向車載無線傳輸裝置轉發系統指令,涉及海量數據計算、數據處理以及與數據持久層頻繁讀寫操作。機車運行數據服務通過與機車定位糾偏服務交互完成機車定位,車載設備監測服務對車載設備運行狀態實時監測,對車載設備故障與隱患進行報警。

圖2 系統分布式部署結構圖Fig.2 Distributed deployment structure diagram of LMD system
隨著LMD 系統在全路全面推廣運用,同時車載TSC2 設備運用數量急劇增加,LMD 系統的車地數據交互、機車運行數據計算、車載設備監測等功能的性能急劇下降。為解決系統性能瓶頸,本文旨在設計基于RMI 分布式的LMD 系統性能優化與實現,采用RMI 技術分布式車地數據交互服務、機車運行數據服務、機車定位糾偏服務和車載設備監測服務到不同的服務器,并分別在各服務器采用緩存技術實現車地通信交互數據、機車運行數據、車載設備監測數據的緩存,從而解決LMD 系統原有架構設計弊端,避免數據持久層不斷大量讀寫和單服務器性能受限的問題,提高LMD 系統的整體性能。
如圖3 所示,系統采用3 層結構模式實現RMI。在整個體系結構中,客戶端通過本地Java虛擬機環境下的樁對象遠程調用服務端的對象方法。

圖3 RMI模型Fig.3 RMI model
1)遠程調用過程
a.客戶端查詢服務端的注冊表并獲取遠程對象引用。客戶端通過調用本地JAVA虛擬機環境的樁對象,傳遞遠程對象方法的序列化參數到本地遠程引用層。
b.樁對象與遠程對象保持完全一致的接口,客戶端通過調用相應的樁對象完成遠程對象方法調用。遠程引用層在將樁對象的本地引用轉換為服務端的遠程對象的遠程引用之后,將調用過程傳遞給傳輸層,由傳輸層通過TCP 協議發送調用。

圖4 車地數據交互流程圖Fig.4 Vehicle-ground data interaction flowchart
c.服務端傳輸層監聽入站連接,接收客戶端遠程調用,轉發調用至服務端遠程引用層。
d.遠程引用層轉換客戶端遠程引用為本地Java 虛擬機的引用,并轉發到服務端骨架。
e.骨架讀取并傳遞引用的參數,服務端接收參數,調用實際對象方法。
2)結果返回過程
a.如果遠程方法調用后有返回值,則服務端將方法執行結果沿“骨架”“傳輸層”向下傳遞。
b.客戶端的傳輸層接收到返回值后,沿“傳輸層”“樁”向上傳遞,樁對象反序列化返回值,傳遞至客戶端程序。
LMD 系統分布式服務主要由車地數據交互服務、機車運行數據服務、機車定位糾偏服務和車載設備監測服務,如圖2 所示,取締系統功能模塊集中式部署,不同服務之間通過RMI 遠程調用訪問資源。與此同時,各服務采用緩存技術,經過計算和處理的數據均緩存在內存中,不同業務的服務數據計算和數據交互效率高。
2.2.1 車地數據交互
車地交互數據主要包括機車運行數據、車載設備運行數據、LKJ 運行文件。車載無線傳輸裝置TSC 不斷向車地數據交互服務的地面ICS 通信程序發送機車運行數據、車載設備運行數據,數據處理程序DPS 接收、實時計算和處理ICS 通信轉發的數據,并緩存運算結果與數據。與此同時,TSC 與ICS 通過3 次握手協議傳輸車載LKJ 運行文件。
如圖4 所示,車地數據交互流程設計如下:
Step1:TSC 向地面ICS 發送機車運行數據、車載設備運行數據,轉Step2。否則轉Step4;
Step2:地面ICS 轉發機車運行數據、車載設備運行數據給DPS,轉Step3;
Step3:DPS 計算處理車載數據并緩存;
Step4:TSC 通知地面ICS 產生新LKJ 運行文件,轉Step5;
Step5:ICS 轉發新文件標志給DPS,轉Step6;
Step6:DPS 通過ICS 發送下載目錄文件命令,轉Step7;
Step7:TSC 收到下載命令,下載目錄文件,轉Step8;
Step8:DPS 更新目錄文件對應記錄的下載狀態,并傳輸目錄文件到地面,轉Step9;
Step9:解析目錄文件后,DPS 通過ICS 向TSC 請求未下載的新LKJ 文件,轉Step10;
Step10:TSC 向 地 面 傳 輸LKJ 文 件, 轉Step11;
Step11:DPS 更新下載文件狀態,轉Step12;Step12:DPS 緩存文件與下載結果。
2.2.2 機車運行數據處理

圖5 機車運行數據處理流程圖Fig.5 Locomotive operation data processing flowchart
機車運行數據服務從車地數據交互服務接收機車數據進行處理。如圖5 所示,系統通過將接收數據與緩存數據遍歷,對比判斷機車信息是否已緩存。未緩存的機車運行數據通過計算處理與定位糾偏后緩存到內存,已緩存的機車運行數據經過比對與處理后緩存到內存。
如圖5 所示,機車運行數據處理流程設計如下:
Step1:接收車地交互數據,轉Step2;
Step2:緩存中存在機車數據,轉Step3。否則轉Step9;
Step3:從緩存讀取機車信息,轉Step4;
Step4:交互機車經緯度大于0 且緩存中存在該機車,轉Step5。否則轉Step7;
Step5:取出緩存機車信息,若緩存機車時間等于交互機車時間轉Step6。否則轉Step8;
Step6:加入機車運行數據緩存隊列;
Step7:若經緯度大于0 或機車非出入庫狀態時,線路號和公里標均大于0,轉Step8。否則轉Step6;
Step8:調用機車定位糾偏服務對機車定位進行糾偏,轉Step6;
Step9:訪問數據庫獲取機車信息, 轉Step10;
Step10:若經緯度大于0 或機車非出入庫狀態時,線路號和公里標均大于0,轉Step11。否則轉Step12;
Step11:調用機車定位糾偏服務對機車定位進行糾偏,轉Step12;
Step12:加入機車運行數據緩存隊列。
2.2.3 機車定位糾偏
在機車運行數據處理的過程中,需要對機車GPS 定位進行糾偏,機車運行數據服務通過RMI遠程調用機車定位糾偏服務的對象方法,查找sqlite 數據庫的鐵路數據(線路號、信號機、前方距離、上下行和里程),計算糾正經緯度。
如圖6 所示,機車定位糾偏流程設計如下:

圖6 機車地理位置糾偏流程圖Fig.6 Locomotive location correction flowchart
Step1:機車經緯度為0 轉Step2。否則轉Step3;
Step2:查找sqlite 數據庫鐵路數據中距離機車經緯度最近的點集合,轉Step4;
Step3:根據機車線路號、上下行和里程查找線路數據最近的點集合,轉Step4:
Step4:根據數學模型計算距離最近的最佳點。
2.2.4 車載設備監測
如圖7 所示,車載設備監測服務通過不斷接收和實時分析車地交互的車載設備運行數據(工況、信號機、前方距離、公里標等),將存在運行故障和隱患的設備數據形成報警緩存在內存中,并向Web服務及系統使用者推送報警數據,提升車載設備運用質量、減少機車行車安全問題。

圖7 車載設備監測流程圖Fig.7 Onboard equipment monitoring flowchart
基于RMI 分布式的LMD 系統性能優化與實現,在現有LMD 系統架構下,通過采用RMI 分布式技術,實現LMD 系統整體性能的提高。通過按照設計的RMI 分布式系統結構重新部署LMD 系統,系統的車地數據交互、機車運行數據計算處理、車載設備監測性能瓶頸得到解決,實現車地數據高效交互、機車運行數據和車載設備運行數據快速實時處理。目前,經過優化的LMD 系統已在南昌、沈陽、蘭州、濟南等鐵路局部署運行,運用效果良好。基于RMI 分布式的系統設計為其他應用系統擴展業務功能提供了接口,且基于RMI 分布式設計方法為今后鐵路信息化開發領域提供了新的設計思路。