3.3 - GUI Simulator for Automated Testing of Embedded Systems
- Event
- etc2016 - 36. European Telemetry and Test Conference
2016-05-10 - 2016-05-12
Nürnberg, Germany - Chapter
- 3. Video & Data Management
- Author(s)
- A. Walter, F. Weber - macio GmbH, Karlsruhe (Germany), T. Rupp - macio GmbH, Kiel (Germany)
- Pages
- 104 - 108
- DOI
- 10.5162/etc2016/3.3
- ISBN
- 978-3-9816876-2-0
- Price
- free
Abstract
Software Developers for embedded systems are often confronted with the situation that development tools are less mature than their pendants for desktop systems. During the development process in general, and in particular for automated testing, it can be very helpful to do frequent test-runs on the host rather than on the embedded system. Special care needs to be taken for the GUI and for lowlevel components like sensors.
This paper summarizes the experiences macio made with simulators in three embedded projects. With relatively little effort, it was possible to port bare-bone GUI applications which are based on low-level graphics engines (bare-metal on a framebuffer devices or simple APIs like emWin) for Linux. The main effort was the implementation of the respective low-level driver layer for the host platform, such that the original source code used on the target could be compiled for the host platform and the resulting binaries can now be executed on the host. Consequently, the screens of the resulting simulator are pixel-identic with those on the target platform.
Another benefit of this approach is that building for a second platform generally improves the robustness of the application, because it increases the probability to trigger timing-related bugs or bugs due to side-effects which may rarely become visible on the original platform. On the host, the required time for a build-and-run cycle is dramatically reduced compared to crosscompilation and download to the target system. In total, the simulation typically reduces the turnaround time from several minutes down to a few seconds. We measured built time improvements from 6 minutes to 19 seconds on the same host. Also debugging becomes much easier and elaborated tools like Valgrind can be used for finding memory leaks and other runtime errors.
As a benefit for sales and marketing, the simulator can be used for presenting the final application to customers or producing screen shots for the documentation or brochures.
Also, the simulator can easily be integrated in automated test runs. Embedded devices often lack the possibility to generate screen shots or the memory for collecting test data. The automated handling of loading a test-program, executing it and transmitting the test-results back to the test server often is a difficult task.
Two general strategies are possible for the integration of sensors and other components: The communication can be recorded and played back by a simulator. Tools like CANoe provide morecomfort and allow the execution of scripts for the simulation of smarter and more complex components. An alternative would be to only run the user interface on the host, while the non-GUI part of the application is executed on the real embedded hardware.
The paper elaborates on the benefits and limitations of the given approaches and gives guidance on the integration of the embedded device with the simulator.