Event-B [3, 56] is a formal method for development and veri cation of de- pendable reactive and distributed systems. It has evolved from the Action Systems formalism [16, 17] and the B Method [2]. The associated Rodin plat- form [56], together with the accompanying plug-ins [122], provides a mature tool support for automated modelling and veri cation of critical computer- based systems.
An Event-B model can be de ned by a tuple (d, c, A, v, Σ, I, Init, E), where d represents sets, c stands for constants, v corresponds to a vector of model variables, Σ is a model state space determined by all possible values of the vector v. A(d, c) is a conjunction of axioms, while I(d, c, v) is a conjunction of invariants. Init is an non-empty set of model initial states such that Init ⊆ Σ. Finally, E is a set of model events.
Event-B uses the abstract machine notation [3], which consists of the static and dynamic parts called CONTEXT and MACHINE respectively. On the one hand, the sets (d) and constants (c) of a modelled system are de ned in the CONTEXT components, where their properties are postu- lated as axioms (A). On the other hand, the model variables (v), invariants (I ) and events (E), including the initialisation event (Initialisation), are in- troduced in the MACHINE components. The model variables are strongly typed by constraining predicates stated as system invariants. A MACHINE component can be connected to one or several CONTEXT components by a binding relation called Sees. A generalised representation of the Event-B components is shown in Figure 2.3.
Each event e ∈ E may have the following form: e ˆ= any lv where g then R end,
where lv is a list of local variables, the guard g is a conjunction of predicates de ned over the model variables, and the action R is a parallel composition of assignments over the model variables.
The guard of an event de nes when this event is enabled. In case when several events are enabled simultaneously, any of them can be chosen for execution non-deterministically. If there is no enabled event, the system deadlocks. There are two types of assignments over the variables: deter- ministic and non-deterministic. A deterministic assignment is expressed as x := Expr(v), where x is a state variable and Expr(v) is an expression over
MACHINE M_Name variables v invariants I events Initialisation e1 … eN end CONTEXT C_Name constants c sets d axioms A Sees
Figure 2.3: General representation of Event-B MACHINE and CONTEXT the state variables v. A non-deterministic assignment can be denoted as x :∈ S or x :| Q(v, x0), where S is a set of values and Q(v, x0) is a predicate. As a result of a non-deterministic assignment, x gets any value from S or it obtains a value x0 satisfying Q(v, x0).
The Event-B language can also be extended by dierent kinds of at- tributes attached to model events, guards, variables, etc. We will use Event- B attributes to contain formulas or expressions to be used by external tools or Rodin plug-ins, e.g., Linear Temporal Logic (LTL) formulas to be checked. Semantically Event-B events are de ned using before-after predicates (BAs) [3, 75, 101]. BAs declare the relationships between the system states before and after execution of events. Hence, the semantic de nition of an event presented above can be given as the relation describing the correspond- ing state transformation from v to v0, such that:
e(v, v0) = ge(v)∧ I(v) ∧ BAe(v, v0),
where ge is the guard of the event e, BAe is the before-after predicate of
this event, and v, v0 are the system states before and after event execution
respectively.
Re nement in Event-B. The main development methodology of Event- B is top-down re nement (Figure 2.4). It is a process of transforming an abstract speci cation of a system (i.e., an abstract model) into a detailed sys- tem model via stepwise unfolding of implementation details (i.e., re nement steps) yet preserving its correctness. We say that a more detailed model Re nes a more abstract one.
Abstract model The 1st refinement Refines The Nth refinement Refines ... Code generation...
Figure 2.4: Event-B re nement
To preserve a validity of a re nement step, every possible execution of the re ned model must correspond to some execution of the abstract model.
The re nement-based development allows us to reduce non-determinism of an abstract model as well as introduce new concrete variables and events into the model. This type of a re nement is known as a superposition re nement. Additionally, Event-B supports data re nement. It allows us to replace some abstract variables with their concrete counterparts. In this case, a part of the invariant of a re ned model, called gluing invariant, formally de nes the relationship between the abstract and concrete variables.
Furthermore, the most detailed model obtained during the re nement- based development can be used for code generation. Speci cally, the Rodin platform [56], a tool supporting Event-B, permits for program code gener- ation utilising a number of plug-ins. For example, EB2ALL [52], which is a set of translator plug-ins, allows for automatic generation of a target pro- gramming language code from an Event-B speci cation. In particular, EB2C allows for generation of C code, EB2C++ supports C++ code generation, using EB2J one can obtain Java code, and using EBC# C# code.
The consistency (e.g., invariant preservation) and well-de nedness of Event-B models as well as correctness of re nement steps are demonstrated by discharging the respective proof obligations (POs). The complete list of POs can be found in [3]. The Rodin platform [56] automatically generates the required POs and attempts to automatically prove them. Sometimes it requires user assistance by invoking its interactive prover. In general, the tool achieves a high level of automation (usually over 80%) in proving. Therefore, the Event-B method together with its mature tool support is attractive for both academic and industrial applications.
Event-B is highly suitable for safety assurance of highly critical systems due to its proof-based veri cation. However, to justi ably demonstrate that such systems can be safely operated, we utilise safety cases. Next, we de- scribe in detail safety cases, their supporting graphical notation, as well as provide a small example illustrating the structural representation of a safety case.