Merging modern software development with electrons and metal
Random header image... Refresh for more!

Initial Statechart Thoughts

I’ve finished my initial skim of Practical Statecharts in C/C++; my time was definitely well spent.

Startcharts are a type of hierarchical state machine.  Hierarchical state machines allow state machines to be nested inside state machines, which allows behavior to be inherited (analogous to inheritance in object oriented programming).

State machines are a way of modeling systems based on transitions from one state to another, with the transitions caused by events or conditions being met.  They are a very natural way of modeling many systems (for example, communications protocols) in semiconductors, embedded systems, automation systems, and more.

The UML (Unified Modeling Language) provides a standard statechart.  The author, Miro Samek, implements a simplified version of the UML statechart in object oriented C or C++ using message passing with a publish/subscribe message bus.  Although the author emphasizes implementation details, he does include some good advice on creating and structuring statecharts.  On the other hand, his quantum physics analogies detract from the text.

I will have to carefully re-read it and try using the concepts myself before I deeply understand it, but here are my initial, somewhat unorganized, thoughts:

  • The book is definitely aimed at embedded developers; the author is always focused on speed and small size.
  • The book was definitely worth reading; overall, it’s well written, and appropriate for its target audience.
  • The concurrency method used (messaging with publish/subscribe) looks similar to the now-trendy actor approach (used in Erlang, Scala, etc).
  • Not a good fit overall for my current project, but I think I will be able to use some concepts from the book.
  • This book, and others such as Functional Programming in C#, show a great strength of general purpose “traditional” languages such as C, C++, and C#: you can use them with all kinds of different programming styles, including imperative, object oriented, functional, dataflow, and statechart.  Try doing that with ladder logic!
  • Actually, I do wonder how well I could implement hierarchical state machines in structured text.  I definitely couldn’t use the more advanced implementations (since they relay on function pointers, which structured text does not have), but it could still be worthwhile.
  • Final note: I love this quote the author chose from Fred Brook’s The Mythical Man Month: “…software structure is not embedded in three-space, so there is no natural mapping from a conceptual design to a diagram, whether in two dimensions or more … one needs multiple diagrams, each conveying some distinct aspect, and some aspects don’t diagram well at all.”  That is why graphical programming is not inherently better than text.

2 comments

1 Sid { 11.01.12 at 7:03 am }

What tools do you use for creating statecharts?
I use the tool Stateflow for drawing and executing the
state machines and flow charts. The tool also contains state transition tables if your need to check what conditions/events the system does _not_ react to.

-Sid

state machines

2 Tony { 11.03.12 at 9:31 am }

Thanks for the feedback.

I suspect most people are using Mathwork’s Stateflow like you are, NI LabView’s state charts (added in V8.2 IIRC), or rolling their own.

I haven’t used a hierarchical state chart in production yet. We have used state machine for some PLC applications (programmed in structured text), but these were simple applications so we used did it manually. Still, it worked much better than traditional ladder logic.

For many of my more complex applications, state charts aren’t the best fit because those apps typically involve heavy data handling and formatting to interface with the customer’s systems.

Leave a Comment