趙圣娜 張 寧 王 健 張義鑫

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

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

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

1 AFC系統(tǒng)現(xiàn)狀

1.1 AFC系統(tǒng)基本架構(gòu)

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

1.2 AFC系統(tǒng)架構(gòu)優(yōu)化現(xiàn)狀

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

圖1 AFC系統(tǒng)架構(gòu)圖

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

2 基于私有云平臺的AFC系統(tǒng)

2.1 AFC系統(tǒng)云部署模式

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

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

2.2 基于私有云平臺的AFC系統(tǒng)總體架構(gòu)

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

圖2 基于私有云平臺的AFC系統(tǒng)結(jié)構(gòu)圖

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

2.3 私有云平臺架構(gòu)

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

2.3.1 基礎(chǔ)設(shè)施層

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

圖3 私有云平臺架構(gòu)示意圖

2.3.2 平臺層

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

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

表1 業(yè)務(wù)管理子平臺的業(yè)務(wù)功能明細表

2.3.3 軟件層

軟件層主要提供相關(guān)部門辦公和公共信息發(fā)布等所需的軟件服務(wù)。軟件層通過提供1種統(tǒng)一標準的互連通信方式，來屏蔽各組件間的結(jié)構(gòu)功能差異。軟件層集合了參數(shù)管理、票務(wù)管理、清分管理、客流分析和數(shù)據(jù)挖掘等軟件，滿足了網(wǎng)絡(luò)環(huán)境下業(yè)務(wù)集成的需求。

2.3.4 安全管理模塊

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

2.3.5 用戶訪問接口層

用戶訪問接口定義了各種可能的用戶接口類型，實現(xiàn)了用戶對云平臺服務(wù)的泛在訪問。不同級別的用戶根據(jù)訪問權(quán)限請求服務(wù)接入。

3 系統(tǒng)關(guān)鍵技術(shù)

3.1 虛擬化技術(shù)

虛擬化技術(shù)在硬件層與上層之間引入虛擬層，將繁雜多樣的物理資源經(jīng)虛擬化抽象后呈現(xiàn)為虛擬資源[14]。虛擬化技術(shù)體系結(jié)構(gòu)如圖4所示。

圖4 虛擬化技術(shù)體系結(jié)構(gòu)示意圖

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

3.2 分布式存儲技術(shù)

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

3.3 負載均衡技術(shù)

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

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

圖5 負載均衡原理示意圖

4 結(jié)語

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

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

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

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

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

[5] 吳吉義, 平玲娣, 潘雪增, 等. 云計算: 從概念到平臺[J]. 電信科學(xué), 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] 全國城市軌道交通標準化技術(shù)委員會. 城市軌道交通自動售檢票系統(tǒng)技術(shù)條件: GB/T 20907—2007 [S]. 北京: 中國標準出版社, 2012.

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

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

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

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

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

[13] 趙小肖. PaaS模式下私有云政務(wù)架構(gòu)設(shè)計與實現(xiàn)[D]. 曲阜: 曲阜師范大學(xué), 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.