Thời gian thực - hệ thống P11

CHAPTER 11 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS As rule-based expert systems become widely adopted in new application domains such as real-time systems, ensuring that they meet stringent timing constraints in these safety-critical and time-critical environments emerges as a challenging prob- lem. As described in detail in chapter 10, in these systems, a change in the envi- ronment may trigger a number of rule firings to compute an appropriate response. If the computation takes too long, the expert system may not have sufficient time to respond to the ongoing changes in the environment, making the result of the com- putation useless or even harmful to the system being monitored or controlled. To evaluate and control the performance of a real-time expert system, it is necessary to relate the quality of a response computed by the expert system to the time available to compute it. Even in a case where response time is not a major concern or a deadline is not imposed, the predictability is still a desired quality which may improve the resource utilization or the user productivity. For example, if the programmer has a tool to measure an upper bound on the maximal program response time, he/she will not have to guess whether the program runs into an infinite loop or the program just takes a long time to complete execution, thus avoiding unnecessary waiting for the program to complete execution or undesirable interrupting of program execution. This is particularly true for production systems whose rule firing patterns depend on initial working memory contents. Unfortunately, rule-based expert systems are computationally expensive and slow. Moreover, they are considered less predictable and analyzable because of their context-sensitive control flow and possible nondeterminism. To remedy this prob- lem, two solutions are proposed in the literature. The first is to reduce the execution time via parallelism in the matching phase and/or firing phase of the MRA [Brown- ston et al., 1986] cycle. Several approaches [Cheng, 1993b; Ishida, 1994; Kuo and 367 Real-Time Systems: Scheduling, Analysis, and Verification. Albert M. K. Cheng Copyright ¶ 2002 John Wiley & Sons, Inc. ISBN: 0-471-18406-3 368 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS Moldovan, 1991; Pasik, 1992; Schmolze, 1991] have been provided to achieve this goal. The other solution is to optimize the expert system by modifying or resynthe- sizing the rule base if the response time is found to be inadequate [Zupan and Cheng, 1994a; Zupan and Cheng, 1998]. In this chapter, we present more approaches for the response-time analysis of rule-based systems. In particular, we study the timing properties of programs written in the predicate-logic-based OPS5 language [Forgy, 1981] (and other OPS5-style languages), which is not designed for real-time purposes although it has been widely adopted in practice. In chapter 10, we introduced the propositional-logic-based rule- based language EQL (equational rule-based language), for real-time applications. EQL is a simple, rule-based language with well-defined semantics. It has been used to program a number of practical real-time applications. OPS5 exhibits an incremental increase in expressiveness over MRL [Wang, Mok, and Cheng, 1990; Wang, 1990a] but it is not as complex as more recent object- oriented rule-based languages. OPS5 has been successfully used in a variety of ap- plications [Forgy, 1985]. MRL is designed to be an extension of EQL. It includes set variables (working memories) and logical quantifiers over set variables. How- ever, MRL does not include the timing tags in its working memory, so many conflict resolution strategies, such as LEX and MEA, cannot be applied to MRL programs. It is entirely the programmer’s responsibility to guarantee that any firing sequence is a normal execution flow. Under this situation, the programmer usually needs to avoid interference among rules; otherwise, the program may be hard to debug and maintain. OPS5 has been used to implement several industrial expert systems, including MILEX (The Mitsui Real Time Expert System) and XCON/R1, which is generally considered the first commercially successful expert system [Forgy, 1985]. Our goal is to obtain a tighter bound on the execution time that is close to the real upper bound. We consider the case where an OPS5 expert-system program forms the decision module of a real-time monitoring and controlling system [Payton and Bihari, 1991]. This real-time system takes sensor input readings periodically, and the embedded expert system must produce, based on these input values and state values from previous invocations of the expert system, an output decision that ensures the safety and progress of the real-time system and its environment prior to the taking of the next sensor input values. Thus, the upper bound on the 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. To analyze the timing behavior of an OPS5 program, we first formalize a graph- ical representation of rule-based programs. This high-level data-dependency graph captures all possible logical control paths in a program. Based on this graph, we design a termination detection algorithm to determine whether an OPS5 program al- ways terminates in bounded time. If an 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. They then modify THE OPS5 LANGUAGE 369 the program to ensure program termination. Note that this modification is performed off-line, prior to the execution of the expert system, and the modified version must still satisfy the logical correctness constraints. On the other hand, if the termination of an OPS5 program is guaranteed, we proceed to determine an upper bound on its execution time. Instead of using static analysis, we build a tool to aid timing analy- sis of OPS5 expert systems. This tool generates a set of working memory elements (WMEs) which cause the program to consume maximum time. We take this set of WMEs as the initial working memory (WM) and test the program to determine the maximum execution time. In real applications, the initial WM is usually restricted to a certain domain. The OPS5 programs can execute only normally with this restric- tion. So, we also take this information into consideration. Users can then provide their requirements of the initial WM to our tool, making it possible to reduce the size of the WMEs we generate and thus produce more accurate analysis results. We briefly introduce the OPS5 language in the next section. Then we describe the Cheng–Tsai analysis methodology, partially based on the graphical representation of the control paths of OPS5 programs. Next we present the Cheng–Chen analysis methodology, based on a different set of quantitative algorithms. 11.1 THE OPS5 LANGUAGE This section provides an overview of the OPS5 language, with examples, and de- scribes the Rete matching network for determining instantiations of rules. 11.1.1 Overview An OPS5 rule-based program [Forgy, 1981; Brownston et al., 1986; Cooper and Wogrin, 1988] consists of a finite set of rules, each of which is of the form (p rule-name (condition-element-1) (condition-element-2) : (condition-element-m) --> (action-1) : (action-n)) and a database of assertions, each of which is of the form (class-name ^attribute-1 value-1 ^attribute-2 value-2 : ^attribute-p value-p) The symbol “ ^ ” means there is an attribute name following it. The set of rules is called the production memory (PM) and the database of assertions is called the 370 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS working memory (WM). Each assertion is called a working memory element (WME). A rule has three parts: • the name of the rule, rule-name ; • the left-hand-side (LHS), that is, a conjunction of the condition elements, each of which can be either a positive condition element or negative condition ele- ment; and • the right-hand-side (RHS), that is, the actions, each of which may make, modify, or delete a WME, perform I/O, or halt. All atoms are literals unless put in variable brackets <> . The scope of variables is a single rule. A WME is an instance of an element class. An element class defines a WME structure in the same way a C data type defines the structure of entities in a C program. An element class is the template from which instances are made. It is identified by class-name and by a collection of attributes describing characteristics relevant to the entity. The following is an OPS5 rule for processing sensor informa- tion from a radar system: (p radar-scan ; an OPS5 rule (region-scan1 ^sensor object) ; positive condition element (region-scan2 ^sensor object) ; positive condition element (status-check ^status normal) ; positive condition element - (interrupt ^status on) ; negative condition element { <Uninitialized-configuration> ; positive condition element (configuration ^object-detected 0) } --> (modify <Uninitialized-configuration> ^object-detected 1)) ; action If both radars, (region-scan1) and (region-scan2) , detect an object, the status of the radar system is normal, there is no interrupt, and the attribute object-detected in the element class configuration is 0, then assign 1 to object-detected . The nota- tion <name> WME is used to name the matching WME for use in this action. Hence, <Uninitialized-configuration> refers to the “configuration” WME matched in the LHS. Otherwise, the number of the matching conditions in the LHS may be used in modify and delete commands. Comments are given following the semicolon. When the working memory contains the WMEs (region-scan1 ^sensor object) (region-scan2 ^sensor object) (status-check ^status normal) (configuration ^object-detected 0) but does not contain the WME (interrupt ^status on) , the above rule is said to have a successful matching. More precisely, a rule is enabled if each of its positive con- dition elements is matched with a WME in the working memory and each of its negative condition elements is not matched by any WME in the working memory. A rule firing is the execution of the RHS actions in the order they appear in the rule. The above rule fires by modifying the attribute object-detected in the element class configuration to have the value 1. THE OPS5 LANGUAGE 371 A condition element can consist of value tests, other than equality, that a matching WME value must satisfy. These tests may be specified using the following compo- nents. Consider the WME (airport ^airport-terminals 3 ^vacancies 3), which is an instance of the element class airport . • Variables: variables are specified in brackets and are used for matching values in the WMEs, or for defining a relationship between two values. Variables are implicitly existentially quantified over the rule LHS and RHS. Note that the following example requires the same value for the attributes airport-terminals and vacancies . ^airport-terminals <terminals-available> ^vacancies <terminals-available> • Predicate operators: for restricting the range of values that can match. ^airport-terminals > 0 • Disjunctions: for specifying a list of values, one of which must be equal to the value in the WME. ^airport-terminals <<123>> • Conjunctions: for specifying a group of value tests that must be satisfied by one WME value. ^airport-terminals { > 1 <> nil } • Variable semantic restrictions: any variable may be further qualified using these predicates by inclusion in the braces, as in (airport ^airport-terminals { <terminals-available> > 0 }). The execution of the OPS5 program is known as the MRA cycle [Brownston et al., 1986] and is executed by the inference engine. The MRA cycle consists of three phases: • Match: for each rule, determine all sets of WMEs that match the condition elements of the rule. Note that a rule may have more than one matching. The result of a successful match is called an instantiation. The set of all satisfied rule instantiations is called the conflict set. • Resolve (Select): a single rule instantiation is selected from the conflict set ac- cording to some conflict-resolution strategies. Two common strategies are LEX (lexicographic ordering) and MEA (means-end analysis). • Act: the selected rule instantiation is executed in the act phase. The actions in the selected rule are executed sequentially in the order they appear in the rule. 372 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS The production system repeats the MRA cycle until the conflict set is empty or an explicit halt command is executed. 11.1.2 The Rete Network Of these three phases, the match phase is by far the most expensive, accounting for more than 90 percent of execution time in some experiments [Forgy, 1982; Gupta, 1987; Ishida, 1994]. Therefore, to maximize the efficiency of an OPS5 program, a fast match algorithm is necessary. The Rete match algorithm was first introduced in [Forgy, 1982] and it has become the standard sequential match algorithm. A new version called Rete II was introduced in [Forgy, 1985]. The Rete algorithm compiles the LHS patterns of the production rules into a dis- crimination network in the form of an augmented dataflow network [Miranker, 1987]. The state of all matches is stored in the memory nodes of the Rete network. Since a limited number of changes are made to the working memory after the firing of a rule instantiation, only a small part of the state of all matches needs to be changed. Thus, (p p1 (c1 ^a1 <x> ^a2 10) (c2 ^a1 <x>) --> (remove 2)) (p p2 (c1 ^a1 <y> ^a2 10) (c3 ^a1 2 ^a2 <y>) -(c4 ^a1 <y>) --> (modify 1 ^attri 4)) root class=c2 class=c1 class=c3 class=c4 a2=10 a1=2 alpha memory node and-node terminal-node p1 beta memory node alpha memory node alpha memory node alpha memory node not-node terminal-node p2 and-node Constant-test nodes Figure 11.1 An example of a Rete network. CHENG–TSAI TIMING ANALYSIS METHODOLOGY 373 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 in- stantiation. The top portion of the Rete network contains chains of tests that perform the select operations. Tokens passing through these chains partially match a partic- ular 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 con- dition 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 (c1 ^a1 2 ^a2 3) (c2 ^b1 5) (c1 ^a1 4 ^a2 3) (c2 ^b1 3) (c1 ^a1 3 ^a2 3)(c1 ^a1 5 ^a2 3) (p r1 (c1 ^a1 <x> ^a2 3) (c2 ^b1 { <y> <> <x> } ) --> (modify 1 ^a1 <y>) (remove 2)) (p r1 (c1 ^a1 <x> ^a2 3) (c2 ^b1 { <y> <> <x> }) --> (modify 1 ^a1 <y>) (remove 2)) (p r3 (c1 ^a1 2 ^a2 <x>) (c2 ^b1 5) -(c1 ^a1 <x>) --> (modify 1 ^a1 4) (modify 2 <x>)) (p r2 (c1 ^a1 5 ^a2 <x>) --> (modify 1 ^a1 <x>)) 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 r 1 potentially enables rule r 2, and rule r 3 potentially enables rule r 1. 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 n m possible WMEs. In the state-space graph, 2 n m 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 poten- tially 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. (class ^a1 3 ^a2 4) (class ^a1 3 ^a2 8 ^a3 4) (class ^a1 3 ^a2 <y> ^a3 <z>) CHENG–TSAI TIMING ANALYSIS METHODOLOGY 375 Note that to determine with certainty whether a rule enables rather than poten- tially 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 stati- cally. 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 (class_a ^a1 <x> ^a2 3) (class_b ^b1 <x> ^b2 {<y> <<open close>>}) --> (make class_c ^c1 off ^c2 <x>) (modify 1 ^a2 <y>)) (p b (class_a ^a1 <x> ^a2 off) (class_c ^c1 <y>) --> (modify 1 ^a2 open)) 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 ex- ecution 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 ter- mination 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 num- ber of its rule firings is finite. Thus the maximal number of times a rule in a termi- nating 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 poten- tially 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 ele- ments 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>)) [...]... entity name R-A-0 R-A-1 T-A-0 T-A-1 # entity state nominal failed suspect # entity mode on off # entity backup R-A-0 R-A-1 T-A-0 T-A-1 # relationship from R-A-0 R-A-1 T-A-0 T-A-1 # relationship to R-A-0 R-A-1 T-A-0 T-A-1 # relationship state nominal failed suspect # relationship mode on off # relationship type direct # problem entity R-A-0 R-A-1 T-A-0 T-A-1 # answer name R-A-0 R-A-1 T-A-0 T-A-1 # answer... 1 2,3 2,3 none x-1 y-1 x-2 y-2 1 2,3 2,3 1 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 ) (class2 ^a21 ) (class2 ^a21 ^a22 ) 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... ^a42 ) (class4 ^a41 2 ^a42 ) > ; cycle information (p loop-rule12 ;cycle: 3 4 1 (control ^rule extra) ;redundant with loop-rule10 (class1 ^a11 ^a12 ) (class4 ^a41 2 ^a42 ) (class4 ^a41 { 1} ^a42 { >} ) (class2 ^a22 ) > ; cycle information (p loop-rule13 ;cycle: 1 3 4 (control ^rule extra) ;redundant with loop-rule8 (class1 ^a13 {... loop-rule1 (class1 ^a13 { >} ) (class4 ^a41 { 1} ^a42 ) (class2 ^a22 ) > ; cycle information (p loop-rule10 ;cycle: 3 1 (control ^rule extra) (class1 ^a11 ^a12 ) (class4 ^a41 2 ^a42 ) (class2 ^a22 ) > ; cycle information (p loop-rule11 ;cycle: 1 4 3 (control ^rule extra) ;redundant with loop-rule8 (class1 ^a13 { 1} ) (class2 ^a22 {... ^a21 ) ) ) ^a22 ) 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 TABLE A TABLE B TABLE C Variable Binding space Variable Binding space Variable Binding space x-1 y-1 x-2 y-2 1 none 2,3 none x-1 y-1 x-2 y-2 1... W is now (class1 ^a11 ) (class2 ^a21 ) (class2 ^a21 ^a22 ) 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 ) (class2 ^a21 ) (class2 ^a21 ^a22 ) where y-21 and y-1=2,3 The detailed algorithm... ^a22 ) (class4 ^a41 2 ^a42 ) (class4 ^a41 ^a42 { >} ) > ; cycle information (p loop-rule14 ;cycle: 4 3 1 (control ^rule extra) ;redundant with loop-rule7 (class1 ^a13 { >} ) (class4 ^a41 ^a42 ) (class4 ^a41 2 ^a42 ) (class2 ^a22 ) > ; cycle information (p loop-rule15 ;cycle: 3 1 4 (control ^rule extra) ;redundant with loop-rule5... ;redundant with loop-rule5 (class1 ^a11 ^a12 ) (class4 ^a41 2 ^a42 ) (class2 ^a22 { >} ) (class4 ^a41 ^a42 ) > ; cycle information (p loop-rule16 ;cycle: 4 1 3 (control ^rule extra) ;redundant with loop-rule7 (class1 ^a13 { >} ) (class4 ^a41 { 1} ^a42 ) (class2 ^a22 ) (class4 ^a41 2 ^a42 ) > ; cycle information CHENG–TSAI... extra) (class1 ^a13 { 1} ) (class2 ^a22 ) > ; cycle information (p loop-rule5 ;cycle: 3 4 (control ^rule extra) (class1 ^a11 ^a12 ) (class4 ^a41 2 ^a42 ) (class4 ^a41 ^a42 { >} ) > ; cycle information (p loop-rule6 ;cycle: 1 4 (control ^rule extra) (class1 ^a13 { 1} ) (class2 ^a22 { >} ) (class4 ^a41 ^a42 ) > ; cycle information... information (p loop-rule7 ;cycle: 4 3 (control ^rule extra) (class1 ^a13 > ) (class4 ^a41 ^a42 ) (class4 ^a41 2 ^a42 ) > ; cycle information 386 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS (p loop-rule8 ;cycle: 1 3 (control ^rule extra) (class1 ^a13 { 1} ) (class2 ^a22 ) (class4 ^a41 2 ^a42 ) > ; cycle information (p loop-rule9 ;cycle: 4 . which is of the form (p rule-name (condition-element-1) (condition-element-2) : (condition-element-m) -- > (action-1) : (action-n)) and a database of assertions,. space x-1 <>1 y-1 none x-2 2,3 y-2 none TABLE B Variable Binding space x-1 <>1 y-1 2,3 x-2 2,3 y-2 none TABLE C Variable Binding space x-1 <>1