FROM EDN EUROPE: Virtual instruments drive test standards

Walk into any test bay today, and there's a good chance you'll encounter racks of individual instruments, all communicating via GPIB (general-purpose interface-bus) ports under the control of a dedicated bus controller. Apart from improvements in instrument design, the situation hasn't changed much since the early 1980s. Back then, commodity microprocessors and I/O-controller chips fashioned the rack-and-stack approach to manufacturing test requirements, albeit at the cost of substantial space requirements. To reduce bulk in complex manufacturing or mobile test environments, such as avionics, variations include the instrument on a card, which uses a chassis to provide common power supplies and a communications backplane. Examples include the VXI bus (VMEbus for instrumentation), an instrumentation-specific adaptation of the VME (versa-module-Europa) industrial-computing platform that IEEE standard 1014-1987 describes. More recent examples include derivatives of the PC's own PCI bus, such as CompactPCI and PXI (PCI extensions for instrumentation).

Rack-and-stack installations remain popular where ultimate measurement accuracy is crucial and cost is a secondary consideration. For example, a VXIbus multimeter can manage about 6½ digits of dc voltage resolution. Instruments such as Agilent's model E1412A VXIbus multimeter resolve 100 nV on its 100-mV range, with a basic annual accuracy figure of 0.005%, or 50 ppm/year. In comparison, a premium reference multimeter, such as Fluke's 8½-digit model 8508A resolves 1 nV with a basic dc-voltage accuracy metric of better than ±3 ppm/year. It received Test & Measurement World's 2003 "Best in Test" award (www.tmworld.com). With these devices costing around $2279 and $12,495, respectively, performance differences aren't due solely to price. Rather, the controlled environment of bench instruments permits designers to optimise not just the measurement circuitry, but also associated systems, such as power supplies that maintain isolation between ac line and sensitive amplifiers. Similarly, shielding and screening issues are easier to resolve in a traditional instrument's format, and you needn't contend with the radiated and conducted emissions that can afflict bus-based devices.

A core of test-industry heavyweights comprising Agilent, National Instruments, Teradyne, Racal Instruments, and VXI Technology conceived and sponsored VXI—today's de-facto standard for both commercial and military ATE (automated-test-equipment) systems. Ratified as IEEE standard 1155-1992 and with some 80 vendors supplying system components, VXI also benefits from key extensions, such as VXIplug&play to ease configuration, and SCPI (standard commands for programmable instrumentation) to standardise the command set. The basic arrangement consists of a one- to 13-slot chassis that accommodates a controller card, as many as 12 master/slave cards, a passive backplane, and analogue- and digital-subsystem power supplies (Figure 1). The specification allows for four rack-unit card sizes ranging from the 3U×160-mm size A to the massive 9U×340-mm size D; the most popular sizes are B (6U×160 mm) and C (6U×340 mm). As a result, a VXIbus system shrinks rack-and-stack functions and—importantly, for complex ATE systems—provides the close coupling between instruments that enables accurate triggering and minimises latency. By contrast, a GPIB system's bus controller typically waits for a service request before responding to a new event, then either serially polls or parallel-polls the bus to find the service request's source. But VXI product lines may now be approaching maturity as users seek smaller, lower cost approaches. Significantly perhaps, former VXI champion Tektronix is discontinuing its line of general-purpose VXI instruments; it is, however, still offering its card frames and high-end digitiser cards.

Although the PC's influence is ubiquitous today, one reason for VXI's rapid acceptance lies with the contemporary PC's inability to accommodate complex plug-in cards. Back in the '80s, the limitations of the 8/16-bit ISA (industry-standard-architecture) bus and its 32-bit EISA extension, together with the few available motherboard card slots, restricted instrumentation use to applications such as simple ADC/DAC and general-purpose-I/O cards. But the advent of the Intel-developed PCI bus and cheap silicon soon stimulated new opportunities that now appear in several variations on the native PCI specification. Original features include plug-and-play installation and a 32-bit data-transfer burst rate as fast as 132 Mbytes/sec using a 33-MHz bus; currently, maximum data-transfer rates of 528 Mbytes/sec are possible using 64-bit transfers and a 66-MHz bus. Significantly, PCI's development and management lies within the hands of the developer community via PCI-SIG (PCI Special Interest Group). The group has a nine-year history and more than 900 member companies representing computer-hardware, software, instrumentation, and semiconductor manufacturers. Its role ensures forward compatibility between specification revisions and additions.

Stability enables key developments that include CompactPCI—which the telecommunications industry quickly adopted—and its PXI derivative, which adds VXIbus-style clocks, individual and global trigger lines, and local-bus signals to tailor the bus toward instrumentation applications. Just as the PICMG (PCI industrial computer manufacturers' group) administers the CompactPCI specification, the PXI Systems Alliance owns and maintains the PXI specification. The spec is now at Revision 2.1 and recently split between hardware and software requirements (Figure 2). Architecturally, PXI mirrors VXI's embedded-controller-card and common-backplane format. Alternatively, you can fit a host-to-slave link module in place of the controller card to form a link to a host PC using normal PCI-bridging technology. In this way, the PXI-card frame appears as a conventional set of PCI devices within the PC's operating system. This PC-hosting approach suits low-cost embedded-system development, as well as test-and-measurement applications in which PC-resident software furnishes control and analysis capabilities. Because PXI uses standard PC hardware and software, you can easily connect to networks as well as alternative system architectures, such as GPIB and VXI. Also useful, PXI devices are intended to interoperate with CompactPCI cards, so you can easily add, say, a CompactPCI Ethernet peripheral to a PXI chassis.

Mechanically, a PXI chassis is a ruggedised 3 or 6U Eurocard card frame with a maximum of 31 slots, one of which is the system slot that accommodates the controller card. Processor cards with mezzanine boards or bulky heat sinks may occupy more than one slot, in which case they should extend to the left of the system slot and present no additional connections to the backplane. This recommendation maximises the number of available peripheral slots, which conventionally occupy positions to the right of the system slot; if a star-trigger controller card is present, it sits next to the system slot in peripheral slot one. A 3U card measures 100×160 mm and carries two connectors: J1 for normal, 32-bit PCI operation and J2 to support 64-bit transfers and PXI-specific extensions. Each card's J1/J2 connectors mate with P1/P2 on the backplane. The connectors are 2-mm-pitch IEC-1076 types that include staged power and signal pins for hot-swap capabilities. Their multiple ground pins and controlled impedance permit one system and seven peripheral slots per 33-MHz bus segment—compared with just four peripheral slots in a PC—or four peripheral slots per 66-MHz PXI segment versus a PC's two. When you need more slots, PCI-bridge boards seamlessly connect segments across the backplane, with each board occupying one slot. Thus, a 33-MHz system with two segments can accommodate 13 peripheral slots. A 6U card extends height to 233 mm and includes the same connector complement but reserves additional space for J3, which may serve future specification extensions. You can stack two 3U cards in one 6U slot by adding P4/P5 connectors to the backplane and using a bridge to the P1/P2 rows.

Away from the PCI bus, PXI adds a 13-bit local bus that's daisy-chained between slots, such that the right-hand side of one module connects with the left-hand side of the next. This bus can carry digital or analogue signals as large as 42V to implement, for example, a peer-to-peer communications channel. To prevent incompatible modules from accessing inappropriate local-bus lines, PXI uses a software-based configuration that's more flexible than a hardware-keying scheme. If a star-trigger module is present, the left-hand side of its local bus carries 13 individual trigger lines out to downstream modules. Backplane traces from the star-trigger controller to each peripheral slot employ line-equalisation techniques to guarantee low skew between signals for precise synchronisation; less demanding applications can use the global 10-MHz system clock, the eight bused PXI trigger lines, or both. But to maintain timing performance, these bused trigger lines serve only their local segment. You can access modules in an adjacent segment using the remaining star-trigger lines to further extend critical timing signals. However, this approach is not recommended.

To simplify power-consumption calculations, the PXI specification demands that any chassis provide minimum levels of current for each of its four voltage rails. Both the 5 and 3.3V rails must each supply at least 6A for the system slot and 2A for each peripheral slot; the 12 and –12V rails must support 0.5 and 0.25A per slot, respectively. The chassis must provide forced-air cooling, and cards must route the cool-air stream from the bottom to the top of the enclosure. Both chassis and card vendors must supply wattage figures to ensure safe operation of any configuration. All cards must meet the IEC-61326-1:1998 standard for conducted and radiated emissions, and card vendors must document environmental test data for both operational and storage conditions. Each of these steps greatly simplifies systems integration by ensuring a common specification base that provides all the data you need.

Compared with software practices, hardware implementations have traditionally been easy to standardise. Originally conceived as the HPIB (Hewlett-Packard interface bus) and first adopted as IEEE 488-1975, the standard that's typically known as GPIB and revised in IEEE-488.1-1987 is easily the test industry's most successful instrumentation interface (Reference 1). Before the establishment of 488.1, you had to wrestle with an amalgam of RS-232-serial, Centronics-parallel, and complex-instrumentation interfaces, such as the CAMAC (computer-aided measurement- and-control) standard that's still popular in nuclear-physics labs. By sponsoring an open standard that defines the mechanical and electrical characteristics of the interface together with its basic communication protocols, Hewlett-Packard (now Agilent) made it possible to connect as many as 15 instruments on one bus segment without worrying about hardware compatibility. And 488.1 development continues; the IEEE standards board approved the P488.1 high-speed project as recently as June 2003.

Of course, as hardware becomes increasingly modular and easier to configure, the focus inevitably moves toward software-compatibility issues. In its first real move toward software harmony, the test industry conceived and rapidly adopted the IEEE-488.2 Standard Codes and Formats extensions to the original data-transfer specification (Reference 2). The extensions define a hierarchical structure for event messaging, together with command syntax and a number of common commands. Such commands include mandatory housekeeping instructions, such "*STB?" which reads an instrument's 488.1-defined status byte. A number of optional commands handle common functions; for example, "*TRG" triggers a reading in a compatible instrument. Amazingly, perhaps, 488.2 also introduces a proper command syntax for program messages. A simple program message comprises one syntactic element and an ASCII new-line terminator; more complex messages can comprise multiple program-message units that semicolon separators divide.

The philosophy behind 488.2 describes a message-based rather than register-based model of instrument behaviour that uses an instrument's 488.1-defined status byte at the apex of a hierarchical message-exchange structure (Figure 3). In 488.2, bits four, five, and six of the status-byte register summarise the standard-defined event structure; below this level, the standard-defined event-status register reports important events, such as power-up and various error conditions. Decisively, the 488.2 protocols guarantee that the instrument executes commands in the order that it receives them. So, if you send, say, "*TRG; RDG?" you can expect to read the result of this latest trigger command. This observation seems stunningly self-evident—until you discover that first-generation GPIB instruments rarely behave consistently or predictably with respect to timing issues and thus present test programmers with difficult or even impossible-to-meet challenges. As a result, 488.2 aims to ensure that instruments are forgiving while receiving messages but precise in transmission.

The success of 488.2 drives complementary developments that include VISA (Virtual Instrument Software Architecture)—a core component of the VXIplug&play environment—with SCPI for universal use. Although 488.2 defines how to send and receive data and includes some common commands, manufacturers are otherwise free to implement any device-specific commands they require and to decide their effects. As a result, similar instruments are likely to employ different command sets. SCPI, the first concrete achievement toward truly interchangeable instruments, goes beyond 488.2 to consistently define a range of functions, commands, and responses. It also offers a syntax that permits functionally equivalent instruments to employ identical control software. This common programming environment makes it easy to learn and maintain systems, in turn promoting software quality and lowering cost.

The SCPI Consortium, which originally comprised nine founder-member companies, now includes cosponsors Agilent and AIGER (American Industry/Government Emission Research), together with AVL North America, Keithley, Horiba, National Instruments, Pierburg, Rohde and Schwarz, and PX Instrument Technology. Test-industry consolidation apart, today's group regularly updates the specification to continue its evolution. The current revision is SCPI-1999, but additions that tackle commands for emissions-sampling systems are effectively a year-2000 update. Although SCPI requires instruments to meet 488.2 specifications, you can send SCPI's ASCII strings over any interface, including Ethernet, GPIB, RS-232, and VXI. You can also embody SCPI commands within popular test-programming environments, such as Agilent's VEE, Microsoft's Visual Basic and Visual C++, and National Instruments' LabView and LabWindowsCVI. As such, SCPI is as close to platform-independent as the test industry currently allows. And, unlike the IEEE—which charges for both downloads and printed specifications—you can freely download SCPI's specifications from the consortium's Web site.

Today, the test industry's desire for interchangeable virtual instruments continues to shape software-development practices. The IVI (interchangeable-virtual-instrument) Foundation is the industry's latest initiative to ensure interoperability between instruments. Incorporated in 2001, its sponsors include Agilent, Keithley, Lucent Technologies, National Instruments, Rohde and Schwarz, and Tektronix—together with an array of high-profile ATE and aerospace members that range from Advantest to Teradyne. One reason the member list comprises so many key players from the military and aerospace industry is the high cost of maintaining COTS (commercial-off-the-shelf) test equipment. As a result, a prime IVI Foundation goal is to preserve future hardware and software compatibility by defining common programming interfaces for a variety of instruments. But rather than simply harmonising variations on test-programming practices, the foundation's approach transcends previous initiatives by defining an instrument-driver architecture together with its application-programming interfaces (see sidebar "Abstraction eases hardware compatibility").

Also, don't forget the contributions that programming environments make to ease system-software development and maintenance. Deeply unfashionable elsewhere, Microsoft's VB (Visual Basic) is a core component of countless test applications and enjoys extensive driver support from instrument vendors. First used for Windows 3 in the mid-1980s, VB has seen six major revisions that culminate in today's .NET edition. However, many programmers feel that .NET's wholesale style and content change is premature and currently unfit for "real work." These same misgivings apply to the vendor's equivalent C-programming environment. Thus, you can expect to see versions up to and including VB6 controlling test bays for the foreseeable future. But if you want a copy of VB6, you'll need to search surplus and second-user sources, such as eBay (www.ebay.com). If you choose this route and want to use the software in a commercial application, make sure you receive a new and unregistered license.

Contemporary rapid-application-development environments that target test applications include Agilent's VEE Pro and packages from the National Instruments family, such as the ubiquitous LabView. Each of these products employs graphical-programming techniques that rely on icons and drag-and-drop functions to replace traditional line-by-line coding. Currently at Version 6.2, with Version 7 scheduled for release this year, Windows-compatible VEE has prices that start at around $1395. The product now includes embedded Matlab Script and the companion signal-processing toolbox, both from The Mathworks. LabView's latest development is Version 7 Express, which the company now ships with approximately 40 virtual instruments that you can augment using built-in templates. You can also add various modules to the core product as needs dictate, including a $1995 FPGA module that complements the vendor's reconfigurable PXI card. This facility allows you to graphically configure hardware for real-time use, such as a controller and sequencer for PXI's dedicated trigger lines. LabView 7 Express starts at $995 and is available now. Full versions that include data-acquisition card, GPIB, RS-232, VISA, and VXI instrument-driver libraries are available for Windows, Linux, MacOS, and Solaris hosts.

You can reach Contributing Editor David Marsh at forncett@btinternet.com.