Model Checking Event-B by Encoding into Alloy

As systems become ever more complex, verification becomes more main stream. Event-B and Alloy are two formal specification languages based on fairly different methodologies. While Event-B uses theorem provers to prove that invariants hold for a given specification, Alloy uses a SAT-based model finder. In some settings, Event-B invariants may not be proved automatically, and so the often difficult step of interactive proof is required. One solution for this problem is to validate invariants with model checking. This work studies the encoding of Event-B machines and contexts to Alloy in order to perform temporal model checking with Alloy’s SAT-based engine.

💡 Research Summary

The paper presents a method for model checking Event‑B specifications by translating them into Alloy, thereby leveraging Alloy’s SAT‑based model‑finding engine. Event‑B, rooted in the B‑Method, relies on theorem proving (via the RODIN platform) to establish that invariants hold. However, for complex models many invariants cannot be proved automatically, forcing users into interactive proof sessions that are time‑consuming and require expertise. Alloy, on the other hand, is a lightweight relational modeling language whose analysis is performed by the Kodkod SAT solver; it can quickly find counter‑examples within bounded scopes.

The authors describe a systematic encoding process that covers three main aspects: (1) model structures, (2) expressions, and (3) predicates (events). First, every Event‑B carrier set and enumerated set is mapped to an Alloy signature. Carrier sets become empty signatures, while enumerated sets are represented as a family of signatures extending a common abstract signature. Variables of the Event‑B machine become fields of a special “State” signature. The type of each field is derived from the corresponding Event‑B type and encoded as a signature, ensuring type safety within Alloy.

A global ordering of states is introduced using Alloy’s built‑in ordering module. The initial state is generated from the Event‑B “Initialisation” event and encoded as a fact that fixes the first element of the ordered state set and assigns initial values to all fields. Each Event‑B event is translated into an Alloy predicate that takes two arguments – the current state and the next state. The predicate’s body consists of (i) the translation of the event’s guards into Alloy boolean formulas, and (ii) the translation of the actions into assignments that define the next state’s fields in terms of the current state. An additional fact, “EventTrigger”, forces that for every state at least one event predicate must hold, thereby guaranteeing that the model can always progress.

The most challenging part of the encoding is the treatment of Event‑B expressions, especially those involving nested relations, domain/range restrictions, and function application. Since Alloy only supports flat relations, the authors decompose complex Event‑B operators into combinations of existing Alloy functions or small user‑defined functions. Operators such as domain, range, domain restriction, and subtraction are either directly available in Alloy’s standard library or defined as tiny helper predicates. Function expressions are represented as relations together with facts that enforce functional properties (e.g., totality, injectivity). When functions are nested, the encoding creates new intermediate signatures, leading to a recursive expansion that can increase the size of the generated Alloy model.

To illustrate the approach, the paper presents a small but representative example: a mutex‑allocation system with two carrier sets (Process and Mutex) and two relations (Holds and Waits). Three events (HoldOnMutex, WaitOnMutex, ReleaseMutex) manipulate these relations. The encoding maps the carrier sets to signatures, the relations to fields of the State signature, and each event to a predicate that updates the appropriate fields while preserving the “Ev” field that records which event caused the transition. The invariant “Holds ∈ Process ↔ Mutex” and “Waits ∈ Process ↔ Mutex” are expressed as Alloy assertions. By issuing a “check NoDeadlock for exactly 6 State, exactly 2 Process, exactly 2 Mutex” command, the Alloy analyzer discovers a deadlock within six steps, which corresponds to a violation of the Event‑B invariant after six event executions.

The authors conclude that the encoding enables Event‑B users to exploit Alloy’s highly optimized SAT solving to obtain counter‑examples for false invariants, and to translate those counter‑examples back into the Event‑B world for debugging. They acknowledge current limitations: the encoding is performed manually, the number of generated signatures can explode for complex expressions, and the approach is bounded (as all Alloy analyses are). Future work includes automating the translation, integrating the tool as a RODIN plug‑in, extending the backend to other solvers (e.g., SMT), and exploring constraint‑based checking as an alternative verification mode. Overall, the paper demonstrates that bridging Event‑B and Alloy is feasible and can substantially improve the practicality of formal verification for large‑scale systems.