
- •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
284 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
Example 3. This program satisfies condition CR1:
input: read(b, c)
1.a1 := true IF b = true
2.[] a2 := false IF c = true
Example 4. This program satisfies condition CR2:
input: read(b, c)
1.a1 := true IF b = true AND c = true
2.[] a1 := true IF b = true AND c = false
3.[] a2 := false IF c = true
Example 5. This program satisfies condition CR3:
input: read(b, c)
1.a1 := true IF b = true
2.[] a1 := true IF c = true
The utility of the special form above might seem quite limited since the three conditions of the special form must be satisfied by the complete set of rules in a program. However, the main use of the special form in our analysis tools is not to identify special-case programs. The leverage of the special form comes about when we can apply it to a subset of rules and conclude that at least some of the variables must attain stable values in finite time. The exploitation of the special form in a general strategy will be explained in the next section.
10.6.3 The General Analysis Strategy
Our general strategy for tackling the analysis problem is best understood by an example.
Example 6
input: read(b, c)
1.a1 := true IF b = true AND c = true
2.[] a1 := true IF b = true AND c = false
3.[] a2 := false IF c = true
4.[] a3 := true IF a1 = true AND a2 = false
5.[] a4 := true IF a1 = false AND a2 = false
6.[] a4 := false IF a1 = false AND a2 = true
THE ANALYSIS PROBLEM |
285 |
For this program, L ∩ T = and thus the rules are not of the special form described in the preceding section. However, observe that rules 1, 2, and 3 by themselves are of the special form and that all the variables in these rules do not appear in LHS of the rest of the rules of the program, and thus will not be modified by them. (Rules 1, 2, and 3 are actually the rules in the program of example 4.) We can readily conclude that the variables a1 and a2 must attain stable values in finite time, and these two variables can be considered as constants for rules 4, 5, and 6 of the program. We can take advantage of this observation and rewrite the program into a simpler one, as shown below.
input: read(a1, a2)
4.[] a3 := true IF a1 = true AND a2 = false
5.[] a4 := true IF a1 = false AND a2 = false
6.[] a4 := false IF a1 = false AND a2 = true
Note that a1 and a2 are now treated as input variables. This reduced program is of the special form since all assignments are to constants, L and T are disjoint, and all tests are mutually exclusive. Hence this program is always guaranteed to reach a fixed point in finite time. This guarantees that the original program must reach a fixed point in finite time.
In fact, more special forms can be exploited in the above fashion. Our general strategy for tackling the analysis problem is as follows.
1.Identify some subset of the rules that is of a special form (determined by looking up a catalog of special forms) and that can be treated independently. Rewrite the program to take advantage of the fact that some variables can be treated as constants because of the special form.
2.If none of the special forms applies, identify an independent subset of the rules and check the state space for that subset to determine if a fixed point can always be reached. Rewrite the program as in (1) to yield simpler programs (with fewer rules) if possible.
3.Perform an analysis on each of the programs resulting from (1) or (2).
In the appendix, we present an analysis of the Cryogenic Hydrogen Pressure Malfunction Procedure of the Space Shuttle Vehicle Pressure Control System. By performing a simple transformation (rewriting) on the subset of this program, we can actually obtain an equivalent program that is of the special form. The transformation consists of replacing those test variables that also appear in the LHS by their corresponding test expressions as long as the tests do not contain any LHS variables. (The replacement for some test variables may involve more than one level of substitution of variables. Both the original version and the transformed version of the program appear in the appendix.) As a result, the transformed program satisfies special form condition (3), whereas the original version does not. All rules in the transformed pro-
286 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
gram are compatible and the program is always guaranteed to reach a fixed point in a finite number of iterations.
We are incorporating more powerful textual analysis procedures into our suite of design tools as they are discovered. A more comprehensive treatment of special forms that guarantee that an EQL program will always reach a fixed point in finite time, together with formal proofs of correctness, will be given later in this chapter.
10.7INDUSTRIAL EXAMPLE: ANALYSIS OF THE CRYOGENIC HYDROGEN PRESSURE MALFUNCTION PROCEDURE OF THE SPACE SHUTTLE VEHICLE PRESSURE CONTROL SYSTEM
In this section, we analyze a “real-life” real-time decision system using our analysis tools. The real-time decision system is called the Cryogenic Hydrogen Pressure Malfunction Procedure of the Space Shuttle Vehicle Pressure Control System. It is invoked in every monitor-decide cycle to diagnose the condition of the Cryogenic Hydrogen Pressure Control System and to give advice for correcting the diagnosed malfunctions. The complete EQL program for this malfunction procedure consists of 36 rules, 31 sensor input variables, and 32 program variables. We have verified, using our analysis tools, that a large subset of this decision system is guaranteed to reach a safe fixed point in a finite number of iterations. The EQL program for this subset, given below, consists of 23 rules, 20 sensor input variables, and 23 program variables. Understanding the meaning of most of these sensor input and program variables requires specialized knowledge of the pressure control system, but this is not essential for understanding this example.
Define the following sensor input variables:
v63a1a |
sensor H2 P Normal. |
v63a1b |
sensor H2 P High. |
v63a1c |
sensor H2 P Low. |
v63a3 |
sensor Press in all tks < 153 psia. |
v63a5 |
sensor Both P and TK P of affected tk low. |
v63a8 |
sensor Received O2 PRESS Alarm and/or S68 CRYO H2 PRES and |
|
S68 CRYO 2 PRES msg lines. |
v63a11 |
sensor TK3 and/or TK4 the affected tk. |
v63a12 |
sensor TK3 and TK4 depleted, QTY < 10%. |
v63a13 |
sensor a13. |
v63a16 |
sensor CNTLR cb of affected tk on Pnl ML868 open. |
v63a17 |
sensor TK3 and TK4 Htrs cycle on when press in both tks = 217–223 psia. |
v63a22 |
sensor a22. |
v63a23 |
sensor TK3 and/or TK4 the affected tk. |
v63a26 |
sensor TK3 and TK4 htrs were deactivated (all htrs switches |
|
in OFF when the problem occurred). |
v63a29 |
sensor Press in both TK3 and TK4 > 293.8 psia. |
v63a31 |
sensor Both P and TK P of affected tk high. |
|
INDUSTRIAL EXAMPLE |
287 |
v63a32 |
sensor MANF Ps agree with P and TK P of affected TK. |
|
v63a34a |
sensor P high. |
|
v63a34b |
sensor TK P high. |
|
v63b7 |
sensor b7. |
|
Define the following program variables:
v63a2 diagnosis: C/W failure.
v63a4 diagnosis: System leak. Execute ECLS SSR-1(7).
v63a6 diagnosis: Leak between affected TK and check valve. Leak cannot be isolated. v63a7 action: Deactivate htrs in affected tk.
v63a9 recovery: Reconfigure htrs per BUS LOSS SSR. v63a10 temporary variable.
v63a14 if true, then CNTLR cb of affected tk (TK1 and/or TKS) on Pnl 013 is open. if false, then CNTLR cb of affected tk (TK1 and/or TK2) on Pnl 013 is closed.
v63a15 diagnosis: Possible electrical problem. Do not attempt to reset circuit breaker. v63a18 diagnosis: P 63axduce failed low. Continue to operate TK3 and TK4 in AUTO. v63a19 diagnosis: Possible electrical problem. Do not attempt to reset circuit breaker. v63a20 diagnosis: PWR failure in affected HTR CNTLR.
v63a21 action: deactivate htrs in affected tk(s).
v63a24 diagnosis: P Xducer failed low. Continue to operate TK1 and TK2 in AUTO. v63a25 diagnosis: PWR failure in affected htr cntlr.
v63a27 diagnosis: Instrumentation failure. No action required. v63a28 action: Operate TK1 and TK2 htrs in manual mode. v63a30 diagnosis: Auto pressure control failure.
v63a33 diagnosis: Line blockage in tk reading high. v63a35 diagnosis: Auto pressure control or RPC failure. v63a36 diagnosis: Instrumentation failure.
v63a37 action: Leave affected htrs deactivated until MCC develops consumables management plan.
v63a38 diagnosis: Instrumentation failure. v63a39 action: Activate htrs.
The syntax of EQL is similar to Pascal with declarations of constants and variables. Input variables are declared in the INPUTVAR section. The INIT part initializes the program variables as well as the input variables. As indicated previously, since EQL is used for the design and analysis of real-time decision systems, the current version simulates the reading of external sensors by initializing the input variables before any rule is fired in the invocation. In an actual implementation of the real-time decision system, the EQL program should read in the input values from sensors attached to the external environment before each invocation of the set of rules. The RULES part specifies the set of rules of the program. The TRACE statement instructs the program to print out the values of the specified variables after every rule firing, and the PRINT statement prints out the values of the specified variables after the program reaches a fixed point. The EQL program for the subset of the malfunction procedure is:
288 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
PROGRAM cryov63a; CONST
true = 1; false = 0;
VAR
v63a2, v63a4, v63a6, v63a7, v63a9, v63a10, v63a14, v63a15, v63a18, v63a19, v63a20, v63a21, v63a24, v63a25, v63a27, v63a28, v63a30, v63a33, v63a35, v63a36, v63a37, v63a38, v63a39 : BOOLEAN;
INPUTVAR
v63a1a, v63a1b, v63a1c, v63a3, v63a5, v63a8, v63a11, v63a12, v63a13, v63a16, v63a17, v63a22, v63a23, v63a26, v63a29, v63a31, v63a32, v63a34a, v63a34b, v63b7 : BOOLEAN;
INIT
v63a2 := false, v63a4 := false, v63a6 := false, v63a7 := false, v63a9 := false, v63a14 := false, v63a15 := false, v63a18 := false, v63a19 := false, v63a20 := false, v63a21 := false, v63a10 := false, v63a24 := false, v63a25 := false, v63a27 := false, v63a28 := false, v63a30 := false, v63a33 := false, v63a35 := false, v63a36 := false, v63a37 := false, v63a38 := false, v63a39 := false,
v63a1a := true, v63a1b := true, v63a1c := true, v63a3 := true, v63a5 := true, v63a8 := true, v63a11 := true, v63a12 := true, v63a13 := true, v63a16 := true, v63a17 := true, v63a22 := true, v63a23 := false, v63a26 := true, v63a29 := false, v63a31 := true, v63a32 := false, v63a34a := true, v63a34b := true, v63b7 := true
RULES
v63a2 := true IF (v63a1a = true)
[]v63a4 := true IF (v63a1c = true) AND (v63a3 = true)
[]v63a6 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = true) []v63a7 := true IF (v63a6 = true)
[]v63a9 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = true)
[]v63a10 := true IF (v63a9 = true)
[]v63a14 := true IF (v63a12 = true) OR ((v63a12 = false) AND (v63a13 = true)) []v63a15 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND
(v63a8 = false) AND (v63a11 = false) AND (v63a12 = true) AND (v63a14 = true)
[]v63a18 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = false) AND (v63a11 = true) AND
(v63a16 = true) AND (v63a17 = true)
[]v63a19 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = false) AND (v63a11 = true) AND (v63a16 = true)
[]v63a20 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = false) AND (v63a11 = true) AND
(v63a16 = true) AND (v63a17 = false) []v63a21 := true IF (v63a19 = true) OR (v63a20 = true)
[]v63a24 := true IF (v63a22 = true) AND (v63a14 = false) AND (v63a12 = true) AND (v63a11 = false) AND (v63a8 = false) AND (v63a5 = false) AND (v63a3 = false) AND (v63a1c = true)
INDUSTRIAL EXAMPLE |
289 |
[]v63a25 := true IF (v63a22 = false) AND (v63a14 = false) AND (v63a12 = true) AND (v63a11 = false) AND (v63a8 = false) AND (v63a5 = false) AND
(v63a3 = false) AND (v63a1c = true)
[]v63a27 := true IF (v63a26 = true) AND (((v63a23 = true) AND (v63a1b = true)) OR (v63b7 = true))
[]v63a28 := true IF (v63a25 = true) OR (v63a15 = true)
[]v63a30 := true IF (((v63a1b = true) AND (v63a23 = true)) OR (v63b7 = true)) AND (v63a26 = false) AND (v63a29 = true)
[]v63a33 := true IF (v63a32 = false) AND (v63a31 = true) AND (v63a29 = false) AND (v63a26 = false) AND (v63a23 = true) AND (v63a1b = true)
[]v63a35 := true IF (v63a32 = true) AND (v63a31 = true) AND (v63a29 = true) AND (v63a26 = false) AND (v63a23 = true) AND (v63a1b = true)
[]v63a36 := true IF (v63a34b = true) AND (v63a31 = false) AND
(v63a29 = false) AND (v63a26 = false) AND (v63a23 = true) AND (v63a1b = true)
[]v63a37 := true IF (v63a30 = true) AND (v63a33 = false) AND (v63a35 = false) AND (v63a38 = true)
[]v63a38 := true IF (v63a34a = true) AND (v63a31 = false) AND
(v63a29 = false) AND (v63a26 = false) AND (v63a23 = true) AND (v63a1b = true)
[]v63a39 := true IF (v63a36 = true)
TRACE
v63a2, v63a4, v63a6, v63a7, v63a9, v63a10, v63a14, v63a15, v63a18, v63a19, v63a20, v63a21, v63a24, v63a25, v63a27, v63a28, v63a30, v63a33, v63a35, v63a36, v63a37, v63a38, v63a39
v63a2, v63a4, v63a6, v63a7, v63a9, v63a10, v63a14, v63a15, v63a18, v63a19, v63a20, v63a21, v63a24, v63a25, v63a27, v63a28, v63a30, v63a33, v63a35, v63a36, v63a37, v63a38, v63a39
END.
To execute the EQL program on the Sun 3 workstation for a particular set of sensor input values given in the INIT section of the program, we translate it into a C program using the eqtc translator: eqtc example example.c. This program can be compiled using the cc compiler and then executed to obtain the stable output values if a fixed point exists. Note that a scheduler is used to determine the next enabled rule to fire, and the program will continue execution as long as the fixed point has not been reached. Due to space limitations, we omit the listing of the generated C program, which is similar to the one given in section 10.5.
To analyze the performance of the program given a particular combination of sensor input values, the EQL program with the given input is transformed into a finite state–space graph using the ptf translator by using the command: ptf example example.fsg. It also generates a CTL temporal-logic formula for checking whether this program will reach a fixed point in bounded time using the given input. The file mc.in is generated as input to the model checker and the timing analyzer.
290 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
Finite State Space Graph Corresponding to Input Program:
--------------------------------------------------------
state next states
----------------
rule # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
0:1 2 0 0 0 0 3 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0
1:1 5 1 1 1 1 6 1 1 1 1 1 1 1 7 1 1 1 1 1 1 1 1
2:5 2 2 2 2 2 8 2 2 2 2 2 2 2 9 2 2 2 2 2 2 2 2
3:6 8 3 3 3 3 3 3 3 3 3 3 3 3 10 3 3 3 3 3 3 3 3
4:7 9 4 4 4 4 10 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
5:5 5 5 5 5 5 11 5 5 5 5 5 5 5 12 5 5 5 5 5 5 5 5
6:6 11 6 6 6 6 6 6 6 6 6 6 6 6 13 6 6 6 6 6 6 6 6
7:7 12 7 7 7 7 13 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
8:11 8 8 8 8 8 8 8 8 8 8 8 8 8 14 8 8 8 8 8 8 8 8
9:12 9 9 9 9 9 14 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
10:13 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
11:11 11 11 11 11 11 11 11 11 11 11 11 11 11 15 11 11 11 11 11 11 11 11
12:12 12 12 12 12 12 15 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
13:13 15 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13
14:15 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14
15:15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15
State Labels:
-------------
state (v63a2, v63a4, v63a6, v63a7, v63a9, v63a10, v63a14, v63a15, v63a18, v63a19, v63a20, v63a21, v63a24, v63a25, v63a27, v63a28, v63a30, v63a33, v63a35, v63a36, v63a37, v63a38, v63a39, v63a1a, v63a1b, v63a1c, v63a3, v63a5, v63a8, v63a11, v63a12, v63a13, v63a16, v63a17, v63a22, v63a23, v63a26, v63a29, v63a31, v63a32, v63a34a, v63a34b, v63b7)
00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
20 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
30 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
40 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
51 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
61 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
71 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
80 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
90 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
INDUSTRIAL EXAMPLE |
291 |
100 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
111 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
121 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
131 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
140 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
151 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
0 1 0 1 0 1 1 1
The file mc.in contains the adjacency matrix representation of the labeled finite statespace graph and a CTL formula for checking the reachability of a fixed point.
16
1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0
0 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0
0 0 1 0 0 1 0 0 1 1 0 0 0 0 0 0
0 0 0 1 0 0 1 0 1 0 1 0 0 0 0 0
0 0 0 0 1 0 0 1 0 1 1 0 0 0 0 0
0 0 0 0 0 1 0 0 0 0 0 1 1 0 0 0
0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 0
0 0 0 0 0 0 0 0 1 0 0 1 0 0 1 0
0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 0
0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0
0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1
0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1
0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 n1 ;
1 n1 ;
2 n1 ;
3 n1 ;
4 n1 ;
5 n1 ;
6 n1 ;
7 n1 ;
8 n1 ;
9 n1 ;
10 n1 ;
11 n1 ;
12 n1 ;
13 n1 ;
14 n1 ;
15 f1 ; (au n1 f1) 0
292 DESIGN AND ANALYSIS OF PROPOSITIONAL-LOGIC RULE-BASED SYSTEMS
The temporal-logic model checker mcf is then used to determine whether a fixed point is reachable in a bounded number of iterations by analyzing this finite statespace graph with the specified launch state: mcf < mc.in. To verify that the program is guaranteed to reach a fixed point given any legal combination of input values, all finite state-space graphs, each with a different launch state must be analyzed by the model checker. Therefore, the above graph is one of 220 possible graphs that must be checked using the model checker if all combinations of the 20 input values are allowed. The tool ptaf automatically performs the above translation and analysis on all state-space graphs corresponding to the EQL program.
Finally, the timing analyzer fptime is invoked to determine, for the particular set of input values, the number of rule firings and the sequence of rule firings leading to a fixed point, if at least one exists: fptime < mc.in. The following is a partial output from fptime:
> initial state: 0
>fixed-point state(s):
>15
>initial state: 0 fixed-point state: 15
>maximum number of iterations: 4
> path: |
0 |
1 |
5 11 15 |
Using the completely automated tool ptaf, we obtain the following messages:
>The program always reaches a fixed point in finite time.
>The maximum number of iterations to reach a fixed point is 6.
Applying the transformation described earlier to the above program, we obtain the following equivalent program, which falls into a subclass of EQL programs for which the question of bounded-time fixed-point reachability can be easily answered by performing a simple textual analysis and without generating the corresponding state-space graph. This equivalent program is of the special form described earlier. Notice that all LHS variables are distinct. Hence, all rules in this program are compatible and thus the program is always guaranteed to reach a fixed point in a bounded number of iterations.
PROGRAM cryov63a; CONST
true = 1; false = 0;
VAR
v63a2, v63a4, v63a6, v63a7, v63a9, v63a10, v63a14, v63a15, v63a18, v63a19, v63a20, v63a21, v63a24, v63a25, v63a27, v63a28, v63a30, v63a33, v63a35, v63a36, v63a37, v63a38, v63a39 : BOOLEAN;
INPUTVAR
v63a1a, v63a1b, v63a1c, v63a3, v63a5, v63a8, v63a11, v63a12, v63a13, v63a16, v63a17, v63a22, v63a23, v63a26, v63a29, v63a31, v63a32, v63a34a, v63a34b, v63b7 : BOOLEAN;
INDUSTRIAL EXAMPLE |
293 |
INIT
v63a2 := false, v63a4 := false, v63a6 := false, v63a7 := false, v63a9 := false, v63a14 := false, v63a15 := false, v63a18 := false, v63a19 := false, v63a20 := false, v63a21 := false, v63a10 := false, v63a24 := false, v63a25 := false, v63a27 := false, v63a28 := false, v63a30 := false, v63a33 := false, v63a35 := false, v63a36 := false, v63a37 := false, v63a38 := false, v63a39 := false,
v63a1a := true, v63a1b := true, v63a1c := true, v63a3 := true, v63a5 := true, v63a8 := true, v63a11 := true, v63a12 := true, v63a13 := true, v63a16 := true, v63a17 := true, v63a22 := true, v63a23 := false, v63a26 := true, v63a29 := false, v63a31 := true, v63a32 := false, v63a34a := true, v63a34b := true, v63b7 := true
RULES
v63a2 := true IF (v63a1a = true)
[]v63a4 := true IF (v63a1c = true) AND (v63a3 = true)
[]v63a6 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = true) []v63a7 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = true) []v63a9 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND
(v63a8 = true)
[]v63a10 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = true)
[]v63a14 := true IF (v63a12 = true) OR ((v63a12 = false) AND (v63a13 = true)) []v63a15 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND
(v63a8 = false) AND (v63a11 = false) AND (v63a12 = true) AND ((v63a12 = true) OR ((v63a12 = false) AND (v63a13 = true)))
[]v63a18 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = false) AND (v63a11 = true) AND (v63a16 = true) AND (v63a17 = true)
[]v63a19 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = false) AND (v63a11 = true) AND (v63a16 = true)
[]v63a20 := true IF (v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = false) AND (v63a11 = true) AND (v63a16 = true) AND (v63a17 = false)
[]v63a21 := true IF ((v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = false) AND (v63a11 = true) AND (v63a16 = true)) OR ((v63a1c = true) AND (v63a3 = false) AND (v63a5 = false) AND (v63a8 = false) AND (v63a11 = true) AND (v63a16 = true) AND (v63a17 = false))
[]v63a24 := true IF (v63a22 = true) AND
((v63a12 = true) OR ((v63a12 = false) AND (v63a13 = true))) AND (v63a12 = true) AND (v63a11 = false) AND (v63a8 = false) AND (v63a5 = false) AND (v63a3 = false) AND (v63a1c = true)
[]v63a25 := true IF (v63a22 = false) AND
(v63a12 = true) OR ((v63a12 = false) AND (v63a13 = true)) AND (v63a12 = true) AND (v63a11 = false) AND (v63a8 = false) AND (v63a5 = false) AND (v63a3 = false) AND (v63a1c = true)
[]v63a27 := true IF (v63a26 = true) AND (((v63a23 = true) AND (v63a1b = true)) OR (v63b7 = true))