How IVI Drivers Provide Interchangeability

The IVI Foundation uses the term instrument class to refer to a distinct set of functionality for a canonical instrument type. Although there are many different types of instruments used in test and measurement and their functionality varies considerably, many of these instruments naturally fall into distinct categories, or types. Often these instruments are categorized based upon the type of measurements they can perform or the type of output they can produce.

For each instrument class, the IVI Foundation publishes a specification, known as the class specification. Each class specification lays out the requirements for compliance with that class specification. An IVI driver that complies with a class specification is said to be a class-compliant IVI driver. The primary purpose of an IVI class specification is to detail the set of functions and attributes that an IVI driver must support in order to be class-compliant. The class specification carefully prescribes the exact name of each function, along with the parameter list and the API hierarchy, as well as other behavior details.

Currently, the IVI Foundation has defined and approved specifications for twelve instrument classes. These specifications are available from the IVI Foundation.

The term interchangeability in IVI refers to the ability to exchange an instrument of one class in a system with a different instrument from that same class. IVI interchangeability does not generally refer to the case of exchanging instruments from different instrument classes.

Client applications achieve interchangeability by writing their code such that it meets at least the following two conditions:

It uses only functions and attributes from the IVI class specification.
It has no references to a specific IVI instrument driver.

Since IVI drivers can contain functionality beyond the class specification (known as instrument-specific functionality), the client programmer must take care to only use functionality from the IVI specification if their program is to be interchangeable. Only the IVI-defined functionality is guaranteed to be supported by a class-compliant driver.

The second condition (excluding references to a specific driver) is a bit trickier to meet, and requires the use of extra software components. The mechanism by which this is achieved is different for IVI-COM drivers and IVI-C drivers.

IVI.NET Interchangeability

Interchangeability with IVI.NET relies upon special components shipped as part of the IVI Shared Components. The first component required for IVI.NET interchangeability is the .NET factory classes. These classes component allows users to instantiate a specific IVI.NET driver by name rather than by a hard-coded program reference. The IVI Shared Components supply one factory class per IVI instrument class.

The name used to instantiate the driver is termed the logical name. The IVI Configuration Store holds all of the user-assigned logical names, and maps them to specific IVI drivers. When a different instrument is introduced into the system, the user need only change the specific driver referenced by their logical name in the IVI Configuration Store. No user code is modified, so the application will run without re-compiling or re-linking. The factory class will lookup the logical name in the IVI Configuration Store and instantiate the new driver.

The second component required for IVI.NET interchangeability is the class assembly associated with the IVI instrument class in use. The IVI.NET class assemblies are also part of the IVI Shared Components. These DLLs contain the interface definitions (method signatures, property and parameter types, etc.) for a particular instrument class. Class-compliant IVI.NET drivers reference these type libraries to implement the functionality they define. Client applications reference these type libraries to access driver functionality in a driver-independent fashion.

The .NET factory classes and the class assemblies are the basic machinery that enables interchangeability with IVI.NET drivers.

An instrument class capability group is a logical grouping of related methods and properties. Capability groups might accurately be thought of as coarse-grained instrument class "features". Dividing the functionality of an instrument class into capability groups allows class-compliant drivers to advertise the subset of instrument class features they support. When a class-compliant driver is installed, the IVI specifications require the driver installer to publish in the IVI Configuration Store not only the name of the instrument class with which it complies, but also the set of class-defined capability groups it supports.

Each IVI class specification partitions IVI-defined functionality a into two kinds of capability groups -- the required base capabilities and the optional extension groups.

Base Capabilities Group

The Base Capabilities group contains functionality that all IVI drivers must implement if they wish to claim conformance with the instrument class in question. Typically, the Base Capabilities group represents the "least common denominator" of functionality for an instrument class, so most commercial instruments can be expected to support this level of capability.

As an example, the IviDmm Base Capabilities group contains functions for range, resolution, and triggering. Most commercial DMMs possess at least these capabilities, so any IVI driver that wishes to claim IviDmm-compliance must support this group of functionality.

Extension Groups

IVI uses Extension Groups to define functionality that is found in many instruments of a particular class but may not be as common as the functionality expressed in the Base Capabilities. One may think of Extension Groups as being standard definitions for "optional" functionality in an IVI driver.

Extension Groups provide a means for more advanced intruments to expose functionality in an interchangeable fashion, while still allowing simpler instruments to be class-compliant. For instance, not all DMMs have the ability to perform temperature measurements. Thus, the IviDmm class specification uses the IviDmmTemperature Extension Group to define temperature measurement capabilities.

Simply put, an Extension Group is making the statement to the driver developer, "You do not have to provide these capabilities in your IVI driver, but if you do, you must do it according to the IVI definition." An IVI driver can be class-compliant without supporting any of the extension groups in its instrument class. All IVI drivers expose a GroupCapabilities attribute that returns a comma-separated list of the extension groups supported by the driver. Using this attribute, client applications and tools can programmatically determine what optional functionality is present in an IVI driver.