基于互联网+ 的地铁票务云ACC 平台探究

1、基于互联网+ 的地铁票务云ACC 平台探究1 引言在整个轨道交通系统中，自动售检票(AFC) 系统承担着重要的角色，它实现了自动售票、自动检票，和计费、收费、统计、结算等全过程的自动化管理。随着科学技术的开展，AFC 系统呈现多种类型，主要取决于支付方式应用技术的多样化。目前AFC 系统中采用的支付方式，包括硬币支付、纸币支付、储值票支付、车票圈存支付和银行卡支付等。近年来，挪动互联网的迅猛开展，在线支付作为一种新型的支付方式，因其便捷性，逐渐占据人们各种生活消费场景。如何结合挪动互联网电子支付技术，对整个线网的AFC 系统规划布局，满足网络化运营需求，如何结合挪动互联网在线支付技术在系统中的

2、应用，对传统AFC 系统进展优化，成为了亟需解决的问题，而云ACC平台正是这样一套完好的解决方案。2 互联网+地铁票务云ACC平台研究2.1 云ACC平台概述云ACC 平台将采用云架构体系实现，在原有票卡系统外建立起云平台的4 层体系：整个云平台将分为第三方对接系统，云中心系统，云票务处理系统与云终端管理系统四大层次。每一个系统层次内还包含了不同的应用系统，所有的系统之间采用接口进展数据交互以便于进展系统的可持续化扩展。另外，系统建立起一套完好的、可扩展的接口数据标准，标准包含了数据构造标准、传输与响应标准、平安与认证标准几部分。通过接口将不同的系统整合起来，并最终实现整个平台的有机运行。平台

3、系统需要与现有的AFC 系统进展对接，以进展交易数据的对帐以及云闸机数据的清分等操作，对接操作核心要求是平安与数据完好。通过实现系统对接使得整个云平台系统真正结合入地铁日常业务系统中。2.2 云ACC平台系统设计2.2.1 整体设计系统整体将参照现有的轨道交通ACC 四层构造，并针对性地做出优化与设计。新系统采用两层物理逻辑架构搭建，在云ACC 中心虚拟出SC 与LC 层，用以结合到现有的传统ACC 架构中，进展日常管理与控制。系统将使用TLS 实现数据传输加密，并可以记录所有的数据操作日志以便于进展平安审计。所有的接口进展负载平衡，并进展双机热备以使得系统支持7*24小时的不连续效劳。设备端

4、，考虑到地铁效劳的特殊性，云匣机需要支持一定程度的孤岛形式，在设备离线的情况下或者紧急情况下，云匣机可以进展根底的票务验证以进展人员的放行。另外，所有的设备端需要支持轨道交通的运营事件，通过帐号权限细分，可以通过在站点设置管理平台的方式实现SC 层级的操作管理。系统设计与开发将采用MVC+WebAPI 的方式，不同接口之间使用JSON 数据格式进展交互，核心数据库使用MySQL 实现主从数据库双在线，数据缓存使用redis，消息中间件使用AMQS 协议的RabbitMQ 组件。设备端，iTVM 与云匣机设备直接通过专用100MB 网络连接至云ACC 中，实现与效劳器端的实时交互，通过系统设计实

5、现500ms内的交互响应，云BOM-PAD 实现扫码与客服的功能。2.2.2 应用拓扑2.2.3 核心功能需求分析(1)互联网购取票机(iTVM)。用户可以过网上购票，线上支付，或者现场通过支付，线下终端取票入站的流程进展地铁票卡的购置，支付方式包括微信支付、支付宝支付、银联支付、市民卡支付等方式，票卡包括单程票、单日票、月票、纪念票等。(2)云闸机。系统需要在现有的闸机端添加新的云闸机以支持用户使用二维码扫码入闸功能。用户使用APP，注册用户帐户并关联支付方式。在入站时，用户在云闸机端扫描APP 产生的二维码，云闸机在效劳器端验证后放行用户，并且用户在出站时在出站闸机扫描二维码以实现出站，效

6、劳器端在验证后直接扣取用户的乘车费用。用户二维码通过平安算法，基于信誉体系实现。使得二维码可以在一定时间内脱机实现，即使扫码时用户不在线，也可以正常进出闸机，并可以正常扣款。用户每一次进站首先需要将未正常扣款的订单通过客服或者自助处理完成。当用户存在低信誉时，系统将会制止用户扫码入站，而建议用户通过iTVM 设备买卡进入。(3)云对帐平台。云ACC 的核心功能就是对产生的所有交易进展对帐、核销与清分操作，其中对帐平台的核心功能是自动化对接所有的对帐平台，包括第三方支付平台，轨道交通AFC 中心等，实现交易收入、票卡支出的所有交易信息的处理。并自动化产生交易大数据与对帐信息，最终实现数据的可视化

7、分析等功能。(4)乘客事务处理。当用户发生无法出/ 入站时，需要向当前站点的客服中心恳求处理。每一个客服中心装备1-2 台手持式PAD处理终端，通过终端客服人员可以在用户提供用户信息、交易信息、出入信息等前提下，对用户进展客服事件处理。详细事件处理参照现有的完好乘客事务处理的意见表格，对它进展完善与修改。2.3 云ACC平台平安策略2.3.1 电子票密钥与管理电子票务在进展发放前，需要向票卡平安中心申请一个动态加密密钥，密钥有效期为26 小时，应用系统刷新期为24 小时。所有的电子二维码在生成时，需要进展一次密钥的加密，终端设备在扫描到二维码等电子密钥时，首先需要通过密钥对电子票卡进展有效性验

8、证，然后再向效劳器端进展订单、信誉等在线信息的认证。当系统产生大规模网络失效时，密钥系统可保证电子票务的线下有效性。2.3.2 办公网与专网的设计系统建立在专网内，专网环境由宁波轨道交通办公网提供根底网络构造，通过添加相应的互联网设备实现专网拓扑构造。由于整个系统需要与第三方支付平台进展对接，而第三方支付平台存在于互联网内，考虑到整体系统的平安性与完好性，所有的第三方支付平台通过云ACC 下的第三方支付网关统一接口、统一管理与维护，以实现系统的网络平安。2.3.3 传输套接字层加密与数据加密整个平台采用 S 进展传输层的数据加密，以防止数据被窃听，协议采用TLS2.0方案。在数据提交时，平台接

9、口针对提交的数据域进展AES 对称加解密，加解密部门包括密钥Key 与加密向量VI，加密向量在终端授权进入平台时配置，密钥Key 由终端向效劳器端动态申请，具备唯一性。2.3.4 终端支付与唯一性网络设计有别于目前其他轨道交通终端双网络等构造的差异，云ACC 下属终端只使用系统专网联络，所有的支付业务通过云ACC 统一接口，终端本身不存在与外界的连接，以保障终端的网络平安性。2.3.5 唯一流水码设计由于网络传输的不稳定性，存在小概率状况下的数据丢包现象。为了保证数据的完好性与一性，针对交易流水恳求中设计一个唯一流水码功能，每一次重点恳求将会附带一个唯一流水码(GUID)，当效劳器发现存在一样的流水码时，直接通过原始响应处理，而不进展新的交易操作，以解决由于网络问题产生的重复提交而导致交易流水的混乱。3 结语文章对互联网+ 传统AFC 行业的结合做出了初步探究，提出了云ACC 平台的概念，通过互联网 +支付的应用设想，期待推动传统A