Chapter 4 Expert Systems

The techniques we have already mentioned under alarm correlation were developed for expert systems. Some of the problems peculiar to such systems will help understand some of the issues at work in forming a good alarm correlator. Section 4.1 describes expert systems in general, giving some of their strengths and weaknesses. Section 4.2 explains the structure of an expert system and how they are put together. The challenges faced by expert systems are described in section 4.3. Lastly the issue of usability of expert systems is illustrated in section 4.4.

4.1 What is an expert system?

Expert systems are hard to define. They all aim to simulate a human expert in some way. They take a narrow field and build up the knowledge needed to solve problems in their area. They can be used to increase productivity by making faster, more accurate decisions, to preserve the skills which come from experience and to allow other operators to share the expertise which comes from more experience.

These systems have been very successful in areas where a large volume of knowledge is needed in a narrow area. The pioneering work featured a program called DENDRAL(1971) which was used to find all the possible molecular structures of a chemical from its mass spectrogram. Another work was MYCIN(1976), a medical diagnostic program for bacterial infections of the blood. These were successful because they had well defined areas to solve, they had an expert willing to assist in the development and they had dedicated programmers to implement the program.

4.2 How do you build an expert system?

There are various ways to construct an expert system. Each gives different emphasis to different parts of a general structure.

the knowledge base
the inference engine
the mechanism to acquire knowledge
the user interface

Each of these components affects the others. The way that knowledge is represented affects how easily it can be used to draw inferences as well as how easy it is to acquire new knowledge. The inferences produced by the inference engine must be useful to the user at the interface. The interface may also be used for finding out how the decision was reached, so it may need to interact with the inference engine too.

In Figure 4.1 the circle encompasses the `working guts' of the expert system. The knowledge acquisition is there to add to the knowledge base, perhaps separate from run time. The user interface is necessary to take in the problem set and display the conclusions. This may also conduct queries into why the system gave that particular conclusion. Ideally the process of knowledge acquisition could also be done through a user interface. Otherwise it requires the usual programming - debugging cycle.

Figure 4.1: Expert System Architecture

4.2.1 Programming platform

Any language can be used, since an expert system is just another technique for building computer software. Some computing languages are particularly suited to developing expert systems.

The two most commonly used in Artificial Intelligence PROLOG are PROLOG and LISP LISP. The first is designed to handle logic. Each command states an interrelationship between two things. Gradually a database of information is built up. This is used as the knowledge base. The database can be queried. LISP is based on processing lists. The data type is very flexible and uses functions in a more mathematical format.

Instead of starting from scratch there are shells available for developing expert systems. The most famousEMYCIN example is EMYCIN which was derived from MYCIN. MYCINThis is basically MYCIN without the knowledge base. This is good if the knowledge one wishes to add fits into the space left by the old knowledge base. If the new knowledge has to be contorted to fit, then the system will be problematic to use and maintain.

The next level of abstraction are environments. ILOGILOG is one of these. They not only have an inferencing engine but also tools for editing, testing and debugging. They may have their own language and data structures for storing knowledge.

4.3 The Challenges

4.3.1 Knowledge Acquisition

knowledge acquisition Having an extensive and accurate knowledge base is difficult to achieve. One hurdle is the fact that it is usually a computer programmer who is putting in the information, rather than the expert in the field.

Communication is vital in this process.There needs to be cross checking to clarify ambiguities and resolve conflicting ideas. All this takes time, especially when human error is factored in. There are techniques for sorting out the information that the expert can give during interviews.

repertory grids Repertory grids are one of these techniques. They work on finding the differences between cases. [Hart, 1992] There is a process structured questions, ranks then calculations to find the percentage differences. The cases with similarities are clustered into groups, then you have an easy step to turn this into a decision tree. Even if this process is not followed to the letter it can help focus minds on defining the task.

Involving the domain expert in the process of knowledge acquisition is important. There is an important element of social skills needed to ensure that the expert is not too reluctant to give the time and effort to define a good rules base. The programmer must be wary not to succumb to the temptation to assume too much. Hubris is the mistaken pride of greek myths, nemesis is the certain revenge of the gods. Too much hubris can spell disaster further down the track when it turns out that the structure of the system needs major alterations to accommodate variables that should have been known from the beginning.

Involving the expert also ensures some degree of acceptance of the system once it is finished. The company using the system will be more inclined to put in the resources to keep the system up to date if the expert can act as an advocate.

4.3.2 Knowledge Maintenance

knowledge maintenance In software there is one sure thing. Any working system will need to be changed [Menzies and Debenham, 2000]. It is not unreasonable to say that there is always going to be something that needs to be fixed at a later date. This is not always due to a mistake during the knowledge acquisition stage. It may be due to a change in the problem space. In a telecommunication network this is particularly the case with the changes in the network as parts are renovated.

Adding rules seems a straightforward task, but there will be interdependencies between the rules and unforseen consequences. There are packages available for checking the system for coherence. Such is the Truth Maintenance System (TMS) used in Ilog Rules. TMS uses justification weightings to keep track of rule dependencies. Another notable one is QCM (Qualitative Compartmental Models) [Menzies and Compton, 1997] which envision hypotheses in the form of qualitative models and then test these out.

Another way is to construct the knowledge base so that conflicts are prevented and, if they do occur, are easy to remedy. This is one of the advantages of Ripple Down Rules in chapter 6.

4.4 Usability

usability Programming, even using a language like ILOG Rules is very demanding. For an end user the task of rewriting code and debugging is prohibitive.

The main two factors to bear in mind when designing a system are to:

Make it easy
Make it work

4.4.1 Microsoft Outlook

Figure 4.2: The first page of MS Outlook's Rules Wizard

As with so many software packages, the user is provided with a `wizard' to help configure the program. Successive screens are displayed to walk the user through the process of specifying rules for the email browser.

A list of rules in order of priority. A natural language description of each rule can be viewed when the rule is highlighted. Tick boxes allow the user to deactivate or activate rules. The order of rules can also be shuffled.
To start making a new rule the wizard asks you to choose a type of rule. The types are broad categories like check messages after arrival.
The conditions part of the rule is set. A list of templates for conditions is shown. Tick boxes select which conditions are relevant. Variables in the conditions are stipulated by either typing or browsing as appropriate.
The action is set. Again a list of template actions is shown. The actions are specified just like the conditions.
Exceptions to the rule are set. These form negative conditions on the rule.
The last screen shows the complete rule. A label is required for the rule, which is typed in. The choice is given whether to activate the rule, ready for the next time email arrives, to activate the rule on the existing email or to leave the rule dormant.

This sort of set up is too simplistic for the Telecommunications network. Email typically does not exceed 100 messages per day. Fault alarms can reach astronomical numbers during alarm storms. The email system has a limited number of users. Telecommunication networks can be huge. Scrolling through a list of network elements would be ridiculous. Also the domain for fault management is not always as clear cut as email preferences.

4.5 Summary

The existing rules based inferencing engine can be seen as an embedded expert system. The interface between the user and the expert system is hidden, since the user does not see the incoming alarms and the processing, but only a filtered set of alarms.

Many of the problems faced in keeping the existing inferencing engine relevant to the users can be seen mirrored in the experiences of expert systems from other fields.