IN THE NAME OF GOD Review of Statecharts

IN THE NAME OF GOD Review of Statecharts and Its Model Checking Techniques BY SHAH MOHAMMADI - 1 -

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 - 2 -

Requirements for specification techniques • Hierarchy Humans not capable to understand systems containing more than ~5 objects. Most actual systems require more objects • Behavioral hierarchy • Structural hierarchy • Timing behavior. - 3 -

Requirements for specification techniques(1) • Event-handling (external or internal events) • Exception-oriented behavior Not acceptable to describe exceptions for every state. exception We will see, how all the arrows labeled k can be replaced by a single one. . - 4 -

Requirements for specification techniques (2) • Concurrency Real-life systems are concurrent • Synchronization and communication Components have to communicate! • Presence of programming elements For 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. - 5 -

State. Charts • Classical automata not useful for complex systems • complex graphs cannot be understood by humans. • Introduction of hierarchy State. Charts [Harel, 1987] • State. Chart = the only unused combination of • “flow” or “state” with “diagram” or “chart” - 6 -

Introducing hierarchy FSM will be in exactly one of the substates of S is active (either in A or in B or. . ) super-state S sub-states - 7 -

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 substates of S is active whenever S is active. ancestor state of E - 8 -

Default state mechanism • Filled circle indicates sub-state entered whenever superstate is entered. - 9 -

History mechanism (behavior different from last slide) • 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. - 10 -

Concurrency • Convenient ways of describing concurrency are required. • AND-states: FSM is in all (immediate) sub-states of a superstate; Example: - 11 -

Types of states • In State. Charts, states are either • basic states, or • AND-states, or • OR-states. • Root : no parent state - 12 -

General form of edge labels event [condition] / reaction • 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 - 13 -

Broadcast mechanism • Values of variables are visible to all parts of the State. Chart model. • State. Charts implicitly assumes a broadcast mechanism for variables. - 14 -

Semantics of Statecharts • Implemented in the STATEMATE system. • First executable semantics defined for the Statecharts • Support different styles of modeling - 15 -

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 Status= values of all variables + set of events + current time - 16 -

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) - 17 -

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 - 18 -

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 - 19 -

Full configuration (all parents and root) Basic configuration - 20 -

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 - 21 -

Problems in verification of statecharts models • State Hierarchy • Inter-level transitions • Conflicting transitions and transition priority • STATEMATE semantics • UML semantics • Concurrency • Communication • History - 22 -

Introduction to SMV • Symbolic Model Verifier • Specifications given as CTL formulas • Internal representation using BDDs • Automatically verifies specification or produces a Counterexample - 23 -

Language Characteristics • Allows description of synchronous and asynchronous systems • Modularized and hierarchical descriptions • Finite data types: Boolean and enumerated • Nondeterminism - 24 -

Variable Assignments • Assignment to initial state: init(value) : = 0; • Assignment to next state (transition relation) next(value) : = value + carry_in mod 2; - 25 -

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 - 26 -

Alternative of 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) - 27 -

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. - 28 -

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 - 29 -

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 • t 0 : = in-PICTURE & txt; • t 1 : = in-TEXT & txt; - 30 -

Translation to SMV • Next state: ASSIGN • next(TV=: ( • case • t 6: WORKING; • . . . • : 1 TV; • esac; • Event generated: • • • next(txt=: ( case stable: {0, 1{ ; 0 : 1 esac; • Initialize states : • init(TV) : = WAITING; - 31 -

Problems • Nondeterminism • Synchrony Hypothesis • Transition Priority • Other features • History connectors - 32 -

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. - 33 -

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. - 34 -

Part of the SMV code for the statechart 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( - 35 -

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 - 36 -

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. - 37 -

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. - 38 -

PROMELA Model Basics • Promela model consists of: • type declarations • channel declarations • variable declarations • process declarations • • mtype = {MSG, ACK}; chan to. S; chan to. R; bool flag; • • proctype sender() { … } proctype receiver() { … } - 39 -

Executability • 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 - 40 -

Non-Determinism • Process interleaving and statement execution is nondeterministic: if : : z++ : : z-fi do : : ch? msg : : ch!MSG : : break od - 41 -

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 - 42 -

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 - 43 -

EHA • An EHA consists of a set of sequential automata (SA). • A SA A is a 4 -tuple ( , s 0, 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, , s 0, 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 - 44 -

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 A 0 F • Every non-root automata has exactly one ancestor state • There are no cycles - 45 -

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 subautomata must contribute to the Conf, and vice versa. • set of all Confs are denoted by Conf) (. - 46 -

Translation to spin • The semantics of an EHA H = (F, E, ) is given in terms of a Kripke structure K=(S, s 0, step), where • S=Conf( ) × (E) • s = (C , 0) 0 0 • step S × S • operational semantics is in terms of three principal rules: • Progress Rule • Composition Rule • Stuttering Rule - 47 -

Translation to PROMELA • • Variables used as states of K Processes encode the transition relation of K. Events defined as booleans The translation supports the closed systems only. - 48 -

Problems • Statecharts subset • History - 49 -

Translating UML Statecharts to PROMELA (Latella) • The method is similar to the previous approach. • In translation : • UML transition priorities are considered. - 50 -

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. - 51 -

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 - 52 -

Problems • Statecharts subset • History • Multiple statecharts • The translation does not consider multiple statecharts with multiple input queues. • Complexity - 53 -

Translating using v. UML(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 v. UML tool - 54 -

Features of this formalisation • allows to formulate the transition selection algorithm. • verification is limited to deadlock checking. • verification by SPIN without user intervention. - 55 -

Problems • Statecharts subset • The subset of UML statecharts considered is bigger than the other works. • Scope of Verification • Deadlock detection - 56 -

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 . - 57 -

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. - 58 -

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. - 59 -

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. - 60 -

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 - 61 -

Mode example - 62 -

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 - 63 -

Verification • Assertion condition • Point or mode • Invariants • For all states of the system • Hermes toolkit • Create, …, verify HRM diagrams - 64 -

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 - 65 -

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 - 66 -

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 - 67 -

Conclusion (cont) • Lack of traceability between the front-end and back-end design models. • Mikk, Damm • Test on actual industrial examples. - 68 -

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 2 nd 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, 12 th Int. Conf. CAV 2000, volume 1855 of Lecture Notes in Computer Science, Springer, 2000. - 69 -

References • S. Seshia, et al. A Translation of Statecharts to Esterel. In Proc. of the 1 st World Congress on Formal Methods (FM’ 99), . • R. Alur, et al. Exploiting behavioral hierarchy for ef-ficient model checking. In 14 th Int. Conf. on Computer-Aided Verification CAV’ 02, LNCS, 2002. - 70 -

Thanks - 71 -