Hierarchical State Machines (HSM) in AnyLogic 6
One of the key mechanisms used to bring these different paradigms
together is the Hierarchical State Machines (HSM). Based on the UML-RT
specification, the HSMs provide a powerful capability to each of the modeling
paradigm supported. The HSM or simply statecharts can be used to define:
The following
figure shows an example of a statechart model for a watch:
Statecharts Modeling with Anylogic 6
While using events is quite
clear, sometimes you may need to define some more sophisticated behavior that
cannot be defined using events and dynamic events. This can be done using
statecharts. Statechart is the
most advanced construct to describe event- and time-driven behavior. For some
objects, this event- and time-ordering of operations is so pervasive that you
can best characterize the behavior of such objects in terms of a state
transition diagram – a statechart.
Statechart has states and
transitions. Transitions may be triggered by user-defined conditions (timeouts
or rates, messages received by the statechart, and Boolean conditions).
Transition execution may lead to a state change where a new set of transitions
becomes active. States in the statechart may be hierarchical, i.e. contain other
states and transitions. The actual structure of state diagram is stored in the
active object.
Statechart is used to show
the state space of a given algorithm, the events that cause a transition from
one state to another, and the actions that result from state change.
By using statecharts you can
visually capture a wide variety of discrete behaviors, much more rich than just
idle/busy, open/closed, or up/down status offered by most block-based tools.
Statechart Elements
The behavior of a statechart
is defined in a graphical editor using the following statechart constructs:
 Statechart entry point
 State
 Transition
 Initial state pointer
 Final state
 Branch
 History state
Statechart elements are
added on the diagram from the Model stencil of the Palette view.
Statechart
elements
State
State
represents a location of control with a particular set of reactions to
conditions and/or events. A state can be either simple or, if it contains other
states, composite. Control always resides in one of simple states, but the
current set of reactions is a union of those of the current simple state and of
all composite states containing it – i.e., a transition exiting any of these
states may be taken.
States
 To
draw a state
1.
Choose the State
element from
the Model page of the Palette view.
2.
Click or drag in
the graphical editor where you want to place the state.
A state has the following
properties:
Properties
Fill
Color – the
control sets the fill color for the state. Choose any color you like, or leave
the Default one.
Entry
Action –
sequence of Java statements to be executed when the statechart enters the state.
Exit
Action –
sequence of Java statements to be executed when the statechart exits the
state.
Statechart Entry Point
Statechart entry point
is used to indicate the initial state of the statechart. There should be
exactly one statechart entry point defined for each statechart.
You may define several
independent statecharts for the same active object, each one describing some
particular process. In this case AnyLogic will distinguish how many are there
distinct statecharts by analyzing the number of statechart entry points.
To
draw a statechart entry point
1.
Choose the Entry
Point
element from
the Model page of the Palette view.
2.
In the graphical
editor, click the starting point of the statechart entry pointer.
3.
Click the points
where the statechart entry pointer should turn.
4.
Click the ending
point of the statechart entry pointer (a state or a pseudo state).
A
statechart entry point has the following property:
Properties
Action – sequence of Java statements executed when the statechart entry
point forwards the control to an initial state.
The
generic transition editing operations can be applied to statechart entry
points.
Initial
State
Pointer
Initial state pointer
points to the initial state within a particular level of state hierarchy.
If the control is passed to
a composite state, a simple state is found inside it by following the initial
state pointers down the state hierarchy, and this state becomes current. There
should be exactly one initial state on each level – i.e., on the upper level
and in each composite state.
To
draw an initial state pointer
1.
Choose the Initial
State Pointer
element from
the Model page of the Palette view.
2.
Click the
starting point of the initial state pointer.
3.
Click the points
where the initial state pointer should turn.
4.
Click the ending
point of the initial state pointer (the border of a state or pseudo state).
The
generic transition editing operations can be applied to initial state pointers.
Properties
Action – sequence of Java statements executed when the initial state pointer
forwards the control to an initial state.
Transition
A transition
denotes a switch from one state to another. A transition indicates that if the
specified trigger event occurs and the specified guard condition is true, the
statechart switches from one state to another and performs the specified action.
When this occurs, we say that the transition is taken.
The starting point of a
transition lies on the border of the transition’s source state. The end point
of a transition lies on the border of the transition’s destination state. A
transition may freely cross simple state and composite state borders. If the
source of a transition lies either on or inside a state, and the destination of
that transition lies outside of the state, then that state is considered exited
by the transition. If such a transition is taken, the exit action of the exited
state is executed. If the source of a transition lies outside a state, and the
destination of that transition lies either on or inside the state, then that
state is considered entered by the transition. If such a transition is taken,
the entry action of the entered state is executed. In case a part of a
transition lies inside a state, but both source and destination are outside the
state, this state is considered neither entered nor exited.
There is a special type of
transition called internal transition. An internal transition lies inside a
state, and both start and end points of the transition lie on the border of this
state. Since an internal transition does not exit the enclosing state, neither
exit nor entry actions are executed when the transition is taken. Moreover, the
current simple state within the state is not exited too. Therefore, the internal
transition is very useful for implementing simple background jobs, which should
not interrupt the main activity of the composite state.
Transitions
To
draw a transition
1.
Choose the Transition
element from
the Model page of the Palette view.
2.
Click the
starting point of the transition (the border of a state or pseudo state).
3.
Click the points
where the transition should turn.
4.
Click the ending
point of the transition (a state or pseudo state).
Properties
Guard
– boolean
expression that allows (if true)
or prohibits (if false)
the transition. If not specified, true
is assumed.
Action –
sequence of Java statements executed when the transition is taken.
Pseudo States
A pseudo
state is a special type of a node on a statechart diagram. Control
never stays in a pseudo state; it always passes through. Therefore, triggers
cannot be specified for transitions exiting pseudo states. When control passes a
pseudo state, pseudo state’s action is executed.
There are
four types of pseudo states:
·
Final state
·
Branch
·
Shallow history
state
·
Deep history
state
They all have the following
set of properties:
Properties
Name – name of the pseudo state.
Action – sequence of Java statements executed when the control passes the
pseudo state.
Final
State
A final state is a
termination point of a statechart. When control enters a final state, its action
is executed, and the statechart terminates. Transitions may not exit a final
state.
To
draw a final state
1.
Choose the
Final
State
element from
the Model page of the Palette view.
2.
Click or drag in
the graphical editor where you want to place the final state.
Final states
A final state has the
following properties:
Properties
Action
– sequence of Java statements to be executed when the statechart enters the
state.
Branch
A branch represents a
transition branching and/or connection point. Using branches you can create a
transition that has more than one destination state, as well as several
transitions that merge together to perform a common action.
When control passes a
branch, its action is executed, and then the guards of transitions exiting the
branch are evaluated. The first enabled transition – i.e., the transition
whose guard evaluates to true – is taken.
To
draw a branch state
1.
Choose the Branch
element from
the Model page of the Palette view.
2.
Click or drag in
the graphical editor where you want to place the branch state.
Branches
A branch may have at most
one special outgoing transition marked default branch exit. This transition is
taken in case all other outgoing transitions are closed.
Transitions exiting branch
states have the following properties, slightly different from other transitions
properties.
Properties
Fire – the trigger type.
If
guard is open –
the transition is triggered if the specified guard is open.
If all other guards are closed – the transition is the default branch
exit.
Guard – [for transitions triggered If guard is open only] boolean
expression that allows (if true)
or prohibits (if false)
the transition. If not specified, true
is assumed.
Action – sequence of Java statements executed when the transition is taken.
If all outgoing transitions
are closed and there is no default exit from a branch, a runtime error is
issued.
History
State
A composite state may
contain shallow history and deep history states. A shallow history state is a
reference to the most recently visited state on the same hierarchy level within
the composite state. Deep history state is a reference to the most recently
visited simple state within the composite state. When the control comes to a
shallow/deep history state, its action is executed, and the control is
immediately passed to the “real” state referred by it.
To
draw a history state
1.
Choose the History
element from
the Model page of the Palette view.
2.
Click in the
graphical editor where you want to place the history state.
3.
In the Properties
view, choose whether the history state is Deep or Shallow.
Shallow history and deep history
states
The figure illustrates the
difference between shallow and deep history states. Suppose E
is the most recently visited simple state inside the composite state A. If the control reaches the deep history state H*,
it passes to E,
whereas shallow history state H
passes the control to C
– the most recently visited state on the same hierarchy level. Then the
standard procedure of finding the initial state within C
is invoked, and the statechart ends up in D.
In case there is no visited
state at all within the scope of a history state (no history exists yet), the
control goes to the corresponding initial state, unless there is a transition
exiting the history state and pointing to the so-called default history state.
There may be at most one such transition (with If there is no history
trigger type) for a history state.
Default
history states
Triggering a Transition
When a statechart enters a
simple state, the triggers of all outgoing transitions (including the
transitions outgoing all composite states containing the simple state) are
collected and the statechart begins to wait for any of them to occur. When a
trigger event occurs, the guard of the corresponding transition is evaluated. If
the guard is true,
then the transition may be taken (we say “may be” because there may be
alternative simultaneous events at AnyLogic simulation engine, which may reset
the trigger). This algorithm of guard evaluation is called
“guards-after-triggers”.
If several triggers are
signaled at the same time, and the corresponding guards are true, the transition
to be taken can be chosen randomly or deterministically.
Transition can be triggered
as a result of various types of events occurred, namely:
·
After the
specified timeout elapses;
·
With the
specified rate;
·
When the
specified condition becomes true;
·
When the message
matching the specified descriptor is received by the statechart.
You specify the trigger type
in the Triggered by property of a transition.
Timeout Triggered Transition
The transition becomes
enabled after the specified amount of time (the timeout) elapses, since the statechart comes to the source
state of the transition. Such transition may be used to model delays and,
combined with alternative transitions, timeouts.
To
define a timeout triggered transition
1.
Select the
transition in a graphical editor.
2.
On the General
page of the Properties view, choose Timeout from the Triggered
by drop-down list.
3.
Specify the
timeout in the Timeout edit box below.
Rate Triggered Transition
Statechart transition with
trigger of type rate. A rate is a form of updateable exponential timeout. Such
transition is executed with the timeout distributed exponentially with the
parameter rate (counted from the moment the statechart came to the transition's
source state), i.e. if the rate is 5, the transition will be executed on average
5 times per time unit.
To
define a rate triggered transition
1.
Select the
transition in a graphical editor.
2.
On the General
page of the Properties view, choose Rate from the Triggered
by drop-down list.
3.
Specify the rate
value in the Rate edit box below.
If the rate changes
dynamically, the timeout gets re-evaluated; such changes may only be noticed by
transition if onChange()
is called for the active object.
Condition Triggered Transition
The transition is executed
when the condition becomes true. If the active object has continuously changing
variables, the numeric engine constantly monitors the condition. In purely
discrete models the condition is tested when something changes in the active
obejct, i.e. when onChange()
is called.
To
define a condition triggered transition
1.
Select the
transition in a graphical editor.
2.
On the General
page of the Properties view, choose Condition from the Triggered
by drop-down list.
3.
Specify the
condition in the Condition edit box below.
A transition with such a
trigger is enabled when the specified Boolean expression is true.
If by the time the statechart comes to the source state of such transition the
expression is true already, the transition becomes enabled immediately.
Otherwise, it becomes enabled as soon as the expression becomes true – e.g.,
as a result of equation solving, as a change event may contain variables
changing continuously according to a set of differential and algebraic
equations. When the expression becomes true, AnyLogic determines the switch
point – the moment when the expression becomes true – with the accuracy set
by the user.
When specifying a change
event, you should keep in mind the so-called sensitivity problem. Let the
transition wait for the Boolean expression x>=5, and let x
changes continuously in time as shown in the figure below:
Sensitivity problem
As the numeric equation
solver works by steps, it may happen that x will exceed the value 5 and get back in between the two steps. In this
case the change event will not be detected. You should be aware of such
situations when modeling systems where such error might be critical. If you
encounter such a problem, you should make numerical method accuracies smaller.
Message Triggered Transition
Statechart transition with
trigger of type message. Such transition is executed when the statechart
receives a message (an instance of an arbitrary Java class, or integer value)
that conforms with the defined message descriptor.
There are two ways of
generating message events:
·
First, you can
connect a port and a statechart. Then messages coming into the port will be
routed to the statechart and will generate message events.
·
Alternatively,
you can call the method receiveMessage() of a statechart. In this case a
message event is added to the statechart event queue, and then it can trigger a
transition.
You can perform
message checking and discard messages not matching the defined conditions. The
match can be determined using only message class and/or the message object also.
·
You can define
message type checking to allow triggering transition only by messages of some
particular message type.
·
Moreover, you can
filter messages by contents. You can define a message descriptor and accept only
messages matching this descriptor. Event descriptor is an object, which is
compared with a received message to decide if a transition should be triggered
– a filter for message events. Or you can define some boolean condition
operating with message contents and check it on each message reception.
Transition will be triggered only when this condition is true. Since you can
refer to the message contents in this expression, this way you can implement
sophisticated message contents checking.
To
define a message triggered transition
1.
Select the
transition in a graphical editor.
2.
On the General
page of the Properties view, choose Message from the Triggered
by drop-down list.
3.
If you want to
perform message type checking, specify the message type allowed to trigger
the transition using Message type group of buttons. To define some Java
class, select the Java class button and enter the class name in the Class
Name edit box. In this case transition will be triggered only by messages of
this particular type or Java class.
4.
Otherwise, if you
do not wish to perform message type checking, leave the default settings when Java
class button is selected and Object class is specified.
5.
Now define the
message contents checking conditions using the Fire transition group of
buttons.
6.
In case you do
not wish to perform message contents checking, simply choose the Unconditionally option.
7.
If you want to
define the message descriptor and accept only messages with the same contents,
choose the If message equals option and specify the descriptor value in
the edit box below. It works in the following way: when a message is
received at a statechart, AnyLogic calls the method equals() of a descriptor,
giving a reference to the message as a parameter. The method equals() may use
just message type information, or may look at message parameters. If it returns
true, then the event matches the descriptor and the transition should be taken.
false means no match. Possible message descriptors are "STOP!"
for a message of type Striing, or 5.0 for a message of type Double.
8.
Otherwise, if you
want to define a sophisticated message contents checking using a condition,
choose the If expression is true (use msg for message) option. Enter
the expression in the edit box below. Here you can access the just received
message as msg variable.
9.
Enter the
transition's guard expression in the Guard edit box. The event that has
just triggered the transition is available for further analysis via the method
getEvent() of a statechart.
10.
Enter the
transition's action code in the Action edit box. The event that has
just triggered the transition is available via the method getEvent() of a
statechart.
Statechart queue processing
A
statechart handles message reception events in the so-called event queue. The
event queue is necessary because message events may occur at those moments of
time in which the statechart cannot react to events (e.g. when a transition is
executed). The event queue is processed by a statechart according to the
following algorithm:
The event processing starts every time something occurs to the statechart, e.g.
receiveMessage() is called or the statechart makes a step.
·
If there is one
or several transitions outgoing the current simple state or any of its container
states, whose trigger matches the first event in the queue, such transitions
become enabled, i.e. one of it is taken depending on guards.
·
If there are no
such transitions, but the event matches any of the deferred event descriptors of
the current simple state or any of its container states, or of the whole
statechart, the event is kept in the queue, and the next event is processed.
·
If no match is
found in the deferred event lists either, the event is deleted from the queue,
and the next event is processed.
A
statechart can make several consequent steps processing several signal events
from the queue (these steps take zero model time). When the statechart finishes
processing and starts waiting, the event queue is either empty or contains only
currently deferred events.
Execution Order
It is important to know
exactly what the order is of the execution of statechart elements' actions. For
this reason we present the following algorithm.
When a transition is taken,
transition and state actions are executed in the following order:
1.
State exit
actions starting with the old simple state up to the outermost exited composite
state.
2.
Transition
action.
3.
State entry
actions starting with the outermost entered composite state down to the new
simple or pseudo state.
4.
If the control
enters a pseudo state, its action code is executed, and then the control goes
out of the pseudo state immediately, and this algorithm applies again from the
beginning.
Actions associated with
statechart elements (states and transitions) are executed atomically and in zero
model time. Therefore they cannot contain synchronization and delay operations,
or call methods directly or indirectly containing them.
Example
Execution
order illustration
Consider the example shown
in. Suppose N
is the current simple state and transition T1
has been selected to be taken. Then the actions are executed in the following
order:
1.
N
state exit action
2.
M
state exit action
3.
T1
transition action
4.
Branch action
Then the transition T2
or T3 is selected depending on guards of the transitions. In case
the selected transition is T2,
the following actions are executed:
5.
T2
transition action
6.
I1
initial state pointer action (exit and entry actions of the state L
are not executed since that state is not exited)
7.
M
state entry action
8.
I2
initial state pointer action
9.
N
state entry action
In case the selected
transition is T3,
the following actions are executed:
10.
L
state exit action
11.
K
state exit action (actions of the state V
are not executed)
12.
T3
transition action
13.
S
state entry action
14.
P
state entry action
15.
Branch action
16.
P
state exit action
17.
T4
transition action (the guard of this transition must be true as this is the only
exit from the branch)
18.
Q
state entry action
19.
I3
initial state pointer action
20.
R
state entry action
Event Processing at the Simulation Engine
AnyLogic simulates the model
as a sequence of time steps and event steps. During a time step:
·
The model clock
is advanced.
·
The
“discrete” state of the model (the statechart, port, event, etc.
states) remains unchanged.
·
Active equations,
if any, are being solved numerically and the variables are changed
correspondingly.
·
Awaited change
events are tested for occurrence.
During an event step:
·
No model time
elapses.
·
The actions of
states, transitions, events, ports, etc. corresponding to this event are
executed.
·
The state of the
model may change.
·
Some scheduled
events may be deleted, and the new events may be scheduled in the AnyLogic
Engine event queue.
Engine Events
AnyLogic engine events are
events that occur at runtime. Please do not confuse them with static/dynamic
events that are a part of AnyLogic modeling language. There are several types of
engine events:
·
current –
events that can be executed at the time now
·
chosen – one of
the enabled events that is chosen to be executed next
·
enabled – other
current events (those that potentially could be executed next)
·
scheduled –
events scheduled at some particular known time in the future
·
pending –
events that may occur in the future, but the time is not known
Engine events reside in the
engine event queue. Any event present in the engine event queue may be
associated with:
·
an active
static/dynamic event
·
a transition
triggered by rate or on a timeout or expiry
In addition, current events
may be associated with something that has just happened as a result of other
event execution:
·
a transition
being triggered by a port, or by message or condition event
Time Step
If there are no current
events, AnyLogic makes a time step to the nearest event (or events) in the
queue, i.e., advances its clock. During a time step a condition event may occur.
The discrete part of AnyLogic engine does not know when a condition event
associated with a transition occurs: it depends on the equation set being solved
numerically by a continuous part of the engine. Once this happens, the clock is
advanced to the time reported by the continuous-time equation solver, and the
event step is executed.
Event Step
Several events may be scheduled to occur at the same moment
of time. If there are several current events, AnyLogic chooses one and executes
it. This is repeated until there are no current events. Thus, several event
steps may be made in succession, whereas a time step is always followed by an
event step. Simultaneous events may depend on each other or be truly concurrent.
The serialization of concurrent events is called interleaving a model.
The execution of a timer event is actually the execution of
the timer’s action code. The execution of a transition event is the execution
of a set of actions associated with the transition. As a result of the event
execution, the discrete state of the model may change: statecharts may change
their states, other transitions may begin waiting, and other timers may be
activated. Thus, some events may be deleted from the event queue and other
events may be added to it.
The example of AnyLogic event queue processing is shown in
the figure below.
AnyLogic event queue (pending events not shown)
| 
