|
Finite State
Machine logic was used successfully in various aspects of computer
programming and in 1987, David Harel published
Statecharts: A Visual Formalism for Complex Systems. Harel
embellished the Mealy and Moore paradigm with the concept of
hierarchical finite state machines and concurrency/orthogonality.
Although Harel did not specify Statechart implementation, many vendors
used his work as the basis for products offering visual design of FSMs
with auto-code generation for (embedded) software systems. Statecharts
eventually became part of the Unified Modeling Language (UML 2.0), a
step forward in the recognition of the usefulness of Finite State
Machines in general-use software applications. However, most of these
Statechart-based tools presume the FSMs of the resulting application are
to be run within the framework of an enterprise or real-time operating
system (OS/RTOS).
Definition and Operation...
It is common to
distinguish Finite State Machines as either a Mealy or Moore machine.
The difference between the two machines, as we shall explore later, are
noteworthy, but not necessarily paramount to successful Finite State
Machine design for software application architecture, but likely
important in sequential circuit design.
Finite State
Machines (Mealy and Moore) are defined as sharing the following
characteristics:
-
a finite set
of defined states, one of which being defined as the initial
state of the machine
-
a set of
defined inputs
-
a set of
defined outputs
-
a set of
transitions between selected states, and
-
the machine
is said to be in a single state at any instant of time
The basic
operation of a Finite State Machine system is this: as the system is in
one of the defined states at any instant of time, it will react
to specified (external) inputs or (internal) conditions with specified
actions, and transition to another defined state, or remain in its
current state, depending on the design. For a Mealy machine, the
transition will be associated with an output. For a Moore machine, the
output occurs within the next state. For this reason, Finite State
Machines are often called
'reactive' systems. Inputs are also called events. Typical events
may be: a message received from another state machine, a simple event
flag set by another state machine, or the expiration of a time interval.
Likewise, outputs may be: sending a message to another state machine,
setting an event flag for another state machine to respond to, or
starting a timed interval. Also, multiple unique transitions are allowed
from one state to other defined states. For software FSMs, each state
will have its unique source code logic to process events, perform
actions and output, and to effect state transitions. A complete system
may be comprised of one or more Finite State Machines, as determined by
the partitioning process performed during the initial design or
analysis.
Finite State Machines are generally depicted as a State Diagram,
represented graphically with two symbols: the state bubble
and the
transition arrow. States are labeled or numbered and both
inputs and outputs are described textually. At any instant of time, a
state machine is in its current state. Depending on the specified
input events and conditions, a transition to the next state will
occur. Finite State Machines are considered deterministic if all
transitions to next states are unique to a given state and its inputs.
Most useful FSMs are fully deterministic, making them ideal for embedded
systems software and the process of validation and verification. |