SC-I. Software Design and Statecharts

In this series, we will introduce modern software architecture and advanced design techniques for embedded systems. You’ll learn how to develop reactive, responsive and reliable systems with an industrial-strength application framework. These ideas build the foundation for our projects integrating with various hardware modules such as IMU sensors, WiFi, LCD, etc.

Programming Is Simple

When I first started my career in embedded systems, I was told, “Our job of programming is simple. We just need to instruct the computer to do what we want it to do.”

Obviously, it is an over-simplification. It does, however, bring up a couple interesting questions:

1. Are we certain we know what we want the computer to do? More specifically, is our knowledge complete and free of contradictions?
2. If the answers to the above questions are “yes”, how do we transfer this knowledge to the computer in a precise and straight-forward manner?

Even in the world of AI and machine learning, these questions are still relevant today, especially in the fields of safety-critical and mission-critical systems. Let’s take a deeper look at them.

Design is Hard

Knowledge Representation

The first set of questions are about knowledge representation. They are very tricky since knowledge is very abstract. We do better in reasoning about sequential logic (like if … then, do … while, wait until … etc.) than reasoning about things that can happen in parallel.

The knowledge we are talking about here boils down to system behaviors. Since human minds aren’t very good at reasoning about it, we need a tool to help us, a tool that helps us define behaviors, capture them and visualize them.

It is such a difficult problem that it took a computer scientist to find a solution. It was David Harel who invented statecharts back in late 1980s to solve this exact problem – how to specify system behaviors for embedded systems (a fighter jet in his case). We will look into the rather interesting history behind it later.

Knowledge Mapping

Now let’s address the second question – how do we transfer our knowledge to a computer in a precise and straight-forward manner? The short answer is of course by programming. However as anyone with some programming experience can tell, if you simply program your sequential thoughts into code, it won’t take long for your program to evolve into a messy ball of spaghetti. This is a mapping problem. We need an effective tool to map system behaviors (specification or knowledge) into executable code. Traditional CASE tools and code generators have existed as long as statecharts, but they have been very expensive. It is not until the advent of Quantum Framework/Platform by Miro Samek in 2000 that made it truly affordable and practical to everyone.

Today, statechart frameworks are available to almost every computer language, including:

1. YAKINDU Statechart Tools
2. google/statechart: C++ StateChart Library
3. The Boost Statechart Library
4. Qt SCXML
5. jp-embedded/scxmlcc
6. xstate (Javascript)
7. miros (Python)

QP remains a top candidate for embedded systems due to its small size, performance and few dependencies.

Software Design

Now we attempt to answer the question of “What is software design?” It is:

1. A complete and precise specification of system behaviors that fulfills the requirements. We call it the behavioral model which is the representation of our knowledge about what the system is required to do. Statecharts are simple yet powerful tools that help us achieve this.
2. A software architecture that supports the execution of the behavioral model. Quantum Platform (QP) is one of such tools that help developers map or translate statecharts to C/C++ code effectively.

A Story of Statecharts

There are no better stories about statecharts than being told by the inventor David Harel in his reflection paper:

Statecharts in the Making: A Personal Account [HAREL07]

The original publication on statecharts can be found here:

Statecharts: a visual formalism for complex systems [HAREL87]

It was 40 years ago when the story began in 1982. It is amazing that after 40 years many observations made at that time are still vividly true today. Here are some of the notable quotes from the reflection paper [HAREL07]:

“The aspect that dominates such a system [an avionics system] is its reactivity; its event-driven, control-driven, event-response nature, often including strict time constraints, and often exhibiting a great deal of parallelism. A typical reactive system is not particularly data intensive or calculation-intensive. So what is/was the problem with such systems? In a nutshell, it is the need to provide a clear yet precise description of what the system does, or should do. Specifying its behavior is the real issue.“

“…someone, eventually, would make a decision about what happens when you press a certain button under a certain set of circumstances. However, that person might very well turn out to be a low-level programmer whose task it was to write some code for some procedure, and who inadvertently was making decisions that influenced crucial behavior on a much higher level.”

“…having come from a slightly more mathematically rigorous background, making it somewhat more difficult for them to convince me that a two-volume, 2000 page document, written in structured natural language, was a complete, comprehensive and consistent specification of the system’s behavior.“

It was towards this background that statecharts emerged in 1983 as a “structured and hierarchical extension of the conventional state machine formalism“. The goal was simple, just “to find a way to help take the information that was present collectively in their [engineers’] heads and put it on paper, so to speak, in a fashion that was both well organized and accurate.”

A Story of QP

While statecharts solve the first problem, that is the need for “a complete and precise specification of system behaviors (model)”, we still need to tackle the second problem, that is the need for “a software architecture that supports the execution of the model”.

Quantum Platform is one of such tool that works particular well for embedded systems since it’s very light-weight and efficient. This is a short story of its evolution.

1. Miro Samek published his article “State-Oriented Programming” in Embedded System Programming in August 2000. (State-Oriented Programming, 8/2000)
2. In 2002 he published the first edition of his book “Practical Statecharts in C/C++”. The 2nd edition came out in 2008. (Practical UML Statecharts in C/C++, 2nd Ed.)
3. He later formed his company Quantum Leaps with a wide customer base.

QP follows the dual-licensing model (GPL and commercial), with GPL exceptions granted to Raspberry Pi/Arduino/mbed-enabled boards. Check out its website for latest licensing terms. (Licensing and Pricing)

Initially QP was called QF (Quantum Framework) and only provides an event processor and event framework. Later he added a real-time kernel called QK and its extension called QXK. The package as a whole is called QP.

QP is a very active project and is constantly updated to fix bugs and add support to new hardware platforms such as the Cortex-M7. It has ports to many RTOS including uCOS-II and FreeRTOS.