城市轨道交通综合监控系统数据库部署及服务器配置方案研究

袁伟（铁道第三勘察设计院集团有限公司广东分公司，广东深圳518000）

城市轨道交通综合监控系统数据库部署及服务器配置方案研究

袁伟
（铁道第三勘察设计院集团有限公司广东分公司，广东深圳518000）

城市轨道交通项目中综合监控系统的建设，依据线路特点、技术发展水平、运营管理技术水平及需求，在数据库部署及服务器配置方面有不同的方案实践，各方案均有其不同的侧重点及优缺点，对各方案进行归纳和总结，为综合监控系统的工程设计提供设计思路和方法。同时提出了基于服务器虚拟化技术的服务器配置方案，为云计算在城市轨道交通综合监控系统中的应用提出了新的思路。

综合监控系统；数据库部署；服务器配置

0　引言

综合监控系统是实现城市轨道交通自动化调度管理的重要工具，也是当今城市轨道交通监控系统的主要发展方向。设置综合监控系统的目的，就是为了增强城市轨道交通系统指挥调度的统一性、灵活性和系统间的协调运作能力，因而综合监控系统性能的优劣直接关系到它是否能在城市轨道交通运营管理中发挥应有的效能和能否满足城市轨道交通运营管理的需要。综合监控系统数据库部署及服务器配置方案是影响综合监控系统性能及投资的关键因素[1]。本文依据综合监控系统的发展趋势及多年的设计和工程经验对数据库部署和服务器配置方案进行归纳和总结，为综合监控系统的工程设计提供设计思路和方法。

1　数据库部署方案

综合监控系统根据运营管理模式、采集信息的处理方式以及中心级存储和管理数据量的大小，在数据库部署上可分为以下四种方案。

方案一，中心集中与站点分布的数据库部署方案：在中心级设置全局实时数据库和历史数据库，将车站级的所有联网子系统的全部数据实时地采集到中心级来进行统一的管理和控制[1-2]。由于数据量的庞大，处理复杂，需要分别设置实时数据库和历史数据库，以便监视和控制全线所有监控对象，实时反映现场状态并进行及时的响应和存储。车站级仅设实时数据库，仅用于监控，负担本站所辖范围内的数据采集、报警分析、运算控制、事件记录等事务。车站不设历史数据库，数据以文件形式存储，历史数据的存储、整理、统计、分析等数据管理工作不在车站级实现。如果某个站点需要查询相关数据，则必须通过综合监控系统主干网络来远程调取中央全局历史数据库中的相关数据，传输网络的依赖性较大。

该方案有利于数据的多重保护和历史数据的集中管理，但需依靠综合监控的骨干网实现历史数据的查询，对网络具有一定依赖性，同时要求骨干网具有较大的带宽，且系统投资较大。适合车站规模大且站点数目较多的线路。该方案数据库部署及数据流如图1所示。

图1　中心集中与站点分布的数据库部署方案及数据流

方案二，中心数据库集中部署方案：仅在综合监控系统中心级设置全局的实时数据库和历史数据库，在车站不设置数据库，只设置网络设备和车站终端工作站等[1-2]。全线所有站点的被监控对象的实时监控数据都集中传送到中心来进行处理、存储和管理。如果某个站点需要查询相关数据，则必须通过综合监控系统主干网络来远程调取中央全局数据库中的相关数据。

该方案的主要特点是所有数据集中存储在控制中心，各站点的应用通过骨干网与中心数据库通信，保证了每个终端应用使用的都是同一信息。在该方式下，实现数据备份及安全防护比较容易。但该方案由于所有车站应用均需要访问中心数据库，增加了对传输网络的依赖性，系统处理速度稍慢。另外，如果用户有新的应用需求，在集中式结构上满足这些需要难度较大，因为每个用户的应用程序和资源都必须单独设置，而让这些应用程序和资源都在同一套中央集中式服务器上操作，使得系统效率不高。该方案对服务器、软件平台及传输网络的依赖性都较大，适合车站规模小且站点数目较少的线路。该方案数据库部署及数据流如图2所示。

图2　中心数据库集中部署方案及数据流

方案三，站点分布的数据库部署方案：综合监控系统不设置全局性数据库，车站级数据库作为数据收集、处理和保存的核心[1-2]；在日常工作期间，如果车站工作站需要查询本区域范围内的数据，只需在本地数据库调取相关数据。如果网络上某个节点需要查询其他站点范围内的数据，则需要通过网络调取相应站点数据库中的数据。控制中心可作为一个特殊站点考虑，控制中心的数据库规模与车站相当。此外，由于电力监控系统对实时响应要求较高，且站间联系较为紧密，因此需要将全线SCADA数据存入中心数据库，以利于对全线的变电所综合自动化系统信息的调用访问和显示，也便于控制中心电力调度人员对整个地铁供电系统进行统一调度。

该方案对传输网络的依赖较小，切换实时响应高，调试方便，对软件要求低，配置也较低，但不利于数据的集中管理及备份操作。且需要增加站点服务器的存储成本。适合车站规模大且站点数目较少的线路。该方案数据库部署及数据流如图3所示。

图3　站点分布数据库部署方案及数据流

方案四：混合数据库部署方案：该方案可视为方案一的延伸，在方案一两层的架构下增加集中站数据库部署层次，以实现车站分为集中站和卫星站的管理模式[1-2]。该方案中心级综合监控系统部署实时数据库和历史数据库，中心不担负每个车站级实时数据处理，只负责必须由中心级实现的功能，而将大量实时数据处理功能下放到车站一级。车站一级又分为集中站和分站，每3～4个车站设置一个集中站（与信号系统集中站的设置一致），其余为分站。集中站部署数据库，负责各站的数据存储，分站不部署数据库。

图4　混合数据库部署方案及数据流

集中站与分站的关系：正常情况下，集中站具有本站设备监控功能，对分站设备只有监视功能和数据存储功能；分站监控本站设备，分站授权给集中站后，集中站也可以具有对分站设备的控制功能。中心级与集中站、分站的关系：正常情况下，中心级直接与集中站互传信息，集中站与分站互传信息；经过集中站授权后，中心级综合监控系统可以与分站直接互传信息。该方案数据库部署及数据流如图4所示。

以上四个方案，在运营管理方面，方案一、方案二、方案四更适用于OCC集中运营管理，亦即更容易向将来车站无人管理模式过渡，方案三集中管理功能相对较为弱化，不易将来向车站无人管理模式过渡；在系统安全可靠性方面，方案一每一份数据均双重拷贝，当某一车站的服务器宕机时，不会存在数据丢失，且其故障范围只影响本站。方案四每个数据亦双重拷贝，但当集中站宕机时，其故障波及范围包括本站及其分站。方案二数据仅储存于控制中心服务器内，方案三数据仅储存于车站服务器内，无异地备份；在投资方面，方案一中心级软件投入较高，车站级软件投资费用较低，整体投资适中。由于硬件数量较多，总体投资较高。但若考虑服务器虚拟化技术的应用，该方案投资较低。方案二应用集中，软件平台要求较高，需部署大型数据库管理系统等，软件费用较高。但在硬件上大大节约了投资，总体投资较低。方案三由分布式数据处理软件平台及小型数据库管理软件构成。费用较低。硬件投资较方案一增加，总体投资适中。方案四软件费用与方案一相近，但硬件数量少于方案一，总体投资适中；在可扩展性方面，方案一、方案三、方案四均采用分布式模块化体系结构，其差别主要在方案一、四中心级结构庞大，扩展代价相对于方案三要高，由于方案二中心集中部署，方案三车站级采用集中站/分站结构，其扩展灵活性比方案一、二要低。

2　服务器配置方案

服务器应根据数据库的部署方案设置，根据冗余方式的不同，存在不同方案，以下以中心集中与站点分布的数据库部署方案为例，对服务器配置方案进行分析（以下分析同样适用于其它数据库部署方案）。该数据库部署方案下服务器配置存在以下三个方案。方案一所有服务器冗余配置方案，方案二为中心级服务器冗余配置，车站级服务器邻站互备方案，方案三采用服务器虚拟化技术集群配置服务器方案。

（1）方案一，所有服务器均为冗余配置，采用双机热备方式工作。正常情况下为两台服务器同时运行，一台服务器被指定为进行关键性操作的主服务器，另一台服务器作为备用服务器（配置一样），两机用心跳线相连，当主机出现问题，备机接管业务[3]。服务器工作示意图如下。

正常情况时，如图5所示。

图5　方案一正常工作示意图

站内服务器发生单点故障时，如图6所示。

图6　方案一单点故障工作示意图

这种配置是国内外的城市轨道交通工程中综合监控系统的典型配置。该方案的服务器配置档次一般即可。

（2）方案二，中心级服务器冗余配置，车站级服务器邻站互备方案。

中心级配置与方案一相同，车站级每个车站配置一套服务器，本站服务器同时作为邻站的备用服务器，处理本站数据业务的同时备份邻站数据。逻辑上的主备冗余的服务器采用双机互备方式工作[3]。正常情况下，各站点服务器上分别运行不同的处理事件，应用不同，当某一站点主机出问题时，其上所有应用转到邻站服务器上，该邻站服务器将同时负担两个站点的业务处理。

正常情况下，相当于将方案一的冗余服务器在地理位置上分散至相邻两站部署，如图7。

图7　方案二正常工作示意图

当某一站点的服务器故障时，需要邻站服务器接管故障服务器全部的应用。此时故障服务器站点工作站显示的信息需要从邻站服务器中获得，如图8。

图8　方案二单点故障工作示意图

这种配置使站间联系较为紧密，故障情况下服务器负载会倍增，在国内外的城市轨道交通工程中综合监控系统的较少使用。服务器配置将高于方案一的档次。

（3）方案三，采用服务器虚拟化技术集群配置服务器方案。

1）虚拟化技术

虚拟化在计算机方面通常指计算元件在虚拟架构上而不是真实架构上运行。虚拟化技术的一个典型应用就是服务器虚拟化技术，在服务器虚拟化技术中，同一台物理服务器上可以同时运行多个操作系统，可以通过虚拟化技术的应用，模拟出多台逻辑上的服务器设备，且每一个操作系统为可以独立运行的应用系统。服务器虚拟化技术可以实现服务器物理资源到逻辑资源的转变，让一台服务器变成几台甚至上百台相互隔离的虚拟服务器，或让几台服务器变成一台服务器来用，使用户不再受限于物理上的界限，而是让CPU、内存、磁盘、I／O等硬件变成可以动态管理的资源池，来灵活地进行资源的分配和调整[4]。

2）采用服务器虚拟化技术集群配置服务器方案

综合监控系统仅在控制中心设置服务器集群，通过采用虚拟化技术，将多台服务器虚拟化为一个服务器资源池，该资源池再向系统内的各类应用提供逻辑上独立的虚拟服务器。如图9所示。

图9　服务器虚拟化方案

该方案优势如下。

（1）降低成本。通过服务器虚拟化技术，控制和减少物理服务器的数量，明显提高每个物理服务器及其CPU的资源利用率，从而降低硬件成本；降低运营和维护成本，包括控制中心和车站物理空间、耗电量、冷气空调及人力成本等。

（2）提高运营效率。为IT基础设施中所有资源的管理访问提供单一且安全的接口，允许管理员对所有资源进行诊断，对所有资源进行配置和修改管理。

（3）虚拟化技术和存储网络的有效结合，提高了应用可用性、灵活性及安全性。相对于双机环境下每台服务器应用只能是另外一台做备份服务器，在集群环境下，理论上的其他服务器，只要满足条件，都可以是备援服务器，实现了群集化资源的高可用性。此外，一旦在服务器上安装并运行了群集服务，该服务器即可加入群集，即可以随意增加和删改集群系统的节点，对于系统的扩展十分方便。

方案比选。综合以上三个方案，从网络需求角度分析，方案一站内实现系统数据处理及备份功能，不依赖网络，传输网络负荷较低。方案二站内实现数据处理功能，但需要站间数据备份，网络负荷一般。方案三对网络依赖最大，网络负荷最高。从运营维护角度分析，方案一和方案二差别不大，方案三采用虚拟化技术，服务器数量最少且仅在中心设置，维护工作量最小。从投资成本角度分析，方案一投资略高于方案二，方案三最低，若综合考虑服务器对物理空间的占用、耗电量、冷气空调及维护成本，方案三远远低于方案一和方案二。从工程实施角度分析，方案一最为成熟，其对软件要求低，实施难度小。方案二站内单服务器方便，切换调试较难，其对软件要求较高，实施难度大。方案三国内外综合监控系统项目均无实施案例，但在视频点播系统、网络搜索引擎等领域已有应用，实施难度大。

3　小结

综合监控系统数据库部署及服务器配置方案，应依据线路特点、技术发展水平、运营管理技术水平及需求进行选择。本文对数据库部署及服务器配置方案进行了全面的总结和归纳，为综合监控系统的工程设计提供设计思路和方法。同时提出了基于服务器虚拟化技术的服务器配置方案，为云计算在城市轨道交通综合监控系统中的应用提出了新的思路。

［1］管建华，王凯杰，秦小光，等.城市轨道交通主控系统研究报告［R］.天津：铁道第三勘察设计院集团有限公司，2009.

［2］魏晓东.城市轨道交通自动化系统与技术［M］.北京：电子工业出版社，2011.

［3］GB 50636-2010.城市轨道交通综合监控系统工程设计规范［S］.

［4］杭州华三通信技术有限公司.新一代网络建设理论与实践［M］.北京：电子工业出版社，2013.

(编辑：向飞)

Study for Database Deploymentand Server System in Integrated Supervision and Control System of Urban Rail Transit

YUAN Wei
（Guangdong Branch，the Third Railway Survey and Design InstituteGroup Corporation，Shenzhen518000，China）

According to different project features，technical level and operation managementdemands in integrated supervision and control system(ISCS)of urban rail transit，various schemes about database deployment and server system have been proposed.Each schemeemphases different，the purpose of this paper is to provide engineering train of thought，on the basis of the advantages and disadvantagesof them.At the same time，a new scheme isput forwardwhich isserver virtualization application in ISCS.

integrated supervision and controlsystem；database deployment；server system

TP399

A

1009－9492(2015)06－0077－05

10.3969/j.issn.1009-9492.2015.06.019

2015－02－28

袁伟，男，1984年生，陕西汉中人，硕士研究生，工程师。研究领域：通信及自动化。