
- •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
256 PROCESS ALGEBRA
9.8 HISTORICAL PERSPECTIVE AND RELATED WORK
Process algebras were first developed to specify and analyze concurrent processes in distributed systems without absolute timing characteristics. These algebras include Hoare’s CSP [Hoare, 1978; Hoare, 1985], Milner’s CCS [Milner, 1980; Milner, 1989], and Bergstra and Klop’s ACP [Bergstra and Klop, 1985].
Because of their capabilities in specifying systems and manipulating their specifications in compact forms, process algebras have been extended recently by several researchers to handle the notion of real time. Reed and Roscoe proposed a timed version of CSP called Timed CSP [Reed and Roscoe, 1987]. The ISO specification standard LOTOS [Bolognesi and Brinksma, 1987] is based on CSP, and a timed version of LOTOS called Timed LOTOS has been used to specify and analyze a number of industrial systems. Baeten and Bergstra extended ACP to produce a timed version of ACP [Baeten and Bergstra, 1991]. [Aceto and Murphy, 1993] also considered adding the notion of time to process algebras. [Moller and Tofts, 1990] extended CCS to yield a Temporal Calculus of Communicating Systems (TCCS). [Nicollin and Sifakis, 1991] introduced the Algebra of Timed Processes (ATP) and show its applications. [Yi, 1991] added the notion of time to CCS and proposed an interleaving model for specifying and verifying real-time systems.
Lee’s group’s first proposal to add the notion of time to process algebras produced a real-time algebra without the notions of resources and priorities [Zwarico, 1988]. Later, [Gerber and Lee, 1989; Gerber and Lee, 1990] extended CCS to yield a Calculus of Communicating Shared Resources (CCSR), the first timed process algebra to support the notions of both resources and priorities. More recently, Lee’s group added instantaneous synchronization events to CCSR to yield ACSR [Bremond-Gregoire, 1994; Lee, Bremond-Gregoire, and Gerber, 1994]. To improve the user interface, [Ben-Abdallah, Lee, and Choi, 1995; Ben-Abdallah, 1996; Ben-Abdallah and Lee, 1998] introduced a graphical language called GCSR together with a formal semantics specifying and analyzing real-time systems. [Ben-Abdallah et al., 1998] and [Choi, Lee, and Xie, 1995] also applied the process-algebraic approach to analyze the schedulability of real-time systems.
9.9 SUMMARY
A process algebra is a concise language (usually not logic-based) for describing the possible execution steps of computer processes. It has a set of operators and syntactic rules for specifying a process using simple, atomic components. Process algebras use the notion of equivalence to show that two processes have the same behavior. Wellestablished process algebras such as Hoare’s Communicating Sequential Processes (CSP) [Hoare, 1978; Hoare, 1985], Milner’s Calculus of Communicating Systems (CCS) [Milner, 1980; Milner, 1989], and Bergstra and Klop’s Algebra of Communicating Processes (ACP) [Bergstra and Klop, 1985] have been used to specify and analyze concurrent processes with interprocess communication. These are untimed
SUMMARY 257
algebras since they allow one to only reason about the relative ordering of execution steps and events.
To use a process algebra or a process-algebraic approach to specify and analyze a system, we write the requirements specification of the system as an abstract process and the design specification as a detailed process. We then show that these two processes are equivalent, thus showing the design specification is correct with respect to the requirements specification. Here, the requirements specification may include the desired safety properties.
A process algebra has four basic components: (1) a concise language to specify a system as a process or set of processes, (2) an unambiguous semantics to provide precise meanings for the behavior of the specified processes, showing the possible execution steps of these processes, (3) an equivalence or preorder relation to compare the behavior of the processes, and (4) a set of algebraic laws to syntactically manipulate the process specifications.
To specify and verify real-time systems while maintaining their modular verification capabilities as well as their single-language specification advantage, untimed process algebras have been extended with the notion of time by adding timed operators to the original set of untimed operators. Several timed process algebras exist as a result of these timed extensions. These real-time process algebras can specify process synchronization delays and upperbounds in terms of absolute timing intervals but vary in the way they model the resources used by processes.
On one end of the spectrum is the assumption that each type of resources is unlimited so that a ready process (not blocked by communication constraints, as discussed in chapter 3) can start execution without delay. On the other end of the spectrum is the assumption that a single processor exists so that all process executions are interleaved. Between these two extreme assumptions, real-time process algebras assume a limited number of resources. One popular timed process algebra that assumes a limited number of n resources capable of executing n actions is the Algebra of Communicating Shared Resources (ACSR) [Lee, Bremond-Gregoire, and Gerber, 1994].
The ACSR language is a discrete real-time process algebra based on CCS (described earlier) that provides several operators to handle timing properties. Two ways are available to establish equivalence: syntax-based and semantics-based techniques. The VERSA system [Clarke, Lee, and Xie, 1995] maintains as much as possible the syntax of ACSR while using ASCII keyboard-typable notations for special ACSR characters and subscripted or superscripted variables. Here, VERSA converts the algebraic-process descriptions bound to these processes to state machines and then employs a state minimization algorithm to preserve strong bisimulation simultaneously to these two machines. The original machines are strongly bisimilar if the corresponding minimal state machine contains a state with the start state of both original machines. Since this construction of the state machine from its corresponding algebraic expression requires space exponential in the length of the expression, checking for prioritized strong equivalence is restricted for algebraic expressions with small state machines.
258 PROCESS ALGEBRA
EXERCISES
1.How do process-algebraic techniques such as those based on CCS and ACSR verify that two system specifications have the same behavior without exploring their state representations (such as finite-state machines)?
2.Use CCS laws to determine whether the following two statements are equivalent:
(a)((P + (Q + R))|(S + (T + V )))|(X + Y )
(b)((Y + X)|((V + S) + T ))|((P + Q) + R).
3.Use CCS to specify the solution to the two-process mutual-exclusion problem.
4.Use the definition operator to specify a recursive process without using the rec operator.
5.How does ACSR extend CCS to allow the specification of real-time systems? Describe the timing-related operator.
6.The radar system specified using ACSR employs a rate-monotonic scheduler to assign priorities to its signal-processing tasks. It also has two resources, cpu1 and cpu2.
(a)Suppose the least-laxity scheduler is used instead to assign task priorities. Rewrite the ACSR specification.
(b)Suppose one resource cpu and one resource disk are available. A signalprocessing task must use cpu for a certain amount of time and then use disk for a certain amount of time. Rewrite the ACSR specification.
7.Explain the difference between syntactic analysis and semantic analysis. Is it possible to find two processes that cannot be shown to be equivalent using syntactic analysis but can be proved to be equivalent using semantic analysis?
8.Specify the mobile telephone/entertainment system described in chapter 4 (exercise 5) as an ACSR process.
9.Specify the smart airbag deployment system described in chapter 4 (exercise 6) as an ACSR process. Compare the expressiveness and space requirement for the ACSR model and the timed transition graph model.

CHAPTER 10
DESIGN AND ANALYSIS OF
PROPOSITIONAL-LOGIC
RULE-BASED SYSTEMS
Real-time decision systems are computer-controlled systems that must react to events in the external environment by making decisions based on sensor inputs and state information sufficiently fast to meet environment-imposed timing constraints. They are used in applications that would require human expertise if such decision systems were not available. Human beings tend to be overwhelmed by a transient information overload resulting from an emergency situation, thus expert systems are increasingly used under many circumstances to assist human operators. As the complexity of tools and machineries increases, it is obvious that more intelligent and thus more complex embedded decision systems are expected to be developed and installed to monitor and control the environments in which they are embedded.
Since the solutions to many of these decision problems are often nondeterministic or cannot be easily expressed in algorithmic form, these applications increasingly employ rule-based (or knowledge-based) expert systems. In recent years, such systems are also increasingly used to monitor and control the operations of complex safety-critical real-time systems. This chapter gives an introduction to real-time expert systems by describing a class of these systems in which decisions are computed by propositional-logic rule-based programs implemented in the equational logic language EQL.
We begin by describing EQL and we present several examples. The notion of the state space of an equational rule-based program is then introduced. Next, we demonstrate the use of a set of analysis tools that have been implemented to perform timing and safety analyses of real-time equational rule-based programs. The theoretical formulation and solution strategies of the relevant analysis and synthesis problems are then given. Complexity issues of the various analysis and synthesis problems are also discussed. Next, we present the specification language Estella for customizing
259
260 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
the analysis tool. Finally, we describe quantitative algorithms for predicting the timing performance of rule-based systems.
To show that the analysis tools are practical enough to verify realistic real-time decision systems, we have used them to analyze several rule-based systems, including a subset of the Cryogenic Hydrogen Pressure Malfunction Procedure in the Pressure Control System of the Space Shuttle Vehicle [Helly, 1984]. This malfunction procedure is used to warn Shuttle pilots and operators of possible malfunctions of the pressure control system and to give helpful advice for correcting possible malfunctions.
10.1 REAL-TIME DECISION SYSTEMS
A real-time decision system interacts with the external environment by taking sensor readings and computing control decisions based on these readings and stored state information. We can characterize a real-time decision system by the following model with seven components:
1.a sensor vector x¯ X,
2.a decision vector y¯ Y ,
3.a system state vector s¯ S,
4.a set of environmental constraints A,
5.a decision map D, D : S × X → S × Y ,
6.a set of timing constraints T , and
7.a set of integrity constraints I .
In this model, X is the space of sensor input values, Y is the space of decision values, and S is the space of system state values. (We shall use x¯(t) to denote the value of the sensor input x¯ at time t, etc.)
The environmental constraints A are relations over X, Y, S and are assertions about the effect of a control decision on the external world which in turn affect future sensor input values. Environmental constraints are usually imposed by the physical environment in which the real-time decision system functions.
The decision map D relates y¯(t + 1), s¯(t + 1) to x¯(t), s¯(t); that is, given the current system state and sensor input, D determines the next decisions and system state values. For our purpose, decision maps are implemented by equational rulebased programs.
The decisions specified by D must conform to a set of integrity constraints I . Integrity constraints are relations over X, S, Y and are assertions that the decision map D must satisfy to ensure safe operation of the physical system under control. The implementation of the decision map D is subject to a set of timing constraints T which are assertions about how fast the map D has to be performed. Figure 10.1 illustrates the model of a real-time decision system.
Let us consider a simple example of a real-time decision system. Suppose we want to automate a toy race car so that it will drive itself around a track as fast as

REAL-TIME DECISION SYSTEMS |
261 |
_ |
|
A |
|
_ |
|
|
|||
|
|
|
||
|
|
|
||
x |
|
|
|
y |
|
|
|
|
|
D |
_ |
s |
• Environment constraints:
Arelates x¯(t + 1) with y¯(t)
•Decision system:
Drelates y¯(t + 1), s¯(t + 1) with x¯(t), s¯(t)
•D is subject to:
•integrity constraints I : assertions over s¯, y¯
•timing constraints T
Figure 10.1 A real-time decision system.
possible. The sensor vector consists of variables denoting the position of the car and the distance to the next obstacle ahead. The decision vector consists of two variables: one to indicate whether to accelerate, decelerate, or maintain the same speed, and another to indicate whether to turn left, turn right, or keep the same heading. The system state vector consists of variables denoting the current speed and heading of the car. The set of environmental constraints consists of assertions that express the physical laws governing where the next position of the car will be, given its current position, velocity, and acceleration. The integrity constraints are assertions restricting the acceleration and heading of the car so that it will stay on the race track and not run into an obstacle. The decision map may be implemented by some equational rulebased program. The input and decision variables of this program are respectively the sensor vector and decision vectors. The timing constraint consists of a bound on the length of the monitor-decide cycle of the program, that is, the maximum number of rule firings before a fixed point is reached.
There are two practical problems of interest with respect to this model:
1.Analysis problem: Does a given equational rule-based program satisfy the integrity and timing constraints of the real-time decision system?
2.Synthesis problem: Given an equational rule-based program that satisfies the integrity constraints but is not fast enough to meet the timing constraints, can we transform the given program into one that meets both the integrity and the timing constraints?
To investigate these problems, we first describe what real-time expert systems are and the EQL language. Then we formulate these problems in terms of a state-space representation of equational rule-based programs, in the next section.
262 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
10.2 REAL-TIME EXPERT SYSTEMS
The operations and functions of systems that rely on the computer for real-time monitoring and control have become increasingly complex. These embedded systems include airplane avionics (e.g., the Pilot Associate-driven aircraft and navigation systems [Bretz, 2002], automatic vehicle control systems [Bretz, 2001; Hamilton et al., 2001; Gavrila et al., 2001; Jones, 2002], fly-by-wire Airbus 330/340/380 and Boeing 777 [Yeh, 1998]), smart robots (e.g., the Autonomous Land Vehicle and the Boeing X-45A Unmanned Combat Air Vehicle), space vehicles (e.g., unmanned spacecrafts [Cass, 2001], the NASA Space Shuttle and satellites [Paulson, 2001], and the International Space Station), electric and communication grid monitoring centers, portable wireless devices [Smailagic, Siewiorek, and Reilly, 2001; Want and Schilit, 2001], and hospital patient-monitoring devices [Moore, 2002].
In addition to verifying functional/logical correctness requirements, a problem that has been more thoroughly studied with non-time-critical software systems, it is equally important to verify that these systems satisfy stringent response-time requirements. Based on input sensor values, the embedded expert system must make decisions within bounded time to respond to the changing external environment; the result of missing a deadline may inflict serious damage to the real-time system and may result in the loss of life and property. Therefore, it is essential to accurately determine an upper bound on the execution time of the embedded expert system before it is put into use.
The added complexity of timing requirements makes the design and maintenance of these systems particularly difficult. Few attempts have been made to formalize the question of whether rule-based systems can deliver adequate performance in bounded time. In this chapter, we provide a formal framework for answering this important question. We shall also describe a set of software tools that have been designed to ensure that programs for computing complex decisions in real time can indeed meet their specified timing constraints.
The class of real-time programs that are investigated herein are called equational rule-based (EQL) programs. An EQL program has a set of rules for updating variables that denote the state of the physical system under control. The firing of a rule computes a new value for one or more state variables to reflect changes in the external environment as detected by sensors. Sensor readings are sampled periodically. Every time sensor readings are taken, the state variables are recomputed iteratively by a number of rule firings until no further change in the variables can result from the firing of a rule. The EQL program is then said to have reached a fixed point. Intuitively, rules in an EQL program are used to express the constraints on a system and also the goals of the controller. If a fixed point is reached, the state variables have settled down to a set of values that are consistent with the constraints and goals as expressed by the rules.
EQL differs from the popular expert system languages such as OPS5 in some important ways. These differences reflect the goal of our work, which is not to invent yet another expert system shell but to investigate whether and how performance objectives can be met when rule-based programs are used to perform safety-critical

PROPOSITIONAL-LOGIC RULE-BASED PROGRAMS: THE EQL LANGUAGE |
263 |
functions in real time. Whereas the interpretation of a language like OPS5 is defined by the recognize-act cycle [Forgy, 1981], the basic interpretation cycle of EQL is defined by fixed-point convergence. The fixed-point semantics of EQL follow closely that of the language Unity developed by Chandy and Misra. It is our belief that the time it takes to converge to a fixed point is a more pertinent measure of the response time of a rule-based program than the length of the recognize-act cycle. More importantly, we do not require the firing of rules that lead to a fixed point to be implemented sequentially; rules can be fired in parallel if they do not interfere with one another. The definition of response time in terms of fixed-point convergence is architectureindependent and is therefore more robust.
In view of the safety-critical functions that computers are beginning to be relied upon to perform in real time, it is incumbent upon us to ensure that some acceptable performance level can be provided by a rule-based program, subject to reasonable assumptions about the quality of the input.
10.3PROPOSITIONAL-LOGIC RULE-BASED PROGRAMS: THE EQL LANGUAGE
An EQL program is organized like the following model:
PROGRAM name; CONST declaration; VAR declaration; INPUTVAR declaration; INIT
statement,
statement,
:
:
statement
INPUT
READ variable list
RULES
rule [] rule
:
:
[] rule TRACE variable list PRINT variable list END.
An EQL program is composed of four major distinct sections: the declaration section, the initialization section, the rule section, and the output section. The syntax of EQL follows closely that of the language Pascal. EQL programs are an entirely free