It is possible to assign different transition priorities to every transition in a DCharts model. Unlike the common approach of allowing for arbitrary priority numbers for transitions (which is not modular), DCharts support another scheme based on inner-first and outer-first transition ordering. The meaning of several related keywords is explained below:
Note: A transition is in the scope of a state iff the source state of the transition is that state or a substate of that state.
Note: In case of a conflict caused at run-time (i.e., two or more transitions are able to handle a single event and compete for it), the transition of the highest overall priority (or one of those transitions of the highest overall priority) is fired, while the other transitions are simply ignored.
Note that transitions in the scope of state B are also in the scope of state A. The transition ordering of state A is considered before the ordering of state B, while the ordering of state B overrides the ordering of state A within the scope of B.
If none of the above properties is assigned to a state (the default case), the state inherits the transition ordering of its parent if any, or follows the true or false setting of the InnerTransitionFirst global option if it is a top-level state.
The ITF and OTF scheme solves most of the run-time conflicts, but not all those conflicts. For example, the conflict between two transitions with the same source state cannot be solved in this way. To solve this conflict, the designer is allowed to assign priority numbers (integers that can be negative) to the two transitions. For transitions ordered in the same place with the ITF and OTF scheme, smaller priority number always means higher overall priority. Priority numbers are not considered for conflicts that can be solved with the ITF and OTF scheme. By default, each transition has a priority number of 0.
If conflicts still exist at run-time, for example, two transitions with the same source state and the same priority number, the transition that is actually triggered is implementation-dependent. Designers should always avoid this circumstance.