基于TDCS/CTC生產(chǎn)系統(tǒng)的車站數(shù)據(jù)查詢方案研究

曹亞輝，王亞飛

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

1 概述

隨著TDCS/CTC 系統(tǒng)在全路的大規(guī)模使用，車站用戶從實際工作需要出發(fā)，提出越來越多對行車日志、速報、站存車、報警、調(diào)度命令及事件數(shù)據(jù)的查詢需求?，F(xiàn)有的車站終端程序滿足了生產(chǎn)需求，但無法滿足查詢需求，為應(yīng)對車站用戶的需求，考慮利用現(xiàn)有的系統(tǒng)架構(gòu)，在不影響在用系統(tǒng)功能的前提下，設(shè)計一套實用的車站數(shù)據(jù)查詢系統(tǒng)。

目前路局在用的TDCS/CTC 生產(chǎn)系統(tǒng)整體架構(gòu)如圖1 所示。

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

圖1 TDCS/CTC生產(chǎn)系統(tǒng)結(jié)構(gòu)示意圖Fig.1 Basic structure diagram of TDCS/CTC production system

2 方案選擇

對于數(shù)據(jù)源的問題，必須要實現(xiàn)生產(chǎn)數(shù)據(jù)的存儲；對于查詢端的問題，必須要不影響現(xiàn)有LiRC和車務(wù)終端軟件的正常使用，而且方便車站用戶使用；查詢端與數(shù)據(jù)源交互的問題，必須要不影響現(xiàn)有軟件架構(gòu)，即不經(jīng)過通信前置機服務(wù)器進行數(shù)據(jù)交互。

基于以上分析，車站查詢數(shù)據(jù)需求可以通過以下兩種方案實現(xiàn)。

1）在車站部署數(shù)據(jù)源，實現(xiàn)生產(chǎn)數(shù)據(jù)存儲，開發(fā)數(shù)據(jù)查詢端軟件，部署在車站，開發(fā)后臺服務(wù)，訪問數(shù)據(jù)源，響應(yīng)查詢端的請求，通過網(wǎng)絡(luò)連接實現(xiàn)查詢端與數(shù)據(jù)源的直接交互。

2）利用中心系統(tǒng)數(shù)據(jù)庫服務(wù)器作為數(shù)據(jù)源，開發(fā)數(shù)據(jù)查詢端軟件，部署在車站，開發(fā)后臺服務(wù)，訪問數(shù)據(jù)源，響應(yīng)查詢端的請求，通過網(wǎng)絡(luò)連接實現(xiàn)查詢端與數(shù)據(jù)源的直接交互。

兩種方案的核心區(qū)別是，是否利用既有中心數(shù)據(jù)源。

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

結(jié)合TDCS/CTC 生產(chǎn)系統(tǒng)的實際情況，用戶要求車站生產(chǎn)數(shù)據(jù)查詢方案要部署靈活，使用方便，維護簡單，且不影響現(xiàn)有系統(tǒng)架構(gòu)及功能，這都是車站部署數(shù)據(jù)源方案實現(xiàn)不了的，因此只能采用利用現(xiàn)有數(shù)據(jù)庫服務(wù)器作為數(shù)據(jù)源的方案。

利用現(xiàn)有數(shù)據(jù)庫服務(wù)器作為數(shù)據(jù)源的方案，具有以下優(yōu)點。

1）部署成本低

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

2）對維護人員要求低

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

3）部署靈活

本方案只用開發(fā)數(shù)據(jù)查詢端軟件，部署在車站，開發(fā)后臺服務(wù)，訪問數(shù)據(jù)源，響應(yīng)查詢端的請求。車站查詢終端增加，只用多部署查詢端軟件即可。車站需求增加，只用修改新增的查詢端軟件和后臺服務(wù)即可，不需要修改現(xiàn)有軟件架構(gòu)和功能，部署靈活性比較高。

3 設(shè)計與實現(xiàn)

3.1 方案設(shè)計

基于成本和靈活性的考慮，本文選擇利用現(xiàn)有TDCS/CTC 系統(tǒng)數(shù)據(jù)庫服務(wù)器作為數(shù)據(jù)源，實現(xiàn)車站用戶的生產(chǎn)數(shù)據(jù)查詢需求，整體方案架構(gòu)如圖2所示。

圖2 增加查詢功能后TDCS/CTC生產(chǎn)系統(tǒng)結(jié)構(gòu)示意圖Fig.2 Basic structure diagram of TDCS/CTC production system after adding query function

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

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

3.2 實現(xiàn)過程

方案的實現(xiàn)過程如圖3 所示。

圖3 實現(xiàn)過程圖Fig.3 Realization process diagram

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

方案的實現(xiàn)難點包括以下幾點。

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

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

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

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

3）查詢結(jié)果傳輸準確性的保證

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

4）通信連接質(zhì)量的保證

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

3.3 關(guān)鍵技術(shù)

1）Web Service 通信技術(shù)

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

2）Oracle 數(shù)據(jù)庫技術(shù)

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

3）QT 界面開發(fā)技術(shù)

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

4）多用戶并發(fā)訪問技術(shù)

為響應(yīng)多用戶同時查詢，后臺服務(wù)采用并發(fā)訪問技術(shù)，當查詢端發(fā)起查詢時，動態(tài)的為每個查詢端單獨分配一個通信線程，處理查詢請求，查詢結(jié)束，釋放資源?？筛鶕?jù)硬件資源配置后臺服務(wù)能分配的最大通信線程數(shù)。

4 總結(jié)

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

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