基于TCMS落地數據的存儲、檢索、顯示軟件平臺

蔣陵郡，周黎明，吳 強，朱少華

（中車南京浦鎮車輛有限公司電氣研發部，南京 210000）

0 引言

城市軌道交通行業業內傳統的調試和故障分析方法是“黑匣子”策略，即將故障本身和引起故障相關的信號信息存儲在固定的符合行業標準的車載設備中，該設備一般稱為EVR（Environment Variable Record）。該方式存在的弊端是必須在列車返庫時，由工程師上車下載數據并使用特定的解析工具分析。其一，增加人工及維護成本，各列車數據都要人工下載且需要安裝了特定解析工具的維護電腦；其二，數據實時性低，無法第一時間獲取相關信息；其三，解析工具軟件為C/S架構，同時只能單臺電腦單人分析。

該平臺采用車地無線傳輸方式將關鍵數據落地，考慮到運營中列車存在頻繁切換通信基站導致丟包的場景。第一，為保證故障數據傳輸實時且準確，設計具備以太網傳輸能力的車載設備DDU（driver display unit）作為中間設備，接收數據并判斷故障發生和消失狀態，并以TCP 報文將故障信息發送至地面服務器；第二，為保證環境變量數據（即導致故障發生的變量）的完整性與準確性，犧牲一定的實時性，在車載設備中每存滿一包固定大小的數據再通過FTP/SFTP 的形式下發至地面服務器，該方式支持斷點續傳；最后，根據配置文件在地面服務器綁定故障信息與環境變量并生成FDL（Fault Data Logger）存儲至數據庫軟件，地面服務器再對外提供可視化的Web應用服務。

1 設計方案

1.1 數據落地方案

DDU 實時接收來自VCU 的周期性故障數據（UDP報文）。故障數據中每bit代表一個故障，當且僅當連續兩包數據中相同bit位由0跳變為1表示該故障發生，由1 跳變為0 表示該故障消失。故障發生或消失均觸發TCP報文。如圖1所示。

圖1 故障數據傳輸流程

DDU 實時接收來自VCU 的周期性環境數據（UDP報文）。DDU將接收到的環境數據每18000個采樣點（按100 ms 的周期即30 分鐘，可配置）緩存成一個文件。該文件命名格式如下：<線路號>_<列車號>_<源設備>_<文件創建時間>.cache， 如: 0001_10_VCU1_2020_9_17_14_27_34_245.cache。當緩存文件寫滿后即通過FTP/SFTP 上傳到地面服務器，上傳完成后將地面服務器上的緩存文件的擴展名由cache 改為dat，并刪除DDU中的緩存文件。

1.2 數據存儲方案

故障記錄落地后存儲在關系數據庫（如MySQL）中的“近期故障表”，環境數據落地后存儲在時序數據庫（如InfluxDB）［2］。如圖2 中①所示。

圖2 數據存儲方案

當DDU 啟動后，開始接收來自VCU 的UDP報文，其中的“列車號”或“源設備”發生變化則向地面服務器發送一個故障ID為0xFFFF的表示列車上電的報文。地面服務器在接收到該報文后，將對應“列車號”和“源設備”的當前故障設置為歷史故障，即使有些故障仍未消失，這些故障也會被設置為歷史故障，并且地面服務器將該“列車上電”報文作為一條故障記錄記錄到數據庫。同時，對于UDP 報文中故障數據為1 的故障，DDU 會重新發送表示這些故障發生的報文給地面服務器。

地面服務器每天定時將“近期故障表”中3個月外的故障記錄轉移到“歷史故障表”。同時也會將時序數據庫中與這些故障相關聯的環境數據一起存儲到“歷史故障表”中。并刪除時序數據庫中3個月外的環境數據。如圖2中②所示。

1.3 數據檢索和顯示方案

數據的檢索和顯示功能的實現采用B/S 架構［3］。主要實現以下功能：

（1）當前故障和所有故障

故障的檢索、顯示、處理建議和分類統計。

（2）環境數據

以圖形或表格的方式顯示任意時段用戶選取的環境數據，圖形方式如圖3所示。

圖3 查看環境數據

1.4 項目配置方案

項目配置包括該項目對應的故障清單、環境變量清單以及故障與環境數據的綁定關系（下稱綁定關系）。只有地面服務器需要配置，DDU等其他設備無需配置。項目配置保存在地面服務器關系數據庫的“故障清單表”和“環境變量清單表”中。故障清單保存在“故障清單表”中，環境變量清單保存在“環境變量清單表”中。綁定關系保存在“故障清單表”的“綁定關系”列。

故障序號即VCU 發送給DDU 的故障數據中對應位的位偏移。DDU 發送到地面服務器的故障信息TCP 報文中通過故障序號標識故障。這樣DDU 無需項目配置，即可完成故障信息的發送。在后期的故障清單維護過程中，故障序號不能復用。已刪除故障的序號不能再分配給其它新的故障使用，以免出現數據解析錯誤。

環境變量序號與環境數據中的環境變量一一對應。在后期的環境變量清單維護過程中，環境變量序號不能復用。已刪除環境變量的序號不能再分配給其它新的環境變量使用，環境變量的偏移、大小以及數據類型都不能修改，以免出現數據解析錯誤。

關系數據庫的“歷史故障表”中也有“綁定關系”列。當有新的故障記錄寫入到“歷史故障表”，此時該故障對應的綁定關系也和對應的環境數據一起保存。如果后期該故障的綁定關系發生改變，“歷史故障表”中的環境數據也可以依賴之前的綁定關系成功解析。

1.5 司控臺模擬功能方案

司控臺模擬功能采用B/S架構。地面服務器實時接收來自VCU（或通過DDU 中轉）的周期性司控臺狀態數據（UDP 報文）。用瀏覽器訪問地面服務器提供的相應Web 服務，頁面會根據最新的司控臺狀態數據實時刷新顯示內容。

當用戶點擊菜單欄“司控臺”選項，將打開一個“列車列表”界面，其中顯示列車的概要信息：列車號、在線狀態、信息更新最后時間，當前故障和歷史故障總數。效果如圖4所示。

圖4 列車列表頁面

在“列車列表”界面單擊某一列車的圖標，進入到該列車的“列車狀態”界面。該界面上半部分內容固定，包括列車速度、牽引級位、制動級位、駕駛模式、下一站、總風缸壓力、網壓。下半部分內容分為以下三個板塊：按鈕狀態、指示燈狀態、旁路開關狀態。如圖5 所示，其中按鈕、指示燈和開關可在數據庫中由TCMS（train control and management system）開發人員自行配置［4］。

圖5 列車狀態頁面

1.6 重大故障彈框方案

當有重大故障發生時，瀏覽器彈出重大故障彈框。該彈框采用Bootstrap 中的模態框，每個重大故障對應一個彈框。當有多個重大故障發生時，瀏覽器會彈出相同數量的彈框，且最新發生的重大故障位于最上方。當有重大故障彈框彈出時，用戶不能操作該頁面其它部件，但不影響其他標簽頁或瀏覽器實例的操作。

Web前端和后端之間采用WebSocket方式通訊。前端作為客戶端，后端作為服務器端。服務端周期性每隔5秒鐘查詢一次數據庫中未消失且未確認的重大故障推送給所有的客戶端［5］。一條推送消息中可能包含多個重大故障的信息。當客戶端連接上服務端后，即可接受到推送消息。兩次推送消息中可能有重復的重大故障，客戶端需要去重。接收到的每個重大故障彈出一個彈框。

當彈框被用戶確認，客戶端發送一個響應消息給服務端，響應消息中包含用戶信息以及對應的故障信息。服務端向MySQL 數據庫中寫入對應的確認記錄。該條故障后續將不會再向客戶端推送。客戶端在沒有收到重大故障或均已被確認的情況下，一旦再次收到重大故障，則同時觸發警示音。一旦有一個重大故障被確認，表示已經有人處理時，則同時消除警示音。

1.7 歷史數據清理方案

應用軟件EDCleaner 將遍歷某個時間點（可通過命令行參數配置）之前的所有故障，將這些故障對應的環境數據由InfluxDB 保存到MySQL的fault 表的envData 字段。envData 字段中保存的環境數據為json 格式，包含時間和各環境變量的變量名以及值。MySQL 的fault 表的envData字段的初始值都是null。檢索環境數據時，如果envData 字段的值為null 則直接從InfluxDB 調取環境數據，如果非null 則直接從該字段調取環境數據。

2 軟件清單與運行設計

2.1 軟件清單

本軟件平臺需要開發的軟件清單如表1所示。

表1 軟件清單

2.2 運行設計

FDL 與EVR 數據實時存儲到地面服務器，與該功能相關的模塊有FDHandler、EDCache、FDSaver、EDSaver以及EDCleaner［6］。如圖6所示。

圖6 功能模塊組合

3 結語

該平臺通過設計合理的車載數據落地傳輸策略，較為完美地解決數據實時性、數據準確性以及數據完整性三者之間的矛盾，并成功將繁雜的線下處理流程部署至線上解決，大大降低地鐵運營時的維護成本。平臺運行概況如圖7所示。

圖7 TCMS落地數據平臺處理方式