State Machine based software: The washing machine example

State Machine based sw. The washing machine case.

Abstract	Modern electronic washing machines have a microcontroller to perform all the washing cycle plus interfacing with the user and monitoring signals to keep the machine in a safe state. This is a clear example of a multitask software. For this scenario, deployment of state-machine based software makes the development process easier, quicker, and leading to a more robust product and shorter time-to-market times.
Author	Joan C. Abelaira
References:	Wagner, F., "Modeling Software with Finite State Machines: A Practical Approach", Auerbach Publications, 2006 Linz, Peter. "Formal Languages and Automata" (4th ed.). Sudbury, MA: Jones and Bartlett (2006) Cassandras, C., Lafortune, S., "Introduction to Discrete Event Systems". Kluwer, 1999 Carroll, J., Long, D. , Theory of Finite Automata with an Introduction to Formal Languages. Prentice Hall, Englewood Cliffs, 1989

The washing machine software case.

An electronic washing machine control has to do a number of tasks (pseudo) simultaneously:

control the speed and sequence of the rotating drum.
keeping the water level in the drum for the wash.
taking soap and softener at the right moment.
keeping the water temperature profile.
accepting user commands, even when running a wash cycle.
displaying info to the user.
optimize the function, like minimizing water usage or doing extra rinsing.
monitoring system for safety, stop if door opens, avoid flooding or the motor going at full speed.

Traditionally, microcontroller software has been developed in C language after the stone ages of crude assembler. This work scheme leads to a number of "modules", independent of each other up to a certain level, one for water level, other for motor speed, another for temperature, for user interface and so on. All these modules are integrated by a kind of scheduler that provides "unity" to he system.

Current competitiveness forces software developing teams to become not only faster but also creating more robust products. Software bugs, when at customer's house, become not only a huge expense in reprogramming, but also a discredit that eventually lowers sales. Clearly, like in the past moving from assembler to C represented an advantage in software quality, nowadays moving from C language to visual and structured tools strengthens and speeds up the software developing process.

One of these tools is VisualState (from IAR). With this application, software is developed graphically, with the traditional box-and-arrow appearance. One would say this is approach only practical for small charts otherwise you get a mess of lines, but as State Machines (SM) can be parallelized (as many as you want in parallel) and nested (a state of a SM can contain a second SM and so on), with a little organisation you can put in half a dozen of A3 sheets what otherwise would be 100 pages of C listing. Another big point of implementing such tools is that developers can discuss with non technical people (like the customer) about the software behaviour.

Another complain people come up with about SMs is the reluctance to the change: "we already have a library of functions...", "this takes us back to a ground level...", "the way we have worked so far is well proven...", "this will force us to train again our whole engineering team..." and so on. But reality shows us that wisely betting for good new tools makes companies to outstand from the others and this eventually turns into an increased market quota and sales. VisualState actually integrates perfectly with C code. In fact, it generates C files to be compiled with the rest of the code. C language and experience has not to be thrown out, it is just "hidden" while the developer look at a higher level. And VisualState do not demand all C code to be replaced by SMs, functions can be executed from SM states and transitions.

Basics of State Machine based software

A State Machine (SM) is a way to describe the behaviour of a logic process. Therefore it serves for the same as flowcharts used in formal programming languages, like C, Fortran, etc. They are represented by a state diagram (see example below), opposed to the text format used in C language. Note why at a glance you discover this is the behaviour of a battery charger. Would you find it out so easily in a C listing without comments?

The elements of a SM are these:

States: represented by circles (like in the example above) or boxes. Each state has a name. The systems has to be always in one and only one state. They represent a memory and make the SM output to depend on history.
Transitions: represented by arrows. A transition is a change from one state to other (or the same).
Actions: The output of the SM. They are processes (like turning on or off a LED or computing an FFT) triggered by either a transition (Mealy Automata) or a state (Moore Automata).
Events: The input to the SM. Events plus current state (that depends on history) generate the output (actions).

How a State Machine is implemented in software

One question many people put at this point is "how do I put that beautiful graph in my microcontroller?". The answer is the State Machine Compiler. This tool generate a number of standard C files that can be later compiled (with your own C files) by using your preferred compiler for your microcontroller. As SMs are not microcontroller dependent (they are in a higher abstraction level), code generated have no portability problems. IAR VisualState offers two code generation options: human-readable and table-based. The latter makes the final software to be smaller and quicker.

Evil people come again and say now "two compilers in series? isn't that odd?". Well, years ago many people distrusted C compilers with arguments like "I don't know what the compiler is making" or "compilers can have flaws". Where are they now and how develops (competitively) without them? Actually, what we call "compiler" is a 3-stage process (compiler-assembler-linker), so what's wrong in adding a 4th stage (SM compiler)?

A compiled SM comes with an API (Advanced Programmer's Interface) to interface it to your C program. Basically there is an Event Queue and an Action Queue. The usage process is as simple as described below. First your C program generates events (wherever, even in interrupt routines) and add them to the queue (with an API function). Then the SM is invoked with another API function. And the third and last step is to retrieve the actions from the queue and execute (call) the corresponding functions. Do that regularly (let's says every 1 ms) and the recipe is finished. Could it be simpler?

queue events from anywhere in your code

update (execute) State Machine

retrieve actions and call them

What more can State Machines offer?

No software development tool makes perfect software at once. So simulation and debugging are needed tools and as important as any other part of the development process. A slow, inefficient debugging is as bad as a faulty developing or production process.

In the case of IAR VisualState, the following debugging tools are available:

Verificator: This tool examines the design looking for dead-locks, conflicting transitions, unreachable states and other wrong conditions before they become code where they would be harder to find.
Validator: you can look at it as a SM simulator where events are entered and the behaviour and actions can be seen and recorded before generating code. In this way, the tested SM is robust and reliable, so the chance of later bugs is much less, thus reducing the field-test time to the minimum.
Prototyping: SMs can include a PC based user interface to emulate the final application, like a wash machine front panel. These prototypes (software ones) can be tested by the customer in a very nearly stage to fine-tune the desired software behaviour.

Conclusion

One should avoid thinking SM based software is going to replace C language. Remember the definition of SM: a way to describe a logic behaviour. It doesn't say the best way, nor a better way. Just a way to do it. SM approach is good for history dependent processes or parallel inter-dependent processes, like many machines and user interfaces. It is not good for computing and other clearly sequential processes. So SMs do not come to replace C, just to enrich it.

SM based software design is not only aesthetically more pleasant and nicer to work with it. Potential bugs can be easily fixed by looking at the state diagram and putting questions like "what if the system is doing this and that happens?". Immediately you identify the state and the condition and check if the action is right or not.

Designing SM based software is like watching an area from the sky, having a 2D view.
Programming just in C is like watching that area from its roads, in 1D.