李兆君，張 建，馬曾卓

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

0 引言

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

1 定義

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

2 設(shè)計原則[3]

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

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

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

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

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

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

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

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

2.5 實名制及信用消費原則

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

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

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

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

3 平臺構(gòu)建

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

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

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

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

3.2.1 平臺功能及域界面

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

圖1 各平臺域界面

3.2.2 軟件架構(gòu)

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

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

3.2.3 云平臺架構(gòu)

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

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

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

圖3 用戶操作流程

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

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

4 接口要求

4.1 平臺與ACC 接口

城軌互聯(lián)網(wǎng)票務(wù)平臺與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ā)碼機構(gòu)公鑰證書下載等。

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

4.2.2 交易接口協(xié)議

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

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

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

4.3 平臺與BOM 的接口

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

4.3.1 實時交易接口定義

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

4.3.2 交易接口協(xié)議

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

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

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

5 管理要求

5.1 對賬業(yè)務(wù)管理

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

5.2 運營服務(wù)管理

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

5.3 應(yīng)急處置管理

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

6 結(jié)束語

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