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

1 引言

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

2 互联网+地铁票务云ACC平台研究

2.1 云ACC平台概述

云ACC 平台将采用云架构体系实现，在原有票卡系统外建立起云平台的4 层体系❥：整个云平台将分为第三方对接系统，云中心系统，云票务处理系统与云终端管理系统四大层次。每一个系统层次内还包含了不同的应用系统，所有的系统之间采用接口进行数据交互以便于进行系统的可持续化扩展。

另外，系统建立起一套完整的、可扩展的接口数据规范，规范包含了数据结构规范、传输与响应规范、安全与认证规范几部分。通过接口将不同的系统整合起ซ来，并最终实现整个平台的有机运行。

平台系统需要与现有的AFC 系统进行对接，以进行交易数据的对帐以及云闸机数✯据的清分等操作，对接操作核心要求是安全与数据完整。通过实现系统对接使得整个云平台系统真正结合入地铁日常业务系统中。

2.2 云ACC平台系统设计

2.2.1 整体设计

系统整体将参照现有的轨道交通ACC 四层结构，并针对性地做出优化与设计。新系统采用两层物理逻辑架构搭建，在云ACC 中心虚拟出SC 与LC 层，用以结合到现有的传统ACC 架构中，进行日常管理与控制。

系统将使用TLS 实现数据传输加密，并可以记录所有的数据操作日志以便于进行安全审计。所有的接口进行负载均衡，并进行双机热备以使得系统支持7*24小时的不间断服务。设备端，考虑到地铁服务的特殊性，云匣机需要支持一定程度的孤岛模式，在设备离线的情况下或者紧急情况下，云匣机可以进行基础的票务验证以进行人员的放行。另外，所有的设备端需要支持轨道交通的运营事件，通过帐号权限细分，可以通过在站点设置管理平台的方式实现SC 层级的操作管理。

系统设计与开发将采用MVC+WebAPI 的方式，不同接口之间使用JSON 数据格式进行交互，核心数据库使用MySQL 实现主从数据库双在线，数据缓存使用redis，消息中间件使用AMQS 协议的RabbitMQ 组件。设备端，iTVM 与云匣机设备直接通过专用100MB 网络连接至云ACC 中，实现与服务器端的实时交互，通过系统设计实现500ms内的交互响应，云BOM-PAD 实现扫码与客服的功能。

2.2.2 应用拓扑

2.2.3 核心功能需求分析

互联网购取票机。用户可以过网上购票，线上支付，或者现场通过手机支付，线下终端取票入站的流程进行地铁票卡的购买，支付方式包括微信支付、支付宝支付、银联支付、市民卡支付等方式，票卡包括单程票、单日票、月票、纪念票等。

云闸机。系统需要在现有的闸机端添加新的云闸机以支持用户使用二维码扫码入闸功能。用户使用手机APP，注册用户帐户并关联支付方式。在入站时，用户在云闸机端扫描APP 产生的二维码，云闸机在服务器端验证后放行用户，并且用户在出站时在出站闸机扫描二维码以实现出站，服务器端在验证后直接扣取用户的乘车费用。

用户二维码通过安全算法，基于信用体系实现。使得二维码可以在一定时间内脱机实现，即使扫码时用户手机不在线，也可以正常进出闸机，并可以正常扣款。

用户每一次进站首先需要将未正常扣款的订单通过客服或者自助处理完成。当用户存在低信用时，系统将会禁止用户扫码入站，而建议用户通过iTVM 设备买卡进入。

云对帐平台。云ACC 的核心功能

就是对产生的所有交易进行对帐、核销与清分操作，其中对帐平台的核心功能是自动化对接所有的对帐平台，包括第三方支付平台，轨道交通AFC 中心等，实现交易收入、票卡支出的所有交易信息的处理。并自动化产生交易大数据与对帐信息，最终实现数据的可视化分析等功能。

乘客事务处理。当用户发ผ生无法出/ 入站时，需要向当前站点的客服中心请求处理。每一个客服中心配备1-2 台手持式PAD处理终端，通过终端客服人员可以在用户提供用户信息、交易信息、出入信息等前提下，对用户进行客服事件处理。具体事件处理参照现有的完整乘客事务处理的意见表格，对它进行完善✍与修改。

2.3 云ACC平台安全策略

2.3.1 电子票密钥与管理

电子票务在进行发放前，需要向票卡安全中心申请一个动态加密密钥，密钥有效期为26 小时，应用系统刷新期为24 小时。所有的电子二维码在生成时，需要进行一次密钥的加密，终端设备在扫描到二维码等电子密钥时，首先需要通过密钥对电子票卡进行有效性验证，然后再向服务器端进行订单、信用等在线信息的认证。

当系统产生大规模网络失效时，密钥系统可保证电子票务的线下有效性。

2.3.2 办公网与专网的设计

系统建立在专网内，专网环境由宁波轨道交通办公网提供基础网络结构，通过添加相应的互联网设备实现专网拓扑结构。由于整个系统需要与第三方支付平台进行对接，而第三方支付平台存在于互联网内，考虑到整体系统的安全性与完整性，所有的第三方支付平台通过云ACC 下的第三方支付网关统一接口、统一管理与维护，以实现系统的网络安全。

2.3.3 传输套接字层加密与数据加密

整个平台采用HTTPS 进行传输层的数据加密，以防止数据被窃听，协议采用TLS2.0方案。

在数据提交时，平台接口针对提交的数据域进行AES 对称加解密，加解密部门包括密钥Key 与加密向量VI，加密向量在终端授权进入平台时配置，密钥Key 由终端向服务器端动态申请，具备唯一性。

2.3.4 终端支付与唯一性网络设计

有别于目前其他轨道交通终端双网络等结构的差异，云ACC 下属终端只使用系统专网联系，所有的支付业务通过云ACC 统一接口，终端本身不存在与外界的连接，以保障终端的网络安全性。

2.3.5 唯一流水码设计

由于网络传输的不稳定性，存在小概率状况下的数据丢包现象。为了保证数据的完整性与一性，针对交易流水请求中设计一个唯一流水码功能，每一次重点请求将会附带一个唯一流水码，当服务器发现存在相同的流水码时，直接通过原始响应处理，而不进行新的交易操作，以解决由于网络问题产生的重复提交而导致交易流水的混乱。

3 结语

文章对互联网+ 传统AFC 行业的结合做出了初步探索，提出了云ACC 平台的概念，通过互联网 +支付的应用设想，期待推动传统AFC 行业的发展。未来通过研究，将继续完善云ACC 平台的安全策略，规范互联网票务的业务流程，并对核心功能进行优化，通过建立账户体系对互联网票务营销深度开发，促进传统轨道交通票务业务转型升级。