Imprint Privacy policy Terms & Conditions Sitemap

Reactions

Reactions are one of the most important features of the itemis CREATE language. Basically everything that happens in a statechart happens in a reaction.

Reactions can be attached to states as well as to transitions. While states can have as many reactions as you wish, transitions can only have one.

The syntax follows the standards of automata theory, where the output is put into relation to the input of the automaton using the following notation (especially Mealy automata):

input / output

itemis CREATE uses the following syntax for all reactions:

trigger [ guard ] / effect

The possible values that can be specified as a trigger depend on the context, which is either a state or a transition.

All three components are grammatically optional, though a reaction with neither a trigger nor a guard will never happen. Reactions with no effect are useful for transitions, the slash / can be omitted as well then.

Trigger specifications

Reactions can define a trigger that needs to occur to activate the reaction. Events are possible triggers, as well as certain keywords defined in the statechart language.

Triggers can be combined with guards to further define the execution conditions of the reaction. In that case, the reaction is only executed if both the trigger occurs and the guard condition is true.

You can define multiple triggers for a reaction, separated by comma: trigger1, trigger2. For the combined trigger to fire, it is sufficient that one of the individual triggers occurs.

There are a couple of special triggers defined by the statechart language:

Examples:

  • A reaction shall occur if an event named ev1 happens: ev1 / effect
  • A reaction shall occur if ev1 or ev2 happen: ev1, ev2 / effect
  • A reaction shall occur if ev1 happened or three seconds passed: ev1, after 3s / effect

Figure "Event specifications syntax overview" shows where to put event specifications in a reaction trigger and how their syntax is defined.


Event specifications syntax overview

Event specifications syntax overview

Reaction trigger "after"

The after trigger specifies a one-shot time event.

After the specified period of time the reaction is triggered. An after trigger can be used in transitions of states as well as in local reactions of states and statecharts. The specified period of time starts when the state or statechart is entered. 

after 20 s

Synopsis: after time unit

The time value is a integer literal or an expression with an integer value.

The time unit is one of:

  • s: seconds
  • ms: milliseconds
  • us: microseconds
  • ns: nanoseconds

Reaction trigger "every"

The every trigger specifies periodic time events.

The reaction is triggered recurrently after each passing of the specified period of time. An every trigger can be used in transitions as well as in local reactions of states and statecharts. The specified period of time starts when the state or statechart is entered and repeats periodically. 

every 200 ms

Synopsis: every time unit

The time value is a integer literal or an expression with an integer value.

The time unit is one of:

  • s: seconds
  • ms: milliseconds
  • us: microseconds
  • ns: nanoseconds

Reaction trigger "always"

The always trigger is always true and enables a reaction to be executed in every run-to-completion step (RTC). This trigger is equivalent to the oncycle trigger.

Reaction trigger "oncycle"

The oncycle trigger is always true and enables a reaction to be executed in every run-to-completion step (RTC). This trigger is equivalent to the always trigger.

Reaction trigger "else"

The else trigger is intended to be used for the outgoing transitions of choice pseudo states to make sure that there is always an outgoing transition that can be taken. It can only be be used in transitions and implies the lowest evaluation priority for that transition. The default trigger is equivalent to the else trigger.

Reaction trigger "default"

The default trigger is intended to be used for the outgoing transitions of choice pseudo states to make sure that there is always an outgoing transition that can be taken. It can only be be used in transitions and implies the lowest evaluation priority for that transition. The default trigger is equivalent to the else trigger.

Reaction trigger "entry"

An entry trigger marks actions that are carried out when entering a state or state machine, immediately before making it active.

Please note: A self-transition, leading from a state back to itself, actually first leaves and then re-enters the state. That means that its exit effects as well as its entry effects are executed. This is in contrast to a local reaction, which is executed without leaving the active state. Thus exit and entry effects are not executed in the latter case.

Reaction trigger "exit"

An exit trigger marks actions that are carried out when exiting a state or state machine, immediately after making it inactive.

Please note: A self-transition, leading from a state back to itself, actually first leaves and then re-enters the state. That means that its exit effects as well as its entry effects are executed. This is in contrast to a local reaction, which is executed without leaving the active state. Thus exit and entry effects are not executed in the latter case.

Guard conditions

A guard condition, or simply guard, is another option that can be used to specify when a reaction should be executed. Guard conditions can be used on their own or in conjunction with a specified trigger . In the latter case, the trigger needs to be fired and the guard needs to be true for the reaction to fire its effect.

As a reminder, the complete reaction syntax is as follows:

trigger [ guard ] / effect

In the square brackets you can use any expression that evaluates to a boolean. Boolean variables, all kinds of comparisons, and operations returning a boolean fall into this category. Furthermore, events are also treated as booleans which are true when the event is active. This allows to check for the simultaneous occurrence of multiple events by concatenating them with ‘&&’.

Please note: itemis CREATE does not support the concept of “truthy and falsey” seen in C, Javascript or Python. [x] is not a valid guard condition, unless the type of x is boolean.

Please consult figure "Guard condition syntax overview" to find out how a guard condition syntactically fits into a reaction.


Guard condition syntax overview

Guard condition syntax overview

Actions and reaction effects

A transition specification may contain zero, one or more actions that are executed when the transition is taken. An action could be something like assigning a value to a variable, calling an operation, or raising an event. All actions taken together are called the transition’s reaction effect, or simply effect. The complete syntax for reactions is as follows:

trigger [ guard ] / effect

This means that the effect will only be executed if the trigger fires or does not exist and the guard condition evaluates to true or does not exist and at least a trigger or a guard exist. See the sections about triggers and guard conditions.

Normally, actions are statements. Note that you can also use the conditional expression to make some constructs more elegant.

If an effect shall consist of multiple actions, they must be separated by a semicolon. That means the last action is not followed by a semicolon. The syntax is:

trigger [ guard ] / action1 ; action2 ; action3 ;

A reaction in a state always has a reaction effect with at least one action.

Figure "Reaction effect syntax" shows the syntax definition.


Reaction effect syntax

Reaction effect syntax

Example: When a transition or local reaction specified as ev1 [x > 3] / x += 1; notify(x); raise ev2 is executed, it increments variable x by 1, calls the notify operation with x as parameter, and raises event ev2.

Raising and processing an event

For the syntax of event raising, see section "Raising an event".
For the syntax of event declaration, see section "Events".

There are different variants of event processing semantics. These can be defined individually for each statechart by using different annotations:

  • Event-driven statecharts process one event after each other according to the order in which the events were raised.
  • Cycle-based statecharts process all events which were raised between two run to completion steps in a single step.
  • Event buffering has an impact on the event processing life cycle.

Raising and processing events in 3.x releases is relevant for users of pre 4 releases.

Definition section Types