基于私有云平臺(tái)的城市軌道交通自動(dòng)售檢票系統(tǒng)架構(gòu)及關(guān)鍵技術(shù)

趙圣娜 張 寧 王 健 張義鑫

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

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

近年來(lái)，云計(jì)算作為一種新型的計(jì)算模式，被逐漸應(yīng)用于城市軌道交通系統(tǒng)中，以降低建設(shè)與運(yùn)營(yíng)成本[3-4]。云計(jì)算是一種基于互聯(lián)網(wǎng)的計(jì)算方式，融合了分布式計(jì)算、虛擬化技術(shù)、網(wǎng)絡(luò)存儲(chǔ)、負(fù)載均衡和網(wǎng)絡(luò)通信等技術(shù)，采用計(jì)算機(jī)集群構(gòu)成數(shù)據(jù)中心，通過(guò)整合分布的網(wǎng)絡(luò)、存儲(chǔ)和應(yīng)用軟件等基礎(chǔ)設(shè)施資源，使用戶能夠根據(jù)工作負(fù)載的大小按需獲取網(wǎng)絡(luò)上的資源，且不受時(shí)空的限制[5-6]。本文在分析國(guó)內(nèi)城市軌道交通AFC系統(tǒng)建設(shè)現(xiàn)狀的基礎(chǔ)上，構(gòu)建基于私有云平臺(tái)的城市軌道交通AFC系統(tǒng)架構(gòu)，并對(duì)系統(tǒng)關(guān)鍵技術(shù)進(jìn)行探討，為優(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《城市軌道交通自動(dòng)售檢票系統(tǒng)技術(shù)條件》中提出：AFC系統(tǒng)架構(gòu)分為5個(gè)層次[7]。這種架構(gòu)具有層次分明、安全性高、不受其他線路建設(shè)工期影響等優(yōu)點(diǎn)，已在國(guó)內(nèi)多地采用。其系統(tǒng)結(jié)構(gòu)見(jiàn)圖1。其中，第一層為車(chē)票，第二層為車(chē)站終端設(shè)備(SLE),第三層為車(chē)站計(jì)算機(jī)(SC)系統(tǒng),第四層為線路中央計(jì)算機(jī)(LCC)系統(tǒng),第五層為城市軌道交通的中央清分(ACC)系統(tǒng)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2 平臺(tái)層

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

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

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

2.3.3 軟件層

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

2.3.4 安全管理模塊

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

2.3.5 用戶訪問(wèn)接口層

用戶訪問(wèn)接口定義了各種可能的用戶接口類(lèi)型，實(shí)現(xiàn)了用戶對(duì)云平臺(tái)服務(wù)的泛在訪問(wèn)。不同級(jí)別的用戶根據(jù)訪問(wèn)權(quán)限請(qǐng)求服務(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)示意圖

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

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

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

3.3 負(fù)載均衡技術(shù)

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

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

圖5 負(fù)載均衡原理示意圖

4 結(jié)語(yǔ)

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

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

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

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

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

[5] 吳吉義, 平玲娣, 潘雪增, 等. 云計(jì)算: 從概念到平臺(tái)[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] 全國(guó)城市軌道交通標(biāo)準(zhǔn)化技術(shù)委員會(huì). 城市軌道交通自動(dòng)售檢票系統(tǒng)技術(shù)條件: GB/T 20907—2007 [S]. 北京: 中國(guó)標(biāo)準(zhǔn)出版社, 2012.

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

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

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

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

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

[13] 趙小肖. PaaS模式下私有云政務(wù)架構(gòu)設(shè)計(jì)與實(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.