城轨云平台上AFC建设的模式分析及选择

严浩毓

（太原轨道交通集团有限公司，山西 太原 030032）

1 城轨云平台上AFC建设的模式分析

1.1 区域线路中心的模式

AFC（自动售检票系统）是一个自动化系统，可基于计算机、通信、网络和自动技术执行车票销售、票务检查、发票、统计、计费、管理和分类的全过程。随着信息通信技术的发展，AFC系统在城市轨道交通的票务系统中得到了广泛的应用。

在同时建设多条新线路和改造及扩展现有AFC系统的背景下，如果更多的多轨线路继续采用独立的单线建设模式，将不可避免地带来高昂的建设成本、分散的管理和较低的成本。

为了满足运营公司对多线和统一管理的需求，ZLC（区域线路中心）的模式可以统一线路中心的建设、运营和维护标准，避免因多个集成商在不同时期的建设、运营和维护而造成的协调问题和技术障碍，从而提高运营、管理和维护的效率，降低成本。其主要优势如下：①降低多线路的建设成本。在线路网络快速建设发展的情况下，可以降低建设许多新线路的成本，同时避免了系统的重复建设，缓解了政府的财政压力。②实现集中管理，统一协调。在大规模进行地铁建设时，区域线路中心网络集中管理模式可以使运营管理更加高效、有序、科学。③提高运营管理及维护的效率。当大规模构建有线网络时，如果在区域级别上进行日常的运营管理和维护，则可以降低运营和维护成本并提高运营效率[1]。

1.2 多线路中心模式

AFC系统通常采用具有一定程度可扩展性的标准5层体系结构系统。线的中心是AFC轨道交通系统的核心部分。从ACC（轨道交通自动售检票清算管理中心）的计费中心接收订单，并将ACC请求的数据发送到AFC。将订单发送到SC（车站中心），并接收SC发送的数据。从一条线路的市区到一条共享线路的市区的过渡，其将不可避免地导致AFC系统的灵活架构。

1.2.1 设置多线路中心

多线路中心在同一运营商的管辖范围内共享线路资源，因此可以在ACC层中处理线路之间的信息。在每个运营商管辖的多线路中心的基础上，它可以被视为小型的分拣中心，可以对其管辖范围内的线路上的操作、票证和数据分类进行补充管理，从而节省资源，并提高经济效率和安全性系统[2]。同时，ACC是不同的操作员，不再有特定的行，因此简化了分类模型并减轻了ACC的工作压力。

1.2.2 合并多线路中心和清分中心

在计划中的短期和长期路线很少（通常少于6条）的城市中，由于有一名操作员且排队的车站较少，因此分类和核算压力并不大，建立基于经济和实践原则的集成系统是可能的。ACC系统的多线中央系统，每条线路上的站计算机系统通过线路汇聚设备直接或间接连接到多线路中心，用于获取整个链接网络的所有交易数据，并负责管理线路操作以及清除和结算卡以及多合一线路。集成架构模型改善了系统，在一定程度上提高了系统效率，节省了构造和维护资源，并限制了线路接口的边界。

1.2.3 多线路中心系统的功能定位

在网络运营、节省建设投资、产品标准化等基础上，提出了多线路中心。多线路中心的引入将导致每个ACC级别的多线路中心的功能发生变化。线路中心和车站中心功能相互作用的准确定义是提高运营效率和稳定性的前提。

多线路中心系统已成为轨道交通网络发展中的一种趋势，对多线路中心的组成、功能布局和施工计划的说明是施工的基础。根据功能需求，分析了多线路中心的组成，引入后AFC系统的结构变化以及使用ACC进行功能划分[3]。最后，结合北京和深圳的设计案例，总结了各自设计模式的特点。为随后的多线路中心城市化提供提示和参考，每个城市都可以根据自己的建筑计划和系统架构选择合适的建设计划。随着AFC系统中在线支付方式的逐步推广，第二票务服务平台与多线路中心系统之间的安全内部通信需要进一步研究。

1.3 多线路中心加车站中心上云模式

作为对AFC系统现有架构进行的国家改革的一部分，通过分析北京地铁和广州地铁采用多线公共线路中心的计划，提出了区域性建议。最终提出了一种基于云策略部署AFC系统的创新方法，该方法大大减小了AFC系统的大小。在对城市轨道交通自动售票系统技术条件进行分析的基础上，研究自动售票系统的组成、结果和布局，详细分析了自动售票系统的5层布局并提供了每个层系统的最终模块组成。该系统弥补了现有AFC维护管理系统效率低下的问题，使配置维护管理更加高效和便捷[4-6]。

2 基于城轨云平台的AFC管理模式方案选择

AFC系统部署在城轨云平台上主要有3种模式选择的方案，即保留各线路中心模式、多线路中心模式和多线路中心加车站中心模式。这3种方案是针对不同城市不同的建设投资方式而产生的，如何针对不同的地铁建设投资方式选择合适的基于城轨云平台的AFC系统对于地铁线路的决策者和投资方而言无疑是一种博弈与挑战。

2.1 模式选择的依据

近年来很多城市开启了大规模的基础设施建设项目，众所周知，基础设施建设对于一个城市的财政而言无疑是一只巨大的“吞金兽”。由于其投资金额巨大、项目建设周期长、项目回报周期长，很多地方政府的财政负担增大，政府负债率偏高，甚至有些地方政府的负债率已经超出了国家的允许范围。城市轨道交通对于地方政府就属于投资金额巨大的基础设施项目，对于很多符合地铁修建条件的城市来说都不堪重负，为了减轻财政负担和不增加政府负债率，很多城市选择使用PPP（Public-Private Partnership）模式来投资建设城市轨道交通线路，即政府和社会资本合作。使用该模式可以减轻政府的财政压力，但对于城市轨道交通线路的建设来说，社会资本方成立的项目公司注重的是成本的节约和后期运营过程中对运营数据的准确掌握，而代表地方政府的轨道公司则注重有效管理整个城市轨道交通线网的运行。而AFC系统恰恰是社会资本方和政府方关注的焦点，因此必须通过合理的理论为基于城轨云平台的AFC系统的管理模式选择提供有力的支撑。

2.2 模式选择的过程分析

2.2.1 逻辑维分析

在模式选择分析中首先要明确问题的性质，特别是在问题的形成和规划阶段，搞清楚要研究的是什么性质的问题。对于该模式选择的问题，可以明确不同的模式在建设过程中会产生不同的投资额度，其中保留各线路中心的模式所产生的的投资是最大的，由于城轨云平台本身已经提供了足够的计算和存储的资源池，各线路再建设相应的LC（线路中心）时显然会增加成本的支出，其所包含的车站中心同样在工程建设的成本之中。MLC（多线路中心）上云模式对于线路投资方来说相应减少了成本的投资额度，但是车站中心的建设一样不可避免地需要产生硬件采购的成本。多线路中心加车站中心上云模式可以在最大程度上降低线路投资方的成本投入，由于MLC和SC全部部署在城轨云平台上，由云平台进行统一纳管和统一调度资源，各线路只需要把相对应的软件部署使用容器或者虚拟机的方式部署在云平台上，对应的工作站使用云桌面的方式进行监控和控制管理即可。但是多线路中心加车站中心模式对于各线路可能造成无法对自己所运营的线路进行独立的改造和升级，给线路运营商独立自主的运营带来挑战。

2.2.2 时间维分析

从时间维的角度去进行分析，3种不同模式的建设周期从保留各线路中心模式到多线路中心上云模式再到多线路中心加车站中心上云模式依次减短。由于保留各线路中心模式的硬件设备最多，所占用的硬件机房的面积最大，因此该模式在建设过程中所花费的时间也是最多的。就目前的国际形势而言，全球的芯片产能紧缺，所有的服务器硬件的芯片到货时间基本为6～12个月，更多数量的硬件代表着更多时间的消耗。而多线路中心加车站中心上云的模式由于统一使用城轨云平台的硬件资源，故其所花费的系统建设时间相应也是最短的。

2.2.3 知识维分析

在AFC系统的网络构建过程中，涉及的接口种类多，结构复杂。外部接口主要体现在整个系统拓扑结构的两端，最低端是车站终端设备读卡器与各种票卡的接口，包括地铁单程票、各类纪念票和城市一卡通票。顶部是分拣系统和城市智能卡系统之间的分拣和对接接口。内部接口主要是结构之间的数据接口，包括分拣系统与线路中心的接口、线路中心与车站系统的接口以及车站系统与终端设备的接口。同时，AFC系统中存在多条线路的内部通信节点较多，物理网络结构也较为复杂。因此，基于网络的AFC系统涉及的数据类型多、结构复杂、规模大、传输节点多，而这些数据与地铁票务管理和排序统计相关，其重要性不言而喻。这样，在AFC系统网络建设过程中，如何有效保证系统和数据的完整性与安全性就显得尤为重要。城市轨道云平台在系统安全中使用防火墙和网关，可以有效隔离潜在的系统安全风险。对于互联网票务业务，在使用云平台时，端口白名单方式确保互联网票务业务不受影响的同时，最大限度地减少对外网的接入，最大限度地保护整个系统的安全。

3 模式选择的结果

选择的模式为多线路中心加车站中心上云模式。软件是AFC系统建设的核心。需求的统一通过软件实现，主要目的是保证各线网中各条线路AFC系统的互联互通，为各条线路的网络化运营打下基础。同时软件系统还要保证AFC系统操作规则、票务规则以及相关业务处理流程的统一，模块间数据格式、各组件和接口的统一，为整个线网互联互通、各条线路无缝接入提供了技术基础；密钥管理系统的轮换和票卡的应用统一，保证了各线路的票卡在线路间能够正常使用[7]。

3.1 关键模块的统一

在设备的设计和生产中，不同的系统集成商都有各自的特点。所有设备模块相互兼容的要求对于系统集成商比较困难，这样并不利于招标工作的开展，而且减少了设备的选择。但对于一些关键模块，如主控、读卡器等，应制定统一的软硬件数据接口和技术规范，可以增加常用部件的数量和种类，同时降低维护成本，减少备件种类和数量。

3.2 用户界面的统一

AFC系统的用户界面一般分为面向乘客的操作界面和运维人员的操作界面。在线网运营中，用户界面需要具有统一的要求。面对乘客和维修人员的相关软件界面需要有统一的显示规范，如界面的布局、界面元素的大小和颜色、错误提示信息等，都需要统一的操作流程。针对各类用户，保证不同系统集成商开发的系统在操作和信息获取上没有差异，不需要有重复熟悉的流程，降低培训成本。

3.3 新线AFC系统的接入调试

在地铁建设大规模进行的过程中，一定会遇到新建线路接入线网系统的问题。新线AFC系统的接入和调试是一个非常复杂的过程。它不仅要保证新线AFC系统的各种功能的验证，还不能影响既有线的正常运营。同时，接入调试还包含大量的培训工作，测试方案复杂，耗时较长。为确保新线路接入调试工作顺利完成，达到巡检系统和维修设备的目的，要求一方在调试过程中牵头，多方配合，提前谋划，精心准备，制定详细的实施方案并严格执行。同时，要明确各调试阶段的工作重点，划分调试的定性和定量风险，确定工作的优先级别，区分风险和要求。

太原轨道交通2号线AFC系统主体部署在太原轨道交通城轨云平台中。在控制中心云平台中部署LC系统，包含LC数据库服务器、LC应用/交易服务器、LC通信服务器，均采用双机部署，由城轨云平台提供对应的计算、网络、存储、安全资源，并且为了保证可靠性，LC系统中同业务的双机由云平台的云主机反亲和性配置功能，保证处于不同的宿主机中；控制中心有城轨云平台为AFC系统提供云桌面服务，实现工作站的云化部署；车站部署SC系统，每个车站中部署1台SC虚拟机，承载在城轨云平台车站云节点中，可以通过控制中心云平台实现统一管理。

太原2号线清分中心与互联网售票系统也采用云化部署模式，并且在传统IaaS服务的基础上，采用了PaaS服务的形式对业务系统进行了支撑。通过城轨云平台中的容器服务与微服务治理等功能，保证了互联网售票系统面对海量数据并发请求的高效响应。