Explore model-based testing for production hardware(2)

Furthermore, with the corresponding external tools, the interface is also useable with different programming languages such as C, C++, C# and other .NET frontends. A dynamic link library (DLL) written in C++ forms the connection between TPT and the Universal Debug Engine (UDE). This means that in every simulation step any debugger functions can be selected and, for example, breakpoints can be set fully automated. At each of these breakpoints, the user can precisely define which variables of the System under Test (SuT) can be read out or filled with predefined data. Furthermore, the execution can be continued at any position by changing the instruction pointer. This approach provides a great advantage over other couplings, which can only change and determine variables via the interface to the SuT. A great advantage is that additionally any memory spaces and registers of the target hardware, individual bit positions and even local variables from functions can also be set and read out. Hence, it is now possible for the first time to not only prove or refute the functional correctness of the SuT, but also at the same time to show why the SuT does not behave as expected. Since in each simulation step several actions of the UDE debugger can be executed on the target hardware, testing functional correctness of software/bypass hooks of the SuT is also possible, fully automated.

Figure 3 shows the configuration of UDE coupling with the TPT technique.

Figure 3: Configuration of the tool coupling TPT with UDE as target access.

In the upper table, breakpoints on the target hardware are determined. In the table in the middle, actions to be performed by the UDE debugger per simulation step are determined. In the lower table, to be set and/or to be read out variables of the target hardware and of the SuT are determined. The breakpoints can be set by the user either at an absolute hexadecimal address, at the beginning of a function, at the end of a function – defined via the function name with hexadecimal offset or by means of keyword endof() – or at a specific line in a source code file.

A state machine is used for the description of the individual actions that are to be performed by the UDE per simulation step. In this state machine, the breakpoints are the states and state transitions are described by continuing the execution to a certain breakpoint (keyword: run) or by changing the instruction pointer (keyword: setNextStatement). With that, an action which should be executed one time, for example memory initialisation, can be separated from the actual test execution because the control steps for the UDE will not processed line by line from the table 'Program' in the middle (Figure 3). In the given example the first three lines are executed once after program start and then with the next two lines the execution is continued. The test flow goes from function_start via function_middle to function_end. Through program execution as state machine, the subsequent steps are in the last line, followed by the previous. The test iterates again at function_start from this point.

Conclusion
Testing of highly-complex embedded software increasingly requires integrated approaches at the system level and model-based methods. The role that hardware-related debuggers will play in the future, which since some time now show an emerging paradigm shift, will depend particularly not least on how simply and reliably their functionality can be used by other programs within the tool chain. As clearly shown by the example of close interaction of TPT and UDE, entirely new workflows are conceivable here in the ideal situation. These new workflows open up completely new opportunities for developers, in particular with regard to automated test techniques.

About the authors
Dirk Tetzlaff (Dr.-Ing.) completed his studies in computer science in 2007 at the Technische Universität Berlin (TU Berlin) in Germany. Following that he was on the scientific staff at the Institute of Programming Embedded Systems under the direction of Professor Dr. Sabine Glesner, where he received his doctorate in 2014. Since then, he works as a software engineer and consultant at PikeTec GmbH.

Heiko Riessland (Dipl.-Ing.) studied information technology at the Technische Universität Dresden (TU Dresden) in Germany. In 1992, he began his career as software developer at PLS. After several years he moved to sales of software development tools for 16bit and 32bit microcontrollers. During the past eight years, Heiko is heading product marketing at PLS GmbH.