基于私有云平臺的城市軌道交通自動售檢票系統架構及關鍵技術

趙圣娜 張 寧 王 健 張義鑫

(1.東南大學ITS研究中心軌道交通研究所，210018，南京；2.中鐵上海設計院集團有限公司，200070，上海； 3.南京地鐵建設有限責任公司，210024，南京；4.北京城建設計發展集團股份有限公司，100037，北京//第一作者，碩士研究生)

城市軌道交通自動售檢票(AFC)系統，是實現城市軌道交通售票、檢票、計費、清分結算及運營管理等全過程的自動化系統[1]。隨著城市軌道交通線網規模的不斷擴大，AFC系統結構越來越復雜[2]，大客流情況也已成為常態，AFC系統對海量數據(客流數據、交易數據及票務數據等)的高效率存儲、讀寫和計算需求越來越高，后期線路接入的擴展性需求也越來越高。

近年來，云計算作為一種新型的計算模式，被逐漸應用于城市軌道交通系統中，以降低建設與運營成本[3-4]。云計算是一種基于互聯網的計算方式，融合了分布式計算、虛擬化技術、網絡存儲、負載均衡和網絡通信等技術，采用計算機集群構成數據中心，通過整合分布的網絡、存儲和應用軟件等基礎設施資源，使用戶能夠根據工作負載的大小按需獲取網絡上的資源，且不受時空的限制[5-6]。本文在分析國內城市軌道交通AFC系統建設現狀的基礎上，構建基于私有云平臺的城市軌道交通AFC系統架構，并對系統關鍵技術進行探討，為優化AFC系統架構、提高系統資源利用率提供參考。

1 AFC系統現狀

1.1 AFC系統基本架構

GB/T 20907—2007《城市軌道交通自動售檢票系統技術條件》中提出：AFC系統架構分為5個層次[7]。這種架構具有層次分明、安全性高、不受其他線路建設工期影響等優點，已在國內多地采用。其系統結構見圖1。其中，第一層為車票，第二層為車站終端設備(SLE),第三層為車站計算機(SC)系統,第四層為線路中央計算機(LCC)系統,第五層為城市軌道交通的中央清分(ACC)系統。

1.2 AFC系統架構優化現狀

目前，AFC系統多采用“一線一中心”的單線建設模式。隨著城市軌道交通快速發展，運營經驗不斷積累，單線建設模式的不足逐漸顯現：①AFC系統接入節點越來越多，系統結構越來越復雜。②接入新線增加了車站級和中央級設備的采購、維護和保養費用，同時也增加了房屋、電源、人力等資源的費用。③AFC系統承擔了多運營商和多線路的清分任務，故系統應具備數據量大、計算持續及實時反饋等特點[8]；而傳統的AFC系統受服務器性能的限制，無法滿足使用要求。

圖1 AFC系統架構圖

為了彌補傳統AFC系統的不足，不少城市軌道交通結合自身實際情況對AFC系統架構進行了優化。北京地鐵采用了多線共用AFC系統線路中心(MLC)的建設方案[9]。南京地鐵以幾條線路或多個車站組成的區域集合為建設管理單位，構建了基于區域線路中心(ZLC)的線網AFC系統架構[10]。此外，國內很多線網規模較小的城市，如其近期規劃建設的城市軌道交通線路不超過5條，可嘗試通過合并ACC和LCC的方式達到系統優化的目標[11]。上述建設方案在一定程度上精簡了系統架構，但未將車站級系統的優化考慮在內，且無法應對大規模客流帶來的海量數據處理，對海量數據的存儲能力與計算能力存在不足。

2 基于私有云平臺的AFC系統

2.1 AFC系統云部署模式

根據所有權和服務對象的不同，云計算可分為公有云、私有云和混合云。公有云是由第三方擁有和管理，并通過互聯網向普通用戶開放的應用、存儲和其他資源集[12]；私有云是由企業自己構建的專有資源，其企業擁有基礎設施，并可控制在此基礎設施上部署的應用程序。將兩種云組合的部署模式就是混合云。

綜合考慮AFC系統現狀及運營管理需要，可選擇私有云模式。一方面，盡管私有云平臺比公有云平臺需要更大規模的基礎設施，其初始成本較高；但從長遠角度考慮，公有云平臺運營過程中的平均成本逐漸增加，而私有云平臺的平均成本呈現由高變低的趨勢[13]。另一方面，由于私有云平臺的基礎設施由城市軌道交通公司自己擁有并管理，其數據存儲的安全性與可靠性較高；故只需少量的投資，管理部門便可根據業務需要部署私有云平臺架構及定制服務，其部署靈活性較高。

2.2 基于私有云平臺的AFC系統總體架構

基于對當前AFC系統存在的不足以及云部署模式的分析，提出基于私有云平臺的AFC系統方案，其系統結構如圖2所示。

圖2 基于私有云平臺的AFC系統結構圖

在基于私有云平臺的AFC系統中，私有云平臺取代了原系統中的ACC層和LCC層。車站計算機系統直接通過專用通信傳輸系統提供的以太網通道與私有云平臺互連，各車站共享私有云平臺計算機服務器資源池，車站只保留操作終端。通信網采用光纖自愈環網技術對傳輸系統進行網絡級的保護。當光纖切斷時,AFC系統能實時、自行恢復其所承載的業務，保證了傳輸系統的高可靠性。當車站終端設備與SC或SC與私有云平臺之間通信中斷或無網絡連接時，設備可在離線模式下工作，并在本機上保存相關的參數設置。斷網故障期間可通過外部專用設備上傳數據、下載參數；當恢復通信時，AFC系統自動檢測未完成上傳的數據，并自動上傳至私有云平臺。

2.3 私有云平臺架構

私有云平臺由基礎設施層、平臺層、軟件層、安全管理模塊和用戶訪問接口層等5個部分組成，其具體架構如圖3所示。

2.3.1 基礎設施層

基礎設施層是AFC系統私有云平臺的基礎。傳統AFC系統各級基礎設施數量多、成本較大。私有云平臺將服務器、存儲器及網絡等硬件設備集中，組建新的數據中心，并采用虛擬化技術將這些設施抽象為虛擬化資源池，按需為上層應用提供計算、存儲和網絡等服務。這一特色不僅減少了基礎設施數量，降低了成本，而且通過基礎設施的集中建設，為AFC系統的業務整合及統一管理提供了基礎支持，保障了AFC系統的正常運行。

圖3 私有云平臺架構示意圖

2.3.2 平臺層

平臺層是AFC系統私有云平臺的核心層。它通過應用程序接口將調用的底層基礎資源開放給軟件層用戶，并向上層提供業務服務。平臺層按功能不同可劃分為開發測試、部署運行和業務管理等3個子平臺。

開發測試子平臺為用戶提供各類開發及測試工具，以及語言執行環境，便于用戶完成應用軟件的配置、開發、調試等工作。部署運行子平臺主要負責實時監控平臺的各種資源與運行狀態。對于AFC系統的任務請求，特別是多任務或多用戶并發任務請求，部署運行子平臺能自動快速地部署、分配資源，達到自動負載均衡和故障恢復的目標。在開發測試與部署運行子平臺的配合下，業務管理子平臺能高效地實現參數管理、票務管理、清分管理及信息發布等業務功能。業務功能明細如表1所示。在業務管理子平臺內還特別集成了數據挖掘功能，能對隱藏在數據庫中的客流及交易信息等進行統計與分析，為城市軌道交通運營管理提供輔助決策信息。

表1 業務管理子平臺的業務功能明細表

2.3.3 軟件層

軟件層主要提供相關部門辦公和公共信息發布等所需的軟件服務。軟件層通過提供1種統一標準的互連通信方式，來屏蔽各組件間的結構功能差異。軟件層集合了參數管理、票務管理、清分管理、客流分析和數據挖掘等軟件，滿足了網絡環境下業務集成的需求。

2.3.4 安全管理模塊

為保障私有云平臺服務高效安全地運行，需由安全管理模塊提供相應的技術加以支持。在安全管理模塊中，對服務管理保證機制、身份驗證與訪問權限、安全審計等內容作了詳細規定。

2.3.5 用戶訪問接口層

用戶訪問接口定義了各種可能的用戶接口類型，實現了用戶對云平臺服務的泛在訪問。不同級別的用戶根據訪問權限請求服務接入。

3 系統關鍵技術

3.1 虛擬化技術

虛擬化技術在硬件層與上層之間引入虛擬層，將繁雜多樣的物理資源經虛擬化抽象后呈現為虛擬資源[14]。虛擬化技術體系結構如圖4所示。

圖4 虛擬化技術體系結構示意圖

車站服務器、存儲器、網絡等基礎設施資源虛擬化后可不再受終端設備異構性的限制，車站虛擬服務器等虛擬機的數量也可根據實際業務需求靈活配置。因此，在保證計算能效的前提下，在基于私有云平臺的AFC系統中,車站實體設備數量可減少，從而提升了車站設備的資源利用率。

3.2 分布式存儲技術

AFC系統負責城市軌道交通全網運營數據的管理。隨著線網規模的擴大，AFC系統數據量不斷增長，現多采用分布式存儲技術進行數據管理。分布式存儲系統包含了負責管理AFC數據系統的管理節點及負責各類數據存儲的存儲節點。通常情況下，管理節點可同時監管多個存儲節點，管理節點數量的設置由運營管理者決定。各車站數據直接上傳至私有云平臺中，管理節點根據數據類型自動將其分配到存儲節點，各車站數據被集中存儲在私有云平臺中，車站工作人員直接通過終端查詢數據并執行相關操作，而無需知道數據的具體存儲形式與位置。這種存儲方式較好地滿足了AFC系統的實際需求，也實現了運營管理者集中管理的操作需要，具有一定的適用性與可行性。

3.3 負載均衡技術

AFC系統是1個計算密集型的系統。成網運營以后接入私有云平臺的車站數量很大，其終端數據采集到云平臺的清分結算全過程涉及大量數據存儲、備份與計算，尤其在節假日等井噴式客流出現時，對服務器性能更是極大的挑戰。

負載均衡技術充分利用每臺服務器的處理能力，將到達的任務分割為多個小任務；根據運營管理部門的需求制定分配原則，將小任務分配到多臺空閑服務器中處理；待處理完后將各臺機器的計算結果合并匯總，從而得到最終的任務結果[15]。以清分結算任務為例，在運營結束后處理當天交易數據時，交易清算任務將被分配給多個計算節點，當某個節點負載過高而導致該節點清算任務隊列較長時，可及時將該節點上的任務轉移至負載較輕節點上。這樣既減少了閑置資源，又縮短了清結算時間，一定程度上保證了系統的經濟性。負載均衡原理示意如圖5所示。

圖5 負載均衡原理示意圖

4 結語

在城市軌道交通網絡化運營條件下，優化AFC系統架構是提高AFC系統資源利用效率的有效措施與必然趨勢。本文分析了AFC系統基本架構和目前國內城市AFC系統架構優化方案，總結了建設及運營過程中有待完善的方面，在此基礎上提出了一種基于私有云平臺的AFC系統架構方案，以私有云平臺取代ACC系統和LCC系統。對其包含的基礎設施層、平臺層、軟件層、用戶訪問接口層和安全管理模塊進行分析，并探討了所涉及的虛擬化、分布式存儲和負載均衡等關鍵技術。基于私有云平臺的AFC系統架構簡單，資源利用率較高，有助于降低投資及運營成本。

[1] 鄧先平, 陳鳳敏. 中國城市軌道交通AFC系統的現狀及發展[J]. 都市快軌交通, 2005, 18(3): 18.

[2] 邱華瑞, 張寧, 徐文, 等. 城軌交通自動售檢票系統架構體系研究[J]. 都市快軌交通, 2014, 27(2): 86.

[3] 雷定猷, 賈莉, 王娟,等. 基于云計算技術的地鐵自動售檢票系統研究[J]. 計算機應用研究, 2014, 2(2): 480.

[4] 孟存喜. 大數據、云計算在軌道交通工程中的應用需求[J]. 土木建筑工程信息技術, 2015, 7(5): 62.

[5] 吳吉義, 平玲娣, 潘雪增, 等. 云計算: 從概念到平臺[J]. 電信科學, 2010, 25(1): 1.

[6] MOLLAH M B, ISLAM K R, ISLAM S S. Next generation of computing through cloud computing technology[C]//IEEE. IEEE Canadian Conference on Electrical and Computer Engineering. New York: IEEE, 2012: 1.

[7] 全國城市軌道交通標準化技術委員會. 城市軌道交通自動售檢票系統技術條件: GB/T 20907—2007 [S]. 北京: 中國標準出版社, 2012.

[8] 胡宇舟, 范濱, 顧學道, 等. 基于Storm的云計算在自動清分系統中的實時數據處理應用[J]. 計算機應用, 2014(S1): 96.

[9] 李道全, 趙華偉. 多線共用AFC系統線路中心設計探討[J]. 都市快軌交通, 2012, 25(5): 71.

[10] 黎慶, 張寧, 徐鐘全, 等. 城市軌道交通自動售檢票系統區域中心總體設計[J]. 城市軌道交通研究, 2015(8): 71.

[11] 楊承東. 面向智能交通的AFC系統架構研究[J]. 鐵道通信信號, 2013, 49(8): 79.

[12] 吳俊, 徐溟. 公有云服務計費模式比較研究[J]. 電信科學, 2012, 28(1): 127.

[13] 趙小肖. PaaS模式下私有云政務架構設計與實現[D]. 曲阜: 曲阜師范大學, 2013.

[14] ACHAHBAR O, ABID M R. The impact of virtualization on high performance computing clustering in the cloud[J]. International Journal of Distributed Systems & Technologies, 2015, 6(4): 65.

[15] WEI Q, XU G, LI Y. Research on cluster and load balance based on linux virtual server[J]. Communications in Computer & Information Science, 2010, 105: 169.