Mwrf 1719 Edasoftware 0

Inside Track with Lorne Graves, Chief Technologist for Mercury Systems

Feb. 9, 2015
Technology Editor Jean-Jacques DeLisle talks with Lorne Graves, chief technologist at Mercury Systems, about the OpenRFM initiative targeting defense systems.
Lorne Graves, Chief Technologist, Mercury Systems

LG: We are launching the OpenRFM initiative to streamline the integration of RF and digital subsystems in advanced sensor-processing applications. The goal is to create more affordable, flexible, and open solutions. Our desire is to see the formation of a complementary, industry-developed RF ecosystem that gives defense primes and the Department of Defense (DoD) maximum flexibility and adaptability for the rapid deployment of affordable EW and SIGINT systems. Such capability is critical to addressing evolving threats.

JJD: What components comprise an open-architecture RF system?

LG: A common Open Systems Architecture (OSA) RF system would consist of an RF controller and one or more integrated microwave assemblies or multi-function RF circuits. They would be connected to a common control plane, such as Gigabit Ethernet, PCI-E, VME, or OpenVPX.

JJD: What interface technologies can communicate with an OpenRFM system?

LG: The OpenRFM architecture allows for a variety of interface connections. Along with those mentioned previously, you could have 10 Gigabit Ethernet, Serial Rapid I/O, and Serial Front Panel Data Port. These physical protocols could then use a transport layer, such as VITA-49 (also known as Vita Radio Transport), to send packetized data or receive commands. One of the compelling features of OpenRFM is that it is virtually “protocol-agnostic.”

JJD: What is meant by the term “RF middleware”?

LG: “RF middleware” is a term coined by myself and others that work with the OpenRFM architecture.  Simply put, it’s a software layer that provides a hardware abstraction layer (HAL). That HAL is derived from the various protocols mentioned for control planes ranging to the low-level discrete control of RF control lines.

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

JJD: What time/cost savings are associated with a module-based design approach?

LG: The time and cost savings are tremendous.  At Mercury, for example, we now have a single common test environment for all OpenRFM-based RF modules. Because the control software is universal, little effort is required to develop new test code for control. This aspect reduces the costs associated with integrating and testing the OpenRFM-compliant modules and infrastructures that are designed and implemented by customers. Another example is that standardized parts, such as common connectors and interface components, allow for greater interoperability and reuse across multiple applications and platforms. They deliver a better overall return on investment and a more affordable solution for the end users.

JJD: How is Mercury encouraging other organizations and companies to participate in the development and implementation of OpenRFM?

LG: We are trying to show tangible evidence that this architecture is well aligned with the DoD’s directives to lower costs and increases the ability to rapidly and continuously upgrade critical defense electronics systems. We are developing interoperable RF, microwave, and digital modules and showing how we can reuse those modules. We can scale them to various platforms to reduce overall integration time and tighten schedules for RF subsystem development. Nothing breeds acceptance like success, and we are working to have real examples to show to a broad audience in the near future.

JJD: What types of configurability and upgradability are offered by an architecture such as OpenRFM?

LG: The possibilities are seemingly endless. For instance, if a system needed increased instantaneous bandwidth (IBW) or a particular filter changed on a signals-intelligence (SIGINT) subsystem, you could simply change that one module without having to change the system software. The configurability of newer systems provides many options. For example, you could use a receiver, synthesizer, and transmitter to build the RF section of an electronic warfare (EW) system. If a user wanted to build a multichannel SIGINT system, they could then use the same receiver and synthesizer modules as common building blocks to construct a new functional system.  

JJD: How may the OpenRFM hardware and software impact the retrofitting, modernizing, and maintaining of aerospace EW systems?

LG: Retrofitting systems will allow for more competition in terms of the RF modules, reducing “vendor lock.” At the same time, they will give systems integrators a quicker, easier, and more affordable path for future upgrades.

JJD: What external threats are encouraging the development of systems that can be rapidly upgraded and reconfigured?

LG: Many adversaries are already using readily available commercial technology for various EW, communications, and radar systems. This provides them with the ability to adapt quickly. To effectively counter these systems, we must be able to meet or exceed their rate of adaptability. Because it is based on an open-systems architecture approach, OpenRFM can help speed the rate of technology insertion in EW, SIGINT, and radar systems.  

JJD: What systems could benefit from using OpenRFM?

LG: Consider, for example, an aging platform with custom hardware that is experiencing obsolescence issues. The system could be re-“architected” using the flexibility of OpenRFM to interface to the older control mechanisms at a line-replaceable-unit (LRU) level. The platform infrastructure (chassis, cooling, wiring, etc.) could then be preserved. In addition to saving millions of dollars, such an approach provides new capabilities to protect or defeat new threats.

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

JJD: Where is OpenRFM to date, and how do you see it developing in the next year?

LG: The first introductions of OpenRFM to the general industry began in October 2014. We have also discussed OpenRFM at the recent Embedded Technology Trends conference hosted by the VITA organization ( The architecture is taking shape, as we have carriers in VME and VPX for OpenRFM modules. The first OpenRFM modules are being tested now. We expect to have at least three to four OpenRFM-based subsystems deployed with several customers by the end of this year.

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...