Leveraging the Sensor Open Systems Architecture (SOSA) for radar applications

Story

February 11, 2022

Nicholas Borton

SRC

With the highly anticipated release of Version 1.0 of the Sensor Open Systems Architecture Technical Standard in September 2021, there are more and more Requests for Information and contracts asking specifically for SOSA. The SOSA Technical Standard is targeting five sensor modalities: electro-optical/infrared (EO/IR), electronic warfare (EW), radar, and signals intelligence (SIGINT). What does the first version of the SOSA Technical Standard have to offer a system designer? Specifically, how can SOSA be applied to radar systems?

Radars are critical tools to armed forces for situational awareness. Potential uses include a unmanned aerial system (UAS) carrying a synthetic aperture radar (SAR), surveillance on a vessel at sea, or precision target acquisition.

As the various threats and needs of the warfighter keep increasing, so does the need to develop ever more advanced radars with an increasing list of capabilities. The Modular Open Systems Approach (MOSA) for system development provides a path to get warfighters the equipment they need to meet these requirements. Adhering to the MOSA ecosystem enables:

Getting sensors to the field sooner to counter emerging threats
Reducing integration time and costs
Reaching higher technology readiness levels faster
Enabling competition for capabilities and technology

As the Sensor Open Systems Architecture (SOSA) is part of the MOSA ecosystem, there is a lot of push to develop radar systems with it. With the stringent performance requirements radars need to meet, can it be done within the bounds of a modular open architecture like SOSA? Can the MOSA benefits be capitalized on while still meeting performance needs with SOSA? In fact, SOSA can indeed enable performance while simultaneously delivering the MOSA benefits.

Basic radar with SOSA V1.0

As SOSA does not define a system per se, rather components to build a system with, one of the first questions is “How much of the system should be SOSA?” Often the answer to this is “As much as possible.” Regardless of the answer, this question needs to be revisited again and again throughout the design process.

Central to the SOSA Technical Standard are the SOSA modules. Although many module interfaces are not fully standardized yet, planning for how they will manifest in the SOSA infrastructure will pay future dividends. SOSA is split into two major sections of standardization which is shown in the SOSA taxonomy in Figure 1.

[Figure 1 | The SOSA taxonomy shows the two major sections of standardization. Courtesy Technical Standard for SOSA Reference Architecture, Edition 1.0, The Open Group.]

Dealing with custom or non-SOSA components

When determining “how much of the system should be SOSA,” it is important to first consider which SOSA modules might eventually be used. Using module boundaries, basing where a system is or is not SOSA will help enable uses of future versions of SOSA and capitalize on the SOSA marketplace. To gain a sense of where to make that break, looking at the high-level data flow diagram from V1.0 of the Technical Standard can help. (Figure 2.)

[Figure 2 | Pictured is the high-level data flow of the SOSA Technical Standard. Courtesy Technical Standard for SOSA Reference Architecture, Edition 1.0, The Open Group.]

Whether other standards are going to be used needs to be weighed when asking “how much SOSA.” Alternate standards might be needed for many reasons, most commonly when there will be reuse of a system or an existing system upgrade. These other standards might include Common Open Architecture Radar Program Specification (COARPS) and Fires Radar Open System Technologies (FROST). Depending on the use case, either a clean break would need to be made between the SOSA components and the other architectures on a SOSA module boundary, or the other architectures’ components could be encapsulated inside a SOSA module’s boundaries.

As the front end of a radar provides the system with most of its mission-critical performance characteristics, it makes sense that it is most likely to be the custom portion of the sensor. From a SOSA standpoint, the front end is constrained to the 2.4 and 2.3 modules. In many radar systems, the very low-latency constraints tend to occur in the front end. Low probability of intercept (LPI) and low probability of detect (LPD) are prime examples of low-latency-inducing requirements.

Tight requirements in dwell scheduling and execution may require a large amount of hardware interconnected in a way that prevents a break between the 2.4 and 2.3 SOSA modules (depicted in Top-Level SOSA Services Context Description diagram, Figure 3, next page). If a highly custom front end is needed, maintaining the 2.3 receiver exciter module boundary and the SOSA aperture and electro-mechanical interface will enable full capitalization on SOSA for the rest of the system.

[Figure 3 | Shown is the Top-Level SOSA Services Context Description. Courtesy Technical Standard for SOSA Reference Architecture, Edition 1.0, The Open Group.]

Balancing today’s needs against future functionality and technology insertions

As the designer moves past the front-end modules into the rest of the processing chain, command and control (C2), and the support modules, there is more of an ability to embrace the SOSA technical standard. Even in the case where size, weight, and power (SWaP) concerns may initially prevent SOSA adoption, adherence to the SOSA standard now will enable rapid tech insertion when new technology with a reduced SWaP becomes available.

Radar back-end processing may be demanding in terms of overall throughput, or complexity of algorithms, but it does not typically have the same real time and latency requirements of the front end. Here we are typically dealing in full dwell, or possibly scan timelines, which are much larger than the pulse to pulse (or even intra-pulse) deadlines the front end must cope with. Here the possibility of broadly embracing the Ethernet-centric SOSA inter-module infrastructure is reasonable.

SOSA design patterns are ways in which sensor functionality can be realized through SOSA infrastructure implementations. The focus on the design pattern is on the level of severability they provide, and therefore differing levels of independence from the surrounding system. The design patterns impact how functionality upgrades and technology insertions occur.

The various software patterns provide the most independence. The software patterns can be moved to any piece of hardware which is running a compliant SOSA run-time environment. That could be a SOSA PIC [programmable interface controller] with an x86 processor onboard or an FPGA SoC [field-programmable gate array system-on-chip] whose Arm cores are hosting a run-time environment.

Of the hardware patterns, either a single PIC or box-/chassis-level implementation would provide the next level of independence. In these instances, the functionality is tightly coupled to the hardware in question. To move that piece of functionality, or add new functionality in its place, the old hardware needs to be removed and new hardware which matches the backplane or mil-circular connector interfaces must be installed in its place. With the standardization which SOSA provides, finding a hardware solution already on the market is very likely.

The last major hardware pattern is the multiple PIC implementation. This is typically the most restrictive version of functionality from a reuse standpoint. With multiple PICs there are multiple interfaces to match up, but beyond just matching those interfaces, there must also be the proper interconnections between those multiple PICs. This pattern may have some common use cases such as an SBC [single board computer] paired with a GPU. Due to the popularity of the specific pattern, they might not be as restrictive as at first glance.

Sustainment considerations

Strongly correlated with functionality and technology insertions are sustainment considerations.

As much as technology insertions are reliant on the SOSA interfaces to replace an old technology with a new one, these same interfaces are useful from a sustainment standpoint. The best of both worlds occurs when a planned technology insertion to keep pace with a threat also solves an obsolescence issue. To enable that best-of-both-worlds scenario, a plan needs to be in place to upgrade SOSA components in a system.

When reuse is leveraged properly, SOSA can enable merging among different supply chains as well. This can also be coupled with the rolling upgrades of SOSA components as well. When more sensor systems are reusing the same SOSA components, and team up for upgrades, the savings continue to multiply.

SOSA V1.0 provides a handful of tools based on standardized interfaces for building radars. These standardized interfaces provide many benefits to the development and sustainment of radars. It’s important to begin with the end in mind, as pre-planning for future upgrades and sustainment and making those components SOSA compatible will provide enduring threat-matched capabilities and cost savings.

Nicholas Borton is a machine intelligence hardware architect at SRC, Inc. and vice chair of the SOSA Steering Committee. Borton has worked at SRC for more than 17 years and is currently conducting research in edge-machine-learning to maximize the use of size, weight, power, and cost, in addition to furthering open standards adoption at SRC. Borton earned his bachelor’s degrees in both computer engineering and electrical engineering from Clarkson University.

SRC Inc. • https://www.srcinc.com/