In Part 1 of this mini-series we introduced the concept that any manufactured product should be tested. Of course, a key aspect to testing is controlling the test. There are numerous approaches to creating the circuitry required to test any board. It is vital to remember that the test equipment documentation is as important as the product itself. The product life cycle can extend beyond expectations. Test jigs are shipped back and forth to subcontractors, stacked on shelves, and abused in many other ways (sometimes intentionally), so they have to be rugged.
Quick and dirty
It is sometimes possible to make your test equipment very quickly and cheaply, as you can see in Figure 1.
Figure 1. Comparators and a simple PLD sequence generator with hexadecimal readout of failure codes, hand-wired on protoboard, form the heart of this test equipment.
This approach has some problems as well. The second unit takes just as long to build as the first and is rather fragile. Nevertheless this piece of test equipment has worked for 18 years with only one solder connection breaking.
Design your own
Sometimes there is just no commercial equipment available to meet your unique requirements and you simply have to design your own. For example, we required a method of generating a stable 100 amps AC, preferably without high voltage or heat. Of course, creating the equipment can be a huge project in its own right. The problem with this approach is that it drains corporate resources and -- if the project needs multiple iterations -- you may have to compromise on the requirements.
Figure 2. This device, together with a user interface on a PC, will generate up to 100 amps AC. The current is controlled by a closed loop system implemented using an 8052.
If you have a microcomputer on board, and provided you have sufficient memory, the whole test can be implemented as an integral portion of the firmware.
Figure 3. On the unit shown here, the test process is invoked by a jumper. When an input is activated a corresponding output activates. One problem with this test is that diagnosing where the fault lies is fairly coarse. (It's somewhere on the input or output path.)
If there is not enough processor memory, you can start by downloading the test software, and then reprogram the flash with the operational firmware after the test has been completed.
The approach I have taken most often has been to use a central controller and then to add standard external peripheral functions. This could be a standalone microcontroller board that is commercially available (as described in this article), or a PC controlling PC-installed cards (A/D converters etc.), or even a PC accessing external standard components as seen in Figure 4.
Figure 4. In this test jig, the control program (written in BASIC) interfaces to industry-standard ModBus modules. Even with the wide variety of options that are available with this approach, every so often you still have to make something custom.
Communication from the PC to the on-board micro allows the PC to set inputs to the DUT (device under test) and query if they have been seen, and also request that an output be set and check that this actually occurred.
There are some commercially available devices that are meant specifically for the test market, such as the FT-100a from Y-tek, but it seems to me that our likely direction forward is to a hardware/software solution like Labview.
In any organization, staff moves on, and in many cases maintaining a test jig is becomes difficult. Furthermore, is the test process occurs remotely -- in Asia, for example -- maintenance becomes an issue. For both these reasons, a universally understood approach has its attractions.
All of the above assumes that you don't have the resources to access a dedicated test system like the ones from Teradyne. These machines will allow you to track a fault down to a specific component. An alternate approach would be to use boundary scan testing (the original JTAG application).
Table 1. Pros and cons of the various test approaches.
(Source: Click here to see a larger image.)
- Reproducible: Ease with which a second or third unit can be made
- Transportable: How will the unit handle shipment to subcontractor?
- Ease of maintenance: How easy is it for others to fix?
- Required specialist knowledge: How much do you have to know to create the test jig?
- Universality: Can the unit be designed or modified by a subcontractor?
- Granularity: How close to an individual component can the system diagnose?
In my next column I will be presenting some "Lessons Learned." In the meantime, I welcome your questions and comments.