The evolution of instrumentation interfaces has landed squarely on Ethernet, an open standard that leverages the most prolific communications infrastructure in history. Simplified, inexpensive out-of-the-box connectivity and high-speed data transfers excite many potential users, but Ethernet implementations will likely involve a learning-curve hurdle for those unfamiliar with network terminology and infrastructure.

Today many consumers purchase a PC, call their local cable or telephone company for high-speed Internet installation, and magically they are surfing the World Wide Web with minimal effort and limited personal interaction. However, this scenario is not a typical occurrence for test and data acquisition (DAQ) engineers. Configuring instrumentation interfaces, setting addresses, defining subnets with multiple network interface cards (NICs), and selecting hubs and switches are more likely to become commonplace.

To begin, let' s review some background on network communications, the standard on which it is based, how individual devices are identified, and other configuration essentials.

Network communications are based on a well-defined standard established by the International Organization for Standardization (ISO), a standard that is commonly referred to as the Open Systems Interconnect (OSI) model. Think of any network, not just Ethernet, as a stack with each layer building on the one below it (Table 1).

Table 1. The OSI Networking Model

Ethernet is one of the most common selections for the network' s physical layer and clearly the choice for the computer industry. This layer specifically identifies how nodes on the network communicate with one another at the lowest level.

The physical layer specifies the wiring, voltages, and other characteristics required to allow computers to send messages to one another. In the ISO OSI model, Ethernet actually fulfills the functionality of two layers: Layer 1 and Layer 2. Other physical layers that many engineers are familiar with include token ring, asynchronous transfer mode (ATM), and controller area network (CAN).

TCP/IP
The transmission control protocol/Internet protocol (TCP/IP) is a set of communications protocols defined for the Advanced Research Projects Agency Network (ARPANET), the first operational packet-switching network. Today, these protocols form the basis of all Internet communications.

Within the OSI model, IP is found in the Layer 3, which addresses how messages are transferred from machine to machine on a network. The most familiar protocols are user datagram protocol (UDP) and TCP. They specify how hosts are addressed, how messages find their way between hosts, and how the general formats for messages are determined.

TCP and UDP are collectively known as Layer 4 and primarily concerned with transporting data. UDP is a connectionless protocol for sending messages, and messages sent over UDP are sometimes referred to as datagrams.

UDP has the advantage of a low message overhead, but it is not as reliable as TCP. UDP is primarily used for sending temporary data that causes no errors if some or all of the data sent is lost, such as streaming audio.

There are instances, however, where UDP is useful for a test engineer. LXI instrumentation, for example, uses UDP transmissions for broadcasting messages when performing device discovery. UDP also can be advantageous in situations where a limited number of nodes are on the network, minimizing the possibility of packet collisions and lost data.

TCP, in contrast, is connection-oriented, setting up a persistent connection between two hosts; this approach is well proven and quite reliable. Reliable in this case means that an application that sends a message via TCP will know if that message is received at the other end. TCP uses a number of techniques to guarantee delivery such as:
• Requiring messages to be acknowledged.
• Automatic retransmission of missed messages.
• Timeouts to detect missed messages and unavailable hosts.

With all of these features, it should not be surprising that TCP has a larger message overhead than UDP, but this is the price we pay for dependable message transmission.

Addressing: MAC and IP
Every Ethernet device in the world has a unique hardware address known as a media access control (MAC) address. Each is 6 bytes long, and the addresses typically are written in hexadecimal format, such as 0007E97CA6A0.

Manufacturers of Ethernet-based instrumentation as well as other products such as NICs and switches must purchase a range of MAC addresses from the IEEE. Then, the manufacturer assigns an individual address to every Ethernet product. Using this approach ensures that there is a unique identifier for every device.

Each MAC address then is mapped to an instrument-specific TCP/IP address that consists of 4 bytes, often shown in dotted-decimal notation such as 10.1.2.9. A collection of services and special computers perform a function called domain name service (DNS), which allows for mapping of mnemonic names and domains to Internet addresses. A separate but related protocol, address resolution protocol (ARP), helps to map IP addresses to MAC addresses on a LAN.

To extend the range of Internet addresses, a new scheme called IPv6 is being deployed. It fixes a number of problems in IPv4, such as the limited number of available addresses. It also improves IPv4 in areas such as routing and network autoconfiguration. However, the existing implementation, IPv4, will be supported for at least the next 20 years.

LXI-based instruments follow this same scheme and require a valid TCP/IP address for proper communications. All devices have a default factory power-on state that includes a TCP/IP address, which typically is derived from the hardware MAC address. Once the instrument is initialized, the user can access the mandatory web browser, enter the default TCP/IP address, and make any changes to this field that might be required. There are a number of ways to configure the address.

Ports
TCP/IP defines a range of ports for communications. Ports create multiple communications points to a single node and keep the conversations separate. They are numbered from 0 to 65,534, with the first 1,024 ports typically called the reserved range.

The reserved ports are used for running well-known services so that other hosts can easily connect to them. For instance, web servers using the HTTP protocol typically run on Port 80.

When a browser such as Microsoft' s Internet Explorer attempts to connect to a web server, it opens a connection to Port 80 on the designated host. Similarly, SMTP, the protocol used to transmit e-mail on the Internet, uses Port 25. Both ends of a TCP/IP connection require a port. The client side of a connection, such as a browser, typically is assigned a temporary number and is in the higher range of port numbers ( >1,024).

In Figure 1, two copies of Internet Explorer are running on Ports 2004 and 2008 and connected to the same web server (Port 80).

Figure 1. Examples of the Usage of Ports

Sockets
The most common method to send and receive messages using UDP and TCP is with a software object known as a socket. A socket creates a virtual end-to-end network connection between the applications running on the two machines involved. Each end of the connection is identified by the node' s address and the port number it is using. A connection is fully specified by four elements: client address, client port number, server address, and server port number.

Sockets greatly simplify network-programming tasks. Once a socket connection is opened, the application effectively treats it like a software FIFO. The application uses a simple write function call to send data to the selected target and a simple read function call to retrieve data from the target. Then the operating system handles all details of how the data is communicated to the other side, such as routing, underlying physical connection, and retransmission.

Additionally, socket interfaces are fairly consistent and standardized between operating systems. Windows has a slightly different API than most UNIX-like systems but is similar enough to avoid significant porting issues. Sockets can be seen as the Layer 5 of the ISO OSI model.

When using the IVI instrument driver, which is required by the LXI specification, the user must identify the instrument' s IP address. The driver is tasked with creating the required sockets and identifying which ports to use for communications.

LAN Configuration
All networked devices, whether instrumentation or computers, must obtain a valid IP address before they can communicate with other devices. There are a number of choices available to acquire an IP address, and all LXI-compliant devices must support the three most common approaches: manual, auto-IP, and dynamic host configuration protocol (DHCP). Most PC users are familiar with these alternatives from the standard network setup screens.

Manual
Manual configuration involves entering the address within a selected range provided by your organization or your choice when dealing with smaller private networks. There are two additional fields that must be entered for manual configuration: the subnet mask and default gateway. The subnet mask determines which subnet, or logical division of a network, the computer is part of. The default gateway identifies the router used by the local computer to gain access to another network.

Auto-IP
Auto-IP configuration is an easy way to obtain an IP address from a DHCP server or from a reserved set of addresses in the absence of the server. The typical range for these addresses is 269.254.0.0 to 269.254.255.255.

An example might involve an LXI instrument connected directly to a host computer with both set to Auto-IP. On power-up, both devices automatically select an IP address such as 169.254.1.10 (LXI device) and 169.254.1.15 (host). The host computer now can use this address in a browser address field to access the device.

DHCP
DHCP involves the host computer accessing a server that contains a list of available addresses. It simplifies network administration because the server automatically assigns addresses from an allotment of available values and eliminates the possibility of duplicate address assignment. The DHCP designates IP addresses, subnet masks, and a default gateway.

Upon power-up, the local computer sends a query to the DHCP server, which then responds with the assigned network parameters. The IP address and other parameters typically are assigned for some finite period of time as determined by the DHCP server; this period is commonly referred to as a lease.

Crossover Cables
Moving from software configuration aspects to hardware, a commonly mentioned concern involves determining when a crossover cable is needed. This is most prevalent when connecting an instrument directly to a computer, and it is similar to connecting two computers directly together.

Crossover cables typically are needed when directly connecting two Ethernet devices without the use of a hub, switch, or router. This is necessary because devices such as routers and switches have their Ethernet plugs reversed to allow connection to these devices without a special cable.

The LXI specification recommends that instrumentation incorporate the Auto-MDIX protocol that allows two Ethernet devices to negotiate their use of the Ethernet transmit and receive pairs, eliminating the need for crossover cables. The specification further requires that any device that does not implement Auto-MDIX must clearly label this exception.

Hubs and Switches
Most test systems are far more expansive than just a connection between one instrument and a PC. When connecting multiple instruments, you must consider some additional aspects, especially when implementing IEEE 1588, a scheme that allows triggering among instruments using Ethernet signals. LXI Class B instruments include IEEE 1588 capability.

An Ethernet hub connects multiple Ethernet devices together as a networked system. These hubs are unsophisticated and increasingly being replaced by network switches.

The hub is a shared-medium device, so any packet that enters the hub, on any port, is broadcast to all other ports. This type of device results in packet collisions on the network affecting overall performance. Additionally, the host computer is responsible for error detection and packet retransmission when an error occurs.

Ethernet switches are similar to hubs except they resolve the performance issues associated with hubs, specifically when more than a few nodes are connected. Switches transmit a received packet only through the port where the device is located, eliminating packet collisions and improving overall system performance.

Switches have become the popular choice primarily due to competitive pricing and improved performance. However, engineers implementing LXI Class B instrumentation must be aware of certain limitations.

The level of synchronization achievable from an IEEE 1588 implementation depends to a large degree on the latency contribution from the network infrastructure. Small configurations composed of only a few devices can use a hub with a fair degree of success because of the broadcast nature of the device.

General-purpose switches are better suited to larger configurations, but they can introduce significant jitter when individual messages are buffered. This issue becomes more of a concern as network traffic increases.

As a result, connecting multiple devices requires a network switch that implements a boundary clock component. The boundary clock effectively allows the synchronization of multiple IEEE 1588 devices without the associated latency fluctuations that are seen in general-purpose switches. The boundary clock acts like any other IEEE 1588 device, permitting all devices to synchronize as if they were connected point to point.

Dedicated Test LANs
Dedicated networks are inexpensive to install and provide the necessary isolation between corporate-wide network traffic and the test system. These characteristics make this approach the logical choice for networked functional test and DAQ installations. This network also can be easily interfaced to the rest of the corporation or the World Wide Web with little effort.

The low cost and ease of use of today' s switches, routers, and hubs simplify the task of establishing a dedicated network specifically for test purposes (Figure 2). Standard Category 5 (CAT-5) cable is easy to route throughout test bays, inexpensive to use, and available from many commercial sources. Standard RJ-45 connectors also are used, and cable lengths are easy to modify and customize.

Figure 2. A Dedicated Test Network

Isolated instrumentation networks also eliminate many of the logistical issues that can arise when trying to conform to corporate networking and security requirements. Security concerns also can be addressed by prohibiting physical access to outside network connections. One simple and inexpensive way to achieve this is through the use of dedicated NICs.

Conclusion
Adopting any new standard requires some level of change and an associated learning curve, but LXI has the advantage of using the most prolific communications standard in the world as the underlying foundation. Many households have implemented both wired and wireless networks so many of the concepts are familiar. LXI instrumentation will continue to leverage the open standard advantages of Ethernet, offering designers and engineers increased speed, functionality, and flexibility.

About the Author
Jon N. Semancik formerly was the corporate marketing and business development manager at VXI Technology and both secretary and co-chair of the marketing committee for the LXI Consortium. The U.S. Navy veteran has held engineering and project management positions on numerous programs in both the military and commercial sector. Mr. Semancik earned a B.S.E.E. from Fenn College of Engineering and an M.B.A. from the Weatherhead School of Management, Case Western Reserve University.

PDF of this article

Back to Top

Web Pages Go Beyond the Basics

By Conrad Proft, Agilent Technologies

 

Imagine being able to monitor a test system from the comfort of your office when the instrument might be 100 feet away, 100 miles, or halfway around the world. That' s one key benefit of LXI instruments.

The built-in web server gives users an easy way to configure, learn, access remotely, and even assist in programming the product. Virtually no software installation is required to start using the instrument. If your computer has a LAN port, a LAN cable, and virtually any web browser, you can connect to the instrument.

The LXI standard specifies how instruments must behave on the LAN, and there are requirements for the content and presentation of an instrument' s home web page. This behavior is the foundation of LXI instruments.

If you have worked with one LXI instrument, you already are familiar with others— much like driving a car or riding a bicycle. You can build a test system with certified instruments from any supplier, and they all behave the same way when connected to the LAN, even if they have drastically different functionality.

Venturing beyond an instrument' s home page, vendors have the flexibility to implement functionality beyond the LXI specification. This permits product differentiation and lets suppliers achieve competitive advantages. While some manufacturers offer only what is required by the LXI spec, others provide a very comprehensive and even graphical way to control, monitor, and troubleshoot their instruments through the web interface.

Getting Started
Consider a simple case of connecting an LXI instrument directly to a laptop computer with a single LAN cable. All modern-day laptops have LAN interfaces, and those interfaces will likely be Gigabit Ethernet if the computer is less than three years old. With Gigabit Ethernet, you don' t have to worry about crossover LAN cables because the standard requires auto-sensing of the configuration and modifying itself to connect properly to the peripheral, a feature called Auto-MDIX.

LXI instruments and PCs behave the same way when you connect them to another device over a LAN. First, they both request an IP address from a dynamic host configuration protocol (DHCP) server. Because there is no such server in this simple configuration, both the PC and the instrument revert to Auto-IP, which means they each pick an IP address for themselves. They then broadcast that IP address to each other to make sure it is not the same. If a conflict arises, one device must pick another IP address until no conflict is present.

In this configuration, the IP address always is in the range of 169.254.xxx.xxx. This means the default IP addresses for both the instrument and the PC fall into the same address range, and they can talk to each other.

Many instruments default the last two digits of the IP address to the last three digits of the instrument' s model number. As a result, the 34980A Switch Measure Unit would default to 169.254.9.80.

The IP address is all you need to connect a web browser to the instrument. Here are just three of the many ways to determine that address:
• Read the IP address from the instrument' s front panel.
• Use LAN instrument discovery programs, such as ACE and MAX from Agilent Technologies and National Instruments, respectively, to find instrument IP addresses.
• Use the instrument' s default host name, which usually is a combination of the instrument' s model number and serial number.

Now run your computer' s web browser— whether Firefox, Internet Explorer, Netscape, or another— and enter the IP address of the instrument into the browser' s address field. The result looks something like Figure 1.

Figure 1. LXI Instrument Home Page

Manufacturers use different color schemes and templates to give a unique look and feel to their family of instruments, but the information presented on the home page adheres to the LXI spec. It includes product description, serial number, host name, VISA programming string, Telnet port, and socket port.

Buttons on the left give access to additional functionality and information. With View & Modify Configuration, you can change defaults and set up security. Browser Web Control directs you to observing the configuration and controlling the instrument. It also is where vendors find the freedom to create an environment that works best for their particular instrument.

While the home page, the associated communications configuration, and help pages all must be HTML based, the Browser Web Control pages can be Java scripts, Java applets, and flash programs. Java applets and flash programs are executed by browser plug-ins, which means you might have to load some additional software on the PC before controlling instruments using such programs. Most modern PCs come with this software loaded already, but it' s a simple matter to obtain the plug-in from www.java.com, for example.

Products such as oscilloscopes and spectrum analyzers generally have a real-time graphical screen that looks very similar to the screen presented on the front panel of the bench version of the instrument. These screens typically are Java applets or flash programs because of the need for real-time updates.

Figure 2 shows examples of screens from various instruments. The user would select various functions simply by clicking on buttons of the virtual front panel.

Figure 2. Various Virtual Displays

Other instruments provide a combination of pop-up dialog boxes, animated representations of switches, and direct control of those switches simply by clicking the image of the switch to actuate it. With up to eight plug-in modules present in the Model 34980A, the user selects which module to view and then can control and configure that module (Figure 3).

 

Figure 3. Direct Control and Feedback

Other Cool Features
A host of functions are provided that can simplify development and verification of test systems using LXI instruments. In some cases, when you configure the instrument from a web browser, each button push with the mouse actually records which SCPI commands are necessary to configure the instrument for that operation.

For these instruments, there is literally no need for a programming manual. You can copy and paste the SCPI commands from the browser window into a test program. Because many programmers use instrument drivers to avoid learning SCPI, this can be a way to make that learning experience easier. And the net result is a faster executing program.

Having a web browser window open to the instrument also provides the programmer with feedback on the instrument configuration at any time when stepping through a program. This is more difficult to achieve with VXI and PXI products because there typically is no way to open up a soft front panel to the module simultaneously while debugging without causing a conflict with the module driver operating in the user program.

In addition, some instruments, such as the 34980A, also capture SCPI commands and responses when a program is running. If you are using instrument drivers, this can assist you in understanding what the driver is sending to the instrument.

One other feature worth mentioning is the monitoring of relay cycle counts. LXI instruments can keep track of the number of times relays are actuated. The web browser interface allows technicians to monitor test systems passively, while they are operating, to provide preventative maintenance.

Are You Secure?
Instruments that can be operated from a web browser should offer a means to keep instruments from being altered during test system operation. Agilent and other vendors provide security through pop-up dialog boxes that require a password before you can modify the instrument configuration.

In most cases, it is possible to view any configuration, but you are prevented from modifying it without supplying a password. The Agilent 34980A in Figure 3, for example, allows you to view any of the modules during their operation in a test system, even with password protection.

Multiple Browser Connections
Most, if not all, LXI instruments permit multiple users to be connected to the instrument at the same time. There is a limit, of course, due to available memory. In most cases, three or more connections can be made at the same time. This can be very helpful in training and diagnosing problems with remote test systems.

For example, a 34980A was sent from the United States to France for a trade show. It had an associated demo program that was developed by engineers in Colorado and New Jersey.

When the demo program didn' t work for the engineer in France, he called the engineers in Colorado and New Jersey for help. Because all Agilent facilities are behind the same firewall, access to instruments can take place from any facility.

The engineer in France simply had to plug the instrument into the Agilent Enterprise Network and provide the instrument' s IP address. All three engineers brought up the unit' s web pages to view its operation and configuration.

The French engineer ran the test program, and the other two engineers watched the results because they could monitor the SCPI commands sent to the instrument using their web browsers. In the input buffer log, they noticed errors in the SCPI commands.

The engineer in New Jersey ran the same demo program on his computer connected to the instrument in France. It was slower due to the long distance, but the results were positive. The engineer in Colorado noticed the difference between the input buffer log of the two program executions. The problem became obvious: The PC in France was using a different radix configuration where commas and periods were reversed, which caused the errant SCPI commands.

The program was modified to avoid the localization issue, and the demo worked on the PC in France. The entire effort took 30 minutes to straighten out. Remote access provided a significant benefit in troubleshooting this situation.

Other stories are prevalent where engineers can diagnose problems of test systems running in Asia while monitoring them from their location in the United States or Europe. All this is possible simply because the LXI instrument has a built-in web server that allows monitoring and control.

Conclusion
Easy setup, verification, and help with programming using built-in web pages are all significant strengths of LXI instruments. They reduce overall development time and avoid having to complicate a test program to provide the same functionality. Remote access of instruments is key to monitoring the operation of a test system.

LXI instruments are available in both bench and system packages. System packages typically have no front panel. The web pages provide easy interactive control, often better than using the actual front panel of a bench instrument. As a result, you maintain complete control and access to instrument functionality even when using faceless instruments.

Instrument web pages will become even more functional in the future as instrument manufacturers find ways of providing driverless interfaces to instruments via a LAN. Functionality can literally be created from the web pages and accessed by name through the user program. This then will provide the best of both worlds: easy to set up and easy to program.

About the Author
Conrad Proft is a sales development expert for the Next Generation of Test Electronic Measurements Group at Agilent Technologies. He has worked for HP/Agilent for 28 years and spent about half of that time between R&D and marketing, specializing in general-purpose instrumentation for bench and system measurements. Mr. Proft holds both B.S.E.E. and M.S.C.S. degrees. Agilent Technologies, Loveland, CO 80537, 970-679-3009, e-mail: conrad_proft@agilent.com

 

PDF of this article

 

Back to Top

 

---

---

---

Climbing the LXI Learning Curve

By Paul G. Schreier, Editor

 

Just as users are becoming familiar with LXI and its benefits, manufacturers are finding out how to efficiently add LXI capabilities to instruments and build in features users will find attractive and easy to use. So, what are the major product trends you can expect to see in the next months?

In speaking with LXI suppliers, I' ve found them universally very enthusiastic. They say that the move to LXI is simply so logical and obvious that the spec' s success is inevitable, and to be a player in the future, they have to be on-board. As a result, they' ve started making significant investments in terms of time and funding, and we' re seeing their first fruits. But product development is as yet embryonic.

It' s important to recognize that LXI is evolutionary rather than revolutionary. That is, it doesn' t add any fantastic new functions. Everything you could do before you can do now— but in some cases much more easily.

By itself, " LXI doesn' t change the world. There are no earth-shaking measurement capabilities with LXI today," commented Mike Kawasaki, senior manager, Next Generation of Tests Initiative at Agilent Technologies. " There is huge potential, but it will take time. Suppliers need to learn how to best integrate these capabilities into their instruments, and users have a learning curve to climb."

Will LXI take over as the single dominant instrumentation standard? Most people think not. Modular schemes such as PXI and VXI still will have a place. But when it comes to connecting discrete instruments together, that' s where LXI shines.

According to Chuck Cimino, a marketing director at Keithley Instruments, " We envision GPIB as falling by the wayside. USB will be viable for single instruments, and LXI will dominate for connecting discrete instruments. In the transition period, we will likely offer all three, perhaps with GPIB as an option."

From the viewpoint of Peter Allen, product marketing manager at Xantrex/Elgar, " LXI is the next logical thing, and Class C is the next evolutionary step after GPIB." For a summary of classes, see the sidebar.

Manufacturers as well as users are in a transition period. For instance, Kepco is upgrading its existing power supplies and making LXI an option. To make room in the supplies, they remove the RS-232 interface. In new designs, the company hopes that LXI becomes standard with GPIB as an option.

In the meantime, customers are not forced to build complete LXI systems from scratch; their test systems can evolve. They can build around a LAN backbone, but it is key that they can reuse existing test-system components while moving to LXI.

It' s difficult to pin down how many people are actually using it because of the lack of LXI-only instruments. LXI is in the mix, but it' s not yet a primary driver for people buying instruments.

To get some rough indication of where the market is going, consider power supplies from Xantrex/Elgar. For the moment, LXI is available only as an option. Today, 10% of the units the company ships go out with the LXI option, and the number is growing steadily.

Already there' s a wide selection of LXI-compatible products, and with them, you should be able to put together systems that meet a wide range of requirements. Agilent, a co-founder of the LXI Consortium and presently offering the widest selection of certified products, has tried to include at least one LXI instrument from each of its major product lines.

In general, though, only a few LXI products implement the spec in its full form. That is, most conform to Class C specs as opposed to Class B or A.

This situation is changing with a number of product introductions at AUTOTESTCON this month. Besides an extensive demo in the LXI Consortium booth, a number of member companies will demo LXI in their own booths. One interesting demo will be based on a wireless LAN.

What' s Getting Customers Excited?
So what aspects of LXI are actual users getting excited about? Vendors report that initially it' s the LAN interface. Second, they like avoiding investing lots of money in cables and controllers. Third come the software issues such as the capability to program with standard drivers and operate instruments with web-page interfaces. Finally, there are the life-cycle issues.

Today, explained Agilent' s Mr. Kawasaki, users sometimes actually hate new products because when it' s time to replace an instrument they have to reconfigure their systems. With LXI, they can purchase a new box and take advantage of its form factor and functions, yet it will be compatible with the existing system.

LXI also is very attractive for building distributed systems, even in an unconventional sense. Engineers like to work from many locations, whether in the office, at home, or in a coffee shop. With LXI, they can access instruments from anywhere, using built-in web pages to run tests and check results.

For instance, Jon Semancik, formerly corporate marketing and business development manager at VXI Technology, reported that Boeing uses a number of the company' s EX1629 Strain-Gage Boxes, a model built to be LXI compliant but not yet officially certified, to test the wings of its 787 Dreamliner. Similarly, Jochen Wolle, a software development manager at Rohde & Schwarz, explained that for EMC applications people want control of a test receiver inside a shielded chamber. Rather than route standard cables into this protected area, the LAN connection can be based on fiber optics.

For power supplies, noted Xantrex/Elgar' s Mr. Allen, the LAN approach can be very attractive. Many power-supply applications require sense leads on the DUT to help compensate for voltage drops in the cables, and these leads usually are designed for a couple of volts.

But, what if a missile system is located at a distance on the launch pad, resulting in large voltage drops that can be difficult to deal with? Although the test engineer must be far away, the power supply need not be. With LXI, you can simply put a LAN connection close to the missile and not worry about the control computer being too close. Similarly, engineers working in a wafer fab wouldn' t have to dress in a clean-room suit to debug a test setup.

LXI has other attractive features in specific industries. Physical size can be an issue, particularly when working with microwave signals or in switching high currents such as in the automobile industry, reported Bob Stasonis, sales and marketing manager at Pickering Interfaces.

Some microwave relays are so large that only two or three can fit on a PXI card, and a system will need multiple cards and even multiple chassis. That requires lots of plumbing, which, in turn, affects insertion loss and VSWR. With LXI, the company can offer better specs and use larger, lower-cost relays. In this way, users have switching that is inexpensive to scale up.

The Integrated Web Page
The first round of LXI instruments has been dominated by Class C units that are upgrades of existing designs. Some vendors previously had Ethernet-based instruments, even some with built-in web pages. But they weren't standardized, so interconnecting them could require significant time.

But even at this lowest level of compliance, the LXI spec leaves considerable room for interpretation and enhancements. As a result, manufacturers are taking different approaches to how they deal with it. Some implement the very minimum to get a unit certified; others add special features.

   

Actual Front Panel (top) and Replica Built-In Web Page (bottom) of Keithley’s Model 2810 RF Signal Analyzer

Even so, Class C units have much to offer. One core feature is the integrated web page. LXI has fairly minimal requirements in this regard, and here manufacturers can add interesting features.

With Keithley' s Model 2810 Signal Analyzer, users can view a remote version of the analyzer' s front panel on a PC. The web page closely resembles the instrument' s actual front panel and display in what Keithley terms a lively remote interface. Also, multiple users can view the instrument' s front panel simultaneously.

Perhaps an engineer in a lab wants to ask colleagues elsewhere for their opinion of certain test results. In an educational setting, an instructor can set up the instrument and, instead of the students crowding around it trying to get a peek at the settings and results on the display, they all can have the instrument display appear on their PCs.

The web page also will have an impact on how users program instruments. " With that web interface, we think it likely will be possible to eliminate ancillary software for many sequential or analytical applications," added Keithley' s Mr. Cimino. For complex test applications, users will still want a test executive. But for simple sequential tasks, the web page gives customers alternatives to big software applications.

For its LXI switching networks, Pickering wrote a Java applet that allows users to set switches at random. Some of their customers find that they don' t have to write any code; they just manipulate the switches on the web page.

Similarly, Agilent points to how time can be saved when setting up its Model 34980 Switch. On a PC screen, users can visually click through a series of tasks. The software contains a logging capability so that you first click through the tasks, then ask for the commands to generate code from this listing capability.

The situation is somewhat different with power supplies, and Kepco still is tinkering with their web-page design. For now, that page basically lets you set all power supply parameters. The company' s plan with its bipolar supplies, though, is to implement a list command to program waveforms on a point-by-point basis in a sort of basic function generator.

EX2500 LXI-VXI Gigabit Ethernet Slot-0 Interface From VXI Technology

Interestingly, one thing that Kepco discovered is that more than one person can try to control the same power supply at the same time, which would lead to the instrument locking up. As a result, they have implemented a password feature whereby only one person at a time can take control of the instrument.

Class C is perfectly adequate for many power supply applications. Rise times are orders of magnitude larger than the difference between the control signals of GPIB vs. LXI so precise triggering, as in Class B and A designs, isn' t mandatory. Further, power supply control is not an application with a large data package so control commands can move quickly across the net.

Even if there' s lots of bus traffic, a control signal has a delay of only a few milliseconds. According to Mr. Stasonis from Pickering, " Some customers are afraid of sending control signals over the LAN. But by setting up the network properly, we can alleviate these fears."

Class B: Triggers Over the Ethernet
Those who do need precise triggering will start investigating doing so over the Ethernet. Here LXI works with IEEE 1588, a standard that defines clock synchronization over a LAN.

Because early prototypes of this scheme were developed by Agilent, it' s no surprise that the company currently has the largest number of instruments with this capability. Until recently, there have been no pure Class B instruments available; they' ve either been Class C (with no LXI triggering) or Class A (with both LAN-based and hardwired triggering).

There is great potential with this little understood technology. The trick is in implementing it in a particular instrument, and there is a significant learning curve for both users and manufacturers. Some vendors even say that adding 1588 is the most expensive and toughest part of this business.

Rack of Class A Synthetic Instruments From Agilent Technologies

Even so, a growing number of products with IEEE 1588 capabilities will appear shortly. You can get a first-hand look at some at two separate demos at AUTOTESTCON this month. The LXI Consortium is presenting a Class B demo that involves multiple vendors including National Instruments, Rohde & Schwarz, and Agilent. Agilent is showing the power of timing synchronization through a new trigger box and the capability of its MXA Spectrum Analyzer and MXG Signal Generator to communicate through peer-to-peer capabilities.

Class B adds some unique features such as peer-to-peer communications without sending signals over a wired bus. It would be useful, for instance, to have an RF signal generator send a stimulus and then notify a spectrum analyzer directly to take a measurement without having to involve a central controller.

A small program inside each box could send signals back and forth as the two instruments step through a series of frequencies. Users could download a list of frequencies, have each instrument run on its own time, and tell the central controller when that task is done. This approach would take traffic off the bus and speed up system-wide communications.

Class A: The Wired Trigger Bus
Currently, the only Class A products are available from Agilent and VXI Technology. The Class A wired trigger bus (WTB) plays a large role in letting engineers integrate LXI into existing test setups and makes LXI compatible with legacy hardware while allowing people to ease into these new technologies. This is part of the philosophy behind VXI Technology' s EX2500, an LXI-VXI Gigabit Ethernet Slot-0 Interface.

Rohde & Schwarz FSL Spectrum Analyzer With Class C Plus Capability

For the moment, all of Agilent' s Class A products can be used to build synthetic instruments. These modules, building blocks rather than complete traditional instruments, include a digitizer, a downconverter, a waveform generator, and an upconverter.

One distinguishing feature they all share is the lack of a front panel: Everything is controlled via software. By combining these modules in various ways, users can emulate traditional instruments or create specialized instruments. The reusability of modules in different measurement scenarios reduces the total lifetime costs of a test system by extending its longevity and provides obsolescence protection.

Much is said about the cost of GPIB cables, and while LAN cables are inexpensive, WTB cables aren' t throwaways. One of the few suppliers is VXI Technology, whose Class A triggering cables cost from $158 to $475 in distances from 0.5 m to 20 m. The connectors are expensive because they are 25-way microD connectors with shielding.

Class C + WTB = Class C Plus
While Class A instruments must include both the WTB and IEEE 1588 triggering, several vendors have developed Class C instruments that add the WTB but not IEEE 1588. They' re more than Class C but don' t qualify as Class A, so some vendors refer to them informally as Class C Plus instruments.

One such supplier is Rohde & Schwarz, whose FSL Spectrum Analyzer has been certified with its LXI hardware trigger. It has a slot that accepts an option card populated with an FPGA that implements the routing of the trigger signals across the WTB.

In addition, there is room on this FPGA to accommodate hardware support for the IEEE 1588 clock synchronization and time-based triggering. With these counter registers for clock implementation and hardware comparison of timestamps, Mr. Wolle said the IEEE 1588 implementation achieves accuracy of between 10 to 20 µs where a pure software scheme would work at 100 to 150 µs.

C&H Technologies is adding the WTB to the EM405-8, an M module carrier already approved as a Class C instrument, to make it another Class C Plus box. Interestingly, the EM405-8 is not a product upgraded to LXI. The company planned to include Ethernet capability and designed it from the ground up for Class C operation.

Reference
1. Dewey, M., " LXI Instrument Classes," LXI ConneXion, January 2006, pp. 8-11.

About the Author
Paul G. Schreier is a technical journalist and marketing consultant working in Zurich, Switzerland. He was the founding editor of Personal Engineering & Instrumentation News, served as chief editor of EDN Magazine, and has since written articles in countless technical magazines. He earned a B.S.E.E. and a B.A. in humanities from the University of Notre Dame and an M.S. in engineering management from Northeastern University. e-mail: paul@pspr.biz

For More Information
on a wide selection of LXI-compatible products
www.rsleads.com/715ee-176

 

PDF of this article

 

Back to Top

 

---

---

---

 

LXI Makes Smart Instruments Possible

By Paul F. Franklin, Keithley Instruments

Smart instruments that do more work and relieve the burden on test system designers are becoming more available. These instruments incorporate a number of advanced functions, including the capability to make complex measurements and control timing and sequencing.

Smart instruments also can perform highly sophisticated data analysis that helps transform raw data into useful information. These and other capabilities greatly improve the performance of test systems while simplifying setup, debugging, and troubleshooting.

However, while instruments are becoming smarter, none have reached the level of intelligence most users would like. One factor limiting the development of smart instruments is cost. Defining, designing, and producing truly smart instruments increase development cost, time to market, and product cost.

As a result, instrument makers must strike a balance between the market' s demand for less expensive but more intelligent products and the need to bring products to market faster. For smart instruments to truly make an impact, instrument makers must demonstrate how they can reduce the total cost of test before users will be willing to pay more.

Technical considerations also limit the development of smart instruments. Instruments typically must interface with other equipment and software as part of a complete test system. Because few test systems are configured exclusively with one vendor' s products, the limitations associated with other components and the interfaces may restrict the overall level of possible improvement.

Major instrument manufacturers recognized that current technology and standards limited their capability to provide smarter instruments at lower total cost. This realization played a major role in the formation of the LXI (LAN eXtensions for Instrumentation) Consortium. LXI-compliant instruments provide a number of capabilities that improve the prospects for the development and deployment of smart instruments.

The Power of LXI
The key features of LXI that make smart instruments possible include the following:

●  A LAN interface featuring a defined standard network configuration, a Web page for network configuration, and a discovery mechanism for locating LXI devices on a network.
●  A Web interface consisting of a set of standard Web pages that provides information about the instrument, a standard way to configure the LAN interface, and other features.
●  Timing and synchronization based on IEEE 1588 that synchronizes real-time clocks in each device and can be used to timestamp data or initiate time-based triggers.
●  An IVI-compliant instrument driver.
●  Peer-to-peer messaging from one LXI device to another that implements LAN triggering and supports a short data payload.
●  A uniform trigger model and event structure.

These features provide a powerful toolbox for vendors developing smarter instruments, especially when combined with test-script programming that will be available in next-generation instruments.

Smart Instruments at the Interface
Besides being a key factor in making smart instruments possible, LAN connectivity can simplify maintenance and support. For example, the LAN interface provides centralized maintenance monitoring in which the calibration and maintenance status of all instruments can be monitored and tracked from a remote location. This capability also allows remote asset tracking of instruments.

Firmware upgrades also are easier because they can be installed over the network. In addition, in-house and vendor technical support personnel can diagnose problems remotely over the LAN, saving the time and expense of sending a technician to the instrument location. Finally, users can share and administer licenses for advanced features over the network. All these features can reduce support, maintenance costs, and downtime.

The basic Web pages recommended by the LXI specification make instruments easier to integrate and use, but they do not fully demonstrate the potential of a full-featured Web interface. Web technologies such as Asynchronous JavaScript and XML (AJAX) and Java applets can provide a rich, responsive, and easy-to-use Web interface with relatively modest memory and processing power requirements. Potential features include full instrument configuration and control, tabular or graphic data display, extensive user help, and wizard-style guidance for common tasks.

An enhanced Web interface can provide several benefits, including the following:
●  Web pages that can be viewed on any browser from a remote computer.
●  The ability to operate an instrument from anywhere in the world.
●  No requirement to install software on a remote computer.
●  No software version conflict issues because the Web interface is always the correct version for the instrument.
●  Instruments without a front-panel display or a simple one that still can provide an intuitive user interface.
●  Embedded Web-based help to eliminate hunting for lost manuals or CDs.

Embedded Applications
In addition to the capabilities provided by enhanced Web pages, smart instruments can include embedded applications with capabilities rivaling those of discrete applications normally installed and executed on a test- system controller. The peer-to-peer capability of the LAN interface means these applications can involve multiple instruments, allowing small to medium test systems to be constructed without the traditional system controller.

For example, two instruments could be controlled by an embedded application to perform I-V characterization of four-terminal devices. The instrument running the application could use peer-to-peer LAN messaging to control the second instrument and collect data for display on a Web page.

Another benefit of embedded applications is the smaller impact on end applications due to changes in the operating system, I/O libraries, and related software and utilities. In traditional systems, application programs running on a separate computer or controller demand maintenance because they must be retested when those components are updated.

In contrast, Web browsers change less frequently and maintain strict backward compatibility. This translates into reduced maintenance by the vendor, which, in turn, means fewer updates and revisions for the user.

Embedded applications also provide an architectural advantage. A typical application program generally involves interactions between the program logic itself, an instrument driver, an I/O library that supports instrument communications, and the instrument firmware.

Although there are benefits to this type of layered architecture, it also can increase development time and cause maintenance problems. An error in the logic or changes to the instrument can require revisions to all components in the system.

However, with an embedded application, all the necessary logic is contained within the instrument, reducing development time and maintenance. For example, consider a simple application developed to run on a separate controller. The application has a graphical user interface that allows the user to select the measurement range of an instrument. The application uses the IVI driver provided with the instrument and the VISA I/O library to manage communications with the instrument.

Such an application will have logic to check the validity of the user' s range selection in multiple software components. There will be range-checking logic in the user interface logic and perhaps in the main program logic, the instrument driver, and the instrument itself.

However, in the case of an embedded application with the same functionality, all the logic is contained within the instrument so updates become simpler and there is no danger of having incompatible versions of separate components. A further improvement is possible by using a single-range check function within the instrument that is called whenever range validation is required. This eliminates the redundant software code entirely, an ideal solution that is not practical in the stand-alone application.

Some system designers may be concerned about the performance of embedded Web-based applications, especially Java applets. However, many techniques are available to optimize the performance of embedded applications.

In addition, because discrete application programs often use layered architectures, data and commands must pass through each layer, often requiring buffering and reformatting to conform to the standards for each layer. These steps incur extra processing overhead that slows throughput.

However, embedded applications have total control over the data flow from instrument to application. All aspects associated with data and command flow can be fully optimized because there is no need to conform to IVI driver or VISA I/O library formatting standards. For that reason, performance of a Web-based application can be superior to a stand-alone application program implementation.

Scripting Boosts Performance
Adding script-processing capability to smart instruments can greatly improve performance because it supports the concurrent operation of multiple instruments. In a traditional controller-based test system, instruments can experience significant idle time while waiting for the controller to process data from another instrument before sending the next command. Each step in the test program may require several commands be sent to each instrument to prepare for the next step.

With script-processing instruments, each instrument' s portion of the test program can be transferred to it prior to execution. The instruments then can be sequenced through their individual programs using LAN triggers, time-based triggers, or hardware triggers to keep the instruments synchronized and minimize the delay between steps.

In high data-rate or large data-set applications, instruments can post-process data, compressing large data sets or performing sophisticated analysis before the data is transferred to the controller, easing controller or network throughput issues. Scripting and concurrency also can benefit applications that are not controller or network limited. Here, complex problems can be broken into manageable pieces that run independently but also collaborate to solve the larger problem.

In addition to scripting, features incorporated into the LXI standard such as IEEE 1588 clock synchronization, peer-to-peer messaging, and LAN triggers will offer users the ability to develop concurrent test and measurement systems.

Scripting Enables Event-Driven Testing
One strategy for accelerating testing, which avoids bottlenecks in conventional test system architectures, is event driven testing. In this approach, test code embedded in the UUT collaborates with smart instruments to run a series of tests at the fastest possible test execution rate.

The smart instruments are pre-loaded with appropriate test scripts. Once the test cycle has been initiated, the UUT starts and controls the sequence of tests. The UUT can sequence tests using control signals of various types, including hardware trigger lines, Ethernet communications, or some other communications bus.

While this strategy is only applicable to sophisticated UUTs, it provides additional benefits. For example, since the UUT has access to internal data and state information, it is possible to optimize test selection and speed without interaction from a system controller. Preloading test scripts and other configuration information into smart instruments can eliminate controller and communications bottlenecks, improving overall test throughput.

Scripting and Extensible Instruments
Test scripts are an ideal way to extend the functionality of an instrument beyond its base set of functions. Because scripts are executed within the instrument itself, their performance is better, and timing is more deterministic than for an application running on a remote or system controller, regardless of the communications bus used.

For an instrument manufacturer, deploying example programs and small application solutions as scripts greatly reduces its development effort. Normally, such an example program would have to be written in multiple programming languages to suit the needs of various users.

However, when written as a script, it is usable by all users, regardless of their choice of programming language. Writing, testing, and documenting a single example are much easier than supporting multiple versions. Lowering the cost of developing and deploying examples and applications ultimately reduces the total cost of test.

The Future of LXI and Smart Instruments
Several significant enhancements and additions are planned for future LXI specification releases that will further enhance the ability of instrument makers to provide smarter instruments. LXI Identification is a mechanism for obtaining a detailed description of an instrument and its capabilities from the instrument via the LAN interface. Upon request, the instrument will provide an XML document with a structured description of the instrument. This capability is intended to provide an enhanced version of the *IDN? query currently implemented in all SCPI- based instruments.

LXI Resource Management will provide a protocol for managing access to instrument functions and data from multiple clients or controllers. GPIB-based systems, for example, are limited to a single active controller at any time.

LXI systems have no such inherent limitation. LXI instruments with multiple channels or subsystems can be shared by multiple applications or controllers. A power supply with four independent outputs can be used simultaneously for four different test programs. LXI Resource Management also will provide the tools to prevent inadvertent or improper access to a device when it already is in use.

The IEEE 1588 Working Group is pursuing version 2.0 of the specification. When it is released, LXI will require compliance with the version 2.0 specification for LXI Class B devices. IEEE 1588 V2 provides significant enhancements relevant to test and measurement applications. One important change is support for much better timing accuracy.

Conclusion
Smart instruments offer the potential to lower the total cost of test by performing more of the work for users. Limitations in prevailing test-system architectures and communications buses have, until recently, prevented smart instruments from achieving their full potential. LXI technologies and programmable instruments are combining to break through the limitations of the past and allow smart instruments to shine. Planned LXI enhancements will accelerate this trend.

 

Putting Smart Instruments to the Test The capabilities and benefits of smart instruments can be demonstrated by considering a test system designed to make pulsed RF measurements on an RFIC power amplifier. Testing is done in short pulses (2 ms) to avoid overheating and thermal effects so timing and synchronization are critical design factors. Existing Setup The existing test setup consists of standard instruments; a PC; application programs in visual C, VB, or other ADE; instrument drivers; an I/O library; a GPIB controller and cables; trigger cables; and a controller and communications to determine timing (Figure 1). Figure 1. Existing Setup Possible Future Solution A test system taking advantage of LXI-compliant smart instruments would include LXI Class B instruments with scripting, a PC, an embedded application in each instrument, LAN cables, a hub or switch, and IEEE 1588 timing (Figure 2). Figure 2. Possible Future Setup Benefits The move to smart instruments benefits both the user and the instrument supplier: no software, driver, or I/O library installation and maintenance; no version-itis between software, driver, I/O library, and instrument versions; less costly than GPIB; no trigger cabling; and better performance with timing accuracy tied to IEEE 1588 and optimized communications between application and instruments. Vendors also can reap some benefits. Applications are written only once, eliminating the need for several versions for different ADEs. Also, less maintenance is needed for operating systems and ADE upgrades.

About the Author
Paul Franklin is the manager of Keithley Labs and chairs the LXI Consortium' s Technical Committee. Before joining Keithley Instruments in 2000, he gained more than 20 years of measurement and control industry experience as an engineer and a manager with electronic controls and industrial automation firms. Mr. Franklin earned B.S.E.E. and M.S.E. degrees at Case Western Reserve University and is a member of IEEE, the IEEE Computer Society, the IEEE Instrumentation and Measurement Society, and the Association for Computing Machinery. Keithley Instruments, 28775 Aurora Rd., Cleveland, OH 44139, 440-542-8097, e-mail: pfranklin@keithley.com

 

FOR MORE INFORMATION
on the LXI specification
www.rsleads.com/714ee-176
 

PDF of this article

 

Back to Top

 

---

---

---

 

Network Security for LXI Systems

By Mike Dewey, Editor

 

The ubiquity of LANs and the low cost of Ethernet are features that make LXI a very attractive alternative to other control bus implementations such as GPIB, RS-232, FireWire, or USB. However, unlike test systems that might be controlled by a localized network such as GPIB, systems that rely upon a LAN or WAN must contend with network security issues.

Depending on the specific architecture and span of connections that comprise a LAN-based test system, the requirements for a secure network can vary from minimal to extensive, with each LXI device and the associated system configuration conforming to a company' s IT security policies.

The need for secure networks is universally recognized by all IT organizations. Consequently, implementing an LXI system that uses these same networks requires that test system designers and users apply the adopted policies and procedures to maintain the security integrity of the network.

Understanding Network Security
To understand how the incorporation of an LXI device or the design of an LXI system might impact the overall security of the controlling network, it' s important to know the requirements, policies, and methods associated with creating a secure network. Protecting the integrity of your network and the information transported requires addressing the following questions: How do you protect confidential information that is available on your private network from those who do not explicitly need to access it, and how do you protect your network and its resources from malicious users and accidents that originate outside your network?

Network security involves protecting against a variety of security threats, which can compromise both your network' s information and performance. Several of the more common methods of attack include the following:

Network Packet Sniffers
Network packet sniffers can gain access to system-level account information by monitoring nonencrypted packet traffic. User account information, passwords, and even the integrity of the network can be compromised by intercepting network traffic packets.

IP Spoofing
IP spoofing involves an attacker who can send erroneous or embarrassing e-mail to someone within the organization appearing like it came from a known person within the organization. It also can be used to access user account and password information. The attack could come from within the organization or via a Telnet connection to an SMTP port on the system, which allows the attacker to insert bogus sender information.

Password Attacks
Password attacks can result in an unauthorized individual successfully penetrating the network, compromising a network' s integrity. For example, an attacker could modify the routing tables of the network by having all packets routed to him or her for monitoring prior to delivery, effectively becoming a man in the middle.

Denial-of-Service Attacks
Denial-of-service attacks are somewhat different from other security breaches because they make a network or service unavailable for normal use. Basically, by overloading a service or server, they can effectively shut down a website or server. Depending on a network' s specific architecture and topology, it is possible for a denial-of-service attack to cripple a complete network by flooding it with undesired or useless data packets and providing erroneous information regarding the status of network resources.

Application-Layer Attacks
Application-layer attacks are probably the most visible or at least the most publicized types of security attacks and referred to as malicious software (malware). Viruses, worms, and Trojan horses are all types of malware.

A Trojan horse is any program that invites the user to run it but conceals a harmful or malicious payload. The malicious payload may take effect immediately and can result in many undesirable consequences, such as deleting all the user' s files. More commonly, it may install further harmful software into the user' s system to serve the creator' s longer-term goals.

Trojan horses also can start a worm outbreak by injecting the worm into the user' s local networks. The use of ActiveX controls is a known method for implementing a Trojan horse attack and one of the main reasons that many network computers are configured to disallow the use of ActiveX controls.

A network' s vulnerability to security breaches or attacks can vary depending on the network' s span or perimeter size as well as the number of access points. Generally, the larger the network, the more vulnerable it may be to security incursions. Types of networks include the following:
● LAN— a network that typically operates within a limited part of a building' s floor or area. Private networks also can be classified as LANs.
● WAN— a network of subnetworks that interconnects LANs over a geographical area within a single organization.
● Intranet— a TCP/IP-based logical network within an organization' s internal network structure.
● Internet— a global, public TCP/IP-based network that may be used to interconnect WANs and LANs via a switched or a virtual switched connection using the Internet cloud.
● Virtual Private Network (VPN)— a network where data packets from an internal network are transmitted over the Internet using encryption to ensure a secure connection, resulting in a virtual private connection.

Figure 1 details a simple network that incorporates some of these network topologies.
 

Figure 1. Typical Network Configuration

 

Regardless of the network' s complexity or size, establishing a secure network involves defining the security perimeter of your network; that is, the outer bounds of the network where traffic is monitored and managed to and from your network as well as defining what users are trusted. To ensure network security, all external interfaces to your network must be controlled including connections to the Internet, PCs, modems, and other network devices including instruments such as LXI devices.
 

All LXI devices conform to current TCP/IP networking standards. When they are connected to a LAN, they will operate in a defined manner. In the case of a network fault such as a duplicate IP address, they will have a benign effect on the network.

Depending on the type and size of a network, various network components will be used, some for simply interconnecting various network devices and others that provide not only connectivity but also a level of security. Network components for interconnecting Ethernet devices, LANs, WANs, and network infrastructure include hubs, switches, routers, and firewalls. Routers and firewalls are key components for constructing a secure network perimeter.

Routers provide the capability to interconnect and isolate multiple networks via high-level protocols such as TCP/IP. They also allow devices within a network to hide their presence from the wider network or Internet to create small, private networks.

A router is aware of all devices that are connected to its interfaces and based on routing tables. Data packets are sent to their appropriate destinations or another router for further routing. Many routers also contain security features that function as a simple firewall by filtering packets on individual interfaces based on source and destination IP addresses.

For example, a router that interfaces to a Web server can block all traffic except for that addressed to port 80. The term port in this case refers to a virtual slot in a TCP and UDP stack and is used to map a connection between two hosts. Ports are numbered from 0 to 65535 with the range 0 to 1023 being marked as reserved or privileged and the remaining ports marked as dynamic or unprivileged. For a well-known service such as HTTP, TCP port 80 is used by Web servers to establish a TCP connection with a user.

Although routers may incorporate a simple firewall, they generally will not filter packet payloads; an actual firewall is required to support this capability. A firewall' s primary job is to protect a network from outside security threats and incursions.

However, unlike a personal firewall that a desktop computer may use, a network firewall can have two or more interfaces with traffic passing into and out of the firewall. It monitors traffic crossing network perimeters and imposes restrictions according to security policy. Firewalls typically are used to separate internal (private) and external (public) networks. As data passes through the firewall, packet source and destination IP address, source and destination ports, packet payload, and other characteristics are examined to determine whether the packet should be allowed through the firewall.

Essentially, a firewall implements an access control policy for a network. For example, to eliminate vulnerability to outside attacks, the firewall can be configured to block access to well-known TCP/IP port-specific services such as Telnet, FTP, or SMTP. If your network requires an FTP site, it can be located outside the firewall in a perimeter network area, also known as a DMZ.

If the firewall has been configured with an appropriate rule set, malicious packets will not reach the Web server. However, it should be noted that firewalls alone are not sufficient to guard against malicious traffic.

Computer viruses can pass through firewalls undetected. As a result, it is essential that all users of the network adhere to an antivirus policy that includes the use of up-to-date antivirus software on all PCs and Windows-based instruments that may be connected to an intranet or Internet.

Networks and LXI Devices
With a basic understanding of networks and security, test system designers can better determine how to best use LXI devices securely within a network. A test system' s overall physical location requirements and the span or complexity of the network interconnecting LXI devices will largely determine the security measures needed to ensure a secure LXI test system network. In some cases, simply the configuration of the network may be sufficient to ensure a secure network; for more complex topologies, the use of security policies and hardware may be needed.

A local network is the most simple network configuration case and referred to as a private network or subnet. Creating a subnet for all LXI devices that are part of a test system, particularly if all devices are physically collocated in a system, guarantees that device control will not be compromised by other non-test system LAN traffic.

Additionally, a subnet provides protection against network viruses or worms by isolating the test system from the corporate intranet or Internet. A properly configured router supports the creation of a subnet by using a feature called network address translation (NAT), which allows the subnet devices to hide their presence from public networks. This is accomplished by using a private set of IP addresses that is not accessible from the public side of the router, effectively isolating the subnet from any other network.

Alternatively, a private LAN can be created by using a dedicated network card that interfaces to LXI devices via a switch or hub. If a network error does occur within the subnet, the error condition is isolated without impacting the rest of the network. Figures 2a and 2b depict the dedicated network-interface and router-isolated implementations.

 

Figure 2. Subnet Configuration Figure 2a. Private Network With Separate Network Interfaces to PC and Intranet. Figure 2b. Router Isolated Private Network

With a subnet, any Windows-based PCs and LAN-controlled Windows-based instruments connected to the network must have updated antivirus software. However, since most LXI devices use a non-windows OS, virus attacks on these devices are not likely. Consequently, they do not normally include virus protection.

The most likely means of virus infiltration into an isolated network will be via portable memory devices where malware can be introduced via a memory stick or floppy disk. When connected to a corporate network, even via a router, devices with a USB, floppy disk, or any other I/O port represent potential security holes in a security perimeter. Consequently, it is incumbent upon the user to not only protect network devices, but also to ensure that malware is not introduced via one of these security holes, which could then propagate throughout your corporate network.
A more complex network for interconnecting LXI devices incorporates two or more subnets. For example, a test system distributed within one facility might require interconnection among several subnets via the company' s intranet (Figure 3).

 

Figure 3. Intranet Test System Configuration

For this type of network topology, the overall network security is achieved by isolating various network functions to minimize exposure to security breaches as well as manage user access to specific devices within the network. This type of topology relies upon routers and firewalls to manage access and filter traffic to and from the internal network to ensure no malicious payload can enter or leave the organization. Deploying additional firewalls between the routers and the Web servers can prevent malicious traffic from reaching servers and subnets.

Behind the network' s firewall, the premises router separates the various subnets according to specific activities or tasks. For example, a distributed LXI data acquisition system may comprise several different subnets that represent geographically different locations within a facility.

Access to and isolation of these subnets are managed by the premises router via filtering rules established by a network administrator. In this way, a virtual network of LXI devices can be created with access limited to users needing to control and manage the test system.

If other users are present on a subnet that is part of an LXI system, it is possible for these users to access an LXI device, disrupting your test or data acquisition session. This is because LXI devices presently cannot create a locked LAN I/O session between the instrument and a controller, which ensures a stable connection and blocks other attempts to access the instrument for the duration of a session. However, by properly constructing your subnets and working with your system administrator to manage user access, you can mitigate unauthorized access to LXI devices and maintain the integrity and reliability of your LXI system when using an intranet connection.

LXI devices also can be controlled over great distances. It is conceivable that a distributed test or data acquisition system might require instrumentation located at two distant facilities.

As shown in Figure 4, this type of network topology might involve two distant groups of LXI devices interconnected by perimeter routers that are, in turn, connected via the Internet. However, since the Internet is an unsecured network, creating an end-to-end, secure connection via the Internet requires a VPN.
 

Figure 4. Distributed Test System With VPN

VPNs offer a variety of features and capabilities. However, the primary criterion to consider regarding a VPN is whether the connection is temporary or always on. These types of connections are supported by client/server tunneling or peer-to-peer IP security (IPSec) tunneling, respectively.

The temporary connection allows access to WANs via remote clients and supports the access of instruments located on a remote, secure network. This type of VPN allows multiple clients to be connected to the remote devices and is most appropriate for test system networks requiring ad hoc access by various users. Two common approaches to implementing these tunnels use L2TP/IPSec (IP Security with Layer-2 Tunneling Protocol) and PPTP/MPPE with MS-CHAPv2 (Microsoft Point-to-Point Encryption over Point-to-Point Tunneling Protocol with Microsoft Challenge-Handshake Authentication Protocol version 2.)

Alternatively, for a test system or data acquisition that requires a dedicated connection between two or more remote networks, a peer-to-peer VPN connection will provide a permanent, secure end-to-end connection between two distant perimeter routers.

Some key points associated with the use of VPNs include the following:
● VPNs are capable of transporting secure traffic over unsecured networks via the use of tunneling which uses a combination of transport and security layers to transmit data over routers and through firewalls.
● IPSec provides the best support for encryption, authentication, and data integrity and its own tunneling mode, establishing a secure, always-on tunnel between two networks. It is the only truly secure method for communications via the Internet.
● Many routers support VPN connections as well as IPSec tunneling support, providing a secure, always-on connection. However, VPN routers without a hardware encryption co-processor can be an order of magnitude slower than a router with a built-in encryption co-processor. This may be a concern if your distributed test network has moderate to high data bandwidth requirements.

Like the intranet/WAN-based system, you still need to know what devices and users are present on each of your subnets so judicious configuration of each network is necessary to ensure overall system performance integrity. In addition, coordination with your network administrator is required to establish the correct type of VPN connection.

Finally, in spite of all the security infrastructure features present within a network, it is imperative that all Windows devices connected to your network, no matter where they are physically located, be protected with antivirus software. Any unprotected I/O port or device within the perimeter of your virtual network offers the opportunity to compromise not only your local network, but also your company' s entire network. With a potentially large system with multiple devices located in remote locations, the need to adhere to security policies and procedures is more acute.

Summary
The requirements for building a secure test system will be primarily determined by the complexity of the overall network used to control all LXI devices. A local system with several devices connected to a single switch will have very minimal security requirements, assuming that all devices are located behind a common firewall and the PC is isolated in some way from the intranet and Internet.

LXI systems that move beyond the use of a local network no doubt will be subject to a company' s IT security policies, automatically providing a level of network security equal to all other devices connected to the same WAN. In this case, the combination of firewalls and IT security policies will most likely provide sufficient security.

Distributed LXI systems that use the connectivity of the Internet will need to leverage all of the security measures defined by an organization' s IT department. Tools such as VPNs and authentication policies will need to be leveraged to construct a secure, distributed LXI test system.

Even with all of the best network security hardware, a secure network still requires that everyone adhere to the IT department' s security policies. Just like all other devices that are connected to the network, LXI devices represent potential security risks. Connecting to your corporate intranet and the Internet means observing the same security policies for LXI devices that are used for any other device connected to the network.

Additional Reading
1. Internetworking Technologies Handbook, Cisco Systems.
2. Zimmerman, S.C., Secure Infrastructure Design, CERT® Coordination Center, 2002.
3. Using LAN in Test Systems, Application Note 1465-14, Agilent Technologies, 2005.
4. Using LAN in Test Systems, Application Note 1465-10, Agilent Technologies, 2004.
5. Firewalls FAQ, http://www.interhack.net/pubs/fwfaq/
6. Curtin, M., Introduction to Network Security, Kent Information Services, March 1997.
7. Network Security Basics, Secure IT Consulting Group, 2002.

About the Author
Mike Dewey, the marketing product manager at Geotest-Marvin Test Systems, previously has held various positions in design engineering, engineering management, marketing, and product management with GenRad/Teradyne, ADR Ultrasound, and Motorola Government Electronics Group. He is a member of the IEEE and has served as a board member for both the PXI Systems Alliance and the VXI Consortium and been an LXI Consortium advisory member on the marketing, technical, and physical working group committees. Mr. Dewey received a B.S.M.E. from Syracuse University and an M.S.E.E. from Georgia Institute of Technology. e-mail: miked@geotestinc.com

PDF of this article

Back to Top

A Multivendor Test System

By Rob Purser, The Mathworks

When the LXI Consortium elected to develop a system featuring LXI devices in 2006, the plan involved creating a multivendor demonstration system (MVDS) to show the capabilities of LXI-compliant instruments as well as how to incorporate equipment from multiple vendors into a real-world system. The project' s goals included the following:
●  Create a system that integrated hardware and software from several of the member companies.
●  Demonstrate the variety of LXI-compliant equipment.
●  Experience the scenarios end users might encounter when building an LXI-based test system.
●  Validate the interoperability of as-built LXI-compliant equipment and that the LXI- 1.1 standard meets its objectives.
●  Complete the demo for the 2006 AUTOTESTCON and Electronica shows.

The Multivendor Team
The MVDS brought together people from Agilent Technologies, Data Translation, Elgar Electronics, Keithley Instruments, The MathWorks, Measurement Computing, Rohde & Schwarz, and VXI Technology. We met three times in person and weekly by conference call.

Getting such a diverse team to work together is a significant challenge. Many of the members represented companies that are direct competitors, which occasionally led to some contentious situations. However, everyone recognized that LXI represents a key step forward for customers and that successfully demonstrating the capabilities of LXI was critical. This shared commitment allowed us to find solutions when issues arose.

At the June 2006 meeting in Loveland, CO, we decided to focus on the following aspects:
●  Show how to perform setup and discovery of an LXI device.
●  Demonstrate that LXI matches the capabilities of GPIB and surpasses it in many areas.
●  Show how to integrate LXI into existing systems and how to create hybrid systems containing LXI, GPIB, VXI, and PXI elements.
●  Show how to migrate a system from GPIB to LXI.
●  Compare LXI performance to GPIB.
●  Feature hardware and software that is available today to help build LXI-based test systems.
●  Demonstrate the triggering capabilities of Class A and Class B devices.

Along with these goals, tight time limits were set for executing the demos to ensure that we maintained our audience' s interest. Most demos were executed in less than 60 seconds.

Getting-Started Video
To demonstrate how to get started with LXI, we created a 90-second video that illustrated the three steps required to communicate with an LXI instrument: connecting power and Ethernet to the instrument, discovering the instrument on the network, and accessing the instrument using a browser and its Web page. This video was interleaved with the Class C demo that introduced LXI.

Class C Capabilities Demonstration
The Class C demonstration focused on how a user can transition from GPIB-based test systems to LXI systems based on Ethernet. Every LXI instrument must implement the Class C capabilities including:
●  A Web page hosted by the instrument that provides access to basic configuration and setup functions from any Web browser. In addition, it may provide more in-depth Web applications.
● Instrument discovery via the VXI-11 protocol.
●  An IVI driver that provides access to the instrument from various programming languages and applications.
●  A TCP/IP-based Ethernet hardware and software interface making the instrument a good network citizen.

To demonstrate the various software environments available for supporting LXI equipment, each demo was created as a Windows 32-b .EXE and implemented using four different software packages: the C# programming language, Measure Foundry from Data Translation, MATLAB and Instrument Control Toolbox from The MathWorks, and LabVIEW from National Instruments.
The development environments were not installed on the systems running the demo. Additional software included Agilent I/O libraries and NI-VISA from National Instruments.
 

Figure 1. Class C Demo

Figure 1 shows the Class C system as built. It consisted of a number of devices that were connected via GPIB or LXI. Several devices supported both interfaces with no reconfiguration, allowing for straightforward benchmark performance comparisons of GPIB and LXI.

Most systems with LXI have other instrument control interfaces as well. As part of the demo, a Rohde & Schwarz FSQ Signal Analyzer (GPIB and LXI), a Keithley 2910 RF Vector Signal Generator (LXI), and VXI instruments using a VXI Technology EX2500 LXI-VXI Bridge were incorporated to demonstrate a hybrid system implementation. This collection of instruments, in conjunction with software I/O libraries, demonstrated the ease with which a test system could be implemented with multiple instrument control interfaces.

To illustrate the minimal software changes needed to switch from GPIB to LXI, the demo included the use of two Sorensen DLM 20-30 Power Supplies, one controlled via GPIB and the other by LXI. By using the same programming code, it was possible to demonstrate that, by simply changing the resource string, either device could be controlled.

For example, for the GPIB device, the VISA resource string "GPIB0::22::INSTR" was used. For LXI, the VISA resource string "TCPIP0::192.168.1.105::INSTR" was used. No other changes were needed to move the test program from GPIB to LXI.

Performance of new technologies always is a concern. To show how LXI and Ethernet stacked up against GPIB, two scenarios were created.

To illustrate the performance of LXI when transmitting large blocks of data, a Rohde & Schwarz FSQ Signal Analyzer was used which has both an LXI and a GPIB interface. This unit can return raw spectrum data to the PC in 256-kB blocks. Our test acquired and transmitted 100 of these blocks back to the PC over LXI and then repeated the test using GPIB. Typically, an improvement of four to five times in the throughput was observed when using the LXI interface.

To test small packet transfers where GPIB has lower overhead, 1,000 readings were acquired from a high-speed Agilent 34410 Digital Multimeter with both LXI and GPIB interfaces. Each of these readings was 16 B. In this case, GPIB and LXI offered similar performance.

These scenarios were implemented using all four software packages and coordinated by using Microsoft PowerPoint running in a continuous kiosk mode. To provide equal time to all the packages, they were sequenced so that the viewer saw demo 1 from vendor A, demo 2 from vendor B, and so on. In addition, each demo from each vendor was atomic, meaning setup, execution, and exit were self-contained, allowing the next demo to proceed without relying on pre-existing or previous conditions.

Despite these complexities and multiple software packages running side by side, the reliability of the demo was very high; it never had to be rebooted while running at AUTOTESTCON and Electronica. This is a credit to the skills of the team members, the stability of the various software packages, and the instruments used in the demo.

Class B Triggering Demonstration
The Class A and B demonstrations focused on the new capabilities that the LXI standard created for triggering and synchronization of instruments in the test system. Class B devices have all the Class C capabilities plus the IEEE 1588 network-based protocol that allows instruments to precisely synchronize their internal clocks. This enables multiple instruments to trigger at the same moment, timestamp all their readings, and even use pretriggering techniques to retroactively collect data on past events. To learn more about IEEE 1588 and Class B capabilities, see " Time Scales and IEEE 1588" by John Eidson and Dan Pleasant in the July and October 2006 issues of LXI ConneXion.

The demos were implemented in both the C# programming language and LabVIEW. The system alternated between the two software packages and between demos, showing the capabilities of both the Class B and Class A triggering and synchronization mechanisms.

The Class B demo used IEEE 1588 to synchronize the internal clocks of the instruments. Although traditional networking hardware can be used, we chose a Hirschmann high-precision boundary clock to align the instrument clocks to within 100 ns of each other. No user intervention is required for synchronization.

Each clock identifies how accurate it is, and the devices negotiate to determine who has the best clock, with all clocks then aligning to that one. Once the clocks are aligned, they can be used to trigger based on wall-clock time with a reasonable level of accuracy and no additional wiring.

In addition, Class B instruments are required to timestamp their data. Consequently, when these instruments send their data to the system controller, data can be readily correlated from multiple instruments, knowing that the internal clocks are aligned.

As shown in Figure 2, the Class B demonstration involved the characterization of an RF filter using a Rohde & Schwarz SMATE RF Generator to provide the test signals. A pair of Agilent synthetic instruments, a downconverter and digitizer, monitored the signal input into the filter. On the output side, a Rohde & Schwarz FSU Spectrum Analyzer was used. Ambient temperature was monitored using the VXI Technology EX1048 Thermocouple System.

Figure 2. Class B Schematic

With the exception of the SMATE, all are Class A LXI devices. The SMATE is Class C so it does not support LAN synchronization and triggering. Consequently, to synchronize this unit, a National Instruments' NI-1588 NIC was used in the PC to provide synchronization triggers to the SMATE.

Once the instruments had synchronized their clocks, all were configured to acquire continuously. The SMATE then iterated through the various frequencies used to test the filter. Although each instrument was free running, the data was timestamped so when the data was uploaded to the PC, it was easy to post-process to evaluate the characteristics of the DUT.

On the whole, the Class B demo was fairly reliable. Many of the instruments in this demo still were prototypes and as such required an occasional reset to get them working correctly. In addition, when using the Hirschmann clock as the master clock, some configuration was required to boot up and stabilize the unit, which made it impractical to use it as part of the demo on the show floor. Consequently, to simplify the process of starting up the demo system, we forced the system to use the NI-1588 Card as the master.

Class A Triggering Demonstration
The Class A demo used the same hardware as the Class B demo but rather than the IEEE 1588 LAN synchronization, it relied on the LXI Class A high-performance wired trigger bus (WTB) to synchronize instrument operations. Class A devices have all the Class C and Class B capabilities and incorporate a WTB, which provides low-latency triggering and synchronization between devices. This low-voltage differential signal system has eight triggering channels to coordinate instruments using traditional hardware triggering and wired-or modes. For more information, see "Introducing the Wired Trigger Bus" by David Owen in the October 2006 issue of LXI ConneXion.

As shown in Figure 3, the Class A demo used the same set of hardware as the Class B demo but synchronized the instruments very differently. It was implemented in both the C# programming language and LabVIEW.

Figure 3. Class A Schematic

Once again, to integrate the Rohde & Schwarz SMATE, we used the NI-1588 NIC along with a Pickering TTL-to-WTB converter. This device provides eight TTL lines that correspond to the eight channels of the LXI WTB. WTB channel 1 triggered the Agilent downconverter, and channel 2 coordinated the readings of the Agilent digitizer and the Rohde & Schwarz FSU Analyzer. As in the Class B demo, the VXI Technology thermocouple system monitored ambient temperature when triggered over the WTB.

While creating the Class A demo, it was difficult to diagnose exactly what was occurring on the WTB. Debugging tools onboard the instruments that offer insight into the status of the bus were rudimentary, and we found an oscilloscope to be a requirement while wringing out bus issues in the demo. Here, the Pickering TTL-WTB interface made debugging much simpler.

Both the Class A and Class B demos executed a similar test and gave results similar to Figure 4 but each used very different techniques to control the instruments' measurements. This highlighted one of the advantages of LXI: its measurement flexibility.

Figure 4. Filter Characterization Result

If you need high-performance triggering and synchronization, you can use the additional connections of the WTB. However, if submicrosecond jitter in trigger signals is acceptable in your system, you can take advantage of the simplicity of a Class B pure LAN configuration.

AUTOTESTCON & Electronica
The demos were completed and final testing took place in August 2006. The systems worked within two hours of being rolled out of the box at AUTOTESTCON in September and ran well. The Class C demo operated essentially continuously for three days. The Class A and Class B demos did require occasional reboots, but given the prototype nature of some of the equipment in the demo, some instability was inevitable.

One instance at AUTOTESTCON underlines a great strength of LXI. We had planned to give away yellow Ethernet cables to demonstrate how inexpensive the interconnect cables are because they leverage the economies of scale of the telecommunications industry. But, unfortunately, the cables were stolen during shipment to the show. Had these been GPIB cables, the loss one day before the show opened would have been a catastrophe. However, we were able to find a vendor in Anaheim who delivered 200 cables in the right length and color directly from their stock— for less than we' d paid originally.

After AUTOTESTCON, the systems were shipped to Munich, Germany, for Electronica in November. There they essentially worked out of the box even with the switch from 120 V to 220 V, a requirement for all LXI devices.

Lessons Learned
Our goal was to create a system that integrated hardware and software from several of the member companies and demonstrated a variety of LXI-compliant equipment. We found that it is straightforward to create an LXI-based system made up of equipment from multiple vendors. We have validated that real-world LXI-compliant equipment does interoperate and that the LXI 1.1 standard meets its objectives.

Along the way, we learned that assignment and configuration of the Ethernet network could be easier. Our early demos used dynamic addressing, which is how LXI is configured out of the box. However, to coordinate the dozen or so software and hardware vendors, we needed the instrument addresses to be consistent and reliable. Consequently, we found it necessary to use fixed IP addresses.

Multivendor System Demo 2007
We are in the early stages of planning the Multivendor System Demo for 2007. This time, we will focus on ease of use. We plan to enhance and refine the demos to address issues that we found, show how wireless Ethernet technologies can be used with LXI, and provide concrete examples of a hybrid system where LXI, VXI, and PXI work together. We' re currently recruiting hardware and software products for incorporation into a demo system that will show how these products can be used together to produce powerful solutions to a user' s problems.

About the Author
Rob Purser is the senior team lead for connectivity products at The MathWorks and leads the Multivendor System Demo Group for the LXI Consortium. Previously, he founded Owl Control Systems, LLC. He is a member of the IEEE and has held positions at PictureTel and Microsoft. Mr. Purser holds a B.S.C.S. from Rensselaer Polytechnic Institute. The MathWorks, 3 Apple Hill Dr., Natick, MA 01760, e-mail: rob.purser@mathworks.com
 

FOR MORE INFORMATION
on Class A, B, and C Demos
www.rsleads.com/714ee-177
 

PDF of this article

Back to Top

Looking at LXI From a Supplier' s Perspective

By David Owen, Pickering Interfaces

Being an early adopter of a new standard for instrumentation control can seem a daunting prospect for any business and particularly so for smaller test and measurement companies. In the case of the LXI standard, the presence of virtually all the major test and measurement companies at the inaugural and subsequent LXI Consortium meetings meant that these industry heavyweights were firmly focused on this new technology.

There also was a good representation of smaller companies at those early meetings. These smaller companies have an important contribution to make to the promotion and adoption of the standard since they tend to be capable of changing direction quickly.

With lower cost structures, smaller companies can implement designs and address product niches that the larger companies would have little interest in pursuing because of moderate sales volumes or the need for product customization that does not fit their business model. Smaller organizations also tend to be closer to their customer base, making it easier for them to define and develop products in a relatively short time. With a combination of both large and small LXI vendors, the benefits to the end user include a broader range of products and more vendor choices.

Commercial Background
In the early days of LXI standardization, there was much talk about competition between LXI and PXI, with some members promoting LXI as a replacement for PXI. With PXI products accounting for approximately 70% of my company' s revenue, there was concern about how LXI might influence the future of our PXI business.

Although there always will be competition among instrument standards, it quickly became evident that the very different architectures of LXI and PXI often would compliment rather then compete. PXI is good at solving problems requiring dense and diverse instrumentation within a compact footprint, and LXI is better at addressing distributed test requirements, larger systems that might not easily fit into the PXI architecture, and high-performance or dedicated applications.

The challenge was how to exploit the benefits of LXI to access new markets by leveraging the company' s current product technology.

While larger companies may have the option of starting with a clean sheet of paper when developing new platforms, smaller companies must think hard about the consequences of devoting most of their resources to a new instrumentation platform. It is financially inconvenient for a large company to get this transition wrong, but it can be fatal for a smaller company.

For Pickering, it was clear that we wanted to get involved in LXI early. But the question was how to do it and manage the risks.

Company Strengths
The experiences and expertise gained in the development of PXI switching products were our biggest strengths. However, the investment and experience were not just in hardware designs, but also in the software required to drive the switching products— a crucial asset that all too easily is overlooked.

Pickering had a big investment in switching hardware for several different control architectures, but we had an equally high investment in the software required to control the hardware. For us, the pragmatic solution was to leverage current technologies.
 

Figure 1. LXI Modular Switching Chassis

New Products
The first LXI product introduced by Pickering was a modular switching chassis, one of the first LXI-compliant products to be certified and known in the consortium as the Toaster (Figure 1). This product leveraged our current technology and allowed any Pickering PXI switching module to be controlled through an LXI-compliant interface. This immediately made a large variety of switching functions available for integration into LXI systems.

To leverage existing PXI switch modules into an LXI platform, a controller was required to support both a LAN interface and a PCI bus interface. In addition, software was needed to control the PXI cards, support a TCP/IP protocol stack, and execute driver commands received via the LXI interface.

One implementation that supports these hardware and software functions would be an embedded x86/Windows-based controller. However, the type of applications and costs associated with this type of product led us to consider other alternatives.

For signal-switching applications, the speed of execution for controlling the switch cards was not a key performance parameter. As relay closure times normally are specified in milliseconds and not nanoseconds, a high-powered, Windows-based processor for controlling the switch cards would be an overkill. As a result, we specified a lower-cost Linux-based embedded controller not ordinarily used for controlling PXI systems.

However, in this case, the embedded controller' s task was relatively simple and limited to enumerating the PXI bus, controlling the PXI devices, and translating the commands received via the LXI interface to PXI device driver commands. This choice of controller resulted in significant savings in hardware and software licensing costs. Figure 2 shows a block diagram of the modular switch/controller implementation.

Figure 2. Signal Switching in a PXI Environment Controlled Through a PCI Interface Using an Embedded Controller

Beyond the cost savings, we also had solved some important technology problems:
• Management of PCI-based PXI cards within an LXI compliant chassis via a cost-effective implementation.
• Compliance with the LAN aspects of the LXI standard.
• Generation of soft front panels by the use of Java downloads.
• Development of a common driver philosophy for LXI and PXI products.
• Restructure of our drivers to provide commonality between LXI and PXI, simplifying future code management.

Equally important, the development of this product gave Pickering knowledge and credibility about LXI. This insight helped when talking to customers about how LXI products might solve problems that were not easily addressed either technically or in terms of cost by PXI or GPIB solutions.

Our initial design efforts demonstrated just how easy it could be to control switching products through an LXI interface, particularly when the application did not require tight coupling between the controller and the switching system. By using LXI, we could leverage PXI switching products and offer a switching control solution comparable to a GPIB-controlled implementation.

An LXI-based solution provided additional tools to tackle new switching problems that might not be easily addressed by our other instrument architectures. In addition, by basing the LXI/PXI architecture on a common firmware and electrical platform, various other system configurations could be created using the same common technologies. The benefits of basing subsequent products on a common platform were twofold:
• LXI certification of these derivative products could be greatly simplified, with some products requiring only submission of a technical justification based on the commonality with the baseline product. The result is an expedited certification process, shortening the overall time to market for these products.
• By reusing common components, it would be possible to assemble other LXI products in a very short time, allowing the company to capitalize on new and time-critical opportunities presented by customers.

Moving On
Since the Toaster was introduced, other product opportunities have been successful. Applications include a video matrix and a microwave matrix, products built on a model that uses the same embedded controller that supports the LXI engine and controls the switching functions through an internal PCI interface.

This has proved to be a practical method of producing new designs with a rapid turnaround from project start to finish. LXI supplies a platform that can use both standard and custom switching solutions with investment levels similar to those associated with comparable PXI solutions.

The use of a common LXI engine across a number of products also provides a major benefit when performing LXI compliance testing. The consortium requires that all products be certified through independent testing.

The testing is a constructive process, performed by engineers with a common goal of achieving a consistent interpretation of the specification (see sidebar). Once you have proven that an instrument' s LXI engine is compliant, compliance for further products based on the same LXI engine can be demonstrated by completing a technical justification and a compliance test spreadsheet. Those documents are submitted to the Compliance Group for approval.

User Reaction
User reaction to the LXI products has been very positive. The LXI products can be easily configured, and the interface provides a high degree of isolation between the user' s controller platform and the functions within the LXI device. The common driver approach also has made it easy for users familiar with our PXI products to translate their experience to LXI.

Lessons Learned
Pickering' s experience has shown that, by judiciously leveraging a company' s current technology, small as well as large test and measurement companies can make successful LXI products. Small companies need to choose their design methodology carefully and ensure that it can be used across a range of products. Ideally, they need to choose a methodology that takes advantage of their core competencies rather than embarking on new technologies.

There certainly could be a need for a significant initial investment; but once made, the barriers to creating more products are low. Reuse is the best way of ensuring successful product development.

LXI offers opportunities for both large and small suppliers. By leveraging current technologies, the investment to create the first LXI device can be moderate with the resulting product providing an entry into a new market segment with growth opportunities.

About the Author
David Owen is the business development manager for Pickering Interfaces. Over the last 30 years, he has held key engineering, product management, and strategic marketing positions with Marconi Instruments, then IFR. Mr. Owen, the innovator of more than 10 patents in the field of RF signal generation and analysis, currently is involved in the PXI and LXI standards and serves as deputy chair of the LXI Compliance Working Group. Pickering Interfaces, Stephenson Rd., Clacton-on-Sea, Essex, CO15 4NL U.K., 011 44 1255-687900, e-mail: david.owen@pickeringtest.com

For More Information
on the LXI specification
www.rsleads.com/713ee-177
 

PDF of this article

Back to Top

LXI Simplifies Satellite Environmental Testing

By Mike Dewey, Editor, and Peter Allen, Elgar Electronics

Because satellites are subjected to large temperature extremes over very short times and distances, they present some interesting pre-flight environmental testing challenges. Parts of the satellite exposed to the sun will see very high temperatures while nearby sections that are shaded will see a very low temperature. This is due to the vacuum of space that prevents convection heating or cooling.

To accommodate these many conditions, the China Academy of Space Technology' s Environmental Engineering Department recently began developing a project for environmental testing of spacecraft satellites.

A test chamber used for environmental testing of a satellite must subject it to the same conditions encountered in space. This requires the use of a vacuum chamber that also can, under programmatic control, heat and cool the satellite.

Implementing a Solution
Chamber cooling was accomplished using liquid cooling. For chamber heating, the equivalent of 240 precision heater control zones was required to accurately replicate the heating profiles that a spacecraft would experience in space.

To heat the chamber, halogen-type heater elements were used since they provide a highly efficient and relatively precise means to incrementally control the heating process. Each heating element needed 2 W to 600 W and operated from 0 to 150 V at 0 to 4 A, requiring a total of 144,000 W of power. For maximum flexibility, each element had to be independently programmable and monitored via a central controller, allowing precision operation of all power supplies and a response time of 100 ms for any one supply.

Besides the large mechanical size implied by the number of power supplies needed to supply 144 kW, providing the remote control and management of these power supplies offered an equally large integration challenge. The implementation had to consider the following issues:

● Cabling from unit to unit as well as interconnection to the remote controller.

● Setup and debugging of the system once assembled as well as ongoing
maintenance/support tools.

● Interface control such as software and drivers.

● Interconnect infrastructure cost including cables, controllers, hubs, and switches.

● Distance from the system control computer to the power supply racks.
 

To meet the overall system requirements, 240 remote-controlled, 600-W power supplies would be needed. Based on Elgar' s DLM power supply family, the implementation chosen consisted of 16 master units each driving 14 slave units. Additionally, each power supply or group of power supplies could be controlled by a GPIB or LXI interface.

GPIB Implementation
To implement the overall system configuration using GPIB control, several key technical factors had to be considered. The GPIB bus architecture only supports up to 15 devices on one network with a maximum total cable length of 20 meters and a maximum separation of 2 meters allowed between devices. Consequently, to control 16 master power supplies, two IEEE controllers would be needed, with each master unit controlling multiple slave power supplies.

As shown in Figure 1, a GPIB-controlled system could be configured by using a combination of master and slave units, with each slave unit controlled by a daisy-chained RS-485 interface. Up to 30 slave units can be controlled by a master unit, although for this configuration, 16 masters with 15 slave units per master were proposed with control of the masters split between two GPIB control buses.

Figure 1. GPIB Configuration

While technically feasible, the use of multiple IEEE controllers would create a complex and expensive implementation. With two controllers and multiple instruments located on each bus, there was the additional concern that significant time might be needed to debug a complex GPIB configuration such as this one.

For example, if one or more instruments on the same bus were set to the same GPIB address, the control bus could lock up. There is very little the user could do to debug the problem aside from methodically checking and testing each device to verify operation and address assignment. This is a very slow and time-consuming process, particularly when you have multiple devices interspersed across four racks with limited accessibility to any one unit.

Interconnecting GPIB devices, which requires the use of expensive, shielded 24-conductor cables, also can present limitations when configuring such a large system. Overall cable length for a GPIB bus is limited to 20 meters with individual devices connected via a linear, star, or linear/star configuration.

This bus-length limitation was seen as a potential problem for this application since the controller might easily be located more than 20 meters from the chamber. Additionally, with the number of cables needed to interface to each device and the need for two GPIB bus networks from the controller to the racks, cable management and the expense of outfitting the complete system with GPIB cables were perceived to be problematic.

LXI Implementation
While it might be possible to implement this application based on GPIB control, significant setup and debug time would be required to make the system operational, and the requirement of having the control room close to the power supply was not desirable. However, because the selected power supplies supported both an LXI interface and the master/slave configuration, it was decided that a LAN-based control environment might be preferable.

Unlike a GPIB implementation, the LXI implementation removed any concern regarding the location of the power supply racks relative to the control-room location. A LAN-based implementation also eliminated any special communications cabling requirements, allowing the user to simply connect the test system to an existing LAN network without installing special cabling between the racks and system controller.

Implementing this system configuration with LXI-controlled power supplies meant using an Ethernet network or LAN to control and monitor all devices. As part of the system configuration and design, an overall LAN topology and IP address management scheme had to be established.

The LAN topology for this configuration was based on the creation of a sub network (subnet) that consisted of a PC with a dedicated LAN port and a switch/router that provided four LAN connections, one to each of the four racks. Within each rack, a seven-port switch was co-located to provide a LAN connection to each LXI device.

Creating a subnet or private network for all the LXI devices guaranteed that device control would not be compromised by other non-test system LAN traffic. Additionally, a subnet provided protection against network viruses or worms by isolating the test system from the corporate intranet or Internet. Figure 2 details the overall LAN configuration for the system.

Figure 2. Network Configuration

The overall system layout consisted of multiple racks of power supplies, with each rack subsystem being controlled by an Ethernet connection. Like the proposed GPIB configuration, each rack contained 60 power supplies with four of them configured as LXI device masters. In turn, each of these masters controlled 14 slave units via RS-485 connections.

Each rack included an inexpensive, off-the-shelf LAN switch that connected each LXI device along with simple off-the-shelf Cat 5 cabling to each group of master/slave power supplies. Figure 3 depicts an overall layout of the power supply rack system.

Figure 3. System Configuration

LXI Device Configuration
To set up or configure LXI devices, each device requires its own IP address. Since all LXI devices must support TCP/IP, communications to other network devices are done via IP addresses that can be set statically or dynamically depending on the device' s capabilities and whether the network supports the dynamic host configuration protocol (DHCP) dynamic IP assignment. For this system configuration, all devices were assigned static IP addresses.

Static addressing allowed for the orderly numbering of preassigned IP addresses throughout the power supply rack. For example, IP address xxx.xx.xx.101 corresponded to the unit in the upper left rack location and IP address xxx.xx.xx.117 to the unit in bottom right rack location.

To configure each device' s IP address assignment and the TCP/IP address mode, the user can access the LXI device' s web page, a feature that all LXI devices support. Accessing the instrument' s home page requires entering the device' s IP address if statically configured by the manufacturer. If the device' s IP address has been dynamically assigned and the network supports the domain naming system (DNS), you can enter the device' s default host name, which is specified in the manufacturer' s product manual.

Accessing the LXI device' s web home page and configuration page provided the following network information and control options:

● Host Name.

● MAC and TCP/IP Address.

● VISA Resource String.

● Configuring TCP/IP Mode: DHCP or static IP assignment; default will be DHCP if the device supports automatic IP assignment.

● Configuring Static IP Configuration, Set Values for IP Address, Subnet Mask, and Default Gateway.

● Enabling Dynamic DNS if the device supports this mode and Specifying DNS Server(s); default will be dynamic DNS enabled.
 

With the capability to access each device' s web page via the LAN interface, configuration and maintenance of each device as well as overall system configuration were easily accomplished in spite of the large number of remote-controlled devices and complexity of the system.

There are other LXI features that helped to facilitate debugging and turn-up of the system. To aid in the discovery of devices located on a subnet, all LXI devices support the VXI-11 discovery protocol. The VXI-11 protocol in conjunction with software I/O libraries and a discovery tool provided the capability to identify all LXI devices located on the LAN subnet.

By invoking the discovery mechanism, each LXI device connected to the subnet provided identification information such as manufacturer, model number, serial number, and IP address. This information was used to access each instrument' s web page as well as populate resource tables that were used by other applications and utilities.

LXI devices also support the use of the Internet control message protocol (ICMP) ping server functionality, which provides a diagnostic mechanism for verifying an LXI device' s LAN connection. By sending a ping command to a device, the LXI instrument' s LAN status indicator will indicate when a ping command has been received, providing a diagnostic mechanism for verifying an LXI device' s LAN connection and physically identifying the location of the device within the rack. This functionality was very useful during system debug since it allowed the user to easily associate the physical location of an instrument with the device' s IP address.

Controlling the LXI Devices
After connecting and configuring all LXI devices on the network, programming and control of each device required developing an application, which interfaced with the instruments' supplied drivers. For this application, a COM-based software development environment was selected with control of each LXI device.

All LXI devices are supplied with an IVI driver. For these user power supplies, an IviDCPwr class driver provided a standardized set of commands for monitoring and controlling all the LXI-controlled DC power supplies in the system. The IVI class driver with its
standardized functions helped expedite integration and development of the application and offered the capability to easily incorporate or interchange other DC power supplies in the future.

Actual configuration of the IVI driver required only that the appropriate VISA resource string name be attached to each instrument driver:

TCPIP::10.0.41.6::INSTR or
TTCPIP::HOSTNAME::INSTR

where the value 10.0.41.6 is the device' s IP address. For this configuration, since static IP address assignment was used, each instrument' s IP address value was used to create each resource string name.

Conclusion
When compared to a GPIB-based solution, the use of LXI-compliant power supplies greatly reduced the challenges and risks associated with implementing a complex system configuration. System control and integration were made much easier by using IVI.COM drivers that easily interfaced to the system' s application development software. Troubleshooting and debugging of the complete system also were streamlined by features such as the VXI-11 discovery mechanism, the use of ICMP (ping server) functionality, and web-page support for each LXI device.

Using an LXI solution also made the implementation of this system quicker, easier, and less expensive when compared to a comparable GPIB implementation. Significant savings and performance were realized by:
● Virtually unlimited flexibility in locating the controlling computer relative to the LXI instrument rack. The distance between the controller and the chamber was a nonissue by adopting an LXI-based implementation. The flexibility associated with being able to locate LXI instruments virtually anywhere relative to the system controller has become a key reason for adopting Ethernet-based instrumentation.
● Elimination of costly and bulky GPIB cables. Even though GPIB cabling was possible, cable management would have been much more difficult and complicated.
● Web-based control of power supplies providing support for diagnostics and lab testing. During the initial integration and debug phase of the project, the capability to easily connect a laptop computer to an instrument or portion of the subnet highlighted the benefits of using Ethernet in conjunction with a browser interface to control and troubleshoot system components. Unlike a GPIB implementation, no special interface cards or cables were needed to interconnect to a LAN device or switch.
● Simpler and less costly networking components. Cabling and control interfaces cost a fraction of an equivalent GPIB implementation.
● Simplified system integration and system turn-up by the customer. The combination of a simple discovery mechanism for identifying all LAN devices, coupled with the use of an IVI class driver, resulted in a very short integration time. The system was running almost immediately.

For a large system, using an LXI-based solution clearly provided a superior solution compared to an equivalent GPIB implementation. LXI' s network-based communications, the web-based interface, and the standardized software features helped to create a high-performance, cost-effective, and technically sound solution for a complex test system.

About the Authors
Mike Dewey, the marketing product manager at Geotest-Marvin Test Systems, previously has held various positions in design engineering, engineering management, marketing, and product management with GenRad/Teradyne, ADR Ultrasound, and Motorola Government Electronics Group. He is a member of the IEEE and has served as a board member for both the PXI Systems Alliance and the VXI Consortium and been an LXI Consortium advisory member on the marketing, technical, and physical working group committees. Mr. Dewey received a B.S.M.E. from Syracuse University and an M.S.E.E. from Georgia Institute of Technology. e-mail: miked@geotestinc.com

Peter Allen is a marketing product manager at Elgar Electronics and an active member of the LXI Consortium, including the marketing and compliance subcommittees. Before joining Elgar, Mr. Allen held various marketing and product management positions at Advanced Energy Industries. Elgar Electronics, 9250 Brown Deer Rd., San Diego, CA 92103, 858-458-0283, e-mail: pallen@elgar.com
 

PDF of this article

Back to Top

Autodiscovery Speeds Test-System Design

By Tom Gaudette, The MathWorks, and Scott Frasso, Northeastern University

The interconnection of instruments over LAN has created new capabilities and challenges in the areas of triggering, timing, and instrument discovery. For example, when connecting an instrument over LAN, a dynamic IP address may be assigned to that instrument, and a user needs to know the address to communicate with the device. This challenge is resolved by using the instrument discovery protocol described in the LXI standard.

The LXI Consortium was formed to create a new standard for instrument communication over LAN. The appeal of connecting instruments via LAN has increased over the last 15 years, and the need for a standard has become more critical. LAN-based instrumentation offers many advantages when compared to GPIB and proprietary interface hardware, including the wide acceptance of LAN and its low cost compared to other control interfaces.

The LXI standard builds on existing standards and protocols as well as specifies new capabilities. However, these protocols do not encompass all aspects of instrument communications over LAN. The goal of LXI is to incorporate today' s best instrument standards, provide a roadmap for future development, and simplify instrument integration and test-system creation.

Autodiscovery
Instrument discovery as defined by the LXI standard implements the VXI-11.2 Instrument Discovery protocol. This mechanism allows the user to quickly discover instruments on a local subnet.

The LXI Instrument Discovery protocol mandates the use of an identification method defined by IEEE 488.2. Instrument discovery is invoked by the use of the familiar "*IDN?" query command, which ascertains the information about the device' s manufacturer and model.

The LXI standard requires that each instrument on the network respond to a broadcast call stating that it is available. This allows the user to quickly determine which devices on the LAN are LXI compliant.

The standard also requires that each device provides identity information, such as instrument name and manufacturer. These two mechanisms allow users to obtain information about all the devices listening without any prior knowledge of the devices or the network.

The VXI 11.2 standard implements Open Network Computer Remote Procedural Calls (ONC/RPC), a distributed computing protocol. The ONC/RPC protocol provides a means of communications without heavy reliance on a structured network.

A broadcast call is sent over the subnet to ONC/RPC servers listening on port 111 of the host machines as shown in Figure 1. The broadcast call asks on which port the VXI service may be running; then the ONC/RPC servers that have this service reply. After a port has been identified, communications with the instrument can begin.

Figure 1. RPC Discovery Method

After discovering where the instrument resides, the next step is to find out more information about the type of instrument identified at a specific location. This identification process is done by querying the instrument that will return the manufacturer, model, serial number, and firmware version. This identification method is based on IEEE 488.2, which is used in conjunction with the VXI-11.2 Instrument Discovery protocol. IEEE 488.2 specifies the set of instrument commands that are to be used for controlling GPIB devices and is the origin of the "*IDN?" query.

One limitation of IEEE 488 for most instruments is associated with the use of the "*IDN?" query. For GPIB devices, this query is processed independently of what the instrument currently is doing, which is not a significant problem when all devices are interconnected via a simple daisy-chain bus such as one implemented with a GPIB cable.

But when instruments are connected across a wider network such as a LAN, this behavior can cause a fault in an instrument. This is one aspect of the LXI discovery protocol that is being addressed by future revisions of the standard (see sidebar).

Discovery Within the ADE
An application development environment (ADE) can provide users with the ability to discover and identify LXI-compliant instruments as well as a software environment and high-level computer language for data analysis and visualization, algorithm development, and numeric computation. In general, products supplied by software vendors will include a tool such as MATLAB' s InstrumentFinder that will search for instruments on the network and provide a list of instruments located on a subnet, or it may run as a background process roaming other subnets. The InstrumentFinder uses the Open Source Java Remote Tea ONC/RPC library to send broadcast calls and the "*IDN?" command to query the instrument.

The InstrumentFinder discovery tool provides the functionality needed to discover LXI devices including timeout support. Figure 2 shows the InstrumentFinder object being created and called to return a list of instruments after searching the local subnet. This list contains all the information associated with each instrument as specified by the LXI instrument discovery protocol. In addition, sufficient information is provided by the discovery tool to construct a driver using the resource string information.

Figure 2. Autodiscovering Instruments

The RPC protocol has a limitation: When searching for instruments outside the domain of a broadcast call, the discovery process requires additional work. Specifically, the discovery process must sequentially search addresses and query them for information in the same manner as a broadcast call. Instrument discovery still will be successful, although this method will not be quite as fast as searching only a local subnet.

Using the Discovery Information
Once the address and information for an instrument are known, the next step is to control and configure the instrument to perform meaningful tasks such as acquiring data, transmitting data, performing data analysis, or some other function. Before the instrument can be set up for communications, an instrument driver capable of dealing with the particular instrument is needed.

The LXI standard requires that each instrument provide an interchangeable virtual instruments (IVI) instrument driver in either the IVI-COM or IVI-C format. The IVI Foundation defines how an application-programming interface (API) for an instrument driver is to be written and allows different instruments of the same type to be grouped together in classes by each manufacturer. The IVI Foundation also maintains the Virtual Instrumentation Software Architecture (VISA) standard that defines how the API is used with I/O libraries for instrument communications.

An ADE that can configure and control LXI-compliant instruments must support IVI instrument drivers. Most environments provide tools to help create and manage the interface between the instrument driver and an ADE.

For example, MATLAB supports IVI instrument drivers through its Instrument Control Toolbox. This toolbox provides a graphical tool to communicate with LXI instruments such as oscilloscopes without writing code.

Using the address provided by the InstrumentFinder tool, a VISA resource string can be constructed to communicate with LXI instruments directly over the network. The graphical tool also can use the VISA resource string to construct a device object by specifying the driver.

Once configured, communications with the LXI instrument now are possible, and parameters such as triggering and data acquisition can be programmed, as shown in Figure 3. The tool also automatically generates scripts that can be incorporated into a test program or a GUI-based application for automation of instrument communications.

Figure 3. Configuring an LXI Instrument

Depending on how the IVI driver is implemented and what version of VISA is installed on the system, the user may be required to run other utilities for the discovery to work. Some VISA implementations require execution of a separate user interface (UI) for the discovery process before a VISA session can begin. No VISA implementation currently available allows for programmatic discovery, which is why some suppliers of ADE products offer discovery tools that can programmatically perform instrument discovery.

Conclusion
Instruments interfaced over LAN can be of many different types and from many different manufacturers. They also may require distributed programming, making test-system development challenging.

The LXI standard leverages existing standards such as those from the VXI standard and IVI Foundation to unify instrument communications over the network. Instrument autodiscovery and simplified instrument control and configuration are key components of the LXI standard. Efficient test systems can be created with LXI-compliant instruments and an ADE supporting LXI.

About the Authors
Tom Gaudette joined The MathWorks in 2001 and currently is a development manager in the Test and Measurement group. He holds a B.S.E.E. and an M.S.E.E from Northeastern University and has worked at the Nuclear Medical Resonance Center for Harvard University on combining diffuse optical tomography with other imaging modalities. Mr. Gaudette serves as co-chair (software group) of the Synthetic Instrument Working Group, is a member of the ATML and the Framework working groups, and represents The MathWorks at the IVI Foundation and LXI Consortium. The Mathworks, 3 Apple Hill Dr., Natick, MA 01760, 508-647-7759, e-mail: tom.gaudette@mathworks.com


Scott Frasso is pursuing a B.S. in computer engineering at Northeastern University. While interning for the Test and Measurement group at The MathWorks, he developed the LXI InstrumentFinder, software to assist users in MATLAB to configure LXI instruments on the network. Mr. Frasso is an active student member of IEEE at Northeastern. e-mail: ScottFrasso@gmail.com 

For more information
on the LXI standard
www.rsleads.com/713ee-178
on VXI-11.2
www.rsleads.com/713ee-179
on using MATLAB with LXI instruments
www.rsleads.com/713ee-180

PDF of this article

Back to Top

Time Scales and IEEE 1588

Part 2

By John C. Eidson, PH.D., and Dan Pleasant Agilent Technologies

Part 1 in the July issue of LXI ConneXion explored how Class B devices use IEEE 1588 to establish a system-wide precise time scale and included some examples from other industries of how these time scales may be used. Part 2 focuses on current programming models.

LXI Class B devices introduce several new capabilities not easily achievable with current test and measurement architectures:¹
• Peer-to-peer messaging.
• A wider variety of trigger models including LAN and time-based triggers.
• A system-wide time scale based on IEEE 1588.²
• Flexible, application-specific configuration of devices.

Current Practice
The most common programming model in test and measurement is for all application-specific code to execute in a central controller. This code is responsible for configuring each of the instruments in the system, collecting and distributing any needed data, sequencing of tests, ordering and associating data, and performing application-specific computation. Much of this involves interaction with the instruments, which typically is done via some sort of driver installed in the controller.

In the case of LXI, the communications take place over a LAN interface rather than a GPIB cable or a backplane. In a typical LXI system illustrated in Figure 1, this type of communication is shown as the DRIVER CALLS path between the controller and instruments A and B. Similar paths would exist between other devices and the controller. In this model, the controller mediates all interactions between devices.

Figure 1. Device-to-Device Communication Options With LXI Hardwired Triggers

In a GPIB system, precise synchronization of instruments usually is done via a hardwired trigger. Signal sources typically provide some sort of trigger-out function that can be used to synchronize an acquisition device such as an oscilloscope or digitizer. A hardwire trigger can achieve low latency and jitter but is relatively inflexible and not directly accessible to the system programmer.

LXI Class A instruments provide an eight-wide hardwire trigger bus between instruments. This trigger bus achieves the low latency and jitter of conventional hardwired triggers but with greater flexibility. The LXI specification requires that each Class A instrument be configurable so the system integrator can programmatically specify the assignments of the eight triggers to functions in the instruments at run time.

Peer-to-Peer Messages
Class A and B instruments introduce the concept of peer-to-peer messaging to test and measurement systems. In a sense, this is a generalization of hardwire triggers that provides a communications channel between instruments separate from the controller. However, unlike a hardwire trigger, the peer-to-peer messages, which are part of the LAN communications interface, have a much richer structure and can be used to implement more complex interactions. The structure of an LXI peer-to-peer message is illustrated in Figure 2.

Figure 2. Peer-to-Peer Message Structure

LXI peer-to-peer messages can be broadcast over a network. Since more than one test system can exist on a network, there must be a way to prevent the messages broadcast by one system from interfering with the other. The Domain byte can accomplish this. If the instruments in the two test systems are assigned to different domains, each system will ignore any messages received from the other.

The key fields used in structuring a system program are the following:
• Domain: This is a scoping field that allows the system integrator to restrict messages to certain classes of devices or applications.
• Event ID: This identifies the semantics of the message. These messages are intended for communicating a specific event much like the hardwire trigger. The Event ID allows events to be given names significant to the application.
• Timestamp and Epoch: Together these fields normally are used to specify the time at which the event signified by Event ID occurred or is scheduled to occur. These timestamps are useful only in the presence of the system-wide time scale produced by IEEE 1588.
• Data: This field may be used to convey supplemental information about the event.

The peer-to-peer messages typically are used with a publish-subscribe communications model to implement loosely coupled systems. In this model, a device or devices detecting a system-significant event publish a peer-to-peer message with the appropriate Event ID and timestamp.

Devices required to take action as a result of this event subscribe to peer-to-peer messages with the same Event ID. This clean separation of event detection and the actions that result allows easy system modification during debugging or as requirements change. For example, additional instruments may be added to a system that must react to a given event. These new instruments need only to subscribe to the event to implement the new actions; the publishers are not involved in the change.

Class A and B instruments are permitted to accept application-specific as opposed to instrument-specific code or configuration. Along with peer-to-peer messaging, this feature enables system integrators to create truly distributed applications. Properly implemented, a distributed solution:
• Enables true parallel execution of functions.
• Allows the separation of functions such as control and sequencing from data organization and computation.
• Increases visibility into system performance via the use of event logs, which are resident in each LXI device. Since each device maintains a timestamped log file, debugging applications is much less disruptive when compared to a centralized system configuration where monitoring of LAN traffic would be required to adequately analyze an application.
• Allows easier modification, extension, and maintenance of applications as a result of the partitioning.
• Lowers latency and LAN traffic in cases where the controller' s function is just to forward information or the result of a computation from one instrument to another.

Achieving these benefits will require more capable instrumentation, the evolution of supporting tool sets for system integrators, and a shift in the design architectures used by system integrators.

While the peer-to-peer messages currently defined in the LXI specification are designed primarily for event communications, they also may convey data. However, these messages are intended to contain relatively small amounts of data. For large amounts of data, more specialized peer messaging structures must be specified.

In LXI systems, peer-to-peer messages can be broadcast across the network using user datagram protocol (UDP) multicasting or transmitted point-to-point using transmission control protocol (TCP) connections. UDP broadcasts enable one-to-many communications and have less network latency than TCP. TCP connections are required for large distances and complex networks because network routers typically are configured to block the passage of multicast UDP packets.

Time-Based Programming
Class A and B instruments implement the IEEE 1588 precision timing protocol (PTP) to establish a system-wide time base. This is illustrated in Figure 1, which shows clocks resident in each of the instruments and the controller. The presence of these synchronized clocks in devices provides the following test-system features:
• Timestamping data and events at the source.
• Separating the functions of collecting and aligning data from multiple instruments.
• Scheduling events based on time rather than on the receipt of a message.
• Fully specifying the events in peer-to-peer messages.

Timestamping
Timestamping of data and events at the source based on the IEEE 1588 local clock allows instruments to return a timestamp with the collected data or the event; for example, the time at which an RF spectrum was measured or the time at which a signal from the DUT was received. Timestamps generated elsewhere in the system, such as at the controller, will be in error by the latency in the communications path between the source of the measurement and the controller generating the timestamp.

This latency includes the operating system, protocol stack, and network latency and jitter. Timestamps generated at the source are orders of magnitude more accurate and precise than timestamps initiated upon receipt of a message. Source-generated timestamps provide a mechanism for reliably associating data and events from multiple sources.

Separating Functions
Separating the function of collecting and aligning data from multiple sources is enabled in an LXI Class B system by source-generated timestamps. In current centralized controller-based systems, data acquisition and alignment from multiple instruments normally are achieved with polling loops or other techniques that allow unambiguous alignment of the data.

With LXI Class B, rather than requiring a controller to associate data sampled at the same time in multiple instruments, this data can be delivered directly to the consuming function, such as a database or correlation routine. The receiving function can make the association based on the timestamps. Properly done, this simplifies the system-level code. It also permits additional functions using the data to be added to the system without changing the basic acquisition code.

Scheduling
Scheduling of events based on time is a new feature enabled by the synchronized clocks in an LXI Class B system. In current systems and Class C systems, coordination between events in separate devices only can be accomplished by sending and acting on a message, either a LAN message or a hardwired trigger signal. In a system with Class B instruments, it is possible to provide a time schedule of events to each instrument that will be executed based on the local IEEE 1588 clock.

Once the devices are given the schedule, no further messages are required. Using this mechanism, it is simple to support complex timing behavior; for example, different sampling rates in different instruments, nonperiodic events, time offsets between samples in different instruments, and similar functions that would be quite difficult using commands from a central controller. The only requirement is that a device must be given the timing specification before the time the action occurs; that is, causality cannot be violated.

Specifying
The presence of the IEEE 1588 clocks also allows accurate timestamping of events. These timestamps should be used in constructing the peer-to-peer messages of Figure 2.

Peer-to-Peer Messages Revisited
The combination of peer-to-peer messaging and IEEE 1588 clocks provides system integrators with the ability to construct complex and precisely timed test sequences not practical with current technology. The key new feature is the ability to specify an event by name and associate it with an accurate timestamp.

At the source of an event, the event timestamp is generated in hardware or software depending on the accuracy required. The assembly of the peer-to-peer message incorporates this timestamp but can occur in a non-time-critical environment without degrading the information quality of the message.

Similarly, at the receiver(s), the timing of actions for a given named event can be based on the timestamp and implemented in hardware or software depending on the accuracy requirements. The parsing of the event name to determine the action can be done in a non-time-critical environment. By contrast, without timestamps the only recourse is to act based on the time that the message is received.

For example, consider extending the normal function of a digitizer or scope so the samples captured and stored in a circular buffer are associated with timestamps derived from the IEEE 1588 clock. Upon receipt of a peer-to-peer message, the correct data can be retrieved from the buffer based on the value of the timestamps. The design trade-off is among message latency, timing precision, and memory depth of the device.

Trade-Offs
In general, the difference between hardware-based triggering on the LXI trigger bus and time-based triggering using the IEEE 1588 time base revolves around the different inaccuracies that can be encountered. Hardware-based triggering is subject to a fixed latency, which sometimes can become large enough to require some type of calibration or other special effort to eliminate its effects on the measurement.

Time-based triggering is subject to jitter, which is not a fixed quantity nor dependent on the length or electrical characteristics of trigger cables. The amount of jitter depends on a number of factors, but in some cases, the jitter encountered with time-based triggers will be less problematic than the latency of hardware-based triggers.

Usually, the performance of any type of trigger will be adequate. The difference only will be apparent in the most demanding timing-critical applications. The correct choice, as always, depends on the application.

Recipients of peer-to-peer messages also can be provided with timing specifications based on the occurrence time of a named event where the time is defined in the future. The actual time of this event, for example the time to start the execution of a sequence of tests, can be delivered via a peer-to-peer message. Again the timing is determined by the timestamps, allowing the delivery mechanism for the message to be less time critical.

The Class A hardwire trigger bus provides analogous but fewer features because the name space of events is constrained to eight and the number of trigger lines and the timing typically is limited to an act upon receipt of event. In principle, the timing of actions by the recipient could be made programmable relative to the hardwire trigger. However, unless the timing corrections were based on the IEEE 1588 time base, inaccuracies between instruments would occur due to the different definitions of the second in each instrument.

In practice, system integrators will select the event-signaling mechanisms appropriate to a given application. Peer-to-peer messaging based on timestamps will be used when the latency involved in a LAN message is manageable. When low latency is required and distances are not too long, a hardwire trigger or a local time-based trigger can be used. In complex systems, the simplest solution often will involve both.

Selecting a hardwire trigger does not automatically guarantee that system timing will be better than timing based on a timestamp in a peer-to-peer message. In a large multirack test system, trigger-line lengths may vary from a few feet to perhaps 20 feet, resulting in timing skew that must be calibrated. In the future, IEEE 1588 timing to a nanosecond or better will provide an interesting trade-off to hardwire triggers in such systems.

Examples
Simple examples illustrate the key points of the previous sections.

Example 1: Stimulus-Response With Frequency Scan Settling Requirements
Consider a measurement system with the following requirements:
• A source supplying a test signal to the DUT is to be stepped over a range of frequencies.
• A receiver is to step its center frequency to correspond to that of the source and measure the output of the DUT at each frequency.
• Several other instruments measure supplementary information at each interval.
• The dwell time at each frequency must allow for both the source and receiver to settle within some tolerance before any of the measurements at a frequency are deemed valid.

This can be done from a Class C-style controller by having the controller poll or wait for an SRQ from both the source and receiver indicating that they have settled before commanding all devices to make their measurements. The controller then would retrieve the data from each instrument before commanding the source and receiver to step to the next frequency. While this is a perfectly good technique for such a simple measurement, this example also can be used to consider the alternate techniques that LXI Class B instruments make available.

A Class B implementation using peer-to-peer messages but not utilizing timestamps would distribute the settling function from the controller to each instrument. In this model, both the source and receiver send a peer-to-peer message when they have settled to the required tolerance.

Having received both peer messages, all devices make the required measurements and then publish a data-collected event. The controller waits until it has received both settling messages and the data-collected events and then retrieves the data from the measurement devices before initiating the next measurement step.

If Class B timestamps are used, there are a couple of interesting possibilities. First, suppose that the measuring devices have circular data capture buffers. In this case, each measuring device measures and fills its buffer with timestamped data. Upon receipt of both peer messages containing the times at which the devices settled, the measuring devices retrieve the data corresponding to the latest timestamp and forward the relevant data to the designated receiver.

The frequency stepping can be specified to occur at a designated time after the settling time to allow the measurements to be made and delivered. Such an implementation improves the throughput by eliminating the peer message delay before taking the measurements.

If the settling times are predictable, then a further refinement is possible. Suppose that for each frequency step the source and receiver settling times are known to a good but not perfect approximation. In this case, each device can be given a schedule of when to shift frequency, when to make a measurement, and when to send the measurement to the recipient. The schedule could allow for the worst-case timing.

If a more aggressive approach is warranted, the schedule would include provision for a repeat of all measurements at a given frequency step based on a peer-to-peer message containing the actual settling time. In other words, the system is programmed on what to do to recover in the event of a relatively rare departure from the predicted model.

In this model, once the system is configured, there are no communications between instruments except for reporting of data unless one of the settling times extends beyond the prediction, in which case the repeat-measurements peer-to-peer message is sent. Except in the repeat case, the total test time is reduced by at least the processing and delivery latency of the two settling messages required in other solutions.

There are some side benefits to the use of time-based programming. For example, by observing LAN traffic, it is relatively easy to see which device is at fault when things are not working correctly. Likewise, the scheduling of data delivery to a recipient can preclude communications or computation overload. This, in turn, allows simpler data transport mechanisms to be used without risk of data loss and permits bandwidth savings.

For example, UDP, or at most UDP with simple error correction encoding, can be used instead of the far more heavyweight TCP since the possibility of queue overflow has been eliminated by scheduled transmissions. This technique is widely used in industrial automation.

Example 2: Distributing Application-Specific Computations to Instruments to Minimize LAN Traffic
Consider a sequence of tests in which the decision on which branch to take depends on a computation involving the measured quantities. Suppose the system consists of instruments A, B, and C and a controller. During test step 1, instrument A monitors the DUT for some event. When this event is detected, A sends a hardwire trigger to B, C, and the controller. B and C then measure variables VB and VC, respectively. If VB = VC, then the next test step is 2; otherwise, the next step is 3.

In a centralized Class C implementation, the controller first configures and arms B and C instruments for test step 1. It configures and starts instrument A. It then waits for an SRQ from B and C, indicating that they had data as a result of receiving a hardwired trigger and making a measurement.

The controller then retrieves the data, makes the necessary comparison, decides which branch of the test tree to take, and issues new configuration commands to all instruments for either step 2 or 3 as appropriate. The command sequence is shown in Table 1.

Table 1. Command Sequences for Example 2 in Class C Implementation

The LAN message transactions for this model are shown in Figure 3. The index numbers in Table 1 correspond to the events shown on the timeline in Figure 3. In Figure 3, the solid line indicates a message passed between devices, either as a unicast such as message 1 or multicast shown as message 5. The dotted lines indicate events that occur internal to a single device (event 6) or in all devices (event 12).

Figure 3. LAN Traffic for Example 2

In a Class B implementation, the controller first configures all instruments with scripts outlining the responses to peer-to-peer messages and hardwire triggers. The portion of the scripts relevant to step 1 and the transition to step 2 or 3 for each of the devices are shown in Table 2.

Table 2. Scripts for Example 2 Using Class B Implementation Techniques

The LAN message transactions for this model are shown in Figure 3. Once the hardwire trigger, signal 4, occurs, the only network traffic is the publishing of the measured data VB in message 6 and VC in message 8. The remainder of the application is executed without further message passing with each device performing exactly the same computation, operating on the same data, reaching the same conclusion, and executing test step 2 as the next step.

Example 2 illustrates how judicious use of peer-to-peer messages, especially with timestamps, can be used to reduce LAN traffic to optimize system performance. At the same time, the partitioning of the application, basing most interactions on time, and observing the LAN traffic allow considerable nonintrusive visibility into system operation. The partitioning, the use of time, and LAN visibility along with per-device logging of significant events simplify system debugging and maintenance by isolating faulty logic and timing performance to individual modules.

Example 3. Environment Simulation During Test
In some test applications, the test equipment must simulate the expected operating environment of the DUT during the execution of a test. For example, when testing the performance of an amplifier, it might be necessary to mimic the operating environment by varying power supply voltage, cooling airflow, ambient RFI, or other variables.

In many cases, the control of the environment and the actual test are essentially independent applications. In this case, a standard Class C implementation, either with separate controllers or perhaps separate processes or threads in a single controller, would work as long as LAN traffic is sufficiently low to preclude timing or data transmission difficulties. However, if the environment and test control become less independent, these solutions are more difficult.

For example, if the environment is required to vary depending on some measured test variable, and especially if the timing of changes differ in the two applications, then the normal techniques for coordinating or synchronizing the applications can lead to missed deadlines, deadlock, livelock, and similar difficulties.³

The use of a completely distributed Class B implementation for both the environment control and the measurement reduces the complexity in any individual device. For example, even if the environment and measurement applications were managed by separate controllers, each still would be responsible for managing several instruments. Any message between applications always would be received in the context of code managing multiple instruments.

However, if the applications themselves are appropriately distributed, then these messages are received in the context of a single instrument. Handling a message in the context of a single instrument control structure should be simpler and definitely more visible than in the multi-instrument context.

Additional examples from test and measurement and other fields of the Class B mechanisms discussed here may be found in Reference 4.

Class A and B Instrument Architecture
The introductions of the Class A hardwire trigger bus and the Class B peer-to-peer messages, IEEE 1588, configurability, and downloaded code require additions to traditional instrument architectures. A very general functional block diagram of Class A and B instruments is shown in Figure 4.

Figure 4. Architecture of a Class A and B Instrument

The alternatives available to system integrators are much richer than in traditional systems that fundamentally provide only a driver interface and perhaps a single channel of hardwire trigger. In Class A and B, there not only is a wider variety of execution mechanisms, but also considerable flexibility in connecting these mechanisms to the underlying measurement functions of the instrument.

LXI Programming Interface
Although a casual glance may make LXI timing and peer-to-peer capabilities seem like complicated subjects, the programming interface to these features has a consistent and unified structure. Simple names are given to different functions, and the programmer can switch between triggering modes by simply changing a name.

For instance, an instrument can be programmed to respond to a LAN message by specifying the string ' LAN0' as a parameter in certain API calls. If the programmer later decides to use a hardware trigger, the string ' LXI0' can be used in place of ' LAN0' . All of the rest of the source code would be unchanged.

Conclusions
We have presented some key features associated with LXI Class B instruments. We also have provided examples illustrating how these features can be applied. Some will be quite satisfactorily implemented using only Class C instrumentation. Other applications, particularly those with complex timing or interaction requirements, will benefit from the use of Class B instrumentation.

References
1. LXI Specification, Revision 1.0, Sept. 23, 2005.
2. IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, IEEE 1588-2002, Nov. 8, 2002.
3. Lee, E.A., The Problem With Threads, IEEE Computer, May 2006, pp. 33-42.
4. Eidson, J.C., Measurement, Control, and Communication Using IEEE 1588, 2006.

About the Authors
John C. Eidson, Ph.D., received a B.S. and an M.S. from Michigan State University and a Ph.D. from Stanford University, all in electrical engineering. He held a postdoctoral position at Stanford for two years, spent six years with the Central Research Laboratory of Varian Associates, and joined the Central Research Laboratories of Hewlett-Packard in 1972. When HP split in 1999, he transferred to the Central Research Laboratory of Agilent Technologies. Dr. Eidson was heavily involved in IEEE 1451.2 and IEEE 1451.1 and is the chairperson of the IEEE 1588 standards committee and a life fellow of the IEEE. e-mail: john_eidson@agilent.com

Dan Pleasant holds a B.S.E.E. from the University of Colorado and an M.S.E.E from Stanford University. After a seven-year stint at MIT Lincoln Laboratory, Mr. Pleasant joined the CAE group (now known as Agilent EEsof) at HP in 1989. He has been a member of the DoD ATML Working Group and the LXI Consortium where he is the co-chair of the Timing and Synchronization Subcommittee. e-mail: dan_pleasant@agilent.com.

Agilent Technologies, 395 Page Mill Rd., Palo Alto, CA 94306, 800-829-4444.


 

PDF of this article

Back to Top

Driving LXI Devices

By Simon Appleby, Pickering Interfaces

Anyone who has learned to drive a car knows how to step into an unfamiliar vehicle and within a few moments make it move. It doesn' t matter that the particular vehicle he or she learned to drive was from a different manufacturer. Once you have learned the concept of driving, adapting to a new car is a simple process.

Compare this scenario with one in which a user needs to set up a DSL or cable modem. You open the box and are presented with a device that can be configured in a number of ways. And if you have to set up a modem with which you are not familiar, the installation process will almost certainly be different. All modems just don' t drive the same.

Not so with LXI devices. Many different manufacturers now produce LXI-based devices that perform a whole range of test and measurement functions. Some are simple devices; others are much more sophisticated, providing complex functionality or even the functionality of several instruments under the control of one interface.

To unify the configuration method for these different types of equipment means putting all of the basic controls in the same place. The LXI standard requires that a common user interface be available as part of the device' s overall functionality.

The user interface is the way in which a user communicates with an LXI device for configuration purposes. The LXI specification, however, is not a set of strict guidelines designed to limit the way in which a manufacturer implements the user interface.

There is considerable flexibility in the specification that allows for unique implementations. For example, a user interface can be implemented that satisfies a specific corporate design or color scheme.

The specification also does not deal with particular instances of control associated with how a manufacturer implements its web pages. For instance, some devices, such as an LXI-controlled switch, would not require the same levels of control as an LXI-controlled spectrum analyzer.

The specification is designed to provide a common interface that supports configuring an LXI device for network connectivity. The functionality of the device also may be controlled via the web pages, but it is not a requirement. Indeed, a complex instrument may not have any configuration options other than networking setup functionality. Such is the flexibility of the specification.

What Does This Mean for the End User?
Only a short time ago, when a new test system was constructed, the options for connecting stand-alone test equipment together were limited. GPIB and RS-232 were the only realistic technologies for many users, and configuring these interfaces was fairly simple. You set some switches or jumpers on the back of the device and plugged your cables into the device. It was a physical means of setting a device' s identity that could be easily checked by simply observing the device' s configuration switches.

Over time, manufacturers moved away from this simple approach. Some used a front-panel control to set the GPIB address, and others relied on RS-232 interfaces or proprietary connectors to set the device up via terminal software. Pretty soon, every manufacturer was doing its own implementation with no common way of assigning addresses.

The problem could become worse with older equipment that may not have been used in some time. How do you reset the device back to its default configuration? The users who integrated the system may have left the company or retired, the original manufacturer may no longer be in business, or the manuals may be unavailable or lost.

The use of laptop computers for configuring equipment also is important for the field engineer and adds a different problem. These machines are less likely to include RS-232 ports or have the capability to control GPIB equipment without requiring additional adapters or converters.

LXI does away with all of these concerns. The ease with which you can reconfigure your equipment in a standard way is obvious. If you can set up one LXI device, you can set up any LXI device.

The advantages for integrators are many. With minimal training, you can quickly connect equipment in ways not previously possible with other test system architectures. If a piece of equipment is configured incorrectly, you can reset the device back to its default state, which is the same for all instruments as long as you have physical access to it.

Special cables and hardware are not required; LXI uses the same routers and CAT 5 cables that connect your computers to a network. You are not limited to the short cable runs associated with GPIB devices or the complexity of null modem cables associated with RS-232 devices. Any of the networking equipment you pick up at a local computer store can be used in your test-system setup.

Using the Device' s Web Interface
The LXI device' s Web interface is designed in a logical manner so you will find it intuitive to use, making device configurations easy. There are no cryptic menu items to decipher. Once you are familiar with the basic configuration of one LXI device, configuring those from other manufacturers becomes an almost trivial exercise.

When you first configure your LXI device, there are a number of ways in which you can communicate with it. As a minimum, you will require a computer with a web browser. The Internet is ubiquitous now, and even if a computer does not have a direct Internet connection, it is likely to have some sort of web browser installed by default.

The LXI specification requires that all web pages adhere to established browser standards. It does not even matter what type of web browser you use because the pages will display in a logical way. And if you know how to browse the Internet, you are going to know how to navigate the LXI configuration screens. By using established concepts and embracing existing standards, you now can configure your device using a browser and networking technology. Figure 1 shows a typical LXI device home page.

Figure 1. LXI Device Home Page

Once you have a web browser and your LXI device is connected to your network, how do you know what LAN address to use? If you have a server that issues addresses automatically via the dynamic host configuration protocol (DHCP), you can check its log, compare the medium access control (MAC) address printed on your LXI device to that in your server' s DHCP log, and discover the device' s address in this way.

This MAC address is unique to every piece of network-enabled equipment in the world. Examine any network card or enabled device and you will find this hexadecimal number clearly printed on it. The LXI specification mandates that this MAC address be clearly visible on all devices to aid users in troubleshooting and configuration.

Alternatively, you can use the VXI-11 discovery protocol, which is part of the LXI specification. This is the real-world equivalent to looking for an item in a darkened room with a flashlight. However, as VXI-11 is part of the LXI standard, all devices will support it.

You can use some of the many available software tools that support this protocol to list all LXI devices found on a network. VXI-11, however, has some limitations. It cannot discover multiple devices behind a single IP address as would be the case with hybrid LXI devices. VXI-11 does not work through firewalls or across subnets easily, and it requires the use of large software libraries, which can be problematic when they are incorporated as part of an LXI device' s embedded controller.

The LXI Consortium is addressing these issues in Version 2.0 of the specification, and additional discovery protocols will be based on industry standards already deployed within the greater computer industry. These protocols include universal plug & play, web services, or the ZeroConf family of protocols.

There are several open-source implementations of the ZeroConf protocol, of which perhaps Apple' s Bonjour version is the most well known. Bonjour clients are included with Apple' s OS X operating system and installed in many networked devices such as printers and scanners.

Additional work also is being completed on a schema that can be downloaded from an LXI device. This will give much more detailed configuration information about an instrument' s capabilities than the VXI-11 protocol or other discovery methods can provide today. In addition, the use of a schema will embrace the new requirements of hybrid- and adapter-based LXI devices that may contain much more advanced functionality than what is provided in a single instrument.

Once you have discovered your LXI device' s address, you simply type it into your web browser' s address bar. On the first page, the user will see the device' s home page which describes the information you will need to communicate with the device. It lists the IP addresses the device is using and its LXI class, description, serial number, manufacturer' s website, and VXI-11 resource string. Manufacturers also can place additional information specific to their device here, but you always know that this page will display the same basic information regardless of manufacturer.

This page, being standards compliant, will display on any web browser. And because the web page is platform agnostic, the browser could be on a Microsoft Windows-, Apple OS X-, or a Linux-based computer. Some browser platforms such as cell phones or hand-held devices also might work as long as they are standards compliant.

The use of standards is of vital importance for both present and future LXI products. By using the hypertext transfer protocol (HTTP) standard hypertext markup language (HTML) code, you are not restricting an instrument access to a particular brand of web browser. Secondly, the use of web standards means that web browsers on different platforms will display the page correctly.

Many years ago, the differences between the two major web browsers of the time, Netscape Navigator and Internet Explorer, meant that web designers had to use browser detection routines to send the correct HTML for the page to render correctly. This became even more complex when these browsers were ported to different operating systems where the problem became much more pronounced.

The use of web standards makes the need for this difficult and tedious process much less likely. Even today, however, differences can occur which means web designers still must test their pages to ensure compliance and operation on a number of different platforms. Tools exist for this purpose and are freely available from organizations such as the World Wide Web Consortium.

The process of building web pages also is made much easier for a manufacturer by being standards based. A manufacturer designing the pages can use standard HTML editing tools or a web design package such as Dreamweaver or Homesite. These types of packages have a number of options that can generate standards-compliant output. Figure 2 depicts the use of web standard tools that are used to generate web pages.

Figure 2. Web Page Generated by Dreamweaver Software Application

The use of web pages for network configuration also is a logical choice. Many people configure network devices by using web pages, and it gives the manufacturer a way of presenting configuration options in a clear and concise graphical manner.

A web page is inherently simpler to understand than a command prompt. A manufacturer can restrict setup options, for instance, by using a pull-down menu with the selections based on a user' s previous configuration setting.

Guiding you through a logical configuration is preferable to presenting cryptic error messages via a command line interface. Graphical cues also make the options clearer, which can be useful for persons whose primary language may not be that of the device manufacturer.

An example of graphical control of an LXI device is given in Figure 3. Here a Java applet is loaded into the user' s browser from the device, in this case a video switch matrix. The user can close or open sets of virtual contacts within the Java applet simply by clicking on the icon representing a crosspoint.

Figure 3. Typical Graphical Control Panel

This type of interface is simple for a novice to use and provides a visual representation of the user' s actions by using color to reflect the switch states. These types of graphical cues supply instant feedback that is obvious and much more intuitive than using a command-line implementation.

The use of standard form elements such as those found on any website also gives you a familiar way to interact with the device. Most users will have seen or used these elements on websites when they fill out a questionnaire or submit information as part of an online registration process or auction service. The use of familiar user interface controls and methods provides a much quicker learning curve for LXI users than would be the case if a command line configuration method were used.

An example of this scheme is the way you can configure how an LXI device obtains its TCP/IP address. Support for this functionality is mandated by the specification and again presents a common format and layout. When you follow these links, the information required to change whether the device uses DHCP, a Dynamic/Auto IP, or a static address is displayed in a format you can easily identify and change.

An advanced address configuration link also allows you to control other aspects of the device' s networking if they are supported. The use of radio buttons and pull-down menus means that there is no uncertainty in a user' s selection, and the web pages can be constructed to make it almost impossible to select the wrong option or an invalid configuration. Figure 4 shows an example of a network configuration web page.

Figure 4. Network Configuration Web Page

If the device' s LXI class supports synchronization, a link also is provided to a page that allows you to configure this in a uniform way. Once again, this minimizes having to learn a new way of doing things for each manufacturer' s product, speeding up system integration and simplifying support and maintenance.

Conclusion
The LXI standard makes things simple and predictable for users. By using web-based control methodology and standardized web design, many of the problems and nonstandard control methods associated with earlier instrumentation standards are eliminated.

LXI instruments allow you to configure equipment in a way that is comfortable and familiar from previous exposure to the Internet and consistent with many other areas of the computer industry. Additionally, the use of industry standards reduces the need for specialists and unusual or proprietary configuration equipment. Today' s LXI-based instrumentation allows a system to be configured quickly and easily using off-the-shelf components available from any computer store.

About the Author
Simon Appleby is the embedded systems manager at Pickering Interfaces. He started his career at GEC-Marconi before moving into consulting and management positions within the e

lectronics and computer industry. Mr. Appleby has worked at Pickering Interfaces for six years and is a member of the LXI Consortium' s LAN and Web Working Group. Pickering Interfaces, Stephenson Rd., Clacton-on-Sea, Essex, CO15 4NL U.K., +44 1255-687900, e-mail: simon.appleby@pickeringtest.com

For More Information
on Web-based specifications,
guidelines, software, and tools
www.rsleads.com/616ee-176

PDF of this article

Back to Top

Making the Transition From GPIB to LXI

By Mike Dewey, Editor

For more than 30 years, automating test and measurement instrumentation has relied upon the ubiquitous GPIB standard. Developed by Hewlett-Packard in the early 1970s, the HP-IB evolved to become a de facto industry standard.

With its adoption by the IEEE in 1987 as IEEE 488, HP-IB became the standard instrument control bus for the test and measurement industry. Today, there are literally thousands of different instruments that support the IEEE 488 or GPIB interface.

There are several reasons for the longevity and universal acceptance of GPIB within the test and measurement industry. A simple and well-defined method for physically connecting a GPIB device to a system controller and an industry-accepted set of software commands for communicating with GPIB devices are two primary reasons.

LXI is based on these same concepts and uses current technology such as TCP/IP for connectivity, IVI for software interfaces, and Web-based communications for instrument setup and control. It also leverages IEEE 1588 LAN triggering facilities for Class B devices and offers a more robust hardware triggering facility with Class A devices.

As a result, setting up and controlling an LXI instrument are remarkably similar to how you would set up and control a GPIB instrument. There is one exception: An LXI instrument can offer extended functionality beyond those features found in a GPIB device.

Connectivity
Both GPIB and LXI instruments require a hardwired connection between the device and the system controller. In the case of GPIB, a relatively large and somewhat expensive shielded 24-conductor cable is used to connect a GPIB device(s) to the system controller.

The connectors support the stacking of cables which allows up to 15 devices to be part of a GPIB network with the connection topology being a linear, star, or linear/star configuration. The IEEE 488 bus specification accommodates a maximum cable length of 20 meters with a maximum separation of 2 meters between devices. The maximum data transfer rate for the IEEE 488 bus is 1 MB/s.

GPIB interface cards are available from several vendors and typically installed in a system controller' s PCI slot. Alternately, cards are available that can be controlled via USB, Firewire, cPCI, or even a LAN host interface. The interface cards include a driver, which provides the necessary functionality to control and monitor GPIB devices per IEEE 488.2.

For LXI devices, the control interface is provided by a LAN connection: typically, a 10 or 100Base-T Ethernet physical interface although the LXI spec supports Gigabit Ethernet interfaces as well. Unlike GPIB, LXI devices use unshielded and inexpensive twisted-pair cabling with RJ45 modular connectors to connect a device and controller.

This cabling, which bears the designation of Category 5, is widely used for interconnecting various network devices and supports 10 and 100Base-T with Cat 5e cable recommended for 1000Base-T electrical interfaces. The maximum cable length for any segment of a LAN is 100 meters with 10/100Base-T hubs extending this distance to approximately 1,600 meters. With routers, switches, bridges, and repeaters, a LAN segment can essentially have unlimited length, a clear advantage over a GPIB network topology.

Since LXI devices leverage LAN as the control interface, they also use the same networking components that are required for configuring data networks. LXI and LAN devices utilize point-to-point connections.

Connecting more than one LXI device to a controller will require hardware to interconnect devices to a LAN network, unlike a GPIB network of devices where you can just daisy-chain devices with no additional hardware. Depending on the specific requirements of the network, LXI devices can be interconnected using a hub, router, or switch, which are common and generally inexpensive networking components.

Networking Basics for LXI Devices
To assemble a network for controlling LXI devices, a network adapter providing the electrical connection between the controller or PC and the network is required. Like GPIB, these network adapter PC cards interface to a variety of buses such as PCI and cPCI.

Most PCs today incorporate a LAN connection as a standard interface port. Virtually all LAN adapters support both 10 and 100Base-T interfaces and automatically adapt to be compatible with the speed of other devices connected to the network. For LXI devices, 1000Base-T also will support 100 and 10Base-T interfaces, and 100Base-T devices will support the 10Base-T interface.

If connecting only a single LXI device to a PC' s LAN port, all that is needed is a LAN cable that crosses the Tx and Rx paths. If the LXI device supports the automatic medium dependent interface crossover (Auto-MDIX) function, then a normal LAN cable can be used since the device will automatically interchange the Tx and Rx ports.

LXI devices that accommodate the Auto-MDIX function must display a label on the unit indicating this capability. All 1000Base-T interfaces support Auto-MDIX.

When connecting more than one LXI device to a network, a network hub can be an inexpensive implementation. A hub is a small, stand-alone unit that connects multiple devices together, usually in a star topology. In this configuration, any device can discover and talk to any other device on the LAN although only one device can successfully transmit at any one time. Consequently, if network traffic is heavy, the effective bandwidth of the network will be reduced.

Four-port hubs are available for $30 or less and offer the most cost-effective means to interconnect multiple LXI devices. Hubs are available in 10, 10/100, or 100Base-T versions.

Unlike USB hubs, LAN hubs require an external power source, normally an AC-to-DC power adapter powered by 120/240 VAC. The same holds true for switches or routers.

Network switches also can be used to interconnect LXI devices. These physically small devices, classified as layer-2 devices, create a dedicated switch path based on an Ethernet device' s transmit and receive medium access control (MAC) addresses.

Switches typically provide better network performance than hubs since they maintain bandwidth regardless of network traffic loads. Today, four-port 10/100Base-T switches can be purchased for less than $50, making them an attractive alternative to hubs when interconnecting multiple LXI devices within a simple network.

Network routers can interconnect LAN devices as well as isolate multiple networks by supporting high-level protocols such as TCP/IP. Routers allow one- and two-way communications between devices and enable awareness among the devices on a network. They also allow devices to hide their presence, enabling the creation of small, private networks.

Routers typically include the capability to dynamically assign IP addresses and domain names to devices connected to the network. Depending on the number of ports needed, routers are more expensive than switches although the capability to create a subnet of LXI devices that can be connected or isolated from other subnets could be a desirable feature. Routers also can incorporate LAN switch functions; a DSL router with multiple LAN ports is an example of a router/switch device.

Creating a subnet or private network for all LXI devices that are part of a test system, particularly if all devices are physically collocated in a system, is strongly recommended and guarantees that device control will not be compromised by other non-test system LAN traffic. Additionally, a subnet protects against network viruses or worms by isolating the test system from the corporate intranet or Internet.

A properly configured router can create a subnet. Alternatively, dedicating a network card that interfaces to an LXI device network can be a viable option when combined with a switch or router. Figure 1a and 1b detail both topologies for creating a private subnet.

Figure 1a. Switch-Based Private Network

Figure 1b. Router-Based Private Network

Setup
After making the physical connection between the GPIB device and the controller, communicating with a GPIB or LXI device requires setting the device' s address. For GPIB instruments, the device' s primary address needs to be programmed.

Early-generation devices relied on physical switches to set the address while today' s instruments allow you to set an address via the instrument' s front panel and store it in nonvolatile memory. Each GPIB instrument on a network is required to have a unique address, which is analogous to LXI devices where each device has a unique and fixed MAC address.

For GPIB devices, if two or more instruments are set to the same address, the bus will hang. There is very little you can do to debug the problem aside from methodically checking and testing each device to verify operation and address assignment. Assuming that each device on the bus has a unique address, the GPIB commands *IDN? and FINDLSTN offer some base level of functional verification by providing a status of which devices are active on the bus as well as identifying model and manufacturer.

A successful response to the *IDN? command usually is a good indication that each GPIB device is communicating properly with the controller and ready to receive/transmit data. LXI devices retain this same functionality and support the *IDN? command as well as the VXI-11 discovery protocol to identify all LXI devices on the network.

To set up or configure LXI devices, each device requires its own IP address that maps a device to its MAC address. Since all LXI devices are required to support TCP/IP, communications to a network device are via IP addresses that can be set statically or dynamically depending on the device' s capabilities and whether the network supports dynamic host configuration protocol (DHCP).

Configuration is performed after interconnecting all LXI and LAN network components and powering up all devices. Initial network configuration information and any subsequent modification of the device' s network configuration can be accessed via the instrument' s front panel or the device' s web page, a feature supported by all LXI devices.

Accessing the instrument' s home page requires entering the device' s IP address. If the device' s IP address has been dynamically assigned and the network supports DNS, you can enter the device' s default hostname, which will be specified in the manufacturer' s product manual. As shown in Figure 2, an LXI device' s web page provides the following network information and control options:
• Host Name
• MAC and TCP/IP Address
• VISA Resource String
• Configuration of the TCP/IP Mode: DHCP or static IP assignment; default will be DHCP if the device supports automatic IP assignment
• Configuration of the Static IP Configuration, Set Values for IP Address, Subnet Mask, and Default Gateway
• Configuration of the dynamic domain naming system (DNS) (if the device supports this mode) and specification of the DNS Server; default will be dynamic DNS enabled

Figure 2. Instrument Home Page

If a network uses a switch or router with DHCP capability such as shown in Figure 1, then using dynamic IP assignment will be the easiest way to configure each device on the network. However, for a test system with a relatively static instrument configuration, you may want to have the DHCP server provide infinite IP leases, which can be part of the DHCP server' s IP policy configuration.

It also is probably preferable to configure the DHCP servers to always return a particular IP address for a given client MAC address, essentially assigning a static address to each LXI device. Infinite lease times can make it harder to change network configurations, making short leases or static IP addresses a preferred implementation.

Issuing infinite leases or static IP addresses from the DHCP server ensures that every device located on the LAN will have the same IP address assignment each time the system is powered up even though IP addresses are normally retained by a device upon shutdown. This is critical if you are explicitly using VISA IP string names. Without having static IP addresses, VISA IP string names must be modified if an IP lease expires and a different IP address is assigned.

If a server also supports DNS capability and the LXI device does as well, then VISA string names can use the specific host name instead of an IP address value. This negates the need to maintain static IP addresses since instruments are referenced by name instead of an IP address. Alternatively, you can rely upon the VXI-11 discovery mechanism to locate devices and IP addresses.

If a system configuration is limited to a PC and a single LXI device or a hub or switch with only a few LXI devices with no DHCP capability, all devices can be configured with static IP addresses. As an example, static IP address assignment for a PC and two LXI devices would be assigned as follows:
Computer IP address: 192.168.1.50
Computer subnet mask: 255.255.255.0
LXI device1 IP address: 192.168.1.51
LXI device1 subnet mask: 255.255.255.0
LXI device2 IP address: 192.168.1.52
LXI device2 subnet mask: 255.255.255.0

IP addresses should only be assigned in the last field of the address, such as 192.168.1.x. And if a router were part of the configuration, its IP address in this example would be 192.168.1.1.

Assigning static IP addresses raises the possibility of duplicate addresses. However, unlike GPIB devices, LXI devices provide some level of diagnostics and protection should a duplicate IP address be encountered. If an LXI device detects a duplicate address, it disconnects itself from the network, and the LAN fault condition will be displayed as a steady red indicator on the instrument' s front panel.

For the case where a PC is directly connected to an LXI device with DHCP capability but the network has no DHCP server, the device, after failing to obtain an IP address, will configure itself using the Auto-IP protocol which will result in the device negotiating with the PC for an IP or Link Local address. Link Local addresses are assigned randomly from 169.254.1 to 169.254.254.255.

For some users, Auto-IP may be the preferred method to configure a simple network since it requires no administration and offers a simple way to establish communications with an LXI device with very little user intervention. Communications with the device cannot commence until you know its IP address, and due to the nature of the Auto-IP process, subsequent connections will likely result in a different IP address being assigned to the device. Consequently, the device should be reconfigured to a static IP address, or you can use the VXI-11 discovery mechanism to identify the device' s address, which then can be used to access the device via the VISA I/O library.

GPIB and LXI Device Control
Once you' ve connected and set up a GPIB or LXI device, you can control and program the instrument. Controlling or programming GPIB or LXI devices relies upon VISA, an industry standard software I/O component that makes the transition from a GPIB instrument to an LXI instrument very easy. In addition, many instruments now offer both GPIB and LAN interfaces and support the same set of SCPI commands, making the user' s task of migrating to LXI that much easier.

Regardless of the programming development environment that you may be using, VISA or I/O libraries built on VISA, such as Agilent' s IO Library or National Instrument' s NI-MAX, provide a consistent method for identifying and communicating with an instrument, regardless of the type of control bus.

VISA supports a broad range of buses including GPIB, TCP/IP, VXI, RS-232, and USB. To change instrument control from a GPIB- to an LXI-based interface requires changing only the VISA resource string.

For example, a GPIB instrument resource string might be ' ' GPIB::22::INSTR' ' which defines a GPIB instrument with an address of 22. For an LXI device, the instrument resource string would be TCPIP::10.0.41.6::INSTR or TCPIP::HOSTNAME::INSTR where the value 10.0.41.6 is the device' s IP address. Once these changes are made and the appropriate host address value inserted, the same test program code can be used where the instrument supports both GPIB and LAN interfaces.

An additional benefit associated with the use of VISA and instrument I/O libraries is the functionality provided by the VXI-11 discovery protocol, which all LXI devices support. The VXI-11 protocol in conjunction with I/O libraries provides the capability to identify all LXI devices that are located on a subnet via a discovery tool, which can be particularly useful when all devices are configured for dynamic IP address assignment.

By invoking the discovery mechanism, a device' s response will include information such as manufacturer, model number, serial number, and IP address. This information then can be used to access instrument web pages and populate resource tables for other applications and utilities.

All LXI devices are supplied with an IVI driver, and if appropriate, the instrument will be supplied with an IVI class driver. This feature can be a key benefit if you are considering transitioning from GPIB to LXI if the current instrument is in the same IVI class but a different device. Even without the benefits of instrument interchangeability, providing LXI devices with an IVI-COM or IVI-C driver will help ensure that existing GPIB software environments can be easily adapted and migrated to support LXI devices.

Summary
Migrating from GPIB to LXI instruments for test systems can offer many performance and cost benefits. Many of the features and capabilities associated with LXI devices are based on well-established technologies and standards that will help minimize the technical effort and risk associated with adapting current and new applications to LXI devices.

While you may need to spend some time getting comfortable with networking basics, in most cases, the design and default operation of LXI devices within a network minimize the need to become an expert. Once you make the transition and move up the learning curve, the benefits of LXI will be very clear, and you probably will wonder why you waited to make the move.

Additional Information
1. www.lxistandard.org
2. www.agilent.com
3. Dewey, M., ' ' Integrating LXI Devices Into Hybrid Test Systems,' ' LXI ConneXion, July 2006, pp. 18-24.

About the Author
Mike Dewey, the marketing product manager at Geotest-Marvin Test Systems, previously has held various positions in design engineering, engineering management, marketing, and product management with GenRad/Teradyne, ADR Ultrasound, and Motorola Government Electronics Group. He is a member of the IEEE and has served as a board member for both the PXI Systems Alliance and the VXI Consortium and been an LXI Consortium advisory member on the marketing, technical, and physical working group committees. Mr. Dewey received a B.S.M.E. from Syracuse University and an M.S.E.E. from Georgia Institute of Technology. e-mail: miked@geotestinc.com

PDF of this article

Back to Top

Time Scales and IEEE 1588
Part 1

By John C. Eidson, Ph.D., and Dan Pleasant, Agilent Technologies

 LXI Class B devices¹ introduce several new capabilities to test and measurement systems not easily achievable with current architectures:
• Peer-to-peer messaging.
• A wider variety of trigger models including LAN- and
time-based triggers.
• A system-wide time scale based on IEEE 1588.²
• Flexible, application-specific configuration of devices.
The use of system-wide time scales and IEEE 1588 probably are the least familiar to you but key differentiators of Class B devices.

Time has long been recognized as a key variable in test and measurement instrumentation and systems. For many measurement devices, time is one of the measured or controlled variables. Oscilloscopes, logic analyzers, frequency counters, spectrum analyzers, and signal sources all deal directly with time. However, these devices invariably treat time as an internal matter.

For system integrators trying to correlate measurements from two or more such devices in rack-and-stack environments, only two techniques are available with current architectures. If two devices must share a common time base, provision often is made for a device to provide a 10-MHz output based on its internal oscillator and accept a similar signal from other devices. These signals typically are distributed using BNC cables and enable consistent frequency-based readings to be made across multiple devices.

However, the absolute accuracy of the time base established in this way is no better than the typical 100-ppm accuracy of the primary oscillator. If multi-instrument measurement systems also require a precise time reference, the only mechanism currently available is hardwired triggering. Software-based techniques, such as the group execute trigger in IEEE 488-based systems, are not very precise due to limitations in controller protocol stacks and device message parsing.

Timing is even more problematic in data acquisition systems where the number of devices generally is quite large. The system integrator must either implement the time correlations between multiple sensor readings based on the time of request or receipt of the data at the controller or provide a separate time distribution scheme to permit timestamps to be generated at the source. In the latter case, time distribution protocols such as IRIG-B often are used.³

The LXI standard section 3.2 requires that all Class A and B devices establish a system-wide time scale based on IEEE 1588.

The Basics
IEEE 1588 enables the precise synchronization of real-time clocks in devices that are part of a distributed system. This synchronization is achieved by an exchange of timing messages between the clocks over the same network communications media used for other interdevice communications. All LXI implementations of IEEE 1588 use Ethernet as the communications network.

Properly implemented, IEEE 1588 establishes a system-wide self-consistent time scale among the participating device clocks. All clocks will have the same time origin or epoch.

IEEE 1588 implements a master-slave hierarchy of clocks. If the root clock in this hierarchy is synchronized to a standard coordinated universal time (UTC) source such as the GPS, then the IEEE 1588 time scale will be traceable to UTC. As will be seen, this is very easy to do.

Two principal sources of timing errors must be eliminated to provide precise synchronization of clocks. The first is timing errors introduced by instabilities and drift of the local oscillators, and the second is fluctuations in the latency of communications between the clocks. IEEE 1588 addresses the issue of latency fluctuations. Oscillator stability primarily is a component selection issue for implementers.

To see how IEEE 1588 synchronizes clocks, consider two clocks communicating over a communications link with one being the master and one the slave. The master and slave clocks exchange timing messages as illustrated in Figure 1.

Figure 1. IEEE 1588 Timing Messages

The Sync message is sent from the master to all slaves. As the message is being transmitted, a timestamp, t₁, is generated by the master as precisely as possible.

In practice, most implementations to date do this by snooping on the media independent interface (MII) within the Ethernet protocol stack as illustrated in Figure 2. The value of t₁ is communicated to all slaves as a data field in the Follow Up messages. When a slave receives the Sync message, it generates a receipt, timestamp t₂, as shown.
 

Figure 2. IEEE 1588 Block Diagram

Periodically, the process is reversed with each slave sending a Delay_Req message to the master. The Delay_Req messages are timestamped by the slave at transmission, t₃, and the master upon receipt, t₄. After the master returns t₄ in a Delay_Resp message, a slave has all four timestamps.

If you assume that the propagation time from master to slave and from slave to master is the same, then these four timestamps provide sufficient information for the slaves to compute both the mean propagation time and the offset between the two clocks. The slave uses these offsets as the input to a servo that brings the slave clock into alignment with the master clock.

Figure 2 shows block diagrams of a master and a slave clock. To obtain the highest accuracy, an implementation of IEEE 1588 consists of software, running in user space, and specialized hardware consisting of the oscillator, a counter forming the clock, and a packet detector.

The packet detector monitors the MII interface between the PHY and the MAC layers of the protocol stack for both Sync and Delay_Req messages. When one of these messages is detected, the packet detector takes a snapshot of the 1588 clock to create one of the timestamps.

Since network protocol stacks introduce considerable timing fluctuation, the use of this packet detector eliminates all but the PHY fluctuations, which are quite small. In the slave nodes, the four timestamps are used to adjust the rate and offset of the clock.

The other main source of timing fluctuations in an Ethernet system results from message queuing in switches. IEEE 1588 specifies a special type of switch, the boundary clock, which eliminates the queuing jitter. As illustrated in Figure 2, each boundary clock has a common IEEE 1588 hardware clock, and each port contains a packet detector similar to that in the master or slave clock.

The switch itself is configured to block IEEE 1588 timing messages so that, in effect, the clocks in the end devices synchronize directly with the clock in the boundary clock. A boundary clock not only eliminates the timing fluctuations that would otherwise be introduced by an ordinary switch, but it also allows clock synchronization to be independent of network traffic.

There are two types of IEEE 1588 clocks: ordinary and boundary. The protocol will automatically configure these into a tree-structured master-slave hierarchy of clocks with the ordinary clocks forming the leaf nodes and the boundary clocks forming the branch points of the tree.

As a result, in Figure 2, the IEEE 1588 clock in the boundary clock is synchronized to the ordinary clock labeled master. Likewise, the ordinary clock labeled slave is synchronized to the IEEE 1588 clock within the boundary clock.

The selection of which clocks are master and which are slave is based on clock characterization information contained in the Sync messages. Each clock executes an independent copy of an algorithm called the best master clock algorithm that compares the characterization information in the Sync messages to internal characterization information.

If the local clock is judged to be inferior to the clock described in the timing message, then the local clock will cease transmitting Sync messages and become a slave. If the local clock is judged to be superior, then it transmits Sync messages. The situation is slightly more complex in a boundary clock, but the result is that after a few Sync messages the master-slave hierarchy is established with the best clock in the system, the grandmaster clock, appearing at the root of the tree.

The best clock is determined by the best master clock algorithm, which is based on the following parameters:
• Preferred Status: Allows a system integrator to optionally designate a collection of devices from which the grandmaster clock will be selected.
• Stratum: Characterizes the source of time. For example, a clock linked to a GPS and UTC is judged better than a free-running clock.
• Identifier: Characterizes the accuracy of the clock. For example, a clock linked to UTC via a GPS is judged more accurate than a clock set to UTC by hand from a user interface.
• Variance: Characterizes the precision of the clock and is a measure of the fluctuations of this clock when compared to a perfect clock.
• Universally Unique Identifier (UUID): Serves as a tiebreaker.

IEEE 1588 currently is being revised, and version 2 is expected to be available in early 2007. New features and modifications in version 2 will greatly ease the implementation of high-accuracy clocks. Other features will enable the construction of fault-tolerant and secure systems that may be required in some critical applications.

Performance
Since the publication of the IEEE 1588 standard in November 2002, there have been numerous independent implementations. Some were pure software implementations with timestamps generated in interrupt service routines while others used the hardware packet detectors. Performance figures for synchronization between a master and a slave for various configurations of an Ethernet network are shown in Table 1.
 

Table 1. Clock Synchronization Jitter Except for row 1, all clocks use hardware packet detectors.

Pure software implementations depicted as configuration 1 in Table 1 are less precise due to the increased fluctuations introduced by the lower levels of the Ethernet protocol stack. However, if the required accuracy is in the low microsecond range and network traffic is well controlled, software implementations can be quite useful.

The effect of including a non-boundary clock switch in the synchronization path is evident in configurations 2 and 3. Network loading by ordinary commercial off-the-shelf (COTS) switches can severely degrade performance. However, under the controlled conditions illustrated by configuration 2, quite satisfactory performance can be achieved for many applications.

For synchronization, configurations 4 and 5 are better than ordinary switches due to the absence of queuing. Most test and measurement applications will make use of boundary clocks per configuration 6 to achieve good accuracy independent of network loading.

Configuration 7 indicates that very good accuracy is achievable if proper attention is paid to all sources of fluctuation and bias. High-accuracy implementations will require good oscillators, clock resolution at or below 1 ns, and careful attention to PHY selection and clock design.⁶

Implementation
To date, most implementations of IEEE 1588 have used FPGAs for the packet detectors and the clock. The associated software is executed as an application-level task in the processor of the host device. While this is clearly feasible, supporting silicon will shorten the design cycle and simplify the task of the instrument designer. Likewise, the test and measurement industry will require boundary clocks for the more demanding applications.

Early adoption of IEEE 1588 in the industrial automation industry has resulted in products that can be used by instrument designers and system integrators. For example, Intel® has introduced the IXP465® chip that incorporates hardware support for IEEE 1588.⁷ This network processor has been adopted by Rockwell Automation for use in future control products.

Boundary clocks targeted at industrial automation but useful in test and measurement have been introduced by Hirschmann Automation and Control⁸ and Westermo OnTime⁹. At the PlugFest during the 2004 IEEE 1588 Conference in Zurich, three companies demonstrated IEEE 1588 grandmaster clocks linked to GPS.

Applications
At the present time, there are numerous field trials and prototype application tests under way. In telecommunications, field trials have demonstrated frequency transfer over metropolitan area Ethernet networks using IEEE 1588.¹⁰ It is being used in a new generation of industrial robots to coordinate multiple robot controllers.¹¹

The largest fielded application to date is in the latest line of General Electric controllers for the large turbines used in power plants.¹² It is very much like large data acquisition applications in test and measurement with the added feature of a few very stringent control and timing requirements. In many respects, the new GE controller design represents the same sort of architectural shift represented by LXI Class B instrumentation relative to the GPIB architecture.

The original GE controllers used a centralized architecture based on the VME backplane. Signals from various sensors and actuators were routed to signal-conditioning circuitry on the backplanes, which was, in turn, controlled by computers also resident on the backplanes. Increases in the number of I/O points and bandwidth limitations on the backplanes caused GE to move to a LAN-based, distributed architecture in the new controllers.

In the new design, small local microprocessor-based controllers and signal conditioners interact directly with the sensors and actuators. These local controllers are on 3" × 4" boards and communicate with supervisory controllers in the main control racks using Ethernet LAN.

In a large installation, there can be up to 3,000 of these sensors distributed over hundreds of meters. Most of the application consists of acquiring sensor data for logging and inputting to local and supervisory controllers. Tight control loops are executed in the local controllers under supervision of the main controllers. It is very important not to lose data but even more critical not to delay reaction to critical events such as a loss of grid load.

To meet these communications and timing constraints, GE uses the simplest Ethernet switches to eliminate overhead and queuing introduced by the higher-level network switching protocols such as quality of service (QOS), spanning tree, and others normally found in Ethernet environments. Each of the local controller boards and the supervisory controllers executes IEEE 1588 to allow precise timestamps to be assigned at the source to all sensor data. The observed timing accuracy is on the order of a few hundred nanoseconds, a value consistent with the data associated with configuration 2 of Table 1.

A comparison with configuration 3 in the table indicates that this accuracy only can be achieved by eliminating the queuing jitter in the switches. This was done by using the IEEE 1588 time base to enforce admission control to the network at each local controller. The admission control mechanism is a time-slotted protocol in which each local controller is assigned a periodic time slot during which it is permitted to use the network, eliminating queuing in the switches.

Time-slotted protocols are almost always used in safety-critical systems to provide predicable execution. This same mechanism guarantees that time is available to communicate critical control information during normal operation and abnormal events such as a loss of load which requires a response within a known and bounded time.

The time-slotted protocol also permits the use of user datagram protocol (UDP) rather than the more resource and bandwidth intensive transmission control protocol (TCP) by eliminating queue overflow as a cause of packet loss. In fact, GE found that in this application UDP actually is more reliable than TCP.

Since this is a critical control application, the most recent data is more valuable than a missed data point in the past, which makes the preservation of the time-slotted protocol critical. The time required to reestablish a TCP connection in the face of failure is inconsistent with maintaining the protocol timing.

More detail on the General Electric and other applications including a more in-depth discussion of IEEE 1588 can be found in reference 13.

Conclusions
The LXI specification mandates the use of IEEE 1588 in
Class B devices to produce a system-wide time scale. IEEE 1588 is easily implemented in typical test and measurement devices and components, and infrastructure devices are now appearing on the market that support system-wide implementation of the IEEE 1588 protocol.

Part 2
Applications in industrial automation and power have proved the worth of this technology and provide important lessons for the test and measurement community. Part 2 of this article will explore the use of IEEE 1588, system-wide time scales, and other Class B features in test and measurement applications. It will appear in the October 2006 issue of LXI ConneXion.

References
1. LXI Specification, Revision 1.0, Sept. 23, 2005.
2. IEEE 1588-2002, Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, Nov. 8, 2002.
3. Inter-Range Instrumentation Group, http://www.jcte.jcs.mil/sitemap.htm
4. Correll, K. et. al, ' ' Designing Software-Only IEEE 1588 Systems,' ' Proceedings of the 2005 IEEE 1588 Conference.
5. Mohl, D., ' ' Experiences With IEEE 1588 in Higher Cascaded Ethernet Networks,' ' Proceedings of the 2005 IEEE 1588 Conference.
6. Vook, D. et al, ' ' Update on High Precision Time Synchronization,' ' Proceedings of the 2005 IEEE 1588 Conference.
7. Sharma, P., ' ' Hardware Assisted IEEE 1588 Implementation in a Next Generation Intel Network Processor,' ' Proceedings of the 2004 IEEE 1588 Conference.
8. Mohl, D., ' ' Implementation Results of an IEEE 1588 Boundary Clock,' ' Proceedings of the 2004 IEEE 1588 Conference.
9. Holmeide, O., ' ' Boundary Clock Implementation,' ' Proceedings of the 2003 Workshop on IEEE 1588.
10. Tonks, D., ' ' IEEE 1588: PAR Work and Field Trial Results With Reference to G.pactiming,' ' Meeting of the ITU, Study Group 15, Working Party 3, Question 13/15, May 2005.
11. Gerstenberger, M. et. al, ' ' Application of IEEE 1588 to Synchronize Multiple Robot Controllers,' ' Proceedings of the 2005 IEEE 1588 Conference.
12. Shepard, M., ' ' Implementation of IEEE 1588 in a Networked I/O Node,' ' Proceedings of the 2003 Workshop on IEEE 1588.
13. Eidson, J.C., Measurement, Control, and Communication Using IEEE 1588, 2006.

About the Authors
John C. Eidson, Ph.D., received a B.S. and an M.S. from Michigan State University and a Ph.D. from Stanford University, all in electrical engineering. He held a postdoctoral position at Stanford for two years, spent six years with the Central Research Laboratory of Varian Associates, and joined the Central Research Laboratories of Hewlett-Packard in 1972. When HP split in 1999, he transferred to the Central Research Laboratory of Agilent Technologies. Dr. Eidson was heavily involved in IEEE 1451.2 and IEEE 1451.1 and is the chairperson of the IEEE 1588 standards committee and a life fellow of the IEEE. e-mail: john_eidson@agilent.com

Dan Pleasant holds a B.S.E.E. from the University of Colorado and an M.S.E.E. from Stanford University. After a seven-year stint at MIT Lincoln Laboratory, Mr. Pleasant joined the CAE group (now known as Agilent EEsof) at HP in 1989. He has been a member of the DoD ATML Working Group and the LXI Consortium where he is the co-chair of the Timing and Synchronization Subcommittee.
e-mail: dan_pleasant@agilent.com
Agilent Technologies, 395 Page Mill Rd., Palo Alto, CA 94306, 800-829-4444.

For More Information
on literature on products, services,
and pointers to IEEE 1588
www.rsleads.com/615ee-176

PDF of this article

Back to Top

Introducing the Wired Trigger Bus

By David Owen, Pickering Interfaces

The capability of instrumentation to respond to events or trigger commands to perform measurements is an important part of a test system. All instrumentation platforms have this feature, and not surprisingly, it also is an important part of the LXI standard. The importance of including trigger capabilities is demonstrated by how other instrumentation platforms evolved from the trigger standard defined in GPIB.

For GPIB systems, the standard includes a comprehensive model that supports trigger operation by commands over the GPIB interface. More deterministic trigger operation in these GPIB systems typically is provided by the use of vendor-specific hardware trigger signals between instruments using coaxial connections.

There is no uniform way in which these hardware triggers operate or how they are implemented. If you need to change the hardware trigger connectivity, it has to be done via switching. The integrator has to design this into the system and handle the differing characteristics of the devices.

Modular instrumentation, such as VXI and PXI, tackled hardware triggering by including a backplane trigger interface that interconnects the modular cards. The modules can exchange and route trigger signals on different physical channels. For both VXI and PXI, eight channels of independent trigger signals are provided.

The VXI standard uses open-collector drivers to connect to the trigger bus with a pull-up resistor to assert the logic high state. This arrangement has some considerable advantages since an open-collector arrangement supports a capability referred to as Wired OR.

In a Wired OR, several VXI devices can drive the trigger bus. If they all initially assert the bus to the low state, the line remains low until the last device releases the trigger bus line. This means the last device to be ready initiates events in all receiving devices.

Conversely, with all open collectors initially off, the first device to detect an event also initiates the receiving devices to act. The VXI trigger bus can be considered as a multipoint-to-multipoint bus. More than one device can drive the bus, and more than one can receive the signal.

The PXI trigger bus provides a point-to-multipoint trigger system. One device drives the bus, and many can receive it. It does not support the Wired OR trigger mode. However, it does have an additional capability referred to as a Star Trigger, which connects Slot 2 of the chassis to 13 slots on a point-to-point arrangement. This facility supports triggering actions with low timing skew between the modules by using matched transmission line lengths.

In each case, PXI and VXI support eight trigger bus channels. The VXI speed typically is limited to around 10-MHz clock rates. The PXI standard can go considerably faster since it uses active drivers rather than open-collector drivers.

Hardware Trigger Advantages
A trigger bus based primarily on hardware connectivity has significant advantages for some applications. The key benefits are the following:
• Low latency: When the trigger occurs, there is only hardware delay between the trigger occurring and action starting.
• Low jitter: The delays are more consistent between successive events so if there are any timing skews, it is easy to compensate for the delay.

These were important advantages recognized as the LXI standard was created. Just as the standard included innovation on LAN, programmatic, and IEEE 1588 triggers, there was a strong motivation to innovate in the area of hardware-based triggers.

Wired Trigger Bus
The LXI standard set an objective to emulate the characteristics of the VXI/PXI trigger bus and provide a more unified method of exchanging triggers between LXI devices, a facility not supported by bench instruments based on GPIB and other control interfaces. The Wired Trigger Bus (WTB) is complementary to the LAN-based triggers, providing additional functionality normally found in modular instrumentation.

Since LXI is not a card-cage-based solution, a hardware trigger facility needed to be based on cables and connectors that provide the interconnection between LXI devices. The selected electrical specification is based on the Multipoint Low-Voltage Differential Signaling (M-LVDS) standard defined in TIA/EIA-899-M-LVDS. Choosing to adapt an existing standard has ensured that the chip sets are commercially available.

LVDS was selected because it can be carried over long distances using simple twisted-pair transmission lines. The differential signaling ensures that the signals have low emissions and high immunity, and the controlled rise and fall times of LVDS devices minimize high-frequency emissions.

The use of the multipoint variant enables multipoint-to-multipoint operation, which permits a Wired OR operation of the trigger bus. It also allows the bus to operate even when at least one or more of the LXI devices connected together is switched off.

There are eight separate trigger channels, and LXI devices should be able to route their trigger signals onto any of the channels. The trigger bus channel count matches the channel count used in VXI/PXI trigger backplanes and meets the anticipated application requirements.

The LXI LAN and programmatic triggers also use a logical model of eight trigger channels, permitting an easy equivalence model between them and the WTB. This also allows hardware trigger events to be timed by IEEE 1588 via suitable signal routing on
Class A devices.

WTB Transmission Line
The WTB uses a terminated transmission line to direct signals from one device to another.

As shown in Figure 1, each LXI device includes M-LVDS drivers, which drive a transmission line, and M-LVDS receivers that respond to the signals on the transmission line. The transmission line is a twisted pair with impedance of approximately 110 Ω. The signal from any driver is immediately split into two paths, one going left and one going right.
 

Figure 1. LXI Wired Trigger Bus Configuration

At the end of each transmission line is a differential termination load of 100 Ω. Any common-mode disturbance is terminated by the two 50-Ω resistors connected to AC ground via a 0.01-µ F capacitor. The M-LVDS drivers must support a differential load impedance of 50 Ω.

To maintain the transmission-line characteristics, it is important that stubs and other parasitic components be minimized. Reflections on the transmission line could cause false trigger events or timing jitter. This imposes some constraints on the WTB connector arrangement. The bus has to use an input and an output connector wired together within the LXI device by a differential transmission line that has minimal parasitic stubs.

The transmission line is shown in Figure 2. Each LXI device has two connectors for cabling to adjacent LXI devices. The connectors are interchangeable so they require no additional identification. Stacking connectors could not be used because they would have created significant transmission-line stubs.
 

Figure 2. LXI Wired Trigger Bus Connection Scheme

The connectors chosen for the WTB are the commercial version of the 25-conductor Micro D connector. They are physically small, minimizing the space occupied on the panel and providing a reasonable transmission-line match for the WTB. The screw locks ensure the cable is secure when fitted into an ATE system.

Transmission-Line Cable and Termination
The cable that connects LXI devices with the WTB is critically important for correct operation of the system. It contains eight twisted pairs for the eight channels, each of which has a shield around it to minimize crosstalk between channels. Without the shield, the crosstalk between the channels has the potential to cause timing jitter.

To connect LXI devices over reasonable distances, it is essential that the cable have low loss since at high frequencies the skin effect and wire diameter have a significant impact on overall performance. Increasing wire gauge makes the cable stiffer and eventually impossible to use with the selected connector, so the usual engineering compromises were applied. The wire chosen uses a silver finish to ensure the best surface conductivity and achieves the best transmission distance with the largest useable wire gauge.

The cable characteristics are carefully controlled and specified in the document ' ' LXI Trigger Bus Cables and Terminators.' ' The terminators are simple devices that provide the termination for all eight channels at the end of each segment.

Cable assemblies and terminators can carry the LXI logo if they conform to the full specification and are available commercially. Tests at the LXI PlugFests have shown that compliant cables can support 10-ns wide pulses over a distance of 10 meters

Driving the WTB
It is not obvious from Figure 1 how the WTB can support more than one LXI device driving a particular channel, but it is clear that one device can be used to assert the logical state of the LVDS interface if no other device is attempting to drive it. When this is the case, the mode is referred to as the Driven mode. It is a point-to-multipoint connection method similar to PXI backplane triggers. A single driver is used to set the channel to its low or high state.

The Wired OR mode takes advantage of the fact that LVDS drivers actually are current source drivers rather than voltage source drivers. This feature also helps manage common-mode voltage sources between LXI devices without introducing errors.

In the Wired OR mode, two drivers are used in parallel and have two states, either disabled or enabled when positive current from the two drivers is forced into the WTB channel. A Wired OR bias device is used to bias the channel with the negative current from one driver. If all the LXI devices on one channel are disabled, the net current in the channel is negative by one driver' s current.

The first LXI device to turn its driver from disabled to enabled (two drivers worth of positive current) overcomes the bias device and sets a high state, precisely the functionality required for Wired OR operation. As with the VXI open-collector arrangement, setting the starting condition with all the drivers enabled and changing state to disabled can implement the last-device-ready scenario.

The Wired OR bias device can be either not participating or participating in the trigger event. In the latter case, the Wired OR bias device is set to the Driven mode so that when its trigger event is low it provides one unit of negative current. If this device is the first to go high, it forces one unit of positive current into the channels.

In the Wired OR mode, more than one device could be setting the channel high, causing a larger voltage to appear across the LVDS receivers. This, however, has no impact on the WTB since the receivers and drivers are designed to handle such conditions.

With the Wired OR mode, the LVDS drivers do not operate as quickly to/from the enabled/disabled conditions as they do in the Driven mode. As a rough guideline, the minimum pulse width for trigger operation has to be doubled in the Wired OR compared to the Driven mode; consequently, the standard supports both modes.

The M-LVDS standard recommends that only 32 devices be connected on a bus. Since the LXI WTB has two drivers per LXI device, 16 LXI devices can be connected together on a single WTB segment.

Daisy Chaining and Star Connections
Some applications may require more LXI devices to be connected together than the 16 recommended for a daisy chain. Other applications could need access to more independent trigger channels with connectivity between them. In some cases, an application may demand that the delays to each LXI device be equalized in a way similar to the PXI Star Trigger bus. For these applications, the standard has defined the Star Hub.

A Star Hub can support a number of ports that are electrically buffered from each other. They can be set up so that a particular channel on one port can be connected to a channel on another port in a defined direction.

With the addition of the Star Hub, the WTB can be connected as a Star network, a daisy-chain network, or a combination of each. If a Star Network uses equal length cables, then delays will be nominally the same for each path from the Star Hub.

WTB Adaptors
Devices that do not support the LXI WTB can be made compatible through the use of simple adaptors. These adaptors allow external triggers to be converted to the WTB or WTB signals to be converted to single-ended triggers, enabling easy integration of older trigger standards into the LXI trigger system.

WTB Capability
The key capabilities of WTB are the following:
• Eight independent channels.
• All LXI devices supporting the WTB have a uniform wired interface.
• The WTB freely exchanges signals with the LAN and programmatic triggers since they use the same model.
• A total of 16 LXI devices can be connected as a single WTB chain. Functionality is preserved even if some of the LXI devices connected to the WTB are not powered.
• A trigger function provides low latency and low jitter.
• In the Driven mode, LXI devices can exchange 10-ns wide trigger signals over a distance of 10 meters.
• The Wired OR mode is a simple and effective way of providing a last device ready or first device to initiate an event without programmatic intervention.
• Extension of the WTB through the use of a Star Hub is defined to provide solutions for larger systems.
• Simple inclusion of triggers to and from other sources via adaptors provides a means to interoperate with LAN-based triggers.

The result is that the LXI WTB is a powerful addition to the LXI standard. And with its integration with LAN, IEEE 1588, and programmatic triggers, the WTB can emulate and exceed the ad hoc trigger mechanisms found on bench instruments. Users of LXI systems have a comprehensive suite of trigger functions that allows them to address even the most demanding applications.

About the Author
David Owen is the business development manager for Pickering Interfaces. Over the last 30 years, he has held key engineering, product management, and strategic marketing positions with Marconi Instruments, then IFR. Mr. Owen, the innovator of more than 10 patents in the field of RF signal generation and analysis, currently is involved in the PXI and LXI standards and serves as deputy chair of the LXI Compliance Working Group. Pickering Interfaces, Stephenson Rd., Clacton-on-Sea, Essex, CO15 4NL U.K., 011 44 1255-687900, e-mail: david.owen@pickeringtest.com

PDF of this article

Back to Top

Integrating LXI Devices Into Hybrid Test Systems

By Mike Dewy, Editor

Almost all modern test systems today use a variety or collection of instrumentation, a PC-based system controller, and associated control interfaces to effectively address the functional test needs of modern, complex electronic assemblies. And when these systems have more than one type of control interface, they can be broadly characterized as hybrid test systems.

Incorporating LXI devices as part of a system can provide an additional level of flexibility and capability for a specific application. Successful integration of all system components, including LXI devices, must include determining the capability of the hardware and software interface, assessing the required test-system performance or throughput, and specifying mechanical configuration, UUT interfacing, and system maintenance requirements.

For each specific application, an overall test system' s requirements and configuration will be different— one solution will not serve for all applications. LXI offers several options for incorporating devices into a hybrid system that provide the flexibility to optimally configure and implement test systems based on specific requirements.

To incorporate LXI devices as part of a test-system architecture, you must consider the performance requirements and implementation feasibility of an integrated system. Hybrid test systems are an integrated collection of devices or instruments, each with a hardware control interface, a software interface, an interface to the UUT, and possibly a triggering infrastructure that may be part of the control interface or a dedicated interface such as a trigger bus. For each component that is integrated into the system, ask the following questions:

• How do I support the device' s control interface? Is there an interface available on my system controller to support the interface, or can I procure the necessary adaptor and associated control software?
• Are the necessary software drivers available for the device and the specific program development environment I' m using?
• Do I need to support the interoperation of hardware triggering among different device standards?
• Is test-system throughput a key factor?

Your answers to these questions and the priority assigned to each of these requirements or features will determine how you integrate LXI devices into a hybrid system. And depending on the class of LXI instrument, additional consideration may be needed to determine how best to use the LAN-based precision timing, triggering, and high-performance wired trigger bus features associated with Class B and Class A devices.

System Configurations and LXI Device Control
The specific configuration of a hybrid system will depend greatly on system performance requirements, the availability of hardware, and interoperability requirements between various device stand-ards. Incorporating LXI devices as part of a hybrid system can be accomplished in several ways:

1. Dedicated Ethernet interface supported by the system controller.
2. An Ethernet-centric control interface with other control interfaces adapted or bridged to the Ethernet interface or backbone.
3. A combination of items 1 and 2.
Figures 1 and 2 show how these configurations might be implemented for a collection of instrument control interfaces such as VXI, PXI, PCI, and GPIB.

Figure 1. Multiple Bus Control Configuration

Figure 2. LAN-Centric Configuration

All LXI device classes use Ethernet as their instrument control bus as defined by IEEE 802.3 and support three IP address configurations: dynamic host configuration protocol (DHCP), dynamically configured link local addressing, and manual IP address assignment. Support for these configurations provides the flexibility to integrate an LXI device into various test-system configurations ranging from private LANs to systems that might be part of a LAN network.

For Class C devices, incorporating and controlling LXI devices via a dedicated LAN subnet as depicted in Figure 1 provide an easy and straightforward implementation. If additional LXI devices are needed for the system configuration, you can use an inexpensive router or hub to support the additional LAN connections.

However, if Class B and Class A devices are integrated into a system, consider how best to use the LAN and hardware trigger features associated with these devices. For LAN triggering functionality, all Class B devices must be located on the same subnet or be part of a 1588 capable subnet or network to take advantage of the timing protocol features. And for Class A devices, consider how best to interface the LXI wired trigger bus to other trigger buses located within the test system, such as VXI, PXI, or GPIB.

Using a dedicated LAN connection or subnet helps ensure optimal system performance and reliability since this communications interface will not be subjected to superfluous intranet traffic or other non-runtime tasks such as datalogging. Of course, the test-system controller most likely will be required to support two Ethernet ports: one to connect to a company' s intranet to support datalogging and program updates and a second to handle the LXI device' s subnet communications. Normally, this should not be a problem since most controllers, including embedded controllers, offer multiple LAN ports.

Software control of LXI devices is based on the use of the virtual instrument software architecture (VISA) interface, which provides a defined set of I/O commands for communicating to an Ethernet device via transmission control protocol (TCP)/IP. As depicted in Figure 3, it affords a level of abstraction for essentially all instrument control bus interfaces that require read/write control functionality.

Figure 3. Software Interface/Control Architecture

The use of VISA is key to providing a common read/write command structure and allows the development of applications using one application development environment (ADE), which works seamlessly and independently with all instrument control buses that may be part of a hybrid test system. By using VISA, LXI devices can be controlled and integrated just like any other instrument that may be part of a hybrid system such as VXI, PXI, or GPIB.

The LXI standard specifies that all instrument vendors provide a driver based on existing standards such as interchangeable virtual instruments (IVI) and VXI plug-and-play specifications. This establishes a common baseline of capabilities and provides the flexibility to use a variety of ADEs while leveraging existing and established software standards for instrumentation.

More specifically, the standard specifies that LXI instrument vendors provide an IVI-specific driver that conforms to the various IVI standards including IVI class compliance if applicable. The requirement that LXI device vendors supply an IVI-COM or IVI-C driver helps ensure that an LXI device can be easily integrated with any number of modern software development environments that may be used as part of a hybrid system.

Figure 2 shows several alternatives for incorporating various instrument platform standards including LXI devices as part of an overall hybrid test system. For this LAN-centric topology or configuration, Ethernet is the primary control interface. Depending on the required flexibility, performance, and availability of specific hardware, several options are available for interconnecting non-LXI devices to an Ethernet-centric control interface.

The LXI Consortium' s Hybrid Systems Technical Working Group has specified various types of interfaces and options for incorporating non-LXI devices into an LXI-centric test system. The working group has defined the use of adaptors and bridges as two types of devices that can help facilitate the integration of instruments with diverse control interfaces.

An LXI bridge device provides a complete LXI interface on one side and interfaces to a non-LXI interface on the other. This type of device is a fully compliant LXI device, providing all of the required capabilities of an LXI device including network protocol support, web pages, a LAN configuration initialize (LCI) button, and an IVI driver. All of these capabilities are specific for the bridge itself.

For devices located on the downstream or far side of the bridge, specific hardware and software interfaces must be specified. For example, if a bridge supports one or more GPIB devices, the bridge not only would have to include support for the GPIB control bus, but also provide a means to map software commands from the LAN interface side of the bridge to the GPIB instrument side.

Support for control of the devices on the far side of the bridge might be done via Web pages as well as a mechanism that allows the mapping of control or VISA resource strings via the bridge' s IVI driver, an implementation that would be part of the bridge' s capabilities and specific design. In addition, because only the LXI bridge itself is compliant, there is no specific provision or requirement to support interfacing the downstream device' s triggering facilities to the LXI' s wired trigger bus facility or the 1588 precision timing protocol (PTP) LAN triggering facility. This capability may or may not be needed, depending on a specific application.

An LXI adaptor offers a complete LXI interface for one or more adapted instruments. In its simplest form, it presents a single adapted instrument as an LXI-compliant device.

The adaptor and the associated instrument are tested for conformance as a set and, when viewed together, are indistinguishable from any other single network instrument. The adaptor may be physically integrated into the instrument, or it could be a stand-alone device.

Unlike the bridge device, the instrument driver and web pages access and control the adapted instruments directly. There is no mapping of control or VISA strings between the adapted instrument and the LXI control interface.

The concept of an LXI adaptor, however, is not limited to a one-to-one LXI instrument mapping. Adaptors also can be used to adapt multiple instruments to one LXI device or even multiple LXI devices to multiple instruments.

Figure 4 details these two configurations. In the many-to-one case, a multiple VXI or PXI modular instrument configuration might be combined to form a higher-level virtual or synthetic instrument. This one-to-many adapted instrument appears as a single LXI instrument and offers all the functionality required of an LXI device including an IVI driver for the aggregate set of instruments, Web access, IP configuration, required LXI physical attributes, and LAN/wired trigger bus capability if a Class B or A device.

Figure 4. LXI Adapter Configurations

In this case, the adapted instrument will be a conforming LXI device based on a specific instrument configuration. It does not provide the option to add or change components within the modular instrumentation platform since the collection of instrumentation is used in conjunction with a specific IVI driver to support a defined set of synthetic or virtual instrument functions.

As an alternative, an adaptor also could support a many-to-many adaptation whereby multiple, non-LXI instruments are adapted to multiple LXI- compliant devices. For system configurations that use modular instrumentation such as PXI or VXI, the many-to-many configuration may be most appropriate. However, by supporting a multiple LXI device configuration, the adaptor' s functionality will be more complex since each LXI device must have its own IVI driver and Web page and support a discovery mechanism that identifies each adapted device.

Besides having individual Web interfaces, the adaptor also may have a master Web interface for overall Ethernet configuration with links to pages for each device. This type of adaptor could be implemented by incorporating the necessary LXI device interface functionality as part of a PXI controller' s or VXI Slot 0 controller' s functionality. For Class C LXI device functionality, the creation of such an adaptor requires a vendor or system integrator to augment a VXI or PXI controller to include the following capabilities:
• An Ethernet port.
• IVI drivers for the system host PC that control the PXI or VXI instruments via the Ethernet interface.
• A Web server in the PXI or VXI controller.
• LAN status indicators and LCI functionality.
• An LXI-compliant Web page for each adapted instrument.
• A discovery mechanism that identifies all adapted devices.

To date, no vendor has developed an adaptor that generically supports PXI or LXI devices. Adapting certain classes or types of instruments to an LXI interface may compromise the instrument' s performance within a hybrid test system. For example, instruments requiring the bus performance of PXI or VXI could have performance issues when adapted to a 10/100Base-T interface if high bus data rates are required.

In addition, for LXI Class A and Class B devices, adapting instruments to support the LAN and wired trigger protocols may be difficult. Consequently, using a many-to-many type of LXI adaptor as part of an LXI-centric system probably is not a preferred implementation based on the current availability of products and required functionality.

Trade-Offs and Implementations
Hybrid systems can incorporate LXI devices in several ways. A test system with several bus interfaces as shown in Figure 1 provides the easiest and most direct means to incorporate LXI devices. Since all LXI devices are provided with an IVI-compliant driver, the capability to integrate LXI devices with other instrument platforms such as GPIB, VXI, or PXI as well as with application programming interface (API) software is easily accommodated. In addition, the needed hardware and software are available to support this type of system configuration.

For a LAN- or LXI-centric configuration as shown in Figure 2, LXI devices can be interfaced via bridges or adaptors. Bridges can offer a simple and pragmatic way to interface instruments to an LXI interface without developing all of the features required of an LXI-compliant device.

Only the bridge itself must be LXI compliant. The mapping and control of instrument functions will be specific for each application.

In addition, when incorporating modular instrumentation such as PXI or VXI, bridges may provide an expedient way to control these types of devices. For example, for VXI devices, a Slot 0 device can have an Ethernet-to-VXIbus interface based on the use of VISA, which supports a variety of communications interfaces including VXI and TCP/IP. A similar implementation based on VXI-11 and VISA is possible for GPIB devices.

For PXI devices, a bridge implementation most likely will require the addition of software as part of the PXI system controller to support PXI devices via a LAN interface. To be a compliant LXI bridge device, additional functionality for supporting a Web page, an IVI driver, and other required LXI device functions also would be needed.

LXI adaptors offer various configurations for supporting the conversion or adaptation of instruments. From a practical and realistic standpoint, only the one-to-one or the one-to-many configuration is reasonable.

The one-to-one configuration is readily realizable for GPIB instruments and only requires that the supplier certify both the adaptor and adapted instrument as LXI conformant. The one-to-many configuration most likely will be used for applications where a modular subsystem comprises a virtual or synthetic instrument or multiple GPIB instruments.

Summary
The introduction of LAN-controlled instrumentation offers the opportunity to develop new and different system configurations. However, to achieve the optimal system configuration, the integrator needs to evaluate product availability, technical requirements, and system performance attributes.

For example, if test-system throughput and flexibility are primary concerns, a system that uses multiple system interfaces may be the best choice. More specifically, if a system is primarily based on a card modular subsystem core, adding LXI modules via a dedicated subnet will be the preferred method of integration and provide the easiest means of integrating LXI devices with other system components.

Alternatively, a LAN-centric system configuration can offer all the advantages associated with the LXI architecture including Web-page interfaces and the flexibility to remotely locate and control instruments. In addition, adding non-LXI instruments can be done via bridges or adaptors, providing a straightforward methodology for incorporating GPIB instruments as well as modular instruments.

The use of adaptors or bridges, however, will depend on the availability of specific products as well as specific system performance requirements. For example, using an LXI interface to control a device with low to moderate data bandwidth requirements will be much more compatible with a LAN-centric control architecture than an adapted device with high data bandwidth demands. Ultimately, configuring and implementing a hybrid system with LXI devices will require the system integrator or user to evaluate and prioritize performance, product availability, and the need for network-centric features.

Additional Resources
1. www.lxistandard.org
2. McCarthy, A., ' ' A Software Technique for Optimizing Measurement Time and Repeatability on Instrument Control Buses,' ' Autotestcon, 2005.
3. Dewey, M., ' ' The LXI Standard,' ' LXI ConneXion, October 2005.

About the Author
Mike Dewey, the marketing product manager at Geotest-Marvin Test Systems, previously has held various positions in design engineering, engineering management, marketing, and product management with GenRad/Teradyne, ADR Ultrasound, and Motorola Government Electronics Group. He is a member of the IEEE and has served as a board member for both the PXI Systems Alliance and the VXI Consortium and been an LXI Consortium advisory member on the marketing, technical, and physical working group committees. Mr. Dewey received a B.S.M.E. from Syracuse University and an M.S.E.E. from Georgia Institute of Technology. e-mail: miked@geotestinc.com
 

PDF of this article

Back to Top

10 Good Reasons to Use LXI

By Stefan Kopp, Agilent Technologies

Ease-of-Use
Did you ever ask yourself why GPIB still is popular more than three decades after its introduction? The answer is simple: ease of use and robustness. LXI offers the same level of robustness and ease of use and more.

Admittedly, Ethernet, with its many protocols and versions, is a fairly complex standard. However, it is the end-user' s experience that matters. LXI features a number of elements that make it easy to successfully implement and deploy an LXI-based test system.

At the physical-network layer, LXI recommends medium dependent interface crossover (Auto MDIX), a feature that eliminates the need for crossover cables for direct peer-to-peer or controller-to-instrument connections (Figure 1). Consequently, the instrument can automatically adjust to its communications counterpart and the interconnecting cable. Another helpful feature is automatic negotiation of the speed and duplex mode of the LAN connection.

Figure 1. Tools/Protocols That Increase the Ease-of-Use at the ISO/OSI Layers

At the network layer, LXI instruments support automatic IP configuration through a dynamic host configuration protocol (DHCP) server, typically available in managed corporate networks and in cable/digital subscriber line (DSL) routers, or dynamic configuration of link local addresses, usually used in small or ad hoc network situations.

LXI also recommends support for the dynamic domain name server (DDNS) where instruments can publish their host name through a DDNS server, a feature typically available in large corporate networks. This allows the end user to specify a host name while retaining the benefits of a domain naming system (DNS) network.

At the application layer, LXI instruments support the VXI-11 protocol, based on remote procedure call (RPC), for automatic discovery of new instruments connected to the network and identification through the *IDN? Query. This is similar to the discovery method used for IEEE 488-based instruments.

Beginning with the web server, let' s look at some LXI instrument control features that take the ease of use beyond the level of GPIB instrumentation. LXI instruments include a web server that provides information regarding instrument configuration and allows you to manage the device' s LAN configuration. Typically, the web page also permits you to interactively exercise instrument functions and can be an invaluable tool during system test and commissioning.

For programmatic control, the LXI standard recommends IVI-COM instrument drivers. These drivers are based on the ubiquitous Microsoft COM architecture and work with all modern programming environments. With their object-oriented nature and hierarchical APIs, they can take advantage of the advanced features associated with modern, object-oriented environments.

Performance
For many years, VXI has set the standard for high-performance communications in test and measurement. Can LXI rival VXI' s data rate performance?

LXI uses Ethernet' s TCP for communications among the system' s components. What payload data rates are realistically achievable taking the protocol overhead of Ethernet into account?

Figure 2 shows the structure of an Ethernet frame with TCP/IP packets enclosed as payload. Assuming the use of IPv4 and a maximum frame size, the bandwidth remaining for application data is just a little less than 95% of the underlying physical-layer transmission rate.

Figure 2. Payload Efficiency of Ethernet

With a Fast Ethernet connection such as IEEE 802.3u at 100 Mb/s, the payload data rate becomes approximately 11.9 MB/s. Gigabit Ethernet (GbE), IEEE 802.3z, recommended by the LXI specification, boosts the performance by a factor of ten to approximately 119 MB/s. Consequently, an LXI device with a GbE interface easily surpasses VXI 1.0, which provides 40 MB/s, and comes close to the peak performance of PXI and PCI, which supports a transfer rate of 132 MB/s.

Certainly, simultaneous communications by devices over a LAN can cause degradation in performance due to collisions and retransmission. To avoid or limit this effect, high-performance systems typically use their own subnet.

As a final note, what about the latest version of the VXI specification, revision 3.0 released in 2004? It pushes the data rate performance up by a factor of four, to 160 MB/s, beyond the capabilities of GbE. Here is the beauty of LXI: It takes advantage of the IT world' s innovations and hunger for ever-increasing data rates which eventually will result in LXI devices adopting 10GbE and enabling LXI device performance to even surpass the performance of VXI 3.0.

Cost
A test system based on LXI components is likely to be less expensive than GPIB, VXI, and PXI because it doesn' t require a card cage, Slot-0 controller, or specialized communications interfaces and cables. With card-cage systems, these items typically cost $5,000 to $10,000 depending on the configuration.

Scalability
Scalability means buying just what you need when you need it and being able to add resources as the need arises in the future. How is LXI going to help in this respect?

Longevity
Most test engineers appreciate technologies that have proven track records and are widely used across many industries. Our test systems must live as long as the products they were designed to test. In some industries, including automotive and defense, product life cycles can easily span several decades. Furthermore, our systems need to be updated and expanded for new product variants.

Distributed Systems
With Ethernet, LXI opens a whole new world of applications that previously would require more specialized equipment. Using your corporate Ethernet infrastructure or the Internet, bridging large distances is easy to do and transparent to the end user.

Flexibility
Unlike PXI/VXI systems, LXI modules can be freely distributed in a test rack, lab, or building. This allows you to place the instruments where it' s best from a measurement or application standpoint.

Synchronization Through IEEE 1588
IEEE 1588 is one of the key enabling technologies behind LXI. By incorporating the capabilities of IEEE 1588 as part of LXI Class A and B instruments, Ethernet becomes a much better fit for measurement applications.

In the kind of distributed applications enabled by LXI, intelligent instruments perform measurement tasks on their own, independent of the system controller and synchronized by real-time clocks in the instruments. To synchronize tasks and events among instruments, IEEE 1588, also called Precision Timing Protocol, allows the clocks to synchronize to a master clock.

IEEE 1588 works across the same Ethernet we use for instrument control. No additional cables are required. Depending on the variation in latency times, clocks can be synchronized down to 10 ns or better with 100 ns of synchronization easily achievable in a typical test system with its local subnet.

IEEE 1588 uses a master, typically the instrument or network element with the most precise clock in your system, which regularly sends synchronization messages to the slaves. The slaves reply after a random delay with a corresponding acknowledgement message (Figure 3). Timestamps are taken as the various messages pass each instrument' s IEEE 1588 hardware. These timestamps are taken in hardware, bypassing the software TCP/IP stack and eliminating the latency variations involved in software processing.

Figure 3. Time Synchronization Through IEEE 1588

Based on the four timestamps, users then can calculate the message transit time and the offset relative to the master' s clock. This calculation is done at regular intervals, and statistical methods are used to limit the effect of variation in the message transit time.

IEEE 1588 is a key technology for LXI because it enables tightly synchronized measurements and synchronous triggering, previously possible only using card-cage systems with a central controller and hardware-based trigger buses.

Rack Space
The LXI standard includes an optional mechanical specification primarily intended for automated applications. Instruments used in such applications typically will be faceless, half-rack width, and one or several rack units high. Without a physical user interface, depending on the type of instrument, manufacturers will be able to shrink their instruments considerably in size.

Synthetic Instruments
LXI is the best enabling technology to date for synthetic instruments (SI). With SI, instruments are broken down into major building blocks. This approach is especially well suited to RF instruments, but it also applies to other types of instruments. For example, an RF vector signal analyzer (VSA) includes a down-converter, a digitizer, and a piece of analysis software.

Summary
LXI combines qualities and capabilities that previously would have required heavy compromising. It offers the ease of use of GPIB, the performance of VXI, and the flexibility and functionality of Ethernet all at the same time. With the release of the first version of the standard, a growing number of LXI instruments are becoming available. Watch for more new product introductions. There are many good reasons why your next test system might be based on LXI.

PDF of this article

Back to Top

The Process and Requirements for LXI
Device Compliance

By Mike Dewey, Editor

Principles and Overview
Certification of an LXI instrument or device gives a vendor the license to use the LXI logo on its products and promote it as LXI compliant. The consortium licenses the LXI trademark and provides test procedures or recommendations regarding conformance testing. However, it is the responsibility of the vendor, not the consortium, to ensure that the product is fully LXI compliant.

Conformance and Interoperability Tests
Development and management of the overall conformance process are the responsibilities of the LXI Compliance Technical Working Group. This group is tasked with assembling the overall LXI Compliance Test Procedure that includes specific test procedures by each of the technical working groups.

However, for Class A and Class B devices, specific functionality supporting the API, as defined by the LXISync Interface Specification, requires that these functions be tested as part of the plug-fest conformance process. These tests involve the use of specific software test routines, Ethernet monitoring software to confirm the generation and reception of LAN triggers, and hardware to create and monitor hardware triggers.

Summary
LXI product vendors are responsible for testing their devices against the standard and documenting conformance. However, to help facilitate the process, the consortium takes a proactive approach by sponsoring plug-fests and establishing an overall compliance process to help ensure interoperability and consistency in product performance.

This effort not only has included a definition of the conformance process, but also the definition and implementation of specific test methods for verifying key features and capabilities of an LXI device. By establishing a baseline set of conformance requirements and tests for the three instrument classes, vendors and customers alike can be assured that all LXI instruments, regardless of their class, will be interoperable, perform reliably, and have a consistent look and feel.

References
1. LXI Specification Revision 1.0, Section 14
2. www.wheelwrightenterprises.com
3. www.ethereal.com
4. http://validator.w3.org
5. http://jigsaw.w3.org/css-validator

About the Author
Mike Dewey, the marketing product manager at Geotest-Marvin Test Systems, has previously held various positions in design engineering, engineering management, marketing, and product management with GenRad/Teradyne, ADR Ultrasound, and Motorola Government Electronics Group. He is a member of the IEEE and has served as a board member for both the PXI Systems Alliance and the VXI Consortium and been an LXI Consortium advisory member on the marketing, technical, and physical working group committees. Mr. Dewey received a B.S.M.E. from Syracuse University and an M.S.E.E. from Georgia Institute of Technology. e-mail: miked@geotestinc.com
 

PDF of this article

Back to Top

LXI Addresses Structural Test

By Jon N. Semancik, VXI Technology

Open architecture designs have been the choice for many military and commercial test systems since their introduction. They offer a solution that is open-hardware and open-software based, computer and operating system independent, and highly modular in nature.

The introduction of the local area network (LAN) eXtensions for Instrumentation (LXI) standard has added another platform alternative, incorporating all of the open architecture advantages of Ethernet while increasing the number of critical components necessary for true test and measurement compatibility. LXI offers a glimpse into the future of test-system interfaces that is particularly interesting to designers who wish to leverage open-platform architectures for distributed measurement applications.

Another less obvious advantage of this platform is apparent when focusing on the data acquisition application arena. Classic data acquisition applications typically have involved independent signal-conditioning subsystems to amplify and filter inputs from transducers before sending the signals to the digitization hardware. This complicated the test setup and ultimately increased system cost.

The distributed nature of an LXI-based data acquisition platform makes it easy to place an integrated instrument containing signal conditioning, excitation, and digitization hardware near the test article and supports communications with the various test components via standard hardware, interfaces, and protocols.

Open Architecture Significance
The advantages of adopting an open architecture test platform span both hardware and software, providing a wide range of choices not available to those locked into proprietary designs. An open hardware approach guarantees that a well-defined set of signal and interface characteristics has been adopted and that multiple vendors will provide support and products for the defined standard. All of this results in reduced cost, extended test-system life cycles, and commercial-off-the-shelf (COTS) product availability.

The LXI standard was designed with hardware independence in mind, largely accomplished by leveraging well-established industry standards. The LAN interface for LXI devices is based on IEEE 802.3, and it is intended to support current and future networks with 100Base-T or faster connections.

Utilizing this standard greatly reduces entry obstacles for instrumentation manufacturers thanks to many standard interface implementations that have been driven by the PC market. The very nature of this interface also makes it suitable for many distributed applications. Standard Category 5 (CAT-5) copper connections can reach 100 meters point-to-point, and fiber-optic implementations can span several kilometers without additional switches or routers.

Open software support also plays an important role in reducing development costs and ensuring life-cycle management. Software independence is built upon well-defined standards such as those seen in plug-and-play drivers and IVI. This is further extended into the application development environment, providing the freedom of choice to select the software environment best suited to specific needs.

All LXI-compliant instrumentation is required to furnish an IVI driver: IVI-C or IVI-COM. This provides the flexibility to choose the development environment best suited to the application. These drivers can be used in a number of application programming environments such as C/C++, MatLAB, Visual Basic, VEE, and LabVIEW/LabWindows CVI. It also is possible to port instrument functionality into non-Windows based environments when source code is provided by the manufacturer.

Distributed Measurement Approach
Open hardware and software are fundamental requirements for any truly sustainable platform, but system designs using the LXI platform also provide an inherent benefit suitable for distributed data acquisition applications. Many traditional data acquisition implementations involve placing the instrumentation in a control room that may be located hundreds of feet from the article that is being tested. This distance presents numerous challenges including cable cost, maintenance, calibration, noise, and debugging.

Aircraft structural test applications illustrate this concept. Not only is the test performed some distance from the control room, but the sheer size of the test article also is a challenge. Fatigue testing on an aircraft wing may involve 5,000 to 6,000 channels of strain gage transducers that must be located at strategic points on the structure.

The cost of the cabling and installation will be significant; 5,000 strain gage channels would result in 40,000 connections (eight-wire configuration) that must be properly identified, cataloged, attached, and tested. Measurement errors due to cable loss and noise pickup also must be considered, and many installations have implemented proprietary calibration sequences and correction factors to compensate for these effects.

This effort results in a significant engineering investment. Maintenance and support also will be an issue because many tests of this nature span long time periods and are susceptible to typical fatigue issues and accidents. Fortunately, the effects from most of these issues are greatly reduced by placing the instrumentation as near to the test article as possible.

Distributed LXI-based instrumentation, such as VXI Technology' s EX1629, a 48-channel high-performance remote strain measurement unit, can simplify the task. Each EX1629 can be placed near the test structure and connected to the test LAN using standard Ethernet cable and networking accessories (Figure 1). The simpler cabling and installation process decreases both setup time and cost.

Figure 1. Aircraft Structural Test Setup

Highly integrated instrumentation of this nature also improves accuracy by incorporating all signal conditioning and excitation sourcing within a single package. Separate analog excitation sources provide programmable bridge excitation voltages near the test article, and independent ADCs monitor the voltage applied to the strain gage. Extensive signal conditioning and filtering are integrated into the instrument along with comprehensive self-calibration to further improve system accuracies and reduce test setup times.

Once all of the LXI instruments are connected to the dedicated test LAN, a single Ethernet cable can be routed to the control room for data collection and control. While this approach simplifies installation and addresses several key areas of concern, a distributed approach still must address LAN use and access, synchronization, and trigger control, issues common to classic data acquisition applications and network installations.

Dedicated Test LAN
The affordability and ease of use of Ethernet network components are other reasons why LXI has been so openly accepted. Dedicated networks are inexpensive to install and provide the necessary isolation between corporate-wide network traffic and the test system. Additionally, with little effort, this network can be easily interfaced to the rest of the corporation or the World Wide Web.

The low cost and ease of use of today' s routers and hubs simplify the task of establishing a dedicated network. Standard CAT-5 cable is easy to route throughout test bays and around test articles, inexpensive to use, and available from many commercial sources. The familiar RJ-45 connector accommodates cable lengths that are easy to modify and customize.

Isolated instrumentation networks also eliminate many of the logistical issues that may arise when trying to conform to corporate network requirements. Security concerns can be addressed by not allowing physical access to outside network connections by installing a second Ethernet card, implementing a virtual private network (VPN), or physically disconnecting the network cable.

System synchronization and throughput also can be optimized using dedicated test networks. Today' s generation of network switches has greatly reduced issues associated with traffic control and collisions common in earlier implementations, but independent test LANs can ensure the highest degree of performance.

LAN Synchronization
LAN synchronization incorporating IEEE 1588 Precision Time Protocol (PTP) provides the capability to time-align multiple devices in systems including clocks of different precision, resolution, and stability. PTP allows the synchronization of multiple LXI devices while eliminating the need for external cabling between devices. Submicrosecond accuracy can be achieved with minimal network and local clock computing resources and little administrative attention.

PTP can be implemented in several ways ranging from user-level software control to kernel-level driver modifications to hardware implementations using dedicated field programmable gate array (FPGA) devices. Gigabit Ethernet can provide synchronization times in the hundreds of nanosecond range, which are suitable for low- to medium-speed data acquisition rates common with certain static parameters such as thermocouple measurements. The highest level of precision is obtained when hardware implementations assist in the timestamping of incoming and outgoing network packets or frames.

Once multiple devices are synchronized using IEEE 1588 and a data capture sequence is initiated, individual samples can be time correlated with minimal effort. Many typical data acquisition applications require physical forces to be applied to the UUT. These forces can include tensile loading, temperature characterization, or simulated pressure variations. The measurement data then is time correlated with the excitation sources through the use of independent sample timestamps that are inherently available through the IEEE 1588 interface.

Hardware Triggering
The most accurate and deterministic synchronization mechanism between multiple devices involves the implementation of a hardware trigger interface. As a result of this requirement, the LXI standard defines a high-performance hardware trigger interface referred to as TriggerBus. TriggerBus can provide the link between all devices in the test system for triggering, synchronization, and clock signal distribution.

Deterministic trigger generation and propagation between multiple devices are accomplished with an eight-channel, multipoint low-voltage differential signal (LVDS) interface. This architecture permits individual lines to be configured as a source and/or receiver and supports external, time-based, or software-generated triggering as well as clock distribution.

Common topologies are supported including star, daisy-chain, and hybrid configurations, providing the flexibility to distribute the trigger lines as dictated by the application requirements. Flexibility is increased with the addition of a star hub. This device permits very tight trigger tolerances to be maintained throughout a large distribution network
(Figure 2).

Figure 2. TriggerBus Star Distribution Configuration

The configuration in Figure 2 provides the capability to interconnect a very large number of instruments while preserving a high level of synchronization and timing performance that currently is not available with IEEE 1588. For applications requiring this level of triggering performance, the TriggerBus interface, standard on all Category A-compliant LXI devices, can be used to distribute system-wide clock, synchronization, and trigger signals.

Propagation delays between the various strain measurement instruments and the distribution hubs also can be minimized by using equidistant cables. This ensures extremely deterministic signal distribution throughout the entire system.

The TriggerBus also can automatically extend trigger and clock distribution signals to other platforms such as VXI with an LXI-VXI slot-zero control bridge. This provides a mechanism to link a VXI chassis with other LXI hardware.

The LXI-VXI slot-zero control bridge provides a direct extension of the eight VXI trigger lines to any external device, adding the capability to individually control specific instruments and switch devices within the VXI chassis. This type of flexibility supports integration of other instruments into a homogeneous open test environment, leveraging the strengths of each subsystem.

Summary
Many end users, integrators, and designers have been looking for the next logical step in the evolution of instrumentation interfaces, and it appears as if LXI has emerged as the clear choice. Obvious advantages such as high bandwidth, ease of connectivity, low cost, and readily available technology only scratch the surface of the possibilities that arise from the selection of Ethernet as the base technology.

Entire test methodologies are being transformed as more applications are considered under this new paradigm. The transition to distributed measurements is a prime example.

Large-scale structural, automotive and aircraft test-cell, and wind-tunnel test applications are just a few examples that will benefit from distributed Ethernet-based measurements thanks to the addition of key technologies such as IEEE 1588 and the hardware TriggerBus that ensure critical timing and synchronization requirements are met. Instruments with fully integrated signal conditioning now can be placed adjacent to test articles, eliminating miles of cabling and simplifying setup and maintenance. Performance and accuracies also will be improved as these new classes of instruments leverage functionality once considered only fitting for the laboratory.

About the Author
Jon N. Semancik is the corporate marketing and business development manager at VXI Technology and treasurer of the LXI Consortium. The U.S. Navy veteran has held engineering and project management positions on numerous programs in both the military and commercial sector. Mr. Semancik earned a B.S.E.E. from Fenn College of Engineering and an M.B.A. from the Weatherhead School of Management, Case Western Reserve University. VXI Technology, 2031 Main St., Irvine, CA 92614, 949-955-1894,
e-mail: jsemancik@vxitech.com

PDF of this article

Back to Top

LXI Instrument Classes

By Mike Dewey, Editor

The LAN Extensions for Instrumentation (LXI) standard builds on the use of Ethernet IEEE 802.3 as the communications interface for LXI devices. And as part of the standard, the LXI Consortium has devoted significant effort to developing instrumentation classes that define incremental instrument capabilities— not only based on specific instrument features, but also on how these features might be used in certain applications.

This viewpoint and methodology are somewhat of a departure from previous instrumentation standards that were more instrument-feature-centric with compliant instruments requiring an all-or-nothing adherence to the specific standard. The current LXI standard allows for incremental features by specifying three instrument classes, A, B, and C, which promotes the concept and flexibility of aligning instrument capabilities with classes of applications.

The three instrument classes can be viewed as a hierarchy of capabilities. Class C offers the basic communications capabilities associated with the Ethernet standard. Class B and Class A add capabilities based on features associated with IEEE 1588 precision timing protocol (PTP) and hardware triggering.

Figure 1 presents these capabilities and requirements for each class. The flexibility of the specification offers instrument vendors the option to provide both proprietary and compliant hardware triggering for Class C instruments.
 

Figure 1. LXI Device Class Hierarchy

Classes of Devices

Baseline Features and Requirements

All three instrument classes share a baseline of capabilities. These capabilities or features address required functionality in the areas of LAN communications, electrical, mechanical, web interface, and software for all LXI devices.

One of the expectations and goals of the LXI standard is to promote more compact instrumentation, which has resulted in the specification defining a half- rack configuration denoted as an LXI unit. However, the standard does not require that any compliant device, whether A, B, or C, be a particular form factor or size. As a result, the standard readily accommodates a broad range of form factors ranging from multi-U, IEC rack mount units to small, portable devices.

The flexibility of the standard allows instrument suppliers to adopt IEC 60297 for 19-in. rack-mount units or alternatively a half-rack configuration. This latter opportunity gives implementers the opportunity to adopt a defacto standard or use the LXI-unit standard as defined in the specification, providing a large amount of flexibility when establishing a mechanical package size and configuration.

In a similar fashion, the electrical and environmental requirements for any compliant device offer implementers a large degree of flexibility with respect to input power, indicators, and specific EMI, safety, and EMC requirements. For example, it is recommended that an instrument' s power configuration be single phase, but the specification does not exclude other options such as multiphase, DC, or even power over Ethernet (POE) configurations.
 

The standard recommends that LXI devices meet electrical and environmental requirements for their intended market, providing developers of LXI devices the flexibility to design a product based on customer needs without being overly constrained by a rigid specification.

All device classes use Ethernet as their communications interface and are designed to comply with IEEE 802.3 for both physical and function compliance. Required LAN features for all three classes include the following:

• A LAN configuration initalize (LCI) mechanism that provides the means to configure the LXI device to default network settings as well as some type of protective mechanism (time delay or mechanical) that prevents inadvertent operation of the LCI.
• A LAN activity indicator that can be a one- or two-color LED. The indicator, which identifies devices and LAN fault conditions, is located on the front panel of the device.
• Ethernet connection monitoring via Microsoft' s Media Sense implementation or via some other means.
• Capability to adapt to networks operating at an equal or lower speed than that of the LXI device with autonegotiation enabled as a default configuration.
• Support for the user datagram protocol (UDP), IPv4, and TCP/IP network protocols.
• Support for the Internet Control Message Protocol (ICMP).
• Support for three LAN configuration protocols: dynamic host configuration protocol (DHCP), dynamically configured link local addressing, and manual. Also, LXI devices must support either an automatic or manual configuration or separate configuration settings for each of the three LAN configuration protocols.
• Capability to detect a duplicate IP address and subsequently disconnect.
• Use of the VXI-11 discovery protocol and support for the stand-ard commands for programmable instrumentation (SCPI) query ' ' *integrated digital network (IDN)?' ' that allows all module classes to respond with manufacturer, model, serial number, and firmware revision number information.

There also are several other specific rules associated with the use of the DHCP that all modules must implement and support to ensure efficient and nonambiguous communications via the Ethernet.

With all LXI devices being network centric, integration of a Web page for each instrument is easily accomplished and required for all three classes. For each instrument class, information about the instrument and LAN configuration is presented on a Web welcome page and a LAN configuration page. Information for the two respective pages includes the following:

• Host name, instrument model, manufacturer, serial number, LXI class, LXI version, TCP/IP address, medium access control (MAC) address, and software/firmware version.
• Host name, instrument descriptor, TCP/IP configuration mode, IP address, subnet mask, default gateway, and domain naming system (DNS) server(s).

All LXI devices adhere to the same set of software standards that requires each instrument to have an IVI-specific driver. If the LXI instrument matches with one of the defined IVI instrument classes, then the LXI driver will be IVI class compliant as well.

In addition, all drivers will be registered with the IVI Foundation. Additional driver requirements are imposed on Class B and A devices to support triggering capabilities.

Class C Devices
The baseline set of capabilities suggests that a broad range of current and new instruments could be converted or implemented as LXI Class C devices. For instruments that currently support an Ethernet communications interface, the conversion could involve firmware and software upgrades to address the requirements for a Web interface, an IVI driver, and support for the prescribed LAN communications standards.

In addition, any proprietary triggering mechanism used by the instrument can be retained since there is no requirement to adopt the LXI triggering or synchronization features for Class C devices. In fact, even for Class A and B devices, a proprietary triggering scheme can be used in addition to the defined LXI triggering mechanisms.

Non-rack-mount devices, including WLAN-based devices or stand-alone remote units such as those used in autonomous distributed test, process control, or data acquisition applications, also are excellent candidates for deployment as Class C devices. Again, with minimal additional requirements beyond the core set of LAN, Web, and driver requirements, these devices can be implemented in a variety of sizes and shapes, which in turn, allows these devices to take full advantage of the flexibility and ubiquity of a LAN-based network.

Class B Devices

Class B LXI devices retain all of the features of a Class C device while providing expanded triggering capabilities by supporting direct LAN messaging for module-to-module triggering as well as supporting time-based trigger events. The addition of LAN-based triggering is made possible by incorporating the features of the IEEE 1588-2002 PTP, which provide the means to distribute a precision timing source across many LXI devices and subsequently the capability to create precision trigger events for all participating LXI devices based on a common coherent time reference.

Typically, a timing accuracy of 10s of microseconds to 10s of nanoseconds can be realized. The exact details and implementation of this standard are topics all on their own, but for the purposes of this article, it is sufficient to understand that IEEE 1588 PTP provides the means to create relatively precise trigger events in absolute time via the LAN communications channel.

Implementation of IEEE 1588 PTP can be done by dedicated hardware or in software. However, for instrumentation purposes, a software implementation is discouraged due to concerns associated with the level of timing precision that can be achieved.

One of the two trigger modes made possible by IEEE 1588 PTP is the direct LAN message mode where a data packet containing triggering and a time stamp is sent to another LXI device via the LAN interface. Implementation of this functionality relies upon the use of UDP multicast for point-to-multipoint applications or TCP for point-to-point transports.

Even though Class C modules do not have the capability to assign a time stamp to a data packet since they don' t incorporate IEEE 1588 PTP, they still can participate in intermodule communications by inserting a time-stamp value of zero, which will indicate that a measurement action is to start now.

The second LAN trigger mode allows a Class B device to generate a precise, time-based trigger event by relying upon the coherent time base established by IEEE 1588 PTP. In this case, a trigger is generated based on a predefined absolute time value. This capability works well for applications requiring the coordination of actions at precisely scheduled times using only the LAN communications channel.

With LAN triggering and hardware triggering for Class A devices, additional software driver functionality is required to support the various triggering modes. Overall trigger functionality includes the capability to uniformly map a trigger event to any of the trigger transport mechanisms. For example, a software trigger function via the driver also can be implemented via the direct LAN message mode or a time-based trigger event.

Figure 2 shows a simplified trigger model for LXI classes A, B, and C. For Class B and A devices, the LXISync Interface Specification defines the application programming interface (API) required to support the LXI uniform trigger model.

Figure 2. LXI Device Trigger Model

Figure 2 shows a simplified trigger model for LXI classes A, B, and C. For Class B and A devices, the LXISync Interface Specification defines the application programming interface (API) required to support the LXI uniform trigger model.

Table 1. Sync Configuration Web Page Parameters

Web page support also is required with the addition of LAN and hardware triggering capabilities. Table 1 provides a summary of required parameters supported by the Sync Configuration Web page for Class B and Class A devices.

Class B devices offer the opportunity to coordinate measurement and stimulus functions very precisely in time even when the measurement/stimulus components are not in close proximity to each other. An application might involve multiple devices on a factory floor that are monitoring/controlling a process and required to make measurements or corrections at a precise point in time or in near real time.

Using the IEEE 1588 PTP facilities, Class B devices can perform measurements precisely in time by using the time-based trigger-event facility. This functionality is accomplished by communicating to all devices via the LAN interface, an absolute time or sequence of times for the creation of a measurement trigger or triggers. Since all LAN devices that subscribe to the IEEE 1588 PTP functionality have a common, coherent sense of time, all measurements will be performed based on a common time base and specific transmitted time-stamp values.

Use of the direct LAN message-triggering mode allows precise control of measurement events. For example, the occurrence of an event might require the acquisition of data before and after the specific event. In this case, the measurement device, which might be a digitizer or digital instrument, could be continuously acquiring data.

With the occurrence of the LAN trigger transmitted with a time stamp to the second instrument, the acquisition instrument then can align the acquired data with the initial trigger event, providing an exact view of measurement events leading up to and after the event. The result is a triggering facility that can be deployed over extended distances via the LAN interface while maintaining excellent timing precision.

Class A Devices

Class A LXI devices incorporate all of the features found in Class B and C devices plus a hardware triggering facility. Three different trigger configurations are specified: daisy chain, star, and hybrid star, all of which are implemented using an eight twisted-pair bus and M-LVDS technology. Figure 3 details the three configurations.
 

Figure 3. Wired-Trigger Configurations

The daisy chain configuration supports a variety of applications that require the robustness and repeatability of hardware triggers but not the precision or flexibility afforded by a star-trigger configuration. The star-trigger configuration not only provides the repeatability of hardware triggers, but also ensures that all trigger events are received at essentially the same time by each receiver. In addition, the star-trigger hub has the means to not only equalize trigger delays, but also to provide a flexible cross-point switching mechanism for cross connecting LXI trigger bus lines.

The hybrid star configuration, which combines features of both the daisy chain and star configurations, may be most appropriate for large systems or systems with a diverse set of trigger requirements or that require a high degree of reconfigurability.

For each LXI Class A device, two trigger bus connectors wired in parallel are required to facilitate the implementation of a daisy chain segment connection. The implementation of the hardware trigger bus requires terminators at each end of a trigger line segment with a maximum of 16 LXI devices being connected to any one segment.

For each trigger line, two drivers and one receiver are needed with their configurations determined by the trigger bus mode. Two trigger configuration modes are supported:

• Driven Mode: This configuration supports the transmission of a trigger event to one or more receivers connected to the same trigger bus line. For this mode, one driver and one or more receivers are connected to each trigger line of interest.
• Wired-OR Mode: This configuration supports a multipoint-to-multipoint mode of trigger transmission. More than one trigger source can initiate a trigger, and multiple receivers can receive the generated trigger event. When a trigger line is configured for the Wired-OR Mode, a single driver associated with an LXI trigger receiver must be configured as a bias source, and each trigger source uses two drivers in parallel to drive the trigger line.

Additional required functionality for the LXI trigger bus includes the following:

• Routing of all eight trigger lines to each trigger function contained within a module, which provides maximum flexibility when allocating trigger lines for a specific function.
• Simultaneous drive/sense on each trigger line.
• Configurable edge or level detection for each trigger line.

The addition of the trigger features for Class A and B devices requires that these instruments support the LXIsync API and the associated trigger model. The model, which includes the concept of an arming and triggering state machine, takes into account all trigger sources and allows LAN, driver, or hardware triggers to be mapped to a specific measurement function. This unified approach to triggering presents a consistent set of functions and capabilities for Class A and Class B devices as well as a high degree of trigger flexibility and options.

Class A devices provide users and instrument suppliers with the capability to create instrument subsystems that are linked by hardware triggers. A typical application might be the creation of a synthetic instrument, which comprises several source/measure components with coherent intermodule clocking and triggering supplied by LXI trigger lines.

In addition, time-critical communications among several remotely located subsystems may be required which could be implemented by using the direct LAN message mode of communications. The capabilities of Class A devices and the associated flexibility of the LXI trigger model also allow for the use of hardware or LAN triggers for initiating measurement events, which provides an added level of flexibility for distributed measurement or data acquisition systems.

Summary

Defining three distinct LXI product classes offers the flexibility to produce and deploy products that satisfy a specific set of requirements without incurring excessive cost or complexity. In addition, the capability to offer a LAN-based product without IEEE 1588 PTP will help accelerate acceptance of the standard and promote the development of LXI products. And as the standard matures and becomes more widely accepted, you might not only see Class A and B devices, but also the upgrading of current Ethernet-based instruments to Class C devices. 

About the Author
Mike Dewey, the marketing product manager at Geotest-Marvin Test Systems, has been active in the test and measurement industry for more than 20 years and held various positions in design engineering, engineering management, marketing, and product management with GenRad/Teradyne, ADR Ultrasound, and Motorola Government Electronics Group. He is a member of the IEEE and has served as a board member for both the PXI System Alliance and the VXI Consortium and been an LXI Consortium advisory member on both the technical and physical working group committees. Mr. Dewey received a B.S.M.E. from Syracuse University and an M.S.E.E. from Georgia Institute of Technology. e-mail: miked@geotestinc.com

PDF of this article

Back to Top

Embracing LXI for Switching
By David Owen, Pickering Interfaces

Signal management, the use of switching systems to route instrumentation and stimulus to appropriate test points on a UUT, has a very crucial role to play in most electronics tests. The sharing of resources, connection of calibration references, and load management are among the many functions controlled by signal management.

PXI has proven to be an excellent basis for switching products. Although the PXI form factor is small, the development costs are low once the initial entry barriers have been crossed. Speed of development is high, enabling a large variety of standard and custom switching solutions to be made available in response to user demand.

PXI is mature and has been widely adopted in the test industry. Not only does it offer very fast communications interfaces for the exchange of large blocks of data that may be needed for analysis by the system controller, but it also imposes mechanical and power restrictions on the modules.

Not all users want their instrumentation or switching products to be extensions of their PC' s PCI bus or for the data analysis to be performed in the PC rather than the instrument. Although it has been hugely successful, PXI has not displaced the majority of rack or bench instruments.

GPIB instruments have had their control interfaces supplemented more recently by a LAN connection that can be used as an alternative control mechanism. Ethernet connections are ubiquitous on system controllers, and the connection cables are easily managed and have a latching mechanism and virtually no restrictions on distance. However, there was no agreed-to standard for controlling an instrument through a LAN connection, so users found that manufacturers solved the problems differently.

This is rather like the situation 30 years ago when GPIB was introduced. No two manufacturers did things the same way. As occurred on GPIB, a more cohesive approach now is being taken with LAN-based test instruments.

Standardization of LAN connections for instrumentation is taking a major leap forward following the introduction of the LAN eXtensions for Instrumentation (LXI) standard. It defines LAN-controlled instruments that behave in a similar and consistent way when they are connected to a network. Each instrument has its own web interface that can be used to set up the instrument and report its status. An IVI driver on the client PC provides programmatic control of the LXI device over the LAN interface.

In most cases, LXI devices are considered to be self-contained: They have their own power source, LAN connector, and case. They are intended to be small compared to their bench-instrument versions and controlled from an external controller, so generally they have no front-panel user interface.

The standard recommends that user connections be on the front of the instrument and power and LAN on the rear. An LXI device providing this level of performance is referred to as a Class C Device. It meets all the essential requirements of the LXI standard.

Two more classes of LXI devices are intended to provide more deterministic response to trigger events. The Class B devices include a timing facility based on IEEE 1588 that allows users to trigger events in the system at specified times including immediately. This can be used to make the LAN timing of measurements more deterministic, permitting timing accuracies of a few 10s of nanoseconds to be achieved.

A Class A device includes both the IEEE 1588 features and a wired trigger interface that can be used to physically connect instruments together with an eight-wire-bus trigger interconnection. This provides a more deterministic way of responding to trigger events since only internal hardware and cable interconnect delays affect response times.

Comparison of LXI

There has been speculation that PXI and LXI are competing standards. In many ways, the standards are sufficiently different that the case will be clear when one is better than another for a particular solution. Table 1 illustrates these differences for both switching and instrumentation applications.

For LXI, instruments are largely platform agnostic whereas PXI is very dependent on the PC architecture. LXI devices do not have many mechanical or electrical constraints, but PXI modules must conform to the PXI standard to benefit from the multivendor chassis platform.

Table 1. Functional Comparison of PXI and LXI

They also can have quite different speed drivers. Although PXI has the faster connection speeds, it relies on processing data in the controlling PC so it inherently needs a high-speed interconnect for some functions. An LXI system might be expected to process data within the LXI devices and simply has to report the results.
 

For switching, speed differences are of little consequence because, in practice, the speed of change of switching systems is constrained by mechanical components. The mechanical and electrical constraints of PXI can influence the upper limit of what can be cost-effectively supported, but the cost overheads of an LXI device can limit the minimum functionality that can be reasonably implemented.
 

As ever, one standard does not fit all.

Getting LXI to Market

Revision 1.0 of the LXI standard now is available, and the LXI Consortium is working on more revisions to cover additional areas and improve the existing content. All new standards face a period of time when companies seek to launch products conforming to the standard as quickly as possible to encourage users to embrace the new technology. But it takes time before a new standard has the breadth of product availability of legacy standards. Lack of availability of a wide range of products can act as a deterrent to being able to move, for example, from GPIB to LXI.
 

Pickering Interfaces has a very large range of PXI switching products that has been developed in the last seven years and a smaller range of older designs housed in a GPIB chassis. We recognized that PXI was the natural answer to the switching needs of a significant number of users. But there are many other users who would prefer to use a different control method that provides a barrier between the system controller and the switching hardware.
 

Redeveloping the breadth of PXI switching products as LXI products would create many years of effort in both hardware and software. For that reason, we have leveraged the existing PXI switching products by building a PXI chassis with an LXI interface. This approach provides a new switching product for either format whenever a suitable module is introduced.

Where Does LXI Fit in Terms of Switching?

The use of the LXI architecture for switching makes sense for many test applications. In the area of legacy test systems, where a migration path to newer systems is planned, LXI can be selected to replace older GPIB-based switching subsystems. From a software standpoint, there is no easy answer to migrating older test programs. However, modern software does make the change more manageable.
 

LXI-based switching simplifies PCI bus enumeration because the LXI device is not on the PCI bus. As a result, powering down the switching system will not force rebooting of the controller when maintenance, upgrades, or experimentation are required.
 

When compared to a pure PXI switching application, the controller for LXI switch systems can be far less intelligent and expensive because the application is slower and less bus intensive. In this instance, the LXI device does not need a fast controller. For that reason, the overall costs of a switch system based on LXI can be lower than an equivalent PXI implementation requiring an embedded controller or a PC-to-PXI control interface.
 

If the system requires the tight integration of switching and instrumentation with high data bandwidth demands in the same chassis, then PXI implementations may be favored.

Symbiosis in Test

With the broad range of switching available in PXI, it does not make sense for a vendor to replicate the entire catalog in another architecture. A gradual evolution is called for, which provides a breadth of offering immediately and allows new markets to be addressed by an existing architecture. If an LXI device could accept products from another architecture, it would create a new market and very quickly. This symbiosis will likely be seen in instrumentation as vendors add an LXI interface to existing products.

An example of such an implementation for switching is shown in Figure 1. The hardware provides a means of physically controlling the PXI modules installed in the backplane. For external control and monitoring, LXI requires a standardized programming interface (IVI) and web interfacing.
 

Figure 1. LXI-to-PXI Interface Module

The control route taken to support the PXI modules is shown in Figure 2. The client PC has an installed driver and discovery software that communicate through the client Ethernet interface to the chassis. The Ethernet interface, discovery server, and web server interface to the control software that, in turn, controls the PXI modules.

Figure 2. Functional Representation of Control Interface

The drivers include IVI-compliant custom and class drivers that communicate through the Ethernet connection using a proprietary command set. The control subsystems then manage the connection and handle the physical interface to the PXI cards.

Physically, the chassis implements these control and management functions on a single-board embedded PC using flash memory cards to avoid the problems of supporting hard drives, also ensuring that the program information remains intact even if unexpected power interruptions occur. The embedded PC has a PCI interface connected to the PXI backplane through a bridge, making the PXI modules appear as an extension of the embedded PC' s PCI bus.

Only a small proportion of the internal flash memory is used for system functions, leaving room for the memory to be loaded with other data, including the drivers, manuals, and data sheets related to the products installed in the LXI chassis.

What About the Future?
This approach will have a long service life because it is not simply a temporary measure to provide LXI products quickly. As new switching modules are introduced in PXI, they immediately become available in LXI. It will serve as an incentive to develop modules that can be used in either environment.

The engineering investment is spread across both platforms, making it possible to continue to develop low-volume products and higher volume products to the same physical and electrical standards. Users will benefit because they do not have to make the choice of what switching platform to use simply on the grounds of product availability.

Other versions of this concept can be introduced with more available slots as well as 3U and 6U implementations, so that more diverse applications or more complex switching modules can be included.

Conclusion

LXI-only products will be developed, particularly in areas where LXI has a technical advantage over PXI because of its relatively high mechanical and electrical freedom compared to PXI. However, PXI has many advantages where there is a need for a mixture of switching functions that can be densely packed in a chassis. For many applications, the choice is staying with a PXI environment or operating the modules through an LXI environment.
 

The future is bright for both PXI and LXI standards supporting switching functions in test systems.

About the Author
David Owen is the PXI business development manager for Pickering Interfaces. Over the last 25 years, he has held key engineering, product management, and strategic marketing positions with Marconi Instruments, then IFR, and now part of Aeroflex. Mr. Owen is the innovator of more than 10 patents in the field of RF signal generation and analysis and currently involved in the evolution of the PXI standard. Pickering Interfaces, Stephenson Rd., Clacton-on-sea, Essex, CO15 4NL U.K., 011 44 1255-687900, e-mail: david.owen@pickeringtest.com

For More Information

on LXI switching solutions

www.rsleads.com/613ee-176

PDF of this article

Back to Top

Exploring LXI' s Advanced Capabilities

By Paul Franklin and Andy Creque, Keithley Instruments

The new LAN Extensions for Instrumentation (LXI) specification promises to shake up test and measurement applications. When combined with the latest generation of instruments, LXI-based systems can perform advanced test and measurement functions that are difficult to accomplish with non-LXI-based test systems. Rather than building the specification around a particular architecture, the LXI Consortium focuses on specifying a scalable framework for integration and interoper­ability that accommodates a wide range of test and measurement equipment, from simple modules and synthetic instruments to complex, high-performance instrumentation. The LXI specification addresses standardizing interfaces and defining a suite of services to construct systems with an architecture optimized for the application.

LXI can cope with limitations of common test and measurement system architectures in several ways. First, by using Ethernet LAN for device interconnection, LXI systems do not impose a limit on the number of interconnected devices. Connections can be made more easily and inexpensively than with GPIB, USB, or serial connections. Plus, an existing Ethernet infrastructure, combined with the fact that Ethernet interfaces are included in virtually all computers, eliminates the expense of add-in interface cards.

Ethernet interfaces also scale well. A minimal LXI-compliant Ethernet interface costs little to im­plement, making it suitable for simple devices. However, high-performance Ethernet interfaces can be implemented when required, with low-speed and high-speed devices working together seamlessly.

Ethernet also can easily support physically distributed systems while gigabit and multigigabit Ethernet networks accommodate large data sets and high data rates. The number of controllers in a large system can potentially be reduced because there' s no requirement for devices and their controller to be in close proximity as is true with rack-based solutions with GPIB and USB implementations. 

Measurement System Architectures

Single PC Systems
In a single PC-based architecture, the PC connects to the test and measurement equipment in a variety of ways with IEEE 488 currently most prevalent but also with serial, USB, and other interfaces (Figure 1). Less demanding applications need only the PC to acquire and store measurement data.

FIGURE 1. Single PC-Based Architecture

 
More sophisticated applications use the PC to sequence through a series of test steps; acquire, process, and analyze the data; and present the results. The PC provides additional processing power for acquiring and analyzing large data sets and presenting results. Complex and interleaved sequences can be executed because the controller is connected to all the instruments.

The PC sends commands to instruments when they are needed so the measurements and the sequence in which they are performed can be altered dynamically to respond to real-time events such as the results of previous measurements. It also has access to data from the instruments so the data can be combined, processed, and analyzed as needed to give meaningful results.

However, this architecture has some limitations for larger and more complex applications. Specifically, the number of instruments or channels in the system is limited by the physical capacity of the controller connection. And because all the data and commands flow through the communications channels of the controller, the maximum data set size and data rate are bandwidth limited.

Additionally, the complexity of the application software and the difficulty associated with developing, testing, and maintaining the application increase rapidly with system size. This is largely because the program has to manage the sequencing and timing while keeping data sets properly aligned and correlated.

Without complex programming techniques to achieve pseudo-parallel operation, much of the system remains idle while the controller services other system components, reducing efficiency and decreasing throughput. Finally, in the case of GPIB, USB, and other dedicated communications interfaces, all of the equipment must be located in close physical proximity because of interconnection limits. Rack-based or card modular solutions are even more constraining.

There are drawbacks to this architecture for smaller, simpler systems as well. Adding a PC or workstation to a system to coordinate a few instruments for the purpose of performing a simple sequence of tests is overkill.

Although the cost of a simple PC is low, it requires space, power, and maintenance. It also increases integration effort and may not be justified by the application. Add the effort and expense of developing the software for the PC, and this becomes an even less attractive solution for small, simple systems.

Multicontroller Systems
Adding more processors is one common technique to avoid the problems of the single-controller architecture for larger or physically distributed systems or systems that must handle large data sets and/or high data rates. Extra processors add capacity in terms of channel count and control and data bandwidth.

Dividing the system into sub­systems reduces software complexity and develop­ment effort because each sub­system is concerned only with its part of the system. The subsystems can each have an independent processor for parallel or concurrent operation. Plus, if subsystems are networked together, they need not be close to one another.
 

Such a multicontroller system addresses many of the limitations of single-controller systems. It can be scaled upward to accommodate virtually any number of channels, data set size, or data rate and physically distributed as needed by the application.

Multicontroller configurations do have some limitations that have less to do with the architecture and more to do with the implementations currently available to test and measurement engineers. There are two main ways to implement subsystems: with a PC or workstation with an attached cluster of GPIB-, serial-, or USB-connected instruments; or through PXI, VXI, or other card-modular-based solutions (Figure 2).
 

FIGURE 2. Multicontroller System Implementation

Sometimes either solution can be overkill, particularly if the mini­mum subsystem is too big for the application. This results in an implementation that doesn' t scale downward well.

Exploring Advanced Capabilities

While existing architectures can be implemented with LXI devices, LXI has no implicit or explicit requirement for a traditional controller that is part of the test system. From the standpoint of the network connections, LXI devices are peers; any LXI device can send messages directly to any other LXI device without the need for a traditional controller.

 
LXI uses peer-to-peer communications for the LAN trigger capability, which is required for Class A and B LXI devices and optional for Class C devices. An LXI device can send a trigger message over the LAN to one or more LXI devices. This provides a synchronizing capability analogous to hard-wired trigger lines in conventional instrumentation but without the physical distance limitations of hard-wired signals. Of course, LAN triggers have different timing characteristics than hard-wired triggers, but they offer a viable option for physically distributed systems where hard-wired triggers are impractical.

LAN triggers also can be used in nondistributed systems with less stringent timing requirements. Here, LAN trigger performance is acceptable and saves the effort and expense of connecting hard-wired triggers.

The LXI specification recommends that devices implement a uniform trigger model to increase the usability of LAN triggers and all other triggers to reduce integration effort. With a uniform trigger model, an instrument action can be initiated by one of several different trigger events.

For example, if an LXI device has three actions that can be initiated in response to a signal received on the LXI hardware trigger bus, then LAN trigger events, IEEE 1588 time-based trigger events, or IVI driver trigger functions should be capable of initiating those same three actions. The LXI standard also recommends that a trigger event be able to initiate multiple trigger actions to further increase flexibility.

This uniform trigger framework gains added power when implemented by an LXI device that is programmable, for example, one that supports an embedded scripting language. With a script-processing device, users can specify a test script of arbitrary complexity that' s executed in response to any type of trigger event or several test scripts each of which is executed in response to a different trigger event. Test scripts also can be changed on the fly if necessary to reconfigure the test system dynamically in response to application-dependent conditions.

For script-processing devices, the inclusion of an arbitrary payload within an LXI LAN trigger message provides even greater flexibility. This payload could be a short test script— a piece of executable code— that' s executed upon receipt of the message. It also could be the name of a longer test script that' s preloaded into the target device and then executed upon receipt of the message. These LXI features, when used with a script-processing instrument, provide a powerful, flexible, and extensible way for LXI devices to interact with test systems and applications.
 

New Architecture Options

Because LXI doesn' t require test systems to include a traditional controller and defines peer-to-peer messaging and triggering capabilities, users have new test-system architecture options.

Figure 3 shows a simple test system with two programmable LXI instruments and a DUT. The instruments are programmable with the application programs loaded into the instruments. The instruments can use LAN triggering to coordinate their actions. Results can be displayed on the front-panel user interface or Web pages or transferred to another system over the LAN.

Figure 3. Simple LXI System Implementation

Figure 4 shows a variation of the test system shown in Figure 2 with one of the subsystems replaced with the simple test system from Figure 3. Figure 4 illustrates how LXI instruments with script processing can improve system scalability by eliminating the need for a separate controller for each subsystem.

Figure 4. Multicontroller System With LXI Implementation

Application Examples

Some example systems help illustrate the advantages of LXI' s new architecture options.

A Production Test System
In a production test system, two instruments are connected to a test fixture. The test fixture includes a handler mechanism that rapidly feeds a stream of devices through the fixture for testing.

Several different types of devices can be tested, and the stream consists of randomly mixed types. Each type requires different test steps and parameters from both instruments. The first instrument performs a single measurement at the start of the test to determine the device type, which then defines which tests must be performed.

A conventional test system adds a controller to the two instruments, the test fixture, and the handler. At the start of the test, the controller transmits commands to the first instrument to identify the device and read back the result. The controller then sends the proper streams of commands to both instruments to control the test based on the device type. The command streams to the two instruments would have to be properly interleaved and synchronized by the controller.

Alternatively, an LXI-based test system using script-processing instruments will not require a controller. Each instrument can be given its own identity and behaves as a smart instrument without relying on commands from an external controller. Each instrument can hold variables, handle conditional events, and initiate external events. And instead of a general-purpose DMM, the function of the instrument can be defined to meet the specific needs of the application.

At the start of the test, the first instrument identifies the device and sends the type to the second instrument using a LAN trigger. Both instruments would now run the proper test based on the device type, using additional LAN triggers for synchronization if required.

Compared to a conventional design, the LXI system can operate much faster. LXI instruments can run at their maximum speed since no delays are incurred while waiting for the proper instructions to be sent from the controller to the instruments. If the tests require many instructions, the time saved can be substantial.

Eliminating the controller, associated integration, and interconnections also can represent a significant cost savings. Finally, the programming is simpler and requires less effort because the implementation is broken into small, relatively independent sections.

A Scientific Experiment
A scientific experiment designed to detect the presence of a type of cosmic particle also can benefit from an LXI-based system. In this system, a large tank is equipped with hundreds of widely separated detectors, each connected to a script-processing LXI instrument.
 

Any of the detectors can sense a particle event, which occurs very infrequently, but can be identified by analyzing the signal from the detector. When an event occurs, the system must record the measurements from all the sensors for the period beginning right before the event and continuing for several seconds after the event. Each sensor must be sampled at 100,000 measurements/s. The instruments are networked together and to a central controller.

Several of LXI' s advanced capabilities are useful in this example, including the IEEE 1588 precision time protocol and LAN triggers. In an LXI-based solution, once the experiment begins, each instrument starts sampling the sensor at the required rate, storing readings in a circular buffer so that the oldest readings are overwritten after 30 s. Each reading is time stamped with the IEEE 1588 synchronized clock.

The script running on the instrument examines the data in near real time to determine if a particle has been detected. When one of the instruments detects a particle, it immediately sends a LAN trigger to all other instruments, which includes the time stamp indicating the start of the event.

Upon receiving the LAN trigger message, each instrument stops sampling the sensor at the time of the event plus 5 s, freezing the desired data in its buffer. The central controller also receives the LAN trigger from the instrument that detected the event, and the controller begins collecting the relevant data from all the instruments. Once the data is collected, the controller notifies all the instruments to restart the test.

The LXI-based solution uses LAN triggers for synchronization and control, and IEEE 1588 synchronized clocks provide the precision time stamps needed to realign the data in the controller when an event is recorded. Because the instruments have script-processing capability, they can monitor the data in near real time, discarding all the data except that related to the event of interest. In the traditional approach, the data from all points would have to be sent to the central controller, which then would analyze and identify the relevant data and discard the rest.

Given the large number of sensors, the large data set, and the high data rate, a traditional design approach is inefficient and wastes resources. In the script-based scenario, each data collection point can analyze the data and send only the relevant information to the central controller.

The capability for an instrument to execute a script and then filter and compress the data stream dramatically reduces the amount of data transferred over the network. A modular instrument-based solution could handle the required processing as well, but the wide physical separation of the sensors means each location would require a rack and controller, creating a very expensive solution.

A Script-Processing Prototype
A prototype test system illustrates the performance of some advanced LXI capabilities. The prototype hardware is a commercially available development board equipped with an Intel PXA255 Microprocessor running Windows CE 4.20. A small C application using Windows sockets performed the testing and recorded the results.

The prototype also implemented a commercially available embedded scripting language. The controller side of the system was simulated using a Pentium M, 1.4-GHz notebook PC running Windows XP. Another small C application performed the controller side tests. All timing was verified using an external LAN analyzer.

LAN Trigger Performance
Tests were conducted to measure the time required for a LAN trigger packet to be transmitted from the controller to the prototype under various conditions. Table 1 describes the tested combinations and results.

Table 1. Time to Send LXI LAN Trigger Packet From Controller to Device

The results show that the time to transfer a single LAN trigger packet with minimal data payload averages slightly less than 0.6 ms for the prototype system. The variables of network traffic, network speed, and protocol type have little effect on the result.

When the packet size is increased to 512 B, there' s greater impact due to the variable factors, with the most