- 1 - in the name of god review of statecharts and its model checking techniques by shah mohammadi

- 1 -

IN THE NAME OF GOD

Review of Statecharts and Its Model Checking Techniques

BYSHAH MOHAMMADI

- 2 -

Outline

• Statecharts• Problems in verification of statecharts models• Translating to SMV• Translating to SPIN• STATEMATE Verification Environment• Verification of Statecharts using Esterel Tools• Exploiting Behavioural Hierarchy for Efficient Model

Checking

• Statecharts• Problems in verification of statecharts models• Translating to SMV• Translating to SPIN• STATEMATE Verification Environment• Verification of Statecharts using Esterel Tools• Exploiting Behavioural Hierarchy for Efficient Model

Checking

- 3 -

Requirements for specification techniques

• HierarchyHumans not capable to understand systems containing more than ~5 objects. Most actual systems require more objects

• Behavioral hierarchy

• Structural hierarchy

• Timing behavior.

• HierarchyHumans not capable to understand systems containing more than ~5 objects. Most actual systems require more objects

• Behavioral hierarchy

• Structural hierarchy

• Timing behavior.

- 4 -

Requirements for specification techniques(1)

• Event-handling (external or internal events)

• Exception-oriented behaviorNot acceptable to describe exceptions for every state.

• Event-handling (external or internal events)

• Exception-oriented behaviorNot acceptable to describe exceptions for every state.

We will see, how all the arrows labeled k can be replaced by a single one..

exception

- 5 -

Requirements for specification techniques (2)

• ConcurrencyReal-life systems are concurrent

• Synchronization and communicationComponents have to communicate!

• Presence of programming elementsFor example, arithmetic operations, loops, and function calls should be available

• Support for the design of large systems Domain-specific support (control-dominated, data-dominated, centralized and distributed applications-domains)

• Readability

• human, computer.

• ConcurrencyReal-life systems are concurrent

• Synchronization and communicationComponents have to communicate!

• Presence of programming elementsFor example, arithmetic operations, loops, and function calls should be available

• Support for the design of large systems Domain-specific support (control-dominated, data-dominated, centralized and distributed applications-domains)

• Readability

• human, computer.

- 6 -

StateCharts

•Classical automata not useful for complex systems

• complex graphs cannot be understood by humans.

• Introduction of hierarchy StateCharts [Harel, 1987]

•StateChart = the only unused combination of

•“flow” or “state” with “diagram” or “chart”

•Classical automata not useful for complex systems

• complex graphs cannot be understood by humans.

• Introduction of hierarchy StateCharts [Harel, 1987]

•StateChart = the only unused combination of

•“flow” or “state” with “diagram” or “chart”

- 7 -

Introducing hierarchy

super-state S

sub-states

FSM will be in exactly one of the substates of S if S is active(either in A or in B or ..)

FSM will be in exactly one of the substates of S if S is active(either in A or in B or ..)

- 8 -

Modeling of Hierarchy: Definitions

• Current states of FSMs are also called active states.

• States which are not composed of other states are called basic states.

• States containing other states are called super-states.

• For each basic state s, the super-states containing s are called ancestor states.

• Super-states S are called OR-states, if exactly one of the sub-states of S is active whenever S is active.

• Current states of FSMs are also called active states.

• States which are not composed of other states are called basic states.

• States containing other states are called super-states.

• For each basic state s, the super-states containing s are called ancestor states.

• Super-states S are called OR-states, if exactly one of the sub-states of S is active whenever S is active.

ancestor state of E

- 9 -

Default state mechanism

•Filled circleindicates sub-state entered whenever super-state is entered.

•Filled circleindicates sub-state entered whenever super-state is entered.

- 10 -

History mechanism

•For input m, S enters the state it was in before S was left (can be A, B, C, D, or E). If S is entered for the very first time, the default mechanism applies.

•For input m, S enters the state it was in before S was left (can be A, B, C, D, or E). If S is entered for the very first time, the default mechanism applies.

(behavior different from last slide)

- 11 -

Concurrency

•Convenient ways of describing concurrency are required.

•AND-states: FSM is in all (immediate) sub-states of a super-state; Example:

•Convenient ways of describing concurrency are required.

•AND-states: FSM is in all (immediate) sub-states of a super-state; Example:

- 12 -

Types of states

• In StateCharts, states are either

• basic states, or

• AND-states, or

• OR-states.

• Root : no parent state

• In StateCharts, states are either

• basic states, or

• AND-states, or

• OR-states.

• Root : no parent state

- 13 -

General form of edge labels

• Events:• Triggers the transition• Can be either internally or externally generated

• Conditions:• Guards the transition from being taken unless it is true when e

occurs

• Reactions:• Can either be assignments for variables or creation of events

• Events:• Triggers the transition• Can be either internally or externally generated

• Conditions:• Guards the transition from being taken unless it is true when e

occurs

• Reactions:• Can either be assignments for variables or creation of events

event [condition] / reaction

- 14 -

Broadcast mechanism

•Values of variables are visible to all parts of the StateChart model.

•StateCharts implicitly assumes a broadcast mechanism for variables.

•Values of variables are visible to all parts of the StateChart model.

•StateCharts implicitly assumes a broadcast mechanism for variables.

- 15 -

Semantics of Statecharts

• Implemented in the STATEMATE system.

• First executable semantics defined for the Statecharts

• Support different styles of modeling

• Implemented in the STATEMATE system.

• First executable semantics defined for the Statecharts

• Support different styles of modeling

- 16 -

Behavior

•Run: a set of possible behavior

•A series of snapshots of system responses to external environment stimuli

•Status: a snapshot of system situation

•Step: transition between two snapshots

•Run: a set of possible behavior

•A series of snapshots of system responses to external environment stimuli

•Status: a snapshot of system situation

•Step: transition between two snapshots

Status= values of all variables + set of events + current timeStatus= values of all variables + set of events + current time

- 17 -

Some Timing Issues

• The execution takes zero time

• The time between two consecutive steps is excluded from step semantics (this is part of user control)

• The execution takes zero time

• The time between two consecutive steps is excluded from step semantics (this is part of user control)

- 18 -

Principles in Defining the semantics

• Reactions to events, and changes occurred within a step, can be sensed only after the step

• Events live in the step following their occurrence, for one step only.

• Calculations are based on situation at the beginning of the step

• Reactions to events, and changes occurred within a step, can be sensed only after the step

• Events live in the step following their occurrence, for one step only.

• Calculations are based on situation at the beginning of the step

- 19 -

Configuration

• A maximum set of states (C) that the system can be simultaneously in

• C contains root state

• If C contains OR-state A, it must contain only one of A’s substates

• If C contains AND-state A, it must contain all of A’s substates

• Basic configuration is a maximal set of basic states that the system can be in simultaneously

• A maximum set of states (C) that the system can be simultaneously in

• C contains root state

• If C contains OR-state A, it must contain only one of A’s substates

• If C contains AND-state A, it must contain all of A’s substates

• Basic configuration is a maximal set of basic states that the system can be in simultaneously

- 20 -

Basic configuration

Full configuration (all parents and root)

- 21 -

Verification of Statecharts

• System is represented as a Kripke structure.

• Model checking of statecharts requires an interpretation of the statecharts model as a Kripke structure

• System is represented as a Kripke structure.

• Model checking of statecharts requires an interpretation of the statecharts model as a Kripke structure

- 22 -

Problems in verification of statecharts models

• State Hierarchy• Inter-level transitions• Conflicting transitions and transition priority

• STATEMATE semantics

• UML semantics

• Concurrency• Communication• History

• State Hierarchy• Inter-level transitions• Conflicting transitions and transition priority

• STATEMATE semantics

• UML semantics

• Concurrency• Communication• History

- 23 -

Introduction to SMV

• Symbolic Model Verifier

• Specifications given as CTL formulas

• Internal representation using BDDs

• Automatically verifies specification or produces a Counterexample

• Symbolic Model Verifier

• Specifications given as CTL formulas

• Internal representation using BDDs

• Automatically verifies specification or produces a Counterexample

- 24 -

Language Characteristics

• Allows description of synchronous and asynchronous systems

• Modularized and hierarchical descriptions

• Finite data types: Boolean and enumerated

• Nondeterminism

• Allows description of synchronous and asynchronous systems

• Modularized and hierarchical descriptions

• Finite data types: Boolean and enumerated

• Nondeterminism

- 25 -

Variable Assignments

• Assignment to initial state: init(value) := 0;

• Assignment to next state (transition relation)next(value) := value + carry_in mod 2;

• Assignment to initial state: init(value) := 0;

• Assignment to next state (transition relation)next(value) := value + carry_in mod 2;

- 26 -

ASSIGN and DEFINE

• VAR a: boolean;ASSIGN a := b | c;

• declares a new state variable a

• becomes part of invariant relation

• DEFINE d:= b | c;• is effectively a macro definition, each occurrence of d is

replaced by b | c

• no extra BDD variable is generated for d

• VAR a: boolean;ASSIGN a := b | c;

• declares a new state variable a

• becomes part of invariant relation

• DEFINE d:= b | c;• is effectively a macro definition, each occurrence of d is

replaced by b | c

• no extra BDD variable is generated for d

- 27 -

Alternative of ASSIGN

• ASSIGN

• next(s) := case

d: on;

1: off;

esac;

• An alternative way to specify the transition relation

• TRANS

• (d & next(s)= on) | (!d & next(s) = off)

• ASSIGN

• next(s) := case

d: on;

1: off;

esac;

• An alternative way to specify the transition relation

• TRANS

• (d & next(s)= on) | (!d & next(s) = off)

- 28 -

Modules and Hierarchy

• Modules can be instantiated many times

• Each instantiation creates a copy of the local variables

• Each program has a module main

• Scoping

• Variables declared outside a module can be passed as parameters

• Internal variables of a module can be used in enclosing modules (submodel.varname).

• Parameters are passed by reference.

• Modules can be instantiated many times

• Each instantiation creates a copy of the local variables

• Each program has a module main

• Scoping

• Variables declared outside a module can be passed as parameters

• Internal variables of a module can be used in enclosing modules (submodel.varname).

• Parameters are passed by reference.

- 29 -

RSML Model Checking (Chan)

• RSML is a variation of statecharts.

• RSML borrows the following notions from statecharts.

• Superstates

• AND decomposition

• Broadcast communication.• Synchrony hypothesis: during a step

• No new external events may occur

• Value of inputs remain unchanged

• Adds features like

• directed communication between state machines

• The RSML models are translated to SMV

• RSML is a variation of statecharts.

• RSML borrows the following notions from statecharts.

• Superstates

• AND decomposition

• Broadcast communication.• Synchrony hypothesis: during a step

• No new external events may occur

• Value of inputs remain unchanged

• Adds features like

• directed communication between state machines

• The RSML models are translated to SMV

- 30 -

Translation to SMV

• Events defined as booleans

• Inputs defined as variables

• States defined as enumerated types:• IMAGE: {PICTURE, TEXT};

• Each OR-state translates to an enumerated variable which ranges over the substates of the OR-state.• DEFINE• TV: {WORKING, WAITING};

• Transitions:• DEFINE• t0 := in-PICTURE & txt;

• t1 := in-TEXT & txt;


• Inputs defined as variables

• States defined as enumerated types:• IMAGE: {PICTURE, TEXT};

• Each OR-state translates to an enumerated variable which ranges over the substates of the OR-state.• DEFINE• TV: {WORKING, WAITING};

• Transitions:• DEFINE• t0 := in-PICTURE & txt;

• t1 := in-TEXT & txt;

- 31 -

Translation to SMV

• Next state:ASSIGN

• next(TV) :=

• case

• t6: WORKING;

• ...

• 1: TV;

• esac;

• Event generated:• next(txt) :=

• case

• stable: {0,1}

• 1: 0;

• esac;

• Initialize states :• init(TV) := WAITING;

• Next state:ASSIGN

• next(TV) :=

• case

• t6: WORKING;

• ...

• 1: TV;

• esac;

• Event generated:• next(txt) :=

• case

• stable: {0,1}

• 1: 0;

• esac;

• Initialize states :• init(TV) := WAITING;

- 32 -

Problems

• Nondeterminism

• Synchrony Hypothesis

• Transition Priority

• Other features• History connectors

• Nondeterminism

• Synchrony Hypothesis

• Transition Priority

• Other features• History connectors

- 33 -

Translation of STATEMATE statecharts to SMV (Clarke)

•Attempts to reflect the hierarchical structuring of statecharts

•The notion of hierarchy

•Any state may contain entire statecharts

•Inter-level transitions are not handled by the translation

•The translation to SMV is via a temporal language ETL.

•Attempts to reflect the hierarchical structuring of statecharts

•The notion of hierarchy

•Any state may contain entire statecharts

•Inter-level transitions are not handled by the translation

•The translation to SMV is via a temporal language ETL.

- 34 -

Features of the translation

• Statecharts translated as individual SMV modules.

• Three types of SMV modules in the translation:

• Main-module : top level statechart

• Chart modules : subcharts

• Monitor-module : global event and condition variables.

• State of each statechart modelled as local variable state.• AND states have at least two subcharts.

• Events defined as global boolean variables.

• Statecharts translated as individual SMV modules.

• Three types of SMV modules in the translation:

• Main-module : top level statechart

• Chart modules : subcharts

• Monitor-module : global event and condition variables.

• State of each statechart modelled as local variable state.• AND states have at least two subcharts.

• Events defined as global boolean variables.

- 35 -

Part of the SMV code for thestatechart TV

• MODULE TV(on,off,out,in,active,default)• VAR• state: {WORKING, STANDBY, DISCONNECTED};• INIT• active & default -> state = STANDBY;• TRANS• next(active) & next(default) -> next(state = STANDBY);• TRANS• ( (active & state = WORKING & ( (out & next(state) = DISCONNECTED)• | (off &next(state) = STANDBY)• | (!(out|off) & next(state) = state)))• | (active & state = STANDBY & ( (on & next(state) = WORKING)• | (out &next(state) = DISCONNECTED)• | (!(on|out) & next(state) = state)))• | (active & state = DISCONNECTED & ( (in & next(state) = STANDBY)• | (!in & next(state) = state)))• | !active)

• MODULE TV(on,off,out,in,active,default)• VAR• state: {WORKING, STANDBY, DISCONNECTED};• INIT• active & default -> state = STANDBY;• TRANS• next(active) & next(default) -> next(state = STANDBY);• TRANS• ( (active & state = WORKING & ( (out & next(state) = DISCONNECTED)• | (off &next(state) = STANDBY)• | (!(out|off) & next(state) = state)))• | (active & state = STANDBY & ( (on & next(state) = WORKING)• | (out &next(state) = DISCONNECTED)• | (!(on|out) & next(state) = state)))• | (active & state = DISCONNECTED & ( (in & next(state) = STANDBY)• | (!in & next(state) = state)))• | !active)

- 36 -

Problems

• Events and Condition Variables

• Modularity• Modules make the SMV code more readable

• The internal representation in SMV is a flattened out transition system

• OR hierarchy

• Inter-level transitions and Priority

• State Explosion

• Events and Condition Variables

• Modularity• Modules make the SMV code more readable

• The internal representation in SMV is a flattened out transition system

• OR hierarchy

• Inter-level transitions and Priority

• State Explosion

- 37 -

Introduction to PROMELA

• PROMELA (Process/Protocol Meta Language)

• Specification language to model finite-state systems.

• Dynamic creation of concurrent processes.

• Communication using channels and global variables.

• Non-deterministic choices and interleaving .

• PROMELA (Process/Protocol Meta Language)

• Specification language to model finite-state systems.

• Dynamic creation of concurrent processes.

• Communication using channels and global variables.

• Non-deterministic choices and interleaving .

- 38 -

SPIN

• SPIN (Simple PROMELA Interpreter)

• Tool for analyzing the logical consistency of concurrent systems.

• SPIN uses

• Linear Temporal Logic (LTL).

• On-the-fly explicit state model checking

• number of optimisation techniques to reduce the size of the state space.

• Takes a PROMELA model as input.

• SPIN (Simple PROMELA Interpreter)

• Tool for analyzing the logical consistency of concurrent systems.

• SPIN uses

• Linear Temporal Logic (LTL).

• On-the-fly explicit state model checking

• number of optimisation techniques to reduce the size of the state space.

• Takes a PROMELA model as input.

- 39 -

PROMELA Model Basics

• Promela model consists of:• type declarations• channel declarations• variable declarations• process declarations

• Promela model consists of:• type declarations• channel declarations• variable declarations• process declarations

• mtype = {MSG, ACK};• chan toS;• chan toR;• bool flag;

• proctype sender()• {• …• }• proctype receiver()• {• …• }

• mtype = {MSG, ACK};• chan toS;• chan toR;• bool flag;

• proctype sender()• {• …• }• proctype receiver()• {• …• }

- 40 -

Executability

• The body of a process consists of a series of statements.

• Statements are either executable or blocked.

• The body of a process consists of a series of statements.

• Statements are either executable or blocked.

(x < y)

i = 3

ch!MSG

ch?msg

- 41 -

Non-Determinism

• Process interleaving and statement execution is non-deterministic:

• Process interleaving and statement execution is non-deterministic:

if

:: z++

:: z--

fi

do

:: ch?msg

:: ch!MSG

:: break

od

- 42 -

On-The-Fly

• System is the asynchronous composition of processes

• The global transition relation is never built

• For each state the successor states are enumerated using the transition relation of each process

• System is the asynchronous composition of processes

• The global transition relation is never built

• For each state the successor states are enumerated using the transition relation of each process

- 43 -

Implementing STATEMATE statecharts in SPIN(Mikk)

• Using the extended hierarchical automata (EHA) model.

• To overcome problems with interlevel transitions

• Has a simple priority concept.

• The transformation from statecharts to EHA

• Lifting interlevel transitions to the uppermost states

• Using the extended hierarchical automata (EHA) model.

• To overcome problems with interlevel transitions

• Has a simple priority concept.

• The transformation from statecharts to EHA

• Lifting interlevel transitions to the uppermost states

- 44 -

EHA

• An EHA consists of a set of sequential automata (SA).

• A SA A is a 4-tuple (,s0,L, )

is the set of states

• L is the set of transition labels × L × is the transition relation

• An EHA is a 5-tuple (F,E, ,s0,V )• F is the set of SA with disjoint state space• E is the set of events

• V is the set of variables

: A F A (F) is refine function

• An EHA consists of a set of sequential automata (SA).

• A SA A is a 4-tuple (,s0,L, )

is the set of states

• L is the set of transition labels × L × is the transition relation

• An EHA is a 5-tuple (F,E, ,s0,V )• F is the set of SA with disjoint state space• E is the set of events

• V is the set of variables

: A F A (F) is refine function

- 45 -

EHA (cont)

•Refine function imposes a tree that satisfies:

•Maps a state s of a SA to a set of automata

•There exists a unique root automata A0F

•Every non-root automata has exactly one ancestor state

•There are no cycles

•Refine function imposes a tree that satisfies:

•Maps a state s of a SA to a set of automata

•There exists a unique root automata A0F

•Every non-root automata has exactly one ancestor state

•There are no cycles

- 46 -

Configurations

• System states of an EHA H are modelled by configurations.

• Conf= set of states of the component SA of H.

• Every SA contributes at most one state to a Conf.

• The root automaton is a part of every Conf.

• For every non-basic state is in a Conf, each of its direct sub-automata must contribute to the Conf, and vice versa.

• set of all Confs are denoted by Conf) (.

• System states of an EHA H are modelled by configurations.

• Conf= set of states of the component SA of H.

• Every SA contributes at most one state to a Conf.

• The root automaton is a part of every Conf.

• For every non-basic state is in a Conf, each of its direct sub-automata must contribute to the Conf, and vice versa.

• set of all Confs are denoted by Conf) (.

- 47 -

Translation to spin

• The semantics of an EHA H = (F,E, ) is given in terms of a Kripke structure K=(S,s0, step(, where

• S=Conf() ×(E)

• s0 = (C0,0)

• step S × S

• operational semantics is in terms of three principal rules:

• Progress Rule

• Composition Rule

• Stuttering Rule

• The semantics of an EHA H = (F,E, ) is given in terms of a Kripke structure K=(S,s0, step(, where

• S=Conf() ×(E)

• s0 = (C0,0)

• step S × S

• operational semantics is in terms of three principal rules:

• Progress Rule

• Composition Rule

• Stuttering Rule

- 48 -

Translation to PROMELA

• Variables used as states of K

• Processes encode the transition relation of K.


• The translation supports the closed systems only.

• Variables used as states of K

• Processes encode the transition relation of K.


• The translation supports the closed systems only.

- 49 -

Problems

• Statecharts subset

• History


• History

- 50 -

Translating UML Statecharts to PROMELA (Latella)

• The method is similar to the previous approach.

• In translation :

• UML transition priorities are considered.

• The method is similar to the previous approach.

• In translation :

• UML transition priorities are considered.

- 51 -

Features of the Translation

• Events defined as integer values.

• Set, multi-set or FIFO queue is used to storing events directed to an object.

• States modelled as a single bit variable.

• Steps generation by the PROMELA process (called STEP) consists:

• Selection of an event from the environment.

• Identification of all the candidate transitions for firing.

• Selection of transitions that will be fired.

• Actual firing of the selected transitions,

• The STEP process includes a loop to generate successive steps of the EHA.

• Events defined as integer values.

• Set, multi-set or FIFO queue is used to storing events directed to an object.

• States modelled as a single bit variable.

• Steps generation by the PROMELA process (called STEP) consists:

• Selection of an event from the environment.

• Identification of all the candidate transitions for firing.

• Selection of transitions that will be fired.

• Actual firing of the selected transitions,

• The STEP process includes a loop to generate successive steps of the EHA.

- 52 -

Features of the Translation (cont)

• Code for selecting an event from the input queue ( queue as set) uses the selection command:

• if

• :: Qe_1 -> Ev = e_1; Qe_1 = 0

• .

• :: Qe_n -> Ev = e_n; Qe_n = 0

• Fi

• Code for selecting an event from the input queue ( queue as set) uses the selection command:

• if

• :: Qe_1 -> Ev = e_1; Qe_1 = 0

• .

• :: Qe_n -> Ev = e_n; Qe_n = 0

• Fi

- 53 -

Problems


• History

• Multiple statecharts

• The translation does not consider multiple statecharts with multiple input queues.

• Complexity


• History

• Multiple statecharts

• The translation does not consider multiple statecharts with multiple input queues.

• Complexity

- 54 -

Translating using vUML(Lilius)

• Uses UML state machines Formalisation for translation.

• Steps of formalisation

• the structure of a UML state machine is translated into a term rewriting system.

• operational semantics of state machines is defined.

• Formalisation is able to deal with all the features of UML state machines.

• It has been implemented in the vUML tool

• Uses UML state machines Formalisation for translation.

• Steps of formalisation

• the structure of a UML state machine is translated into a term rewriting system.

• operational semantics of state machines is defined.

• Formalisation is able to deal with all the features of UML state machines.

• It has been implemented in the vUML tool

- 55 -

Features of this formalisation

• allows to formulate the transition selection algorithm.

• verification is limited to deadlock checking.

• verification by SPIN without user intervention.

• allows to formulate the transition selection algorithm.

• verification is limited to deadlock checking.

• verification by SPIN without user intervention.

- 56 -

Problems

• Statecharts subset• The subset of UML statecharts considered is bigger than the other

works.

• Scope of Verification

• Deadlock detection

• Statecharts subset• The subset of UML statecharts considered is bigger than the other

works.

• Scope of Verification

• Deadlock detection

- 57 -

STATEMATE Verification Environment(Damm)

• Uses an SMI language for translating STATEMATE models.

• Model checking using VIS.

• BDD-based symbolic model checker that uses CTL.

• Properties specified in the user interface are translated automatically into temporal logic formulas

• Space state reduction

• compositional reasoning

• abstraction techniques.

• Restricts the model to only those variables that may influence the truth of .

• Uses an SMI language for translating STATEMATE models.

• Model checking using VIS.

• BDD-based symbolic model checker that uses CTL.

• Properties specified in the user interface are translated automatically into temporal logic formulas

• Space state reduction

• compositional reasoning

• abstraction techniques.

• Restricts the model to only those variables that may influence the truth of .

- 58 -

Verification of Statecharts using Esterel Tools(Seshia)

• Translates statecharts to Esterel. • STATEMATE semantics of statecharts is used.

• Esterel is deterministic

• Almost all the features of statecharts are considered, like

• history

• inter-level transitions

• An Esterel module is considered to each OR-state.

• Translates statecharts to Esterel. • STATEMATE semantics of statecharts is used.

• Esterel is deterministic

• Almost all the features of statecharts are considered, like

• history

• inter-level transitions

• An Esterel module is considered to each OR-state.

- 59 -

Problems

• State space explosion

• Since each OR-state is translated into a module

• Esterel tools have a very limited verification support

• There is not much experience in using the tool in an industrial setting

• There is no traceability to the original model.

• State space explosion

• Since each OR-state is translated into a module

• Esterel tools have a very limited verification support

• There is not much experience in using the tool in an industrial setting

• There is no traceability to the original model.

- 60 -

Exploiting Behavioural Hierarchy for Efficient Model Checking (Alur)

• A method for model checking of hierarchical state machines.

• The input language to the model checker is based on hierarchic reactive modules (HRMs).

• HRM is a graphical language for describing & analysing systems.

• A simple HRM diagram resembles a FSM.

• HRM consist of

• States ( called points)

• Transitions between points

• Extends FSM by adding variables which can be read & updated as in normal programming languages.

• A method for model checking of hierarchical state machines.

• The input language to the model checker is based on hierarchic reactive modules (HRMs).

• HRM is a graphical language for describing & analysing systems.

• A simple HRM diagram resembles a FSM.

• HRM consist of

• States ( called points)

• Transitions between points

• Extends FSM by adding variables which can be read & updated as in normal programming languages.

- 61 -

Mode

• The central component of an HRM.

• A set of points & transitions can be grouped into a mode.

• Interaction By two interfaces :

•Control interface

•Set of entry & exit points on the boundary of a mode

•Data interface

•Through a set global of variables

•Each mode has

• Local and global variables

• Control points

• Submodes

•The transitions can connect to a mode only at its entry/exit points

• The central component of an HRM.

• A set of points & transitions can be grouped into a mode.

• Interaction By two interfaces :

•Control interface

•Set of entry & exit points on the boundary of a mode

•Data interface

•Through a set global of variables

•Each mode has

• Local and global variables

• Control points

• Submodes

•The transitions can connect to a mode only at its entry/exit points

- 62 -

Mode example

- 63 -

Mode

• Transitions priority • Top level modes

Certain modes are designated as top level modes

• Concurrency by interleaving

• At any time there is only one active top level mode.

• Communicating of top level modes is through shared variables

• Transitions priority • Top level modes

Certain modes are designated as top level modes

• Concurrency by interleaving

• At any time there is only one active top level mode.

• Communicating of top level modes is through shared variables

- 64 -

Verification

• Assertion condition

• Point or mode

• Invariants

• For all states of the system

• Hermes toolkit

• Create,…,verify HRM diagrams

• Assertion condition

• Point or mode

• Invariants

• For all states of the system

• Hermes toolkit

• Create,…,verify HRM diagrams

- 65 -

Model checking

• Enumarative checker

• Depth first search of all reachable states of an HRM diagram

• Check for

• deadlock

• Assertion violation

• Invariants

• Optimization

• Exploiting Hiding

• Exploiting sharing

• Symbolic checker

• Enumarative checker

• Depth first search of all reachable states of an HRM diagram

• Check for

• deadlock

• Assertion violation

• Invariants

• Optimization

• Exploiting Hiding

• Exploiting sharing

• Symbolic checker

- 66 -

Problems

• Unlike statecharts

• HRMs have entry and exit points

• Transitions can connect to a mode only at its entry/exit points.

• Mode sharing by various parents modes

• The local and global variables in HRMs

• Unlike statecharts

• HRMs have entry and exit points

• Transitions can connect to a mode only at its entry/exit points.

• Mode sharing by various parents modes

• The local and global variables in HRMs

- 67 -

Conclusion

• Tools are Prototypical academic tools.

• Accepting a subset of features.

• Having a wide variety of semantics• STATEMATE, UML

• Translate … to another modelling language

• The back-end modelling languages

• �ِDo not exhibit the high level features of statecharts, like

• hierarchy

• synchronous

• Flattenning hierarchical statecharts leads to large state space

• Except HRM that is different from statecharts

• Tools are Prototypical academic tools.

• Accepting a subset of features.

• Having a wide variety of semantics• STATEMATE, UML

• Translate … to another modelling language

• The back-end modelling languages

• �ِDo not exhibit the high level features of statecharts, like

• hierarchy

• synchronous

• Flattenning hierarchical statecharts leads to large state space

• Except HRM that is different from statecharts

- 68 -

Conclusion (cont)

• Lack of traceability between the front-end and back-end design models.

• Mikk, Damm

• Test on actual industrial examples.

• Lack of traceability between the front-end and back-end design models.

• Mikk, Damm

• Test on actual industrial examples.

- 69 -

References

• W. Chan, et al, Model checking large software specifications. IEEE Trans.Soft. Eng., 24(7), 1998.

• E. M. Clarke and W. Heinle. Modular translation of statecharts to SMV. Technical Report CMU-CS-00-XXX, Carnegie-Mellon University School of Computer Science, 2000.

• E Mikk,et al, Implementing statecharts in PROMELA/SPIN. In Proc. of the 2nd IEEE Workshop on Industrial-Strength Formal Specification Techniques, 1998.

• D. Latella,et al. Automatic verification of a behavioural subset of UML statechart diagrams using the SPIN model-checker.Formal Aspects of Computing, 1999.

• J Lilius,et al. Formalising UML state machines for model checking. Second Int.Conf., Fort Collins, CO, USA, October 28-30. 1999, Proceedings, volume 1723 of LNCS, pages 430–445. Springer, 1999.

• T. Bienmller, et al. The STATEMATE Verification Environment - Making It Real. In E. Allen Emerson and A. Prasad Sistla,editors, Computer Aided Verification, 12th Int. Conf. CAV 2000,volume 1855 of Lecture Notes in Computer Science, Springer,2000.

• W. Chan, et al, Model checking large software specifications. IEEE Trans.Soft. Eng., 24(7), 1998.

• E. M. Clarke and W. Heinle. Modular translation of statecharts to SMV. Technical Report CMU-CS-00-XXX, Carnegie-Mellon University School of Computer Science, 2000.

• E Mikk,et al, Implementing statecharts in PROMELA/SPIN. In Proc. of the 2nd IEEE Workshop on Industrial-Strength Formal Specification Techniques, 1998.

• D. Latella,et al. Automatic verification of a behavioural subset of UML statechart diagrams using the SPIN model-checker.Formal Aspects of Computing, 1999.

• J Lilius,et al. Formalising UML state machines for model checking. Second Int.Conf., Fort Collins, CO, USA, October 28-30. 1999, Proceedings, volume 1723 of LNCS, pages 430–445. Springer, 1999.

• T. Bienmller, et al. The STATEMATE Verification Environment - Making It Real. In E. Allen Emerson and A. Prasad Sistla,editors, Computer Aided Verification, 12th Int. Conf. CAV 2000,volume 1855 of Lecture Notes in Computer Science, Springer,2000.

- 70 -

References

• S. Seshia, et al. A Translation of Statecharts to Esterel. In Proc. of the 1st World Congress on Formal Methods (FM’99),.

• R. Alur, et al. Exploiting behavioral hierarchy for ef-ficient model checking. In 14th Int. Conf. on Computer-Aided Verification CAV’02, LNCS, 2002.







- 71 -

Thanks

- 1 - in the name of god review of statecharts and its model checking techniques by shah mohammadi

Documents