基于网管告警分析的重载铁路通信设备故障诊断系统研究

张 斌，王 巍，吴明明

(1.国能朔黄铁路发展有限责任公司 科技部，河北 肃宁 062350；2.中国铁道科学研究院集团有限公司通信信号研究所，北京 100081；3.北京英诺威尔科技股份有限公司 产品方案部，北京100071)

随着朔黄铁路通信网络各专业系统的不断发展扩大，厂家不断多元化，网管也不断多样化，网络中发生一个或多个故障时可能会触发大量的告警数据。虽然告警信息可以帮助网管人员定位网络故障点，但大量的告警信息既增加了网管系统的开销，也掩盖了表示故障的根源或实际具有业务分析价值的告警信息，非常不利于网管人员排查故障。由于大量告警信息的分析与故障定位都需要人工手动处理，极大影响了网管分析人员故障处理的效率，降低通信网业务服务质量，严重时甚至影响行车安全。因此，针对朔黄铁路通信网络和故障处理情况，提出一种基于网管告警分析的智能故障诊断系统方案。

1 朔黄铁路通信设备故障处理现状

朔黄铁路(神池南—黄骅港)位于山西省东北部及河北省中部，基本呈西东走向，是神黄铁路(大柳塔—黄骅港)的重要组成部分，西起山西省朔州站，西与神朔铁路(大柳塔—朔州)相联，东至河北省沧州市黄骅港口货场。线路设计为国家I级干线、双线电气化铁路，重载路基，正线总长594 km[1]，共计34个车站33个区间，在全国铁路网中占有重要地位，特别是对加快沿线地方经济发展、保证华东、东南沿海地区能源供应、扩大我国煤炭出口能力具有重要的战略意义。朔黄铁路先后于2001年12月开通神肃段通信工程，2002年8月开通肃黄段通信工程，2014年开通LTE宽带移动通信工程，黄万铁路(黄骅南—万家码头)LTE-R网络已于2020年开通运营。

通信设备在通信领域中是关键的基础设施，如果通信网设备出现了障碍性问题，则会影响到整个通信网和通信设备的运行[2]。而且随着通信网的功能更加强大，对通信设备的使用质量要求也越来越高，整个通信网络也变得更加庞大、复杂，故障分析十分困难。有些故障的发生可能会引起多个网管子系统同时产生大量告警，各通信专业子系统的告警数据较为分散，形成数据“孤岛”；另外各通信专业子系统开发厂商采用数据标准不一，难以确保数据的一致性和完整性；缺乏有效的分析手段，难以对现有数据进行分析挖掘，导致大量有价值的信息流失；数据共享能力弱。部分监测、检测系统较为老旧，采集内容较少，误警率高，不利于故障诊断分析；相关的检测、监测、运维、管理等数据分散存储，难以集中，无法支撑数据的挖掘分析；设备状态等数据的分析主要依靠现场人员经验判断，效率低下且难以发现一些趋势类和跨专业的隐患；设备告警信息无法很好地进行关联性分析，不能更有效地保证设备健康、高效、低成本的运用，实现精细化、智能化[3]故障处理管理。

为解决上述问题，在朔黄铁路电务智能运维平台[4-5]采集归一化数据的基础上，建立一种基于网管告警分析的通信设备智能故障诊断系统。

2 智能故障诊断系统架构

智能故障诊断的系统架构[6-7]设计共分为4层，分别为数据采集层、数据预处理与存储层、数据挖掘层、数据应用层。

（1）数据采集层。通过与各通信专业子系统、监测检测系统的北向接口，完成数据采集指令的发送和接收，并把采集到的原始数据以文件的方式保存，为故障诊断系统提供资源、告警的原始数据。

（2）数据预处理与存储层。实现对原始数据进行清洗、转换、标记、索引等预处理操作，然后将原始数据转换为可以满足故障诊断所需信息的初始数据。

（3）数据挖掘层。根据故障诊断系统需求实现对初始数据的挖掘分析，形成满足故障诊断系统功能应用层需要的结果数据，用于支撑功能应用层的故障诊断相关功能。

（4）数据应用层。故障诊断的主要内容和需求，实现告警监控、工程告警管理、告警相关性分析、故障诊断、故障工单管理、经验与案例等功能。

故障诊断的系统架构如图1所示。

图1 系统架构Fig.1 System architecture

3 故障诊断实现

故障诊断是通过工程告警标记、告警叠加等方法从各通信专业子系统的大量告警数据中获取少量有价值的告警数据，以业务相关性为牵引，结合时间相关性、资源相关性，根据告警相关性规则给出根源和衍生告警，对告警实现端到端的业务告警监控分析、辅助故障诊断、故障处理来实现。另外建立并不断丰富完善告警经验库与故障案例库，可用于告警分析、故障分析推荐处理建议，提高告警分析、故障分析、故障处理效率，降低故障处理时延[8]。故障诊断流程如图2所示。

图2 故障诊断流程Fig.2 Fault diagnosis process

3.1 告警数据预处理

对采集到的各通信专业网管系统的告警数据进行预处理。将不同厂家、不同设备类型的告警数据进行标准化处理，处理成统一格式、告警等级的数据。另外对传输业务经过的端口、时隙发生的告警数据标记上业务影响范围。

3.2 告警收敛

告警处理插件almserver根据告警过滤规则、工程告警标记对预处理后的标准化的大量告警数据进行收敛[9-10]。

（1）过滤规则。根据专业、网管、区域、设备类型、设备型号、告警名称、告警等级、告警类型、告警对象、告警发生的起始时间和结束时间制定过滤规则，almserver将不需要参与分析的告警数据直接过滤到历史告警库中。

（2）重复告警收敛。当系统在限定时间内收到重复发送的同一告警时，系统会自动消除重复的告警，只保留最初一条告警，同时记录告警重复上报的次数以及上报的时间。

（3）工程告警标记。根据施工单信息对因施工原因引起的工程告警进行工程标记。工程告警标记可以实现告警数量的收敛，减少无效告警的干扰，提高维护人员告警分析和故障排查的处理效率。系统根据用户批量录入的施工单信息，结合施工影响网元、施工真实时间范围标记工程告警。

可以满足2种场景的工程告警标记：①实时标记工程告警。提前填写施工单信息，施工过程中系统实时根据施工计划时间和施工网元标记工程告警。②施工后标记工程告警。施工后录入施工单信息，填写施工单真实施工时间信息，点击工程告警标记按钮即可实现施工范围内工程告警的标记。

经过上述步骤，对故障引起的告警进行收敛；告警收敛后数量对比如表1所示。①对DWDM光缆中断故障引起的告警数据进行收敛，收敛前为22条告警，收敛后为7条告警，告警收敛率为68.18%；②对SDH系统2.5G双向线路中断故障引起的告警数据进行收敛，收敛前为401条告警，收敛后为15条告警，告警收敛率为96.25%。

表1 告警收敛后数量对比Tab.1 Number comparison after alarm convergence

3.3 告警相关性分析

对告警收敛后的数据，通过相关性分析规则对告警信息进行关联和分类[7]，自动关联识别出相关性告警组和不具有相关性的独立告警。相关性分析规则主要依据对活跃告警的业务相关性、时间相关性、资源相关性、事件相关性进行关联分析，对告警数据关联分组。

（1）业务相关性。根据业务承载链路经过的设备、端口、时隙信息，制定业务相关性分析规则。某一时间段内，同一个电路所涉及到的时隙/端口的活跃告警归为一组。

（2）时间相关性。某种情况下同时发生的活跃告警。多个网元同时或者5 s内发生的活跃告警归为一组。

（3）资源相关性。告警对象存在资源关系。如相同资源、上下级资源、资源承载、复用段端口关系。资源相关性按照以下方法进行匹配：①当前活跃的告警中，同一告警对象的相同告警归为一组；②当前活跃的告警中，上下级对象(设备-板卡-端口)的告警归为一组；③当前活跃的告警中，同一个复用段两端端口的所有告警归为一组；④当前活跃的告警中，同一个光缆段的复用段的端口的活跃告警归为一组。

（4）事件相关性。告警名称存在相关性，如当发生复用段远端接收失效指示MS_RDI告警时，相同或极短时间内的对端站线路板发生的R_LOS，R_LOF，MS_AIS告警可以归为一组。

上述相关性规则的获取和不断完善主要来源于专家处理故障经验，以及不断丰富完善的告警处理经验和故障案例库。

3.4 故障诊断

故障诊断对收敛后的告警数据基于相关性规则进行规制匹配，将符合相关性规制的每组相关性告警作为一个疑似故障，并及时提示相关运维人员。同时结合告警处理经验库和故障案例库罗列出该疑似故障可能影响业务范围的故障信息和相应的故障处理建议，运维人员只需要通知现场人员线下根据故障信息进行简单排查验证，即可快速对系统分析出的疑似故障信息进行判断确认。当疑似故障确认为故障后，现场故障处理人员能够根据系统提供的故障处理建议快速处理故障。

故障诊断功能[11-13]辅助运维人员快速、及时地发现故障，并结合业务信息进一步实现端到端的业务影响分析，提高影响业务的故障处理效率，极大地避免了因故障发生处理不及时而有可能产生的安全隐患[14]。

故障诊断还提供运维人员对确认后的故障信息直接下发故障工单功能。系统自动填充故障分析结果和处理建议，同时运维人员也可手动修改相关故障分析结果和处理建议，简化人工劳动，提高故障工单下发效率。

3.5 故障工单管理

对故障处理的全面监控，实现故障处理的闭环管理审批流程，便于运维人员在最短的时间内有效解决网络故障问题。故障工单处理流程如图3所示。

图3 故障工单处理流程Fig.3 Processing flow of fault work order

（1）分公司发起故障工单给通信工队；工单状态为未接收；故障状态为未恢复。

（2）通信工队进行工单受理，若维护人员发现不是自己负责的故障范围，则转派给负责处理该故障的维护人员；工单状态为已接收；故障状态为未恢复。

（3）通信工队的维护人员进行工单故障处理，当“具备恢复条件，且故障已经恢复”时；维护人员填写实际完成时间和处理结果；然后进行工单回复；工单状态为已接收；故障状态为未恢复。

（4）分公司对回复工单进行确认，处理方法分别为：①当故障恢复，则信息中心对工单确认归档；②故障未恢复，则信息中心进行退单操作；确认归档后，工单状态为已接收；故障状态为已恢复。

3.6 经验与案例

告警知识库描述各类告警的发生原因和处理建议，为告警监控模块处理告警时可以快速匹配出告警处理经验提供完善的告警知识库，且在告警监控模块可以通过快捷录入告警知识库来实现对知识库的积累完善操作。告警知识库如图4所示，系统根据告警名称、专业、厂商自动给出告警原因和告警处理建议，方便运维人员快速排查故障。

图4 告警知识库Fig.4 Alarm knowledge base

故障案例库则是记录一些典型故障案例发生时将会产生的特征告警及故障关联告警的详细信息，为故障诊断提供重要依据，为故障工单下发时的处理方法提供建议和依据。

4 结束语

智能故障诊断系统从海量告警信息中收敛出具有业务分析价值的少量告警，以业务相关性为牵引，结合时间相关性、资源相关性、事件相关性，对告警实现端到端的业务告警监控分析、辅助故障诊断、故障处理等功能，并且结合日常故障分析处理经验，通过数据挖掘逐步完善告警识别规则、告警相关性规则、经验与案例库。随着经验与案例的积累，将以往发生的告警处理经验和故障处理典型案例进行学习再利用于故障诊断环节，形成一个正反馈效应，而故障诊断功能的不断使用，又促进了经验与案例的积累愈加丰富，故障诊断给出的疑似故障信息的影响范围和故障处理建议也将更加精确。随着经验与案例的不断积累和学习，故障诊断的持续使用，朔黄铁路通信网故障处理运维人员的告警分析、故障处理的效率和质量得到提高，工作量不断简化，对降低故障时延、提高响应速度、改善服务质量、降低生产人力成本和时间成本、提高生产效率和安全性、提高通信网各专业系统及网络运行的稳定性和可靠性、确保行车安全具有重要意义。