城市轨道交通信息集中监控系统的设计与实现摘要：目前的城市轨道交通管理信息系统都是针对某具体系统或某类型设备进行管理与控制，且各条线路相互之间不通任何信息，是孤立的系统。无法对各线各系统运行情况特别是设备故障情况迅速准确把握。针对这种情况，整合现有资源，设计了轨道交通信息集中监控系统。该系统采集现有各系统设备故障信息进行处理和故障报告，并进行了综合分析和预测，给集中监控增加了智能决策功能;且只需在原有的网管系统上提供或新增所需要的北向接口，并不需要改变原有网络的拓扑结构，只要新增采集系统和集中监管系统，在实现上很简洁，相对投资也不大。关健词：城市轨道交通，信息集中监控，网络管理 目前，城市轨道交通的信息管理系统一般分为传输、公务电话交换、调度电话、电源、无线调度、广播、图像监控(安防系统)、时钟、自动售检票等9大子系统;每个子系统的管理网络自成体系，且都有自己相应的网管中心或数据采集系统。所以，目前的管理系统不能形成一个有机整体，宏观控制管理能力弱，而且各条轨道交通线的信息系统间也都相对独立。 针对上述网络管理现状，为提高城市轨道交通信息管理能力，提出信息集中监控的构想。即对所有轨道交通系统网络设备实施统一监视与必要控制、管理。该方案不只针对某类单一系统设备的监控和管理，而是一个对各条轨道交通线上的上述9大子系统设备实施综合监控和管理的系统。该方案也不是针对各系统的所有参数进行监控管理，而是初步对设备故障进行实时的监控管理。1 概述 对于各个系统，原有的管理网络或维护方法不尽相同。象自动售检票系统等管理系统就可将原有系统重新整合进解决方案。而象传输系统等，比如SDH(同步数字多级)设备，处在多厂商环境中，将涉及多厂商的SDH网管系统。这种网络设备的多元化，加上有些不同厂家设备还不兼容，因此造成综合网管的困难。所以，设计信息集中监控系统时，仅简单地从原有网管系统进行整合还是不够的。 对于把传输系统复杂的网管系统整合成集中监管，大致有三种途径:①综合化方法—在已有网管系统之上再加一级管理系统;②翻译法—在有信息交互需求的网管系统之间进行两两翻译;③标准化法—已有的各网管系统采用公共信息模型和功能集。 第二种方法有现成的支持标准(SNMP/CM IP /CORBA)互操作的静态规范描述和动态交互式转化方法，适用于信息量不大的情况。第三种方法是比较彻底的综合网管方法，但需要将所有的网管系统被统一标准替换，故暂时还只是一个想法。本文提出的信息集中监控解决方案主要针对故障信息进行处理，而且为了避免各厂商间的交涉，将采用综合化方法，做到与原有网管系统的平滑过渡;这也与那些通过简单整合就可以实现集中监控的系统的做法很类似，系统也比较容易整合。这样，在各系统原有管理系统或网管系统的基础上再添一层管理者，在新的管理层上实现信息集中综合监管，从而解决了各系统间的“信息孤岛”问题。2 系统架构 系统架构分为三层:管理监控层、代理层和应用层(如图I)。应用层是现有的各种硬件系统，比如传输系统、自动售检票系统等。代理层是数据集中的中间层。包括数据采集硬件和软件。管理监控层将对采集的所有数据进行综合处理并形成新的业务模型。 架构中，上层管理者管理若干网络体系、网络协议异构的系统，异构子网各自维护一套专业管理信息库。它们向综合监管系统提供Q3,CORBA接口。 为了实现综合监管的目标，利用代理层将原有系统(应用层)在数据接口上达到统一，这样代理层加上应用层组成的新的网络将是管理监控层所需要的“统一”网络，在概念上可以想象成一个虚拟网络。管理监控层通过由代理层组建的综合数据库，对大的方面(比如现在的告警系统，以后通过统一其他系统的数据接口就可以实现其他方面的监控)进行全局性调配与管理，细节留给原有系统的网管系统或者管理系统处理。各系统通过代理层的代理软件(数据采集软件)的映射，完成数据接口的统一。3 解决方案3.1 硬件系统解决方案 图2是以某地铁线为例的集中监控系统拓扑图。其中A11是从传输网管NM11，采集数据的代理PC ; A12是从自动售检票管理系统NM12采集数据的代理PC。所有系统经代理PC采集数据后，通过路由器R，把数据送到数据库服务器DS。其他地铁线的拓扑都与该线类似。MIS1 , MIS2，MIS3凡等是信息集中综合监管系统。比如MIS1管理1一4号线，MIS2管理5一9号线，MIS3管理10一13号线。MIS1—MIS3对数据库服务器中的数据进行综合处理、显示、告警，以及统计和分析。MIS1一MIS3放在一起，这样在多个处理机上进行监管可以扩大可视范围，也达到综合监管的目的。 设备网管所提供的北向接口，有的是Q3接口，可以通过网口进行采集;有的是串口，可以通过串口接收。如果通过串口接收数据，可以根据图3所示，用一个1-8多串口卡，使用一台代理PC机进行多个串口数据收集。 上述方案的可靠性:如果原有设备的网管系统提供的北向接口是串行方式，那么通过图3方式，一台代理PC机就可以采集8台网管的数据，但是串行方式的数据是通过重复机制来最大限度地确保信息的完整。所谓重复机制，是当信息没有被接收就重新发送，如果三次没有接收到就不再重发。这样的数据采集方式很不可靠。而采用TCP/IP方式进行采集，如果数据包没有被正确接收，将等待到可以正确接收的时候重新发送。所以在可能的情况下，此方案需要厂商提供网管软件的Q3北向接口。 在安全性方面，整个系统并不通过公网，局域网能保证数据的安全、不被截获、破坏等。3.2软件解决方案 软件解决方案中包括数据采集和数据处理。两个独立的体系，并通过数据库使两者形成整体。数据采集建立数据库，数据处理管理数据库。 数据采集部分是针对各个不同的分立系统对不同类型的数据进行收集。由于不同系统的数据存储方式对外提供数据的方式不同，就算同一系统的不同厂商设备的网管系统所提供的北向接口也不同，所以数据采集部分将针对每个系统进行编程。数据采集方式的多样性会导致软件架构的杂乱无章。为避免不一致和保证软件系统的易扩展及易维护性，应根据数据处理部分所感兴趣的数据内容制定统一的数据接口。解决方案如图4所示:数据采集平台将根据不同系统不同设备加载特定的数据采集DLL(动态链接库)。对于同一系统，数据采集平台和DLL之间的数据接口相同，而且数据采集部分和数据处理部分也将以统一的数据接口进行数据汇总。这样一旦有新增设备，数据采集系统只要针对新增设备编写DLL,整个系统就具备良好的可扩展性。图4中简单列举了数据采集DLL采集数据的三种方法:TCP/IP, RS232及直接读取相关数据库DB。这些差异性将在统一的数据接口处消失。 数据处理部分是软件解决方案的核心，对汇总的数据进行分类处理并形成新业务逻辑。数据处理部分的主要功能如图5所示。其中:安全管理系统是对使用该系统的所有用户的权限管理;该模块将保证系统的安全性。告警系统对采集系统收集的所有数据进行实时处理，对所有设备的现有故障进行报告，对消除的故障进行告警清除(使设备告警状态复位)。收发文系统是在系统有新增设备故障告警时，在行政上上级对负责维护的部门进行派工单发放的业务处理模块;相关部门维护完毕后对所收到的派工单进行回执，这样可以明晰责任，实现了该解决方案的行政“监管”目的。统计报表系统是对故障告警历史信息进行统计和简单计算形成特定形式的报表。分析预测系统对故障告警历史信息进行统计分析，采用经验法和曲线拟合法对设备近阶段的运行状况进行预测告警，这样可以对故障发生概率较高的设备进行重点维护，最大限度地避免运营事故。4结语 本文设计的系统，只是通过从现有网管系统的北向接口提取故障信息，或从现有的管理系统直接提取故障信息进行综合。在原有的网管系统上提供或新增所需要的北向接口，并不需要改变原有网络的拓扑结构，只要新增采集系统和集中监管系统，相对投资也并不大。数据的集中处理，能对运营的整个网络系统的设备运行情况进行宏观把握，并有现存管理系统所没有的派工单业务流程，不仅对设备运行情况进行了集中监控，还能对设备维护进行统一调配和管理。系统的另一个价值在于，可以对综合的数据进行智能分析和预测，可以根据预测进行有目的的检修，增强整个系统运行的安全性和可靠性。参考文献1郭军.网络管理与控制技术.北京:人民邮电出版社，1999. 42 -902孟洛明，杨正球.电信管理网.北京:人民邮电出版社，2000. 50 -1253王刚.电信网络管理体系结构的发展.电信技术，2001(12):39-41