城市軌道交通信號(hào)智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)研究

鄧永祁，楊 將，陽(yáng)亦斌

（湖南中車時(shí)代通信信號(hào)有限公司，湖南 長(zhǎng)沙 410005）

0 引言

隨著城市軌道交通（簡(jiǎn)稱“城軌”）的快速發(fā)展，傳統(tǒng)運(yùn)維服務(wù)模式的保障能力已達(dá)極限，很難適應(yīng)城市軌道交通設(shè)備運(yùn)維日益增長(zhǎng)的數(shù)量、服務(wù)品質(zhì)、響應(yīng)率和效率的需求[1]。2020年中國(guó)城市軌道交通協(xié)會(huì)發(fā)布的《中國(guó)城市軌道交通智慧城軌發(fā)展綱要》提出，到2025年，車輛、能源、通信及信號(hào)等智能運(yùn)維系統(tǒng)在全行業(yè)推廣應(yīng)用，日常檢修效率和車輛整體可靠性達(dá)到世界先進(jìn)水平，運(yùn)營(yíng)安全事故率降低30%，信號(hào)設(shè)備故障率降低15%[2]。與此同時(shí)，城軌信號(hào)設(shè)備設(shè)施分散，數(shù)量繁多，種類繁雜，對(duì)信號(hào)設(shè)備智能運(yùn)維數(shù)據(jù)的傳輸、處理和儲(chǔ)存的要求上升到了新的高度，而傳統(tǒng)的數(shù)據(jù)平臺(tái)架構(gòu)與模式無(wú)法滿足當(dāng)前的系統(tǒng)需求。文獻(xiàn)[2]研究了多源融合感知、多引擎融合預(yù)警、運(yùn)維多專業(yè)融合協(xié)同及主動(dòng)維修決策等關(guān)鍵技術(shù)，并提出智能運(yùn)維與各線路之間、核心業(yè)務(wù)之間的接口方案。文獻(xiàn)[3]基于大數(shù)據(jù)平臺(tái)并采用微服務(wù)技術(shù)架構(gòu)體系，研發(fā)了一種集成化、智能化和信息化的城軌信號(hào)智能運(yùn)維系統(tǒng)，提供了城軌信號(hào)智能運(yùn)維系統(tǒng)架構(gòu)與功能的建設(shè)思路。文獻(xiàn)[4]以上海地鐵為例，從維護(hù)支持、智能分析和運(yùn)維管理3個(gè)方面分析信號(hào)智能運(yùn)維系統(tǒng)需求，提出基于感知層、平臺(tái)層和服務(wù)層的3層系統(tǒng)建設(shè)方案。 但上述文獻(xiàn)均未解決城軌信號(hào)智能運(yùn)維系統(tǒng)在海量數(shù)據(jù)采集、儲(chǔ)存與計(jì)算等方面的問(wèn)題。本文基于大數(shù)據(jù)技術(shù)開(kāi)展城軌信號(hào)智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)研究，探索基于大數(shù)據(jù)技術(shù)的數(shù)字化、標(biāo)準(zhǔn)化和智能化的信號(hào)設(shè)備運(yùn)維數(shù)據(jù)平臺(tái)，從而構(gòu)建運(yùn)、檢、修一體化的城市軌道交通信號(hào)設(shè)備智能運(yùn)維服務(wù)體系，實(shí)現(xiàn)從計(jì)劃修、故障修到狀態(tài)修的轉(zhuǎn)變，確保城市軌道交通信號(hào)設(shè)備的安全運(yùn)營(yíng)。

1 信號(hào)設(shè)備運(yùn)維數(shù)據(jù)平臺(tái)現(xiàn)狀

傳統(tǒng)的信號(hào)設(shè)備運(yùn)維方式采用子系統(tǒng)分離式維護(hù)監(jiān)測(cè)，即各子系統(tǒng)使用本系統(tǒng)獨(dú)立的單機(jī)運(yùn)維軟件。一般來(lái)說(shuō)，在控制中心（operation control center，OCC）部署列車自動(dòng)監(jiān)控系統(tǒng)（automatic train supervision, ATS）和數(shù)據(jù)傳輸網(wǎng)管系統(tǒng)（data communication system, DCS），進(jìn)行信號(hào)系統(tǒng)通信網(wǎng)絡(luò)與列車信號(hào)設(shè)備的運(yùn)維；在集中站設(shè)備房部署聯(lián)鎖(computer based interlocking, CI)維護(hù)系統(tǒng)、維護(hù)支持系統(tǒng)（maintain support system, MSS）和道岔缺口監(jiān)測(cè)系統(tǒng)，進(jìn)行聯(lián)鎖系統(tǒng)與信號(hào)基礎(chǔ)設(shè)備的運(yùn)維[3]。這種方式運(yùn)維數(shù)據(jù)較為獨(dú)立，數(shù)據(jù)的傳輸、處理與儲(chǔ)存以單機(jī)和單系統(tǒng)為主，容易形成信息孤島，數(shù)據(jù)的利用效率較低，無(wú)法實(shí)現(xiàn)各子系統(tǒng)間的聯(lián)動(dòng)分析，且對(duì)于系統(tǒng)內(nèi)部與系統(tǒng)間的故障，無(wú)法進(jìn)行精準(zhǔn)定位與分析處理。

信號(hào)智能運(yùn)維系統(tǒng)由傳統(tǒng)的數(shù)據(jù)分離式管理轉(zhuǎn)向數(shù)據(jù)集中式管理，數(shù)據(jù)量將爆發(fā)式增長(zhǎng)，具備大數(shù)據(jù)的“4V”特征，即規(guī)模性（volume）、多樣性（variety）、價(jià)值性（value）和高速性（velocity），使得傳統(tǒng)的技術(shù)架構(gòu)及路線已經(jīng)難以高效地處理和存儲(chǔ)如此海量的數(shù)據(jù)。以當(dāng)前主流的城市軌道交通控制系統(tǒng)、基于通信的列車自動(dòng)控制系統(tǒng)（communication based train control, CBTC）為例，系統(tǒng)將集中式管理 ATS,CI, DCS 及 MSS 等系統(tǒng)以及區(qū)域控制器 (zone control,ZC)、 車 載 控 制 器 (vehicle on-board controller，VOBC)、計(jì)軸和軌旁電子單元(lineside electronic unit, LEU)等子系統(tǒng)的數(shù)據(jù)。MSS系統(tǒng)會(huì)將信號(hào)基礎(chǔ)設(shè)備的數(shù)據(jù)傳輸至智能運(yùn)維系統(tǒng)，包含電源、外電網(wǎng)、道岔、軌道、繼電器、站臺(tái)與屏蔽門、轉(zhuǎn)轍機(jī)及信號(hào)機(jī)等信號(hào)系統(tǒng)基礎(chǔ)設(shè)施，系統(tǒng)數(shù)據(jù)流如圖1所示。

以某信號(hào)廠商的CBTC產(chǎn)品為例，單線路實(shí)際運(yùn)維數(shù)據(jù)量如表1所示。表中所計(jì)算的數(shù)據(jù)為原始數(shù)據(jù)，當(dāng)進(jìn)行解碼明文后，數(shù)據(jù)量級(jí)會(huì)更大；同時(shí)；信號(hào)系統(tǒng)基礎(chǔ)設(shè)施的運(yùn)維數(shù)據(jù)根據(jù)實(shí)際工程由不同的廠家提供，未在表中進(jìn)行估算。當(dāng)系統(tǒng)擴(kuò)大至線網(wǎng)級(jí)時(shí)，數(shù)據(jù)量會(huì)隨著線路條數(shù)成倍增長(zhǎng)。

表1 某CBTC產(chǎn)品單線路實(shí)際運(yùn)維數(shù)據(jù)量Tab. 1 Actual operation and maintenance data volume of a single line of a CBTC product

綜上所述，信號(hào)智能運(yùn)維的數(shù)據(jù)集中式管理會(huì)導(dǎo)致數(shù)據(jù)規(guī)模呈指數(shù)型增長(zhǎng)，一方面反映了信號(hào)系統(tǒng)本身的復(fù)雜程度，另一方面也顯示出信號(hào)系統(tǒng)運(yùn)維數(shù)據(jù)的復(fù)雜程度。智能運(yùn)維的本質(zhì)是使用分析理論和機(jī)器學(xué)習(xí)等方法來(lái)分析和處理各類設(shè)備產(chǎn)生的大量數(shù)據(jù)，通過(guò)一定的策略和算法來(lái)進(jìn)行智能化的監(jiān)測(cè)、診斷與決策。為建立更快、更準(zhǔn)確、更高效的信號(hào)系統(tǒng)智能運(yùn)維體系，實(shí)現(xiàn)智能運(yùn)維的目標(biāo)，需要成熟的數(shù)據(jù)平臺(tái)進(jìn)行支撐，而傳統(tǒng)的單機(jī)式的數(shù)據(jù)平臺(tái)已無(wú)法滿足當(dāng)前日益增長(zhǎng)的數(shù)據(jù)量的需求。因此，研究基于大數(shù)據(jù)技術(shù)的城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)，解決系統(tǒng)在實(shí)際應(yīng)用中面臨的數(shù)據(jù)問(wèn)題的需求已十分迫切。

2 智能運(yùn)維數(shù)據(jù)平臺(tái)研究

為解決城軌信號(hào)智能運(yùn)維系統(tǒng)在實(shí)際應(yīng)用中面臨的數(shù)據(jù)問(wèn)題，本文設(shè)計(jì)了一種數(shù)據(jù)平臺(tái)架構(gòu)，并提出了數(shù)據(jù)采集與傳輸、數(shù)據(jù)存儲(chǔ)及數(shù)據(jù)計(jì)算的解決方案。

2.1 數(shù)據(jù)平臺(tái)架構(gòu)

城軌信號(hào)智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)架構(gòu)如圖2所示，主要分為數(shù)據(jù)采集層、數(shù)據(jù)計(jì)算層、數(shù)據(jù)服務(wù)層和數(shù)據(jù)應(yīng)用層。

圖2 智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)架構(gòu)Fig.2 Data platform architecture of the intelligent operation and maintenance system

2.1.1 數(shù)據(jù)采集層

數(shù)據(jù)采集是系統(tǒng)架構(gòu)中最重要的一環(huán)。城軌信號(hào)智能運(yùn)維系統(tǒng)的數(shù)據(jù)采集主要為實(shí)時(shí)數(shù)據(jù)采集和日志數(shù)據(jù)采集。實(shí)時(shí)數(shù)據(jù)采集，指由各信號(hào)子系統(tǒng)及設(shè)備通過(guò)地鐵維護(hù)網(wǎng)使用用戶數(shù)據(jù)報(bào)協(xié)議(user datagram protocol，UDP)向通信組件集發(fā)送實(shí)時(shí)數(shù)據(jù)；如需要解碼，則由解碼組件集進(jìn)行解析后，按約定的數(shù)據(jù)格式寫入Kafka隊(duì)列。日志數(shù)據(jù)采集，指各子系統(tǒng)按照日志格式的需求將數(shù)據(jù)轉(zhuǎn)換成消息或落地成文件進(jìn)行存儲(chǔ)分析。

2.1.2 數(shù)據(jù)計(jì)算層

實(shí)時(shí)計(jì)算部分，采用Spark Streaming和Flink組件直接從Kafka集群中消費(fèi)隊(duì)列的數(shù)據(jù)，然后進(jìn)行計(jì)算與處理，并將處理結(jié)果發(fā)送到數(shù)據(jù)服務(wù)層的數(shù)據(jù)存儲(chǔ)模塊或?qū)懭隡ySQL給應(yīng)用層使用。離線計(jì)算按照業(yè)界的標(biāo)準(zhǔn)分層處理，主要有操作數(shù)據(jù)層、明細(xì)數(shù)據(jù)層、匯總數(shù)據(jù)層和數(shù)據(jù)集市層。分層之后的計(jì)算脈絡(luò)更清晰，便于支撐層對(duì)元數(shù)據(jù)、主數(shù)據(jù)、計(jì)算調(diào)度的管理。

2.1.3 數(shù)據(jù)服務(wù)層

數(shù)據(jù)服務(wù)層主要分為數(shù)據(jù)查詢引擎和數(shù)據(jù)存儲(chǔ)服務(wù)。查詢引擎有兩個(gè)職能，一是給應(yīng)用層提供數(shù)據(jù)服務(wù)接口；二是對(duì)查詢操作進(jìn)行路由，保障查詢的性能。城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)數(shù)據(jù)服務(wù)層的數(shù)據(jù)存儲(chǔ)采用分布式文件系統(tǒng)，為了提升數(shù)據(jù)分析能力，將部分?jǐn)?shù)據(jù)存儲(chǔ)于Redis集群，業(yè)務(wù)數(shù)據(jù)庫(kù)采用MySQL。

2.1.4 數(shù)據(jù)應(yīng)用層

數(shù)據(jù)應(yīng)用層從數(shù)據(jù)服務(wù)層提供的數(shù)據(jù)接口獲取數(shù)據(jù)，用于支撐信號(hào)智能運(yùn)維系統(tǒng)的功能實(shí)現(xiàn)，主要包含狀態(tài)監(jiān)測(cè)、健康管理、智能分析、規(guī)則引擎及故障定位等模塊。

2.2 數(shù)據(jù)采集與傳輸

數(shù)據(jù)采集是城軌信號(hào)智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)的基石，其核心是保證數(shù)據(jù)的完整性、準(zhǔn)確性和實(shí)效性。數(shù)據(jù)的完整性要求數(shù)據(jù)采集時(shí)盡可能搜集到足夠多且完整的信息，在采集過(guò)程及預(yù)處理過(guò)程中都不能丟失數(shù)據(jù)。數(shù)據(jù)的準(zhǔn)確性要求在數(shù)據(jù)采集過(guò)程中，不能因?yàn)轭A(yù)處理而導(dǎo)致處理后的數(shù)據(jù)與原始數(shù)據(jù)不一致，影響后續(xù)的分析和決策。數(shù)據(jù)的實(shí)效性要求數(shù)據(jù)采集要做到實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)。城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)的通信服務(wù)組件構(gòu)成如圖3所示。

圖3 通信服務(wù)組件構(gòu)成Fig.3 Composition of communication service components

按照《城市軌道交通基于通信的列車運(yùn)行控制系統(tǒng)（CBTC）互聯(lián)互通接口規(guī)范》[5]規(guī)定，信號(hào)各設(shè)備實(shí)時(shí)數(shù)據(jù)發(fā)送周期如下：VOBC系統(tǒng)的為320 ms；ZC 系統(tǒng)的為 400 ms；CI系統(tǒng)的為 160 ms；ATS系統(tǒng)的為5 s；MSS系統(tǒng)的為 1 s；DCS系統(tǒng)的為1 s。部分信號(hào)基礎(chǔ)設(shè)備的數(shù)據(jù)發(fā)送周期可自定義。由各子系統(tǒng)采用UDP協(xié)議向智能運(yùn)維數(shù)據(jù)平臺(tái)通信組件發(fā)送實(shí)時(shí)數(shù)據(jù)，各子系統(tǒng)的日志按需求轉(zhuǎn)換成消息或落地成文件進(jìn)行存儲(chǔ)分析。同時(shí)，預(yù)留Kafka接口給外部系統(tǒng)（如地鐵綜合智能運(yùn)維平臺(tái)）使用。

城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)面臨數(shù)據(jù)量高并發(fā)、數(shù)據(jù)發(fā)送周期不同、數(shù)據(jù)解碼組件的處理速度無(wú)法跟上數(shù)據(jù)寫入速度等問(wèn)題。城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)采用Kafka消息隊(duì)列，Kafka是一個(gè)高性能、跨語(yǔ)言、分布式、發(fā)布與訂閱消息隊(duì)列的系統(tǒng)，消費(fèi)者通過(guò)拉取的方式消費(fèi)消息。城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)利用Kafka消息隊(duì)列作為消息中間件，并使用多個(gè)Kafka消息隊(duì)列集群。針對(duì)信號(hào)設(shè)備的不同子系統(tǒng)業(yè)務(wù)劃分為不同的集群和Kafka Topic，可提高信號(hào)設(shè)備各子系統(tǒng)運(yùn)維數(shù)據(jù)寫入的并發(fā)性能，提高系統(tǒng)吞吐量，方便數(shù)據(jù)處理程序進(jìn)行消費(fèi)處理，提高讀的并發(fā)性能。Kafka可以讓信號(hào)設(shè)備子系統(tǒng)與子系統(tǒng)之間的耦合度大大降低，同時(shí)讓系統(tǒng)之間的業(yè)務(wù)處理異步化，并且可以配置消息寫入模式來(lái)降低丟失消息的風(fēng)險(xiǎn)，其是城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)實(shí)現(xiàn)最終一致性、可擴(kuò)展性、高可用性的重要基石。

2.3 數(shù)據(jù)存儲(chǔ)

根據(jù)城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)架構(gòu)，可推導(dǎo)出數(shù)據(jù)平臺(tái)存儲(chǔ)架構(gòu)，如圖4所示。城軌信號(hào)智能運(yùn)維數(shù)據(jù)存儲(chǔ)架構(gòu)分為業(yè)務(wù)存儲(chǔ)、消息存儲(chǔ)、離線存儲(chǔ)、分析存儲(chǔ)和應(yīng)用存儲(chǔ)；系統(tǒng)使用MySQL作為業(yè)務(wù)數(shù)據(jù)庫(kù)；采用Kakfa消息隊(duì)列作為消息中間件進(jìn)行消息存儲(chǔ)；采用分布式文件系統(tǒng)（hadoop distributed file system，HDFS）進(jìn)行離線存儲(chǔ)；分析數(shù)據(jù)存儲(chǔ)采用ClickHouse，實(shí)時(shí)數(shù)據(jù)存儲(chǔ)采用Druid；應(yīng)用存儲(chǔ)采用MySQL或Redis，服務(wù)于應(yīng)用層。

圖4 數(shù)據(jù)儲(chǔ)存架構(gòu)圖Fig.4 Architecture diagram of data storage

隨著系統(tǒng)應(yīng)用時(shí)間的推移，數(shù)據(jù)規(guī)模會(huì)從GB上升至TB級(jí)別。以長(zhǎng)沙地鐵3號(hào)線為例，業(yè)主要求ATS的系統(tǒng)需要至少存儲(chǔ)180天，車載VOBC系統(tǒng)需要存儲(chǔ)7天，CI/ZC/DMS/MSS存儲(chǔ)90天，原始數(shù)據(jù)量已在10 TB左右。在實(shí)際應(yīng)用中，信號(hào)各子系統(tǒng)業(yè)務(wù)不斷產(chǎn)生大量的原始數(shù)據(jù)，原始數(shù)據(jù)被分析和處理再加工、再存儲(chǔ)后，數(shù)據(jù)規(guī)模和數(shù)據(jù)吞吐量將變得更為龐大，導(dǎo)致采用傳統(tǒng)的單節(jié)點(diǎn)來(lái)存儲(chǔ)已比較困難。傳統(tǒng)的單點(diǎn)存儲(chǔ)帶來(lái)的問(wèn)題如下：

（1）性能問(wèn)題。由于數(shù)據(jù)量較大，系統(tǒng)的數(shù)據(jù)索引效率較低。

（2）成本問(wèn)題。大型主機(jī)成本較高，導(dǎo)致硬件成本、運(yùn)維成本、能耗成本增加。

（3）單點(diǎn)問(wèn)題。傳統(tǒng)存儲(chǔ)由于沒(méi)有采用分布式文件系統(tǒng)，當(dāng)單塊磁盤損壞時(shí)，將面臨數(shù)據(jù)丟失的情況。

為解決上述問(wèn)題，城軌信號(hào)智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)的離線儲(chǔ)存采用HDFS。系統(tǒng)設(shè)置3個(gè)數(shù)據(jù)副本用于保證數(shù)據(jù)可用性，同時(shí)為了節(jié)約存儲(chǔ)資源，采用特定的數(shù)據(jù)壓縮算法來(lái)降低總體存儲(chǔ)量。HDFS采用中心總控式架構(gòu)（圖5），包含NameNode，DataNode和Client這3個(gè)部分[6]。各部分功能如下：

圖5 HDFS架構(gòu)Fig.5 HDFS architecture

（1）NameNode集群的中心節(jié)點(diǎn)，用于管理整個(gè)文件系統(tǒng)的元信息。元信息主要包括HDFS目錄樹(shù)、文件副本數(shù)、文件到數(shù)據(jù)節(jié)點(diǎn)的映射關(guān)系和DataNode的操作。

（2）DataNode主要用于存儲(chǔ)文件塊、響應(yīng)Client的文件讀/寫請(qǐng)求和執(zhí)行文件塊的創(chuàng)建、刪除和復(fù)制操作。

（3）Client主要作用是在數(shù)據(jù)應(yīng)用層與HDFS交互過(guò)程中提供面向應(yīng)用的統(tǒng)一數(shù)據(jù)接口。

城軌信號(hào)智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)采用HDFS的優(yōu)勢(shì)如下：HDFS具備儲(chǔ)存節(jié)點(diǎn)錯(cuò)誤檢測(cè)和快速、自動(dòng)恢復(fù)功能，解決了傳統(tǒng)儲(chǔ)存方式因硬件故障而導(dǎo)致數(shù)據(jù)丟失的問(wèn)題；HDFS提供數(shù)據(jù)訪問(wèn)的高吞吐量，完美適配了城軌信號(hào)智能運(yùn)維系統(tǒng)子系統(tǒng)多、數(shù)據(jù)雜、數(shù)據(jù)發(fā)送頻率高的場(chǎng)景；HDFS支持大規(guī)模數(shù)據(jù)集，一個(gè)單一的HDFS實(shí)例能支撐數(shù)以千萬(wàn)計(jì)的文件；HDFS對(duì)硬件性能要求較低，降低了系統(tǒng)成本。HDFS也存在部分不適用的場(chǎng)景：

（1）低延遲訪問(wèn)的場(chǎng)景。HDFS主要針對(duì)系統(tǒng)吞吐量做了很多優(yōu)化設(shè)計(jì)，而數(shù)據(jù)訪問(wèn)的實(shí)時(shí)性要求不高。

（2）儲(chǔ)存大量小文件。

（3）多個(gè)寫入以及隨機(jī)修改的場(chǎng)景。

2.4 離線計(jì)算

城軌信號(hào)智能運(yùn)維系統(tǒng)的核心功能模塊包括故障預(yù)測(cè)與健康管理（prognostics health management，PHM）模塊、日志分析模塊及數(shù)據(jù)回放等，其功能的實(shí)現(xiàn)需要大量的數(shù)據(jù)計(jì)算支撐。以PHM模塊為例，城軌信號(hào)智能運(yùn)維系統(tǒng)基于數(shù)據(jù)采集、數(shù)據(jù)處理和狀態(tài)檢測(cè)模塊處理后的設(shè)備狀態(tài)數(shù)據(jù)，結(jié)合歷史數(shù)據(jù)，采用建模和統(tǒng)計(jì)等方法，實(shí)現(xiàn)健康評(píng)估和故障預(yù)測(cè)，并提出維護(hù)建議[7-8]。以日志分析為例，信號(hào)各子系統(tǒng)的日志數(shù)據(jù)十分龐大，日志分析模塊常需要分析GB級(jí)別的數(shù)據(jù)，數(shù)據(jù)回放功能則需要加載某段時(shí)間內(nèi)所有設(shè)備狀態(tài)的歷史狀態(tài)數(shù)據(jù)。

從上述功能模塊的需求可知，海量計(jì)算是上述系統(tǒng)功能實(shí)現(xiàn)的基礎(chǔ)。城軌信號(hào)智能運(yùn)維系統(tǒng)的離線計(jì)算組件由分布式計(jì)算模型MapReduce提供數(shù)據(jù)計(jì)算能力，整個(gè)計(jì)算分成Map和Reduce兩個(gè)階段[9]，Mapper與Reduce的任務(wù)執(zhí)行過(guò)程如圖6所示。

圖6 MapReduce的執(zhí)行過(guò)程Fig.6 Execution process of MapReduce

在Map階段，并行處理輸入數(shù)據(jù)。每個(gè)Mapper任務(wù)都是一個(gè)進(jìn)程，讀取HDFS中的文件，將文件解析為鍵值對(duì)(key-value)，經(jīng)過(guò)Map函數(shù)處理后，轉(zhuǎn)換為新的鍵值對(duì)輸出。

在Reduce階段，對(duì)Map結(jié)果進(jìn)行匯總。同樣，每個(gè)Reduce任務(wù)都是一個(gè)進(jìn)程，Reduce任務(wù)接收Mapper任務(wù)的輸出，處理后寫入HDFS。

2.5 實(shí)時(shí)計(jì)算

城軌信號(hào)智能運(yùn)維系統(tǒng)的基礎(chǔ)功能是可視化監(jiān)測(cè)、設(shè)備報(bào)警與故障定位?？梢暬O(jiān)測(cè)需要系統(tǒng)將收到的各子系統(tǒng)的實(shí)時(shí)數(shù)據(jù)經(jīng)過(guò)清洗處理后在應(yīng)用層展示。設(shè)備報(bào)警的實(shí)現(xiàn)邏輯是，由規(guī)則引擎對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行計(jì)算，將系統(tǒng)采集到的設(shè)備數(shù)據(jù)輸入到針對(duì)各信號(hào)子系統(tǒng)設(shè)備設(shè)計(jì)的規(guī)則模型中，經(jīng)過(guò)規(guī)則模型計(jì)算后產(chǎn)生輸出結(jié)果，判定設(shè)備是否故障并對(duì)故障進(jìn)行報(bào)警[10]。報(bào)警產(chǎn)生后，系統(tǒng)會(huì)對(duì)數(shù)據(jù)進(jìn)行分析，提供故障定位功能來(lái)輔助作業(yè)人員進(jìn)行運(yùn)行維護(hù)。對(duì)這些業(yè)務(wù)功能來(lái)說(shuō)，數(shù)據(jù)的特點(diǎn)是隨著時(shí)間的流逝，數(shù)據(jù)價(jià)值不斷降低，提高數(shù)據(jù)處理速度和保證數(shù)據(jù)實(shí)時(shí)性是極其重要的。為解決計(jì)算的實(shí)時(shí)性、準(zhǔn)確性和響應(yīng)速度問(wèn)題，城軌信號(hào)智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)的實(shí)時(shí)計(jì)算組件采用Spark Streaming和Flink。

Spark Streaming是一個(gè)對(duì)實(shí)時(shí)數(shù)據(jù)流進(jìn)行高通量、容錯(cuò)處理的流式處理系統(tǒng)。城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)可視化監(jiān)測(cè)采用Spark Streaming，從Kafka數(shù)據(jù)源獲取信號(hào)設(shè)備的實(shí)時(shí)數(shù)據(jù)；采用高級(jí)函數(shù)對(duì)數(shù)據(jù)進(jìn)行復(fù)雜的數(shù)據(jù)計(jì)算和圖形計(jì)算，并將結(jié)果輸出給數(shù)據(jù)服務(wù)層，由數(shù)據(jù)應(yīng)用層將設(shè)備實(shí)時(shí)狀態(tài)展示在系統(tǒng)上。

城軌信號(hào)智能運(yùn)維系統(tǒng)通過(guò)設(shè)計(jì)邏輯語(yǔ)句解釋器來(lái)實(shí)現(xiàn)故障規(guī)則引擎。故障規(guī)則由條件和動(dòng)作兩部分組成，規(guī)則引擎的輸入端是一系列規(guī)則（稱為“規(guī)則執(zhí)行集”）和數(shù)據(jù)對(duì)象[11]，針對(duì)不同子系統(tǒng)和業(yè)務(wù)場(chǎng)景提供的模型輸入端均不相同。Spark在流處理的實(shí)時(shí)性方面具有一定的局限性，而Flink是一個(gè)針對(duì)流數(shù)據(jù)和批數(shù)據(jù)的分布式處理引擎，其處理的數(shù)據(jù)主要是流數(shù)據(jù)，非常適用于規(guī)則引擎和故障定位的場(chǎng)景[12]。Flink包含的主要模塊有Data Source,Transformations和 Data Sink。其中，Data Source就是要進(jìn)入Flink處理的數(shù)據(jù)，如HDFS, Kafka中的數(shù)據(jù)；Transformations根據(jù)實(shí)際業(yè)務(wù)進(jìn)行計(jì)算和轉(zhuǎn)換；Data Sink是Flink處理完的數(shù)據(jù)，即輸出數(shù)據(jù)。圖7示出ZC系統(tǒng)的列車移動(dòng)授權(quán)（movement authority, MA）回撤故障定位案例。ZC系統(tǒng)發(fā)生此項(xiàng)報(bào)警時(shí)，系統(tǒng)通過(guò)Kafka隊(duì)列將數(shù)據(jù)（ZC數(shù)據(jù)、計(jì)軸數(shù)據(jù)、道岔數(shù)據(jù)、聯(lián)鎖數(shù)據(jù)、信號(hào)機(jī)數(shù)據(jù)及列車數(shù)據(jù)）傳入Flink形成數(shù)據(jù)源，由Transformations模塊根據(jù)規(guī)則引擎提供的規(guī)則進(jìn)行計(jì)算和轉(zhuǎn)化。計(jì)算過(guò)程完成后，由Data Sink模塊將故障定位數(shù)據(jù)輸出至應(yīng)用層。

圖7 ZC系統(tǒng)列車MA回撤故障定位Fig.7 Fault location of train MA fallback in ZC system

3 系統(tǒng)應(yīng)用

城軌信號(hào)智能運(yùn)維系統(tǒng)數(shù)據(jù)平臺(tái)利用大數(shù)據(jù)技術(shù)生態(tài)實(shí)現(xiàn)了對(duì)各信號(hào)子系統(tǒng)與信號(hào)基礎(chǔ)設(shè)備海量數(shù)據(jù)的采集、存儲(chǔ)、分析和處理，其通過(guò)數(shù)據(jù)平臺(tái)的數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)層、數(shù)據(jù)服務(wù)層和數(shù)據(jù)應(yīng)用層4層架構(gòu)支撐業(yè)務(wù)系統(tǒng)的應(yīng)用，是實(shí)現(xiàn)系統(tǒng)可視化監(jiān)測(cè)、健康管理、智能分析、規(guī)則引擎等核心模塊的基礎(chǔ)設(shè)施[13-14]。與傳統(tǒng)的數(shù)據(jù)平臺(tái)架構(gòu)相比，本數(shù)據(jù)平臺(tái)在數(shù)據(jù)采集與利用效率、離線計(jì)算與實(shí)時(shí)計(jì)算效率、儲(chǔ)存可靠性、吞吐量和成本方面更具優(yōu)勢(shì)。

以本系統(tǒng)在某城軌線路上的試點(diǎn)部署情況為例，信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)采用5節(jié)點(diǎn)結(jié)構(gòu)。單節(jié)點(diǎn)配置如下：（1） CPU，數(shù)量2，型號(hào)為英特爾4110處理器；（2）內(nèi)存，數(shù)量8，容量為16 GB，速率為2 133 MT/s；（3）硬盤，容量為16 TB，轉(zhuǎn)速為7 200 RPM。該數(shù)據(jù)平臺(tái)性能如下：

（1）從運(yùn)行效果來(lái)看，由其支撐的業(yè)務(wù)核心模塊均能穩(wěn)定快速運(yùn)行。數(shù)據(jù)采集方面，在系統(tǒng)運(yùn)行狀態(tài)和維護(hù)網(wǎng)網(wǎng)絡(luò)狀態(tài)正常情況下，數(shù)據(jù)采集丟包率較低，可視化監(jiān)測(cè)從接收數(shù)據(jù)到處理完畢的時(shí)間不超過(guò)1 s。

（2）數(shù)據(jù)計(jì)算分析方面，典型報(bào)警從設(shè)備產(chǎn)生至系統(tǒng)顯示時(shí)間不超過(guò)1 s,典型故障定位時(shí)間不超過(guò)5 s，單個(gè)設(shè)備數(shù)據(jù)回放加載時(shí)間不超過(guò)10 s，系統(tǒng)級(jí)數(shù)據(jù)回放加載時(shí)間不超過(guò)15 s，故障規(guī)則引擎每5 s運(yùn)行一次，始終穩(wěn)定運(yùn)行。

（3）存儲(chǔ)方面，單個(gè)硬件節(jié)點(diǎn)故障不會(huì)引起數(shù)據(jù)的丟失和系統(tǒng)的癱瘓，系統(tǒng)吞吐量高，且成本較傳統(tǒng)單節(jié)點(diǎn)相對(duì)較低。

（4）從系統(tǒng)本身可靠性來(lái)看，城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)對(duì)系統(tǒng)服務(wù)有效性起到了保障，平均故障間隔時(shí)間（MTBF）、平均修復(fù)時(shí)間（MTTR）和系統(tǒng)可用性（Availability）等指標(biāo)均優(yōu)于傳統(tǒng)架構(gòu)。

以實(shí)驗(yàn)室仿真測(cè)試數(shù)據(jù)為例（5節(jié)點(diǎn)），測(cè)試監(jiān)測(cè)項(xiàng)點(diǎn)數(shù)量約為10萬(wàn)個(gè)，測(cè)點(diǎn)信息如表2所示，單次測(cè)點(diǎn)數(shù)據(jù)處理分析性能對(duì)比、隊(duì)列性能和平臺(tái)吞吐量及IO性能如圖8所示。從結(jié)果看，在主要性能指標(biāo)方面，智能運(yùn)維數(shù)據(jù)平臺(tái)均優(yōu)于傳統(tǒng)單機(jī)數(shù)據(jù)平臺(tái)：

圖8 智能運(yùn)維數(shù)據(jù)平臺(tái)與傳統(tǒng)數(shù)據(jù)平臺(tái)性能對(duì)比Fig.8 Performance comparison between intelligent operation and maintenance data platform and traditional data platform

表2 實(shí)驗(yàn)室仿真監(jiān)測(cè)項(xiàng)點(diǎn)信息Tab. 2 Laboratory simulation monitoring item informations

（1）數(shù)據(jù)處理方面，傳統(tǒng)單機(jī)平臺(tái)單次處理時(shí)間約為12 851 ms，智能運(yùn)維數(shù)據(jù)平臺(tái)處理時(shí)間為 2 672 ms，處理效率提高約 4.8倍。

（2）隊(duì)列性能方面，傳統(tǒng)數(shù)據(jù)平臺(tái)生產(chǎn)數(shù)據(jù)吞吐量約為 26.7 Mb/s，消費(fèi)數(shù)據(jù)吞吐量約為 79.4 Mb/s；智能運(yùn)維數(shù)據(jù)平臺(tái)生產(chǎn)數(shù)據(jù)吞吐量為104.9 Mb/s，消費(fèi)數(shù)據(jù)吞吐量為203.2 Mb/s；整體效率提升約2.9倍。

（3）數(shù)據(jù)讀寫方面，智能運(yùn)維數(shù)據(jù)平臺(tái)吞吐量與 IO 性能在寫數(shù)據(jù)時(shí)分別為 279 Mb/s, 313 Mb/s；讀數(shù)據(jù)時(shí)分別為 442 Mb/s, 863 Mb/s。

4 結(jié)語(yǔ)

本文研究了一種基于大數(shù)據(jù)技術(shù)的城軌信號(hào)智能運(yùn)維數(shù)據(jù)平臺(tái)，與既有的數(shù)據(jù)平臺(tái)架構(gòu)相比，其在數(shù)據(jù)采集、數(shù)據(jù)儲(chǔ)存、數(shù)據(jù)實(shí)時(shí)和離線計(jì)算等方面均具備一定的優(yōu)勢(shì)，平臺(tái)的主要性能指標(biāo)均能滿足當(dāng)前城軌信號(hào)智能運(yùn)維系統(tǒng)的應(yīng)用需求。但與此同時(shí)，平臺(tái)本身的開(kāi)發(fā)周期長(zhǎng)，技術(shù)難度高，迭代成本較高且工程實(shí)施與后期維護(hù)的專業(yè)性要求也較高。如何解決數(shù)據(jù)平臺(tái)低成本迭代與降低工程實(shí)施與運(yùn)維成本更需進(jìn)一步地深入研究。

總體來(lái)說(shuō)，該數(shù)據(jù)平臺(tái)具備數(shù)字化、標(biāo)準(zhǔn)化、智能化的基本特征，其作為基礎(chǔ)設(shè)施組件，支撐了城軌信號(hào)智能運(yùn)維系統(tǒng)的應(yīng)用，進(jìn)而構(gòu)建運(yùn)、檢、修一體化的城市軌道交通信號(hào)設(shè)備智能運(yùn)維服務(wù)體系，促進(jìn)信號(hào)設(shè)備運(yùn)維由傳統(tǒng)的計(jì)劃修向狀態(tài)修轉(zhuǎn)型，為城市軌道交通信號(hào)設(shè)備運(yùn)維工作的降本增效奠定了基礎(chǔ)。通過(guò)本數(shù)據(jù)平臺(tái)的應(yīng)用，信號(hào)智能運(yùn)維的數(shù)據(jù)采集、儲(chǔ)存、分析和處理效率逐步提高，數(shù)據(jù)平臺(tái)成本明顯下降。隨著《中國(guó)城市軌道交通智慧城軌發(fā)展綱要》的全面落實(shí)，該數(shù)據(jù)平臺(tái)在信號(hào)系統(tǒng)領(lǐng)域之外，也可以提供給城軌供電、車輛、AFC、車站機(jī)電等系統(tǒng)進(jìn)行多專業(yè)綜合應(yīng)用，同時(shí)通過(guò)對(duì)數(shù)據(jù)平臺(tái)的進(jìn)一步挖掘，結(jié)合物聯(lián)網(wǎng)、人工智能及5G通信等技術(shù)的聯(lián)合應(yīng)用，可進(jìn)一步提升運(yùn)維系統(tǒng)的智能化程度，達(dá)到真正的運(yùn)維智能化。