A state machine is a concept that helps with defining a - mostly finite - number of states of a system, and how that system navigates (transitions) between those states. State machines are usually used to either model or recreate real-world systems, so that we can design and build our software accordingly. Graphs can help with visualising how a given system can be represented by states and transitions. In software engineering, we sometimes take the concept of a state machine and actually build that concept into actual code that can execute.

For the history of our HSE State Machine, feel free to read our guest blog post on Steve Watts' blog.

A state machine can be used for both high- and low-level modules, e.g. to control a whole application or to implement a hardware driver.

Transitions may trigger a state change, e.g. Finished Initialization (only in one state), or Exit (in multiple states), but also be ignored, e.g. there is no transition Reset allowed to request the state change from Idle to Initialising.

The HSE State-Machine Singleton module template is a standard DQMH Module, extended with our HSE DQMH® Flavour. Additionally, a Helper Loop is used to implement a state machine.

The State Machine Helper Loop is a while loop with nested case structures:

• The nested cases define the state machine, in particular which transitions within states can lead to another state.
• Two type def enums are used to define which states and transitions generally exist in the module.
• The outer case structure HSE_STATE_MACHINE has a case for every state.
• The inner case structure HSE_SM_TRANSITION defines the allowed transitions within this state and the subsequent state.
• The SM Wait for Transition.vi implements an event structure which waits forever for a transition, if no timeout is wired in.

Contrary to our normal approach, the State Machine Helper Loop is not registered to the Stop Module event. See How to stop the State Machine for more information.

In general, a public request asks the DQMH Module to do something, resulting in the execution of an MHL-case. There a transition is requested. Depending on the implementation of the state machine, this request will

• lead to an exception
• trigger a transition
• be ignored

When a transition is actually triggered by the state machine, in general, code needs to be executed. This code is placed inside an MHL-case which will be triggered by the State Machine. Finally, the MHL-case itself could request the state machine to go to the next state. Of course, the calling code could also be a request to another module and the transition to the next state could be requested by the broadcast of another module, etc.

For modules with user interface, the SM Update UI State.vi is implemented in the state machine. This VI calls the Update UI State MHL-case and allows to specifically react to state changes.

• HSE Blogpost
• Parsing State Machines
• Transitions are important
• State Machines Done Right
• Cohesion for VIs and your State Machine