lecture-19-state-machines-NuSMV-6

lecture-19-state-machines-NuSMV-6 - 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 Introduction Csci 5802 Introduction to State Machines and NuSMV Language 1 behavior Can be extremely difficult http://www.umsec.umn.edu t Adopted from Ajitha Rajan • Describing embedded system’s processing – Many implementation bugs due to description mistakes/omissions English (or other natural language) common starting point Models and languages • Right-of-way of crosswalks 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 Common computation models: We may think of languages (C, C++), but computation model is the key http://www.umsec.umn.edu t 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. How can we (precisely) capture behavior? • • California Vehicle Code Sequential program model Communicating process model process model State machine model Dataflow model Object-oriented model State machine Sequent. program 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 Models vs. languages Models Precise description difficult to impossible 2 An example of trying to be precise in English Complexity increasing with increasing IC capacity Desired behavior often not fully understood in beginning 4 Text versus Graphics • Models versus languages not to be confused with Dataflow text versus graphics Languages C C++ 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 • E.g., sequential program model C,C++, Java E.g., C++ → sequential program model, object-oriented model, state machine model Certain languages better at capturing certain computation models 5 CSci 5802 - Mats Heimdahl http://www.umsec.umn.edu t http://www.umsec.umn.edu • Java Text and graphics are just two types of languages Text: letters, numbers Graphics: circles, arrows (plus some letters, numbers) X=1 X = 1; Y = X + 1; Y= X+ 1 6 1 Lecture 19 - State Machines and NuSMV Spring 2009 Introductory example: An elevator controller • Request Resolver resolves various floor requests into single requested floor Unit Control moves elevator to this requested floor “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 ... buttons inside elevator b1 b2 bN up1 up/down buttons on each floor up2 dn2 up3 dn3 ... dnN Try capturing in C... Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis 7 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); } } • Possible states states Possible transitions from one state to another based on input E.g., req > floor Actions that occur in each state • E.g., Idle, GoingUp, GoingDn, DoorOpen 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 void main() { Call concurrently: UnitControl() and RequestResolver() } down open floor req Request Resolver ... b1 b2 bN up1 up2 dn2 up3 dn3 buttons inside elevator up/down buttons on each floor ... dnN Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis 8 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 t 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…” void RequestResolver() { while (1) ... req = ... ... } up Unit Control Describing a system as a state machine Trying to capture this behavior as sequential program is a bit awkward Instead, we might consider an FSM model, describing the system as: Partial English description You might have come up with something having even more if statements. Finite-state machine (FSM) 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; up Unit Control http://www.umsec.umn.edu t http://www.umsec.umn.edu • System interface Partial English description Simple elevator controller Elevator controller using a sequential program model Describing a system as a state machine 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 Finite-state machine (FSM) model 1. List all possible states 2. Declare all variables (none in this example) UnitControl process using a state machine 3. For each state, list possible transitions, with conditions, to other states • No two exiting conditions can be true at same time – • Otherwise nondeterministic state machine req > floor u,d,o, t = 1,0,0,0 u,d,o, t = 1,0,0,0 req > floor Idle req == floor u,d,o,t = 0,1,0,0 !(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 u,d,o,t = 0,0,1,0 One condition must be true at any given time – !(req > floor) GoingUp 11 CSci 5802 - Mats Heimdahl t is timer_start http://www.umsec.umn.edu t 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 req > floor GoingUp !(req > floor) 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 2 Lecture 19 - State Machines and NuSMV Spring 2009 State machine vs. sequential program model Formal definition • • 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 Associates outputs with states (as given above, H maps S → O) Mealy-type Different thought process used with each model State machine: http://www.umsec.umn.edu t http://www.umsec.umn.edu • • • An FSM is a 6-tuple F<S, I, O, F, H, s0> Associates outputs with transitions (H maps S x I → O) 13 • 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 NuSMV NuSMV is both a language and a tool (like Simulink) • Introduction to NuSMV http://www.umsec.umn.edu t 15 NuSMV language has two parts Modeling language: a basic programming language for creating model Verification language: for checking behavior of model • 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 Kripke Structure • • Backend Let AP be a set of atomic propositions Kripke structure, M = (S, S0, R, L) where OBDD based Symbolic Model Checking Specification – TL Formula No CounterExample 17 CSci 5802 - Mats Heimdahl Yes http://www.umsec.umn.edu t http://www.umsec.umn.edu Finite State Kripke Structure Checks properties written in CTL or LTL Also allows constraints on model to restrict environment 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 3 Lecture 19 - State Machines and NuSMV Spring 2009 Example Kripke Structures Language Characteristics • Allows description of completely synchronous to • A Simple Telephone asynchronous systems http://www.umsec.umn.edu t http://www.umsec.umn.edu 19 • Modularized and hierarchical descriptions • Finite data types: Boolean and enumerated • Parallel-Assignment Syntax • Non-Determinism 20 A Sample NuSMV Program 21 Accessing a Critical Resource http://www.umsec.umn.edu t 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)) Exercise Solution (bad) VAR state : {idle, entering, critical, exiting}; idle entering critical exiting : : : : : 23 CSci 5802 - Mats Heimdahl {idle, entering}; critical; {critical, exiting}; idle; state; http://www.umsec.umn.edu t http://www.umsec.umn.edu := idle; := entering critical exiting 22 SMV Syntax - Expressions MODULE user() ASSIGN init(state) next(state) case state = state = state = state = 1 esac; idle 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 4 Lecture 19 - State Machines and NuSMV Spring 2009 The Case Expression 25 http://www.umsec.umn.edu t 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 State Variables 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 Variable Assignments ASSIGN declaration 27 • Assignment to initial state: init(value) := 0; • Assignment to next state (transition relation) next(value) http://www.umsec.umn.edu t http://www.umsec.umn.edu Decl :: “ASSIGN” dest1 “:=“ expr1 “;” dest2 “:=“ expr2 “;” … Dest :: atom | “init” “(“ atom “)” | “next” “(“ atom “)” 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 • • proc1 a := next(b); next(b) := c; c := a; idle This is o.k. init(a) := 0; next(a) := !b; init(b) := 1; next(b) := !a; 29 CSci 5802 - Mats Heimdahl http://www.umsec.umn.edu t http://www.umsec.umn.edu • Exercise … are not allowed! This is illegal: := value + carry_in mod 2; • Assignment tto current state (invariant) o current state entering critical exiting proc2 idle entering critical exiting 30 5 Lecture 19 - State Machines and NuSMV Spring 2009 Solution (bad) Exercise (better) proc1 MODULE main VAR proc1 : process user(); proc2 : process user(); / sem:=false !sem / sem:=true SPEC AG !(proc1.state = critical & proc2.state = critical) idle entering critical exiting ASSIGN 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 http://www.umsec.umn.edu t http://www.umsec.umn.edu MODULE user() sem: Boolean proc2 idle • Nondeterministic choice can be used to: Model an implementation that has not been refined yet Abstract behavior 33 Modules can be instantiated many times, each instantiation creates a copy of the local variables • • Each program has a module main Scoping • 34 ASSIGN and DEFINE • VAR a: boolean; • Synchronous composition ASSIGN a := b | c; declares a new state variable a becomes part of invariant relation A step of the composition is a step by exactly one process. Variables, not assigned in that process, are left unchanged. 35 CSci 5802 - Mats Heimdahl http://www.umsec.umn.edu t http://www.umsec.umn.edu • Asynchronous composition Variables declared outside a module can be passed as parameters Parameters are passed by reference. Module 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. exiting • http://www.umsec.umn.edu t http://www.umsec.umn.edu {val_1, …, val_n} is an expression taking on any of the given values nondeterministically. the given values nondeterministically. critical Modules and Hierarchy Completely unassigned variable can model unconstrained input. • entering 32 Nondeterminism • / sem:=false !sem / sem:=true • 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 6 Lecture 19 - State Machines and NuSMV Spring 2009 NuSMV Downloads • SMV • • • NuSMV • time CTL logics 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 http://www.umsec.umn.edu t http://www.umsec.umn.edu • Specifications expressible in CTL, LTL and Real www.cs.cmu.edu/~modelcheck/smv.html http://nusmv.irst.itc.it/ http://wwwcad.eecs.berkeley.edu/~kenmcmil/smv • Cadence SMV 38 Sample Stateflow Specification Summary • State machines provide an effective way of CSci 5802 - Mats Heimdahl http://www.umsec.umn.edu t http://www.umsec.umn.edu 39 • • modeling system behaviour in response to internal or external events Several modeling notations available Examined the syntax of the NuSMV modeling language 40 7 ...
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