In order to keep up with the continued acceleration of new technology and to be able to protect the warfighter from the latest threats, it is essential that we can turn our deployed platforms into adaptable entities that can evolve over time and are not static. The SOSA [Sensor Open Systems Architecture] Technical Standard is the next major step in realizing this goal.

The global military radar market is approximately a $10 billion per year business and spans a wide range of airborne, ground, and naval platforms. Radar platforms consist of surveillance, air defense, fire control, search and rescue, and other types of radar systems. These systems can range from very large active electronically scanned array (AESA) radars, which contain thousands of sensors, to very small radars with only a couple of sensors that can fit on small drones.

While the most visible part of a radar system is the large sensor array or antennae, behind each of these sensor arrays is a set of processing hardware that receives the sensor data, filters the data to identify the meaningful portions, generates metadata to characterize the received data, and then interprets that data to make useful decisions. This processing chain requires multiple interactions between different hardware entities as well as software functions.

One of the key challenges faced by radar system designers is the expense and effort required to keep the technology up to date with the latest innovations as they become available in the market. Additionally, there exists the desire to be able to introduce new algorithms quickly (i.e., quick-reaction capability [QRC]) and to be able to port specific mission capabilities easily between multiple systems. There also is a strong push to move from single-function systems to multi-INT [multiple intelligence] or multimission systems, which can be repurposed for different functions based on alternate firmware or software loads. Furthermore, if the processing module slots within a system are compatible with a range of different processing modules, the benefits of repurposing can cover an even wider range of applications. Over the past few decades, the use of standard interfaces and the adoption of commercial off-the-shelf (COTS) hardware for reusable functions have helped to address some of these challenges. But more can be done.

Standards push

In 2013, the U.S. Army's CERDEC group kicked off an initiative called C5ISR [Command, Control, Computers, Communications, Cyber, Intelligence, Surveillance, and Reconnaissance]/EW Modular Open Suite of Standards (CMOSS) that focused on tackling many of the radar system integration problems head-on by defining a suite of standards leveraging other industry open standards initiatives. CMOSS tried to address the challenge holistically by targeting not just hardware modules, but also by looking at software, networking, and front-end RF components.

CMOSS defined the following layers:

Hardware Layer – OpenVPX with specific plug-in-card profiles
Software Layer – Future Airborne Capability Environment (FACE), which was developed by NAVAIR PMA-209 for avionics applications; REDHAWK for a software-defined radio (SDR) framework; and Software Communications Architecture (SCA) for communications applications
Network Layer – Vehicular Integration for C4ISR/EW Interoperability (VICTORY)
RF – Modular Open RF Architecture (MORA)

In 2014, the Naval Air Systems Command (NAVAIR) initiated the Hardware Open Systems Technologies (HOST) initiative; HOST had similar objectives as CMOSS but was targeted at avionics processing and focused heavily on system-management architecture. The Air Force also had its Open Mission Systems (OMS) initiative, launched started in 2015, which leveraged FACE and focused on standardizing messages and middleware for airborne platforms.

However, as all these initiatives had similar objectives, the U.S. Department of Defense (DoD) pushed for a single initiative across all the military branches: With that, the Sensor Open System Architecture (SOSA) Consortium was born. The SOSA Consortium has adopted many of the CMOSS standard initiatives, but is focused on the overall architectures for sensor processing. Today there is much overlap between the CMOSS, HOST, and SOSA initiatives – with most of the new work being done within the SOSA Consortium, which is currently working toward its first official version of its standard.

To help ensure that the resulting SOSA Technical Standard focuses on the challenges listed previously, the SOSA Consortium has defined 10 quality attributes that are used to guide the work being undertaken. These quality attributes are:

Interoperability
Securability
Modularity
Compatibility
Portability
Plug-and-Playability
Upgradeability
Scalability – Sensor multiplicity
Scalability – Platform size
Resiliency

One of the significant challenges that the SOSA Consortium, as well as other similar initiatives, have had to face is that of balancing these frequently competing objectives. For instance, while fully defined backplane interfaces enable high levels of portability, over-constraining interconnects can lead to lack of flexibility and potentially add extra cost. Striking the right balance will prove key to the ultimate success of the SOSA Consortium.

While radar processing is one of the target applications for SOSA, it is also focused on communications, electronic warfare (EW), electro-optical/infra-red (EO/IR) and signal intelligence (SIGINT) applications, as well multi-INT sensor systems which combine two or more of these sensor types. In order to facilitate modularity and portability, the SOSA Technical Standard defines modules more generically than just hardware entities. While a hardware card may be a “module,” it can also apply to a software function, or a combination of cards and software. The key is that the module has well-defined boundaries, is severable, and has well-defined functionality. The use of modules is essential to enabling systems to be more easily upgradeable either for new technology or alternate functions. In order to accommodate the multiple use-cases, a generic, high-level SOSA sensor system is defined as shown in Figure 1.

[Figure 1 | Illustration of a high-level SOSA sensor system.]

While not every system will use all of these services, these services will be the main building blocks and are further detailed within the SOSA specification.

Zoom in

Taking a closer look at the layers, multiple standards are being used and refined as part of the definition of the Sensor Open Systems Architecture.

At the hardware module level, CMOSS and SOSA both adopted OpenVPX but defined a subset of plug-in card profiles to limit the number of unique configurations. This was done by defining all user-I/O pins, rather than leaving them "user-defined" as in standard VPX. Furthermore, the profiles prioritize backplane coax and fiber capability in lieu of other I/O. Utilizing backplane rather than front-panel I/O for optical and RF is key to easing card replacement, avoiding complex cable management, and promoting higher levels of reliability and density. Another key item is the use of Ethernet as the only fabric protocol for both 3U and 6U based systems.

For 3U VPX systems this is a bit of a change, as PCIe was the more dominant fabric previously. PCIe is still used on the expansion plane to facilitate high-bandwidth connections between processor and FPGA [field-programmable gate array] or GPGPU [general-purpose graphics processing unit] plug-in cards. While these capabilities are driving changes across the COTS ecosystem, they will provide a much better-defined path for future upgrades.

At the hardware module level, there are four primary plug-in card profile types:

• I/O-Intensive Profile – for single-board computers with external I/O support. For a sensor system, these modules support XMC (VITA 42) mezzanine expansion cards and are intended for command-and-control functionality as well as being the only modules that handle external I/O.

• Payload Profile – This is the primary workhorse profile and contains the modules that handle the sensor interfaces and the bulk of the sensor processing. This profile can support FPGA modules with RF or optical interfaces, but can also support compute-intensive processor modules or GPGPU modules.

• Switch Profile – This is the profile for the network switches within the system and is key for scaling to larger systems.

• Timing Card Profile – Timing distribution is a key function within a sensor system and this profile standardizes the I/O of the timing module.

At the software layer, work is ongoing to standardize the run-time environment, but several options will likely be supported. The goal is to leverage the FACE Technical Standard, OMS, MORA, and REDHAWK, as well as the Common Open Architecture Radar Program Specification (COARPS), which is targeted for multiple large radar systems.

The diagram in Figure 2 shows how a subset of the FACE architecture is expected to be utilized.

[Figure 2 | Illustration of how a subset of the FACE architecture is used.]

Software portability and modularization will be key as this is where new radar modes, new waveforms, new countermeasures, or other similar functions can be upgraded or replaced. For true Multi-INT functionality, alignment will be needed at the module boundaries.

Putting all this together, the SOSA initiative is striving hard to enable a well-defined architecture of building blocks that will facilitate modularized radar, SIGINT, EW, EO/IR, and comms systems, leveraging an ecosystem of modules provided by the COTS marketplace. If successful, the industry’s ability to keep sensor-processing systems current and easily upgradeable will be markedly improved. An example of such a system is shown in Figure 3.

[Figure 3 | An example of a sensor-processing system from Curtiss-Wright using a family of SOSA-aligned modules.]

From a COTS perspective, SOSA will enable easier substitution of competitors’ products, but there will still be the opportunity to differentiate in the areas of ruggedization, longevity of supply, enhanced security, and other capabilities that go beyond what is defined by the architecture.

Denis Smetana is a senior product manager for FPGA and DSP products for Curtiss-Wright Defense Solutions, based out of Ashburn, Virginia. He has more than 30 years of experience with ASIC and FPGA product development and management in both the telecom and defense industry and over 15 years of experience with COTS ISR products. He has a BSEE in electrical engineering from Virginia Tech.

Curtiss-Wright Defense Solutions · https://www.curtisswrightds.com/