Have you ever had to create a Finite-State machine?

Question

This does not include a finite-state machine you might have done for college.

I want to know who has had to create one and why?

What was the most difficult aspect of creating the machine?

Answer 1

Yes, lots of them. Basically, I had to implement lexical analyzers manually for performance reasons. Other personal uses have been in GUI designs where the FSA has controlled the flow of interaction with the user.

Creating such machines is not difficult at all. Changing them is because at least part of the structure of the FSA is embedded rigidly in the code. The state pattern helps to ease some of these transitions – but not all of them.

Answer 2

As above, the purpose of an FSA is just that, going from step to step to step, all your processing (and state changes) are handled in one loop. And, when something changes in the process, getting to the next logical step is easy.

And yes, they're easy to do, I have used them frequently over 25 years.

Answer 3

Many times!

Most protocol stacks used in communications systems are implemented as state machines. The CSTA call model being one good example.

Also most embedded systems are essentially state machines.

Basically any system that has to react to events in the real world is a good candidate for implementation as a state machine.

The most difficult thing about state machines is understanding what they do in the absence of up to date documentation. They have a tendency to get bug fixed beyond recognition.

Answer 4

Sure, I designed and created a turbine governor to control small turbines, pumps, and motors. It is an embedded device with a DSP chip. It has states such as stopped, startup, running, overspeed-test and then there are several states within the running state to cover other control possibilities.

In my case, the hardest part about the state machine management was designing a clean transition, especially when states can have sub-states. For the turbine governor, this meant that the speed output (actuator) had to be adjusted smoothly between transitions. Other challenges were related to the user interface (push buttons and 7-segment LED display) and how they interacted with the state machine. So there ended up being a master control state machine, a related user-interface state machine, and a related communications state machine (it was not permissible to write certain values while the turbine was running).

I have used state machines in a variety of other projects, some embedded and some standard software, as well from communications to user interface software.

Answer 5

I have too. I usually create small FSMs (with few states) because bigger ones become maintenance nightmares, but sometimes an FSM is a very simple and elegant design for a given task.

As a real-world example, I created a little utility to repair a certain type of file once. There were only 3 or 4 possible interaction paths with the user:

• show a little message, select file (maybe cancel and start over),
• repair file (maybe cancel and exit with error message),
• show a confirmation message.

Creating the state machine made those paths apparent and easy to implement.