OpenVPX: The future is now

VPX was the natural successor to the venerable VMEbus architecture, providing significant advances in performance while providing straightforward migration. The VPX specification did not, however, address interoperability between boards – and the OpenVPX specification addresses this. It is, however, in essence and by design, a work in progress.

VME has long been the de facto open standard for the embedded computing industry. And VPX/VITA 46 (in addition to its more VME-like alternative, VXS/VITA 41) was one of the first VITA open standards for embedded computing boards to capitalize on emerging serial link protocols. VPX was not, however, and nor was it intended to be, an open architecture for complete systems solutions. The flexibility of VPX was both a strength and a weakness. On one hand, it allowed manufacturers significant leeway to develop innovative technologies. On the other hand, its flexibility in the use of pins for serial link communications, its mapping of those pins to various protocols, and the lack of system-level thinking meant that VPX boards from different manufacturers did not easily interoperate.

As VPX attracted more and more attention, with myriad defense vendors introducing broad ranges of products, interoperability became an increasing issue. A number of vendors, including GE Intelligent Platforms, responded in the form of the OpenVPX (VITA 65) initiative, which was designed to leverage the work done on each of the individual “dot” specifications within the VPX standard to create a comprehensive set of definitions for system-level interoperability (Figure 1). Where individual manufacturers had used VPX’s plethora of pins as each saw fit, OpenVPX looked to harmonize the assignment of those pins – in effect, defining pinouts. VPX was a bottom-up approach to providing a successor to VMEbus: OpenVPX is a top-down approach that still leaves room for customization.

Figure 1: “Dot” specifications are at the heart of a comprehensive set of definitions for system-level interoperability.
(Click graphic to zoom)

How is OpenVPX organized?

The OpenVPX specification has been constructed in sections that break down the standard, using a top-down approach; this makes it a different type of document from the typical specification. It is also clearly a “living” document, allowing the opportunity for additional profiles – be they slot, module, or backplane – to be added without major modification of the document. For example, slot profiles – currently in sections 6, 10, and 14 of the document – are written such that, if a new 3U slot profile is needed, it can be added to the end of a subsection within section 14. This can be done because much time and effort were put into understanding the various slot types that might be used and how they can be summarized: as payload, peripheral, switch, and miscellaneous (Figure 2).

Figure 2: An example slot profile
(Click graphic to zoom by 1.9x)

The “miscellaneous” category is significant because it is used to standardize pinouts that would otherwise normally not be set by the OpenVPX specification. For example, the storage slot profile defines two ultra-thin pipes that shall be used by vendors developing compliant storage modules of whichever type or capacity.

Whether of the payload, peripheral, switch, or miscellaneous type – which apply equally to 3U and 6U implementations – slot profiles use the concept of pipes and planes. Pipes are, in effect, communications pathways through the system. Pipes can be “fat” (four links of 4x Tx pairs and 4x Rx pairs), “thin” (two links of 2x Tx pairs and 2x Rx pairs), and “ultra-thin” (single link comprising 1x Tx pair and 1x Rx pair), among others called out in the specification. Note that pipes do not define the protocol used on them; this is specified by the module profile.

Meanwhile, OpenVPX system architectures can also include multiple planes, where a plane defines a type of traffic depending on its characteristics and requirements. There are five planes: management, utility, control, data, and expansion. Within each of the slot profiles, all serial link communications paths between slots are defined as either on the Data Plane or Expansion Plane: Those that would, in the traditional VME environment, have been on the VMEbus might be on either the Data or Expansion Plane. High-speed interfaces that in VME used special backplane overlays on user I/O pins such as RACE++ or SkyChannel are now defined on the Data Plane. It is important to understand that, at the slot level, no protocols are specified – only the number and size of links. For example, one such 3U slot profile is SLT3-PAY-2F-14.2.7. This describes a Slot Profile (SLT) for a 3U (3) Payload (PAY) with two Fat Pipes (2F) as described in section 14.2.7 of the document. Module profiles and backplane profiles are similarly defined.

A module conforming to a particular definition will always be compatible with a chassis slot defined as being designed to accept that type of module. Every OpenVPX-compliant VPX module has a defined set of backplane signal assignments, mapping protocols to its ports – while OpenVPX backplanes have slot profiles designed to support specific types of modules. The slot profile provides mapping of ports to a slot’s backplane connectors. A backplane profile specifies the type and number of slots along with the topology of the channels and buses that connect the slots. As of this writing, profiles had been defined for 22 3U VPX modules, 13 6U modules, 11 3U backplanes, and 13 6U backplanes.

Still a need for customization

There is, however, one area of the OpenVPX standard intentionally left to the discretion of each vendor: user-defined pins, recognizing that every program’s I/O requirement will be different. For the VMEbus community, these have long been a fundamental and advantageous element of the VME architecture, and this flexibility is retained by OpenVPX. The implication, of course, is that this will often mean that 100 percent plug-and-play operation is not possible in the way that it is possible with, for example, the PC.

If the OpenVPX standard sounds prescriptive, that is because it is intentionally so: Without a strict set of definitions, the goal of interoperability cannot be obtained. It is also important to understand that the primary goal of OpenVPX is to support more rapid, more cost-effective development of applications: It implicitly recognizes that deployment is a very different consideration than development. Only development chassis and backplanes are standardized, with Rear Transition Modules (RTMs) providing user I/O. The expectation is that a custom backplane will be used for deployment, especially where the target system will be deployed in a harsh environment.

Typical rugged deployed systems are usually size- and weight-constrained, with the emphasis resting on obtaining the maximum performance from the minimum space envelope. This is especially true in land-based or airborne fighting vehicles. It is also often true for naval applications as more and more equipment is added to existing platforms. These systems will rarely, if ever, use RTMs as these take up far too much space and are susceptible to shock and vibration; however, such systems have complex backplanes that contain the routing for all functionality required by the application, including all user-defined I/O. As such, OpenVPX is not – yet – typically applicable to the deployed environment. However, by specifying development backplanes and chassis, OpenVPX means that the long and complex effort of developing application software can begin much earlier in the development process while the custom chassis and backplane are developed. This will shorten the time to deployment.

Currently, a limited number of backplanes have been defined for use in a limited number of chassis. That might sound like a restriction, but, in fact, it is not: Today, the OpenVPX standard is designed to apply almost exclusively to development systems in which user I/O goes to an RTM; this is where most of the custom application-specific requirements come from. As such, the number of payload modules interacting with switch and peripheral modules can be relatively easily standardized to a smaller set if the complexity of all the various user I/O types is not addressed on the backplane, but rather in an RTM ignored.

Going forward

In the near term, we will continue to see VPX specified in requests for quotation. Just as there are custom backplanes for VME in deployed systems, so there will be custom backplanes for VITA 46/VPX and VITA 65/OpenVPX. VPX and OpenVPX are joined at the hip and will live together – but as the OpenVPX specification lives and grows, it will assume increasing significance.

OpenVPX is an initiative that should be welcomed by the embedded computing community. It is, by design, a work in progress. An inherent strength of the OpenVPX initiative is that it explicitly recognizes the need for, and encourages submission of, new module and slot definitions that can be incorporated into the standard, such that it will progressively embrace a broadening range of possible scenarios. Ratification by ANSI later this year is the beginning of the journey, not the destination.

James M. Goldenberg is Chief Engineer at GE Intelligent Platforms and has been a contributing editor to the OpenVPX initiative since it began early last year. He is also the current editor for VITA 46.9 and contributed to the VITA 41 SERDES specification. He has more than 25 years of experience in the computer industry. Prior to GE, he was VP of Engineering at SBS Technologies and Sky Computer. Jim has a Masters in Computer Science from Indiana University. He can be contacted at

GE Intelligent Platforms 505-796-1763