城市轨道交通线网指挥系统数据处理平台方案探讨<br/>——以云平台、大数据平台为基础

城市轨道交通线网指挥系统数据处理平台方案探讨
——以云平台、大数据平台为基础

2021-06-05王圣炜

工程建设与设计 2021年8期

王圣炜

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

1 引言

国内城市轨道交通随着网络化运营、跨线路协调的需要，各个城市逐步开始建立线网指挥系统，目前北京、上海、广州、深圳、成都、西安、苏州等地已建立了线网指挥系统。各大城市早年建立的线网指挥系统是构建在各线路中心之上的线网中心，形成了线网—线路—车站的三级管理、线路—车站—现场的三级控制模式，早期线网指挥系统大多以“只监不控”的方式构建[1]。

2020年8月6日，交通运输部印发《关于推动交通运输领域新型基础设施建设的指导意见》（交规划发〔2020〕75号），围绕加快建设交通强国总体目标，推动交通基础设施数字转型、智能升级，建设便捷顺畅、经济高效、绿色集约、智能先进、安全可靠的交通运输领域新型基础设施。

国务院《“十三五”国家科技创新规划》和党的十九大均提出了对云计算、大数据等新技术推广应用战略；工信部《云计算发展三年行动计划（2017—2019年）》（工信部信软〔2017〕49号）、科技部和交通运输部《“十三五”交通领域科技创新专项规划》（科技部交通运输部国科发高〔2017〕121号）的发布表明信息化与自动化两化融合的工业互联网已成为新时代技术发展的趋势，多层域感知、人工智能、移动互联、主动协同等技术的应用，推动了智能轨道交通系统的全面创新[2]。

2020年3月，《中国城市轨道交通智慧城轨建设纲要》正式发布，开启了城市轨道交通行业交通强国建设的新征程。中国城市轨道交通行业以强国建设为战略导向，以推进城轨信息化、发展智能系统、建设智慧城轨为主题，以城轨交通的关键核心业务为主线，以数字化、智能化、网络化为手段，构建高度集成的城轨云与大数据平台。

国家政策支持、信息技术发展趋势、轨道交通行业的标准均推动了轨道交通由传统的智能化向智慧化演变。作为可以统筹全线路的线网指挥系统，也逐步承担起城轨智慧大脑的角色。单一的“只监不控”模式需进行改变，演变成“又监又控”的模式[3]。线网指挥系统在新时代轨道交通的发展下也由传统的线网综合监控及应用系统、线网通信系统扩充到由线网综合监控系统、线网通信系统、线网智能客服、线网安防平台、线网电力调度系统、线网行车调度系统、综合应用系统、线网安检系统、线网门禁授权系统等共同构建的8大中心，分别是：线网运营数据中心、线网日常行车协调指挥中心、线网电力调度与能耗管理中心、线网机电设备调度中心、线网运营消防与安防中心、线网运营信息集中发布中心、线网突发事件处置中心、线网对外协同中心。

传统的小型机架构下的线网指挥系统随着线网智慧化功能的不断扩充将面临计算、网络、存储等瓶颈，改造费用将随着智慧化的引入变得越来越高，工程实施将越来越困难。

随着技术的发展，云技术、大数据技术越来越多地被应用到城市轨道交通中。智慧化功能的增加需对传统的线网数据处理平台进行改进。

2 数据处理平台方案

2.1 传统数据处理平台方案

传统数据平台构建在小型机服务器上，在数据处理平台架构上采用多服务器分担处理业务技术，由服务器完成从数据采集、数据处理、数据存储、人机界面显示的全部流程。线网指挥系统分别设置数据服务器处理各线路系统上传的实时数据和历史数据；设置应用服务器负担应用服务（含应急指挥、信息发布、KPI指标统分等）功能；设置防病毒服务器和WEB服务器实现其他系统安全访问和信息的发布；同时系统数据处理平台还设置有高效的存储系统和数据备份系统。

软件体系上采用数据直通应用的方式，数据专用，数据通过采集经过数据库直接到达应用，实时性强，系统相对独立，可实施性强[4]。

1）优点：该数据处理平台模式符合当时对系统可靠性、实时性、稳定性、安全性等要求，是城市轨道交通应用最多的信息化处理平台模式。在该模式下，硬件设备、软件、数据等均为专用。

2）缺点：软件开发难度随数据量的增加而增加，软件拓展性弱，二次开发难度大，系统间数据关联性弱，软件开发随着数据量越来越大将遇到硬件性能不足的瓶颈。

2.2 集中处理平台+实时数据库方案

数据平台架构：分为实时处理部分（数据库）和非实时（含近线）处理部分，其中，非实时处理部分采用大数据平台。

实时处理采用云架构，并设置实时数据库和实时监控软件，在数据处理速度上能满足各系统工业级响应。离线应用均采用大数据平台进行分布式计算，具有更快的响应性能和统计分析性能。

软件体系：采用数据到服务平台后由应用选择服务方式。

数据采用服务方式，业务微服务化，由服务平台开放给上层应用。可实现跨专业调用数据。各类应用相同的部分下沉至中台，并以服务方式提供给应用，减少应用重复开发。平台扩展性较好，扩充中台和服务的方式能更快速适应上层应用的变化[5]。架构如图1所示。

图1 集中处理平台+实时数据库方案

1）优点：将实时与非实时部分处理平台分开，实时部分处理平台满足部分工业控制系统对实时性高要求的需求，可用于进行实时监控，如ATS（列车自动监控系统）、SCADA（电力监控系统）。非实时部分数据大多为分析型数据，用于数据分析、挖掘，该部分数据没有调度类系统对实时性要求那么高，但需要进行亚秒级的数据分析和呈现。在传统的小型机架构下，一经部署，随着功能的扩充会遇到硬件的计算瓶颈，采用云技术后，计算资源可做到按需分配、对各类接口及上层功能模块进行容器化、微服务化改造，加上大数据平台对于海量数据（PB级）的快速分析及响应能力可满足城市轨道交通对数据分析处理、统计等需求。系统扩展性好，新增数据接入可直接扩充存储节点，统计分析能力不够可横向扩充计算节点，上层应用需求改变，可仅改变服务平台，无需对上层应用进行大幅度改动。

2）缺点：城市轨道交通行业内应用案例较少，但在其他行业已有应用案例，大数据平台及云平台的引入会增加工程投资。

2.3 数据集中处理方案

数据平台架构：分为实时处理部分和非实时（含近线）处理2部分，均纳入线网智能调度平台。

线网智能调度平台为各应用提供用于实施数据监控用的实时数据库，根据其他应用特点提供所需关系数据库、非关系型数据库、MPP数据仓库等。

软件体系：采用数据到服务平台后由应用选择服务方式。

数据采用服务方式，由服务平台开放给上层应用。可实现跨专业调用数据。各类应用相同的部分下沉至数据处理平台，并以服务方式提供给应用，减少应用重复开发。平台扩展性较好，扩充中台和服务的方式能更快速适应上层应用的变化。架构如图2所示。

图2 集中处理平台方案

1）优点：实时与非实时部分合并处理平台，利用容器及微服务技术对应用进行部署，快速适应需求端、接口端、处理端的变化。利用云技术、大数据技术系统在实时部分和非实时处理部分均能灵活地进行系统扩展。

2）缺点：城市轨道交通行业内应用案例很少，但在其他行业已有应用案例，大数据平台及云平台的引入会增加工程投资。

3 数据处理平台的选型

因大数据平台的处理能力，目前暂未达到工业级系统（SCADA、ATS等）对实时性的响应要求。建议数据处理平台可分步走，按近期和远期进行部署。因集中处理平台+实时数据库方案和集中处理平台方案均采用云技术、大数据技术，方案具有延续性。可根据目前的技术发展情况选择数据处理平台。近期采用集中处理平台+实时数据库方案，后续随着技术的发展逐步将实时处理平台迁移至集中处理平台。