A FSM model contains all the elements associated with a finite state machine. From the view of these model elements, a FSM model splits up into two different model types, the interface and the state transition diagram of a finite state machine.
The interface of an FSM model differs slightly from a typical MLDesigner model interface, especially from models of the discrete event (DE) domain. It contains the elements of a finite state machine to interact with an outer environment or to represent constants and variables. The following interface elements are available for FSM models:
These elements can be of any type or data structure.
The FSM model design represents the state transition diagram of a finite state machine. It contains all the state objects, like normal states, history states, or default entrance states, and their relations via transition objects. The graphical representation of the state transition diagram is completely embedded into the associated FSM model.
Associated with each FSM model is a special data structure called current state data structure. This data structure is derived from the MLDesigner Root.ENUM data structure and named by default of the FSM model name followed by CS (e.g. SimpleElevatorCS). Each item of this enumeration data structure represents the logical name of a state of the associated state transition diagram. The current state data structure of a FSM model is generated automatically and updated, if the set of states or the logical name of a state has changed.
Each FSM model must contain a memory argument called current state memory. This Memory argument is added automatically to a new FSM model and contains the default name CurrentState. In this context, the current state memory can not be deleted from the FSM model. The type of this memory argument is always set to the associated current state data structure. During execution, the value of the current state memory is always the logical name of the current state. If the scope of this memory argument is external, another block linked to this memory argument can change the finite state machine’s current state.
Changing the value of the current state memory from outside of the FSM block or via an FSM action statement causes no action execution.
The state, specified by the value of the current state memory, becomes the current state. If this state is a hierarchical state, its default entrance destination becomes the current state and so on, until the destination of a default entrance is a leaf state.
The CurrentStateDS property can be used to change the name of the current state data structure associated with every FSM model. In this context, the old current state data structure is removed from the parent library model of the FSM model and a new generated current state data structure based on the new specified name is added to the parent library.
The type of the current state memory is automatically updated to the new current state data structure.
Because the old current state data structure is deleted, any other elements (e.g. ports, memories), using this data structure will lose the reference to the old current state data structure and they are not automatically updated to the new current state data structure.
In addition to the basic properties of MLDesigner models, an FSM model contains a string property called Internal Events. The value of this property is a space separated list of the names of the internal events of the finite state machine. Each time the value of this property changes, every item on the list of internal events is checked to see if it is unique in the scope of the FSM Model and not equal to the name of any interface element.
The Additional Code property is a powerful feature for advanced usage of the MLDesigner FSM model. It provides the facility to define additional ptlang primitive source code in context with a finite state machine. Likewise for MLDesigner primitive models, it is possible to include additional header files or to define global variables and functions. These functions can be called in any action associated with states, transitions or default entrances. Global variables can be read and written in any action and used in expressions of transition guard conditions.
// This code section can be used to define additonal ptlang source code, e.g.
// global methods, variables or additional header includes, used in context with
// State Entry and Exit Actions, Transition Actions and Guard Conditions and
// the Action of the FSM top level Default Entrance.
// NOTE: The methods: constructor, destructor, go, begin, setup and wrapup
// are reserved and cannot be defined in this section !!!
hinclude {}
ccinclude {}
public
{
double mArc;
double mAngle;
}
method
{
name { RadianToDegree }
access { public }
type { "double" }
arglist { "(double pArc)" }
code
{
return 180 / pi() * pArc;
}
}
method
{
name { DegreeToRadian }
access { public }
type { "double" }
arglist { "(double pAngle)" }
code
{
return pi() / 180 * pAngle;
}
}
The variables mArc and mAngle can be written and read in any action and used in transition guard conditions, e.g.
mAngle >= 90
Furthermore, the functions RadianToDegree and DegreeToRadian can be called in any action, e.g.
mAngle = RadianToDegree(mArc);
As described in the comment at the beginning of the additional code example, it is not possible to define reserved methods: constructor, destructor, go, begin, setup and wrapup. Furthermore it is highly recommended to check the additional code section for validity before editing any action or transition guard condition. Parse or compiling errors are often caused by source code from this section.