SinelaboreRT

Latest News

webmin@undisclosed.example.com (webmin) — Sun, 15 Mar 2026 19:22:24 +0000

Latest News

March 2026 | New version 7.1

Update for SysMLV2. This version improves the code generation and adds more supported SysMLV2 features. E.g. actions are SysMLV2 first hand features and as such represented as structs in the generated code and not as methods anymore. Checkout the GitHub examples for more details.

November 2025 | New version 7.0

SysML v2 is here — and it’s announced as major leap forward in systems modeling. I've taken a first deep dive into the new modelling language, exploring its strengths, potential, and some early tooling support. The latest version 7.0 supports the generation of CPPX code from a SysML v2 textual model. With the help of a small framework the generated parts and state-machine code can be easily be executed and tested.

July 2025 | SysML v2.0 - First Experiments

We explored the current status of SysML v2. Read more in this article.

February 2025 | New version 6.5.2

This new version is recommended to all users. Core modules were refactored for better maintainability and consistency and improved test coverage. Improved CPPX code generation to eliminate unnecessary dynamic memory allocations.

February 2025 | New version 6.5.1

Beside several improvements support for additional command-line parameters when using ’-l cppx’ was added. You can now optionally specify -std with additional information to enable all necessary parameters for the corresponding language features either for either version 11 or 14. This simplifies configuration for new users. For more details, see section “Generating CPP Code”.

September 2024 | New version 6.4

Since version 6.4 the handling of history states has been changed. It is now possible to end a transition in a history state. Only if a transition ends in a history state will the previous history be taken into account when entering the state set. Otherwise the default entry chain is used. The new parameter TransitionsCanEndInHistoryStates has been added to enable this feature. This new feature makes history state handling more powerful and the designer's intent clearer than before. An example of the new possibilities is shown in the following figure.

August 2024 | New version 6.3.4

This release adds another way to influence the signature of the processEvent() method in C++.

June 2024 | New version 6.3.3

This version provides some small updates for the Python backend and fixes an issue with the C Sharp backend.

18. Feb. 2024 | New version 6.3.2.1

Bugfix in the C++ backend. Relevant for users who have state machines with regions and do not want event handler parameters. With previous version a msg parameter of the region code was generated. In the previous version, a msg parameter was incorrectly generated for the region handler code. This has now been corrected.

18. Feb. 2024 | New version 6.3.2

A state machine with regions can be in more than one state at a time. Previously the getInnermostActiveState() function only returned the topmost state the state machine was in. With this release, some backends can return more states to reflect the real situation.

Improvements in the JS backend. IsIn() and getInnermostActiveStates() works now with regions.
Improvements in the C++11 backend. IsIn() and getInnermostActiveStates() works now with regions (cpp-11 only).

In the case of C++11, the generated function has this signature:

auto oven::getInnermostActiveStates() const -> std::forward_list<oven::States>{
  std::forward_list<oven::States> stateList;
  ...
  return stateList;
}

22. Jan. 2024 | New version 6.3

JavaScript is now supported as new target language for the code generator

20. Nov. 2023 | New version 6.2

Go is now supported as new target language for the code generator

26. Sep. 2023 | New version 6.1

Changes:

Bugfixes and improvements in the built in state-diagram editor
Use of a project specific configuration file in the graphical editor
New C-backend related parameters to generate code following the opaque object pattern (https://en.wikipedia.org/wiki/Opaque_pointer) to hide the state machine implementation from other user code and thereof reduce dependencies.
Improvements in the section about the c-backend and reorganization of the examples folder in the download.

New features:

Experimental parsing for the DrawIO Editor added
Events marked external are now exported in a separate file to allow further external processing. This allows to generate one file containing all state machine events (only with events as defines possible). Designs with a global event bus where all machines always receive all events could benefit from this feature.

12. Aug. 2023 | New version 6.0.5

Experimental support for DrawIO added

29. July 2023 | New version 6.0.4

Small bug-fixes and several improvements in the built-in graphical state diagram editor.

5. July 2023 | New version 6.0.3

Only available as jar download. Small bug-fixes in the built-in graphical state diagram editor as well as small improvements in the C-backend. It is better taking care of C89 only compilers.

3. June 2023 | New version 6.0.2

Several minor improvements especially for the cbackend. With some new configuration parameters, the generated code now passes the clang-tidy checks for c++11 with ''modernise-'' checks enabled. A new example has been added to the examples folder to show how to set the parameters in a sensible way. === 1. March 2023 New version 6.0 === This major release fixes many small issues and adds support for generating code from Eclipse Papyrus™. There is a step by step introduction video available. === 27. Jan 2023 | New version 5.5.6.3515 === This version fixes a bug in handling config files. Recommended for all users. === 21. Jan 2023 | New version 5.5.6.3490 === This version adds many small improvements to the integrated state diagram editor. * Code editor window is not always on top * A larger font in the state diagram used by default. The size can be configured in the configuration file. * Improved layout (larger distance between states) to increase readably of transition texts * The configuration file is now searched locally and then in the users home directory. If the location was given as command line it has always priority. * Display of an error symbol in correct line of the output window in the case when the model check returns an error. * Some IDEs do treat files ending in cfg in a special way. Therefore the codegen configuration file can also be named codegen.cf optionally. * Many more … === Dec 2022 | New version 5.5.5.5 === This new version adds Rust as a language backend. === June 2022 | New version 5.5.5.1 === This new version fixed several issues related to misra 2012 rules. As a result also some recommended parameter settings are published here to get you started. Recommended for all C/C users.

May 2022 | New version 5.5.5

This new version improved region handling for own instance data types. Recommended update for all C backend users. Additionally it improves XMI parsing of attributes and methods for the various supported UML tools.

January 2022 | New version 5.5.4

This new version brings Ctemplate parameters to the event handler method. As well as the option to hand over a user defined parameter to the event handler method in C#. Both increases flexibility to hand over data together with the event to the state machine. === January 2022 New version 5.5.2 === This new version allows to add attributes and operations to EA/UModel class diagrams. They are added to the generated code. An example about the creation of signal forming function blocks shows the new possibilities in detail. For users of the built-in state machine editor and the C-backend a new dialog shows all the configuration parameters and how they influence the signature of the generated state machine handler. === October 2021 | New version 5.4.1 === New Windows/Mac installer (thanks to Java 17) makes life easier for users who are not at ease with the command line. C backend now supports the ValidationCall parameter.

August 2021 | New version 5.3

Several usability improvements, bug fixes and new functions esp. in the built-in editor. Recommended for all users. A detailed change log is available in the Codegen Manual.

Jan.2021 | New version 5.2

. Complete rewritten built-in editor. Generate state diagram within minutes. Editor has full support for regions.

15.02.2020 | New version 4.1

This new version provides a backend for Lua. It is the first state machine code generator from UML state diagrams/machines to Lua. Lua is a lightweight, embeddable scripting language. It follows the approach described by Roberto Ierusalimschy in his book. More information is available here.

17.6.2019 | New version 3.7.4

This is a bug-fix version and recommended for all users. For users of the Cadifra tool connection points were added to keep oversight in complex diagrams more easy. Connection points are a well known concept in circuit diagram drawing tools. More details can be found in the sinelabore manual (Cadifra part).

2.5.2019 | New example for PIC users

This tutorial explains the use of state machines with the PIC16F18446 Curiosity Nano board. Go on reading ...

29.12.2017 | Sparx new EA Version

Tests of new EA version 13 were successful. If you find any flaws using the codegen with the new version send a bug report please.

20.9.2017 | QuickStart tutorial on how to use the code generator with Energia on GitHub

Energia is based on the Arduino IDE and is a great IDE for processors form Texas Instruments. The new example on GitHub shows the integration of code generated from the sinelabore code generator into the Energia IDE. What does the demo do: The flash frequency of the green LED on the MSP430FR5969 LaunchPad can be controlled. A minimal timer and queueing lib is used as basis to be prepared for much more challenging tasks. You will see the benefit of state machine modeling over direct coding. Take a look at the state diagrams and the generated code here! Or download the example and try it out yourself.

9.4.2017 | New version 3.7.1 with some small improvements

Recommended for all C# users and those who use the built in editor/simulator.

6.11.2016 | Code Generator Features for High-Availability and Safety Systems

There is a new article in the “Designers Toolbox” explaining the special features for for High-Availability and Safety Systems offered from the C-backend.

16.10.2016 | Generate Python Code from State Diagrams

With version 3.7 is is now possible to generate Python code. The state machine code is generated as a Python class. All relevant state machine features are available. Look into the manual for details. The fully working microwave oven code is available in the examples folder. It contains a TKinter GUI wich makes simulation and testing of the generated state machine even simpler.

Generating CPP Code from SysML V2 textual models

webmin@undisclosed.example.com (webmin) — Sun, 15 Mar 2026 19:16:03 +0000

Generating CPP Code from SysML V2 textual models

SysML V2 is a newer version of SysML that is more flexible and powerful. An important aspect is that it now allows to write textual models. This lowers the entry barrier to the model based system development a lot becasue no special tools are needed to write the models. E.g. a Visual Studio Code plugin is available to write SysML V2 models. The Sinelabore Code Generator supports code generation from SysML V2 models. In opposite to the current Sinelabore capabilites, the code generation also supports the generation of structural code and not just the generation of state machine code.

This means that also code for parts, interactions between parts and so forth is generated. This can be used to quickly generate mockups and simulations of an intended system.

To generate CPP code from a sysml model call the code generator with the command line flag -l Sysml2Text.

A fully functional example is available on our github site.

Introduction

The present version only supports a small subset of the powerful SysML V2 feature set. Over time more features might be added. Main goal of this first version of the SysML V2 backend is to support a relevant set of features to generate code for state machines and the interaction of statemachines between parts.

To execute the generated code a small header only runtime environment is provided. It contains some base classes and implements inter-part communication via ports and timeout handling. So just the minimum to execute a model.

In case a part contains a state machine the code generatior also generates additional files for the state machine. This code follows the structure that is already used by the cppx backend.

Parts: Parts are the main building blocks of a system. They can contain other parts, attributes, a state machine, actions, enums, connections and ports. Parts are realized as CPP classes in the generated code. If a part contains other parts you are responsible to create them in the init method. Create a subclass of the part class and override the init method. Then call the base class init method. Example:
```
 part def P1{part p2:P3;} 
```
Attributes Parts can have attributes. Attributes can have a base type and a default value. Attributes can contain other attributes. Attributes are translated to CPP member variables. Depending on the type of the attribute it is realized as a basic data type or a class. Example:
```
attribute a:bool;
```
Enums: Basic enums with their enum values can be defined. Enums are directly translated to CPP enums in the generated code. Example:
```
enum def Color{RED; GREEN; BLUE;}
```
Ports: Ports are the way to communication points between parts. The framework has some helper classes to realize ports. A port marked as “in” has a receive method, a port marked as “out” has a send method in the generated CPP code. Example:
```
port def p {attribute x : Integer;}
```
Connections: Connections are the way to connect ports of parts in order to share data. Connections are realized as queues in the generated code. Only ports of the same type can be connected. One part must be marked as “in”, one as “out”. If you need bidirectional communication you can add two other ports in opposite direction. All attributes in a port share the same direction. Example:
```
connect p1.sendPort to p2.recvPort;} 
```
State Machines: A part can have a state machine. State machines are not as expressive as in UML so far, but still powerful. With the help of a TimerManager class in the framework, timed transitions can be realized. Exampel:
```
{state def sm { ... }}
```

The following listing shows an example for a small traffic light control system model. It consists of three parts with some attributes and actions. The TrafficManagementCenter part represents a central control system that can control TrafficLightController parts connected via ports.

In this simple model the TrafficManagementCenter just enables a traffic light controllers to operate by sending a start event. The TrafficLightController then changes state from OutOfService to Operational and performs expected traffic light operations. In a real system this simulation is for sure much more complex. But the example is rich enough to show the available possibilities. The TrafficLightSystem part weaves together the TrafficManagementCenter and the TrafficLightController parts.

private import ScalarValues::*;
 
package TrafficLight {
 
 
    // definition of events to control motor
    enum def TRAFFICLIGHTCONTROLLERSM_EVENT_T {
        //@TrafficLightController
        evOperational;
        evError;
    }
 
    //@TrafficManagementCenter
    enum def TRAFFICMANAGEMENTCENTERSM_EVENT_T {
    }
 
    port def ControlPortData {
        attribute msg : TRAFFICLIGHTCONTROLLERSM_EVENT_T;
        attribute test:Integer;
    }
 
    part def Test{}
 
    // traffic management center
    part def TrafficManagementCenter{
        out port sendPort : ControlPortData;
        part test1 : Test;
 
        state def tmcStateMachine {
            entry; then PreOperational;
 
            state PreOperational;
            accept after 2[SI::second] do send new ControlPortData(TRAFFICLIGHTCONTROLLERSM_EVENT_T::evOperational,5) via sendPort then Operational;
 
            state Operational {
 
            }
 
        }
    }
 
    part def TrafficLightController{
 
        in port recvPort : ~ControlPortData;
        part test1 : Test;
 
        action def setRedLED{}
        action def resetRedLED{}
        action def setYellowLED{}
        action def resetYellowLED{}
        action def setGreenLED{}
        action def resetGreenLED{}
        action def setRedAndYellowLED{}
        action def resetRedAndYellowLED{}
 
        state def tlcStateMachine {
            ...
        }
    }
    // Main system composition
    part def TrafficLightSystem {
        doc /*
        * Main system that contains the parts
        */
        part tmc : TrafficManagementCenter;
        part tlc : TrafficLightController;
 
        // Connect the parts
        connect tmc.sendPort to tlc.recvPort;
    }
}

Adding a State Machine to a Part

A state machine can be added to a part. The following listing shows an example of a state machine definition. Presently the following features are supported which are demonstrated in the following listing.

State machine definition: state def sm { … }
Default state: entry; then statename;
Default state setting extended form: This allows to select the default state based on conditions.
States long form: They can have $entry$, $exit$ and $do$ actions. See state OperationalRed { entry; … } as example.
States short form without details. Just a name must be given.
Transitions short form. This transition can only directly follow a state and allows a short form.
Transitions long form: This transition must have the extended form. An example for this is transition t1 shown in the listing.

/ definition of events
enum def TRAFFICLIGHTCONTROLLERSM_EVENT_T {
    //@TrafficLightController
    evOperational;
    evError;
}
 
state def tlcStateMachine {
    entry; then OutOfService;
 
    state  OutOfService {
        entry; then OutOfServiceYellowOn;
 
        state OutOfServiceYellowOn{
            entry action setYellowLED{}
        }
        accept after 0.5[SI::second] then OutOfServiceYellowOff;
 
        state OutOfServiceYellowOff {
            entry action resetYellowLED{}
        }
        accept after 0.5[SI::second] then OutOfServiceYellowOn;
 
        transition t1 first OutOfService 
            accept TRAFFICLIGHTCONTROLLERSM_EVENT_T::evOperational then Operational;
    }
 
    state Operational {
        entry; then OperationalRed;
 
        state OperationalRed {
            entry action setRedLED{}
            exit action resetRedLED{}
        }
 
        state OperationalRedYellow {
            entry action setRedAndYellowLED{}
            exit action resetRedAndYellowLED{}
        }
 
        state OperationalGreen {
            entry action setGreenLED{}
            exit action resetGreenLED{}
        }
 
        state OperationalYellow {
            entry action setYellowLED{}
            exit action resetYellowLED{}
        }				
 
        transition t1 first OperationalRed  accept after 1[SI::second] 
            then OperationalRedYellow;
        transition t2 first OperationalRedYellow  accept after 1[SI::second] 
            then OperationalGreen;
        transition t3 first OperationalGreen  accept after 1[SI::second] 
            then OperationalYellow;
        transition t4 first OperationalYellow  accept after 1[SI::second] 
            then OperationalRed;
        transition t5 first Operational 
            accept TRAFFICLIGHTCONTROLLERSM_EVENT_T::evError then OutOfService;
 
    }
}

The system including the state machines are then fully generated following the well known SinelaboreRT state machine structure.

Defining Events

It is required to use enums to define events to be processed by the state machine.

It is necessary to add a comment in the enum that starts with

//@. --> example see above

plus the name of the part containing the state machine processing the events.

Transition triggered by Timeouts

A great new feature with SysML V2 is the ability to trigger transitions by timeouts. In UML this was also possible but in much more limited way.

transition t1 first start state  accept after 0.1[SI::second] then next state;

At present the time can only be specified in seconds. If other units are needed you can write e.g. 0.001[SI::second] for 1 millisecond. Each part has by default a TimerManager class that is used to manage the timeouts. The code generator generates the needed entry code to start the timer if the state is entered. Also the exit code is generated to stop the timer when the state is left. A timeout event is added to the event list.

Basic executing a model

It is possible to directly execute the model in a CPP main function. But in most cases you you might want to add own CPP behaviour. Then it is necessary to subclass the generated Part classes and implement the intended business logic and handlers (i.e. methods of the generated part classes). By default a process() and init() method is generated per part.

If needed overwrite these two methods and add your own code. Then call the baseclass method to ensure that the part is initialized correctly. Parts used in a part (i.e. sub-parts) must be created in the init method.

Here is an example for a simple main program:

MyTrafficLightSystem tls;

tls.init();

// Start process thread
for(int i = 0; i < 80; i++) {
   tls.process();
   std::this_thread::sleep_for(std::chrono::milliseconds(100));
}

Executing Model with State Machines

For each state machine, state handling classes are generated (details see section '3.4. Generating C++ Code' in the manual). Set the following parameters in the config file – codegen.cfg otherwise the compiler will fail:

UseEnumBaseTypes=yes
UseStdLibrary = yes
CallInitializeInCtor = no
EnumBaseTypeForEvents = std::int16_t

A state handling method named like the topmost state def of the part is generated.

For ports and timeouts a handler method is added into the generated part class. Overwrite this handler in your derived class and forward the timeout event or the event received in the port to the state machine. Examples for such handlers are as follows:

    void onTimeout(const TLCEvent& e) override{
        std::cout << "[MyTrafficLightController] Timeout fired with id="
            << getNameByEvent(e)<< std::endl;
        // put event to input queue to be able to handle it via sysml code
        recvPort.receive(ControlPortDataDef{e});
        tlcStateMachine();
}

Missing Features

Sysml V2 is a very rich model language. There are many features that are not yet supported by the code generator. The following list is not exhaustive but list some of the not supported features. Take a look at the code on github to see what is used in the code generator and therefore supported.

Regions in state machines
Inner transitions
Attributes can't be qualified by additional keywords like $ordered$ or $unique$
Attributes can't have multiplicity
Referencing, Subsetting, …
Additions features in enums beside basic definition
Other inter part communication features than ports and connections as shown above
The complete model must reside in a single file. It is not supported to split the model into multiple files.
Sysml imports are ignored and no code is generated for them. But it still useful just to satisfy sysmlv2 editors and get rid of error messages.
Many other features not shown in the example code.

Navigation

webmin@undisclosed.example.com (webmin) — Sun, 15 Mar 2026 19:12:18 +0000

Modelling-Tool specific Intro

Generating CPP Code from SysML V2 textual models New!

Language Backends

RTOS/Bare Metal

How-To

Designers Toolbox

Using time triggered events
Using regions or not
High-Availability and Safety Systems
Model-based testing of state machines I
Model-based testing of state machines II
Create nice looking state flow diagrams using Mscgen
Article on www.embedded.com State charts can provide you with software quality insurance.
Tutorial about state machines@bela.io New!

Examples

There are better ways to model state machines than using spread sheets!

In the past different μC manufacturers have published application notes about the benefit of using state machines for the design of embedded software. An example is the application note SLAA402 from Texas Instruments (TI). It suggests to generate source code based on a spread sheet table. Nowadays several affordable UML modeling tools are available supporting the efficient design of state machines in a graphical way. SinelaboreRT generates production quality source code from state diagrams created with many different UML tools. Give it a try!

Latest Changes

Trademarks and Terms of Use

webmin@undisclosed.example.com (webmin) — Sat, 29 Nov 2025 13:13:13 +0000

Trademarks and Terms of Use

I refer to the Contract and License Conditions SINELABORE Software / Vertrags- und Lizenzbedingungen Sinelabore Software, which apply insofar as nothing to the contrary results from the following conditions.

Trademarks

Java is a registered trademark of Sun Microsystems, Inc. in the United States and/or other countries.
Microsoft, Windows Vista, Windows XP, Windows 2000, Windows, Microsoft Word, Word 97 and Word 2003 are trademarks or registered trademarks of Microsoft Corporation.
Cadifra is a registered trademark Adrian & Frank Buehlmann.
Enterprise Architect is a trademark of Sparx Systems Pty Ltd
Magic Draw is a trademark of No Magic, Inc.
UModel is a trademark of Altova GmbH and Altova Inc.
ArgoUML is made available under the BSD Open Source License
UML and Unified Modeling Language are trademarks or registered trademarks of Object Management Group, Inc.
SysML and SysML v2 are trademarks or registered trademarks of OMG Object Management Group, Inc..
Other trademarks or registered trademarks mentioned on this web site are the property of their respective owners and no rights are claimed for these.

Terms of Use, License Agreement

This software and its associated documentation are the intellectual property of Peter Mueller.

This Software is Licensed, not Bought

The licensee obtains the non-exclusive, non-transferable right, to use the software under the conditions given below. The license remains valid for an unlimited period of time.

Storage and Network Use

Each licensed copy of the software may either be used by a single person who uses the software personally on one or more computers, or installed on a single workstation used non-simultaneously by multiple people, but not both. Each licensed copy may be accessed through a network, provided that you have purchased the rights to use a licensed copy for each workstation that will access the software through the network. You may make copies of the Software for backup purpose. The Software may be installed and used on an unlimited number of computers, provided the software is used in evaluation mode (i.e. without the license file). Evaluation mode of the software may only be used for evaluation or demonstration purposes, not for development or production.

No Derivative Works

The licensee agrees not to translate, disassemble, de-compile or in any other way create derivative works of the software.

No Resale

The licensee agrees not to rent, sell, lend, license or otherwise distribute the software to any third party without the prior written consent of Peter Mueller. (However, the licensee is encouraged to recommend the software.)

Limitation of Liability

The software is provided “as is”, without warranty of any kind, express of implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall Peter Mueller or any other contributor be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use of other dealings in the software. In no event shall Peter Mueller‘s liability arising out of the use or inability to use the software exceed the amount that you have actually paid for the software.

General

Place of performance and place of jurisdiction for all disputes arising from and in connection with this contract are the headquarters of Sinelabore Software Tools GmbH.

For questions write to

From design to code with ease - [Generate CPP code from SysML V2 textual models]

webmin@undisclosed.example.com (webmin) — Sat, 29 Nov 2025 13:08:46 +0000

From design to code with ease

Generate production ready source code from state diagrams

Sinelabore enables developers to effectively combine event-driven architecture, hierarchical state machines, model-based design and automatic code generation. A payback is usually given already immediately.

Generate CPP code from SysML V2 textual models

Sinelabore allows also the generation of CPP code on the basis of a SysML V2 textual specification. Code generation for parts, attributes, ports, enums, connections and of course state machines is supported. This allows to specify complete systems in a simple and efficient way and to simulate them on CPP basis. Some basic framework classes are used in addition to provide required glue code.

If you are specifically interested in the new SysML V2 features go on reading here.

What can Sinelabore do for me as an embedded software developer?

SinelaboreRT focus is on generation of readable and maintainable code from flat or hierarchical UML state machine diagrams. With its unique features the tool covers perfectly the requirements of embedded real-time and low-power application developers coding in C / CPP or another language. The generated code is independent of CPU and operating system.

What can Sinelabore do for me as a software developer for the IoT or for critical applications?

Many systems are likely candidates for implementation as finite state machines. A system that must sequence a series of actions or that must handle inputs differently depending on the mode it is in is often best implemented as a finite state machine. Typical examples are control-logic-oriented applications such as metering, monitoring, workflows and control applications. For IoT applications where parts of the application are implemented in Java / Python / C# / Lua / Rust / JavaScript / Go or Swift, the code can also be generated in these languages besides C or CPP.

How do I use the Code-Generator?

Use your existing favourite modelling tool and generate code from your created model with an easy-to-use command line tool. Or use the built editor to create state machines within minutes. Automatic model checks warn from design flaws. Configure the generation process according to your needs. Simulate your model. Generate trace code automatically if needed. All major state diagram features like hierarchical states, regions, history, sub-machines … are supported.

Download & Try it! There are examples for various UML modelling tools and target languages for having a quick start.

Does the Code Generator run on my OS?

The Sinelabore code generator runs on any OS that supports a modern Java Version e.g. Windows, Linux, macOS or from within a container.

Can I use the generated code on my embedded platform?

By generating code that can be compiled with virtually any compiler, and the ability to integrate with your existing IDE, build process or continuous integration system, the code generator can be quickly integrated into any project. Configuration is stored in a plain text file which allows customisation of generated code to exactly your needs.

Generated code has production-quality. It is based on nested switch/case and if/then/else statements. It is easy to read, understand and debug if needed. The generated code requires no compiler specific tricks except standard language features. This means that if the worst comes to the worst, you can easily change or expand the code by hand.
Can be used with any 8-, 16- or 32-bit CPUs. There is no run-time environment needed like with some other solutions.
Fits well in different system designs. The code generator does not dictate how you design your system. Therefore it is no problem to use the generated code in the context of a real-time operating system (VxWorks, FreeRTOS, embOS, RTEMS, …) or within an interrupt service routine or in a foreground / background (super loop) system.
There will be no problems when using static code analyzers.
Generated cpp code passes clang-tidy and is cpp11 ready (modernize-*). Set configuration parameters accordingly.

How Sinelabore Improves Developer Productivity

Avoid bugs that can waste countless hours of developer and end-user time before they are found. Developers spend a lot of their time coding state machines by hand. And have to do it whenever the design changes. Sinelabore avoids the error-prone and tedious hand-coding by generating high-quality source code directly from the state machine design document.

No gap between design and code anymore. The documentation is always up to date.
Use the UML tool of your choice: Cadifra UML Editor, UModel, Magic Draw, Enterprise Architect, Astah* / astah SysML, Visual Paradigm, Modelio
An integrated state diagram editor makes it easy to get started and allows you to create state diagrams within minutes. The entry barrier is significantly lower compared to full-fledged UML tools. A series of tutorials (see sidebar) explains step by step how to use the integrated diagram tool.
Use the code generator only for those parts of your software that benefit from state machine modeling and code generation. Use your existing development environment for all the other code. The code-generator does not dictate an “all or nothing” approach as many other commercial tools.
Automatic robustness tests, test-case generation, tracing and simulation
Extensive Manual with getting started section

Secure, On-site Code Generation

The code generator runs locally on your developer workstations, build servers or continuous integration servers. It does not use an internet connection and will never collect nor submit data, code, statistics, analytics, or any other information from your system over any channel.

Generate code in the shortest time

To get an impression of the powerful capabilities of the tool download the demo version. Checkout the examples folder to see the generated code. Follow the “Getting Started” pages on this website. The manual contains a basic introduction into state-machines in case you need a refresh. Read the sections related to your UML tool and the language backend you want to use. If no UML tool is already in place take a look at the built in state machine diagram editor.

To run the code you have two options.

Run the examples on your PC. The example folder contains examples for all supported modelling tools and various languages (C, CPP, …). The examples realizes a microwave oven and can be executed and tested. Play with the model and enhance it. Regenerate the code and learn from the warning and error messages.
Run examples on a Micro-Controller e.g. a MSP430 evaluation board using Energia. An example with all details is available on github.

Customers and what customers say

Sinelabore Code Generator is used worldwide by companies of all sizes, from well-known multinational organizations to smaller independent companies and consultants. The code generator is also used in a wide range of industries.

“Sinelabore has helped me implement the behavior of a complex, asynchronous system. All the UML 2 elements I needed are available. I like that I don’t have to draw the state machine, then separately implement it and keep these two synchronized; this saves me time and reduces the potential of bugs. The error checking to make sure the state machine is valid is also useful. —- Daniel Bedrenko / Software Developer @ BPS…tec GmbH”

“Thank you again for providing such great tool!”

“… wir nutzen Ihr Produkt schon seit vielen Jahren und es hat sich als zuverlässiges und wertvolles Werkzeug erwiesen …”

“We like Your Tool, infact we will give intro for another local company next week.”

Study done by “Laboratory of Model Driven Engineering for Embedded Systems @ CEA in France” with the title “Complete Code Generation from UML State Machine” write in their report “ … without optimization, Sinelabore generates the smallest executable size ,,,”.

Using State-Machines in (Low-Power) Embedded Systems

Reactive systems are characterized by a continuous interaction with their environment. They typically continuously receive inputs (events) from their environment and − usually within quite a short delay − react on these inputs. Reactive systems can be very well described with the help of state machines. State machines allow to develop an application in an iterative way. States in the state diagram often correspond to states in the application. The resulting model helps to manage the complexity of the application and to discuss it with colleagues from other departments (and domains). Details can be added step by step during the development. Even during creation, the Code Generator can check the state diagrams for consistency (Model Check). Its logic can be simulated and tested. This ensures that the state machine behaves as intended. State machines are very useful for control-oriented applications where attributes such as reliability, code size, power consumption, and real-time behavior are particularly important.

System Architecture

There are different ways how to integrate state machines in a specific system design. Some design principles are more applicable for developers of deeply embedded systems. Others more relevant for developers having not so tight resource constraints.

The SinelaboreRT code generator supports you in the creation of the state based control logic. Generated code fits well in different system designs. The code generator does not dictate 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.

Using state machines in a main-loop

In this design an endless loop — typically the main function — calls one or more state machines after each other. It is still one of the most common ways of designing small embedded systems. The event information processed from the state machines might come from global or local variables fed from other code or IRQ handlers. The benefits of this design are no need for a runtime framework and only little RAM requirements.

The consequences are:

All housekeeping code has to be provided by the designer
Main loop must be fast enough for the overall required response time
In case of extensions the timing must be carefully rechecked again

Example:

void main(void){
  …
  sm_A();
  sm_B();
  …
}

Using state machines in a main loop with event queue

This design is like the one presented above. But the state machine receives its events from an event queue. The queue is filled from timer events, other state machines (cooperating machines) or interrupt handlers.

Benefits:

Events are not lost (queuing)
Event order is preserved
Decoupling of event processing from event generation.

Consequences:

A minimal runtime framework is required: Timers and Queues
Main loop must be fast enough for the overall required response time

A minimal runtime framework for C is available here: https://github.com/sinelabore/examples/tree/master/lib

It offers timers and queues. The intended usage is as follows:

Each state machine has an own event queue
Eventually a state machine requires one or more timers (single shot or cyclically).
A state machine can create as many timers as needed. When creating a timer the event queue of the state machine and the timeout event has to be provided. For different timers it makes sense to provide different timeout events.
To make the timer work, a tick counter variable has to be incremented cyclically from a timer interrupt (e.g., every 10 ms). The tick frequency should be selected based on the minimal required resolution of the timeout times.
A tick() function must be called in the main loop to check if any timer has expired. In case a timeout has happened the provided event is stored in the event queue of the state machine.
The main loop has to check if events are stored for a state machine in its queue. If there are new events they are pulled from the queue and the state machine is called with the event.

Example code with two state machines shows the general principle:

// tick irq
void tick(void){
  pulseCnt++;
}
 
 
void main(void){
  ….
 
  // create two queues for two state machines and init the timer subsystem
  fifoInit(&fifo2VendingMachine, fifo2VendingMachineRawMem, 8);
  fifoInit(&fifo2ProductStoreMachine, fifo2ProductStoreMachineRawMem, 8);
  timerInit();
 
  …
 
  while (1) {
    uint8_t evt;
    //
    // Check if there are new events for the state machine. If yes,
    // call state machine with event.
    //
    bool fifoEmpty = fifoIsEmpty(&fifo2VendingMachine);
    if (!fifoEmpty) {
      fifoGet(&fifo2VendingMachine, &evt);
      vending_machine(&vendingMachine, evt);
    }
 
    fifoEmpty = fifoIsEmpty(&fifo2ProductStoreMachine);
    if (!fifoEmpty) {
      fifoGet(&fifo2ProductStoreMachine, &evt);
      product_store_sm(&productStoreMachine, evt);
    }
 
   // any new timeouts?
   tick();
  }

As indicated in the figure above also other state machines or interrupt handlers might push events to the queue of a state machine. An example how to do this is shown below.

// add event evErr to a state machine queue.
void ISR_Btn1() {
  fifoPut(&fifo2VendingMachine, evErr);
}

Using state machines in a main loop with event queue, optimized for low power consumption

In low power system designs a key design goal is to keep the processor as long as possible in low power mode and only wake it up if something needs to be processed. The design is very similar to the one described above. The main difference is that the main loop runs not all time but only in case an event has happened. The timer service for the small runtime framework is handled in the timer interrupt.

A skeleton for the MSP430 looks as follows:

void main(void){
 
  // init system
 
  while(1) {
 
    // check event queues and run the state machine as shown above
 
     …
     __bis_SR_register(LPM3_bits + GIE);  // Enter low power mode once
     __no_operation();                    // no more events to process
   }
}
 
// Timer A0 interrupt service routine. If the timer 
// function tick() returns true there
// is a timeout and we wakeup the main loop.
#pragma vector=TIMER0_A0_VECTOR
__interrupt void Timer_A0(void)
{
  bool retVal=false;
 
  P1OUT |= BIT0; // toggle for debugging
 
  retVal = tick();
 
  if(retVal){
    // at least one timeout timer fired.
    // wake up main loop
    bic_SR_register_on_exit(LPM3_bits);
  }
  P1OUT &= ~BIT0; // toggle for debugging
  // no more events must be processed
}

The following temperature transmitter using a MSP430F1232 header board with just 256 bytes of RAM and 8K of program memory is based on this design principle. For more information on how to use state-machines in low-power embedded systems see here and here.

Using state machines in interrupts

Sometimes state dependent interrupt handling is required. Then it is useful to embed the state machine directly into the interrupt handler to save every us. Typical usage might be the pre-processing of characters received by a serial interface. Or state dependent filtering of an analog signal before further processing takes place. Using state machines in an interrupt handler can be useful in any system design.

For code generation some considerations are necessary. Usually it is necessary to decorate interrupt handlers with compiler specific keywords or vector information , etc. Furthermore interrupt service handlers have no parameters and no return value. To meet these requirements the Sinelabore code generator offers the parameters StateMachineFunctionPrefixHeader, StateMachineFunctionPrefixCFile and HsmFunctionWithInstanceParameters.

The example below shows an interrupt service routine with the compiler specific extensions as required by mspgcc

// generated state machine code for an irq
 
interrupt (INTERRUPT_VECTOR) IntServiceRoutine(void)
{
   /* generated statemachine code goes here */
}

To generate this code, set the key/value pairs in your configuration file the following way:

StateMachineFunctionPrefixCFile=interrupt (INTERRUPT_VECTOR)
HsmFunctionWithInstanceParameters=no

If the prefix of the interrupt service routine requires to span more than one line the line break ’\n’ character can be inserted as shown below:

StateMachineFunctionPrefixCFile=#pragma vector=UART0TX_VECTOR\n__interrupt void

Prefixes for the header and the C file can be specified separately.

Using state machines with a real-time operating system

In this design each state machine usually runs in the context of an own task. The principle design is shown in the following figure.

Each task executes a state machine (often called active object) in an endless while loop. The tasks wait for new events to be processed from the state machine. In case no event is present the task is set in idle mode from the RTOS. In case one or more new events are available the RTOS wakes up the task. The used RTOS mechanism for event signaling can be different. But often a message queue is used. Events might be stored in the event queue from various sources. E.g. from within another task or from inside an interrupt service routine. This design can be realized with every real-time operating system. Only the event transport mechanisms might differ.

Benefits:

Efficient and well tested runtime environment provided from the real-time operating system
Prioritization of tasks, scheduling available
State machine processing times decoupled from each other.

Consequences:

Need of a real-time operating system (complexity, ram usage, cost …)

In the how-to section an example of this pattern is presented with FreeRTOS. The examples below shows code for the RTEMS and embOS.

Example code for RTEMS

// rtems specific task body
rtems_task oven_task(rtems_task_argument unused)
{
  OVEN_INSTANCEDATA_T inst = OVEN_INSTANCEDATA_INIT;
 
  for ( ; ; ) {
    // returns if one event was processed
    oven(&inst);
  }
}
 
 
// generated state machine code
extern rtems_id Queue_id;
uint8_t msg=NO_MSG;
size_t received;
rtems_status_code status;
 
void   oven(OVEN_INSTANCEDATA_T *instanceVar) {
 
  OVEN_EV_CONSUMED_FLAG_T evConsumed = 0U;
 
 
  /*execute entry code of default state once to init machine */
  if (instanceVar->superEntry == 1U) {
    ovenOff();
 
    instanceVar->superEntry = 0U;
  }
 
  /* action code */
  /* wait for message */
  status = rtems_message_queue_receive(
             Queue_id,
             (void *) &msg,
             &received,
             RTEMS_DEFAULT_OPTIONS,
             RTEMS_NO_TIMEOUT
           );
  if ( status != RTEMS_SUCCESSFUL )
    error_handler();
  }else{
    switch (instanceVar->stateVar) {
      // generated state handling code
     …
    }
  }
}

Example code for embOS RTOS from Segger.

// state machine instance
SM_INSTANCEDATA_T instanceVar = SM_INSTANCEDATA_INIT;
 
// Task and queue objects.
static OS_STACKPTR int Stack_TASK_1[128];   /* Task stacks */
static OS_TASK         TCB_TASK_1;         /* Task-control-blocks */
static OS_Q            MyQueue;
static char            MyQBuffer[100];
 
OS_TIMER MyTimer;
 
char txbuf[32] ;
 
// Routine called from the embOS RTOS to signal 
// a timeout. A timeout event is sent to the state
// machine. Multiple timer callback functions might be created if
// several timers are needed at the same time. Each one then fires an own
// event. E.g. ev50ms or ev100ms
static void MyTimerCallback(void) {
 
    uint8_t msg=evtTimeout;
 
    OS_Q_Put(&MyQueue, &msg, 1);
}
 
// Task blocked until a new event is present. The new event is 
// then sent to the state machine.
static void TaskRunningStateMachine(void) {
    char* pData;
 
    while (1) {
        // waiting for new event
        volatile int Len = OS_Q_GetPtr(&MyQueue, (void**)&pData);
        volatile char msg = *pData;
 
        sm(&instanceVar, (SM_EVENT_T)msg); // call generated state machine with event
 
        OS_Q_Purge(&MyQueue);
 
    }
}

Events versus Boolean Conditions

Sinelabore supports two basic modes of operation. Either the generated state machines react on events. Only if an event is present a transition is taken (e.g. evDoorClosed, evButtonPressed). Events are eventually send to the state machine using an event queue (see above). Alternatively transitions are triggered by boolean conditions. If a boolean condition is true a state change happens (e.g. DI0==true). The latter one is useful if binary signals should be processed like shown in these two designs (signal shaping function blocks)(PLCOpen function block). In this case the state machine runs without receiving a dedicated event. Based on the current state, conditions derived from boolean signals are used to trigger state transitions.