lecture-19-state-machines-NuSMV-3

lecture-19-state-machines-NuSMV-3 - Lecture 19 - State...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Lecture 19 - State Machines and NuSMV Spring 2009 Csci 5802 Introduction to State Machines and NuSMV Language Adopted from Ajitha Rajan 1 Introduction • Describing embedded system’s processing behavior Can be extremely difficult http://www.umsec.umn.edu Complexity increasing with increasing IC capacity Desired behavior often not fully understood in beginning – Many implementation bugs due to description mistakes/omissions English (or other natural language) common starting point Precise description difficult to impossible 2 An example of trying to be precise in English • California Vehicle Code Right-of-way of crosswalks http://www.umsec.umn.edu 21950. (a) The driver of a vehicle shall yield the right-of-way to a pedestrian crossing the roadway within any marked crosswalk or within any unmarked crosswalk at an intersection, except as otherwise provided in this chapter. (b) The provisions of this section shall not relieve a pedestrian from the duty of Th thi th using due care for his or her safety. No pedestrian shall suddenly leave a curb or other place of safety and walk or run into the path of a vehicle which is so close as to constitute an immediate hazard. No pedestrian shall unnecessarily stop or delay traffic while in a marked or unmarked crosswalk. (c) The provisions of subdivision (b) shall not relieve a driver of a vehicle from the duty of exercising due care for the safety of any pedestrian within any marked crosswalk or within any unmarked crosswalk at an intersection. All that just for crossing the street (and there’s much more)! Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis 3 CSci 5802 - Mats Heimdahl 1 Lecture 19 - State Machines and NuSMV Spring 2009 Models and languages • How can we (precisely) capture behavior? • Common computation models: We may think of languages (C, C++), but computation model is the key http://www.umsec.umn.edu Sequential program model Communicating process model process model State machine model Dataflow model Object-oriented model Statements, rules for composing statements, semantics for executing them Multiple sequential programs running concurrently For control dominated systems, monitors control inputs, sets control outputs For data dominated systems, transforms input data streams into output streams For breaking complex software into simpler, well-defined pieces Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis 4 Models vs. languages Models State machine Sequent. program Dataflow C C++ Java Languages http://www.umsec.umn.edu • Computation models describe system behavior • Languages capture models Conceptual notion, e.g., sequential program Concrete form, e.g., C • Variety of languages can capture one model • One language can capture variety of models • Certain languages better at capturing certain computation models E.g., sequential program model C,C++, Java E.g., C++ → sequential program model, object-oriented model, state machine model 5 Text versus Graphics • Models versus languages not to be confused with text versus graphics Text and graphics are just two types of languages http://www.umsec.umn.edu Text: letters, numbers Graphics: circles, arrows (plus some letters, numbers) X=1 X = 1; Y = X + 1; Y= X+ 1 6 CSci 5802 - Mats Heimdahl 2 Lecture 19 - State Machines and NuSMV Spring 2009 Introductory example: An elevator controller • Partial English description Simple elevator controller http://www.umsec.umn.edu • “Move the elevator either up or down to reach the requested floor. Once at the requested floor, open the door for at least 10 seconds, and keep it open until the requested floor changes. Ensure the door is never open while moving. Don’t change directions unless there are no higher requests when moving up or no lower requests when moving down…” Request Resolver resolves various floor requests into single requested floor Unit Control moves elevator to this requested floor System interface up Unit Control down open floor req Request Resolver ... buttons inside elevator b1 b2 bN up1 up2 dn2 up3 dn3 up/down buttons on each floor ... dnN Try capturing in C... Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis 7 Elevator controller using a sequential program model System interface Sequential program model Inputs: int floor; bit b1..bN; up1..upN-1; dn2..dnN; Outputs: bit up, down, open; Global variables: int req; http://www.umsec.umn.edu void UnitControl() { up = down = 0; open = 1; while (1) { while (req == floor); open = 0; if (req > floor) { up = 1;} else {down = 1;} while (req != floor); up = down = 0; open = 1; delay(10); } } void RequestResolver() { while (1) ... req = ... ... } void main() { Call concurrently: UnitControl() and RequestResolver() } Partial English description “Move the elevator either up or down to reach the requested floor. Once at the requested floor, open the door for at least 10 seconds, and keep it open until the requested floor changes. Ensure the door is never open while moving. Don’t change directions unless there are no higher requests when moving up or no lower requests when moving down…” down open floor req Request Resolver ... b1 b2 bN up1 up2 dn2 up3 dn3 You might have come up with something having even more if statements. Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis up Unit Control buttons inside elevator up/down buttons on each floor ... dnN 8 Finite-state machine (FSM) model • • Trying to capture this behavior as sequential program is a bit awkward Instead, we might consider an FSM model, describing the system as: http://www.umsec.umn.edu Possible states states Possible transitions from one state to another based on input Actions that occur in each state • E.g., Idle, GoingUp, GoingDn, DoorOpen E.g., req > floor E.g., In the GoingUp state, u,d,o,t = 1,0,0,0 (up = 1, down, open, and timer_start = 0) Try it... Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis 9 CSci 5802 - Mats Heimdahl 3 Lecture 19 - State Machines and NuSMV Spring 2009 Describing a system as a state machine 1. List all possible states 2. Declare all variables (none in this example) 3. For each state, list possible transitions, with conditions, to other states http://www.umsec.umn.edu 4. For each state and/or transition, list associated actions 5. For each state, ensure exclusive and complete exiting transition conditions • No two exiting conditions can be true at same time • One condition must be true at any given time – – Otherwise nondeterministic state machine Reducing explicit transitions should be avoided when first learning Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis 10 Describing a system as a state machine 1. List all possible states 2. Declare all variables (none in this example) 3. For each state, list possible transitions, with conditions, to other states http://www.umsec.umn.edu 4. For each state and/or transition, list associated actions 5. For each state, ensure exclusive and complete exiting transition conditions • • u,d,o,t = 0,1,0,0 One condition must be true at any given time – !(timer < 10) DoorOpen u,d,o,t = 0,0,1,1 req < floor !(req<floor) GoingDn u is up, d is down, o is open req < floor Reducing explicit transitions should be avoided when first learning Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis timer < 10 Idle req == floor Otherwise nondeterministic state machine !(req > floor) GoingUp req > floor u,d,o,t = 0,0,1,0 No two exiting conditions can be true at same time – req > floor u,d,o, t = 1,0,0,0 t is timer_start 11 Finite-state machine (FSM) model UnitControl process using a state machine req > floor u,d,o, t = 1,0,0,0 GoingUp !(req > floor) http://www.umsec.umn.edu timer < 10 10 req > floor fl !(timer < 10) u,d,o,t = 0,0,1,0 Idle req == floor u,d,o,t = 0,1,0,0 DoorOpen u,d,o,t = 0,0,1,1 req < floor !(req<floor) GoingDn u is up, d is down, o is open req < floor Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis t is timer_start 12 CSci 5802 - Mats Heimdahl 4 Lecture 19 - State Machines and NuSMV Spring 2009 Formal definition • An FSM is a 6-tuple F<S, I, O, F, H, s0> http://www.umsec.umn.edu S is a set of all states {s0, s1, …, sl} I is a set of inputs {i0, i1, …, im} O is a set of outputs {o0, o1, …, on} F is a next-state function (S x I → S) H is an output function (S → O) s0 is an initial state • Moore-type • Mealy-type Associates outputs with states (as given above, H maps S → O) Associates outputs with transitions (H maps S x I → O) 13 State machine vs. sequential program model • • Different thought process used with each model State machine: http://www.umsec.umn.edu • Sequential program model: • Encourages designer to think of all possible states and transitions among states based on all possible input conditions Designed to transform data through series of instructions that may be iterated to transform data through series of instructions that may be iterated and conditionally executed State machine description excels in many cases More natural means of computing in those cases Not due to graphical representation (state diagram) Would still have same benefits if textual language used (i.e., state table) Besides, sequential program model could use graphical representation (i.e., flowchart) Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis 14 Introduction to NuSMV 15 CSci 5802 - Mats Heimdahl 5 Lecture 19 - State Machines and NuSMV Spring 2009 NuSMV NuSMV is both a language and a tool (like Simulink) • NuSMV language has two parts http://www.umsec.umn.edu Modeling language: a basic programming language for creating model Verification language: for checking behavior of model • Checks properties written in CTL or LTL Also allows constraints on model to restrict environment NuSMV tool is a symbolic model checker Uses binary decision diagrams (BDDs) to represent data sets; much more efficient than explicit model-checkers for certain problems Limiting factor is BDD description of the state-space. Often scales better than explicit model checkers. 16 Overview of NuSMV SMV Input Language Backend http://www.umsec.umn.edu Finite State Kripke Structure OBDD based Symbolic Model Checking Yes Specification – TL Formula No CounterExample 17 Kripke Structure • • Let AP be a set of atomic propositions Kripke structure, M = (S, S0, R, L) where http://www.umsec.umn.edu S is a finite set of states S0 is a set of initial states set of initial states R ⊆ S × S is a transition relation such that for every state s ∈ S there is a state s' ∈ S such that R(s,s') L: S → 2AP is a function that labels every state with the set of atomic propositions true in that state 18 CSci 5802 - Mats Heimdahl 6 Lecture 19 - State Machines and NuSMV Spring 2009 Example Kripke Structures • A Simple Telephone http://www.umsec.umn.edu 19 Language Characteristics • Allows description of completely synchronous to asynchronous systems http://www.umsec.umn.edu • Modularized and hierarchical descriptions • Finite data types: Boolean and enumerated • Parallel-Assignment Syntax • Non-Determinism 20 A Sample NuSMV Program http://www.umsec.umn.edu MODULE main VAR request: boolean; state: {ready, busy}; ASSIGN init(state) := ready; next(state) := case state=ready & request: busy; state=ready & !request : ready; 1: {ready, busy}; esac; SPEC AG(request -> AF (state = busy)) 21 CSci 5802 - Mats Heimdahl 7 Lecture 19 - State Machines and NuSMV Spring 2009 Exercise Accessing a Critical Resource http://www.umsec.umn.edu idle entering critical exiting 22 Solution (bad) MODULE user() VAR state : {idle, entering, critical, exiting}; http://www.umsec.umn.edu ASSIGN init(state) next(state) case state = state = state = state = 1 esac; := idle; := idle entering critical exiting : : : : : {idle, entering}; critical; {critical, exiting}; idle; state; 23 SMV Syntax - Expressions http://www.umsec.umn.edu Expr :: atom | number | id | “!” expr | expr1 <op> expr2 | “next” “(“ id “)” | case_expr | set_expr ;; symbolic constant ;; numeric constant ;; variable identifier ;; logical not ;; next value 24 CSci 5802 - Mats Heimdahl 8 Lecture 19 - State Machines and NuSMV Spring 2009 The Case Expression http://www.umsec.umn.edu Case_expr :: “case” expr_a1 “:” expr_b2 “;” … expr_an “:” expr_bn “;” “esac” • Guards are evaluated sequentially. • The first one that is true determines the resulting value • If none of the guards are true, result is numeric value 1 25 State Variables http://www.umsec.umn.edu Decl :: “VAR” atom1 “:” type1 “;” atom2 “:” type2 “;” … State is an assignment of values to a set of state variables Type of a variable – boolean, scalar, user defined module, or array. 26 ASSIGN declaration http://www.umsec.umn.edu Decl :: “ASSIGN” dest1 “:=“ expr1 “;” dest2 “:=“ expr2 “;” … Dest :: atom | “init” “(“ atom “)” | “next” “(“ atom “)” 27 CSci 5802 - Mats Heimdahl 9 Lecture 19 - State Machines and NuSMV Spring 2009 Variable Assignments • Assignment to initial state: init(value) := 0; • Assignment to next state (transition relation) next(value) := value + carry_in mod 2; http://www.umsec.umn.edu • Assignment tto current state (invariant) o current state carry_out := value & carry_in; • Either init-next or invar should be used, but not both • SMV is a parallel assignment language 28 Circular definitions • • … are not allowed! This is illegal: http://www.umsec.umn.edu • a := next(b); next(b) := c; c := a; This is o.k. init(a) := 0; next(a) := !b; init(b) := 1; next(b) := !a; 29 Exercise proc1 idle entering critical exiting http://www.umsec.umn.edu proc2 idle entering critical exiting 30 CSci 5802 - Mats Heimdahl 10 Lecture 19 - State Machines and NuSMV Spring 2009 Solution (bad) MODULE main VAR proc1 : process user(); proc2 : process user(); SPEC AG !(proc1.state = critical & proc2.state = critical) ASSIGN http://www.umsec.umn.edu MODULE user() VAR state : {idle, entering, critical, exiting}; ASSIGN init(state) next(state) case state = state = state = state = 1 esac; := idle; := idle entering critical exiting : : : : : {idle, entering}; critical; {critical, exiting}; idle; state; 31 Exercise (better) proc1 / sem:=false !sem / sem:=true idle entering critical exiting http://www.umsec.umn.edu sem: Boolean proc2 / sem:=false !sem / sem:=true idle entering critical exiting 32 Nondeterminism Completely unassigned variable can model unconstrained input. • http://www.umsec.umn.edu • {val_1, …, val_n} is an expression taking on any of the given values nondeterministically. the given values nondeterministically. • Nondeterministic choice can be used to: Model an implementation that has not been refined yet Abstract behavior 33 CSci 5802 - Mats Heimdahl 11 Lecture 19 - State Machines and NuSMV Spring 2009 Modules and Hierarchy http://www.umsec.umn.edu • 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 Parameters are passed by reference. 34 Module Composition • Synchronous composition All assignments are executed in parallel and synchronously. A single step of the resulting model corresponds to a step in each of the components. http://www.umsec.umn.edu • Asynchronous composition A step of the composition is a step by exactly one process. Variables, not assigned in that process, are left unchanged. 35 ASSIGN and DEFINE • VAR a: boolean; ASSIGN a := b | c; declares a new state variable a becomes part of invariant relation http://www.umsec.umn.edu • 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 the BDD for b | c becomes part of each expression using d 36 CSci 5802 - Mats Heimdahl 12 Lecture 19 - State Machines and NuSMV Spring 2009 NuSMV • Specifications expressible in CTL, LTL and Real time CTL logics http://www.umsec.umn.edu • Provides both BDD and SAT based model checking. • Uses a number of heuristics for achieving efficiency and control state explosion • Higher number of features in interactive mode 37 Downloads • SMV www.cs.cmu.edu/~modelcheck/smv.html http://nusmv.irst.itc.it/ http://wwwcad.eecs.berkeley.edu/~kenmcmil/smv • NuSMV http://www.umsec.umn.edu • Cadence SMV 38 Sample Stateflow Specification http://www.umsec.umn.edu 39 CSci 5802 - Mats Heimdahl 13 Lecture 19 - State Machines and NuSMV Spring 2009 Summary • State machines provide an effective way of http://www.umsec.umn.edu • • modeling system behaviour in response to internal or external events Several modeling notations available Examined the syntax of the NuSMV modeling language 40 CSci 5802 - Mats Heimdahl 14 ...
View Full Document

This note was uploaded on 10/21/2011 for the course CSCI 5802 taught by Professor Heimdahl,m during the Spring '08 term at Minnesota.

Ask a homework question - tutors are online