Page History

...

What we cannot detect in this picture is any information on whether this implementation is correct as to the timing specification. Does the worst tick of this model take longer than 300 time units? To answer this question the modeler would have to generate code from the model and invoke a timing analysis tool on the code. The analysis tool would return a (single) time value. If this time value is too high, the modeler has to return to the modeling process and go on. Additionally there is no information as to where the most time consuming parts of the model are to be found. To relieve the modeler of such a tedious process, we developed the Kieler Interactive Timing Analysis (KITA). Its central idea is to interactively feed back timing information to the image of the model. This can not only be done for the model in general but more detailed for model parts. Additionally we highlight the costly regions of the model with different shades of red, according to their contribution to the overall worst case execution time for one pass of the tick function for the SCChart:

The time values shown in the right upper corners of the regions denote the region's share of the overall worst case execution time of the model for a single tick. The legend is <flat exectution time value>/<deep execution time value> in which the flat timing value does not take child regions (regions that are contained in this region) into account, whereas the deep timing value inclues their share of the overall execution time. Now the modeler can see that the specification of 300 time units is violated. Additionally the hotspot-highlighting points to the most costly part of the model, which is the region HandleMotor, whose time value alone exceeds the timing specification. The model might now be revised to another version:

Image Added

In the new version, getImage() and writeLog() will never be executed in the same tick anymore. The interactively updated time values confirm success: The time value now meets the specification.