# Finite State Machines _FSM's_

Document Sample

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

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.
When T4 fires, a token will be placed in P2, to start another
dispensing cycle, and a token will be removed from P4 and

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
Shared By:
Categories:
Stats:
 views: 3 posted: 8/28/2011 language: English pages: 45