2.2.5 Transition Priorities

Transition Priorities are an extension of concepts found in STATEMATE statecharts, UML statecharts and DEVS (the select function). They are used to solve run-time conflicts between multiple transitions enabled by the same event at a given time. This case would make the model non-deterministic. [26]

Two possible kinds of transition conflicts are described in [5].

1. At least two transitions are enabled by the same event, the source state of one of the transitions is a substate (or superstate) of the source state of the other transition(s).

2. At least two transitions are enabled by the same event, they have the same source state.

(Note that if those transitions have source states in different orthogonal components, no conflict occurs and all those transitions are triggered by the same event. In that case, the order of the firing of those transitions is random or implementation-dependent.)

Solutions to the first kind of conflicts are found in both the STATEMATE semantics [5] and the UML [27]. Unfortunately, the solutions from the two sources are opposite: in UML, if the source state of a transition is a substate of the source state of the others, it gets higher priority; however, in the STATEMATE semantics, it gets lower priority.

In DCharts, it is possible to customize the priority of transitions by setting the $TP$ attribute of states (1st-round decision) and the $Prio$ attribute of transitions (2nd-round decision). The semantics of the different values of $TP$ is formalized below (function $Priority(t)$ is the total priority number of transition $t$; $t_1$ and $t_2$ are transitions; $SRC_1$ is the $SRC$ of $t_1$; $SRC_2$ is the $SRC$ of $t_2$):

• $TP_{SRC_1}==ITF \wedge SRC_2\in Substate(SRC_1) \Rightarrow Priority(t_1)>Priority(t_2)$

  If $SRC_1$ is set to be inner-transition-first (ITF), and $SRC_2$ is a substate of $SRC_1$, then the total priority of $t_1$ is lower than that of $t_2$, or the total priority number of $t_1$ is larger than that of $t_2$.

• $TP_{SRC_1}==OTF \wedge SRC_2\in Substate(SRC_1) \Rightarrow Priority(t_1)<Priority(t_2)$

  If $SRC_1$ is set to be outer-transition-first (OTF), and $SRC_2$ is a substate of $SRC_1$, then the total priority of $t_1$ is higher than that of $t_2$, or the total priority number of $t_1$ is smaller than that of $t_2$.

• If $TP_{SRC_1}==Keep$, $SRC_1$ preserves the $TP$ setting of its parent. This means, if its parent is inner-transition-first, $SRC_1$ is inner-transition-first, too. And vice versa.

• If $TP_{SRC_1}==RTO$, $SRC_1$ reverses the $TP$ setting of its parent. This means, if its parent is ITF, $SRC_1$ is OTF. And vice versa. In the case where $s_2\in C(s_1) \wedge TP_{s_1}==RTO \wedge TP_{s_2}==KEEP$, $s_2$ preserves the transition order of $s_1$ rather than the reverse-transition-order (RTO) property itself. Similarly, if $TP_{s_1}==RTO \wedge TP_{s_2}==RTO$, $s_2$ reverts the actual transition order of $s_1$ rather than the reverse-transition-order (RTO) property itself.

Figure 2.3: An example of transition priorities

Suppose there are three transitions t1, t2 and t3 as illustrated in Figure 2.3. When event e occurs, they are all enabled, so there is a conflict of the first kind. To understand the priority of these transitions, one must first consider the outermost state and step inward from there. Because S1 is specified to be $ITF$, the priority of t1 must be lower than both t2 and t3. Since S2 is $OTF$, t2 has a higher priority than t3. So the ordering by priority is t2, t3, t1. Detailed explanation of the graphical representation of DCharts models is in section 4.1.

The above scheme cannot solve the second type of conflicts. In case of such a conflict, the transition with the smallest $Prio$ number is fired. It is the designer's responsibility to ensure that this situation does not occur, or even if it occurs, there is a unique decision among the conflicting transitions according to their $Prio$ numbers. If the choice is not unique (more than one transition has the smallest $Prio$ number), the transition that is fired is random or implementation-dependent.