Test developers have been trying to build interchangeable systems for years. Many industry initiatives have attempted to address this issue with varying degrees of success. The Interchangeable Virtual Instruments Foundation (IVI) is in the process of defining specifications for building such interchangeable systems.
These specifications provide a definition of IVI instrument drivers and their capabilities, including a set of class application programming interface (API) specifications, and a definition of the different driver architectures and interchangeability routes.
Test and measurement engineers have had a long-standing desire to exchange instruments in their systems without having to rewrite their programs. This ability can be very useful to system developers in many situations. For example, when building a production test system, a test developer may need to build a system and validate it using multiple test instrument racks. This allows them to switch between the different sets of hardware on the production floor very rapidly, thereby minimising overall system downtime.
The problem with this, however, is that when you are using a variety of instruments, you end up dealing with a variety of system software that makes instrument interchangeability hard to achieve. The IVI Foundation is helping system developers bypass this problem by defining standard specifications for achieving instrument interchangeability. The overall goal of the organisation is to provide a mechanism for creating one test program and using that same program with multiple sets of instrumentation hardware.
IVI driver definition
The main portion of the IVI specifications defines the overall IVI system architecture and the inherent capabilities of all IVI compliant instrument drivers. The IVI system architecture divides driver functionality into two layers. One layer, called the instrument-specific layer, is focused on providing drivers for individual instruments, similar to old-style drivers such as VXIplug&play. This layer provides a consistent API, and incorporates features such as instrument simulation, range checking, and state caching. The other layer, called the class-compliant layer, is focused on providing a generic instrument API for each instrument class (or type) that can be used with many instruments in that class. The main benefit of the class-compliant layer is to provide the test system developer with instrument interchangeability.
This architecture is necessary to provide interchangeability. The idea is to define a common programming interface for instruments of a similar type. When this is accomplished, IVI specific drivers for a certain type of instrument have very similar APIs and can be easily interchanged through the class-compliant layer.
There are currently five classes of instruments with defined class specifications. These are DMMs, oscilloscopes, function generators and arbitrary waveform generators, DC power supplies, and switches. More class definitions are being defined, including those for spectrum analysers, RF signal generators, power meters, and digital test instruments.
In addition to features such as instrument simulation and state-caching that are mentioned above, the IVI specifications also define several features and inherent attributes of IVI drivers including, range-checking, multithread safety, interchangeability checking, and coercion checking. While some of these features are required of all IVI drivers, others are optional. Finally, these specifications also define a configuration mechanism that is used to set up an IVI system.
IVI interface architectures
There are currently two architectures being defined by the IVI Foundation. These define what interface a driver exposes to the test program developer. One of the architectures is based on ANSI-C technology, while the other uses component object model (COM) technology. The reason for defining two architectures is to provide a choice for instrument driver and test system developers.
The ANSI-C portion of the specifications defines a C-based driver. A C driver is presented in the form of a dynamic link library (DLL), such as a Windows DLL. All the driver function calls are presented with C function prototypes and have to be called appropriately. The C specifications also define other components, such as error handling and driver session creation and management that are necessary to ensure overall system robustness.
C interface: There are many benefits to having a C interface. C is a mature, proven, and stable technology that has been and will be around for a long time. C facilitates the creation of multiplatform systems, since it is available on almost all operating systems including Windows, Macintosh, Linux, and Sun Solaris. In addition, C interfaces have no encumbrances that can adversely affect performance.
There are also some disadvantages to using C. C interfaces are not as easy to use in Visual Basic, a popular development environment. In addition, C does not provide a way to create multiple namespaces. You cannot use multiple DLLs with the same C function names in the same program. If multiple instrument driver DLLs have functions of the same name, the program linker returns an error. This limitation requires that the C function names for the instrument specific interfaces in each driver begin with a unique instrument prefix.
COM interface: Similarly, the COM specifications define the architecture of COM-based drivers. These drivers provide a standard COM interface that exposes the class-defined functionality through methods and properties. COM also offers many advantages. It is the standard method for using components in Visual Basic. In addition, COM interfaces have namespaces, so the methods and properties do not need an instrument prefix. Finally, distributed instrument communication is possible using a variation of the technology called distributed COM, or DCOM.
There are also a few disadvantages to using COM interfaces. COM is not as easy to use in C, C++, and other standard development environments. At this time, COM is fully and freely available only on the Windows platform. Finally, and maybe most importantly, COM is a young and evolving technology, so the IVI COM specifications that are written today may become obsolete due to changes in the COM technology.
While these two interfaces have been chosen for standardisation in the IVI Foundation, no one interface is best for all environments. In any development environment, it is easiest to use an interface that is native to that environment. While a C interface and a COM interface are best in C and Visual Basic respectively, a C++ interface is best in Visual C++, and a native LabVIEW interface is best in LabVIEW. These and other interfaces to IVI drivers can be supported by individual vendors, as the IVI specifications do not prevent this.
Routes to interchangeability
Each of the interface technologies that was mentioned above provides for instrument interchangeability in a unique way, which is specific to the technical requirements of that interface technology.
The C architecture provides interchangeability through the class driver mechanism. Because of the namespace issue discussed earlier, all driver functions in a C driver include a prefix that is specific to the instrument. When these function calls are embedded in a test program, exchanging that instrument for another requires the developer to modify the program to contain the functions with the new instrument's prefix.
This problem is resolved by defining a class driver that exports the functions defined in the class specifications and uses a generic prefix such as IviFgen or IviScope. To achieve interchangeability, test programs call the class driver functions rather than specific driver functions. The class driver serves as a pass-through layer to the specific driver by being bound to the specific driver at run-time.
In the COM architecture, interchangeability is achieved differently. Each COM specific driver that complies with one of the IVI class specifications contains both an instrument specific interface and a class-compliant interface. For a particular class, the class-compliant interface is identical from one COM specific driver to another. This is possible because each COM specific driver has a different namespace and does not require an instrument prefix. Thus, a test program can use interface, method, and property names that will be present in every specific driver of the same class.
Although the COM methods do not explicitly refer to the specific instrument being used, the developer still needs an explicit reference to the instrument in the declaration part of the program. To take care of this problem, IVI COM architecture provides what is called the IVI-COM Driver Factory. The factory binds the COM methods to the appropriate driver specified in the IVI configuration.
In both architectures, there is also the problem of explicitly referring to the hardware address of the instrument in the code. To overcome this, the IVI specifications define the concept of a logical name, which is bound to a hardware address and an instrument driver in the IVI configuration store. Either the class driver or the IVI factory reads the IVI configuration store and uses the definition of the logical name to determine which specific driver and hardware resource it should refer to. Table 1 provides examples of instrument communication for each of the four scenarios described.
Increased interchangeability
Both mechanisms described provide interchangeability in most cases, but there are a few situations where they are not sufficient. For example, they both do not provide an appropriate route for interchanging two instruments from different classes that are capable of making the same measurement. In addition, if the hardware itself is not interchangeable (different capabilities), then the ability of the software to provide interchangeability is not enough.
To account for these differences, developers usually take care of these irregularities in their own code. However, the IVI Measurement and Stimulus Subsystems (IVI-MSS) working group is working on a specification that defines how these differences can be accounted for by abstracting them into another layer in the IVI hierarchy called the role control module (RCM). In order to interchange instruments in this type of system, only this extra layer needs to be modified. Usually, a system developer will retain the services of an integrator who will develop these RCMs for them. This integrator will also be consulted whenever the user needs to interchange instruments in the system. In some of these cases, when used with the IVI architecture described earlier, IVI-MSS can offer increased interchangeability, although at the expense of increased cost and complexity.
Conclusion
The IVI specifications can be used to achieve a long desired goal of test system developers. When using IVI drivers in designing a test system, a developer can be confident that the system they are building will continue to work when the current instruments they are using become obsolete and need to be replaced.
For more information see www.ivifoundation.org or contact Mike Hutton, National Instruments South Africa, 080 020 3199, [email protected]
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version