郭弘倩，南 迪

（1.國家知識產權局專利局專利審查協作天津中心，天津 300304；2.中國鐵路設計集團有限公司，天津 300308）

隨著國內對“互聯網+城市軌道交通”戰略的推進，云計算、大數據等信息技術已逐漸成為軌道交通發展的趨勢。城市軌道交通由運營生產中心、企業管理中心和乘客服務管理中心組成，建立一個涵蓋安全生產、內部管理和外部服務等多領域的大數據平臺，也是當前智慧城軌系統的需求。

傳統城市軌道交通安全生產業務采用基于傳統物理服務器分散隔離式部署模式建設，造成硬件資源利用率嚴重不平衡。隨著各地城市軌道交通線網快速發展，業務系統分散部署和物理隔離的模式已逐漸無法滿足資源集中管理，高密度數據交換等深層次的資源、數據共享需求。

采用云架構建設城市軌道交通信息化系統，構建服務器、存儲、網絡等資源池，通過對城軌業務系統之間的橫向融合和各線路間信息資源的縱向融合，最終可實現城市軌道交通的全方面融合、全方面的資源共享。

1 當前技術發展現狀

信號系統作為安全生產網的重要組成，也是保證城市軌道交通行車安全的基石。信號系統主要由列車自動防護（Automatic Train Protection，ATP） 、列車自動運行（Automatic Train Operation，ATO）、 列車自動監控（Automatic Train Supervision，ATS）和聯鎖4個子系統組成，共同完成列車自動控制功能?？紤]系統功能定位和設備選型，ATS子系統具備納入云平臺條件。

根據功能定位，ATS系統應設置于IaaS層，即可任意部署和利用云平臺的處理、存儲、網絡等計算資源部署與運行操作系統和應用程序等各種軟件，但不可操作云平臺管理系統，保證云平臺上各安全生產業務系統的相對獨立性和安全性。

ATS主要實現線路/線網的運營監控，運行圖和列車時刻表編輯和根據計劃組織全線路/線網的統一調度，同時可向PIS、ISCS、PA等系統傳輸列車運行信息。相較于傳統“信息孤島”模式的系統架構，ATS子系統可利用云平臺實現安全生產數據交換，同時借助大數據平臺為內部管理網和外部服務網提供一些有用信息如列車正晚點信息、列車時刻表、運營數據等，對于城軌的建設者、運營者和使用者均有創新意義。

2 云平臺部署原則

ATS納入城軌云平臺時，既需要考慮ATS系統與其他業務系統實現效率最大化的信息交換共享，又必須保證信號系統對安全性的要求。本節結合信號ATS子系統與云平臺接口的設計要求及傳統ATS子系統部署原則進行分析。

2.1 ATS子系統與信號安全系統的接口設備

信號系統網關計算機，作為ATS子系統與信號安全系統的接口設備，實現ATS子系統邏輯數據與信號安全系統邏輯的交互，為保證云平臺與信號安全系統的隔離需求，ATS子系統網關計算機不納入云平臺部署及管理。

2.2 ATS子系統與非信號專業接口設備

云平臺建設過程中，多專業共用云平臺可最大限度地實現云平臺的資源利用率。由于各個專業均納入云平臺部署及管理，ATS子系統與非信號專業的接口設備可納入云平臺部署及管理。

2.3 ATS子系統車站設備

ATS子系統車站設備主要包括現地控制工作站和ATS車站分機。結合考慮中心故障后，保留車站降級模式功能的設計需求進行分析：在控制中心故障后，ATS子系統優先使用站控模式進行運營組織，ATS車站分機借助現地工作站實現中心故障后站控模式的運營能力。由于部分廠家采用非通用服務器/工作站的方式部署ATS分機，暫不建議將其納入云平臺部署。當中心ATS系統、車站分機均故障時，現地控制工作站作為聯鎖控顯機（上位機）直接對聯鎖主機進行控制命令輸出，因此也不建議將現地控制工作站納入云平臺管理。

2.4 ATS系統網絡

納入云平臺后，中心級ATS系統網絡需納入云平臺，車站級網絡可納入云平臺也可采用自組網方案。當采用自組網方案時，車站ATS獨立組建光纖環網，在中心通過安全隔離設備（如網關）接入云平臺網絡。

3 系統架構分析

按照國內武漢、呼和浩特等在建或已開通的城軌項目經驗，目前信號ATS系統納入云平臺主要思路是“中心上云，車站不上云”，即中心ATS系統納入云平臺，而車站聯鎖、ATP/ATO及站級ATS系統保留傳統架構。

云平臺對CPU的調度是以邏輯核為單位的，邏輯核是將物理核通過超線程（HT）技術模擬成2個邏輯核心，每臺計算節點服務器承載vCPU數量計算方法如下：vCPU數量＝（CPU數量×每顆CPU物理核數量×2－虛擬化層占用邏輯核數量）×虛擬化復用比。

虛擬化復用比是一臺服務器上虛擬機的vCPU的總數相對可用邏輯核數（不包括虛擬化層占用邏輯核）數量的比率，標稱的是服務器上邏輯核復用的程度，一般情況下推薦復用比為1.0，不同應用場景下復用比推薦如表1所示。

表1 虛擬機應用場景對照Tab.1 Comparison between the application scenarios of virtual machines

以一條標準線路為例，對系統配置進行分析，系統配置如表2所示。

表2 系統配置示意Tab.2 Example of system conf iguration

3.1 云平臺硬件選型

目前城軌云平臺處于發展的起步階段，仍以硬件云為主，存儲資源主要由整合服務器搭建完成。目前云平臺常用的服務器主要有：刀扇式服務器、機架式服務器以及上述2種服務器組合的形式。

方案1：業務服務器&數據庫服務器全部采用刀片；

方案2：業務服務器&數據庫服務器全部采用機架；

方案3：業務服務器采用刀片，數據庫服務器采用機架。

刀片式服務器與機架式服務器面對不同場景、需求，各有優勢。在城軌云平臺的體系下，考慮到多種業務的硬件融合，刀片式服務器的高密度分布和計算能力更適合業務服務器，而數據庫服務器本身用于存儲的是本專業的重要運營數據，考慮使用機架式服務器作為選擇。綜上，ATS系統推薦采用方案3：應用服務器及接口服務器采用刀扇式服務器，數據庫服務器推薦采用機架式服務器。

3.2 計算資源架構

計算資源包括服務器（應用服務器、數據庫服務器、接口服務器）、工作站（調度員/調度長工作站、時刻表/運行圖編輯工作站、維護工作站）。

中心級服務器硬件（應用/接口服務器采用云主機，云管從虛擬資源池統一分配計算資源，數據庫服務器考慮信號系統特殊性采用裸金屬服務器）納入云平臺管理，軟件由ATS系統提供，保留ATS系統既有架構不變。雖然云平臺本身具有冗余和備份功能，但不能滿足ATS系統主/備無擾切換需求，因此ATS系統切換邏輯由主/備雙套的ATS系統軟件完成。此外，云平臺還可以為同一專業多條線路的數據庫服務器提供共享存儲空間，提高服務器利用率。

培訓系統相關設備一般僅在培訓時開機，可以考慮將其納入云平臺，使用時通過云管為其分配相應的虛擬機分區即可。也可以保留其全套硬件，作為信號系統初期調試的備份系統使用。

根據線路情況，ATS系統業務資源配置推薦如表3所示。

表3 計算資源池資源需求Tab.3 Resource requirements of the computing resource pool

其中虛擬機損耗為5%，虛擬化復用比采用1.5。另外，考慮業務高可靠（HA），根據經驗，需要預留30%資源支撐HA。按照上述業務資源需求及計算公式，具體物理服務器資源如表4所示。

表4 計算資源池服務器配置Tab.4 The conf iguration of servers of the computing resource pool

行調工作站、時刻表編輯工作站納入云平臺，可納入桌面云系統直接管理，也可參照服務器上云方案僅硬件上云，在云主機提供的虛擬機中安裝相關軟件。需要注意的是，由于上述工作站直接參與列車調度信息交互，上云時應考慮云平臺安全完善度等級與ATS系統保持一致，即滿足SIL2級安全完善度等級的要求。由于維護網與車站級設備共同接入維護網，不建議中心ATS維護終端上云。ATS系統云桌面資源配置推薦如表5所示。

表5 計算資源池云桌面需求Tab.5 Cloud Desktop requirements of the computing resource pool

考慮到工作站數量較少、硬件要求較低，為實現資源云化、整合硬件數量的需求，因此配置服務器時，一般采用多個專業工作站計算資源共同整合的模式。根據經驗，在考慮虛擬機損耗、虛擬化復用比按1.5設置的情況下，一臺云主機可同時承擔90個vCPU的計算能力。

3.3 存儲資源架構

存儲資源主要包括服務器/工作站自身存儲和運營數據存儲，業務存儲資源采用FC SAN架構，各業務服務器雙歸屬到兩臺FC交換機，FC交換機分別與存儲設備互聯，架構如圖1所示。

圖1 城軌云平臺存儲架構示意Fig.1 Storage architecture of the urban rail cloud platform

3.4 網絡資源架構

如圖2所示，ATS系統通過云平臺接入交換機和云平臺核心網交換機實現與本系統及其他系統的信息傳輸及交換。為簡化網絡部署，提高網絡可靠性，多臺接入交換機采用堆疊技術虛擬化為1臺。

圖2 城軌云平臺網絡架構示意Fig.2 Network architecture of the urban rail cloud platform

為保證ATS業務帶寬，推薦每臺接入交換機采用10 G鏈路聚合與核心交換機互聯。

3.5 信息安全防護

《網絡安全等級保護測評要求 第2部分：云計算安全擴展要求》中明確提出：在云計算環境中，應將云服務方側的云計算平臺單獨作為定級對象定級，云租戶側的等級保護對象也應作為單獨的定級對象定級。

云計算安全要求應涵蓋物理和環境安全、網絡和通信安全、設備和計算安全、應用和數據安全、安全建設管理和安全運維管理等內容。

基于上述準則，在本方案中，云平臺作為單獨的定級對象，由云平臺廠商提供等級保護技術建設及等級保護測評服務；ATS系統作為單獨的定級對象，由專業安全廠商提供等級保護安全建設及等級保護測評服務。

目前城軌云平臺還是以硬件云為主，控制中心云平臺通過設置核心交換區來實現中心各業務系統之間的數據交換。為保證信息安全，在核心交換區的交換機上可以旁掛防火墻和入侵檢測等設備。中心級ATS系統納入云平臺后，ATS系統與其他系統接口由硬件網絡接口變為邏輯接口，ATS系統內部架構保持不變，站段級ATS系統通過接入交換機接入中心級ATS系統。

信號系統和云平臺均應按照信息安全等級保護三級進行建設。

4 工程建設中需注意的問題

本文分析了ATS上云方案，但對于信號ATS系統是否上云目前還處于百家爭鳴階段，各類工程建設規范也并沒有強制性要求ATS系統納入云平臺。在實際工程運用時，不論是建設單位、運營單位還是設計單位，應結合不同線路規劃及投資情況考慮云平臺整體架構是否有必要將ATS系統納入云平臺，同時也應知曉ATS上云后，相比傳統架構需額外注意如下的問題。

1）ATS系統屬于信號系統的核心組成部分，一旦控制中心因火災、地震等災害中斷勢必導致行車中斷，考慮極端場景下云平臺宕機場景，根據線路重要程度可考慮設置災備中心以應對主用中心癱瘓時信號行車調度指揮的可用性和功能完整性，并做好應急預案。

2）上云后，ATS系統需通過云平臺網絡接入中心級ATS系統，在信息安全方面云平臺必須整體實現三級防護。

3）ATS采用冗余機制，可實現主/備系統的無擾切換。目前云平臺虛擬機間的熱遷移功能（HA）因需要在主資源池故障時重新啟動一套同配置的虛擬機，不具備無擾切換能力，因此ATS主/備系統需同時分別占用云資源，并由信號系統軟件自行判斷切換時機。

5 總結與展望

國內的軌道交通業自20世紀80年代開始孕育，隨著線路長度、機車數量、客運數量等指標不斷攀升，現己成為世界最大的城市軌道交通建設市場。在不斷增長與建設的背景下，軌道交通作為城市交通的重要組成部分，其智能化是智慧城市、智慧交通的重要組成。在《國家中長期科學和技術發展規劃綱要(2006-2020年)》中指明，“高速軌道交通系統”和“智能交通系統”是優先主題。軌道交通智能化系統是以多系統為基礎的綜合平臺，是現代軌道交通發展的必然趨勢。《智慧城軌發展綱要》也提出：建設一個自主可控、功能完備、技術領先、安全可靠、可持續發展的城軌云與大數據平臺，實現對城軌業務應用的統一部署承載，資源動態分配，統一開發運營部署運行環境，為城市軌道交通各類信息系統應用提供服務，助力城軌智能化、智慧化發展。信號系統作為涉及行車安全的重要系統，系統運行數據是作為現在軌道交通大數據平臺的重要組成部分。信號ATS系統作為列車行車調度指揮的“大腦”，存儲著大量線網列車運營數據，對于將其融合到線網大數據云平臺，為實現城軌智能化、智慧化有著非常重要的意義。