北京轨道交通AFC2.0智慧票务系统研究

2022-10-27帅国莹成永彬陈少创

铁路通信信号工程技术 2022年10期

关键词：票务轨道交通乘客

帅国莹，张莉，成永彬，陈少创

（北京轨道交通路网管理有限公司，北京 100101）

1 北京轨道交通AFC系统现状及问题

1.1 AFC系统建设情况

北京轨道交通AFC系统建设从2006年引进日本、韩国、法国、澳大利亚厂商的系统、设备，到逐渐实现系统、设备的国产化，到2017年全网实现AFC系统、设备的标准化，再到2018年实现二维码过闸，整个系统的建设是一个逐步发展和完善的过程。

北京轨道交通AFC系统的建设可分为3大建设阶段。

第一阶段在2013年前，建设标准采用《ACC/AFC系统业务规则和技术规范》《AFC系统设计与实施规范》，统一标准读写器，实现全网互联互通。

第二阶段是2014～2015年，完成北京市轨道交通AFC技术改造一期工程，执行新票价方案，实现计程计时票制及累计积分优惠功能。

第三阶段是2015～2018年，完成北京市轨道交通AFC技术改造二期工程，建成AFC监视中心；建成运营公司MLC（II）系统。实现AFC系统全网SC系统软件和终端设备软件的标准化；实现一卡通低峰优惠和一卡通累积积分转移；实现交通部互通卡购票、充值、进站、出站、补票等业务；实现身高1.3 m以下儿童免费过闸；实现对全网AFC终端设备的状态监视。

另外，2018年后，北京如易行科技有限公司在公有云的基础上单独建设互联网业务平台，全网AFC系统各层级同步进行改造，逐步在全网范围内实现电子支付（微信、支付宝、银联云闪付、数字人民币）和二维码过闸。

目前，北京市轨道交通票务系统由AFC系统和互联网票务系统两部分组成，其中AFC系统由1个监视中心系统、1个清分系统、5个线路中心系统、400多个车站中心系统和约18 000多台终端设备组成；互联网票务系统由互联网业务平台、互联网业务交换平台和车站认证系统组成。

1.2 既有AFC系统目前尚存在的问题

北京市轨道交通2006年引进国外AFC系统，从初期的单线设置线路中心系统到引领全国建设热潮的多线路共用线路中心系统；从封闭的传统AFC系统到AFC系统与互联网票务系统共存；从单一的IC过闸到支持NFC手机、电子二维码、人体生物特征识别过闸；从单一的现金支付到实现微信、支付宝、银联云闪付、数字人民币等电子支付；率先实现全网车站系统和AFC终端设备软件的标准化，并完成轨道交通AFC监视中心系统的建设。以上变化体现了北京轨道交通管理者和建设者的智慧，起到了科技引领作用。

目前，北京市轨道交通AFC系统的运营管理水平和技术水平均已达到国际、国内领先水平，但AFC系统经过多次“打补丁式”的改造和升级，不可避免地会出现一些问题，不利于未来轨道交通智慧化的发展。

1.2.1 AFC系统与互联网票务系统分离，新增业务难度高、工作量大

AFC后台系统的主要功能定位是承担实体卡等传统票务业务处理工作，互联网平台的主要功能定位是承担互联网票务业务处理工作。AFC系统和互联网平台两套系统共用AFC系统建设的终端设备。现有AFC终端设备是在满足传统AFC系统业务功能基础上逐步扩展物联网票务功能，从而实现对传统实体卡业务和互联网业务的双重支持。

AFC系统的架构是基于20世纪90年代末和21世纪初的技术条件进行设计的，票务服务和系统功能以脱机为主、联机为辅；而互联网票务系统的票务服务和系统功能则以实时联机验证为主、脱机为辅。AFC系统和互联网票务系统对数据传输和检验的实时性要求冲突。由于互联网票务系统没有专用的终端设备，而是在AFC终端设备传统功能的基础上叠加互联网票务的相关功能，这种技术路线冲突的问题，造成传统AFC系统在应对互联网票务服务需求时，终端设备软件实现复杂，修改和调整难度大。每次终端设备的功能调整都需要对AFC系统和互联网系统的应用软件进行升级，并进行大量的功能测试，稍有不慎将可能给AFC系统引入一定的安全隐患。

从北京轨道交通既有票务系统架构可以看出，AFC系统和互联网平台系统的架构基本类似，均可分为车站级、线路级和路网级，两个系统独立建设、独立运营管理，这种多系统独立建设、打补丁的建设方式，造成整个票务系统的业务数据流向复杂、功能设置分散、内部接口众多，任何票务业务的修改或新增都需要AFC系统和互联网平台系统的同步开发、测试和升级，导致新开线路或新增业务时工作量大、周期长、投资高，出现问题的几率大，容易引发不可预知的故障。

1.2.2 系统层级多、数据分散，不满足轨道交通智慧化发展的要求

随着移动互联网的进一步普及和社会经济不断的发展，出行总量持续增加，交通需求从“走得了”逐步演化为“走得好”，人民群众对城市轨道交通安全、高效、舒适、经济多样化的要求越来越高，单纯的安全可达、方便快捷已难以满足地铁出行需求，出行品质正成为乘客关注的重点。随着移动互联网的进一步普及和发展，轨道交通的票务服务已从单一的传统IC卡转变为传统IC卡+互联网票务。服务模式也从“我们给什么，乘客用什么”转变为“乘客需要什么，我们提供什么”。

传统的AFC系统是根据各级企业的运营管理体制需求建设的，由监视中心、清算系统、线路中心系统、车站中心系统、终端设备5层架构组成，能满足各企业日常的运营管理的需要，但随着北京市轨道交通的线路逐渐增多和新业务不断增加，这种多层级系统的缺点也逐渐显现。

1.2.3 互联网票务全部承载于公网平台，存在一定的信息安全风险

随着二维码技术的发展和普及，2018年北京市轨道交通完成互联网票务系统建设。建设初期，由于无法预估使用互联网票务的客户量和服务量，为降低系统建设投资，将互联网票务系统架设于公网平台上。随着政府和乘客对信息安全的关注程度提高、二维码业务爆发式增长和人体生物特征识别过闸业务兴起，继续将所有互联网业务放置到公网平台上，一旦发生信息泄露，造成的社会影响不可估量。

因此，从提升运营安全、信息安全管控等角度出发，也亟需将互联网票务转移至北京市轨道私有云，在公网平台仅保留必要的客户管理功能。

2 AFC2.0智慧票务系统研究目标

随着乘客对地铁出行智慧化要求的提高，AFC系统也需要不断变革。乘客由原来的纸票乘车，到使用实体卡乘车，到使用二维码乘车，随着社会的发展和老百姓的需要，未来AFC系统需要满足乘客的刷脸乘车、电子身份证乘车等需求。为快速满足乘客需要，AFC系统需由原来的各层系统更改程序来实现功能进而提供服务的方式，改变为由中心提供服务规则，系统设备自动识别并提供服务的方式。提高系统的自我适应和调整的能力，减少投资成本，提高服务效率。

AFC2.0智慧票务系统研究目标，是将AFC传统票务业务和互联网票务业务融合，重点考虑未来AFC智能化管控需求，采用云计算技术架构，结合大数据分析、人工智能技术，构建一体化、数字化、智能化的AFC2.0智慧票务系统。

3 AFC2.0智慧票务系统研究内容

研究传统票务和互联网票务基础数据格式，服务功能和服务部署方式，进行统一设计。

研究AFC2.0云平台结构，将目前互联服务平台预付费系统、后付费系统、非现金支付系统、电子发票系统、亿通行APP后台系统、一码通系统、SC系统、MLC系统等服务系统进行迁移，建设智慧票务系统，与ACC系统通过接口连接进行票务数据交互。

研究智慧票务平台在AFC2.0系统内的部署，所有应用都采用多点部署方式，防止单点故障造成系统服务中断，系统每一种应用服务部署的数量根据数据量和处理性能的要求，进行弹性部署，但每种应用至少部署在两台服务器上，保证高可用性。

研究智慧票务平台与内部和外部的接口，通过云中心系统统一的接口服务集群，实现数据通信和数据交换，包括对内其他系统的数据接口，如ACC系统接口、大数据中心系统接口等；对外部的一卡通接口，第三方支付接口等；保证互联网的安全接入，支撑亿通行APP，为乘客提供移动售检票服务。

研究智慧票务平台多元化票务体系的完善，基于用户账户体系，丰富票务介质，如人脸、NFC等；大数据分析下，不同乘客，不同线路，月票、季票、次票等个人定制化票务服务，既满足乘客定制化出行需求，又能帮助空闲运力转化为票务收入；推出标准化线上票务服务产品，可实现票务服务标准输出；以地铁为城市服务主干网，打通航空，铁路、出租等周边交通场景，实现跨场景票务服务；将生活服务和地铁票服务打通，使生活服务的优惠措施与乘车费用支付融合挂钩，实现乘客乘车优惠与生活服务商业化场景的融合发展。

4 AFC2.0智慧票务系统研究路线

4.1 票务系统融合

研究目前传统票务系统和互联网票务系统数据格式的差异，详细分析各基本数据的需求，统一数据格式，形成智慧票务系统标准数据源。

研究目前传统票务系统和互联网票务系统的服务分类、服务功能，归纳相同功能的服务，进行服务的融合。

研究目前传统票务系统和互联网票务系统的应用部署架构，基于云平台的技术，将两个系统的应用部署方式及应用类型统一，完成系统架构的融合。

研究目前传统票务系统和互联网票务系统的系统功能设计，统一规划设备管理功能、客流管理功能、票卡管理功能、应急管理功能、客户服务功能、票务服务功能、运营管理功能等系统功能，完成系统功能的融合。

研究目前传统票务系统和互联网票务系统的接口设计，统一规划智慧票务平台的内部和外部接口，实现接口标准统一。

4.2 智慧票务多元化服务

运用大数据分析，研究乘客画像的建立，包括数据来源、数据分析、数据标签的建立、数据标签的更新等，根据乘客画像数据，为乘客自动匹配最便捷、最优惠的票务服务。

通过需求调研，进行乘客期望的多元化票务服务研究，并通过乘客画像数据和票务数据，分析新业务上线后的受益人群范围，预测受众群体及新业务上线的使用量，为业务上线的研判提供更多的数据支撑。

通过调研其他轨道交通城市的现状和相关文献查阅，研究未来更适应地铁场景的票务媒介，结合多元化票务服务，带来更便利、更高效的出行体验。

研究航空、公交车、出租车等市内交通场景的特点，结合轨道交通场景的特点，推出跨场景的票务服务。研究围绕轨道交通覆盖范围内的其他生活场景，将生活服务与乘车服务有机结合，实现跨场景的服务融合。

5 AFC2.0智慧票务系统

5.1 系统架构

智慧票务系统架构分为4层，如图1所示，包括数据接入层、数据层、计算服务层和应用展现示层。

5.1.1 数据接入层

数据接入层实现中心系统与终端设备的数据通信，实现对终端系统的控制和业务数据的采集。系统数据接口包括内部系统的数据接口和与外部系统的数据接口。

5.1.2 数据层

数据层包括生产数据和历史数据两大部分。生产数据包括设备、交易、支付等支撑AFC日常业务运行的当前阶段的数据；历史数据则包括较长时间的业务历史数据，用于AFC业务大数据分析，这些数据至少应该保留3年。

5.1.3 计算服务层

计算服务层包括AFC业务服务、实时计算平台、智能数据平台和互联网服务平台4个部分。

1）AFC业务服务为设备管理、客流监视、票卡管理等各项AFC业务提供后台服务支撑，实现这些业务流程的管理功能和信息查询统计。

2）实时计算平台提供实时计算服务，通过对从设备上传的交易、状态数据的实时处理和计算，为AFC即时业务统计、大屏幕监视等业务需求提供设备故障告警、实时客流、动态票卡库存等实时数据支持。

3）智能数据平台通过对设备使用、故障、客流、乘客记录等长时间历史数据的大数据分析，对设备故障规律、设备使用规律、客流规律、乘客风险等进行数据挖掘，支撑AFC设备智能化管控、智能化维修，以及智能化乘客服务。

4）互联网服务平台提供互联网APP用户管理、支付服务、客户服务、发票管理等后台服务，为手机APP乘客提供后台服务支撑。

5.1.4 业务展现层

业务展现层主要是通过工作站、移动终端为内部管理客户提供客流监视、设备管理、票卡管理、设备智能管控等业务管理界面，通过大屏幕提供集中监视大屏幕显示功能，通过手机端亿通行APP为乘客提供互联网票务服务。

5.2 内外部接口

搭建专用接口服务，统一进行内部接口和外部接口的对接，根据传输数据的特点，通过FTP，MQ，Socket等方式进行数据交互，规范数据接口的对接工作，减少系统的复杂性。改变原来因建设时期不同，传统票务系统和互联网票务系统各自进行内外部数据接口对接的现象。

5.3 多元化票务服务

按照现有的数据格式内容，对原始数据进行采集、存储。通过对采集到的数据进行清洗，结合地铁乘车的业务场景，给乘客账户粘贴不同的标签，如常用站点、通勤站点、上/下班时间、居住区域等。用丰富的标签构建精准的乘客画像，根据乘客的乘车习惯，给乘客推荐更优惠便捷的乘车方案。若乘客每月乘坐机场线次数大于10次，则给乘客推荐机场线计次票，10次即可省50元，且用的次数越多省的越多。

用户画像的完善可给运营管理人员提供更多的票务分析规划依据，根据乘客的乘车规律，推出适合大部分乘客的乘车方案，实现“乘客需要什么，我们提供什么”。