Architecture of kinara

Figure 8.2 depicts the high level architecture of thekinaraframework.kinarais implemented as a C++ library, which can support multiple front-ends for describing models and requirements, including the Murϕlanguage. The arrows in Figure 8.2 denote inter module dependencies. For example, the arrow from the module labeled “Low-level Model Representation” to the module labeled “Expression Representation” indicates that the model representation depends on the functionality provided by the module responsible for expression representation.

At the heart ofkinarais an extensible library for representing expressions. The expression module deals with the syntax of expressions, and also provides APIs to create types. The module also supports expressions involving array indexing, field references of a record. Expressions can also be quantified over values of a type.

The low-level model representation APIs provide constructs for describing the model as a set of guarded commands. Theguardof each guarded command is a Boolean valued expression,

and the updates are a sequence of simple assignments to lvalues. Becausekinaraonly supports

finitetypes, we assume that loops are unrolled in the low-level model description. The low-level

representation does not check that symmetry breaking constructs are not used. It assumes that a higher-level front-end handles these aspects. In fact, in the low-level representation, allobjectsthat are parameterized by a set of symmetric types are assumed to have already

16kinara_{is not another recursive acronym, or}kinara_{is not another reachability analyzer.}kinara_{is open}

Expression Representation Low-level Model

Representation RepresentationBüchi Monitor

State Space Generation and Representation Counterexample Generation Operator Semantics Simplification Routines Front-end for

esmandesm-sk Descriptions

Synthesis Engine

Corekinaramodules

Pluggable semantics modules

Figure 8.2: Architecture of thekinaraframework for model-checking and synthesis been unrolled, with the exception of Büchi monitors. These are handled differently, as we

explain in Section 8.3.3. For example, the low-level representation of the Peterson’s mutual exclusion algorithm shown in Figure 1.13 will havetwoprocesses, one for each instantiation

of the parameters. The values of the parametersPmandPoin each of the machines will be substituted with concrete values from the set{P0,P1}corresponding to the instantiation. The definitions of symmetry in terms of executions from Chapter 2, imply the following constraints on the low-level model representation:

• For every guarded commandcmd, there must also exist the corresponding guarded command π(cmd), for everyπ∈perm(T). Hereπ(cmd)is obtained by syntactically permutingcmd by the permutationπ.

• The transitions of every Büchi automaton must also be symmetric in the same manner. The notion of symmetry for Büchi automata will be described in greater detail in Section 8.3.3. • For every fairness setF∈F_{w, (respectively}F_{s), of the form}F_,{cmd₁,cmd₂, . . . ,cmd_m}, it must be the case that for every permutation π ∈ perm(T) the fairness set F0 ∈ F_w

(respectivelyF0 ∈F_s), where the fairness setF0isFpermuted according toπand has the formF0_,{π(cmd₁),π(cmd₂), . . . ,π(cmdm)}.

Also, note that the low-level model representation represents theproductof all theesms and esm-sks that form the protocol, where the product construction is as described in Chapter 2. The framework also provides APIs to construct Büchi monitors. These are restricted to be state machines without state variables, but which can inspect the state of the model to

determine the next state to transition to. These may be symmetric as well, but we defer a discussion on symmetric Büchi monitors to Section 8.3.3.

The module for state space generation provides mechanisms for efficiently representing the state space, where each state is represented as a sequence of bytes which encodes the valuation of variables in the state. Given a state which violates an invariant, or a fair, accepting strongly connected component, the counterexample generation module presents a counterexample as a simple path or a stem and a loop respectively. Given that the state space is represented in a compressedor symmetry-reduced manner, generating a usable counterexample is non-

trivial, especially in the case of counterexamples which demonstrate the violation of a liveness requirement. Owing to this complexity, we have chosen to implement the counterexample generation as a separate module.

We note that the user is not restricted to specifying the model and requirements using the low-level model description APIs. Front-ends that support higher levels of abstraction can be implemented to translate models specified using these abstractions to the low-level model description. In our instantiation, we have implemented a front-end library that allows the specification of the model as communicating state machines and state machine sketches. This is indicated using dashed lines in Figure 8.2. The front-end which we have implemented ensures that symmetry breaking constructs are not used. This is done by enforcing the following rules at a syntactic level: (1) no reference to a concrete value of a symmetric type is allowed anywhere, and (2) the only operation defined on values of symmetric types is equality. In effect, this requires that the only way that the values of a symmetric type can be referred to is in the context of afor eachconstruct, which is quantified over the values of the symmetric type. This

ensures that there existsoneinstance of the quantified object — which could be an assignment,

a transition, a message, a fairness assumption, or even anesmoresm-sk— for each value in the symmetric type. In addition, invariants and safety properties can only refer to values of a symmetric type using a universal or existential quantifier over the type. These syntactic

restrictions are sufficient to prevent a user from specifying invariants that are not symmetric over the symmetric model.

Recall that thekinaraexpression module deals only with the syntax of expressions. The semantics of expressions are not a part of the corekinaralibrary. Instead,kinaraallows the semantics to be specified using pluggable C++ modules. In our instantiation, we implemented a module which described the semantics of the most commonly used operators in protocols, namely basic arithmetic operators including multiplication, modulus and division as well as conditional operators. The simplification routines are also implemented using pluggable modules to the corekinaraframework.

The synthesis engine uses the mechanisms provided by the state space representation routines to drive the model checking along paths which lead to more fruitful constraints as described in Section 8.2.3. It also leverages the counterexample generation routines to provide it with a usable counterexample whenever the model checking phase discovers a safety or liveness violation.

We now provide a brief description of the model checking algorithms, which are adaptations of the algorithms presented in earlier work [ID96, Dil96, ES97], are implemented inkinara.