- •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
248 PROCESS ALGEBRA
The close operator is used to assign private resources to a process.
Close
CloseT
A1
P−→P
A1 A2
[P]I −→ [P ]I
where A2 = {(r, 0)|r I − s(A1)}. CloseI
(a,n)
P−→P
(a,n)
[P]I −→[P ]I
The recursion operator Rec is used to specify infinite behaviors via recursion.
Recursion
Rec
e
P[recX.P/ X]−→P
e
recX.P−→P
The operator recX.P indicates recursion, and P[recX.P/ X] means the substitution of recX.P for every free occurrence of X in P. This operator is used to specify infinite behaviors such as a system are always idle or a system never deadlocks.
Example. The second part of following statement specifies that the system is forever idle.
Radar \ \{cpu1, cpu2} ≈π recX. : X
9.4.3 Example Airport Radar System
An airport radar and signal processing system is a hard real-time system. Here, we use ACSR to specify and analyze a simplified radar system. At any given time, four airplanes are approaching the airport runway and hence are detected and tracked by the airport radar. These airplanes are said to be within the approach range of the radar. Planes that have landed leave the radar tracking range. For each plane detected in the approach range, signal processing must be performed to compute vital data such as altitude and speed of the plane, and to display its graphical representation on the radar screen.
The signal processing for each tracked plane is done by a corresponding process. Obviously, a plane that is closer to the airport must be checked more often to guarantee a safe landing since there is usually more air traffic. Therefore, a process handling a closer plane must be executed more often than one handling a plane that is farther away. This means the first process has a shorter period than the second pro-
ALGEBRA OF COMMUNICATING SHARED RESOURCES |
249 |
cess. Hence, we assign a higher priority to the process associated with a closer plane and a lower priority to the process associated with a plane that is farther away.
This scheduling strategy follows that of rate-monotonic policy (described in chapter 3), which assigns a static priority to a process; this priority is inversely proportional to the period of the process, that is, a process with a shorter period has a higher priority. In a more realistic radar system, the periods of the signal processing processes should be dynamic and decrease as their corresponding tracked planes get closer to the airport runway. However, for simplicity, let us assume that these periods are fixed. In fact, the latest version of ACSR cannot yet handle dynamic priorities. In this specification, we also assume that context-switching due to preemption of processes takes no time and an instance of a process is ready at the start of its period. We are now ready to show the ACSR specification of this radar system.
def
Radar =[(Scheduler T1 T2 T3 T4) \ {s1, s2, s3, s4}]{cpu1,cpu2}
def
Scheduler = S1 S2 S3 S4
def |
|
, 1). p1 |
|
S1 =( |
s1 |
: S1 |
|
def |
|
, 1). p2 |
|
S2 =( |
s2 |
: S2 |
|
def |
|
, 1). p3 |
|
S3 =( |
s3 |
: S3 |
|
def |
|
, 1). p4 |
|
S4 =( |
s4 |
: S4 |
def
T1 =(s1, 1).C1,0
def
T2 =(s2, 2).C2,0
def
T3 =(s3, 3).C3,0
def
T4 =(s4, 4).C4,0
def
C1, j = : C1, j + {(cpu1, 1)} :
def
C1,c1 = : C1,c1 + T1
def
C2, j = : C2, j + {(cpu1, 2)} :
def
C2,c2 = : C2,c2 + T2
def
C3, j = : C3, j + {(cpu1, 3)} :
def
C3,c3 = : C3,c3 + T3
def
C4, j = : C4, j + {(cpu1, 4)} :
def
C4,c4 = : C4,c4 + T4
C1, j+1 + {(cpu2, 1)} : C1, j+1,
C2, j+1 + {(cpu2, 3)} : C2, j+1,
C3, j+1 + {(cpu2, 3)} : C3, j+1,
C4, j+1 + {(cpu2, 4)} : C4, j+1,
0 ≤ j < c1
0 ≤ j < c2
0 ≤ j < c3
0 ≤ j < c4
250 PROCESS ALGEBRA
The first line (Radar) specifies that the scheduler and signal-processing processes (Scheduler, T1, T2, T3, T4) use only resources in {cpu1, cpu2}, that is, cpu1 and cpu2. It also says that the behavior of Scheduler and the four processes are limited by the events in {s1, s2, s3, s4}. The next five lines (pertaining to Scheduler) specify the instantiations of these four signal-processing processes. More precisely, Scheduler periodically instantiates a process Ti as follows. First, process Si signals process Ti to start (become ready) by sending the event si . Then Si stays idle for the period pi of the process before sending si again. The next four lines specify the priorities of the four processes in using a cpu according to the rate-monotonic algorithm. For other types of scheduling algorithms, we can easily change these priorities, which are associated with actions. As soon as signaled to start, each process Ti attempts to execute for ci time units using either cpu resource cpu1 or cpu2.
The next eight lines show that a process may remain idle (no cpu usage) or may use either cpu1 or cpu2. In the first case, process Ti idles by executing the process: Ci, j , which also means that Ti is preempted since it has lower priority. In the second case, the processes Ci, j update the computation times used by process Ti in each cpu. Each process Ci,ci specifies that after process Ti finishes its execution, it stays idle waiting for the next periodic instantiation.
The key point here is that if Ti is not allocated a cpu resource for ci time units within its period pi , it will not be able to synchronize with Scheduler, which sends the starting event si once in every period pi . This will cause process Si of Scheduler to deadlock, leading the whole Radar system to deadlock. Therefore, a deadlock in this system means the failure to successfully schedule a given set of signalprocessing processes. This example illustrates that in order to determine schedulability or other feasibility conditions, we have to first specify the system in a way that the failure to satisfy the condition is equivalent to a deadlock, which can be readily checked using either syntactic or semantic analysis techniques.
9.5 ANALYSIS AND VERIFICATION
To verify that a design specification is correct with respect to a requirements specification using a process-algebraic approach, we show that the two processes representing respectively these two specifications are equivalent. Two ways exist to establish this equivalence: syntax-based and semantics-based techniques. The syntax-based technique uses a suite of equational laws to manipulate the textual representations of two processes to show that they are equivalent or not equivalent. These equational laws are similar to those used in mathematics to show that two expressions are equivalent. On the other hand, the semantics-based technique compares the two prioritized labeled transition systems representing all possible behaviors of these processes and determines whether they are equivalent. Here, semantics refers to the behaviors of the processes.
The laws in a large subset of ACSR laws are the same as those in CCS. The ACSR-specific laws include three new laws for the choice operator, one new law for the parallel (composition) operator Par (Com), six new laws for the scope rule, one
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ANALYSIS AND VERIFICATION |
251 |
||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||||
Choice(5) |
|
|
|
|
|
|
|
|
[P + Q]I = [P]I |
+ [Q]I |
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||||
Choice(6) |
|
(a1, n1).P1 + (a2, n2).P2 = (a2, n2).P2 if (a1, n1) < (a2, n2) |
|
|
|||||||||||||||||||||||||||||||
Choice(7) |
|
|
|
|
A : P + (τ, n).Q = (τ, n).Q if n > 0 |
|
|
|
|
|
|
|
|
||||||||||||||||||||||
|
|
= |
|
i |
I,k K ,ρ(Ai ) |
|
|
ρ(Bk ) |
|
|
i |
|
|
k |
|
: |
|
i |
|
k |
+ |
|
|
|
|
||||||||||
Par(3) |
( |
i I Ai : Pi + |
j |
J |
(a j , m j ).Q j ) ( |
|
|
k K |
Bk |
: Rk |
+ |
|
|
l L (bl , nl ).Sl ) |
|
||||||||||||||||||||
|
|
j J (a j , m j ).(Q j ( k K |
Bk |
: Rk |
+ |
|
) |
l L |
(bl , nl ).Sl )) + |
|
|
||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
∩ |
|
= |
(A |
|
|
B |
|
|
(P |
|
R ) |
|
|
|
|
|
|||||||||
|
|
l L |
(bl , nl ).(( |
i I Ai : Pi |
+ |
|
|
|
j J (a j , m j ).Q j )) Sl + |
|
|
||||||||||||||||||||||||
|
|
|
|
|
|
j |
|
J,l |
L,a j |
|
bl (τ, m j |
|
nl ).(Q j |
|
Sl ) |
|
|
|
|
|
|
|
|
||||||||||||
Scope(1) |
|
A : |
|
|
b |
|
|
|
|
|
|
= |
|
b |
|
+ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
P t (Q, R, S) = A : P t |
|
1(Q, R, S) + S if t > 0 |
|
|
||||||||||||||||||||||||||||||
Scope(2) |
|
|
b |
|
|
|
|
|
|
|
|
|
|
|
b |
|
− |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
(a, n).P |
t (Q, R, S) = (a, n).(P |
t (Q, R, S) + S if t > 0 a = b |
|
|
||||||||||||||||||||||||||||||
Scope(3) |
|
(a, n).P bt (Q, R, S) = (τ, n).Q + S if t > 0 |
a |
= b |
|
|
|||||||||||||||||||||||||||||
Scope(4) |
|
|
|
|
|
|
|
|
|
P b0(Q, R, S) = R |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||
Scope(5) |
|
(P1 + P2) bt (Q, R, S) = P1 bt (Q, R, S) + P2 bt (Q, R, S) |
|
|
|||||||||||||||||||||||||||||||
Scope(6) |
|
|
|
|
|
|
(NIL) bt (Q, R, S) = S if t > 0 |
|
|
|
|
|
|
|
|
|
|
||||||||||||||||||
Restriction Res |
|
|
|
|
|
|
|
|
(A : P)\F = A : (P\F) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||||
Close(1) |
|
|
|
|
|
|
|
|
|
|
|
[NIL]I = NIL |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||
Close(2) |
|
[A : P]I |
|
|
|
|
[P + Q]I = [P]I |
+ [Q]I |
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||||||
Close(3) |
|
= (A B) : [P]I where B = {(r, 0)|r I − ρ(A)} |
|
|
|||||||||||||||||||||||||||||||
Close(4) |
|
|
|
|
|
|
|
|
[(a, n).P]I = (a, n).[P]I |
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||||
Rec(1) |
|
|
|
|
|
|
|
|
recX.P = P[recX.P/ X] |
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 9.2 ACSR-specific laws.
new law for the restriction operator Res, and four new laws for the close rule. These laws are given in Figure 9.2. The Rec operator is similar to CCS’s action operator Act, but Rec uses slightly different notations, so the ACSR law pertinent to Rec is also listed in Figure 9.2. The law Par(3) for the parallel operator uses the summation symbol, (or sum, “+”) to indicate the choice of zero or more processes.
These two analysis techniques are based on two equivalence or bisimulation relations [Park, 1981]. Bisimulation compares the execution trees of two processes to determine whether these processes are equivalent. It is also used to show that two automata are equivalent (described in chapter 2) or that two timed automata are equivalent (described in chapter 7). Two common types of bisimulation exist: strong bisimulation and weak bisimulation [Milner, 1989], as presented in the description of CCS.
There is a largest bisimulation “ ” over “−→.” There is a largest strong bisimulation “ π ” over “−→π .” π is a prioritized strong equivalence, or simply strong equivalence.
As we have seen in the description of CCS, and unlike other state transition models, a small set of equational laws can be used to prove strong equivalence between processes. The equality sign, =, is used to indicate that two processes are strongly equivalent. As in conventional mathematics these equational laws can be applied many times for processes or instances of processes that satisfy their forms.