The IVI Foundation is an open consortium founded in 1998 to promote standards for programming test instruments. Composed primarily of instrument manufacturers, end-users, software vendors, and system integrators, the Foundation strives to create specifications that govern the development of instrument drivers.
IVI-compliant drivers offer a number of benefits, such as a consistent programming interface, better performance, and, most notably, interchangeability. Interchangeability refers to the ability of an end user to replace one IVI driver in an application program with another IVI driver from a different vendor, without modifying or even recompiling the application program. To achieve interchangeability, IVI driver developers must carefully follow all of the requirements laid out in the IVI Foundation specifications.
The following sections present an overview of some of the most important IVI topics for driver developers. This document does not attempt to reproduce all of the details contained in the IVI specifications. For complete information on IVI and for the most up-to-date versions of all IVI specifications and components, visit the IVI Foundation web site.
In This Section
- IVI Specifications
- IVI Shared Components
- Types Of IVI Drivers
- Inherent Capabilities
- Class-Compliant Interfaces
- Base Capabilities Group
- Extension Groups
- Instrument-Specific Interfaces
- Repeated Capabilities
- Standard IVI Driver Features
IVI Specifications
The primary work product of the IVI Foundation is the IVI specifications. These documents are publicly available on the IVI Foundation web site. There are two sets of IVI specifications -- instrument class specifications and architecture specifications.
Instrument Class Specifications
The IVI Foundation categorizes test instrumentation according to instrument class. Each IVI instrument class specification describes the standard functionality required of IVI drivers that want to be compliant with that IVI instrument class. Currently, the IVI Foundation has defined and approved specifications for eight instrument classes.
- 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.6: IviSwtch Class Specification
- IVI-4.7: IviPwrMeter Class Specification
- IVI-4.8: IviSpecAn Class Specification
- IVI-4.10: IviRFSigGen Class Specification
Each class specification prescribes methods, properties, errors, and other behaviors that IVI drivers must implement if they can claim to be class compliant. IVI drivers can support more than one instrument class, or they may not support an instrument class at all. That is to say, a driver may correctly claim IVI compliance without being class-compliant. All IVI drivers, at a minimum, must support a base level of functionality and must follow the IVI architecture. These fundamental rules for building IVI drivers are established by another series of IVI documents known as the IVI architecture specifications.
Architecture Specifications
In order to be considered an IVI-compliant driver, irrespective of instrument class, a driver must be implemented according to the rules and guidelines expressed in the IVI architecture specifications. The following documents comprise the IVI architecture specifications.
- IVI-3.1: Driver Architecture Specification
- IVI-3.2: Inherent Capabilities Specification
- IVI-3.3: Standard Cross-Class Capabilities Specification
- IVI-3.4: API Style Guide
- IVI-3.5: Configuration Server Specification
- IVI-3.6: COM Session Factory Specification
- IVI-3.7: IVI Event Server Specification
- IVI-3.9: C Shared Components Specification
- IVI-3.10: Measurement and Stimulus Subsystem Specification
- IVI-3.12: C Shared Components Specification
- IVI-3.12: Floating Point Services Specification
- IVI-5.0: Glossary
Collectively, the architecture specifications describe such things as common features and capabilities of IVI drivers, required APIs drivers must provide, interface design guidelines, and configuration and deployment requirements.
IVI Shared Components
In order to facilitate IVI driver development and to ensure a consistent experience for end users building IVI-based test systems, the IVI Foundation develops and maintains a series of freely available software components. These components are collectively referred to as the IVI Shared Components, and they must be installed on any computer that will use IVI drivers. In fact, IVI driver installation programs are required to check for the presence of the IVI Shared Components before installing.
The following sections provide a brief overview of some of the most important IVI Shared Components.
IVI Shared Component Installer
The IVI Foundation provides an installer for the IVI Shared Components. Moreover, the Foundation's Shared Component installer is the only IVI-compliant way to install the IVI Shared Components. Third parties are not allowed to develop custom installation programs for the IVI Shared Components.
The IVI Shared Component installer creates a directory structure to house the IVI Shared Components as well as IVI drivers themselves. The root of this directory structure is referred to as the IVI install directory (<IviInstallDir>) and is typically <ProgramFilesDir>\IVI.
The IVI Shared Component installer is available for download from the IVI Foundation web site.
IVI Configuration Store
When the IVI Shared Components are installed, a special XML file named IviConfigurationStore.xml is placed in the <IviInstallDir>\Data directory. This file is known as the IVI Configuration Store and serves as a central repository for IVI driver configuration information.
IVI driver installers are required to populate the Configuration Store with information such as the instrument classes supported, the instrument models for which the driver is designed, and the physical channel names understood by the driver. End users add information to the Configuration Store to describe how they intend to use IVI drivers in their system. End users can specify logical names for IVI drivers and virtual names for channels.
For more information on the structure of the IVI Configuration Store, see IVI-3.5: Configuration Server Specification available on the IVI Foundation web site.
IVI Configuration Server
The IVI Foundation discourages users and driver developers from directly manipulating the Configuration Store XML file (IviConfigurationStore.xml). The Configuration Store is highly self-referential and easily corrupted if modified directly. Thus, the Foundation provides a COM component known as the IVI Configuration Server for programmatically reading and writing information to the Configuration Store.
The IVI Configuration Server is installed automatically by the IVI Shared Component installer. For more information on how to use the IVI Configuration Server, see IVI-3.5: Configuration Server Specification available on the IVI Foundation web site.
COM Session Factory
IVI-COM drivers, like all COM components, must be created using a specific, hard-coded reference to the main COM class. In Visual Basic, this reference takes the form of a class data type, while in Visual C++, a CLSID must be specified. Irrespective of the IDE in use, this identifier must somehow be provided to instantiate the driver and begin calling methods and properties. Yet, having a direct reference to such an instrument-specific item in an application program renders that application non-interchangeble. Specifically, if the user wishes to use a different instrument (and, hence, a different driver), then this CLSID (or class name in Visual Basic) must be manually changed and the program re-complied and re-linked.
The COM Session Factory (or, simply, the session factory)is a very simple COM component supplied with the IVI Shared Components. In spite of its simplicity, the session factory is a key to writing interchangeable applications that use IVI-COM drivers.
Rather than directly creating an IVI-COM driver using a CLSID (or the equivalent), the application program creates an instance of the session factory and then asks it to instantiate a specific IVI-COM driver. For this to work, the user must create a Logical Name in the IVI Configuration Store and associate that Logical Name with the specific IVI-COM driver they with to instantiate. The COM Session Factory simply looks up the Logical Name in the IVI Configuration Store, locates the associated IVI-COM driver and instantiates it accordingly.
Note that, as the name implies, the COM Session Factory is only relevant for IVI-COM drivers. IVI-C drivers use a completely different mechanims (namely, IVI Class Drivers), to facilitate interchangeability.
The COM Session Factory is installed automatically by the IVI Shared Component installer. For more information on how to use the IVI Session Factory, see IVI-3.6: COM Session Factory Specification available on the IVI Foundation web site.
IVI-COM Type Libraries
Part of the IVI Shared Components include a series of COM type libraries that contain the interface definitions for the IVI inherent capabilities as well as for all IVI instrument classes. These type libraries are installed in <IviInstallDir>\Bin and are generally named <IviClass>TypeLib.dll. For instance, the type library containing the interface definitions for the IviDmm instrument class is IviDmmTypeLib.dll.
Client applications must directly reference the IVI-COM type libraries from their projects in order to call methods and properties in IVI-defined interfaces. All client applications must include a reference to IviDriverTypeLib.dll, since this type library houses the interface definitions for the IVI inherent capabilities. Application programs must also reference the type library containing the interface definitions for any class-compliant interfaces they wish to support.
IVI Event Server
The IVI Foundation supplies a software component known as the IVI Event Server for communicating between IVI drivers (and other components) in a test system. Using the Event Server, IVI drivers may send status events, warning events, debug events, and other types of events, to other IVI drivers in the same process, in a different process, or on a different machine on the network.
The IVI Event Server is installed automatically by the IVI Shared Component installer. For more information on how to use the IVI Event Server, see IVI-3.7: Event Server Specification available on the IVI Foundation web site.
Types of IVI Drivers
The IVI Foundation defines two fundamental types of IVI drivers -- IVI-COM drivers and IVI-C drivers. IVI-COM drivers are bonafide COM components that use standard COM interfaces to expose both IVI-defined and instrument-specific functionality. IVI-C drivers are simple DLLs that export C-based entry points.
IVI-COM drivers reference the standard IVI-COM type libraries to implement IVI-defined functionality while IVI-C drivers use standard include (.h) files to define function signatures and attribute values. While IVI-COM drivers offer interchangeability directly, through the use of class-compliant type libraries, IVI-C drivers require a special class driver to achieve interchangeability. This class driver serves as a level of indirection between the client program and the specific IVI driver in question. Application programs that want to allow for interchaneability of IVI-C drivers must only reference the class driver. Application programs that want to allow for interchangeability of IVI-COM drivers must only reference the IVI-COM type libraries. While the IVI-COM type libraries are freely available from the IVI Foundation, class drivers are only available as products from third parties.
Inherent Capabilities
All IVI drivers must support a fundamental set of methods and properties. These methods and properties are known as inherent capabilities, and address such common functionality as driver initialization and shutdown, driver identification, and error reporting. The details of the IVI inherent capabilities are laid out in IVI-3.2: Inherent Capabilities Specification.
IVI-COM drivers provide support for the inherent capabilities by referencing the standard IVI-COM type library IviDriverTypeLib.dll, located in <IviInstallDir>\Bin.
Class-Compliant Interfaces
The set of IVI-COM interfaces the IVI Foundation defines for a particular instrument class, such as the IviDmm instrument class, are known as class-compliant interfaces. Class-compliant interfaces are the fundamental mechanism by which IVI drivers achieve interchangeability. Since the definition of class-compliant interfaces is fixed by the IVI Foundation, end users programming against these interfaces can substitute one class-compliant IVI driver for another, without modifying or recompiling their application program.
There is one IVI specification for each class-compliant interface. For example, IVI-4.2: IviDmm Class Specification describes the syntax and semantics for the IviDmm instrument class.
The class-compliant interface definitions are packaged into IVI-COM type libraries and installed as part of the IVI Shared Components. For instance, the class-compliant interfaces for the IviDmm instrument class are located in the file <IviInstallDir>\Bin\IviDmmTypeLib.dll. IVI-COM drivers that wish to provide support for a particular instrument class must reference the appropriate IVI-COM type library.
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."
Instrument-Specific Interfaces
Modern instruments typically possess much more functionality than is represented in the IVI instrument class specifications. End users must have a way to access the full capability of the instrument they have purchased. Thus, the driver must expose interfaces that are specific to that instrument alone. These are known as instrument-specific interfaces.
Instrument-specific interfaces are obviously not interchangeable. End users programming against a driver's instrument-specific capabilities typically do so to access functionality that is not available in the class-compliant interfaces. Nevertheless, for complex instruments such as spectrum analyzers, there will often be far more functionality in the IVI driver's instrument-specific hierarchy than in the class-compliant hierarchy.
Although, by definition, IVI does not dictate the syntax and semantics of instrument-specific interfaces, there are still guidelines that must be followed in the design of the interfaces if the driver is to be IVI compliant. Most of these rules are laid out in IVI-3.4: API Style Guide.
Repeated Capabilities
Instruments often contain multiple instances of the same kind of functionality or capability. For instance, modern oscilloscopes may have multiple channels, each with independent settings for such things as vertical scale. IVI refers to funtionality that is duplicated in an instrument as a repeated capability.
For a complete explanation of repeated capabilities in IVI instrument drivers, see the IVI specification IVI-3.1: Driver Architecture Specification.
Accessing Repeated Capabilities from Client Code
The repeated capability structure for IVI-COM drivers is designed to faciliate easy access from client programming languages. The following C++ code snippet shows how a client would access a repeated capability instance called "REF" in the Channels collection of an IviScope driver.
IIviScopePtr spScope(CLSID_AcmeE4321); // ... Initialize called IIviScopeChannelPtr spChan = spScope->Channels->Item["REF"]; spChan->Enabled = true;
Instances of repeated capabilities are identified by name. The Item method uses this name to locate and return a pointer to the desired instance.
There are two types of repeated capability names -- physical names and virtual names.
Physical Repeated Capability Names
Physical repeated capability names are those that the driver writer specifies during driver development. These are the names that the driver natively understands.
Virtual Repeated Capability Names
Virtual names allow end users to specify their own names for repeated capability instances and map those names to the physical names that the driver natively understands. The user establishes the virtual-to-physical name mappings in the IVI Configuration Store. At runtime, the user can supply a virtual channel name to the Item method and the driver will use the mappings in the IVI Configuration Store to translate the virtual name into a physical name that the driver understands.
The purpose of virtual names is to faciliate driver interchangeability. If a user writes application code using virtual names, then no modifications to the application code are necessary when an existing driver is replaced with one that natively understands different physical names. The user need only modify the appropriate settings in the IVI Configuration Store to map their virtual names to the new driver's physical names.
Standard IVI Driver Features
Many of the customer benefits of IVI drivers lie in the standard features that IVI drivers support. The follow section discusses some of the most important features for users of IVI drivers to understand.
State Caching
As a means to offer better performance in customer test applications, IVI drivers often support a feature known as state caching. The principle of state caching is quite simple, although in practice it can be extraordinarily difficult to implement properly.
When a end user enables state caching for an IVI driver, the driver attempts to determine if new settings passed into the driver are different from the actual instrument state. In this way, I/O traffic between the driver and the instrument is reduced, as fewer I/O calls are performed.
In the simplest example of when state caching improves performance, consider what happens when a user passes identical values several times in a row for the frequency property on a function generator driver. Without state caching, each call into the driver would result in an I/O function call to the instrument, whereas a driver performing state caching would detect that subsequent calls to the frequency property were redundant and should not result in any communication with the instrument. Correspondingly, the driver can "remember" the last known value for instrument properties so that queries can be performed by retrieving data from computer memory, rather than by performing instrument I/O.
As with caching schemes in other types of software systems, IVI driver state caching is frought with potential pitfalls. The chief challenge in properly implementing state caching is maintaining cache coherency. Complex instruments often have complex couplings between instrument settings, making it difficult for the driver to track whether or not settings stored in the driver cache are valid. Consequently, many instrument vendors choose not to implement state caching in the driver.
For more information on state caching, see IVI-3.1: Driver Architecture Specification.
Range Checking
Range checking in IVI drivers simply refers to the ability for the driver to test whether or not input values passed to the driver are within an acceptable range. End users typically use range checking during debugging and, after validation is complete, disable it to maximize performance.
For more information on range checking, see IVI-3.1: Driver Architecture Specification.
Coercion and Coercion Recording
Instruments often accept only a discrete set of values for certain properties. For example, a DMM might only accept values such as 10 V, 100 V, 300 V for the voltage range setting. These discrete value sets will necessarily be different for different vendor's instruments. An Agilent DMM may accept 10 V, 100 V, 300 V while a Fluke DMM accepts 20 V, 200 V, and 400 V. As a result, IVI class specifications are forced to define such real-valued properties as accepting a continuous range of values, even though the underlying instrument only accepts a discrete set of values.
Following along with the DMM voltage range example, if a user sends a value of 150 V for the voltage range, the instrument will internally coerce the value to one of the accepted values, such as 300 V. To maximize interchangeability, the IVI class specifications provide guidance on how IVI drivers should coerce user requested values for specific properties.
To aid end users in building interchangeable applications, IVI drivers may implement a feature called coercion recording. If a user enables coercion recording, the IVI driver retains a log of each user value that it coerces. Standard functions in the IVI Inherent Capabilities provide the user with access to the driver's coercion log.
For more information on coercion, see IVI-3.1: Driver Architecture Specification.
Simulation
IVI drivers are often constructed for complex instruments that are difficult to procure or that are in high demand at the end user facility. Consequently, it may be the case that end users need to be able to test their application programs without being physically connected to an instrument. IVI driver simulation is a feature that allows end users to use IVI drivers without a physical connection to the instrument.
When an end user enables simulation in an IVI driver, the driver performs no I/O communication whatsoever. IVI drivers are free in their choice of mechanisms for returning meaningful output values to the end user, but the intent is that the user program should be able to proceed normally when calling functions on the driver. This allows the end user to exercise their test application before the actual hardware is available.