Zdroj: |
Aachen : Fachgruppe Informatik, RWTH Aachen University, Aachener Informatik-Berichte 2013,20 II-XI, 126 S. (2014). = Zugl.: Aachen, Techn. Hochsch., Diss., 2013 |
Popis: |
Model-based approaches in the development of embedded software become more and more widely spread. In these approaches, different models of one target system are the central elements. Recently, a growing number of algorithms and functionality of embedded software are designed using such model-based approaches. In controller design, Rapid Control Prototyping is a prominent example. Its main advantage is the possibility to develop functionality of both the controlling embedded software and the controlled system in one modelling environment. Additionally, the developer can simulate the whole system and improve its performance, debug algorithms, etc. in early development stage. Important test phases are Software in the Loop and Hardware in the Loop. In this work, we discuss two problems that may occur during these phases. The first question is: Taking into account the continuous characteristics of system variables, how can we safeguard a consistent evolution of the development artefacts? To deal with this problem, data resulting from testing these artefacts under the same stimuli is compared. Since different artefacts were tested at different stages of the development under different conditions, we cannot expect that the results of each test case to be exactly equal, but at most similar. This similarity check of continuous systems is addressed in this work. The methodology presented here is based on behavioural black-box models of our system in the time domain on different levels of abstraction. A behaviour is represented by the input and output signals of a system and their interrelationship. On each level of abstraction, a system's model is put up by a set of behaviours, each of which consists of input signals and the according output signals created by the system. The description of the signals themselves varies strongly, depending on the level of abstraction. PFL as a reference to compare it with a oracle's behaviour. For the comparison of two systems or artefacts, we have to introduce a similarity relation with respect to an abstract model. Two systems are similar with respect to an abstract model A, when their behaviours conform to this abstract model A. The central question is how we can find properties in measured signal data. To find a characteristic property in a set of measured signal data, we compute the cross correlation of the interpolated measured data and a template signal. By this, we find on which time interval of the measured data one property potentially occurs. Repeating this for all properties yields all occurrences of the properties in the system's abstract behaviour model. In the end, we know that these systems conform to the abstract model and therefore are similar with respect to the abstract model. The second problem we address is: Given real time test devices that are less expensive but have clocks with unknown precision, how can we make sure that the test results obtained from these devices are valid? The motivation here are possible differences in sample timing due to not exactly working hardware timers. Due to this, a drift occurs in the sampled data which leads to distorted signals and seemingly wrong timings of events. We compare such a signal to one obtained with a certified device by searching for certain properties, and obtaining the points in time of the occurrences. Using these time information, we can estimate the difference of the sample times, i.e. the drift. For the search for properties we use the cross correlation approach already used for regression tests. |