基于TRDP協議的高速動車組列車通信網絡檢測平臺

張大林 郝梓騰 王洪偉 林思雨

(北京交通大學， 北京 100044)

從上世紀90年代開始，我國高速鐵路動車組技術歷經自主探索、引進消化吸收再創新以及自主創新三個階段，復興號中國標準動車組標志著我國真正意義上具備了完全自主知識產權的動車組技術。2020年，我國400 km/h高速動車組在中車唐山公司下線，昭示著我國高速動車組技術進入了新的階段，有助于推動中國鐵路“走出去”，對促進國際經濟、文化融合發展具有重要意義。

高速動車組結構復雜，子系統眾多，列車通信網絡是承擔監測、控制等重要信息的關鍵，也是提升動車組信息化、智能化的核心。傳統的列車通信網絡有絞線式列車總線(Wire Train Bus, WTB)、多功能車輛總線(Multifunction Vehicle Bus, MVB)、CAN、ARCNET和LonWorks等。傳統總線式列車網絡具有實時性好、抗干擾能力強和穩定性高的優勢，但其傳輸速率較低(MVB總線通信速率為1.5Mbit/s，WTB總線通信速率為1 Mbit/s)，無法滿足大吞吐量的要求，且其擴展性較差，單一的總線實現功能難以應對復雜的通信任務[1]。隨著智能化時代的到來，列車通信網路的作用已不僅僅局限于簡單的數據傳輸，還需實現網絡故障診斷、優先級調度等更多功能，目前的現場總線技術已不能滿足高速列車發展的需求[2]。以以太網為代表的高速率傳輸技術已成了列車通信網絡的發展方向，并陸續裝備到我國多類型號的動車組列車上，我國400 km/h的高速動車組也采用以太網技術來實現高速列車的網絡控制、智能化自動輔助駕駛等功能。

以太網使用CSMA/CD協議，可能會導致通信節點之間的信息傳輸沖突，并導致數據丟失或不確定的傳輸時延等，從而無法滿足列車通信對實時性和確定性的要求[3]。鑒于列車通信網絡在動車組安全、高效運營過程中的關鍵作用，對基于以太網的列車通信網絡開展安全性和可靠性測試具有重要意義。

為保障列車通信網絡信息傳輸的可靠性和安全性，列車實時數據協議(Train Real-Time Data Protocol, TRDP)得到了廣泛的應用[4]。基于OSI網絡模型，TRDP位于TCP/UDP傳輸層之上[5]，應用層之下，屬于第五層協議。TRDP協議主要用于列車通信網絡中過程數據和消息數據兩種實時通信數據的傳輸。過程數據是實時周期性傳輸的，消息數據是實時非周期性傳輸的。過程數據長度小，一般用于控制單元發出的控制命令和遠程輸入、輸出模塊反饋的運行狀態信息，但其數據量大、對可靠性、確定性，實時性要求高。消息數據一般用于設備狀態信息和故障報警信息，數據量長短不一，對實時性要求較低[6]。TRDP對過程數據的幀結構、交互模型和通信流程都進行了規定。

因此，本文以TRDP協議為基礎，基于BS架構構建面向高速動車組列車通信網絡的實時檢測技術，實現對時延、丟包、亂序、吞吐量等關鍵服務質量參數的測試和統計分析，驗證列車車載網絡的可靠性和安全性。

1 基于TRDP協議的動車組列車通信網絡檢測平臺功能需求分析

面向TRDP的以太網通信網絡監測平臺的主要目標是實現對列車通信網絡各類業務運行情況的實時監測，并可實現統計結果實時展示告警、歷史統計結果查詢、監測報告導出等功能。因此，本文設計了列車以太網通信網絡性能監測平臺，通過大數據技術對列車網絡流量進行實時計算，并實現對列車網絡流量實時采集存儲、各類業務TRDP網絡數據包的性能指標統計、網絡監測統計結果的實時展示、統計數據的管理與監測報告的導出以及TRDP網絡數據包發包規則與監測標準的配置等功能。性能監測平臺基本需求如表1所示。

表1 性能監測平臺需求分析表

1.1 TRDP數據包信息配置需求

TRDP數據包的基本信息配置主要應用于對網絡性能指標的計算和當前性能指標是否符合傳輸標準的判斷，包括Comid、源IP地址、目的IP地址、發送周期、數據包大小、最大丟包率閾值、時延抖動閾值等測試標準。

1.2 性能計算需求

TRDP協議的每類業務均對應一個Comid特性，并以此為基礎，實時監測列車通信網絡各類業務的數據包丟失情況、數據包亂序情況及數據傳輸時延情況。要求能實時統計當前通信網絡的帶寬占用情況，設計算法實現對通信網絡中丟包、亂序情況的實時計算，統計出數據包總量及各類業務中丟失數據包的數據量、亂序數據包的數據量和最大時延抖動，并根據每類業務的測試標準將丟失數據包、亂序數據包及最大時延抖動進行輸出。

1.3 實時展示功能需求

為讓用戶直觀了解當前列車網絡狀態的性能指標，要求實時展示當前的數據包總量、數據包丟失數量及數據包亂序情況。分別以柱狀圖和折線圖的形式呈現當前每類業務的數據包丟失與亂序數量，要求折線圖按照秒級進行展示，并具有篩選功能，柱狀圖按照分鐘級別的粒度進行排序展示。

1.4 數據管理與報告導出需求

數據管理模塊主要是為了讓用戶可以對歷史統計數據進行回溯管理，進一步分析網絡鏈路中可能出現的異常情況。數據管理需求主要是能根據時間、Comid、源IP地址、目的IP地址等查詢條件查詢歷史數據。報告導出需求主要是能根據Comid、目標地址、源地址及時間等查詢條件生成報表，根據時間、業務ID等條件自定義生成報告。

2 基于TRDP協議的動車組列車通信網絡檢測平臺設計

平臺實行模塊化設計，基本架構如圖1所示。平臺架構分為數據采集層、數據傳輸層、數據處理層、數據存儲層、數據應用層五層，設計過程中多采用分布式架構，對處理性能擴展及列車控制中心遠程監控列車網絡通信具有借鑒意義。

圖1 檢測平臺架構圖

2.1 平臺功能結構設計

根據用戶需求分析，性能檢測平臺可細分為數據采集模塊、性能指標計算模塊和數據應用模塊。其中，數據采集模塊又可分為基本信息配置模塊、網絡流量采集模塊和數據包解析模塊，性能指標計算模塊主要包括丟包計算、亂序計算、時延計算及吞吐量計算，數據應用模塊又可分為數據實時展示模塊、歷史數據管理模塊和監測報告導出等模塊，功能架構如圖2所示。

圖2 檢測平臺功能架構圖

2.2 平臺性能檢測數據庫設計

性能檢測平臺中的數據庫主要用于存儲列車通信網絡中所產生和統計的數據，因此數據庫設計的簡潔性、易拓展性等特點對于平臺十分重要，好的數據庫設計能使平臺更易進行更新和維護。在數據庫設計過程中，首先根據需求分析確定實體關系(性能監測平臺實體關系如圖3所示)，再根據實體關系設計數據庫的概念模型，然后將概念模型轉換為數據庫的邏輯數據模型，最后將邏輯數據模型轉換為更高級的物理數據模型。

圖3 性能監測平臺實體關系圖

3 基于TRDP協議的動車組列車通信網絡檢測平臺實現關鍵技術

動車組列車通信網絡檢測平臺主要包含TRDP網絡數據采集、網絡性能計算、數據存儲、統計結果應用等多個模塊。

3.1 TRDP網絡數據包采集

平臺采用WinPcap抓取網絡數據包(數據類型為十六進制ASCii碼)后，首先將抓取的數據包數據轉化為十六進制數據，然后直接解析出數據包的Comid。目前，解析的數據包主要是基于UDP傳輸的過程數據，過程數據的TRDP數據包最大為1 472字節，在傳輸過程中不會產生IP數據報分片問題，因此可直接根據TRDP協議格式對網絡數據包進行解析。解析過程中，平臺會丟棄無法正確解析成TRDP協議的網絡數據包。由于網絡性能指標計算模塊是根據TRDP網絡數據包的序列號實現網絡通信監測的，因此每類業務在傳輸及存儲過程中均需保證順序性。根據每類業務Comid的唯一性，將數據包存入不同的先進先出隊列當中，存入隊列之后，由對應進程解析出源IP地址、目的IP地址、Comid、序列號、消息類型、etbTopoCnt、opTrnTopoCnt、datasetLength等數據包內容信息，并將信息賦值于數據包對象。業務流程如圖4所示。

圖4 TRDP網絡數據包采集流程圖

為避免出現數據包順序錯亂，解析后便將網絡數據包存儲到Mysql數據庫當中，如此讀取的網絡數據包順序便與采集的順序一致。

3.2 性能指標計算

性能計算模塊通過利用采集到的數據包對列車通信網絡的性能進行實時計算，主要采用Flink數據處理引擎對Mysql的BinLog日志進行解析，將解析后的數據利用丟包、時延、亂序以及吞吐量的計算方法進行實時統計。數據采集模塊的采樣數據需存儲到Mysql數據庫中，因此，需要實現Flink與Mysql的整合。利用Flink的窗口機制、鍵值狀態、水印等特性實現對基于TRDP協議的列車通信網絡的實時性能計算，數據流處理的流程如圖5所示。

圖5 數據流處理流程圖

以此為基礎，使用Flink實時拉取Mysql中的日志消息，對列車以太網通信進行性能指標統計，分析當前通信鏈路各類業務的通信情況。對于異常信息，將數據存儲到數據庫的同時，也通過Kafka傳輸到應用層，應用層會對性能指標統計結果進行實時顯示。

3.2.1丟包與亂序計算

當第N個數據包到達時，首先與狀態版本號進行比較，若小于當前狀態版本號，則將該條數據丟棄。若大于當前版本號，則將其作為新版本號，此后流程同第一個數據包到達流程相同。對于相同的版本號，首先更新狀態時間(定時器會使用該時間判斷是否將狀態中丟失的數據包進行輸出)，之后遍歷緩存的丟失數據包，并對該數據包經過的數據包步長進行遞增，對于經歷的數據包步長大于給定值的，認為屬于丟包，計算丟包率并與規則進行比對后，對其信息進行封裝，存儲于列表當中。在遍歷判斷數據包丟失的過程中，也會進行數據包的亂序計算，判斷當前數據包的序列號在緩存的丟失數據包中是否存在，若存在則將其從緩存中移除，并將其標記為亂序數據包，更新亂序數據包狀態統計的數量。

3.2.2時延抖動與吞吐量計算

時延抖動與吞吐量都是網絡性能檢測的重要性能指標。時延抖動可確保列車網絡管理員實時觀察列車網絡設備在運行過程中的異常抖動現象，其計算方式是以前一個到來的數據包的嗅取時間為標準，用當前數據包的時間減去前一個到來的數據包的時間后，與規則中的閾值進行比對，對異常情況進行標記。吞吐量的計算是將數據包嗅取的時間作為時間窗口的時間，利用Assign Times Tamps And Watermarks來定義生成水印的邏輯，通過為數據流設置滾動窗口，來統計每一秒中數據包總量的大小。

4 平臺性能測試

平臺的前端界面包含亂序、丟包、時延、吞吐量及數據包的實時顯示等。

為保障基于TRDP的列車通信網絡檢測平臺在真實運營場景中的適應性，需搭建具有高擬真度的測試環境對平臺進行性能測試。測試環境的硬件部分由網絡設備和計算設備組成。其中，網絡設備主要通過無線路由器搭建小型局域網，實現標準的TRDP網絡通信；計算設備用來進行軟件環境部署，主要包括用于TRDP數據發送的計算機1臺、用于數據采集、處理與展示的計算機1臺?？紤]本地計算機性能的局限性，利用2臺阿里云網絡服務器分別作為消息隊列和時序數據庫服務器。硬件配置如表2所示。

表2 性能測試硬件配置表

在性能測試階段，為對網絡數據包采集系統進行壓力測試，并驗證數據采集設備的采集能力，使用采集設備進行發包與捕獲，同時開啟WireShark抓取數據包。測試中，采用同時開啟80個線程，以5 ms作為發送周期，發送長度為1 432字節的數據包來模擬列車設備發送的不同業務數據包，所發送數據包全部被收包設備的數據采集器捕獲，測試結果如圖6所示。

圖6 數據采集對比圖

在網絡性能計算模塊中，以并行度1讀取存儲在Mysql數據庫的BinLog日志，測試了25 190條數據在Flink處理引擎中處于不同并行度時的處理速度，分別以并行度1、并行度2、并行度4及并行度6執行網絡性能統計的算子，對數據處理模塊的處理速度進行測試，測試結果如圖7所示。

圖7 不同并行度計算速度比較圖

5 結束語

本文設計了基于TRDP協議的列車通信實時檢測平臺，對列車網絡進行長時間實時監測，分析列車通信網絡中各類業務的通信狀況，對出現的異常信息進行實時統計。該平臺包括TRDP網絡數據采集、性能指標計算、實時展示、數據管理及監測報告導出五大模塊，對保障列車運行的安全性和可靠性具有重大意義，對以400 km/h高速動車組為代表的高速鐵路技術的推廣和應用具有重要的推動作用。