Our test engineering department was tasked with providing automated production test capability for a new family of RF communications products. In-circuit test was to be used on all new circuit cards, but a new RF test station was required for functional tests of analog cards and units.
Many previously developed test stations were built as one-of-a-kind testers and did not provide much reuse for our new station. Also, the average experience in our department was about two years out of school. As a result, we had the daunting task of developing and integrating a new RF test station while meeting schedule and budget requirements—all with a young engineering team. Fortunately, our team was given full control of the project, and we designed from the ground up.
Requirements
The primary goal of the test station was to effectively test a new radio family with these requirements:
Audio to 1.5-GHz signals.
Data and communications ports (RS-232 and RS-422).
Five DC voltage levels with a maximum power of 30 W.
PROM programming capability to automatically tune RF cards.
Common RF measurements, such as sensitivity, harmonics, or transmit power.
We included several requirements to make the test station robust and flexible enough to be used on other existing and future products:
Digital I/O (up to at least 10 MHz).
Switch matrix to route RF and audio signals.
An interface to easily swap fixtures for different UUTs.
Fully automated built-in self-test of test-station equipment and wiring.
Common equipment that exists within our factory.
Modular hardware and software design to maximize reuse.
Less than a one-year schedule from conception to completion.
Test-Station Design
From the start, we understood that the cost of custom circuit designs and software could far exceed instrumentation costs. New circuit designs were avoided where possible. The major components of the test station were instruments, switching, software, computer control, and a standard interface.
Selecting Equipment
A fairly standard desktop IBM-compatible PC was chosen as the computer platform. It made future hardware and software upgrades simple and avoided the limitations of embedded VXI controllers (lack of ISA slots, cost, lack of spares, and upgrade complications). A reasonably fast PC (120 MHz) with lots of memory (64 M) was selected.
The test-station architecture is shown in Figure 1. Three standard control buses were implemented to automatically control the instruments from the PC:
PC ISA bus cards on a PC expansion chassis for low-cost digital I/O, communications ports, and PROM programming.
VXI chassis (through AT-MXI) for EMI-controlled switching and reduced size.
GPIB (IEEE 488.2) bus for RF test instruments. This was the most cost-effective solution, and similar instruments from the factory could be used to replace a defective instrument. With the availability of instrument front-panel control, these instruments also were effective for troubleshooting.
All instruments were selected as ISA-, VXI-, or GPIB-controlled other than a few high-power/high-frequency switches controlled through ISA digital I/O cards. Instrument selection was based on tests of loaner instruments from various manufacturers.
A tester interface was selected based on its mechanical robustness. It was mounted on the VXI chassis and provided a very short path to the switch matrixes.
Selecting a Software System
LabVIEW was chosen as the test-station software system. Although new to the department, it was selected as the best choice in an internal trade-off among other popular test-software development environments. Drivers were available from National Instruments for many of the instruments we chose, although we needed to modify most of them to add features, fix bugs, and fit our structure.
Assign Team Responsibilities
There was an obvious risk. Our team had little experience and was using a software-development platform new to the department. To mitigate the risk, one person spent six months learning as much about LabVIEW as possible. This enabled us to focus on coordinating software development and to design a software hierarchy.
Other assignments included one hardware designer, one digital I/O and buffer card designer, and several part-time software driver and modular test developers. Consultants were considered; but the team picked up LabVIEW quickly, and we felt confident on our own.
Modularity
Important features in the test-station design were modularity and reuse of hardware and software. A software system architecture was developed to maximize software reuse (see sidebar on Test Software Hierarchical Design).
This architecture resulted in test programs calling instrument types (handlers) that were cross-referenced in a station lookup table. As a result, a signal generator could be swapped with one from a different vendor, and only the tester lookup table needed to be changed for all tests run on the station.
Since the digital I/O and communications ports were based on ISA cards, many very low-cost mini test stations were used in the hardware design lab. These mini testers consisted of a PC with a GPIB card, a digital I/O card, and a fixture. Various instruments could be connected to the GPIB ports. Because of the software architecture, the same tests from the main station could be run with minor modifications as long as the drivers were written for the selected instruments.
Consequently, design and test groups co-developed design verification tests that were reused in the production test station and vice versa. This provided an effective and efficient concurrent-engineering environment.
Custom Hardware Design and Software Tools
Although we tried to avoid custom designs, a few were necessary. Our new products used both 5-V and 3.3-V digital logic. A digital buffer card was developed to provide selectable 3.3-V or 5-V logic levels and impedance matching. It was a stand-alone card controlled by digital I/O ISA cards. We located it in the VXI chassis to be close to the interface, even though it did not connect to any VXI signals.
We purchased a standard LabVIEW user interface for test-program execution, the Test Executive, but had to significantly modify it to meet our production requirements. A standard data-sheet electronic record was added to keep measurement results for each unit tested. It could be retrieved at any time. We also added an automated configuration management (CM) feature that recorded CM data, such as part number, serial number, PL rev, and date tested, to a central networked data base.
Two other software tools developed in-house are an automated station calibration routine and a switch path tool. The calibration tool automatically verifies internal station wiring and steps the operator through any cable connections needed to complete the calibration. Results are stored in a calibration table used by tests as correction factors.
The switch path tool automatically selects the shortest connection between an instrument and the tester interface. The developer simply enters the names of the end points and the tool simultaneously configures the switch connections. It simplifies test-program generation and retrieves the correction factors for the desired paths.
Results
We were very pleased with our results. The test station was developed and integrated with a modest budget distributed as:
45% for test-station hardware.
25% for nonrecurring engineering (NRE) software development.
20% for NRE hardware development.
10% for self-test design and tester integration.
Recurring costs for duplicate test stations and test programs were very low. Even though we were careful to have good software reviews and testing, many bugs and additional feature requirements were detected during the self-test integration. Integrating the self-test prior to any test programs was paramount to our success and effectively verified the station design and software.
Most instruments worked out well. It was easy to create LabVIEW drivers using standard GPIB and VXI routines. Only a few workable problems occurred.
Some noise migrated up to the tester interface from the ISA cards but was filtered at the digital buffer card. Noise also appeared in the switching, but it turned out to be SMA connectors that were not on tight. Integrating ISA cards that required vendor software created a few additional problems.
The tester was designed with roughly 10% to 20% spare I/O, ISA/VXI slots, and switches. This was very important because half of them were needed for unexpected requirements.
Summary
As long as you follow a few simple rules, developing a new test station can be less difficult than you might expect. Use standard instruments and components as much as possible and avoid inventing hardware.
Realize that software costs often exceed instrument costs. Consequently, it is critical to design a good software system concept up front. Likewise, hardware and software integration is very important and can be effectively integrated with a good test-station self-test.
The software system concept we developed allows us to swap instruments from different manufacturers with minor changes that are transparent to our top-level applications. A test program developed on our station also can be re-hosted to a completely new station by changing a lookup table and accounting for new switch paths.
About the Author
Ron Press is a lead engineer at Harris RF Communications. Mr. Press has been with Harris RF for two years and in the test industry for 10 years. He has a B.S.E.E. degree from the University of Massachusetts. Harris RF Communications, 1680 University Ave., Rochester NY 14610, (716) 242-4689, [email protected].
Copyright 1997 Nelson Publishing Inc.
August 1997