基于“互聯網+”的軌道交通互聯網票務系統平臺

李兆君，張 建，馬曾卓

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

0 引言

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

1 定義

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

2 設計原則[3]

2.1 系統可靠性原則

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

2.2 系統安全性原則

系統的設計、開發、制造、調試和維護的全生命周期，體系應符合《信息安全等級保護管理辦法》信息安全等保三級的標準要求，遵循國家網絡安全設計規范，系統關鍵信息進行機密管理，系統數據完整、防非法修改。

2.3 系統擴展性原則

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

2.4 系統開放性原則

系統的主要功能、數據應具備開放性，通過標準或通用的接口向外部提供數據和功能的支持，且對接口有安全性的保護控制?？赏ㄟ^接入各城軌互聯網票務平臺實現乘車功能的互聯互通。

2.5 實名制及信用消費原則

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

2.6 業務安全及獨立性原則

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

另外，平臺還要具有經濟性、通用性、前瞻性，以實現平臺適應發展的需求。

3 平臺構建

如何構建互聯網票務系統平臺，根據互聯網票務的特性，結合城軌AFC 系統的定位，以合肥軌道交通二維碼掃碼過閘建設為例來說明。

3.1 系統關鍵指標

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

3.2 構建系統平臺

3.2.1 平臺功能及域界面

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

圖1 各平臺域界面

3.2.2 軟件架構

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

圖2 系統平臺架構圖

3.2.3 云平臺架構

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

3.2.4 APP 過閘業務流程

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

圖3 用戶操作流程

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

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

4 接口要求

4.1 平臺與ACC 接口

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

4.1.1 接口協議

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

4.1.2 交易對賬

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

4.2 平臺與AGM 接口

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

4.2.1 指令接口定義

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

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

4.2.2 交易接口協議

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

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

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

4.3 平臺與BOM 的接口

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

4.3.1 實時交易接口定義

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

4.3.2 交易接口協議

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

4.4 城市間互聯互通

各城市軌道交通互聯網票務平臺要預留互聯互通接口，以方便實現城市間互通，為跨區域出行人員提供便利?？梢圆捎肧DK 調用方式實現，可實現進行對賬和清算。

5 管理要求

5.1 對賬業務管理

互聯網票務交易數據能夠實現云平臺、ACC 以及第三方支付平臺間進行對帳，以ACC 數據為主；平臺提供清結算報表，數字票務系統對行程匹配、計費；平臺通過終端補登、撤銷時，數據同步上傳ACC，ACC 對交易數據進行復核；數據傳輸過程要對敏感信息加密，MAC 驗證、TAC 驗證，采用專線傳輸時可以不加密。

5.2 運營服務管理

對互聯網用戶統一管理，實現乘客信息、行程查詢及處理；為客戶提供服務支持，如咨詢、注冊、注銷、扣費等；支持雙脫機模式。

5.3 應急處置管理

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

6 結束語

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