Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

 Image Modified
Sequentially Constructive Statecharts (SCCharts)

SCCharts [5] is a new visual synchronous language that is designed for specifying safety-critical reactive systems. SCCharts uses a new statechart notation similar to Harel Statecharts [3] and provides deterministic concurrency based on a synchronous model of computation (MoC), without restrictions common to previous synchronous MoCs like the Esterel constructive semantics [2].  Specifically, we lift earlier limitations on sequential accesses to shared variables, by leveraging the sequentially constructive MoC [4]. Thus SCCharts in short are SyncCharts [1] syntax plus Sequentially Constructive semantics.

The key features of SCCharts are defined by a very small set of elements, the Core SCCharts, consisting of state machines plus fork/join concurrency.

Conversely, Extended SCCharts contain a rich set of advanced features, such as different abort types, signals, history transitions, etc., all of which can be reduced via semantics preserving model-to-model (M2M) transformations into Core SCCharts. Extended SCCharts features are syntactic sugar because they can be expressed by a combination of Core SCCharts features.


[7] David Harel. Statecharts: A visual formalism for complex systems, Science of Computer Programming, 8(3):231-274, June 1987.


Excerpt Include
Downloads - KIELER SCCharts Product
Downloads - KIELER SCCharts Product

Sequentially Constructive MoC

In contrast to SyncCharts (see [1] Charles André) a signal (or variable) in SCCharts is allowed to be emitted with different values in the same macro tick (if the emissions are schedulable according to the SC MoC). The following example is forbidden in SyncCharts but not in SCCharts.


SyncCharts: x cannot be absent and present in the same macro tick.
SCCharts: Deterministic ordering possible: If x is false then take the transition and set x to true.

Core & Extended SCCharts

A core SCChart is composed of elements of a minimal set of constructs. Additional constructs and syntactical sugar (f.e. actions, suspend) are introduced in extended SCCharts. Every extended SCCharts can be transformed into a core SCChart.


Core SCChartExtended SCChartsGraphical comparison
  • Simple States
  • Hierarchical States
    (aka Composite States)
  • Regions
  • Transitions (weak abort)
  • Immediate Transitions
  • Normal Termination 
  • Variables (primitive types)
  • Interface Declaration

Core SCCharts +

  • Connector (aka Choice)
  • Strong Abort
  • Weak Abort
  • History Transition
  • Suspension
  • Entry Action
  • During Action (aka Inner Action)
  • Exit Action
  • Signal
  • Pre
  • Count Delay
  • Conditional Termination
  • Initialization
  • Complex Final State
  • Deferred Transition

[click to enlarge]

Modeling & Compiling SCCharts

SCCharts can be modeled using our KIELER SCChrats editor and compiler (download). The modeling editor is a textual editor based on the itemis Xtext framework. The language used to model SCCharts textually is called SCT and documented here. A quick start guide introducing first steps from downloading over modeling to compiling SCCharts can be found here.

Project Status

SCCharts Editor (*.sct)Implemented and tested
SCG EditorImplemented and tested
SCL EditorImplementation not yet finished


Extended 2 Core SCChartsImplemented, not yet fully tested
Core 2 Normalized SCChartsImplemented, not yet fully tested (some known bugs)
Normalized SCCharts 2 SCGImplemented, not yet fully tested (some known bugs)
SCG 2 Sequential SCG

Implemented and partly tested,

straightforward scheduler for 0.9.0 release,

enhanced scheduler planned for 0.10.0 release.


Implemented by transformation via common S language

(this can also be translated into Java -> SJL)

Online Compiler and Command Line ToolsImplemented and partly tested
SimulationImplemented and partly tested
Hardware Circuit Synthesis and SimulationImplemented and partly tested

Known Limitations

  • Normalization may result in conditions where there actually is no conditions, this should optimized manually
  • SCG Generation currently produces unoptimized hierarchy levels, e.g., fork nodes with just one successor node should be eliminated
  • Scheduling of unconnected SCG exit nodes is currently not possible