基于“互联网+”的轨道交通互联网票务系统平台

2019-08-13李兆君马曾卓

设备管理与维修 2019年7期

李兆君，张建，马曾卓

（1.合肥城市轨道交通有限公司，安徽合肥 230000；2.南京熊猫信息产业有限公司，江苏南京 210000）

0 引言

在随着“互联网＋”和智慧城市建设发展，国内轨道交通自动售检票系统（AFC）新技术发展迅速，国内各地铁城市开始推出新型支付模式，目前较多城市实现了将二维码支付成功运用于地铁票务中，有效解决了排队购票、零钱难兑、票款清点、加币加票等问题，减少人力、设备、票卡、解行等成本，“刷码过闸，先乘后付”大大方便了乘客。新技术引发自动售检票系统的升级换代，互联网票务系统应运而生，如何构建互联网票务系统平台也提上行业主管部门和地铁公司的管理日程[1-2]。

1 定义

所谓互联网票务就是采用各种互联网技术手段实现票的虚拟化、数字化，互联网票种分为多种介质，目前主要包括4类：二维码；NFC，分银联闪付卡，手机PAY，智能穿戴式设备，如智能手环、智能手表；生物特征识别，如人脸、掌纹、声纹、虹膜；二维码+蓝牙等。基于以上多种新型的介质实现的虚拟化、数字化票种统称为互联网票务。而在互联网票务使用、运营过程中提供各种管理功能的信息系统称为互联网票务系统平台。

2 设计原则[3]

2.1 系统可靠性原则

系统架构健壮、运行稳定、功能可靠。支持通过容错、热备、故障恢复等，在系统故障时能保持正常工作，确保数据不因意外情况丢失或损坏。

2.2 系统安全性原则

系统的设计、开发、制造、调试和维护的全生命周期，体系应符合《信息安全等级保护管理办法》信息安全等保三级的标准要求，遵循国家网络安全设计规范，系统关键信息进行机密管理，系统数据完整、防非法修改。

2.3 系统扩展性原则

系统应具备在用户量、业务量增大时，具备规模扩展性，能快速响应业务需求的变化。系统采用松耦合构件方式进行设计，对应用功能的扩展可采用发布新构件方式实现，且新功能的部署不影响客户的使用。

2.4 系统开放性原则

系统的主要功能、数据应具备开放性，通过标准或通用的接口向外部提供数据和功能的支持，且对接口有安全性的保护控制。可通过接入各城轨互联网票务平台实现乘车功能的互联互通。

2.5 实名制及信用消费原则

要求接入互联网票务平台的移动应用，需遵循互联网票务实名制安全要求，在申请开通服务时，根据互联网票务平台的接口要求，提供用户的实名信息，确保互联网票务运营的安全。在实名制的前提下，采用信用消费模式，通过后台行程匹配及计费来实现先乘车后付费。

2.6 业务安全及独立性原则

互联网票务平台应是独立的，以保障业务数据的安全性。业务密钥使用城轨企业ACC私有密钥，确保城轨企业对业务的主控权。应具备独立发码能力，同时支持国家其他行业、交通部的发码要求，支持转码方式，在保障业务安全、独立性情况下，支持行业兼容及业务拓展。签名密钥算法应选用国密算法，可采用基于非对称SM2算法或/和3DES的对称签名，在保障密钥安全的同时实现对脱机生码模式的支持。

另外，平台还要具有经济性、通用性、前瞻性，以实现平台适应发展的需求。

3 平台构建

如何构建互联网票务系统平台，根据互联网票务的特性，结合城轨AFC系统的定位，以合肥轨道交通二维码扫码过闸建设为例来说明。

3.1 系统关键指标

关键指标主要有两个方面，一是可靠性指标，如可用性≥99.9%，MTBF＞6个月，MTTR＜0.5 h，可连续 7×24 h 工作。二是二维码事务处理性能指标，如电子票读写处理时间≤400 ms，读写距离≥60 mm，过闸通过能力≥60人/（min×通道）。信息传输性能：实时时钟同步误差≤1 s；交易数据和状态数据上传间隔时间≤1 min，其他数据≤15 min；命令响应时间≤2 s；状态改变的响应时间≤1 s[4]。

3.2 构建系统平台

3.2.1 平台功能及域界面

互联网票务平台实现对传统票务、新型互联网票务的业务能力支持。对互联网票务业务进行管理，包括数字票务系统、二维码管理系统；同时对AGM、BOM进行改造，实现对传统票务、互联网票务的乘客事务处理；新建城轨APP，提供用户实名认证管理、二维码扫码乘车、移动支付及城轨企业特色服务等。业务功能包括用户系统、结算系统、报表系统、参数系统、风险管理系统等，管理各个子系统的帐号、密码、权限等，以及各个子系统计划任务。各平台域界面如图1所示。

图1 各平台域界面

3.2.2 软件架构

本次二维码过闸业务采用APP客户端与支付宝签约代扣协议来实现扣费过闸，用户只需在手机APP上注册生成二维码即可在车站闸机上扫码进出车站。处于业务核心的支付平台首次采用私有云zstack、redis实时数据库、MQ消息队列、F5负载均衡器等技术实现对大客流、多设备的压力处理，为合肥地铁开启了新技术应用的先河。同时在系统架构设计时考虑到远期其他支付机构接入，在设计二维码机构中支持多种APP和支付结构的接入，在系统设计支持未来五条线的客流量和并发数。同时系统采用云技术增强系统的可扩展性，也为后期接入创造便利条件[5]。平台业务架构如图2所示。

图2 系统平台架构图

3.2.3 云平台架构

按照传统架构+互联网私有云架构的模式进行系统设计，硬件设计考虑了功能模块化布置的需求，具备堆砌式扩展的能力，同时系统安全采用三级等保，分为互联网接入区、AFC系统网络接入区、云平台服务器区和安全运维管理区等4个区域。

3.2.4 APP过闸业务流程

合肥轨道交通二维码过闸技术于2018年12月24日，在1、2线正式上线公测，可适用Android和IOS系统手机，用户操作流程如图3所示。

图3 用户操作流程

二维码过闸门业务流程，用户打开合肥地铁APP，展现乘车码→用户在闸机上的二维码读头上实现拍码支付，闸机对二维码验证，有效后放行→闸机将本次交易信息实时推送给移动支付平台→移动支付平台将交易信息转发给第三方开放平台→第三方平台将乘车信息推送给合肥地铁APP→移动支付平台进行行程匹配并向第三方平台发起支付。流程简图如图4所示。

图4 二维码过闸进出站流程

4 接口要求

4.1 平台与ACC接口

城轨互联网票务平台与 ACC接口主要包括二维码交易对账、同步实名认证用户信息接口，包括接口协议、交易对账流程。

4.1.1 接口协议

接口协议包括文件传输及存取方式、文件列表、文件格式。平台与ACC对账数据接口采用文件格式，采用HTP传输方式，传输中文件以.tmp作为后缀，传输完成后删除后缀。文件格式可分为二维码行程文件、日终行程调整交易文件、单边交易文件、差异交易及调整文件、以及用户实名认证信息文件等。

4.1.2 交易对账

主要是平台与ACC对账，平台接收终端实时上传过闸数据，进行运营日间和日终处理，与ACC各类交易数据对账，进行差异调整处理。

4.2 平台与AGM接口

平台与AGM的接口主要由指令接口定义、交易接口协议两部分组成。

4.2.1 指令接口定义

指令接口定义包括指令码定义、客户端注册、心跳检测、终端交易控制参数下载、扫码数据实时上传、扫码联机验证、发码机构公钥证书下载等。

指令码定义是对各种指令代码功能进行定义，如A1H表示心跳检测。客户端注册、心跳检测、终端交易控制参数下载、扫码数据实时上传、扫码联机验证、发码机构公钥证书下载是对本类指令定义、确定请求和返回数据格式进行规定。同时处理原则和异常情况处理进行规定。

4.2.2 交易接口协议

交易接口协议包括通信协议格式、报文格式、报文数据元说明、指令错误返回码定义以及安全要求等。

通信协议格式约定基于TCP/IP协议，交互采用长、短连接方式，报文（包括请求及应答）数据元采用key=value的形式组织，并以&作为连接符拼接成字符串进行编码，在数据包最后使用进行标识。数据集合（ARRAY）类型的数据元名称采用英文大括号{}进行包括，各个数据子集之间采用#进行分隔。接口服务方、发起方在建立通信连接后，通过指定端口与服务程序进行连接。交互采用申请↔应答交互方式进行，应答报文将以同步响应的方式返回给请求方，每次交互设置交易时限，超时失败。

为了防止通信过程中报文信息被恶意篡改，除特殊要求外，双方通信报文要签名，交易请求方实现对请求报文签名，交易服务端对签名进行验证，签名不合法的请求将会被拒绝。以保证通信交易的安全性。

4.3 平台与BOM的接口

平台与BOM的接口主要由实时交易接口定义、交易接口协议两部分组成。

4.3.1 实时交易接口定义

实时交易接口定义主要由用户信息查询、用户行程查询、客服行程补登、客服行程撤销、代申请出站凭证等组成。每部分又分别由接口功能描述、请求和应答报文定义组成。

4.3.2 交易接口协议

交易接口协议由接口协议格式、交易报文结构、公共报文信息、报文数据元说明，以及安全要求组成。平台与BOM的交易接口实现采用HTTP作为传输协议，json作为传送信息的编码格式，接口服务提供方实现接口服务程序。交易报文结构，双方交换的消息报文以json格式。公共报文信息由HTTP请求头与应答头，请求公共参数与应答公共参数组成。同样为了防止通信过程中报文信息被恶意篡改，通信报文要签名机制，交易双方分别报文签名和验签，以保证通信交易的安全性。