In modern automated test systems, software often is the most complicated and expensive part of a system design. In the past, our department wrote code ad hoc with little or no commonality among various UUTs and test platforms.
As part of a recent effort to design a state-of-the-art test station, we broke from the past and developed a robust, reusable modular software structure for all new functional test developments. The block diagram outlines the hierarchy we designed and implemented in LabVIEW.
An instrument driver is a collection of functions that controls a single equipment model through an interface such as GPIB, VXI, or ISA. We used Virtual Instrument Software Architecture (VISA) device calls to simplify GPIB and VXI development, and we created our own analogous architecture for ISA instruments.
Each driver contains an initialization function that opens a session using a provided bus address and returns a unique session number. The session number is a required input to any other driver function to identify which instrument to control.
The direct use of instrument drivers became clumsy and inflexible for large systems. We required another layer of abstraction.
An instrument handler is a collection of functions that controls all models of an equipment type. Handlers are used as a generic representation of an instrument in test code. They allow the programmer to develop software independent of equipment model details.
The trickiest part of designing handlers is accounting for instrument-specific features. When possible, parameters are coerced to make these differences transparent to the end user, but some incompatibilities may require extra care during system integration.
Each handler contains an initialization function that calls the appropriate driver initialization based on an array of parameters including the equipment model and bus address. The model name and the assigned session number are stored in a lookup table.
All other handler functions simply use an instance number to index into this table to determine which specific driver to use. As a result, the programmer does not track VISA session numbers and can easily reference multiple instances of the same or different models of an instrument type.
Continuing up the system hierarchy, we found additional opportunities for abstraction. For RF testing, several standard types of measurements were performed on many UUTs, such as transmit power output, receive sensitivity, and harmonic distortion.
Wherever possible, we created reusable modules to perform these tasks minus any UUT-specific setup. Using this strategy, we developed robust procedures for complicated measurements, with great cost savings for subsequent test development. These reusable modules are especially effective since they call handlers that allow them to deal with general classes of instruments rather than specific models, making the measurements fully transportable among different station configurations.
Throughout our software projects, we aimed for a modular design with maximum reusability. This philosophy allowed us to create a large system that was easy to use and flexible enough to work with various hardware configurations. Also, any problems with a reusable module could be fixed in a single location and automatically folded into every application that calls it.
Caution is required, however, since any change can affect multiple programs. It is important to maintain strict control over reusable functions and to carefully review any changes prior to system integration. Finally, for any reusable hierarchy to work, you must define a solid structure up front and educate all developers on how to use and contribute to it.
About the Author
Roddy Shuler is a senior engineer at Harris RF Communications, where he has worked for three years. Mr. Shuler holds a master’s degree in electrical engineering from Stanford University and a bachelor’s degree in biochemistry from Cornell University. Harris RF Communications, (716) 242-3499, [email protected].
Copyright 1997 Nelson Publishing Inc.