轨道交通通信告警系统构造.docxVIP

轨道交通通信告警系统构造 　　随着社会的飞速发展，交通拥挤问题日益突出，严重影响了人们的生活和国家经济建设，轨道交通是缓解交通拥挤问题的一个强有力的交通工具。 　　轨道交通是一个复杂的系统，其可靠高效运营需要众多相关系统相互协作和大力支持。 　　专用通信系统在其中发挥举足轻重的作用，它为地铁运营提供通信保障。 　　专用通信系统主要包括传输、无线、公务电话、专用电话、闭路电视、时钟、广播、电源、集中告警等至少9个子系统［1］。 　　集中告警系统是轨道交通专用通信系统中一个重要的组成部分，它实时监控其他各子系统的运行状况，为维护人员提供全网络运行视图，是专用通信系统的运维支撑系统。 　　1总体设计集中告警系统整体结构如图1所示。 　　图1集中告警系统结构集中告警系统采用分层设计，主要包括前置机、告警解析服务器、应用服务器和客户端。 　　前置机负责采集各子系统的告警数据，将不同协议的告警数据转换成系统内部统一格式并存入数据库。 　　告警解析服务器根据不同设备类型的告警状态匹配规则进行告警分析定位，将分析结果提交给应用服务器。 　　应用服务器将告警结果转发给客户端显示，并响应客户端的各种操作指令。 　　客户端主要提供人机操作界面，通过监控拓扑视图来显示网络及设备的运行状态。 　　2需要解决的难点问题集中告警系统的建设难点在于①管理设备类型众多，接口协议繁杂;②监控场景视图千变万化。 　　专用通信系统至少包含8个子系统，不同的子系统由不同的设备供应商提供，各子系统告警接口协议一般都由设备供应商自己定义，而且多采用私有接口协议［3］。 　　不同子系统功能不同，设备组网方式及配置情况差异巨大，因此抽象出的监控场景视图也不同，且随时可能发生改变。 　　通常解决这种问题最简单的方案就是定制系统，为每个项目开发一套集中告警系统，这样做存在如下缺陷①项目通用性差，不能一劳永逸解决同一个问题，每个项目都需要重新投入人力物力;②项目后期维护成本增加，版本管理困难，每个项目一个版本，对于共性的解决需要份雷同工作。 　　该系统要解决上述难点问题并避免定制系统带来的缺陷［4］。 　　3设计实现31前置机实现前置机直接与被监控系统通信，采集设备告警，需要设计成接口可灵活扩充的软件结构［5］。 　　前置机软件结果如图2所示。 　　图2前置机软件结构前置机接口适配层设计成横向可扩充结构，接口实体间没有任何耦合，接入新协议只需横向扩充一个全新接口实体即可［6］。 　　接口实体将不同格式规约的告警数据转换成内部可识别的统一格式，然后存入数据库，并通知告警解析服务器。 　　前置机与告警解析服务器间采用面向连接私有协议通信。 　　前置机各接口实体通过的方式实现，前置机初始化时动态加载。 　　新增设备类型时只需增加一个全新的接口实体。 　　32告警解析服务器、应用服务器实现前置机虽然将告警转换成统一格式［7］，但不同设备的告警状态匹配规则不同，有的通过告警级别匹配如1～4级表示故障，5级表示恢复;有的通过告警类告警号匹配如通信故障1表示故障，通信故障2表示恢复。 　　告警解析服务器主要根据不同设备类型的告警状态匹配规则进行告警分析定位，产生内部告警数据结构，程序结构如图3所示。 　　告警解析服务器从数据库提取告警数据，根据设备类型进行数据调度，把告警数据分发到对应的告警解析实体，告警解析实体通过的形式实现，在程序初始化时动态加载进来。 　　新增设备类型时除了前置机上增加一个接口实体，告警解析服务器也需增加一个全新的解析实体。 　　内部告警数据结构是一个内存链表，数据保存在数据库中，程序启动后加载到内存，其内按告警级别记录着系统每个故障单元对应的故障告警个数及恢复告警个数。 　　告警解析实体根据告警状态匹配规则进行告警分析。 　　如为故障状态告警则把对应故障单元的故障告警数加1;如为恢复状态告警则清除之前存在的相匹配的故障告警假设故障告警个，≥0，把对应故障单元的故障告警数减，恢复告警数加+1，产生内部告警数据结构，将数据入库并通知应用服务器。 　　告警解析服务器与应用服务器间采用面向连接私有协议通信。 　　应用服务器负责将内部告警数据结构转发给在线客户端;同时对客户端提交的数据进行后台分析处理并入库，将处理结果返回给客户端。 　　33客户端实现客户端可以实现系统告警的图形化管理，告警可以定位到板卡或者端口级别。 　　但不同集中告警系统管理的设备不同，设备外观及配置也各不相同，这就为系统图形化管理带来了困难。 　　为了不走定制路线，系统需要提供一个设备无关的拓扑场景［8］编辑工具，可以根据设备组网及配置情况利用各种形状的图元进行拓扑编辑。 　　拓扑编辑原理如图4所示。 　　图4拓扑编辑原理一个监控拓扑由若