The Automated Test Blog

I’d like to clarify the difference between these two terms as I have found that there is very often confusion between them. The distinction is entirely in the software model and the programmability of software-based analysis by the instrument user. A Virtual Instrument’s primary programming model is to present raw data to the user for customized measurements. A Traditional Instrument’s primary programming model is to present vendor-defined measurements to the user.

What about Standalone Instruments versus Modular Instruments? This is a question of form-factor, not software, and is therefore entirely orthogonal to whether the instrument is virtual or traditional. A standalone instrument can indeed be used as a virtual instrument. An example is a standalone oscilloscope that is automated to create custom measurements in software. Similarly, it is possible for a modular instrument to present only a traditional use model to the user; VXI instruments, for example, were most often vendor-defined instrument repackaged in a modular form factor.

While the definition of virtual instruments and modular instruments is orthogonal, it is true that many modular instrument standards lend themselves to building virtual instrumentation systems. In order to effectively perform user-defined analysis on a signal, the user must have access to the raw data from the instrument’s acquisition. For high-speed measurements, this requires transferring many megabytes of data from the instrument to a processor to be analyzed in software. High-speed interface buses such as PCI Express, which can transfer data at up to 4 Gigabytes/s, are well-suited to this application. Instrumentation standards such as PXI combine high-speed buses and upgradeable PC-based processors, making it an ideal platform for virtual instrumentation systems.

I just saw another example of what we call a VBA, a “van-based acquisition”. It turns out that in RF applications, virtual instrumentation is particularly common when customers need portability and real-time data streaming. There aren’t a lot of commercial products to solve this application, but a PXI-based system can handle most of these requirements at a very low cost. Here is the latest example I just received of a VBA:

“The customer was looking for a completely mobile RF spectral monitoring application. They want to have a DC-based system mounted in their vehicles and they want to drive through areas and monitor a band of secure radio channels and signal strengths for those channels. The main requirements of the system are portability, quick spectral acquisition and storage (stream-to-disk) and time/location stamping for each spectral sweep.

This is a unique application that requires a small form-factor, stream-to-disk capabilities and GPS stamping. It can solved today with commercial off the shelf PXI products”

Other PXI-based VBAs are deployed in military applications (either looking for “signals of interest” or jamming them), ground-based transceiver testers, commercial spectral monitoring systems, and cell-phone coverage mapping applications.

I’ve recently been using the term Instrumentation 2.0 to refer to the changes happening in the architecture and use of test instrumentation. Rick Nelson, Editor of Test and Measurement World, wrote about this trend in his recent editorial and blog, I’d like to clarify what this concept means in terms of architecture and usage, for the two are related, but can be independent.

The internal architecture of test instruments is changing. Rapidly improving capability of PC processors, bus technology, and FPGAs have changed the architecture of both standalone instruments as well as modular devices such as PXI. Standalone oscilloscopes, for example, used to use proprietary technology from the front-end conditioning, through digitization, memory, storage, and display. Instrumentation companies were once the pioneers of early display technology, like the DVBST CRT in the Tektronix 4014. Signal processing on these devices has often been done using custom Digital Signal Processors, or DSPs. The investment in commercial PC and consumer electronics technology has created a compelling alternative to these proprietary architectures, however. Increasingly, standalone instruments use commercial operating systems, displays, memory, and storage. Indeed, most high-performance modern instruments contain a standard PC motherboard, transfer data over a commercial bus such as PCI, and run the Windows operating system. Increasingly, I believe the digitization and signal processing capability inside standalone instruments will also migrate to commercial technologies. Commercial A/Ds, driven by applications such as direct conversion for cellular base stations, are now available up to several GS/s. And studies have show that for many applications general-purpose processors and FPGAs can outperform dedicated DSPs. Modern instruments, will, in fact, start to look a lot more like a PC, at least architecturally speaking. A typical standalone instrument will have a acquisition block connected over a commercial high speed bus, such as PCI Express, to a general purpose processor. This processor will both run Windows and drive the display, as well as perform the signal processing necessary for real time measurements. In the highest performance instruments, FPGAs will be used to augment the analysis capability of the processor.

The change is architecture, combined with evolving needs of design and test engineers, has led to a change in usage. Increasingly, users require flexibility in their measurement systems and desire the ability to define capability specific to their application. This trend towards ever increasing customization and the ability through technology to capture this demand, is well articulated by Chris Anderson in his blog and book, both titled The Long Tail. He focuses on the trend in media markets such as music and film, but examples of long tail demand abound in test and measurement as well. Wireless technologies, for example, continue to evolve at a fast pace, and devices often include more than one wireless link. The model of a “one-box” tester specific to a single wireless protocol, therefore, has become a dinosaur. Users need a common platform where they can deploy measurements for new standards as they are deployed, without replacing their hardware. The relationship between these two trends is that the ability of users to define their own measurement capability is enabled by the architectural changes noted above. Instruments built on a PC architecture that use commercial technolgy components can enable users to write their own algorithms in software for processing the acquired data. Even better if they can switch out the acquisition front-end when the requirements necessitate it.

Of course, modular, or PC-based, instrumentation has been at the forefront of this trend. By their nature, these devices build on PC busses and processors and separate the acquisition from the measurement analysis. And the rapid evolution of converters, buses, and PC processors, has increased the capability of this approach over recent years, so that in many cases it is equal to or greater than the alternative standalone instrument. Software tools such as LabVIEW have been used for many years to create customized analysis for measurement applications. Newer developments, such as LabVIEW FPGA actually target LabVIEW programs to FPGA components in a test system to create very powerful embedded processing that is still defined by the user to their needs.