Transitions

Guard

You can use any valid C-Code in guards as long as it produces a truth value. Make sure to reference instance attributes by prepending me-> in front of them. Additionally, you can use the keyword else, which you can omit if you want to, for specifying a guard which always evaluates to true and is checked only after all the guards from the competing transitions evaluate to false. For example, the following state machines produce equivalent code:

Without else

With else

Trigger

Embedded Engineer supports signal and time triggers. Active transitions of nested states are checked in the order necessary to comply with the UML specification. As soon as a transition fires, no other active transition can fire in that cycle anymore. The order is:

1. Triggered transitions (transitions with at least one trigger) from the state itself
2. Triggered transitions from the owner states, starting with the innermost owner state
3. Untriggered transitions (transitions without a trigger) from the state itself
4. Only for final states, untriggered transitions of the direct owner (if it exists)

For example for the state Level3, this is the order in which the transitions are checked, starting from 1:

And for the final state:

Signal Triggers

To use signal triggers, make sure that every signal trigger in your model also has a signal specification. If the signal specification is missing, Embedded Engineer will produce an error when generating code for the signals. It's easiest to specify the signal right when setting the trigger for the transition:

In order to use the signals, please use the option Generate Signals on the package you want to generate code for. For more information see Signals Enumeration. Please keep in mind that the name of the signal is used as an identifier in the generated code, so it has to conform to the identifier rules of your target language.

Time Triggers

You can use time-triggers in your state machines. To make modeling easier, you can use the following units in the signal specification:

Unit in Model	Name in checkTimeEvent	Default Meaning
{empty}	TIME_TICKS	Milliseconds
ns	TIME_NANOSECONDS	Nanoseconds
us	TIME_MICROSECONDS	Microseconds
ms	TIME_MILLISECONDS	Milliseconds
s, sec, "	TIME_SECONDS	Seconds
m, min, '	TIME_MINUTES	Minutes
h, hr	TIME_HOURS	Hours

You can define the conversion and handling of time by modifying the supplied checkTimeEvent function, defined in FSM. If you don't specify a unit, the value will be handled as TIME_TICKS, meaning that no conversion between the value and your system time takes place. For the actual value, you can use any expression as long as it's valid C and the result is an integer, so a waiting time of me->currentWaitingTime * 2 + 10 sec is valid, while twenty seconds is not.

Effect

The effect of a Transition specifies an optional Behavior to be performed when the Transition fires.

A Transition may contain either User Code, an Activity or Operation. To specify the behavior select the Transition:

Enterprise Architect

Go to the Constraints tab in the Connector Properties tab

• Enter your code directly into the Effect field

  

• Check the Effect is a Behavior checkbox and select an Activity or Operation

  

Magic Draw

• Open the Specification dialog for the Transtion and scroll down to the Effect grouping

• There you can select a Behavior Type:

  

• After selection of the Behavior Type either an Activity, OpaqueBehavior or an FunctionBehavior will be added to the Transition and can be filled with User Code or with a modeled Activity

  

Currently we support:

1. Activity
2. FunctionBehavior
3. OpaqueBehavior

See also

Execution Sequence