What is an IVI Instrument Class?

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.

•IVI-4.1: IviScope Class Specification

•IVI-4.2: IviDmm Class Specification

•IVI-4.3: IviFgen Class Specification

•IVI-4.4: IviDCPwr Class Specification

•IVI-4.5: IviACPwr Class Specification

•IVI-4.6: IviSwtch Class Specification

•IVI-4.7: IviPwrMeter Class Specification

•IVI-4.8: IviSpecAn Class Specification

•IVI-4.10: IviRFSigGen Class Specification

•IVI-4.12: IviCounter Class Specification

•IVI-4.13: IviDownconverter Class Specification

•IVI-4.14: IviUpconverter Class Specification

•IVI-4.15: IviDigitizer Class Specification

Interchangeability and IVI

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:

1.It uses only functions and attributes from the IVI class specification.

2.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-COM Interchangeability

Interchangeability with IVI-COM relies upon special components shipped as part of the IVI Shared Components. The first component required for IVI-COM interchangeability is the COM Session Factory. This component allows users to instantiate a specific IVI-COM driver by name, rather than by a hard-coded program reference.

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 COM Session Factory will lookup the logical name in the IVI Configuration Store and instantiate the new driver.

The second component required for IVI-COM interchangeability is the type library associated with the IVI instrument class in use. The IVI-COM type libraries are also part of the IVI Shared Components. These DLLs contain the interface definitions (function signatures, property and parameter types, etc.) for a particular instrument class. Class-compliant IVI-COM 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 COM Session Factory and the IVI-COM type libraries are the basic machinery that enables interchangeability with IVI-COM drivers.

IVI-C Interchangeability

IVI-C interchangeability differs fundamentally from IVI-COM interchangeability in that IVI-C drivers require the use of a special 3rd-party component called a class driver.

The class driver exposes the functions defined in a particular IVI instrument class. All of the class driver functions have generic names, so that client applications have no driver-specific references. For example, rather than naming a function "ag34401_Configure", which is obviously device-specific, the class driver will expose the function with the name "IviDmm_Configure".

IVI-C client applications link to the class driver and call into the class driver's Initialize function providing a logical name. This logical name is the same as that described for IVI-COM drivers above. Specifically, the logical name identifies a specific IVI-C driver that the class driver should load. Once the specific driver is loaded, subsequent function calls on the class driver are delegated to the corresponding function in the specific driver. In this way, IVI-C client applications can be written generically against a class driver and incorporate new specific drivers without modification.

Base Capabilities and Extension Groups

Each IVI class specification partitions IVI-defined functionality into two groups -- base capabilities and 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.

Copyright 2013-16 Boonton. All rights reserved.