Multi-INT and SOSA: A consideration of next steps

Story

October 18, 2022

Multiple intelligence (Multi-INT), sometimes referred to as multi modality, is a popular term used in recent years to describe C5ISR [command, control, computers, communications, cyber, intelligence, surveillance, and reconnaissance] applications in which data obtained from disparate sensing sources is fused together to derive new information and operational insights. In some cases, this can mean the fusion of SIGINT [signals intelligence] data and radar data, or SIGINT data with EW [electronic warfare] data and EO/IR [electro-optical/infrared] data. In other cases, it may mean combining real-time data with post-mission analysis from previously processed data. Additionally, there are approaches where artificial intelligence (AI) and machine learning (ML) assist via data and information analysis to identify patterns or predict outcomes.

With the U.S. Department of Defense (DoD) push for Modular Open Standards Approach (MOSA)-based architectures, there is strong intent to leverage that proper level of modularity from standards like the Sensor Open System Architecture (SOSA) to enable common building blocks to support multiple mission types, adding an extra dimension to multiple intelligence or Multi-INT.

One of the key tenets of Multi-INT or multi modality is that the architecture by its very nature is realizable through the core components of a sensing system which can accommodate more than one mission at the same time. This means when disparate mission modalities operate simultaneously (or in series), the system can gather data from those modalities and process it for actionable intelligence (It is worth noting that the core components of the sensing system could include hardware level plug-in cards [PIC], software [application software, for example], front-end sensing apertures, and some manner of system management and task management).

SOSA as an enabler of Multi-INT

With MOSA in mind, from the technical and business acquisition perspective, and SOSA as an enabler of MOSA for something like Multi-INT, we see that the SOSA Reference Architecture (RA) is fundamentally well positioned to help realize the potential of Multi-INT applications. This is evident from some of the SOSA products, such as the logical building blocks (SOSA modules) and the SOSA taxonomy that make up the SOSA RA (as seen in Figure 1 and Figure 2, respectively).

[Figure 1 | A diagram shows the SOSA taxonomy.]

Figure 1 is the core of the SOSA RA. This RA is described, and in so doing, is encompassed, by modules and interfaces; where each module exhibits functions and behaviors; and interfaces, both logical or physical in nature. The SOSA Consortium was deliberate in its development of these modules and interfaces to ensure independence and low (or loose) coupling. (“Low coupling” means that changes in one of the modules will not impart changes to the others.)

From the SOSA RA technically oriented architecture principle number 13, in section 3.2.2 of the SOSA Technical Standard v1.0, we see the SOSA modules exhibit these criteria:

Severable (can be separated and used elsewhere) – based on business needs, timing requirements, or other drivers
Has minimal complexity interfaces (minimum interdependencies)
Can operate as stand-alone or be operated via function/process/system manager
Is independently testable
Does not expose IP
Facilitates competitive procurement
Encapsulates rapid change

In Figure 1, we see the potential for how one could envision and subsequently develop any type of sensing system, either for single mission modality or Multi-INT. These logical building blocks, the SOSA modules, enable a variety of implementation types.

The importance of this perspective is furthered when we look at the SOSA Taxonomy (Figure 2). That’s because SOSA isn’t solely a set of logical building blocks (i.e., the SOSA modules): it is also a set of infrastructure building blocks. These include items like hardware elements (PICs [peripheral interface controllers], apertures, or connectors), software runtime environments, or interaction infrastructures, all things used to create capability with SOSA modules. From this we see what SOSA has ultimately accomplished: SOSA has created a sandbox of, to repeat, building blocks (tools) for the developer and end user.

[Figure 2 | A diagram shows the SOSA modules.]

Let’s take a closer look at some of those infrastructure items on the right of the SOSA taxonomy (Figure 2). One example, which is one of the more mature pieces of SOSA, is the hardware element PICs. As we evolve from single INT to Multi INT, we see how current architectures like SOSA and CMOSS [C5ISR/Electronic Warfare Modular Open Suite of Standards] potentially enable single-sensing capabilities on a per PIC basis. Alternatively, they enable the use of multiple types of cards (i.e., FPGA [field-programmable gate array], GPGPU, processor) in a common backplane profile, thereby enabling mission flexibility by swapping out card types.

An example of potential growth from component to system with these SOSA hardware building blocks is shown in Figure 3. For SOSA, these hardware building blocks (the PICs) are the proper level of modularity when one contemplates their use in either single INT or Multi-INT systems. These building blocks were developed for both current and future needs.

[Figure 3 | A diagram shows the SOSA hardware building blocks.]

Another important piece of SOSA infrastructure is software, whether this is application software (from a SOSA module perspective) or software runtime environments (RTEs). Within SOSA there are three RTE options: FACE, virtual machines (VM), or containers. These SOSA RTEs provide an execution environment for SOSA modules (these are the logical entities used in SOSA to develop capabilities), which a system designer can implement as portable software (FACE), containers, or VM.

The way these run time environments are built, based on the SOSA standard’s use of modules, is that capability can be developed that encompasses both software and hardware. It should be possible for contained pieces of software to have correct, well-defined interfaces with which the system designer knows how to interact. That makes it possible to take a piece of software from one place, such as from a card or some other hardware element, and perform the required configuration needed to support Multi-INT operations.

This is the big challenge: to understand how the data from multiple modalities interact. If a system is put into operation with one modality, and we want it to work simultaneously with another modality, it’s essential to know if the same system infrastructure, not just the cards, is able to support that, including all the front-end hardware. This consideration is important, as the front-end hardware includes front-end sensors that may have certain frequency-bandwidth or dynamic-range limitations.

While the DoD’s goal is to have plug-and-play system building blocks, it’s not clear if that model will enable system designers to reuse modules in another application, such as Multi-INT, without making any modifications. To minimize NRE [non-recurring engineering costs], it’s ideal that software is developed so that it’s both adaptable and can be moved from one place to another.

System design has evolved from discrete systems based on individual modalities to where it stands now, with individual modalities supported at the card level – including software and everything else that goes along with it – in order to deliver a capability. In the future, with Multi-INT, it will be possible to integrate more than one modality onto a single card, with all of the associated software based on SOSA modules. Some of the fundamental pieces are now in place, but what really needs to happen to drive Multi-INT system design is an understanding, including all the specifics, of how to interact between modalities.

Where it stands now: The modality focus is at the card level. With that in mind, commercial off-the-shelf [COTS] vendors need to make sure that their PICs have the right interfaces to move the types of data and information in and out of their card and into other cards associated with a particular modality. Another thing for COTS vendors to consider: whether they have the right infrastructure to support two modalities on the same card now. COTS vendors should reach out to their customers to ask if they are thinking about Multi-INT and whether they have any architecture considerations in mind now.

SOSA brings the benefits of open standards to sensor system design. It also enables migration of applications between domains, such as from ground to airborne platforms. The intent for standards is that they provide building blocks with well-defined open interfaces, and the interfaces determine what’s needed to be able to talk and interact with a particular building block. That makes it easier for an end user to build a system using those building blocks, and then to build a completely different system using those same building blocks. In the case of SOSA, while various domains – air, ground or sea – may embrace the SOSA interfaces, there may still be constraints that prevent the migration of an application from one domain to another, such as size and power limitations.

Ideally, it will be possible to take any SOSA card and use it on any platform: for example, an EW card and its application that are used in an Army ground platform could also be used in an Air Force airborne platform. What needs to be considered ultimately: Whether that model will be simple, or if there are other considerations involved when going from one physical type of platform to another, with both platforms operating in different domains but using the same modality. Will one platform have certain constraints that another platform doesn’t? There will be some cases where the physical space is limited, where the space is too small or there are power constraints. There may be situations where it won’t be possible to migrate a card with certain capabilities into another physical domain. The good news is that SOSA is well positioned to consider these variables.

One potential next step in the evolution of SOSA is for the SOSA Consortium to focus on Multi-INT. The industry is moving into a realm where solutions that were previously discrete instances can migrate into complex systems. While every community within SOSA has its own perspective – whether government, COTS suppliers, system integrators or academia – the SOSA Consortium model enables all of those perspectives to come together in one room where all the different communities can listen and interact with each other. By coming together, all the varied communities can work to evolve the standard and define the next building blocks needed to make Multi-INT a reality. MES

C. Patrick Collier – cofounder of SOSA and chair of its Hardware Working Group – is an open systems architect and systems engineer at Aspen Consulting Group. He was a lead hardware engineer at NAVAIR, where he focused on developing the Hardware Open Systems Technology (HOST) set of standards. Patrick also founded and is currently chair for the VITA 78 (SpaceVPX) and VITA 78.1 (SpaceVPXLite) efforts.

Denis Smetana is a senior product manager for 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 more than 15 years of experience with COTS ISR products. He has a BS in electrical engineering from Virginia Tech.

Aspen Consulting Group · https://www.aspenconsultinggroup.com/

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