As a software engineer you are probably familiar with Finite State Machines and their traditional usage in digital hardware design. You are likely aware that FSM concepts are also part of the UML modeling capabilities using Statecharts. As indicated by the 2008 Market Survey provided by Embedded Systems Design magazine, about one in five embedded projects uses UML. The survey does not specify whether UML Statecharts is the reason why UML is used. Unfortunately, the survey does not provide any data about the use of Finite State Machines for embedded software either, so it is difficult to assess the opinion software engineers have about FSMs. It could be stated that the current unpopularity of FSMs (for embedded software) might be attributed to the fact that FSMs are traditionally a digital hardware design method, and that they are therefore too complex to even consider using for embedded software architecture design. Also, there exists a common misconception that attempting to model and design an entire system as a single state machine results in 'state explosion' and unnecessary complexity. Thanks, in part, to Harel[87]'s Statecharts: A Visual Formalism for Complex Systems, this misconception should be dispelled entirely. Statecharts introduced orthogonality/concurrency and the concept of AND states (versus exclusive OR) and Staccato™ introduces 'partitioning by resource' to encourage an architecture based on 'a system of Finite State Machines'. Given this, software engineers should (re)consider using FSM concepts in their embedded software architecture and module design.

In the early times of computer programming, 'spaghetti code' was a term often used (correctly) to describe typical source code and its unmanageability. Fortunately, formal structured methods were eventually developed to offer some organization to this arcane process. However, the challenge to organize logic into manageable patterns continues to persist today. You should now recognize that this is why Finite State Machine concepts are so useful. FSMs allow you to organize your logic into independent blocks of event-action-transition logic that are easy to design, debug, document and verify. In fact, one could consider all embedded systems, in particular the software, as Finite State Machines, whether explicitly designed as such or not. It is very conceivable that, upon reviewing non-FSM-based embedded source code, state behavior could be determined and proper partitioning would likely be indicated. So, why aren't FSM concepts used more frequently in embedded system software?...Is it due solely to lack of knowledge or training?... or is it the fact that most embedded systems still use a commercial or open-source RTOS? They work, but at what cost?

Multitasking, kernals, schedulers, code re-entrancy, mutexes, inverted priorities, arbitrary partitioning, context switching...ugh!...and now Finite State Machines? Yes, but you won't need that RTOS at all. Staccato™'s 'system of Finite State Machine-encoded tasks' allows for direct execution without an RTOS. Staccato™ is an RTOS alternative.

If you think you would benefit from using Finite State Machines in your embedded project software, discuss it with your team members and suggest it to your manager. The Staccato Crossroads SDK provides individual IEEE-CEU Certified Training and many examples of how to architect your embedded system software.