Agilent Developer Network

White Paper

IVI Standards Tutorial

Kirk Fertitta
Pacific MindWorks, Inc.

Abstract
The Interchangeable Virtual Instrument Foundation was formed with the purpose of
creating a standard that would allow engineers to use test equipment from different
manufacturers without having to change their instrument control software. While this
is an admirable goal, there's a little more to the story than this first blush would
suggest. In particular, there are several different flavors of IVI, and which of these
versions an engineer uses has implications for that engineer's flexibility. For
instance, IVI-C drivers meet the goal of hardware independence - allowing users to
swap instruments without rewriting software - but are supported only within a
particular vendor’s environment, whereas IVI-COM drivers are not restricted to one
framework. This article will educate the T&M user on the different types of IVI drivers
and examine tradeoffs in order to enable that engineer to make informed choices in
test development.

Background
It has been more than three years now since the IVI Foundation set out to create a
set of instrument driver software standards that would allow T&M engineers to
author test applications that were independent of the underlying test equipment.
Initially, the standardization effort focused on defining C-language interfaces. The
vision for these C-language drivers is that driver developers write conventional DLLs
(on the Windows platform) that expose a flat hierarchy of instrument-specific
functions. A separate component, termed a class driver, is then used to expose
generic functions for interchangeability. Much of the initial momentum for C-style
driver interfaces came from early work National Instruments had performed on C
drivers with their LabWindows/CVI development environment. However, not long
after the IVI Foundation’s public inception, a number of active member companies
began clamoring for a driver standard that would leverage Microsoft’s ubiquitous
component technology known as the Component Object Model (COM). After all,
many of the goals Microsoft pursued with COM seemed enticingly similar to those
sought by IVI. T&M developers want flexibility in their choice of integrated
development environment (IDE) as well as drivers that are easy to use in their IDE
of choice, drivers that perform in multithreaded environments, and drivers that
enable multi-process and multi-host applications. For their part, instrument vendors
need a true component standard – one that allows them to develop a single driver
for any IDE using standard Microsoft tools that leverage existing expertise, rather
than proprietary tools with specific requirements and vendor-specific peculiarities.
These motivations have culminated in a full suite of IVI standards for both C and
COM, termed IVI-C and IVI-COM, respectively. Understanding the differences
Agilent Developer Network White Paper 2 of 5
IVI Standards Tutorial

between these two distinct flavors of IVI is critical to a T&M engineer designing new
test applications. While both flavors of IVI simplify interchangeability, it is more
important to examine the specific technology in use, as this will dictate many of the
benefits of IVI, such as the productivity gains T&M engineers experience.

Along with the COM standardization effort, the IVI Foundation has labored vigorously
to develop architectural standards for IVI drivers. These standards place certain
minimum requirements on IVI drivers independent of the specific instrument class
the driver supports. The idea behind these architectural standards is that drivers
must do certain fundamental operations in a standard way if interchangeability can
be achieved in real-world applications. For instance, the architectural standards
dictate how drivers are installed and configured. Additionally, the IVI Foundation will
be developing, shipping, and maintaining specific software components for
performing configuration, event handling, and other common tasks in a standard
way. Though these architectural standards promise to enable interchangeability,
their greater benefit lies in the ease-of-use, productivity features, and familiarity
they bring to developing test applications with IVI drivers. Again, the driver
technology chosen, IVI-C or IVI-COM, is paramount in maximizing the benefits
derived from this architectural standardization effort. Indeed, many vendors and
users alike find more potential in the architectural standards combined with
standardized component technology, such as COM, than they find in the potential of
robust interchangeability itself. Nevertheless, the end result of the multi-pronged
IVI standardization effort is an entire suite of standards, the many permutations of
which are a persistent source of confusion for T&M users.

Comparing Interface Standards

The first decision a T&M user will face when considering IVI drivers for an application
is whether to use IVI-C or IVI-COM. Both interface technologies offer approximately
the same level of interchangeability with regard to the underlying test equipment.
That is to say, both technologies allow a user to write software that will not need to
be recompiled when new test equipment is introduced into the system. This is what
is meant by hardware independence. However, IVI-C and IVI-COM provide very
different degrees of software independence. IVI-COM drivers rely upon COM
technology for operating seamlessly in various IDEs. Users working in Visual Basic,
Visual C++, Delphi, LabVIEW, and many other environments, all enjoy a host of
features for using IVI-COM drivers in their application. Object browsers provide a
convenient, standardized way of viewing the functionality exposed by IVI-COM
drivers. Microsoft’s IntelliSense feature provides auto-completion capabilities that
even the most experienced developers find indispensable in their day-to-day
programming work. The most popular environments, Visual Basic and Visual C++,
provide direct support for importing IVI-COM drivers in an application. In the case of
Visual Basic, users simply select the “Add Reference” menu item, while Visual C++
users have the #import compiler directive which makes using COM components in
C++ as easy as using them in VB – literally!! By comparison, IVI-C drivers really
only have special support in a single environment – National Instruments’
LabWindows/CVI.

One of the most important things to note about IVI-C drivers is their reliance on
proprietary components. For instance, in IVI-C technology, instrument-specific
drivers are developed that expose instrument-specific interfaces. Each function call
exposed by the driver DLL is prefixed with the name of the instrument, so obviously,
these functions cannot be called directly in an application that wants to have

Visit the Agilent Developer Network at http://www.agilent.com/find/ADN

Agilent Developer Network White Paper 3 of 5
IVI Standards Tutorial

interchangeable drivers. Rather, IVI-C drivers require the cooperation of a separate

component known as a class driver. The class driver DLL exposes generic functions
that delegate to the instrument-specific driver. In this way, IVI-C achieves syntactic
hardware interchangeability. At present, class drivers are only available from
National Instruments and no other vendor or end-user has expressed interest in
developing class drivers. IVI-COM drivers, on the other hand, do not need class
drivers at all. COM inherently supports this type of polymorphic behavior, that is,
the ability for code to determine at runtime the appropriate function to call. The
notion of commercializing polymorphism in the form of class drivers seems
anachronistic to this author.

IVI-C drivers also rely upon another component from National Instruments for their
basic operation – the IVI Engine. The IVI Engine is a separate DLL that
communicates with drivers at runtime to provide such services as range checking,
state caching, and coercion. This means that IVI-C drivers cannot operate “stand-
alone”, unlike their IVI-COM counterparts, which provide the same capabilities within
the driver itself. Additionally, the presence of a single centralized component shared
by all IVI-C drivers in an application creates performance considerations. Since the
IVI Engine must service multiple IVI-C drivers, it is possible that these drivers could
contend for some resources or services provided by IVI Engine.

Different Levels of Compliance

Along with the consideration of C and COM interface standards, IVI drivers are
distinguished by their differing levels of compliance. This point has been a source of
confusion since IVI’s inception. Essentially, there are two levels of compliance with
an IVI driver – class-compliant drivers and custom drivers. The characteristics of the
class-compliant drivers are somewhat self-explanatory. A class-compliant driver
exposes one (or more) of the IVI-defined instrument class interfaces, such as DMM,
oscilloscope, or function generator. The class-compliant driver must follow the exact
syntax and semantics of the functions defined in the relevant IVI Foundation class
specification. This is true regardless of whether the driver’s interface technology is C
or COM. Class-compliant drivers are the ones that offer the possibility of hardware
independence, as other drivers in the same instrument class (e.g. other DMMs or
other oscilloscopes) can be exchanged without having to recompile the application
program. Many people are currently under the misapprehension that this is the only
type of IVI driver, since the IVI moniker has become synonymous with
interchangeability. However, it is perfectly legitimate to develop an IVI-compliant
driver that follows no instrument class specification, and, hence is not generally
interchangeable. IVI drivers that do not fall into any of the IVI-defined instrument
classes are termed IVI custom drivers. These drivers usually represent instruments
that are either too complex or too specialized for the IVI Foundation to standardize
upon. However, the term “custom” driver can be misleading, because it is not a
“free-for-all” with IVI custom drivers. Though these drivers do not comply with any
class specification, they must comply with all of the architectural standards. This
enables these drivers to take advantage of the various IVI infrastructure components
that provide valuable services, such as configuration, installation, and event
handling. Moreover, compliance with the architectural standards means that IVI
custom drivers can be integrated with other IVI drivers in user applications. While
this does not provide interchangeability between drivers, it does provide for
interoperability amongst drivers. The architectural standards also impose certain
design guidelines on IVI custom drivers. These guidelines are designed to ensure a
consistent “look and feel” to IVI drivers, so that T&M users enjoy some level of

Visit the Agilent Developer Network at http://www.agilent.com/find/ADN

Agilent Developer Network White Paper 4 of 5
IVI Standards Tutorial

familiarity when dealing with drivers from different vendors, drivers of different
instrument classes, and even custom drivers with no IVI-defined instrument class
support at all.

So, with two choices for interface technology (C or COM) and two choices for
compliance level (class-compliant or custom), there are four distinct types of IVI
drivers:
1. IVI-COM class-compliant driver – exposes a COM interface; supports one
or more IVI-defined instrument classes; complies with architectural standards
2. IVI-C class-compliant driver – exposes a C interface; supports one or
more IVI-defined instrument classes; complies with architectural standards
3. IVI-COM custom driver – exposes a COM interface; complies with
architectural standards
4. IVI-C custom driver – exposes a C interface; complies with architectural
standards

Looking Towards .NET

Technology in the software changes rapidly – very rapidly. Just when IVI was
completing its work with COM and C standards, Microsoft is trying to reinvent the
way software is developed on the Windows platform. The Microsoft .NET platform
represents a revolutionary step in component software development. It is impossible
to ignore the influence this important new technology will have on T&M developers.
Indeed, .NET offers a wealth of productivity and performance benefits for a wide
variety of applications. The scope of the .NET platform and the advantages it offers
is beyond the scope of this article. However, it is important to consider the impact of
.NET on IVI. T&M engineers want to know that the IVI technology they choose today
will give them the flexibility to work with .NET effectively when that platform takes
root. Specifically, engineers considering adopting IVI-C driver technology versus
IVI-COM technology should be aware of some important considerations with respect
to .NET. The short story is that .NET provides much richer support for integrating
COM components like IVI-COM drivers than conventional DLLs like IVI-C drivers.
This should come as no surprise to many, as COM is very deeply rooted in the
Windows operating system and it is the preferred method Microsoft uses for exposing
a wide variety of system services. The .NET platform provides a type library import
utility, called tlbimp.exe, which allows a developer to seamlessly integrate a COM
component into their .NET application. The developer simply runs this utility on their
IVI-COM driver, for example, and a .NET wrapper component is generated for the
IVI-COM driver. This generated component is used in a .NET application just as if it
were a native .NET component. Conversely, COM components can be generated
from code written in a .NET native language, such as C# or VB.NET. The type library
export utility, called tlbexp.exe, generates a COM wrapper component for code
developed in .NET. These generated components can then be integrated into any
application that expects to interface with a conventional COM component, such as an
IVI-COM driver.

By comparison, the technology .NET provides for integrating conventional DLLs such
as IVI-C drivers is far less appealing. In order to access an IVI-C driver from .NET
code, each .NET application must contain explicit code describing each function to be
used. The .NET application must declare in code a static reference to each function
exposed by the IVI-C driver and it must adorn each of these declarations with
detailed attributes to control such things as the calling convention and whether ANSI

Visit the Agilent Developer Network at http://www.agilent.com/find/ADN

Agilent Developer Network White Paper 5 of 5
IVI Standards Tutorial

or Unicode strings are in use. For IVI-C drivers, this would mean that each .NET
application would contain hundreds of lines of declarative code for each IVI-C driver
it needed. It is likely that this will prove to be simply intractable for most
developers. Contrast this with COM where a single utility needs to be run only once,
and no extra code in the application is required. Additionally, there is no equivalent
of the tlbexp utility for conventional C DLLs like IVI-C drivers. .NET components
cannot be exported to a conventional DLL. Thus, unlike the situation with IVI-COM
there is no way for a .NET component to seamlessly “impersonate” an IVI-C driver.
In general, T&M developers looking at .NET will find much richer support for IVI-COM
than for conventional DLLs like IVI-C drivers.

Conclusion
This article has examined the IVI Foundation’s standardization effort and the
different types of IVI drivers available. IVI-COM drivers leverage COM technology to
provide a host of benefits when compared to IVI-C. Most popular IDEs provide a
very rich experience for developers working with COM components, while IVI-C
drivers work well in a proprietary environment. Additionally, IVI-C drivers require
the use of secondary components like class drivers and the IVI Engine to perform
their work while delivering interchangeability. Both IVI-COM and IVI-C drivers can
be class-compliant by supporting one of the IVI-defined instrument classes. Or, both
interface types can be used for custom drivers that do not support an IVI-defined
instrument class but that do follow architectural standards that ensure
interoperability with other IVI drivers. Finally, users who may ultimately want to
utilize the new Microsoft .NET platform will have a much better experience doing so
with IVI-COM technology.

Kirk Fertitta is the Chief Technical Officer for Pacific MindWorks, a San Diego-based
consulting firm specializing in Windows application design and development, COM,
and Microsoft .NET. Kirk is an instructor for DevelopMentor where he delivers .NET
courses across the country. He also teaches and develops the .NET curriculum at the
University of California San Diego.

Product and company names mentioned herein are trademarks or trade names of their respective
companies.

Microsoft, Visual Basic, Visual C++, Visual Basic.NET, and .NET are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
LabVIEW and LabWindows are trademarks of National Instruments Corporation.
Delphi is a trademark or registered trademark of Borland Software Corporation in the United States and
other countries.

Agilent T&M Software and Connectivity

Agilent’s Test and Measurement software and connectivity products, solutions and Agilent Developer Network allow you
to take time out of connecting your instrument to your computer with tools based on PC standards, so you can focus on
your tasks, not on your connections. Visit:
http://www.agilent.com/find/connectivity
Product specifications and descriptions in this document subject to change without notice
© 2002 Agilent Technologies, Inc. All rights reserved.
Published: November 2002

Visit the Agilent Developer Network at http://www.agilent.com/find/ADN