Find out what's new in the upcoming V2 release of SCCharts!

What is new to SCCharts?

Controlflow / Dataflow Hybrid-Models

Semantic Comments

New Reference / Module Support

For Region

New Transformations

New Annotations & Pragmas

SCCharts Syntax Changes

What is new to the KIELER SCCharts workflow?

New Warnings & Errors

• Detailed reference warnings
• Label shadowing

Project Management

Working with SCCharts now integrates better in the Eclipse workflow by providing new wizards and an incremental project builder.

There are wizards for SCCharts projects on the one hand and different files on the other hand. The file wizards are used, e.g., to create files for the new configuration DSLs.

The SCCharts project wizard is a flexible approach to create a project for some target platform that is ready to be deployed. Therefore the wizard references another project wizards (e.g. from the CDT or JDT) to integrate with other tooling. After the referenced wizard has created the project, additional files are added to work with SCCharts. These files include a model file and configuration files for the new incremental project builder.

The incremental project builder is run by Eclipse either in the background when resources changes (Project > Build automatically), or manually by the user (Project > Build Project). What and how files are built can be configured using a new DSL (kibuild files). Errors and warnings that occur during the build are added as markers to the resources where they occur, which is a known concept in the Eclipse IDE. For instance when working with Java, compiler errors are added as markers to files when they are saved. This is now also possible for SCCharts text files and provides faster compiler feedback to users, e.g. because a model can not be compiled, as long as the automatic build is active.

Several actions are performed when a project is built:

• Model files are compiled
  • Optionally a template is processed for each model to generate the simulation code for the model.
• Simulation code is compiled to an executable, which can be started using the new simulation
• Freemarker templates are processed to generate code.
  Depending of the type of the template, additional variables are injected into the template
  
  • Wrapper code templates are used to create the wrapper code for a specific model.
    Annotations on inputs and outputs in the model can be used to define which code snippets are injected as part of the build. These code snippets typically contain code to read or write the corresponding inputs and outputs.
  • Simulation code templates are used to create wrapper code for simulation of models.
    Thus it is a special form of wrapper code template. Instead of user defined annotations, the injected code snippets are determined by the variables in the model.
    This kind of template can be configured as part of a model compiler to automatically generate the simulation for all compiled models.
  • Simple templates are self contained and no additional variables are injected.

Corresponding to the actions that are performed during the build, its configuration consists of model compilers, simulation compilers and template processors. A template processor is either a simple template processor, wrapper code template processor or simulation template processor.

If all of these are defined, an incremental project build could consist for example of the following steps:

• Build a model file A.sctx
  
  • Afterwards process a simulation template to generate its simulation code Sim_A.c
• Compile the simulation code Sim_A.c to an executable using gcc
• Create wrapper code for the model, that is ready to be deployed

Note that if the Build automatically option is set, it is possible to (re-)start a simulation without the need to (re-)compile the corresponding model beforehand. This is because the simulation executable has been created in the background as part of the build and is updated if the model changes. This results in a faster code-test-workflow compared to the previous approach, in which a model was always re-compiled before its simulation was started.

Integrated Simulation

The simulation backend has been rewritten to be more lightweight, flexible and transparent and to better integrate in the workflow.

Major new features are:

• simulation of multiple models at once that interact with each other
• starting the simulation with precompiled executables
• support for arrays
• more user friendly interaction with the simulation
• a DSL (kisim files) to configure complex simulation setups

Simulation Visualization

The current state of a running simulation can be displayed by setting attributes of elements in an SVG image. For instance it is possible to set the color or position of elements based on the value of a variable in the simulation.
Furthermore it is possible to interact with SVG elements to control the simulation and set variable values. This way it is possible to define buttons in the SVG to play, pause, step or stop the simulation, as well as setting variables.

To use these features, an SVG image has to be created, in which the elements that should be animated must have a unique id. Afterwards the interactions and animations for these elements are defined using a DSL (kivis files).

Interactive Model-Based Compiler

What is new for SCCharts developer?