The U.S. Department of Defense’s Synthetic Instrument Working Group (SIWG) originally defined synthetic instruments (SIs) in 2004 as elemental hardware and software components with standardized interfaces and measurement software, which yield a smaller footprint and greater flexibility.1 Once the standard was defined, the group disbanded, and the remaining work moved to IEEE’s Automatic Test Markup Language (ATML) Group and the IVI Foundation Synthetic Instrument Groups.
The IVI class driver model fits inherently well with the SI hardware model of finer measurement granularity. An IVI class driver representing common functionality plus its extensions will cover a large amount of the SI hardware capability.
A test example calculating total harmonic distortion using an SI waveform generator, an SI up-converter, an SI down-converter, an SI digitizer with IVI drivers, and several SI software components illustrates the interactions between the hardware and software as well as how to set it up and get the desired results. From this, several rules of thumb help ensure good results.
A Test System With SIs and IVI Drivers
As we look closer at SIs and their respective IVI drivers, it will be important to understand how an entire test system works. There are many system models, but let’s assume a typical testsystem consists of three interdependent components: the hardware computer, the software, and the instrument or device, as shown in Figure 1.
Figure 1. IVI Drivers and SIs
Interfacing technologies exist between these hardware and software components to integrate them as a system. The purpose of this test system is to characterize, validate, and compare both parametric and functional capabilities of a UUT to a known standard.
When a UUT must last for 25 years, the test program sets (TPSs) written in software components need to evolve to match upgrades in the UUT. Often the test hardware or the software becomes obsolete and needs to be updated as well. Standardized interfaces between these components and the UUT can help manage change throughout the test system.
To use an IVI driver, you must write a program using a software programming language such as C#, C++, C, Visual Basic .NET, Visual Basic, MATLAB, LabVIEW, LabWindows/CVI, or VEE Pro to access various function calls of the instrument or device of interest. A test executive typically sequences this program and other similar programs as a TPS. Math algorithms also manipulate the data.
Normally, IVI drivers sit on top of another software I/O interface called Virtual Instrument Software Architecture (VISA). The two main versions of VISA are NI-VISA from National Instruments or Agilent’s VISA.
There are two IVI driver standards: IVI-C and IVI-COM. These replaced the previous VXI plug-and-play driver standards. In addition, there are programming language-specific drivers that enable an easy-to-use experience native to each respective language.
The LXI instrument protocol was invented in 2005, and the test and measurement-specific VXI-11 protocol over TCP/IP was developed in the early 1990s based on the Ethernet/LAN bus that has been around since 1969. Both the PXI backplane and LXI bus standards are used for the creation of SIs today.
Emerging Standards
Standard software I/O interfaces for SIs are just emerging. For example, the U.S Navy is taking the lead for DoD since it has a large quantity of test stations with the strictest requirements for space. Accordingly, the original goals for moving in the direction of SIs were to reduce the total cost of ownership, the time to develop and field new or upgraded automated test systems (ATS), and the overall footprint and provide greater flexibility through interoperable ATSs.
Now in 2008, these goals have further played out as both onshore and afloat CASS test stations using approximately 1,300 TPSs for automated avionics/electronics testing are approaching the end of their useful service life. In addition, a recent Request For Information by the Naval Air Systems Command describes the goals for replacing existing CASS test stations with a next-generation test station solution called electronic CASS or eCASS.2 These systems need to emulate existing functionality as well as take advantage of new capabilities, use standardized interfaces, and be flexible enough to resolve obsolescence issues that appear in the future.
The IEEE ATML Group incorporated the SIWG’s charter and research into the Instrument Description Standard P1671.2, which now is in the IEEE balloting process.3 This will be the standard for Exchanging Automatic Test Equipment and Test Information via XML. It is much broader than SIs and intended to provide one overall description language for all instruments, including VME, VXI, GPIB, LAN, LXI, PCI, cPCI, PXI, RS-232, and USB. This allows for interoperability and the exchange of ATML-defined components.
The IVI Foundation approved charters for two SI IVI driver working groups about a year ago. One group is developing the SI digitizer and SI waveform generator driver specification. The other group is addressing the SI up-converter and SI down-converter specification. Prototyping will be followed by an IVI Foundation review before the SI interfaces become official.
Types of SIs and Related IVI Drivers
Let’s walk through each SI instrument and the IVI driver that is likely to emerge to support it. Figure 2 shows that the SI digitizer converts analog data to digital data through sampling and can acquire time-varying voltage waveforms. Typical functionality includes setting the channel, the acquisition, and the triggering subsystems when configuring a waveform for acquisition, initiating the waveform acquisition, and returning a waveform.
Figure 2. Expanded System SIs Block Diagram With IVI Drivers
An IVI digitizer class driver for this SI component will cover common attributes of the typical digitizer as well as typical extended functionality found in digitizers that are more complex. High-speed data streaming capability that exceeds the I/O bus capability is an example of extended functionality that might be required. In this case, your program would implement the IVI digitizer extended class.
The SI down-converter translates a frequency or group of frequencies from a higher frequency, usually in the gigahertz range, to a lower or intermediate frequency (IF) where the signal may be more readily digitized and processed. It also provides amplitude control and band limiting.
Very high frequency signals currently can’t be handled by a 100-MHz digitizer and a 500-MHz waveform generator.4 As a result, IF bandwidths are needed for the converters. Today’s fastest converters are about 1 to 2 GS/s. At a sample rate of 2.5:1, they can handle a signal up to 800 MHz. Anything above this frequency will require this additional complexity.
Figure 2 shows that the SI up-converter translates a frequency or group of frequencies from a lower frequency, usually in the megahertz range, to a higher CW or modulated RF/microwave signal. This CW typically is up to 26.5 GHz for wireless networking, radar, and satellite links.
Often, the up-converter incorporates signal conditioning within its functionality. This core capability will be in the IVI SI up-converter driver with potential extensions for FM, AM, or pulse modulation as well as I and Q input and a reference frequency.
Waveform generation most likely includes inputs such as data, a reference frequency, and a synchronization signal. Outputs consist of the analog output, the reference frequency, and markers. Extensions probably will be functionality such as differential signals, waveform depth, specialty waveform creation, and advanced sequencing.
Different Technology Approaches to SIs
Remember that SIs are software and hardware components based on elemental measurements or finer granularity. In effect, it is breaking an integrated instrument box into its elemental measurement hardware and software components. For example, an integrated spectrum analyzer consists of an SI hardware down-converter, an SI hardware digitizer, and several SI software spectrum measurement and calibration components.
There are different technical approaches to delivering SIs. For instance, National Instruments uses virtual instrumentation technology to create SIs. NI defines virtual instrumentation as a software-defined system where software based on user requirements defines the functionality of generic measurement hardware.5 The company delivers on this combination by using PXI modules in combination with its LabVIEW graphical programming language. PXI adds mechanical specifications and integrated timing and synchronization to cPCI.
Agilent, on the other hand, uses LXI-compatible instruments for its SI offerings.6 LXI has three pieces: a standardized Ethernet interface for both peer-to-peer and master-slave operation, a triggering protocol that enables synchronization over the LAN, and a physically wired trigger system for tight synchronization.
LXI comes in three classes. Class A provides a standardized LAN interface, IEEE 1588 triggering, and a physically wired trigger bus (WTB)interface. Class A, though a superset of PXI’s overall functionality, has physical triggering like PXI, which yields submicrosecond I/O latency. Class B features the standardized LAN interface and the IEEE 1588 triggering protocol. Class C has only the standardized LAN interface.
THD Application Using IVI Drivers With SIs
Let’s illustrate the interaction between SIs and IVI drivers with a simple total harmonic distortion (THD) application using both IVI-COM and IVI-C drivers. We will use the interactive software platform called Virtual Rack (VR). This will eliminate using a programming language for hard-coding the instrument to the I/O interface and allow us to follow the application logic.
To simulate the UUT source, we will use a waveform file in combination with an SI waveform generator and an SI up-converter (Figure 3). Instead of a typical spectrum analyzer, we’ll use a combination of an SI down-converter and an SI digitizer and some software in C++ that represents our numeric algorithms normally in the firmware of the spectrum analyzer. The two C++ programs we need are a spectrum measurement program that converts data from time domain to frequency domain and the actual THD calculation.
Figure 3. THD Application Using SIs With Disaggregated Measurement Algorithms
For maximum interchangeability of drivers, use a computer with one of the following operating systems: Windows 2000 Service Pack 3, Windows XP, or Windows Vista. These operating systems are compatible with both types of IVI drivers and versions of VISA.
First, install NI-VISA or Agilent VISA. VISA is the input/output application-programming interface between your software and a specific backplane to an internal device or a specific bus to an external instrument. Install the VISA Shared Components prior to installing your IVI driver.
Install Agilent Connection Expert (ACE) or NI Measurement and Automation Explorer (MAX). These tools enable you to configure your I/O.
Install IVI Shared Components. These are common capabilities shared by IVI drivers and normally provided with any IVI drivers you download but also can be downloaded from the IVI Foundation’s website.
The development environment you choose, such Visual Studio, MATLAB, LabVIEW, or VEE Pro, may impact which IVI driver you install. This also could affect your version of VISA. VISA has a standard visa32.h header file for use in C and C++ as well a VISA32.bas header file for Visual Basic. Agilent and some other vendors offer a VISA32.cs for C# and a VISA32.vb for VB .NET.
Install an appropriate IVI-C or IVI-COM driver from the instrument vendor. Configure an IVI driver session in your chosen development environment. Hook up your equipment, then write, compile, and run your program. This also will include a test executive sequencing your test scripts.
Since we are using VR as an illustrative tool, we can configure interactions between hardware and software without hard-coding I/O to each instrument from the previous step. After expanding the appropriate folders, choose the key function nodes; for example, the waveform output and the channel 1 waveform data under the waveform generator configuration. By dragging and dropping the nodes into a source-and-sink dialog box, a data or logic interaction is set up for their methods and properties.
Figure 3 shows that six overall sets of interactions and configurations are required:
1. A software waveform file to hardware waveform generator.
2. A hardware waveform generator to hardware up-converter.
3. A hardware up-converter to hardware down-converter.
4. A hardware down-converter to hardware digitizer.
5. A hardware digitizer to software spectrum measurement.
6. A software spectrum measurement to software THD calculation.
Since many engineers use NI TestStand as their test executive, I configured the VR macro recorder to target its output to TestStand. As a result, VR turned every action and instrument configuration into a TestStand test step and saved my whole set of steps as a TestStand sequence. For example, when I clicked on the node to enable the output of channel 1 on the SI LXI waveform generator, the VR macro recorded it in terms TestStand understood: “Set Agilent N8241A, Channel1, Channel1OutputEnabled value to TRUE”.
Figure 4 shows this node highlighted in the IVI-C driver for the SI waveform generator along with a directory view of the four SIs in blue, the three software algorithms in green, and the computing in red. Agilent’s driver includes the base functionality, the extension capabilities, and the additional functionality of the proposed SI IVI waveform generator class driver.
Loading my square waveform and driving it through the waveform generator using its 1.25-GHz internal clock resulted in the signal coming out of the WG at 128 MHz. Choosing a square waveform makes the overall distortion obvious.
THD is a measurement of harmonic distortion caused by a signal passing through a nonlinear device, which adds content as harmonics of the original. It usually is expressed in percent as distortion factor or in decibels as distortion attenuation. Accordingly, THD is the ratio of sum of the powers of all harmonic frequencies above the fundamental frequency to the power of the fundamental or
Consequently, the 128-MHz signal has a 3rd harmonic at 384 MHz, a 5th at 640 MHz, and a 7th at 896 MHz. Therefore,
Sure enough, the output from the C++ THD calculation coming from the spectrum measurement reads 0.2297.
Rules of Thumb to Ensure Good Results
Many engineering decisions are required to get everything working right. Here are some observations that may help.
• Choose a software development environment that meets your long-term flexibility needs. Integration of the various SI hardware pieces and measurement science puts higher expectations on the software used. Use IVI drivers wherever possible to maximize the possibility of interchangeability. You want to be able to use the best tool for the job and integrate your pieces together.
• Engineering equivalence is very important if you are swapping hardware or software. For example, one instrument bases its measurement on an input of Start Frequency and an input of Stop Frequency while the next instrument is based on an input of Carrier Frequency and Frequency Span. This is a very simple calculation, but if your TPS is based on one or the other, a simple program needs to be added to ensure engineering equivalence.
• Pay attention to different data scaling. Some instruments auto-scale; others require setting the minimum and maximum. Each instrument has different ranges that need to be accounted for in your algorithms.
• Watch for different data types. A spectrum analyzer outputs a spectrum value, the translation from time domain to frequency domain being done in firmware. However, a down-converter may put out a time-based waveform and require a software spectrum waveform calculation separate from the SI down-converter.
• Make sure you understand your system I/O. The gain in flexibility now requires more attention to details. In my case, I had a group of instruments connected via LAN that IT would bounce off every 30 minutes for security reasons until I got my own instrument subnet.
• Pay attention to cabling and calibration between SI hardware. System calibration and inline corrections between SI hardware are especially tricky with RF signals. In gaining flexibility, fine-tuned signal paths within an integrated instrument now are, in some cases, broken.
With different lengths of cabling and quality of cabling, your results may vary. In my experiments, I borrowed a well-used cable that turned out to have an intermittent problem. In another case, moving my SI hardware boxes around in my test area caused a connection to loosen, changing my results.
Summary
SIs are reconfigurable elemental hardware and software components emphasizing separating individual components at a finer granularity of measurement science. They provide a smaller footprint and greater flexibility over time.
Standardization work by the IEEE ATML Group and the IVI Foundation Driver Groups will greatly enhance the interoperability of SI components. The IEEE ATML Group is defining an overall description language for all instruments, including SIs, which will facilitate exchange of ATML-prescribed hardware components. The IVI Foundation is developing new IVI classes for an SI down-converter, an SI up-converter, an SI digitizer, and an SI waveform generator that will greatly enhance interoperability.
SIs also enable the creation of a wide range of measurement analyses beyond a standard instrument. For instance, a down-converter plus a digitizer plus software can act as a spectrum analyzer, a network analyzer, and a peak power meter.
A good implementation of SI requires stable I/O interfaces such as IVI class drivers so older modules could be replaced with the latest technology and protect against obsolescence. IVI drivers are an excellent fit for SIs because the class driver can represent, one-for-one, a large percentage of the SI component’s capability.
With greater flexibility comes greater engineering responsibility to ensure all of the components of the test system are properly integrated. This will ensure accurate results, engineering equivalence of prior solutions, and adequacy for capabilities that were provided in the instrument. These needs will put more importance on integration and measurement science software, whether leveraged from instrument firmware or provided by software vendors or system integrators.
References
1. SIWG Meeting #2 Statements and Definitions, Dec. 11, 2004.
2. Solicitation Number: eCASS-RFI-B, Department of the U.S. Navy, May 15, 2008, www.FedBizOpps.gov
3. P1671.2/D9: IEEE Draft Trial-Use Standard for Automatic Test Markup Language (ATML) for Exchanging Automatic Test Equipment and Test Information via XML: Exchanging Instrument Descriptions, April 2008, http://ieeexplore.ieee.org/servlet/opac?punumber=4497172
4. Stratton, J., Can You Make One Size Fit All?, Agilent Technologies, ieeexplore.ieee.org/iel5/10700/33790/01609120.pdf?arnumber=1609120
5. Creating an SI With Virtual Instrumentation Technology, Sept. 6, 2006, http://zone.ni.com/devzone/cda/tut/p/id/3183
6. www.agilent.com/find/synthetic
About the Author
Hob Wubbena, a software product marketing manager in the Signal Networks Division at Agilent Technologies, has been with Agilent/Hewlett-Packard since 1983. Mr. Wubbena is published in more than 13 technical and business publications in the United States, Europe, and Asia and holds three patents relating to displaying instrumentation, system verification, and synchronous test. He received an M.B.A. from the University of Denver and a B.S. in engineering from the University of Wisconsin. Agilent Technologies, Signal Networks Division, Electronic Measurements Group, 900 S. Taft Ave., Loveland, CO 80537, 970-679-3363, e-mail: [email protected]
December 2008