杨扬

（广州地铁设计研究院股份有限公司，广州510010）

1 引言

随着城市轨道交通快速发展进入新常态，新一代信息技术从根本上变革了轨道交通的运行、管理、服务方式，使城市轨道交通更加智能、智慧。我国城市轨道交通建设初期，多采用一线一批、一批一建的方式，信息系统基本上也是随用随建设，缺少统筹规划，导致系统相对独立，应用、数据、网络、设备设施等资源集约利用率不高。随着国民经济和社会发展，城镇化进程加快的需要，城市及城际轨道交通成网络化运营局面逐渐形成。同时，伴随着云计算平台在各行业的广泛应用，其数据集中共享、业务快速响应和灵活扩展的优势日趋明显，云计算部署速率、安全性大幅度提升，部署成本逐渐被轨道交通行业接收。

2 传统的系统构架方案

城市轨道交通传统的系统架构主要采用以线路为单位，线网和线路两级管理的建设模式。系统架构层次复杂，建设和运维成本较高。由于系统专业分工细，各自独立建设，数据格式无法统一，实现数据共享和挖掘应用难度很大。且各系统平台自成体系，后期开发对既有厂商依赖性强，较难适应运营不同时期的需求变化。

3 云平台的系统架构方案

当城市轨道交通建设不断加快，运营效率逐步提升，各业务系统之间的信息交互必将更加频繁、实时性要求更高。伴随轨道交通管理水平的提升以及新技术的应用，构建以云计算为核心的轨道交通线网综合业务平台，是城市轨道交通可持续发展的关键和提高运营管理、服务水平的重要载体。

综合业务云平台采用虚拟化技术、分布式存储技术、云资源管理技术、信息安全技术等，搭建适应地铁综合生产业务基础云平台，实现计算、存储、网络资源按需分配、统一管理和集中监测，提高资源利用率，便于业务快速部署和扩展。

3.1 云平台总体框架

综合业务云平台总体框架由“四个层面、三大体系”构成[1]。“四个层面”即感知层、网络层、数据平台层和应用层；“三大体系”即标准规范体系、信息安全体系以及运维管理体系。以感知网、车载网、车地通信网和地面网络、数据采集平台、云计算平台、大数据平台和存储资源池等为基础，围绕决策管理、运营管理、安全防范、乘客服务、维修、资源开发6 大业务领域。

各层级的功能如下：

1）感知层具备源数据的采集功能，源数据在各系统的运行过程中直接产生。源数据的采集通过数据平台及各应用系统的传感器等实现，感知层既能获取标量信息，又能获取视频、音频和图像等矢量信息。

2）网络层具有信息系统层级间的信息传输功能。

3）数据平台层具有信息系统基础数据、共享数据、源数据的采集、存储和交换功能；平台层具有信息的数据处理、统计、分析等功能。为数据的全生命周期管理和实时数据、历史、周期性数据分析、挖掘提供技术支撑；可构建生成轨道交通企业所需要各种指标及分析模型。

4）应用层主要包括运营生产、运营管理等领域的应用。应用层可根据需要，扩展各领域的新应用。

3.2 系统融合实施方案

结合网络化运营管理和决策分析需要，对轨道交通全线网的行车、设备、调度指挥、客流等进行数据收集、存储、分析、挖掘，形成融合生产网。通过构建融合生产网，将轨道交通线网投融资、建设、运营及管理数据进行合理统计和分析，探寻轨道交通建设、运营及管理的规律，从而科学指导轨道交通后期的规划、建设和网络化运营管理。

系统融合方案（见图1）将生产系统共建统一综合业务云平台，包括综合监控ISCS、乘客信息系统PIS、门禁系统ACS、集中告警系统、线网指挥系统、线网视频、智能运维、智能客服、安检系统等。综合业务云平台前期考虑与清分中心云平台信息互通，后期可考虑将清分中心云平台相关业务逐步飘移至综合业务云平台。

云平台为每条线路承载业务划分为一个VDC 资源池。考虑整体业务系统的稳定性，和后续业务上线速度，支撑云平台资源需要根据业务应用工作负荷需求进行弹性伸缩，IT 基础架构应与业务系统耦合。在业务系统进行容量扩展时，只需增加相应数量的IT 硬件设备。

图1 系统融合实施方案示意图

3.3 云平台网络方案

根据轨道交通控制中心的规划，建议各线路的主用资源池设置在本线路的控制中心，备用资源池设置在临近的控制中心。主中心的数据中心网络架构采用分层分域设计，其中层次上划分为核心交换、业务分区以及存储分区。主中心的数据中心网络由核心交换、业务分区网络以及存储网络构成。核心交换设置数据中心交换机；各业务分区根据实际业务诉求分别采用汇聚、接入2 层或单接入网络架构。根据实际业务需求，存储网络分别采用FC 交换机、以太网交换机构建不同的网络存储资源池。云平台网络方案示意图如图2 所示。

图2 云平台网络方案示意图

3.4 系统主要功能

根据综合业务云平台业务部署，综合业务云平台主要功能分为运营生产功能、安全保障功能、乘客服务功能、建设管理业务等几部分内容。

综合业务云平台运营生产功能包括运营生产管理功能以及各条线路通信、行车、电力、环境与设备监控、防灾、票务管理、乘客服务和动态管理、设备维修及信息管理等运营调度和指挥功能，对地铁运行的全过程进行集中监控和管理；在非常情况下，也是对各类事件处理的指挥中心；同时还是全线所有相关运营管理信息的集散地和交换枢纽。

建设管理业务包括工程项目和职能管理两大类型业务。工程项目业务包括新线规划、前期管理、设计管理、施工管理、验交管理、后续管理等模块；职能管理业务包括综合管理、总体管理、质量安全管理、合同/投资管理、技术/科研管理等模块。

3.5 云平台系统接口方案

云平台的系统接口分为内部接口和外部接口。由于线路信号系统ATS、自动售检票系统AFC、视频监控系统CCTV、乘客服务系统PIS、综合监控系统ISCS、门禁系统ACS、电力监控系统PSCADA 统一由云平台纳管。各系统之间数据接口不再像以往的物理接口，而是逻辑接口。系统数据之间的交互为东西流向，资源池在不同的VPC 之间交互[2]。

云平台与外部系统，如公安部门、气象部门、交通运输部门、地震局等相关部门进行接口，负责采集相关数据信息，进行信息交换，实现信息共享。云平台与外部系统（公安、气象、交通、地震等）接口界面在云平台对外接口交换机侧，经互联网通过千兆或万兆接口与外部系统通过标准的、通用的、开放的、软件解码的协议进行传输，将外部系统信息接入云平台接口交换机中。

3.6 云平台的运维管理模式及挑战

既有运营维护模式的现状是各专业运维的业务即管理硬件资源，同时也管理软件应用。在云架构下的运营维护模式，云平台专业运维业务人员对于硬件资源统一管理，各专业运维人员仅需管理软件应用。因此，运维业务分工由原来的设备资源和业务统一维护模式，变为云架构下的设备资源和业务分开的维护模式。

由于云计算带来运维模式、运维职责、运维流程、组织和分工变化调整，因此，运维的管理架构需要同步调整。云平台的运维管理模式变化示意图如图3 所示。

图3 云平台运维管理模式变化示意图

1）运维模式：由烟囱式垂直分散维护向平台化横向集中维护转变；

2）维护界面：资源平台划归专门的云运维部门；云平台运维团队虽然不管理业务，但要支撑业务整体的稳定性；

3）人员技能：云维护人员技能要求更加专业化，精细化，平台管理人员素质要求更高。

4 结语

随着城市轨道交通信息化发展及云技术的成熟，基于新IT 架构的轨道交通线网管理模式已在积极探索[3]。单系统云平台的建设成本较高，随着云技术的发展和成熟，多系统综合部署的云平台，是实现线网全面融合重要技术支撑[4]。为全面完成轨道交通综合业务云平台建设，目前仍面临不少挑战。如何处理好软件平台与硬件设备兼容性问题、各专业系统信息安全等级保护与云平台信息安全之间的关系都将是未来云平台能否顺利建设的关键因素。