鄧永祁，楊 將，陽亦斌

（湖南中車時代通信信號有限公司，湖南 長沙 410005）

0 引言

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

1 信號設備運維數(shù)據(jù)平臺現(xiàn)狀

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

信號智能運維系統(tǒng)由傳統(tǒng)的數(shù)據(jù)分離式管理轉向數(shù)據(jù)集中式管理，數(shù)據(jù)量將爆發(fā)式增長，具備大數(shù)據(jù)的“4V”特征，即規(guī)模性（volume）、多樣性（variety）、價值性（value）和高速性（velocity），使得傳統(tǒng)的技術架構及路線已經(jīng)難以高效地處理和存儲如此海量的數(shù)據(jù)。以當前主流的城市軌道交通控制系統(tǒ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)、計軸和軌旁電子單元(lineside electronic unit, LEU)等子系統(tǒng)的數(shù)據(jù)。MSS系統(tǒng)會將信號基礎設備的數(shù)據(jù)傳輸至智能運維系統(tǒng)，包含電源、外電網(wǎng)、道岔、軌道、繼電器、站臺與屏蔽門、轉轍機及信號機等信號系統(tǒng)基礎設施，系統(tǒng)數(shù)據(jù)流如圖1所示。

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

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

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

2 智能運維數(shù)據(jù)平臺研究

為解決城軌信號智能運維系統(tǒng)在實際應用中面臨的數(shù)據(jù)問題，本文設計了一種數(shù)據(jù)平臺架構，并提出了數(shù)據(jù)采集與傳輸、數(shù)據(jù)存儲及數(shù)據(jù)計算的解決方案。

2.1 數(shù)據(jù)平臺架構

城軌信號智能運維系統(tǒng)數(shù)據(jù)平臺架構如圖2所示，主要分為數(shù)據(jù)采集層、數(shù)據(jù)計算層、數(shù)據(jù)服務層和數(shù)據(jù)應用層。

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

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

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

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

實時計算部分，采用Spark Streaming和Flink組件直接從Kafka集群中消費隊列的數(shù)據(jù)，然后進行計算與處理，并將處理結果發(fā)送到數(shù)據(jù)服務層的數(shù)據(jù)存儲模塊或寫入MySQL給應用層使用。離線計算按照業(yè)界的標準分層處理，主要有操作數(shù)據(jù)層、明細數(shù)據(jù)層、匯總數(shù)據(jù)層和數(shù)據(jù)集市層。分層之后的計算脈絡更清晰，便于支撐層對元數(shù)據(jù)、主數(shù)據(jù)、計算調(diào)度的管理。

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

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

2.1.4 數(shù)據(jù)應用層

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

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

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

圖3 通信服務組件構成Fig.3 Composition of communication service components

按照《城市軌道交通基于通信的列車運行控制系統(tǒng)（CBTC）互聯(lián)互通接口規(guī)范》[5]規(guī)定，信號各設備實時數(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。部分信號基礎設備的數(shù)據(jù)發(fā)送周期可自定義。由各子系統(tǒng)采用UDP協(xié)議向智能運維數(shù)據(jù)平臺通信組件發(fā)送實時數(shù)據(jù)，各子系統(tǒng)的日志按需求轉換成消息或落地成文件進行存儲分析。同時，預留Kafka接口給外部系統(tǒng)（如地鐵綜合智能運維平臺）使用。

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

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

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

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

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

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

（2）成本問題。大型主機成本較高，導致硬件成本、運維成本、能耗成本增加。

（3）單點問題。傳統(tǒng)存儲由于沒有采用分布式文件系統(tǒng)，當單塊磁盤損壞時，將面臨數(shù)據(jù)丟失的情況。

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

圖5 HDFS架構Fig.5 HDFS architecture

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

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

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

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

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

（2）儲存大量小文件。

（3）多個寫入以及隨機修改的場景。

2.4 離線計算

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

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

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

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

在Reduce階段，對Map結果進行匯總。同樣，每個Reduce任務都是一個進程，Reduce任務接收Mapper任務的輸出，處理后寫入HDFS。

2.5 實時計算

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

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

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

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

3 系統(tǒng)應用

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

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

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

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

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

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

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

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

表2 實驗室仿真監(jiān)測項點信息Tab. 2 Laboratory simulation monitoring item informations

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

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

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

4 結語

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

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