Chapter 9 Future Work
9.1 Building a Multiple Conclusion tree
This was one of the major limitations on providing a good
demonstration of the rules base in a telecommunications situation.
The single conclusion model is adequate for a small scale
demonstration of a single fault. However, there is seldom only
one single fault present in a telecommunications network. In a
single conclusion tree each combination of faults needs to be
represented as a compound conclusion.
As explained in chapter 6, a multiple conclusion tree
helps eliminate some of the repetition involved in representing
every combination of faults as compound conclusions. More recent
work on compressing MCRDRs automatically is looking promising
[Suryanto etal., 1999].
9.2 Storing the trees and alarm sets
This is something I could have used in my code. A way to write the
modified trees to file. This is a fairly low key sort of improvement.
It should be pretty straight forward.
The code in Example.java is very cumbersome. It all could have
been averted by storing the examples in a text file. My code
does help modify the tree easily, but if you can't store the modifications
after the program stops then its not much good.
9.3 Modelling a telecommunications network
The work done in physiological cases suggests that qualitative modelling
is the way to go. This has the advantage of being able to cope with
incomplete knowledge about how the network really works. Quantitative
details about the mechanisms involved is not necessary.
The model will build on what is already known about the network topology.
Different layers may be needed to make the network easier to see.
The qualitative links will need some `inside knowledge' as to what
goes wrong in a telecommunications network. This part is difficult to
obtain, but could be eased by taking a simplified view of things.
Once the model is satisfactory then the next step is to use it to
simulate the generation of alarms in the network. See section
7.2. It is not necessary to extract every possible
permutation (although this would be good). This is to provide a
starting point for a rules base.
9.4 Designing the user interface for the correlator
This would be the icing on the cake. The problems encountered in
a conventional rules-based system, which require extra software
and debugging tools, would be circumvented by a system that was
reliable and easy to maintain.
The RDR concepts make it possible to reduce the complexity of
adding rules to a multiple choice format. There are
existing RDR implementations of interactive rules definition
available for demonstrations.
9.5 Using topology information
It would be an interesting task to adapt the usual rules-base
interface to the telecommunications field. The question of
using the topology information comes up here.
The topology information in a RDR rules tree would be rather
implicitly defined. It may be possible to somehow open up
this information. The work in [Kumsy, 2000] uses Remote Method
Invocation to call the information from the topology manager to
the correlator. His work hard coded the rules, but since they called
to the topology, changes in topology would effectively change the rules.
Of course the topology information can be used to start off the rules
base, so there must be a way to use it in incrementally adding to
the knowledge base. It would be a great shortcut if, on the addition
of a new subnetwork, somehow the rules could be updated in one go,
rather than waiting for each new case to surface.