Mwrf 2383 22cpromo 0

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

March 25, 2015
Using commercial strategies and technologies for military-grade RF/microwave systems promises to reduce costs while increasing flexibility.
Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.

As a cost-saving strategy that adopts commercial processes, standards to increase the modularity and flexibility of electronic-warfare (EW) and signal-intelligence (SIGINT) equipment are being developed by military research organizations, device/component manufacturers, and standards groups. The motivation for this effort is simple: to enable warfighters to compete in the rapidly evolving global arena.

1. With the introduction of VITA 67.0, the coaxial interconnect through the backplane of the VPX card became standard. The result was decreased RF loss and noise to the card. (Courtesy of CommAgility Ltd.)

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.


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.


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.

Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.


Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.

In a military-grown initiative, the U.S. Army Communications-Electronics Research, Development, and Engineering Center (CERDEC) has been developing the Modular Open RF Architecture (MORA). Although it is similar to OpenRFM, MORA encompasses a larger vehicle system. Its goal is to reduce the size, weight, and power (SWaP) of RF electronic systems by increasing hardware sharing and system flexibility—at the same time, reducing complexity and cost. While OpenRFM can be applied to a variety of warfighter platforms, MORA aims to increase next-generation multifunction missions for military ground vehicles.

2. Using a common-interface modular approach helps to reduce the reconfiguration and maintenance costs involved in upgrading or repairing RF systems. (Courtesy of Mercury Systems)

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.

Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.

Sponsored Recommendations

Getting Started with Python for VNA Automation

April 19, 2024
The video goes through the steps for starting to use Python and SCPI commands to automate Copper Mountain Technologies VNAs. The process of downloading and installing Python IDC...

Can I Use the VNA Software Without an Instrument?

April 19, 2024
Our VNA software application offers a demo mode feature, which does not require a physical VNA to use. Demo mode is easy to access and allows you to simulate the use of various...

Introduction to Copper Mountain Technologies' Multiport VNA

April 19, 2024
Modern RF applications are constantly evolving and demand increasingly sophisticated test instrumentation, perfect for a multiport VNA.

Automating Vector Network Analyzer Measurements

April 19, 2024
Copper Mountain Technology VNAs can be automated by using either of two interfaces: a COM (also known as ActiveX) interface, or a TCP (Transmission Control Protocol) socket interface...