Using a rapidly evolving ecosystem to develop optimized OpenVPX systems

Story

October 06, 2010

OpenVPX (VITA 65) design principles and a rapidly maturing component ecosystem support development of next-generation embedded computing systems.

The pressure is on defense programs to deliver advanced next-generation capabilities and to deliver them fast. This includes programs for military communications, missile defense, and, most especially, ISR programs. In the words of Defense Secretary Robert Gates, “Our conventional modernization programs seek a 99% solution in years. The wars we are in require 75% solutions in months[1].”

Secretary Gates is pushing hard for faster program deployments because of the advantages new technologies can bring to our warfighters. For example, an advanced electro-optic camera mounted in a UAV can provide finely detailed images of areas occupied by insurgent forces. If those images could be combined with data from a SIGINT system, the result would be a rich picture of what is happening and where it is happening. New ISR programs are being designed to deliver this type of valuable information to warfighters by combining – in real time – data from different types of sensors.

Powerful, flexible, configurable embedded computing is essential to delivering these next-generation capabilities. The new sensors, including electro-optic cameras, SIGINT antennae, and sophisticated radars, are generating huge volumes of data that must be processed in real time. Then even more processing is needed to execute the complex algorithms that synchronize and combine output from multiple sensors. The computing subsystems must deliver powerful, real-time processing and also support flexible configurations that can deal with different types of processing and many I/O protocols.

Meeting these challenges requires an embedded computing architecture supported by a wide range of processing, I/O, and storage options. In industry terms, this means a robust ecosystem with a great number of compatible choices. Meeting the computing challenges and satisfying compressed delivery schedules requires that the components of this ecosystem can be selected, designed into a functional subsystem, integrated, tested, debugged, and finally deployed in a predictable fashion, without undue risk. The OpenVPX (VITA 65) standard meets these requirements, defining an embedded computing architecture supported by a robust and growing ecosystem.

The OpenVPX ecosystem matures quickly

In 2009 and 2010 the OpenVPX standard made huge strides in both system-level maturity and in the breadth of its ecosystem. First, the OpenVPX Industry Working Group, an alliance of VITA member defense and aerospace prime contractors and embedded computing systems suppliers, came together to address VPX (VITA 46) system-level interoperability issues. Many of the original VPX subspecifications, known as “dot specifications,” had been developed without a top-down system-level approach supporting multivendor interoperability (Figure 1). As a result, the initial attempts at VPX implementations using components from multiple vendors were difficult to integrate, interoperate, and specify at the systems level. OpenVPX addressed this issue.

 

Figure 1: VITA 46.0 and VITA 46.x dot-specification matrix

 

The OpenVPX specification developed by the Working Group was released to the VITA 65 working group within VITA and in June 2010 the OpenVPX System Specification was ratified as ANSI/VITA 65.0-2010 describing OpenVPX as “… the architecture framework that defines system-level VPX interoperability for multivendor, multimodule, integrated system environments.”

OpenVPX uses the concepts of planes, pipes, and profiles to provide a standards-based basis for interoperability. It defines multiple planes for Utility, Management, Control, Data, and Expansion, as well as various sizes of pipes used for serial communication. There are also several types of profiles for structure and hierarchy in the specification (slot profile, backplane profile, module profile, and development chassis profile). The backplane profiles define the backplane topology (types: centralized and distributed switching, and host/slave).

By expanding VPX with OpenVPX, the industry came together in a focus on system-level interoperability. Well before final ratification, the technology vendors that participated in creating OpenVPX, as well as many other companies, began to design, develop, and deliver products that adhered to the OpenVPX standard, rapidly creating a continually growing ecosystem. Just a partial list includes:

• BittWare Signal Processing Systems – FPGA and DSP processing modules
• Concurrent Technologies – Intel processing and storage modules, and XMC carrier card
• Elma Bustronic – Backplanes/Chassis
• Extreme Engineering Solutions – Power Architecture processing and development chassis
• GE Intelligent Platforms – Power Architecture and Intel processing module, XMC carrier cards, Ethernet switches, and chassis
• Kontron – Intel processing, GbE switch, and development chassis
• Mercury Computer Systems – Processing modules implementing Power Architecture, Intel, FPGA, and GPU components, digital receivers with A/D conversion, XMC carrier cards, and RapidIO and Ethernet switches
• TEK Microsystems – FPGA processing and A/D converters
• Tracewell Systems – development chassis and deployable chassis

(For a full list, see www.vita.com.)

Making decisions for OpenVPX designs

However, despite its design advantages and ecosystem, OpenVPX is not a magic elixir for the instant creation of embedded computing subsystems. Integrating the components from the OpenVPX ecosystem into deployable subsystems still requires expertise that spans both computing technologies and application-specific demands.

First, there is the challenge of subsystem design. To look at just one example, designers working within the OpenVPX standard must decide upon a backplane topology. This decision requires an understanding of intrasystem communications technologies, such as switch fabrics. The decision also involves an understanding of the application’s data flow. Given an understanding of both technology and application, the designer can select the best backplane approach. The OpenVPX backplane profile decision will rule some components out, while others remain viable.

In an OpenVPX design, this type of decision is repeated many times within the context of planes, pipes, and profiles. It requires skill and experience to create a subsystem design optimized for maximum performance in a specific application. After that stage is complete, the next step is selecting the best components.

The process of component selection

The market has supplied great depth and variety in available OpenVPX technology components; making the right choices from that variety is a critical part of developing an application-optimized design. While it is often tempting to stay within the “comfort zone” of a given vendor’s product line, the only way to deliver maximum value is to carefully evaluate all the options in the ecosystem. For every type of component – backplane, carrier card, power supply, processing module, and so on – it is necessary to compare what is available with what is needed and take a “best-of-breed” approach to selection.

Performance numbers are important to this evaluation but so are SWaP parameters, interface compatibility, software support, reliability characteristics, and environmental limitations. Effective component selection requires a comprehensive understanding of the application’s goals, system requirements, and related limitations. As with any complex design activity, experience has great benefits. Mercury was recently involved in a subsystem design effort that illustrates this process.

OpenVPX ecosystem – UAV case study

A UAV platform required an image and signal processor to process, exploit, and disseminate large amounts of multisensor data (Figure 2). New technology for multi-image processing, image compression, and forensic data storage was needed. Achieving SWaP and QRC schedule requirements were also crucial to program success. A determination was made that basing the subsystem design on OpenVPX was the best way to unite the efforts of multiple technology vendors and still create a functional, interoperable subsystem on schedule.

 

Figure 2: OpenVPX subsystem computing supports a new, multisensor program.

 

Because all the vendors were working from the OpenVPX Specification, a common “language” was used, which greatly reduced the response time from board, chassis, and backplane suppliers. Mezzanine card carrier modules, JPEG compression modules, and new types of processing modules were all selected and successfully integrated into an appropriately sized backplane and chassis combination. After successfully completing initial field tests, this program has moved on to the next phase.

OpenVPX is ready to support next-generation programs

The DoD is committed to driving more programs that rapidly deploy advanced capability in support of the warfighter; one result of this commitment is a need for powerful, integrated embedded computing subsystems built on a standards-based, robust ecosystem.

The OpenVPX standard, with its focus on component interoperability, offers a solid basis for faster, less risky development of the complex, new subsystems that will meet these demands. Using the OpenVPX concepts of planes, pipes, and profiles, system architects and designers can define technologies that are optimized to satisfy a specific set of application requirements and also have unambiguous parameters for component interoperability.

More than 30 vendors have produced components that adhere to OpenVPX, creating a solid and rapidly growing ecosystem that supports OpenVPX designs. Ecosystem choices include multiple styles of processing modules, mezzanine carriers, storage cards, I/O interfaces, fabric switches, backplanes, and chassis. After developing an optimized design, subsystem developers must carefully evaluate and select the best possible components from this available ecosystem.

A combination of an optimized OpenVPX design and effective component selection gives developers a flexible but reproducible process for the creation of next-generation embedded solutions.

Reference:

1. “Vice chief: FCS vehicles will transform warfighting,” by John R. Guardiano, Army News Service, Oct. 8, 2008, www.army.mil/-news/2008/10/08/13149-vice-chief-fcs-vehicles-will-transform-warfighting

Thomas Roberts is a Solutions Marketing Manager at Mercury Computer Systems. He has more than 25 years of experience in systems engineering and technical marketing with IBM, Nixdorf, Data General, Digital Equipment, and Compaq. He holds a BS in Engineering from Cornell University and an MBA from the University of Kansas. He can be contacted at [email protected].

Mercury Computer Systems 978-256-1300 www.mc.com