Building an Interchangeable Test System Using IVI Drivers

Test developers have been trying to build interchangeable systems for years. Many industry initiatives have attempted to address this issue with varying degrees of success. The Interchangeable Virtual Instruments (IVI) Foundation is in the process of defining standards for such systems. These standards define IVI instrument drivers and their capabilities, including a set of class Application Programming Interface (API) specifications, and a description of the different driver architectures and interchangeability routes.

Contents
•IVI Driver Definition
•IVI Interface Architectures
•Routes to Interchangeability
Test and measurement engineers have a long-standing desire to exchange instruments in their systems without having to rewrite their programs. For example, when building a production test system, a test developer may need to build a system and validate it using multiple test instrument racks. Interchangeable systems allow them to switch between the different sets of hardware on the production floor very rapidly, thereby minimizing overall system downtime.

When you are using a variety of instruments, however, you end up dealing with a variety of system software. The Interchangeable Virtual Instruments (IVI) Foundation is helping system developers bypass this problem by defining standard specifications for instrument interchangeability. The organization's overall goal is to provide a mechanism for creating one test program and using that same program with multiple sets of instrumentation hardware.

IVI Driver Definition
The main portion of the IVI specification defines the overall IVI system architecture and the inherent capabilities of all IVI compliant instrument drivers. The IVI system architecture divides driver functionality into two layers. The instrument-specific layer provides drivers for individual instruments, similar to old-style drivers such as VXIplug&play. This layer provides a consistent API and incorporates features such as instrument simulation, range checking, and state caching. The class-compliant layer provides a generic instrument API for each instrument class (or type) that can be used with many instruments in that class. The class-compliant layer supports instrument interchangeability.

This architecture defines a common programming interface for instruments of a similar type. IVI-compliant drivers for a given type of instrument will have very similar APIs and can be easily interchanged through the class-compliant layer.

Class specifications have currently been defined for five classes of instruments: DMMs, oscilloscopes, function generators and arbitrary waveform generators, DC power supplies, and switches. Class definitions are under development for spectrum analyzers, RF signal generators, power meters, and digital test instruments.

In addition to features such as instrument simulation and state-caching, the IVI specifications also define such features and inherent attributes of IVI drivers as range-checking, multithread safety, interchangeability checking, and coercion checking. While some of these features are required of all IVI drivers, others are optional. These specifications also define a configuration mechanism that is used to setup an IVI system.

Back to top

IVI Interface Architectures
Interface architectures define what interface a driver exposes to the test program developer. The IVI Foundation is designing two such architectures. One is based on ANSI-C technology, while the other uses Component Object Model (COM) technology. By defining two architectures the Foundation offers instrument driver and test system developers a choice.

A C driver, such as defined in the ANSI-C portion of the specifications, is presented in the form of a dynamic link library (DLL). All the driver function calls have C function prototypes and must be called appropriately. The C specifications also define other components, such as error handling and driver session creation and management, that are necessary to ensure overall system robustness.

C is a mature, proven, and stable technology that has been and will be around for a long time. C facilitates the creation of multi-platform systems, since it is available on almost all operating systems including Windows, Macintosh, Linux, and Sun Solaris. In addition, C interfaces have no encumbrances that can adversely affect performance.

There are also some disadvantages to using C. C interfaces are not as easy to use in Visual Basic, a popular development environment. In addition, C does not provide a way to create multiple namespaces. You cannot use multiple DLLs with the same C function names in the same program. If multiple instrument driver DLLs have functions of the same name, the program linker returns an error. Thus, the C function names for the instrument specific interfaces in each driver must begin with a unique instrument prefix.

Similarly, COM based drivers provide a standard COM interface that exposes the class-defined functionality through methods and properties. COM also offers many advantages. It is the standard method for using components in Visual Basic. In addition, COM interfaces have namespaces, so the methods and properties do not need an instrument prefix. Finally, distributed instrument communication is possible using a variation of the technology called Distributed COM, or DCOM.

There are also a few disadvantages to using COM interfaces. COM is not as easy to use in C, C++, and other standard development environments. At this time, COM is fully and freely available only on the Windows platform. Finally, and maybe most importantly, COM is a young and evolving technology, so the IVI COM specifications that are written today may become outdated.

While these two interfaces have been chosen for standardization in the IVI Foundation, no one interface is best for all environments. In any development environment, it is easiest to use an interface that is native to that environment. While a C interface and a COM interface are best in C and Visual Basic respectively, a C++ interface is best in Visual C++, and a native LabVIEW interface is best in LabVIEW. The IVI specifications do not prevent individual vendors from supporting these and other interfaces to IVI drivers.

Back to top

Routes to Interchangeability
Each of these interface technologies supports instrument interchangeability in a unique way, specific to the technical requirements of that interface technology.

The C architecture provides interchangeability through the class driver mechanism. Because of the namespace issue, all driver functions in a C driver include a prefix that is specific to the instrument. When these function calls are embedded in a test program, exchanging that instrument for another requires the developer to modify the program to contain the functions with the new instrument's prefix.

This problem is resolved by defining a class driver that exports the functions defined in the class specifications and uses a generic prefix such as IviFgen or IviScope. Test programs call the class driver functions rather than specific driver functions. The class driver serves as a pass-through layer to the specific driver by being bound to the specific driver at run-time.

In contrast, each COM specific driver that complies with one of the IVI class specifications contains both an instrument specific interface and a class-compliant interface. For a particular class, the class-compliant interface is 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. A test program can use interface, method, and property names that will be present in every specific driver of the same class.

Although the COM methods do not explicitly refer to the specific instrument being used, the developer still needs an explicit reference to the instrument in the declaration part of the program. To take care of this problem, the IVI COM architecture provides the IVI-COM Driver Factory. The factory binds the COM methods to the appropriate driver specified in the IVI configuration.

Both architectures also face the problem of explicit references to the hardware address of the instrument. To overcome this, the IVI specifications define the concept of a logical name, bound to a hardware address and an instrument driver in the IVI configuration store. Either the class driver or the IVI factory reads the IVI configuration store and uses the definition of the logical name to determine which specific driver and hardware resource it should refer to. The table provides examples of instrument communication for each of the four scenarios described above.

Both mechanisms described provide interchangeability in most cases, but there are a few situations where they are not sufficient. For example, they both do not provide an appropriate route for interchanging two instruments from different classes that are capable of making the same measurement. In addition, if the hardware itself is not interchangeable (different capabilities), then the ability of the software to provide interchangeability is not enough.

Developers usually take care of these irregularities in their own code. However, the IVI 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). Only this extra layer needs to be modified to interchange instruments in this type of system,. Usually, a system developer will retain the services of an integrator who will develop these RCMs for them. This integrator will also be consulted whenever the user needs to interchange instruments in the system. When used with the IVI architecture described earlier, IVI-MSS can offer increased interchangeability, although at the expense of increased cost and complexity.

Back to top

Conclusion
The IVI specifications can be used to achieve a long desired goal of test system developers. When using IVI drivers in designing a test system, a developer can be confident that the system they are building will continue to work when the current instruments they are using become obsolete and need to be replaced.