Finite State Machine
Introduction to FSM
Finite State Machines (FSMs) are used extensively in designing sequential control logic. This set of tutorials show the user how to construct models of circuits, controller, and hierarchical hybrid systems using the graphical FSM editor. These examples also highlight the embedding of the FSM into models containing other blocks using the Digital and Continuous time domains. There are two major reasons behind their use.
In their simple flat form, FSM models have a key weakness; the number of states in an FSM model can get quite large even for a moderately complex system. Such models quickly become chaotic and incomprehensible when one tries to model a system having many concurrent activities. The problem can be solved by introducing hierarchical organization into FSM models and using them in combination with concurrency models.
The VisualSim philosophy of hierarchical composition of heterogeneous models of computation allows embedding hierarchical FSMs within a variety of concurrency models. If the system has a global notion of time and components communicate by time-stamped events, then FSMs can be composed by the discrete-event model.
An FSM model is contained by an instance of FSM Block. The FSM model reacts to inputs to the FSM block by making state transitions. Actions such as sending tokens to the output ports of the FSM block can be associated with state transitions.
The FSM Block contains states and transitions. The State has two ports; IncomingPort, which links to incoming transitions to the state, and OutgoingPort, which links to transitions going out from the state. The Transition links to exactly two ports; the outgoing port of its source state, and the incoming port of its destination state. The two ports of the states are not displayed on the circle.
The guard of a transition is specified by its guardExpression String attribute. Guard expressions are parsed and evaluated using the VisualSim expression language. Guard expressions should evaluate to a boolean value. A transition is enabled if its guard expression evaluates to true. Parameters of the FSM block and input variables (defined below) can be used in guard expressions.
Input variables represent the status and input value for each input port of the FSM block. If the input port is a single port, two variables are used; a status variable named portName_ isPresent, and a value variable named portName. If the input port is a multiport of width n, then 2n variables are used, two for each channel - a status variable named portName_ channelIndex_ isPresent, and a value variable named portName_channelIndex. The status variables has a boolean value true if there is a token at the corresponding input, or false otherwise. The value variables have the same type as the corresponding input and contain the token received from the input, or null if there is no token. All input variables are contained by the FSM block.
A transition can have a set of actions that produce output tokens or set parameters of the FSM block. To make FSM blocks simulator polymorphic, especially for them to be operational in Simulators having fixed-point semantics, two kinds of actions are defined - Choice Actions and Commit Actions.
Two marker interfaces are defined in the FSM kernel package:
A transition has an outputActions attribute and allows the user to specify a list of semicolon separated output actions of the form destination = expression. The expression can use parameters of the FSM block and input variables. The destination is either a port name, in which case the result token from evaluating the expression is broadcast to all channels of the port, or of the form portName( channelIndex), in which case the result token is sent to the specified channel.
Output actions are choice actions.
A transition has a setActions attribute which allows the user to specify a list of semicolon separated commit actions of the form destination = expression. The expression can use parameters of the FSM block and input variables. The destination is a parameter name.
It is worth noting that parameter values are persistent. If not properly initialized, the parameter retains its accumulated value from previous model executions. A useful approach is to build the FSM model such that the initial state has an outgoing transition with guard expression true, and use the set actions of this transition for parameter initialization.
The methods that define the execution of an FSM block are implemented as follows:
Non-deterministic FSMs are currently not allowed . The fire() method checks whether there is more than one enabled transition from the current state. An exception is thrown if there is. In the case when there is no enabled transition, the FSM stays in its current state.
Figure 1: FSM-Hierarchical Illustration
The FSM simulator supports the *charts formalism with modal models. The concept of modal model is illustrated in Figure 1. M is a modal model with two operation modes. The modes are represented by states of an FSM that controls mode switching. Each mode has a refinement that specifies the behavior of the mode. In VisualSim, a FSM-Hierarchical is constructed in a hierarchical block having the FSM Simulator as local Simulator.
The composite block contains a mode controller (an FSM block) and a set of blocks that model the refinements. The FSM Simulator mediates the interaction with the outside simulator, and coordinates the execution of the refinements with the mode controller.
