基于TDCS/CTC生產系統的車站數據查詢方案研究

曹亞輝，王亞飛

（卡斯柯信號有限公司，上海 200071）

1 概述

隨著TDCS/CTC 系統在全路的大規模使用，車站用戶從實際工作需要出發，提出越來越多對行車日志、速報、站存車、報警、調度命令及事件數據的查詢需求。現有的車站終端程序滿足了生產需求，但無法滿足查詢需求，為應對車站用戶的需求，考慮利用現有的系統架構，在不影響在用系統功能的前提下，設計一套實用的車站數據查詢系統。

目前路局在用的TDCS/CTC 生產系統整體架構如圖1 所示。

從圖1 中可以看到，目前TDCS/CTC 系統分為中心和車站兩大部分，各服務器及車站終端間通過網絡相連，車站系統連接通信前置機服務器，通過通信前置機與中心系統進行數據交互，車站現在只有LiRC 和車務終端軟件，沒有數據查詢終端，而且生產數據都存儲在中心數據庫服務器中。所以要滿足車站查詢生產數據的需求，又不影響現有軟件架構和功能，就要解決3 個問題：數據源的問題；查詢端的問題；查詢端與數據源交互的問題。

圖1 TDCS/CTC生產系統結構示意圖Fig.1 Basic structure diagram of TDCS/CTC production system

2 方案選擇

對于數據源的問題，必須要實現生產數據的存儲；對于查詢端的問題，必須要不影響現有LiRC和車務終端軟件的正常使用，而且方便車站用戶使用；查詢端與數據源交互的問題，必須要不影響現有軟件架構，即不經過通信前置機服務器進行數據交互。

基于以上分析，車站查詢數據需求可以通過以下兩種方案實現。

1）在車站部署數據源，實現生產數據存儲，開發數據查詢端軟件，部署在車站，開發后臺服務，訪問數據源，響應查詢端的請求，通過網絡連接實現查詢端與數據源的直接交互。

2）利用中心系統數據庫服務器作為數據源，開發數據查詢端軟件，部署在車站，開發后臺服務，訪問數據源，響應查詢端的請求，通過網絡連接實現查詢端與數據源的直接交互。

兩種方案的核心區別是，是否利用既有中心數據源。

對于車站部署數據源的方案，存在以下缺點：部署成本高，每個車站都要單獨部署數據源；要求車站人員對數據源有較高的維護水平；需要修改軟件實現生產數據的入庫，而且不便于功能擴展。

結合TDCS/CTC 生產系統的實際情況，用戶要求車站生產數據查詢方案要部署靈活，使用方便，維護簡單，且不影響現有系統架構及功能，這都是車站部署數據源方案實現不了的，因此只能采用利用現有數據庫服務器作為數據源的方案。

利用現有數據庫服務器作為數據源的方案，具有以下優點。

1）部署成本低

本方案使用現有的數據庫服務器作為數據源，不用考慮新增數據源，而且現有數據庫中已經包含所有需要的生產數據，不用考慮修改軟件實現生產數據的入庫問題，降低了方案的復雜性，使得部署成本非常低廉。

2）對維護人員要求低

本方案的數據庫服務器位于中心機房，所有車站可以共用，不會增加中心和車站維護工作量，且方案執行過程易于理解，維護簡單。

3）部署靈活

本方案只用開發數據查詢端軟件，部署在車站，開發后臺服務，訪問數據源，響應查詢端的請求。車站查詢終端增加，只用多部署查詢端軟件即可。車站需求增加，只用修改新增的查詢端軟件和后臺服務即可，不需要修改現有軟件架構和功能，部署靈活性比較高。

3 設計與實現

3.1 方案設計

基于成本和靈活性的考慮，本文選擇利用現有TDCS/CTC 系統數據庫服務器作為數據源，實現車站用戶的生產數據查詢需求，整體方案架構如圖2所示。

圖2 增加查詢功能后TDCS/CTC生產系統結構示意圖Fig.2 Basic structure diagram of TDCS/CTC production system after adding query function

對比圖1、2 的系統架構，增加數據查詢功能后，增加響應查詢的后臺服務軟件，可以新加設備，也可以部署在現有應用服務器中。在車站設備中增加查詢端軟件，并未改變現有軟件架構及功能。這樣不僅實現車站用戶查詢行車日志、速報、站存車、報警、調度命令及事件數據的需求。即使日后車站用戶需要查詢更多的信息，包括以后生產系統擴展新業務的信息，都可以通過該方式簡單修改后臺服務軟件和查詢端軟件實現。

考慮到車站用戶查詢需求差異性，查詢端提供的查詢功能可以通過配置文件靈活配置。

3.2 實現過程

方案的實現過程如圖3 所示。

圖3 實現過程圖Fig.3 Realization process diagram

其中，車站查詢端，根據用戶在界面中輸入的查詢條件，生成查詢請求，然后同后臺服務建立Web Service 通信，向后臺服務發送查詢請求，后臺服務收到查詢請求，根據查詢條件從數據庫中獲取相應數據，再發送給查詢端，查詢端接收到數據，在界面中進行展示。整個過程由查詢端發起，順序進行。

方案的實現難點包括以下幾點。

1）配置靈活簡易性的保證

車站用戶查詢需求多樣，因此方案通過靈活配置滿足車站用戶的個性需求，另外從維護角度考慮，車站配置要盡可能少，因此方案通過將公用配置放置于后臺服務端的方式，車站查詢端啟動時，從后臺服務獲取公用配置，減輕了車站查詢端配置工作量。而且后臺服務收到查詢端的請求，才會讀取公用配置，即使公用配置有變化，可以直接修改，不用重啟后臺服務，減輕了對正常使用的影響。

2）查詢反饋時效性的保證

車站查詢端發起查詢請求后，如果網絡條件不好，或者查詢結果比較多，接收很慢，如果不做考慮，會造成界面卡頓，影響使用效果。因此方案通過設置超時參數的方式，卡控反饋的時效性，對于超時未收到查詢結果的情況，會提醒用戶重新發起請求。

3）查詢結果傳輸準確性的保證

車站查詢端發起查詢請求后，如果協議設計不好，在網絡通信質量不好，或者查詢結果較多的情況下，可能會導致查詢結果在傳輸過程中部分丟掉或異常。因此方案在設計通信協議時，通過將所有查詢結果放入一條消息中，且在查詢結果消息頭上包含結果條數的方式，在查詢端進行結果校驗，對于不完整的消息直接丟棄，避免傳輸過程中數據異常造成的結果不準確。

4）通信連接質量的保證

由于TDCS/CTC 系統現在普遍采用雙網，因此查詢端發送Web Service 連接時，如果一路網絡有問題，要能夠切換使用另一路網絡。否則會導致無法完成連接。方案在設計時，考慮了這種情況，查詢端程序可以配置雙網，在網絡通信不好的情況下，可以自動切換網絡，保證功能的正常使用。

3.3 關鍵技術

1）Web Service 通信技術

為了不影響在用軟件的功能及架構，且實現功能獨立，因此不能采用現有的連接結構，即連接通信前置機，通過通信前置機與中心后臺服務通信，必須采用另一種簡單獨立的技術，經過查閱相關資料，并結合易用性、可維護性的需求，本方案選擇Web Service 通信技術，后臺服務只用開放Web Service 查詢服務，車站查詢終端可直接通過后臺服務的ip 和端口與之進行數據交互。使用Web Service 技術，車站查詢端與后臺服務不需要維持常連接，發送查詢請求時，才會建立連接，這樣大大減輕對現有網絡通信的影響，且數據交互采用XML 格式，擴展簡單，使用靈活，保證了方案的可行性。

2）Oracle 數據庫技術

由于TDCS/CTC 系統采用Oracle 數據庫，因此在后臺服務中采用Oracle API 直接方位數據庫并獲取數據。Oracle 自帶的API 使用廣泛，查詢速度快，簡單且可靠性高的優點，保證方案的可行性。

3）QT 界面開發技術

由于車站查詢端程序要跟用戶進行交互，因此需要設計友好的人機界面，車務終端原有MFC 界面不夠友好美觀，且技術陳舊。在查閱資料的基礎上，方案選擇QT 界面開發技術，利用QT 界面美觀友好，且開發簡單，易于維護的特點，滿足車站用戶的需求，提高方案的可用性。

4）多用戶并發訪問技術

為響應多用戶同時查詢，后臺服務采用并發訪問技術，當查詢端發起查詢時，動態的為每個查詢端單獨分配一個通信線程，處理查詢請求，查詢結束，釋放資源。可根據硬件資源配置后臺服務能分配的最大通信線程數。

4 總結

本文設計方案易于實現且簡單靈活，在既有硬件條件及軟件架構和功能不變的前提下，開發后臺服務和車站查詢端程序，實現車站用戶對生產數據的查詢需求，降低了接管單位運營成本和運維復雜性，提高了方案的可用性和易用性。

目前該數據查詢方案已在多個鐵路集團公司TDCS/CTC 生產系統中運用實現，包括廣鐵集團有限公司（車站查詢行車日志、調度命令和報警數據），濟南局集團有限公司（車站查詢調度命令和報警數據）等，至今運行穩定可靠，實現方案的設計目標，滿足了車站用戶對查詢生產數據的需求，提高了系統的可用性，同時對其他系統中的類似需求也有一定的參考價值。