system: [SYSTEM]

user: 4. 基于私有云的AFC架构设计 4.1. 整体逻辑架构设计 针对当前AFC系统存在的不足，结合平台需求和数据信息流，在五层AFC架构基础上，本文提出基于私有云的AFC系统架构。架构自底向上分为车票层、车站终端设备层、车站层、私有云平台层，整体逻辑架构如图1所示： 1) 车票层：车票层集合了各类型车票，包含单程票､储值票､计次票､计程票､纪念票等，是AFC系统的支付媒介； 2) 车站终端设备层：车站终端设备包括自动售票机(Ticket Vending Machine， TVM)、自动检票机(Automatic Gate Machine， AGM)、半自动售票机(Booking Office Machine， BOM)等直接与乘客交互的车站级设备； 图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服务提供信息查询与发布等按需服务。 图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)主要负责设备故障管理、备品备件管理、维修工单管理、维修计划管理、数据同步和内务处理等。 图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服务器从不主动断开连接。当数据消息的发送者在发出请求消息后，在业务规定的时间内未收到应答时，应按数据消息的业务要求，决定是否对其进行重发。重发的请求应和原始的请求消息完全相同。超时时间和重试次数通过通信参数进行设置。