Creating a way of knowing that the rules had reached a specified goal

To be able to breakdown the list of rules fired into branches of possible equipment options it is necessary to know when the end of branch is

e n a p ter b - r .L .u .r . u e v e io p m e n t reached. This is achieved by forward chaining to a goal so that the last rule is known, which will always be called 'Goal'. This allows the system to prune branches which are not attached to the decision tree representing the current plant layout being reviewed. In the decision tree shown below Rulen+1, Rulen+2 and Rulex are the rules fired from the facts ( slots ) asserted. Only branches which are attached to the root GOAL are options which can be applied to the current situation. Updating the related rules class takes between 5 - 1 0 minutes, depending on the type of computer used.

The rule which provides the root of the current tree is shown in figure 6.9.

Current Decision Tree

pruned branch w

u , e n+1 R u , e n*2 ^ R u , e *

\ . /

1

GOAL

Figure 6.9

Figure 6.10 shows the rule 'Goal' used as a root for the current decision tree.

cn a p ter b - r .L .u .r . u e v e io p m e n t

U pdate Edit S earch Options

Patterns: Priority:

0

If: PlantEquipment:AlferationCajiBe U= Selected Or PlantEquipmen

Then: _{

AppendToLisi( RiuiRuleLists:RulesFired, Goal); PlantEquipmeni:Goal = Achieved;

};

Comment Goal - Explanation

u 3

ill

Figure 6.10

6.2.7 U nderstanding the exact way in which the rules fired

Kappa-Pc has four different modes of Forward Chaining SELECTIVE, DEPTHFIRST, BREADTHFIRST and BESTFIRST. Each mode has different approaches for deciding which rules they evaluate next, explained below:

• SELECTIVE adds newly identified rules to the agenda according to priority. Without knowing this priority it makes it very difficult to determine which rules each rule identified.

• DEPTHFIRST evaluates each new assertion fully, i.e. an exhaustive strategy before backtracking and evaluating the next assertion, all new

Chapter b - r .L .u .r . u e v e io p m e n t assertions are added at the beginning of the agenda. The next rule could then check if it is related to any part of previous branch. If true it can then be grafted onto the appropriate stump and the branch continued.

• BREADTHFIRST is also exhaustive but adds new assertions at the end of the agenda. Without knowing the current rules on the agenda it becomes difficult to unravel why each rule was fired.

• BESTFIRST mixes newly identified rules into the agenda according to their priority. This causes similar problems as already discussed in the SELECTIVE strategy.

Any of the approaches would have achieved the same end using Forward chaining, but DEPTHFIRST was the simplest to decompose. The addition of new slots to the top of the agenda aids the process of identifying exactly where the branches occur, using the list RulesFired, in the decision process. Knowing the position of the branch points allows the system to identify complete linear routes down a branch. Each branch, constituted by rules, is then stored in its own list.

Figure 6.11 shows how a typical part of the list RulesFired can be used to create a current decision tree. With the use of the rule 'Goal' the list is split up.

^ napter o - r .L .u .r . u e v e io p m e n t List: R ulel Rule2 R ulel Rule3 Rule2 Rule4

M S tandS houldB ellsed Goal

Rule3 Rule4

M S tandS houldB ellsed EncoPanelsC anB eU sed

E ncoP anelsC anB ellsed

Goal Goal

Figure 6.11

Each of these branches will be stored in their own list. These lists would contain

- Listl: Rulel, Rule2, MStandShouldBellsed, Goal - List2: Rule3, Rule4, EncoPanelsCanBeUsed, Goal

6.2.8 Being able to check that the rules in a specific branch were related to each other

As part of the process of pruning unwanted branches the system has to check that the sequence of rules which represent a branch are related; i.e. the rule in a sequence is related to the preceding and following rules. Kappa-Pc provides this capability as part of its toolkit. The flaw with this tool is that it can only be used by the user and not be integrated programatically. This resulted in the writing of a system which could check the relations of specified rules.

The class RelatedRules was created to deal the process of checking whether two rules were related to each other. This class repeats information stored in the rules. Each instance, in the class, stores the name of the rule it has data on, the pattern of the rule, the object & slots referred in the IF part of the rule and the object & slots referred to in the THEN part of the rule.

cn a p ter b - r .L .u .r . u e v e io p m e n t The instances of the class RelatedRules are created programatically. This is done by writing all rules to temporary file and then integrating the file to create one instance per rule. The rule name of the current rule in the temporary file is stored in a slot, in the current instance, called RuleName. Similarly the pattern is stored in a slot called Pattern; at present the system makes the assumption that there is only one pattern per rule, which may be incorrect in the future. Then values of the objects and slots, from the IF., and THEN., components of the rule, are stored in lists ( multi-valued slots ). The Pattern is then used to replace each occurrence of the pattern variable with a set of object and slot pairs for all plant options.

Checking the relationship of two rules is then achieved by sending a message to the object RelatedRules, passing arguments detailing the names of the rules to be checked. Argument rulel is the preceding rule to the current rule2. The process of determining if they are related is shown in Figure 6.12.

After determining if the rules are related, the system is able to determine where one branch finishes and another starts. Without this facility it would be impossible to generate an accurate runtime decision tree.

R elate d

Chapter b - r .L .u .r . u e v e io p m e n t

A rguem ents

ru le l, rule.2 U se all of the _{instances of} R elatedR ules U se all of the instances of R elatedR ules S et slot R elated to FALSE no m ore instances no m ore instances instance _instance C om pare slot RuleN am e in "instance" with rulel C om pare slot RuleN am e in "instance" with rule2 A T _{A T}

the sam e the sam e

S et slot Rule2 to "instance" S et slot R ulel to "instance" U se the list IfText in the object n am ed in slot Rule2 not a m em ber S et slot R elated to TRUE a m em ber

C heck if new item is a m em ber of list ThenText in the object nam ed in slot R ulel no m ore item s n ew jtem s R eturn the value of slot R elated Figure 6.12

6.2.9 Producing an understandable explanation for why the rule has fired To use the system's presentation of the rules as explanations would be confusing. This is because the rules written in the system are not written using an English type format. This meant that an English interpretation of the rule had to be recorded elsewhere in the system. The logical place for this was in the rule comment facility. It could then be referenced by the system and presented in an appropriate format, with complete branch becoming a text block in the explanation window ( See Figure 6.13 ).