综合监控系统雪崩功能设置必要性分析

邹 艳

(苏州轨道交通有限公司运营分公司 江苏 苏州 215101)

1 综合监控系统的构架理念

综合监控系统是通过现代控制系统集成技术构建起来的大型自动化系统，它采用开放的形式，无缝地将城市轨道交通各个自动化专业的子系统接入。综合监控系统对子系统的无缝接入在实践中产生了两类方式，一类是对子系统集成，另一类是对子系统互联。

1.1 子系统集成与互联的概念

所谓对子系统集成，是指开放系统将被集成子系统完全融入其中，使之成为综合监控系统的一部分。被集成子系统的全部功能都由综合监控系统实现，除了管理意义外，被集成子系统构成了综合监控系统的主体。所谓对子系统互联，是指被互联子系统作为一个独立运行的系统，具有自身的完整结构，综合监控系统通过外部接口与子系统进行必要的信息交互，以支持信息共享平台的构建。互联子系统独立运行，实现自己的功能，也向综合监控系统提供交互数据，支持综合监控系统互联功能的实现。

1.2 综合监控系统的主要构架形式

就目前的发展来看，城市轨道交通综合监控系统的构架形式主要分为两类:一类是以环调、电调为构建核心的综合监控系统，它以机电设备监控为主体，是轨道交通线路的数字信息共享平台，主要集成了电力监控系统(SCADA)和机电设备监控系统(BAS);另一类是以行车调度指挥为核心的综合监控系统，其标志是集成了轨道交通运营的主专业系统——列车自动监控系统(ATS)。下面对这两种构架形式进行比较，如表1所示。

表1 综合监控系统的主要构架形式比较

1.3 苏州轨道交通1号线综合监控系统构架

根据以上的分析对比，不难解释苏州1号线综合监控系统为何采用以环调和电调(PSCADA、BAS)为核心的设计方案。该方案将PSCADA和BAS子系统在车站级纳入综合监控系统，其中央级、车站级功能由综合监控系统完成，对CCTV(闭路电视系统)、PA(广播系统)、PIS(乘客信息显示系统)、PSD(屏蔽门系统)、FG(防淹门系统)、FAS(火灾自动报警系统)、AFC(自动售检票系统)、ACS(门禁系统)、ATS(信号系统)、CLK(时钟系统)10 个子系统进行互联。虽然该方案集成度不如以行车调度指挥为核心的方案高，但在目前的技术条件和人员条件下，对于刚建设第一条线的苏州来说应该是比较合适的选择。

2 设置雪崩功能的必要性

2.1 雪崩功能的设置

在城市轨道交通综合监控系统中，一般集成、互联的子系统达到10个以上，系统需要接收和处理的数据量很大，所以软件设计时会考虑在处理大量状态信息变化时采用雪崩处理，以防止任何数据的丢失。苏州轨道交通1号线的综合监控系统集成和互联了12个子系统，需要处理的数据量达到了30万点，因此在搭建整个系统框架时也考虑设置了雪崩功能模块。

2.2 雪崩功能的验证

1号线综合监控系统建成后，为了验证雪崩功能的实际作用和效果，组织了一次真实的故障试验。

2.2.1 触发条件

经过前期设计测算和国内同行的经验，最有可能引发大量状态信息变化、造成大量数据上传的极端情况一般出现在主变电所解列退出时，所以把雪崩功能验证的触发条件定义为一座主变电所故障断电并整所退出。

2.2.2 评判依据

按照上述触发条件，为验证雪崩功能的效果，主要考察控制中心(OCC)综合监控实时服务器在主所断电时的运行性能和OCC综合监控工作站在主所断电时的监控能力。

2.2.3 评判标准

按照上述评判依据，在主所退出时，信号、通信、SCADA、AFC、BAS、FAS等系统由于失电而在同一时间内向ISCS传递，由于掉电或转为不间断电源系统(UPS)供电的接口数据信息，此时OCC综合监控实时服务器应该保持正常的数据处理能力，两台冗余服务器数据处理的主从状态不应产生变化;在服务器运行正常的情况下，工作站可以保持正常的监控功能，各系统事件、报警、图页均保持实时更新，人机界面可以正常监控，无刷新缓慢、卡阻等现象。

3 雪崩功能的验证结果

3.1 服务器主从状态检测与分析

OCC两台实时服务器互为冗余，在同一时间由一台服务器负责关键进程的数据处理，在联调过程中选取前置处理器(FEP)和SCADA两个关键进程作为服务器的状态检测对象，判断主从状态。如图1所示，通过检测FEP和SCADA两个关键进程，停送电前后均运行在服务器1(绿色显示)上，可以判断服务器的主从工作状态未发生切换。

图1 服务器进程状态

3.2 实时服务器CPU使用率分析

OCC由实时服务器1和2负责数据的处理，与FEP和工作站进行通信。因此，从停电前到停电后分为5个时间节点进行检测，实测中央处理器(CPU)使用率如表2所示。

表2 OCC实时服务器CPU使用率记录 %

按照表2记录的数据，可绘制出服务器1和2的CPU使用率趋势(见图2)，同时进行分析。

图2 服务器CPU使用率趋势

1)服务器1和2的CPU使用率在整个停送电过程中均小于2%，负载较低。虽然此时车站及正线处于夜间停运状态，但即使是在运营状态，以加多2倍的数据处理推算，服务器CPU使用率约为5%，服务器依然可以正常运转。

2)服务器1比服务器2的CPU使用率高0.3% ～0.7%，因为服务器1一直处于主服务器状态，处理关键进程多，负载相对较高。

3)在停电瞬间，服务器使用率相对提高了0.1% ～0.5%，主要是停送电时的设备状态变位相对较多、上传数据量增加的缘故，但增加的使用率幅度较小，不会影响服务器程序的运行。

从以上图表及分析可以得出，OCC实时服务器1(主)和服务器2(从)在主所断电退出时，CPU使用率比较稳定，受影响不大。

3.3 实时服务器内存占用检测与分析

与CPU使用率相同，对于服务器内存占用情况，主要将停电前到停电后分为5个时间节点进行检测，实测内存占用情况如表3所示。

表3 OCC实时服务器内存占用记录 GB

按照表3数据，可绘制出主从服务器内存占用柱状对比图(见图3)，同时进行分析。

图3 主从服务器内存占用对比

1)主从服务器的内存占用比较平均，在整个停送电过程中，服务器1和2的内存占用相差不大。

2)在停送电瞬间，服务器1和2的内存占用比较稳定，波动的范围不大于0.2 GB，相对于服务器16 GB的内存来讲，影响基本可以忽略。

从以上图表及分析可以得出，OCC实时服务器1(主)和服务器2(从)在主所断电退出时，内存占用比较稳定。

综合以上主从状态、CPU使用率、内存占用3个方面的分析，在主所停电退出导致各系统接口产生变位数据时，综合监控服务器能保持在正常的工作状态。

3.4 OCC工作站监控能力评定

对于工作站监控能力，主要从事件报警刷新、界面操作速度进行检测分析，按照提前设计的记录表格进行记录和检测，汇总整理后发现:在联调过程中，各接口专业在停送电期间均能正常监控，事件报警能正常上传;在停送电时，在OCC电调、环调工作站进行页面切换及点击图面时，操作速度正常，无缓慢、卡阻等现象。综合以上分析得出，在主所退出时，各系统事件、报警、图页均能正常更新，无刷新缓慢、卡阻现象，工作站可以保持正常的监控功能。

3.5 雪崩测试的结论

通过这次对综合监控系统雪崩功能验证的数据分析，得出结论:在一个主所故障退出时，各接口系统均能正常上传数据，综合监控系统OCC工作站及服务器都能保持正常工作。

4 结语

苏州轨道交通1号线综合监控采用了以环调、电调为核心的构架方案，集成和互联了12个子系统，接入数据量达到30万点。在此前提下，测试了比较极端的故障情况，即一座主变电所整体解列退出运行，断电范围达到了12个站及区间(全线共24个站点)。测试结果表明，并没有发生数据量激增而导致系统处理速度变慢甚至死机的现象，相反中央服务器的CPU使用率和内存占用率都非常富余，整个系统的处理能力在测试过程中没有受到任何影响。因此，可以得出以下结论:基于苏州1号线综合监控系统的构架方式，只要系统的硬件配置参数和冗余度不低于目前国内主流设计标准，雪崩功能设置就可以考虑取消。

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

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

［3］湛维昭.地铁机电系统综合集成平台的设计［J］.都市快轨交通.2006，19(2):81-84.

［4］顾明星，董德存.城市轨道交通信息通信系统技术［J］.城市轨道交通研究，2003(6):27-30.

［5］曲立东.城市轨道交通环境与设备监控系统设计与应用［M］.北京:电子工业出版社，2008.

［6］苏州轨道交通有限公司.苏州轨道交通1号线综合监控系统招标文件［G］.苏州，2009.

［7］柳彦青，朱志平.城市轨道交通综合监控系统浅述［J］.上海电器技术，2006(4):33-36.

［8］靳守杰.城市轨道交通综合自动化系统研究［J］.城市轨道交通研究，2007(5):8-11.