The Universal Communicating Hierarchical State Machine Template shown below (with debugging code removed and Run State Machine action selected) includes initialization, main, and clean-up parts. Save the image to your hard drive and open it in a graphical editor to see the details.

The initialization code includes reading the HSM behavior info from an external file. The main part of the code in turn breaks down into three major subparts: the Processing loop, the UI Events Capturing loop (optional), and a call of a reentrant Message Receiver VI (optional).

The actions’ code is stored in the respective cases of the case structure inside the Processing loop. The special action Run State Machine takes the behavior info, the current state, the state history info, and the next event pulled from the Events queue after prioritizing it. The Run State Machine action determines the next (target) state of the system and enqueues all the actions that need to run in the transition. The actions then execute in the order they were enqueued. At the beginning of each iteration the next action is pulled from the Actions queue defining which case the program will go into. Whenever the Actions queue becomes empty Run State Machine gets executed again. If there are no events in the Events Queue, the VI just waits for the next event without consuming CPU cycles.

To observe the encapsulation principle only public events should be exposed. This is implemented by a separate message queue and the Message Receiver VI on the bottom of the diagram.

There are three possible sources of events: a user interaction event, an event resulted from some action and a message received from another VI . The top loop provides capturing user events and putting them into the Events queue. Additionally, events can be posted to self from within actions. Message Receiver translates external messages into the respective events and puts them into the same Events queue. Thus, uniform handling of all the events is provided regardless of their source.