Section: New Results
Models and Verification Techniques
The CÆSAR_SOLVE Library
Participant : Radu Mateescu.
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.2 ), the model checker Evaluator 3.5 (see § 6.1.3 ), and the minimization tool Reductor 5.0 (see § 6.1.4 ). The resolution method is based on boolean graphs, which provide an intuitive representation of dependencies between boolean variables, and which are handled implicitly, in a way similar to the Open/Cæsar interface  .
The Cæsar_Solve library provides five different resolution algorithms. A1 and A2 are general algorithms based upon depth-first, respectively breadth-first, traversals of boolean graphs. A3 and A4, based upon memory-efficient depth-first traversals of boolean graphs, are optimized for the case of acyclic, respectively disjunctive/conjunctive, boolean graphs. A5 is a general algorithm based upon a depth-first traversal of boolean graphs; it generalizes Tarjan's algorithm for computing strongly connected components and is much faster than A1 and A2 when it is invoked many times on the same equation block. All these algorithms can generate diagnostics explaining why a result is true or false (examples and counterexamples).
In 2006, the Cæsar_Solve library (12, 200 lines of C code) was improved as follows:
The primitive for writing a boolean equation system to a text file was enhanced in order to write not only the whole system, but also the portion of the system representing the diagnostic produced after solving a given boolean variable.
The primitive for reading a boolean equation system from a text file was enhanced in order to handle the cases where the equation blocks and the boolean variables in the left-hand sides of the equations of a block are numbered neither contiguously, nor increasingly. This allows to read text files containing diagnostics of resolutions, which do not necessarily fulfill these two conditions.
The primitives for reading and writing a boolean equation system from/to a text file were enhanced in order to support on the fly compression, which can reduce the size of text files by several orders of magnitude. This possibility is exploited by Bisimulator (see § 6.1.2 ) and Evaluator (see § 6.1.3 ).
The A4 algorithm was enhanced to detect cycles of the boolean graph that contain certain boolean variables marked by a predicate provided by the user application. This feature is useful for encoding the evaluation of certain temporal logic properties describing infinite, unfair execution sequences. Also, a bug was corrected in algorithm A4 when detecting disjunctive/conjunctive boolean graphs.
An article about Cæsar_Solve was published in an international journal  .
The BISIMULATOR Tool
Participant : Radu Mateescu.
Bisimulator is an equivalence checker that 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. Due 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 accepted lower level models (networks of communicating automata).
Bisimulator works by reformulating the graph comparison problem in terms of a boolean equation system, which is solved on the fly using the Cæsar_Solve library (see § 6.1.1 ). A useful functionality of Bisimulator is the generation of a ``negative'' diagnostic (i.e., a counterexample), which explains why two graphs are not equivalent (or not included one in the other). The diagnostics generated by Bisimulator are directed acyclic graphs and are usually much smaller than those generated by other tools (such as Aldébaran ) that can only generate counterexamples restricted to sets of traces.
In 2006, we continued the development of Bisimulator (15, 900 lines of C code). In addition to a bug fix related to the counterexample generation for branching equivalence:
A new command-line option was added to Bisimulator to apply -confluence reduction on the implicit graph when comparing modulo branching or observational equivalence. When the implicit graph contains interleavings due to the presence of loosely-coupled parallel processes, this option can reduce the time and memory required for the verification by up to one order of magnitude.
The encoding of observational equivalence in terms of boolean equation systems was enhanced in order to simplify the equations when the explicit graph is deterministic and does not contain -transitions. In this case, observational equivalence becomes identical to *.a equivalence, except for the states of the implicit graph from which a deadlock state can be reached after zero or more -transitions. These states are now detected during the computation of -closures (transitive reflexive closures over -transitions) and used to simplify the equations accordingly. This can reduce the number of boolean variables by up to 30% .
The EVALUATOR Tool
Evaluator is a model checker that evaluates a temporal logic property on a graph represented implicitly using the Open/Cæsar environment. Properties are described in regular alternation-free -calculus, a logic built from boolean operators, possibility and necessity modalities containing regular expressions denoting transition sequences, and fixed point operators without mutual recursion between least and greatest fixed points. The input language of the tool also allows to define parameterized temporal operators and to group them into separate libraries.
Evaluator works on the fly, meaning that only those parts of the implicit graph pertinent to verification are explored. The model checking problem is reformulated in terms of solving a boolean equation system. A useful feature of Evaluator is the generation of diagnostics (examples and counterexamples) explaining why a formula is true or false.
In 2006, we continued the development of the Evaluator 3.5 tool. In particular, the translation in regular alternation-free -calculus of the inevitability operator of Actl was improved. When using Evaluator 3.5 to check temporal formulas containing this operator, the new translation leads to gains in time and memory up to a factor 8.
We also continued our work (undertaken in 2003) for extending the regular alternation-free -calculus with new operators dedicated to the specification of properties involving data values. This led to a prototype Evaluator 4.0 (37, 600 lines of Syntax /Lotos NT code and 11, 100 lines of C code), which brings the following enhancements with respect to Evaluator 3.5:
State formulas are extended with data-handling operators inspired from programming languages, such as ``if-then-else'' and ``case''. Fixed point operators are enhanced with data parameters allowing arbitrary calculations to be performed on the fly while exploring the graph. Action formulas are extended with action patterns that extract the data values contained in transition labels and store them in variables that can be referred to in the formula. Regular expressions occurring inside modalities are extended with iteration operators ranging over natural intervals, and also with programming language constructs such as ``while'', ``until'', and ``for''. Finally, special operators are introduced for capturing states of the graph and manipulating them in formulas; this allows to express non-standard properties, such as the existence of self-loops (transitions from a state to itself) and past-time properties (occurence of actions before a certain state). This new language of formulas is called Mcl (Model Checking Language ). It supersedes the regular alternation-free -calculus accepted as input by Evaluator 3.5.
The problem of evaluating an Mcl formula on the fly amounts to the local resolution of a boolean equation system, which is performed using the Cæsar_Solve library. The translation consists of several phases: lexical, syntactic, and semantic analysis of the Mcl formula; type checking and replacement of the derived operators by primitive ones; conversion to positive normal form by propagating negations down to the atomic formulas; generation of modal equation systems containing parameterized propositional variables in the left-hand sides and modal formulas in the right-hand sides; elimination of regular expressions by translating them into terms of modalities and fixed point equations. Then, the resulting modal equation system and the graph (represented implicitly using the Open/Cæsar environment) are combined together into a boolean equation system (represented implicitly according to the Cæsar_Solve interface) containing a distinguished variable, whose local resolution yields the truth value of the Mcl formula on the initial state of the graph.
The translation of a state formula into a modal equation system was optimized in order to maximize the number of blocks in the final boolean equation system whose corresponding boolean graphs are disjunctive/conjunctive. These blocks are solved using the memory-efficient algorithm A4 of Cæsar_Solve , which avoids storing the transitions of the boolean graphs (and hence the transitions of the graph on which the formula is evaluated). In practice, all temporal formulas built from the operators of Ctl , Actl , and Pdl are translated into boolean equation systems containing only disjunctive/conjunctive blocks, and are therefore evaluated with a quasi-optimal memory consumption using A4.
The prototype version Evaluator 4.0 was successfully tested on 2, 300 examples of Mcl formulas and on all regular alternation-free -calculus formulas available in the demo examples of the Cadp distribution.
The REDUCTOR and DETERMINATOR Tools
The Reductor 4.0 tool of Cadp , developed in 2005, implements several forms of (partial or total) graph reductions. Some of these reductions are obtained by encoding the reduction problem into a boolean equation system that is solved on the fly using the Cæsar_Solve library (see § 6.1.1 ).
Cadp also contains a tool named Determinator , which eliminates nondeterminism from ordinary or stochastic graphs.
In 2006, we released a new version 5.0 of Reductor , together with a new version of Determinator . Reductor 5.0 includes several functionalities previously available in Determinator . The main changes are the following:
We fixed a bug in reduction modulo safety equivalence, which caused the generated labeled transition system to be not minimal in some cases.
Three new equivalences were added to Reductor , namely trace reduction (previously available in Determinator as normal determinization), weak trace reduction (previously available in Determinator as determinization with -elimination), and divergence reduction.
Compositional Verification Tools
The Cadp toolbox contains various tools dedicated to compositional verification, among which Projector 2.0, Exp.open 2.0, and Svl play a central role.
Exp.open 2.0 explores on the fly the graph corresponding to a network of communicating automata (represented as a set of Bcg files).
Svl (Script Verification Language ) is both a high level language for expressing complex verification scenarios and a compiler dedicated to this language.
In 2006, we enhanced these tools along the following lines:
We corrected one bug in Projector 2.0, two bugs in Exp.open 2.0, and four bugs in Svl .
We enhanced Exp.open 2.0 to convert networks of communicating automata into Petri nets encoded in the Tpn format of the Tina toolbox developed at Laas-Cnrs .
We added to Exp.open 2.0 a new operator for specifying priorities between the transitions of a network of communicating automata.
We extended the Svl language to support the new equivalences available in Reductor 5.0 (see § 6.1.4 ) and the new features of Bisimulator (see § 6.1.2 ) and Evaluator (see § 6.1.3 ), e.g., selection between depth-first or breadth-first search algorithms, selection of algorithms dedicated to acyclic graphs, etc.
An article on refined interface generation using Exp.open and Svl (see the Vasy 2005 activity report) was published in an international conference  .
Parallel and Distributed Verification Tools
Enumerative verification algorithms need to explore and store very large graphs and, thus, are often limited by the capabilities of one single sequential machine. To push forward the limits, we are studying parallel and distributed algorithms adapted to the clusters of Pc s and networks of workstations available in most research laboratories.
As a first goal, we focused on parallelizing the graph construction algorithm, which is a bottleneck for verification, as it requires a considerable amount of memory to store all reachable states. For this purpose, we developed two tools  : Distributor splits the construction of a graph over N machines communicating using Tcp/Ip sockets; each machine builds a graph fragment, the distribution of states between the machines being determined by a static hash function; Bcg_Merge merges the N graph fragments constructed by Distributor to produce the entire graph.
Distributor 3.0 and Bcg_Merge 3.0 are now properly documented and integrated into Cadp . A tool paper was published at an international conference  .
In 2006, this work progressed as follows:
We studied various enhancements of our Cæsar_Network library, which implements generic communication primitives for distributed verification tools. We simplified its programming interface by reducing the number of primitives needed to initialize and terminate a distributed computing session. We also designed an extension of the Gcf (Grid Configuration File ) format used by Cæsar_Network in order to support the mainstream job schedulers available in clusters and grids.
Each graph generated by executing Distributor on a set of machines is represented as a Pbg (Partitioned Bcg Graph ) file, which consists of a set of graph fragments generated on each machine and stored as Bcg files. The Pbg format provides various information for handling these fragments (number of states and transitions of each fragment, Gcf file used to generate the fragments, log files produced on each machine, etc.). So far, the only tool of Cadp handling the Pbg format was Bcg_Merge , which translates a Pbg file into a Bcg file by merging all fragments into a single graph. In 2006, we developed four new prototype tools operating on Pbg files:
Pbg_Cp copies a Pbg file and its dependencies (fragments, log files, and Gcf file) from a machine to another,
Pbg_Mv moves a Pbg file (and its dependencies) between two machines,
Pbg_Rm removes a Pbg file (and its dependencies), and
Pbg_Open provides a distributed algorithm that implements the Open/Cæsar programming interface  , thus allowing to explore on the fly a Pbg file (without merging its fragments first as Bcg_Merge does).
As a second goal, we aim at parallelizing on the fly verification itself. Because the Cæsar_Solve library (see § 6.1.1 ) is our central verification engine for both model checking, e.g., in the Evaluator tool (see § 6.1.3 ), and equivalence checking, e.g., in the Bisimulator (see § 6.1.2 ) and Reductor (see § 6.1.4 ) tools, we have been designing a distributed version of the Cæsar_Solve library to solve boolean equation systems on the fly using several machines.
In 2006, we continued the development of this library. The library code (16, 000 lines of C code) was thoroughly reviewed and simplified. The error management was improved. The primitive for writing a boolean equation system (or the portion of the system corresponding to the diagnostic of a given variable) to a file was also implemented in the distributed version of Cæsar_Solve . The distributed resolution algorithm for boolean equation systems was enhanced to detect on the fly cyclic dependencies between equation blocks (the presence of such dependencies indicates that the boolean equation system has an alternation depth greater than one).
An article about the distributed version of Cæsar_Solve and its applications was published in an international conference  .
We developed a new tool, named Bes_Solve , which supersedes two existing prototype tools for generating random boolean equation systems and for reading and writing boolean equation systems from/to text files, respectively. Bes_Solve allows to compare and cross-check the various resolution algorithms provided by the sequential and distributed versions of Cæsar_Solve . It constructs a boolean equation system in memory either by reading it from a (possibly compressed) text file, or by generating it randomly according to various parameters (number of equation blocks, minimum and maximum number of variables in each block, length of the equations, percentage of boolean constants, percentage of disjunctive and conjunctive variables in the right-hand sides of the equations, seed value for initializing the random number generator, etc.). Then, a boolean variable defined in some equation block of the boolean system can be solved by invoking any sequential or distributed algorithm of Cæsar_Solve . Bes_Solve served to experiment intensively the resolution algorithms and allowed to correct a bug in algorithm A4 of the sequential version of Cæsar_Solve .
Other Tool Developments
We undertook the design of an integrated development environment for Cadp within the Eclipse framework. This environment comprises both a Lotos editor and a graphical user-interface (inspired from Eucalyptus but based on Eclipse ) for the Cadp tools.
Additionally, we improved the following Cadp tools and libraries:
We fixed one bug in the Caesar_Regexp library and two bugs in Xtl .
We enhanced Determinator and Bcg_Min to support double precision floating point numbers.
We improved the Eucalyptus graphical user-interface to provide access to all recent features and tools of Cadp .
We added a new Cadp demo example (Web services for stock management and an on-line book auction) and we updated most of the other demo examples to take advantage of the most recent features and tools of Cadp .
We continued adapting Cadp to the latest computing platforms:
We finished porting Cadp to recent Linux distributions and Mac OS 10.4 ``Tiger ''.
We modified Cadp to support recent C compilers (Gcc 4, Intel Icc 9.0, Sun Studio 11).
We improved the portability of Cadp by adding new ``wrappers'', i.e., shell scripts that make Cadp less dependent on the underlying operating system.
As regards 64-bit architectures: