城軌信號系統(tǒng)大數(shù)據(jù)平臺部署方案研究

侯旭陽，田 元，陳 逸

(通號城市軌道交通技術(shù)有限公司，北京 100070)

1 大數(shù)據(jù)平臺需求分析

以Hadoop 為代表的開源大數(shù)據(jù)平臺目前已經(jīng)在互聯(lián)網(wǎng)相關(guān)行業(yè)得到廣泛應(yīng)用。在傳統(tǒng)領(lǐng)域，比如交通、工業(yè)現(xiàn)場控制、農(nóng)業(yè)等也正在得到快速的應(yīng)用。傳統(tǒng)信號系統(tǒng)主要依靠定制化程度較高的信號監(jiān)測系統(tǒng)實現(xiàn)系統(tǒng)級的數(shù)據(jù)存儲、統(tǒng)計分析功能，但是受限于平臺的軟硬件架構(gòu)能力，無法實現(xiàn)大數(shù)據(jù)級的數(shù)據(jù)挖掘和統(tǒng)計分析功能。在信號系統(tǒng)范圍內(nèi)部署大數(shù)據(jù)平臺可以較好的解決該問題。

信號系統(tǒng)目前針對大數(shù)據(jù)平臺主要集中在以下幾種應(yīng)用場景。

1）用戶能力評價。比如通過ATO 運行數(shù)據(jù)與司機手工駕駛數(shù)據(jù)進行對比，用以評價司機及熟練程度，或者通過分析日常維護過程的數(shù)據(jù)，分析維護人員的熟練程度，用于用戶能力的精準評價。

2）備品備件庫存調(diào)整。通過積累的故障歷史數(shù)據(jù)（比如各設(shè)備板卡故障時間、地點、次數(shù)，設(shè)備運行時間，故障設(shè)備的電壓、電流、網(wǎng)絡(luò)設(shè)備的流量、丟包率等）和設(shè)備故障模型，預(yù)測一定時間內(nèi)設(shè)備發(fā)生故障的概率，對備品備件的庫存進行智能調(diào)整，用于改善現(xiàn)金流。

3）故障預(yù)測和故障影響評價。通過積累的歷史故障數(shù)據(jù)，將故障按季節(jié)、溫度等要素進行分類，分析規(guī)律性內(nèi)容，用于開展針對性的故障防范措施。

上述應(yīng)用場景對信號系統(tǒng)大數(shù)據(jù)平臺提出下面技術(shù)需求。

1）平臺需要存儲較長時間范圍內(nèi)數(shù)據(jù)。原因在于信號系統(tǒng)的RAMS 指標比一般的非涉安系統(tǒng)高，故障次數(shù)相對更少，為了支撐分析歷史故障數(shù)據(jù)，需要長期記錄全系統(tǒng)的數(shù)據(jù)，這些數(shù)據(jù)在傳統(tǒng)的維護監(jiān)測系統(tǒng)中并不需要記錄。

2）平臺需要存儲盡可能廣泛的系統(tǒng)運行過程中的數(shù)據(jù)。無論是分析司機駕駛的數(shù)據(jù)還是維護人員的施工數(shù)據(jù)，都需要盡可能采集設(shè)備運行中實時產(chǎn)生的過程數(shù)據(jù)，而這些數(shù)據(jù)在傳統(tǒng)的維護監(jiān)測系統(tǒng)中也不需要記錄。

3）平臺的規(guī)模和造價需要控制在合理范圍內(nèi)。鑒于平臺的最終作用在于數(shù)據(jù)挖掘和統(tǒng)計分析，為用戶改善現(xiàn)金流或者節(jié)省人力資源，本身并不能直接創(chuàng)造利潤，因此造價必須控制在合理范圍內(nèi)才能具備推廣價值。

2 部署方案

2.1 硬件架構(gòu)方案設(shè)計

服務(wù)器硬件：大數(shù)據(jù)平臺的服務(wù)器硬件采用通用的、可擴展能力強和存儲能力的商用服務(wù)器，最小規(guī)模條件下采用雙機設(shè)計即可，同時預(yù)留后續(xù)硬件橫向（增加主機數(shù)量）和縱向（增加單個主機的CPU、內(nèi)存、存儲）擴展能力。服務(wù)器存儲空間和內(nèi)存空間均需要提前估算信號系統(tǒng)實時數(shù)據(jù)量決定。典型的單臺服務(wù)器配置包括：Linux 操作系統(tǒng)或者可運行Linux 虛擬機，雙CPU 配置，單個CPU 至少為8 ～16 核；內(nèi)存至少為64 G；硬盤至少為4塊，單塊在1 T 以上。

終端硬件：大數(shù)據(jù)平臺的監(jiān)視和維護終端對硬件要求并不高，因此既可以單獨設(shè)置，也完全可以與維護網(wǎng)內(nèi)其他用戶終端合并設(shè)置（比如維護工作站）。

網(wǎng)絡(luò)硬件：由于大數(shù)據(jù)平臺所在的網(wǎng)絡(luò)需要接入大量其他子系統(tǒng)的數(shù)據(jù)，為不影響信號系統(tǒng)傳統(tǒng)業(yè)務(wù)功能，可采用復(fù)用維護網(wǎng)的方式，城軌系統(tǒng)中維護網(wǎng)可以為單網(wǎng)或者雙網(wǎng)，與ATS 網(wǎng)或者ATC網(wǎng)分開設(shè)置。一方面復(fù)用維護網(wǎng)這樣既節(jié)省了投資，又能避免過大的數(shù)據(jù)流影響。另一方面，針對既有線改造，接入維護網(wǎng)可以更方便的從既有信號維護監(jiān)測系統(tǒng)（比如直連維護監(jiān)測的DMS 服務(wù)器）獲取數(shù)據(jù)。

與其他子系統(tǒng)接口：為提高網(wǎng)絡(luò)吞吐量和系統(tǒng)擴展性并同時減少維護工作，與其他子系統(tǒng)接口均統(tǒng)一為以太網(wǎng)接口。

典型的硬件架構(gòu),如圖1 所示。

圖1 硬件架構(gòu)圖Fig.1 Hardware architecture

2.2 軟件平臺部署方案設(shè)計

后臺：軟件平臺以開源軟件為主，采用Apache基金會的Spark 和Hadoop 的統(tǒng)一部署方式。

文件系統(tǒng)采用Hadoop 的HDFS 分布式文件系統(tǒng)，該文件系統(tǒng)實現(xiàn)了高度的硬件容錯性、高吞吐量的讀取速度、良好的可擴展性、便捷的流式讀取。

HDFS 上層部署Yarn 資源調(diào)度平臺。Yarn 資源調(diào)度平臺作為集群的資源管理器和運行在集群中所有節(jié)點上的節(jié)點管理器來啟動和監(jiān)控容器（使用一定內(nèi)存、CPU 等計算資源執(zhí)行特定應(yīng)用程序的一系列流程的集合）。

Spark 是目前應(yīng)用較為廣泛的專用于大規(guī)模數(shù)據(jù)處理的通用計算引擎，由于Spark 采用內(nèi)存分布數(shù)據(jù)集，因此性能相對更好。Spark 提供了大量的庫，可以執(zhí)行各類任務(wù)，比如SQL 數(shù)據(jù)查詢引擎Spark SQL、用于實時數(shù)據(jù)處理的流計算Spark Streaming、用于機器學(xué)習(xí)的MLlib、用于圖計算的GraphX。典型的Spark 和Hadoop 混合部署的方案，如圖2 所示。

圖2 大數(shù)據(jù)后臺軟件部署方案Fig.2 Big data background software deployment scheme

客戶端：采用B/S 架構(gòu)在客戶端瀏覽器呈現(xiàn)數(shù)據(jù)統(tǒng)計分析、運維、開發(fā)任務(wù)的可視化界面。因此終端可以部署Windows 操作系統(tǒng)或者Linux 操作系統(tǒng)（比如維護工作站）。

根據(jù)不同崗位上用戶的工作內(nèi)容區(qū)分，客戶端分為以下幾類部署。

1) 平臺維護客戶端：負責監(jiān)視服務(wù)器的硬件負載、計算任務(wù)執(zhí)行進度、網(wǎng)絡(luò)狀態(tài)、各客戶端用戶狀態(tài)；對各類硬件進行遠程運維，比如硬件重啟、更換程序、用戶權(quán)限管理、計算節(jié)點管理。該終端面向運維人員。

2)任務(wù)開發(fā)客戶端：負責根據(jù)其他用戶需求在平臺上開展計算任務(wù)程序開發(fā)、程序提交、程序調(diào)試、任務(wù)上線。該終端面向大數(shù)據(jù)開發(fā)人員。

3)統(tǒng)計查詢客戶端：發(fā)起數(shù)據(jù)查詢、呈現(xiàn)數(shù)據(jù)統(tǒng)計分析結(jié)果。該終端面向使用最終計算結(jié)果信息的用戶。

實時計算任務(wù)和批量計算任務(wù)的最終計算結(jié)果的呈現(xiàn)將通過客戶端實現(xiàn)。從數(shù)據(jù)源到客戶端的數(shù)據(jù)流如圖3 所示。

從圖3 中可以看出，由于采用B/S 架構(gòu)，且客戶端本身并不承擔計算任務(wù)，因此客戶端的部署位置可以比較靈活，比如車站、控制中心或者備用中心等。從而實現(xiàn)平臺維護、結(jié)果查詢、任務(wù)開發(fā)的工作崗位靈活拆分與合并。

圖3 大數(shù)據(jù)平臺數(shù)據(jù)流Fig.3 Data flow of big data platform

2.3 對外接口方案設(shè)計

由于信號系統(tǒng)的子系統(tǒng)較多，每個子系統(tǒng)的對外接口形式也都不同。比如與ATS 系統(tǒng)可采用以太網(wǎng)接口，使用非涉安的私有協(xié)議。但是CI 和ZC 均屬于SIL4 的系統(tǒng)，針對這類安全至關(guān)重要的系統(tǒng)，很可能只具備采用安全協(xié)議才能進行以太網(wǎng)信息交互的條件。故常見有以下兩種接口方案。

接口方式一：大數(shù)據(jù)平臺分別跟各個子系統(tǒng)接口，子系統(tǒng)接口之間進行進程隔離或者線程隔離。這種方式適合無信號系統(tǒng)維護監(jiān)測系統(tǒng)的工程。優(yōu)點是可靠性較高，單個子系統(tǒng)接口的故障不影響其他接口信息的采集。缺點是接口開發(fā)工作量大，需要單獨跟各子系統(tǒng)接口定制協(xié)議。

接口方式二：大數(shù)據(jù)平臺只跟信號系統(tǒng)維護監(jiān)測系統(tǒng)接口。由維護監(jiān)測系統(tǒng)與各子系統(tǒng)接口，然后維護監(jiān)測系統(tǒng)將其他子系統(tǒng)接口信息轉(zhuǎn)發(fā)至大數(shù)據(jù)平臺。優(yōu)點是接口形式簡單，開發(fā)和部署工作量小，缺點是可靠性相對較差，接口一旦故障則會丟失所有子系統(tǒng)的數(shù)據(jù)。

3 項目實施步驟

針對新建線路的大數(shù)據(jù)平臺部署實施分為以下幾步。

1)項目需求分析：明確本項目需求目標，明確需求特點，尋找需求相關(guān)性。

2)硬件和軟件平臺設(shè)計階段：調(diào)研、評估本項目信號各子系統(tǒng)的業(yè)務(wù)數(shù)據(jù)量、實時性要求和統(tǒng)計分析算法復(fù)雜度，并結(jié)合本項目大數(shù)據(jù)平臺部署方式進行大數(shù)據(jù)平臺服務(wù)器硬件的配置選型和安裝部署設(shè)計。

3)數(shù)據(jù)設(shè)計階段：對本項目信號系統(tǒng)各子系統(tǒng)的輸入的業(yè)務(wù)數(shù)據(jù)，精確到每個字段，進行存儲形式的統(tǒng)一規(guī)范，以及人工識別設(shè)備狀態(tài)與故障的相關(guān)性，人工操作效能（比如司機、調(diào)度員）與若干系統(tǒng)反饋指標的相關(guān)性。

4)室內(nèi)大數(shù)據(jù)訓(xùn)練階段：通過本項目信號系統(tǒng)的仿真系統(tǒng)生成模擬訓(xùn)練樣本數(shù)據(jù)，并對人工識別的數(shù)據(jù)相關(guān)性在室內(nèi)大數(shù)據(jù)試驗平臺上進行驗證試驗。

5)現(xiàn)場大數(shù)據(jù)迭代階段：在現(xiàn)場部署全套大數(shù)據(jù)相關(guān)硬件、網(wǎng)絡(luò)和軟件，初期采用室內(nèi)大數(shù)據(jù)訓(xùn)練的參數(shù)模型進行分析，在實際運營逐步產(chǎn)生較多數(shù)據(jù)后，結(jié)合實際的數(shù)據(jù)對模型參數(shù)進行迭代修正。

4 結(jié)語

在城軌CBTC 信號系統(tǒng)中，得益于車地間和地面的網(wǎng)絡(luò)帶寬大幅改善，可以獲取到大量有價值的數(shù)據(jù)，從而為故障預(yù)測、用戶能力評價、庫存優(yōu)化等任務(wù)提供有利支撐。大數(shù)據(jù)技術(shù)對海量數(shù)據(jù)的快速分析能力讓這些過去低價值的數(shù)據(jù)也能隨時間的逐步積累而挖掘出有效的價值，而且相對于傳統(tǒng)信號系統(tǒng)的部署調(diào)試，大數(shù)據(jù)平臺的部署難度反而更低，同時對既有業(yè)務(wù)系統(tǒng)的影響也降到較低水平。因此可以預(yù)見在未來的新建線路和既有線改造中，大數(shù)據(jù)技術(shù)將會得到更加深入和廣泛的應(yīng)用。