Unfortunately, the state machine concept in software has been firstly used for theoretical purposes in the mathematical foundation of computer science where obviously only the event driven parser model is useful. This model assumes that a state machine is triggered by an event to do something and possibly change a state. This model applied to application software where a control systems are modeled is totally useless: in our book (Wagner F. et al.: Modeling Software with Finite State Machines) we discussed in details the limitations of that model, especially the problem of state number explosion.
A recent email has provoked us to show the solution of a traffic light controller in the Solution page on our web site. This email shows again the damage that is produced by tools which use the UML syntax for specifying state machines. The base is a statecharts idea that assumes the above mentioned parser model.
I do not want to repeat here any extracts from the book or numerous technical notes and case studies available on our web site. I would limit my comments only to two topics that are the essence of all the misunderstandings that surround the state machine concept.
1. An event is a signal that triggers the state machine to work: to do something and change a state (I do not want to go now into the different models with input action, entry actions, etc. as these are secondary issues). The conditions that determine what to do and whether to change a state is not the event itself but the value of one or more state machine inputs (see for instance Chapter 7 in the book). In the Traffic Light example the transition condition from the state Hgreen_FRed to the state HYellow_FRed is Vehicle_DETECTED & Ti_Green_OVER, i.e. the transition condition is an AND operation of two input values: Vehicle_DETECTED and Ti_Green_OVER. If you try to do it using only the event as a condition you end up in a lunatic world with a state machine inside a state, flags in a state machine, inventing “guards” on transitions, concurrencies, and so on.
2. There is very rarely a need for concurrent state machines. First of all a system of concurrent state machines makes sense only if you have a true multiprocessor system and you are able to partition the (multiple) state machine execution onto several processors. Secondly, you need to have a reason to do it. In reality you normally need three levels of parallelism: the system of state machines, the input handling system and the output handling system. The input handling system processes the inputs, makes them available to the state machines and generates events to trigger state machines if any input changes. The output handling system performs action as ordered by state machines. If those two time-consuming tasks run concurrently to the system of state machines this system is just a decision machine, to order the output handling system what to do on the basis of the actual input conditions and a state, and is very fast in operation. In such a model it is difficult to discover any motive for requiring concurrency of state machines.
Any comments will be appreciated.

The concept of a state machine is old; its definition belongs to the basics of Automata Theory. In principle it seems to be a simple definition and requires understanding of the “state” concept. In spite of its simplicity the concept has been deformed, corrupted, misunderstood and up now the well known misunderstandings about a state machine result in a relatively modest use of the state machine idea in the specification and design of software. In our publications we try to indicate that a state machine is so well defined (see for instance the book or the technical note and the the already mentioned document about Moore and Mealy models) that it does not require re-definitions or (mis-)interpretations, especially that:
- a flow chart is not a state machine
- a Petri net is not a state machine
- a statechart is not a state machine
- there is no need to define an incomplete state machine under a new name (see for instance the technical note)
- it is possible to create a complex control system modeled by a system of state machines
to name only some topics discussed in our documents.
We are convinced that the concept of a finite state machine is one of the strongest ideas in the world of modelling control tasks in general and specifically in the design of a software control flow. A typical implementation of software control flow using the if-then-else and switch like mechanisms supported by numerous flags is a primitive style of development difficult to understand and accept in the 21 century.

Mealy and Moore models are the basic models of state machines. A state machine which uses only Entry Actions, so that its output depends on the state, is called a Moore model. A state machine which uses only Input Actions, so that the output depends on the state and also on inputs, is called a Mealy model. The models selected will influence a design but there are no general indications as to which model is better. Choice of a model depends on the application, execution means (for instance, hardware systems are usually best realized as Moore models) and personal preferences of a designer or programmer. In practice, mixed models are often used with several action types.