Verification and Validation
Verification and validation are related tasks that should be completed throughout the life cycle of the
mechatronic product or system. Boehm in his book describes verification as “building the product right” while validation is “building the right product.”
In other words, verification is the testing of the software and product to make sure that it is built to the design. Validation, on the other hand, is to make sure the software or product is built to the requirements 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.
