rather than checking every rule to determine which rules are matched by the WM in each recognize–act cycle, Rete maintains a list of matched rules and determines how these matches change due to the modification of the WM by the firing of a rule instantiation. The top portion of the Rete network contains chains of tests that perform the select operations. Tokens passing through these chains partially match a particular condition element and are stored in alpha-memory nodes. The alpha-memory nodes are connected to the two input nodes that find the partial binding between condition elements. Tokens with consistent variable bindings are stored in beta-memory nodes. At the end of the two input nodes are the terminal nodes, which signify that a consistent binding for a particular rule is found. The terminal nodes send the rule bindings to the conflict set. An example of a Rete network is shown in Figure 11.1.

11.2 CHENG–TSAI TIMING ANALYSIS METHODOLOGY

11.2.1 Static Analysis of Control Paths in OPS5

Several graphical representations of procedural programs have been developed for testing and debugging purposes. An intuitive representation is a physical rule flow graph. In such a graph, nodes represent rules, and an edge from node a to b implies rule b is executed immediately after rule a is executed. This graph is not appropriate for rule-based programs because the execution order of OPS5 programs cannot be determined statically. On the other hand, the control flow of rule-based programs should be thought of in terms of logical paths. A physical rule flow graph does not present the most appropriate abstraction. Another approach to represent the control paths is a causality graph. Here, too, nodes represent rules, but an edge from node a to node b implies rule a causes rule b to fire. The RHS assertions of rule a match all the LHS condition elements of rule b. This graph is not sufficient to capture all the logical paths since the LHS conditions of a rule are usually generated from the RHS actions of many rules; that is, a combination of several rules may “cause” another single rule to fire. This leads to the definition of a graph called the enable rule (ER) graph, which is adapted from [Cheng and Wang, 1990] and [Kiper, 1992]. The control information among rules in an OPS5 program is represented by the ER graph. To define the ER graph, we need to first define the state-space graph.

Definition 1. The state-space graph of an OPS5 program is a labeled directed graph G = (V, E). V is a distinct set of nodes, each of which represents a distinct set of WMEs. We say that a rule is enabled at node i if and only if its enabling condition is satisfied by the WMEs at node i. E is a set of edges, each of which denotes the firing of a rule such that an edge (i, j) connects node i to node j if and only if a rule R is enabled at node i, and firing R will modify the WM to become the set of WMEs at node j.

Definition 2. Rule a is said to potentially enable rule b if and only if there exists at least one reachable state in the state-space graph of the program where (1) the

374 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

Figure 11.2 State-space graph of an OPS5 program.

enabling condition of rule b is false, (2) the enabling condition of rule a is true, and

(3) firing rule a causes the enabling condition of rule b to become true.

Figure 11.2 shows the state-space graph of an OPS5 program. Rule r1 potentially enables rule r2, and rule r3 potentially enables rule r1. Suppose we have m different attributes in all classes, each attribute has n data items, and each WME is a unit in the WM, then we have nm possible WMEs. In the state-space graph, 2nm states would exist.

Since the state-space graph cannot be derived without running the program for all allowable initial states, we use symbolic pattern matching to determine the potentially enabling relation between rules. Rule a potentially enables rule b if and only if the symbolic form of a WME modified by the actions in rule a matches one of the enabling condition elements of rule b. Here the symbolic form represents a set of WMEs and is of the form

(classname ^attribute1 v1 ^attribute2 v2 ... ^attributen vn)

where v1, v2 . . ., and vn are either variables or constant values and each attribute can be omitted. For example, (class ^a1 3 ^a2 <x>) can be a symbolic form of the following WMEs.

Note that to determine with certainty whether a rule enables rather than potentially enables another rule, and thus determine whether the condition elements of a rule actually have a matching, would require us to know the contents of the working memory at run-time. This a priori knowledge of the WM cannot be obtained statically. Therefore, the above approximation of the potentially enabling relation is used instead. Example 1 illustrates the potentially enabling relation. Rule a potentially enables rule b because the first action of rule a creates a WME (class c ^c1 off ^c2 <x>), which symbolically matches the enabling condition (class c ^c1 <y>) of rule b. Notice, incidentally, that the second action of rule a does not match the first enabling condition (class a ^a1 <x> ^a2 off) of rule b because variable <y> ranges in <<open close>>.

Example 1. An example of a potentially enabling b.

(p a

(p b

(class_a ^a1 <x> ^a2 3)

(class_a ^a1 <x> ^a2 off)

(class_b ^b1 <x> ^b2 {<y> <<open close>>})

(class_c ^c1 <y>)

-->

-->

(make class_c ^c1 off ^c2 <x>)

(modify 1 ^a2 open))

(modify 1 ^a2 <y>))

The symbolic matching method actually detects the enabling relation by checking the attribute ranges. This information can be found by analyzing the semantics of the rules.

Definition 3. The (ER) graph of a set of rules is a labeled directed graph G = (V, E). V is a set of vertices such that there is a vertex for each rule. E is a set of edges such that an edge connects vertex a to vertex b if and only if rule a potentially enables rule b.

Note that an edge from a to b in the ER graph does not mean that rule b will fire immediately after rule a. The fact that rule b is potentially enabled only implies that the instantiation of rule b may be added to the conflict set to be fired.

The previous analysis is useful since it does not require us to know the contents of working memory that cannot be obtained statically.

11.2.2 Termination Analysis

As described in the introduction, the upper bound on a real-time expert system’s execution time cannot exceed the length of the period between two consecutive sensor input readings [Cheng et al., 1993; Chen and Cheng, 1995b]. Therefore, our goal is to determine before run-time a tight upper bound on the execution time of the expert system in every invocation following each reading of sensor input values. The first analysis step is to determine whether the expert system terminates. Since a rule-based expert system program is data-driven, it is not designed for all possible data domains. Certain input data are required to direct the control flows in the program. Many con-

376 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

trol techniques are implemented in this manner, and the absence of certain WMEs or a specific ordering of WMEs is required to generate the initial WM. If these WMEs are not present in the expected data domain, abnormal program behavior will occur, usually leading to a cycle in the program flow.

Ullman [Ullman and Van Gelder, 1988] studied recursive relations and described termination conditions in backward-chaining programs. Here, we consider the termination conditions for forward-chaining rule-based programs. We examine the ER graph of an OPS5 program to detect the termination conditions. If the OPS5 program is found not to terminate for all initial program states, the culprit conditions that cause nontermination are extracted to assist programmers in correcting the program.

Termination Detection An OPS5 program is terminating if the maximal number of its rule firings is finite. Thus the maximal number of times a rule in a terminating program can fire is also finite. A rule is said to be terminating if its number of firings is always finite. To detect program termination, we use the ER graph, which provides information about the logical paths of an OPS5 program. In particular, we use this graph to trace the control flows of the program. Because we know the potentially enabling relation between rules, we can detect if the firing of each rule in an OPS5 program can terminate. The following definitions are needed to describe the conditions under which a rule will terminate.

Definition 4. Suppose rule a potentially enables rule b. Then there is an edge from node a to node b in the ER graph. A matched condition element of rule b is one of the enabling condition elements of rule b, which may be matched by executing an action of rule a. Here, rule a is called the enabling rule of the matched condition element.

Definition 5. An unmatched condition element is one of the enabling condition elements of a rule, which cannot be matched by firing any rule.

Note that an unmatched condition can still be matched by the initial working memory.

Example 2. Matched and unmatched condition elements

(p a

(c1 ^a1 5)

(c2 ^a2 <x> ^a3 2) -->

(modify 2 ^a2 3)) (p b

(c2 ^a2 <x>)

(c3 ^a4 <x> ^a5 <y>) -->

(modify 1 ^a2 <y>))

In example 2, suppose the firing of any other rule cannot match the second condition element of rule a. In the ER graph, rule b will potentially enable rule a. The first condition element (c2 ^a2 <x>) of rule a is a matched condition element because it may be matched by firing rule b. The second condition element (c3 ^a4 <x> ^a5 <y>) of rule a is an unmatched condition element because it cannot be matched by firing other rules.

An important property of OPS5 rule-based systems is called refraction, which ensures that the same instantiation is never executed more than once. Two instantiations are considered the same if they have the same rule name and the same WMEs matching to the same condition elements.

Next, we derive a theorem to detect the termination of a program. One way to predict the termination condition is to make sure that every state in the state-space graph cannot be reached more than once. However, since it is computationally expensive to expand the whole state-space graph, we use the ER graph to detect this property.

Theorem 1. A rule r will terminate (terminate in finite firings) if one of the following conditions holds:

C0. No rule potentially enables rule r.

C1. The actions of rule r modify or remove at least one of the unmatched condition elements of rule r.

C2. The actions of rule r modify or remove at least one of the matched condition elements of rule r, and all of the enabling rules of the matched condition elements can terminate in finite firings.

C3. Every rule that enables rule r can terminate in finite firings.

Note that condition (C1) is not necessary for OPS5 rules because refraction in OPS5 prevents a rule from firing again immediately after firing once. Also, if rule r is self-enabling, condition (C2) is not satisfied.

Proof

C0. If no rule potentially enables rule r, the instantiations of rule r can be formed only from the initial WM. Since the number of WMEs in the initial WM is finite, the number of firings of rule r is also finite.

C1. Since the firing of any rule cannot match the unmatched condition elements, the only WMEs that can match the unmatched condition elements are the initial WMEs. Moreover, since the actions of rule r change the contents of these WMEs, the WMEs cannot match the unmatched condition elements again after rule r is fired. Otherwise, the unmatched condition elements will be matched by firing rule r. This contradicts the definition of unmatched condition elements. Each initial WME matching the unmatched condition element can cause rule r to fire at most once since we have a finite number of initial WMEs. Thus rule r can terminate in finite firings.

378 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

C2. Since the enabling rules of the matched condition elements can terminate in finite firings, by removing these rules the matched condition elements can be treated as unmatched condition elements. According to (C1), rule r can terminate in finite firings.

C3. All rules that enable rule r can terminate in finite firings. After these rules terminate, no other rule can trigger rule r to fire. Thus rule r can terminate as well.

Example 3. A rule can terminate in finite firings.

(p a

(c1 ^a1 1 ^a2 <x>)

(c2 ^a1 4 ^a2 <x>)

-->

(modify 2 ^a1 3))

In example 3, suppose the second condition element (c2 ^a1 4 ^a2 <x>) cannot be matched by firing any rule, including this rule itself. Then this condition element is an unmatched condition element. Suppose three WMEs are in the initial working memory matching this condition element. Then this condition element can be matched by at most three WMEs. The actions of rule a modify these three WMEs when rule a fires. As a result, rule a can fire at most three times.

Example 4. Two rules with a cycle embedded.

(p p1

(class1 ^a11 { <x> <> 1 } ) (class2 ^a21 <y>)

-->

(modify 1 ^a11 <y>)) (p p2

(class1 ^a11 <x>)

(class2 ^a21 { <x> << 2 3 >> } ^a22 <y>) -->

(modify 1 ^a11 <y>))

Example 5. Example 4 with modified variables.

(p p1

(class1 ^a11 { <x-1> <> 1 } ) (class2 ^a21 <y-1>)

-->

(modify 1 ^a11 <y-1>)) (p p2

(class1 ^a11 <x-2>)

(class2 ^a21 { <x-2> << 2 3 >> } ^a22 <y-2>) -->

(modify 1 ^a11 <y-2>))

Enabling Conditions of a Cycle We use the above termination-detection algorithm to determine whether an OPS5 program always terminates in bounded time by inspecting the ER graph of the program. If no cycle exists in the ER graph or every cycle can be broken, that is, each cycle can be exited as a result of the firing of a rule that disables one or more LHSs of rules in this cycle [Cheng et al., 1993], then the firings of every rule in the OPS5 program are finite, and thus termination is detected. However, if the OPS5 program is not detected to terminate for all initial program states, then the culprit conditions that cause nontermination are extracted to assist programmers in correcting the program. This is done by inspecting the cycles with no exit conditions in the ER graph. Again, note that cycles composed entirely of rules that terminate in finite firings (and hence have exit conditions) do not need to be examined.

We now discuss the conditions under which a cyclic sequence of rule firings occurs. Suppose rules p1, p2 . . . , pn form a cycle in the ER graph, W is a set of WMEs, and W causes rules p1, p2 . . . , pn to fire in that order. If firing p1, p2 . . . , pn in that order will produce W again, then W is called an enabling condition of the cycle. We can use symbolic tracing to find W if the data of each attribute are literal. Example 4 illustrates the idea.

Rules p1 and p2 form a cycle in the ER graph. To distinguish different variables in different rules, we assign different names to variables. Thus, the program is rewritten as in example 5. A symbol table is built for each variable, which is bound according to the semantics of the enabling conditions. Here, Table A is the symbol table, where the Binding Space refers to the restrictions imposed by the semantics of the constraints on the variables from the rule conditions.

In order to derive an acceptable enabling condition of the cycle, the algorithm below first postulates it to be the set of all enabling conditions of the rules of the cycle. Then it removes redundant conditions to arrive at a condition suitable for examination by the programmer, to see if the cycle should be broken by introducing further conditions into the LHSs of the rule. Thus W is

(class1 ^a11 <x-1>) (class2 ^a21 <y-1>) (class1 ^a11 <x-2>)

(class2 ^a21 <x-2> ^a22 <y-2>)

Each variable occurs once in the symbol table.

Now we trace the execution by firing p1 first; p1 enables p2 by matching the first condition. Since the first condition of rule p2 can be generated from rule p1, it can

380 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

be removed from W . Variable x-2 is now replaced by y-1. W is

(class1 ^a11 <x-1>)

(class2 ^a21 <y-1>)

(class2 ^a21 <y-1> ^a22 <y-2>)

Since x-2 is bound with 2 and 3, y-1 is bound with the same items. The symbol table is modified (Table B). In general, the conjunction of the binding-space restrictions is substituted.

After executing the action of rule p2, W is now

(class1 ^a11 <y-2>)

(class2 ^a21 <y-1>)

(class2 ^a21 <y-1> ^a22 <y-2>)

To make this WM trigger p1 and p2 in that order again, the WME (class1 ^a11 must match the first condition of p1. Thus variable y-2 is bound with the

binding space of x-1. Table C is the symbol table. W is

(class1 ^a11 <y-2>) (class2 ^a21 <y-1>)

(class2 ^a21 <y-1> ^a22 <y-2>) where y-2<>1 and y-1=2,3

The detailed algorithm for detecting the enabling conditions of cycles is described next.

Algorithm 1. The detection of enabling conditions of cycles.

Premise: The data domain of each attribute is literal.

Purpose: Rules p1, p2 . . . , pn form a cycle in the ER graph. Find a set of WMEs, W , that fires p1, p2 . . . , pn in that order such that these firings cannot terminate in finite firings.

1.Assign different names to the variables in different rules.

2.Initialize W to the set of all enabling conditions of p1, p2 . . . , pn .

3.Build a symbol table for variables. Each variable’s binding set is limited to the restriction specified in the rule enabling conditions.

4.Simulate the firing of p1, p2 . . . , pn in that order.

Each enabling condition of rule pi is matched from the initial WM, unless it can be generated from rule pi−1.

If the enabling condition element w of rule pi can be generated by firing pi−1, then remove w from W . Substitute pi−1’s variables vi−1 for corresponding variables vi in pi .

Modify vi−1’s binding space in the symbol table to the conjunction of the restrictions on vi and vi−1.

5.If p1’s enabling condition elements can be generated by pn , substitute pn ’s variables vn for corresponding variables v1 in p1. Modify vn ’s binding space in the symbol table.

6. In steps 4 and 5, while substituting pi−1’s variables for pi ’s variables, check the intersection of the binding spaces of pi ’s and pi−1’s variables. If the intersection is empty, then terminate the algorithm: the loops terminates in finite firings.

7.Suppose Wn is the WM after firing p1, p2 . . . , pn . If Wn can match W , then W is an enabling condition of the cycle p1, p2 . . . , pn .

Note that certain conditions are subsets of others, as explained in section 4.4.

Prevention of Cycles If the OPS5 program is not detected to terminate for all initial program states, then the culprit conditions that cause nontermination are used to assist programmers in correcting the program. After detecting the enabling conditions, W , of a cycle, we add rule r , with W as the enabling conditions of r . By doing so, once the working memory has the WMEs matching the enabling conditions of a cycle, the control flow can be switched from the cycle to r . In example 4, r is

(p loop-rule1

(class1 ^a11 { <y-2> <>1 } ) (class2 ^a21 { <y-1> << 2 3 >> } ) (class2 ^a21 <y-1> ^a22 <y-2>)

-->

action ...

If the cycle is not an infinite loop or desirable (e.g., in periodic control and monitoring applications), we may not want to add rule r . The action of r , determined by the application, depends on how the application needs to react when the program flow is going to enter a cycle. The simplest way to escape from the cycles is to halt.

To ensure the program flow switches out of the cycles, the extra rules r should have higher priorities than the regular ones. To achieve this goal, we use the MEA control strategy and modify the enabling conditions of each regular rule.

At the beginning of the program, two WMEs are added to the WM and the MEA strategy is enforced.

(startup

......

(strategy mea)

(make control ^rule regular) (make control ^rule extra))

The condition (control ^rule regular) is added to each regular rule as the first enabling condition element. (control ^rule extra) is added to each extra rule as the first enabling condition element too. Since the MEA strategy is enforced, the order of instantiations is based on the recency of the first time tag. The recency of the condition (control ^rule regular) is lower than that of the condition (control ^rule

382 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

extra). Thus, the instantiations of the extra rules are chosen for execution earlier than those of the regular rules. Example 6 is the modified result of example 4.

Example 6. The modified result of example 4.

(startup (strategy mea)

(make control ^rule regular) (make control ^rule extra))

(p p1

(control ^rule regular) (class1 ^a11 { <x> <> 1 } ) (class2 ^a21 <y>)

-->

(modify 2 ^a11 <y>)) (p p2

(control ^rule regular) (class1 ^a11 <x>)

(class2 ^a21 { <x> << 2 3 >> } ^a22 <y>) -->

(modify 2 ^a11 <y>)) (p loop-rule1

(control ^rule extra) (class1 ^a11 { <y-2> <> 1 } )

(class2 ^a21 { <y-1> << 2 3 >> } ) (class2 ^a21 <y-1> ^a22 <y-2>)

--> (halt))

Usually, a cycle is not expected for an application. Thus, once the entrance of a cycle is detected, the program can be abandoned. Hence, after all cycles in the ER graph are found, the program is guaranteed to terminate. In example 6, the action of the extra rule can be

(remove 2 3 4)

Since the WMEs that match the enabling condition of a cycle are removed, the instantiations in the cycle are also removed. Then, other instantiations in the agenda can be triggered to fire.

Another example of program modification is shown in the analysis of the Space Shuttle Orbital Maneuvering and Reaction Control Systems’ Valve and Switch Classification Expert System (OMS) [Barry and Lowe, 1990]. A non-terminating rule is modified in order to break a cycle, thus guaranteeing the termination of this rule and the program.

Program Refinement Due to its complexity, the ER graph usually contains many cycles. Furthermore, even for a single cycle, more than one enabling condition may exist to trigger the cycle. This leads to a large number of extra rules in the modified programs and thus reduces their run-time performance. To tackle this problem, redundant conditions and rules must be removed after the modification.

Redundant Conditions In algorithm 1, after symbolic tracing, some variables will be substituted and the binding spaces may be changed too. This may cause subset relationships among the enabling condition elements of a cycle. In an extra rule, if condition element Ci is a subset of condition element C j , then C j can be omitted to simplify the enabling condition. In example 6, the condition

^a22 <y-2>) is a subset of (class2 ^a21 <y-1>). Hence, (class2 ^a21 <y-1>) can be

omitted.

(p loop-rule1

(control ^rule extra) (class1 ^a11 { <y-2> <>1 } )

; (class2 ^a21 { <y-1> << 2 3 >> } ) ;omitted (class2 ^a21 <y-1> << 2 3 >> ^a22 <y-2>)

--> (halt))

Redundant Extra Rules In certain situations, we can remove some extra rules if the actions of these extra rules can be ignored. For example, extra rules with action “halt” or “print” can be ignored. Since each cycle is analyzed independently, the extra rules correspond to cycles with different enabling conditions. If the enabling condition of rule ri is a subset of the enabling condition of rule r j , then rule ri can be removed since firing ri will definitely fire r j . The cycling information of rule r j contains that of rule ri . Thus, it is sufficient to just provide more general information. In many cases, if the set of nodes Pi which forms a cycle Ci is a subset of the set Pj which forms a cycle C j , then the enabling condition of C j is a subset of Ci ’s enabling condition. The situation becomes apparent when the cycle consists of many nodes. Hence, we can expect to remove the extra rules whose enabling conditions are derived from large cycles.

In example 7, the first and third condition elements of rule 1 are identical to the first and fourth condition elements, respectively, of rule 3. WMEs matching the second condition element of rule 3 also match the second condition element of rule 1, but not vice versa. The third condition element of rule 3 is not in rule 1, making the LHS of rule 3 more restrictive than the LHS of rule 1. Thus the enabling condition of rule 3 is a subset of the enabling condition of rule 1. Similarly, the first, second, and fourth condition elements of rule 2 are identical to the first, second, and fifth condition elements, respectively, of rule 4. WMEs matching the third condition element of rule 4 also match the third condition element of rule 2, but not vice versa. The fourth condition element of rule 4 is not in rule 2, making the LHS of rule 4 more restrictive than the LHS of rule 2. Thus the enabling condition of rule 4 is a subset of the enabling condition of rule 2. Therefore, rules 3 and 4 can be removed.

Example 7. Redundant rules.

(p 1

(control ^rule extra)

(class1 ^a13 { <y-1> <> 1 } )

(class2 ^a22 <y-1>)

384 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

-->

action ...

(p 2

(control ^rule extra) (class1 ^a13 { <x-1> <> 1 } ) (class2 ^a22 <y-1>)

(class4 ^a41 2 ^a42 <x-3>)

-->

(class1 ^a13 { <y-1> << 2 3 >> } ) (class4 ^a41 { <y-4> <> 1 } ^a42 <y-1>) (class2 ^a22 <y-1>)

(control ^rule extra) (class1 ^a13 { <x-1> <> 1} )

(class2 ^a22 { <y-1> << 2 3 >> } (class4 ^a41 <y-4> ^a42 <y-1>) (class4 ^a41 2 ^a42 <x-3>)

-->

action ...

An Example Now we apply our technique to a complete example.

Example 8. An OPS5 program with cycles embedded in the ER graph.

(p p1

(class1 ^a13 { <x> <> 1 } ) (class2 ^a22 <y>)

-->

(modify 1 ^a13 <y>)) (p p2

(class3 ^a31 <x> ^a32 <y>) (class4 ^a41 <x> ^a42 <y>)

-->

(modify 1 ^a31 2 ^a32 <x>)

(make class1 ^a11 1 ^a12 2 ^a13 3)) (p p3

(class1 ^a11 <x> ^a12 <y>) (class4 ^a41 2 ^a42 <x>)

-->

(modify 1 ^a11 <y>)) (p p4

(class1 ^a13 { <x> << 2 3 >> } ) (class4 ^a41 <y> ^a42 <x>)

-->

(modify 1 ^a13 <y>))

(p p5

(class1 ^a11 <x>) (class3 ^a31 1 ^a32 <y>)

-->

(modify 2 ^a31 2 ^a32 <x>) (make class2 ^a21 2 ^a22 3))

First, we detect if the program can terminate in finite firings. We find rule p5 can terminate since it contains an unmatched condition. Next, the enabling condition of each cycle is found and extra rules are added to the program (Example 9). Here, the actions of all extra rules are halt. Hence, we remove the redundant rules without considering the interference among the extra rules. After removing the redundant rules, the number of extra rules is reduced from 16 to 9.

Example 9. Extra rules of example 8 (including redundant rules).

Implementation and Complexity For an OPS5 program with n rules, potentially O(n!) cycles are embedded in the ER graph. However, we found that cycles do not contain a large number of nodes in actual real-time expert systems we examined. If it is detected that no path contains m nodes in the ER graph, there is no need to test cycles with more than m nodes. This reduces both the computational complexity and the memory space.

To further reduce the computation time in identifying cycles, we store information about rules that do not form a path in certain orders. This non-path is called an impossible path. If there is no path consisting of rules p1, p2 . . . , pn executing in this order, then there is no cycle containing these rules. Thus, we do not need to examine the cycles with an embedded path consisting of the rules in the above order (an impossible path). Since the ER graph actually represents all possible paths between two rules, we can construct a linear list to store all impossible paths with more than two rules. Since storage of these impossible paths requires space, we are in fact trading space with time. In our tool, we store impossible paths with up to nine nodes.

This tool has been implemented on a DEC 5000/240 workstation running RISC/Ultrix. Two real-world expert systems are examined. Ongoing work applies this tool to more actual and synthetic OPS5 expert systems in order to evaluate the run-time performance and scalability of this tool.

Industrial Example: Experiment on the ISA Expert System The purpose of the Integrated Status Assessment (ISA) Expert System [Marsh, 1988] is to determine the faulty components in a network. It contains 15 production rules and some Lisp function definitions. A component can be either an entity (node) or a relationship (link). A relationship is a directed edge connecting two entities. Components are in one of three states: nominal, suspect, or failed. A failed entity can be replaced by an available backup entity. This expert system makes use of simple strategies to trace failed components in a network.

One rule is found to terminate in a finite number of firings. One hundred twenty five cycles are detected. After removing the redundant rules, four cycles remain.

Industrial Example: Experiment on the OMS Expert System The purpose of the OMS Expert System [Barry and Lowe, 1990] is to classify setting valves and switches. It recognizes special patterns of settings and creates intermediate assertions. With settings and new assertions, it infers more and creates more assertions until no more assertions can be derived. Finally, the settings and assertions are compared with the expected values supplied by the user. All matches or mismatches are reported.

No rule is reported to terminate in finite firings. However, after checking all possible paths, only one cycle is found. The enabling condition of the cycle, shown below, is in rule loop-rule1.

(control ^rule extra)

(device ^mode {<x-4> <> void } ^domain <y-4>

^compnt <v-4> ^desc {<w-4> << closed open >>} ) (valve_groups ^vtype <v-4> ^valve_a <v-4> ^valve_b <v-4> )