城市軌道交通自動售檢票系統區域中心總體設計＊

黎 慶 張 寧 徐鐘全 王 健

（1.南京地鐵建設有限責任公司，210024，南京；2.東南大學智能運輸系統研究中心，210018，南京；3.北京全路通信信號研究設計院有限公司，100073，北京∥第一作者，教授級高級工程師）

GB／T20907—2007《城市軌道交通自動售檢票系統技術條件》中提出：自動售檢票（AFC）系統采用標準五層構架體系［1］。五層構架體系是根據我國國情和城市發展現狀，綜合考慮了城市軌道交通建設和運營的特點（如票種設置豐富、線路多而復雜、與城市一卡通兼容等），具有一定的可伸縮性［2－3］。同時，隨著運營經驗的豐富和相關技術的進步，運營商意識到AFC 系統的架構體系需符合城市自身特點。在考慮未來線網規模、管理體制、系統升級改造、滿足運營管理需求的基礎上，對現有的五層架構體系進行了一定程度的拓展，以提高運營效率，節約建設、運營成本，使系統更好地適應并滿足線網網絡化運營帶來的種種需求［4］。例如北京地鐵提出的多線公用 AFC 系統線路中心［5］、南京地鐵提出的AFC 系統區域中心［6］等。本文對城市軌道交通AFC 系統的區域中心（ZLC）總體設計及功能設計進行探討。

1 ZLC總體設計

城市軌道交通AFC 系統ZLC 是面向城市軌道交通線網的區域化管理而提出的，旨在解決一定規模的線網內相關各線路獨立運營所帶來的運營管理復雜、維修調配不便，線網建設發展帶來的線路升級改造對運營產生的影響，以及新老線路間接口不統一帶來的一系列問題。其業務需求如下：

（1）網絡化運營下對區域范圍內車站實現統一運營、統一票務、統一維修管理；

（2）統一線路內部技術標準、接口標準，滿足新建或改造項目的接入（例如延伸線的接入）；

（3）減輕清分中心（ACC）日常運營壓力，同時為ACC 升級改造確定前提條件；

（4）為后續項目（如控制中心）的建設提供參考樣本。

基于以上業務需求，ZLC 建成后應能作為AFC 系統的核心部分，實現對AFC 系統運營、票務、收益、維修等的集中管理功能。ZLC 可收集、處理系統內各類數據，制定、維護系統各類參數，接收、下達系統各類指令，接受ACC的統一管理并提供高度的安全機制和嚴格的操作規程；同時，通過ACC實現本區域與城市軌道交通網絡其它區域以及城市公共交通一卡通之間的結算。在線網中設置ZLC 的AFC 系統架構如圖1所示。

圖1 設置區域中心的AFC 系統架構圖［3］

根據對ZLC 業務需求的分析，ZLC 層位于ACC層與SC（車站中心）層之間，依據AFC 系統建設實際情況，該層可獨立設置ZLC 或設置ZLC／LC（線路中心）共存模式，以便AFC 系統由線路管理過渡到區域管理。ZLC 的設置對原先布置與LC的清分管理、運營管理、票務管理、收益管理、維修管理、數據管理、報表管理等功能與其對應管理主體都需做出相應變動。ZLC 通過統一交互接口實現不同車站或線路的接入，ACC 通過 ZLC 與SC 及終端設備進行數據交換。ZLC 系統的核心由實時數據庫和關系數據庫組成。其中，實時數據庫用于處理在線更新的快速變化的數據及具有時間限制的事務處理，如設備／客流實時監控等；而關系數據庫建立在ZLC 各類數據集合的基礎上，通過不同軟件模塊實現如系統管理、網絡管理、報表分析等分析和管理功能。ZLC 硬件部署的核心是中心數據庫集群與交易處理集群的設置。其中，交易處理集群實現對ZLC所轄車站交易數據收集、分析、處理的支持，并將處理后數據發送至ZLC 數據庫集群；ZLC數據庫集群收集、分析、處理ZLC 各類綜合數據（如收益數據、運營數據、清分數據等），為ZLC 各類功能的實現提供支持。以南京地鐵為例，ZLC 總體規劃及系統硬件部署如圖2、圖3所示。

2 ZLC功能設計

根據ZLC 的總體規劃，ZLC 系統可以劃分為核心業務后臺、核心業務前臺和運營支持與分析三大功能模塊。

2.1 核心業務后臺

核心業務后臺包含通信管理、數據管理以及時鐘管理3個模塊，是核心業務前臺與支持分析系統的基礎，保證系統內部所有數據的傳輸、解析、審核、核對、備份以及安全等。

2.1.1 通信管理

系統將整個通信系統分為消息接入模塊和消息處理模塊。消息接入模塊接受來自內部和外部系統的消息報文，然后轉由消息處理模塊處理。

消息接入模塊主要提供通信服務，包括消息報文的接受和發送，分別由通信服務模塊和通信客戶模塊來完成。通信服務模塊接受外接系統的連接請求，建立通信連接，接收消息請求報文，發送給消息處理模塊，然后從消息處理模塊接收應答報文，發送到外接系統；通信客戶模塊向外接系統發送消息請求和接收外接系統的消息應答。

消息處理模塊接受來自外部和內部接入模塊的各種消息，進行業務處理后，形成應答報文發送給外部和內部系統。

2.1.2 數據管理

系統的數據管理包括數據傳輸、數據解析、數據審核、數據核對、數據聚類、數據連續性檢驗以及數據安全。

圖2 ZLC 系統總體規劃

圖3 ZLC 系統硬件部署

ZLC 系統的數據傳輸可分為實時通信傳輸與文件傳輸。通過實時通信傳輸，ZLC 實現區域內SC、車站設備（SLE）以及區域外部ACC、LC 之間的實時通信（比如設備事件、設備工作狀態、客流信息、監控命令、車站模式狀態、控制命令等）。實時報文采用CRC32算法來驗證報文中的數據有沒有發生丟失或被篡改，確保數據傳送過程中的數據安全及完整性。實時通信傳輸采用CORBA（公共對象請求代碼體系結構）技術開發實現，部署在接入服務器上。ZLC 系統的文件傳輸包括FTP（文件傳輸協議）的服務端程序和客戶端程序兩個部分。ZLC 系統向SC 系統提供FTP服務，SC 系統通過實時通信傳輸平臺向ZLC 發送FTP 登錄申請報文，獲取FTP服務的用戶名和密碼等信息后，登錄ZLC 的FTP服務器并主動向ZLC 上傳或下載文件。同樣，ACC系統向ZLC 系統提供FTP服務，ZLC 系統通過實時通信傳輸平臺向ACC發送FTP登錄申請報文，獲取FTP 服務的用戶名和密碼等信息后，登錄ACC 的FTP服務器并主動向ACC 傳輸或下載文件。

在數據傳輸完成后，ZLC 對所收集的數據進行處理，根據數據的類型及用途進行實時或批量地處理，以滿足系統監視、運營管理及決策分析的需求。同時，ZLC 系統需對數據進行審計，以檢查原始數據的真實性、完整性等。通常對于每種車票交易類型的數據一方面通過設備寄存器進行數據累計，另一方面以交易數據的形式存在，兩種數據均上傳到ZLC。ZLC 對兩種數據進行相互核對，檢查系統中是否存在非法數據。通過對收集數據、審查數據的核對，檢查收集數據、審查數據的一致性，檢查系統是否存在數據的缺失。ZLC 對數據的核對分為三級，分別為 ZLC／ACC 核對、ZLC／SC 核對以及SC／SLE核對，保證交易文件處理結果的準確性。

2.1.3 時鐘管理

AFC 系統以ACC 作為主時鐘源，線路通信服務作為備時鐘源。系統使用SNTP（簡單網絡時間協議）進行時鐘同步。ZLC 從時鐘源獲得標準時鐘后，把自己作為SNTP服務器，向本ZLC 的管理終端和所轄線路及其下屬SC 提供標準時鐘。

2.2 核心業務前臺

核心業務前臺由監控管理、參數管理、票務管理以及收益管理等功能模塊組成，負責ZLC所轄車站的相關日常管理。

2.2.1 監控管理

監控管理負責區域監控、車站監控、客流監控以及系統監視。ZLC 區域監控模塊集中監視區域內各個車站的狀態，車站的狀態包括車站的運行狀態和模式狀態。車站的運行狀態包括正常，報警，警告和離線狀態。車站的模式狀態包括緊急模式、正常模式和各降級模式。

ZLC車站監控模塊集中監視本區域內各個車站的設備，對設備的監控主要包括運行模式、設備狀態、設備故障及報警等各類監控信息。同時，ZLC系統可以集中控制整個系統的運行，可向某組設備、某類設備或某臺設備下達控制指令。

ZLC客流監控模塊集中監視系統內線路和車站的客流情況，以提供制定運營計劃的基礎數據。所監視的客流包括所有設備處理的客流，同時ZLC系統生成客流統計報告，顯示系統各類設備處理各類客流的情況。通常，統計報告包括各類車票使用人數、自動售票機購票人數、半自動售票機處理各類車票人數，自動加值機使用人數、各類車票進站人數、各類車票出站人數、補票人數、無票通過人數等。

ZLC系統監控模塊負責對系統主機性能、后臺線程、存儲設備、數據庫、UPS（不間斷電源）以及網絡進行監控。

2.2.2 參數管理

ZLC參數管理主要包括設備運行數據（EOD）、黑灰名單和履歷等。EOD 參數又分為ACC級參數和ZLC 級參數。ACC 級別的參數在ACC生成，向全線網所有ZLC 發布。ZLC 級別的參數，向本ZLC 的下級SC 發布，SC 轉發給下級設備。黑灰名單在ACC 生成，以文件的形式向全線網所有ZLC發布。履歷在ACC 生成，以文件的形式向全線網所有ZLC 發布。

2.2.3 票務管理

ZLC票卡庫存管理統一集中管理ZLC 和各個車站的庫存點的票卡庫存信息。當區域所轄站點每天日終結算后，產生當日票卡結存信息并上傳ZLC。當需要進行票卡調撥操作時，ZLC 根據庫存情況向ACC提出票卡調撥申請，接受ACC 調撥命令，根據線路實際情況響應該命令，完成票卡的調撥。

2.2.4 收益管理

ZLC收益管理查看本區域內某個設備或多個設備的當前收益，或日終收益，通常包含自動售票機（TVM）現金管理、POST（半自動售票機）現金管理以及一卡通充值現金管理。同時，系統負責為車站提供備用金增加、減少、領用、歸還等管理功能。

2.3 運營支持與分析

ZLC運營支持與分析由維修管理、系統管理和運營分析等功能模塊組成。

2.3.1 系統管理

ZLC 系統管理主要對系統的操作權限、系統日志以及內務進行管理。操作員在對ZLC 系統進行操作前，需要對操作員ID、操作密碼進行驗證，通過驗證后方可進行權限允許內的操作。同時系統軟硬件運作過程中產生的各種事件，包括系統運行事件、應用軟件運行事件、安全事件、異常事件等都由系統統一管理。在內務管理方面，系統對生成的文件及與各子系統相關聯的文件進行有效管理，對任何過期或無效的文件定期進行刪除、清理、歸檔或備份處理。

2.3.2 維修管理

ZLC 維修管理對本區域線路AFC 系統設備進行登記，形成設備臺賬。臺帳詳細記錄設備的設備號、設備名、設備屬性、設備所處車站、服務運行狀態、故障維修記錄、主要部件更換記錄、安全卡更換記錄和設備搬遷記錄等信息。數據庫中記錄了設備或部件的規格、數量、出入庫和庫存等信息，以便維修人員查詢和統計備品備件在其入庫、出庫、報廢等周期內的完整記錄。根據設備維修歷史和檢修周期等，系統自動或手動生成維修計劃，并對維修計劃進行統一管理。

2.3.3 運營分析

ZLC 運營分析通過對各類運營原始數據的統計，進行收益分析、客流分析以及差異分析。收益分析包括ZLC對所轄線路、車站、設備進行收益統計分析，如各類車票的不同處理類型的統計分析、系統現金數據的核算及統計分析、各種優惠條件下的收益損失統計、對車站每日收益狀況進行統計等?？土鞣治鲋饕鶕O備上傳的實時客流狀態來監視實時客流數據，通過建立合適的路網模型來計算各車站不同方向的斷面客流，為指定票務政策、行車調度等提供參考。差異分析為常見的差異類別，提供便捷的查詢、分析差異的工具，減少相應的數據分析人員對底層數據庫表的直接訪問，提高效率的同時增加數據安全性。

3 結語

隨著城市軌道交通網絡化運營的深入，許多城市在AFC 系統標準的五層架構的基礎上提出了相應的調整策略，如增設LC、ZLC 等。筆者在分析城市軌道交通線網網絡化后帶來新的運營需求的基礎上，首先對ZLC 的總體規劃進行分析，然后從核心業務后臺、核心業務前臺以及支持與分析系統3個模塊詳細分析了ZLC 的功能設計，為國內城市軌道交通AFC 系統ZLC 的總體設計提供參考。

［1］GB／T20907－2007城市軌道交通自動售檢票系統技術條件［S］.

［2］鄧先平，陳鳳敏.中國城市軌道交通AFC 系統的現狀及發展［J］.都市快軌交通，2005，18（3）：18.

［3］邱華瑞，張寧，徐文，等.城市軌道交通自動售檢票系統架構體系研究［J］.都市快軌交通，2014，27（2）：74.

［4］王健，張寧，黃亮，等.南京地鐵AFC 系統網絡化建設思路和再思考［J］.都市快軌交通，2011，24（1）：69.

［5］李道全，趙華偉.多線共用AFC 系統線路中心設計探討［J］.都市快軌交通，2012，25（5）：71.

［6］陳楠，李繼銘.南京地鐵AFC 系統管理方式的分析和研究［J］.鐵路通信信號工程技術，2011，8（6）：47.

［7］楊柯，蘇競.地鐵自動售檢票系統運營籌備體系的研究與實現［J］.城市軌道交通研究，2014（5）：22.