Question

I have a state machine in which I might have to restart something when needed (Say restart a hardware). But after restarting, I need to run some tests on the thing. If the tests fail, I need to stop the thing and exit the state machine with a failure status.

In case of failure, how should I handle the 2nd stopping of the thing? The state machine diagram loses its readability if I do it the following way. And the implementation becomes ugly since I need to decide Stop thing state's output based on the previous state (SUCCESS the first time and ERROR if the state was reached after failing the tests)

Option1

My other option is to create a 2nd instance of the Stop thing state as follows. But then it makes the state machine bigger

Option2

Which one of these is the correct approach? Or is there another way to approach these kind of problems?

If it matters here, I am using ROS and smach for the state machine implementation

Was it helpful?

Solution

Your first statemachine does not accurately reflect the desired behaviour you described. In the first statemachine, you keep retrying to restart the "thing" until either the tests pass or stopping fails.

Your second statemachine does show the desired behaviour of trying to restart the "thing" once and stopping it again when the tests fail.

Note that a state is not defined by the actions that are performed in the state, but more by the transitions leading out of the state. This also means that a state should not need to know how it was reached. If the path leading up to a state is relevant for how the state reacts to events, then it is really multiple states. As the transitions for Stop thing 1 and Stop thing 2 are completely different, it is entirely correct to model them as two different states, even if they take the same actions and respond (albeit differently) to the same events.

Licensed under: CC-BY-SA with attribution
scroll top