How IVI-C Instrument Driver Technology Enables System Longevity and Platform Portability

Since 1998, the Interchangeable Virtual Instruments (IVI) Foundation has been the primary organization for defining the instrument driver standards for the test and measurement industry. The IVI Foundation defines two architectures for IVI drivers – IVI-C, which is based on the ANSI C standard, and IVI-COM, which is based on Microsoft’s Component Object Model (COM) technology. While IVI-COM is one way to implement IVI drivers, IVI-C drivers offer many advantages over IVI-COM drivers, and IVI-C drivers are the best drivers for NI customers interested in instrument interchangeability.

History of Instrument Drivers

In the early 1990s, different commercial implementations of I/O software existed for GPIB, VXI, and serial interfaces. These I/O software products were neither standardized nor interoperable. As a step toward industry-wide software compatibility, the VXIplug&play Systems Alliance was founded in 1993, with one of its goals being to define a specification for a standard I/O software architecture, the Virtual Instrument Software Architecture (VISA).

Although VISA simplifies instrument control programming significantly, you still must have low-level knowledge of instrument communication and of instrument command sets. To address this problem, instrument and software vendors began writing instrument drivers. An instrument driver consists of a set of high-level software routines to control a programmable instrument. For example, instead of sending four commands to an oscilloscope to configure it to perform an acquisition, an instrument driver might have one function that initiates the acquisition, waits for the instrument to complete the acquisition, queries the scope for the waveform, parses the response, and returns an array of data representing the acquired data.

Instrument drivers simplify instrument control and significantly reduce the amount of time required to develop an instrument control application. Not only do instrument drivers eliminate the need for the user to learn a new command set for each instrument, but also they provide a common architecture and interface to the user.

Standards for instrument drivers have evolved over the years, with each standard building on the previous one. Throughout this evolutionary process, National Instruments™ LabVIEW™ and LabWindows™/CVI™ plug and play drivers have provided a consistent approach to instrument control for more than 15 years. Following is an overview of some of the instrument driver standards that have been defined over the years.

VXIplug&play – The VXIplug&play Systems Alliance was founded to provide standards for multivendor interoperability. The organization was founded by companies including National Instruments, Tektronix, and Racal Instruments. In addition to standardizing VISA, VXIplug&play was the first organization to define an open standard for instrument drivers. VXIplug&play defines a set of standard functions that all instrument drivers must have. VXIplug&play also specifies that drivers be provided in source code so that users have the flexibility to modify them.

IVI – The IVI Foundation was founded to create an instrument driver standard that builds on the VXIplug&play standards but also provides features such as instrument interchangeability, simulation, state-caching, and multithread safety. The IVI Foundation is comprised of user companies such as Boeing, integrators such as BAE Systems, and instrument and software vendors such as National Instruments, Agilent Technologies, and Tektronix. The IVI Foundation was founded in 1998, incorporated in March of 2001, and has an active membership of 27 companies.

IVI Architecture

Figure 1 shows the architecture of an IVI system as envisioned by the IVI Foundation. Explained simply, the architecture provides a way for you to use your development environment to access IVI drivers to communicate with the instrumentation hardware in your system through standard interfaces. Everything shown within the dotted line is defined in the IVI Foundation specifications. The detail in this layer is required to provide the various capabilities and features that IVI offers.


[+] Enlarge Image
On the left you see the IVI drivers. The IVI specifications define two types of drivers, class-compliant drivers and custom drivers. Class-compliant drivers comply with one of the eight instrument classes currently defined by the IVI Foundation¹ and export a common application programming interface (API). Custom drivers comply with the IVI architecture but implement a custom API for an instrument that does not fit within one of the instrument classes specified by the IVI Foundation. IVI drivers can be implemented based on one of two architectures – IVI-C and IVI-COM. The differences between the two are discussed in the IVI-C and IVI-COM section that follows.

On the right hand side are a group of components referred to as the IVI Shared Components. These components, which are created and distributed by the IVI Foundation, provide a common basis for configuring IVI systems and handling other tasks such as dynamic driver loading and error handling. The IVI Foundation provides the shared components to ensure interoperability between different vendor systems.

IVI-C and IVI-COM

The IVI Foundation defines two architectures for IVI drivers, one based on ANSI-C and the other on Microsoft COM technology. Both architectures are designed to coexist and are not mutually exclusive. You can use IVI-C drivers and IVI-COM drivers in the same application. Refer to Table 1 for a detailed comparison of the two architectures.

Although the technologies underlying IVI-C and IVI-COM are different, implementation technology by itself is not a primary concern to instrument driver users. Instead, instrument driver users are primarily concerned about two key issues: 1) the longevity of the architecture on which the instrument driver is based, and 2) the usability of instrument drivers in the application development environment (ADE) the user chooses.

Table 1. Comparison of IVI-C and IVI-COM Drivers

	IVI-C	IVI-COM
Included in approved IVI specifications	Since August 1998 (IVI 1.0 based on IVI-C)	Since January 2003
Source code availability (for message-based instruments)	Generally available	Not generally available
Stability and robustness	Industry proven (based on ANSI C and VXIplug&play specifications)	New and evolving (based on superseded COM technology)
Driver development tools	IVI Driver Wizard (LabWindows/CVI)	Third-party custom tools
Driver ADE Usage	–	–
Native interface	C, LabWindows/CVI	Visual Basic 6.0
Native interface (through custom wrapper)1	LabVIEW, C++2, .NET2	None
Non-Native, but Usable interface	Visual Basic 6.0	LabVIEW3, LabWindows/CVI, C++, .NET
Multiplatform capability4	√	-
IVI-based software products	NI Switch Executive	None
IVI feature support	–	–
Interchangeability	√	√
Simulation	√	√
Multithreading	√	√
State-caching 5	On all drivers written by NI	Driver supplier dependent
Interchange checking 5	On all drivers written by NI	Driver supplier dependent
Trace class level calls6	Yes (NI Spy tool)	-
Advanced simulation6	Yes (NI class simulation drivers)	-
Handles custom IVI classes	√	√
IVI configuration support	Through NI MAX	Through Agilent GUI

Table Notes
1. Wrappers written by National Instruments for NI and third-party instrument drivers
2. Using NI Measurement Studio
3. Some third-party drivers more usable through LabVIEW interface
4. Multiplatform capabilities demonstrated, not yet fully developed
5. Optional IVI features
6. NI specific IVI features not included in the IVI Foundation specifications

Architectural Longevity
The issue of architectural longevity is particularly important to users of IVI drivers. Interchangeability is one of the most beneficial features of IVI, and a primary reason for achieving interchangeability is to make it easier to replace instruments in systems that must last 10 to 20 years. Having a common API for instrument drivers is not sufficient if the architecture on which those instrument drivers are based changes every few years.

For this reason, National Instrument prefers to adhere to the IVI-C architecture. ANSI C is a long established standard that is available on all platforms and is fully expected to remain so. On the other hand, COM is not available on all platforms and has already been superseded by Microsoft .NET² technology, which was introduced in 2002.

Usability
A key motivation behind IVI-COM is the desire to develop one driver that works automatically in all development environments. Unfortunately, this comes at the expense of usability. IVI-COM drivers present an interface style that is optimal only in Microsoft Visual Basic 6.0, which was superseded by Microsoft Visual Basic .NET in 2002.

Ideally, instrument drivers should present an optimal interface for each development environment in which they are used. For example, instrument drivers should be presented as a set of LabVIEW VIs for use in LabVIEW, a set of C++ classes for use in Microsoft Visual C++, and a set of .NET classes for use in Microsoft Visual Basic.NET and Visual C#.

National Instruments follows this model in implementing IVI drivers. Our focus is on providing native support for NI development environments, LabVIEW and LabWindows/CVI. We also support other environments as they become popular. Our IVI-C drivers ship with ANSI C interfaces, LabWindows/CVI function panels, and LabVIEW VI wrappers. For message-based devices, we include the ANSI C source code with the driver. We also provide C++ wrappers for IVI drivers for Measurement Studio users. In the future, we also intend to provide .NET assembly wrappers for our IVI drivers. Because Visual Basic 6.0 is becoming obsolete, National Instruments does not plan to develop COM wrappers for our IVI-C drivers.

COM As a Solution
During the work on IVI-COM in the IVI Foundation, several members expressed the opinion that COM would provide many free benefits. However, by itself, COM does not solve any problems or issues that are specific to developing test systems or using instrument drivers. The key advantages of the IVI concept are instrument interchangeability, simulation, state-caching, multithread safety, and configurability. None of these features are native to COM or provided free through COM technology.

Take interchangeability as an example. Both IVI-C and IVI-COM implement instrument interchangeability but in slightly different ways. In IVI-COM, each specific driver within an instrument class exports the same class-compliant interface as well as its own instrument-specific interface. The IVI Session Factory, one of the IVI shared components, is used to provide dynamic loading of IVI-COM drivers at run time.

In IVI-C, each specific driver within an instrument class exports the same class-compliant interface and then extends that interface with its own instrument-specific functions and attributes. For each instrument class, there is an IVI-C class driver that provides dynamic loading of IVI-C specific drivers at run time. Each IVI-C class driver uses the IVI-C Shared Components to dynamically load the appropriate specific driver at run time.

As you can see, both architectures require additional infrastructure and effort to provide interchangeability. There is no clear advantage of one over the other. For example, while IVI-COM requires only one extra component instead of a separate class driver for each instrument class, the fact that IVI-C requires a separate class driver for each class affords class driver developers the flexibility to offer additional features such as advanced simulation and tracing.

Evolution of IVI
The IVI Foundation was founded by National Instruments and end-user companies to address the issue of instrument interchangeability. Many end-user companies had already developed architectures internally for interchangeability. Users also were requesting features such as simulation, state-caching, multithread safety, and easier configurability. NI developed the IVI-C architecture to address these issues while at the same time maintaining compatibility with the VXIplug&play standards.

Some IVI Foundation members see COM technology as the major advance that IVI provides over VXIplug&play. NI, on the other hand, sees interchangeability, simulation, state-caching, multithread safety, and easy configurability as the major advances of IVI. In addition, NI remains committed to the IVI-C architecture for the sake of long-term compatibility as well as the potential for multiplatform deployment. From a usability standpoint, IVI-C, along with wrappers for LabVIEW and the Visual Studio languages, is the best solution for robust instrument control application development.

Test System Development

In developing a test system, the architecture of the instrument drivers you use should not be a paradigm for the test system architecture. A test system should be built with an architecture that is flexible and allows the developer to use more than one type of instrument driver. Instrument driver standards have evolved over the years, and several types of types of drivers are available. Instrument driver standards are likely to continue to evolve.

To build an interchangeable test system that can stand the test of time, IVI-C drivers are the best choice. However, if all that is available for your instrument is an IVI-COM or VXIplug&play instrument driver, then you should use it. Your goal is to be able to easily communicate with your instruments and not to be tied to one driver technology or another.

Summary

In conclusion, both IVI-C and IVI-COM drivers deliver the benefits of IVI technology. IVI-C drivers offer many advantages over IVI-COM, such as longevity, usability in NI development environments, and platform portability. National Instruments believes that IVI-C drivers are the best drivers for engineers and scientists that require the features that IVI delivers.

Footnotes
1. The instrument class specifications defined as of August 2003 are digital multimeter, DC power supply, function/arbitrary waveform generator, oscilloscope, power meter, RF signal generator, spectrum analyzer, and switch.
2. Microsoft .NET is a set of Microsoft software technologies for connecting information, people, systems, and devices. Microsoft .NET enables a high level of software integration through the use of XML Web services – small, discrete, building-block applications that connect to each other as well as to other larger applications over the Internet.

Reader Comments | Submit a comment »