Team VASY

Application Domains
Software
Contracts and Grants with Industry
Other Grants and Activities
Bibliography
Inria / Raweb 2003
Project: VASY

# Project : vasy

## Section: New Results

### Models and Verification Techniques

#### The BCG_GRAPH Tool

Participants : David Champelovier, Hubert Garavel, Frédéric Lang, Frédéric Tronel.

Designed to speed up the compositional verification of asynchronous systems (see §  6.3.2), Bcg_Graph is a tool for generating the Bcg graphs corresponding to Fifo communication buffers efficiently.

In 2003, we extended Bcg_Graph so as to generate two other kinds of graphs:

• Bag automata, which model asynchronous communication buffers that do not preserve the ordering of messages. Each bag automaton is defined by the number and list of messages it may contain.

• Chaos automata, which are graphs containing one single state and and a set of looping transitions on that state. Each chaos automaton is defined by the list of its transition labels.

Bcg_Graph ( $2,700$ lines of C code) allows to generate large Bcg graphs (hundreds of thousands of states) within a few minutes. The generated graphs are always minimal modulo strong bisimulation.

#### The CÆSAR_SOLVE Library

Cæsar_Solve is a generic software library for solving boolean equation systems of alternation depth 1 (i.e., without mutual recursion between minimal and maximal fixed point equations) on the fly. This library is at the core of several Cadp verification tools, namely the equivalence checker Bisimulator (see §  6.1.3), the model checker Evaluator 4.0 (see §  6.1.4), and the $\tau$ -confluence reduction tool (see §  6.1.6). The resolution method is based on boolean graphs, which provide an intuitive representation of dependencies between boolean variables; boolean graphs are handled implicitly in a way similar to the Open/Cæsar interface.

The Cæsar_Solve library provides four different resolution algorithms: A1 and A2 are general algorithms based upon depth-first, respectively breadth-first, traversals of boolean graphs; A3 and A4 are optimized for the case of acyclic, respectively disjunctive/conjunctive, boolean graphs; they are based upon memory-efficient depth-first traversals of boolean graphs. All these algorithms can generate diagnostics explaining why a result is true or false (examples and counterexamples).

In 2003, the Cæsar_Solve library ( $7,250$ lines of C code) was extended and improved as follows:

• A new algorithm that generates tree diagnostics of minimal height was developed. This algorithm reduces by several orders of magnitude the height of the trees produced by depth-first search resolution algorithms (such as A1, A3, and A4), which is often prohibitive. Experiments indicate that the new algorithm also provides significant reductions for non-tree diagnostics (such as the counterexamples produced by equivalence checkers, which in general are directed acyclic graphs).

• The library was enhanced with a textual format for boolean equation systems. Primitives for reading/writing this format and an application tool that reads and solves boolean equation systems was developed.

• The library was enhanced with a primitive giving statistical information about the resolution (size of the boolean variables, number of boolean variables explored during resolution, etc.).

• The interface of the library was properly documented in view of its future integration within the Open/Cæsar environment.

The Cæsar_Solve library was subject to an invited publication [23].

#### The BISIMULATOR Tool

Participants : Nicolas Descoubes, Radu Mateescu.

Bisimulator is an equivalence checker, which takes as input two graphs to be compared (one represented implicitly using the Open/Cæsar environment, the other represented explicitly as a Bcg file) and determines whether they are equivalent (modulo a given equivalence relation) or whether one of them is included in the other (modulo a given preorder relation).

Bisimulator works on the fly, meaning that only those parts of the implicit graph pertinent to verification are explored. Thanks to the use of Open/Cæsar, Bisimulator can be applied directly to descriptions written in high level languages (for instance, Lotos). This is a significant improvement compared to older tools (such as Aldébaran and Fc2Implicit) which only accept lower level models (product of communicating automata).

Bisimulator works by reformulating the graph comparison problem in terms of a boolean equation system, which is solved using the Cæsar_Solve library (see §  6.1.2). A useful functionality of Bisimulator is the generation of diagnostics (counterexamples), which explain why two graphs are not equivalent (or not included one in the other). The counterexamples generated by Bisimulator are directed acyclic graphs and usually much smaller than those generated by other tools (such as Aldébaran) that can only generate counterexamples restricted to sets of traces.

In 2003, we continued the development of the Bisimulator tool ( $10,000$ lines of C code):

• An optimized encoding of equivalence relations in terms of boolean equation systems was designed, which exploits local determinism to simplify the right-hand sides of boolean equations. This optimization increased the speed of Bisimulator by a factor between 2 and 5. It is worth noticing that boolean equations can be simplified on the fly: There is no need to check before verification if the explicit graph (represented in Bcg format) is deterministic.

• The diagnostic generation of Bisimulator was adapted to benefit from the minimal-height tree diagnostic generation algorithm implemented in the Cæsar_Solve library. In some cases, the size of counterexamples produced by depth-first search resolution algorithms was reduced by nearly two orders of magnitude, which makes them suitable for visual inspection.

• In order to validate Bisimulator and compare its performance with other equivalence checking tools, extensive experiments were performed on 70 realistic examples obtained from the Cadp distribution and the Vlts benchmark suite (see §  6.3.3). The results indicate that Bisimulator compares favorably with the on the fly algorithms implemented in Aldébaran. In some cases (e.g., for observational equivalence), Bisimulator even outperforms the classical algorithms based on partition refinement.

#### The EVALUATOR 4.0 Tool

Evaluator 4.0 is an on the fly model checker for temporal properties containing data. These properties are evaluated on a graph represented implicitly using the Open/Cæsar environment. The input language of Evaluator 4.0 is the regular alternation-free $\mu$ -calculus extended with typed variables. It offers primitives for handling states and transitions in logic formulas, thus allowing to express non-standard properties (such as for instance the fact that a state has a looping transition on itself, or that a finite sequence of transitions has the same number of occurrences of two actions A and B ).

In 2003, we continued the development of Evaluator 4.0. Our work focused on improving the translation of the verification problem into a boolean equation system. We devised two property-preserving reductions, which are performed on the fly on the Open/Cæsar graph:

• $\tau$ -compression merges all states of a strongly connected component that contains only $\tau$ -transitions. This reduction preserves the usual weak equivalences (e.g., branching, observational, ${\tau }^{*}.a$ , and safety equivalences) and, thus, any property compatible with these equivalences. The algorithm is derived from Tarjan's algorithm for computing strongly connected components.

• $\tau$ -closure collapses sequences of $\tau$ -transitions preceding each visible transition. This reduction preserves ${\tau }^{*}.a$ and safety equivalences and, thus, any property compatible with these equivalences (such as the safety property ``[  R  ] false'', which forbids any execution sequence matching the regular expression R ). The algorithm computes a transitive closure using two nested depth-first searches.

These reductions significantly increase the speed of Evaluator 4.0 (by a factor up to 5 for graphs containing many $\tau$ -transitions).

#### The AAL Tool

Participants : Alban Catry, David Champelovier, Hubert Garavel, Radu Mateescu.

In the framework of the ArchWare project (see §  7.1), we focused on the analysis of software architectures:

• We contributed to the definition of Aal (Architecture Analysis Language[26], a language for expressing properties of software architectures and architectural styles. Aal contains operators borrowed from first-order logic and modal $\mu$ -calculus, extended with predicates specific to architectural descriptions. It allows to specify both style-related structural properties (e.g., connectivity between components, cardinality, etc.) and architecture-related behavioral properties (e.g., safety, liveness, fairness).

• We defined Aaf-Mc (Architecture Analysis Formalism for Model Checking[27], the fragment of Aal containing properties to be verified using model checking. In collaboration with ArchWare partners, we identified a large number of property patterns relevant to software architectures. We also studied fragments of Aaf-Mc compatible with usual equivalence relations (e.g., strong, branching, observational, and safety equivalences).

• We developed a prototype model checker for Aaf-Mc [28], which translates the temporal formulas expressed in Aaf-Mc into boolean equation systems. This prototype tool ( $7,500$ lines of code) was developed using the Syntax compiler generator and the Traian compiler (see §  5.2).

• We also developed a methodology for the efficient verification of Aaf-Mc properties on execution traces generated during the simulation of an architectural description [30].

#### Partial Order Reduction Tools

Participants : Frédéric Lang, Radu Mateescu.

A way to fight state explosion is partial order reduction, which tries to avoid the exploration of redundant interleavings caused by independent, concurrent transitions. A form of partial order reduction that preserves branching equivalence is the so-called $\tau$ -confluence [44]. It consists in identifying, for each state s , the set $C\left(s\right)$ of confluent $\tau$ -transitions going out of s , meaning that after their execution any other transition going out of s can still be executed. The reduction consists in eliminating all transitions going out of s except those in $C\left(s\right)$ .

In 2003, we developed a $\tau$ -confluence reduction tool (800 lines of C code) for graphs represented implicitly using the Open/Cæsar environment. This tool encodes the definition of $\tau$ -confluence as a boolean equation system, which is solved on the fly using the general algorithms A1 and A2 provided by the Cæsar_Solve library (see §  6.1.2). Experiments on various communication protocols indicate that $\tau$ -confluence significantly reduces the number of states (up to 6 times) and transitions (up to 10 times).

The work on $\tau$ -confluence led to a publication [24].

#### The EXP.OPEN 2.0 Tool

Participant : Frédéric Lang.

Exp.Open 2.0 is a compositional verification tool that explores on the fly the graph corresponding to a network of communicating automata (represented as a set of Bcg files). These automata are composed together in parallel using either algebraic operators (as in Ccs, Csp, Lotos, and μCrl), or ``graphical'' operators (as in E-Lotos and Lotos NT [10]), or synchronization vectors (as in the Mec and Fc2 tools). Additional operators are available to hide and/or rename labels (using regular expressions) and to cut certain transitions.

Version 2.0 of Exp.Open was developed in 2002 to overcome the limitations of the previous version 1.0. In 2003, we worked along the following lines:

• We proved that branching bisimulation is a congruence for all Exp.Open 2.0 operators. This is a key property for compositional verification.

• The code was optimized. A performance comparison with Exp.Open 1.0 on a dozen realistic examples shows that Exp.Open 2.0 is faster (from $1.6$ to 50 times) and uses less memory (about 2 times less).

• We extended the possibilities of translation from Exp.Open's networks of communicating automata into input formats accepted by other tools. In addition to the existing interconnection with the Pep tool for Petri nets (developed at the University of Oldenburg), we implemented a translation to the parallel Fc2 format designed at Inria Sophia-Antipolis.

• To address state explosion, we enhanced Exp.Open with a partial order reduction technique based on $\tau$ -confluence (see §  6.1.6). We assessed our approach on two benchmarks (a leader election protocol on a token ring, and a distributed implementation of Erathostene's sieve) used by Ramakrishna & Smolka [50] to experiment another partial order reduction based on $\tau$ -inertness. The graphs generated by Exp.Open are comparable or even smaller than those reported in [50]: As the number of concurrent processes increases, the graph generated by Exp.Open for the sieve remains of constant size, whereas [50] indicates a linear growth.

The Exp.Open 2.0 tool consists of $1,700$ lines of Syntax code, $6,400$ lines of Lotos NT code, and $1,600$ lines of C code. An article about Exp.Open 2.0 was submitted to an international conference.

#### Parallel and Distributed Verification Tools

Participants : Nicolas Descoubes, Hubert Garavel, Christophe Joubert, Radu Mateescu.

Enumerative verification algorithms need to explore and store very large graphs and, thus, are often limited by the capabilities of current sequential machines. To push forward the limits, we are studying parallel and distributed algorithms adapted to the clusters of Pcs and networks of workstations available in most research laboratories.

Our initial efforts focused on parallelizing the graph construction algorithm [7], which is a bottleneck for verification as it requires a considerable memory space to store all reachable states. In this respect, we developed the following software:

• Distributor 2.1 splits the construction of a graph over N machines communicating using sockets. Each machine is required to build a fragment of the graph represented as a Bcg file, the states being distributed between the N machines by means of a statically determined hash function.

• Bcg_Merge 3.0 merges the N graph fragments constructed by Distributor to obtain — after renumbering states appropriately — a unique Bcg file representing the entire graph.

• Cæsar_Network is a code library for distributed tools such as Distributor and Bcg_Merge. It provides basic functionalities including: management of the machine configuration file that contains the parameters of the distributed computation, process deployment protocol on a set of remote machines, emission and reception of messages using blocking or non-blocking sockets, communication buffer management, etc. Cæsar_Network allows a clear separation between verification algorithms and communication primitives.

In 2003, we improved the distributed model checking tools as follows:

• We ported the Cæsar_Network library to the Windows and Linux operating systems.

• We integrated new functionalities in the Cæsar_Network library, such as a better error processing, primitives to enable both blocking and non-blocking message sending in the same algorithm, and several bug corrections.

• We extended Distributor to handle graphs containing labels of unbounded length, which requires a non-trivial distributed algorithm.

• Distributor was made faster (from 2 to 5 times depending on the size of graphs and number of machines) by reducing the time spent in busy waiting.

• Bcg_Merge was made (at least one order of magnitude) faster by delegating to remote machines certain tasks (such as opening, closing, and sorting Bcg files) that were previously done sequentially by the coordinating process.

• We developed a prototype, distributed version of the Cæsar_Solve (see §  6.1.2) generic library. This prototype library ( $7,600$ lines of C code) uses several machines to solve boolean equation systems on the fly. It implements an efficient parallel version of algorithm A2 based on a breadth-first traversal of the boolean graph.

An article on distributed model checking was published [21].

#### Other Tool Developments

We also improved the following Cadp tools and libraries:

• The Cæsar_Hash library was enriched with several new hash functions.

• The Bcg_Io tool was enhanced with a new option that produces the graph format accepted by the Etmcc (Erlangen-Twente Markov Chain Checker) tool.

• The Bcg_Info tool was enhanced with a new option that reports about the order (depth-first search, breadth-first search, etc.) in which the transitions of a graph are sorted. Also, the algorithm used by Bcg_Info to decide whether a graph is deterministic was redesigned to avoid loading the entire transition relation in main memory, thus resulting in significant time savings (from several hours to a few minutes for large graphs).

• The Determinator, Bcg_Steady, and Bcg_Transient tools were ported to the Windows operating system. Bcg_Steady and Bcg_Transient were enhanced so as to generate output in the standard Csv (Comma Separated Values) format used by mainstream data processing tools, including Excel and Gnuplot. Two demo examples illustrating the use of Cadp for performance evaluation were prepared. A tool paper on Determinator, Bcg_Steady, and Bcg_Transient was published [20].

• The Svl language was extended to generate particular graphs using the Bcg_Graph tool (see §  6.1.1), to minimize stochastic and probabilistic Bcg graphs using the Bcg_Min tool, and to support shell variables representing lists of labels instead of single labels.

• Finally, we started to adapt the Cadp tools to the latest versions of operating systems (Linux RedHat 9, etc.) and compilers (Gcc 3), and to improve their integration with Windows (especially by supporting filenames containing space characters).

We also contributed to other tools outside the Vasy team:

• We corrected several bugs in the TReX symbolic verification tool(See http://www.liafa.jussieu.fr/~sighirea/trex) and added several functionalities, such as gate synchronization, optimized representation of boolean variables, and new options for controlling acceleration and processing non-linear formulas. These improvements led to the release of TReX 1.3 in February 2003 and TReX 1.4 in November 2003.

• We found and proposed a correction for a bug in the Syntax abstract tree generator developed at Inria Rocquencourt (incorrect error message when source code is split in several files).