軌道交通自動售檢票系統(tǒng)區(qū)域中心接口設計的探討

毛 建王彬彬何鐵軍

（1.南京地鐵建設有限責任公司，南京 210024；2.東南大學智能運輸系統(tǒng)研究中心，南京 210018）

軌道交通自動售檢票系統(tǒng)區(qū)域中心接口設計的探討

毛 建1王彬彬2何鐵軍2

（1.南京地鐵建設有限責任公司，南京 210024；2.東南大學智能運輸系統(tǒng)研究中心，南京 210018）

通過對網(wǎng)絡化條件下城市軌道交通地鐵自動售檢票（AFC）系統(tǒng)建設需求的分析，提出在AFC系統(tǒng)五層標準架構(gòu)基礎(chǔ)上的區(qū)域中心（ZLC）概念。進而以南京為例，說明在數(shù)據(jù)接口標準化、數(shù)據(jù)接口兼容性、數(shù)據(jù)接口可擴展性等3個方面進行探索和思考，實踐表明，ZLC在南京地鐵已取得良好應用。

區(qū)域中心；接口標準化；CORBA；可擴展性

1 概述

地鐵自動售檢票（Automatic Fare Collection，AFC）的標準架構(gòu)體系由系統(tǒng)清結(jié)算中心（ACC）、線路中心計算機系統(tǒng)（LC）、車站計算機系統(tǒng)（SC）、車站終端設備（SLE）和車票組成［1］，從功能定位來看，LC是某條線路AFC系統(tǒng)的管理及監(jiān)控中心，通過對系統(tǒng)數(shù)據(jù)的采集、統(tǒng)計及管理，以實現(xiàn)系統(tǒng)運作、收益及設備維護集中管理的功能，LC還是各線路接入線網(wǎng)的節(jié)點，通過LC與ACC的接口進行各類數(shù)據(jù)的上傳與下發(fā)，實現(xiàn)網(wǎng)絡化的運營。

地鐵工程一般以線路為單位進行建設，因此傳統(tǒng)的建設方案是各線均設置獨立的LC系統(tǒng)接入ACC，除通過線網(wǎng)通用讀寫器解決與線網(wǎng)內(nèi)票卡的接口外，其他線路內(nèi)接口均由線路系統(tǒng)內(nèi)部保證。該方案具有接口界面清晰，工程責任明確，便于項目實施管理的優(yōu)點，得到廣泛的應用。

以線路為單位建設的AFC系統(tǒng)因各類數(shù)據(jù)和管理平臺是分線獨立的，因此，運營管理也只能按線路為單位來分線開展。但隨著城市軌道線網(wǎng)建設的迅速擴展，線網(wǎng)密度不斷加大，基于網(wǎng)絡化為導向的建設與運營管理需求越來越突出。

1） 除信息化的數(shù)據(jù)流以外，AFC系統(tǒng)的運作過程中還存在著大量的票卡、單據(jù)及維修部件等物流工作，實際物理距離的長短影響現(xiàn)場維護響應速度和物流運輸成本。為提高運行效率和響應速度、降低運行成本，在線網(wǎng)不斷加密的情況下，提出建立以換乘站為中心的，覆蓋多條線路的區(qū)域化運營管理和維修管理模式，以大幅度縮短物流運輸及維修人員旅行距離。

2） 隨著城市建設的迅速發(fā)展，地鐵線網(wǎng)規(guī)劃修編引起的線路規(guī)劃調(diào)整在所難免，加之地鐵工程分期建設的特點，AFC系統(tǒng)會出現(xiàn)兩種情況：一是先期建設的一條線路的部分車站SC以下系統(tǒng)需調(diào)整到另一條線路LC中，二是一條既有線路LC系統(tǒng)需在延伸線建設時，接入新增車站的SC系統(tǒng)。在單線建設模式下，第一種情況存在著既有車站系統(tǒng)及設備與擬接入線路AFC系統(tǒng)接口不兼容的問題，第二種情況則存在擴容的延伸線車站系統(tǒng)受制于既有線路接口的問題，為解決上述兩個問題，需在全網(wǎng)或一定區(qū)域內(nèi)統(tǒng)一接口。

3） 在信息技術(shù)迅速發(fā)展的今天，提供更多擴展功能和服務的自助設備不斷推出，并逐漸得到推廣應用；在系統(tǒng)的運營維護過程中，重要部件與設備的選型往往受到原有系統(tǒng)接口的限制。為提高服務水平，降低運營成本，做好AFC系統(tǒng)在設備層的接口兼容設計，滿足新機種、新設備的靈活接入是一個非常迫切的需求。

基于以上需求和認識，結(jié)合南京地鐵區(qū)域控制中心規(guī)劃，提出南京地鐵AFC系統(tǒng)的區(qū)域線路中心（ZLC）的概念。文獻［2］探討了ZLC的功能架構(gòu)并分析各模塊及其子模塊的構(gòu)成與功能，本文著重從接口標準化的角度，介紹在南京地鐵ZLC建設過程中對系統(tǒng)兼容性與可擴展性進行的若干思考與實踐。

2 基于ZLC的接口需求分析

城市軌道交通AFC系統(tǒng)中的ZLC是面向城市軌道交通線網(wǎng)的區(qū)域化管理而提出的，旨在解決一定規(guī)模的線網(wǎng)內(nèi)相關(guān)各線路獨立運營所帶來的運營管理復雜、維修調(diào)配不便，線網(wǎng)建設發(fā)展帶來的線路升級改造對運營產(chǎn)生的影響，以及新老線路間接口不統(tǒng)一帶來的一系列問題。基于ZLC特點的AFC系統(tǒng)內(nèi)各層級接口設計需重點考慮如下幾個方面的需求。

1） 接口的標準化。無論是建立以換乘樞紐站為中心，覆蓋多條線路部分車站的區(qū)域化運營管理和維修管理模式，亦或是以車站為單位開展的工程建設，同屬于一個ZLC的多條線路的車站設備運行數(shù)據(jù)、運營數(shù)據(jù)以及運營管理平臺需實現(xiàn)統(tǒng)一，才能真正發(fā)揮ZLC加快響應速度、提高服務水平、降低運營成本的優(yōu)點，因此，系統(tǒng)各層間及層內(nèi)的數(shù)據(jù)定義與數(shù)據(jù)傳輸方式必需標準化。

2） 接口的兼容性。在現(xiàn)有的建設管理模式下，同一個ZLC系統(tǒng)中必然會出現(xiàn)不同供應商或不同版本的系統(tǒng)與設備，因此，作為共同遵守的接口規(guī)范必須充分考慮兼容性的要求。在線路延伸線建設、系統(tǒng)設備大修更新或是日常維修維護過程中，良好的接口兼容性設計將會給設備采購帶來更多的選擇，有利于減少改造工程量，降低工程實施難度。

3） 接口的可擴展性。同一個ZLC會承擔跨度較長時期的建設任務，ZLC是一個不斷接入新車站、新設備的系統(tǒng)，需適應新技術(shù)的發(fā)展，例如新出現(xiàn)的互聯(lián)網(wǎng)購票取票機，未來可能出現(xiàn)的云購票機、云檢票機等，接口設計應充分考慮可擴展性，為未來產(chǎn)品預留空間和接口。

3 基于ZLC的接口設計

ZLC架構(gòu)的實現(xiàn)主要受制于AFC系統(tǒng)的數(shù)據(jù)接口，因此本文著重對此進行介紹。

3.1 數(shù)據(jù)接口的標準化設計

在基于ZLC的AFC系統(tǒng)數(shù)據(jù)接口標準化設計中，主要對數(shù)據(jù)接口層級的劃分、數(shù)據(jù)的組織方式和數(shù)據(jù)的傳輸方式進行研究和設計。

3.1.1 數(shù)據(jù)接口層級的劃分

AFC系統(tǒng)5層架構(gòu)體系下，自然存在著ACC 與 LC/ZLC、LC/ZLC與 SC、SC與 SLE、SLE（讀寫器）與票卡4個層級間的接口。在傳統(tǒng)線路為單位的建設模式下，ACC與LC/ZLC、SLE（讀寫器）與票卡兩個接口得到重視，以滿足單線路接入線網(wǎng)的需要。在設備與線路系統(tǒng)集成商為不同廠家的項目中，SC與SLE的接口也需要進行定義，但一般由線路系統(tǒng)集成商進行管理。在ZLC建設模式下，則需要對上述4個層間接口根據(jù)ZLC的特點與功能進行完整的定義和驗證。

此外，在傳統(tǒng)建設模式下，層級內(nèi)的接口一般看作承包商的軟件內(nèi)部事務，不會納入到線網(wǎng)規(guī)范管理的范疇。但在ZLC建設模式下，ZLC、SC內(nèi)部功能模塊的接口也需進行管理。這是因為ZLC系統(tǒng)會在較短的時間內(nèi)完成建設并投入使用，一般與一條線路的建設周期同步，但接入更多其他線路車站的過程需要跨越較長的時間，期間由于管理需求、技術(shù)更新、供應商選擇等多方面的原因可能需增加對系統(tǒng)功能模塊進行調(diào)整或增減。為使新的軟件模塊能準確獲取到系統(tǒng)數(shù)據(jù)，需要在ZLC和SC的系統(tǒng)層級內(nèi)劃分出數(shù)據(jù)接口。例如車站和線路都有監(jiān)控工作站需要監(jiān)控設備的工作狀況和客流，傳統(tǒng)模式下并不定義該監(jiān)控工作站軟件如何從SC或ZLC中獲取數(shù)據(jù)；而在本系統(tǒng)下，定義了系統(tǒng)同一層內(nèi)的數(shù)據(jù)接口，監(jiān)控軟件模塊與SC主程序之間的接口定義如圖1所示。

圖1 設備事件數(shù)據(jù)傳輸接口圖

3.1.2 接口數(shù)據(jù)的組織方式

接口數(shù)據(jù)可分為兩種類型：一是非實時類數(shù)據(jù)；此類數(shù)據(jù)通常比較重要，要方便運維人員追蹤查看，但實時性要求不高，因此采用文件方式封裝數(shù)據(jù)，數(shù)據(jù)包括交易數(shù)據(jù)、參數(shù)數(shù)據(jù)等；二是實時類數(shù)據(jù)，此類數(shù)據(jù)實時性要求高，但數(shù)據(jù)刷新頻率高，且通常無需記錄此類數(shù)據(jù)的變化過程，數(shù)據(jù)包括系統(tǒng)命令、設備狀態(tài)和實時客流數(shù)據(jù)和各類事件等。

兩種類型的數(shù)據(jù)分別以如下方式進行組織。

非實時類數(shù)據(jù)采用文件形式對數(shù)據(jù)進行封裝，文件數(shù)據(jù)通常有二進制、文本、XML和XDR等形式，系統(tǒng)中的文件數(shù)據(jù)采用外部數(shù)據(jù)表示（eXternal Data Representation，XDR）格式。XDR既是一種描述數(shù)據(jù)的語言，又是一組用于編碼的規(guī)則。XDR允許采用一種與體系結(jié)構(gòu)無關(guān)的方式進行封裝，可以在不同的體系結(jié)構(gòu)和異構(gòu)計算機系統(tǒng)之間正確地傳輸數(shù)據(jù)，XDR文件就是采用XDR編碼規(guī)則所定義的文件［3］。通過遠程過程調(diào)用（Remote Procedure Call，RPC），將.x文件轉(zhuǎn)換成多種開發(fā)語言源程序，在接口調(diào)整時，只需調(diào)整.x文件即可保證接口的一致性。

實時類的數(shù)據(jù)可采用實時數(shù)據(jù)庫存儲，通常采用鍵值對（Key-value）形式，鍵值對是一個常用的數(shù)據(jù)結(jié)構(gòu)概念，每個存放到該數(shù)據(jù)結(jié)構(gòu)中的值（Value）都對應一個全局唯一的鍵（Key）。該數(shù)據(jù)結(jié)構(gòu)的特征是以空間換時間，通過鍵查詢值通常是比較快速的過程，且具有查詢速度快、存放數(shù)據(jù)量大、支持高并發(fā)等優(yōu)點。

3.1.3 接口數(shù)據(jù)的傳輸方式

文件類型數(shù)據(jù)一般對傳輸實時性要求不高，但需保證較好的安全性、完整性和通用性。采用文件傳輸協(xié)議（File Transfer Protocol，F(xiàn)TP）進行通信是一個較好的選擇。FTP是一種被廣泛認可的通訊協(xié)議，傳輸效率高，安全性高，同時它也是一個應用程序?；诓煌牟僮飨到y(tǒng)有不同的FTP應用程序，而所有這些應用程序都遵守同一種協(xié)議以傳輸非實時數(shù)據(jù)。

實時類包括命令、事件和狀態(tài)等，其特點是對傳輸?shù)膶崟r性和兼容性要求高。CORBA （Common Object Request Broker Architecture）技術(shù)是一種面向?qū)ο蟮耐ㄐ胖虚g件技術(shù)，它使得客戶可以像調(diào)用本地對象的操作一樣調(diào)用服務器CORBA對象的接口操作，從而實現(xiàn)通信雙方的信息交換。CORBA通信中間件具有如下優(yōu)點［4］：

1）引入了代理的概念。在分布式環(huán)境中，對象請求代理（Object Request Broker，ORB）負責透明地接收請求與發(fā)送響應。

2）實現(xiàn)了客戶和服務器的完全分離。在保持接口不變的情況下，客戶和服務器可分別獨立升級。

3）提供了軟件總線的機制。軟件總線是指CORBA規(guī)范定義的一組接口規(guī)范，并且這個接口規(guī)范與任何的運行平臺與編程語言相獨立。服務器將具有標準接口的軟件構(gòu)件掛接到軟件總線上，客戶通過軟件總線訪問軟件構(gòu)件，從而實現(xiàn)軟件構(gòu)件的即插即用。

4）具有良好的語言無關(guān)性?？蛻襞c服務器可以用不同的編程語言編寫。

基于以上優(yōu)點，南京ZLC系統(tǒng)采用CORBA技術(shù)進行實時數(shù)據(jù)的通信傳輸。在設備、數(shù)據(jù)服務器以及監(jiān)控軟件上都部署CORBA的接口服務程序，根據(jù)AFC的需求，最終，其實時通信核心接口被抽象為：發(fā)送命令、推送事件和讀狀態(tài)3種接口。

3.2 數(shù)據(jù)接口的兼容性設計

系統(tǒng)同時存在ACC和ZLC兩種參數(shù)。ACC參數(shù)主要用于整個線網(wǎng)運營，例如票種、車站、費率、費率等級等。與ACC參數(shù)不同，ZLC參數(shù)主要用于管理線網(wǎng)設備。在同一ZLC系統(tǒng)內(nèi)的設備因模塊或整機不同，部分具體設備參數(shù)也不盡相同，如票箱裝票數(shù)量、設備發(fā)聲、地圖像素、硬幣模塊參數(shù)、紙幣模塊參數(shù)等。即使同一供應商的設備，因為是不同建設時期的設備產(chǎn)品，軟件版本也可能不盡相同。

為此，對各類型設備的進行編碼，對同類型設備，如自動售票機，也需根據(jù)其部件類型、硬件特點、軟件版本等具體情況進行分類，編碼為子類型。同時，在統(tǒng)一編碼的基礎(chǔ)上建立起各類型設備與設備參數(shù)的映射關(guān)系。當進行設備升級管理時，系統(tǒng)可根據(jù)設備編碼對應的目錄進行各自獨立的下載更新。

通過設備參數(shù)線網(wǎng)級的兼容性設計，實現(xiàn)ZLC系統(tǒng)軟件對不同類型設備的兼容接入，可以對廣泛分布于各線車站現(xiàn)場的各類型設備集中進行參數(shù)與設備軟件的升級管理，提高了運營管理效率。也因此打破具體設備屬于某條線路的限制，大大方便了運營維護過程中根據(jù)客流情況進行線網(wǎng)內(nèi)設備調(diào)配和更新的工作開展。

3.3 數(shù)據(jù)接口可擴展性設計

隨著技術(shù)的發(fā)展，在ZLC生命周期內(nèi)，為滿足具有新功能的新部件模塊、新設備機種的接入，除了在系統(tǒng)定義、編碼上的設計預留以外，可擴展性還通過如下方面得以實現(xiàn)。

系統(tǒng)交易數(shù)據(jù)采用XDR形式，XDR通常采用UNION的方式，將一些功能相似，數(shù)據(jù)字段不同的數(shù)據(jù)抽象成一種數(shù)據(jù)類型，因此具有良好的可擴展性。例如南京地鐵在實施交通部一卡通項目改造過程中，由于進度問題，舊線路上只有部分設備支持城市交通卡，則原有系統(tǒng)沿用原有.x文件，而新系統(tǒng)則在新.x文件交易類型中新增城市一卡通交易的聯(lián)合體即可。

命令、事件和狀態(tài)數(shù)據(jù)均采用鍵值對形式，實現(xiàn)了實時通信的良好可擴展性。車站設備一方面需向數(shù)據(jù)服務器上傳狀態(tài)和事件數(shù)據(jù)，另一方面需接收數(shù)據(jù)服務器發(fā)來的命令。雖然AFC系統(tǒng)各個接口是固定的，ZLC可監(jiān)控各種設備的鍵值對型參數(shù)來增強數(shù)據(jù)接口的擴展性。當發(fā)送命令時，對于新增的設備，增加相應鍵值對來響應命令；對于舊有設備，則采取拋棄命令措施。除了固定的必備事件，設備向上層進行上報的事件是可配置的，通過配置表文件來配置事件類別、事件級別等來完成對新事件的處理。例如私自打開TVM、擅闖閘機扇門等事件。

4 南京地鐵ZLC項目實施

根據(jù)南京地鐵線網(wǎng)建設相關(guān)規(guī)劃，將在東部、南部、中部及位于江北的北部設立4個區(qū)域化的線路控制中心，AFC系統(tǒng)也將同址建設4個區(qū)域中心ZLC，其中位于南部的南京南區(qū)域中心已經(jīng)建成，靈山區(qū)域中心在建，珠江路區(qū)域中心將結(jié)合既有1號線、2號線改造進行實施，如圖2所示。

圖2 南京地鐵AFC系統(tǒng)區(qū)域中心實施現(xiàn)狀圖

目前，南京南ZLC已成功接入3、10號線并開通運營，寧和城際線正在接入調(diào)試中，未來還將接入多條線路，開通運營兩年以來，包括售檢票交易、設備監(jiān)控、運營參數(shù)下發(fā)等主要AFC系統(tǒng)功能均運行良好，并且在提高運營管理效率、方便現(xiàn)場維護組織上都體現(xiàn)了較好的優(yōu)越性。此外，在兼容性方面，南京南ZLC系統(tǒng)已經(jīng)實現(xiàn)對兩種子類型的自動檢票機的兼容，在建的靈山ZLC也已完成兩種子類型自動售票機的現(xiàn)場調(diào)試，系統(tǒng)支持對不同子類型設備的統(tǒng)一管理。

5 結(jié)語

通過對網(wǎng)絡化條件下城市軌道交通AFC系統(tǒng)建設需求的分析，結(jié)合南京地鐵AFC系統(tǒng)建設實踐，對軌道交通自動售檢票系統(tǒng)區(qū)域中心建設思路進行探討。相信隨著各兄弟城市在AFC系統(tǒng)建設方面的探索和創(chuàng)新，包括南京區(qū)域中心在內(nèi)的網(wǎng)絡化建設模式一定會得到不斷的完善和更廣泛的應用。

［1］中華人民共和國國家質(zhì)量監(jiān)督檢驗檢疫總局，中國國家標準化管理委員會.GB/T 20907-2007 城市軌道交通自動售檢票系統(tǒng)技術(shù)條件［S］.北京：中國標準出版社，2007.

［2］黎慶，張寧，徐鐘全，等.城市軌道交通自動售檢票系統(tǒng)區(qū)域中心總體設計［J］.城市軌道交通研究，2015（8）：71-75.

［3］莊濤，樓生琳.XDR技術(shù)在軌交AFC系統(tǒng)消息傳輸中的應用研究［J］.計算機應用與軟件，2012，29（6）：219-221.

［4］陸文偉.基于CORBA的軌道交通AFC設備監(jiān)控組態(tài)軟件的設計與實現(xiàn)［D］.東南大學，2013.

Through the analysis of AFC system under the internet environment， the paper puts forward the concept of Zone Line Center （ZLC） based on 5-layer architecture of AFC system. By taking Nanjing metro as an example， it discusses ZLC interface standardization， interface compatibility and extensibility. The practice proves that ZLC has been applied in Nanjing metro with a good effect.

Zone Line Center （ZLC）； interface standardization； CORBA； extensibility

10.3969/j.issn.1673-4440.2016.05.018

（2016-06-28）