A state machine diagram (or state chart) shows the dynamic behaviour of an application. It is a graph of states and transitions that describe the response to events depending on the current state that it is in. State machines are used for decades in hardware design. And during the last years also more and more in the area of software development. Especially in the embedded real-time domain the use of statecharts is popular because the behavior of applications and/or devices in this domain can be often described very well with statecharts. The paper of D. Harel „Statecharts: A Visual Formalism for Complex Systems“ published in 1987 is still a must read.

An important aspect of state diagrams is that the design can be directly transformed into executable code. This means that there is no break between the design and the implementation. This is all the more important if the device under development has to be developed e.g. according to IEC61508. Please note that the code-generator itself is not certified in any way. It is your responsibility to verify and validate that the generated code fulfills your needs!

SinelaboreRT was built especially for embedded real-time developers. It focuses on just one task: code generation from state diagrams. A command line tool and a configuration file is all what is needed.

The generated code is based on nested switch/case and if/then/else statements. It is easy to read and understand. The generated code will not create any headache when using static code analyzers.

SinelaboreRT does not force you in any way on how you design your system. Therefore it is no problem to use the generated code in the context of a real-time operating system or within an interrupt service routine or in a foreground / background system. The generation process can be influenced to meet specific needs.

How does SinelaboreRT work? From a state-chart design file created with the Cadifra UML editor, Enterprise Architect, UModel or Magic Draw the code-generator generates the complete statemachine implementation. For an example design file called oven.cdd the command line looks like

java -cp "path_to_coden_jar:*" codegen.Main -p CADIFRA -o oven oven.cdd 

As an result files will be generated:

• oven.c implements the state-machine as graphically specified in the oven.cdd file
• oven_ext.h defines the events that can be sent to the state-machine
• oven_dbg.h defines functions to support you during debugging
• oven.h defines the function prototypes, states etc. used in the state-machine.

These files realize the complete state machine. They are in clearly readable target language code and can be understood and verified by every C/C++ programmer.

Hierarchical state definition: State machines can be hierarchical or flat. A state with sub-states is called a hierarchical state-machine. States can have entry code that is always executed if a state is entered. Exit code is executed whenever the state is left. A state can also have action code. The action code is executed whenever the state is active just before event transitions are evaluated.

Regions : Regions allow to model parallel behavior within the same state machine diagram. The benefit of using regions is to explicitly show the this parallel behavior instead of creating different state diagrams.

Transitions: There are two types of transitions a) event based ones and b) conditional ones. Event based transitions are triggers coming from the outside of a state-machine. An event based transition has the following syntax: eventName[guardExpression]/action. A conditional (or when) transition is not triggered from an event but a C expression that is evaluated to true (e.g. port pin set). It has the syntax: #condition/action.

Choices: The OMG UML specification states: …choice vertices which, when reached, result in the dynamic evaluation of the guards of the triggers of its outgoing transitions. This realizes a dynamic conditional branch. It enables splitting of transitions into multiple outgoing paths such that the decision on which path to take may be a function of the results of prior actions performed in the same run-to-completion step.

History States: When leaving a hierarchical state and entering it the next time the default state us usually entered. If the last active state should be entered instead a shallow history marker can be placed in the state. If you want to activate the history for all sub-states of the state then use the deep history marker instead. Macros are provided to reset the history if needed.

Interactive Test and Simulation: If the command line flag -s (for simulation) is used, the code generator turns into interactive mode after parsing the input file. No code is produced then. After parsing the input file you can type in events and check what the state machine’s reaction is. During a simulation step all code that is executed as the reaction to an event is printed out (e.g. the OnEntry code). When using the command line flag -S the graphical simulation is started.

Debugging / Trace Support: In the *_dbg.h file two helper functions are provided that are useful for debugging state machines. The function *_GetNameByState(id) returns the name of the state the function *_GetNameByEvent(id) returns the name of an event each identified by its id. Trace statements can be automatically added to the machine. This allows to follow the flow of events.

Integrated State-Diagram Editor: Using the command line flag -E brings up the integrated state diagram editor. It provides an efficient tree based entry method. The graphical representation is created automatically. So you can fully focus on the modeling task. For Windows and Mac, instead of the Jar file, Exe files are also provided, which directly launch the integrated editor.

Download the trial version and test the generator.