
- •CONTENTS
- •PREFACE
- •LIST OF FIGURES
- •INTRODUCTION
- •1.1 WHAT IS TIME?
- •1.2 SIMULATION
- •1.3 TESTING
- •1.4 VERIFICATION
- •1.6 USEFUL RESOURCES
- •2.1 SYMBOLIC LOGIC
- •2.1.1 Propositional Logic
- •2.1.2 Predicate Logic
- •2.2 AUTOMATA AND LANGUAGES
- •2.2.1 Languages and Their Representations
- •2.2.2 Finite Automata
- •2.3 HISTORICAL PERSPECTIVE AND RELATED WORK
- •2.4 SUMMARY
- •EXERCISES
- •3.1 DETERMINING COMPUTATION TIME
- •3.2 UNIPROCESSOR SCHEDULING
- •3.2.1 Scheduling Preemptable and Independent Tasks
- •3.2.2 Scheduling Nonpreemptable Tasks
- •3.2.3 Nonpreemptable Tasks with Precedence Constraints
- •3.2.5 Periodic Tasks with Critical Sections: Kernelized Monitor Model
- •3.3 MULTIPROCESSOR SCHEDULING
- •3.3.1 Schedule Representations
- •3.3.3 Scheduling Periodic Tasks
- •3.4 AVAILABLE SCHEDULING TOOLS
- •3.4.2 PerfoRMAx
- •3.4.3 TimeWiz
- •3.6 HISTORICAL PERSPECTIVE AND RELATED WORK
- •3.7 SUMMARY
- •EXERCISES
- •4.1 SYSTEM SPECIFICATION
- •4.2.1 Analysis Complexity
- •4.3 EXTENSIONS TO CTL
- •4.4 APPLICATIONS
- •4.4.1 Analysis Example
- •4.5 COMPLETE CTL MODEL CHECKER IN C
- •4.6 SYMBOLIC MODEL CHECKING
- •4.6.1 Binary Decision Diagrams
- •4.6.2 Symbolic Model Checker
- •4.7.1 Minimum and Maximum Delays
- •4.7.2 Minimum and Maximum Number of Condition Occurrences
- •4.8 AVAILABLE TOOLS
- •4.9 HISTORICAL PERSPECTIVE AND RELATED WORK
- •4.10 SUMMARY
- •EXERCISES
- •VISUAL FORMALISM, STATECHARTS, AND STATEMATE
- •5.1 STATECHARTS
- •5.1.1 Basic Statecharts Features
- •5.1.2 Semantics
- •5.4 STATEMATE
- •5.4.1 Forms Language
- •5.4.2 Information Retrieval and Documentation
- •5.4.3 Code Executions and Analysis
- •5.5 AVAILABLE TOOLS
- •5.6 HISTORICAL PERSPECTIVE AND RELATED WORK
- •5.7 SUMMARY
- •EXERCISES
- •6.1 SPECIFICATION AND SAFETY ASSERTIONS
- •6.4 RESTRICTED RTL FORMULAS
- •6.4.1 Graph Construction
- •6.5 CHECKING FOR UNSATISFIABILITY
- •6.6 EFFICIENT UNSATISFIABILITY CHECK
- •6.6.1 Analysis Complexity and Optimization
- •6.7.2 Timing Properties
- •6.7.3 Timing and Safety Analysis Using RTL
- •6.7.5 RTL Representation Converted to Presburger Arithmetic
- •6.7.6 Constraint Graph Analysis
- •6.8 MODECHART SPECIFICATION LANGUAGE
- •6.8.1 Modes
- •6.8.2 Transitions
- •6.9.1 System Computations
- •6.9.2 Computation Graph
- •6.9.3 Timing Properties
- •6.9.4 Minimum and Maximum Distance Between Endpoints
- •6.9.5 Exclusion and Inclusion of Endpoint and Interval
- •6.10 AVAILABLE TOOLS
- •6.11 HISTORICAL PERSPECTIVE AND RELATED WORK
- •6.12 SUMMARY
- •EXERCISES
- •7.1.1 Timed Executions
- •7.1.2 Timed Traces
- •7.1.3 Composition of Timed Automata
- •7.1.4 MMT Automata
- •7.1.6 Proving Time Bounds with Simulations
- •7.2.1 Untimed Traces
- •7.2.2 Timed Traces
- •7.3.1 Clock Regions
- •7.3.2 Region Automaton
- •7.4 AVAILABLE TOOLS
- •7.5 HISTORICAL PERSPECTIVE AND RELATED WORK
- •7.6 SUMMARY
- •EXERCISES
- •TIMED PETRI NETS
- •8.1 UNTIMED PETRI NETS
- •8.2 PETRI NETS WITH TIME EXTENSIONS
- •8.2.1 Timed Petri Nets
- •8.2.2 Time Petri Nets
- •8.3 TIME ER NETS
- •8.3.1 Strong and Weak Time Models
- •8.5.1 Determining Fireability of Transitions from Classes
- •8.5.2 Deriving Reachable Classes
- •8.6 MILANO GROUP’S APPROACH TO HLTPN ANALYSIS
- •8.6.1 Facilitating Analysis with TRIO
- •8.7 PRACTICALITY: AVAILABLE TOOLS
- •8.8 HISTORICAL PERSPECTIVE AND RELATED WORK
- •8.9 SUMMARY
- •EXERCISES
- •PROCESS ALGEBRA
- •9.1 UNTIMED PROCESS ALGEBRAS
- •9.2 MILNER’S CALCULUS OF COMMUNICATING SYSTEMS
- •9.2.1 Direct Equivalence of Behavior Programs
- •9.2.2 Congruence of Behavior Programs
- •9.2.3 Equivalence Relations: Bisimulation
- •9.3 TIMED PROCESS ALGEBRAS
- •9.4 ALGEBRA OF COMMUNICATING SHARED RESOURCES
- •9.4.1 Syntax of ACSR
- •9.4.2 Semantics of ACSR: Operational Rules
- •9.4.3 Example Airport Radar System
- •9.5 ANALYSIS AND VERIFICATION
- •9.5.1 Analysis Example
- •9.5.2 Using VERSA
- •9.5.3 Practicality
- •9.6 RELATIONSHIPS TO OTHER APPROACHES
- •9.7 AVAILABLE TOOLS
- •9.8 HISTORICAL PERSPECTIVE AND RELATED WORK
- •9.9 SUMMARY
- •EXERCISES
- •10.3.1 The Declaration Section
- •10.3.2 The CONST Declaration
- •10.3.3 The VAR Declaration
- •10.3.4 The INPUTVAR Declaration
- •10.3.5 The Initialization Section INIT and INPUT
- •10.3.6 The RULES Section
- •10.3.7 The Output Section
- •10.5.1 Analysis Example
- •10.6 THE ANALYSIS PROBLEM
- •10.6.1 Finite Domains
- •10.6.2 Special Form: Compatible Assignment to Constants,
- •10.6.3 The General Analysis Strategy
- •10.8 THE SYNTHESIS PROBLEM
- •10.8.1 Time Complexity of Scheduling Equational
- •10.8.2 The Method of Lagrange Multipliers for Solving the
- •10.9 SPECIFYING TERMINATION CONDITIONS IN ESTELLA
- •10.9.1 Overview of the Analysis Methodology
- •10.9.2 Facility for Specifying Behavioral Constraint Assertions
- •10.10 TWO INDUSTRIAL EXAMPLES
- •10.10.2 Specifying Assertions for Analyzing the FCE Expert System
- •Meta Rules of the Fuel Cell Expert System
- •10.11.1 General Analysis Algorithm
- •10.11.2 Selecting Independent Rule Sets
- •10.11.3 Checking Compatibility Conditions
- •10.12 QUANTITATIVE TIMING ANALYSIS ALGORITHMS
- •10.12.1 Overview
- •10.12.2 The Equational Logic Language
- •10.12.3 Mutual Exclusiveness and Compatibility
- •10.12.5 Program Execution and Response Time
- •10.12.8 Special Form A and Algorithm A
- •10.12.9 Special Form A
- •10.12.10 Special Form D and Algorithm D
- •10.12.11 The General Analysis Algorithm
- •10.12.12 Proofs
- •10.13 HISTORICAL PERSPECTIVE AND RELATED WORK
- •10.14 SUMMARY
- •EXERCISES
- •11.1 THE OPS5 LANGUAGE
- •11.1.1 Overview
- •11.1.2 The Rete Network
- •11.2.1 Static Analysis of Control Paths in OPS5
- •11.2.2 Termination Analysis
- •11.2.3 Timing Analysis
- •11.2.4 Static Analysis
- •11.2.5 WM Generation
- •11.2.6 Implementation and Experiment
- •11.3.1 Introduction
- •11.3.3 Response Time of OPS5 Systems
- •11.3.4 List of Symbols
- •11.3.5 Experimental Results
- •11.3.6 Removing Cycles with the Help of the Programmer
- •11.4 HISTORICAL PERSPECTIVE AND RELATED WORK
- •11.5 SUMMARY
- •EXERCISES
- •12.1 INTRODUCTION
- •12.2 BACKGROUND
- •12.3 BASIC DEFINITIONS
- •12.3.1 EQL Program
- •12.3.4 Derivation of Fixed Points
- •12.4 OPTIMIZATION ALGORITHM
- •12.5 EXPERIMENTAL EVALUATION
- •12.6 COMMENTS ON OPTIMIZATION METHODS
- •12.6.1 Qualitative Comparison of Optimization Methods
- •12.7 HISTORICAL PERSPECTIVE AND RELATED WORK
- •12.8 SUMMARY
- •EXERCISES
- •BIBLIOGRAPHY
- •INDEX
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 analysis 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 restriction. 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 describes 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 element; 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 and by a collection of attributes describing characteristics relevant to the entity. The following is an OPS5 rule for processing sensor information 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
in the element class configuration is 0, then assign 1 to object-detected. The notation 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 condition 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 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 components. 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 << 1 2 3 >>
•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 according 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 discrimination 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 |
|
(p p2 |
|
|
|
(c1 |
^a1 <y> ^a2 10) |
||
(c1 |
^a1 <x> ^a2 10) |
|||
(c3 |
^a1 2 ^a2 <y>) |
|||
(c2 |
^a1 <x>) |
|||
|
|
--> |
-(c4 ^a1 <y>) |
|
--> |
||
(remove 2)) |
||
(modify 1 ^attri 4)) |
||
|
||
|
root |
class=c2 class=c1
a2=10
alpha memory
node
alpha memory node
and-node
terminal-node
class=c3 class=c4
a1=2
alpha alpha
memory memory
node node
and-node
beta memory node
p1 |
not-node |
|
Constant-test nodes
terminal-node
p2
Figure 11.1 An example of a Rete network.