云計算環境下地鐵新型 AFC 系統研究

駱 濱

（昆明地鐵建設管理有限公司，云南昆明 650021）

1 計算技術簡述

1.1 云計算系統

云計算系統在各個行業得到日益廣泛的應用。云計算系統平臺包括云計算、云調度、云存儲、云安全、云監控、云端打印設備和外存儲設備等，兼顧數值處理和數據存儲，是一種集成分布式計算、邊緣計算、網格計算、虛擬化、分布式存儲、分布式設備管理、負載動態均衡功能的系統。云計算系統的外在表現是為客戶提供實時的軟件服務、海量的數據存儲、快速的系統響應、豐富的開發工具等。

1.2 邊緣計算

云計算中心是把相關的基礎層硬件設備通過網絡實行虛擬化管理、動態分配、按需服務，是一個通過分布式技術實現的集中式數據處理中心。隨著云計算的發展成熟，研制與特定行業或者特定的工作需求相吻合的專業云方案就浮上了桌面。邊緣計算是指在分布式的云環境中，將數據和信息、信號等傳輸給距離最短的相鄰節點來處理，并將處理結果以最短的時間反饋給終端用戶。這種節點本身具備信息處理的能力，可以作為一個微型的云計算中心來對待。這種處理方式避免長距離的網絡傳輸，減輕網絡的負擔，減少帶寬的占用，也減輕云計算中心的信息處理量和資源占用，同時提升了用戶的使用體驗。邊緣計算與云計算互為補充、深度協調各種資源的使用和調度，使整個系統的資源利用率更高、負載更為均衡、處理和響應效率更佳、避免網絡擁堵、用戶體驗度提高。

2 現存 AFC 系統的狀態分析

目前昆明地鐵自動售檢票系統（AFC），能夠較好地完成售、檢票的功能，完成票款的清分和資金的劃撥，系統功能完備、數據獨立、邏輯清楚，系統結構如圖1所示。但從昆明地鐵實際使用情況來分析，目前的系統也存在明顯的不足。

（1）層次過多。從第四層到第一層的客流、票卡、設備狀態、統計收益數據等和從第一層到第四層的運營參數、控制命令、時鐘同步等數據都需要層層轉發，整個過程傳輸和轉發環節過多。

（2）設備和數據高度冗余。數據高度冗余，從終端設備（四層）到車站計算機系統（三層）再到線路中央計算機系統（二層）再到清分系統（一層），每一層都保存著重復的應用數據。設備高度冗余，從車站終端設備（第四層）到清分系統（第一層）每層都有服務器、工作站、存儲設備、打印設備等。

（3）功能重疊。從第三層到第一層都存在傳輸、存儲、統計分析、系統數據安全監控、時鐘管理、報表生成、收益管理等功能，使得每一層都需要配置網絡系統軟件、操作系統軟件、數據庫軟件、應用軟件等，整個系統中多處重復軟件使整個系統顯得十分冗雜。

（4）資源利用率低。2019年 7月 （疫情前），昆明地鐵客流量最大的首期工程平均單日運送394 437人次，全線平均客流26 296人次/h，單站平均客流低于1 000人次/ h。線路運營高峰時段斷面客流單站最大值小于18 000 人次。清分系統、線路中央系統、車站等大量計算機設備處于空閑狀態，造成投資浪費。

（5）系統越來越龐大。隨著新線次第完工，AFC系統的設備規模也同步增多。同時維護成本也越來越高。

3 基于云和邊緣計算的 AFC 系統

3.1 總體結構

在充分分析現存的AFC系統結構及優缺點后，提出一個4層的基于云計算和邊緣計算技術的自動售檢票系統（ACE）。在如圖2所示的ACE架構中，剔除圖1中的清分系統、線路中央計算機、車站計算機系統3個層次，增加了多車站邊緣計算節點層（MEC）和云清分中心（CCC）。第四層CCC采用了云計算技術，構建了能夠滿足系統清分功能的清分系統。

3.2 物理拓撲結構

ACE系統包括了云計算清分設備、多車站邊緣計算設備、傳輸速率10 GB以上主干網和車站終端設備。其物理拓撲結構如圖3所示。

3.2.1 云計算清分中心

CCC包括若干物理服務器、萬兆交換機、萬兆路由交換機等核心設備。由云計算系統對物理服務器進行虛擬化分割和管理，產生多臺虛擬服務器，并在此基礎上實現即時響應。當線路增加時，可以根據實際需要實時擴展系統硬件和性能。

3.2.2 地鐵網絡系統

主干網絡采用自愈式冗余網絡雙環形結構，二層組網，車站設備、邊緣計算節點設備和CCC各自組成局域網，局域網采用星形以太網結構。各個局域網采用萬兆路由交換機接入環形網絡，CCC局域網內部采用萬兆交換機相連，其他局域網內部采用千兆交換機相連接。當網絡工作時，若主環出現故障，則備用環路工作，主環進入自愈修復狀態，以保證整個網絡系統正常工作。

3.2.3 邊緣計算節點

邊緣計算節點（MEC）可以看成是1個微縮版的云計算服務節點。1個邊緣計算節點管理和傳輸若干個（圖2中若K= 5，即表示5個站點）站點的數據、命令、時鐘信號，所轄站點的交易數據、設備參數、人臉特征、報表信息等都存儲在邊緣計算節點的計算機系統中，由該系統統一處理和上傳下發。

3.2.4 車站設備

車站設備包括接入主干網的留有冗余萬兆接口的路由交換機以及接入千兆交換機口的自動檢票機、售票充值一體機、人臉識別器、手機刷碼器、票房售票機等，省去了車站計算機及其相關設備。當主干網絡斷開時，車站設備能夠獨立運行并保存數據，當網絡恢復正常時，車站設備可以正常傳輸數據。

3.3 應用功能劃分

由于ACE系統中去除傳統的清分中心和線路中央計算機、車站計算機功能層，增加MEC和CCC功能層，因而有必要對自動售檢票系統的功能進行適度的重新劃分，盡量避免不必要的重復和累贅。

3.3.1 云清分中心功能

CCC保留傳統AFC系統中的清分、參數管理、報表分析、票務管理、密鑰管理、數據交換、異地容災、系統管理等子系統，增加決策支持子系統和人臉比對子系統。同時去除客流監測和設備監控功能。

人臉比對子系統在CCC的人臉中心庫中保留所有線路站點采集的人臉數據、支付方式（銀行卡、微信、支付寶等）和其他必須的輔助信息。CCC人臉中心庫和各個MEC人臉本地庫數據結構完全一致。CCC中的人臉比對功能為全線網提供服務，但并不是所有的人臉比對都在CCC中心庫完成。

將原線路中央計算機系統中的決策支持功能移到CCC中執行，既可以根據數據對于全線網的客流、收益、系統運行等提供分析報告，也可以對某條線路或指定區間、站點提供分析預測報告。

3.3.2 邊緣計算節點功能

MEC主要功能包括軟件更新、數據采集、時鐘管理、客流監控、設備監控、維護管理、人臉比對、數據庫操作、權限管理等。將原線路中央計算機、車站計算機系統中的報表系統和收益管理等功能劃分到CCC中實現。

MEC人臉本地庫保存著MEC所轄站點采集的人臉與支付信息，并實時傳輸到CCC人臉中心庫中保存。若通過手機APP采集的人臉與支付信息，則直接傳入CCC人臉中心庫存儲。當旅客刷臉驗票時，系統在本地庫對人臉信息進行比對，若比中，則支付以后過程結束；否則將信息傳送到CCC中心庫比對，若比中，則將該人臉信息復制到當前MEC人臉本地庫；若未比中，則反饋信息給站點人臉設備。本地人臉數據庫和CCC人臉中心庫都要進行數據定時更新。

3.3.3 車站設備功能

車站設備中增加人臉采集和比對、手機刷碼功能，除去原車站計算機系統中的計算機及其附屬設備，升級交換機性能，其余自動檢票機、自動售票機、票房售票機等設備保留，但需要升級其網絡傳輸性能。

3.4 云架構

3.4.1 云清分中心架構

CCC架構包括業務應用層、系統平臺層、基礎設施層。架構層級如圖4所示。

（1）基礎設施層。該層包括資源池化的基礎設施和云計算管理平臺。如物理服務器、存儲器等物理基礎設備，通過云計算管理平臺的虛擬化管理功能產生一系列的虛擬機，包括虛擬服務器、虛擬存儲器、虛擬網絡等。虛擬機有利于更充分地利用硬件資源，提高設備的使用效率，更好地共享底層物理資源。底層物理設備為系統的正常運轉提供物理支持。

（2）系統平臺層。虛擬化是云計算的核心技術。云系統軟件和云操作系統、通信軟件、云數據庫系統等為應用的實現提供了一個軟件環境。云計算技術通過負載均衡、進程線程調度、數據實時遷移、動態分配、虛擬化、多用戶等功能保證ACE系統功能的及時實現。人臉比對子系統、電源管理子系統和數據備份軟件以線程的形式運行于系統層，以便對來自于ACE系統的請求及時作出響應。該層提供了應用軟件的二次開發平臺、應用編程接口（API）程序開發包，為ACE功能的再次提升和軟件更新提供了基礎環境。智能管理平臺實現對主機、網絡、數據庫、應用軟件、防火墻等的監控、配置、安裝、管理等功能。

（3）業務應用層。該層包括了ACE系統的應用程序接口，系統以桌面云的形式提供服務。桌面云提供與CCC虛擬設備進行數據交互、計算的能力，可以圓滿地完成CCC的工作。桌面云可以根據不同的用戶權限和需求定義不同的應用入口、虛擬數據區和訪問范圍，有利于對不同級別人員的區別管理。

3.4.2 多站點邊緣計算節點架構

MEC架構類似于CCC架構，但規模要小。MEC采用云操作系統。MEC根據所轄站點的多少和客流大小選擇設備的數量和性能。MEC硬件基礎提供的性能要與該節點處理所有所轄站點的數據、命令和人臉比對等的響應時間相匹配。隨著市郊線網的建造，一部分站點離CCC的距離可以達到200多km甚至更遠，MEC能夠對所轄站點的數據就近處理，這極大地減輕主干網絡的傳輸負載，也縮減數據處理的響應時間。

3.5 人臉庫動態更新算法

人臉識別系統是一個分布式二級數據庫管理系統，即本地庫—中心庫管理模式。為了提高人臉識別的效率和釋放無用空間、清理不使用的人臉數據，需要定期對 MEC本地人臉數據庫進行動態更新和數據清理。算法如下：

第一步，對每一個MEC本地庫取一定的時間段天數L，按每天進出站兩次計算，時間段L進出站總數為2×L，作為比較基數；

第二步,取當前人臉數據，若是數據庫尾，則判定為空庫，結束；否則，轉第三步；

第三步，統計時間段L范圍內該MEC所轄站點的該人臉進出站次數T；

第四步，若T /（2×L）≤0.05（小于等于5%），則該人臉信息移到CCC中心庫，覆蓋中心庫中該人臉舊的信息，刪除本地庫該人臉信息；

第五步，在MEC本地庫中，取下一條記錄，若是數據庫尾，則結束；否則，轉第三步；算法結束。

可以對CCC人臉中心庫進行類似的操作，以清理掉長期（例如10年）不使用的人臉數據。通過人臉信息更新，始終保持人臉庫為活躍有效乘客，以減少庫容和提高識別速度。

4 ACE 系統與傳統 AFC 系統比較分析

基于云計算的ACE系統構架是4層結構，比原來的AFC系統構架少1層，這在一定程度上不僅減少設備冗余，也減少數據傳輸的層級。ACE系統既減少了整個系統的硬件設備，也減少了相關的軟件需求。數據存儲由原來的4層存儲減少到新系統的3層存儲。新系統重新劃分了各層級的應用功能，減少了功能重復和累贅，也減少了數據在系統中的傳遞。ACE系統引入了MEC概念，1個多站點邊緣計算節點能夠代替K個車站計算機系統，減少了K套車站計算機系統,增加了一套MEC系統,設備減少50%以上。

隨著線網的擴容，清分中心處理數據的能力也要求同步提高。基于云計算系統的易擴展性，可以通過增加服務器等設備的方式提高云清分中心的處理能力。

云計算系統與傳統系統相比，資源的利用率更高，在云清分中心與傳統清分中心設備數量和性能相當的情況下，相同時間內CCC能夠處理更多的數據。

5 可能存在的問題

經分析ACE系統可能存在的問題有以下幾個方面。

（1）在ACE系統中，站點設備數量K取值的準確性部分決定整個系統的效率。若K的取值太大，則可能使多站點邊緣計算節點的反應速度下降；若K的取值太小，則可能使該節點的設備空閑率增高。

（2）若云清分中心與多站點邊緣計算節點設備性能懸殊，則也會影響到整個系統的處理能力。

（3）云計算系統是產生規模效益的，若某個城市的人口和地鐵規劃（包括輕軌）達不到一定的規模，則要考慮是否存在建設ACE系統的必要。

（4）安全問題。CCC屬于私有云，與傳統清分中心一樣都與外界存在數據與信息的交互，但只要采取必要的安全措施，安全風險是可以防范的。

6 結論

ACE系統運用云計算和邊緣計算技術，使整個系統總體投資適度減少。ACE系統比傳統AFC系統層級更少、設備規模降低、各層功能避免重疊，整個系統更加精簡和運行流暢。ACE系統中融合了人臉比對系統，提出了人臉數據庫的建庫模式和動態更新算法，使系統功能更加完備，符合地鐵機電技術發展的趨勢和方向。ACE系統是一個結構精簡、技術先進、性價比高的地鐵自動售檢票系統，比傳統AFC系統更具優勢。

若新建地鐵線路直接采用ACE系統建設，則性價比較高；若對于既成線路進行改造，則會有一定的工程量，需要慎重考慮其性價比。