基于互聯網+的地鐵票務云ACC平臺

許玲++于丹++葉曉峰

摘 要本研究旨在現有AFC系統的基礎上，探討移動互聯網在線支付技術在系統中的應用，對傳統AFC系統進行優化，結合“互聯網+”模式，搭建一個云ACC平臺。研究平臺的云實現方式，對平臺進行技術設計，并提供一套完整的解決方案和安全策略。

【關鍵詞】AFC（自動售檢票系統） 云ACC平臺 互聯網+ 移動支付

1 引言

在整個軌道交通系統中，自動售檢票（AFC）系統承擔著重要的角色，它實現了自動售票、自動檢票，和計費、收費、統計、結算等全過程的自動化管理。隨著科學技術的發展，AFC系統呈現多種類型，主要取決于支付方式應用技術的多樣化。目前AFC系統中采用的支付方式，包括硬幣支付、紙幣支付、儲值票支付、車票圈存支付和銀行卡支付等。近年來，移動互聯網的迅猛發展，在線支付作為一種新型的支付方式，因其便捷性，逐漸占據人們各種生活消費場景。如何結合移動互聯網電子支付技術，對整個線網的AFC系統規劃布局，滿足網絡化運營需求，如何結合移動互聯網在線支付技術在系統中的應用，對傳統AFC系統進行優化，成為了亟需解決的問題，而云ACC平臺正是這樣一套完整的解決方案。

2 互聯網+地鐵票務云ACC平臺研究

2.1 云ACC平臺概述

云ACC平臺將采用云架構體系實現，在原有票卡系統外建立起云平臺的4層體系：整個云平臺將分為第三方對接系統，云中心系統，云票務處理系統與云終端管理系統四大層次，云ACC平臺系統層次圖如圖1所示。每一個系統層次內還包含了不同的應用系統，所有的系統之間采用接口進行數據交互以便于進行系統的可持續化擴展。

另外，系統建立起一套完整的、可擴展的接口數據規范，規范包含了數據結構規范、傳輸與響應規范、安全與認證規范幾部分。通過接口將不同的系統整合起來，并最終實現整個平臺的有機運行。

平臺系統需要與現有的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.2.3 核心功能需求分析

（1）互聯網購取票機（iTVM）。用戶可以過網上購票，線上支付，或者現場通過手機支付，線下終端取票入站的流程進行地鐵票卡的購買，支付方式包括微信支付、支付寶支付、銀聯支付、市民卡支付等方式，票卡包括單程票、單日票、月票、紀念票等。

（2）云閘機。系統需要在現有的閘機端添加新的云閘機以支持用戶使用二維碼掃碼入閘功能。

用戶使用手機APP，注冊用戶帳戶并關聯支付方式。在入站時，用戶在云閘機端掃描APP產生的二維碼，云閘機在服務器端驗證后放行用戶，并且用戶在出站時在出站閘機掃描二維碼以實現出站，服務器端在驗證后直接扣取用戶的乘車費用。

用戶二維碼通過安全算法，基于信用體系實現。使得二維碼可以在一定時間內脫機實現，即使掃碼時用戶手機不在線，也可以正常進出閘機，并可以正常扣款。

用戶每一次進站首先需要將未正常扣款的訂單通過客服或者自助處理完成。當用戶存在低信用時，系統將會禁止用戶掃碼入站，而建議用戶通過iTVM設備買卡進入。

（3）云對帳平臺。云ACC的核心功能就是對產生的所有交易進行對帳、核銷與清分操作，其中對帳平臺的核心功能是自動化對接所有的對帳平臺，包括第三方支付平臺，軌道交通AFC中心等，實現交易收入、票卡支出的所有交易信息的處理。并自動化產生交易大數據與對帳信息，最終實現數據的可視化分析等功能。

（4）乘客事務處理。當用戶發生無法出/入站時，需要向當前站點的客服中心請求處理。每一個客服中心配備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 唯一流水碼設計

由于網絡傳輸的不穩定性，存在小概率狀況下的數據丟包現象。為了保證數據的完整性與一性，針對交易流水請求中設計一個唯一流水碼功能，每一次重點請求將會附帶一個唯一流水碼（GUID），當服務器發現存在相同的流水碼時，直接通過原始響應處理，而不進行新的交易操作，以解決由于網絡問題產生的重復提交而導致交易流水的混亂。

3 結語

文章對互聯網+傳統AFC行業的結合做出了初步探索，提出了云ACC平臺的概念，通過“互聯網 +”支付的應用設想，期待推動傳統AFC行業的發展。未來通過研究，將繼續完善云ACC平臺的安全策略，規范互聯網票務的業務流程，并對核心功能進行優化，通過建立賬戶體系對互聯網票務營銷深度開發，促進傳統軌道交通票務業務轉型升級。

參考文獻

[1]鐘銳楠.地鐵互聯網售票研究方案[J].科技創新與應用，2016，160（12）：19-20.

[2]龔迥.“互聯網+票務”在地鐵AFC系統的支付應用研究[J].科技風，2016，300（18）：227-228.

[3]張小春，張茜.基于互聯網+的天津地鐵AFC發展探討[A].智慧城市與軌道交通，2016[C].

[4]鄧先平，陳鳳敏.我國城市軌道交通AFC系統的現狀及發展[J].都市快軌交通，2005，18（03）：18-21.

[5]趙時旻.軌道交通自動售檢票系統[M].上海：同濟大學出版社，2007.

作者單位

寧波市軌道交通集團有限公司 浙江省寧波市 315101