Finite State Machine

Note: Sample code is given in this note to give you a feel of how the simulations could be
implemented using software languages:

A finite-state machine (FSM) or simply a state machine is a mathematical abstraction sometimes

used to design digital logic or computer programs. It is a behaviour model composed of a finite
number of states, transitions between those states, and actions, similar to a flow graph in which one
can inspect the way logic runs when certain conditions are met. It has finite internal memory, an
input feature that reads symbols in a sequence, one at a time without going backward; and an
output feature, which may be in the form of a user interface, once the model is implemented. The
operation of an FSM begins from one of the states (called a start state), goes through transitions
depending on input to different states and can end in any of those available, however only a certain
set of states mark a successful flow of operation (called accept states).

In many programs, there is a need to deal with entities whose handling requires a variety of distinct
behaviours. A straight-forward approach to algorithm design deals with the different kinds of
entities using case statements or extended if-then-else statements. However, if the number of types
of the entities is large then this approach lead to large amounts of code, often with poor run-time
characteristics. A table driven approach uses tables to classify the different kinds of entities, aiming
at a reduction of the number of cases requiring distinct code.

For example, an assembler needs to translate a variety of machine instructions into machine code.
These instructions often have varying numbers of operands and varying operands types. Translating
an instruction involves combining information based on the instruction mnemonic and the operands
into a binary coded instruction. For fixed-length instruction coding, the binary code instruction is
constructed by starting with a base code for the mnemonic and adding operand data using bitwise
or operations.

One obvious use of a table in algorithm design is the for retrieving the base code for an instruction.
However, this use does not involve any classification of instructions. With careful classification,
tables can often be put to more profitable uses.
Classification
The heart of table-driven design is a classification of the kinds of entities that the software needs to
handle. For example, in some simple assembly languages, there are only a few types of instructions
when classified according to the number and types of their operands.

If the programming language supports enumerated types then an enumerated type can be defined
with a value for each type of instruction. Then a table of instruction data can be constructed that
contains operand type information in addition to the base code for each instruction. The operand
type can be used in a case or switch statement to control handling of operands.

For languages, such as C, that allow functions to be treated like other kinds of data, functions for
handling operands can be stored in the instruction table. Each instruction has the particular function
that is needed for dealing with its operands stored in its instruction data entry.

Often, there are different levels of granularity possible in the classification involved in a table-driven
design. For example, in an assembler the machine instructions may be assigned a single classification
based on all of the operands (course granularity), or individual operands can be classified (finer
granularity).

Any finite-state machine can be shown as a graph with a finite set of nodes. The nodes correspond
to the states. There is no other memory implied other than the state shown. The start state is
designated with an arrow directed into the corresponding node, but otherwise unconnected.

An unconnected in-going arc indicates that the node is the start state

The arcs are labelled σ/δ as shown below, where σ is the input symbol and δ is the output symbol or
action to be taken. The state transition is designated by virtue of the arrow going from one node to
another.

Transition from q1 to q2, based on input σ, giving output (action) δ

• A Finite State Machine models behaviour by breaking it down into a small (finite) number of
different states.
• The machine remains in each state for a relatively long period of time.
• State transitions are triggered by a particular series of events (inputs).
• Transitions between states are instantaneous.
• The machine can generate output when a transition occurs. (For the nerds, this form of Finite
State Machine is called a "Mealy" machine)
Example:
Consider a "Missile Attack" game.
• The user controls an interceptor missile (sprite) which is fired to shoot down incoming warheads
(sprites).
• The missile sits on the launch pad until the user clicks the mouse to set a target position.
• The missile flies to the target position and explodes (possibly destroying an incoming warhead).
• If the warhead is destroyed then the score is increased by 10 points.
• If any warhead reaches the ground then it explodes and the game finishes.
• We can model the missile sprite lifetime using this FSM.
• States are updated every 1/60th of a second in Update().

Missile Lifetime FSM

 The FSM for an incoming warhead

Combining FSMs
• We have three Finite State Machines which we need to combine into one working application.
• Each FSM requires its own separate state variable.
• Each FSM is updated within the Update() method every 1/60th second.
• The updates to missile and warhead states only take place when the game State is
GAME_PLAYING.
• The warhead FSM can trigger the game FSM to move to GAME_OVER when the game has
finished.

Uses of the FSM:

• Design of Logic gates
• Design of Software module
• Understand the behaviour of complex RT system
• Design of Communication protocol
• Manage the interactions between entities of RT system

FSMs are powerful because they are a very dense representation. A lot of logic can be represented
by a relatively small diagram. They are powerful because they follow very simple rules, and are easy
to verify. And they are powerful because they can be used to generate code.

We know that the behaviour of a system could be represented at the highest level by a set of finite
states. The dynamics of the system means that the system will be transitioning between states in
response to events, either external or internal events.

Before the system completes the transition to the final states it normally performs some action, and
ends up in the final state. An example of this sort of behaviour is:
• Initial state: lift at 5th floor, Door is open
• Event: You press the call button at the Ground floor
• Action: Door closes, lift descends to Ground floor, Door opens
• Final State: Lift at Ground floor with Door open

EXAMPLE:
Consider a subway turnstile. This simple device is governed by an equally simple FSM. Figure 1
shows part of that FSM. The round rectangles are states. The turnstile has only two states. It can be
locked, or it can be unlocked. When the turnstile is locked, a person can drop a coin into its slot. This
will cause the turnstile to change to the Unlocked state. This is shown in the diagram by the arrow
leading from the Locked state to the Unlocked state. This arrow is called a transition, because it
describes how the FSM.

Abnormal events:

Implementation:
enum State {Locked, Unlocked};
enum Event {Pass, Coin};
void Unlock();
void Lock();
void Thankyou();
void Alarm();

void Transition(Event e)
{
switch(CurrentState)
{
case Locked:
switch(e)
{
 case Coin:
Unlock();
CurrentState = Unlocked;
break;
case Pass:
Alarm();
break;
}
break;
case Unlocked:
switch(e)
{
case Coin:
Thankyou();
break;
case Pass:
CurrentState = Locked;
Lock();
break;
}
break;
}
}

For the full implementation see code provided with this lecture.

Table Driven Control:

Generic control logic could be implemented to achieve the FSM. This is could be found with the code
provide. The idea is that the table contains the following items:
Current State
Expected event
Action to be performed
The Next (final) state.

For the example above, the table is as follows:

TABLECONTROL ControlTable [MAX_LEGAL_TRANSITIONS] =
{
{ Locked, Pass , Alarm , Locked} ,
{ Locked, Coin , Unlock , Unlocked} ,

{ Unlocked, Pass , Lock , Locked} ,

{ Unlocked, Coin , Thankyou , Unlocked}
};

The control logic (algorithm) works as follows:

Search for the CurrentState/Event combination in the table
If found then
Perform the Action
Change the state to the Final state