Aswec2014 Correctness by Construction with Logic-Labeled Finite-State Machines – Comparison with Event-B'

1
Vlad Estivill-Castro
Correctness by Construction with
Logic-Labeled Finite-State
Machines – Comparison with Event-
B

IIISIIIS © V. Estivill-Castro 2
Thanks for your interest
Vlad Estivill-Castro
School of Information and Communication Technology
Institute for Intelligent and Integrated Systems
Griffith University
Australia
Rene Hexel
School of Information and Communication Technology
Institute for Intelligent and Integrated Systems
Griffith University
Australia

IIISIIIS
Outline
Motivation
• Model-Driven Development (MDD) vs formal
methods
• Event-B
• Logic-labelled Finite State Machines
Case Studies
• Bridge – controller
• Car-window Controller
Conclusions
© V. Estivill-Castro 3

IIISIIIS
Model-Driven Development
(MDD)
Widely successful approach to developing
software
Ensures traceability, validation against
requirements, and platform independence
Tools and techniques are resulting in faster
and simpler (easier to maintain) products
and applications than traditional language
parser/compiler or interpreter approaches

IIISIIIS
MDD illustration (static modelling)
Data/Class Modelling tools that generate code
• (ER diagrams to SQL CREATE)
• (Class Diagrams to Java class templates)
[4][5]:The two most used
(100% of the time) UML
constructs are
•class diagrams
•state-charts

IIISIIIS
What is Event-B?
The B method is method of
software development based
on B,
• a tool-supported formal method
based around an abstract
machine notation, used in the
development of computer
software.

IIISIIIS
Widely used model of behavior in
embedded systems
• QP (Samek, 2008), Bot- Studio (Michel, 2004) StateWORKS (Wagner et al.,
2006) and MathWorks R⃝ StateFlow. The UML form of FSMs derives from OMT
(Rumbaugh et al., 1991, Chapter 5), and the MDD initiatives of Executable UML
(Mellor and Balcer, 2002).
The original Subsumption Architecture was implemented using the
Subsumption Language
It was based on finite state machines (FSMs) augmented with timers
(AFSMs)
AFSMs were implemented in Lisp
Finite-State Machines (FSM)
(c) Vlad Estivill-Castro 7

IIISIIIS
Event-driven FSMs
Most common approach
• System is in a state
• waiting
• does not change what is
– doing/happening
• until event arrives
• Events change the state of
the system
8
AttackAttack
DefendDefend
gain
possession
lose
possession
(c) Vlad Estivill-Castro

IIISIIIS
Logic-labeled FSMs
A second view of time (since Harel’s seminal paper)
• Machines are not waiting in the state for events
• The machines drive, execute
• The transitions are expressions in a logic
• or queries to an expert system
attack for a
bit
attack for a
bit
is the game over?
I am injured?
did the team lost possession?
are the fans misbehaving?
defenddefend
Lay
down
Lay
down
CelebrateCelebrate
Take
cover
Take
cover

IIISIIIS
% BallConditions.d
name{BALLCONDITIONS}.
input{badProportionXY}.
input{badProportionYX}.
input{badDensityVsDensityTolerance}.
BC0: {} => is_it_a_ball.
BC1: badProportionXY => ~is_it_a_ball. BC1 > BC0.
BC2: badProportionYX => ~is_it_a_ball. BC2 > BC0.
BC3: badDensityVsDensityTolerance => ~is_it_a_ball. BC3 > BC0.
output{b is_it_a_ball, "is_it_a_ball"}.
Example from robotic soccer
Logic labeled FSMs provide deliverative control

IIISIIIS
Arrangements of LLFSM
Enable MDD
Provide sequential execution
Avoid concurrency challenges
Can be formally verified
Can be simulated (validated)
So far, compared directly with
• Behaviour Trees, Petri nets, Executable UML
Can perform FMEA
BUT, how do they compare with UML-B?

IIISIIIS
One Minute Microwave
Widely discussed in the
literature of software
engineering
Analogous to the X-Ray
machine
• Therac-25 radiation machine
that caused harm to patients
Important SAFETY feature
• OPENING THE DOOR
SHALL STOP THE
COOKING

IIISIIIS
Requirements
Requirements Description
R1 There is a single control button available for the use of the oven. If the
oven is closed and you push the button, the oven will start cooking
(that is, energize the power-tube) for one minute
R2 If the button is pushed while the oven is cooking, it will cause the oven
to cook for an extra minute.
R3 Pushing the button when the door is open has no effect.
R4 Whenever the oven is cooking or the door is open, the light in the oven
will be on.
R5 Opening the door stops the cooking.
R6 Closing the door turns off the light. This is the normal idle state, prior
to cooking when the user has placed food in the oven.
R7 If the oven times out, the light and the power-tube are turned off and
then a beeper emits a warning beep to indicate that the cooking has
finished.
and does not clear the timer
and stops the timer

IIISIIIS
Logic-labeled Finite-state
machines with DPL
Step 1: Consider writing the script of music for an orchestra. Write
individual scripts and place together all actuators that behave with the
same actions for the same cues
Example: The control of the tube (energizing), the fan and the
spinning plate

IIISIIIS
Step 2: Describe the
conditions that result in the
need to change state
% MicrowaveCook.d
name{MicrowaveCook}.
input{timeLeft}.
input{doorOpen}.
C0: {} => ~cook.
C1: timeLeft => cook. C1 > C0.
C2: doorOpen => ~cook. C2 > C1.
output{b cook, "cook"}.
Action:
Posting a message
to the whiteboard

IIISIIIS
One of the LLFSMs
% MicrowaveCook.d
name{MicrowaveCook}.
input{timeLeft}.
input{doorOpen}.
C0: {} => ~cook.
C1: timeLeft => cook. C1 > C0.
C2: doorOpen => ~cook. C2 > C1.
output{b cook, "cook"}.

IIISIIIS
Step 1 (again): Analyze another
actuator
Illustration: The light

IIISIIIS
Step 2 (again): Describe
the conditions that result in
the need to change state
% MicrowaveLight.d
name{MicrowaveLight}.
input{timeLeft}.
input{doorOpen}.
L0: {} => ~lightOn.
L1: timeLeft => lightOn. L1 > L0.
L2: doorOpen => lightOn. L2 > L0.
output{b lightOn, "lightOn"}.

IIISIIIS
actuator
• Illustration: The button

IIISIIIS
% MicrowaveButton.d
name{MicrowaveButton}.
input{doorOpen}.
input{buttonPushed}.
CB0: {} => ~add.
CB1: buttonPushed => add. CB1 > CB0.
CB2: doorOpen => ~add. CB2 > CB1.
output{b add, "add"}.

IIISIIIS
actuator
• Illustration: The bell

IIISIIIS
No need for a logic: timeLeft
- posted by another module
- does not require a proof

IIISIIIS © Vlad Estivill-Castro 23
Step 1 (again): Analyze
another actuator
Illustration: The timer
1 INIT
OnEntry {int currentTime; extern buttonPushed;
extern doorOpen; currentTime=0;}
OnExit {}
{}
2 TEST
OnEntry
{timeLeft=0<currentTime;}
OnExit {}
{}
TRUE
TRUE
4 DECREMENT
OnEntry {currentTime=currentTime-1;}
OnExit {}
{}
buttonPushed && !doorOpen && (currentTime<4035)
3 ADD_60
OnEntry {currentTime=60+currentTime;}
OnExit {timeLeft=1;}
{}
!buttonPushed
!doorOpen && timeLeft && timeout(1000000)

IIISIIIS
Embedded systems are
performing several things
The models is made of several finite state-
machines
• Behavior-based control
With a rich language of logic, the
modeling aspect is decomposed
• the action /reaction part of the system
• the states and transitions of the finite-state machine
• the declarative knowledge of the world
• the logic system

IIISIIIS
The Microwave example
--- We can translate DPL to
propositions
NOT_COOKING
OnEn try:
motion:=false
COOKING
OnEntry:
motion:=true;
! (!doorOpen && timeLeft)
!doorOpen && timeLeft
© Vlad Estivill-Castro 25
LIGHT_OFF
OnEntry:
lights:=false
LIGHT_ON
OnEntry:
lights:=true;
! (doorOpen || timeLeft)
doorOpen || timeLeft

IIISIIIS
The complete arrangement
2 OFF
OnEntry {int sound; sound=0;}
OnExit {}
{}
1 ARMED
OnEntry {}
OnExit {}
{}
timeLeft
timeout(2000000)
1 RINGING
OnEntry {sound=1;}
OnExit {}
{}
!timeLeft
2 NOT_COOKING
OnEntry {int motor; motor=0;}
OnExit {}
{}
1 COOKING
OnEntry {motor=1;}
OnExit {}
{}
!doorOpen && timeleft
doorOpen || ! timeLeft
2 NOT_SHINE_LIGHT
OnEntry {int light; light=0;}
OnExit {}
{}
1 SHINE_LIGHT
OnEntry {light=1;}
OnExit {}
{}
!doorOpen && ! timeLeft
1 INIT
OnExit {}
{}
2 TEST
OnEntry
OnExit {}
{}
true
true
4 DECREMENT
OnExit {}
{}
3 ADD_60
{}
!buttonPushed
Light Motor
Bell
Timer
Execute in predefined
schedule ti ringlets
of FSM Mi

IIISIIIS (c) Vlad Estivill-Castro 27
Demo video (java)
http://www.youtube.com/watch?v=t4ueI1o67Xk
relmfu

IIISIIIS
SIMULATION
2 OFF
OnEntry {int sound; sound=0;}
OnExit {}
{}
1 ARMED
OnEntry {}
OnExit {}
{}
timeLeft
timeout(2000000)
1 RINGING
OnEntry {sound=1;}
OnExit {}
{}
!timeLeft
2 NOT_COOKING
OnEntry {int motor; motor=0;}
OnExit {}
{}
1 COOKING
OnEntry {motor=1;}
OnExit {}
{}
!doorOpen && timeleft
doorOpen || ! timeLeft
2 NOT_SHINE_LIGHT
OnEntry {int light; light=0;}
OnExit {}
{}
1 SHINE_LIGHT
OnEntry {light=1;}
OnExit {}
{}
!doorOpen && ! timeLeft
1 INIT
OnExit {}
{}
2 TEST
OnEntry
OnExit {}
{}
true
true
4 DECREMENT
OnExit {}
{}
3 ADD_60
{}
!buttonPushed
Light
Motor
Bell
Timer
CONTROLLER
Qt GUI
HARDWARE

SIMULATION demo video (C++)

IIISIIIS © Vlad Estivill-Castro 30
http://www.youtube.com/watch?v=Dm3SP3q9_VE

Demo video (C++)

IIISIIIS
Model Checking and Validation
Properties
• Property 1: Necessarily, the oven stops (after several
steps, i.e. a small, finite number of transitions in the
Kripke structure) after the door opens.”
• Property-2: “It is necessary to pass through a state in
which the door is closed to reach a state in which the
motor is working and the machine has started.”
• Property-3: “Necessarily, the oven stops(after several
steps, i.e. again, a small, finite number of transitions in
the Kripke structure) after the timer has expired.”
• Property-4: “Cooking may go on for ever (e.g. if the
user repeatedly keeps pressing the add button while the
timer is still running).”
32(c) Vlad Estivill-Castro

IIISIIIS
Formal description of the
Property in LTL
Using NUSMV’s code
• “the cooking must stop if the door is held open”
SPEC
AG( (E$$doorOpen=1 & M0$$motor=1) ->
AX( (E$$doorOpen=1 -> M0$$motor=0) | AX(
(E$$doorOpen=1 -> M0$$motor=0) | AX(
M0$$motor=0)))))))))
33(c) Vlad Estivill-Castro

IIISIIIS
Failure Mode Analysis
New components come into place
Fault injection determines the effects
1. to remove behavior from the model (an omission
failure) and test all properties, and
2. to modify (a value failure) behavior and test all
properties.
34
2 BULB_OFF
OnEntry {int On; On=0;}
OnExit {}
{}
1 BULB_ON
OnEntry {On=1;}
OnExit {}
{}
light
!light
Figure 3: A model of the light bulb hardwarecomponent.
bulb being poorly connected, or busted. These ad-
ditional components enable verification of some very
important initial and shut-down conditions of thesys-
tem. Onecan observethebehaviour of thesoftware, if
it startsrunning with error statesof other components.
For instance, in the microwave example, it could be
starting with a faulty door sensor always reporting a
door Open condition.
The point we want to make here is that these ad-
ministic order (an
amples in the liter
(DPL) (Estivill-C
et al., 2012a), but
expressions of an
such as C, C++, or
provides an answe
that execution of a
theonesin Fig. 1i
deterministically b
chine in the vecto
ringlets it execute
machine in the v
back to the first m
pletes its allocated
uating the OnEnt
is the first time co(c) Vlad Estivill-Castro

IIISIIIS
The comparison with UML-B?
Note that the models we are going to construct will
not just describe the control part of our intended
system, they will also contain a certain
representation of the environment within which
the system we build is supposed to behave. In fact,
we shall quite often essentially construct closed
models, which are able to exhibit the actions and
reactions taking place between a certain
environment and a corresponding, possibly
distributed, controller [8]
Potentially carry out FMEA

IIISIIIS
The negation of MDD
“In no way is the model of a program, the pro-
gram itself. But the model of a program and
more generally of a complex computer system,
although not executable, allows us to clearly
identify the properties of the future system and
to prove that they will be present in it.” [8,
Page 13].
“Note again that, as with blueprints, the basis
is lacking: our model will thus not in general
be executable” [8, Page 17].

IIISIIIS
Case Study I: Bridge to the Island
(64-page chapter [8])

As usual, requirements are refined

IIISIIIS
Correctness by construction
Build the model incrementally
Always (formally) verifying correctness
• Events
• ML_Out: A car has gone out of the mainland onto
the compound of the bridge and the island.
• ML_In : A car has moved away from the
island/bridge compound onto the mainland.
• Variables
• d capacity of the island (and bridge)
• n cars in compound (bridge & island)

Figure 1: LLFSM model for level one of the car-bridge.

IIISIIIS
Verified properties
always 0≤ n∧ n< d
d remains constant
once n = d−1, any alternation of the values of
has_ML_Out_happened (between TRUE and
FALSE) will not change the value of n.
has_ML_Out_happened must be set to
FALSE before the setting of
has_ML_In_happened to TRUE causes the
value of n to decrease
under the assumption 0<d, the statement (n<d ∨
0≤ n) in all future states.

IIISIIIS
The second level
New events:
• IL_In : A car has gone out of the bridge onto the
island.
• IL_Out : A car has moved off the island onto the
bridge.
New variables
• n_b2i : the number of cars on the bridge heading towards the
island.
• ni : the number of cars on the island.
• n_b2m : the number of cars on the bridge heading towards the
mainland.

IIISIIIS
The invariant
(n_b2i == 0) (∨ n_b2m == 0).
• That is, enforcing the bridge is one-way
(in one direction or the other).

IIISIIIS
Still prove deadlock free
(n_b2m>0) ((∨ n_b2i+ni<d) (∧ n_b2m==0)) ∨
(n_b2i>0)
∨ ((ni >0) (∧ n_b2i==0)).
Fig. 2. LLFSM model for level two of the car-bridge.

IIISIIIS
Level three
Introducing the lights
• Variables
• ml_lt : The colour of the light on the mainland side.
• il_lt : The colour of the light on the island side.

Figure 3. Versatile model at the level of lights for the car-bridge controller.
(
a
)
T
h
e

(
b
)
T
h
e

(
c
)
T
h
e

IIISIIIS
UML-B does not model delays
As a consequence, to ensure that the lights
alternates, it forcers cars to alternate.
Does not even notice this awkward
behaviour of the system (model).

IIISIIIS
Scenario where the UML-B model
fails
Capacity is no more than 4 cars
Two (2) cars to go onto the bridge
One (1) car to go from the bridge onto the island
A car from the mainland can still go on the
bridge

IIISIIIS
Scenario where the UML-B
model fails
If the third car reaches the island and no other
car takes the bridge

IIISIIIS
Scenario where the UML-B
model fails
If the third car reaches the island and no other
car takes the bridge
A fourth car cannot go to the island!!
Has to wait for a car out, and there is still
capacity

Fig4. Lights models with no delay as [8, Sec. 2.6.1 to 2.6.7].
(a) The mainland light.

Fig4. Lights models with no delay as [8, Sec. 2.6.1 to 2.6.7].
(b) The island light.

Figure 5 Modification to Fig. 3 to create the forced-alternation
model of [8, Sec. 2.8.8].
(a) The mainland light.

(b) The island light.

(c) The replaced states.

IIISIIIS
Event-B considerations match
Logic-Labelled FMS
considerations
“make clearer the separation between the
software controller and the physical
environment” [8, Page 89].
“a closed model corresponding to the
complete mathematical simulation of the
pair formed by the software controller and
the environment” [8, Page 89].

Fig. 6 The 4 sensor behaviour models.
ON
OnEntry{ has_ML_out_happened=TRUE;}
OFF
OnEntry{ has_ML_out_happened=FALSE;}
is_car_pushing_M2B
!is_car_pushing_M2B
ON
OnEntry{ has_ML_in_happened=TRUE;}
OFF
OnEntry{ has_ML_in_happened=FALSE;}
is_car_pushing_B2M
!is_car_pushing_B2M
ON
OnEntry{ has_IL_out_happened=TRUE;}
OFF
OnEntry{ has_IL_out_happened=FALSE;}
is_car_pushing_I2B
!is_car_pushing_I2B
ON
OnEntry{ has_IL_out_happened=TRUE;}
OFF
OnEntry{ has_IL_out_happened=FALSE;}
is_car_pushing_I2B
!is_car_pushing_I2B
(a)Mainland to bridge (b)Island to bridge
(c) Bridge to mainland (d)Bridge to island

Figure 7. The communication channels between the environment
and the software controller in Fig 3.

IIISIIIS
UML-B requirements
Event-B uses a model of control over
environment variables
• (making sure the environment plays fair).
• Event-B, a driver will never run a red light, for
example.
This does not happen with LLFSMs
• non-deterministic aspect that is captured in the
Kripke structure in NuSMV, capable of reacting
to the environment changing the corresponding
external variables at any time in any way.

IIISIIIS
The powered-window in the car
Driver and passenger can
control a passenger window
Obstacles when going up halt
the movement.
Short push moves the window
all the way (down or up)
Long push regulates the final
position (when the long push
terminates)

Figure 8. The LLFSM for the button of the passenger.

Figure 10. The LLFSM for the motor of the window.
MOVING_UP
OnEntry{ motor=UP;
}
NOT_MOVING
OnEntry{
extern obstacleFound;
extern atTop;
extern atBottom;
extern passangerShortUp;
extern passangerShortDown;
extern passangerLonUp;
extern passangerLongDown;
extern motor;
motor OFF;
}
MOVING_DOWN
OnEntry{ motor=DOWN;
}
MOVING_DOWN_MANUAL
MOVING_UP_MANUAL
obstacleFound
shallStopUpManual
shallStopDownManual
WAITING
obstacleFound
timeout(delay_4_obstacle)
atTop
atBottom
atBottom
shallGoUpManual
shallDownUpManual
shallGoUp
shallGoUp
shallGoDown
shallGoDown

IIISIIIS
name{SHALLGOUP}.
input{passangerLongUp}. input{passangerShortUp}.
input{driverLongUp}. input{driverShortUp}.
input{driverLongDown}. input{driverShortDown}.
input{obstacleFound}.
input{atTop}.
UP0: {} => ~shallGoUp.
UP1: passangerLongUp => shallGoUp. UP1>UP0.
UP2: passangerShortUp => shallGoUp. UP2>UP0.
UP3: driverLongUp => shallGoUp. UP3>UP0.
UP4: driverShortUp => shallGoUp. UP4>UP0.
UP5: driverLongDown => ~shallGoUp. UP5>UP1. UP5>UP2.
UP6: driverShortDown => ~shallGoUp. UP6>UP1. UP6>UP2.
UP7: obstacleFound => ~shallGoUp. UP7>UP1. UP7>UP2. UP7>UP3. UP7>UP4.
UP8: atTop => ~shallGoUp. UP8>UP1. UP8>UP2. UP8>UP3. UP8>UP4.
output{b shallGoUp,"shallGoUp"}.
Figure 9. DPL coding for the predicate ShallGoUp.

IIISIIIS
name{SHALLGODOWN}.
input{passangerLongDown}. input{passangerShortDown}.
input{driverLongUp}. input{driverShortUp}.
input{driverLongDown}. input{driverShortDown}.
input{obstacleFound}.
input{atBottom}.
DN0: {} => ~shallGoDown.
DN1:passangerLongDown => shallGoDown. DN1>DN0.
DN2:passangerShortDown => shallGoDown. DN2>DN0.
DN3:driverLongDown => shallGoDown. DN3>DN0.
DN4:driverShortDown => shallGoDown. DN4>DN0.
DN5:driverLongUp => ~shallGoDown. DN5> DN1. DN5>DN2.
DN6:driverShortUp => ~shallGoDown. DN6> DN1. DN6>DN2.
DN7:obstacleFound => shallGoDown. DN7> DN6. DN7>DN5. DN7>DN0.
DN8:atBottom => ~shallGoDown. DN8> DN7. DN8>DN4. DN8>DN3.
DN8>DN2. DN8>DN1.
output{b shallGoDown,"shallGoDown"}..
Figure 11. DPL coding for the predicate ShallGoDown.

IIISIIIS
name{SHALLGOUPMANUAL}.
input{passangerLongUp}. input{driverLongUp}.
MUP0: {} => ~shallGoUpManual.
MUP1: passangerLongUp => shallGoUpManual. MUP1>MUP0.
MUP2: driverLongUp => shallGoUpManual. MUP2>MUP0.
output{b shallGoUpManual,"shallGoUpManual"}.
Figure 12. DPL coding for the predicate shallGoUpManual.

IIISIIIS
name{SHALLSTOPUPMANUAL}.
input{passangerLongUp}. input{driverLongDown}.
input{driverShortDown}. input{driverLongUp}. input{atTop}.
SUP0: {} => shallStopUpManual.
SUP1: passangerLongUp => ~shallStopUpManual. SUP1> SUP0.
SUP2:driverLongDown => shallStopUpManual. SUP2> SUP1.
SUP3:driverShortDown => shallStopUpManual. SUP3> SUP1.
SUP4:driverLongUp => ~shallStopUpManual. SUP4> SUP2. SUP4>SUP3.
SUP5: atTop => shallStopUpManual. SUP5>SUP4.
output{b shallStopUpManual,"shallStopUpManual"}.
Figure 13. DPL coding for the predicate shallStopUpManual.

IIISIIIS
shallGoUp≡
( driverLongUp
|| driverShortUp
|| passangerLongUp || passangerShortUp)
&&!
( atTop
|| obstacleFound
|| driverLongDown || driverShortDown).
Figure 14. Simple-C expression for the logic theory in Fig. 9.

IIISIIIS
SPEC AG (
(passangerShortUp = 1 -> ((passangerShortDown = 0
& passangerLongDown = 0)
& passangerLongUp = 0)) | pc = M0S0R0)
Figure 15. CTL formula that verifies that only
passangerShortUp is TRUE once some computation has
happened

Figure 16. Communication channels of the car-window controller
and its environment; the closed world model.
CONTROLLER(
Passenger(
Bu2on(Control(
Driver(
Bu2on(Control(
ENVIRONMENT(
Passenger(
Bu2on((
Driver(
Bu2on((
Motor(
Control(
Motor(
(
passangerUpPressed
passangerDownPressed
driverUpPressed
driverDownPressed
driverLongUp
driverLongDown
driverShortUp
driverShortDown
passengerLongUp
passengerLongDown
passengerShortUp
passengerShortDown
Top(
Sensor(
Obstacle(
Sensor(
Bo2om(
Sensor(
obstacleFound
atTop
atBottom
motor

IIISIIIS
LTLSPEC
G ( ( obstacleFound=1 & atTop=0 & driverLongUp=1 & motor=Up ) ->
X ( obstacleFound=0 | atTop=1 | driverLongUp=0 | motor=Down |
X ( obstacleFound=0 | atTop=1 | driverLongUp=0 | motor=Down
)
)
)
)
)
))
Figure 17. Structure of the LTL formula that encodes that and
obstacle found will cause the motor to switch direction to going
down.

IIISIIIS
Comparison with Event-B (and
its tool UML-B)
Event-B results in 30-Page Event-B
specification [18]
It is incomprehensible to the average
learned software engineer
The specification is longer than the actual
code.

IIISIIIS
Summary
Logic-labelled finite-state machines are very
effective models of behaviour
• Significantly well established event-driven version
• But the logic-labelled reduces many complexities
without loosing expressive power
We can simulate behaviours (detect faults)
We can formally verify models
We can perform fault injection and FMEA
Complete Model-Driven Development

Aswec2014 Correctness by Construction with Logic-Labeled Finite-State Machines – Comparison with Event-B'

More Related Content

Similar to Aswec2014 Correctness by Construction with Logic-Labeled Finite-State Machines – Comparison with Event-B' (20)

Recently uploaded (20)

Aswec2014 Correctness by Construction with Logic-Labeled Finite-State Machines – Comparison with Event-B'