Should a Finite State Machine have a “nested” Finite State Machine?

Question

You can read this question where I ask about the best architecture for a machine application for a little back story, although it's not entirely necessary for helping me with this question.

My understanding (especially for implementation) of Finite State Machine's is a little young and may be lacking a bit, but I am implementing this application as one, and I've got a place where I kind of need to have a nested FSM. Basically the machine has a few high level states (Cold [a.k.a just started], Homing In, Setup, Ready to Run, Running, Reporting, Reseting) but when the machine is running it kind of needs to have it's own little FSM implementation for (Loading Lense, Locating Edge, Measuring Wedge, Measuring Roundness, and Complete [may be some more in there]).

My question is this: Should I build in the capability of having "nested states" where a state can have a list of sub states and the system can enter those sub states and those sub states can return out to parent states? Or should I just put a FSM implementation inside of the Running state, and keep them as two distinct FSMs? Or do you think I'm doing or thinking something dumb and should rethink it?

Thoughts, suggestions, criticisms, and advice are all welcome.

Answer 1

Nested state machines are a standard notion in UML, so this is not necessarily dumb. More details here.

Answer 2

In contrary. Having the possibility to nest FSMs is a good thing.

One should not nest FSMs just to do nesting, but sometimes FSMs get quite large. Having such a large drawing undermines the purpose of an FSM-model since it does not give you a nice view of the inner working. It becomes just a huge diagram with way to many details.

I think you can compare it with classes. If you stick everything into one class (and even worse, make everything static) the purpose and advantages of having a class will disappear.

Same goes for FSMs.

To give you an example, a collegeau of mine has model quite "realistic" the behavior of a dog using FSMs. He has a huge model and by having nested FSMs i was able to understand the model in just a few mins.

So it is definitely a good thing, if it is used properly.

Answer 3

I just want to add that nested states (in UML FSM) are not the same as "putting" a separate FSM inside a running state.

In real hierarchical FSMs, events are first posted to the current nested state. If that state doesn't handle them, they will be posted to the parent state, and so on. This allows one to "refactor" common state transitions from nested states into a parent state.

Answer 4

I solve this by having an enum representing states of the state. For example Bunny has a Procreation state.

ProcreationState has an enum

   enum State
{
    SettinNewSearchPosition,
    SearchingForFriend, 
    MovingTowardsFriend,
    EstablishingFriendship,
    Mating
}

In the states update method i just check what state its in and act acordingly. I guess this limits the overall capability of this system. Im not so experienced so im trying this out. Any feedback on this approach is apreciated.