Software testing and configuration : Embedded software testing Vilnius university – mif – nassim marzouk

Contents What is in a embedded software? Differences from application software Why test? Main differences with application software testing Testing of Embedded Software TEmb Method Overview The application specific measures Summary

What is an embedded software? Software written to control devices that are not typically considered as computers Typically the only software on the device in question No or not all functions of embedded software are controlled via a human interface, but through machine-interfaces instead Used in avionics, cars, telephones, modems, robots, televisions and digital watches Can vary from very simple (lighting controls running) to very sophisticated in applications such as airplanes or missiles control systems.

Embedded systems in contrast to other computing systems

Differences from application software Has fixed hardware requirements and capabilities Often used in applications in which human lives are at stake Your company can be sued if your code fails From a testing point of view, we can not afford any errors

Why test? To find bugs in software To reduce risk to both users and the company To reduce development and maintenance costs To improve performance

Main differences with application software testing First, because human lives are at stake, you have to test to a higher level of reliability than if you were testing application software Second, due to the conditions under which embedded systems are used, the simulation of its actual environment may be expensive, difficult, or dangerous Third, we have to face the difficulty in seeing the output : Since embedded systems are usually connected to devices, their generated outputs are not in the form of a message on the screen, but they may be a command to handle the device or write something in memory

Testing of Embedded Software Basic rules of software testing also apply to embedded software Here, integration testing can be divided into 2 : software integration testing software/hardware integration testing Difficulties : On the one hand, we can not afford to wait the end of the development phase to start testing embedded software From the other hand, one special characteristic in embedded software development is that the actual environment, in which the software is run, is usually developed in parallel with the software. This causes trouble for testing because testing cannot be performed due to the lack of hardware environment

TEmb Method Overview Introduced by Broekman and Notenboom The test approach is divided in 2 parts : the generic elements applicable to any structured approach : Managed by lifecycle, infrastructure, techniques and organization => LITO the application specific measures : The aim is to define the application specific characteristics that dictate the specific measures

The application specific measures safety critical : if can cause serious physical damage technical-scientific algorithms : for vehicles, missiles or robots autonomous : such systems are designed to work continuously one-shot : released only once (satellites) mixed signal : systems that contain, in addition to binary signals, analogue signals hardware restrictions : memory usage and power consumption state-based : depends not only on the input, but also on the history of previous events and states hard real-time : the exact moment that stimulus occurs influences the system behaviour control in extreme environments : require simulation of the environment behaviour

Summary (1) Embedded code often has dependencies on hardware or a real time operating system Most embedded developers only run their code in the target execution environment => often means a heavy reliance on manual testing Most embedded development is done in C or C++, languages that you can write portable code in. If you do manage dependencies on HW and RTOS, you can create target independent unit tests. These help you get the code doing what you think it should do.

Summary (2) Thank you for your attention! This leads to a lot of waste waiting for hardware to be developed waiting for the HW engineers to find hardware problems waiting for long build/load cycles debugging in hostile target environment Thank you for your attention!