In MLDesigner, a finite state machine is always combined with other MLDesigner models, since an FSM model is always embedded into a wormhole of a concurrency domain or different MLDesigner models can be used as a slave process inside a FSM model.
This section describes, how FSM models interact with the Discrete Event (DE) domain, the Synchronous Data Flow (SDF) domain and the Finite State Machine (FSM) domain.
The MLDesigner DE domain uses an event driven model of computation. Events occur at a point in time. A timestamp, possessed by every event, indicates the time, at which the associated event occurs.
An FSM model, embedded in a DE domain environment, behaves like any other DE model. New data on an FSM model input port represent the presence of a new event to trigger the FSM model and new data on an FSM model output port, generated during FSM execution, are interpreted as new events for the DE environment, that is, the FSM model reacts to the outer DE domain as a zero delayed system.
In this context, output events, generated by the FSM model, get the same timestamp as the input event, which triggered the execution of the FSM model. A DE outer domain is the only case where an FSM model is able to use special event arguments to cause state changes inside the finite state machine, because all other domains do not support special events.
In case of an outer DE environment, the usage of the logical AND (&&) operator within transition event expressions is only practical for internal events in connection with FSM slave models. Event expressions of AND-combined FSM input ports or special events are only evaluating to true in the special case, the involved events are all present at the same time in the outer DE event queue and scheduled for the same timestamp. But basically, FSM models inside DE react immediately on an incoming port event or dispatched special event. In doing so, all present events are consumed during FSM execution, independent if a transition has been able to fire on these events or not. In other words, FSM models do not queue events and are not waiting for missing events to satisfy event expressions including AND-combined input ports or special events. Therefore event expressions of non-synchronous transitions should only consist of a single event name, if the associated FSM model is embedded in a DE environment.
If a DE domain module is used as a slave process inside an FSM model, the supply of the input ports of the slave process, before execution, depends on the outer domain of the FSM model.
In case, the outer domain is also a DE domain and there is currently no event on an input port of the FSM model, the appropriate input port of the DE slave process model gets also no event.
In all other cases, each input port of the slave process gets a new event, before the slave process executes. All the input events of the slave process get the current timestamp of the superordinate FSM model.
If the outer domain of the FSM model is also a DE domain, the current timestamp of the FSM model is the same as the timestamp of the FSM model triggering event. Otherwise, the timestamp of the FSM model is zero. Output events, produced by the DE slave process model, are placed on the appropriate FSM model output ports. Again with the current, zero delayed timestamp of the FSM model.
An SDF system consists of a set of modules or primitives interconnected by directed arcs. MLDesigner SDF models represent computational functions that map input data into output data. Unlike the DE domain, the SDF domain is not event driven and there exists always data on each input and output port of the SDF model.
An FSM model, embedded into an SDF domain environment, behaves like any other SDF model. To ensure this behavior, the FSM model needs an approach to differ between the presence and absence of an event, since there exists always data on each input port of the FSM model.
In this context, the FSM model determines the presence and absence of an event via the integer cast of the appropriate input data. If this data cast returns zero, the associated event is interpreted absent and in the case of a non zero result, the associated event is interpreted present.
If the FSM model execution produces no data for an associated output port, a zero valued data is placed on this output, to ensure that there is always data available on each FSM output port, as required by the semantic of the outer SDF domain.
If an SDF domain module is used as a slave process inside an FSM model, each input port of the slave process model gets the same data as currently available on the appropriate FSM model input port, before the slave process executes.
Each execution of an SDF domain slave process model is interpreted as one iteration. The output data, produced by the slave process, are placed on the appropriate output ports of the superordinate FSM model.
If an FSM model is used as a slave process inside another FSM model, each input port of the slave FSM model gets the same data as currently available on the appropriate input port of the master FSM model, before the slave process executes.
In the case, the master FSM model is embedded into a DE domain environment and there is currently no event on an input port, the appropriate input port of the slave FSM model gets a zero valued data, to specify the absence of the associated event.
Likewise an FSM model is embedded into an SDF domain environment, the slave FSM model determines the presence and absence of an event via the integer cast of the associated input data. Output data, produced by the slave FSM model, is placed on the appropriate output ports of the master FSM model.