State Machine / Flow Chart

Image credit: XKCD.com

This post is an interlude from the mainline discussion of Model-Based Design.  Today I will discuss the differences between flow charts and state machines.  The most fundamental difference between the two is that a state machine has knowledge of the past based on its current state(s).

southernsnowproblem

The southern snow problem

To give an example, if you live, or have lived, in the southern part of the United States you are aware of the syndrome known as  snow panic.     The south can be an pleasant place in the winter filled mild walk able days (see left hand state “EverythingIsFine”) but once snow is predicted they enter into the right hand state “OhMyGodSnow” and huddle up “SafeAtHome” until either the snow is gone or food runs out.  All of this logic is captured in 4 states and can be evaluated in a with a maximum of 2 operations [(noSnow==FALSE)&&(food<=deltaFood)].

southernsnowproblemflow

By contrast the flow chart version of this has a average of three operations and manually maintains a state (wasInSnow).

But how does it scale….

When I first learned C programming my instructor provided the rule of thumb “Never nest If/Then/Else statements more than 3 deep.”  That rule of thumb still holds for State Charts (MAAB: NA_0038) and ladder logic .  Fortunately both can be “nested” in logical containers known as Subcharts.  Recommendations for when to sub-chart can be found here,MAAB: NA_0040.

So which do I use?

Like most engineering questions the answer is “the correct one.”  Remember the way to tell which is correct is ask yourself, do past states matter, then a state chart may be the way to go.  If everything is based on current information then use flow chart logic.  In the end favor clarity over dogma.

itisatrapflowchart

Next post:

In the next post I will return to adoption time line: exploration phase part II.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.