综合监控系统迁移技术在深圳地铁的应用

吴嘉勇 黄 路

(1.北京和利时系统工程有限公司 北京100176;2.深圳地铁集团运营公司 广东深圳518000)

1 迁移背景及需求

深圳地铁1号线综合监控系统分二期建设，一期工程于2004年底投入运行，二期工程于2011年6月开通。一期工程综合监控系统(integrated supervision control system，ISCS)是国内第一套成功运行的深度集成综合监控系统，采用10 Mbit/s带宽的逻辑独立通道，将车站、控制中心、车辆段连接起来，搭建了一个大型分层、分布式的自动化监控系统。二期工程综合监控系统除包含一期的三大系统外，还要互联多个地铁核心系统(信号、屏蔽门、售检票、乘客资讯等)。1号线二期工程综合监控系统是在既有一期工程基础上的升级，采用了更为强大的软件平台和更为友好的人机界面。

运营控制中心(operation control center，OCC)主要对一期机电设备监控系统(equipment monitoring control system，EMCS)、火灾自动报警系统(fire alarm system，FAS)和电力监控系统(supervisory control and data acquisition，SCADA)三大系统进行整体迁移，是在对既有系统没有影响的前提下进行的，同时还要保证迁移后系统的安全性、连续性、稳定性。

如上所述，1号线分两期工程完成，虽然采用了同一软件平台，但二期工程在完全保留了一期数据库平台的基础上，对系统的界面、操作风格进行了重新设计，更好地满足了用户对集成系统和互联系统的使用需求。

2 迁移内容及方案设计

从工程实施的层面划分，一期既有系统向二期系统迁移的内容主要包括:一期既有系统(EMCS/SCADA/FAS)监控内容和系统功能的迁移，一期系统历史数据/用户管理系统/对时功能的迁移与合并;从数据层面划分，迁移内容可分为实时数据、历史数据、HMI(human machine interface)画面、管理数据、维护数据。

2.1 典型站迁移设计

为确保迁移工作顺利，需进行典型站的迁移测试，测试的目的是为了对OCC迁移方案的可行性进行验证，并根据测试结果分析、制订下一步迁移的详细方案，测试主要包括EMCS/SCADA/FAS模拟迁移测试、系统功能模拟迁移测试等。

2.2 迁移设计

结合一期工程的规模和功能实现程度，以及典型站迁移测试的验证结果，进行一期工程OCC迁移的详细设计，主要包括一期中心/车站软件的迁移、OCC迁移后的试运行等。二期工程采用新版的系统平台，与一期相比，不仅显示分辨率从1024×768(像素)提高到1280×1024(像素)，而且还提供了更为美观、合理的人机交互界面。

为了充分发挥新平台的特性，同时最大限度地保留一期工程的组态，OCC迁移方案仅对中心的一期系统软件进行修改，对既有车站的配置保持不变，仅对其中的部分软件参数进行重新设置。

首先，将一期中心系统的所有页面(见图1)全部修改为二期的页面样式(见图2)，修改过程不对一期图形的内容进行改动，仅将原来的图形内容居中放置。同时，保留一期所有的信息窗口、控制面板，基本保留一期系统的操作习惯。而报警、事件、趋势功能，统一采用二期的页面和功能。

图1 一期系统HMI风格

图2 二期系统HMI风格

本着尽量不修改车站软件的原则，对于一期工程车站级软件只做部分参数性的修改，可以看作是一次升级操作。修改完成后，需要对车站的所有工作站、服务器重启一次。

由于一期中心软件在迁移试运行期间仍处于运行状态，为了保证与车站级软件的一致性，同样需要对一期的中心软件进行修改，修改的内容与车站级软件一样，也可以看作是一次升级操作，修改完成后同样需要重新启动服务器和调度工作站。

OCC迁移完成后的试运行采取新旧并行的运行方式，即在控制中心设置新的调度工作站，仍保留一期的调度工作站，同时运行新旧两个版本的软件。由于软件平台支持新旧两个版本的并行运行方式，所以可以很好地对新版软件进行对比测试、验证。

试运行结束后，将撤销一期的中心服务器和调度工作站，系统将在重新部署的新版软件平台上运行。

3 系统软件架构及部署

软件平台建立在3个层次上:第1层是采集和通信层，主要用于数据采集，完成与外部系统之间的数据交换;第2层是数据管理层，用于数据管理和高级应用，通过一个实时数据库和一个关系数据库，实现报警、报表和趋势服务;第3层是应用层，主要用于实现HMI功能和外部接口。基于上述的软件结构，软件平台可以进行灵活部署，如图3所示。可以看出，整个系统通过内部总线可以实现灵活的软件配置和软件连接。

图3 软件部署

一期的软件部署如图4所示，二期的软件部署，如图5所示。可以看出，两者采用了相同的软件部署思想和结构，仅在操作系统、工作站的数量上稍有不同，且每个车站、中心的每个功能块或服务块均可以通过网络灵活配置和调用。

4 迁移实施

4.1 实验室验证

所有迁移准备工作均在实验室进行针对性的测试与运行，包括页面组态、参数配置等工作。在迁移工作实施前，需要对所有的修改系统进行逐一验证，保证修改的准确性。同时，在实验室环境中，还要充分考虑现场环境的特殊性，以及对迁移工作实施的影响。

图4 一期软件部署方案

图5 二期软件部署方案

4.2 备份及准备工作

在迁移工程实施前，对一期系统每台计算机上的文件及配置进行备份，以保证在迁移实施过程中出现异常时能快速地恢复到原来的运行状态。

4.3 硬件、软件的安装与配置

在控制中心搭建2台服务器(冗余配置)作为报警及历史服务器，安装新版本软件并配置相应的软件环境。

1)搭建2台调度工作站，作为新版中心调度工作站，安装新版本软件，配置相应的软件环境。

2)搭建2台核心交换机(冗余配置)，作为新搭建中心服务器和工作站的网络接入设备，并配置服务器和工作站相应的网络环境。

3)通过跳线将一期核心交换机和新交换机连通，作为新版中心服务器获取一期IO数据源的数据通道。

4)在控制中心安装1台网络防病毒软件服务器，在新版中心服务器和工作站部署网络防病毒软件客户端。

4.4 现场迁移

在夜间列车停运后，通过OCC依次远程登录一期车站工作站，对车站软件进行修改，并重新启动运行。随后，更新一期系统OCC的服务器和调度工作站软件，并重新启动运行。待一期全线系统全部启动成功、恢复功能后，对升级后的一期系统在线观察，确认运行稳定后，再运行新搭建的两台中心服务器及调度工作站，按车站分批将一期车站接入新系统。此时，原一期的中心服务器和调度工作站与新搭建的系统并机运行。

5 迁移的难点与创新

5.1 难点

1)本次迁移是在既有系统正常运行的情况下进行的一次无扰切换，其中针对OCC特有的全线汇总页面的迁移是在一期系统的基础上添加了二期的车站内容，而二期的控制设备和数据结构都有所改变，涉及的内容较多，所以这部分内容是OCC迁移的难点之一。

2)从运营管理角度来看，迁移完成后针对系统各项功能测试与验证工作的组织与协调，也是确保迁移成功的必要条件。

5.2 创新

1)首次引入人因工程概念(human factor)，从“人、机、环境”3个方面对系统人机界面进行规划，在总体界面风格保持统一的前提下，以“人”为核心元素进行设计，最大限度地满足运营需求。

2)一期既有SCADA电力监控系统的迁移是复杂程度最高、对运营影响最大的环节，为了最大限度地减轻对运营的影响，迁移由简至繁，先降压变电所，后混合变电所，采取分批接入、控制接入规模与节奏的策略，以对正常运营影响最小为前提，最终完成整个迁移工作。

6 结语

笔者从系统迁移的设计、测试、实施等方面，阐述了综合监控系统的迁移技术。伴随着地铁建设的高速发展，网络化运营与资源共享势必要求控制中心的综合监控系统是一个多线路、多系统的软件平台。如何实现不同线路、不同架构的综合监控系统软件的迁移和整合，将是今后所面临的一个新课题。

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

［2］曲立东.城轨交通环境与设备监控系统的结构比较［J］.都市快轨交通，2006，19(3):90-92.

［3］魏晓东.现代自动化技术在城市轨道交通中的应用［J］.北京:自动化博览，2003，20(4):6-11.

［4］王开满，王军，张慎明.城市轨道交通自动化综合监控系统的集成模式［J］.城市轨道交通研究，2007(3):57-62.

［5］彭辉，徐志修.城市轨道交通智能综合监控系统设计［J］.铁道工程学报，2006(1):15-18.

［6］魏晓东.地铁综合监控系统建设的关键问题分析［J］.北京:自动化博览，2009(5):14-37.

［7］GB 50636—2010城市轨道交通综合监控系统工程设计规范［S］.北京:中国计划出版社，2010.

［8］GB 50157—2003地铁设计规范［S］.北京:中国计划出版社，2003.

［9］深圳地铁一号线续建工程综合监控系统技术要求［G］.深圳，2006.