深圳地鐵AFC數據管理中心設計

白云海 丁 耿

(深圳市地鐵集團有限公司 廣東 深圳 518040)

2011年6月，深圳地鐵1、2、5號線將全部建成通車，屆時深圳地鐵AFC系統將正式迎來網絡化運營階段。但由于目前3條線路有各自的線路中心，軌道交通清分中心(ACC)接入、票務管理、參數下發和報表輸出等功能點按線路各自獨立，這給運營管理帶來了一定困難，而且不利于自動售檢票(AFC)系統的管理維護和信息共享。鑒于此，為滿足網絡化運營需求，實現不同線路中心數據庫之間的集中管理，賬戶、交易等數據信息共享和線網化報表的統一輸出，AFC數據管理中心的設計需要得到足夠的重視。

1 數據管理中心總體分析

深圳地鐵AFC系統是一個典型的分布式數據庫系統，每條線路有自己的LC(line center)線路中心，LC管理本線路所有車站節點。

數據管理中心的設計目的就是在線路層之上，為AFC系統管理人員提供一個集中管理的平臺。系統管理者可以通過該平臺管理所有車站及設備，車票生產、收益核對人員可以從一個統一的界面方便地查詢不同數據庫的數據。從網絡結構來看，AFC系統原有的4層結構并不做改變，只在第3層線路中心和第4層軌道交通清分中心之間增加數據管理中心層，集中管理不同線路和車站，并統一各線路與ACC的對賬接口。數據管理中心系統層次結構如圖1所示。

圖1 數據管理中心系統層次結構

2 數據管理中心功能及構成

2.1 主要功能

為了集中管理不同線路和車站，并簡化相關業務流程，數據管理中心的設計應具備以下主要功能:

1)提供各線路與ACC的統一接口，完成參數、報文和對賬文件的上傳與接收;

2)取消各車站與線路中心的同義詞連接，完成票務分離，實現車票生產、配發、回收和調撥等工作的統一管理，做到一個庫存管理所有車站;

3)各級操作權限集中管理，實現不同數據庫之間權限同步;

4)系統各類參數(權限參數、運營參數和設備控制參數)的統一設定與下發;

5)線網化模式下，各類業務報表的統一輸出;

6)對于各業務組常用的設備交易、卡交易等信息，屏蔽系統之間的切換，實現統一輸出。

2.2 系統構成

數據管理中心作為各線路集中管理的平臺，在沒有新的高性能硬件采購計劃的前提下，系統管理人員決定“就地取材”，選用原1號線小型機P650作為數據管理中心主機，并配置了磁盤陣列、磁帶庫、ACC接口服務器、數據采集服務器、Web服務器和報表服務器等設備。整個數據管理中心系統通過千兆以太網與線路中心進行數據交互，其構成如圖2所示。

圖2 數據管理中心系統構成

從圖2可以看出，該設計方案充分考慮了數據管理中心的穩定性和可擴展性。兩臺數據管理中心服務器實現雙機熱備，提供24×365全天侯服務;ACC接口服務器提供各線路與軌道交通清分中心的統一對賬接口，負責發送和接收參數、報文和對賬文件并解析入庫;數據采集服務將客流、結算匯總數據按線路采集到數據管理中心，從而上傳到ACC完成對賬以及報表展示;Web服務和報表服務器分別提供不同數據庫之間的同步和線網化報表的統一輸出。由于數據量最大的交易數據由各線路分別存儲，這樣一方面減小了數據管理中心對存儲設備的需求，也提高了交易數據的安全性。此外，該方案還保證了數據管理中心具有良好的可擴展性，當有新線路增加時，只需更改不同服務的配置文件就可完成線路服務器的接入。

2.3 重要模塊說明

2.3.1 ACC 接入服務

ACC接入服務，負責提供數據管理中心與ACC的統一接口，將各線路的對賬文件上傳至ACC，并接受ACC下發的對賬文件、票務報文和黑名單等參數。該服務程序由2部分構成，其中對賬程序將數據管理中心各線路結算數據打包生成對賬文件，并放在數據管理中心的大對象表中，由接口程序調用MQ文件傳輸服務，將該對賬文件發送至ACC。同時，接口程序又將ACC清分后的線網化客流和對賬文件傳輸至本地目錄，并解析進入大對象表，由對賬程序負責解析進入相關數據表。

2.3.2 數據采集服務

為了將不同線路的對賬文件統一由數據管理中心上傳至ACC，就需要將各線路的結算數據按線路放入數據管理中心，由數據管理中心負責打包上傳。數據采集服務的目的就是通過不斷輪詢各線路數據庫中的相關表，等到結算完成之后(一般是凌晨4:00)，將對應表中的數據抓取至數據管理中心，并對抓取成功的行進行標志位更新。更新的主要數據表有:JS_SETTLE_SUMMARIZING，JS_OD_DAY，JS_OD_HOUR，JS_SUMMARIZING_DATE，JS_FLUX。此外，為了提高處理性能，數據采集服務通過直連方式接入各線路中心，并可通過配置文件更改鏈接的數目，方便新線路開通時加入。

2.3.3 票務分離服務

票務分離主要針對車票管理而言，一期AFC系統通過車站與線路中心建同義詞的方式，實現車站和中心庫存的統一管理。這種中心和車站“綁定”的方式雖然提高了查詢效率，保證了中心和車站的絕對統一，但卻存在較大的安全隱患。因為如果中心數據庫出現異常或網絡故障，將導致所有車站無法進行售票員結算、車票配發、車站營收日報打印等基本票務操作。通過票務分離，車站基本票務操作在車站層完成，由服務程序采用報文的方式傳遞不同數據庫之間的庫存修改和報表信息，完成數據管理中心對車站車票的管理和相關報表的輸出。票務分離前后數據流動方式如圖3所示。

圖3 票務分離前后數據流動方式

2.3.4 權限和參數同步服務

AFC系統是一個有機整體，不同層級的用戶權限和系統參數必須保證高度一致。數據管理中心通過在線路和車站部署票務服務，實現不同數據庫之間的同步修改。當用戶系統權限發生改變時，由數據管理中心向線路或車站下發權限參數，部署在線路中心或車站的票務服務，對參數進行解析，并完成對本地數據庫的更改。此外，在數據管理中心部署Web服務，負責用戶密碼的同步。當用戶通過車站票務終端或者BOM修改密碼時，設備軟件通過調用統一的接口，完成對數據管理中心和車站數據庫的修改。

2.3.5 報表輸出服務

報表輸出是數據管理中心的重要功能之一，數據管理中心通過對不同報表進行分類，屏蔽對于用戶的使用差異，完成對線網化報表的統一輸出。對于與結算有關的報表，如《結算匯總表》《解行票款收入統計表》《設備票款差異匯總表》等，報表系統通過建物化視圖或數據管道將數據傳給數據管理中心;對于與庫存有關的報表，如《中心庫存日報》《中心出入庫統計表》等，則直接查數據管理中心的庫;對于原始交易有關的報表，如《TVM發售單程票明細》《AVM充值明細》和《設備壓數情況分析》等，因數據量大，所以通過建同義詞達到此目的;對于車站自動生成的報表，如《售票員結算單》《車站營收日報》《車站售存票日報》等，通過Web服務，直接將車站自動生成的報表數據插入到數據管理中心數據庫。

3 結語

隨著城市軌道交通行業的不斷發展，AFC系統“一線一中心”的建設方式已成為網絡化運營模式下集中管理的重要瓶頸。如何實現不同線路的集中管理和數據共享，是運營商不得不思考的問題。數據管理中心作為連接各線路的紐帶，提供了AFC系統與軌道交通清分中心的統一接口，實現了不同線路之間用戶和參數的同步，并通過部署數據采集、Web和報表等服務，完成對新線路的擴展和線網化報表的統一輸出。這些有益的探索，將是AFC系統線網化運營研究的寶貴經驗。

［1］趙時旻.軌道交通自動售檢票系統［M］.上海:同濟大學出版社，2007.

［2］丁耿，盧曙光，劉樂.深圳地鐵推行地鐵AFC系統的經驗教訓［J］.都市快軌交通，2007，20(2):97-99.

［3］裴順鑫，張寧.地鐵自動售檢票系統的互聯標準［J］.都市快軌交通，2007，20(5):38-41.

［4］范凡，鄭衍衡.基于Web Services的數據管理中心設計和實現［J］.計算機應用和軟件，2006，23(10):39-42.

［5］周巖.淺析建立軌道交通清分中心(ACC)的必要性［J］.現代城市軌道交通，2010，7(1):53-54.