What’s the Difference between OpenVPX, OpenRFM, and MORA?

To keep pace with ever-changing commercial trends, standards like OpenVPX, OpenRFM, and MORA are seeking to provide swappable architectures that are openly available. In doing so, they will create a web of third-party development. This system-level approach promises to bring common interfacing, footprints, communications protocols, and software abstraction to an industry that is accustomed to non-specialized methods.

This approach requires a radical change in the thinking and philosophies around traditional EW equipment development. Common rack-mounting techniques and some widely used interfaces have become relatively standard in the warfighter. However, the development of these units has been led by only a few suppliers, who each use their own “secret sauce” for design. Breaking from these traditions, OpenVPX, OpenRFM, and MORA seek to define a set of interface, control, software layer, module dimensions, and powering protocols. Interestingly, each standard relies on VITA standards for the digital backplane.

OpenVPX

The latest technologies for digital imaging, signal-intelligence (SIGINT) antennas, sensors, and radar continuously produce a massive amount of data. To make the most of this information, extremely rapid and highly configurable real-time processing must be performed. Such processing must be able to handle many different input/output protocols and storage options while maintaining the necessary robustness expected of military systems.

OpenVPX is a widely adopted architecture framework within the system-level VPX standard. It specifically targets the support of a multi-module, integrated system environment, and multivendor interoperability using commercial-off-the-shelf (COTS) technologies. OpenVPX uses profiles, plans, and pipes as a basis for interoperability for plans, such as data, expansion, management, utility, and control. Profile hierarchies include slot, module, backplane, and development chassis profiles with pipes for serial communications.

OpenVPX has been embraced by companies like BittWare Signal Processing Systems, Mercury Computer Systems, and TEK Microsystems for the development of field-programmable gate arrays (FPGAs), digital-signal-processing (DSP) modules, and converter technology. These components are critical aspects of modern EW systems—specifically military radios. Yet FPGAs, CPUs, GPUs, and DSP electronics now rapidly become outdated due to the growth of the digital realm. As a result, the ability to rapidly design, upgrade, and deploy these devices is critical to keeping a warfighter on par with present challenges.

Although OpenVPX has been accepted as a major player in the embedded-computing portion of EW hardware, it is purely an embedded solution that interfaces with RF/microwave hardware. VITA 67 does address a common RF-coaxial-backplane connection. Yet there is much to be desired for an RF standard. As a basic concept and influencer on later RF/microwave EW open standards, OpenVPX has set the stage for the growth and development of common RF systems.

An example of an OpenVPX application is CommAgilitiy’s VPX-D16A4, which is a double-width AdvanceMC (AMC) card with RF mezzanines and a wireless-baseband-processing carrier card (Fig. 1). The VPX-D16A4 is designed to provide military-grade and secure LTE and LTE-A communications capabilities for military communications and the wireless test market.

​OpenRFM

Currently, OpenRFM is in the standards initiative phase. It was initially developed by Mercury Systems. The goal of OpenRFM is to follow what has been done with OpenVPX and other commercial standards for RF/microwave and digital subsystems for EW and SIGINT applications. The budding standard focuses on creating common approaches for EM and thermal interfaces, control-plane protocols, and software. OpenRFM uses OpenVPX or VXS/VME processing architectures. They are combined with the description for integrated-microwave-assembly (IMA) modules with an IP re-use structure (Fig. 2).

“The common-core control architecture is based on a Xilinx system-on-a-chip (SoC) controller, which is at the heart of all of this. That is where the middleware and meta-command interpreter is,” said Lorne Graves, chief technology officer for Mercury Systems. “With a 6U, OpenVPX allows us additional height so that power modules and other FPGAs can be added for the pre-processing of digitized data. As a result, you can basically combine RF, digital, and pre-processing all in one slot.”

For example, an IMA may comprise integrated switches/switch matrices, attenuators, oscillators, filters, and amplifiers along with other RF components. Current IMA examples developed by Mercury Systems include a direct-digital-synthesis (DDS) synthesizer, a wideband tuner, and a quad down converter all in a 6U VME carrier. As new EW and SIGINT methods evolve, the carriers can receive secure IP-based upgrades in the field because of the IP base structure for these devices. This feature rapidly increases response time.

According to Graves, “The current status of OpenRFM is still in development. But we have multiple modules already designed and products completed—a number of which are wideband carrier cards. There was an early introduction at AOC last October and the VITA annual conference this past January.” OpenRFM also has been used in-house by Mercury Systems for several projects and products. Although its development is far from complete, the open invitation to participate in the growth of an RF standard with actual hardware and case-study examples could facilitate OpenRFM’s adoption and evolution. “We are working on developing sponsorship from the primes and a government sponsor to help us understand the different needs in more detail,” said Graves.

MORA uses the Vehicle Integration for C4ISR/EW Interoperability (VICTORY) data bus-centric architecture for vehicle hardware platforms. Along with a common display, MORA strives to establish an open message interface that promotes the real-time coordination of support management operations.

MORA closely resembles OpenRFM with a ground-based vehicle spin, given its use of a software-defined radio (SDR), RF distribution device, Ethernet switch, VICTORY shared processing unit, and an integrated radio-head block. MORA also uses an IP-based interface on the VICTORY data bus. In addition, a MORA high-speed data bus could adopt 10 Gigabit Ethernet. A common RF cable bus, which could comprise coaxial cable or RF-over-Fiber optical transmission lines, connects the SDR, RF distribution device, and radio heads.

Like OpenRFM, MORA is still under development. Currently, it provides a backplane definition for each component in the standard. This includes a payload profile, RF switch profile, switch profile, and radio clock profile. It may use VITA 67.1 for RF coaxial interconnectivity, or VITA 47 for transporting RF signals digitally. Currently, PCI Express stands as a contender for the card-based radio and digital equipment. Because the test and measurement and automated instrument markets have embraced PXI for rugged PC-based equipment, MORA may move toward a PXI-based system to benefit from commercial development and scalability.

Though OpenRFM, OpenVPX, and MORA share many of the same philosophies, their approaches and applications are somewhat divergent. OpenVPX is predominantly geared toward embedded systems and interconnectivity for EW applications with a few RF-connectivity add-ons. OpenRFM is a budding initiative that looks to bring the success of OpenVPX and commercial-computer system integration and standardization to the RF world. In doing so, it will make integrated modules and software abstraction protocols available for warfighters.

In contrast, MORA is geared toward creating common hardware and connectivity buses for military ground vehicles, which will translate into SWaP savings and increased ruggedness through redundancy. Although the applications for these standards may be different, the emergence and growth of open standards in military applications is a significant step in the use of COTS technologies and approaches. The implementation of such standards could prevent the outmoded limitations that have plagued legacy military technology development.