

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

李兆君¹张建² 马曾卓¹

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

摘要：在“互联网＋”和智慧城市建设发展背景下，轨道交通自动售检票系统（AFC）新技术发展迅速，本文以基于二维码的互联网票务建设为例说明，从平台定义、设计原则、平台构建、接口要求、互联互通等方面阐述平台的构建，同时对管理要求进行探讨。有效解决了排队购票、零钱难兑、票款清点、加币加票等问题，减少了人员定编、建设运营成本、现金管理、设备维护、票卡流通等压力，“扫码过闸，先乘后付”大大方便了乘客体验，提升了城市品质和管理服务水平。

关键词：设计原则；平台构建；互联网+；票务；二维码；接口；互联互通

Construction of Internet ticketing system platform based on "Internet +"
Li Zhaojun¹,Zhang Jian²,Ma Zengzhuo¹

1.Hefei urban rail transit Co., Ltd. 2. Nanjing panda information industry Co., Ltd)

Abstract: Under the background of"Internet +"and the development of intelligent city construction, the new technology of automatic fare collection system (AFC) for rail transportation has developed rapidly. The paper studies the construction of QR code in Internet ticketing, from the aspects of definition, design principles, platform construction, interface requirements, interconnectivity and so on. At the same time, the management requirements are discussed. It has effectively solved the problems of queuing up to buy tickets, no change given, checking the change, adding coins and tickets, etc. The development of Platform is reducing the pressure of employee problems, construction and operation costs, cash management, equipment maintenance and the circulation of tickets. Passenger rides the metro through the QR code mode is very convenient to enjoy the trip first and pay later, which improved urban quality and management services.
Keywords: design principles; platform construction; "internet +";ticket; QRcode; Interface; Interconnection

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

1 定义

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

2 设计原则^[3]

互联网票务系统平台的设计，一般要满足以下6个方面的特性及原则：

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.5h，可连续7×24h工作。二是二维码事务处理性能指标，如电子票读写处理时间≤400ms，读写距离≥60mm，过闸通过能力≥60人/（分钟×通道）。信息传输性能：实时时钟同步误差≤1s；交易数据和状态数据上传间隔时间≤1min，其他数据≤15min；命令响应时间≤2s；状态改变的响应时间≤1s^[4]。

3.2 构建系统平台

3.2.1 平台功能及域界面

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

图1 各平台域界面

3.2.2 软件架构

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

图2 系统平台架构图

3.2.3 云平台架构

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

图3 云平台网络拓扑图

3.2.4 APP过闸业务流程

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

图4 用户操作流程图

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

图5 二维码过闸进出站流程简图

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 的形式组织，并以&作为连接符拼接成字符串进行编码，在数据包最后使用r\\n进行标识。数据集合(ARRAY)类型的数据元名称采用英文大括号{}进行包括，各个数据子集之间采用#进行分隔。接口服务方、发起方在建立通讯连接后，通过指定端口与服务程序进行连接。交互采用申请↔应答交互方式进行, 应答报文将以同步响应的方式返回给请求方，每次交互设置交易时限，超时失败。

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

4.3 平台与BOM的接口

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

4.3.1 实时交易接口定义

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

4.3.2 交易接口协议

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

4.4 城市间互联互通

各城市轨道交通互联网票务平台要预留互联互通接口，以方便实现城市间互通，为跨区域出行人员提供便利。可以采用SDK调用方式实现，可实现进行对账和清算。

5 管理要求

5.1 对账业务管理

互联网票务交易数据能够实现云平台、ACC以及第三方支付平台间进行对帐，以ACC数据为主；平台提供清结算报表，数字票务系统对行程匹配、计费；平台通过终端补登、撤销时，数据同步上传ACC，ACC对交易数据进行复核；数据传输过程要对敏感信息加密，MAC验证、TAC验证，采用专线传输时可以不加密。

5.2 运营服务管理

对互联网用户统一管理，实现乘客信息、行程查询及处理；为客户提供服务支持，如咨询、注册、注销、扣费等；支持双脱机模式。

5.3 应急处置管理

制订系统故障和大面积终端故障时的应急处置预案，明确岗责、明确流程；人员引导、标识引导、广播告知、官网通知；启动传统售检票模式；如果传统设备也大积故障，必要时启动纸票，以限流、分流为宜，引导快速通行离站为主。

6 结束语

引入“互联网+”便捷交通理念，以智慧出行服务为宗旨，颠覆了传统地铁票务模式，减轻了地铁建设、运营成本、现金管理、设备维护等压力，同时为乘客提供了更加便捷的乘车体验，在智慧城市建设过程中，提升了城市品质和管理服务水平。

参考文献