网元层故障管理模块的软件可靠性设计技术

网元层故障管理模块的软件可靠性设计技术

网元层故障管理模块的软件可靠性设计技术

类别：通信网络

 典型的GSM／CDMA移动通信网由交换分系统、基站分系统和大量移动用户终端三大部分组成。其中，交换分系统也称为移动交换系统(MSS)，由移动交换中心(MSC)、归属位置寄存器(HLR)、被访位置寄存器(VLR)、设备识别寄存器(EIR)、鉴权中心(AUC)、短消息中心(SMSC)等诸多网络元素(NetworkElement，简称为网元)和操作维护中心(OMC)构成。交换分系统是移动通信系统的控制交换中心，也是移动网与其他通信网的接口。交换分系统中任何一个网络元素出现故障都有可能对整个移动通信系统产生严重影响。在交换分系统中，操作维护中心和各网元实体上的故障管理模块是网元层网络管理系统的一个重要组成部分。本文以移动交换系统网元层故障管理模块为例，介绍在实时系统的软件设计过程中，在保证系统实时性的前提下，提高软件系统可靠性的一些软件设计技术。1故障管理模块概述

 故障管理模块在交换分系统中所处的位置如图1所示。

 故障管理模块存在于OMC和各网元实体之上。OMC上的故障管理模块一般设计为客户端/服务器(C／S)结构，其实现的功能包括：故障信息的持久性保存(一般是写入数据库)、故障信息的显示、网元机架图的显示等。网元上的故障管理模块负责收集各业务进程和控制进程产生的故障信息，经过处理后把这些故障信息转发到OMC。故障信息也称为告警消息。一条告警消息在C++中表现为-对象，包括告警发生时间、恢复时间、发生位置和流水号等若干属性。

 故障管理模块是监控交换分系统是否正常工作的主要工具，是电信运营商非常重视的一个软件模块。电信运营商对故障管理功能的最基本的要求就是：实时准确，不漏警，不虚警。为了达到这个要求，故障管理模块的设计必须在保证实时性的基础上，确保故障信息的准确无误。

 2网元上故障管理模块的设计和实现

 交换分系统中的各种网元实体(如MSC、HLR等)都是典型的分布式实时系统，一般由若干个模块构成。交换分系统中的设备都要求全年24小时不间断工作，所以每个模块都采用了主机备用冗余的设计。网元中故障管理模块的结构示意图如图2所示。每个模块都有主用和备用2个模块处理机(MP)，2个模块处理机同时处于工作状态。备用MP只和主用MP通信，负责备份主用MP中的重要数据。一旦主用MP发生故障，备用MP可以在不中断业务的情况下迅速地转为主用工作状态。

 从图中可以看出，故障管理模块同时运行在主用和备用MP中。故障管理模块在MP中用3个进程实现。

(1)告警收集进程：收集各业务进程和单板控制进程产生的告警信息，进行必要的格式转换等数据预处理工作，然后把处理后的告警信息放入当前告警列表和消息发送队列。当前告警列表存储在MP内存中的一个数据缓冲区。主用和备用MP中的告警数据缓冲区总是处于一致状态。

(2)告警发送进程：主要的任务是将告警发送队列中的告警消息发送到OMC上的故障管理模块。

(3)告警同步进程：主要完成网元和OMC之间告警消息的周期性同步、断链同步处理以及主用和备用MP之间的周期性同步和倒换同步处理。该进程是实现不漏警、不虚警要求的重要机制。

 3OMC中故障管理模块的设计和实现

 OMC设计为C／S结构。故障管理模块同时存在于客户端和服务器上，分别用不同的应用进程实现。服务器上的故障管理模块实现的功能有：保存告警信息到数据库；转发告警信息到上一级的网络管理中心；转发告警信息到客户端；处理客户端的数据库操作请求和参数修改请求；控制告警箱等。客户端的故障管理模块实现的功能有：最新告警的实时显示；历史告警的查询和打印；告警屏蔽设定和解除；机架图的实时显示；人机命令界面等。

 在C／S结构的系统中，服务器处于核心地位，服务器端的故障管理进程要确保能长时间正常工作。在OMC系统中，可以使用看门狗机制监控故障管理进程。看门狗实际上是一个错误监控程序，可以用一个高优先级的应用进程来实现。看门狗进程定时向故障管理进程发送握手消息，故障管理进程收到此消息后会立刻发回一个确消息。如果在一段时间内收不到故障管理进程的响应，看门狗进程就认为故障管理进程发生异常。此时看门狗进程就会杀掉并重新启动故障管理进程，使故障管理进程恢复正常运行状态。4使用定时同步机制保证故障信息的准确性从用户使用的角度看，故障管理模块必须保证2种信息的准确性：机架图和活动告警机架图是对网元上各种单板位置和状态的直观显示。网元有无故障，用户通过查看OMC客户端上的机架图就能一目了然。为了确保机架图显示的实时性，可以把机架图在内存中按线形结构存储。例如一个机架由7层机框组成，每层机框有27个板位，该机架在内存中就可以用2个长度为27×7的一维数组表示：aRackState[189]和aRackType[l89]。ARackState[l89]是表示单板状态的数组，aRackType[189]是表示单板类型的数组，二者结合就是完整的机架图信息。OMC和网元上的故障管理模块都在各自的内存中维护机架图数组。OMC中维护内存机架图数组的目的在于保证客户端界面上的机架图显示能很好地实时刷新，并且还便于和网元中的机架图数组保持数据同步。网元中的内存机架图数组由网元上的告警进程和控制进程共同维护。数组中的信息和网元中的内存数据库保持一致，其数据是高度可靠的。为了保证OMC和网元的机架图数组的数据一致性，需要引入定时同步机制确保二者的数据完全相同。

 最简单的同步办法是每隔一定时间把OMC上的机架图数组发送到网元上，由网元上的告警同步进程逐字节地比较OMC和网元机架图数组的异同。由于1个网元可能由10个以上的机架构成，而同步间隔一般都是若干秒，因此在很短的时间里把很多数组传来传去对底层通信系统的总体性能会有一定影响。

 本系统采用的办法是比较OMC和网元机架图数组的校验和。同步过程由OMC上的故障管理进程发起，该进程计算出OMC上的机架图数组的校验和，然后把该校验和发送到网元上的告警同步进程。网元上的告警同步进程收到该校验和后，立刻计算出本机内存中的机架图数组的校验和，然后比较这2个校验和的值。如果这2个，值不一致，说明前、后台机架图不一致，网元上的告警同步进程就把本机内存中的机架图数组发送到OMC，OMC中的机架图数组随即得到更新。

 计算校验和的算法采用了16位循环冗余校验CRC(CycleRedundancyCheck)算法。它可以对一个数据块进行校验，是一种高效的差错控制方法。16位CRC算法能够检查出所有的单位错、双位错、奇位数错及小于等于16位的突发性错，还能检查出17位突发性错的99．997％，大于等于18位突发性错的99．998％。如此高的可靠性，可以满足用户对机架图准确性的严格要求。

 活动告警是指当前没有恢复的、正在发生的告警。其同步过程与机架图类似，此处不再展开讨论。

 5持续改善软件设计与开发质量

 前面介绍的主备冗余、定时同步和看门狗机制都不同程度地提高了故障管理模块的可靠性，但这些机制并不能完全确保不漏警、不虚警。网元中的每个模块处理机都是一个运行在PSOS、VxWorks等实时操作系统之上的大型实时系统。MP上运行着大量的应用进程，软件故障不可避免地存在其中。相当比例的漏警、虚警事故与硬件无关，而是由业务模块和故障管理模块中的软件错误导致，所以提高软件设计质量和