
- •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
COMPUTER-AIDED DESIGN TOOLS |
275 |
launch state. If the EQL program indeed reaches a fixed point in a finite number of iterations starting from any launch state, ptaf informs the designer accordingly. Otherwise, ptaf stops at the first launch state for which the program may not reach a fixed point in a finite number of iterations and informs the designer about the unstable launch state.
The module mcf is a temporal-logic model checker based on the Clarke– Emerson–Sistla algorithm for checking the satisfiability of temporal-logic formulas written in CTL [Clarke, Emerson, and Sistla, 1986]. Our model checker assumes that strong fairness is observed by the scheduler; that is, rules that are enabled infinitely often will eventually fire. Under this assumption, a cycle in the state-space graph that has at least one edge exiting from it is not sufficient to cause the program not to reach a fixed point in a finite number of iterations. (The program will leave the states in the cycle because the rule associated with the exit edge must eventually fire.) However, the model checker will warn the designer that the program may require a finite but unbounded number of iterations to reach a fixed point. The default scheduler used to schedule the next enabled rule to fire is fair and is based on a linear-congruential pseudo–random number generator.
The module fptime is a timing analyzer that computes the maximum number of iterations for a given program to reach a fixed point if at least one reachable fixed point exists. In addition, it provides the sequence of rule firings leading from the launch state to this fixed point. It can also compute the number of iterations to any other fixed point and the corresponding sequence of rule firings if the designer so desires. fptime has been designed so that a designer will be able to specify restrictions on the scheduler if it is desired to determine how the specified scheduling restrictions may affect the number of rule firings. This is useful for investigating the performance of customized schedulers.
10.5.1 Analysis Example
We now describe how our tools can be applied to the distributed EQL program of example 2. With the EQL-to-C translator eqtc, we can translate the equational rulebased program in example 2 into a C program by invoking the command
eqtc < example2 > example2.c.
This program can be compiled using a C compiler (the cc command in UNIX) and then executed to obtain the stable output values if a fixed point is reachable in a finite number of iterations. The current version of eqtc simulates the reading of external sensors by initializing the input variables before any rule is fired. The C program generated by the eqtc translator is shown below.
#include <stdio.h> #include "scheduler.c" #define maxseq 24 #define false 0 #define true 1
#define a 0
276 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
#define b 1 int znext,
randseq[maxseq],
counter;
main() {
extern int znext, randseq[maxseq], counter;
int i;
int sync_a, sync_b, wake_up, object_detected; int arbiter;
int sensor_a, sensor_b;
sync_a = true; sync_b = true; wake_up = true; arbiter = a; sensor_a = 1; sensor_b = 0;
init_random_seq(randseq, &znext, z0, &counter); while (!fixed_point())
{i = schedule(randseq, &znext, 6); switch(i) {
case 1:
if ((sensor_a == 1) && (arbiter == a) && (sync_a == true) && (wake_up == true)) {
object_detected = true; sync_a = false;
}
break; case 2:
if ((sensor_a == 0) && (arbiter == a) && (sync_a == true) && (wake_up == true)) {
object_detected = false; sync_a = false;
}
break; case 3:
if ((arbiter == a) && (sync_a == false) && (wake_up == true)) { arbiter = b;
sync_a = true; wake_up = false;
}
break; case 4:
if ((sensor_b == 1) && (arbiter == b) && (sync_b == true) && (wake_up == true)) {
object_detected = true; sync_b = false;
}
break;
COMPUTER-AIDED DESIGN TOOLS |
277 |
case 5:
if ((sensor_b == 0) && (arbiter == b) && (sync_b == true) && (wake_up == true)) {
object_detected = false; sync_b = false;
}
break; case 6:
if ((arbiter == b) && (sync_b == false) && (wake_up == true)) { arbiter = a;
sync_b = true; wake_up = false;
}
break;
}
printf(" object_detected = %d\\n", object_detected);
}
printf(" object_detected = %d\\n", object_detected);
}
The EQL program with the initial input values can be translated into a finite statespace graph by using the ptf translator with the command:
ptf < example2.
ptf generates the following output for user reference:
Finite State Space Graph Corresponding to Input Program:
--------------------------------------------------------
state next states
----------------
rule # 1 2 3 4 5 6
0:1 0 0 0 0 0
1:1 1 2 1 1 1
2:2 2 2 2 2 2
State Labels:
-------------
state (sync_a, sync_b, wake_up, object_detected, arbiter, sensor_a, sensor_b)
0 1 1 1 0 0 1 0
1 0 1 1 1 0 1 0
21 1 0 1 1 1 0
ptf also generates a CTL temporal-logic formula for checking whether this program will reach a fixed point in finite time from the launch state corresponding to the initial input and program variable values. This formula is stored in the file mc.in, which is generated as input to the model checker and the timing analyzer. mc.in contains the adjacency matrix representation of the labeled state-space graph.
278 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
3
1 1 0
0 1 1
0 0 1
0 n1 ;
1 n1 ;
2 f1 ;
(au n1 f1) 0
The temporal-logic model checker mcf can then be used to determine whether a fixed point is always reachable in a finite number of iterations by analyzing this finite statespace graph with the given launch state:
mcf < mc.in.
To verify that the program will reach a fixed point from any launch state, the (finite) reachability graph of every launch state must be analyzed by the model checker. The complete state-space graph of the example EQL program, which consists of eight separate finite reachability graphs, one for each distinct launch state, is shown in Figure 10.5. The graph with launch state (3,0), corresponding to the combination of input values and initial program values specified in the C program, is one of 23 = 8 possible graphs that must be checked by the model checker.
In general, for a finite-domain EQL program with n input variables and m program variables, the total number of reachability graphs that have to be checked in the worst case (i.e., all combinations of the values of the input and program variables are possible) is
i=n j=m
|Xi | · |S j |
i=1 j=1
where |Xi |, |S j | are respectively the size of the domains of the ith input and jth program variable. If all variables are binary, this number is 2n+m . In practice, the number of reachability graphs that must be checked is substantially less because many combinations of input and program variable values do not constitute launch states. Other techniques are also available that do not require examination of the entire state-space graph. They will be discussed in the next section.
Finally, the timing analyzer fptime can be invoked to determine the longest sequence of rule firings leading to a fixed point, if at least one exists, by the command:
fptime < mc.in.
The following is the partial output of the fptime module corresponding to the reachability graph with launch state (3, 0):

|
|
|
|
COMPUTER-AIDED DESIGN TOOLS |
279 |
|||
|
state (1,0) |
|
state (2,0) |
|
state (3,0) |
|
state (4,0) |
|
t,t,t,-,a,0,0 |
t,t,t,-,a,0,1 |
t,t,t,-,a,1,0 |
t,t,t,-,a,1,1 |
|
||||
rule 2 |
state (1,1) |
rule 2 |
state (2,1) |
rule 1 |
state (3,1) |
rule 1 |
state (4,1) |
|
|
|
|
|
|||||
f,t,t,f,a,0,0 |
f,t,t,f,a,0,1 |
f,t,t,t,a,1,0 |
f,t,t,t,a,1,1 |
|
||||
rule 3 |
state(1,2) |
rule 3 |
state(2,2) |
rule 3 |
state(3,2) |
rule 3 |
state(4,2) |
|
|
|
|
|
|||||
t,t,f,f,b,0,0 |
t,t,f,f,b,0,1 |
t,t,f,t,b,1,0 |
t,t,f,t,b,1,1 |
|
||||
|
state (5,0) |
|
state (6,0) |
|
state (7,0) |
|
state (8,0) |
|
t,t,t,-,b,0,0 |
t,t,t,-,b,0,1 |
t,t,t,-,b,1,0 |
t,t,t,-,b,1,1 |
|
||||
rule 5 |
state (5,1) |
rule 4 |
state (6,1) |
rule 5 |
state (7,1) |
rule 4 |
state (8,1) |
|
|
|
|
|
|||||
t,f,t,f,b,0,0 |
t,f,t,t,b,0,1 |
t,f,t,f,b,1,0 |
t,f,t,t,b,1,1 |
|
||||
rule 6 |
state(5,2) |
rule 6 |
state(6,2) |
rule 6 |
state(7,2) |
rule 6 |
state(8,2) |
|
|
|
|
|
|||||
t,t,f,f,a,0,0 |
t,t,f,t,a,0,1 |
t,t,f,f,a,1,0 |
t,t,f,t,a,1,1 |
|
||||
|
state = ( sync_a, sync_b, wake_up, object_detected, arbiter, sensor_a, sensor_b |
) |
||||||
|
t = TRUE, f = FALSE, a = name of process A, b = name of process B, - = don’t care |
Figure 10.5 Complete finite state-space graph representing the program example2.
> initial state: 0
>fixed-point state(s):
>2
>initial state: 0 fixed-point state: 2
>maximum number of iterations: 2
> path: 0 1 2
The module ptaf performs the above translation and analysis on the complete state-space graph of the example EQL program automatically. The command:
ptaf < example2
produces the following messages:
>The program always reaches a fixed point in finite time.
>The maximum number of iterations to reach a fixed point is 2.
>8 FSMs checked.
In the next two sections, we shall discuss the complexity of the analysis and synthesis problems of real-time equational rule-based programs. In the appendix, we shall illustrate the practicality of our tools by analyzing a “real-life” real-time decision system: the Cryogenic Hydrogen Pressure Malfunction Procedure of the Space Shuttle Vehicle Pressure Control System [Helly, 1984].