AFC系统可配置数据/服务交换平台的思考
2015-10-31何铁军
王 健 张 宁 何铁军
(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