252 PROCESS ALGEBRA

Using semantics-based analysis to determine whether two processes are bisimilar, we first construct the two labeled transition systems corresponding to these processes. Then, we combine these two transition systems. Finally, we derive the largest bisimulation relation for the combined labeled transition system [Clements, 1993]. To reduce the complexity of the ACSR requirements specification when trying to prove timing properties, we can ignore the identity of the resources and the absolute priorities of matching events and actions. The relative ordering of these events and actions suffices.

9.5.1 Analysis Example

We now apply the analysis technique to determine whether a given set of processes is schedulable in the airport radar system example. The maximal computation times of the four processes are: c1 = 32, c2 = 4, c3 = 7, c4 = 3. Their corresponding periods are: p1 = 40, p2 = 20, p3 = 10, p4 = 10.

Since we are reasoning with processes or their representations, the radar system represented as an ACSR specification will deadlock if a process misses its deadline. Therefore, to check whether a set of processes is schedulable, we need to show that the system never deadlocks. Since the ACSR specification also states how the resources are used and how the processes synchronize, we can simplify the analysis by ignoring (or hiding) this information about resource usage and synchronization. Thus, the processes are schedulable if the system is forever idle. Therefore, determining the schedulability means verifying that

Radar \ \{cpu1, cpu2} ≈π recX. : X.

Since a feasible schedule, if one exists, repeats after each time interval of length that is equal to the least common multiple of all the periods (chapter 3), it is sufficient to prove that

Radar \ \{cpu1, cpu2} ≈π 40 : (Radar \ \{cpu1, cpu2}).

Substituting the given numerical values, Radar becomes:

(s1, 1).C1,0 (s2, 2).C2,0 (s3, 3).C3,0 (s4, 4).C4,0

\{s1, s2, s3, s4}]{cpu1,cpu2}.

254 PROCESS ALGEBRA

as in the C programming language. VERSA also provides indexed composition and set construction operators for operating on sets of indexed names.

VERSA has a query facility for the user to inquire about identifiers and the binding of process variables, as well as for comparing actions and for comparing processes for equality. For example, the query

T [1] == T [2]?

compares processes T1 and T2 for equality. One often-used notion of equivalence is that of prioritized strong equivalence. 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 to these two machines simultaneously. 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.

VERSA and its graphical user interface version, X-VERSA, are implemented in C++. It is made more portable with the use of the LEDA class library, and the libg++ and X/Motif libraries. The input and output interface is built with the Lex and Yacc compiler construction tools. To make the analysis more efficient, the tool kit makes use of a low-level programming language and the latest state space construction and bisimulation testing algorithms. Indexed names are not supported in X-VERSA.

9.5.3 Practicality

Originally, the lack of a graphical input-output interface makes ACSR and its corresponding tool kit VERSA more difficult to use than other tools with a graphical user interface. Recently, a graphical language [Ben-Abdallah, Lee, and Choi, 1995; BenAbdallah, 1996; Ben-Abdallah and Lee, 1998] was introduced to provide a better user interface. Even when compared to several other techniques, such as RTL, writing and understanding the system specification in ACSR or other process algebras seem to be more difficult since there is an extra level of process abstraction. Also, some of the notations are cumbersome. However, the fact that several practical timing constraints are already expressed by the timing operators of ACSR makes it attractive to specify systems more compactly, whereas in other specification languages such timing constraints must be explicitly written. Since process algebras were originally designed to specify processes, their timed extensions are especially appropriate for describing resource-sharing processes with timing constraints.

9.6 RELATIONSHIPS TO OTHER APPROACHES

In the context of the Jahanian and Mok’s RTL approach [Jahanian and Mok, 1986], the abstract process loosely corresponds to the safety assertion and the detailed process corresponds to the system specification. Determining equivalence of these processes is analogous to finding the relationship between the specification and the safety assertion. In the context of whether an actual system implementation exactly follows the system specification, or whether a specification is a faithful representation of an implemented system, the abstract process corresponds to the specification and the detailed process represents the implementation.

To perform semantic analysis for determining equivalence of two processes in ACSR, the process behaviors are first described as (translated into) a prioritized labeled transition system. This transition system is basically a state space graph used in other approaches such as untimed automata (chapter 2), model-checking (chapter 4), Statecharts (chapter 5), RTL (chapter 6), and timed automata (chapter 7), and thus also suffers from the state-explosion problem. However, this transition system is usually smaller since it describes only behaviors of interest to the analysis, such as deadlock-freedom. The process-algebraic method constructs a specification of a system with encoded constraints such that whenever certain safety or timing properties are violated, the specified process enters an exception state. The analysis consists of finding the set of reachable states and then checking whether the exception state is in this set.

9.7 AVAILABLE TOOLS

VERSA is a toolset with the following analysis functions:

1.derivation of system properties from ACSR specifications using rewriting rules;

2.generation and analysis of the state space to verify safety properties, and testing of equivalence of different process formulations;

3.interactive execution of the process specification to study specific system behaviors.

The basic version of VERSA has a command-oriented interface for inputting process descriptions, binding them to identifiers, and operating on them. The graphicsoriented version of VERSA provides an X/Motif user interface, known as X-VERSA, with a point-and-click interface. This significantly improves the usability of the algebraic term rewriting facility. VERSA extends the basic ACSR syntax with a number of notational conventions borrowed from programming languages. VERSA is available at

http://www.cis.upenn.edu/~lee/duncan/versa.html