Overview
Welcome to the Designing Next Generation Test Systems Developers Guide. This guide is collection of white papers designed to help you develop test systems that lower your cost, increase your test throughput, and can scale with future requirements. This white paper describes the how to integrating your multivendor, multiplatform test equipment into a hybrid system. To download the complete developers guide (120 pages), visit ni.com/automatedtest.
Table of Contents
The Challenge for Test Systems Developers
In recent years, a number of test and measurement platforms and communication buses have emerged as options in test equipment. This proliferation of instrumentation options offers both an opportunity and a challenge to system developers. Engineers now have more flexibility in customizing a system with a wide selection of test equipment, but they face the challenge of integrating instruments built upon distinct platforms into a single system. You have the choice of modular and stand-alone hardware as well as a variety of communication buses, including USB, Ethernet/LAN, and PCI Express. You also face the choice between the software flexibility provided by virtual instruments - where the user defines the instrument&'s functionality - and the fixed functionality provided by vendor-defined instruments. Because budget and time constraints often require developers to reuse some test equipment and because mid-life upgrades and system repairs may require integration of new test equipment, most systems will contain a mix of several of these bus and platform technologies.
This paper discusses how to integrate multivendor, multiplatform test equipment into a single hybrid system, which both protects your existing investment through reuse of existing hardware and software and simplifies the task of upgrading and maintaining the system.
What Is a Hybrid System?
Hybrid systems combine test and measurement components from modular instrumentation platforms such as PXI and VXI and stand-alone instruments that connect externally across GPIB, USB, and Ethernet/LAN. The hybrid system diagram of Figure 1 gives one example of a hybrid topology, but any number of combinations is possible. In the diagram, the nerve center of the system is a PC - either a standard PC or an embedded PXI controller. The instruments themselves include PXI and PCI plug-in devices as well as traditional instruments connecting to the PC over GPIB, USB and Ethernet/LAN/LXI.

[+] Enlarge Image
Figure 1. One Possible Hybrid System Topology
The key to creating and maintaining a hybrid system is implementing a system architecture that transparently accommodates multiple bus technologies and uses an open, multivendor hardware platform to achieve I/O connectivity. With the proper computer platform and driver, application, and test system management software, you can combine the strengths of many types of instruments, including legacy equipment and specialized devices. It is important to fully recognize that no single platform or bus technology meets all needs, though each has unique strengths. For instance, GPIB has the largest installed base of compatible instruments, and is therefore useful for equipment reuse and specialized equipment. PCI and PCI Express offer the best bandwidth and latency performance, critical in applications where large amounts of data are being generated or acquired. PXI and PXI Express offer the same bandwidth and latency specifications as PCI and PCI Express but add the industry's best timing, triggering, and synchronization capabilities. The greatest strength of USB lies in its autodetecting plug-and-play connectivity. And Ethernet/LAN is often the best choice for distributed or remote systems; the LXI specification adds the ability to synchronize Ethernet/LAN instruments.
In a hybrid system, it is the PC and software that pull together the various instrumentation hardware pieces into a single system. The next section outlines in detail how with a properly planned system architecture, you can simplify your hardware integration challenge by:
- Incorporating existing/legacy test routines into the new system with minimal rework
- Introducing future test routines into the system without a complete system redesign
- Simplifying replacement of individual instruments and I/O devices.
Making the Right Software Decisions
Making the Right Software Decisions
Modular hardware and software is the best way to integrate your multivendor, multiplatform test equipment into a single hybrid system. Though some vendors may offer vertical software solutions for specific instruments, the most useful system architecture is one that breaks up the hardware and software functions into interchangeable modular layers so that your system is neither tied to a particular piece of hardware or to a particular vendor. Figure 2 shows a test system architecture. This approach provides the best code reuse, modularity, and longevity. The remainder of this section will discuss each layer in turn.
At the lowest level is the device I/O layer. This is the hardware layer which contains the individual instruments, signal conditioning, and fixturing. Hardware may be stand-alone or modular. The instruments may rely on software-defined functionality, such as with virtual/synthetic instruments, or they may be of a vendor-defined fixed functionality. They may communicate on various instrumentation buses including PCI, PCI Express, GPIB, Ethernet/LAN/LXI, and USB.
The computing layer includes the computer used to control modular instrumentation and connect to stand-alone buses. This is the core or nerve center of the hybrid system. It may be a rugged embedded controller in the case of PXI or VXI. It may be a server or industrial PC. Or it may simply be a laptop or desktop PC. The choice is dependent on the application needs. In the case of PCs and PXI systems, the computing layer components run standard OSs, such as Windows and Linux®, and share the same standard PC backplane technologies, so they are easily interchangeable.
A very important but somewhat invisible part of the test software architecture required to accommodate multiple platforms in hybrid systems is the measurement and control services Layer. This layer serves to provide configuration support and hardware abstraction. It contains the instrument drivers that bridge the hardware to the software. A few examples include Virtual Instrument Software Architecture (VISA), IVI, and Measurement & Automation Explorer (MAX). VISA is a vendor-neutral software standard for configuring, programming, and troubleshooting instrumentation systems comprising GPIB, VXI, serial (RS232/485), Ethernet, USB and/or IEEE 1394 interfaces. It is a useful tool since the API for programming VISA functions is similar for a variety of communication interfaces. Interchangeable virtual instruments (IVI) is a standard for instrument drivers, useful for instrument replacement because with it you can interchange instruments in a system with minimal test software modification, for specified classes of instruments such as oscilloscopes and switches. An application that uses IVI can substitute one instrument for another of the same IVI class, regardless of manufacturer or bus connection. MAX is an NI utility that simplifies configuring your various test hardware and software from one integrated interface. It also provides a means of importing and exporting channel lists and configurations. The right measurement and control services software can simplify the replacement of individual instruments and I/O devices in a hybrid system, because you can use it to make your test code hardware-independent.
The application layer is composed of the individual test programs like a DC voltage measurement or a frequency power spectrum. Though applications can be written in just about any software language, there are several programming environments that include special tools for interfacing to test and measurement equipment, such as National Instruments LabVIEW and LabWindows/CVI (an ANSI C environment). These environments are ideal for open connectivity, with built-in functions in VISA, IVI, Ethernet/LAN/LXI, and USB communication. They also have a suite of analysis and data visualization tools. You can incorporate existing/legacy test routines into the new system by calling the existing code from your new application.
At the highest level, the system management layer provides a framework to sequence the test routines as well as log data, generate reports, and manage user privileges. NI TestStand is the industry de facto standard for this kind of system management software. Regardless of whether individual tests are coded in LabVIEW, LabWindows/CVI, Visual Basic, C, C++, or a .NET programming language, NI TestStand can help to quickly build test sequences and then manage the test execution, including resource scheduling and reporting. By organizing individual test routines through a full-featured test management environment such as NI TestStand, you can introduce future test routines into the system without a complete system redesign.
The layered test system architecture outlined above provides useful way to think about the hardware and software architecture of a hybrid test and measurement system. It is important to remember that without a flexible, modular software model, many of the potential gains of a hybrid system cannot be realized. The final section builds upon the test system architecture concept and offers a few additional implementation tips for designing a hybrid system.
Designing Your System
When designing any test and measurement system, the measurement needs of the specific unit or process under test determine the required functionality of the test equipment. Once these needs are assessed, the developer can begin to select equipment. In a hybrid system, it is common to reuse any appropriate equipment already available, and then add instruments that fill the remaining gaps. Some instruments may be highly specialized and offered only by a particular vendor; but most instruments, such as switches, DMMs, function generators, and digitizers/scopes, are available in a variety of forms (stand-alone and modular) and from a variety of vendors. Choose the instrument that makes sense for you, keeping in mind future needs for extensibility, interchangeability, and upgrade.
Even a single instrument may have multiple connectivity options. Several vendors offer boxed instruments that may include two or more of USB, GPIB, Serial, and LAN/Ethernet connections. When choosing the instrument and interface, prepare not only to meet the basic measurement requirements of the unit under test, but also to have the ability to adapt to growing system measurement needs. This means going beyond features such as resolution, frequency, sampling rate, and channel count, and looking for complete measurement functionality. With virtual instrumentation, you can create a user-defined system that can easily adjust to changing measurement needs without having to replace hardware.
It is also important to think about timing and synchronization requirements. The computing center may need to coordinate tasks between instruments, or instruments may need to communicate directly with each other in a way that requires hardware synchronization. Examples of common timing and synchronization tasks include handshaking between a DMM and switch, phase-lock-looping a waveform generator with a digitizer, or synchronizing an RF downconverter with an IF digitizer. One advantage of choosing the PXI platform as the core of a hybrid system is the integrated timing and triggering capabilities that PXI offers. Unlike stand-alone instruments, the moment you plug in PXI modular instruments to the PXI chassis, all timing and triggering lines are instantly connected and ready for use, including access to a highly stable 10 or 100 MHz system clock, and trigger lines offering nanosecond skew. Plus, PXI systems offer advanced options like IRIG A, IRIG B, and GPS. Largely for these benefits, users choose PXI modular instruments for parts of the hybrid system that require the tightest synchronization and connect to stand-alone instruments as peripherals for specialized needs or equipment reuse.
After choosing the instruments, buses, and hardware platforms, the task remains to create the application software. Because test software development usually costs more (because of developer time) than the system hardware, the right software pieces are critical for staying on time and on budget. To save time and money now and in the future, develop the test system software using layered test system architecture. Keep the driver, application, and test management layers fully separated. Also spend a little effort to select the appropriate drivers, for instance, choosing between IVI for maximum reuse and portability, plug-and-play drivers for a compromise between portability and low-level control, and direct I/O. Direct I/O offers the lowest-level control, but at the cost of intensive programming and no interchangeability.
Conclusion: Building Hybrid Systems
With hybrid instrumentation systems, developers can integrate flexible modular instrumentation platforms with cabled stand-alone instruments to construct a system that takes advantage of the best features of both approaches. The key to successfully integrating PXI and VXI modular instruments with traditional instruments cabled across GPIB, USB, or LAN/Ethernet is the layered test system architecture that abstracts away instrument and vendor-specific concerns.
Relevant NI Products and Whitepapers
National Instruments, a leader in automated test, is committed to providing the hardware and software products engineers need to create these next generation test systems.
Software:
- NI TestStand Test Management Framework
- LabVIEW Graphical Programming Environment
- Signal Express Interactive Measurement Software
- Modular Instruments (Oscilloscopes, Multimeters, RF, Switching, and more)
- Multi-function Data Acquisition
- PXI System Components (Chassis and Controllers)
- Instrument Control (GPIB, USB, and LAN)
White Papers:
NI offers a Designing Next Generation Test Systems Developers Guide. This guide is collection of whitepapers designed to help you develop test systems that lower your cost, increase your test throughput, and can scale with future requirements. To download the complete developers guide (120 pages) , visit ni.com/automatedtest.
Reader Comments | Submit a comment »
Legal
This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).

