Chapter 5 Production Rules

This chapter looks at the most common form of knowledge based system, the production system. Section 5.1 describes the ILOG rules shell. Section 5.2 describes how the rules operate at runtime. Section 5.3 runs through how production rules are maintained.

5.1 ILOG Rules

ILOG Rules is a good example of a Rules based system using a production rules plus objects to represent knowledge. The complexities that can be found in a rules base can be demonstrated here.

The client writes the code to represent objects just like with a conventional program. The ILOG syntax is just for writing rules. Java can also be used within rules, maximising the flexibility.

To add rules the user must code them in. The ILOG language is written to facilitate this. The language is for writing rules and nothing else. Everything is written as part of a rule. Each rule is split into condition and action in the form:


    IF: condition1
            AND: condition2
            ->
            THEN: action

or in ILOG syntax:


    (defrule Name_Of_Rule default
            (something = some_condition)
            (something_else = some_other_condition)
            ->
            (do_something to_something)
            )

5.2 In action

The inference engine in Production systems during runtime consists of a working memory, where all the managed objects under scrutiny are held and an agenda, where all the rules that are eligible to be fired are kept. In Figure 5.1 we see how these two form the context in which the problem is solved.

Figure 5.1: The context of a production systems inferencing engine

5.2.1 Working Memory

In an alarm correlator all the current alarms that are under scrutiny have to be held in memory. In production systems such as OPS-5, working memory is the place where these objects are stored.

As in most object oriented terminology, objects are instances of classes. Each object has certain attributes proper to it. An alarm object is an instance of the class Alarm. It has attributes such as a severity, an object ID (identifying the source of the alarm), an alarm ID (identifying the type of alarm) and a time stamp.

These attributes are used to match them to rules. The rules may act to generate conclusions based on the working memory, or decide on some course of action. The rules may also act directly on the objects in working memory. This may change the context leading to new rules being activated.

When an object it placed in working memory, it is said to be asserted. When it is removed, it is said to be retracted. The attributes of any working memory elements can also be modified. So, not only do we have the input attributes, but also the inferred attributes generated by the rules. See Figure 5.2.

Figure 5.2: Attributes and Conclusions

This makes the scene a little more unpredictable. If there is a mistake in the inferred attributes it is harder to track down.

5.2.2 The Agenda

There needs to be some structure in the rules. In systems where the number of rules can reach the thousands, it would be impossible to manage an homogeneous mass of individual rules. OPS-5 [Cooper and Wogrin, 1988] programmers group rules into subtasks or rule clusters. Then, instead of firing individual rules, a set of rules can be activated for a particular situation.

The set of active rules comprises all the rules whose conditions are satisfied by the objects in working memory. The decision of which rule should be fired at any time is a matter of conflict resolution. There are different algorithms available.

One way to fix the order in which rules are fired is rank them by priority. The most important ones are labelled so that they will take precedence over the lesser rules. In ILOG rules [Inc., 1997] there is available a scale of rankings from 1 to 100.

It helps if we consider for a minute the two types of knowledge. These are declarative knowledge and procedural knowledge. The first deals with facts, which are easy to deal with in single rules. The latter deals with procedures, or the way facts are used. Procedural knowledge is harder to represent in single rules. Take for example, cleaning potatoes. The process is fairly simple:

Take the potatoes out of the cupboard
Rinse under water
Scrub to remove dirt
Peel if desired
Leave to dry

In a rules system this could be dealt with in a call to an external subroutine. If you were keeping strictly in the rules structure, then the rules might look like this:

If clean potatoes are desired, move the potatoes from the cupboard to the sink.
If there are potatoes in the sink, and clean potatoes are desired, rinse the potatoes under water.
If there are wet potatoes in the sink, and clean potatoes are desired, scrub the potatoes.
If you are scrubbing the potatoes, and there is no dirt left on the potatoes, stop scrubbing.
If peeled potatoes are desired, peel the potatoes.
If potatoes are clean and if potatoes are wet, leave to dry.

The rules system is meant to avoid being strictly sequential, so there needs to be another way to keep the order of operations right. This can be done by adding attributes to the objects. In the case of potatoes we add the attribute for `wetness' or `dryness' as well as `dirty' or `clean'. We might also need an attribute for `has skin'.

These rules are only to be applied in a certain context. Adding these extra attributes serves to narrow down the context of the problem.

Of course routines like this can and should be implemented outside the rules structure. ILOG rules is designed to be integrated within usual JAVA programming. The problem arises with borderline cases where there is a trade off to be made. Implementing within rules makes the code more usable for different situations. Implementing outside the rules makes sure the program runs for that particular context.

5.3 Fixing the Rules

Debugging tools are available with most rules-based expert system shells. These involve traces to show which rules were fired and searches of the rules-base. To check that the system works there is usually some sort of test input that covers enough of the possible cases to give some confidence that the system works.

There are two cases, correcting rules that have misfired and adding new knowledge. Misfired rules can be tracked down using the rule trace. It is safer not to modify existing rules too much, since such modifications could have unexpected repurcussions. In a system where much time and effort has gone into getting the knowledge base to work, it could be hard to tell what parts of a rule can be altered without affecting cases that are already handled correctly. Usually new conditions are added to clarify rules. Adding new knowledge is a similar task. It is useful to know the similar rules from the knowledge base before embarking on a whole new work.

In the Garvan-ES1 system [Compton etal., 1989] rules traces were used in tracking down misfired rules. It is not so hard to find the rules that have fired, when they should not. The problem is more tracking down the rules that should have fired. There were search tools for sifting through the database, looking for a text string. Knowing the relevant rules allows the programmer to make the new rule specific enough not to pick up any existing cases. There could also be an existing rule that could be broadened to cover the new knowledge.

Keeping a database of test cases is important when fixing rules. Although the rules concept is designed to be modular, there can be interdependencies as in conventional programming. To be sure that the changes have not invalidated the existing knowledge this set of test cases can give some degree of confidence that the system still works.

5.4 Summary

Production rules are problematic, in that they are difficult to maintain and sometimes they behave unexpectedly. Extra work is needed to ensure consistency and accuracy. Although production rules are designed to be modular, in their separation from the inferencing engine, there are interdependencies that make it difficult to add, remove and reuse rules.