General information:

We are currently running an experiment for which we need participants that are willing to contribute aproximately 20 to 30 minutes of their time. All participants (unless they protest, of course) will be entered into a price draw for 3 amazon vouchers for 25 Euro value each. Thanks if you are considering to take part! Please contact Insa Fuhrmann for one of the time slots from 18th to 25th of January: 0431-880-7526 or in person in room 1113. Also contact Insa Fuhrmann if you have questions that are not answered below.

The participants will be asked to give information on how experienced they are with modeling SCCharts and modeling and programming in general.

The participants will be given an SCChart model in Kieler together with a timing specification for the maximal worst case execution time of the model. The model in its given form does not meet the timing specification and it is the task for the participant to revise the model such that the timing specification is met. To be able to do that the participant will receive a list of alternative library functions for the host code calls that are included in the model. To replace function calls by calls to the respective alternative functions is the only change that is allowed to solve the task. However it is allowed to change the model temporarily, especially by commenting out parts of the code, but the outcome must be the same model (semantically as well as syntactically) with the exception of a number of swapped host code calls.

The participants will be devided into groups that will work with KIELER versions with different degrees of interactive timing support. We will measure the time it takes for each participant to solve the task as well as the number of call replacements. We will also document the final state of the model.

Here is a small example to illustrate the work process (please note that the actual model for the experiment will be larger than this example!):

In a KIELER instance we get a given model:

We are in a group that works with interactive timing analysis that offers the overall timing value in the right upper corner of the model state ("Robot"), it is 2183. Also we get timing values for all three regions in their right upper corners. The first of the two timing values in each case denotes the share of the overall execution time that relates to this region, without its included child regions. The second timing value takes the child regions into account additionally. For example, the total execution time is spent in region "Main", but only 28 time units on the uppermost level, the rest is spent in the child regions. In addition to the region time values, the KIELER instance offers hotspot highlighting, which means here that the regions will be colored in different shades of red, which are related to the share this regions has of the overall execution time. For example in this case, about 98 percent of the overall execution time are spent in region HandleMotor, which is why it has a rather dark shade of red, while the other regions are almost white.

In addition to this model we get a sheet with information on alternatives for the host code calls in the model and with the specification on the maximum overall worst case execution time we want to acchieve:

Maximum Worst Case Execution Time: 500 tu

errorLog() / logErrors()

writeLog() / logProcess()

getImage() / takePicture()

Note that we get no information, on how long those function calls might take. The alternative might be better or worse than the original.

Now we can start to swap host code calls in the textual code to revise our model:

ExperimentExampleArrows.png

Suppose we decide to exchange the call to getImage() with a call to takePicture(). Then we will find, that the time values do not change at all:

Example1.png