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.

On the one hand this eases the compilation and makes it more robust because it reduces its complexity. On the other hand, using Extended SCCharts features, a modeler is able to abstract away complexity of his or her SCCharts model which increases robustness and readability of a model. This approach enables a simple yet efficient compilation strategy and aids verification and certification.

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 SCChart

Extended SCCharts

Graphical 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

Subproject/Extension

Progress

Released

SCCharts Editor (*.sct)

Implemented and tested

0.9.0

SCG Editor

Implemented and tested

0.9.0

SCL Editor

Implementation not yet finished

cancelled

Extended 2 Core SCCharts

Implemented, not yet fully tested

0.9.0

Core 2 Normalized SCCharts

Implemented, not yet fully tested (some known bugs)

0.9.0

Normalized SCCharts 2 SCG

Implemented, not yet fully tested (some known bugs)

0.9.0

SCG 2 Sequential SCG

Implemented and partly tested,

straightforward scheduler for 0.9.0 release,

enhanced scheduler planned for 0.10.0 release.

0.9.0

SCG 2 C

Implemented by transformation via common S language

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

0.9.0

Online Compiler and Command Line Tools

Implemented and partly tested

0.10.0

Simulation

Implemented and partly tested

0.10.0

Hardware Circuit Synthesis and Simulation

Implemented and partly tested

0.11.0

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