Page 55 - The Mechatronics Handbook

from the customer. As mentioned, verification and validation are life cycle tasks, not tasks completed just
before the system is set for production. One of the simplest and most useful techniques is to hold hardware
and software validation and verification reviews. Validation design reviews of hardware and software should
include the systems engineers who have the best understanding of the customer requirements. Verification
hardware design and software code reviews, or peer reviews, are an excellent means of finding errors
upstream in the development process. Managers may have to decide whether to allocate resources
upstream, when the errors are easier to fix, or downstream, when the ramifications can be much more
drastic. Consider the difference between a code review finding a problem in code, and having the author
change it and recompile, versus finding a problem after the product has been sold and in the field, where
an expensive product recall may be required.

Debuggers
Edsgar Dijkstra, a pioneer in the development of programming as a discipline, discouraged the terms
“bug” and “debug,” and considered such terms harmful to the status of software engineering. They are,
however, used commonly in the field. A debugger is a software program that allows a view of what is
happening with the program code and data while the program is executing. Generally it runs on a PC
that is connected to a special type of development microcontroller called an emulator. While debuggers
can be quite useful in finding and correcting errors in code, they are not real-time, and so can actually
create computer operating properly (COP) errors. However, if background debug mode (BDM) is available
on the microprocessor, the debugger can be used to step through the algorithm of the program, making
sure that the code is operating as expected. Intermediate and final variable values, especially those related
to some analog input or output value, can be checked. Most debuggers allow multiple open windows, the
setting of program execution break points in the code, and sometimes even the reflashing of the program
into the microcontroller emulator. An example is the Noral debugger available for the Motorola HC12.
The software in the microcontroller can also check itself and its hardware. By programming in a
checksum, or total, of designated portions of ROM and/or EEPROM, the software can check to make
sure that program and data are correct. By alternately writing and reading 0x55 and 0xAA to RAM (the
“checkerboard test”), the program can verify that RAM and the bus are operating properly. These startup
tasks should be done with every product operation cycle.

Logic Analyzer
A logic analyzer is a device for nonintrusive monitoring and testing of the microcontroller. It is usually
connected to both the microcontroller and a simulator. While the microcontroller is running its program
and processing data, the simulator is simulating inputs and displaying outputs of the system. A “trigger
word” can be entered into the logic analyzer. This is a bit pattern that will be on one of the buses monitored
by the logic analyzer. With this trigger, the bus traffic around that point of interest can be captured and
stored in the memory of the analyzer. An inverse assembler in the analyzer allows the machine code on the
bus to be seen and analyzed in the form of the assembly level commands of the program. The analyzer can
also capture the analog outputs of the microcontroller. This could be used to verify that the correct PWM
duty cycle is being commanded. The simulator can introduce shorts or opens into the system, then the
analyzer is used to see if the software correctly responds to the faults. The logic analyzer can also monitor
the master loop of the system, making sure that the system completes all of its tasks within a designated
time, e.g., 15 ms. An example of a logic analyzer is the Hewlett Packard HP54620.

3.10 Summary
This chapter introduced a number of topics regarding a mechatronic system. These topics included not
just mechatronic input, output, and processing, but also design, development, and testing. Future chapters
will cover all of this material in much greater detail.

©2002 CRC Press LLC