城市軌道交通列車實(shí)時(shí)數(shù)據(jù)處理與應(yīng)用研究

曾高平，王 磊

（株洲中車時(shí)代電氣股份有限公司，湖南 株洲 412001）

0 引言

2020年，中國城市軌道交通協(xié)會發(fā)布了《中國城市軌道交通智慧城軌發(fā)展綱要》[1]。綱要明確了以云計(jì)算、大數(shù)據(jù)[2]等新興信息技術(shù)與城市軌道交通（簡稱“城軌”）深度融合為主線，推進(jìn)城軌信息化、發(fā)展智能系統(tǒng)、建設(shè)智慧城軌的發(fā)展路徑[3-4]。隨著運(yùn)營線路和運(yùn)營里程的增加，運(yùn)營規(guī)模的持續(xù)增長給城軌運(yùn)營單位帶來了一系列的挑戰(zhàn)，如對設(shè)備狀態(tài)評估、故障診斷、故障預(yù)測及維修模式等提出了更多、更高的要求[5]。列車狀態(tài)在途監(jiān)測屬于車輛運(yùn)維中的一個(gè)重要板塊，其主要通過采集列車的實(shí)時(shí)數(shù)據(jù)對列車的行駛狀態(tài)、關(guān)鍵系統(tǒng)運(yùn)行狀態(tài)進(jìn)行監(jiān)測，實(shí)現(xiàn)對列車的狀態(tài)感知。城軌運(yùn)營單位通過借助車輛的實(shí)時(shí)數(shù)據(jù)，實(shí)現(xiàn)對車輛的實(shí)時(shí)監(jiān)測、故障預(yù)警、應(yīng)急響應(yīng)、維修決策等目標(biāo)[6-7]，構(gòu)建智能運(yùn)維體系[8-9]以提升列車運(yùn)營[10]的質(zhì)量。因此，基于列車數(shù)據(jù)并結(jié)合運(yùn)營實(shí)際需求，構(gòu)建一套列車實(shí)時(shí)數(shù)據(jù)處理及快速應(yīng)用的架構(gòu)尤為重要。本文通過對實(shí)時(shí)數(shù)據(jù)的特征進(jìn)行深入分析，基于大數(shù)據(jù)、微服務(wù)等技術(shù)，構(gòu)建一套高效、輕量的實(shí)時(shí)數(shù)據(jù)處理架構(gòu)，并支撐對城軌列車的實(shí)時(shí)監(jiān)測，應(yīng)急響應(yīng)等應(yīng)用功能，進(jìn)而提升地鐵公司對列車的掌控能力。

1 實(shí)時(shí)數(shù)據(jù)處理

在列車運(yùn)營過程中，車載設(shè)備周期性地采集列車上各子系統(tǒng)的實(shí)時(shí)運(yùn)行數(shù)據(jù)，通過數(shù)據(jù)傳輸網(wǎng)絡(luò)發(fā)送到地面數(shù)據(jù)處理平臺；地面系統(tǒng)接收到車載設(shè)備下發(fā)的實(shí)時(shí)數(shù)據(jù)后，對其進(jìn)行并發(fā)處理、數(shù)據(jù)解析、報(bào)文統(tǒng)計(jì)等各項(xiàng)處理，解析后的數(shù)據(jù)經(jīng)業(yè)務(wù)整合后形成可視化應(yīng)用展示界面。本節(jié)主要從車地系統(tǒng)架構(gòu)、實(shí)時(shí)數(shù)據(jù)分類處理兩個(gè)方面進(jìn)行介紹。

1.1 車地系統(tǒng)架構(gòu)簡介

整個(gè)車地系統(tǒng)主要包括列車上車載系統(tǒng)、無線傳輸通道、地面系統(tǒng)3部分，如圖1所示。

圖1 實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)架構(gòu)Fig.1 Real-time data processing system architecture

車載系統(tǒng)負(fù)責(zé)周期性地采集列車總線數(shù)據(jù)，按照既定的通用數(shù)據(jù)報(bào)文協(xié)議組成數(shù)據(jù)包，并借助無線傳輸通道（如4G/5G、WLAN、乘客信息系統(tǒng)等）將原始數(shù)據(jù)包周期性地向地面發(fā)送。數(shù)據(jù)報(bào)文協(xié)議包括3個(gè)部分：報(bào)文頭、數(shù)據(jù)區(qū)及校驗(yàn)和?；诔擒夗?xiàng)目實(shí)施經(jīng)驗(yàn)，報(bào)文頭一般包括報(bào)文長度、線路號、車型、車號、車廂、協(xié)議版本、設(shè)備時(shí)間、通道標(biāo)志、壓縮標(biāo)志、加密標(biāo)志、站點(diǎn)及速度等信息，基本能覆蓋城軌項(xiàng)目應(yīng)用需求；數(shù)據(jù)區(qū)由每個(gè)項(xiàng)目所采集的數(shù)據(jù)內(nèi)容確定；校驗(yàn)和用來保證報(bào)文的完整性和正確性，并采用循環(huán)冗余校驗(yàn)（cyclic redundancy check，CRC）的方法校驗(yàn)。

地面系統(tǒng)對車輛數(shù)據(jù)處理后以可視化的方式呈現(xiàn)來指導(dǎo)運(yùn)營，主要包括數(shù)據(jù)接收、解析、存儲、推送及應(yīng)用等程序。

1.2 實(shí)時(shí)數(shù)據(jù)分類

根據(jù)數(shù)據(jù)處理的時(shí)效性，數(shù)據(jù)可分為批式（batch）數(shù)據(jù)和流式（streaming）數(shù)據(jù)2類。其中，批式數(shù)據(jù)又被稱為歷史數(shù)據(jù)，流式數(shù)據(jù)又被稱為實(shí)時(shí)數(shù)據(jù)。根據(jù)城軌列車的具體業(yè)務(wù)數(shù)據(jù)產(chǎn)生方式，實(shí)時(shí)數(shù)據(jù)又可分為實(shí)時(shí)狀態(tài)數(shù)據(jù)與實(shí)時(shí)故障數(shù)據(jù)。

實(shí)時(shí)狀態(tài)數(shù)據(jù)是車載系統(tǒng)通過定期采集車輛總線數(shù)據(jù)實(shí)時(shí)產(chǎn)生的，并且由車載系統(tǒng)以一定的頻率將數(shù)據(jù)包周期性地下發(fā)到地面服務(wù)器。

實(shí)時(shí)故障數(shù)據(jù)是由車輛發(fā)生故障時(shí)觸發(fā)產(chǎn)生的，發(fā)生時(shí)間具有不確定性，觸發(fā)后車載系統(tǒng)會立即下發(fā)數(shù)據(jù)包到地面服務(wù)器。

下面針對周期性數(shù)據(jù)與觸發(fā)式數(shù)據(jù)分別說明數(shù)據(jù)處理流程。其中，周期性數(shù)據(jù)以實(shí)時(shí)狀態(tài)報(bào)文為例，觸發(fā)式數(shù)據(jù)以實(shí)時(shí)故障報(bào)文為例。

1.2.1 實(shí)時(shí)狀態(tài)數(shù)據(jù)處理

由圖1可知，車載系統(tǒng)下發(fā)的實(shí)時(shí)數(shù)據(jù)包到達(dá)地面系統(tǒng)后，前置服務(wù)器根據(jù)數(shù)據(jù)包頻率、大小及服務(wù)器硬件配置情況做相應(yīng)策略的負(fù)載均衡調(diào)度。一般情況下，采用高性能代理服務(wù)器Nginx的流代理模塊將數(shù)據(jù)包轉(zhuǎn)發(fā)到相同服務(wù)器的不同端口，或者轉(zhuǎn)發(fā)到后置不同服務(wù)器后再進(jìn)行處理。數(shù)據(jù)包到達(dá)數(shù)據(jù)解析程序后的處理流程如下：

（1）數(shù)據(jù)解析程序的設(shè)計(jì)基于異步、事件驅(qū)動的高性能并發(fā)框架。數(shù)據(jù)接收后，先根據(jù)校驗(yàn)信息驗(yàn)證數(shù)據(jù)的合法性和完整性，并將合法的車載原始二進(jìn)制數(shù)據(jù)流寫入一種高吞吐量的分布式訂閱消息隊(duì)列（如Kafka）主題中，不同的數(shù)據(jù)包被寫入到不同的消息主題上。在消息隊(duì)列組件層實(shí)現(xiàn)數(shù)據(jù)的共享，具有如下優(yōu)勢：第一，充分利用該組件的異步、緩沖、高吞吐量等特性，減少實(shí)時(shí)數(shù)據(jù)時(shí)延；第二，隔離數(shù)據(jù)的生產(chǎn)與消費(fèi)，有效降低數(shù)據(jù)處理平臺與各子系統(tǒng)地面的耦合性，在任何一方數(shù)據(jù)接口出現(xiàn)問題時(shí)，不影響整體數(shù)據(jù)鏈路，保證整個(gè)平臺的運(yùn)行安全；第三，可提升數(shù)據(jù)平臺接入類型的橫向擴(kuò)展能力。

（2）針對不同消息隊(duì)列中的原始二進(jìn)制數(shù)據(jù)流，流式計(jì)算引擎根據(jù)數(shù)據(jù)報(bào)文協(xié)議模板對報(bào)文數(shù)據(jù)的內(nèi)容進(jìn)行解析，并將解析后為輕量級格式的點(diǎn)位鍵值對寫回到消息隊(duì)列的另外一個(gè)消息隊(duì)列主題中，供流式存儲引擎或其他程序使用；同時(shí)將解析后的數(shù)據(jù)鍵值對按照一定格式寫入基于內(nèi)存的實(shí)時(shí)數(shù)據(jù)庫（如Redis）中，供不同的應(yīng)用程序?qū)?shí)時(shí)數(shù)據(jù)進(jìn)行共享讀取時(shí)使用。實(shí)時(shí)數(shù)據(jù)庫中的數(shù)據(jù)組織方式一般按照車號-業(yè)務(wù)場景歸類分組。如果車地原始消息隊(duì)列數(shù)據(jù)區(qū)的協(xié)議格式不公開，那么對應(yīng)的二進(jìn)制數(shù)據(jù)流無法被解析，只有擁有原始數(shù)據(jù)協(xié)議才可知道數(shù)據(jù)區(qū)原始二進(jìn)制的含義，從而可以在車地通道中起到數(shù)據(jù)透傳與保護(hù)私有數(shù)據(jù)區(qū)的作用。

（3）流式存儲引擎程序通過消費(fèi)消息隊(duì)列解析后的數(shù)據(jù)流，將全量數(shù)據(jù)存入分布式文件系統(tǒng)（如Hbase）中，為后續(xù)數(shù)據(jù)關(guān)聯(lián)分析、挖掘提供數(shù)據(jù)支撐。少量結(jié)構(gòu)化的業(yè)務(wù)數(shù)據(jù)將存儲到關(guān)系型數(shù)據(jù)庫（如Mysql）中，供應(yīng)用系統(tǒng)快速查詢。

（4）對于絕大部分狀態(tài)點(diǎn)位數(shù)據(jù)而言，應(yīng)用程序功能需求一般只依賴最新的數(shù)據(jù)，如實(shí)時(shí)顯示車輛的站點(diǎn)、速度及網(wǎng)壓等信息，實(shí)時(shí)數(shù)據(jù)庫有一個(gè)全量點(diǎn)位數(shù)據(jù)的鍵用于存放最新的數(shù)據(jù)。對于少數(shù)應(yīng)用場景而言，需要借助一部分點(diǎn)位在一段時(shí)間內(nèi)的數(shù)據(jù)，通過后臺并行計(jì)算方式，從全量點(diǎn)位數(shù)據(jù)的鍵里面抽取所需要的點(diǎn)位到新的業(yè)務(wù)鍵中，并指定業(yè)務(wù)鍵的失效時(shí)間或者長度。

1.2.2 實(shí)時(shí)故障數(shù)據(jù)處理

故障數(shù)據(jù)的下發(fā)包括故障發(fā)生、故障消除、定期刷新等過程，前后數(shù)據(jù)包具有關(guān)聯(lián)性，故障更新邏輯較為復(fù)雜。因此，鑒于故障數(shù)據(jù)的特殊性，其不能與狀態(tài)數(shù)據(jù)采用相同的處理方式。

（1）實(shí)時(shí)故障包通過地面服務(wù)器負(fù)載均衡調(diào)度后被轉(zhuǎn)發(fā)給數(shù)據(jù)解析程序。解析程序根據(jù)相應(yīng)的協(xié)議解析出故障信息，包括故障碼、故障變化時(shí)間及故障狀態(tài)等。如果是故障發(fā)生，則將故障碼、故障發(fā)生時(shí)間等新增信息記錄存入數(shù)據(jù)庫中進(jìn)行歸檔；如果是故障結(jié)束，則添加信息，更新原有的故障記錄條目。另外，故障信息也被同步存入到實(shí)時(shí)數(shù)據(jù)庫中供應(yīng)用系統(tǒng)使用。

（2）故障數(shù)據(jù)的處理機(jī)制比狀態(tài)數(shù)據(jù)的復(fù)雜，需要根據(jù)故障包中每個(gè)故障的狀態(tài)標(biāo)記做不同處理，進(jìn)而維護(hù)每節(jié)車輛的故障列表。

（3）為了進(jìn)一步提升故障數(shù)據(jù)的及時(shí)性與準(zhǔn)確性，一般會增加一個(gè)故障刷新報(bào)文，用于記錄當(dāng)前時(shí)間未結(jié)束的全部故障列表，如圖2所示。

圖2 故障報(bào)文處理機(jī)制Fig.2 Fault package processing mechanism

2 實(shí)時(shí)數(shù)據(jù)應(yīng)用

地面系統(tǒng)應(yīng)用后臺定時(shí)任務(wù)對實(shí)時(shí)數(shù)據(jù)庫進(jìn)行監(jiān)聽，當(dāng)數(shù)據(jù)庫全景點(diǎn)位數(shù)據(jù)的鍵取值發(fā)生變化時(shí)，從全量數(shù)據(jù)中獲取不同的數(shù)據(jù)并分別存儲到對應(yīng)的業(yè)務(wù)鍵以滿足不同的應(yīng)用需求?？梢愿鶕?jù)業(yè)務(wù)功能展示的需要保存實(shí)時(shí)數(shù)據(jù)量的大小，如運(yùn)營指標(biāo)某些功能只需保存最新的一條信息，應(yīng)急響應(yīng)某些功能只需最新10 s內(nèi)的記錄。借助實(shí)時(shí)數(shù)據(jù)庫特性，不僅能夠便捷地實(shí)現(xiàn)對實(shí)時(shí)數(shù)據(jù)的失效時(shí)間或者數(shù)據(jù)量大小的管控，還能在實(shí)時(shí)數(shù)據(jù)庫層面實(shí)現(xiàn)不同專業(yè)實(shí)時(shí)數(shù)據(jù)的快速共享。下面主要從實(shí)時(shí)監(jiān)測、應(yīng)急響應(yīng)和日檢項(xiàng)點(diǎn)3個(gè)方面分別進(jìn)行介紹。

2.1 實(shí)時(shí)監(jiān)測

用戶通過使用應(yīng)用系統(tǒng)的實(shí)時(shí)監(jiān)測功能，可獲取全部列車的位置、速度及載客量等實(shí)時(shí)狀態(tài)信息，并可查看列車是否發(fā)生故障，及時(shí)指導(dǎo)列車司機(jī)進(jìn)行故障處置，提升運(yùn)營質(zhì)量。

實(shí)時(shí)監(jiān)測能夠可視化地展示包括當(dāng)前線路全部站點(diǎn)信息的模擬地圖及各節(jié)車輛的實(shí)時(shí)數(shù)據(jù)。在模擬線路地圖中，根據(jù)實(shí)時(shí)下發(fā)的站點(diǎn)信息以及列車運(yùn)行方向，顯示列車在相應(yīng)的站點(diǎn)位置；根據(jù)故障信息以不同顏色展示列車的健康狀態(tài)；根據(jù)載荷信息計(jì)算并展示當(dāng)前列車載客情況。在單車界面中，詳細(xì)展示當(dāng)前列車的行駛基本信息、實(shí)時(shí)故障、司控臺指示燈狀態(tài)、司機(jī)屏信息等數(shù)據(jù)，遠(yuǎn)程復(fù)現(xiàn)列車當(dāng)前的運(yùn)行狀態(tài)。實(shí)時(shí)監(jiān)測web應(yīng)用界面如圖3所示。

圖3 實(shí)時(shí)監(jiān)測web應(yīng)用界面Fig.3 Real-time monitoring web application interface

2.2 應(yīng)急響應(yīng)

應(yīng)急響應(yīng)功能是針對正線的列車關(guān)鍵應(yīng)急事件提供應(yīng)急響應(yīng)與指導(dǎo)。應(yīng)急事件主要包括高壓成立條件、緊急制動條件、牽引指令條件、門控制回路等。借助此功能，地面人員可以快速指導(dǎo)司機(jī)進(jìn)行應(yīng)急操作，降低晚點(diǎn)和救援事故概率，從而減少應(yīng)急事件對正線的影響。借助點(diǎn)位實(shí)時(shí)數(shù)據(jù)與點(diǎn)位組合邏輯條件設(shè)計(jì)子應(yīng)急應(yīng)用，每組應(yīng)急事件主要包括以下3項(xiàng)功能：

（1）應(yīng)急提示。在每個(gè)監(jiān)測的條件下面，當(dāng)對應(yīng)應(yīng)急邏輯觸發(fā)時(shí)，顯示對應(yīng)應(yīng)急處置信息。

（2）條件成立監(jiān)測。針對開關(guān)監(jiān)測點(diǎn)的點(diǎn)位組合邏輯，條件成立則開關(guān)閉合；條件不成立則斷開。

（3）控制回路電流狀態(tài)監(jiān)測。對于每組應(yīng)急事件中各個(gè)條件，如果前一個(gè)節(jié)點(diǎn)有電流，但本級節(jié)點(diǎn)條件不成立，則顯示橙色；如果前一個(gè)節(jié)點(diǎn)有電流，且本級節(jié)點(diǎn)條件成立，則顯示綠色；如果前一個(gè)節(jié)點(diǎn)無電流，則本級節(jié)點(diǎn)顯示灰色。

前端頁面用開關(guān)圖片模擬每個(gè)對應(yīng)條件是否成立，圓點(diǎn)模擬電路節(jié)點(diǎn)連通性。根據(jù)每個(gè)條件回路實(shí)際情況，設(shè)計(jì)應(yīng)用響應(yīng)（圖4），其能夠監(jiān)測當(dāng)前車輛是否發(fā)生應(yīng)急事件，并能標(biāo)注出異常出現(xiàn)的電路節(jié)點(diǎn)，以達(dá)到快速指導(dǎo)現(xiàn)場人員進(jìn)行應(yīng)急處置的效果。

圖4 應(yīng)急響應(yīng)web應(yīng)用Fig.4 Emergency response web application

2.3 列車日檢項(xiàng)點(diǎn)

車輛檢修人員從日檢檢修單出發(fā)，并結(jié)合車輛落地?cái)?shù)據(jù)內(nèi)容，梳理出可以根據(jù)實(shí)時(shí)數(shù)據(jù)判斷的檢修項(xiàng)點(diǎn)。由于項(xiàng)點(diǎn)功能的驗(yàn)證依賴數(shù)據(jù)在時(shí)序上的變化情況，因此此項(xiàng)功能對實(shí)時(shí)數(shù)據(jù)連續(xù)性的質(zhì)量要求較高。一般列車檢修存在以下檢查項(xiàng)點(diǎn)：

（1）開、關(guān)門功能檢查；

（2）空調(diào)溫度檢查；

（3）蓄電池輸出電壓檢查；

（4）高速斷路器分、合功能檢查；

（5）施加、緩解停放制動功能檢查。

由于此類功能對實(shí)時(shí)性要求不高，且涉及的數(shù)據(jù)量較大，一般常見的做法是從消息隊(duì)列或者分布式文件系統(tǒng)中獲取最近一段時(shí)間（如15 min）內(nèi)的數(shù)據(jù)，并以時(shí)間順序正排，所有項(xiàng)點(diǎn)共享此份全集數(shù)據(jù)，并行計(jì)算每個(gè)項(xiàng)點(diǎn)的業(yè)務(wù)邏輯，業(yè)務(wù)處理流程如圖5所示。

圖5 列車日檢項(xiàng)點(diǎn)業(yè)務(wù)處理流程Fig.5 Business process of train daily inspection point

每個(gè)檢查項(xiàng)點(diǎn)業(yè)務(wù)從全集數(shù)據(jù)中篩選出項(xiàng)點(diǎn)，判斷所依賴的點(diǎn)位值集合，并針對有序值集合進(jìn)行步驟設(shè)計(jì)。下面以開門功能檢查為例進(jìn)行詳細(xì)闡述：

（1）找到前置條件點(diǎn)位值滿足的入口邏輯時(shí)刻，如順序搜索門開請求信號有效的時(shí)刻t1。

（2）判斷是否需要延時(shí)，假設(shè)門從接收“開信號”到門開到位最多需要4 s，那么下一步就從（t1+4）時(shí)刻后開始判斷結(jié)果點(diǎn)位值。

（3）判斷結(jié)果點(diǎn)位值是否正確變化，如“門開到位”信號有效，代表此次開門功能檢查正常。

3 結(jié)語

針對軌道交通領(lǐng)域日益增長的數(shù)字化運(yùn)營需求，本文提出了一種基于大數(shù)據(jù)、微服務(wù)等技術(shù)的實(shí)時(shí)流式數(shù)據(jù)處理架構(gòu)，其能夠?qū)崿F(xiàn)實(shí)時(shí)數(shù)據(jù)的高效處理與靈活應(yīng)用，并在實(shí)時(shí)監(jiān)測、應(yīng)急響應(yīng)、日檢項(xiàng)點(diǎn)等業(yè)務(wù)中應(yīng)用。

截至目前，本文所提供的實(shí)時(shí)數(shù)據(jù)處理架構(gòu)與應(yīng)用功能已經(jīng)在國內(nèi)多條城軌線路實(shí)施驗(yàn)證，基本能滿足常見線路級車輛智能運(yùn)維系統(tǒng)建設(shè)的需要，解決了傳統(tǒng)數(shù)據(jù)處理架構(gòu)無法支撐多并發(fā)數(shù)據(jù)的實(shí)時(shí)處理和海量數(shù)據(jù)存儲的問題；通過狀態(tài)監(jiān)視、應(yīng)急響應(yīng)的應(yīng)用功能，實(shí)現(xiàn)了地鐵公司對運(yùn)行列車的全方位遠(yuǎn)程動態(tài)監(jiān)測，進(jìn)而實(shí)現(xiàn)對列車運(yùn)行狀態(tài)的態(tài)勢感知。

下一步可以結(jié)合高并發(fā)異步IO框架來提升數(shù)據(jù)接收的并發(fā)量，數(shù)據(jù)包間隔時(shí)間從現(xiàn)有的500 ms縮短到100 ms，適應(yīng)后續(xù)更多子系統(tǒng)數(shù)據(jù)、更多線網(wǎng)級車輛數(shù)據(jù)的場景。