SPECIFICATION AND PROOF OF

LIVENESS PROPERTIES IN B EVENT SYSTEMS

Olfa Mosbahi and Jacques Jaray

LORIA, INRIA Lorraine, Nancy University, France

Keywords:

Automated systems, Event B method, Liveness properties, Language TLA

, Veriﬁcation.

Abstract:

In this paper, we give a framework for deﬁning an extension to the event B method. The event B method

allows us to state only invariance properties, but in some applications such as automated or distributed systems,

fairness and eventuality properties must also be considered. We ﬁrst extend the expressiveness of the event B

method to deal with the speciﬁcation of these properties. Then, we give a semantics of this extended syntax

over traces, in the same spirit as the temporal logic of actions TLA does. Finally, we give veriﬁcation rules

of these properties. We denote by temporal B model, the B model extended with liveness properties. We

illustrate our method on a case study related to automated system.

1 INTRODUCTION

The paper deals with liveness properties of automated

systems. In such systems, we distinguish a software

part : the controller and an operative part formed by

a physical device and its environment.

The event B method provides us with techniques

and tools for specifying, reﬁning, verifying invariant

properties and implementing systems. B is not well

suited to deal with liveness properties. We deﬁne an

extension of B in order to capture liveness properties.

We describe the syntax of the extension and deﬁne the

semantics in terms of traces in the same spirit of the

language TLA

. We also give the veriﬁcation rules of

these properties.

Several related works concern B extensions for

capturing and proving liveness temporal properties. J-

R. Abrial and L. Mussat in (Abrial and Mussat, 1998)

proposed an extension consisting in a dynamic invari-

ant clause containing linear temporal logic formulae

(LTL). In order to allow veriﬁcation by theorem prov-

ing, the user has to provide the model with decreas-

ing functions, a variant and a loop invariant. Such

items are necessary for the prover but are indeed not

part of the speciﬁcation. Furthermore, ﬁnding vari-

ant and loop invariant is not an easy task. D.Bert

and R.Barradas (Barradas and Bert, 2002) have pro-

posed a method for the speciﬁcation and proof of live-

ness properties in B event systems under fairness as-

sumptions. They give proof obligations in order to

prove basic progress properties in B event systems un-

der two types of assumptions : minimal progress and

weak fairness. They deﬁne proof obligations in terms

of weakest preconditions, which allow us to prove ba-

sic liveness properties as usual B proof obligations.

They suggest the use of UNITY ”Leadsto” operator to

specify more general liveness properties. The seman-

tics of these properties is deﬁned in terms of weakest

preconditions but in our work, we give a semantics in

terms of traces.

The paper is organized as follows : section 2

presents an overview of the event B method, section 3

presents an overview of the language TLA

, section 4

gives a description of our proposal using a case study

: we give the syntax, the semantics of liveness proper-

ties and then the veriﬁcation rules necessary to prove

these properties under fairness assumptions. Finally,

section 5 ends with a conclusion and future work.

2 OVERVIEW OF THE EVENT B

METHOD

The event B method (Abrial, 2003) is based on the B

notation (Abrial, 1996). It extends the methodologi-

cal scope of basic concepts such as set-theoretical no-

tations and generalized substitutions in order to take

into account the idea of formal models. Roughly

speaking, a formal model is characterized by a (ﬁnite)

list x of state variables possibly modiﬁed by a (ﬁnite)

list of events; an invariant I(x) states some properties

Mosbahi O. and Jaray J. (2007).

SPECIFICATION AND PROOF OF LIVENESS PROPERTIES IN B EVENT SYSTEMS.

In Proceedings of the Second International Conference on Software and Data Technologies - SE, pages 25-34

DOI: 10.5220/0001342400250034

 SciTePress

that must always be satisﬁed by the variables x and

maintained by the activation of the events. General-

ized substitutions provide a way to express the trans-

formations of the values of the state variables of a for-

mal model. An event consists of two parts : a guard

(denoted grd) and an action. A guard is a predicate

built from the state variables, and an action is a gen-

eralized substitution (denoted GS).

An event can take one of the forms shown in the

table 1. Let BA(x,x’) be the before-after predicate as-

sociated with each event shape. This predicate de-

scribes the event as a logical predicate expressing the

relationship linking the values of the state variables

just before (x) and just after (x

′

) the event ”execu-

tion”. In the table below, x denotes a vector built on

the set of state variables of the model. In the gen-

eral substitution x : p(x

, x), x denotes the new value

of the vector, whereas x

denotes its old value and t

represents a vector of distinct local variables.

Table 1: Event forms.

Event Before-after Guard

Predicate BA(x, x’)

BEGIN P(x, x

′

) TRUE

x : P(x

, x)

END;

SELECT G(x) G(x) ∧ Q(x,x

′

) G(x)

THEN x : Q(x

, x)

END;

ANY t ∃t.(G(t, x) ∃t.G(t, x)

WHERE G(t, x) ∧R(x, x

′

,t))

THEN x : R(x

, x,t)

END;

Proof obligations are associated to events and state

that the invariant condition I(x) is preserved. We next

give the general rule to be proved. It follows immedi-

ately from the very deﬁnition of the before-after pred-

icate, BA(x, x

′

) of each event :

I(x) ∧ BA(x, x

′

) ⇒ I(x

′

)

The B model has the following form :

MODEL hnamei

SETS hsetsi

CONSTANTS hconstantsi

PROPERTIES hproperties of sets and constantsi

VARIABLES hvariables xi

INVARIANT hinvariants I(x)i

ASSERTIONS hA(x)i

INITIALISATION hinitialization of variablesi

EVENTS heventsi

END

An abstract B model has a name; the clause SETS

contains deﬁnitions of sets; the clause CONSTANTS

allows us to introduce information related to the

mathematical structure. The clause PROPERTIES

contains the effective deﬁnitions of constants. The

clause ASSERTIONS contains the list of theorems

to be discharged by the proof engine. The clause

VARIABLES contains a (ﬁnite) list of state vari-

ables possibly modiﬁed by a (ﬁnite) list of events; the

clause INVARIANT states some properties that must

always be satisﬁed by the variables and maintained

by the activation of the events. The clause EVENTS

contains all the system events which preserve the set

of invariants.

2.1 Reﬁnement

Construction by reﬁnement (Back and v. Wright,

1998; Back and K-Sere, 1989) is a technique suitable

for the development of complex systems. The reﬁne-

ment of a formal model allows us to enrich a model

in a step by step approach. It is used to transform an

abstract model into a more concrete version by modi-

fying the state description (Spivey, 1988). This is es-

sentially done by extending the list of state variables,

reﬁning each abstract event into a corresponding con-

crete version, and adding new events.

The essence of the reﬁnement relationship is that

it preserves already proved system properties. The in-

variant of an abstract model plays a central role for

deriving safety properties and our method focuses on

the incremental discovery of the invariant; the goal

is to obtain a formal statement of properties through

the ﬁnal invariant of the last reﬁned abstract model.

Atelier B (ClearSy, 2002), the toolkit supporting the

B method, generates the proof obligations associated

with a model or a reﬁnement. It also provides au-

tomatic and iterative proof procedures to discharge

these proof obligations.

2.2 Example : A Parcel Sorting Device

In this section, we present an example of reactive sys-

tem : a parcel sorting device (Jaray and A.Mahjoub,

1996) which will be taken to illustrate our proposed

approach. We just give the abstract model of the sys-

tem and not the reﬁnement steps. The problem is to

sort parcels into baskets according to an address writ-

ten on the parcel. In order to achieve such a sort-

ing function we are provided with a device made of

a feeder connected to the root of a binary tree made

of switches and pipes as shown in the ﬁgure 1. The

switches are the nodes of the tree, pipes are the edges

and baskets are the leaves. A parcel, thanks to gravity,

can slide down through switches and pipes to reach a

basket.

A switch is connected to an entry pipe and two

exit pipes, a parcel crossing the switch is directed to

ICSOFT 2007 - International Conference on Software and Data Technologies

Feeder

0

1

2

3

4 5 6

7 8 9 10 11 12 13

14

1 2 3 4 5 6 7 8

Baskets

Figure 1: Router.

an exit pipe depending on the switch position. The

feeder releases one parcel at a time in the router, the

feeder contains a device to read the address of the par-

cel to be released. When released, a parcel enters

a ﬁrst switch (the root of the binary tree) and slides

down the router to reach a basket. The controller can

activate the feeder and change the switches position.

For safety reasons, it is required that switch change

should not occur when a parcel is crossing it. In order

to check this condition, sensors are placed at the entry

and the exits of each switch.

We consider a simpliﬁed version of the system

with only safety properties to illustrate a speciﬁcation

with the event B method and we will deal in the fol-

lowing with liveness properties (eventuality and fair-

ness) to explain our approach.

Abstract Model of the System

the abstract model of the system is given in the ﬁgure

1 2 3 4 5 6 7 8

Baskets

channel

Feeder

Figure 2: Router.

The sorting device. The sorting device consists of a

feeder and a sorting layout. The feeder has two func-

tions: selection of the next parcel to introduce into the

sorting layout and opening the gate (releasing a par-

cel in the sorting layout). We introduce the events se-

lect and release to capture the two functions. In order

to produce the abstract model of the sorting layout,

we have to notice that a given state of the switches

forms a channel linking the entrance to a unique sort-

ing basket. A basket is an element of a set named

Baskets. Channels and sorting baskets are in a one

to one correspondence. Therefore, the abstract model

of the sorting device can be reduced to a single vari-

able channel taking the value of the sorting basket it

leads to, namely a value in the set Baskets. The chan-

nel value is changed by the event set

channel. It is

worth noticing that the abstraction forces a ”sequen-

tial functioning” of the sorting device, i.e. the value

of the channel remains unchanged as long as the par-

cel released in the sorting device has not reached a

sorting basket.

Parcels. Parcels, as part of the environment, are rep-

resented as elements of a set we name PARCELS. We

use a total function (adr) from PARCELS to the inter-

val Baskets to refer to the parcels address. We give

the status ”arrived” to the parcel which has reached

a sorting basket. The variable (arrived) is a function

from PARCELS to Baskets. The goal of the sorting

system is to decrease the set of the parcels to sort. The

variable sorted represents the set of sorted parcels.

The remaining parcels are deﬁned by the expression

PARCELS - sorted named UNSORTED. As pe is un-

deﬁned when the sorting device is empty, we have in-

troduced a set PPARCELS of which PARCELS is a

proper subset; pe is an element of PPARCELS and

assignment of any value in PPARCELS - PARCELS

stands for ”undeﬁned”. The expression PPARCELS -

PARCELS will be referred as NOPARCELS. The se-

lection of a parcel is an event which may be activated

once the device is free and the variable pe is unde-

ﬁned, which means it does not exist a parcel being

sorted.

Moving parcels. In our abstraction a parcel takes no

time to travel from the feeder to a basket. A parcel

arrives in the basket to which the channel leads up.

When the event cross

parcel occurs, the current par-

cel sorting is ﬁnished and then, of course, the current

parcel becomes undeﬁned.

The Controller. The controller has to ensure right

parcel routing. Two events are added for the con-

troller : Set

channel and Release. The event

Set

channel assigns to channel the value of adr(pe).

The event Release changes the state of the sorting de-

vice from free to busy. The model of the automated

system is presented in Figure 3.

Simulation of the B model with ProB. We have used

ProB (Leuschel and Butler, 2003), witch is an simu-

lator and model checker for the (B/Event-B) Method.

It allows fully automatic animation of many B spec-

iﬁcations, and can be used to systematically check a

speciﬁcation for errors. ProB’s animation facilities al-

low users to gain conﬁdence in their speciﬁcations,

SPECIFICATION AND PROOF OF LIVENESS PROPERTIES IN B EVENT SYSTEMS

MODEL Parcel Sorting

SETS PPARCELS ; SortingState = {free , busy }

CONSTANTS PARCELS, adr, Baskets

PROPERTIES

PARCELS ⊂ PPARCELS ∧ PARCELS 6= ∅ ∧

Baskets 6= ∅ ∧ adr ∈ PARCELS → Baskets

VARIABLES

arrived, channel, sorting, pe, sorted, ready

to sort

INVARIANT

arrived∈ PARCELS 7→ Baskets ∧ channel ∈ Baskets

∧

pe ∈ PPARCELS ∧ sorting∈ SortingState ∧

ready

to sort ∈ BOOL ∧ sorted ⊆ PARCELS ∧

(sorting = busy ⇒ channel = adr(pe)) ∧

(sorting = busy ⇒ ¬ ready

to sort) ∧

(ready

to sort ⇒ channel = adr(pe)) ∧

(ready

to sort ⇒ pe ∈ PARCELS) ∧

∀p.(p ∈ PARCELS ∧ p ∈ dom(arrived) ⇒

arrived(p) = adr(p))

DEFINITIONS

UNSORTED == PARCELS - sorted ;

NOPARCELS == PPARCELS - PARCELS

INITIALISATION

arrived := {} || channel :∈ Baskets || sorting := free

pe :∈ NOPARCELS || sorted := {} ||

ready

to sort := FALSE

EVENTS

select

parcel = ANY p Where p ∈ UNSORTED ∧

pe ∈ NOPARCELS ∧ sorting = free

THEN pe := p

END;

set

channel = SELECT sorting = free ∧ pe ∈

PARCELS

∧ ¬ ready

to sort

THEN channel := adr(pe) ||

ready

to sort := TRUE

END;

release = SELECT sorting = free ∧ pe ∈

PARCELS ∧

ready

to sort

THEN sorting := busy ||

ready

to sort := FALSE

END;

cross

parcel = SELECT sorting = busy

THEN arrived(pe) := channel ||

sorted := sorted ∪ { pe} ||

pe :∈ NOPARCELS || sorting :=

free

END

Figure 3: Abstract model of the sorting device.

and unlike the animator provided by the B-Toolkit,

the user does not have to guess the right values for the

operation arguments or choice variables. ProB con-

tains a model checker and a constraint-based checker,

both of which can be used to detect various errors in

B speciﬁcations. ProB enables users to uncover errors

that are not easily discovered by existing tools. Fig-

ure 4, shows the simulation of the abstract model of

the system.

Veriﬁcation of the B model . All generated proof

obligations are veriﬁed with the B click

n Prove tool.

setup_constants({q,r,s},{e,f,g,h},{(q,e),(r,f),(s,g)})

initialise_machine({},e,free,p,{},FALSE)

Select_parcel

set_channel

release

cross_parcel

PARCELS={q,r,s},Baskets={e,f,g,h},adr(q,e),

adr(r,f),adr(s,g)

arrived={},channel=e,sorting=free,

pe=p,sorted={}

arrived={},channel=e,sorting=free,

pe=q,sorted={}

arrived={},channel=e,sorting=free,

pe=q,sorted={},ready_to_sort

arrived={},channel=e,sorting=busy,

pe=q,sorted={}

channel=e,sorting=free,pe=p,

sorted={q},arrived(q,e)

Figure 4: Model checking of the router abstract model.

Requirement of liveness properties. In our example,

we need to consider the dynamics of the system. Our

model must take into account the following properties

1. Every parcel introduced in the entry eventually

reaches one of the baskets, this property is de-

scribed with :

∀p.(p ∈ UNSORTED ⇒ ♦arrived(p) ∈ Baskets)

2. Every parcel introduced in the entry must reach

the basket corresponding to its destination ad-

dress, this property is described with :

∀p.(p ∈ UNSORTED) arrived(p) = adr(p))

3. Weak fairness conditions on the events is assumed

: WF(select

parcel) ∧WF(cross parcel)∧

WF(set

channel) ∧WF(release)

These properties can not be speciﬁed in the clause

INVARIANT. We need to extend the expressivity of

event B to take into account such properties.

ICSOFT 2007 - International Conference on Software and Data Technologies

3 OVERVIEW OF THE

LANGUAGE TLA

TLA

is a language intended for the high level speci-

ﬁcation of reactive, distributed, and in particular asyn-

chronous systems. It combines the linear-time tempo-

ral logic of actions TLA (Lamport, 1994), and mathe-

matical set theory. The language has a mechanism for

structuring in the form of modules, either by exten-

sion, or by instance. The semantics of TLA is based

on behaviors of state variables. It can be viewed as a

logic built in an incremental way in three stages :

1. predicates whose semantics is based on states.

2. actions whose semantics is based on pairs of

states.

3. temporal formulas of actions whose semantics is

based on state behaviors of variables.

A TLA speciﬁcation of a system denoted by

Spec(S) looks like : Init ∧ [Next]

∧ L where :

1. Init is the predicate which speciﬁes initial states,

2. x is the list of all state variables and [Next]

means that either two consecutive states are equal

on x, x

′

= x (stuttering), or Next is an action (a re-

lation) that describes the next-state relation, usu-

ally written as a disjunction of more elementary

actions,

3. L is a fairness assumption (strong or weak) on

actions. WF

unprimed

var(S)

(S) deﬁnes the condi-

tion of weak fairness over the system S and

unprimed var(S)

(S) deﬁnes the condition of strong

fairness over the system S, where primed

var(S)

are primed occurrences of the system variables x

and as is conventional, a primed occurrence v

′

a state variable v denotes the value of v in the

state following the transition described by Next.

unprimed

var(S) are unprimed occurrences of the

system variables x and an unprimed occurrence

denotes the value of a variable v in the state be-

fore the transition.

In the sequel we will focus on the extension of the

event B method with liveness properties, their syntax,

their semantics and veriﬁcation rules.

4 ASSIGNING TEMPORAL

MEANING TO B MODELS

This section deﬁnes an extension to event B in order

to deal with liveness properties. The most important

construction we need is the ”leads to” eventuality op-

erator as in TLA and Unity which expresses require-

ments on behaviors, i.e. sequence of states. In order

to assess eventuality properties we must state assump-

tions on the fair occurrence of events. Such assump-

tions are stated using the TLA operators WF and SF.

WF(e) assumes that the event e is weakly fair, i.e. the

event e occurs inﬁnitely often provided that it is even-

tually always enabled. SF(e) assumes that the event e

is strongly fair, i.e. the event e occurs inﬁnitely often

provided that it is inﬁnitely often enabled.

We indeed integrate some pieces of the language

TLA

into the event B models and we deal with proof

obligations of ”temporal” B models.

In the following, we start with the syntax of the

extension, then we give a semantics and veriﬁcation

rules of liveness properties over traces as it is done in

TLA

. We suggest the use of TLA

operators because

the two methods are very close with respect to their

foundations.

4.1 Syntax of the Extension

In order to establish liveness properties we must as-

sume some progress conditions on the system. As

long as we have to verify that an event system sat-

isﬁes safety properties, it is sufﬁcient to refer to a pair

of states (before and after states of a triggering event).

But in order to prove temporal properties we need

to introduce behaviors (sequences of states) starting

from the initial state and where two consecutive states

and s

i+1

are such that some event enabled in s

and

leads to the state s

i+1

Before deﬁning the syntax of formulae which ex-

tends B expressivity, we start with some deﬁnitions.

State and rigid variables. The state of a system is

composed of a denumerable set of ﬂexible or state

variables (V). Let (X) be a denumerable set of rigid

variables. These variables are not modiﬁed by pro-

gram transitions and hence keep the initially chosen

value during a program run (logical constant). A state

is a valuation of ﬂexible variables.

Terms and States. A term t is deﬁned recursively as

follows :

t ::= c | x | f (t

, ...,t

) where c is a constant, x is a

variable (x ∈ [V ∪ X]) , t

, ...,t

are terms and f is a

function symbol with arity n.

Atomic propositions. An atomic proposition ap is a

formula of the form :

ap ::= p(t

, ...,t

) where p is a predicate symbol with

arity n and t

, ...,t

are terms.

State predicates. A state predicate sp is a formula

deﬁned by the following grammar

SPECIFICATION AND PROOF OF LIVENESS PROPERTIES IN B EVENT SYSTEMS

sp | ∃x sp | ∀x sp.

In our extension, we introduce transition and live-

ness formulae.

Transition formulae. A transition formula describes

state transitions. A transition formula ac is a formula

of the form :

ac ::= GS(e) | [e]sp | heisp where e is an event,

GS(e) is its generalized substitution and sp is a state

predicate.

Safety properties. Safety properties are formulae of

the form

F ::= sp | (sp ⇒ sp) , where sp is a state predi-

cate.

Liveness properties. Liveness properties (fairness

and eventuality) are formulae deﬁned as follows:

- Eventuality properties are expressed with formulae

of the form :

F G (F leads to G) deﬁned as (F ⇒ ♦G)

and means that every F will be followed by G,

where F and G are formulae of the form : F ::=

sp | ♦F | F | WF(e)|SF(e).

Where sp is a state predicate, WF(e) and SF(e)

are respectively the weak and strong fairness of

the event e.

These properties are added in the clause EVEN-

TUALITY.

- Fairness properties are expressed with formulae of

the form :

- WF(e) deﬁned as ♦grd(e) ⇒ ♦GS(e). It is

the weak fairness condition of an event e and

it means that the event e occurs inﬁnitely often

provided that it is eventually always enabled,

- SF(e) deﬁned as ♦grd(e) ⇒ ♦GS(e). It is

the strong fairness condition of an event e and

it means that the event e occurs inﬁnitely often

provided that it is inﬁnitely often enabled,

Where :

• e is a B event,

• grd(e) is the guard of this event e (state predicate),

• GS(e) is the generalized substitution of the event

e. It is a transition formula containing both

primed and unprimed occurrences of states vari-

ables, such as a before-after predicate.

These properties are added in the clause FAIRNESS.

4.2 Semantics of the Extension

In our extension, we deal with properties over state se-

quences (fairness and eventuality properties). This is

why we need a semantics over sequence of states and

have to explain how we can view events as a relation

over primed and unprimed variables and we will use

this point to ﬁnd the extension of the event B method.

A system S is modelled as a set of possible events trig-

gering actions, when guards are true. An event e as it

was shown in the table 1, is deﬁned by a guard de-

noted grd(e) (condition for triggering or enabledness

condition) and by a relation over a set of ﬂexible vari-

ables (V) denoted GS(e) (relation stating the transfor-

mation of variables). According a TLA

module, we

consider three kinds of properties :

- State properties which denote properties on states

of the system S and are interpreted over states.

These properties are state predicates,

- Relational properties which denote relations on S

between pairs of states, which we call transition

formulae,

- Temporal Properties state properties over traces and

use state properties, relational properties and tem-

poral operators (, ♦, , ...), which we call live-

ness properties.

Properties are interpreted over traces (sequences

of states). We introduce notations for characterizing

systems :

- V is the set of state variables of the system S, v is a

state variable; x is the current value of v and x

′

the next value of v. Primed

Var(S) = {x

′

|v ∈ V}

and Unprimed

Var(S) = {x|v ∈ V}.

- Init(S) speciﬁes the initial values of state variables

of the system S.

- Events(S) speciﬁes the set of possible events of S;

it means that we list the possible events deﬁned in

the ﬁgure 1. An event e is deﬁned as follows :

e , grd(e) then GS(e)

- Next(S) is a formula over primed and unprimed

variables of S corresponding to the relation over

States(S), namely →, where States(S) is the set

of states of the system S. Next has the following

form :

Next(S) , R(e

)(x, x

′

) ∨.... ∨R(e

)(x, x

′

)

where R(e

)(x, x

′

) is a relation corresponding to

one of the event forms presented in the table 1.

R(e

)(x, x

′

) , P(x, x

′

) ∨ (G(x) ∧ P(x, x

′

)) ∨

(∃t.(G(t, x) ∧ P(x, x

′

,t)))

- → is a relation over States(S) simulating the execu-

tion of the system S.

- Invariants(S) is a set of properties over States(S)

invariant for S. ϕ is in Invariants(S), if

1. Init(S) ⇒ ϕ

ICSOFT 2007 - International Conference on Software and Data Technologies

2. ∀ s

, s

∈ States(S) : s

, ξ |= Init(S) ∧ (s

→

∗

) ⇒ s

, ξ |= ϕ

- Traces(S) is the set of traces (state sequences) gen-

erated from Init(S) using →. A trace is denoted

by σ = s

.....s

, ..... and satisfying the following

constraints :

1. s

, ξ |= Init(S) (the initial state s

satisﬁes the

initial condition),

2. ∀i ∈ N : (s

→ s

i+1

) ∨ (s

= s

i+1

) any two suc-

cessive states (s

, s

i+1

) either satisfy the before-

after predicate BA

(x, x

′

) for some event e and

some variables x, or agree on the values of all

system variables (called stuttering steps)

Let σ ∈ Traces(S), A property ϕ over states se-

quence of the system S is a state property, a relational

property or a temporal property; the semantics over

traces uniﬁed semantics over states and pairs of states

as follows :

1. a state property ϕ is a trace property as follows :

σ, ξ |= ϕ, if s

, ξ |= ϕ.

2. a relational property ϕ is also a trace property by

extending the semantics over pairs of states into

a semantics over traces as follows : σ, ξ |= ϕ, if

, s

), ξ |= ϕ.

Temporal properties contains state properties,

relational properties and temporal combination of

these properties. Our extension is the same one than

TLA

and a system S is speciﬁed by the following

temporal expression :

Speciﬁcation(S) , ∧ Init(S)

∧[Next(S)]

<unprimed

var(S)>

∧WF

unprimed

var(S)

(S)

∧SF

unprimed

var(S)

(S)

Where:

Init(S) states initial conditions,

[Next(S)]

states how traces are

built,

unprimed var(S)

(S) deﬁnes the condition of weak

fairness over the system S and

unprimed

var(S)

(S) deﬁnes the condition of strong

fairness over the system S.

unprimed

var(S)

(S) and SF

unprimed var(S)

(S)are

deﬁned as follows :

unprimed

var(S)

(S) ,

E∈WF Events(S)

unprimed

var(S)

(E)

and

unprimed

var(S)

(S) ,

E∈SF Events(S)

unprimed

var(S)

(E)

Where WF Events(S) is the set of weakly fair

events and SF

Events(S) is the set of strongly fair

events. WF

unprimed

var(S)

(E) is the weak fairness

associated to the event E and SF

unprimed

var(S)

(E) is

the strong fairness associated to the event E. Each

event is associated with a fairness condition which

will be a weak or strong or undeﬁned.

In the event B, BA

(x, x

′

) is the before-after pred-

icate for an event; this is a ﬁrst-order formula built

from the constants declared for the system speciﬁ-

cation, as well as primed and unprimed occurrences

of the system variables V. The before-after predi-

cate BA

(x, x

′

) in B method is interpreted by the for-

mula Next in TLA

. In TLA

, or an action e, the

enabled condition Enabled(e) is deﬁned by existen-

tially quantifying over the primed occurrences of the

state variables; thus, the state predicate Enabled(e) is

true of those states that have a successor state related

by an occurrence of the event e.

Enabled(e) , ∃x

′

: BA

(x, x

′

The guard grd(e) in B is interpreted by the

condition Enabled(e) in TLA

We can summarize the semantics of temporal B

notations over traces by the following equivalences in

TLA

grd(e) , Enabled(e)

, Next

Interpretation of formulae

Let σ = s

... be a behavior, i.e. a sequence of

states and ξ a valuation of the rigid variables of S.

Let [|x|]

be the value of the variable x in the state

, [| f(t

, ...,t

)|]

gives the semantics of the term

f(t

, ...,t

) in the state s

[|x|]



ξ(x) where x ∈ X;

(x) where x ∈ V.

[| f(t

, ...,t

)|]

= [| f|]([|t

, ...., [|t

)

In the following, we denote by s

, ξ |= sp the

satisfaction of the state predicate sp in the state s

a transition system and by σ, ξ |= F the satisfaction

of the temporal formula F over a trace σ ∈ Traces(S).

Proposition formulae

, ξ |= ap iff ap holds in the state s

State formulae

, ξ |= sp iff sp holds in the state s

SPECIFICATION AND PROOF OF LIVENESS PROPERTIES IN B EVENT SYSTEMS

Boolean formulae

, ξ |= ¬sp iff s

, ξ |= sp is false

, ξ |= sp

∧sp

iff s

, ξ |= sp

and s

, ξ |= sp

∨ sp

iff s

, ξ |= sp

or s

, ξ |= sp

⇒ sp

iff s

, ξ |= ¬sp

, ξ |= sp

and s

, ξ |= sp

)

, ξ |= sp

⇔ sp

iff s

, ξ |= sp

⇒ sp

and

, ξ |= sp

⇒ sp

, ξ |= (∃x) sp iff (∃x) ∈ V : s

, ξ |= sp

, ξ |= (∀x) sp iff (∀x) ∈ V : s

, ξ |= sp

Transition formulae

(s, s

′

), ξ |= GS(e) iff s

→ s

′

s, ξ |= [e]sp

′

iff for every execution of the

event e, if s

→ s

′

then the state s

′

, ξ |= sp

′

This formula is satisﬁed by a state which evolves

to a state s

′

satisfying sp

′

for every execution of the

event e.

, ξ |= heisp

′

iff it exists an execution of the

event e, such that if s

→ s

′

then the state s

′

, ξ |= sp

′

This formula is satisﬁed by a state which can

evolve to a state satisfying sp

′

by the execution of the

event e.

Temporal formulae

We interpret a temporal formula on behaviors. In

the deﬁnitions below, σ|

, ξ |= F means that formula

F holds of the sufﬁx of σ from point i onwards.

σ, ξ |= F iff σ|

, ξ |= F for all i ∈ N

The formula F asserts that F is true at all times

during the behavior σ.

Leads-to property F G

This formula asserts that every sufﬁx satisfying

the temporal property F is followed by some sufﬁx

satisfying the temporal property G.

σ, ξ |= F G iff for all i ∈ N, if σ|

, ξ |= F

then σ|

, ξ |= G for some j ≥ i

F G ≡ (F ⇒ ♦G) where ♦G = ¬¬G

Weak fairness property

A behavior is weakly fair for some event e iff e

occurs inﬁnitely often provided that it is eventually

always enabled (WF(e) ≡ ♦ grd(e) ⇒ ♦GS(e)).

σ, ξ |= WF(e) iff it exists j ∈ N such that for

all i ≥ j, σ|

, ξ |= grd(e) then for all n ∈ N, it exists

m ∈ N such that for all k ≥ n+m, (s

, s

), ξ |= GS(e)

Strong fairness property

A behavior is strongly fair for some event e iff

e occurs inﬁnitely often provided that it is inﬁnitely

often enabled (SF(e) ≡ ♦ grd(e) ⇒ ♦GS(e)).

σ, ξ |= SF(e) iff for all i ∈ N , it exists

j ∈ N such that for all l ≥ i + j, σ|

, ξ |= grd(e)

then for all n ∈ N, it exists m ∈ N such that for all

k ≥ n+ m, (s

, s

), ξ |= GS(e)

4.3 Veriﬁcation Rules of Liveness

Properties

In this section, we give veriﬁcation rules (WF, SF and

LATTICE) to prove liveness properties under fairness

assumptions.

Under weak fairness

Let S be an extended B event system and

EVENTS

(S) is the set of events of the system

S satisfying the weak fair assumption. Let [e]P be the

weakest pre-condition which ensures that P is true

after the execution of the event e. Let heiP(¬[e]¬P)

be the conjugate weakest pre-condition, i.e. the state

from which it is possible for an event e to ensure P.

The following rule is used to prove a leads-to formula

under a weak fairness assumption.

WF.

I ∧ P∧ ¬Q ⇒ [e](P∨ Q) for all event e of S

it exists an event e of S where :

I ∧ P∧ ¬Q ⇒ hei true∧ [e]Q

e ∈ WF

EVENTS

(S)

S |= P Q

In this rule, P and Q are state predicates, I is

the invariant of the B event system S. By the ﬁrst

premise, any successor of a state satisfying P has

to satisfy P or Q, so P must hold for as long as Q

has not been true. By the second premise, it exists a

successor of a state satisfying P must satisfy Q and

ensures that in every state, the event e is enabled

(hei true means the feasibility condition of the event

e ), and so the assumption of weak fairness ensures

that e eventually occurs, unless Q has become true

before. Finally, the third premise ensures that e is an

event for which weak fairness is assumed.

Proof of a liveness property under weak fairness.

To see why the rule is correct, assume that

σ = s

, s

, ...s

, ... is a behavior satisfying

I ∧ WF

EVENTS

(S), and that P holds in s

. We

have to show that Q holds of some states s

with j ≥

i. Let s

be the initial state and s

satisﬁes P. Suppose

that no next state satisﬁes Q, so all next states must

satisfy P. By the second premise, it exists a successor

ICSOFT 2007 - International Conference on Software and Data Technologies

of a state satisfying P in which an event e is enabled

and always its execution carry out in a state satisfying

Q (contradiction). So, from a state s

satisfying P,

we can reach a state s

( j ≥ i) satisfying Q with the

execution of an event e under weak fairness.

Under strong fairness

Let S be a B event system and SF

EVENTS

(S) is the set

of strong fair events. As similar to the previous rule,

the following rule is used to prove a leads-to formula

from a strong fairness assumption.

SF.

I ∧ P∧ ¬Q ⇒ [e](P∨ Q) for all event e o f S

it exists an event e of S where :

I ∧ P∧ ¬Q ⇒ [e]Q

S |= (I ∧ P∧ ¬Q) ⇒ ♦grd (e)

e ∈ SF

EVENTS

(S)

S |= P Q

In this rule, P and Q are state predicates, I is

again an invariant, e is an event for which strong

fairness is assumed. We assume that σ is a behavior

satisfying I ∧ SF(e) and that P holds of a state

. We have to show that Q holds of some s

with

j ≥ i. By the ﬁrst premise, any successor of a state

satisfying P has to satisfy P or Q. By the second

premise, it exists an event e ∈ S where its execution

from a state satisfying p evolves the system to a state

satisfying Q. The third premise ensures that in all

of these states, the event e is enabled, and so the

assumption of strong fairness ensures that eventually

e occurs, unless Q has become true before, in which

case we are done. Finally, the last premise ensures

that e is an event for which strong fairness is assumed.

Using LATTICE rule

The Lattice rule is used to verify complex liveness

properties using well-founded relations. (S, ≺) is

a binary relation such that there does not exist an

inﬁnite descending chain x

≺ x

, ... of elements

∈ S. Fand G are temporal formulae.

LATTICE.

(S, ≺) is a well − f ounded relation over S

∀x ∈ S : F(x) G∨ (∃y ∈ S : (y ≺ x) ∧ F(y))

(∃x ∈ S : F(x)) G (x not f ree in G)

In this rule, x and y are rigid variables such that x

does not occur in G and y does not occur in F. The

second hypothesis of the rule is itself a temporal for-

mula that requires that every occurrence of F, for any

value x ∈ S, be followed either by an occurrence of G,

or again by some F, for some smaller value y. Be-

cause the ﬁrst hypothesis ensures that there cannot be

an inﬁnite descending chain of values in S, eventu-

ally G must become true. This rule allows us to de-

rive liveness properties by induction over some well-

founded ordering.

Other veriﬁcation rules

P Q Q R

P R

(trans)

P Q R Q

P∨ R Q

(disj)

P ⇒ Q

P Q

(dedu)

P Q

(∃x : P(x)) (∃x : Q(x))

(exists)

These rules can be used to prove complex Leadsto

formulas.

Application to the example.

We try now to prove the following property :

∀p.(p ∈ UNSORTED) arrived(p) = adr(p)).

Let P ≡ ∀p.(p ∈ UNSORTED), Q ≡

arrived(p) = adr(p) and I be the invariant of

the system S. Let e be an event of S. We have :

I ∧ P ∧ ¬Q ⇒ [e](P ∨ Q) for all event e o f S.

With the event cross

parcel, we have :

I ∧ P ∧ ¬Q ⇒ hcross

parceli true∧ [cross parcel]Q

and e ∈ WF

EVENTS

(S). So by applying the rule WF,

we have S |= P Q.

5 CONCLUSION

In this paper, we have built an extension of the event

B method to deal with fairness and eventuality prop-

erties. We have proposed a semantics of the extension

over traces, in the same spirit as TLA

does and we

have given veriﬁcation rules in the axiomatic of the

event B method.

In future work, we plan to deﬁne new required

proof obligations. Moreover, the B prover may not be

enough powerful for proving new proof obligations.

Future work will explore also, the question of the re-

ﬁnement and the properties of reﬁnement, within the

extended language.

ACKNOWLEDGEMENTS

Thanks to Stephan Merz for comments on an earlier

draft of this paper.

REFERENCES

Abrial, J.-R. (1996). Extending B without changing it

(for developing distributed systems). In Habrias, H.,

editor, Proceedings of the 1st Conference on the B

method, pages 169–191.

Abrial, J.-R. (2003). B# : Toward a synthesis between Z and

B. In Bert, D., Bowen, J. P., King, S., and Wald

en, M.,

editors, ZB’2003 – Formal Speciﬁcation and Devel-

opment in Z and B, volume 2651 of Lecture Notes in

SPECIFICATION AND PROOF OF LIVENESS PROPERTIES IN B EVENT SYSTEMS

Computer Science (Springer-Verlag), pages 168–177,

Turku, Finland. Springer.

Abrial, J.-R. and Mussat, L. (1998). Introducing dynamic

constraints in B. In Bert, D., editor, B’98 : The 2nd

International B Conference, volume 1393 of Lecture

Notes in Computer Science (Springer-Verlag), pages

83–128, Montpellier. Springer Verlag.

Back, R.-J. and K-Sere (1989). Stepwise reﬁnement of ac-

tion systems. In Mathematics of Program Construc-

tion., pages 115–138, Berlin - Heidelberg - New York.

Springer.

Back, R.-J. and v. Wright, J. (1998). Reﬁnement Calculus:

A Systematic Introduction. Graduate Texts in Com-

puter Science. Springer-Verlag.

Barradas, H. R. and Bert, D. (2002). Speciﬁcation and proof

of liveness properties under fairness assumptions in B

event systems. In IFM, pages 360–379.

ClearSy (2002). Atelier b. Technical Note Version 3.6, Aix-

en-Provence(F).

Jaray, J. and A.Mahjoub (1996). Une mthode itrative de

construction d’un modle de systme ractif . TSI, 15. .

Lamport, L. (1994). The temporal logic of actions. ACM

Transactions on Programming Languages and Sys-

tems, 16(3):872–923.

Leuschel, M. and Butler, M. (2003). ProB: A model checker

for B. In Araki, K., Gnesi, S., and Mandrioli, D., edi-

tors, FME 2003: Formal Methods, LNCS 2805, pages

855–874. Springer-Verlag.

Spivey, J.-M. (1988). Understanding Z, A Speciﬁcation

Language and its Formal Semantics. Tracts in The-

oretical Computer Science, 3. Cambridge University

Press.

ICSOFT 2007 - International Conference on Software and Data Technologies