In 1998, nine companies created the Interchangeable Virtual Instruments (IVI) Foundation. The foundation’s goal, simply put, is to enable end-users to switch from one brand of test instrument within an instrument class to another without having to rewrite large segments of test program code.
IVI focuses on instrument drivers-software modules used by test programs to communicate with and control test instruments. The organization establishes specifications applicable to particular instrument types, but also to instruments in general.
So has the IVI Foundation progressed? Over a relatively brief period of time, much has been done.
Last year, IVI established standard user command sets for five classes of instruments (see sidebar below). Parallel work also has begun on additional instrument classes. The foundation’s focus for the remainder of this year will be to complete these driver architecture specifications so that vendors can begin supplying, and users can begin exploiting, the advantages of instrument interchangeability.
In other news, IVI has formed a users’ working group, which held its first meeting in May. At the request of the users’ group, IVI also established a panel to investigate approaches to certifying IVI software (see sidebar below).
The foundation decided, as well, to incorporate as a legal entity, to protect the group’s intellectual property and control the release of certain software components. The foundation hopes to incorporate in Delaware this year and has chosen a law firm to provide assistance in the process.
"There are certain areas we don’t want to compete in," says Scott Rust, IVI Foundation chairman and manager of the Test and Measurement Software Group at National Instruments (NI). IVI "needs to own, distribute and grant licenses to" certain shared software components, he says. Incorporation will provide a repository for these shared components and help ensure that they are identical in everybody’s system, he adds.
The architecture specs "define the system into which you install an IVI instrument driver, as well as all the services [the driver] can depend on and all the requirements it must fulfill," Rust says. The architecture standards–elements of which apply to all instrument types–are "the most important missing pieces" of the IVI standards suite, according to Kevin Borchert, marketing manager for measurement connectivity operations with Agilent Technologies. Agilent joined IVI in January of 1999.
Writing architecture standards can be complex. IVI membership is now large–54 companies at last count–and each member may have different ideas on how to proceed. The architecture, like the IVI class specs, also needs to support both drivers based on the C programming language and those based on Microsoft’s Common Object Model (COM) development environment, a newer software standard.
Many elements to the architectural specifications exist, but one basic example is the "config store" component. The config store spec describes the software in which an instrument’s configuration data is stored. This store element is important because the test system needs to access configuration information in order to accept a new device. So an agreement must be made on how to read from, and write to, the config store database, explains Joe Mueller, senior connectivity architect with Agilent.
IVI members also are debating the config store format, Rust says. But the important thing for driver developers is "to have an easy way to interact with, and get information in and out of, that file." The shared components are in the definition stage now, says Dany Cheij, NI test and measurement product manager. IVI hopes to finalize the specifications that define the components this year.
COM vs. C
There also needs to be agreement about how to render expressions in both C and COM. Developing IVI specs is like developing new telephony standards: they have to be translated into English and French, Borchert says. Agilent has emphasized COM in new driver development.
"Part of the architectural exercise...will be understanding what is required to define a software component and how it appears in C and in COM," says Rust, in agreement.
The foundation hopes to begin releasing the IVI architecture and updated class specs, starting late this year, adds Paul Salopek, a program director with IVI and test system developer with BAe Systems.
But the COM vs. C question is not a driver of complexity, Mueller says. "At the [IVI] meetings, we’re not talking as much about how you ‘spell’ something in COM and C," he says. "We spend time talking about the semantics"–what things are called. "A large part of that [architectural work] is language independent."
Nevertheless, the distinction between the programming technologies is important. COM has been Agilent’s "strong theme" since the company joined the IVI organization, Borchert says. COM has appeal as "a way to encapsulate software [drivers] independent of development environments," Mueller says.
National Instruments will support whatever interface the user wants, Cheij says. However, "most test and measurement systems at this point tend to use C-based drivers and architectures," he points out. "We don’t want to neglect the installed base." C also is a cross-platform environment, Cheij adds. And C "doesn’t limit you to one operating system," as COM does at this time.
"Until about a year ago, almost everybody used the ANSI [the American National Standards Institute] C programming language," Salopek says, and back then, most software drivers were written in C.
Still, BAe Systems and other companies also are interested in using and developing COM-based instrument drivers. "The IVI Foundation’s adoption of a language-neutral interface such as COM makes a lot of sense," adds BAe engineering specialist Ron Taylor. The interface "should help promote widespread use of the IVI standards."
The Interchangeable Virtual Instrument (IVI) Foundation recently established a users’ working group to make it easier for prospective users of IVI standards to provide input into the organization’s efforts.
At the group’s first meeting, part of an IVI gathering in May, users expressed interest in finding a means to certify that software developed under the IVI umbrella meets IVI specifications. The concern is "based on past history," says Gail Matysek, a fellow engineer with Northrop Grumman, who heads the users group. "VXI Plug & Play drivers have had problems," she says, referring to a predecessor test instrument standards group. In response to this request, IVI has formed a working group to investigate the issues.
Users want a means or a process "by which we can deem the software to be good and non-buggy," Matysek explains. Validation and certification might be achieved through software that "calls the interfaces and observes to see if they work," she adds. Or a process could be put in place to do the same thing. "It’s up to them to figure it out."
Among those attending the first users’ group meeting were Northrop Grumman, Boeing, Rockwell Collins, Lucent Technologies, and the UK’s Defense Logistics Organization.
A Standards Status Report
Interchangeable Virtual Instruments (IVI) Foundation members approved command sets for the following instrument types:
IVI also plans to develop standards for a second group of instrument classes, including: