Implementation

The current implementation of Passel uses the SMT solver Z3 [136] for proving validity, checking satisfiability, and performing quantifier elimination. Passel is written in C# and uses the managed .NET API to version 4.2 of Z3. Passel proves validity of a formula φ by checking unsatisfiability of ¬φ. First, the variables Vi used in defining A(N , i) are specified

to the SMT solver. Passel automatically generates and asserts trivial data-type lemmas that the SMT solver requires. Next, the list of assumptions given to Passel are asserted as axioms to the SMT solver.

Passel configures Z3 to use a variety of options, in particular, it requires either having model-based quantifier instantiation (MBQI) enabled or quantifier elimination enabled, as otherwise we may receive unknown as a response from Z3 for some satisfiability checks. Within the SMT solver, we model array variables of automata as uninterpreted functions mapping a subset of the integers (i.e., the set of process indices) to the type of the variable. We tried using the theory of arrays for this instead of uninterpreted functions, but the

4_{We took great care in the development and integration of Passel and PHAVer to ensure consistency of}

performance was significantly worse. Global variables are modeled as constants of their types.

Reachability Using Anonymized States. The reachability method using anonymized states of Chapter 4is implemented in Passel as a fixed-point procedure, shown in the pseu- docode in Figure 4.3. The initial condition Initi is converted to an anonymized state and

added to the frontier of states, implemented as a hashset. For each anonymized state in the frontier, any enabled transition is taken, and any resulting anonymized states are added to the frontier, so long as it is not already in the set of anonymized reachable states, which is also implemented as a hashset.

Proving Inductive Invariants. Passel implements an automatic method for checking the conditions for inductive invariance (Definition2.4) for parameterized networks of hybrid automata, as shown in the function inductiveInvariance in Figure5.1. The inductive invariance conditions (Definition 2.4) are encoded using formulas appearing essentially as they do in the definitions of the discrete and continuous transition relations in Section 2.4. We did not need to use any special encoding to represent our systems for Z3, so the queries we ask are almost exactly the same as the formulas appearing in Section 5.3. Given the finite bound N0 from Theorem5.2, we could potentially have composed the system for each instantiation

2 ≤ N ≤ N0 and used existing tools (for instance, HyTech [37] or PHAVer [39]), but the LH-

assertions specifications were more natural to state in an environment that allows quantifiers. Additionally, our prior experience in model checking such parameterized systems [2] indicated that the bound allowed in practice due to memory requirements may be less than the bound N0, and may prevent verification.

Each property ζ(N ) ∈ P is checked as an inductive invariant by proving—checking the unsatisfiability of—the inductive invariance conditions as formalized for parameterized net- works of hybrid automata in Section 5.1.1. If each of these conditions is proved, then ζ(N ) is an inductive invariant, and it is asserted as an axiom. Then, the process repeats with the next property in P. The order of operation in which these properties are attempted to be proved matters. Thus, if any property is proved as an inductive invariant, then all other

properties either not processed or previously disproved will be repeated.

The operation of checking an inductive invariant is as follows. The user specifies a set P of candidate inductive invariants. Based on the protocol specification, we receive from The- orem 5.2 a bound N0 on the number of automata N for which we must check each property.

Many of the invariant properties we are interested in are not inductive (e.g., mutual exclu- sion in Fischer’s protocol is not inductive, nor even k-inductive [103]), so having a set of candidate invariants allows us to discharge each until we have a set of proven lemmas that imply the desired invariant. For each candidate Γ(N ) ∈ P, we check if Γ(N ) is an inductive invariant by attempting to prove Γ(N )0 after each transition, where Γ(N )0 is Γ(N ) with all variables replaced with their primed counterparts (i.e., post-states). If Γ(N ) is successfully proved, we assert Γ(N ) as a lemma and check some other candidate in P until we have proved—or failed to prove—each property in P. We emphasize that if we do not prove a property, it does not necessarily mean that the property does not hold, only that it may not be inductive. Thus, if we terminate with a proof that a desired safety property ζ(N ) holds, then it indeed holds, but if not, then we cannot conclude it is violated, only that the candidate invariants P were not sufficient to prove ζ(N ). For sanity checking (of soundness), we should not be able to prove any property is an inductive invariant that is not.

The main difficulty in safety verification using inductive invariance is specifying a rich enough set of properties P. We perform satisfiability checks with model construction enable, thus if a transition or time elapse violates the candidate property, we record it and display it to the user so she/he may use this information to refine the candidate manually. For example, for Fischer, a detailed inductive invariant refinement is performed in [103]. The set of properties P for Fischer is shown in Equation 2.6. However, we also had to add more properties, partly because we are working with a different semantics compared to the timeout automata considered in [103].

Finding Inductive Invariants. The inductive invariant synthesis methods that Passel implements (see Chapter 6 and refer to Figures 6.1 and 6.2) rely on projection and syn- tactic manipulations. The projection is implemented using quantifier elimination and the syntactic operations include expression replacement and quantifier introduction. We note

that we attempted to implement the invariant synthesis fixed-point method in Passel using the fixed-point engine built into Z3 [174,175], but found it unsuitable for timed examples. In practice, it is useful to project away all variables—Figure6.1, line6—except the discrete ones (variables with types L and [N]⊥), only the control location variables and real variables,

and combinations of these with and without projecting any global variables away, so Passel does this. Passel models the local variables of A(i) as unary functions, mapping indices to the variables type—for each local variable x ∈ Vi, x : [N ] → type(x ), where N is not fixed

a priori, but has some assumption specified, such as N ≥ 2 or N ≥ 2 ∧ N ≤ 73. However, when eliminating quantifiers for the projection part, Passel first converts these to constants, as otherwise it would result in a second-order logic formula that the SMT solver cannot process.