Solar Car Power Management

Testing

© 1996
Paul Vincent Craven
All Rights Reserved


Testing for Sunrayce '95 was very difficult, given that the car wasn't finished until a month before the race. This didn't mean that we could not test, just that it was more difficult and less extensive.

We employed one laptop to provide simulated data from the solar car. This laptop would create sample data packets and send them at 9600 baud over a null modem cable. A null modem cable allows two computers to be hooked together through their serial ports. We had the laptop send random data, sine curves, flat, and saw-tooth signals. Random errors, such as short and long packets, were programmed to be sent. This allowed testing many of the components of the power management system.

Rapidly changing specifications of the on-board computer's data packets presented some redesigning problems. But due to the object-oriented nature of the program, these changes were confined to the data acquisition thread, and the data base engine we used. Changing the number of sensor values from 32 to 64 only required two lines of code to be changed. Complete redefinition of the packet format was confined to changing less than a hundred and fifty lines of code.

Using a program called Bounds Checker Bounds Checker NT aided in finding many programming errors that were not immediately apparent. Bounds Checker looks at every call to the Windows API and checks to make sure that all of the parameters are valid. If a parameter is invalid, and a program doesn't check to see if there were any errors in making the call, then the program will continue to execute without regard the fact that the last command didn't do anything. Bounds Checker also finds memory access errors. If I try to access memory location 101, when I only asked for 100 locations, the results are unpredictable. With Bounds Checker, illegal accesses like these are reported, along with failing to return memory to the operating system, and returning memory that you never allocated. Errors like these may not be apparent in initial testing, and even if they are, it is exceedingly difficult to track them down. Using Bounds Checker helped to increase the robustness of our program by locating the problems before they occurred.

Testing for the '97 car, however, should not be as difficult as the '95 car. This is because we have a working solar car to do the testing on. Very little will need to be changed in order to move a working power management system from the old car to the new one. All of the necessary information about the car is editable by the user at run-time. The electronics of the power management system are separate from the rest of the solar car, not relying on any design feature of the car. All that is needed to begin testing is a working on-board computer and working software to run it. As on-board programs are by necessity rather small, the real challenge is to come up with the financial support.