lecture-19-state-machines-NuSMV-2

lecture-19-state-machines-NuSMV-2 - 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 oduc NuSMV Language Adopted from Ajitha Rajan 1 Introduction • Describing embedded system’s processing behavior behavior Can be extremely difficult http://www.umsec.umn.edu w 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 (or other natural language) common starting point CSci 5802 - Mats Heimdahl Precise description difficult to impossible 2 1 Lecture 19 - State Machines and NuSMV Spring 2009 An example of trying to be precise in English • California Vehicle Code Right-of-way of crosswalks of crosswalks http://www.umsec.umn.edu w 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 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 Models and languages • • How can we (precisely) capture behavior? We may think of languages (C, C++), but computation model is the key Common computation models: Sequential program model http://www.umsec.umn.edu w Statements, rules for composing statements, semantics for executing them Communicating process model State machine model Multiple sequential programs running concurrently For control dominated systems, monitors control inputs, sets control outputs Dataflow model Object-oriented model 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 CSci 5802 - Mats Heimdahl 4 2 Lecture 19 - State Machines and NuSMV Spring 2009 Models vs. languages Models State machine Sequent. program Dataflow C C++ Java Languages http://www.umsec.umn.edu w • Computation models describe system behavior • Languages capture models • Variety of languages can capture one model • • Conceptual notion, e.g., sequential program Concrete form, e.g., C E.g., sequential program model C,C++, Java One language can capture variety of models E.g., C++ → sequential program model, object-oriented model, state machine model Certain languages better at capturing certain computation models 5 Text versus Graphics • Models versus languages not to be confused with text versus graphics text versus graphics Text and graphics are just two types of languages http://www.umsec.umn.edu w CSci 5802 - Mats Heimdahl Text: letters, numbers Graphics: circles, arrows (plus some letters, numbers) X=1 X = 1; Y = X + 1; Y=X+1 6 3 Lecture 19 - State Machines and NuSMV Spring 2009 Introductory example: An elevator controller • Partial English description Simple elevator controller http://www.umsec.umn.edu w • “Move the elevator either up or down 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 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 w 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…” CSci 5802 - Mats Heimdahl 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 each floor ... dnN 8 4 Lecture 19 - State Machines and NuSMV Spring 2009 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 w Possible 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 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 w 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 – • Otherwise nondeterministic state machine One condition must be true at any given time – Reducing explicit transitions should be avoided when first learning Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis CSci 5802 - Mats Heimdahl 10 5 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 w 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 = 1,0,0,0 Idle 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 req > floor req == floor Otherwise nondeterministic state machine !(req > floor) GoingUp u,d,o,t = 0,0,1,0 No two exiting conditions can be true at same time – req > floor 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 w timer < 10 req > floor !(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 CSci 5802 - Mats Heimdahl t is timer_start 12 6 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 w 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 w • 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 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 CSci 5802 - Mats Heimdahl 14 7 Lecture 19 - State Machines and NuSMV Spring 2009 Introduction to NuSMV 15 NuSMV NuSMV is both a language and a tool (like Simulink) • NuSMV language has two parts http://www.umsec.umn.edu w 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 tool is 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. CSci 5802 - Mats Heimdahl 16 8 Lecture 19 - State Machines and NuSMV Spring 2009 Overview of NuSMV SMV Input Language Language Backend http://www.umsec.umn.edu w 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 (S L) http://www.umsec.umn.edu w CSci 5802 - Mats Heimdahl S is a finite set of states S0 is a 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 th R( 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 9 Lecture 19 - State Machines and NuSMV Spring 2009 Example Kripke Structures • A Simple Telephone http://www.umsec.umn.edu w 19 Language Characteristics • Allows description of completely synchronous to asynchronous systems http://www.umsec.umn.edu w • Modularized and hierarchical descriptions • Finite data types: Boolean and enumerated • Parallel-Assignment Syntax Non-Determinism CSci 5802 - Mats Heimdahl 20 10 Lecture 19 - State Machines and NuSMV Spring 2009 A Sample NuSMV Program http://www.umsec.umn.edu w 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 Exercise Accessing a Critical Resource http://www.umsec.umn.edu w idle CSci 5802 - Mats Heimdahl entering critical exiting 22 11 Lecture 19 - State Machines and NuSMV Spring 2009 Solution (bad) MODULE user() VAR state : {idle, entering, critical, exiting}; http://www.umsec.umn.edu w 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 w Expr :: atom atom | number | id | “!” expr | expr1 <op> expr2 | “next” “(“ id “)” “next” “(“ id “)” | case_expr | set_expr CSci 5802 - Mats Heimdahl ;; symbolic constant ;; symbolic constant ;; numeric constant ;; variable identifier ;; logical not ;; next value ;; next value 24 12 Lecture 19 - State Machines and NuSMV Spring 2009 The Case Expression http://www.umsec.umn.edu w Case_expr :: “case” expr_a1 “:” expr_b2 “;” expr … expr_an “:” expr_bn “;” “esac” • Guards are evaluated sequentially. • The first one tthat is true determines tthe resulting fi h h value • If none of the guards are true, result is numeric value 1 25 State Variables http://www.umsec.umn.edu w 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. CSci 5802 - Mats Heimdahl 26 13 Lecture 19 - State Machines and NuSMV Spring 2009 ASSIGN declaration http://www.umsec.umn.edu w Decl :: “ASSIGN” dest1 “:=“ expr1 “;” dest2 “:=“ expr2 “;” … Dest :: atom | “init” “(“ atom “)” init atom | “next” “(“ atom “)” 27 Variable Assignments • Assignment to initial state: • http://www.umsec.umn.edu w • • init(value) := 0; Assignment to next state (transition relation) next(value) := value + carry_in mod 2; Assignment to current state (invariant) carry_out := value & carry_in; Either init-next or invar should be used, but not both • SMV is a parallel assignment language CSci 5802 - Mats Heimdahl 28 14 Lecture 19 - State Machines and NuSMV Spring 2009 Circular definitions • • … are not allowed! This is illegal: is illegal: http://www.umsec.umn.edu w • 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 http://www.umsec.umn.edu w CSci 5802 - Mats Heimdahl entering critical exiting proc2 idle entering critical exiting 30 15 Lecture 19 - State Machines and NuSMV Spring 2009 Solution (bad) MODULE main VAR proc1 : process user(); proc2 : process user(); process user(); SPEC AG !(proc1.state = critical & proc2.state = critical) ASSIGN http://www.umsec.umn.edu w 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 w sem: Boolean proc2 CSci 5802 - Mats Heimdahl / sem:=false sem !sem / sem:=true idle entering critical exiting 32 16 Lecture 19 - State Machines and NuSMV Spring 2009 Nondeterminism Completely unassigned variable can model unconstrained input. • http://www.umsec.umn.edu w • {val_1, …, val_n} is an expression taking on any of the given values nondeterministically. • Nondeterministic choice can be used to: Model an implementation that has not been refined yet Abstract behavior 33 Modules and Hierarchy http://www.umsec.umn.edu w • 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. CSci 5802 - Mats Heimdahl 34 17 Lecture 19 - State Machines and NuSMV Spring 2009 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 w • Asynchronous composition A step of the composition is a step by exactly one process. step of the composition is 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 w • DEFINE d:= b | c; CSci 5802 - Mats Heimdahl is effectively a macro definition, each occurrence of d is replaced by 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 18 Lecture 19 - State Machines and NuSMV Spring 2009 NuSMV • Specifications expressible in CTL, LTL and Real http://www.umsec.umn.edu w • • • 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 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 w • Cadence SMV CSci 5802 - Mats Heimdahl 38 19 Lecture 19 - State Machines and NuSMV Spring 2009 Sample Stateflow Specification http://www.umsec.umn.edu w 39 Summary • State machines provide an effective way of http://www.umsec.umn.edu w • • modeling system behaviour in response to modeling system behaviour in response to internal or external events Several modeling notations available Examined the syntax of the NuSMV modeling language CSci 5802 - Mats Heimdahl 40 20 ...
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