Docstoc

Finite State Machines _FSM's_

Document Sample
Finite State Machines _FSM's_ Powered By Docstoc
					          Finite State Machines (FSM’s)

Finite state machines are used to specify applications that can
   be modeled in terms of states and transitions between
   states. They are a useful technique for “event driven
   systems.” Many machines with software controllers fall
   into this category - in manufacturing, appliances,
   telephones. A classic example of using FSM’s is in the
   design of user interfaces. When the user enters input at the
   keyboard or selects a button with the mouse these are
   events that causes the program to go into some other state.
FSM’s can represent a large amount of written specifications
  in a readily understandable pictorial form. When used in
  the design process they can make programs easier to test
  and check against requirements and specifications. It helps
  in checking the code of certain programs against
  specifications if the parts of the program can be tied to an
  FSM diagram.

FSM’s are used in engineering (e.g. designing logic circuits),
  software engineering, and for pattern recognition.
FSM’s are directed graphs whose arcs are labeled by sets of
  characters. The arcs are called transitions. The graph’s
  nodes represent the states of the program. States are
  “...certain positions in a program’s code at which we know
  something particular about the program’s progress toward
  its goal…”(Aho and Ullman, 1995). At a node action is
  suspended pending one or more external events. The start
  state of the FSM is indicated by an arrow entering from
  nowhere to the start node. Nodes with no outputs are
  known as accepting states.
State machine for processing a basic telephone call (Grosberg, n.d.)
Computers are really state machines with an unimaginably
  large number of states. A computer system is made up of
  flip flops which can be set to a one or a zero. The number
  of possible states is 2^N where N is the number of
  megabits of memory. The number of states in a computer
  is essentially infinite for all practical purposes. It is only a
  small fraction of these states that are useful. These are the
  ones that correspond to our programs and data.
A FSM has a limited amount of “memory” in that it can
  respond to the same input in different ways, depending
  upon what node the of the FSM is current. “Context
  dependency” is a key feature of FSM’s. When an FSM
  receives an input (when an event occurs) the FSM may
  change to a different state and generate an output (perform
  some action). “The behavior of a finite state machine can
  be completely described by defining the response (action)
  and the next state (state transition) generated by each input
  (event) in each state.” (Casey, n.d.)
You start constructing an FSM by identifying the significant
  states of a system and the order in which they occur. The
  main tool for building FSM’s is the State Transition
  Diagram. It depicts the relationship between the system
  states and the events that cause the system to change from
  one state to another.
Consider a state diagram for a push on/push off switch. “The
  switch has only one event (push) but two states (on and
  off). What happens when it is pushed depends on the state
  it is in before it is pushed, which in turn depends upon its
  past history. The state diagram accurately predicts the
  system’s response in the context of past history…The FSM
  “knows” how to respond to a given input under various
  circumstances (Gibson, 2000).
What follows is a state transition diagram for a car cassette
 player (Gibson, 2000). This machine must play the tape in
 both directions, fast wind/rewind the tape in both
 directions and automatically reverse the direction at the
 end of the tape. It has two motors, one for movement left
 and one for movement right. The user controls are four
 momentary pushbutton switches: “Play”, “Reverse”,
 “Rewind”, and “Stop”. There is also an end of tape sensor
 switch. There are 6 control states: Slow Left, Slow Right,
 Fast Left, Fast Right, Top Left, and Top Right.
Symbols rather than words were
used in the state bubbles.
Double headed arrows were
used for events that toggle
between two states. The + sign
means that either event leads to
the state transition.
Next, let us consider a state transition diagram for a watering
  and nutrient dosing system for a hydroponic greenhouse.
  Imagine that we want to add a 10 second squirt of nutrient
  once per hour if, on the hour, the nutrient level is low.
  There are two states, state 0 and state 1. State 0 is waiting
  for the 1 hour interval timer to expire. When the timer
  expires we take a decision based on the measured nutrient
  concentration in the hydroponic solution. If the
  concentration is low, the nutrient pump is started (Gibson,
  2000).
We will now look at how you can implement a FSM in a
 programming language. We have an outer Select Case
 (Switch) structure that selects for the event, and for each
 event an inner Select Case structure that selects for current
 state. For each event/state combination there is a code
 segment that performs whatever actions are specified in the
 state-action-decision diagram and then sets the state to a
 new state.
Select Case Event_Type
Case Event1
   Select Case State_Number
   Case 0
        ‘Action for event 1, state 0 goes here
        State = {New state after above action}
   Case 1
        ‘Action for event 1, state 1 goes here
        State = {New state after above action}
   End Select
Case Event2
   Select Case State_Number
   Case 0
        ‘Action for event 2, state 0 goes here
        State = {New state after above action}
   Case 1
        ‘Action for event 2, state 1 goes here
        State = {New state after above action}
   End Select
End Select                                       From Gibson, 2000
One FSM can generate “output” that becomes the “input” to
  the next FSM in line. That is, an FSM can trigger a
  response in a target FSM. You can have the original FSM
  set a variable to a True (non-zero) value, and have the
  target FSM proactively test that memory location. The
  variable is a flag or a semaphore. The initiating FSM
  “sets” the semaphore and the target FSM tests or reads it.
  Usually the target FSM will reset the semaphore (set it
  back to zero) when it has read it, so it will only “process” it
  once.
                                     Gibson, 2000
Suppose we wanted to modify our on/push off FSM so that
  when the light is on it takes 3 pushes of the button to turn it
  off. To do this without creating a lot of extra states we can
  use a memory variable. We can create a memory variable
  and initialize it to 3 during the transition from state 0 to
  state 1. On each push the counter is decremented and
  tested for zero. Depending on the outcome of this test we
  decide whether to turn the light off and revert to state 0, or
  leave it on and go back to state 2.
From Gibson, 2000
The same approach can be used to count other kinds of
  events, such as semaphore inputs from other FSM’s, or
  timeouts of a timer. A timer expiring may lead to a
  semaphore being set for other FSM’s to process. One
  application of this technique is for protective time outs.
  Say an FSM at some point initiates an external event, such
  as turning on a valve. It then looks for a completion signal
  from a limit switch, that has its own FSM. But it also sets
  a 5 second time limit on the completion. If the completion
  signal fails to appear on time, the FSM goes into an alarm
  state and takes some corrective action.
The strategy of having FSM’s communicate with each other
  using semaphores is a powerful one. “Within this kind of
  structure I sometimes think of the FSM’s as tasks. By this
  I mean that each FSM is given the task of looking after
  some aspect of the overall program, such as scanning a
  keypad, operating a beeper when “asked” (sent a
  semaphore), driving a motor between its home position
  and a target point, or whatever. Each task can be written to
  “know” only about its own area of responsibility,
  communicating with other tasks only via semaphores and
  knowing nothing of how other tasks work.”
                                     Gibson, 2000
The most oft-cited problem with finite state machines is the
  exponential explosion of states and transitions as the
  system described becomes more and more complex. One
  way this problem is handled is to extend the FSM notation
  to make it easier to express a given behavior more
  compactly. The previously discussed approach of allowing
  actions to make use of and modify variables which in turn
  can be used in conditions which guard state transitions.
  Only when the guard condition is true can an event trigger
  the corresponding transition. A second way of handling
  this problem is to not try to model all the behavior of the
  system s an FSM. Only use it where FSM’s especially fit
  and use other techniques for other aspects of the system.
                        Petri Nets

Dealing with timing issues is an important aspect of designing
  and specifying computer programs. A graphical technique
  that can handle timing considerations is Petri Nets. Timing
  difficulties that can arise may involve synchronization
  problems, race conditions, and deadlock. Petri nets are a
  powerful technique for both specifying and designing
  systems with potential timing problems. They can handle
  concurrent and interrelated activities.
Petri nets consist of four parts:
• Places
• Transitions
• Input functions
• Output functions

Kimbler (1997) notes that Petri nets are are a collection of
  directed arcs connecting places and transitions. Places
  may hold tokens. The state or marking of a net is its
  assignment of tokens to places. Arcs have capacity of 1 by
  default, otherwise the capacity is marked on the arc. Arcs
  can only connect places to transitions and vice versa.
Transitions are enabled when the number of tokens in each of
  its input places is at least equal to the arc weight going
  from the place to the transition. An enabled transition may
  fire at any time. When fired, the tokens in the input places
  are moved to the output places, according to arc weights
  and place capacities. This results in a new marking of the
  net. From Kimbler (1997)
Unlike a finite state machine diagram, where execution is
  sequential, traversing one state after another, in the Petri
  net mode of operation all places are considered to be
  possible candidates for receiving a token. Those that do
  receive a token fire and execute their associated actions
  (pieces of code).
From Kimbler, 1997
From Kimbler, 1997
From Kimbler, 1997
Petri nets can express state transitions caused by events as
  well as activities that proceed in parallel. Petri nets are
  nondeterministic. If more than one transition is able to
  fire, then any one of them may be fired.

At any given time instance, the distribution of tokens on
   places defines the current state of the modeled system.

Arcs do not represent system components, but symbolize a
  relationship between components. Tokens (black dots)
  represent a piece of information or control that flows
  between the places and through the transactions.
When arcs have different weights Petri nets behave as
 follows. Ready to fire net:




                              From Kimbler, 1997
After the transition fires tokens are taken from the input
  places that enabled the transition. They are distributed to
  output places according to arc weights.




                                  From Kimbler, 1997
There are inhibitor arcs that reverse the usual logic of an input
  place. With inhibitor arcs, the absence of a token in the
  input place enables, not the presence. The transition below
  is inhibited by the token in P2.




                                               From Kimbler, 1997
There are Petri net primitive structures to model many aspects
  of real systems. Sequence is shown below:
In this Petri net version of conflict, the token in P4 enables
   three transitions. When one of them fires, the token is
   removed, leaving the other two disabled. Without
   knowing the timing of the firing we don’t know how this
   net functions.




                                From Kimbler, 1997
Synchronization is shown below. When the processes leading
  into P8, P9, and P10 are finished, all three are
  synchronized by starting P11.




                              From Kimbler, 1997
Confusion is illustrated using a combination of conflict and
  concurrency. P12 enables both T11 and T12, but if T11
  fires, T12 is no longer enabled.




                                  From Kimbler, 1997
Merging simply merges three parallel processes.




                               From Kimbler, 1997
Priority/inhibit uses the inhibit arc to control T19. As long as
   P16 has a token, T19 cannot fire.




                                        From Kimbler, 1997
  Here is an example of a Petri net used to control a vending
    machine. This is its initial state.




The machine stocks five items. When a coin is accepted, an item
can be dispensed. When all items are dispensed, the request refill
place gets a token, and the refill transition replenishes the machine.
                                       From Kimbler, 1997
After the coin is inserted it is either accepted or rejected.
  Rejected coins take us back to the initial marking.
  Accepted coins lead to dispensing.
When T4 fires, a token will be placed in P2, to start another
 dispensing cycle, and a token will be removed from P4 and
 added to P6.




                            From Kimbler, 1997
After the goods in the machine are depleted we get the
  marking below. A coin is ready, but there is nothing left to
  dispense. The inhibitor arc from P4 now enables T6; when
  it fires, T5 will be enabled, and when it fires, goods are
  removed from P6 and placed in P4, ready to start another
  cycle.




                               From Kimbler, 1997
 There are extensions of the Petri net model. Colored tokens
   allow a differentiation of various kinds of data or entities
   through the system.




From Kimbler, 1997
In colored Petri nets, some arcs allow any color token, and
   some allow a specific type. In the previous example, this
   keeps doctors and nurses in their own nets and correctly
   routes patients through. For a transition to be enabled in a
   colored net, its input places must contain tokens consistent
   with the capacity and color of arcs leading into it. When
   fired, the transition deposits tokens in output places
  according to the color and capacity of the outgoing arcs.
Petri nets can also be used to simulate timed processes by
  attaching delays to transitions or to places. Thus, a time
  duration can be associated with transitions.

Petri net places can have code actions that are executed when
  these places receive a token (on-entry actions), or when it
  gives up its token (on exit actions). Also transitions may
  be associated with a coded condition and/or action.

				
DOCUMENT INFO