Skip to content

Create More generic FSM objects

Summary

Currently, the FSM code is hardcoded to a certain set of states that may or may not be needed by different applications that could use FSM functionality. For instance, in the monitoring suite, only 3 states are truly needed, namely Unconnected, Running, and Stopped for connecting to the rpc and starting and stopping the actual monitoring of variables. While 3 states may need to expand for the monitoring suite, because the current code base only has the specific states in GEMStates.h, this could use expansion and generalization

What is the expected correct behavior?

A generalized FSM class where states and transitions can be specified for the specific application. If there is a commonality in the FSM structure, a helper class could be created for more specific FSM structures. Ideally, all FSMs would be diagrammed out to be easily accessed in the documentation for reference.