Hierarchical State Machine
In this article, we will be highlighting the advantages of hierarchical state machine design over conventional state machine design.
In conventional state machine design, all states are considered at the same level. The design does not capture the commonality that exists among states. In real life, many states handle most messages in similar fashion and differ only in handling of few key messages. Even when the actual handling differs, there is still some commonality. Hierarchical state machine design captures the commonality by organizing the states as a hierarchy. The states at the higher level in hierarchy perform the common message handling, while the lower level states inherit the commonality from higher level ones and perform the state specific functions. The table given below shows the mapping between conventional states and their hierarchical counterparts for a typical call state machine.
|----------------------|--------------------------------------------------|
| Conventional States | Hierarchical States |
| Awaiting First Digit | Setup.CollectingDigits.AwaitingFirstDigit |
| Collecting Digits | Setup.CollectingDigits.AwaitingSubsequent Digits |
| Routing Call | Setup.RoutingCall |
| Switching Path | Setup.SwitchingPath |
| Conversation | Conversation |
| Awaiting Onhook | Releasing.AwaitingOnhook |
| Releasing Path | Releasing.ReleasingPath |
A conventional state machine is designed as a two dimensional array with one dimension as the state and the other dimension specifying the message to be handled. The state machine determines the message handler to be called by indexing with the current state and the received message. In real life scenario, a task usually has a number of states along with many different types of input messages. This leads to a message handler code explosion. Also, a huge two dimensional array needs to be maintained. Hierarchical state machine design avoids this problem by recognizing that most states differ in the handling of only a few messages. When a new hierarchical state is defined, only the state specific handlers need to be specified.
Conventional State Machine Example
The figure below describes the state transition diagram for an active standby pair. The design here assumes that the active and standby are being managed by an external entity.
The different states for the state machine are Active, Standby, Suspect and Failed. The input messages to be handled are Switchover, Fault Trigger, Diagnostics Passed, Diagnostics Failed and Operator Inservice. Thus the handler two dimensional array is 4 x 5 i.e. 20 handlers need to be managed.
The code below shows the handlers that need to be defined. A dummy "do nothing" handler should be specified for all other entries of the two dimensional state table. This simple example clearly illustrates the problem with conventional state design. There is a lot of code repetition between handlers. This creates a maintenance headache for state machine designers. We will see in the following section that hierarchical state machine design exploits these very similarities to implement a more elegant state structure.
Conventional State Machine Implementation
Hierarchical State Machine Example
The following state transition diagram recasts the state machine by introducing two levels in the hierarchy. Inservice and Out_Of_Service are the high level states that capture the common message handling. Active and Standby states are low level states inheriting from Inservice state. Suspect and Failed are low level states inheriting from Out_Of_Service state.
The following diagram clearly illustrates the state hierarchy. Even the Inservice and Out_Of_Service, high level states inherit from the Unit_State that is at the highest level.
Hierarchical State Machine Source Code
The C++ implementation details of the hierarchical state machine are given below. It is apparent that all the commonality has moved to the high level states viz. Inservice and Out_Of_Service. Also, contrast this with the conventional state machine implementation.
The code below contains hyperlinks to more detailed information about the classes, methods and variables in this information.
Header File
The header file below declares the Unit state machine using the Hierarchical_State_Machine class. Important points to note are:
- The state classes are nested private classes within the state machine class. Thus they are not visible to other classes.
- The state machine declares all states to be friend classes. This does not break the encapsulation as only a private class is being declared as a friend.
- The base class (Unit_State) provides a "do nothing" implementation for all handlers. Thus an inheriting state has to provide an implementation only for that methods it supports.
- State objects are declared static. Thus multiple instances of the state machine will share the same state objects. Due to this, the Hierarchical_State_Machine class has a small memory footprint.
- Only the main message handler, On_Message, is declared public. All helper functions are private.
- A pointer to the current state is maintained in p_Current_State variable. This variable gets initialized using the Next_State method.
Hierarchical_State_Machine.h
Source File
Important things to note about the source file:
- On_Message, the main message handler invokes the appropriate handler based on the type of the message. The message is passed to the current state object.
- The Out_Of_Service and Inservice base states handle most of the message processing. In some cases, the inheriting states perform some additional action and call the handler for the base state for the common part of the handling.