For 25 years, the VME architecture defined COTS systems that met the demand for increases in computing and connectivity. Successive generations of new processors provided more and more compute cycles, while VME bandwidth evolved in a similar fashion from 40 Mbytes/s on the original VMEbus to 80 Mbytes/s, then 160 Mbytes/s and finally 320 Mbytes/s on 2eSST.

Structure and draft state of the VITA 46 (VPX) specification as of March 2009.

VME was also proven to be flexible in supporting a range of system sizes and many levels of ruggedization. In its familiar 6U form factor, VME found its way into small 6-slot chassis and large 21-slot systems, as well as a great many ATR and ½ ATR configurations. VME systems were created with environmental specifications running the gamut from benign commercial to almost MIL-SPEC.

A great strength of the VME community was the ability to combine technologies from many contributors into high-performance systems. This was possible because VME was a mature and unambiguous standard. But a few years ago, after an incredibly long run, the VME connector finally ran out of gas. It simply wasn't possible to coax out any more bandwidth, while processors continued to get faster. Innovations were needed to meet the need for balanced systems with ever greater processing density.

VITA, the VMEbus International Trade Association, addressed the need for a new generation of standards by pursuing two options embodied in the VXS (VITA 41) and VPX (VITA 46) standards. VXS offers higher bandwidth than VME and also a large degree of backward compatibility at the module level. The VPX standard, which was developed without the constraint of backward physical compatibility, defines a technical approach that provides support for very-high-bandwidth communications over a new high-speed connector.

The Current Status of VPX

After its initial definition, the VPX standard morphed into a family of specifications, often referred to as "dot specifications," defining a number of board-level implementation options. This expanded range of available VPX-based variants was intended to enable superior processing performance for differing types of embedded computing applications. The challenge is that the proliferation of dot specifications has created a situation in which VITA 46 system building blocks developed by multiple manufacturers won't work together.

ImageThe base specification within VITA 46 defines power and ground and some basic system signals. Then the dot specifications describe the pin assignments and protocols for a wide variety of connection options like Ethernet, Serial RapidIO, PCI-E, and switched data planes. The current status is that the various dot specifications are not well coordinated. Recent experience shows that system developers can design board-level solutions to the various VITA 46 dot specifications and still come up with a proprietary, non-interoperable solution. Since an overall system-level architecture definition and interoperability requirement was not considered by the dot specifications, integration of solutions built upon these multiple variations is difficult if not impossible. The current structure and draft state of the VITA 46 (VPX) specifications are shown in the accompanying table.

As many of the dot specifications were developed independently from the bottom up, with no overarching system architecture, it is evident that systems interoperability issues are not on a path towards resolution. With this type of situation, creating functional, integrated COTS systems is increasingly difficult, expanding development costs and extending time to deployment for new applications.

OpenVPX Industry Working Group

To take a proactive approach in solving the VPX interoperability issues, an industry initiative was launched by defense prime contractors and COTS systems developers in January 2009. Called the OpenVPX™ Industry Work - ing Group, it consists of members from industry-leading defense contractors and embedded computing systems suppliers, and is tasked with developing a comprehensive system specification (formerly referred to as a System Design Guide) that will define a system architecture for VPX, and describe how a subset of the VPX specifications can be bundled to implement interoperable components.

The OpenVPX Industry Working Group is committed to an aggressive timeline as mandated by industry partners and defense contractors, targeting October 2009 for completion of its work. Given this short timeframe, the OpenVPX Working Group is initially working outside of the VITA Standards Organization (VSO) to meet that goal. Once the OpenVPX system specification is complete, it will be transitioned to the VSO for ratification; at the point where the OpenVPX system specification is transitioned into VITA, the Working Group will disband.

Resolving Specification Ambiguity

Connectors covered by the OpenVPX standard.

The OpenVPX Industry Working Group is beginning with the premise that the original performance goals of VPX can be combined with the tradition of VME by clear specification of a system architecture. This architecture will, in many cases, be built upon the existing VPX dot specifications with additional system-level guidance to ensure that VPX components really do work together. Where there are specification opt - ions, specify which option is to be used. Where there is ambiguity, specify a clear interpretation. And, where there are still issues, define a rational resolution. This will be accomplished through the creation of an overall VPX system specification.

A system specification will define the points of interoperability in the system. For VPX, this shall be between the module and slot in the backplane, as well as the fabric which it communicates upon. In order to control interoperability, the high-level system specification must have precedence over lower-level specifications referenced within it. This is a requirement to assure true system- level compliance across lower-level components. For example, legacy products developed prior to the system specification may indeed be compliant to a lower-level referenced specification, but may not be compliant to the overall system specification. Finally, physical pin definition usage must be defined in the system specification to assure that interoperability can be achieved across the range of slots and modules, and how they will communicate across the backplane.

When building VPX systems for different applications, the user needs clear direction, at the system level, pointing to appropriate lower-level standards when appropriate.

The OpenVPX Technical Working Group will accomplish this goal by creating a limited set of bundles, with each bundle defining an integrated system specification to address various application requirements. A typical bundle will, for example, define system topologies encompassing switch modules, payload modules, management modules, rear transition modules, and all associated chassis slot and module types that shall integrate together on a backplane. In order to scale for future requirements, the system specification shall also include a method to add additional architectures, as reference points, for a new or evolving application that seeks to be interoperable.

Building a Mature, System-Level Specification

The focus on the system-level specifications will also involve filling in some areas that are not currently addressed. For example, the concept of defining functional communication planes (management, control, and data) has not been defined in the current VPX standard. Leaving the functional planes undefined clearly increases the interoperability risk and diminishes the performance potential for future designs.

Fortunately, it may be possible to implement these layered scalable communications planes by borrowing some ideas from another proven system-level standard. The Advanced Telecom Computing Architecture (ATCA) is a widely used standard for high-performance commercial electronics. ATCA defines three independent communications planes: a control plane (Gigabit Ethernet), a data plane (high-bandwidth switch fabric), and a system management plane.

The ATCA system management plane uses a sophisticated Intelligent Platform Management Interface (IPMI)-based infrastructure. The IPMI communications plane is very flexible, allowing the construction of a consistent system management environment for alarms, configuration control, and diagnostics, running on a completely different medium from a system's data and control planes.

On March 5, the OpenVPX Industry Working Group announced a call for participation in its Technical Working Group. Any COTS defense contractor or embedded computing supplier that is in good standing with the VSO, and is committed to the OpenVPX Industry Work - ing Group's mission and aggressive schedule for completion of a system specification, is invited to apply for membership in the Technical Working Group.

Summary of the OpenVPX Vision

The OpenVPX initiative has evolved rapidly since its launch in January of this year. The collaboration and energy from all the member companies has lifted the series of 'dot specifications' to a more comprehensive system specification that will provide clear guidance to defense contractors and COTS systems developers on how to build interoperable computing and communication components, defining a scalable architecture to support the new and evolving mission computing and communications requirements.

By enabling a system-level approach to using the VPX standard, OpenVPX will enable prime contractors and embedded computing suppliers to greatly reduce the time required to create integrated COTS system solutions in 3U and 6U form factors. It will also lower the risk of adoption, and expand the addressable market for VPX solutions, while accelerating deployment into real-world applications.

This article was written by Thomas Roberts, Product Marketing Manager, Mercury Computer Systems (Chelmsford, MA). For more information, contact Mr. Roberts at This email address is being protected from spambots. You need JavaScript enabled to view it., or visit

Embedded Technology Magazine

This article first appeared in the July, 2009 issue of Embedded Technology Magazine.

Read more articles from this issue here.

Read more articles from the archives here.