Page 216 - Embedded Microprocessor Systems Real World Design

late a failure. You will occasionally hear someone say they have so much confidence
in their design that such testing is not necessary. My experience is that an unwill-
ingness to test tends to betray a lack of confidence in the design.
On some systems, where safety is part of the embedded design, special tests may
need to be performed to verify that safety systems work. For instance, to prevent a
hazard, a system may need to shut down a motor if the operator opens a door on
the instrument. It is not uncommon to have interlocks on such a safety-related part
of the system to insure that a single point failure (one of the interlocks sticks in the
“door closed” state) does not cause a safety problem. In this case, you probably
need to design a verification test to ensure that either interlock will result in a motor
shutdown. You might want to go a step further and test with one interlock working
and the other one oscillating to simulate a bad connection in the wiring. In many
cases, you will use a Failure Mode Effects Analysis (FMEA) or event tree to formalize
the analysis of such failure effects. Although using these tools is outside the scope
of this book, the results of such analysis will drive the verification requirements for
your system.

Problem Log

On most projects, the first round of functional testing shakes out some problems.
I recommend a problem log for any project, especially for large projects. The log
should list any errors encountered, how they were uncovered (what conditions or
functionality was being tested), who is responsible for fixing the problem, and when
it was fixed. An electronic log is sufficient, but a paper log near the test machine
makes jotting things down easier. Do not try to use a problem log from the first day
of debug, when the basic design is being debugged. The number and frequency of
problems will make keeping the log up to date a chore, and it will not get done.
This is especially true if you are working on multiple projects simultaneously, which,
of course, you always are. A problem log might seem like overkill for a project with
one or two engineers, but it keeps minor problems that were put on the back burner
from being forgotten completely.
When a problem is fixed, there is a question: How much testing is needed to
prove the fix and verify that the fix did not introduce new problems? In a high-
reliability system, it may be necessary to rerun the entire suite of tests. Some other
systems may require only regression testing to verlfy the area of code or hardware
that was changed. It is easy to say that only limited regression testing is needed, but
be careful. A code change that seems innocuous may have far-reaching effects, espe-
cially if it interacts with other processes.
Once everything is working, the final step is to test the complete system against
the original system requirements. This seems obvious, but sometimes a design team

System Integration and Debug 197