城市軌道交通車輛制動系統的車地無線通信數據傳輸各環節常見問題分析及解決方法

孫全濤 崔曉軍 杜振振 趙 欣 張乾乾 秦培斌

(中車四方車輛研究所有限公司， 266031， 青島∥第一作者， 工程師)

在城市軌道交通領域，車輛自身的自動化、信息化已經得到廣泛應用，為智能運維發展提供了數據基礎[1]。智能運維系統概念的出現，為高效的對車輛故障分析、故障預測進行及時診斷提供了途徑。如對其健康狀態進行評估，結合維修基地維修資源情況，給出合適的維修決策，以實現關鍵部件的狀態修[2]。

為滿足城市軌道交通智能運維的數據需要，本文以城市軌道制動系統為應用背景，以4G(第4代移動通信技術)或5G(第5代移動通信技術)為載體，討論解決車地無線通信數據傳輸各環節相關問題，對數據收集的各環節相關策略進行思考、實踐和分析。

車地無線通信數據傳輸環節主要包括車載維護系統終端的數據收集、4G或5G網絡的數據無線傳輸及地面數據中心的數據解析與存儲(見圖1)。在制動系統的車地無線通信數據傳輸中：由車載維護系統終端負責收集并打包全列車制動系統的數據；由4G或5G網絡，按約定的無線通信協議，將數據傳輸傳回地面數據中心；由地面數據中心進行數據計算及數據分析。

1 車載維護系統終端數據的收集

假設列車為6節編組，且每節車廂長度約為25 m。在制動系統中，每節車輛裝有1臺或2臺制動控制裝置。設置于頭車和尾車的車載維護系統終端可通過CAN(控制器區域網絡)總線或以太網來收集并匯總各制動控制裝置的數據信息。

1) CAN方式。如圖2所示，CAN以總線形式貫穿全列車，每臺制動控制裝置采用T型分支連接到CAN。CAN總線需滿足高速CAN 物理層規范ISO 11898-2要求[3]。CAN方式的通信波特率為250 kbit。在實際運用中，CAN方式能可靠地以1幀/ms速度傳遞報文。通過CAN總線，車載維護系統終端可按照一定的時間周期獲取到每臺制動控制裝置的內部數據，形成有序和一定密度的數據。

圖1 車地無線通信數據傳輸示意圖

圖2 CAN總線方案的T型網絡Fig.2 T network of CAN bus scheme

2) 以太網方式。列車以太網方式是未來的發展趨勢之一[4]。目前，列車以太網實時通信采用的TRDP(列車實時數據協議)由IEC 61375-2-3[5]定義。TRDP位于應用層，處于以太網傳輸層之上。車載維護系統終端可通過列車以太網獲取到制動控制裝置內部數據，并通過網絡地址(IP)和網絡身份標識進行特定系統數據收集[4]。

2 數據的無線傳輸

目前數據的無線傳輸運用4G或5G網絡[6]。在實際運用中，CAN總線數據一般按照1 ms或2 ms的間隔對各CAN報文排隊調度發送。按最大的通信量需求，車地無線通信數據傳輸能力要達到10 kB/s以上。此外，車地無線通信數據傳輸要配合一定策略將數據全部傳回數據中心，要保證數據傳輸的完整性、數據密度的可分析性。

2.1 通信數據協議

對于城市軌道交通車地點對點的特定數據傳輸，4G或5G選用TCP/IP協議(傳輸控制協議/互聯網協議)。在TCP/IP協議中，傳輸層選用TCP。車載維護系統終端將實時采集的制動系統數據，以1 s為周期上傳到服務器。

如圖3所示，4G或5G的TCP/IP協議包含4個操作：

1) TCP連接服務器——終端通過TCP連接命令確認與服務器通信網絡的可用性。

2) 設備握手——終端向服務器發送含有設備信息的簡單報文，提前從應用層快速確認網絡的可用性，并通知服務器使之處于數據接收準備狀態。

3) 數據發送——終端向服務器發送數據，并獲得服務器確認；否則本次發送失敗。

4) TCP斷開連接——設備的110 V電源斷電后，終端斷開與服務器連接。維護終端的非斷電情況數據發送完后，TCP不斷開保持長連接。

圖3 4G或5G的TCP/IP協議操作Fig.3 TCP/IP protocol process of 4G or 5G

對于車載維護系統和地面數據中心采用的TCP通信，每次設備握手所發送的數據量和所需驗證時間如表1所示。

2.2 數據發送密度

城市軌道交通車輛制動系統故障分析往往對傳輸數據的發送密度有一定的要求。如數據發送密度過低，則數據發送時間間隔過長，無法準確分析部分的閥故障或者其他電氣故障的原因。

為提高傳輸數據密度，現有通信方法往往追求極高的數據發送頻率。這對地面數據中心的硬件性能和軟件性能有很高的要求。隨著列車的增多，地面數據中心的通信能力將很快達到飽和狀態。

表1 發送特定數據量和所需驗證時間

針對這一問題，通過4G或5G網絡進行通信數據無線傳輸時，不再通過加快數據發送頻率來滿足數據密度的要求，而是將制動控制裝置發送到車載維護系統的高密度數據以合理的數據排列形成較大數據包，并將此數據包發送時間周期間隔放緩至秒級。這樣不僅能滿足不丟包、高數據密度的要求，還能降低對地面數據中心硬件和軟件性能要求。車載維護系統將報文內容以相同的時間周期進行打包，并寫進時間戳；內部多包相同ID號的CAN數據給出排列序號。

2.3 數據的緩存與續傳

在地鐵4G網絡中，隧道內往往存在通信信號弱或通信異常的情況，而各站點內的通信卻能恢復正常。此時，需要采取一定措施，在不影響正常數據傳輸的情況下對數據進行緩存及續傳處理。

當4G網絡的無線通信數據傳輸出現異常時，可先將收到的CAN或TRDP總線數據存儲到車載維護系統終端內部的大容量數據循環緩沖區域；當與服務器的網絡連接恢復后，為不耽誤正常的數據發送，也為了將緩存的數據發回服務器，可在正常數據發送間隔中插空把緩存數據發回服務器。如表1所示，發送1次數據所需的驗證時間為100 ms左右，足以插空補發送緩存數據。地面數據中心收到數據后，會按照數據包中的時間戳對數據進行重新排序。

若車載維護系統終端在較長時間(如10 min)內都無法與服務器建立有效通信連接，則終端循環存儲區域會將最新接收到的CAN總線或TRDP數據依次覆蓋舊數據，并將此異常事件寫入車載維護系統終端的日志系統中。在通信恢復后，車載維護系統終端只能發送當前循環緩沖區域中的數據，而無法發送已被覆蓋的舊數據。車載維護系統終端收到的全部CAN總線或TRDP數據的副本會同步存儲在終端的SD卡(Secure Digital Memory Card)中。如需讀取丟失的數據，則可通過終端維護軟件讀出SD卡存儲數據，并進行后續處理。

2.4 數據安全性

數據安全性主要從兩個方面來保證：在網絡層，通過通信公司專設的隧道技術來傳輸數據；在應用層采用對稱加密技術，由車載維護系統終端在業務數據中使用加密算法，由地面數據中心在接收時進行解密。

3 地面數據中心的數據解析存儲

地面數據中心的數據解析存儲過程如圖4所示。地面數據中心收到無線通信數據包后，可將數據包中的相關線路、車輛編號及設備等信息存入原始數據隊列中，繼而解析、存儲可按線路、車輛編號及設備等區分處理，便于后續數據運用。

圖4 地面數據中心的數據解析存儲過程Fig.4 Data analyzing and storage process of ground datacenter

原始數據隊列緩沖可通過緩存，以解決地面數據中心各個子系統的性能差異及延遲等問題。例如，通過Kafka分布式數據流處理系統對接收到的數據報文進行緩存，可有效解決各子系統數據處理速度差異及可靠性低等問題。

緩存后的數據可按需求解析成各物理量，也可直接按原始數據存儲。

不同線路、不同系統的數據協議往往存在差異性。為能夠在不同設備的不同協議下實現通用的數據解析和存儲，可通過建立數據解析子系統來承載各系統不同線路的數據協議，并將設備和數據協議用模型表示。當數據報文進行解析時，可根據線路、車輛編號及設備去識別子系統中的協議模型，并按照協議模型的語言去解析和存儲數據，以實現通用性。

即便數據協議后期增加內容，只要將拓展的數據協議和設備用模型來表示，就可以將增加的內容進行數據的解析存儲。統一解析后的數據可按照時間序列進行數據排列，為同一物理量數據進行縱向對比和不同物理量間進行橫向對比提供了時間排列基礎。

人員對制動系統進行維護及相關故障分析可通過VPN(虛擬專用網絡)技術訪問地面數據中心，再根據線路、車輛編號及設備等信息進行數據實時監控或對歷史數據進行數據查看分析。

4 結語

本文基于城市軌道交通車輛的制動系統，介紹了制動系統車地無線通信數據傳輸的流程，分析了數據傳輸各環節常見的問題，并給出了相應解決辦法。車載維護系統終端數據收集的CAN總線方案已在實際中裝車使用，驗證了其有效性。針對無線通信數據傳輸信號弱與數據密度問題，提出了通過合理的數據排列，將數據發送時間間隔放緩至秒級的解決辦法。地面數據中心應按相關線路、車輛編號及設備等信息，通過數據解析子系統來完成數據通用解析和存儲。