1. 引言
我国城市轨道交通事业发展迅猛，城市轨道交通线网进入网络化运营阶段，其管理模式也从单线路的垂直管理演进成多线路的区域管理。随着城市轨道交通客运量的暴增，传统的人工检售票无法满足统一的运营管理需要，自动售检票系统(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]：
1) 体系结构复杂、难以快速适应多站点接入，维护及扩展难度随着站点数的增加呈指数级增大；
2) 资源按照高峰客流配置，导致存储和计算的有效利用率偏低，存在较大资源浪费；
3) 采用“一线一中心”模式建设，每条线路均新建LC，导致成本费用居高不下；
4) SC､LC､ACC均会存储并备份交易数据，最终仅在ACC层处理数据，层间数据的过度备份致使通信中转过长，导致整体体系功能偏弱；
5) 不同时期建设的线路集成商及设备不同，缺少标准化的接口规范，导致扩展升级难度增大；
6) AFC负责多运营商和多线路的清分任务，其性能决定整体的效能，成为体系的能力瓶颈。
2.2. 现阶段AFC研究重点
基于上述不足，如何优化AFC系统架构以满足城市轨道交通的发展需求，已成为网络化运营背景下的研究热点和研究重点 [4]，北京､上海､广州､南京等城市在标准五层架构的基础上，结合自身实际情况对已尝试对AFC系统进行灵活优化，取得一定成效，但整体上全国AFC系统的优化工作仍处于起步阶段 [5]，相关研究的规范度和适应性不够完善。主流的AFC系统架构优化集中在以下三方面：
1) 新建多线路中心研究
在拥有多条城市轨道交通线路的特大城市中，如果针对每条线路都设置LC，会造成资源的巨大浪费，并对清分中心的服务性能提出更高要求。基于此，北京、广州等城市提出在同一个运营商管辖范围内，设置多线路中心(Multi-Lines Centre, MLC)，将所辖范围内的多条AFC数据直接上传至MLC，实现线路资源共享，并在清分中心层下将线路信息进行处理，减少层间数据传送和清分中心计算的压力。该种方式将MLC视为小型清分中心，在其内部完成所辖线路的数据传输、报表统计、清分分析等运营管理任务。
2) 新建区域线路中心研究
面向城市轨道交通网的区域化管理需求，在一定规模的线网相关线路内设置区域线路中心(Zone-Line Centre, ZLC)，以替代线路中心部分功能。通过ZLC中心与车站标准接口，解决线路独立运营的管理、维修调配等委托，并未未来线路接入预留服务能力。南京市构建基于ZLC的AFC系统，实现多条线路和相关车站的区域集合管理，取得良好的应用成效。
3) 取消线路中心研究
在中小型城市中轻轨线路较少且运营商单一，清算需求和服务压力偏低，因此通过将LC功能分配到SC和ACC中从而取消LC，实现架构精简，提高整体运营效率。在此优化过程中，ACC需增加对SC的监控管了、SC需收集、处理和分析各类LC数据，并与ACC依据规则直接对账。
上述三类优化方案，均在不同程度上实现了系统架构的简化，但对于车站层的优化考虑不足，同时在应对大规模客流的数据处理能力不足，尤其是应对海量的网络化运营数据存储和计算需求时，无法按时保证；此外，也未解决资源利用率低下､系统结构复杂等关键问题。
3. 基于私有云的AFC需求分析
针对上述不足，本文从业务系统需求及数据信息流动两方面开展研究，提出构建基于私有云平台的AFC系统架构，并对AFC系统中的信息流向、数据流向进行详细分析。
3.1. AFC云平台系统需求分析
AFC系统需求分为功能和非功能需求两部分，其中功能需求需结合运营管理部门的职能定位开展分析，并重点满足具备应对网络化运营及大客流带来的大数据挖掘、分析、存储、管理等能力，非功能需求重点考虑AFC系统的安全性、可靠性和可扩展性。
1) 功能需求分析
结合具体业务要求，AFC系统的功能需求包括运营管理、票务管理、清分管理、信息管理、系统管理、用户管理、资源管理、大数据管理、培训测试和容灾备份十个方面。其中运营管理负责运营起始业务管理、运营日切换、运行模式管理、参数管理、审计管理等业务；票务管理负责票卡采购、制作、流通、回收等业务；清分管理负责与外部系统清分、对账、报表管理等业务；信息管理负责信息决策支持、发布等业务；系统管理负责权限管理、维护管理、日志管理、时钟同步等业务；用户管理负责用户身份、权限、操作环境管理等业务；资源管理负责云平台资源监测与调度等业务；大数据管理负责大数据挖掘、预测、存储等业务；培训测试提供完备的云平台培训及测试中心业务；容灾备份设置云灾备中心，对云平台建立备份业务。
2) 非功能需求分析
基于云化部署的AFC系统平台要求实现安全性、可靠性和可扩展性。其中安全性涉及不同域的边界防护、入侵检测、防病毒体系以及访问控制，并要求采用加密技术实现数据传输的完整性，保障敏感数据的安全性；可靠性要求系统各层在全生命周期中，符合技术规范规定、满足稳定运行与故障修复时间要求；可扩展性要求云平台能根据未来客流数据，预留新线及新建车站接入的接口需求与容量需求。
3.2. AFC系统数据信息流分析
基于私有云的AFC系统，其运营管理包括客流信息流、财务信息数据流和管理信息流，其中客流信息流数据包括交易信息流、车票流和乘客流是客流分析，财务信息数据流包括交易信息流、车票流和资金流，管理信息流为监控指令流。基于私有云的AFC系统数据流向主要包括8个方面，如表1所示。
Table 1. AFC system interface message category list
表1. AFC私有云平台数据信息流向表
1) 监控指令数据信息流
AFC云平台系统监控指令数据来源于监控管理过程，包含全线网所有网络设备的运行情况、通路情况和丢包率，云平台服务器、数据库、交换机等设备以及车站终端设备等，分为监视、控制两类，其中监视数据负责云平台、通信网络及设备的监视，控制数据通过参数和模式设定完成设备的运行控制。
2) 票务数据信息流
云平台与SLE的票务数据交换包括云平台下发到车站终端设备的车票类型、费率表和操作权限等票务参数，以及终端设备上传到云平台的交易、寄存器和维护日志等；云平台与银行系统的票务数据交换包括接收贷记凭证和发送借记凭证，并作为银行账户存款的依据；云平台与城市公共交通卡系统的票务数据交换实现票务交易，同时接收公共交通卡系统的票务参数、黑名单和对账报表等。
3) 乘客信息流
城市轨道交通的实时客流来源于TVM售票数据､BOM售票数据和AGM检票数据，AFC云平台客流数据来源于车站购票客流、进出站处理客流及人工窗口处理客流数据。其中，购票客流数据包括总购票人数，进出站客流数据包括总进出站人数、进出站车票处理总人数、进出站无效票处理总人数及无票通过人数；人工窗口处理客流包括人工售票客流、补票客流和票卡更新客流。
3.3. 基于FTP的数据流交换设计
终端设备在系统运行过程中产生的大量数据，包括交易数据、收益数据、审计数据、设备事件数据。这些数据在终端设备产生后，通过SC逐层上传到ACC；同时，上级系统维护的设备配置参数、结算对账数据、各类程序文件以及资源文件也使用文件传输到下级系统。
由于AFC系统对这些数据传递的实时性和完整性有较高要求，具体交换过程包括：
1) FTP协议将在AFC系统各级数据传输中予以应用，包括ACC、SC、SC/SLE，但仅相邻的两层可进行数据文件交互传输，数据文件不允许跨层传输。
2) ACC/SC之间的数据传输以ACC为FTP服务器，SC为客户端。
3) SC/SLE之间的数据传输以SC为FTP服务器，SLE为客户端。
4) 在FTP服务器和客户端建立Socket连接通讯时，服务器将FTP访问信息传输给客户端，包括FTP的IP地址、端口号、用户名、访问密码、工作目录等信息。
当FTP客户端产生数据文件，需要上传服务器时，客户端主动访问服务器，将文件put到指定的FTP工作目录，需要下发至客户端时，服务器先将数据文件复制到本地FTP工作目录，然后通过Socket报文通知客户端下载文件。客户端接到Socket指令信息后，立刻访问指定的FTP服务器，get相关数据文件。根据特定的业务需求，客户端需要轮询或定期查找服务器端指定的FTP工作目录，主动查找。
同时，FTP服务器本地负责维护FTP工作目录内所有的数据文件。FTP服务器端检测到客户端上传的文件后，应立刻处理移出工作目录。同时，FTP工作目录下用于供客户端下载完的数据文件，服务器本地也需做定期整理。
要保证上述数据交换准确性和及时性，AFC的所有节点计算机(包括线路及车站主机与终端设备)必须具有相同的系统时间，并与清分中心进行时间同步。清分中心从外界时钟源(卫星GPS数据或者通信系统)获得准确的当前时间，来设置自己的系统时间，并成为线网标准时间的源头。目前，各节点计算机之间的时间同步主要通过NTP协议(RFC1305)实现。
4. 基于私有云的AFC架构设计
4.1. 整体逻辑架构设计
针对当前AFC系统存在的不足，结合平台需求和数据信息流，在五层AFC架构基础上，本文提出基于私有云的AFC系统架构。架构自底向上分为车票层、车站终端设备层、车站层、私有云平台层，整体逻辑架构如图1所示：
1) 车票层：车票层集合了各类型车票，包含单程票､储值票､计次票､计程票､纪念票等，是AFC系统的支付媒介；
2) 车站终端设备层：车站终端设备包括自动售票机(Ticket Vending Machine, TVM)、自动检票机(Automatic Gate Machine, AGM)、半自动售票机(Booking Office Machine, BOM)等直接与乘客交互的车站级设备；
Figure 1. The AFC overall system architecture based on cloud platform
图1. 基于云平台的AFC整体系统架构图
3) 车站层：与传统AFC系统的车站层不同，本架构中的车站层作为瘦客户端，不再设置数据存储与计算的相关资源，通过终端设备将数据直接上传至云平台层实现集中处理。
4) 私有云平台层：本层取代传统五层架构的ACC层和LC层，实现城市轨道交通运营数据管理､保存､采集､挖掘､分析､应用及全局性的管理工作。
在此架构基础上，要求AFC清分规则系统实现最短路径规则模型、最短时间规则模型、最少换乘次数规则模型、最少换乘时间规则模型、最小权重规则模型、多路径规则模型6种清分规则模型，并可根据贵阳轨道交通线网设计出多套清分规则模型，供业主确认。
4.2. 私有云平台层架构设计
结合云平台架构，本文提出的私有云平台层架构包括基础设施层IaaS、中间件层PaaS、软件服务层SaaS，并从系统全局角度统筹考虑云平台安全机制，如图2所示。
1) 基础设施层IaaS：由硬件集合构成的物理资源池和虚拟化技术实现的虚拟资源池两部分组成，提供计算､存储和网络等服务。
2) 中间件层PaaS：本层是云平台核心部分，实现IaaS层资源调用，为系统提供多元化的组合应用环境与服务平台。PaaS层包括业务中心､用户中心､资源中心､云数据中心､测试中心和灾备中心六个部分；其中业务中心负责运营管理､票务管理､清分管理､信息管理和系统管理；用户中心负责身份管理､权限管理，并面向用户提供开发､测试工具及语言执行环境；资源中心负责资源与运行状态的实时监控，完成面向多并发任务的资源分配与部署，保障负载均衡和故障恢复；云数据中心负责系统所有数据的存储与分析；测试中心提供私有云平台的系统及接口的开发与维护；云灾备中心通过异地备份保障数据安全。具体包括运营管理模块､票务管理模块､清分管理模块､信息管理模块､系统管理模块､用户管理模块､资源管理模块､数据管理模块､培训测试模块､容灾备份模块十个主功能模块 [6]。
3) 软件服务层SaaS：SaaS层面向管理者和具体系统使用人员，将开发环境､应用软件和操作系统封装成标准WebServices服务提供信息查询与发布等按需服务。
Figure 2. The AFC system architecture based on private cloud
图2. 基于私有云的AFC系统架构图
4.3. AFC系统软件功能设计
作为综合信息管理系统，AFC系统的功能与建设规模、运营模式、管理机制等密切相关 [7]，其重点集中部署在私有云平台中，通过私有云平台实现统一的监控与管理；同时，车站终端设备直接受控于私有云平台，减少车站及线路系统中间收发环节，实现客流数据和票务数据传送，其软件主体功能如图3所示。
软件系统构建过程通过组件提供平台服务 [8]，基于私有云的AFC软件系统主要包括前端收发、设备运营参数、设备管理、监控、库存管理、数据分析、现金管理、报表、通信和维修管理十方面 [9]。其中，前端收发组件(Front-End Module, FEM)负责车站终端设备与私有云平台之间的通信传输，实现车站终端设备数据采集、私有云平台数据下发等功能；设备运营参数组件(Equipment Operation Data Module, EOD)负责对系统运营过程中的票卡交易、设备参数、资金流通等数据进行管理，实现包括EOD文件生成、EOD版本激活、EOD数据分发、EOD数据版本管理、内务处理等功能；设备管理组件(Equipment Management Module, EMM)负责对系统中设备的运营状态信息进行实时的监控管理；监控组件(Supervision Module, SUP)负责监控线网内所有车站及设备的实时运行状态和客流信息，并能够向线网内所有车站及设备发送控制命令 [10]；库存管理组件(Stock Management Module, SMM)负责系统票务管理中的实时库存管理、库存调配管理、运营日结束库存处理和内务处理的工作；数据分析组件(Data Analysis Module, DAM)负责对系统运营状态和票务数据进行分析和辅助决策；现金管理组件(Cash Management Module, CMM)实现对现金的管理、运营日结束后现金的处理以及内务处理工作；报表组件(Report Module, REP)负责报表产生、发布、查看与打印等全过程的功能；通信组件(Communication Module, COM)负责系统各层之间的实时通信；维修管理组件(Maintenance Management Module, MMM)主要负责设备故障管理、备品备件管理、维修工单管理、维修计划管理、数据同步和内务处理等。
Figure 3. The AFC software function module diagram based on private cloud
图3. 基于私有云的AFC软件功能模块图
4.4. 基于FTP的数据流交换设计
终端设备在系统运行过程中产生的大量数据，包括交易数据、收益数据、审计数据、设备事件数据 [11]。这些数据在终端设备产生后，通过SC逐层上传到ACC；同时，上级系统维护的设备配置参数、结算对账数据、各类程序文件以及资源文件也使用文件传输到下级系统。
由于AFC系统对这些数据传递的实时性和完整性有较高要求 [12]，因此本文提出采用FTP文件传输协议对此类数据进行传输，具体交换过程包括：
1) FTP协议将在AFC系统各级数据传输中予以应用，包括ACC、SC、SC/SLE，但仅相邻的两层可进行数据文件交互传输，数据文件不允许跨层传输。
2) ACC/SC之间的数据传输以ACC为FTP服务器，SC为客户端。
3) SC/SLE之间的数据传输以SC为FTP服务器，SLE为客户端。
4) 在FTP服务器和客户端建立Socket连接通讯时，服务器将FTP访问信息传输给客户端，包括FTP的IP地址、端口号、用户名、访问密码、工作目录等信息。
当FTP客户端产生数据文件，需要上传服务器时，客户端主动访问服务器，将文件put到指定的FTP工作目录，需要下发至客户端时，服务器先将数据文件复制到本地FTP工作目录，然后通过Socket报文通知客户端下载文件。客户端接到Socket指令信息后，立刻访问指定的FTP服务器，get相关数据文件。根据特定的业务需求，客户端需要轮询或定期查找服务器端指定的FTP工作目录，主动查找。
同时，FTP服务器本地负责维护FTP工作目录内所有的数据文件。FTP服务器端检测到客户端上传的文件后，应立刻处理移出工作目录。同时，FTP工作目录下用于供客户端下载完的数据文件，服务器本地也需做定期整理。
要保证上述数据交换准确性和及时性，AFC的所有节点计算机(包括线路及车站主机与终端设备)必须具有相同的系统时间，并与清分中心进行时间同步。清分中心从外界时钟源(卫星GPS数据或者通信系统)获得准确的当前时间，来设置自己的系统时间，并成为线网标准时间的源头。各节点计算机之间的时间同步采用NTP协议(RFC1305)来实现。
4.5. 基于TCP的指令流交换设计
对于系统内实时性要求高的上行和下行消息，本文提出采用TCP联机报文方式传送，主要应用于车站模式信息传输、设备监控、客流监控等。
TCPSocket通讯将在AFC系统各级实时通讯中予以应用，系统中仅相邻的两层可进行通讯交互。实时通讯双方可互为Socket服务器和客户端。ACC之间指令流交换以ACC为上层系统，SC为下层系统；SC/SLE之间指令流交换以SC为上层系统，SLE为下层系统。
当上层系统启动以后，其本地的TCP服务器立刻启动，并等待下层过来的TCP链接请求。下层系统启动后，其同样首先将本地的TCP服务器打开；然后根据本地配置的上层系统TCP通讯服务器的IP和端口地址，发起主动链接请求。连接成功后，上层系统记录下层系统的相关信息，例如IP及节点编号，同时将上层系统的上下文信息传递给下级系统，包括FTP服务器访问信息，车站广播信息等。如果报文格式正确，处理相关业务，待进行相关的业务处理完毕后，再发送业务处理结果报文。如果报文解析异常，以MACK报文返回发送方，并填写具体的错误代码。
数据消息的发送者作为客户端向接收者设置的TCP服务器发起TCP连接请求，接收者接受连接请求，建立TCP连接。发送者发出消息报文(请求消息)，接收者返回应答消息。发送者收到应答消息后，根据需要，可再次发送另一个请求消息，或者断开连接。接收者设置的TCP服务器从不主动断开连接。当数据消息的发送者在发出请求消息后，在业务规定的时间内未收到应答时，应按数据消息的业务要求，决定是否对其进行重发。重发的请求应和原始的请求消息完全相同。超时时间和重试次数通过通信参数进行设置。
5. 总结
本文结合城市轨道交通网络化发展需求，研究国内外现有AFC系统的不足，结合主流的AFC系统架构研究热点，深入分析了AFC数据信息流和云平台的功能和非功能需求，通过引入云计算技术优化传统五层AFC系统架构，提出构建基于私有云平台的AFC系统融合架构方案。架构中通过私有云平台替代传统AFC系统中的ACC层和LC层，提出不再在SC层设置数据存储和计算资源，并在云平台上实现统一监控与管理。
本文提出私有云平台AFC架构体系，通过应用系统、数据库软件的集群部署和负载均衡达到较传统结构更高的可靠性和性能；通过将核心关键应用系统部署于不同物理机多个虚拟环境中，坏一台机器不影响整体运行，提高稳定性；通过动态的负载均衡将串行业务分解到集群中，提高性能。在保证性能和可靠性的前提下，通过ACC上云实现节流，有效降低建设和维护成本，并更好地提升客户服务体验。
同时，通过云交付模式，可根据业务体量和预测进行资源分阶段规划，根据阶段规划实现运维费用的阶段划分，结合阶段化的服务采购方式，提供有保障有监督的、持续的运维服务。让车站终端设备直接受控于私有云平台，减少车站及线路系统中间收发环节，有助于应对大客流的常态化，解决海量数据的计算与存储等问题，并能满足全局性运营数据的管理需要。
在城轨票务业务系统上云后，ACC统计了票卡账、交易账、客流账、资金账、收益账，是城轨票务的大账本，使得AFC系统可作为会计科学在地铁票务专业的整体解决方案，推动城轨账户系统和记账系统的统筹建设，推动上层增效增值业务的拓展。
基金项目
《基于重点对象特征及行为模式分析的“智慧监护”平台研究及体系应用》，2020年度贵阳市国家创新城市“百城百园”行动项目，贵阳市科技局(筑科项目[2020] 22号)。