330 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS

rules in K will reach a fixed point in bounded time despite the presence of v. After the rules in K have reach a fixed point, the variables in K will no longer change their contents and thus these variables will not enable or disable rules in v. At this point, only rules in v may fire. Since v is guaranteed to reach a fixed point in bounded time, it can be concluded that the rules in v v1 · · · vp are also always guaranteed to reach a fixed point in bounded time.

10.11.3 Checking Compatibility Conditions

Checking whether the second condition (CR2) or the third condition (CR3) for compatibility is satisfied by a pair of rules is a straightforward exercise in comparing sets and expressions. We shall therefore discuss the checking of the first condition: mutual exclusion.

The Boolean function mutex(e1, e2) determines whether two Boolean expressions, e1 and e2, are mutually exclusive. The goal of mutex is not to conquer the general mutual exclusion problem. Instead, it tries to efficiently detect as much mutual exclusion as possible. When it returns true, it means that the two expressions are mutually exclusive. However, when it returns false, it means that either they are not mutually exclusive or there is insufficient information (without executing the rules and without a priori knowledge of the input values) to determine the mutual exclusion. Therefore, the two expressions may still be mutually exclusive even when mutex returns false.

This approximation does not affect the validity of any of the special forms (all of which use the mutual exclusion check in the compatibility condition) described because the approximate mutual exclusion relation is a subset of the mutual exclusion relation. Thus certain pairs of enabling conditions which are mutually exclusive may not be recognized as such using this approximate mutual exclusion check. This is acceptable since every pair of enabling conditions that are recognized by the approximate mutual exclusion check are guaranteed to be mutually exclusive. Therefore, the analyzer never concludes erroneously that a program with unbounded response time is one that has bounded response time, though some programs which have bounded response time may be rejected because the mutual exclusion relation between at least one pair of rules may not be recognized using this approximation.

mutex makes use of a divide-and-conquer strategy inspired by the following observations. Let e1, e2, e3 be arbitrary Boolean expressions. For (e1 AND e2) and e3 to be mutually exclusive, either e1 or e2 (or both) must be mutually exclusive with e3. For (e1 OR e2) and e3 to be mutually exclusive, both e1 and e2 must be mutually exclusive with e3. Therefore we can continuously divide the problem into subproblems until both Boolean expressions are simple expressions.

A subtle problem arises when NOT operators appear in expressions. For example, to decide whether the expressions (NOT e1) and e2 are mutually exclusive, we cannot simply negate the answer returned from mutex(e1, e2), because errors may occur when mutex(e1, e2) returns false, meaning e1 and e2 may or may not be mutually exclusive. Let us assume that these expressions are properly parenthesized. We define the level of an operator as the number of open parentheses within the scope of this

operator. Thus an operator whose scope has no parenthesis is at level 0. Then this problem can be solved by applying DeMorgan’s laws (chapter 2, Figure 2.3) to the expressions to move the occurrence of NOT operators to the lowest level.

In the implementation, we do not explicitly rewrite the expressions before calling mutex. Instead, a flag to indicate whether special NOT processing is needed is associated with each expression in mutex to keep track of the net effect of NOT operators down to the level at which this NOT appears. If mutex(e1, e2) returns true, then (NOT e1) and e2 are not mutually exclusive; thus the flag is initialized to false to indicate that no special negation processing is needed. Otherwise, if mutex(e1, e2) returns false, then whether (NOT e1) and e2 are mutually exclusive or cannot be determined without additional information. We assume that these two expressions are mutually exclusive and set the flag to true to indicate that special negation processing is needed later. If a NOT operator is encountered at another level, this flag is negated. This procedure is repeated as often as needed while this flag is passed down to the subroutines in charge of the subexpressions. After all NOTs have been processed and if the flag is false, we can conclude that (NOT e1) and e2 are not mutually exclusive. Otherwise, if the flag is true, no such conclusion can be warranted.

The detection of mutual exclusion between two simple expressions s1 and s2 is handled by function smutex(s1, s2). A simple expression can be

a Boolean variable, for example, sensor a good; a constant, e.g., FALSE; or

a relational test, whose operator can be one of =, , >, <, >=, <=, and whose operands can be either variables or arithmetic expressions.

Although tedious, smutex handles the examination case by case. It also invokes function eval(e), which, given an expression e, determines whether it can be evaluated. If it can be evaluated, eval also returns the result of evaluation.

It should be noted that compatibility is independent of any special form. When the analyzer determines that rule a and rule b are compatible or when the user specifies this fact, these two rules are considered compatible under any context (when checked by any special form recognition procedures).

Timing Requirements The complexity of eval is linearly proportional to the length, in terms of the number of operators, of the expression to be evaluated. Although the general problem of mutual-exclusion detection is of exponential complexity, mutex has been implemented to give answers in quadratic time.

10.11.4 Checking Cycle-Breaking Conditions

Cycle-breaking conditions are kept in a list, with the latest specified break condition placed at the head and the earliest specified break condition, which is the one in the special form part, placed at the tail. Later specified break conditions are checked first and therefore are treated as exceptions. Since conditions in a special form may specify different types of graphs, one list exists for each type of graph. We define any cycle found in a graph representing some information about a program to be

332 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS

acceptable if it does not cause a cycle in the state-space graph of the program. A cycle is not acceptable if it may cause a cycle in the state-space graph of the program. An arbitrary cycle-breaking condition is evaluated as follows:

Algorithm Eval CB Conditions Evaluating general cycle-breaking conditions.

When a cycle is found in the graph of type graph type: initially, assume the cycle is acceptable;

if ( cycles list is not specified or

the cycle is found in the specified cycles list ) then if ( break condition is evaluated to FALSE )

then the cycle is not acceptable else the cycle is acceptable

else if (cycles list is specified but the cycle is not found in it)

then check the next break condition in the list of break conditions for this graph type, if any

else the cycle is acceptable

To allow for the checking of arbitrary break conditions for each cycle in an arbitrary graph representing the syntactic and/or semantic structure of a program, the checking algorithm may be required to perform an exhaustive search on the arbitrary graph. The brute-force approach would have to determine every cycle in the graph and then check whether the break condition is satisfied for each cycle found. If |E| |V |, where |E| and |V | are, respectively, the number of edges and the number of vertices in a graph (e.g., ER graph, VM graph) corresponding to a program, then this approach is still practical. The selection algorithm construct HLD graph (section 10.11.2) described earlier decomposes the program into forward-independent modules which can be analyzed independently. This effectively breaks a large graph (corresponding to the entire program) into a set of smaller graphs (corresponding to independent modules of rules), each of which is more amenable to efficient analysis. It should be noted that an arbitrary graph corresponding to the rules in a forwardindependent set may be different from the dependency graph (a strongly connected component) corresponding to these rules. Thus the arbitrary graph may be further decomposed into smaller components for analysis.

Furthermore, it should be noted that the types of graphs used for static analysis are much smaller in size than the state-space graph corresponding to a program. For instance, each vertex in an ER graph corresponds to a distinct rule in a program. If a program has n rules, there are n vertices and at most n(n − 1)/2 edges in the corresponding ER graph. In contrast, each of the vertices in a state-space graph represents a distinct vector of all variables in a program. For instance, for a finite-domain program with m variables, the total number of states in the corresponding state-space graph in the worst case (i.e., all combinations of the values of the variables are possible) is

i=m

|Xi |

i=1

over those based primarily on conventional finite-state-based checking [Emerson et al., 1990].

To further improve the efficiency of checking cycle-breaking conditions, we have developed the following strategies that are applicable to some classes of break conditions and cycles. As in most strategies for attacking NP-complete graph problems, our strategies take advantage of special characteristics of a graph type and of the particular form of break conditions. Any attempt to find checking algorithms which are efficient for arbitrary graphs and arbitrary break conditions would not seem promising.

For a class of break conditions that expresses relationships between two rules in a cycle, we can first determine those pairs of rules that violate the break condition being checked. Then for each pair of these rules, we check to see whether the pair of vertices corresponding to this pair of rules lie in a cycle. If the answer is yes, we can immediately conclude that the cycle detected is not broken by the break condition.

For certain classes of graphs and a class of break conditions, it is possible to first prune the acceptable cycles in the graph without actually finding all vertices in a cycle, and then apply a general cycle-checking algorithm. This would greatly reduce the number of cycles that have to be checked.

10.12 QUANTITATIVE TIMING ANALYSIS ALGORITHMS

We now present quantitative algorithms for determining the worst-case execution times (WCETs) of EQL programs. As defined earlier, given a program p, the response time analysis problem is to determine the response time of p. This problem consists of (1) determining whether or not the execution of p always terminates in bounded time and (2) computing the maximal execution time of p.

We have shown that the response-time analysis problem is undecidable if the program variables have infinite domains and is PSPACE-hard in the case where all of the variables have finite domains. However, we have observed that the use of a simple syntactic and semantic check of programs coupled with other techniques such as state-space graph checks can dramatically reduce the time needed in the analysis. Sets of syntactic and semantic constraint assertions exist such that if the set S of rules satisfies any of them, then the execution of S always terminates in bounded time. Each of these sets of syntactic and semantic constraint assertions is called a special form.

The focus of the remainder of this chapter is to formally prove the correctness of two special forms and to determine tight response-time upper bounds of EQL rule-based programs. For each known special form, an algorithm used to calculate the maximal response time of programs satisfying this special form is presented. Additionally, to enhance the applicability of the proposed algorithms, we show how the General Analysis Algorithm can be used with these algorithms.