城市轨道交通自动检售票系统私有云架构设计

本文结合城市轨道交通网络化发展需求，研究国内外现有AFC系统的不足，结合主流的AFC系统架构研究热点，深入分析了AFC数据信息流和云平台的功能和非功能需求，通过引入云计算技术优化传统五层AFC系统架构，提出构建基于私有云平台的AFC系统融合架构方案。架构中提出通过私有云平台替代传统AFC系统中的ACC层和LC层，不再在SC层设置数据存储和计算资源，并通过云平台实现统一监控与管理。本文提出的私有云平台AFC架构体系，让车站终端设备直接受控于私有云平台，减少车站及线路系统中间收发环节，有助于应对大客流的常态化，解决海量数据的计算与存储等问题，并能满足全局性运营数据的管理需要。

我国城市轨道交通事业发展迅猛，城市轨道交通线网进入网络化运营阶段，其管理模式也从单线路的垂直管理演进成多线路的区域管理。随着城市轨道交通客运量的暴增，传统的人工检售票无法满足统一的运营管理需要，自动售检票系统(Automatic Fare Collection, AFC)应运而生。

城市轨道交通自动售检票AFC 重点实现城市轨道交通售票､检票､计费､清分结算和运营管理等全过程的自动化管理，包括但不限于票卡技术标准、SAM 卡技术标准、IC 卡读写器技术标准、线网运营管理标准、二维码应用技术标准、NFC 应用技术标准、人脸识别技术标准、互联网支付系统数据接口规范、AFC 系统数据接口规范、设备操作人机界面规范、运营管理软件人机界面规范及报表标准等。2007 年建设部在《城市轨道交通自动售检票系统技术条件》(GB/T 20907-2007)提出了五层架构体系标准，从底至上分别为车票层、车站终端设备层(Station Level Equipment, SLE)、车站计算机系统层(Station Computer, SC)、线路中央计算机系统层(Line Center Computer, LC)、城市轨道交通清分系统层(AFC Clearing Center, ACC)，具有层次分明､安全性高､不受其他线路建设工期影响等优点，伸缩性强，已在国内很多城市中得到应用，但随着城市轨道交通的快速推广和业务发展，传统结构在适应个性化票务处理需求时存在较多不足。

2. AFC 系统发展及存在不足 AFC 系统自1997 年在上海市轨道交通系统中引入从而正式进入我国，历经起步、应用和优化三个阶段[1]，发展至今已得到全面应用。

2.1. 传统AFC 系统不足分析 国内城市轨道交通AFC 系统大多采用标准的五层架构体系[2]， 随着交通网规模的快速增大， 传统五层架构暴露出较多不足，主要体现在以下六个方面[3]：