The LXI Standard and Its Evolution

Email this article to a friend

  By David Owen, Technical Chair, LXI Consortium, June 2012

The LXI specification has gone through changes and continues to evolve as the market demand for Ethernet (LAN)-controlled instruments grows. Specification evolution is a healthy response because it ensures that specifications continue to be relevant and customers can get better products for their needs.

LXI products were introduced in December 2005. Since that time, more than 1,700 products have been certified from more than 30 different vendors covering a wide range of product types and capabilities.

Changes From Version 1.3 to Version 1.4

In that intervening time, there have been two major revisions of the standard: Version 1.2, which introduced the mDNS discovery mechanism; and Version 1.3, which changed the version of the IEEE standard from 1588-2002 to 1588-2008 to reflect the migration on the precision timing protocol.

In that time, products that conformed to the 1.1 standard have continued to work almost seamlessly with products that are compliant with later versions of the standard, the major exception being the issues raised by IEEE 1588 migration. The latest revision of the LXI Standard (1.4) has now been published and maintains that backward compatibility. So what has changed?

LXI Standard V1.4 has largely editorial changes that have a dramatic effect on how the standard is organized and the migration of products that are compliant to it. It also paves the way for further additions to the standard to reflect the migration of the Ethernet and IVI standardization efforts.

Structural Changes

The most significant change to the specification is the reorganization into technical, compliance, procedural, and information documents to make the management of the standard much simpler. Previous versions of the standard included much of this detail in a single document. Version 1.4 breaks these aspects apart so that one document can change without affecting a much larger specification. This is particularly true of the key technical documents. Changes in procedural matters or compliance regime, for example, can be made independently of the technical part of the standard.

The new version has three key technical documents that set how compliant products implement the standard:

  • The LXI Device Specification 2011 contains just those aspects of the standard that impact the LXI device itself (the major part of the standard).
  • The LXI Wired Trigger Bus Cable and Terminator Specification describes how  cables and terminators are implemented and how they are tested for systems that use the wired trigger bus (WTB).
  • The LXI Identification Document provides the schema for identifying the device capabilities.

The latter documents have existed since Version 1.2 of the standard but have been updated and, in the case of the trigger bus, restructured.

Introducing Extended Functions

Previous versions of the standard included a class model for LXI devices: Class C covering basic LAN issues, Class B supporting Class C functionality as well as features such as IEEE 1588, and Class A supporting Class B features plus the WTB. This class structure forced vendors who were interested in Class A functionality to also be Class B compliant. Most equipment vendors have found that, despite the fact there are some compelling examples of test systems solving problems with the use of IEEE 1588, complying with the Class C requirements satisfies a majority of customer needs.

With Version 1.4, this class structure has been removed. Instead, a core LXI specification is defined with a set of five optional extended functions, including both IEEE 1588 and the WTB normally associated with the old class model. The standard also has added other extended functions as separate stand-alone documents with minimal impact on the core LXI device specification.

Options are easily added to this modular specification structure. The newest addition is a function that defines how LXI devices adopt the HiSLIP standard. HiSLIP was introduced by the IVI Foundation and provides faster message-based control and an alternative discovery mechanism to VXI-11. The latter will become a significant issue for many Ethernet-based instruments since VXI-11 cannot be supported on IPv6 networks. This extended function has now been published, and the consortium is expecting the first implementations soon.

Not surprisingly, the next extended function then will be an LXI implementation of IPv6. As the world runs out of IPv4 addresses, IPv6 will become more common, and LXI has to be prepared for this change. Initially, it is unlikely it will have much impact on how test systems are put together on local networks (which will probably still be IPv4). However, with governments starting to require IPv6 support for all Ethernet-enabled products, it is crucial to get a standard framework in place that is well tested before it becomes an essential requirement. Work now has been completed and, as of press time, IPv6 is in the formal review period before adoption.

Eventually, some of these new extended functions might become requirements for inclusion in future revisions of the Core LXI Device Standard. By the time they reach that point, the functions will be well tested by both vendors and users with well-proven implementations, and this will make migration of the standard a much simpler and problem-free experience. It is likely, for example, that one day IPv6 will be a requirement of the standard while other requirements, like VXI-11 discovery, will become optional functions.

Of course, for users of LXI instruments, 1.4 will change the way you order LXI devices. New products conforming to 1.4 no longer will be listed as Class A, B, or C.

Conformance Testing

LXI has taken a route of requiring that all products are conformance tested prior to introduction to the market. This ensures users get a consistent experience of using LXI products and prevents any coexistence issues between different vendors’ products being in a system.

This implementation consistency has served the users and the LXI Consortium well. It gives users confidence and provides a way of tracking product introductions through the consortium’s website. The consortium has invested considerable effort in this conformance regime to ensure that tools are provided to the vendors to maximize the chance of first-time passes at testing time.

Version 1.4 maintains this conformance regime. LXI devices must be tested by third parties unless the vendor is able to state that it is a derivative product on an existing platform, referred to as the Technical Justification route. With the introduction of Version 1.4, vendors now are required to demonstrate they have tested the derivative product using the LXI Consortium’s test suite, which is freely available to members of the consortium.

This reinforces the message that LXI is a well-tested standard with high confidence that all LXI marked products work well with each other and behave in a predictable way on an Ethernet network. IT managers will have nothing to fear from putting LXI instruments on a corporate network should the application require it—the LXI products will behave in a responsible way.

In 2012, there is another change to the Technical Justification approach. Vendors no longer will be able to use Technical Justification to introduce new versions of products that conform to Version 1.2 or 1.1 of the standard. Only applications to 1.3 and 1.4 will be allowed.

Other than the disappearance of the class models, the differences between Version 1.3 and Version 1.4 for an LXI device are relatively minor. From a user standpoint, the two versions are very closely aligned. This change in conformance regime is intended to increase the use of mDNS discovery and IEEE 1588-2008.

For WTB cables and terminators, the conformance regime remains the same as in Version 1.3. Vendors are required to declare their products are constructed in accordance with the specification.

It is possible that, at some time in the future, the conformance regime for LXI devices might change to allow vendor testing; however, so far, experience indicates it may be a while before such a change can be made. Unlike Version 1.3 of the standard, in Version 1.4, such a conformance regime change can be implemented without affecting the technical documents.


The introduction of the 1.4 LXI Device Standard will not change the way products work very much, but it does ensure the LXI Standard is well placed to migrate with the evolution of Ethernet standards and to add features in response to market pressure. It will result in a stable core specification with optional features being added, implemented by vendors, and tested by users before consideration of integration into future revisions of the LXI Device Standard. Version 1.4 has set a stable platform for the easy management of the standard and its migration, ensuring a long and successful future in test and measurement.

So what is the bottom line to users? With Version 1.4, they select the product by the core (essential) requirements and added functions rather than by classes. LXI remains a stable and efficient test platform that can evolve in the future without revolutionary changes. That ensures users know they can invest in LXI platforms without fear of major changes—ensuring a long and stable platform life.

About the Author

David Owen is the technical chair of the LXI Consortium and business development manager for Pickering Interfaces. Previously, he held key engineering, product management, and strategic marketing positions with Marconi Instruments, then IFR (now part of Aeroflex). Owen was the named innovator of more than 10 patents in the field of RF signal generation and analysis and has written many application and technical support notes for signal generation and signal switching and management.

Editor’s Note

This article is adapted from an updated version of material appearing on the Pickering Interfaces website. More information about the LXI Standard can be found at

Tags:  Instrumentation