文/张鹏 陈园园 余乐

在“互联网＋”时代大背景下，以手机扫码过闸为代表的新型移动支付技术在轨道交通领域得到迅猛发展，它既能有效解决地铁售检票系统存在的购票效率低、客流高峰期排队购票时间长、车票单次使用成本高等问题，又能丰富地铁票务系统的支付形式，为乘客提供更好的便捷出行服务。

在新技术应用的同时，移动支付手段可谓百花齐放，各城市应用情况各异，技术路线也各不相同，缺乏统一的数据格式和接口，城市间不能实现互联互通，为城轨企业运营管理水平和乘客满意度提升带来新的挑战。本文以南京地铁AFC系统移动支付升级改造工程应用为例，对城市轨道交通互联网票务指南中的二维码标准理念进行阐述，分享南京地铁互联网票务系统建设经验，以便于大家共同学习与探讨。

南京地铁互联网票务系统的发展经历了两个阶段。第一阶段为二维码购票技术试点；第二阶段为移动支付过闸技术推广。

·2017年9月31日南京地铁在3号线大行宫站、南京站和南京南站试点投放互联网售票机，乘客可使用支付宝APP扫码并支付购买单程票。该阶段引入了支付宝当面付技术，摒弃了在互联网上购买车站到车站取票的方案。对移动支付技术引入南京地铁自动售检票系统的可能性及方案进行全面论证。

·2018年4月南京地铁结合自身购票业务的试点经验及行业兄弟单位对移动支付技术的试点推广经验，跳过了购票功能的推广，直接对移动支付过闸技术进行全面推广，并将该工程列为2018年南京市民生实事之一。

二维码标准的制定

关于发码方式的选择。从标准制定和发码方式两个维度对城轨企业二维码发码方式进行分析。二维码标准有第三方支付机构技术标准、银联二维码标准、交通部二维码标准、城轨企业自定义二维码标准等，发码方式有独立发码和混合发码两种方式。结合南京地铁实际需求及城轨互联网票务指南，南京地铁采用城轨自定义混合发码标准，即南京地铁与第三方业务合作方合作共同发码。

序号 进出站分离码 通用乘车码1需要车站或中央查重 需要车站或中央查重2支持在线或离线生码、验码 支持在线或离线生码、验码3进站后必须收到进站行程，才能生码出站 进站后无需进站行程，可直接生码出站4后台系统交通匹配算法简单 后台系统交通匹配算法复杂5 用户行程清晰，便于客服处理，减少投诉纠纷 行程管理复杂，易引发用户疑异，导致投诉增高

关于发码类型的选择。从二维码使用角度，城轨二维码应用方式有进出站分离码和通用乘车码之分，各有优缺点，对比如下：从两者对比上来看，进出站分离码优点在于其后台系统交易配对简单，用户行程管理清晰，投诉少，更便于客服处理。缺点本次行程消息推送成功与否会对下一次使用产生影响，其潜在风险当APP用户群体较大，APP后台系统向APP推送行程时会存在不稳定现象，APP客户端需向后台增加查询用户行程指令，已确保行程完成，导致APP及后台系统设计复杂度上升。

通用乘车码优点在于用户在车站使用时不受上一行程限制，每次均可直接生码使用，如乘客已进站但未收到进站行程，出站时不受任何影响。该方案更容易被第三方业务合作方所接受。其缺点在于互联网票务系统中行程管理及APP行程管理设计较为复杂，更容易引发乘客投诉，乘客使用习惯培养成本较高。

关于南京地铁二维码数据的组成。南京地铁二维码由二维码头、行业数据域、用户数据域、二维码尾组成，其中行业数据域由行业受理方发行，由行业数据、用户公钥、行业数据域签名组成；用户数据域由第三方业务合作方发行，由用户数据、支付机构数据、用户数据域签名组成。二维码编码格式符合《GB/T18284-2000快速响应矩阵码》的要求，采用8位字节数据编码方式，纠错等级选择L（7%）。

二维码标准在AFC系统中的应用

AFC系统架构再设计。传统AFC系统架构是根据功能进行划分，即通常讲的五层架构。第一层：以单程票、储值票为代表的票卡业务逻辑层；第二层：车站为乘客提供服务的终端设备层；第三层：为车站终端设备提供管理功能的车站计算机处理层；第四层：以线路为单位，对线路进行管理的线路中央计算机系统层；第五层：负责对整个线网进行管理，并负责各线路的清分结算功能。

南京地铁AFC系统构架图

在南京地铁方案设计时，对全线网网络链路进行自组工业三层环网设计，确保网络链路实时可靠，并提出了“五+三”混合架构模型，即在保留原有五层架构的基础上，提出了实时性更强的三层补充架构模型，通过两种架构模型的互补，可以有效地解决智慧城市背景下地铁互联网支付票务系统的需求与管理问题。新的三层补充模型，第一层：以互联网票务为代表的电子卡、NFC闪付卡、手机Pay为代表的处理单元，对实时性需要较高的虚拟类、实体类票卡进行规范；第二层：原有车站终端，直接为乘客提供售检票服务的设备，增加互联网票务的业务描述；第三层：互联网票务系统，与清分系统平级亦可归属于清分系统的一个子系统，主要功能是统一城市轨道交通AFC系统内部互联网票务各种运行参数、收集终端设备中产生的实时交易数据，同时负责与第三方支付机构实时对接进行行程推送及计扣等工作，规范了互联网实时数据交互模式下各种票务管理规定。

通过两种模型的互补，在满足地铁互联网业务对系统实时性的要求的同时，又很好得保留了传统业务处理模型的管理需求，对于正线改造系统来讲，既能降低建设系统的改造难度，又最大限度的满足了运营公司现有的管理模式。

电子支付的业务设计。南京地铁移动支付升级项目属于正线生产系统改造项目，系统设计较为复杂，在保留既有自动售检票系统设备功能基础上，对清分系统、线路自动售检票系统及网络进行升级改造，引入移动支付手段，并新建互联网票务系统，以实现二维码、银联联机预授权等多种支付方式的在南京地铁的创新应用。

主要业务参与方如下：

·地铁AFC/ACC系统：由南京地铁ACC清分系统及10条已开通AFC线路组成，其中AFC系统中TVM、AGM、BOM等终端设备为乘客提供移动支付即时服务。ACC清分系统主要负责与互联网票务系统进行数据交互，清分对账等功能，更侧重于数据清分功能。

南京地铁互联网票务系统业务架构

·互联网票务系统：该系统为二维码交易的处理核心及交换平台，实现与第三方开放平台及AFC系统的对接，提供乘车二维码的生成、二维码扫码通知、行程通知、行程消费计费、交易对账等服务，支持乘车码APP的接入能力，最终实现二维码过闸服务能力。

·第三方开发平台：属于移动支付业务实现方APP的后台，主要负责与互联网票务系统进行二维码请码、行程管理、行程计扣、账单对账等数据交互，同时负责管理其APP相关业务使用。

·用户终端：主要指移动APP，APP可以为地铁官方APP、城轨易行APP及商业合作方的APP。其中南京地铁官方APP承担各城轨间官方APP互联互通的接入与管理工作。

互联网票务系统平台的设计

轨道交通传统数据处理中心对数据实时性要求不高，当下轨道交通业务正逐步向数据化、在线化、智能化、标准化发展。传统的系统架构已无法满足互联网场景下，系统的可靠性、安全性、扩展性、开放性、经济性、前瞻性等需求。本项目中从需求角度出发结合当下先进技术，采用“私有云+ 传统SAN 存储”混合架构的设计理念，对南京地铁移动支付中心数据大脑进行创新设计。即在传统关系数据模型基础上增加分布式数据处理模型，两者并存共同解决互联网票务系统的各种业务需求，为银联闪付过闸、二维码过闸同时上线创造条件。

将互联网票务中的用户最终数据通过SAN 储存模式存储到关系型数据库中，利用传统的对账清分模型与第三方业务合作方、地铁官方APP、地铁清分系统进行对账，并对系统日常事务性进行管理。系统中实时性要求较高的业务由私有云分布式计算来完成，利用云计算IaaS 技术对系统资源进行动态分配，利用云计算PaaS 容器技术实现内存数据库Redis 和消息队列ActiveMQ的集群处理。可以对PC 服务器硬件资源进行集中共享，通过负载均衡实现多台计算机协同处理任务，有效降低了数据高并发模式下对硬件资源的需求，使得系统具有高可访问性、透明性、开放性、可扩展性。

二维码进出站流程如下：

二维码进出站流程示意图

通用乘车码进出站流程与进出站分离码流程区别只在于进站或出站后行程推送是否及时，是否对下一次使用产生影响。

互联互通设计的考虑

国内已有25个城市的轨道交通企业实现了手机扫码过闸，在给人们的生活、出行带来诸多便利的同时，城市间互联互通已经成为一个棘手的问题。以南京地铁标准设计时，已经对该问题进行充分讨论，并将南京地铁移动支付互通场景划分为两类：

·互联网票务系统接入方式，即在商务合作模式谈妥的基础上，所有第三方业务合作方按照统一技术标准接入南京地铁互联网票务系统，所有业务合作方关系对等。该方案对互联网票务系统运营维护要求高，且实施技术复杂、涉及面广、难度高。

·官方APP接入方式，可以满足不同机构的APP接入实现APP间的互联互通，即各城市APP通过城轨易行平台或直接与南京地铁官方APP进行相互嵌入调用。该模式下，核心对接工作由APP端完成，互联网票务系统只需与其官方APP对账，由地铁官方APP完成与其他APP之间的数据交互及对账工作，更适合互联网模式下的不同城市间的商业合作及推广。

“熊猫”结合自身AFC多年的业务经验，与南京地铁展开深入合作，为南京地铁提供互联网票务系统的基础设施建设工作。通过双方的共同努力，实现了南京地铁AFC系统移动支付方案从无到有，从吸收兄弟城市经验到完善超越。本项目中对AFC系统架构模型再创新，首次提出了“五+三”混合业务模型架构，利用“私有云+传统SAN存储”混合架体系构建互联网票务数据中心，并对移动支付核心业务标准化。实现国内首创应用地铁业务方和电商平台联合发码技术，对南京地铁11条线路网络链路进行自组工业三层环网改造，实现全线网进出站实时匹配查重技术，为南京地铁移动支付业务上线夯实了基础，也为行业移动支付技术的发展提供可借鉴经验。