Search code examples
c#c#-3.0finite-automata

Should a Finite State Machine have a "nested" Finite State Machine?


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.


Solution

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