Application scenarios Copy link to clipboard

The execution trace model enables interoperability between different tools and as such serves a large number of application scenarios. The possible interoperability is shown in the following figure.

Interoperability based on execution traces

One important part is to enable execution tracing and stimulation for all contexts in which statecharts are executed. One important context is a concrete collaborative embedded system which executes one or more state machines. The others are simulations like the itemis CREATE interpreter based simulation or a Functional Mock-up Interface (FMI) based co-simulation context. On the other side there are tools which analyze the system or the statechart execution. These interpret and analyze the statechart execution traces in a specific way. Some of these just consume execution traces. Others can also stimulate execution and as such can be executed ‘in the loop’ with statecharts.

The execution trace decouples the statechart execution from analysis tools. So, both sides can be combined in a flexible way with each other. There are some application scenarios which are implemented based on this concept.

Model-level target debugging of state machines Copy link to clipboard

In (embedded) software development scenarios, CREATE Statecharts are transformed to state machine code that runs within a target application. To enable model-level debugging of these state machine implementations within the itemis CREATE, a YET based integration is applied.

Integration scenarios for model-level target debugging

Model-level debugging may cover two variants. First, a bidirectional online integration based on streams (YET stream). Second, a file-based integration (YET file) which covers offline post-mortem analysis of execution traces.

In both cases YET must contain execution trace events that allow:

• tracking of variable values
• tracking of statechart events
• tracking of active states and transitions

YET stream is bidirectional and also supports

• changing variable values and
• raising events

on the state machine if that direction is supported by the target application.

Of course YET traces can be analyzed manually as the file format is human readable. This is already a great help in the day to day work. Additionally, tool support enables the visualization of execution traces using the itemis CREATE simulation UI. This enables the playback of traces stored in files or the live visualization and interaction based on a YET stream.

Test statechart execution traces using SCTUnit Copy link to clipboard

While the model-level target debugging supports the interactive analysis of a state machine execution there are cases where automated checking of execution results are required. This is the case if execution traces are very large or must be analyzed very often. A specific kind of automated execution analysis, which is supported by itemis CREATE, is SCTUnit. SCTUnit is a model-level unit testing framework and can check statechart behavior for correctness. As a YET trace is a representation of a statecharts behavior it can be used as a subject of test. According to the the debugging scenario, which are described in the previous section, unit tests can be executed on a execution trace which is stored in a file. If it is connected to a statechart using a YET stream then also stimulation of the statechart and an ‘in the loop’ execution is possible. This can be used to set up HiL (or other kind of XiL) test scenarios.

Testing state machine execution on an embedded target

SCTUnit itself is a text based language which follows the typical XUnit testing approach. Test cases are implemented as simple scripts. These scripts can directly be executed in the itemis CREATE tool or can be transpiled to code. A very simple example for a statechart unit test provides the following code:

testclass TrafficLightTest for statechart TrafficLightCtrl {
	
	@Test operation switchTrafficLightOn () {
				
		// given the traffic light is inactive
		assert !is_active
		// when
		enter
		// then traffic light is off which means no color was switched on
		assert TrafficLight.displayRed
		assert !TrafficLight.displayGreen
		assert !TrafficLight.displayYellow
	}
	

	@Test operation switchLightFromRedToGreen () {
				
		// given
		switchTrafficLightOn
		// when
		raise TrafficLight.releaseTraffic
		proceed 60s
		// then 
		assert TrafficLight.displayGreen
	}
}

The unit test is defined as a test class. A test class refers to the statechart under test and defines two test cases. Each is implemented by a test operation. ‘assert’ statements check properties of the state machine. The ‘enter’ statement activates the state machine and ‘raise’ raises an event. So both are stimuli processed by the statechart. The ‘proceed’ statement controls time and continues the test after 60 seconds have passed. A unit test is optimized to check specific execution sequences. For more complex conditional and iterative scenarios also ‘if’ statements and ‘while’ loops can be defined which can make use of local variables.

FMI based co-simulation Copy link to clipboard

Co-simulation is a major field for the application of YET. itemis CREATE can be used to create Functional Mock-up Units (FMUs) that can be integrated in co-simulations based on the Functional Mock-up Interface (FMI) standard. Different scenarios are supported. First, the debugging and testing approaches described in the previous sections can also be applied using a FMI co-simulation instead of a concrete embedded target. An additional scenario is to integrate the CREATE Statechart simulation into a FMI co-simulation using a tool wrapper FMU. This is a FMU which wraps a simulation tool and does not execute a statechart on its own. Instead, the statechart is executed by the CREATE Statechart simulation. This simulation runs in a separate process. This requires execution events to be exchanged between the FMU and the simulator.

FMU tool wrapper delegates execution to itemis CREATE simulator

Integrating CREATE Statecharts in FMI-based co-simulation scenarios requires additional plugins. A detailed description of this features is not included in this document but it will follow soon. Please contact statecharts@itemis.com if you require more information earlier.

Analyse statechart execution using data visualization & analysis tools Copy link to clipboard

In addition to the tool features provided by itemis CREATE, out of the box analysis and trace visualization tools can be integrated. An example for such a tool is impulse which is a visualization and analysis workbench. It enables engineers to understand and debug complex systems by relating signals and data from arbitrary sources to statechart execution. This data can be visualized using a rich set of diagrams.

CREATE Statechart execution visualized in impulse

The correlation of data from different sources and its visualization is not scope of itemis CREATE tools. Thus it makes much sense to integrate dedicated tools for this purpose. impulse can read and analyse YET trace files of CREATE Statecharts.

Analyse execution traces from file