Instrument Standards: The IVI Position
•IVI Driver Architecture
•IVI Instrument Classes
•IVI Measurement & Stimulus Subsystems
When test engineers write programs that include instrument control, they typically group the
capabilities of each instrument into a single library known as an instrument driver. The instrument driver encapsulates the various I/O operations to the instrument, and provides a convenient interface for test programs that use instruments.
An important benefit of instrument drivers is their ability to help insulate the test system from changes made in the underlying instrument hardware. Ideally, a test engineer should be able to exchange instruments in a system by only performing the physical exchange, and reconfiguring the system to use the appropriate driver for the new instrument. In practice, however, some work is necessary before the system behaves exactly as it did initially. The work required to exchange instruments in a system will depend on both the system itself, and to which of the standards -- now being defined by the Interchangeable Virtual Instruments (IVI) Foundation -- a particular driver or system will conform.
The IVI Foundation is now developing standards for both drivers and subsystems. When completed, these standards will improve the consistency of driver functionality, and ensure that users will be able to mix drivers from multiple vendors in a system without any conflicts arising. The driver standards will address both architecture and class specifications.
Driver architecture specifications, a high-priority item for the IVI Foundation, define the overall environment in which the drivers operate, as well as refer to some behavioral characteristics common to all drivers. These specifications are necessary to enable one vendor's drivers to work in a system with other vendors' drivers.
The architecture standards define those functions that must be implemented by the driver, but don't relate directly to the particular instrument being controlled. They also specify certain functions that a driver may call to accomplish designated tasks.
Some specific examples of common driver behaviors are:
- Functions that drivers must implement consistently, such as the instrument reset function, which should be identical for all drivers.
- Functions implemented in the driver that are called by development tools, and which must be identical to enable a particular tool to work with drivers from any vendor. For instance, IVI drivers support simulation, which provides a way for programmers to develop software when the physical instrument is not preset. A development tool will then control simulation by calling functions on each driver in the system.
- Functions pertaining to the drivers' run-time environment. For instance, the way in which the driver accesses I/O must be consistent across drivers. If this were not the case, a driver might require a specific vendor's I/O, thereby preventing a user from mixing instrument drivers in a system because of I/O conflicts.
Once complete, the architecture specifications will ensure that drivers from multiple vendors can work seamlessly in a software development environment without conflicting, or requiring a particular vendor's software.
IVI instrument class specifications define and cover the most common functions that a driver must implement for a specific type of instrument, such as the function used to measure a voltage with a digital multimeter (DMM). Although these specifications don't preclude a particular driver from supporting other instrument capabilities, any additional calls will vary between drivers.
Instrument class specifications ensure that drivers from various vendors will provide the same functions for a given instrument capability. Therefore, a program that only accesses these functions can access any instrument with a conforming driver.
Class specifications differ from architectural specifications in that the latter guarantee that the driver will load and operate in the software development environment, while class specifications stipulate that the functions associated with a particular instrument will be defined the same way.
The IVI Foundation is currently finalizing class specifications for DMMs, oscilloscopes, function generators/arbitrary waveform generators, DC power supplies and switches, and has begun working on specifications for power meters, spectrum analyzers, and timer counters.
IVI Measurement & Stimulus Subsystems
Together, the class and architectural specifications specify how to create instrument drivers. However, systems that must be maintained with absolute instrument independence require architectural solutions that transcend instrument drivers. A consistent instrument API is insufficient on its own to accomplish long-term interchangeability due to several factors:
- Application programs may use functions not covered by the class specifications.
- It may be useful to replace an instrument of one type with another type that is capable of the same measurement.
- Different instruments will typically make different measurements – even given the same configuration.
IVI Measurement and Stimulus Subsystem (IVI-MSS) is an architectural specification describing how subsystems can be created that address both measurements and stimulus, and:
- guarantee instrument independence (at the cost of additional software)
- combine multiple instruments to provide a single subsystem
- provide interfaces that are based on the measurements being made (or signals being generated) instead of on specific instrument classes
A subsequent column will describe the degree of expected interchangeability that users can expect with IVI drivers, and how IVI-MSS can be used to guarantee instrument interchangeability.