轨道交通专用通信集中告警系统设计

李士东

(河北远东哈里斯通信有限公司，河北石家庄 050200)

0 引言

随着社会的飞速发展，交通拥挤问题日益突出，严重影响了人们的生活和国家经济建设，轨道交通是缓解交通拥挤问题的一个强有力的交通工具。

轨道交通是一个复杂的系统，其可靠高效运营需要众多相关系统相互协作和大力支持。专用通信系统在其中发挥举足轻重的作用，它为地铁运营提供通信保障。专用通信系统主要包括:传输、无线、公务电话、专用电话、闭路电视、时钟、广播、电源、集中告警等至少9个子系统［1］。

集中告警系统是轨道交通专用通信系统中一个重要的组成部分，它实时监控其他各子系统的运行状况，为维护人员提供全网络运行视图，是专用通信系统的运维支撑系统。

1 总体设计

集中告警系统整体结构如图1所示。

图1 集中告警系统结构

集中告警系统采用分层设计，主要包括前置机、告警解析服务器、应用服务器和客户端。

前置机负责采集各子系统的告警数据，将不同协议的告警数据转换成系统内部统一格式并存入数据库。

告警解析服务器根据不同设备类型的告警状态匹配规则进行告警分析定位，将分析结果提交给应用服务器。

应用服务器将告警结果转发给客户端显示，并响应客户端的各种操作指令。

客户端主要提供人机操作界面，通过监控拓扑视图来显示网络及设备的运行状态。

2 需要解决的难点问题

集中告警系统的建设难点在于:①管理设备类型众多，接口协议繁杂;②监控场景视图千变万化。

专用通信系统至少包含8个子系统，不同的子系统由不同的设备供应商提供，各子系统告警接口协议一般都由设备供应商自己定义，而且多采用私有接口协议［3］。

不同子系统功能不同，设备组网方式及配置情况差异巨大，因此抽象出的监控场景视图也不同，且随时可能发生改变。

通常解决这种问题最简单的方案就是定制系统，为每个项目开发一套集中告警系统，这样做存在如下缺陷:①项目通用性差，不能一劳永逸解决同一个问题，每个项目都需要重新投入人力物力;②项目后期维护成本增加，版本管理困难，每个项目一个版本，对于共性的bug解决需要n份雷同工作。该系统要解决上述难点问题并避免定制系统带来的缺陷［4］。

3 设计实现

3.1 前置机实现

前置机直接与被监控系统通信，采集设备告警，需要设计成接口可灵活扩充的软件结构［5］。前置机软件结果如图2所示。

图2 前置机软件结构

前置机接口适配层设计成横向可扩充结构，接口实体间没有任何耦合，接入新协议只需横向扩充一个全新接口实体即可［6］。接口实体将不同格式规约的告警数据转换成内部可识别的统一格式，然后存入数据库，并通知告警解析服务器。

前置机与告警解析服务器间采用面向连接TCP私有协议通信。

前置机各接口实体通过DLL的方式实现，前置机初始化时动态加载DLL。新增设备类型时只需增加一个全新的DLL接口实体。

3.2 告警解析服务器、应用服务器实现

前置机虽然将告警转换成统一格式［7］，但不同设备的告警状态匹配规则不同，有的通过告警级别匹配(如1～4级表示故障，5级表示恢复);有的通过“告警类/告警号”匹配(如“通信故障/1”表示故障，“通信故障/2”表示恢复)。

告警解析服务器主要根据不同设备类型的告警状态匹配规则进行告警分析定位，产生内部告警数据结构，程序结构如图3所示。

图3 告警解析服务器软件结构

告警解析服务器从数据库提取告警数据，根据设备类型进行数据调度，把告警数据分发到对应的告警解析实体，告警解析实体通过DLL的形式实现，在程序初始化时动态加载进来。新增设备类型时除了前置机上增加一个DLL接口实体，告警解析服务器也需增加一个全新的DLL解析实体。

内部告警数据结构是一个内存链表，数据保存在数据库中，程序启动后加载到内存，其内按告警级别记录着系统每个故障单元对应的故障告警个数及恢复告警个数。

告警解析实体根据告警状态匹配规则进行告警分析。如为故障状态告警则把对应故障单元的故障告警数加1;如为恢复状态告警则清除之前存在的相匹配的故障告警(假设故障告警n个，n≥0)，把对应故障单元的故障告警数减n，恢复告警数加n+1，产生内部告警数据结构，将数据入库并通知应用服务器。告警解析服务器与应用服务器间采用面向连接TCP私有协议通信。

应用服务器负责将内部告警数据结构转发给在线客户端;同时对客户端提交的数据进行后台分析处理并入库，将处理结果返回给客户端。

3.3 客户端实现

客户端可以实现系统告警的图形化管理，告警可以定位到板卡或者端口级别。但不同集中告警系统管理的设备不同，设备外观及配置也各不相同，这就为系统图形化管理带来了困难。为了不走定制路线，系统需要提供一个设备无关的拓扑场景［8］编辑工具，可以根据设备组网及配置情况利用各种形状的图元进行拓扑编辑。拓扑编辑原理如图4所示。

图4 拓扑编辑原理

一个监控拓扑由若干个图层构成，图层间有严格的隶属关系，一个图层可有多个子层，子层下还可再有子层，依此类推。拓扑编辑采用图4所示的倒树型拓扑编辑结构，由一个根节点可以扩充出不同的子图层构成一个完整的监控拓扑。每个图层有唯一的图层索引，图层索引代表了该图层在整个拓扑中的位置信息。如1-1的父层是1;1-2-1的父层是1-2;1-1有2个子层1-1-1和1-1-2。

可以在一个图层中添加设备网元，设备网元的属性包括设备类型、设备名称、目的图层和通信参数等。在该图层的子层中编辑设备的机架图，每个设备网元都有一个目的图层，目的图层指向机架图所在的图层。这样点击设备网元就可以切换到目的图层(机架图)，一般机架图层都是设备图层的子层。机架图层主要通过图元的组合来描述设备的详细构成，如模块、板卡和端口等信息，机架图层内的每个组成图元代表一个故障单元，故障单元的属性包括所属设备、单元名称和告警位置等。

系统通过图层索引保存拓扑结构，通过图元数据流保存图层内数据信息，并提取图层内的设备信息及故障单元信息另表保存。

系统初始化时读取所有故障单元信息，依此建立内部告警数据结构内存链表，用来保存每个故障单元的告警个数。

客户端收到服务器转发的内部告警数据结构后，将对应的内存链表更新，然后根据新数据刷新监控拓扑上的告警指示，把指示定位到对应图层的对应故障单元上，根据不同告警级别通过不同颜色来显示告警状态。告警显示具有向上传递性，当一个故障单元产生告警后，会逐层反应到父层对应的网元上，直至最顶层拓扑。维护人员见到告警指示后，可以由设备网元点击逐层深入，直到最底层查看具体的故障位置及故障详细信息。

客户端收到告警数据结构后除了在监控拓扑上进行颜色指示外，还可将告警信息送给告警箱，由告警箱进行灯光显示及声音提示;还可以通过声卡播放告警提示音。

客户端还为维护管理人员提供各种应用功能接口，如:告警清除、告警受理、告警查询、告警打印、告警统计以及告警报表等。

4 系统性能测试

测试的目标是验证通过上述设计方案实现集中告警系统的稳定性、可靠性及系统扩充能力。

测试设备的网络配置结构如图5所示。

图5 集中告警系统测试结构

测试需要的设备包括:服务器、客户端和各子系统接口测试Demo。为了简化测试环境，在一个服务器上部署前置机程序、告警解析程序及应用服务器程序;各子系统接口测试Demo通常由子系统厂家提供，各接口测试Demo可以部署在同一台计算机上，也可分开部署。

按照各子系统提供的组网及设备配置资料进行拓扑编辑测试，拓扑编辑工具可以灵活方便建立监控拓扑，形象描述设备网络及设备机架图。证明了该系统拓扑编辑的设备无关性与灵活性。

根据各子系统提供的接口协议文档，在集中告警系统上扩充前置机的接口实体DLL和告警解析的解释实体DLL。DLL实现后可以动态加载到集中告警平台里，证明了接口管理的实用性与灵活性。

通过各子系统接口Demo向集中告警系统模拟发送告警，告警可以在监控拓扑上定位并正确显示，可以驱动声光告警。证明了接口实体DLL及解析实体DLL工作正常，与平台结合良好。

各测试Demo定时1 ms向集中告警系统发送告警数据。系统没有弹出异常，告警显示准确，证明了系统的稳定性与可靠性。

测试结果证明，分层设计的集中告警系统稳定可靠，扩充能力极强，设计是可行的。

5 结束语

目前该集中告警系统在国内多条轨道交通系统上部署应用，取得了广泛好评。实践证明了该系统完全达到了预期效果，有效地避免了定制系统带来的缺陷，大大减少了系统后期开发投入，降低了集中告警系统软件维护成本。分层可扩展的架构设计提高了系统的生命力;监控场景动态绘制满足了千变万化的用户现场环境。同时对其他网管类、监控类系统的实现具有很强的参考价值。

［1］陈桂汉.综合电信管理解决方案［M］.北京:电子工业出版社，2002:10-230.

［2］徐海军.电信网管发展的五大趋势［N］.通信产业报，2004，第14期(第39版).

［3］李国宁，刘伯鸿.城市轨道交通综合监控系统及集成［M］.北京:西南交通大学出版社，2011:20-330.

［4］张利彪.城市轨道交通信号与通信系统［M］.北京:人民交通出版社，2010:5-90.

［5］贾毓杰.城市轨道交通通信与信号［M］.北京:机械工业出版社，2009:45-160.

［6］李晓江.城市轨道交通技术规范实施指南［M］.北京:中国建筑工业出版社，2009:50-280.

［7］李千日.软件体系结构设计［M］.北京:清华大学出版社，2008:30-370.

［8］田超.多技术网络管理(TMF MTNM)体系综述［J］.无线电工程，2005，31(4):25-29.