文/張鵬 陳園園 余樂
在“互聯網+”時代大背景下,以手機掃碼過閘為代表的新型移動支付技術在軌道交通領域得到迅猛發展,它既能有效解決地鐵售檢票系統存在的購票效率低、客流高峰期排隊購票時間長、車票單次使用成本高等問題,又能豐富地鐵票務系統的支付形式,為乘客提供更好的便捷出行服務。
在新技術應用的同時,移動支付手段可謂百花齊放,各城市應用情況各異,技術路線也各不相同,缺乏統一的數據格式和接口,城市間不能實現互聯互通,為城軌企業運營管理水平和乘客滿意度提升帶來新的挑戰。本文以南京地鐵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系統構架圖
在南京地鐵方案設計時,對全線網網絡鏈路進行自組工業三層環網設計,確保網絡鏈路實時可靠,并提出了“五+三”混合架構模型,即在保留原有五層架構的基礎上,提出了實時性更強的三層補充架構模型,通過兩種架構模型的互補,可以有效地解決智慧城市背景下地鐵互聯網支付票務系統的需求與管理問題。新的三層補充模型,第一層:以互聯網票務為代表的電子卡、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條線路網絡鏈路進行自組工業三層環網改造,實現全線網進出站實時匹配查重技術,為南京地鐵移動支付業務上線夯實了基礎,也為行業移動支付技術的發展提供可借鑒經驗。