基于通信的列車控制系統數據采集與解析軟件的設計與實現*

白廣爭 李 亮 白廣良

(1.中國鐵道科學研究院通信信號研究所，100081，北京；2. 中國石油遼河油田興隆臺采油廠，124011，盤錦 //第一作者，助理研究員)

CBTC(基于通信的列車控制)系統包括CBI(計算機聯鎖)、ATS(列車自動監控)、VOBC(車載控制器)、ZC(區域控制器)和DCS(數據通信)等子系統[1]。各子系統之間實時進行各種控制信息及反饋信息的交互，各子系統內部實時完成自身邏輯功能運算。為了深入分析各子系統自身邏輯運算的準確性及系統間信息交互的可靠性，從系統的角度而言，需要開發一套對整個CBTC系統進行實時數據抓包并根據接口協議進行解析的軟件，為工程測試人員提供參考。

文獻[2]是在Wireshark的基礎上通過腳本嵌入二次開發實現的應用協議解析。本文所介紹的軟件，其開發基于C# 語言，包含了數據抓包解包的過程。本文描述了解決軟件開發過程中出現的一些關鍵問題的思路。軟件主要完成局域網內數據抓包、接口解析配置文件設計與讀取、數據記錄與歷史查詢、界面顯示等功能。

1 數據抓包

CBTC系統一般采用交換機組建局域網。為了實現抓取流經交換機的所有數據，需要做兩方面的工作：一是設計數據抓包機制，二是對交換機進行端口鏡像配置。

1.1 數據抓包機制

在硬件方面，網卡的工作模式分為廣播模式、多播傳送、直接模式和混雜模式等。默認情況下，網卡只接收廣播幀和發至本終端的幀[3]。只有采用混雜模式，網卡才能接收局域網絡內所有發送至本終端的數據包，實現監視捕獲網絡信息的目的。在軟件方面，通過調用Sharpcap應用類庫進行底層網卡的操作。CBTC系統采用A、B雙網組建局域網，分別由兩臺交換機管理。因此，在同一終端上，可采用兩個網卡分別抓取兩臺交換機上的數據，數據抓包機制如圖1所示。

圖1 數據抓包機制

為了避免多個線程同時操作某一塊內存，引起并發性問題，需要在數據存入緩存的過程中設置互斥鎖。互斥鎖的原理為：當線程n需要操作某一被鎖定的內存時，必須首先獲取鎖，然后才能進行該內存操作；當線程n正在操作某一內存時，該內存則被置于鎖定狀態，其他線程不能再對其進行操作；當線程n操作某一內存結束后，需要釋放鎖，從而允許其他線程進行相關操作。

1.2 交換機端口鏡像配置

由于交換機不會把收到的每個數據信息都以廣播的方式發送到其他所有端口，而是根據MAC地址表進行智能轉發。因此，經過1.1節的配置仍無法實現在一個端口上抓取局域網內的所有數據。通過端口鏡像配置方法，能夠將多個端口的數據流鏡像到同一個端口上，這樣，局域網數據抓包條件就能從物理上得到保證。

為了完成端口鏡像配置，首先，交換機需具有網絡管理功能；其次，由于不同型號交換機的配置命令不同，因此對不同的交換機采用與其相應的配置命令進行配置。

2 數據包解析

對于從交換機上獲得的數據包，需要獲取應用層數據，并根據接口協議進行解包，從而提供給測試人員進行驗證。本軟件的數據包解析由XML配置文件和文件讀取程序(解包程序)兩個模塊完成。

2.1 XML配置文件

通常情況下，隨著工程的深入和細化，一些接口協議、工程數據等都會有所改動，為了降低這種改變對程序開發的影響，同時也為了提高開發效率，減少程序開發工作量，接口協議及工程數據等需要以配置文件的方式提供，以便于后期的維護。本解析軟件采用XML文件對CBTC系統中的接口協議進行描述。

XML文件格式能跨平臺使用，具有良好的可擴展性，適合面向對象的程序開發。XML提供的是樹形層次結構，可以很方便地定位某個功能塊[4]。針對CBTC各子系統接口協議，本軟件采用5層節點的XML文件來描述。第1層為標志數據方向的節點，如ZC→VOBC等；第2層為標志數據包類型的節點，如列車控制信息、列車注冊請求報文等；第3層為普通節點，如ZC_ID等應用層字段含義；第4層為被控節點，如某號道岔的信息等；第5層為表示被控節點屬性的子節點，如道岔定位、反位信息等。

其中，普通節點又分為非控制類型節點和控制類型節點兩類，設置節點屬性control來區分這兩種類型。若control為0，表示該節點為非控制類型節點。對于該類節點，只需獲取其中各屬性的值，如每個字段的長度、字段含義描述等。若control為1，表示該節點為控制類型節點。對該類節點的處理方式是，根據控制節點的值對被控節點進行操作。例如，假設數據包中包含N個道岔信息，則通過道岔控制節點獲取N值，然后對描述道岔的被控節點進行N次循環讀取。XML配置文件整體結構如圖2所示。

圖2 XML配置文件結構設計示意圖

采取這種設計模式能夠將CBTC系統的所有接口協議文件轉化為XML配置文件，供解包程序統一調用。若后期協議中需要增加新的字段，只需增加新的節點，文件結構及解包程序均不需改變；若出現新的控制條件或控制類型時，可以通過調整control的值做進一步擴展。

2.2 解包程序

XML配置文件的解包程序，首先獲取數據包的源ID、目的ID和數據類型等包頭信息，讀取XML配置文件，并據此查找與該數據包的數據方向和類型相同的方向節點和類型節點。在此基礎上，對數據包中其他各字段按節點逐個進行解析。XML配置文件解包程序讀取流程如圖3所示。

圖3 XML配置文件解包程序流程圖

為了提高程序的實時響應能力，在抓包過程中，并不對應用層數據全部進行實時解包，而是只獲取包頭的一些必要信息，如時間、PacketID、數據包類型等，并進行數據分類存儲，以便于以后的查詢操作。只有在離線情況下，才響應測試人員的查詢記錄請求，調用解包程序對相應的數據包進行解包處理。

3 數據存儲設計

為了方便測試，提高軟件的可用性，降低數據庫對環境配置的要求，本項目采用SQLite數據庫。該數據庫是一種開源的嵌入式關系型數據庫，與Oracle復雜的客戶-服務器模式不同，SQLite整個數據庫都在一個單一文件中，可以直接通過程序來創建數據庫文件及表單，并進行相關的數據庫操作。另外，SQLite還具有處理速度快、支持跨平臺、能與多種程序語言相結合等優點。

從網絡上抓取到的數據均需存入數據庫，若每獲得一條數據即進行一次存儲操作，頻繁連接和斷開數據庫比較耗時，存儲速度就無法滿足實時性要求。通常情況下，對于實時數據都采取集中式存儲方式。

本文介紹的軟件設置了兩個緩存區，輪流接收抓取的數據，并在緩存區滿時各自進行存儲。緩存區的大小與抓包速率有關，若單位時間內從局域網上抓到的數據包較多，則需要設計較大的緩存區。通過顯式啟動事務的方法將緩存中的數據批量插入數據庫，能夠大大提高存儲效率。

存儲機制分定量存儲和定時存儲兩種方式。定量存儲是指在程序中開辟固定大小的緩存區，當緩存區滿時，執行數據存儲過程。這種存儲機制便于控制內存的合理運用，但存儲周期是不確定的，需要根據緩存區大小和網絡內數據流量來計算；定時存儲是指每間隔固定的時間進行一次存儲，這種存儲機制在存儲周期上是固定的，但需定義動態緩存區，不利于內存管理。本文介紹的軟件采用定量存儲的方式。

根據以上設計思路，設存儲周期為T，網絡抓包速率為v，單個緩沖區大小為s，則三者滿足如下的關系：

T=s/v

(1)

設每次存儲事務的執行時間為t，若要保證有足夠的時間存儲數據，則須滿足如下的要求：

t≤T

(2)

存儲速率根據程序的抓包速率來設計。存儲速率要略大于抓包速率，這樣既能避免內存溢出，又能有效減少資源占用。

根據式(1)、式(2)的關系，v、s與t之間的關系需滿足：

tv

(3)

當式(3)的條件滿足時，能有效避免內存溢出。同時，若式(3)右端遠大于左端，則會造成內存資源的浪費或數據庫連接資源的浪費。

為了提高程序的實時性，抓包線程負責將抓取的數據包放入緩存中，并調用解包頭程序，將更新界面顯示和存儲事務交由數據存儲線程處理。設置兩個緩存區進行數據的輪流接收與存儲，同一時刻只能由其中一個緩存區負責數據接收，當該緩存區存滿后才能由另一個緩存區進行數據接收，具體的控制流程如圖4所示。

圖4 數據接收及存儲流程圖

4 軟件總體結構及界面

以上描述了軟件所涉及到的主要功能模塊，軟件采用基于Winform的C# 語言編程，整體運作流程如圖5所示。

軟件界面提供實時數據抓包顯示，用Listview控件顯示。用戶選擇某一包的數據記錄，軟件界面相應顯示該數據包的解析信息。也可以通過設置篩選條件進行選擇性顯示。該軟件具有歷史數據查詢、Excel導入/導出等功能。

圖5 主程序控制流程圖

通過應用驗證，軟件在Intel Core i5-4590四核8 G內存的終端上運行，能夠滿足CBTC系統的需求，沒有出現漏包現象，抓包及處理效率能夠跟上系統內數據包的產生速度。

5 結語

本文闡述了抓包、存儲及離線解析CBTC系統局域網內數據的軟件的設計過程。該軟件的研發有助于提高CBTC系統接口測試效率，加快問題定位，提高測試質量。按照本文介紹的設計方法開發的軟件具有擴展性好、開發效率高、通用性強等特點，這些設計方法對于其他類似應用系統的開發具有一定的借鑒意義。

在此基礎上的進一步研究工作是：通過統計所抓取數據包的類型來判斷CBTC系統實時網絡狀態；通過修改數據包內容，模擬某一子系統向其他子系統發送錯誤數據包，實現故障注入等功能。