Researching, prototyping, and putting our ideas into code, aside from the day-to-day business, is an essential part of itemis' company culture. -YAKINDU Labs is a collection of projects that are currently in beta phase and therefore not yet released with any YAKINDU product bundles. +CREATE Labs is a collection of projects that are currently in beta phase and therefore not yet released with any CREATE product bundles. As we love early feedback, we regularly blog about what's going on behind the scenes. So try it, and get in touch with us!
-This repository hosts the following YAKINDU Statechart Tools features: +
This repository hosts the following Itemis CREATE features:
- This is a simple example of how to use the C/C++ Domain together with an Arduino. C++ Timer are integrated. - The underlying statechart looks as follows: -
-
-
All Arduino examples can be compiled via command line or be imported into the Arduino IDE. An easier way is using the Sloeber plugin , which allows you to compile and upload the code directly in Statechart Tools. -
- There are two ways of how to install the plugin. The easiest way is using our example wizard, which allows you installing required plugins. Just follow the built-in instructions. -
-- Another way is installing the plugin manually. You need to follow these steps: -
- After the installation you should notice a new Toolbar, which allows you to compile and flash your Arduino. - Initially, the projects are not configured, as you may require to add the toolchain: -
- Finally, you can use the green toolbar for compiling and flashing the Arduino. Have fun! -
-This example demonstrates how to generate C code for a multi state machine scenario and how to set everything up in the application code. As example, we will use a light controller that controls two lights. The controller as well as the lights are defined by state machines that communicate with each other by the means of events.
-- You can find more information on using the multi state machine feature in the online - documentation. -
-- The example application consists of two state machines, one for the controller, and one that describes a simple light switch. -
-
- 
-
- The light switch model simply consists of two states, On and Off, and respectively two incoming events on and off. Each time the event on is received, the brightness is increased until a maximum brightness is reached. Whenever the brightness changes, the outgoing event brightness_changed is raised with the new brightness value. Both, the incoming and outgoing events, are used in the controller machine to control two different lights.
-
- 
-
- Let's first take a look at the definition section. The controller machine declares two variables light1 and light2 of type Light which represents the light state machine above. When the controller machine is entered, also these two light machines are entered. In addition, they get initialized with different maximum brightness values.
-
- 
-
- The state machine basically describes two modes, a regular one in which the switch_on event is just passed on to both light machines, and a blink mode in which the lights' on events are raised periodically. In this mode, both lights' brightness will be automatically increased until its maximum where it starts from zero again. In order to notice when the maximum brightness of a light is reached, the BlinkMode state reacts to the light machines' brightness_changed events and reads the transmitted value.
-
- The generator model simply defines the configuration for both state machines. As the state machines use time events, we ensure that a timer service implementation is generated with the TimerService parameter.
-
- -
- - -- Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. -
- -
- Our application is a simple interactive console with which the user can switch the lights on or off as well as toggle the blink mode. The complete application code is implemented in main.c:
-
- -
-
- The most important parts are commented in the main.c file. These are the bullet points:
-
- You can run the application with Run As -> Local C/C++ Application on the main.c file. A console should open and ask you for input like in the screenshot below.
-
- 
-
This example demonstrates how to generate C++ code for a multi state machine scenario and how to set everything up in the application code. As example, we will use a light controller that controls two lights. The controller as well as the lights are defined by state machines that communicate with each other by the means of events.
-- You can find more information on using the multi state machine feature in the online - documentation. -
-- The example application consists of two state machines, one for the controller, and one that describes a simple light switch. -
-
-
-
- The light switch model simply consists of two states, On and Off, and respectively two incoming events on and off. Each time the event on is received, the brightness is increased until a maximum brightness is reached. Whenever the brightness changes, the outgoing event brightness_changed is raised with the new brightness value. Both, the incoming and outgoing events, are used in the controller machine to control two different lights.
-
-
-
- Let's first take a look at the definition section. The controller machine declares two variables light1 and light2 of type Light which represents the light state machine above. When the controller machine is entered, also these two light machines are entered. In addition, they get initialized with different maximum brightness values.
-
-
-
- The state machine basically describes two modes, a regular one in which the switch_on event is just passed on to both light machines, and a blink mode in which the lights' on events are raised periodically. In this mode, both lights' brightness will be automatically increased until its maximum where it starts from zero again. In order to notice when the maximum brightness of a light is reached, the BlinkMode state reacts to the light machines' brightness_changed events and reads the transmitted value.
-
- The generator model simply defines the configuration for both state machines. As the state machines use time events, we ensure that a timer service implementation is generated with the TimerService parameter.
-
- -
- - -- Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. -
- -
- Our application is a simple interactive console with which the user can switch the lights on or off as well as toggle the blink mode. The complete application code is implemented in main.cpp:
-
- -
-
- The most important parts are commented in the main.cpp file. These are the bullet points:
-
- You can run the application with Run As -> Local C/C++ Application on the main.cpp file. A console should open and ask you for input like in the screenshot below.
-
-
-
This example demonstrates how to generate Java code for a multi state machine scenario and how to set everything up in the application code. As example, we will use a light controller that controls two lights. The controller as well as the lights are defined by state machines that communicate with each other by the means of events.
-- You can find more information on using the multi state machine feature in the online - documentation. -
-- The example application consists of two state machines, one for the controller, and one that describes a simple light switch. -
-
-
-
- The light switch model simply consists of two states, On and Off, and respectively two incoming events on and off. Each time the event on is received, the brightness is increased until a maximum brightness is reached. Whenever the brightness changes, the outgoing event brightness_changed is raised with the new brightness value. Both, the incoming and outgoing events, are used in the controller machine to control two different lights.
-
-
-
- Let's first take a look at the definition section. The controller machine declares two variables light1 and light2 of type Light which represents the light state machine above. When the controller machine is entered, also these two light machines are entered. In addition, they get initialized with different maximum brightness values.
-
-
-
- The state machine basically describes two modes, a regular one in which the switch_on event is just passed on to both light machines, and a blink mode in which the lights' on events are raised periodically. In this mode, both lights' brightness will be automatically increased until its maximum where it starts from zero again. In order to notice when the maximum brightness of a light is reached, the BlinkMode state reacts to the light machines' brightness_changed events and reads the transmitted value.
-
- The generator model simply defines the configuration for both state machines. As the state machines use time events, we ensure that a timer service implementation is generated with the TimerService parameter.
-
- -
- - -- Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. -
- -
- Our application is a simple interactive console with which the user can switch the lights on or off as well as toggle the blink mode. The complete application code is implemented in Main.java:
-
- -
-
- The most important parts are commented in the Main.java file. These are the bullet points:
-
- You can run the application with Run As -> Java Application on the Main.java file. A console should open and ask you for input like in the screenshot below.
-
-
-
This example demonstrates how to generate Python code for a multi state machine scenario and how to set everything up in the application code. As example, we will use a light controller that controls two lights. The controller as well as the lights are defined by state machines that communicate with each other by the means of events.
-- You can find more information on using the multi state machine feature in the online - documentation. -
-- The example application consists of two state machines, one for the controller, and one that describes a simple light switch. -
-
-
-
- The light switch model simply consists of two states, On and Off, and respectively two incoming events on and off. Each time the event on is received, the brightness is increased until a maximum brightness is reached. Whenever the brightness changes, the outgoing event brightness_changed is raised with the new brightness value. Both, the incoming and outgoing events, are used in the controller machine to control two different lights.
-
-
-
- Let's first take a look at the definition section. The controller machine declares two variables light1 and light2 of type Light which represents the light state machine above. When the controller machine is entered, also these two light machines are entered. In addition, they get initialized with different maximum brightness values.
-
-
-
- The state machine basically describes two modes, a regular one in which the switch_on event is just passed on to both light machines, and a blink mode in which the lights' on events are raised periodically. In this mode, both lights' brightness will be automatically increased until its maximum where it starts from zero again. In order to notice when the maximum brightness of a light is reached, the BlinkMode state reacts to the light machines' brightness_changed events and reads the transmitted value.
-
- The generator model simply defines the configuration for both state machines. As the state machines use time events, we ensure that a timer service implementation is generated with the TimerService parameter.
-
- -
- - -- Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. -
- -
- Our application is a simple interactive console with which the user can switch the lights on or off as well as toggle the blink mode. The complete application code is implemented in main.py:
-
- -
-
- The most important parts are commented in the main.py file. These are the bullet points:
-
- You can run the application with Run As -> Python Run on the main.py file. A console should open and ask you for input like in the screenshot below.
-
-
-
- This is a comprehensive example for the deep integration of YAKINDU - statecharts with manually written C code. The example is implemented as a - simple command line tool. It makes use of POSIX threads. So you need a - compiler tool chain and a 'pthread' library to build an run the example. - The underlying statechart for the coffee machine looks as follows:
The source code artifacts are all located in the 'src' folder. File - names that include 'coffee' or 'cm_' include application specific - implementations and those with 'sc_' prefix are generic parts that belong - to the state machine infrastructure.
-As mentioned above you need a compiler tool chain and the 'pthread' - libraries. If you have a Linux or Mac OS Xsystem you likely have - everything installed. If you run Windows than we propose to install cygwin - tools (https://www.cygwin.com).
-This project is preconfigured for Windows with cygwin. If you use - another system: -
... and your project should be ready to build.
--
In the 'Debug' or 'Release' folder you will find an executable - 'coffee_machine_pro.exe' (even on Linux and Mac OS X). Right-click on this - and choose: -
- The embedded Eclipse console shows up and you can follow the instructions.
- Enter 'o' to start the coffee machine...
-
Additionally you can simulate the statechart by right-click and - choose: -
- You'll find more information on using the simulation in the help. -
-
- You may want to change or extend the model. Within the embedded expression
- editor you can press 'Ctrl-Space' to get proposals, which also include the
- C elements from the imported C header files. 
-
If you have changed the model you can generate state machine code by - right-click on 'CoffeeMachine.sgen' and choose 'Generate Code Artefacts'. - This will generate:
-- This is a example for the deep C++ integration of YAKINDU - statecharts. It shows how C++ classes can be used as variables and is based on the C example:
Imported classes can be referenced by declaring a variable and using the - class as the type of it. - Within the example two classes are referenced: -
- The declared variables can be used and changed in the simulation view.
If you have changed the model you can generate state machine code by - right-click on 'CoffeeMachine.sgen' and choose 'Generate Code Artefacts'. - This will generate:
-
- 
-
This tutorial contains three parts:
-1. Installing the YAKINDU Statechart Tool as a Plugin into Texas - Instruments Code Composer Studio
-2. Adding state machines to the project
-3. Creating the Blinky example with the Professional Edition
-The whole tutorial gives you step-by-step instructions to enable you - to upload the project.
- -First, you need to install TIs Code Composer Studio, which you can - find here:
- -- Ensure you have at least chosen the MSP430 ultra-low power MCUs. - -
-- Open your CCS after installation. You can choose a test example of TI to - ensure that you are connected to the launchpad and that you can compile - and upload Code. After this little test, you can install the plugin. - Therefore, open the Help tab and click on Install New - Software... -
-
- 
-
There you can install Yakindu. You need two update sites for this.
-- First you need to add the update site of Eclipse Neon to allow Yakindu - Statechart Tools to find Xtext plugins. Click on Add and paste to add Eclipse Neon - to your repository. You do not need to install anything, the update site - just needs to be set. -
-
- 
-
- After this, you need to get the download site of YAKINDU Statechart Tools. - Go to - our download site and complete the free registration, in case you have - not done this already. Then you will get a number of different - installation options. Choose the black button with install from - update site. -
-
- 
-
- Once again, go over to install new software. There you add the URL - you copied from our site. Choose at least the YAKINDU Statechart - Tools Professional Edition. You will get a trial version, which lasts - for 30 days. Don’t hesitate, our aren’t buying anything. If the time - expired, you can still use all free Standard Edition features. -
-
- 
-
- Start the installation by clicking on Next and follow the - instructions. The installation wizard asks if you really want to install - the software. Click on Ok. After a successful installation CCS - needs to be restarted. Afterwards, the installation is finished. -
- -
- To use state machines proceed as normal and create a new CCS Project. Open
- the File tab, open New, click on Other and search for
- Code Composer Studio. There you can choose a CCS Project.
- Define a project name, choose your microcontroller and create a empty
- project, which contains an empty main.c file. I used the
- MSP430G2553
- .
-
Now you can start working with state machines!
- -- Right click the project, open New and choose a C Statechart Model. - A Wizard will be opened in which you can select your project and name your - statechart. For example, call it “blinkyStateMachine.sctâ€. -
-
- 
-
- The Statechart model will appear in the project folder after clicking on Finish. - Click on Yes if you are asked to change the perspective. -
-
- Now you can import the header file to your state machine. Open the C
- Statechart Model and add “
- import: msp430g2553.h
- â€. This can also be done with code completion (STRG + Space). If
- the file was not found, try to refresh and clean your project. Your
- project should look like this, without any errors markers:
-
- 
-
The goal is to create a project in which the red LED gets initialized - and toggles every 1 second. Additionally the WDT is used for the state - machine's clock.
-- To do so, rename the “StateA†to “Initialization†and add - two new states named “redOn†and “redOff†to the main - region. Add the “always†and the two “after 1 s†- transitions, as shown in the picture. -
-
- 
-
Then you can easily copy the code here, or you enter it on your own. - Once again the code completion can be used. See how you can simply use all - the defines from the imported header files? This really simplifies - everything.
-- Initialization: entry / WDTCTL = WDT_MDLY_32; IE1 |= WDTIE; P1DIR - |= BIT0 -
-- redOn: entry / P1OUT |= BIT0 -
-- redOff: entry / P1OUT &= ~BIT0 -
-Now the C Statechart Model is finished and should look like in this - picture. After a rebuild a no error markers should appear.
-
- 
-
- Now it is time to generate the C-Code. Therefore, a generator model - (.sgen) must be added. Right click the project once again and open New - and click on Code Generator Model. Choose a name for the sgen file. - It is good practice to stay with the state machine name. Call it "blinkyStateMachine.sgen" - for example and click on Next. Choose the desired state machine by - clicking on the checkbox. Ensure that you have chosen the YAKINDU - SCT C Code Generator and click on Finish. -
-
- 
-
Build the project. The folders src and src-gen should appear in your - project. They include the generated C-Code, which will be automatically be - updated when you edit and save the statechart.
-Because this statechart uses time based events, a timer service needs - to be implemented. To prepare this, you need these two files:
-- sc_timer_service.c -
-- sc_timer_service.h -
-- You can get them from GitHub, - but they are already included in this example. -
-Your project folder now should look like this:
-
- 
-
- Now you need to set the compiler. Therefore, right click your Project and - open the Properties view. Then go to Build -> Advanced - Options -> Language Options and choose Compile program in ANSI - C99 mode. (--c99) as the C Dialect. -
-
- 
-
Finally the state machine can be used in your main function. First - you have to include the state machine and the timer service. Then the - state machine, the timer service and the required functions for the timer - service must be declared and defined. The main function contains two - parts. The initialization and enter function of the state machine and the - initialization of the timer. The second part is an endless loop - the - while(1) loop. Within this loop the run cycle function of the state - machine is called. Afterwards the MSP430 will be set into the Low Power - Mode 0 and the General Interrupt Enable bit gets set. Now the - microcontroller is sleeping and waits for an interrupt. After the - interrupt of the WDT, the timer will proceed. This means that every timer - gets updated and the elapsed time gets incremented by 32 - the time in - milliseconds, which is proceed after every interrupt of the WDT.
-- The main.c file is included in the example. -
- -Hopefully this tutorial helped you to successfully create a project - for your MSP430. Now it's time to implement your own ideas!
- -The following tools were used in the creation of this tutorial:
-System: Windows 10
-YAKINDU Statechart Tool Version: 2.9.3
-Code Composer Version: 7.0.0.00043
-- Note: The MSP430G2 Launchpad does not support Linux. -
- -Code Composer Studio V6 is based Eclipse Mars (4.5.) and Java 7. - Installing and running YAKINDU Statechart Tools within CCSV6 requires two steps:
-1st: Use the Mars update site instead of the Neon update site, which you can find here. As I mentioned - before, you do not need to install anything of the Mars update site. Just add the update site. - After this you are able to install YAKINDU Statechart Tools within CCS V6 as described before. - You need to get the download site of YAKINDU Statechart Tools. - Go to - our download site and complete the free registration, in case you have - not done this already. Then you will get a number of different - installation options. Choose the black button with install from - update site.
-2nd: YAKINDU Statechart Tools has been added, but it won't be executed, - because Java 8 is missing. Therefore, if you don't already have, install a 32 bit version of Java 8. - Afterwards, right click your CCS V6 shortcut and add the path of the 32 bit Java 8. - For my machine it looks like this:
-- C:\ti2\ccsv6\eclipse\ccstudio.exe -vm "C:\Program Files (x86)\Java\jre1.8.0_141\bin" -
- 
- This is an example for the integration of YAKINDU Statechart Tools with another IDE, here the STM32CubeIDE. - The example model makes use of the deep C integration to directly call functions from the HAL headers in the - statechart model: -
-
- This simple state machine consists of two states in which the LEDs are controlled. The initialization has - been done with the integrated CubeMX tool. -
- -- As already mentioned, the configuration of the STM32F407VG has been realized with the CubeMX tool. The - configuration can be adapted in the '.ioc' file. For this, a full installation of the STM32CubeIDE is - required. You can find it HERE. -
-- After downloading and installing the STM32CubeIDE, YAKINDU Statechart Tools Professional Edition must - installed via the update - site. You can follow these STEPS. -
-- In this example the configuration is quite simple. Four pins, which are connected to the four mounted LEDs, - are configured as ouputs. The clock is set to it's maximum of 168 MHz and the timer TIM5 works in interrupt - mode, creating an interrupt every 1 ms, which is later on used for the timer. -
- /* USER CODE BEGIN 2 */
- HAL_TIM_Base_Start_IT(&htim5);
- sc_timer_service_init(&timer_service, timers, MAX_TIMERS, (sc_raise_time_event_fp)
- &blinky_raise_time_event);
- blinky_init(&sm);
- blinky_enter(&sm);
- /* USER CODE END 2 */
-
- - Additionally, the callback for the interrupt must be implemented, which is used to trigger the timer - periodically: -
-
- /* USER CODE BEGIN 4 */
- void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef* htim) {
- if(htim->Instance == htim5.Instance) {
- sc_timer_service_proceed(&timer_service, TICK_MS);
- }
- }
-
- void blinky_set_timer(Blinky* handle, const sc_eventid evid, const sc_integer time_ms, const sc_boolean
- periodic){
- sc_timer_start(&timer_service, (void*) handle, evid, time_ms, periodic);
- }
-
- void blinky_unset_timer(Blinky* handle, const sc_eventid evid){
- sc_timer_cancel(&timer_service, evid);
- (void) handle;
- }
-
- /* USER CODE END 4 */
-
- - This is an example for the integration of YAKINDU Statechart Tools with another IDE, here the - STM32CubeIDE. - The example model demonstrates the usage of the multi state machines feature together with the - deep C - integration to directly call functions from the HAL headers in the statechart model. -
-- Additionally, there are significant benefits using multi state machines. Statecharts designed as - configurable components can be reused for various applications. Reusing statecharts, which are - already tested and in use, can significantly increase the application's quality. Moreover, changes must be - handled only at one model, which allows adding new features and bug fixes to multiple applications at once. -
-
- This simple state machine consists of two states which control one LED, as defined by the pin - and port variables. This LED state machine will be used as a submachine. Its configurable parameters will be - set from the calling state machine (see below). This allows the user to change the port and pin easily. -
-
- - The controller declares the submachines as variables. Each LED (green, orange, red, blue) will be - paramaterized by setting their port and pin. After this, the submachines are entered. From now on the - controller can simply raise the events (on, off, toggle) on the submachines. -
- -- The configuration of the STM32F407VG has been realized with the CubeMX tool. The - configuration can be adapted in the '.ioc' file. For this, a full installation of the STM32CubeIDE is - required. You can find it HERE. -
-- After downloading and installing the STM32CubeIDE, YAKINDU Statechart Tools Professional Edition must - installed via the update - site. You can follow these STEPS. -
-- In this example the configuration is quite simple. Four pins, which are connected to the four mounted LEDs, - are configured as ouputs. The clock is set to its maximum of 168 MHz and the timer TIM5 works in interrupt - mode, creating an interrupt every 1 ms, which is later on used for the timer. -
This example demonstrates the two different execution schemes of CREATE statecharts: event-driven and cycle-based execution. For more details, please refer to chapter Execution schemes in our documentation.
+ +The state machine can define one of two different execution schemes:
+
+You can select the execution scheme in the definition section by either using the @CycleBased or @EventDriven annotation. If nothing is specified, the cycle-based execution scheme with a time interval of 200 milliseconds is used for simulation.
+
+In the following, the difference between the two execution schemes will be explained on a simple example model. +
+ +
+In the cycle-based execution scheme, a run-to-completion step is processed in regular time intervals. For example, the annotation @CycleBased(2000) means that a cycle is invoked every 2000 milliseconds. In the example below, this means that it might take up to two seconds after the input event has been raised for the statechart to process it and activate StateB. Same holds for time events. To illustrate this, StateC has two outgoing transitions with different time triggers. With a cycle period of 2 seconds, both time triggers are valid. The state machine will then take the higher prioritized transition, which in this case is the one to StateE. Changing the cycle period from 2000 to 200 milliseconds will cause StateD to be activated as the run-to-completion cycle is executed before the 500ms trigger is raised.
+
+ 
+
+Please note that it is the responsibility of the client code to implement the cycle loop. The generated state machine code provides a runCycle() method that needs to be called periodically.
+
+In the event-driven execution scheme, incoming events and time events are processed immediately. Consequently, when raising the input event, the statechart instantly activates StateB. StateC is activated after 200 milliseconds and similarly, the state machine always finishes in StateD.
+
+ 
+
+Please note that in contrast to the cycle based execution scheme, the client code does not need to invoke the runCycle() method. This is handled internally when a raiseEvent() method is called.
+
+Both execution schemes also imply a different semantic when orthogonal regions are used. Please check out our example on orthogonal states for more information. +
+This example demonstrates the usage of hierarchies in statecharts. It explains the concepts of composite states and subdiagrams.
+ +Let's revisit the light switch example of the Basic Tutorial. To be more concrete, let's start at the point where our light switch can be in one of three possible modes: +
+ As each mode may be reflected in multiple states, switching between the different modes requires the modeling of many transitions. The following example shows one possible solution without using any means of hierarchies: +
+
+ 
+
Although the statechart consists of only five states, it is difficult to understand the underlying behavior because of the relatively high number of transitions. Consider the states TwilightDetectionMode and TwilightDetected. Both states have an outgoing transition to MotionDetectionMode with the same trigger. Same holds for all four automatic mode states, which have an identical transition to the ManualMode state.
+Having multiple states with an identical transition to the same target state is an indicator for the potential to group these states into one composite state.
+ ++ A composite state is a state that contains one or more other substates. It can be used to group states into logical compounds and thus make the statechart more comprehensible. Having one outgoing transition from a composite state is semantically the same as having outgoing transitions from each of the composite's substates. In that way, a composite stay can drastically reduce the number of transitions in the statechart and hence improve readability. +
++ Let's introduce composite states to our light switch example: +
+
+ 
+
+ Compare the model with the one above. We introduced two composite states to logically group the states by the respective light switch modes. In that way we could reduce a number of transitions without changing the model's behavior. +
++ There are multiple ways to create a composite state: +
+ We can go one step further and create a further layer of hierarchy by grouping the two composite states into another composite state. In that way we can create multiple layers of hierarchy. +
+
+ 
+
+ Using composite states is a great way to make your statechart more comprehensible. However, as your statechart becomes bigger you might want to hide the details and only focus on the higher level relationships without loosing the semantic of your statechart. Subdiagrams come as a solution here. +
++ When the Extract Subdiagram refactoring is executed on a composite state, all containing regions are extracted into a separate diagram. The composite state no longer clutters the diagram with all its internal details, but instead appears almost like a normal state. The only difference is a small decorator icon in the lower-right corner of the state, indicating the existence of a subdiagram. When you hover over this decorator with the mouse cursor, you’ll see a small preview of the subdiagram’s content. +
+
+ 
+
+ By introducing subdiagrams, we have hidden the details of the two light switch automatic light switch modes. In that way, you can directly understand which modes the light switch has and how to switch between them. If you are interested in the details, you can hover or click on the decorator to open the respective subdiagrams. You can revert these changes again by using the Inline Subdiagram refactoring. +
+This example demonstrates the usage of history states and explains the difference between a shallow and a deep history.
+ +Let's revisit the light switch example of the Basic Tutorial. To be more concrete, let's start at the point where our light switch can be in one of three possible modes: +
+ The following statechart reflects these requirements: +
+ 
+
+ Consider the following additional requirement: When the user switches from manual to automatic mode, the last active mode shall be activated. +
++ In order to fulfill this requirement, we need to store which state was active before the user switched to manual mode. And this is exactly where history states come in handy. +
++A shallow history state is a pseudo state that is placed inside the region of a composite state. It is used to remember the last active state inside a composite state. This makes it possible to jump back to the remembered state instead of starting at the inner initial state again. +
++A history state saves the current state exactly when its containing region is left. A shallow history state saves the state of the current level only. If you need to save the status of multiple nested composite states, use a deep history state instead. +
++Let's go back to our light switch example. You can easily change the initial state that points to the MotionDetectionMode state into a history node: +
+
+ 
+
+Using a shallow history node changes the behavior of the light switch to the following: Whenever the AutomaticMode is entered, the last active state will be activated. For example, if the light switch was in twilight mode when the user pressed the On button, pressing the Off button will set it again into twilight mode, instead of the motion detection mode. +
++However, the shallow history does not store the inner state of the respective mode state. As the name already says, it only stores the active state on one level, namely the region in which the shallow history node is placed. Regarding our light switch example, this means that switching back to automatic mode will always activate one of the Idle states. +
+ ++A deep history state is similar to a shallow history state, but more complex. With a deep history state, the latest status of all nested states is remembered. +
+
+ 
+
+Let's take a look at our light switch example again. When the light switch is in TwilightDetected state, and the user presses the On button, this state is stored by the deep history and will be activated again when the user switches back to automatic mode. Please note, that already passed time in time triggers is not stored by a history state. When the light switch is in MotionDetected state and stays there for 20 seconds without any motion being registered, switching to manual mode and back, will start the timer at 0 again, i.e. it will take another 30 seconds for the state being switched to Idle. +
+ +This example demonstrates the usage of orthogonal states as well as of forking and joining synchronization nodes. For more details, please also refer to our documentation.
+ ++Itemis CREATE allows to specify orthogonal regions that are executed virtually concurrently. Orthogonal regions can be modeled either on top level, or within a composite state (or subdiagram). They allow to describe that the modeled system can be in multiple states simultaneously. +
++Let's take the simplified example of a keyboard controller. The user can enable caps lock and num lock. These are two independent functionalities, and the keyboard can have both enabled at the same time. +
+
+ 
+
+Orthogonal regions can not only be defined on top level but also within composite states. The semantics explained above are the same. +The following example model uses a synchronization node to fork the execution flow into both orthogonal regions. After both regions have executed their state transitions, the execution flow is joined again by a synchronization node. A joining synchronization is only executed when all incoming transitions can be taken within the same run-to-completion cycle. For more details, please refer to our documentation on Synchronizations. +
++ +
+
+ 
+
+ In this example series we will develop a lamp control from scratch. Starting from a simple On/Off switch, we will add further features like brightness adjustment and motion detection step-by-step while introducing new statechart elements with each iteration. In that way you will learn how to use: +
+ 
+
A statechart is a graphical model which describes the behavior of some thing or entity. It describes how such an entity reacts to changes and events in its environment. Due to it’s graphical nature, lucid concepts, and well defined semantics it provides a comprehensive and executable basis for system specification and implementation which can be shared between stakeholders without demanding too many technical skills.
+The most basic element of a statechart are states, transitions, and events. To introduce these basic concepts we take a look at the simple light switch example below. States represent the modes of a system or entity and in the case of this very simple light switch two states + Off and + On exist. States have a name, are visualized as rounded rectangles. At any point of time states are either active or inactive. Active state are highlighted using a + yellow background color while inactive states have a + blue background color. +
+If something happens then the statechart may change its state. Each state can have outgoing transitions. These transitions connect two states and have a direction which is indicated by the arrow head. Our light switch states are mutually connected by transitions. These transitions are directed and define how state changes (state transitions) can occur under which conditions. Here, the light switch simply defines that + Off and + On are toggled whenever a + switch event occurs. As the state machine only reacts in response to events, it is called + event driven. +
+Events typically occur in the environment of the statechart’s entity. To simulate this environment and to play with the light switch you can interactively trigger events e.g. by clicking on interactive elements like + switch. +
+
+ 
+
State machines as a whole can be active or inactive. If a state machine is inactive then no state is active and it won’t react on any event. If a state machine is active then is has at least one active state and it is ready to react on events. + Entering a state machine activates it + exiting deactivates it. If you + enter the light switch state machine then + Off is the first active state. The first active state is called + initial state and is defined by the + entry node whose single outgoing transition points to + Off. +
++ The statechart can be simulated in Itemis CREATE via right-click -> Run As -> Statechart Simulation. +
+While the classic theory of input/output automata is only aware of events, Harel statecharts and as such CREATE statecharts have many more features, including variables. Variables allow to use quantitative values in statecharts and are very comparable to variables in programming languages.
+ +To explain the use of variables we extend the light switch by adding + dimming functionality. The light switch supports ten different dimming levels. It still defines the states + Off and + On with mutual transitions which are triggered by + switch events. +
+To handle the dimming functionality the light switch statechart defines two additional elements:
+To handle the + brightness level correctly the statechart must maintain its value depending on the active state and the occurring events. As such it defines the following rules: +
+entry / brightness = 0. This action assigns 0 and is executed whenever state
+ Off is entered.
+ This example shows how variables can be used in conjunction with more complex conditions. Variables can be assigned and can also be used in conditions and calculation expressions. Actions can be specified as part of a transition as well as part of states.
+ + +
+ 
+
Normally, a statechart does not only consist of two states. The specification of even simple systems require tens and more complex systems hundreds of states and transitions. To cope with large number of states the base concept of + composite states can be used. +
+Let’s enhance our light switch to explain this in more detail. The light switch now provides an additional motion sensing mode which automatically switches the light on and off depending on the input of a motion sensor. Initially, the light is off, but whenever the motion sensor senses a motion, it turns the light on. After 30 seconds without any motion the light is turned off again. As manually switching and dimming the light should still be supported the existing statechart must be extended.
+First, an additional event + toggleMode is defined. This is used to toggle between the already existing manual and the automated motion sensing mode. To model these modes two additional states are introduced. +
+after 30s. If the state does not change for 30 seconds then a time event is raised which will cause to switch the light off.
+ A + composite state is a state that contains one or more other states (sub states). One of the advantages is the possibility to group states into logical compounds and thus make the statechart more comprehensible. Another advantage is the option to exit a composite state by transitions that have the composite state as their source states, not any substate. If such a transition is executed, the composite state is left regardless of which of its sub states are active at the moment. You could achieve the same without composite states, but it would be cumbersome since you would need a transition from each of the plain states in the group to the „outsideâ€. +
+The transitions which toggles between + MotionSensing and + Manual state are defined for the composite states. This implies that the transitions will be taken independent of the concrete active sub state. So all sub states share the behavior of their parent states. +
+If you want to learn more about composite states, you can check out our Hierarchical tatecharts example or the chapter Composite states in our documentation.
+ +
+ 
+
We already discussed the default entry behavior for regions and how sub states are activated. Histories provide an extension to this mechanism and this section clarifies how history entries work, what they do, and especially what they don’t do. To illustrate this, we introduce another mode to our light switch: light sensing. When operating in light sensing mode, the light control automatically turns on the light when it is dark and turns it off when it is bright. For this purpose a luminosity sensor is used. It permanently senses the ambient brightness and fires + luminosity.bright or + luminosity.dark events all the time. It is out of scope how „dark†and „bright†are defined and how they are configured in the luminosity sensor. Suffice to say that the sensor is always raising events – say, multiple times per second. +
+As before the light switch is either operated manually or operates automatically. When in automatic mode, the light switch functions either as a twilight switch as explained above or as the already introduced motion sense switch (see the previous iteration). The user interface gets another button to toggle between the two modes via the user.mode_button event. The light switch is starting to change into a full light control module.
+ + +
+ 
+
As we added a couple of additional declarations we now use named interfaces to group the different events and variables. This grouping makes the design more clear and provides a better overview. The usage is not different except for the fact that the interface name must be used when referencing its declarations.
+ +The automatic modes are grouped into the + Automatic composite state. That state is subdivided into a composite state for the twilight functionality and another one for motion sensing. We have discussed motion sensing before, but the + Light Sensing composite state deserves some explanation. When the ambient brightness is changing from day to night or from night to day, the luminosity sensor doesn’t deliver consistent values. Rather small fluctuations are causing a succession of quickly alternating + luminosity.dark and + luminosity.bright events. Having each of these events turn the light on or off, respectively, would result in a flickering lamp for some time during twilight. To avoid this, the state machine requires a certain permanence in the luminosity sensor’s results before actually toggling the light’s state. +
+This is done like this: During the day the + Light Sensing composite state’s + Bright sub state is active. In this state the state machine listens for + luminosity.dark events. These events are starting to be raised when it is about to get dark. First they come in spuriously, later there are more + luminosity.dark than + luminosity.bright events within a given period of time, until only + luminosity.dark events are raised. The first + luminosity.dark changes the state from + Bright to + Getting Dark. In this state we are waiting until a certain time has passed, e. g. 10 seconds, to be configured as constant luminosity.wait_time. However, each + luminosity.bright event brings the state machine back to the Off. Only if the waiting time has passed without any + lum_sensor.bright interfering, the + Dark state is reached and the light is turned on. The analogous happens in the morning when the first light of the day is close. The twilight switch is also robust against short disruptions like overshadowing the sensor during the day or illuminating it briefly by a car’s headlamps during the night. +
+An important requirement is that any of the automatic modes can be interrupted at any time by manually operating the light switch via . When the user later raises a event, the state machine should return to that particular sub state somewhere down in the + Automatic composite state that was active before the manual intervention. Similarly, when toggling between + Light Sensing and + Motion Sensing the state machine should remember the respective active sub state and return there when control is turned back. +
+That’s what history entries are good for. The statechart contains a couple of shallow history entries. A shallow history state, contained in a composite state with a set of sub states, remembers which of these sub states was active when that composite state was left.
+The shallow history state in + Automatic remembers whether + Light Sensing or + Motion_Sensing was active when + Automatic was left, but it doesn’t remember which state was active within the active one of these two. On re-entry, the history state would activate either + Twilight or + MotionSensing, but these would use their respective entries. This is why there is a history state in each of them as well. +
+If you have worked with history states before, you might be inclined now to say: "A deep history state would have been the correct thing here." However, you would only be partially right. A deep history state remembers the active state in its own region and everything that was active inside of this state, recursively down to the lowest level. We might spare the two shallow history states in + Light Sensing and + Motion Sensing. But it would not behave in the same way – a history state is activated only when its containing region is actually left. Using one deep history state would not allow to remember the active state in + MotionSensing when switching to + Light Sensing, and vice versa. The deep history state would be activated only if we left the whole + Automatic composite state – and when switching between automatic modes this won’t happen. +
+More information on history states can also be found in the History States example or the corresponding chapter in our documentation.
+ + + +The different versions of light switches which we discussed so far define a couple of states but are quite simple in that respect that at any time at most one single state is active. You may object that hierarchy made up of composite states features a set of active states. This is not really true. Composite states just group a set of states but are not independent of their sub states. + Leaf states are the + real active states and the activation of a leaf state implies that also all its parent states are active. The leaf states also + inherit the parent states behavior. There are scenarios which require + orthogonal states (sometimes also called + parallel states or + and states). +
+Additionally, there are also scenarios where calculation become so complex that you don’t want to maintain them within a statechart. In these cases + operations can be applied. +
+To illustrate these concepts we define a variant of the light switch which includes a + presence simulation. It behaves as if a person operated the light at sensible and irregular intervals although nobody is present. The presence simulation is active on certain hours of the day only, namely from 17:00 to midnight and from 06:00 to 10:00. Here the motion detection and the twilight detection are left out for clarity. +
+To define the presence simulation the + orthogonal state + Active is defined. It contains two sub regions which are independent of each other and are executed virtually in parallel (their order is relevant, though). Each region can contain one active state. Each region is caring about different aspects. The region + schedule includes a single state which cares about scheduling the next + changePresence event. This event in turn is consumed by the + presence region which switches the light on and off. +
+The events + changePresence, + startSimulation, and + stopSimulation are + internal events (also called + local events) which are raised by the statechart itself when a certain condition is fulfilled. They can’t be raised by the environment and are not visible externally. These internal events will be processed directly after the current event. So + interbnal events can be used to chain multiple processing steps. The states + Idle and + Waiting raise these internal events. +
+The definition of + Presence Simulation get quite complex. There are especially a couple of textual rules and expressions which include calculations. Additionally, a modeler may require functions which are not directly available within the statechart. However, CREATE SCT allows you to implement your own operations to overcome these limitations. An operation is called from the state machine itself, so you don’t have to care about when and how they will be called. Operations can receive arguments from the state machine and return a value, exactly like a normal function or method call. Operations are declared by the statechart but are not defined within the statechart and must be implemented externally. The presence simulation uses two operations: +
+get_hour to ask for the current time of day to decide if the presence simulation must be activated.get_rand to ask for a random float to calculate a random waiting interval in minutes between WAIT_MIN and WAIT_MAX.
+ 
+
false.
+ * If there are no active states then the state machine is considered being inactive. In this case this method returns false.
*/
public boolean isFinal();
}
diff --git a/org.yakindu.sct.examples.sctunit.java/src-gen/com/yakindu/core/ITimed.java b/itemis.create.examples.basic.tutorial/src/itemis/create/ITimed.java
similarity index 86%
rename from org.yakindu.sct.examples.sctunit.java/src-gen/com/yakindu/core/ITimed.java
rename to itemis.create.examples.basic.tutorial/src/itemis/create/ITimed.java
index c64e8f7f..7605e4ff 100644
--- a/org.yakindu.sct.examples.sctunit.java/src-gen/com/yakindu/core/ITimed.java
+++ b/itemis.create.examples.basic.tutorial/src/itemis/create/ITimed.java
@@ -1,5 +1,5 @@
-/** Generated by YAKINDU Statechart Tools code generator. */
-package com.yakindu.core;
+/** Generated by itemis CREATE code generator. */
+package itemis.create;
/**
* Interface for state machines which use timed event triggers.
diff --git a/org.yakindu.sct.examples.sctunit.java/src-gen/com/yakindu/core/ITimerService.java b/itemis.create.examples.basic.tutorial/src/itemis/create/ITimerService.java
similarity index 90%
rename from org.yakindu.sct.examples.sctunit.java/src-gen/com/yakindu/core/ITimerService.java
rename to itemis.create.examples.basic.tutorial/src/itemis/create/ITimerService.java
index acfd55ab..05c09912 100644
--- a/org.yakindu.sct.examples.sctunit.java/src-gen/com/yakindu/core/ITimerService.java
+++ b/itemis.create.examples.basic.tutorial/src/itemis/create/ITimerService.java
@@ -1,5 +1,5 @@
-/** Generated by YAKINDU Statechart Tools code generator. */
-package com.yakindu.core;
+/** Generated by itemis CREATE code generator. */
+package itemis.create;
/**
* Defines methods to set and unset timers for a state machine's timed event triggers.
diff --git a/itemis.create.examples.basic.tutorial/src/itemis/create/TimerService.java b/itemis.create.examples.basic.tutorial/src/itemis/create/TimerService.java
new file mode 100644
index 00000000..7f86f6f0
--- /dev/null
+++ b/itemis.create.examples.basic.tutorial/src/itemis/create/TimerService.java
@@ -0,0 +1,110 @@
+/** Generated by itemis CREATE code generator. */
+package itemis.create;
+
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Timer;
+import java.util.TimerTask;
+import java.util.concurrent.locks.Lock;
+import java.util.concurrent.locks.ReentrantLock;
+
+/**
+ * Default timer service implementation.
+ *
+ */
+public class TimerService implements ITimerService {
+
+ private final Timer timer = new Timer();
+
+ private final List+ This is a simple example of how to use the C/C++ Domain together with an Arduino. C++ Timer are integrated. + The underlying statechart looks as follows: +
+
+
All Arduino examples can be compiled via command line or be imported into the Arduino IDE. An easier way is using the Sloeber plugin , which allows you to compile and upload the code directly in Statechart Tools. +
+ There are two ways of how to install the plugin. The easiest way is using our example wizard, which allows you installing required plugins. Just follow the built-in instructions. +
++ Another way is installing the plugin manually. You need to follow these steps: +
+ After the installation you should notice a new Toolbar, which allows you to compile and flash your Arduino. + Initially, the projects are not configured, as you may require to add the toolchain: +
+ Finally, you can use the green toolbar for compiling and flashing the Arduino. Have fun! +
+This example demonstrates how to generate C code from a statechart. We will use a simple light switch example and focus on the generator model.
+ ++ In order to generate code we need to specify which code generator to use and into which folder to generate. For this, we need to create a so-called generator model. To do so, +
+ The new generator model will look similar to this one: +
++ +
++ The generator model defines where the code should be generated into, and enables the generation of a default timer service. Besides setting up the target location, the generator model allows you to adjust several aspects of the generated code like naming, license comments or function inlining. Press [CTRL]+[SPACE] to get a list of available features. For more information, please refer to our documentation. +
+
+
+
+ + Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ ++ As an example application we will use the light switch example with brightness adjustment from the Basic Tutorial. +
+
+
+
+ Our application is a simple interactive console with which the user can switch the light on or off. The complete application code is implemented in main.c:
+
+ +
+
+ The most important parts are commented in the main.c file. These are the bullet points:
+
user.on_button and user.off_button+ You can run the application with Run As -> Local C/C++ Application on the project. A console should open and ask you for input like in the screenshot below. +
+
+
+
This example demonstrates how to generate C++ code from a statechart. We will use a simple light switch example and focus on the generator model.
+ ++ In order to generate code we need to specify which code generator to use and into which folder to generate. For this, we need to create a so-called generator model. To do so, +
+ The new generator model will look similar to this one: +
++ +
++ The generator model defines where the code should be generated into, and enables the generation of a default timer service. Besides setting up the target location, the generator model allows you to adjust several aspects of the generated code like naming, license comments or function inlining. Press [CTRL]+[SPACE] to get a list of available features. For more information, please refer to our documentation. +
+
+
+
+ + Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ ++ As an example application we will use the light switch example with brightness adjustment from the Basic Tutorial. +
+
+
+
+ Our application is a simple interactive console with which the user can switch the light on or off. The complete application code is implemented in main.cpp:
+
+ +
+
+ The most important parts are commented in the main.cpp file. These are the bullet points:
+
user.on_button and user.off_button+ You can run the application with Run As -> Local C/C++ Application on the project. A console should open and ask you for input like in the screenshot below. +
+
+
+
This example demonstrates how to generate Java code from a statechart. We will use a simple light switch example and focus on the generator model.
+ ++ In order to generate code we need to specify which code generator to use and into which folder to generate. For this, we need to create a so-called generator model. To do so, +
+ The new generator model will look similar to this one: +
++ +
++ The generator model defines where the code should be generated into, and enables the generation of a default timer service. Besides setting up the target location and the package names, the generator model allows you to adjust several aspects of the generated code like naming, license comments or function inlining. Press [CTRL]+[SPACE] to get a list of available features. For more information, please refer to our documentation. +
+
+
+
+ + Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ ++ As an example application we will use the light switch example with brightness adjustment from the Basic Tutorial. +
+
+
+
+ Our application is a simple interactive console with which the user can switch the light on or off. The complete application code is implemented in Main.java:
+
+ +
+
+ The most important parts are commented in the Main.java file. These are the bullet points:
+
user.on_button and user.off_button
+ You can run the application with Run As -> Java Application on the Main.java file. A console should open and ask you for input like in the screenshot below.
+
+
+
This example demonstrates how to generate C code for a multi state machine scenario and how to set everything up in the application code. As example, we will use a light controller that controls two lights. The controller as well as the lights are defined by state machines that communicate with each other by the means of events.
++ You can find more information on using the multi state machine feature in the online + documentation. +
++ The example application consists of two state machines, one for the controller, and one that describes a simple light switch. +
+
+
+
+ The light switch model simply consists of two states, On and Off, and respectively two incoming events on and off. Each time the event on is received, the brightness is increased until a maximum brightness is reached. Whenever the brightness changes, the outgoing event brightness_changed is raised with the new brightness value. Both, the incoming and outgoing events, are used in the controller machine to control two different lights.
+
+
+
+ Let's first take a look at the definition section. The controller machine declares two variables light1 and light2 of type Light which represents the light state machine above. When the controller machine is entered, also these two light machines are entered. In addition, they get initialized with different maximum brightness values.
+
+
+
+ The state machine basically describes two modes, a regular one in which the switch_on event is just passed on to both light machines, and a blink mode in which the lights' on events are raised periodically. In this mode, both lights' brightness will be automatically increased until its maximum where it starts from zero again. In order to notice when the maximum brightness of a light is reached, the BlinkMode state reacts to the light machines' brightness_changed events and reads the transmitted value.
+
+ The generator model simply defines the configuration for both state machines. As the state machines use time events, we ensure that a timer service implementation is generated with the TimerService parameter.
+
+ +
+ + ++ Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ +
+ Our application is a simple interactive console with which the user can switch the lights on or off as well as toggle the blink mode. The complete application code is implemented in main.c:
+
+ +
+
+ The most important parts are commented in the main.c file. These are the bullet points:
+
+ You can run the application with Run As -> Local C/C++ Application on the main.c file. A console should open and ask you for input like in the screenshot below.
+
+
+
This example demonstrates how to generate C++ code for a multi state machine scenario and how to set everything up in the application code. As example, we will use a light controller that controls two lights. The controller as well as the lights are defined by state machines that communicate with each other by the means of events.
++ You can find more information on using the multi state machine feature in the online + documentation. +
++ The example application consists of two state machines, one for the controller, and one that describes a simple light switch. +
+
+
+
+ The light switch model simply consists of two states, On and Off, and respectively two incoming events on and off. Each time the event on is received, the brightness is increased until a maximum brightness is reached. Whenever the brightness changes, the outgoing event brightness_changed is raised with the new brightness value. Both, the incoming and outgoing events, are used in the controller machine to control two different lights.
+
+
+
+ Let's first take a look at the definition section. The controller machine declares two variables light1 and light2 of type Light which represents the light state machine above. When the controller machine is entered, also these two light machines are entered. In addition, they get initialized with different maximum brightness values.
+
+
+
+ The state machine basically describes two modes, a regular one in which the switch_on event is just passed on to both light machines, and a blink mode in which the lights' on events are raised periodically. In this mode, both lights' brightness will be automatically increased until its maximum where it starts from zero again. In order to notice when the maximum brightness of a light is reached, the BlinkMode state reacts to the light machines' brightness_changed events and reads the transmitted value.
+
+ The generator model simply defines the configuration for both state machines. As the state machines use time events, we ensure that a timer service implementation is generated with the TimerService parameter.
+
+ +
+ + ++ Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ +
+ Our application is a simple interactive console with which the user can switch the lights on or off as well as toggle the blink mode. The complete application code is implemented in main.cpp:
+
+ +
+
+ The most important parts are commented in the main.cpp file. These are the bullet points:
+
+ You can run the application with Run As -> Local C/C++ Application on the main.cpp file. A console should open and ask you for input like in the screenshot below.
+
+
+
This example demonstrates how to generate Java code for a multi state machine scenario and how to set everything up in the application code. As example, we will use a light controller that controls two lights. The controller as well as the lights are defined by state machines that communicate with each other by the means of events.
++ You can find more information on using the multi state machine feature in the online + documentation. +
++ The example application consists of two state machines, one for the controller, and one that describes a simple light switch. +
+
+
+
+ The light switch model simply consists of two states, On and Off, and respectively two incoming events on and off. Each time the event on is received, the brightness is increased until a maximum brightness is reached. Whenever the brightness changes, the outgoing event brightness_changed is raised with the new brightness value. Both, the incoming and outgoing events, are used in the controller machine to control two different lights.
+
+
+
+ Let's first take a look at the definition section. The controller machine declares two variables light1 and light2 of type Light which represents the light state machine above. When the controller machine is entered, also these two light machines are entered. In addition, they get initialized with different maximum brightness values.
+
+
+
+ The state machine basically describes two modes, a regular one in which the switch_on event is just passed on to both light machines, and a blink mode in which the lights' on events are raised periodically. In this mode, both lights' brightness will be automatically increased until its maximum where it starts from zero again. In order to notice when the maximum brightness of a light is reached, the BlinkMode state reacts to the light machines' brightness_changed events and reads the transmitted value.
+
+ The generator model simply defines the configuration for both state machines. As the state machines use time events, we ensure that a timer service implementation is generated with the TimerService parameter.
+
+ +
+ + ++ Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ +
+ Our application is a simple interactive console with which the user can switch the lights on or off as well as toggle the blink mode. The complete application code is implemented in Main.java:
+
+ +
+
+ The most important parts are commented in the Main.java file. These are the bullet points:
+
+ You can run the application with Run As -> Java Application on the Main.java file. A console should open and ask you for input like in the screenshot below.
+
+
+
This example demonstrates how to generate Python code for a multi state machine scenario and how to set everything up in the application code. As example, we will use a light controller that controls two lights. The controller as well as the lights are defined by state machines that communicate with each other by the means of events.
++ You can find more information on using the multi state machine feature in the online + documentation. +
++ The example application consists of two state machines, one for the controller, and one that describes a simple light switch. +
+
+
+
+ The light switch model simply consists of two states, On and Off, and respectively two incoming events on and off. Each time the event on is received, the brightness is increased until a maximum brightness is reached. Whenever the brightness changes, the outgoing event brightness_changed is raised with the new brightness value. Both, the incoming and outgoing events, are used in the controller machine to control two different lights.
+
+
+
+ Let's first take a look at the definition section. The controller machine declares two variables light1 and light2 of type Light which represents the light state machine above. When the controller machine is entered, also these two light machines are entered. In addition, they get initialized with different maximum brightness values.
+
+
+
+ The state machine basically describes two modes, a regular one in which the switch_on event is just passed on to both light machines, and a blink mode in which the lights' on events are raised periodically. In this mode, both lights' brightness will be automatically increased until its maximum where it starts from zero again. In order to notice when the maximum brightness of a light is reached, the BlinkMode state reacts to the light machines' brightness_changed events and reads the transmitted value.
+
+ The generator model simply defines the configuration for both state machines. As the state machines use time events, we ensure that a timer service implementation is generated with the TimerService parameter.
+
+ +
+ + ++ Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ +
+ Our application is a simple interactive console with which the user can switch the lights on or off as well as toggle the blink mode. The complete application code is implemented in main.py:
+
+ +
+
+ The most important parts are commented in the main.py file. These are the bullet points:
+
+ You can run the application with Run As -> Python Run on the main.py file. A console should open and ask you for input like in the screenshot below.
+
+
+
This example demonstrates how to generate Python code from a statechart. We will use a simple light switch example and focus on the generator model.
+ ++ In order to generate code we need to specify which code generator to use and into which folder to generate. For this, we need to create a so-called generator model. To do so, +
+ The new generator model will look similar to this one: +
++ +
++ The generator model defines where the code should be generated into, and enables the generation of a default timer service. Besides setting up the target location, the generator model allows you to adjust several aspects of the generated code like naming, license comments or function inlining. Press [CTRL]+[SPACE] to get a list of available features. For more information, please refer to our documentation. +
+
+
+ + Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ ++ As an example application we will use the light switch example with brightness adjustment from the Basic Tutorial. +
+
+
+
+ Our application is a simple interactive console with which the user can switch the light on or off. The complete application code is implemented in main.py:
+
+ +
+
+ The most important parts are commented in the main.py file. These are the bullet points:
+
user.on_button and user.off_button
+ You can run the application with Run As -> Python Run on the main.py file. A console should open and ask you for input like in the screenshot below.
+
+
+This example demonstrates how to generate SCXML code from a statechart. We will use a simple light switch example and focus on the generator model.
+ ++ In order to generate code we need to specify which code generator to use and into which folder to generate. For this, we need to create a so-called generator model. To do so, +
+ The new generator model will look similar to this one: +
++ +
++ This is the simplest possible generator model. Press [CTRL]+[SPACE] to get a list of available features. For more information, please refer to our documentation. +
+
+
+
+ + Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
+ ++ As an example application we will use the light switch example with brightness adjustment from the Basic Tutorial. +
+
+
+
+ The code will be generate to a LightSwitch.scxml file. You can run the application with Run As -> Statechart Simulation on the light_switch.sct file. The generated scxml will be interpreted using Appache's Commons Engine.
+
+ This is a comprehensive example for the deep integration of CREATE + statecharts with manually written C code. The example is implemented as a + simple command line tool. It makes use of POSIX threads. So you need a + compiler tool chain and a 'pthread' library to build an run the example. + The underlying statechart for the coffee machine looks as follows:
The source code artifacts are all located in the 'src' folder. File + names that include 'coffee' or 'cm_' include application specific + implementations and those with 'sc_' prefix are generic parts that belong + to the state machine infrastructure.
+As mentioned above you need a compiler tool chain and the 'pthread' + libraries. If you have a Linux or Mac OS Xsystem you likely have + everything installed. If you run Windows than we propose to install cygwin + tools (https://www.cygwin.com).
+This project is preconfigured for Windows with cygwin. If you use + another system: +
... and your project should be ready to build.
++
In the 'Debug' or 'Release' folder you will find an executable + 'coffee_machine_pro.exe' (even on Linux and Mac OS X). Right-click on this + and choose: +
+ The embedded Eclipse console shows up and you can follow the instructions.
+ Enter 'o' to start the coffee machine...
+
Additionally you can simulate the statechart by right-click and + choose: +
+ You'll find more information on using the simulation in the help. +
+
+ You may want to change or extend the model. Within the embedded expression
+ editor you can press 'Ctrl-Space' to get proposals, which also include the
+ C elements from the imported C header files.
+
If you have changed the model you can generate state machine code by + right-click on 'CoffeeMachine.sgen' and choose 'Generate Code Artefacts'. + This will generate:
++ This is a example for the deep C++ integration of CREATE + statecharts. It shows how C++ classes can be used as variables and is based on the C example:
Imported classes can be referenced by declaring a variable and using the + class as the type of it. + Within the example two classes are referenced: +
+ The declared variables can be used and changed in the simulation view.
If you have changed the model you can generate state machine code by + right-click on 'CoffeeMachine.sgen' and choose 'Generate Code Artefacts'. + This will generate:
+This digital watch was first designed by Harel, the founder of the + Statecharts Theory. He described it in "On Visual Formalisms", published + in "Communications of the ACM" in May 1988.
+ +As you can see in the picture below, the complete statechart is + rather complicated and not easy to grasp on first glance:
+ +
+ 
+
We can use a CREATE SCT feature to extract composite states into + subdiagrams. This makes the statechart much easier to comprehend:
+
+ 
+
Using subdiagrams allows you to abstract the statechart to any + level you want, so that you can review the statechart's overall + functionality and its inner workings separately – much like a class + diagram versus the complete codebase. Copy the example to your workspace + and try out the subdiagram editor!
+For reference, here's the interface declaration of both + statecharts:
+ +
+ 
+
This video tutorial is presented by Prof. Tom Mens (Software Engineering Lab, University of Mons). It provides a hands-on demonstration, on the basis of a simulation of an elevator statechart, on how to write and run unit tests for statecharts with Itemis CREATE.
+ + ++
++ The CREATE Execution Trace (YET) infrastructure supports interoperability between + state machines running in a target application and the CREATE tooling. + It supports model-level debugging and testing of the state machines based on execution traces. + This example shows how to remote debug a compiled state machine step by step. Please refer to the + YET documentation for more information. +
+ +
+
+ + This is a simple blinky LED example, which uses two states. The user can switch between the Idle and Blink by setting the toggle event. + Once the Blink state is active, the state machine toggles between the Off and On state. By setting the delay variable, the time for the after + trigger can be changed. +
+
+
+ + This state machine is executed within an interactive application. This application can be used + from the command line. It reads user input from the standard input and writes to the standard output. + It is build to run on a Raspberry PI. The SCT Simulation can be executed on any other machine. + For this setup both are located the same local network. +
+ +
+ The instructions contain detailed explanations of how to set up the environment, compile the program and flash the binary on the ESP32. It also shows how a terminal can be added. Your WiFi SSID and password must be set in the sdkconfig file. 
#define SCT_IP "Add your IP here". The simplest way finding your ip address using ifconfing on linux or mac and ipconfing on windows. It should be something like 192.168.0.42
+
+
+ + Debugging a statechart YET trace is simple. Within a statechart editor or on the model file entry + in the project explorer choose Run As > Statechart Trace Debugging from the context menu. +
+ +
+
+ + This will launch the trace debugger and by default will try to read the input of socket 4444, which is defined in the application. + You can change the port in the Run Configuration. + +
++
+This example demonstrates how to generate a Functional Mock-up Unit (FMU) from a statechart. For this we will use the example of a bouncing ball and calculate the height of the ball over time with the statechart.
+ ++ The Functional Mock-up Interface (FMI) standard addresses the exchange and joint execution of models for co-simulation. It mainly is applied for system level simulation of complex systems. + CREATE statecharts can be exported as *Functional Mock-up Units (FMUs)* and as such can participate in FMI based simulations. As FMUs provide binary executables and only bundle source code or models as an option FMUs can be + provided to other parties without exposing intellectual property. Concretely, Itemis CREATE supports FMI 2.0 for Co-Simulation FMU export. By the support of the FMI standard CREATE statecharts are interoperable with + a wide range of simulation tools. +
+ +
+ 
+
+ The FMU generator supports building FMUs for Windows, Linux and MacOS 64Bit platforms. The generator builds a complete FMU and relies on Eclipse C development infrastructure. + So as a precondition you have to make sure that CDT features are installed. For Windows platform the Cygwin toolchain must be installed. +
++ In order to generate code we need to specify which code generator to use and into which folder to generate. For this, we need to create a so-called generator model, which is already done for this project. To do so by yourself, +
+ The new generator model will look similar to this one: +
++ +
++ The generator model defines where the code should be generated into by specifying the target project and target folders. +
+ ++ Code generation is usually invoked each time the statechart model is saved. This behavior can be disabled by unchecking the option Project -> Build Automatically. You can always manually invoke the code generation with Generate Code Artifacts in the context menu of the generator model. +
++ Each time the FMU code is generated, CDT will build the project and create an FMU for you under the Debug folder. Copy this FMU file to deploy it to your FMI compatible simulation environment. +
++ You can find more information on the FMU feature in our documentation. +
+ ++ As an example application we will use the 'BouncingBall' statechart to calculate the height of a ball which is dropped to the ground and then continues to bounce until a certain point in time. +
+
+
+ + Our statechart determines the height of the ball by taking the velocity of the ball and the gravitation into consideration. Also, with every bounce to the ground the velocity of the ball is reduced by a constant factor. +
+ +This example demonstrates how to integrate a state machine into FreeRTOS. It's based on the C Code Generation example.
+ ++ In order to run the example, FreeRTOS must be cloned. Clone FreeRTOS from https://github.com/FreeRTOS/FreeRTOS
++ Open a terminal and cd to the root of this project, call cmake, make the project and run the binary. Ensure that the state machines code has been generated. +
+cd "path to your project"
+cmake -B build -DCOMPILER=GCC_POSIX -DFREE_RTOS_PATH="path to your cloned FreeRTOS"
+./create_freeRTOSExpandable HMI example for Arduino using a 16x2 LCD Keypad Shield.
+ +
+ 
+
The full example description can be found on Instructables. +
++ This video shows the running application: +
++ This video shows how to simulate the state machine: +
+All Arduino examples can be compiled via command line or be imported into the Arduino IDE. An easier way is using the Sloeber plugin , which allows you to compile and upload the code directly in Statechart Tools. +
+ There are two ways of how to install the plugin. The easiest way is using our example wizard, which allows you installing required plugins. Just follow the built-in instructions. +
++ Another way is installing the plugin manually. You need to follow these steps: +
+ After the installation you should notice a new Toolbar, which allows you to compile and flash your Arduino. + Initially, the projects are not configured, as you may require to add the toolchain: +
+ Finally, you can use the green toolbar for compiling and flashing the Arduino. Have fun! +
++
+ Embedded Systems Integration Guide - FreeRTOS Integration. +
++ This example has been created to illustrate how itemis CREATE can be integrated in FreeRTOS. + You can find a detailed description in our documentation. +
++ The state machine contains the following parts: +
+ 
+
+ In order to run the example, FreeRTOS must be cloned. Clone FreeRTOS from https://github.com/FreeRTOS/FreeRTOS
++ Open a terminal and cd to the root of this project, call cmake, make the project and run the binary. Ensure that the state machines code has been generated. +
+cd "path to your project"
+cmake -B build -DCOMPILER=GCC_POSIX -DFREE_RTOS_PATH="path to your cloned FreeRTOS"
+./create_freeRTOS