Previous Contents Next

Chapter 8   Implementation

This chapter describes the implementation of a Ripple-Down Rules tree. Section 8.1 describes the structure of the knowledge base as it is implemented. The structure of the alarms is given in section 8.2. The correlator, which ties the two together, is described in section 8.3. Section 8.4 gives the examples which illustrate the capabilities of the correlator.

8.1   Single Conclusion Ripple Down Rules (SCRDR)

Multiple conclusion ripple down rules (MCRDR) is more appropriate to alarm correlation since there is more than one conclusion to be drawn from a set of alarms most of the time. However, to demonstrate the principles at work SCRDR is adequate at this stage.

8.1.1   The Ripple Down Rules Tree

To define the RDR tree we start with the nodes. As with all tree nodes each node has links to its parent node and its children nodes. In SCRDR each node has a maximum of two child nodes.



Figure 8.1: One node of an RDR tree.

Each RDR node also has a corner stone case. This is the case for which the node was added. This helps give the context in which the rule is interpreted. The corner stone case is a set of alarms. When it comes time to add another rule, the corner stone case is displayed alongside the case in question. Somehow the differences between the cases should be highlighted.

The conclusion is like the action part of a production rule. In the existing correlator these work to modify the display of the alarms. A simple conclusion such as `Do not display alarm 1' could be automated fairly easily, but for the demonstration the conclusion is given as a sentence.

8.2   The Alarms

The alarms for this demonstration do not have to show all the fields as in page 3.2. It is enough to have a description of the alarm, the name of the object issuing the alarm and the severity. That will give enough to work with to compare the alarms.

The alarms are kept in a set for correlation. The set is passed into the correlator to be tested against the rules tree. The set is merely a list of alarms. They are listed in the order in which they were generated.

In reality the set of alarms is being updated constantly. In figure 8.2 the alarms are coming into the correlator from the network and also in a feedback loop from the correlator.



Figure 8.2: The path that alarms travel through the correlator.

8.3   The Correlator

For the moment testing the conditions at each node against the alarm set is not automated. For this demonstration it is enough to let the user decide whether the conditions are satisfied by an alarm set or not. To automate this would require defining all the semantics that go with interpreting conditional clauses and logical constructs.

The correlator guides the user through the tree. The alarms are presented in a table so that testing the conditions can be done easily.

When a set gives the wrong conclusion, or a conclusion that should be refined further, then the correlator helps add a new rule to the tree.

8.4   Examples

8.4.1   The dinner example

Here is a simple rules base for a demonstration of the principles at work in Ripple-Down Rules. The question is, what shall we have for dinner? The objects we have are the contents of the cupboard. Each of these objects has the attributes:


There are other things taken into consideration in this tree, such as the day of the week, past meals and so forth. These are not standard food objects, and in this demonstration these will be supplied by the user rather than picked out by the computer.



Figure 8.3: The `What shall we have for dinner?' Example

Notice the layout of the tree first. The tree branches to the right for conditions satisfied and downwards for conditions not satisfied. The downwards direction is more developed, as was found in the Garvan RDR tree [Compton etal., 1991].

The first node in this tree is, as always, the root node which is always true. This node serves to identify the tree and provides a starting point. The next node was added fairly arbitrarily. On Fridays it is traditional not to eat meat or poultry. Since it is also the day when people feel least like preparing a meal, fish and chips is the easiest choice.

Notice that in the rule only the day of the week is included in the conditions, not the state of tiredness of the people preparing dinner. This can be refined further on. Also notice that only one conclusion is made. We could have given a list of all the meatless dishes in the family's repertoire. This is also a refinement that can be added later.

Rules were added fairly randomly to add different dishes to the tree. Each day the food available was run through the correlator and for the first week there was a new rule added every day. Lets look at an hypothetical day.

On the twelfth day we have lots of spinach, lots of noodles and some eggs. Unfortunately we're almost out of milk. The rules tree concludes that we should have creamy spinach soup, but we can't since we haven't got enough milk. The conclusion reached by the human experts is to make a spinach noodle quiche.




Rule 6 Rule 12
2L Milk No Milk
Some Noodles Lots of Noodles
2 Eggs 6 Eggs
Creamy Spinach Soup Spinach Noodle Quiche


Table 8.1: The differences between the case at hand and the corner stone case for rule 6

The first step is to look at the differences in the case at hand and the corner stone case for the last rule to be satisfied. See Table 8.4.1 for a summary. The next step is to choose the most relevant differences. For this example we'll pick `No Milk' as the defining difference. To make the rule a little more general, the level of 1.5L of milk will be the cutoff level. That way if there is only 1 cup of milk the rules will not recommend soup. We could have picked the number of eggs as the defining difference, it is up to the expert.

The new rule is illustrated in Figure 8.4. Notice how there can be overlapping nodes in this tree diagram. Such are the limitations of two dimensional paper.



Figure 8.4: The new node inserted in the dinner tree

The question that springs to the mind of the expert here is, what if there are no noodles? Then we could still have quiche, but without noodles mixed in. Logically, were this a decision tree, the general quiche idea should go first, then all the variations should follow. This need not be the case thanks to Ripple-Down Rules. Any refinement can be added onto the existing rules. A different quiche could follow from the satisfied branch of rule 12.

Using the program

The program is run from the command prompt. There is a help screen available, but it does not claim to be the most user friendly program (my apologies). The aim is to demonstrate how Ripple-Down Rules works.

At first the program is loaded with the `dinner' tree and the alarm set which is the corner stone case for node 1.

To step through the example of adding the 12th node, as explained in the previous section, first you load the appropriate alarm set by typing:

                a 12
This loads the case described above, where there is not enough milk to make soup, so we want to make a quiche instead.

To start the correlator type:

                start
The program will present the conditions at each node, asking you whether the present case satisifies these conditions or not. The present case is displayed in a table as you can see in Figure 8.5



Figure 8.5: The cornerstone case for node 12 of the `dinner' tree

An example of one question is:


The Current Conditions: If today is Friday
Are the conditions satisfied? (yes or no)
Looking at the table in Figure 8.5 we can see that `today' is Thursday, so the answer to type is no.

At last we come to the last rule, where we see:

The Current Conditions: If there is a lot of spinach
Are the conditions satisfied? (yes or no)yes
We'll have creamy spinach soup
Here we see the problem that we described earlier in this chapter. There is only 100mL of milk, so we can't make creamy spinach soup. The next step is to fix the problem, by typing: 
                fix
Which brings up a table for the relevant corner stone case for the rule we are fixing (see Figure 8.6). At the command prompt we see: 
The Last Conditions: If there is a lot of spinach
           (which generated this conclusion: We'll have creamy spinach soup)
Are the conditions satisfied? (yes or no)


Figure 8.6: The cornerstone case for node 6 of the `dinner' tree

There is indeed a lot of spinach, so we type yes. Next we are prompted to enter in the new conditions and conclusion. Add the new values as in Figure 8.4 and then type start to check the tree.

Run through the questions again referring to the alarms table 12 and the program should ask you the same questions plus the conditions that you just added. If everything goes according to plan you should end up with the conclusion you just added.

8.4.2   A telecommunications example

Since this project aims to deal with fault management in a telecommunications situation an example in this area is logical.

The network model used is necesarily simple. Taking the case of a telephone network in a small area a simple model may look like Figure 8.7.



Figure 8.7: A simple hierarchical telephone network.



Figure 8.8: An RDR tree based on the network of Figure 8.7

Using the program

The tree for this example is loaded by typing: 
                t 2
and the alarms by typing 
                a 21
where, instead of typing 21, any number between 21 and 33 can be used.

It is apparent that even such a simple network may need more work in defining a set of rules. The rules suggested here work on the object ID of the alarm. The description, however, should also be looked at. If the alarm says that one node cannot contact another node, then either of the nodes could be at fault, not just the one generating the alarm. This is where more knowledge of the domain is needed. Making up theoretical systems is all very well, but reality is bound to be different.

This is another advantage of RDR. The work of the engineer is in providing the capabilities to test the conditions and act on the conclusions, rather than the rules that connect the two. That is left to the one who knows.

8.4.3   Demands of a telecommunications system

The Garvan-ES1 system was particularly suited for an expert system. There were only 32 attributes to be looked at and 60 different classifications to sort each cases into. The thyroid cases were a static system, the human body doesn't change that much over time. Refinements were needed, but there were no major changes. The telecommunications is always changing. Compared to the thyroid problem it would be like having to update the system because people started growing extra glands that affected the thyroid effects.

The other difference is that an expert system in a medical context deals with diagnosing one patient at a time. The telecommunications network deals with reports coming in from a multitude of elements. Each alarm has its own attributes.

There are some standard attributes that come with each alarm, but there are extra fields that are not compulsorily filled. Some fields are set aside for use by the correlator itself, such as duration and count (see page ??).

8.5   Applying Machine Learning

For developing a Ripple-Down Rules knowledge base for a telecommunications system, automating the writing of rules would be of great benefit. The file of examples encoding the trees and the cornerstone cases is quite long, even for a simple example.

There are essentially two paths to generating a knowledge base:
  1. Inducing a rule set from an exhaustive set of data.
  2. Creating a model of the system and inducing a rule set from that.
Generally the second leads to the first because the model is used to generate an exhaustive set of data.

In a quickly changing system such as telecommunications it is generally harder to get a training set of information. But the topology information is more readily available. The topology describes the connections of all the devices in the network. It should be possible to come up with some sort of framework for a model. Experience in monitoring the system is needed to know the interdependencies of the network.

Another difference between medical cases and telecommunication network diagnosis is the multitude of elements. In the heart model used in KARDIO [Bratko etal., 1989] there are five impulse generators and two conduction pathways. This model was used as a reduced model since a classical model, expressed in differential equations, was not available.

Modelling the heart sounded difficult enough, but modelling a telephony system is prohibitive because of the multitude of elements and the irregularity of medium to wide area networks.

However, the first step is to make a start. Whatever is already known can be modelled and encapsulated in a rules tree. This can be used as a base on which to build further refinements.

8.6   Summary

Here I have described the implementation of a single classification RDR knowledge base tested with two examples from different areas. This has helped to see some of the special requirements of fault management compared to areas that already use the techniques described.

Some of the problems in finding a good model of the system could be overcome by getting an RDR system underway. The knowledge needed for such a model could be captured in the tree so that the engineer could know what was required of the system.

Previous Contents Next