Features once reserved for special automated switches on production lines have migrated to desktop instruments.
By Eric Starkloff
National Instruments Corp.
A firm well known for developing integrated circuits embarked on an interesting project recently. The company began replacing a bank of mechanical switches that engineers there had cobbled together for routing signals to test instruments. Now obsoleted by modular instruments and software, the big, manually operated switch bank had been the only practical way of checking out new chips under development.
Of course, there never would have been a mechanical switch bank in the first place had this verification task been on a production line instead of the design lab. Automated test equipment (ATE) has long been available for characterizing products in production. But ATE systems have been feasible only because their relatively high costs could be amortized over the life of the product line. Engineers checking prototypes or new designs have had no such economies of scale. Manual testing has been the sole means available for such chores.
However, several developments have made it easier to set up comprehensive test systems that are economical enough for design and development. Among the most recent is the advent of commercial switchmanagement software. This is used for managing and defining routes through matrix switch modules.
Switch-management software is most useful in situations that need hundreds or even thousands of individual routes to connect each instrument to test points. At the hardware level, matrix switches are the method of choice for connecting any input to any output. One fact that complicates matters is that such switching systems can carry many types of signals — RF, high and low-bandwidth, power, and even optical signals can come into play.
Particularly large testing needs may require more matrix switches added to form even larger switching arrays. These conjoined modules use wires or terminal block connections to connect a row or column of contacts on one switch with the row or column on a second.
Software management of such devices can become problematical, especially during repair and debugging of completed switching systems. Before the advent of switch-management software, switch-control routines were buried within measurement test code itself. This sort of structure can make it difficult for a programmer to remember the mechanics of calling a routine for a certain connection path, or to recall every test that uses a specific relay. If even a single relay out of hundreds on a switch module fails, it has often been less expensive to replace the module than to reprogram the system and route signals around the damaged component.
Switch-management software avoids such difficulties by separating switch control routines from the test code. It works with other layers of software on modular instrumentation systems to let developers identify channels and routes with descriptive names. Users of the software can build routes and groups of routes using software tools that explain the attributes of individual switches. This sort of guidance lets developers see which switches can handle what kinds of signals. All in all, such software reduces the time it takes to configure complex systems and makes them easier to debug.
One program in this category is Switch Executive from National Instruments. It controls switch modules that comply with open instrument standards, treating multiple physical devices as one virtual device. Developers can also configure hardwires to describe the connections between each module to permit automatic routing of signals to any endpoint across the system.
It is useful in understanding the functions of a switch executive to review modern architectures for automated tests. Software modularity is the key theme: Test applications make use of what might be called test-management services that control tests. Programs that manage switch functions are part of this middleware. These software modules call to the hardware level through measurement services to make measurements, power up the device under test, change settings, and so forth.
Modular driver software, in turn, is made practical by a concept called IVI, for interchangeable virtual instruments. IVI was introduced in 1998. It attempts first to standardize the commands to which specific kinds of instruments respond. IVI also makes it possible to interchange instruments in a test system without drastically revising the application software.
IVI specs subdivide instruments into classes such as digital multimeters or oscilloscopes. Specs for each class are based on the most common features and functions of the most widely used instruments in that class. So far, the standards body overseeing the writing of these specs (the IVI Foundation) has defined five instrument classes and will eventually set up several more.
The IVI architecture further divides the traditional instrument driver into two parts: an instrumentspecific driver and a class driver. The instrument-specific driver works like a traditional instrument driver but includes instrument simulation. The class instrument driver contains generic functions for controlling an instrument category and calls the corresponding instrument-specific driver.
Engineers writing application programs can work with either the class driver or the specific driver. But test programs that use the class-driver approach abstract the instrumentation hardware details so the instrument can be interchanged in the future without changes to the test software.
Part of the IVI software consists of a support library the lets IVI instrument drivers do state caching and other actions such as range/status checking and simulation, all of which can be helpful in fielding systems. The library works with instrument-specific drivers to provide these functions.
Switch executives are built on top of the IVI class driver for switches. Consequently, they work with any switch driver that complies with the IVI spec. Besides working with PXI and SCXI switch modules from National Instruments, switch executives also control many third-party PXI, VXI, and GPIB modules.
The usual way of interacting with a switch executive is through a test-management tool such as the TestStand program, also from National Instruments. Developed in 1998, this program takes care of common test functions such as sequencing tests, collecting results, and creating reports.
Using TestStand, developers can encapsulate configuration and measurement for a test into a sequence of steps. Configurations defined in the Switch Executive program can be incorporated into testing steps without getting the switching code too entangled in the test application itself. Switch Executive also validates the IVI devices, routes, and route groups in the application, returning any errors that need correction.
Alternatively, developers can interact with the Switch Executive through LabView. The LabView code can make calls to the Executive and refer to routes through the switch by name. As such, it is easy to update the switch path through the Switch Executive configuration environment while low-level LabView calls remain unaffected. This approach is often practical when there only a few switches involved in testing.
All in all, the ability to decouple test code from the physical implementation saves a lot of time in development, maintenance, and support. Modular hardware and software limits the time needed to test products so developers can spend more of their energy on creating new designs.