Test-system developers historically have used instrument drivers—software modules containing a collection of high-level functions that abstracts the low-level instrument communications details—to simplify the test-program development task. One of their long-standing desires has been the ability to exchange the instruments in the system without rewriting most of the test program. The Interchangeable Virtual Instruments (IVI) Foundation is tackling this issue by defining standard specifications for achieving instrument interchangeability without major code rewrites.
Instrument Interchangeability
Instrument interchangeability refers to the capability of a test-system developer to write a program for use with a set of instrumentation hardware and then use that same program with a different set of hardware. Instrument interchangeability has two inherent limitations:
- Both sets of hardware in question must be interchangeable, meaning that they must be capable of taking the same measurements.
- Since it is almost impossible to achieve complete interchangeability in a complex, real-world system, the aim is to provide a mechanism that requires the least amount of effort to interchange instruments.
Instrument interchangeability can be very useful to test-system developers in many situations, but particularly in two. First, when building long-life test systems, such as in the military, the system often will outlive the instruments that it comprises. Second, when building short-life test systems, such as in the telecommunications industry, test developers need to build a system and validate it using multiple test instrument racks to minimize overall system downtime over the life of the system.
Overall IVI Architecture
The IVI Foundation is defining architecture for instrument interchangeability that attempts to address these issues. Logically, the overall system is split into two layers:
- The instrument-specific layer focuses on providing drivers that are intended to be used with specific instruments, supply consistent Application Programming Interfaces (APIs), and incorporate features to facilitate test-program development and enhance performance, such as instrument simulation, multithread safety, and state-caching.
- The class-compliant layer focuses on providing generic instrument APIs that can be used with a multitude of instruments. Although the main benefit of the class-compliant layer is interchangeability, it also supports features such as instrument simulation and state-caching.
To define the architecture that can support these two layers, the IVI Foundation currently is developing specifications in four areas that are depicted in Figure 1: instrument class API specifications, core driver technology, driver interface technology, and interchangeability mechanisms.
Instrument Class API Specifications
Instrument class API specifications are key to achieving interchangeability. The idea is to define a common programming interface for instruments of a similar type. When this is accomplished, IVI drivers for a certain type of instrument have very similar APIs and can be interchanged through the class-compliant layer.
The instrument class specifications are developed in the following manner: A working group identifies a class of instruments to work on, such as digital multimeters (DMMs) or oscilloscopes, and conducts a survey of all popular instruments within that class to determine what capabilities are common among the majority of those instruments.
These capabilities are defined as base capabilities. For example, in the DMM class, the base capabilities include performing a DC voltage or current measurement.
The working group also identifies capabilities that are less common but still supported by multiple instruments within the class. These capabilities are called extended capabilities and grouped into extension groups. An example of a DMM extension group is the temperature measurement extension. Extension groups allow test-program developers to use a broader range of instrument functionality while limiting the set of instruments that can be interchanged.
Finally, the instrument class specifications leave room for instrument-specific and vendor-specific functionality. This latitude prevents IVI from limiting an instrument manufacturer’s capability to innovate and provide specialized features. In the DMM class, a vendor-specific functionality might be a measurement that is triggered from a user-specified threshold.
Currently, there are five classes of instruments with defined class specifications. These are DMMs, oscilloscopes, function and arbitrary waveform generators, DC power supplies, and switches. More class definitions are on the way, including those for spectrum analyzers, RF signal generators, power meters, and digital instruments.
Core Driver Technology
This part of the IVI specifications defines the core technology that is required to put together a complete IVI system. First, these specifications outline the types of IVI drivers. There are IVI class-compliant specific drivers that conform to one of the IVI class specifications and can be interchanged with other drivers of the same class. There also are IVI custom specific drivers, which contain only instrument-specific functionality and cannot be interchanged.
In addition, these specifications define the inherent capabilities of all IVI drivers. These configurable capabilities include instrument simulation, instrument state-caching, interchangeability checking, and range checking. Some of these capabilities are required for all drivers, and others are optional.
The specifications also define a mechanism for configuring IVI systems. The key to the mechanism is a logical name, which is a high-level abstraction that allows the user to refer to an instrument in software without explicitly referring to its hardware address.
Logical names refer to driver session configurations, which are composed of a reference to a specific instrument driver, a reference to a physical hardware resource, a set of virtual names for channels or other repeated capabilities, and the configuration of the inherent capabilities of the driver. Users define logical names in the IVI configuration store.
In general, the IVI specifications focus on the high-level API that each IVI driver exposes to the user’s test program. Internally, the driver must communicate to the instrument using a standard I/O library. IVI has made an effort to rely on the Virtual Instrument Software Architecture (VISA) for its I/O communications needs although VISA is not always required (see sidebar below).
Driver Interface Technology
This portion of the specifications defines the interface that the driver exposes to the test-program developer. Currently, there are two architectures being defined, one based on ANSI-C technology and the other on Microsoft Component Object Model (COM) technology. The IVI Foundation has chosen this approach to provide options for users rather than suggest that one technology be used over the other. Both interfaces will provide all the benefits of IVI.
The ANSI-C portion of the specifications details the architecture of a C-based driver. A C driver is presented in the form of a dynamic link library (DLL), such as a Windows DLL, composed of standard C functions. The C specifications also define system components that are necessary to ensure robustness and interoperability, such as error handling and driver session creation and management.
The COM portion of the specifications describes the architecture of COM-based drivers. These drivers provide a standard COM interface that exposes the class-defined functionality through methods and properties organized into a hierarchy.
Although the IVI Foundation has chosen to define architectures and APIs for these two interface technologies, no one interface is best for all environments. The easiest interface to use in any environment is the one that is native to that environment. A C interface is best in C, a COM interface is best in Visual Basic, a C++ interface is best in Visual C++, and a native LabVIEW interface is best for that environment. The IVI specifications do not prevent vendors from defining custom interfaces for languages and environments that are not standardized by the IVI Foundation, for example, C++ or LabVIEW.
Interchangeability Mechanisms
For each of the interface technologies for which the IVI specifications define an architecture, the specifications also describe a mechanism for achieving interchangeability. This mechanism is based on the technical requirements of each of the interface technologies.
In the C architecture, the way to achieve interchangeability is through the class driver. For example, the functions to make a measurement on a Keithley 2000 DMM look like this:
ke2000_init (“GPIB::10”, 1, 1, &handle);
ke2000_Read (handle, 5000, &measurement);
ke2000_close (handle);
Exchanging this instrument for another requires that the test program be modified to contain the new instrument’s prefix. In addition, the instrument’s hardware address is specified in the test program, requiring that to be changed as well.
The C architecture takes care of the first problem by defining the concept of a class driver that exports the functions defined in the class specifications and uses a generic prefix such as IviDmm. To achieve interchangeability, test programs call the class-driver functions rather than the specific-driver functions. The class driver is bound to the specific driver at run-time and serves as a pass-through layer to the specific driver.
The test-program developer overcomes the second problem by using the logical-name concept. The class driver reads the IVI configuration store and uses the definition of the logical name to determine which specific driver it must bind to.
The example now looks like this:
IviDmm_init (“LogicalName”, 1, 1, &handle);
IviDmm_Read (handle, 5000, &measurement);
IviDmm_close (handle);
Class and specific drivers are made available by software or instrument vendors.
In the COM architecture, interchangeability is achieved through a different mechanism. Each COM-specific driver that complies with one of the IVI class specifications contains both an instrument-specific interface and a class-compliant interface, which are identical from one COM specific driver to another. This is possible because each COM-specific driver has a different namespace and does not require an instrument prefix. The first example shown for C would look like this in the COM world:
DIM DMM1 as New ke2000
DMM1.Initialize(“GPIB::10”, 1, 1)
Measurement = DMM1.Read(5000)
DMM1.Close()
Notice that the method names (Initialize, Read, Close) do not refer to the specific instrument being used. Nevertheless, there still is an explicit reference to the instrument in the DIM statement and to a hardware resource in the Initialize call.
To take care of this problem, the IVI-COM architecture provides the IVI-COM Driver Factory. The factory binds a logical name specified in the code to the appropriate driver and hardware resource specified in the IVI configuration store. Using the factory, the code snippet would look something like this (the specifications still are in progress):
DIM factory as New IVI_Factory
DIM DMM1 as IIVI_Dmm
Set DMM1 = factory.create(“LogicalName”)
DMM1.Initialize()
Measurement = DMM1.Read(5000)
DMM1.Close()
Limitations of Interchangeability
Although both the C and COM IVI architectures provide mechanisms for interchangeability that work effectively in the majority of cases, a few situations can occur where this approach is not sufficient. In some situations, you might want to interchange two instruments that are in different classes but capable of making the same measurement.
Although the IVI class specifications define guidelines for implementing the class-compliant interfaces, the ultimate success lies in the similarity of the hardware. Some instruments might use different measurement techniques that result in values that are not exactly the same when you replace one instrument with another.
If the differences are significant for your test program, you have to modify your program to ensure the same result. Usually, developers take care of these modifications in their own code. However, a technical committee within the IVI Foundation, called the Measurement and Stimulus Subsystems (IVI-MSS) Working Group, is working on a specification that defines how these differences can be accounted for by abstracting them into another layer in the IVI hierarchy called the Role Control Module (RCM).
To interchange instruments in this type of system, only this extra layer needs to be modified. Generally, a system integrator will develop these RCMs for the user and be consulted or retained whenever instruments have to be interchanged in the system. In these cases, IVI-MSS can be used in conjunction with the IVI architectures to offer increased interchangeability, although at the expense of added complexity in initial program design.
Summary
The IVI specifications offer a tremendous amount of promise to simplify interchangeable test-program development and facilitate the creation of robust, high-performance, and full-featured instrument drivers. These drivers allow the end user to focus on the task of developing a test program and not to worry about the details and peculiarities of instrument communications.
For more information, visit the IVI Foundation website at www.ivifoundation.org.
VISA Support for New Buses
More and more future test systems will comprise instruments that support mixed I/O connectivity. These systems will include GPIB and serial instruments that are popular today plus instruments that use emerging bus technology such as Ethernet, USB, IEEE 1394, or others that have yet to be defined.
The use of a multibus, multiplatform I/O communications library like VISA simplifies the incorporation of these new bus technologies into existing systems. VISA is intended to communicate with instruments using the same API regardless of what communications bus the instrument uses.
VISA currently supports GPIB, VXI, serial, PXI, and Ethernet instruments and will be expanded to include support for other buses as they become prevalent in test and measurement applications. The same IVI driver built using VISA can communicate with an instrument using any one of the buses.
About the Author
Dany Cheij is a test and measurement product manager at National Instruments and an active participant in the IVI Foundation. He holds a B.S. in mechanical engineering from MIT and an M.S. in engineering and public policy from Carnegie Mellon University. National Instruments, 11500 N. Mopac Expressway, Austin, TX 78759, 800-258-7022, e-mail: [email protected].
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2001 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
February 2001