Embedded Systems
Computer systems that cannot be programmed by the user because they are preprogrammed for a specific task and are buried within the equipment they serve. The term derives from the military, where computer systems are generally activated by the flip of a switch or the push of a button. The continual increase in the densities of ever-smaller microprocessors, on silicon chips that fit on a thumbnail, and the attendant decreases in their costs, has pushed the concept of Embedded systems well beyond the original military applications.
Embedded Systems
are also used in industrial, automotive, consumer, and medical applications.
Often the development of such systems requires the use of simulation tools. A “basic test” phase with a simulator is the first mandatory step in a comprehensive test strategy aiming at discovering and fixing all kind of faults.
In the next phase, the “basic tested” software is loaded on the target hardware (a microprocessor, DSP, multi core ASIC, FPGA) where the interaction with the real hardware is tested: a second type of fault will be discovered here. These faults often require more time to be analyzed and fixed; typically this is run in the lab with all the needed instruments available for tracing and troubleshooting.
Embedded systems is by definition difficult to test: when running on the target, the code is not always reachable; debugging tools their limits; sometimes the software designer may have to code using assembly; hardware devices may have bugs–just to mention a few typical barriers to a fault-free embedded software application through proper Embedded systems.
In recent years, multi core technology in Embedded systems has contributed to increasing the complexity of Embedded systems, showing a very interesting opportunity to find efficient solutions to problems requiring high performance.
As pieces are put together and the system grows, more complex functionalities will be tested, and a third type of faults comes up that originates from interaction of the many integrated software parts.
When the system is almost complete and under test for days, a fourth type of fault is likely to show: a crash or a stopping fault. Here, finding which part of the system is misbehaving is usually very hard; in fact, this kind of fault is not easy to reproduce and when you succeed in reproducing it, you realize you need more logs and tracings. Time passes by and the software… is still unstable.
What is the best approach to deal with such problems? Maybe nobody has “the” answer, but we successfully tried the approach to address the fault localization with a minimum human troubleshooting effort.
