Specification of Finite State Machines

Specifying Finite State Machines (FSMs) is important in formalizing the design of network protocols and embedded controllers. Traditional FSMs are very close in abstraction to the implementation, and suffer from many disadvantages:

an exponential explosion in the number of states when composing substates,
difficult to modify complex designs since hierarchy is not present,
does not easily handle global control signals such as reset and halt, and
computation occurs in a single path, so there is no support for concurrency.

The goal is to find models of computation that overcome these drawbacks.

Hierarchy is key for managing design complexity and preventing a state space explosion when composing substates. Consider an FSM with two levels of hierarchy with two nodes in each level. A hierarchical FSM would have 2 x 2 = 4 states, whereas a flat FSM would have 2² states. Now, consider an FSM with N levels of hierarchy with two nodes in each level. A hierarchical FSM would have 2 N states, and a flat FSM would have 2^N states.

Models of computation for FSMs may have graphical and textual syntax. Some finite state machines are easier to describe textually and some are easier to describe graphically. Graphical specification languages include Statecharts and Argos, and textual programming languages include Esterel. Statecharts, Argos, and Esterel (which are described below) support hierarchy, concurrency, and various communication models. All three frameworks are used to specify reactive systems (systems that respond to the environment at the speed of the environment). All three are based on the synchrony hypothesis (all communication and computation is instantaneous).

Statecharts

Statecharts is a graphical representation for FSMs that specify reactive systems [1]. Statecharts extends traditional FSMs to include hierarchy, concurrency, and global communication. The fundamental object is state. Transitions between states are determined by a combination of events and conditions. Hierarchical decompositions can be sequential or concurrent. Sequential is the traditional FSM representation and represented by bubble-and-arc diagrams. In a concurrent decomposition, a state is composed of orthogonal substates, in which all of the substates are active whenever the parent state is active. Graphically, concurrent states are separated by dotted lines.

Statecharts has the following advantages over traditional FSMs:

hierarchy prevents an exponential explosion of states when composing substates;
concurrency allows actions to be associated with both transition arcs and states, which are assumed to be zero-delay computations;
communication is broadcast so any update in the Statechart is sensed by the entire Statechart, which makes it is easier to represent global control signals such as reset and halt;
synchronization is supported by initialization, common event, common data, and status detection;
history remembers the state of substates which is used when the substates are reentered; and
non-determinism is supported in that when there are two possible transitions form a state, one of the arcs is taken by a non-deterministic choice.

Statecharts has the following disadvantages over traditional FSMs:

modularity supports multiple dependencies, much as C++ supports multiple inheritance;
all communication is broadcast globally, which severely limits formal analysis and efficient implementations;
history is imposed on the behavior instead of allowing the user to choose whether to initialize a set of substates when they are reentered;
non-determinism is supported which can cause erratic, unpredictable behavior; and
twenty-one variants of Statecharts [2] exist that satisfy the semantics of the original Statecharts paper [1].

Neither Statecharts nor traditional FSMs support dataflow. For examples of Statecharts, see Figures 3.9(c), 3.9(d), 3.10 and 3.15 in [3].

D. Harel, "Statecharts: A visual formalism for complex systems," Science of Computer Programming 8, 1987.
M. von der Beeck, "A Comparison of Statecharts Variants," Proc. Formal Techniques in Real Time and Fault Tolerant Systems, LNCS 863, pp. 128-148, Springer-Verlag, Berlin, 1994.
Daniel Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong, Specification and Design of Embedded Systems, Prentice-Hall, ISBN 0-13-150731-1, 1994.

Argos

Argos is a graphical synchronous language used for specifying reactive systems. The fundamental objects are finite automata that receive and emit signals. Graphical syntax is similar to Statecharts. Argos restricts transitions between states to a single level in the hierarchy, and is therefore more modular. Argos uses local communication to transmit events, and has explicit self-termination constructs to signal behavioral completion. Argos does not model dataflow processes.

Formal Verification

Statecharts, Argos, and Esterel support concurrency. Concurrency presents a fundamental problem in formal verification because it causes an exponential blow-up in the number of possible states. Nonetheless, these languages are not much different to verify than a Verilog description, which is what the Verification Interacting with Synthesis formal verification system handles. (contributed by Stephen Edwards)

In principle, formalisms for FSMs are syntactic sugar on the theme of interacting FSMs, and the computational complexity of basic verification problems is PSPACE-hard. In practice, these are used to describe very different kinds of systems, and as a result, differing heuristics need to be applied to overcome the complexity of verification. (contributed by Adnan Aziz)

Updated 04/20/99.