基于“互聯(lián)網(wǎng)+”的軌道交通互聯(lián)網(wǎng)票務系統(tǒng)平臺

李兆君，張 建，馬曾卓

（1.合肥城市軌道交通有限公司，安徽合肥 230000；2.南京熊貓信息產(chǎn)業(yè)有限公司，江蘇南京 210000）

0 引言

在隨著“互聯(lián)網(wǎng)＋”和智慧城市建設發(fā)展，國內(nèi)軌道交通自動售檢票系統(tǒng)（AFC）新技術發(fā)展迅速，國內(nèi)各地鐵城市開始推出新型支付模式，目前較多城市實現(xiàn)了將二維碼支付成功運用于地鐵票務中，有效解決了排隊購票、零錢難兌、票款清點、加幣加票等問題，減少人力、設備、票卡、解行等成本，“刷碼過閘，先乘后付”大大方便了乘客。新技術引發(fā)自動售檢票系統(tǒng)的升級換代，互聯(lián)網(wǎng)票務系統(tǒng)應運而生，如何構建互聯(lián)網(wǎng)票務系統(tǒng)平臺也提上行業(yè)主管部門和地鐵公司的管理日程[1-2]。

1 定義

所謂互聯(lián)網(wǎng)票務就是采用各種互聯(lián)網(wǎng)技術手段實現(xiàn)票的虛擬化、數(shù)字化，互聯(lián)網(wǎng)票種分為多種介質(zhì)，目前主要包括4類：二維碼；NFC，分銀聯(lián)閃付卡，手機PAY，智能穿戴式設備，如智能手環(huán)、智能手表；生物特征識別，如人臉、掌紋、聲紋、虹膜；二維碼+藍牙等。基于以上多種新型的介質(zhì)實現(xiàn)的虛擬化、數(shù)字化票種統(tǒng)稱為互聯(lián)網(wǎng)票務。而在互聯(lián)網(wǎng)票務使用、運營過程中提供各種管理功能的信息系統(tǒng)稱為互聯(lián)網(wǎng)票務系統(tǒng)平臺。

2 設計原則[3]

2.1 系統(tǒng)可靠性原則

系統(tǒng)架構健壯、運行穩(wěn)定、功能可靠。支持通過容錯、熱備、故障恢復等，在系統(tǒng)故障時能保持正常工作，確保數(shù)據(jù)不因意外情況丟失或損壞。

2.2 系統(tǒng)安全性原則

系統(tǒng)的設計、開發(fā)、制造、調(diào)試和維護的全生命周期，體系應符合《信息安全等級保護管理辦法》信息安全等保三級的標準要求，遵循國家網(wǎng)絡安全設計規(guī)范，系統(tǒng)關鍵信息進行機密管理，系統(tǒng)數(shù)據(jù)完整、防非法修改。

2.3 系統(tǒng)擴展性原則

系統(tǒng)應具備在用戶量、業(yè)務量增大時，具備規(guī)模擴展性，能快速響應業(yè)務需求的變化。系統(tǒng)采用松耦合構件方式進行設計，對應用功能的擴展可采用發(fā)布新構件方式實現(xiàn)，且新功能的部署不影響客戶的使用。

2.4 系統(tǒng)開放性原則

系統(tǒng)的主要功能、數(shù)據(jù)應具備開放性，通過標準或通用的接口向外部提供數(shù)據(jù)和功能的支持，且對接口有安全性的保護控制。可通過接入各城軌互聯(lián)網(wǎng)票務平臺實現(xiàn)乘車功能的互聯(lián)互通。

2.5 實名制及信用消費原則

要求接入互聯(lián)網(wǎng)票務平臺的移動應用，需遵循互聯(lián)網(wǎng)票務實名制安全要求，在申請開通服務時，根據(jù)互聯(lián)網(wǎng)票務平臺的接口要求，提供用戶的實名信息，確保互聯(lián)網(wǎng)票務運營的安全。在實名制的前提下，采用信用消費模式，通過后臺行程匹配及計費來實現(xiàn)先乘車后付費。

2.6 業(yè)務安全及獨立性原則

互聯(lián)網(wǎng)票務平臺應是獨立的，以保障業(yè)務數(shù)據(jù)的安全性。業(yè)務密鑰使用城軌企業(yè)ACC私有密鑰，確保城軌企業(yè)對業(yè)務的主控權。應具備獨立發(fā)碼能力，同時支持國家其他行業(yè)、交通部的發(fā)碼要求，支持轉碼方式，在保障業(yè)務安全、獨立性情況下，支持行業(yè)兼容及業(yè)務拓展。簽名密鑰算法應選用國密算法，可采用基于非對稱SM2算法或/和3DES的對稱簽名，在保障密鑰安全的同時實現(xiàn)對脫機生碼模式的支持。

另外，平臺還要具有經(jīng)濟性、通用性、前瞻性，以實現(xiàn)平臺適應發(fā)展的需求。

3 平臺構建

如何構建互聯(lián)網(wǎng)票務系統(tǒng)平臺，根據(jù)互聯(lián)網(wǎng)票務的特性，結合城軌AFC系統(tǒng)的定位，以合肥軌道交通二維碼掃碼過閘建設為例來說明。

3.1 系統(tǒng)關鍵指標

關鍵指標主要有兩個方面，一是可靠性指標，如可用性≥99.9%，MTBF＞6個月，MTTR＜0.5 h，可連續(xù) 7×24 h 工作。二是二維碼事務處理性能指標，如電子票讀寫處理時間≤400 ms，讀寫距離≥60 mm，過閘通過能力≥60人/（min×通道）。信息傳輸性能：實時時鐘同步誤差≤1 s；交易數(shù)據(jù)和狀態(tài)數(shù)據(jù)上傳間隔時間≤1 min，其他數(shù)據(jù)≤15 min；命令響應時間≤2 s；狀態(tài)改變的響應時間≤1 s[4]。

3.2 構建系統(tǒng)平臺

3.2.1 平臺功能及域界面

互聯(lián)網(wǎng)票務平臺實現(xiàn)對傳統(tǒng)票務、新型互聯(lián)網(wǎng)票務的業(yè)務能力支持。對互聯(lián)網(wǎng)票務業(yè)務進行管理，包括數(shù)字票務系統(tǒng)、二維碼管理系統(tǒng)；同時對AGM、BOM進行改造，實現(xiàn)對傳統(tǒng)票務、互聯(lián)網(wǎng)票務的乘客事務處理；新建城軌APP，提供用戶實名認證管理、二維碼掃碼乘車、移動支付及城軌企業(yè)特色服務等。業(yè)務功能包括用戶系統(tǒng)、結算系統(tǒng)、報表系統(tǒng)、參數(shù)系統(tǒng)、風險管理系統(tǒng)等，管理各個子系統(tǒng)的帳號、密碼、權限等，以及各個子系統(tǒng)計劃任務。各平臺域界面如圖1所示。

圖1 各平臺域界面

3.2.2 軟件架構

本次二維碼過閘業(yè)務采用APP客戶端與支付寶簽約代扣協(xié)議來實現(xiàn)扣費過閘，用戶只需在手機APP上注冊生成二維碼即可在車站閘機上掃碼進出車站。處于業(yè)務核心的支付平臺首次采用私有云zstack、redis實時數(shù)據(jù)庫、MQ消息隊列、F5負載均衡器等技術實現(xiàn)對大客流、多設備的壓力處理，為合肥地鐵開啟了新技術應用的先河。同時在系統(tǒng)架構設計時考慮到遠期其他支付機構接入，在設計二維碼機構中支持多種APP和支付結構的接入，在系統(tǒng)設計支持未來五條線的客流量和并發(fā)數(shù)。同時系統(tǒng)采用云技術增強系統(tǒng)的可擴展性，也為后期接入創(chuàng)造便利條件[5]。平臺業(yè)務架構如圖2所示。

圖2 系統(tǒng)平臺架構圖

3.2.3 云平臺架構

按照傳統(tǒng)架構+互聯(lián)網(wǎng)私有云架構的模式進行系統(tǒng)設計，硬件設計考慮了功能模塊化布置的需求，具備堆砌式擴展的能力，同時系統(tǒng)安全采用三級等保，分為互聯(lián)網(wǎng)接入?yún)^(qū)、AFC系統(tǒng)網(wǎng)絡接入?yún)^(qū)、云平臺服務器區(qū)和安全運維管理區(qū)等4個區(qū)域。

3.2.4 APP過閘業(yè)務流程

合肥軌道交通二維碼過閘技術于2018年12月24日，在1、2線正式上線公測，可適用Android和IOS系統(tǒng)手機，用戶操作流程如圖3所示。

圖3 用戶操作流程

二維碼過閘門業(yè)務流程，用戶打開合肥地鐵APP，展現(xiàn)乘車碼→用戶在閘機上的二維碼讀頭上實現(xiàn)拍碼支付，閘機對二維碼驗證，有效后放行→閘機將本次交易信息實時推送給移動支付平臺→移動支付平臺將交易信息轉發(fā)給第三方開放平臺→第三方平臺將乘車信息推送給合肥地鐵APP→移動支付平臺進行行程匹配并向第三方平臺發(fā)起支付。流程簡圖如圖4所示。

圖4 二維碼過閘進出站流程

4 接口要求

4.1 平臺與ACC接口

城軌互聯(lián)網(wǎng)票務平臺與 ACC接口主要包括二維碼交易對賬、同步實名認證用戶信息接口，包括接口協(xié)議、交易對賬流程。

4.1.1 接口協(xié)議

接口協(xié)議包括文件傳輸及存取方式、文件列表、文件格式。平臺與ACC對賬數(shù)據(jù)接口采用文件格式，采用HTP傳輸方式，傳輸中文件以.tmp作為后綴，傳輸完成后刪除后綴。文件格式可分為二維碼行程文件、日終行程調(diào)整交易文件、單邊交易文件、差異交易及調(diào)整文件、以及用戶實名認證信息文件等。

4.1.2 交易對賬

主要是平臺與ACC對賬，平臺接收終端實時上傳過閘數(shù)據(jù)，進行運營日間和日終處理，與ACC各類交易數(shù)據(jù)對賬，進行差異調(diào)整處理。

4.2 平臺與AGM接口

平臺與AGM的接口主要由指令接口定義、交易接口協(xié)議兩部分組成。

4.2.1 指令接口定義

指令接口定義包括指令碼定義、客戶端注冊、心跳檢測、終端交易控制參數(shù)下載、掃碼數(shù)據(jù)實時上傳、掃碼聯(lián)機驗證、發(fā)碼機構公鑰證書下載等。

指令碼定義是對各種指令代碼功能進行定義，如A1H表示心跳檢測。客戶端注冊、心跳檢測、終端交易控制參數(shù)下載、掃碼數(shù)據(jù)實時上傳、掃碼聯(lián)機驗證、發(fā)碼機構公鑰證書下載是對本類指令定義、確定請求和返回數(shù)據(jù)格式進行規(guī)定。同時處理原則和異常情況處理進行規(guī)定。

4.2.2 交易接口協(xié)議

交易接口協(xié)議包括通信協(xié)議格式、報文格式、報文數(shù)據(jù)元說明、指令錯誤返回碼定義以及安全要求等。

通信協(xié)議格式約定基于TCP/IP協(xié)議，交互采用長、短連接方式，報文（包括請求及應答）數(shù)據(jù)元采用key=value的形式組織，并以&作為連接符拼接成字符串進行編碼，在數(shù)據(jù)包最后使用 進行標識。數(shù)據(jù)集合（ARRAY）類型的數(shù)據(jù)元名稱采用英文大括號{}進行包括，各個數(shù)據(jù)子集之間采用#進行分隔。接口服務方、發(fā)起方在建立通信連接后，通過指定端口與服務程序進行連接。交互采用申請?應答交互方式進行，應答報文將以同步響應的方式返回給請求方，每次交互設置交易時限，超時失敗。

為了防止通信過程中報文信息被惡意篡改，除特殊要求外，雙方通信報文要簽名，交易請求方實現(xiàn)對請求報文簽名，交易服務端對簽名進行驗證，簽名不合法的請求將會被拒絕。以保證通信交易的安全性。

4.3 平臺與BOM的接口

平臺與BOM的接口主要由實時交易接口定義、交易接口協(xié)議兩部分組成。

4.3.1 實時交易接口定義

實時交易接口定義主要由用戶信息查詢、用戶行程查詢、客服行程補登、客服行程撤銷、代申請出站憑證等組成。每部分又分別由接口功能描述、請求和應答報文定義組成。

4.3.2 交易接口協(xié)議

交易接口協(xié)議由接口協(xié)議格式、交易報文結構、公共報文信息、報文數(shù)據(jù)元說明，以及安全要求組成。平臺與BOM的交易接口實現(xiàn)采用HTTP作為傳輸協(xié)議，json作為傳送信息的編碼格式，接口服務提供方實現(xiàn)接口服務程序。交易報文結構，雙方交換的消息報文以json格式。公共報文信息由HTTP請求頭與應答頭，請求公共參數(shù)與應答公共參數(shù)組成。同樣為了防止通信過程中報文信息被惡意篡改，通信報文要簽名機制，交易雙方分別報文簽名和驗簽，以保證通信交易的安全性。

4.4 城市間互聯(lián)互通

各城市軌道交通互聯(lián)網(wǎng)票務平臺要預留互聯(lián)互通接口，以方便實現(xiàn)城市間互通，為跨區(qū)域出行人員提供便利。可以采用SDK調(diào)用方式實現(xiàn)，可實現(xiàn)進行對賬和清算。

5 管理要求

5.1 對賬業(yè)務管理

互聯(lián)網(wǎng)票務交易數(shù)據(jù)能夠?qū)崿F(xiàn)云平臺、ACC以及第三方支付平臺間進行對帳，以ACC數(shù)據(jù)為主；平臺提供清結算報表，數(shù)字票務系統(tǒng)對行程匹配、計費；平臺通過終端補登、撤銷時，數(shù)據(jù)同步上傳ACC，ACC對交易數(shù)據(jù)進行復核；數(shù)據(jù)傳輸過程要對敏感信息加密，MAC驗證、TAC驗證，采用專線傳輸時可以不加密。

5.2 運營服務管理

對互聯(lián)網(wǎng)用戶統(tǒng)一管理，實現(xiàn)乘客信息、行程查詢及處理；為客戶提供服務支持，如咨詢、注冊、注銷、扣費等；支持雙脫機模式。

5.3 應急處置管理

制訂系統(tǒng)故障和大面積終端故障時的應急處置預案，明確崗責、明確流程；人員引導、標識引導、廣播告知、官網(wǎng)通知；啟動傳統(tǒng)售檢票模式；如果傳統(tǒng)設備也大積故障，必要時啟動紙票，以限流、分流為宜，引導快速通行離站為主。

6 結束語

引入“互聯(lián)網(wǎng)+”便捷交通理念，以智慧出行服務為宗旨，顛覆了傳統(tǒng)地鐵票務模式，減輕了地鐵建設、運營成本、現(xiàn)金管理、設備維護等壓力，同時為乘客提供了更加便捷的乘車體驗，在智慧城市建設過程中，提升了城市品質(zhì)和管理服務水平。