Since the early '70s, test-equipment manufacturers have designed modular or card-based instruments using proprietary architectures. Unfortunately, only a few of these architectures were supported by more than one vendor. The need to allow different instruments to operate in a commonly controlled test system, as well as to reduce instrument size, were the major drivers to produce interoperable and more flexible modular instrumentation. With support from multiple vendors, an instrument-on-a-card (IAC) approach could reduce size and allow standard software to control entire test systems. As a result, in 1987, five test-and-measurement companies (Colorado Data Systems, since acquired by Tektronix; Hewlett-Packard; Racal-Dana Instruments; Tektronix; and Wavetek) joined to form the VXIbus (VMEbus extension for instrumentation) Consortium. Their goal was to maintain, promote, and develop an open architecture for modular instrumentation.

Although many companies have introduced VXI-compatible products since the consortium was formed, two obstacles stood in the way of delivering a truly open architecture: the failure of hardware standards to define connectors, card cages, and fixtures for modular instruments, and a similar failure to define software to control instrument panels. The VXIplug&play Systems Alliance was formed in September 1993 to facilitate and promote ease of use of VXI products.

Says Fred Bode, executive director of SCPI (Standard Commands for Programmable Instruments) Consortium, "VXIp&p is the most important thing that has happened in VXIbus usability. The Achilles' heel of VXI-based systems was the lack of software standards. This failure made automatic-test-equipment (ATE) systems difficult to use. You can refer to IEEE-488.2 (GPIB) as a hardware standard. In contrast, VXIp&p is a software standard."

VXIp&p will also simplify VXI system integrators' role. According to Steve Jennings, Tektronix's product manager of VXI systems, "Plug and play will ease the integration path of VXI-based instruments with guaranteed compatibility among different systems."

Today, VXI system integrators have three distinct options in external controllers. In the first option, you can use the IEEE-488 bus to link VXI mainframes to an external computer. As a second option, you can use the RS-232C interface, which almost every computer and terminal supports, to control the VXIbus. In addition, using RS-232C with a modem allows you to control a VXIbus system over a telephone. In the third option, the high-speed MXIbus (multisystem extension bus) directly connects an external computer to the VXI backplane. In an internal controller configuration, you have a custom VXI computer embedded directly into the VXI mainframe. With this direct access, the controller can transfer data to other VXIbus devices at 5 to 10 Mbytes/sec. All of these cobbled approaches are necessary because of the absence of plug and play.

All hardware conforming to VXIbus specifications can be adapted to VXIplug&play systems. However, the system will lack the benefits of plug and play. A VXIbus system may contain one or more VXIbus subsystems. One full VXIbus subsystem contains 13 modules. Each subsystem consists of a central timing module along with up to 12 additional instrument modules (see Fig 1). A VXIbus system can contain up to 256 logical devices. VXIbus logical devices may occupy more than one module slot, or multiple VXIbus logical devices can be located on one module. CPUs, memory, harddisk drives, IEEE-488-to-VXIbus interfaces, ADCs, DACs, DMMs, and function generators are examples of logical devices.

The specification allocates each VXIbus device a unique set of 64 bytes in the top 16 kbytes of the A16 memory space (C000h to FFFFh). These 64 bytes contain configuration, communication, and device-specific registers. Four deviceconfiguration registers contain basic information that configure and boot a multivendor VXIbus system. In addition, eight communication registers provide the hardware to support message-based interdevice communications. These registers, with their defined protocols and commands, form the low-level foundation for VXIbus communications. These registers form the hardware base upon which the software architecture is built.

The VXIp&p initiative's focus is different from that of the VXI consortium. Instead of module-level interoperability, VXIp&p targets system-level interoperability. Toward this end, the VXIp&p Alliance defined a specification. Called VPP-4.1, this specification creates a virtual-instrument software architecture (VISA). Full VISA implementations are not yet available. However, the VXIplug&play Alliance wrote the VPP-3.3 specification, called VISA Transition Library (VTL). The VTL provides an upgrade path from existing IEEE-488.2 and VXI I/O standards to the next-generation VISA I/O library. Several vendors are supplying their beta VTLs and are using these VTLs to test and implement multivendor VXIplug&play system components.

VXIp&p uses clearly defined instrument drivers. These drivers conform to the VPP-3.1 and VPP-3.2 specifications. A conceptual model (Fig 2) shows how the instrument driver interfaces to the external software system. At the heart of this model is the instrument-driver functional body, which is the actual code of the instrument driver. The program-developer interface is the mechanism for calling the driver from a higher level software program. The interactive developer interface assists the software developer in understanding what each instrument-driver function does and how to use the interface to call each function. This interface is usually a graphical front panel. The I/O interface is the interface through which the instrument driver performs I/O to and from instruments. To claim VXIp&p compliance for an instrument, its vendor must supply an instrument driver (preferably in C source code) and a "soft" front panel (executable file).

As with any other instrument, you like to have immediate interaction with VXIbus instruments. However, VXIbus modules do not have traditional controls or displays. Instead, these instruments offer VXIp&p soft front panels (Fig 3). Soft front panels are stand-alone applications with graphical user interfaces. The soft panels demonstrate the major features of the instrument and give users interactive control. Instead of physical knobs and displays, the virtual instrument graphically presents its front panel on a VGA monitor. Using soft front panels, you can immediately interact with the instrument after integrating the VXI module in your system. The soft front panels help you verify module configuration and installation and gain familiarity with the instrument features.

While VISA/VTL ensures system-level interoperability, other components are necessary for fast and easy system design and integration. To provide these components, the VXIplug&play Alliance has defined System Frameworks, which include computer hardware and operating-system software. Three defined frameworks are:

• Win framework for application-development environments (ADEs) that use Microsoft Windows

• Gwin framework for LabView from National Instruments

• DOS framework for ADEs using Microsoft DOS

Maximum ease of use and interoperability results from a system integrated using system components from the same system framework. Currently, the Win system framework is the most popular, because it is compatible with more programming tools than are the DOS or Gwin frameworks. Also, the Win framework allows programming tools that can use Microsoft dynamic link libraries (DLLs) to access instrument drivers that are provided with Win framework instruments. Examples of these programming tools include Hewlett-Packard's VEE, Microsoft's Visual Basic, C, and other types of Windows development software; and National Instruments' LabWindows/CVI. Given the developing nature of VXIplug&play standards and the scope they offer to welcome new customers into the VXI fold, the industry is preparing itself with several strategies and products.

The leading VXI vendors are using VXIplug&play to level the playing field and to promote competition among its members. This competition leads to better products.

Jon Titus, editorial director of Test & Measurement World magazine, says, "Obviously, all companies are looking after their own interests. They know they must serve the customer. A company like HP, for example, will make as many products available as it can. But, to sell those broad lines of products, it realizes that engineers don't want to worry that this software won't work with that board. Therefore, the companies will adhere to the standard. They will compete in the features their software provides with their instruments. This approach also helps small companies produce products to compete with the big names."

1. "Designing and evaluating VXI systems," Tektronix, February 1994.

2. VXIplug&play Systems Alliance VPP-4.1: VISA-1 specification, May 2, 1994.

3. VXIplug&play Systems Alliance VPP-1: Charter Document, July 15, 1994.