The search for maximal test instrument interchangeability with minimal test program modifications has made a lot of progress in the last five years. But work by the Interchangeable Virtual Instruments (IVI) Foundation, a consortium of instrument developers, users, system integrators and prime contractors (see box on page 32), promises to bring the industry closer than ever before to that goal.
Digital multimeters (DMMs),
Arbitrary wave-form/function generators, and
DC power supplies, the first four of which were approved late last year.
Part of the user interface, these command sets will enable users to address each device in a class—regardless of the manufacturer or bus connection—in a standard way. New specs for related IVI "class drivers" also have been approved. (Instrument drivers are the software modules used by test software to communicate with and control test instruments.)
According to James Kimery, director of test and measurement marketing with National Instruments, a second set of instrument classes is expected to include the following:
The IVI Foundation also is developing architecture standards. Chairing separate IVI architecture specification groups, Agilent and National Instruments take somewhat different design and programming approaches, but they target the same goals. IVI is the biggest, most coordinated standardization effort seen by the test industry in the last 15 years, says Paul Salopek, a program director with Marconi Integrated Systems. "IVI is trying to address the crux of the matter, getting a level of interchangeability between instruments that’s never really happened before."
"IVI takes off where VXI Plug & Play left off," Kimery adds. IVI drivers are hardware-independent, embracing not only VXI, but also GPIB (general purpose instrument bus) box-type instruments and PC standards such as PCI, ISA and PXI, he says. Instruments based on the IEEE 1394 "firewire" spec, when they emerge, would also be covered, he says.
Airframe manufacturers, too, praise the IVI Foundation’s efforts. A spokesman for Boeing, an IVI member, says his company "encourages and actively supports the development of industry standards that advance the goal of reducing ATS [automatic test system] development and factory life-cycle costs."
"Using IVI drivers, [instrument swapping] can be as simple as changing a configuration file," Kimery says, whereas, under VXI Plug & Play, engineers often would "have to change every call to a driver and recompile [test software]." Although with some instruments, "100% interoperability will be out of reach" because they don’t share the same exact features, "80% to 90% interoperability is better than zero," in that there will be fewer software changes required than in the past, he says.
But VXI Plug & Play drivers will not become obsolete in the next few years. "A lot of aerospace companies have a lot of interest in VXI, " says Rick Robinson, Agilent’s general manager for measurement connectivity operations. "We have to underscore that [the evolution to IVI] is a gradual process."
IVI also adds support for features such as: multi-threading, which is required for today’s operating systems; state-caching, to minimize bus traffic and eliminate redundant instrument commands; and simulation, Kimery says. Support for software simulation of instrument signals is important for customers who want to be able to prototype test software without actually having to have a physical instrument and a hardware connection, says a National Instruments official.
What’s been done so far, however, is only a first step, says Joe Mueller, senior connectivity architect with Agilent. To interchange instruments, you have to define the driver environment, he adds. This is being done through IVI architecture committees chaired by Agilent and National Instruments, respectively. The former group focuses on a spec based on Microsoft’s COM (Common Object Model), with documents expected by the second quarter of this year. The latter, focusing on a C language-based architecture, is documenting architectural work that National Instruments already has accomplished, Kimery says.
Agilent, National Instruments, Vektrex, TYX and other companies already have demonstrated instrument interchangeability, using IVI class and prototype COM-based architecture specs within the Visual Basic, C, C++, LabView, CVI, Excel (VBA) and Atlas software development environments, Mueller says.
In the demos, engineers replaced one scope with another, changing the instrument-specific driver and the instrument name in the system configuration file. COM was key, as it will work in any environment, Mueller says. National Instruments also has implemented, and continues to pursue, ActiveX controls—a technology that is an implementation of COM—in its test products, the company says.
The promise of COM—and a related technology called DCOM, or distributed COM—is that if you wrote an IVI driver with a COM interface, you potentially could "control [an instrument] over an Ethernet [network] from another computer," National Instruments’ Kimery explains. If a driver has a COM interface, "then you can call that driver from a textual programming language like C or from a visual programming environment like Visual Basic or Visual C++," Robinson adds. "These are the most commonly used programming environments in our industry and those that are growing the fastest." COM is location-, language- and hardware-independent, he says.
While various companies have developed IVI drivers and other software, National Instruments already has a product that is compliant with the original IVI driver specs: LabWindows CVI, Kimery reports. This environment allows engineers to write a test program set for one DMM, for example, and then take out the instrument and replace it with another DMM, he says. A National IVI driver toolkit, with instrument-specific and class drivers, is available separately or as part of the CVI package, he says.
Class, or generic, drivers, a concept championed by National Instruments, interpret user commands and "make calls to the corresponding commands in the appropriate specific driver," Kimery says. Software using IVI’s COM-based architecture specification, however, will be able to make calls to specific drivers without using the generic driver specification, says Mueller, adding that implementations based on the COM spec will use the same standard command sets recently approved by IVI members.
Agilent also emphasizes the significance of adopting a broad, commercial computing standard. If the test community wants standards to last, "it’s really important...not to re-engineer solutions to problems that have already been solved by the computer industry," Robinson comments. There are a lot of different types of instrument drivers now, including VXI Plug & Play, LabWindows and Agilent’s Virtual Engineering Environment (VEE), says Kevin Borchert, an Agilent strategic market consultant. "Each is implemented using different technologies. But none of them are the industry-standard technologies that the computer industry is basing its programming on."
With the IVI foundation, Agilent also stresses the Measurement and Stimulus Subsystem (MSS), technology it initiated before joining the group. While the idea behind IVI drivers is that "you can change instruments, but the calls remain the same...[you may not get] exactly the same results, depending on how different the new instrument is," Robinson says. But, "if you put the MSS layer on top of that," he says, "that’s the point at which you can be sure you get the same results."