The FSM mechanism provided by MLDesigner supports all the basic standard elements of a finite state machine.
Events are used as triggers to cause a finite state machine to undergo state changes. In doing so, the presence of an event is interpreted as logical true and the absence of an event as logical false. The MLDesigner FSM supports 3 different kinds of events:
The basic events are represented by data parsed into an input port of the FSM model interface.
If a FSM model is embedded into a discrete event (DE) environment, MLDesigner Special Event arguments can be used to trigger the FSM model.
In context with the FSM state slave process mechanism, internal events can be set or reset inside an FSM model, without influence of the outer environment of the finite state machine. These internal events are represented by a boolean flag associated with the name of the event. If a state slave model contains an input port with the name of an internal event, this input port gets the current flag value (true or false) of the associated internal event, before the slave model executes. If a state slave model contains an output port with the name of an internal event and this output port contains new data after execution of the slave model, the associated internal event flag is set to the integer cast (unequal zero = true, equal zero = false) of the new data. If the output port, associated with an internal event, contains no new data after execution of the slave model, the internal event flag is reset to false.
States represent conditions or periods characterized by the concepts of duration and stability. A finite state machine can have an arbitrary number of states but at any time of execution, the FSM must reside in only one state.
In the scope of a single FSM, each state of this FSM must have a unique name. This name is centered at the top of the rounded rectangle in the graphical notation of a state.
Each state can have an arbitrary number of substates and the substates can also be hierarchical. All states on the same level of a hierarchy are sibling states. States up the hierarchy are called ancestor states and states down the hierarchy are called descendant states. Leaf states are states without substates. In the graphical representation of hierarchical states, the borders of a substate must reside completely inside the boundaries of all ancestor states.
At any time during simulation, a finite state machine must reside in only one state. This state is called the current state. If the current state is a hierarchical state, then only one of its substates must be the current substate. This rule goes down the hierarchy until a leaf state is the current substate of a level of the hierarchy.
Together with each state, it is possible to define two sets of operations. The entry action is executed whenever the state is entered and the exit action is a set of operations performed whenever the state is exited. These actions are defined using the C/C++ like FSM action language.
The MLDesigner FSM provides a slave process associated with leaf states. An MLDesigner module or a different FSM model can be used as a slave process. The slave process of the current state executes if the FSM receives new events and no preemptive transition, possessed by the current state, fires.
The following conventions must be met.
State changes in finite state machines are described via transitions. Each transition specifies a source state and a target state. The graphical notation is a line or multiple line segments between the source and target state with an arrow on one end, pointing to the target state.
If the source and target state of a transition is the same state, the transition is called a self transition.
Each state possesses all transitions for which it is the transition’s source state as well as those possessed by its ancestor states. Latter transitions are called inherited transitions.
Associated with each transition is a boolean property called preemptive. All the preemptive transitions, possessed by the current state, are checked for firing, before the slave process of the current state is performed. In that way, the slave process executes only, if no preemptive transition fires.
In context with the FSM state slave process mechanism, every transition contains a property called Entry Type. If a transition fires, the entry type of this transition specifies in which way the slave process of the next current state will be executed. The entry type can be either Default or History. For example, a leaf state containing another FSM model as slave process. If this state is entered via a Default entry type transition, the slave process FSM model will always be reset to its initial state, before execution. In the case, this state is entered via a History entry type transition, the slave process FSM model continues the execution in the last current state.
Each transition can have an event expression E described by the grammar:
Events = {Input Ports, Special Events, Internal Events}
In doing so, complex and nested event expressions can be defined using brackets and the C/C++ logical operators ! (NOT), || (OR) and && (AND). For instance, an event expression consisting of two events, combined by a logical AND (Event1 && Event2), only evaluates to true when both events are present. If instead two events are combined by a logical OR (Event1 || Event2), just one of them needs to be present for satisfaction.
The applicability of the different logical operators within transition event expressions depends on the outer domain of the associated FSM model. See FSM inside DE for details.
MLDesigner provides a special Event Expression Dialog for easy event expression composition.
If the event expression evaluates to true, while the current state is a transition’s source state or one of its substates, the transition is triggered and becomes a candidate for firing. A transition without an event expression 
is immediately triggered after its source state entry action is executed. These transitions are called synchronous transitions.
Optionally associated with each transition is a guard condition C, specified by an FSM Action expression. If the guard condition of a triggered transition evaluates to true, the transition fires and the finite state machine’s next state becomes the transition’s target state. A triggered transition without a guard condition fires immediately.
Triggering does not automatically cause transitions to fire, it merely enables firing. If a triggered transition cannot fire, because the guard condition evaluates to false, the transition must be triggered again by a satisfied event expression to become a candidate for firing.
Each transition can also have an action A, which is a set of FSM Action statements. Whenever a transition fires, its action is performed before the transtion’s target state entry action is executed.
Unlike states, transitions have no unique name. They are specified by an automatically generated label. The syntax of the label is: E [C] / A. The label is also visible in the transition properties window.
If more than one transition possessed by the current state is triggered, the inherited transitions up the hierarchy have a higher priority to fire.
A transition conflict occurs, when two or more transitions with the same priority are triggered and no transition with a higher priority is candidate for firing. In this case of nondeterminism, the FSM scheduler fires the first one, which guard condition evaluates to true.
The Default entrance is a special state which indicates the point of entry to that level of the state hierarchy. Each level of the state hierarchy, including the FSM top level, has one default entrance, which is depicted by a small solid circle. A default entrance must not have any incoming transitions and must have only one outgoing transition to designate the default substate destination. The top level default entrance designates the initial state of the finite state machine.
Each default entrance may be linked to a set of FSM action statements that initialize a state hierarchy level (e.g., schedule an event, initialize memories, etc.). Whenever a state hierarchy is entered by its default substate (e.g., when a transition target state is a hierarchical state), the default entrance action is performed before the entry action of the default substate. Upon simulation startup, the action of the top level default entrance and the entry action of the FSM initial state are performed. While the initial state is a hierarchical state, its default entrance action is executed and its default substate becomes the initial state, including execution of the state entry action.
Histories are special states, used to resume the last substate of a hierarchical state. An FSM can have an arbitrary number of histories, placed at any level of the state hierarchy. The graphical notation is a circle containing either an H for static or H* for recursive histories.
A history must have at least one incoming transition and must not have any outgoing transitions.
A static history memorizes only the previous substate of its hierarchy level. If this substate is a hierarchical state, then its default entrance destination becomes the current sub-substate and so on, until a leaf state becomes the current state.
Recursive histories apply to all descendant states and refer to the previous current state of their state hierarchy. So the state, memorized by a recursive history, is always a leaf state on the same or lower level of the state hierarchy.
If a transition, pointing to a history fires, actions are performed as if the transition is pointing to the state stored in the history. Trying to enter a hierarchical state via an empty history, when the hierarchical state was never visited before, results in an error being displayed and the simulation aborts.
In addition to the basic elements, the MLDesigner FSM semantic supports typical MLDesigner arguments associated with finite state machines.
Memories can be used to represent variables in a finite state machine. The MLDesigner FSM supports memories of both scopes: internal and external, and all types and data structures as is the case elsewhere in an MLDesigner block. FSM action statements have read as well as write access to the value of a memory argument.
In addition to events, represented by the inputs of a finite state machine, the MLDesigner FSM supports special event arguments of both scopes, internal and external, and of all types and data structures. These events can also be used in the event expression of transitions and can be accessed via FSM action statements to schedule or cancel an event argument. Events of external scope can generate events in other MLDesigner models, that is, other FSM models.
Using MLDesigner special event arguments in context with finite state machines makes sense only if the FSM model is embedded into a discrete event (DE) environment.
Like memories and special events, parameters are fully supported in MLDesigner finite state machines. FSM action statements have only read access to the value of a parameter.