AFC系統可配置數據/服務交換平臺的思考

王　健　張　寧　何鐵軍

(1. 南京地下鐵道有限責任公司　南京　210024；2. 東南大學智能運輸系統研究中心　南京　210018)

?

AFC系統可配置數據/服務交換平臺的思考

王健1張寧2何鐵軍2

(1. 南京地下鐵道有限責任公司南京210024；2. 東南大學智能運輸系統研究中心南京210018)

針對當前網絡化進程中自動售檢票(AFC)系統升級改造帶來的功能分配、子系統分布重定位等問題，指出功能軟件靈活部署的關鍵在于可方便地獲取支撐軟件的基礎數據和信息，提出AFC系統可配置數據/服務交換平臺的概念。通過對AFC系統數據傳輸需求的分析，確定可配置數據/服務交換平臺所需具備的功能，并基于此對平臺的系統架構進行設計，并將該平臺應用于南京地鐵AFC工程建設。

城市軌道交通；自動售檢票系統；數據交換平臺；區域中心

1　AFC系統架構及存在的問題

當前的自動售檢票(AFC)系統通常采用5層架構，即車票-車站設備(station level equipment，SLE)-車站中心(station center，SC)-線路中心(line center，LC)-清分中心(AFC clearing center，ACC)[1-2];也有城市在此基礎上提出了一些變化，如北京軌道交通在SC與ACC之間設置多線路中心[3-5]，南京軌道交通提出了獨立的票卡交易內置型IC卡讀寫器層、區域中心[6]等，這些架構的變化屬于原5層架構的微調。5層架構的形成有一定的歷史原因：城市地鐵建設初期通常采用單線運行，LC負責整條線路的運營管理，包括數據統計、報表生成、票卡發行、卡賬戶管理、線路設備與 客 流 監控等；隨著線網網絡化的形成，為滿足多條線路間票卡交易的清分結算等工作，因此在LC層上增加了ACC層，負責交易數據的存儲和備份、票卡的發行、卡賬戶管理、線網報表生成、線網設備與客流監控。隨著ACC層的設立，LC的功能定位發生改變。但在運營實踐中，許多城市的軌道交通AFC系統5層架構仍然存在一定的問題。

1) LC功能定位模糊。在成網運行后，原LC的大部分功能被提升部署在ACC，而當前LC的許多功能都可以被替代。例如：LC的數據上傳和備份功能，在當前網絡條件下，數據可以直接由SC與ACC通信進行傳遞，無需LC轉發，SC與ACC直接通信可以增加系統的穩定性和可靠性；ACC存儲和備份了線網的票卡交易數據，LC再次備份本線路的交易數據并沒有太大的實際意義；由于ACC可獲取整個線網AFC系統的原始基礎數據，線路管理所需的所有報表都可由ACC生成；線路與ACC的對賬功能也可改為ACC與SC直接對賬，一旦有交易清分發生異議，可更快捷、準確地定位異議交易的發生原因。一方面，在地鐵線路建設投資主體單一的情況下，LC的功能意義不明確；另一方面，LC的配置通常較好，造價比較高，而且需要配置專門的部門進行管理、維護。

2) 當前的架構對地鐵內部管理有一定的影響。目前，AFC系統的通信接口比較固定，整個線網的數據匯聚于ACC，不同的子系統(如設備監控系統、客流監控系統、票務系統)需要從ACC中獲取基礎數據。這些子系統需要部署在ACC內，而隨著地鐵線網的日益擴大，地鐵運營部門的職能也會隨之調整，維修部門、站務部門、票務部門未必隸屬于ACC，所以對運營組織機構的構建造成一定的障礙。

要想解決上述問題，需實現相應的管理軟件的靈活部署，而其關鍵在于可方便地獲取支撐軟件的基礎數據和信息。為此，筆者基于南京地鐵AFC系統現狀，對AFC系統內部數據的傳輸和管理進行重新設計，提出AFC系統可配置數據/服務交換平臺的概念。

圖1　可配置數據/服務傳輸交換平臺系統

2　可配置數據/服務交換平臺需求

2.1數據分類

AFC系統可配置數據/服務交換平臺設立的目的，是為AFC系統內部提供一個專門進行數據傳輸和管理的后臺，為未來AFC系統的擴建和發展奠定基礎。為此，需對南京地鐵AFC系統數據傳輸現狀進行分析。其中，AFC的數據可分為非實時數據和實時數據兩類。

1) AFC中的非實時數據主要為數據文件的傳輸，采用FTP(file transfer protocol，文件傳輸協議)來分級傳輸，文件包含票卡交易記錄數據文件、事件記錄文件、審計文件和參數文件等。交易數據上傳至ACC中心后，ACC對數據進行解析，將交易數據寫入數據庫，并對數據庫中的卡賬戶進行維護。

2) AFC系統的實時數據如下：ACC-LC-SC-SLE的實時命令，以及命令的響應、設備狀態的快照和事件、BOM(半自動售票機)。

當設備的狀態發生改變時，設備狀態的快照以及事件報警等信息通過CORBA、以“推”的模式發送至SC，SC通過CORBA、將收到的數據以“推”的模式發送數據至LC。ACC在查詢狀態時，以“拉”的方式從LC中提取數據。

實時數據目前還包含一特例，BOM直接與ACC通信，實現SAM(security access module，安全存取模塊)的在線認證以及票卡賬戶的查詢。

2.2建設目標

根據上述內容，在充分考慮與原技術規程充分兼容的基礎上，提出設置一個全網的數據/服務傳輸交換平臺。該平臺匯聚全網的數據并作為服務的入口，它的建設目標是：

1) 節省系統的投資。原每建一條線路AFC系統需要一臺小型機，隨著數據/服務傳輸交換平臺的建設，未來AFC系統中的SC直接接至數據/服務傳輸交換平臺，不僅可以節省LC的建設成本，還可以減少未來系統的維護工作量。

2) 為未來各種可能的應用提供接口。隨著管理的精細化，在不同的位置可能部署著各種應用軟件，而應用軟件則需要各種各樣的數據，平臺將為這些應用提供接入接口。簡而言之，數據/服務傳輸交換平臺具有可擴展性。

3) 技術規程的標準化。在原南京AFC技術規范中，只描述了SLE與SC、LC與ACC的接口，并沒有描述SC與LC間的通信接口。通過可配置數據/服務傳輸交換平臺的建設，將使AFC系統各層的接口都標準化。

4) 解決網絡化運營后LC功能定位模糊、系統資源分散浪費的問題，滿足區域化集中維護、管理，降低日常運營維護成本。

3　交換平臺系統架構及設計構想

3.1系統架構

設計可配置數據/服務傳輸交換平臺，應考慮與現有技術規程的兼容性、實時性、可擴展性、可實現性、可驗證性、經濟性以及模塊化。在AFC系統網絡架構下，任何一臺計算機都可以直接和另一臺計算機通信，且SLE可直接與數據交換平臺通信，這不利于系統的管理、維護以及可能的故障定位和排除，因此考慮SLE通過接入服務器與數據交換平臺通信。平臺的系統拓撲架構如圖1所示，交換平臺系統由數據/服務傳輸交換服務器和接入服務器組成。

圖2　系統平臺功能邏輯

數據/服務傳輸交換服務器是整個平臺的核心系統，向整個網絡內的應用軟件提供數據和服務支持，其內存數據庫映射整個網絡內的數據。對常規的應用，應用軟件可從數據交換平臺服務器中得到應用數據的支持。對于某些特殊的應用，數據交換平臺服務器本身不包含所需的數據，則可以用請求服務的方式，從相應的服務提供端獲取數據。數據交換平臺通常不直接與應用軟件通信，而是通過接入服務器轉接。

接入服務器為應用程序和AFC設備的接入接口。接口主要由3部分組成：與數據交換平臺的接口、原有車站AFC設備接口、應用程序接口。AFC設備可以通過原有車站的AFC設備接口接入，其他應用程序通過應用程序的接口接入。對外提供兩組不同接口的原因是：一方面，要考慮與原有AFC系統接口的兼容性；另一方面，原AFC設備的接口滿足不了未來應用的需求，因此需要重新制定新的技術要求。接入服務器也應該包含一個內存數據庫，用以記錄本服務器的各種相關數據，支持本地的應用。例如，車站的監控軟件需要讀取本站的數據，則直接在本地接入服務器獲取相關的數據支持。

3.2設計構想

系統平臺所提供的功能包括對外提供統一的數據通信接口、數據服務(數據的存儲、讀取、匯聚等再處理)以及服務的再定向等功能。系統平臺包含有通信接入接口、內存數據庫、歷史數據庫等，同時平臺可掛載各種觸發器，實現接口的開放性和功能的多樣性。系統平臺各子功能按不同模塊分別部署，如圖2所示。

3.2.1平臺數據

本平臺的數據分為兩種：第一種是系統產生的數據,直接存儲于接入服務器或數據/服務傳輸交換服務器中；第二種是某些不能直接存儲于接入服務器或數據/服務傳輸交換服務器中的數據，只能在使用時由特定的應用提供數據，如密鑰認證、卡片查詢等。

3.2.2內存數據庫

內存數據庫用于在內存中記錄設備的數據狀態，目前考慮數據的存儲分為3個大類：狀態表、分時記錄表以及事件表。

狀態表用于記錄某種狀態的當前值，每條記錄的字段名包括TAG(標簽)名、設備的ID(identification，身份證明)、記錄更新時間以及狀態的值，每次更新時將采用覆蓋的方式對記錄進行重寫。

分時記錄表用于記錄某個事物的分時狀態，如客流的5min數據。該數據往往不由設備直接上報，而是由平臺的觸發器生成。每條記錄單元包括的字段為TAG名、設備的ID、記錄時間、狀態值。每次記錄更新，若為新值則插入新記錄，否則以覆蓋的方式改寫記錄。

事件表用于記錄各種事件。每條記錄的字段包括事件的TAG名、設備的ID、事件以及事件的值，每次更新時采用插入的方式改寫記錄。

為保證平臺的開放性，平臺存取數據與采用的業務無關，即平臺不關心數據的含義，只是將數據的TAG名和數值采用某種數據結構進行存儲，建議采用鏈式存儲、鏈表、二叉樹等方式。

3.2.3服務

服務是指另一種通信擴展手段，通常由應用服務商提供，可部署于系統內的某一特定的計算機上，服務分為提供端和使用端：服務提供端在啟動時，調用注冊函數，通知平臺服務的位置；服務使用端在需要該服務時，首先向平臺請求該服務，平臺接受到服務請求后，將請求參數發至服務提供端，服務提供端將結果發送至平臺，平臺再將結果回送至服務調用者?？梢?，平臺的作用是為服務提供一種重定向的作用，服務機制是保障系統擴展性的一個主要手段。

3.2.4文件傳輸

接入服務器和數據/服務交換服務器都提供FTP服務，都可提供put和get操作。文件傳輸服務可由腳本控制：FTP服務在收到某一類的數據文件后，可以根據腳本轉發至其他FTP服務器；也可通過腳本設定服務器，定時去某FTP服務器查詢下載指定的文件。當接收或發送完成文件后，向本服務器發送相關的消息(事件)。

3.2.5觸發器

觸發器是一種對數據進行預處理的手段。觸發器分為內置觸發器和外置觸發器兩種：內置觸發器為動態函數庫(DLL)，用戶可通過命令或配置文件動態加載函數；外置觸發器通常是應用程序，可以通過CORBA接口實現觸發。

內置觸發器由平臺提供商提供，部署在平臺上，其觸發條件包括：啟動觸發(平臺在啟動的時候調用指定的觸發函數)、定時觸發(按指定的時間間隔觸發)、接收到指定的TAG命令觸發、接收到某一類數據觸發等。內置觸發器可以考慮使用配置文件等方式進行加載。

外置觸發器通常由應用服務商提供，可部署于系統內任意的計算機上，支持規定的數據接口，其觸發條件包括：接收到指定的TAG命令觸發、接收到某一類數據觸發等。通常，應用軟件使用外置觸發器訂閱某個或某一類消息。外置觸發器調用相應的接口注冊函數的方式加載，平臺以“推”的方式將相關數據送至外置觸發器。

3.2.6消息隊列

考慮到接入服務器和數據/服務交換服務器的通信可能中斷，為了防止數據丟失，接入服務器中重要的數據不直接發至數據/服務交換服務器，而是寫入消息隊列，由接口從消息隊列中讀出后，再傳至數據服務交換服務器。

3.3工程應用

近年來，南京對原有的AFC系統架構進行了調整，在ACC層與SC層增加了AFC系統區域中心層。區域中心是軌道交通網絡化運營后面向區域化管理而提出的，旨在解決一定規模的線網內相關各線路獨立運營所帶來的運營管理復雜、維修調配不便、線網建設發展帶來的線路升級改造對運營產生的影響，以及新老線路間接口不統一帶來的一系列問題[7-8]。

區域中心系統由核心業務后臺、核心業務前臺、支持與分析系統三大模塊組成。其中，核心業務后臺基于可配置數據/服務傳輸交換平臺，通過統一交互接口，實現不同車站或線路的接入，并與ACC、SC之間進行數據傳輸，保證系統內部所有數據的傳輸、解析、審核、核對、備份以及安全等。

4　結語

在網絡化運營背景下，新的運營需求產生和新線加入，使各城市針對自身情況對原有AFC系統的5層架構進行調整或升級逐漸成為一種趨勢。統一接入條件并在一定程度上對AFC系統內部數據的傳輸和管理進行重新設計，是其中的關鍵部分之一。筆者在分析當前5層架構可能存在部分缺陷的基礎上，提出了AFC系統可配置數據/服務交換平臺的概念；再根據AFC系統數據傳輸的需求，對可配置數據/服務交換平臺的系統架構進行了設計；最后說明了該平臺在南京地鐵AFC工程中的應用，為國內城市軌道交通AFC系統的建設提供參考。

[1] GB/T 20907—2007城市軌道交通自動售檢票系統技術條件 [S].北京：中國標準出版社，2007.

[2] 范巍.清分中心系統的功能定位及售檢票系統標準制定[J].城市軌道交通研究，2010 (3)：1-4.

[3] 李道全，趙華偉.多線共用AFC系統線路中心設計探討[J].都市快軌交通，2012，25(5)：71-74.

[4] 丁樹奎.北京市軌道交通AFC多線共用線路中心應用研究[J].科技通報，2012，28(12)：176-178.

[5] 王浩，劉旭，楊霓霏.北京軌道交通自動售檢票系統多線共用線路中心的設計與實現[J].鐵路計算機應用，2013，22(3)：60-63.

[6] 吳娟，徐忠全，毛建.南京地鐵AFC區域線路中心的規劃設計[J].鐵路通信信號工程技術，2012，9(5)：63-65.

[7] 陳楠，李繼銘.南京地鐵AFC系統管理方式的分析和研究 [J].鐵路通信信號工程技術，2011，8(6)：47-50.

[8] 邱華瑞，張寧，徐文，等.城市軌道交通自動售檢票系統架構體系研究[J].都市快軌交通，2014，27(2)：74-77.

(編輯：郭 潔)Thoughts on ‘Configurable Data/Service Exchange Platform’ in AFC System

Wang Jian1Zhang Ning2He Tiejun2

(1. Nanjing Metro Co., Ltd., Nanjing 210024；2. ITS Institute of Southeast University, Nanjing 210018)

To solve the problems of function allocation and subsystem distribution relocation arising from the upgrade of AFC system in current network operation, it is suggested that the key to flexibly deploying functional software is to obtain basic data and supporting information. Based on this point, the concept of ‘configurable data/service exchange platform’ in AFC system is proposed. By analyzing the data transmission requirements of AFC system, the functions of the platform are identified and the system architectures of the platform are designed. This idea is applied to the current AFC system’s construction of Nanjing Metro.

urban railway transit; AFC system; Data Exchange Platform; regional center

10.3969/j.issn.1672-6073.2015.01.003

2014-05-22

2014-06-08

王健，男，碩士，教授級高級工程師，從事城市軌道交通機電工程研究，wang_j@njmetro.com.cn

江蘇省科技廳產學研聯合創新資金項目(BY2012197)；南京地鐵專項科技項目(8550140042)

U29-39；U293.22

A

1672-6073(2015)01-0008-04