Progress in the VXIplug&play System Alliance has been fast and far reaching in the past year and a half. More than 35 members have produced formal standards in many areas, including instrument drivers, soft front panels, installation disks and configuration data-base information. Among the new standards is the Virtual Instrumentation Software Architecture (VISA), the I/O interface standard upon which all VXIplug&play software components are built.
To most users, standard instrument drivers and soft front panels are probably the most exciting developments from the alliance. Today, VXIplug&play-compliant instruments include standardized, high-level instrument drivers that take care of the low-level details of I/O communication.
As such, users rarely need to deal with low-level I/O protocols. Nonetheless, I/O software is the foundation on which the other standards are built.
I/O software handles the details of communication over a physical connection between the computer and instruments, such as VXI, MXI, GPIB and RS-232. Without a common I/O standard, higher-level software components often cannot coexist on the same machine, much less achieve interoperability. As a result, VISA is a unifying standard for the entire industry.
Looking Back Briefly
A common I/O standard has been very difficult to achieve in the past, for both technical and political reasons. Over the years, several implementations have been developed along with interface hardware, each with unique features. Some address a broad, general-purpose scope; others maximize ease of use for a limited set of applications; still others emphasize complete functionality, low-level flexibility and performance-tuning capabilities for the knowledgeable user.
None are fundamentally wrong–they simply reflect a different set of priorities. To be endorsed by all, VISA had to accommodate all points of view and provide a migration path to the future for the entire installed base.
Moving Ahead
VISA also needed to anticipate future requirements, such as the concept of Interface Independence. Rather than simply write software for a GPIB instrument that is independent of the GPIB interface hardware, users want their software to be independent of whether GPIB or some other type of connection is used, such as RS-232 or VXI. And VXI users want to write software that works whether the VXI computer is embedded, connected via MXIbus, or connected through a GPIB-to-VXI translator.
Another forward-looking concept is multiprocessor, or distributed, systems. Whether they are stand-alone instruments with built-in network interfaces or modular VXI instruments with multiple processors, distributed architectures are becoming increasingly popular. Standard backplane architectures such as VXI and Peripheral Component Interconnect (PCI) and standard networks such as Ethernet are driving this interest.
As distributed test-system architectures become more popular, the I/O control software must be up to the task. It is important not only to provide access to new capabilities for new users, but also to provide a smooth migration path for the installed base of existing systems.
VISA Goals
VISA was developed as an open industry standard in the VXIplug&play Systems Alliance. VISA also is undergoing formal IEEE standardization in the 1226.5 subcommittee. Specifically, VISA is designed to:
o Create a single, easy-to-use set of I/O control functions independent of the instrument type, the interface type, the operating system, the programming language and the networking mechanism.
o Transparently accommodate single processor, multiple processor and fully distributed system architectures.
o Provide a migration path for the existing installed base.
o Provide a migration path from nondistributed systems to distributed systems.
Products and Time Frames
The transition to the new VISA standard is occurring incrementally. The full VISA specification is approved by the alliance as VPP-4.1, but no full VISA implementations are currently on the market.
The VXIplug&play alliance has set Dec. 31, 1995, as the deadline for full VISA implementations. At that time, instrument drivers and other VXIplug&play software will take full advantage of VISA, and VXIplug&play controllers must provide a full VISA implementation for I/O. This will run all VXIplug&play software as well as the installed base of applications with compatibility layers that map existing Application Programmers Interfaces (APIs) to VISA.
In the meantime, the alliance has produced a specification for the VISA Transition Library (VTL). This library is a subset of the full VISA API that can be implemented as a layer that maps onto existing I/O software implementations.
The subset is a core set of the most-used VISA calls, and the VTL API and syntax are compatible with the full VISA. This subset allows multiple I/O software vendors to get up and running quickly with a standardized API that moves everyone in the direction of VISA.
VXIplug&play instrument drivers can still use the VTL API until the Dec. 31 deadline. Until then, VXIplug&play controllers must provide the VTL interface along with NI-VXI and NI-488.2. Between now and Dec. 31, vendors that do not provide VTL, NI-VXI and NI-488.2 can at least provide the VTL so that VXIplug&play instrument drivers and soft front panels can run, though other VXIplug&play software may not.
VTL implementations are already on the market and available from National Instruments with the VXIpc embedded controllers, MXI interfaces and GPIB-VXI/C. LabVIEW and LabWindows/CVI support the VTL interface, and VTL implementations are available for controllers from Hewlett-Packard and Tektronix. By the end of this year, all VXIplug&play controller vendors are expected to offer full VISA implementations.
The User’s Standpoint
From a user standpoint, VISA is very similar to existing I/O libraries and is used in much the same way. Table 1 shows a subset of the VISA functions. VISA features a single set of core functions that controls all types of instruments regardless of physical interface, along with a small number of interface-specific functions.
VISA is a functional superset of the existing I/O software products offered by leading vendors in the market. To illustrate, NI-488.2 has more than 60 function calls, NI-VXI has more than 130, and Hewlett Packard’s SICL has over 100.
VISA, while being a superset of all these products, requires approximately 90 operations–thanks to VISA’s object-oriented internal architecture.
The Internal Architecture
While a VISA user will see a familiar set of I/O function calls, the internal architecture is quite different than existing implementations. VISA uses an object-oriented architecture to provide complete functionality for even the most advanced user, yet offers a packaging methodology that hides sophisticated details from casual users.
Understanding VISA’s internal architecture gives some insight not only into how its use compares to traditional I/O software, but also into some new capabilities that can be used to perform functions not possible today. Just as most operating system suppliers are moving to object-oriented architectures to provide exciting new tools and techniques for computer users, VISA’s object-oriented capabilities will enable new tools, techniques and capabilities for instrumentation users.
VISA uses a model called device resource independence, a combination of a bottom-up approach to device capabilities and a top-down approach for presentation to users. The bottom-up approach looks at individual capabilities of instruments connected to all types of interfaces to expose the features of all types of devices.
The top-down approach groups device features so that casual users see a simple, easy-to-use interface that is familiar, yet gives access to advanced features if they need them. This model achieves independence in its most complete sense–at the device level, rather than only at the interface level.
The software elements inside VISA are called resource classes. A resource class generally refers to the definition of a particular capability of a device, such as read, write and trigger. A VISA resource refers to a particular implementation, or instance, of a resource class; for example, the read port on a particular GPIB device at a particular GPIB address.
Each VISA resource consists of three parts–a set of attributes associated with it, a set of events that can asynchronously act on it or be generated from it, and a set of operations that control it. For example, in Figure 1 the VISA write resource is used to send ASCII messages to a device. The write port has the attributes of time-out value, transport mechanism, end mechanism and protocol. The only event for a write is a user abort; and the operations are write, with parameters of a buffer and a number of bytes to transfer, the set and get attribute functions (used to configure the attribute details), and lock and unlock.
In VISA, a session is a term used to designate a communication channel with a VISA resource. A user begins communication with an instrument, for example, by calling viopen to open a session to the resource(s) associated with that device. Resources can have multiple sessions open to them. In addition, a VISA resource can itself control one or more other resources through sessions that it opens with those other resources.
Figure 2 depicts the basic pieces of the VISA model. Device resource independence is the basis used to define and create the resources within VISA. VISA specifies a common definition for how to create all resources, referred to as the VISA resource template.
The VISA Resource Manager is responsible for managing, controlling and distributing (across a network) resources within VISA. As such, users do not need to know about most details of resource management and distribution of VISA resources within a system.
The VISA Resource Manager is a resource adhering to the VISA Resource Template, just like any other resource. Users can access Resource Manager functions by opening session(s) to the Resource Manager itself.
Continuing up the pyramid, VISA defines three levels of resources: I/O-level resources, instrument-level resources and user-defined resource groupings. The three levels reflect the capability for higher-level resources to use, or inherit, the capabilities from lower-level resources. The I/O-level resources provide control of all low-level GPIB, VXI and serial capabilities, and can be easily extended to control any other type of I/O interface.
Instrument-level resources provide control of any grouping of I/O-level resources from the same session from a single resource. An instrument-level resource represents the level of interaction that most users are familiar with using traditional I/O software. It presents a traditional programming model in which the user opens a single session to control each particular physical device.
The third level of resources is user-defined resource groupings, also referred to as virtual instruments. A virtual instrument, in this context, is a name given to a session of a VISA resource that provides the functionality of a traditional, stand-alone instrument.
This level includes the previous two levels. It also incorporates any resources that a developer might create to augment the functionality of the physical instrument, such as additional data analysis capabilities beyond that of the physical instrument itself.
The final level of the model, the top of the pyramid, is simply the user-level applications. These applications simply use one or more of the VISA resources to accomplish some task.
These applications are not themselves VISA resources, though VISA provides a resource registration mechanism that allows users to embed application software inside VISA as VISA resources. This takes advantage of VISA’s capability to transparently handle the details of distributing the user’s application in a distributed system architecture.
VISA’s object-oriented architecture gives the user some new capabilities. Users can program individual instruments by opening a session to an instrument-level resource for each instrument. Unlike traditional I/O software, VISA gives users much more access to the internal operation of the I/O software.
VISA, for example, allows users to open sessions not just to instruments, but also to the individual VISA I/O level resources. For example, a user can open a session to the write port of an instrument to monitor the bus traffic being sent to the instrument by other software. Such techniques can also be used to simulate instruments, or to monitor the performance of the system by tapping into VISA resources at various points.
Users can group the individual resources to create their own virtual instruments. For example, the user can assign a VXIbus trigger line to be associated with a particular instrument in the system by grouping the trigger resource with the other resources of that instrument. The resulting group would be managed automatically by VISA and programmed by opening a single session to the instrument.
Users can also create instrument-level resources with any combination of capabilities they desire. For example, the user could have a single session that communicates with a virtual instrument that is a combination of resources from a VXI instrument, VXI triggers, external GPIB instruments and even some additional software of the user’s design.
Because such a virtual instrument can be created as an internal VISA resource managed with a single session, the user can program it as though it were a single instrument. This could occur even if parts of the instrument are located remotely, because VISA takes care of the distribution mechanism transparently.
Distributed System Support
The advanced, object-oriented nature of VISA provides a direct mechanism for the distribution of software across any type of network. Consider, for example, the system architecture shown in Figure 3. The programming model is exactly the same, regardless of the location of a piece of VISA I/O control software and the location of the corresponding instrumentation hardware that the software controls. This approach provides a smooth migration path for the installed base as well as a seamless migration path for implementors of nondistributed VISA systems to fully distributed VISA systems.
Figure 3 illustrates several main points:
o The system is viewed as one entity, even though there are three types of instrument control hardware.
o All of the communications between the two applications and the devices are handled by making connections to VISA Instrument Control Resources through the VISA Resource Manager.
o Applications do not need to know the location of the device that is to be controlled.
Conclusion
VISA provides a single multivendor foundation for instrumentation software. It is based on familiar concepts and capabilities, so as users learn more, they will find new capabilities at their disposal, especially in the area of distributed instrumentation.
VISA’s object-oriented internal architecture is the key to its capability to be a functional superset of all implementations yet deliver ease of use for casual users. VISA can support the entire installed base from all existing suppliers with compatibility layers that map existing APIs on top of VISA.
The entire installed base of existing systems, therefore, can run on VISA implementations without requiring a single user to rewrite any existing software. Meanwhile, new applications can use the native VISA API, which is not only easier to use, but offers new features not available in existing implementations.
About the Author
Bob Mitchell is the VXI/MXI Engineering Manager at National Instruments, where he has worked since 1987. He has been the company’s lead technical representative to the VXI Consortium since 1988, and currently is the chairman of the VISA Technical Working Group for the VXIplug&play Systems Alliance. Mr. Mitchell received a B.S. degree in computer science from the University of Texas. National Instruments, 6504 Bridge Point Parkway, Austin, TX 78730-5039, (512) 794-0100.
Acknowledgement
Art courtesy of National Instruments; concept and design by Steve Lasher and Michael Hewitt.
Copyright 1995 Nelson Publishing Inc.
February 1995