智能维护系统的设计与实现

第２６卷　

２００６年６月　计算机应用　

Ｃｏｍｐｕｔｅｒ　Ａｐｐｌｉｃａｔｉｏｎｓ　Ｖｏ１．２６　

文章编号：１００１—９０８１（２００６）０６Ｚ一０２１０—０４　

智能维护系统的设计与实现　

赵纲　，王黎明　

（１．河南移动通信有限责任公司网络管理中心，河南郑州４５０００４；　

２．郑州大学信息工程学院，河南郑州４５０００１）　

（ｚｈａｏｇａｎｇ＠ｈａ．ｃｈｉｎａｍｏｂｉｌｅ．ｔｏｍ）　

摘要：电信网络规模的快速增长和用户对电信服务需求的不断提高，使得电信网络基础维护工　

作的难度越来越大。为解决这一问题，介绍了一个智能维护系统的设计及其实现。系统通过引入　

“机器人、定时器、对象组”的概念，实现“维护功能、执行时间、网元对象”三维独立调度；使系统具备　

了灵活性、可扩展性。系统通过“实例属性计算”，支持逐层钻取，多视角展现基础维护工作状态。对　

系统的架构、主要功能部件的实现进行了详细的介绍，对系统的应用进行了举例说明。　

关键词：机器人；定时器；对象组　

中图分类号：ＴＮ９１５．０７；ＴＰ２７３　．５　文献标识码：Ａ　

０　引言　

随着信息技术的快速发展，电信服务越来越普遍、越来越　

丰富的呈现在大家面前。各电信运营商之间的激烈竞争，要　求业务质量更高，要求进一步压缩网络运行成本；同时业务要　更加个性化　Ｊ。伴随着电信网络用户数及电信业务种类的　飞速增长，电信网络的规模及复杂度爆炸式增加。这些因素，　

对保障网络健康运行的维护工作，提出了以下新要求：面向更　加复杂且不断变化的网络；维护工作的深度及力度必须增加，　

以保障网络提供更高质量的服务；提高工作的效率，减少网络　

维护人员　。　目前，各运营商均采用集中化＋运营支撑系统（Ｏｐｅｒａｔｉｏｎ　Ｓｕｐｐｏ￣Ｓｙｓｔｅｍ，ｏｓｓ）的策略，来应对这一挑战　Ｊ。集中化是　

集中维护、集中监控、集中管理的简称，它是各运营商当前网　络维护工作的主要特征。运营商认为集中化运维模式是降低　

网络运行成本，提高业务部署效率的必然选择。ＯＳＳ为集中　化运维在以下方面提供支撑；即ＯＳＳ的主要功能域有Ｈ］：　（１）告警平台。在一点（即集中化）监视所有网络设备、　业务状态的告警，以声、光、短信等形式及时提示监视人员。　

（２）操作平台。在一点操作所有网络设备。即统一鉴　权、自动登录、跨操作系统的操作通道支撑。　

（３）业务管理平台。在一点部署业务数据。即跨操作系　统的配置数据核查、生成、下发。　

（４）性能平台。监视、统计、分析网络运行状态数据，提　供服务质量评价、网络优化指导等支撑。　（５）工作流平台。即承载工单、公文流转、信息发布的指　

挥调度系统。　依托集中化＋ＯＳＳ系统支撑的策略，在很大程度上解决　了以下问题：　

（１）业务管理平台＋工作流平台。提高了业务部署效　率，支撑了业务复杂化、个性化。　

（２）告警平台＋操作平台。实现了省级的一点监控值　班，压缩了网络监控人员。　

（３）性能平台。提高了网络、业务服务质量。　但是，这还不够。保障网络健康运行的核心手段——基　

础维护，各运营商均未考虑在ＯＳＳ上予以支撑。基础维护　（ｂａｓｉｃ　ｍａｉｎｔｅｎａｎｃｅ）主要包括两方面的工作：健康检查与例行　维护㈣。　

健康检查是定期检查网元、网络的如下信息：　

（１）硬件状态。硬件包括：ＣＰＵ、内存、硬盘、板卡等。状　

态包括：主备用、正常、异常、诊断、负荷情况等。　

（２）软件状态。软件包括：进程、软件包等。状态包括：　

激活、正常、异常等。　

（３）业务资源状态。业务资源包括：中继、信令、服务、测　

量等。状态包括：激活、正常、异常、负荷等。　

健康检查的频度，依据被检查对象的特性，各不相同。基　

础维护人员要定期检查网络、网元的上述信息，按照维护规　

程，判断网元、网络工作是否正常，将异常情况上报相关专业　

维护人员处理。　例行维护是指定期对网元、网络执行如下维护任务：　

（１）硬件维护。保持设备正常运行所需要的环境，如：温　

度、湿度、清洁、电源、接地等。　（２）软件维护。保持软件正常运行所需要的维护工作，　

如：垃圾文件清理、备份、杀毒等。　

（３）业务资源维护。保持业务资源正常运行所需要的维　护工作，如：计费数据备份、计费文件上传等。　

目前基础维护存在以下问题：　

（１）对网络变化反应迟钝，新网元、新业务的基础维护工　作不能及时实施；　

（２）维护质量不稳定。因不同维护人员责任心、技术水　

平不同，使得其管理设备的基础维护质量参差不齐。　

（３）力度不足。因网络规模迅速膨胀，维护人员数量又　

被压缩，使得基础维护工作的覆盖面及频度得不到保障。　

为解决上述问题，设计了智能维护系统，该系统有以下特　点：　

（１）快速部署、实施新型维护任务；支撑网络高速扩张；　（２）高速；保障维护工作的覆盖面、频度：　

（３）智能化；基础维护工作中８０％不再需要维护人员参　与；　

（４）与现有ＯＳＳ系统融合，重复利用告警平台、操作平　

台、工作流平台；节约投资。　

收稿日期：２００５—１１—０９；修订日期：２００６—０１—２４　作者简介：赵纲（１９７７一），男，河南驻马店人，工程师，硕士研究生。主要研究方向：电信网管；　王黎明（１９６３一），男，河南浚县人，副教授　博士，主要研究方向：分布式人工智能、机器学习．

　维普资讯 http://www.cqvip.com ６月　赵纲等：智能维护系统的设计与实现　２１１　

１　设计思想　

智能维护系统应能面对：不断变化的网元对象、不断变化　的维护项目、不断变化的维护周期；应能给不同的网络管理人　

员提供不同的视角，让他们看到他们关心的维护过程或结果。　１．１三维调度　为了使系统具有最大的灵活性，必须要考虑所面对的任　务，它所有可能的变化。我们认为，每个具体的维护任务有三　

个因素组成：网元对象，维护功能，执行时间；这三个因素就象　维护任务的三个维度。在维护系统中，只有这三个维度完全　独立，系统才能在三个维护上都实现灵活的调度，才能保障系　

统最大的灵活性。　网元对象与执行时间本来就是相互独立的，关键是使维　护功能与网元对象独立、维护功能与执行时间独立。为此，我　

们引入的机器人的概念：　机器人（ｒｏｂｏｔ）是一个执行具体维护功能的程序。与“网　元”无关，所以ｒｏｂｏｔ不包含登录网元的逻辑与网元鉴权数据；　但它可调用已封装的、与网元无关的网元接１：３程序，实现登录　

网元；与“时间”无关，所以它不会自动运行，只能被其他守护　

进程实时调度。　在维护系统中，用一个三元组＜ｎｅ—ｉｄ，ｒｏｂｏｔ—ｉｄ，　

ｔｉｍｅｒ＿ｉｄ＞来标识一个具体的任务。其中ｎｅ—ｉｄ：是维护对象　

的标识；ｒｏｂｏｔ—ｉｄ：是维护项目（或称维护功能）的标识；ｔｉｍｅｒ—　ｉｄ：是执行时间（或称维护周期）的标识。　

１．２实例属性计算　不同网络管理人员对基础维护工作关心的粒度是不一样　

的。高级网络管理者关心整个网络的基础维护工作是否正　

常；业务管理者关心相关业务网元上的基础维护工作是否正　

常；网元管理者关心某个网元上基础维护工作是否正常，若不　正常，那么其具体情况是什么。为解决基础维护工作的多视　

角管理问题，引人以下概念：　

（１）网元（ｎｅ）。一个具体的网元；例如ＺＺＨＬＲ６。　

（２）网元组（ｎｅ　ｇｒｏｕｐ）。一组网元的集合；例如一组业务　相关网元的集合，一组相同类型网元的集合。　（３）机器人（ｒｏｂｏｔ）。如前所述，一个执行具体维护功能　

的程序，对应一个维护项目。　

（４）机器人组（ｒｏｂｏｔ　ｇｒｏｕｐ）。一组相关维护功能程序的　集合，对应一组维护项目；例如一组业务资源状维护程序集　

合。　（５）方案（ｓｃｈｅｍｅ）。一个ｎｅ　ｇｒｏｕｐ、ｒｏｂｏｔ　ｇｒｏｕｐ、ｔｉｍｅｒ的　

组合。　上述５个概念是维护系统中的５类对象。这５类对象都　有自己的实例；　（６）实例（ｉｎｓｔａｎｃｅ）。对象在一次基础维护任务的具体情　况，叫作对象实例。对象实例有两个基本属性：状态（Ｔｕｒｅ、　

Ｆａｌｓｅ、Ｎｕｌ１）、日志（内容为文本）。　依靠上述５类对象实例，我们能够在不同粒度上展示基　

础维护工作执行情况。例如，常用的对象实例有：　

（１）ｓｃｈｅｍｅ—ｉｎｓｔａｎｃｅ，它的状态表明了整个基础维护工作　执行状态。它向网络管理者展现信息。　状态属性计算方法：它所包含的ｎｅ—ｉｎｓｔａｎｃｅ状态的　

“与”。Ｅｔ志属性计算方法：它所包含的ｎｅ—ｉｎｓｔａｎｃｅ日志的集　合。　

（２）ｎｅ—ｉｎｓｔａｎｃｅ，它的状态表明了某个网元上基础维护　工作执行状态。它向网元管理者展现信息。状态属性计算方　

法：与其相关的ｒｏｂｏｔ＿ｉｎｓｔａｎｃｅ状态的“与”。日志属性计算方　

法：与其相关的ｒｏｂｏｔ—ｉｎｓｔａｎｃｅ　Ｅｔ志的集合。　（３）ｒｏｂｏｔ—ｉｎｓｔａｎｃｅ，它的状态表明了某个ｒｏｂｏｔ在某个网　元上的基础维护工作执行状态，它的日志记录了ｒｏｂｏｔ执行的　具体情况。状态属性计算方法：由ｒｏｂｏｔ在执行过程中赋值。　

Ｅｔ志属性计算方法：由ｒｏｂｏｔ在执行过程中赋值。　如上所述，各类ｉｎｓｔａｎｃｅ通过“属性计算”相互关联。故　从ｓｃｈｅｍｅ—ｉｎｓｔａｎｃｅ可向下钻取到Ｒｅ—ｉｎｓｔａｎｃｅ、ｒｏｂｏｔ—ｉｎｓｔａｎｃｅ；　

从ｒｏｂｏｔ＿ｉｎｓｔａｎｃｅ可向上钻取到Ｒｅ—ｉｎｓｔａｎｃｅ、ｓｃｈｅｍｅ—ｉｎｓｔａｎｃｅ：　从而实现了“多视角展现”。　

２　设计方案　

基于上述设计思想研制了ＩＭＰ（Ｉｎｔｅｌｌｉｇｅｎｔ　Ｍａｉｎｔｅｎａｎｃｅ　ｐｌａｔｆｏｒｍ）系统。　２．１系统框架设计　系统主要由三部分组成：用户界面、任务管理、ＯＳＳ接１：３，　如图１所示。　

口　

图１系统框架　

系统各部件间以消息总线的方式松耦合连接。采用消息　

总线接口主要有两个优点：　（１）减少开发难度，缩短开发周期。可采用成熟的中间　

件产品，如ＩＢＭ　ＭＱ。　

（２）系统部署灵活。根据负荷需要，各部件可部署在不　同的主机上。　系统外部接口主要有两类：　

（１）Ｗｅｂ界面。用户界面采用Ｗｅｂ接口，便于用户使　

用，无需安装客户端。　（２）ＯＳＳ接１：３。系统采用Ａｇｅｎｔ插件模式与ＯＳＳ各平台　

通讯，需要与什么平台通讯只需开发、安装相应的Ａｇｅｎｔ。　

Ａｇｅｎｔ与ＯＳＳ各平台通讯时，遵守已成熟的各平台接１：３规范。　２．２系统部件设计　用户界面部分有：ｍｏｎｉｔｏｒ（用户界面支持部件），管理　

ｓｃｈｅｄｕｌｅｒ、ｓｕｐｅｒｖｉｓｏｒ。ｓｕｐｅｒｖｉｓｏｒ（系统监控部件），监视系统其　他部件的工作状态。　任务管理部分有：ｓｃｈｅｄｕｌｅｒ（任务调度部件）。管理基础维　

护工作方案。ｒｏｂｏｔ（机器人部件），执行基础维护工作的程　

序。　

ＯＳＳ接１：３部分有：Ｒｅｓｏｕｒｃｅ　Ａｇｅｎｔ（资源代理部件），资源　平台的接口。Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ａｇｅｎｔ（鉴权代理部件），鉴权平台　

的接１：３。Ｏｐｅｒａｔｉｏｎ　Ａｇｅｎｔ（操作代理部件），操作平台的接１：３。　Ａｌａｒｍ　Ａｇｅｎｔ（告警代理部件），告警平台的接１：３。Ｗｏｒｋｆｌｏｗ　

Ａｇｅｎｔ（工作流代理部件），工作流平台的接１：３。　系统部件设计如图２所示。各部件间的主要关系如图３　

所示。　２．３主要部件的功能特点　２．３．１　ｓｃｈｅｄｕｌｅｒ部件　ｓｃｈｅｄｕｌｅｒ是实现系统核心功能的主要部件。它主要有两　部分组成：配置数据、后台进程。配置数据存储在数据库中。