Automated power

An exclusive interview with a test engineer

By Martin Rowe, Senior Technical Editor -- Test & Measurement World, 9/1/2010 12:00:00 AM

Sambit Panigrahi is system integration and tools lead in the battery-management solutions group at Texas Instruments (Dallas, TX). He's responsible for integrating systems used to test ICs such as battery fuel gauges that manage power for rechargeable batteries. The gauges can support batteries that are available in more than 600 different packages and chemistries and may have up to four cells. Senior technical editor Martin Rowe spoke with Panigrahi by telephone.

Q: How do you test battery fuel gauges?
A: The power-management devices are really microcontrollers with analog front ends, so a test system tests the firmware for how the device responds to known physical conditions. Our battery fuel gauge ICs are SBS (Smart Battery System) compliant and thus must meet SBS specs so end users can easily swap devices from multiple manufacturers.

We create test conditions by applying voltages and currents with source-measure units from Keithley Instruments. We simulate temperature with a digital potentiometer that acts like an external sensor. We have practically no test components inside the firmware in our devices to aid our testing, so we don't "trick" the devices to think that they are experiencing anything. We do, though, send commands to change the device modes, threshold values, and so forth. Our devices have RISC processors and limited memory. By changing the flash-memory contents in the devices, we can place a device in different modes. We then change physical conditions to test that mode.

Q: What responses do you look for?
A: We typically run as many as 200 tests on each device. We test conditions such as overvoltage or battery temperature. By setting the battery voltage too high, we check that the controller responds correctly. That is, it must trigger an error flag that the tester can then interrogate and verify that the correct trigger occurred.

Q: How have you structured the test software?
A: The software is based on National Instruments' LabView and TestStand. TestStand lets operators set test parameters and conditions. We've developed automated scripts that execute the tests. LabView executes the scripts by communications through drivers encapsulated in DLLs (dynamic link libraries) and OCX (object linking and embedding control extension) files.
The DLLs are sometimes packaged in executable files that we distribute to customers so they can test their battery assemblies. LabView calls the drivers and runs the tests, reporting the results to TestStand.

Q: Which other departments do you work with when developing the testers?
A: We work with firmware engineers within the company, but we also work with field-applications engineers who have direct contact with the customers. We do most of the data gathering in Dallas as well as some of the software development. Some of the software development also takes place in India.

Q: What were the major challenges you faced when developing the testers?
A: People were used to performing these tests manually, without automated scripts. Thus, they had to get used to an automated system. With the old system, sending a command to a controller that set a voltage and waiting for a response could take between 8 s and 10 s, and the test operator could see when the controller under test responded to the stimulus command. The operator could then check the appropriate alarms. With automated systems, we had to program the systems with greater accuracy to wait, say about 10.25 s, before checking the device under test.