DFT Solution (A Software Framework for Improving the Testability of Embedded Real-time Systems)
| Attachment | Size |
|---|---|
| TE_WP3_VTT_1_S001_Probe_Framework_MThesis.pdf | 744.62 KB |
This solution provides an open-source tool implementation for collecting information from embedded Linux environments and a method describing guidelines for how to use it and include it in the system design. The tool is provided as ready-made component(s) to capture observations from different parts of a system, including monitoring kernel and user space functionality and resources. Guidelines are based on DFT experiences collected from industry as well as tool prototyping.
Testing is currently done in ad-hoc style for each case, meaning that everything is done from the scratch every time, i.e. uniform test methodologies are missing. Even though testing is the most expensive part of the system development process it is often considered irrelevant for design, and is overlooked by many. However, with growing understanding of these facts the trend is slowly moving towards DFT. Our method provides the basis for instrumenting the system for testing purposes, considering especially the specific properties of embedded real-time systems; such as real-time requirements, resource constraints and extensive platform access.
On a higher level, the tool (Probe Framework, PF) is a part of a larger concept which includes three main components. The PF provides the needed support as a platform to capture the trace information from the system under test. An information database server is used to collect the trace information and provide the means to query, filter and export the trace to analysis tools. Various trace analysis tools can be used to analyse the information provided. This includes tools specifically for trace analysis and also tools more generally intended for analysis of data, such as multivariate analysis. In addition to making use of the captured information in external analysis tools, it is also possible to make use of it as part of built-in product features for processes such as adaptation, testing and analysis. This overall architecture is described in figure 1.
Fig. 1. High level PF collaboration
The Probe Framework itself has a layered architecture. The PF’s architecture is divided in three main layers; Basic services, monitoring services and test services. The term probe, in the context of this paper, means the entity that is formed by utilizing the different service layers to create the functionality for collecting and handling the monitoring of some aspect of the target system. Each layer builds on the functionality of the layers below it, as described in figure 2.
Fig. 2. Layered architecture
The basic services contain services deemed necessary for information handling, such as data buffering, storage and relaying to external database. The basic services are general for all the probes, and offer the support for fast implementation of the upper level services. The basic services comprises of three parts; first part is the probe interfaces, second is the binary formatter and the third is the communication handler. These are illustrated in figure 3. Together these parts take care of all the data management of the tracing as described in figure 1.
Fig. 3. Structure of basic services
The monitoring services offers a set of readily provided interfaces and probes to attach to the basic services. The actual services at this layer are used to capture and monitor different values, such as memory consumption and CPU usage, and their evolution in the system. Many of these basic monitoring services are provided as ready probe components in the implementation of the PF, including CPU load, memory consumption and network traffic monitoring. Further, they provide simple interfaces for building new monitoring services on top of them without the need to concern with the complex internal details of the data management.
The top layer, test services, is the most implementation dependent and is where the system specific functionality can be build. It relys on using the basic services and monitoring services. For example, functionality can be built to inject test data into the system, use a provided set of monitors to see how the system behaves and store the test results using the basic services. Similarly, in a running system the same monitors could be used from a test service (or more accurately, built-in functionality) that adapts the system’s runtime behaviour and use of components based on thresholds set for monitored values such as memory consumption, CPU load and network traffic patterns.
Source: M. Pollari and T. Kanstrén, A Probe Framework for Monitoring Embedded Real-time Systems, ICIMP 2009.
- Login to post comments
