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

2. 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

3. 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.

4. Embedded systems in contrast to other computing systems

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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.

12. 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!