Problem model for alarm correlation

Details Problem model for alarm correlation Problem model for alarm correlation

1997-07-14

2003-07-22

Davis, George B. (Department: 2121)

Data processing: artificial intelligence

Knowledge processing system

Knowledge representation and reasoning technique

C706S047000, C706S045000, C707S793000

Reexamination Certificate

active

06598033

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to methods of processing data from communications networks, systems for processing data from communications networks, methods of diagnosing causes of events in complex systems, methods of acquiring knowledge for knowledge based reasoning capacity for the above methods, methods of extending compilers for such knowledge based reasoning capacity, and methods and systems for using such extended compilers.
BACKGROUND TO THE INVENTION
In complex systems such as communication networks, events which can affect the performance of the network need to be monitored. Such events may involve faults occurring in the hardware or software of the system, or excessive demand causing the quality of service to drop. For the example of communication networks, management centres are provided to monitor events in the network. As such networks increase in complexity, automated event handling systems have become necessary. Existing communication networks can produce 25,000 alarms a day, and at any time there may be hundreds of thousands of alarms which have not been resolved.
With complex communication systems, there are too many devices for them to be individually monitored by any central monitoring system. Accordingly, the monitoring system, or operator, normally only receives a stream of relatively high level events. Furthermore, it is not possible to provide diagnostic equipment at every level, to enable the cause of each event to be determined locally.
Accordingly, alarm correlator systems are known, as shown in
FIG. 1
for receiving a stream of events from a network, and deducing a cause of each event, so that the operator sees a stream of problems in the sense of originating causes of the events output by the network.
The alarm correlator shown in
FIG. 1
uses network data in the form of a virtual network model to enable it to deduce the causes of the events output by the network. Before the operation of known alarm correlator systems is discussed, some details of how alarms are handled within the network will be given, with reference to FIG.
2
. Several layers of alarm filtering or masking can occur in between a device raising an event, and news of this event reaching a central system manager. At the hardware element (HE) level, the system would be overwhelmed, and performance destroyed if every signal raised by hardware elements were to be forwarded unaltered to higher layers. Masking is used to reduce this flood of data. Some of the signals are always suppressed, others delayed for a time to see if a higher criticality signal arises, and suppressed if such a signal has already been sent.
Some control functions may be too time critical to be handled by standard management processes. Accordingly, either at the hardware element level, or a higher level, some real time control may be provided, to respond to alarms. Such real time control (RTC) has a side effect of performing alarm filtering. For example, a group of alarms indicating card failure, may cause the real time controller to switch from a main card to a spare card, triggering further state change modifications at the hardware element level. All this information may be signalled to higher levels in a single message from the RTC indicating that a failure and a handover has occurred. Such information can reach the operator in a form indicating that the main card needs to be replaced, an operation which normally involves maintenance staff input.
A node system manager may be provided as shown in
FIG. 2
, to give some alarm filtering and alarm correlation functions. Advanced correlation and restoration functions may be located here, or at the network system management level.
In one known alarm correlation system, shown in U.S. Pat. No. 5,309,448 (Bouloutas et al), the problem of many alarms being generated from the same basic problem is described. This is because many devices rely on other devices for their operation, and because alarm messages will usually describe the symptom of the fault rather than whether it exists within a device or as a result of an interface with another device.
FIG. 3
shows how this known system addresses this problem. A fault location is assigned relative to a device, for each alarm. A set of possible fault locations for each alarm is identified, with reference to a stored network topology.
Then the different sets of possible fault locations are correlated with each other to create a minimum number of possible incidents consistent with the alarms. Each incident is individually managed, to keep it updated, and the results are presented to an operator.
Each of the relative fault locations are internal, upstream, downstream, or external. The method does not go beyond illustrating the minimum number of faults which relate to the alarms, and therefore its effectiveness falls away if multiple faults arise in the selected set, which is more likely to happen in more complex systems.
Another expert system is shown in U.S. Pat. No. 5,159,685 (Kung). This will be described with reference to FIG.
4
. Alarms from a network manager
41
are received and queued by an event manager
42
. After filtering by an alarm filter
43
, alarms which are ready for processing are posted to a queue referred to as a bulletin board
44
, and the alarms are referred to as goals. A controller
45
determines which of the goals has the highest priority. An inference engine
46
uses information from an expert knowledge base
47
to solve the goal and find the cause of the alarm by a process of instantiation. This involves instantiating a goal tree for each goal by following rules in the form of hypothesis trees stored in the expert knowledge base. Reference may also be made to network structure knowledge in a network structure knowledge base
48
. This contains information about the interconnection of a network components.
The inference process will be described with reference to FIG.
5
. First a knowledge source is selected according to alarm type. The knowledge source is the particular hypothesis tree. Hypothesis trees, otherwise known as goal trees are stored for each type of alarm.
At step
51
the goal tree for the alarm is instantiated, by replacing variables with facts, and by executing procedures/rules in the goal tree as shown in step
52
. If the problem diagnosis is confirmed, the operator is informed. Otherwise other branches of the goal tree may be tried, further events awaited, and the operator kept informed as shown in steps
53
to
56
.
This inference process relies on specific knowledge having been accumulated in the expert knowledge base. The document describes a knowledge acquisition mode of operation. This can of course be an extremely labour intensive operation and there may be great difficulties in keeping a large expert knowledge base up to date.
A further known system will be described with reference to FIG.
6
. U.S. Pat. No. 5,261,044 (Dev et al) and two related patents by the same inventor, U.S. Pat. No. 5,295,244, and U.S. Pat. No. 5,504,921, show a network management system which contains a model of the real network. This model, or virtual network includes models of devices, higher level entities such as rooms, and relationships between such entities.
As shown in
FIG. 6
, a room model
61
may include attribute objects
62
, and inference handler objects
63
. Device models
64
,
65
, may also include attribute objects
66
,
67
and inference handler objects
68
,
69
. Objects representing, relationships between entities are also illustrated. The device models are linked by a “is connected to” relationship object
70
, and the device models are linked to the room model by “contains” relationship objects
71
,
72
.
The network management system regularly polls all its devices to obtain their device-determined state. The resulting data arrives at the device object in the virtual model, which passes the event to an inference handler attached to it. An inference handler may change an attribute of the device object, which can raise an event which fires another

Affiliated with

Also associated with

Rating

Problem model for alarm correlation does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Problem model for alarm correlation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Problem model for alarm correlation will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3097883