深圳地铁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.