# Hierarchical State Machine (HSM) superstate and substate sharing event

I am learning HSMs and I can see a problem that I don’t know how to address. The problem is shown in the image bellow.

Inside S1, substates S11 and S12 are continuously changing in reaction to TIMERTICK event. At the same time the superstate S1 needs also to keep track of TIMERTICK event in order to change to S2 after an amount of time.

As far as I understand TIMERTICK event will be always processed in one of the substates first so it can’t be used by superstate S1. What is the way to deal with this situation?

As far as I understand TIMERTICK event will be always processed in one of the substates first so it can’t be used by superstate S1. What is the way to deal with this situation?

There are three ways of dealing with this situation:

### Parallel messages

The timing generator posts two messages `TimerTick1` and `TimerTick2`. The substates react only to `TimerTick1`, and "burn" the message when they react to it. The superstate reacts only to `TimerTick2`.

The timing generator will always be posting duplicate timing message, because it shouldn't "know" the exact state configuration.

### Chained messages

The timing generator posts one message `TimerTick1`. When a substate reacts to the `TimerTick1` messages, it "burns" that message, it also post a different message `TimerTick2`. The superstate reacts only to `TimerTick2`.
[I use this method frequently.]

This approach somewhat increases the coupling between the substates and their superstate. The substates "know" that that there is a superstate and they have to post a certain message for it.

### Relax the rule that the substate has to "burn" the message

It's a design choice whether or not the substate necessarily burns the message after acting on the message. If you don't burn the message, you can pass it on to the superstate.

You will need to watch out that the superstate doesn't spoil the work of each of its substates. In other words, this can increase coupling between substates and their superstate.

Here's the purest example of such coupling. As a reaction to a message, a substate determines that the HSM needs to change state to S42. As a reaction to that same message, the superstate determines that the HSM needs to change state to S24. Should substate or superstate win? Were will this be arbitrated?

Typically in an HSM, once you're in a state we let its nested machine have at it (process inputs) until there is an input that is not recognized, which is instead bubbled up to the enclosing/parent state to handle.

In your case, you would need to not handle all timetick's at the nested level so that some can be handled at the outer level.

You might do this by qualifying the events accepted at the nested level, e.g. `TIMETICK [counter < Timeout]`.

The (now) unhandled final timetick at the nested level will naturally bubble up to S1 and cause transition to S2.

• Thanks. This is exactly the same answer I got at [link] (sourceforge.net/p/qpc/discussion/668726/thread/70959a0a3b) – JHG Feb 11 '19 at 17:56
• Very good :) You can see from the mechanics that, given a proper qualifier at the nested level, no qualifier is necessary at the upper level (as this works like an "else" catching any remaining unhandled (timetick) events). Indeed in the sourceforge answer, the qualifier is absent on the S1 -> S2 transition. – Erik Eidt Feb 11 '19 at 19:27
• @Erik This approach works well for timer messages. They are abundant, they occur at a predictable (known) rate, the value (the time) changes in a gradual fashion. This approach wouldn't work as well for events which happen rarely. If an event occurs rarely, and the state machine receives only one message for it, and only one state gets to handle it (nested, or its parent), then how will they (state machine or the states) decide which state (nested, or parent) gets to handle that one event? – Nick Alexeev Mar 25 at 4:06
• Similar thing with messages which come frequently, but only some solitary messages are important. For example, there are fast spikes in the values that are attached to messages. The spike appears only in one message (the message before it, and the message after it are "plain"). How will they (state machine or the states) decide which state (nested, or parent) gets to handle that one event? A simple "not all" approach would leave this to chance. – Nick Alexeev Mar 25 at 4:15