電務卡控模式下車站CTC 數(shù)據(jù)文件一鍵換裝系統(tǒng)的實現(xiàn)

王圣根

（卡斯柯信號有限公司 運營中心，上海 200071）

鐵路調(diào)度集中（CTC，Centralized Traffic Control）系統(tǒng)是保證鐵路行車安全的重要組成部分，已在各鐵路局集團公司逐步推廣部署。當前，鐵路運營線路CTC 系統(tǒng)改造時，影響面大，天窗點時間短，數(shù)據(jù)文件（簡稱：文件）換裝多依賴人工遠程拷貝文件后再進行文件傳輸，無法實現(xiàn)重要文件在服務器上的存儲和追溯，也可能存在天窗點外作業(yè)的情況，電務人員很難對其進行統(tǒng)一管理。文件傳輸方式有多種，有學者提出了基于文件傳輸協(xié)議（FTP，F(xiàn)ile Transfer Protocol）的數(shù)據(jù)服務及文件傳輸優(yōu)化方案[1-2]，但是，F(xiàn)TP 文件傳輸不支持批量操作，自動化程度低。目前，我國鐵路針對CTC 系統(tǒng)文件管理方面的研究和探索[3-5]，只是從管理制度上改進，并沒有從技術層面優(yōu)化。

為更好地提升CTC 文件換裝的效率和安全性，本文設計了電務卡控模式下車站CTC 文件一鍵換裝系統(tǒng)（簡稱：一鍵換裝系統(tǒng)），可對服務器和終端進行批量化操作。

1 系統(tǒng)架構

一鍵換裝系統(tǒng)基于VS2010+Qt 語言研發(fā)，其架構包括車站設備和中心設備，如圖1 所示。

圖1 系統(tǒng)架構

1.1 車站設備層

車站終端、自律機終端和服務器終端可以在施工人員控制臺的操作下完成自身數(shù)據(jù)的一鍵換裝，同時，還能夠完成自身數(shù)據(jù)的備份及比較核對，面向聯(lián)鎖、列車控制等重要的行車系統(tǒng)提供了接口。

1.2 中心設備層

施工人員控制臺和電務人員控制臺是供用戶操作的可視化界面，可以完成車站設備、中心設備的多個調(diào)度臺終端和中心服務器的數(shù)據(jù)換裝，也可以完成待換裝文件與既有文件的更新、比較和備份；前端是控制臺，后端則是文件服務器與數(shù)據(jù)庫之間進行數(shù)據(jù)交互，按用戶要求完成數(shù)據(jù)的存儲和提取。

2 系統(tǒng)功能

一鍵換裝系統(tǒng)功能結構如圖2 所示。

圖2 系統(tǒng)功能結構

2.1 文件更新、比較和備份

在電務安全卡控的模式下完成CTC 文件換裝作業(yè)。文件更新流程如圖3 所示。

圖3 文件更新流程

（1）從控制臺向各終端發(fā)送消息，獲取終端指定路徑下的文件列表。

（2）判斷控制臺收到終端反饋的文件路徑是否存在，若不存在則直接結束本次文件更新流程，否則判斷在電務安全卡控模式下是否允許更新，若允許更新，則由控制臺向服務器發(fā)送消息，獲取服務器指定路徑下的文件列表，然后在控制臺的控制下將獲取到的各終端與服務器指定路徑下的文件通過CRC32 校驗。

（3）判斷終端、服務器指定路徑下的文件名稱、大小是否相同，如果相同，則設置文件狀態(tài)為保留，結束本次文件更新流程；如果不相同，將差異文件壓縮打包，傳輸至終端指定路徑下。

（4）終端接收到差異文件壓縮包后，進行解壓并更換本地對應文件；最后在方法流程結束前將文件更新的結果呈現(xiàn)在控制臺上。

同理，文件比較是待更新文件與既有文件進行CRC32 校驗，校驗結果顯示在控制臺上；文件備份是先獲得終端上的文件，并壓縮傳輸至服務器，再將壓縮文件解壓、備份至服務器。

2.2 通信質(zhì)量探測

本文所提的通信質(zhì)量探測主要完成控制臺、服務器A/B、CTC 相關系統(tǒng)之間的網(wǎng)絡通信質(zhì)量檢測。

控制臺程序啟動后會自主向服務器發(fā)送探測通信網(wǎng)絡質(zhì)量的命令，若通信網(wǎng)絡正常，則表明在服務器上操作是有效的；若通信網(wǎng)絡異常，則默認存儲服務器的相關數(shù)據(jù)無效。同理，在控制臺上進行文件更新、比較和備份等一鍵操作時，控制臺會優(yōu)先往對應的終端上發(fā)送探測通信網(wǎng)絡質(zhì)量的命令，若通信網(wǎng)絡異常，則提示本次操作無效。

2.3 數(shù)據(jù)校驗

各CTC 車站設備與中心設備之間采用CRC32 方法，實現(xiàn)傳輸文件的正確性校驗。發(fā)送方文件與接收方文件的CRC 校驗碼值相同，說明傳輸文件完整、有效，即文件換裝作業(yè)成功。

2.4 數(shù)據(jù)管理

數(shù)據(jù)管理主要包括數(shù)據(jù)存儲、數(shù)據(jù)查詢和施工記錄報告打印。雙機服務器存儲（服務器A 和服務器B）采用2 臺高性能服務器完成數(shù)據(jù)的同步存儲，目的是確保數(shù)據(jù)的完整性和安全性。

2.5 人員管理

人員管理主要是通過管理員身份登錄系統(tǒng)，分別創(chuàng)建施工人員和電務人員帳號及密碼，只有每次登錄系統(tǒng)成功后才允許操作一鍵換裝系統(tǒng)。

3 關鍵技術

3.1 gSOAP 技術

gSOAP（Genivia Simple Object Access Protocol）是跨平臺的Web 服務開發(fā)平臺[6]，使用C++語言編碼，支持Windows 和Linux 平臺，它以XML 文件形式請求遠程服務，再以XML 文件的形式返回執(zhí)行結果。gSOAP 的解釋器及導入器可以使用戶不需要分析Web 服務的細節(jié)就可以實現(xiàn)一個客戶端或服務端程序[7]。

由于gSOAP 具有很好的兼容性，通過gSOAP，一鍵換裝系統(tǒng)應用層可以方便地調(diào)用由VS2010 和Qt 等語言開發(fā)的SOAP 服務，因此，gSOAP 適用于編譯一鍵換裝系統(tǒng)SOAP 客戶端程序。

3.2 gSOAP 開發(fā)框圖

如圖4 所示，通過gSOAP 開發(fā)的一鍵換裝系統(tǒng)客戶端都為遠程方法調(diào)用服務提供一個存根（Stub），避免了開發(fā)人員用手工的方式使用 C/C++編寫存根例程，Stub 的作用主要包括參數(shù)信息編碼，接收本地方法調(diào)用，將不同的服務委派給各自的具體實現(xiàn)對象，并將結果中的參數(shù)信息進行編碼。

圖4 gSOAP 開發(fā)框圖

頭文件通過gSOAP 解析，生成Web 服務描述語言（WSDL，Web Services Description Language）文件與框架（Skeleton）；WSDL 文件通過WSDL 解析器預處理，生成一個包括服務函數(shù)的簽名和其他額外的用于數(shù)據(jù)類型聲明的頭文件；該頭文件經(jīng)過gSOAP 編譯器編譯后，可生成供遠程調(diào)用服務的存根Stub，該存根能鏈接到服務應用程序的Skeleton服務框架，服務端WsFileServer 與Skeleton 之間存在調(diào)用和返回的關系，客戶端WsFileClient 與Stub 之間存在調(diào)用和返回的關系，控制臺（電務和施工）是WsFileClient 和WsFileServer 之間溝通的橋梁，借助gSOAP 服務，實現(xiàn)服務端和客戶端之間的數(shù)據(jù)交換。

3.3 多線程技術

為了提高文件更新、比較和備份的效率，一鍵換裝系統(tǒng)在軟件的開發(fā)過程中使用了多線程技術[8]，在電務人員（或施工人員）控制臺界面上能同時對多個車站和服務器等終端進行操作，且各終端并發(fā)執(zhí)行工作任務，互不影響。

如圖5 所示，在電務（或施工）控制臺上操作對應的終端上的文件更新、比較和備份按鈕時就會動態(tài)創(chuàng)建線程1 至線程n，執(zhí)行完成工作任務后，動態(tài)申請的線程資源會被釋放掉，以備后續(xù)使用。

圖5 多線程技術示意

3.4 雙機文件服務器的存儲

數(shù)據(jù)存儲結構如圖6 所示。存儲區(qū)域包含的文件分類包括：待更新數(shù)據(jù)、待回退數(shù)據(jù)、待比較數(shù)據(jù)和待備份數(shù)據(jù)等，服務器A/B 是互為同步的2 塊獨立的存儲區(qū)域。服務器A/B 用戶管理文件是為了區(qū)分施工人員和電務人員角色而創(chuàng)建的。為了能在作業(yè)期間（或作業(yè)后）掌握作業(yè)的情況，開發(fā)了當前正在作業(yè)數(shù)據(jù)查詢和歷史作業(yè)數(shù)據(jù)查詢功能模塊，并在數(shù)據(jù)查詢后能進行施工記錄報告的打印。

圖6 數(shù)據(jù)存儲結構

數(shù)據(jù)文件分別存儲在服務器A/B 上，所有終端配置指向的服務器，可以是其中的任意一臺，上傳文件成功后，由服務器A/B 之間定時完成數(shù)據(jù)的同步功能，確保服務器A/B 數(shù)據(jù)的一致性。本文所提雙機文件服務器存儲技術具有如下優(yōu)勢：

（1）服務器A/B 的數(shù)據(jù)存儲所依賴的文件服務器程序支持跨平臺功能，可以運行在Windows、Linux 等多平臺上；

（2）服務器A/B 機互為熱備，其中一臺機器出現(xiàn)故障，另外一臺機器仍然可以正常執(zhí)行作業(yè)任務；

（3）服務器A/B 機存儲技術支持針對各終端的批量操作，大幅度提升了數(shù)據(jù)文件的存儲效率。

3.5 CRC32 算法對數(shù)據(jù)文件進行校驗

循環(huán)冗余校驗（CRC，Cyclic Redundancy Check）是由數(shù)據(jù)序列和檢驗碼構成的一個特定長度的二進制序列[9]。其中，檢驗碼與數(shù)據(jù)序列之間存在某種特定關系，若因干擾因素致使數(shù)據(jù)序列某些位發(fā)生錯誤，這種特定關系就會被破壞，進而反映數(shù)據(jù)的正確性。

一鍵換裝系統(tǒng)在文件的更新和比較過程中均使用了CRC32 校驗。其實現(xiàn)的過程是：當進行CRC 校驗時，發(fā)送方和接收方按照事先約定的除數(shù)，即生成多項式，本系統(tǒng)采用的多項式如下：

發(fā)送方要處理的數(shù)據(jù)除以這個除數(shù)而得到的余數(shù)就是CRC1 值，這個CRC1 值會附加到發(fā)送方要處理的數(shù)據(jù)后面，打包傳送給接收方；接收方接收的數(shù)據(jù)后，先取出原始數(shù)據(jù)和CRC1 值，再將原始數(shù)據(jù)除以事先約定的除數(shù)得到新的CRC2 值。若CRC1 等于CRC2，則表示發(fā)送數(shù)據(jù)沒損壞，發(fā)送成功，若CRC1 不等于CRC2，則表示發(fā)送數(shù)據(jù)損壞，發(fā)送不成功。

4 軟件處理流程

軟件處理流程如圖7 所示。

圖7 軟件處理流程

（1）控制臺模塊實現(xiàn)了界面化的人機交互功能；

（2）通過在控制臺界面上使用鼠標點擊任務實體上的更新按鈕、比較按鈕和備份按鈕，程序開始分別觸發(fā)并執(zhí)行更新模塊、比較模塊和備份模塊；

（3）更新模塊、比較模塊和備份模塊的程序里面分別編寫著響應控制臺命令的程序；

（4）響應控制臺命令程序的過程，其實就是執(zhí)行終端Client 和服務器Server 之間的文件互傳，達到文件更新、文件對比分析和文件備份的目的；

（5）呈現(xiàn)模塊能把更新模塊、比較模塊和備份模塊執(zhí)行的結果在控制臺上顯示出來。

在控制臺上添加車站任務實體時，支持動態(tài)創(chuàng)建文件更新、比較和備份等功能，便于對整個軟件資源做合理分配，提升軟件操作的流暢性和交互性。軟件在處理更新模塊、比較模塊和備份模塊時，采用的是多任務和多線程的模式，支持批量化終端和服務器的操作。

5 試驗驗證

5.1 驗證前提條件

（1）在某鐵路局集團公司中心部署2 臺服務器用于運行服務器軟件，分別作為施工人員文件服務器和電務人員文件服務器；

（2）在某鐵路局集團公司中心部署2 臺工作站用于運行控制臺軟件，分別作為作業(yè)人員控制臺和電務人員控制臺；

（3）在某些車站現(xiàn)場部署查詢終端；

（4）運行服務器、控制臺和終端等各類軟件。

5.2 驗證文件更新

（1）在作業(yè)人員控制臺的界面上新增3 個任務實體，例如：車務終端A（stpc A）、車務終端B（stpc B）和占線板（t3term）；在作業(yè)人員控制臺添加的任務實體會自動同步到電務人員控制臺的界面上。

（2）分別點擊各任務實體IP 地址欄的通信質(zhì)量探測，確保任務實體與控制臺通信正常。

（3）在電務人員控制臺上點擊“禁止更新”按鈕，在作業(yè)人員界面上看到的文件更新按鈕是紅底色，無法進行操作，如圖8 所示。

圖8 文件禁止更新示意

（4）在電務人員控制臺上點擊“允許更新”按鈕，在作業(yè)人員界面上看到的文件更新按鈕是綠底色，允許文件換裝（更新），如圖9 所示。

圖9 文件允許更新示意

同理，文件比較和文件備份操作與文件更新操作類似。

綜上所述，一鍵換裝系統(tǒng)有效解決了CTC 系統(tǒng)改造作業(yè)效率低和耗費人力較多的問題，使用換裝系統(tǒng)前、后改造作業(yè)效率的對比如表1 所示。

表1 作業(yè)效率對比

6 結束語

針對目前鐵路運營線路CTC 系統(tǒng)改造時存在的更換數(shù)據(jù)文件效率較低的問題，開發(fā)了一鍵換裝系統(tǒng)。該系統(tǒng)通過一鍵觸發(fā)快速完成終端文件更新、比較和備份；同時，控制臺軟件還支持各終端批量化的數(shù)據(jù)查詢、作業(yè)記錄報告打印等操作，大幅度提升施工質(zhì)量和效率；因批量換裝終端數(shù)據(jù)文件時考慮到網(wǎng)絡帶寬的限制，允許同時操作的最多終端數(shù)量定義為10 個，從而減少因網(wǎng)絡帶寬限制對傳輸數(shù)據(jù)產(chǎn)生的影響。目前，該一鍵換裝系統(tǒng)已在多個鐵路局集團公司推廣應用，取得了良好的應用效果。