城軌云平臺上AFC建設的模式分析及選擇

嚴浩毓

（太原軌道交通集團有限公司，山西 太原 030032）

1 城軌云平臺上AFC建設的模式分析

1.1 區域線路中心的模式

AFC（自動售檢票系統）是一個自動化系統，可基于計算機、通信、網絡和自動技術執行車票銷售、票務檢查、發票、統計、計費、管理和分類的全過程。隨著信息通信技術的發展，AFC系統在城市軌道交通的票務系統中得到了廣泛的應用。

在同時建設多條新線路和改造及擴展現有AFC系統的背景下，如果更多的多軌線路繼續采用獨立的單線建設模式，將不可避免地帶來高昂的建設成本、分散的管理和較低的成本。

為了滿足運營公司對多線和統一管理的需求，ZLC（區域線路中心）的模式可以統一線路中心的建設、運營和維護標準，避免因多個集成商在不同時期的建設、運營和維護而造成的協調問題和技術障礙，從而提高運營、管理和維護的效率，降低成本。其主要優勢如下：①降低多線路的建設成本。在線路網絡快速建設發展的情況下，可以降低建設許多新線路的成本，同時避免了系統的重復建設，緩解了政府的財政壓力。②實現集中管理，統一協調。在大規模進行地鐵建設時，區域線路中心網絡集中管理模式可以使運營管理更加高效、有序、科學。③提高運營管理及維護的效率。當大規模構建有線網絡時，如果在區域級別上進行日常的運營管理和維護，則可以降低運營和維護成本并提高運營效率[1]。

1.2 多線路中心模式

AFC系統通常采用具有一定程度可擴展性的標準5層體系結構系統。線的中心是AFC軌道交通系統的核心部分。從ACC（軌道交通自動售檢票清算管理中心）的計費中心接收訂單，并將ACC請求的數據發送到AFC。將訂單發送到SC（車站中心），并接收SC發送的數據。從一條線路的市區到一條共享線路的市區的過渡，其將不可避免地導致AFC系統的靈活架構。

1.2.1 設置多線路中心

多線路中心在同一運營商的管轄范圍內共享線路資源，因此可以在ACC層中處理線路之間的信息。在每個運營商管轄的多線路中心的基礎上，它可以被視為小型的分揀中心，可以對其管轄范圍內的線路上的操作、票證和數據分類進行補充管理，從而節省資源，并提高經濟效率和安全性系統[2]。同時，ACC是不同的操作員，不再有特定的行，因此簡化了分類模型并減輕了ACC的工作壓力。

1.2.2 合并多線路中心和清分中心

在計劃中的短期和長期路線很少（通常少于6條）的城市中，由于有一名操作員且排隊的車站較少，因此分類和核算壓力并不大，建立基于經濟和實踐原則的集成系統是可能的。ACC系統的多線中央系統，每條線路上的站計算機系統通過線路匯聚設備直接或間接連接到多線路中心，用于獲取整個鏈接網絡的所有交易數據，并負責管理線路操作以及清除和結算卡以及多合一線路。集成架構模型改善了系統，在一定程度上提高了系統效率，節省了構造和維護資源，并限制了線路接口的邊界。

1.2.3 多線路中心系統的功能定位

在網絡運營、節省建設投資、產品標準化等基礎上，提出了多線路中心。多線路中心的引入將導致每個ACC級別的多線路中心的功能發生變化。線路中心和車站中心功能相互作用的準確定義是提高運營效率和穩定性的前提。

多線路中心系統已成為軌道交通網絡發展中的一種趨勢，對多線路中心的組成、功能布局和施工計劃的說明是施工的基礎。根據功能需求，分析了多線路中心的組成，引入后AFC系統的結構變化以及使用ACC進行功能劃分[3]。最后，結合北京和深圳的設計案例，總結了各自設計模式的特點。為隨后的多線路中心城市化提供提示和參考，每個城市都可以根據自己的建筑計劃和系統架構選擇合適的建設計劃。隨著AFC系統中在線支付方式的逐步推廣，第二票務服務平臺與多線路中心系統之間的安全內部通信需要進一步研究。

1.3 多線路中心加車站中心上云模式

作為對AFC系統現有架構進行的國家改革的一部分，通過分析北京地鐵和廣州地鐵采用多線公共線路中心的計劃，提出了區域性建議。最終提出了一種基于云策略部署AFC系統的創新方法，該方法大大減小了AFC系統的大小。在對城市軌道交通自動售票系統技術條件進行分析的基礎上，研究自動售票系統的組成、結果和布局，詳細分析了自動售票系統的5層布局并提供了每個層系統的最終模塊組成。該系統彌補了現有AFC維護管理系統效率低下的問題，使配置維護管理更加高效和便捷[4-6]。

2 基于城軌云平臺的AFC管理模式方案選擇

AFC系統部署在城軌云平臺上主要有3種模式選擇的方案，即保留各線路中心模式、多線路中心模式和多線路中心加車站中心模式。這3種方案是針對不同城市不同的建設投資方式而產生的，如何針對不同的地鐵建設投資方式選擇合適的基于城軌云平臺的AFC系統對于地鐵線路的決策者和投資方而言無疑是一種博弈與挑戰。

2.1 模式選擇的依據

近年來很多城市開啟了大規模的基礎設施建設項目，眾所周知，基礎設施建設對于一個城市的財政而言無疑是一只巨大的“吞金獸”。由于其投資金額巨大、項目建設周期長、項目回報周期長，很多地方政府的財政負擔增大，政府負債率偏高，甚至有些地方政府的負債率已經超出了國家的允許范圍。城市軌道交通對于地方政府就屬于投資金額巨大的基礎設施項目，對于很多符合地鐵修建條件的城市來說都不堪重負，為了減輕財政負擔和不增加政府負債率，很多城市選擇使用PPP（Public-Private Partnership）模式來投資建設城市軌道交通線路，即政府和社會資本合作。使用該模式可以減輕政府的財政壓力，但對于城市軌道交通線路的建設來說，社會資本方成立的項目公司注重的是成本的節約和后期運營過程中對運營數據的準確掌握，而代表地方政府的軌道公司則注重有效管理整個城市軌道交通線網的運行。而AFC系統恰恰是社會資本方和政府方關注的焦點，因此必須通過合理的理論為基于城軌云平臺的AFC系統的管理模式選擇提供有力的支撐。

2.2 模式選擇的過程分析

2.2.1 邏輯維分析

在模式選擇分析中首先要明確問題的性質，特別是在問題的形成和規劃階段，搞清楚要研究的是什么性質的問題。對于該模式選擇的問題，可以明確不同的模式在建設過程中會產生不同的投資額度，其中保留各線路中心的模式所產生的的投資是最大的，由于城軌云平臺本身已經提供了足夠的計算和存儲的資源池，各線路再建設相應的LC（線路中心）時顯然會增加成本的支出，其所包含的車站中心同樣在工程建設的成本之中。MLC（多線路中心）上云模式對于線路投資方來說相應減少了成本的投資額度，但是車站中心的建設一樣不可避免地需要產生硬件采購的成本。多線路中心加車站中心上云模式可以在最大程度上降低線路投資方的成本投入，由于MLC和SC全部部署在城軌云平臺上，由云平臺進行統一納管和統一調度資源，各線路只需要把相對應的軟件部署使用容器或者虛擬機的方式部署在云平臺上，對應的工作站使用云桌面的方式進行監控和控制管理即可。但是多線路中心加車站中心模式對于各線路可能造成無法對自己所運營的線路進行獨立的改造和升級，給線路運營商獨立自主的運營帶來挑戰。

2.2.2 時間維分析

從時間維的角度去進行分析，3種不同模式的建設周期從保留各線路中心模式到多線路中心上云模式再到多線路中心加車站中心上云模式依次減短。由于保留各線路中心模式的硬件設備最多，所占用的硬件機房的面積最大，因此該模式在建設過程中所花費的時間也是最多的。就目前的國際形勢而言，全球的芯片產能緊缺，所有的服務器硬件的芯片到貨時間基本為6～12個月，更多數量的硬件代表著更多時間的消耗。而多線路中心加車站中心上云的模式由于統一使用城軌云平臺的硬件資源，故其所花費的系統建設時間相應也是最短的。

2.2.3 知識維分析

在AFC系統的網絡構建過程中，涉及的接口種類多，結構復雜。外部接口主要體現在整個系統拓撲結構的兩端，最低端是車站終端設備讀卡器與各種票卡的接口，包括地鐵單程票、各類紀念票和城市一卡通票。頂部是分揀系統和城市智能卡系統之間的分揀和對接接口。內部接口主要是結構之間的數據接口，包括分揀系統與線路中心的接口、線路中心與車站系統的接口以及車站系統與終端設備的接口。同時，AFC系統中存在多條線路的內部通信節點較多，物理網絡結構也較為復雜。因此，基于網絡的AFC系統涉及的數據類型多、結構復雜、規模大、傳輸節點多，而這些數據與地鐵票務管理和排序統計相關，其重要性不言而喻。這樣，在AFC系統網絡建設過程中，如何有效保證系統和數據的完整性與安全性就顯得尤為重要。城市軌道云平臺在系統安全中使用防火墻和網關，可以有效隔離潛在的系統安全風險。對于互聯網票務業務，在使用云平臺時，端口白名單方式確保互聯網票務業務不受影響的同時，最大限度地減少對外網的接入，最大限度地保護整個系統的安全。

3 模式選擇的結果

選擇的模式為多線路中心加車站中心上云模式。軟件是AFC系統建設的核心。需求的統一通過軟件實現，主要目的是保證各線網中各條線路AFC系統的互聯互通，為各條線路的網絡化運營打下基礎。同時軟件系統還要保證AFC系統操作規則、票務規則以及相關業務處理流程的統一，模塊間數據格式、各組件和接口的統一，為整個線網互聯互通、各條線路無縫接入提供了技術基礎；密鑰管理系統的輪換和票卡的應用統一，保證了各線路的票卡在線路間能夠正常使用[7]。

3.1 關鍵模塊的統一

在設備的設計和生產中，不同的系統集成商都有各自的特點。所有設備模塊相互兼容的要求對于系統集成商比較困難，這樣并不利于招標工作的開展，而且減少了設備的選擇。但對于一些關鍵模塊，如主控、讀卡器等，應制定統一的軟硬件數據接口和技術規范，可以增加常用部件的數量和種類，同時降低維護成本，減少備件種類和數量。

3.2 用戶界面的統一

AFC系統的用戶界面一般分為面向乘客的操作界面和運維人員的操作界面。在線網運營中，用戶界面需要具有統一的要求。面對乘客和維修人員的相關軟件界面需要有統一的顯示規范，如界面的布局、界面元素的大小和顏色、錯誤提示信息等，都需要統一的操作流程。針對各類用戶，保證不同系統集成商開發的系統在操作和信息獲取上沒有差異，不需要有重復熟悉的流程，降低培訓成本。

3.3 新線AFC系統的接入調試

在地鐵建設大規模進行的過程中，一定會遇到新建線路接入線網系統的問題。新線AFC系統的接入和調試是一個非常復雜的過程。它不僅要保證新線AFC系統的各種功能的驗證，還不能影響既有線的正常運營。同時，接入調試還包含大量的培訓工作，測試方案復雜，耗時較長。為確保新線路接入調試工作順利完成，達到巡檢系統和維修設備的目的，要求一方在調試過程中牽頭，多方配合，提前謀劃，精心準備，制定詳細的實施方案并嚴格執行。同時，要明確各調試階段的工作重點，劃分調試的定性和定量風險，確定工作的優先級別，區分風險和要求。

太原軌道交通2號線AFC系統主體部署在太原軌道交通城軌云平臺中。在控制中心云平臺中部署LC系統，包含LC數據庫服務器、LC應用/交易服務器、LC通信服務器，均采用雙機部署，由城軌云平臺提供對應的計算、網絡、存儲、安全資源，并且為了保證可靠性，LC系統中同業務的雙機由云平臺的云主機反親和性配置功能，保證處于不同的宿主機中；控制中心有城軌云平臺為AFC系統提供云桌面服務，實現工作站的云化部署；車站部署SC系統，每個車站中部署1臺SC虛擬機，承載在城軌云平臺車站云節點中，可以通過控制中心云平臺實現統一管理。

太原2號線清分中心與互聯網售票系統也采用云化部署模式，并且在傳統IaaS服務的基礎上，采用了PaaS服務的形式對業務系統進行了支撐。通過城軌云平臺中的容器服務與微服務治理等功能，保證了互聯網售票系統面對海量數據并發請求的高效響應。