The SOSA Technical Standard: Conformance process, success stories, the role of MOSA Q&A with C. Patrick Collier, Co-founder of the SOSA Consortium, Chair of the SOSA Conformance Standing Committee, and Chair of the SOSA Infrastructure Committee
MOSA reaffirmed, empowering small business
By John M. McHale III, Editorial Director
The SOSA Technical Standard: Conformance process, success stories, the role of MOSA Q&A with C. Patrick Collier, Co-founder of the SOSA Consortium, Chair of the SOSA Conformance Standing Committee, and Chair of the SOSA Infrastructure Committee
By John M. McHale III, Editorial Director
SOSA’s impact on electronic warfare solutions By Ian Beavers, Analog Devices, Inc.
Power play: Optimizing SWaP on uncrewed systems
By Dan Taylor, Technology Editor
Managing the data deluge: How military radar systems are getting smarter
By Dan Taylor, Technology Editor
“MOSA is accelerating the adoption of open standards like SOSA®, CMOSS, and OpenVPX to deploy systems faster and more competitively over a platform’s life cycle. Elma is a proud leader in this growing ecosystem that delivers modular computing solutions the warfighter can rely on.”
– Elma Electronic
ON THE COVER
U.S. soldiers assigned to Headquarters & Headquarters Battalion, Division Artillery, 10th Mountain Division, certify table six on the AN/MPQ 64 Sentinel radar system at an Army installation in southern Arizona. Future radar systems will leverage open architectures like the SOSA Technical Standard. U.S. Army photo by Pfc. Malik Waddy-Fiffee.
Ensure mission success with our solutions aligned to the SOSA® standard. From development to deployment, Elma’s systems deliver superior interoperability, rapid integration, and reduced costs - empowering warfighters with proven capabilities ready for tomorrow’s challenges.
With you at every stage!
By John M. McHale III, Editorial Director
Fans of the U.S. Department of Defense’s (DoD’s) modular open systems approach (MOSA) mandate were recently gifted with a new Tri-Service memo emphasizing continued support for MOSA, well-timed with new DoD leadership coming in focused on reforming acquisition.
The first MOSA Tri-Service memo, published in 2019, mandated that all new programs and tech refreshes must leverage MOSA. The latest memo – signed by the Secretaries of the Army, Navy, and Air Force on December 17, 2024 – states that “MOSA shall be implemented and promulgated among the military services to facilitate rapid transition and sharing of advanced warfighting capability to keep pace with the dynamic warfighting threat.”
Simply put, they see MOSA a way to get technology more quickly into the hands of the warfighter, as a tool for speeding up acquisition. Successful MOSA examples were called out in the memo: the Sensor Open Systems Architecture, or SOSA, Technical Standard; Weapons Open Systems Architecture (WOSA); and others.
The memo also lists the three new MOSA sections added by Congress to Title 10 of the United States Code (USC):
› “Section 4401 requires MOSA in major defense acquisition programs [MDAPs],
› Section 4402 requires the implementation of MOSA in program capability development and acquisition weapon system design, to include verification of MOSA requirements, and
› Section 4403 relates to ensuring the availability of major system interface standards and support for MOSA in defense acquisition.”
The service leaders went on to direct that all DoD acquisition officers commit to “all five MOSA pillars: (1) employing a modular design, (2) designating modular interfaces, (3) leveraging consensus-based open standards, (4) establishing enabling environments, and (5) certifying conformance.” To read the memo, visit https://tinyurl.com/y3cced9y.
MOSA initiatives are having an impact as seen by increased requirements for items like SOSA aligned products. However, enthusiasm and mandates cannot change the laws of bureaucratic physics – governments move slow, not fast. MOSA strategies are long-term plays, but faster procurement and acquisition reforms are being called for by the new Trump administration and its supporters.
“Procurement is a mess, and given that the Pentagon purchases more goods, services, and software than all other federal agencies combined, this is a huge crisis,” write Joe Lonsdale, co-founder of Palantir, and his colleague John Noonan in a blog titled “America Needs Better Defense Acquisition.”
Read it here: https://blog.joelonsdale.com/p/america-needs-better-defense-acquisition
They say the new administration “can seize the moment, learn from what worked and didn’t work in [Trump’s] first administration, and make generational changes to our defense bureaucracy.”
Lonsdale and Noonan write that trimming down the “Federal Acquisition Regulation (FAR), first issued on April 1, 1984,” is a good place for the new administration to start. “The [FAR] has almost doubled in length, and with it the complexity of the overall federal procurement processes – not just the Defense Department,” they state. “The FAR was written to level the playing for all companies, big and small, who sought government contracts. But as with many federal regulations, the cure was worse than the symptoms, and it favored the biggest companies with the highest proportion of lawyers.”
Simply put, [the DoD sees] MOSA as a way to get technology more quickly into the hands of the warfighter, as a tool for speeding up acquisition. Successful MOSA examples were called out in the memo: the Sensor Open Systems Architecture, or SOSA, Technical Standard; Weapons Open Systems Architecture (WOSA); and others.
The authors also call Foreign Military Sales (FMS) approval a “suffocating” process that favors the big defense companies, blocking out new innovative companies.
Innovation is needed, as are more organizations like the Defense Innovation Unit (DIU), which we’ve covered in this space before, around its work integrating commercial uncrewed tech into the defense space and which Lonsdale and Noonan tout as an effective acquisition solution.
They also discuss the aforementioned Title 10, saying it has “become swollen with obsolete and choking legal requirements. This creates fertile grounds for long and contentious lawfare when bids don’t go a company’s way, dragging out deployment of new weapons by years. And because it is so difficult for little companies and startups to bring on the lawyers and lobbyists and staff to contend with this dizzying array of red tape, the government must set aside billions in small business contracts just to give them a shot. Small business is the backbone of our country, but welfare does not get the taxpayer the best value for his money.”
They’re absolutely right. However, the participation of small-business electronics suppliers in MOSA initiatives like the SOSA Consortium hint that the new MOSA additions to Title 10 may actually empower small business. We’ll see.
For more on acquisition reform and technology Lonsdale is worth reading and listening to – he’s often a guest on CNBC’s SquawkBox – and is a good follow on Twitter (@JTLonsdale).
By John McHale, Editorial Director
C. Patrick Collier, Co-founder of the SOSA Consortium, Chair of the SOSA Conformance Standing Committee, and Chair of the SOSA Infrastructure Committee
The Sensor Open Systems Architecture, or SOSA, Technical Standard is changing the way the U.S. Department of Defense (DoD) approaches sensor system design. During the recent MOSA Virtual Summit keynote discussion, John McHale, Group Editorial Director of Military Embedded Systems, and C. Patrick Collier, co-founder of the SOSA Consortium, Chair of the SOSA Conformance Standing Committee, and Chair of the SOSA Infrastructure Committee discussed topics including the SOSA conformance process, SOSA success stories, and the driving factors behind the DoD’s modular open systems approach (MOSA) initiative. Edited excerpts follow.
McHALE: Patrick, what drove the DoD to make the mandate on the modular open systems approach (MOSA) initiative? Long-term life cycle costs, faster deployment?
COLLIER: My understanding is that the DoD is looking at how it can conduct acquisition and development of any system or even updates to existing systems. The way acquisition is carried out today, I think – for some or for everybody – is cumbersome at best. And part of the strategy was to say, OK, we’re looking at all these different types of efforts going on within the DoD, whether it’s the SOSA approach, Vehicular Integration for C4ISR/EW Interoperability (VICTORY), C5ISR/EW Modular Open Suite of Standards (CMOSS), or what have you. I think [the DoD] understood the need to focus on how we conduct those acquisitions and having these types of modular systems to build, that capabilities was the way to go, because it would presumably start to lower the cost over the life cycle of the program. That’s my understanding, based on what I’ve seen today, with respect to what the DoD wants to do with MOSA.
McHALE: The SOSA Consortium is celebrating its 10th anniversary. Patrick, as a co-founder, where is the SOSA Technical Standard today?
COLLIER: It’s interesting because, as the name implies, it was based on sensors. Historically, the push was us to figure out how we can develop multi-sensor systems and do it in a way that we could share information, share data, and have somebody be able to move those module elements around. From the SOSA Technical Standard perspective, it’s grown beyond that. We have new members like NASA and DEWS that go beyond just the sensing portion of a platform – it’s the whole platform. Then we have others that make use of the SOSA approach from the sensor perspective but have other parts of it that are non-sensors. So, what we see today
is that the standard has grown in terms of who’s involved and what they’re bringing to it, albeit that the intent is for everybody to align to the SOSA Technical Standard. That’s part of the benefit, having everybody aligning to what the SOSA approach is and what it can provide for you.
The standard itself has grown in terms of maturity. There are portions of the standard that are at a point where, if you look around in the ecosystem, you see companies, organizations building out to what is in the SOSA Technical Standard, based on customer needs. There’s a lot of growth inside the standard and the whole effort in and of itself, based on where it started.
Then you also see it, like I said, with respect to what actually is happening in the standard that we put in initially, all the things that have matured to the point that we think that they’re in a perfect place for people to start building to them, even though some of them have been doing it for a while.
We also see that the standard is growing in terms of a refocus from, say, the infrastructure side of the SOSA approach, which is the Plug-In-Card, the software portion (SW RTEs), things like that, to the SOSA Module side, or those things that let you build out the capabilities for a sensing system. There’s a focus on getting those to the maturity level where they’re on par with the infrastructure side. So, with respect to that, the standard itself has grown in terms of understanding that there are things we need to spend more time on so that we bring everything to an equal playing field.
McHALE: Revision 1.0 [of the SOSA Technical Standard] came out in 2021 and you provided snapshots before then, and [then] you had snapshots coming after that. What’s coming up next? Is Revision 2.0 coming soon?
COLLIER: Snapshot 2, Version 2 is the latest one. Snapshot 3 is scheduled to come out within the next month or month and a half, and then the consortium agreed that we would go to a Snapshot 4 before we hit Version 2 of the standard. What we’re driving toward from Snapshot 3 Version 2 is sort of a quick release. We get Version 3 out, we do the updates, the focused updates. We’re going to do a quick release based on those pieces that are of high priority for us. And then once we get Snapshot 4 out, we’ll go straight into getting Version 2 ready. That’s in the near term. We’re looking at six to nine months after the Snapshot 4 release for a Version 2.0 release of the Technical Standard.
McHALE: Where has the SOSA Technical Standard had the most impact? Are there success stories now that you can talk to?
COLLIER: Yes. One example comes from the U.S. Army, a founding member of the SOSA Consortium. The Army spent a lot of time looking how they can leverage the SOSA Technical Standard based on what they do
with CMOSS, especially with CMOSS Mounted Form Factor (CMFF). With lessons learned that they bring back into the standard, I consider that a huge success story. (Figure 1.)
The Air Force also is constantly talking about the number of programs that are making use of the SOSA approach for modularity. There are a lot of success stories that are coming into play. The more SOSA aligned content is successfully pulled into programs, the faster its adoption will grow.
McHALE: By leveraging SOSA aligned content, do you mean that program requirements are calling for SOSA aligned products?
COLLIER: Yes. The use of the word “aligns” is specific, because we don’t have an operational conformance program yet, so you’ll see a lot of people saying or wanting to have SOSA aligned products, which [will do] up until we get SOSA conformance, and then you’ll have SOSA conformant products.
McHALE: Can you speak to the technical architecture of the SOSA Technical Standard?
COLLIER: Yes. When I mentioned before about the infrastructure side and the SOSA module side, this graphic shows there are two pieces of the SOSA Technical Standard. (Figure 2.) The left side is for the SOSA modules that are the parts that allow you to build out a capability. When we first started work on the SOSA Technical Standard, we originally focused on five sensing modalities, decomposed them, and looked for similarities between them. What popped out were these SOSA Modules that are logical entities and that have defined functions and behaviors.
We always talk internally that the SOSA Modules are what people would actually acquire in the ideal case. They would acquire these capabilities, and they would use the infrastructure on the right-hand side, whether it’s the Plug-In Card, power supplies, software runtime environments, and the things on the right, like interactions, in order to implement a SOSA Module and convey data/information from one SOSA Module to another. They use the right-hand side to put all that together.
This one graphic displays everything that, if you went to the standard, you would see piece by piece. We talk about the reference architecture, the SOSA Modules, how you use the SOSA Modules to build out capabilities, and then you go into each different piece and determine if you want to do a SOSA Module for the Emitter/Collector (SOSA Module 2.4), or for Image Processing (SOSA Module 3.3), then perhaps you do that do it inside a Plug-In Card, or maybe as a software entity (SW RTE) and build it out that way.
McHALE: There is a common misconception that MOSA is a standard. It’s not, it’s a strategy. The SOSA approach is an example of MOSA. So, you cannot be MOSA compliant because MOSA is not a standard. Patrick, can you take us through the difference between compliance, conformance, and alignment?
COLLIER: Compliance is adherence to a law or regulation, whereas conformance for us is adherence to a standard body or standard and the requirements within. The alignment piece, the SOSA Aligned Product Directory, is an interim step. There are a lot of companies that are building to the SOSA Technical Standard right now and they have been for some time. When I talked about maturity, there were more than a handful of companies that were building out Plug-In Cards from a SOSA snapshot, not even the first version of the standard, because they saw that there was a need and they wanted to be the one to get their products out for their customers.
Since the conformance program is not operational yet, we wanted to find a way for people to say, “OK, I’m procuring something from the SOSA Technical Standard, even though it’s not verified and certified.” That’s where the SOSA Alignment Product Directory came into play. The [SOSA Consortium’s] Business Working Group (BWG) decided that we want to be able to track who’s building what and stating that it’s aligned to the standard. That’s why we have an aligned products directory. Looking at it, you get a good view of all the products and there’s a lot of them. It’s crazy how much people are building to the standard. [Editor’s note: One does not have to be a SOSA Consortium member to view The Open Group Directory of Products Aligned to the SOSA Technical Standard, but companies must be a SOSA member to have a product in it.]
McHALE: How will you begin the conformance process?
COLLIER: We’re doing it in a phased approach. Because the SOSA Technical Standard is so complex and there is so much inside it and so many moving parts, we decided we’re going to pull in the pieces that are mature enough at this point to begin a conformance program.
Anything that is part of the conformance program – once it starts – gets pulled off the aligned products directory. The directory is that waypoint where people can get out of view for what is happening within the SOSA approach, before conformance sets in. What’s in the aligned products directory stays there until it becomes part of the conformance program.
Right now, there are two pieces within the SOSA Technical Standard that we’ve published, documentation for conformance, that being Chassis Level connectors and Power Supplies Cards (PSCs). Those two pieces – if we were to start the program right now – anything related to them on the aligned products directory would get pulled off. There have been discussions about having a grace period so that people can prepare if something is going to get pulled out of the directory. The beauty of the aligned product directory is that it’s giving everybody an opportunity to see what is available, what’s not available, and what they can use.
The drawback is that – based when you mentioned MOSA and requirements within MOSA – you don’t have the assurance that something’s gone through verification and certification, and that it fully adheres to the standard. There’s a good point and a bad point to it: You can get access to the product because you’re in the aligned products directory, but you don’t have the conformance piece to it. We must wait for that to happen.
McHALE: As you mentioned, the military is already adopting and requiring SOSA aligned products. So even with the conformance process not yet being completed, and program requirements asking for SOSA aligned, does the DoD not waiting for the conformance process before leveraging SOSA content change how you might approach a conformance process? For example, [it could be] a way to speed up, maybe make the conformance process a little less time-consuming, especially with the push to speed up DoD acquisition. Does that influence how you go about conformance?
COLLIER: It does. Cost is constantly in the back of the conformance standing committee’s minds, because cost is one of the driving factors as to why most of [it] makes sense; you want to be able to acquire products in a timely fashion and not have to pay more than you need to and pay again for something that’s already been developed. The idea of having product-line architectures in at the supplier base – they can draw from those, and then the customers have an opportunity to go to different places to get their products, just like you and I would if we went shopping for something for personal use.
The conformance program, from a cost perspective, is always making sure that everything that we do and that we would levy upon anybody who goes through the program is not going to cost an arm and a leg. (Figure 3.)
There’s a secondary conversation about fees and everything that goes with the conformance program that’s happened over the past six to seven months. That’s something that people need to be aware of, that conformance isn’t free, and when you pay for it, you’re paying for it because you have the benefit of having a third party do that work for you.
The Conformance Standing Committee (CStC) wants to make sure that everything that we do is streamlined and the tools that we make allow for automation, so it will take less time and cost less for somebody to get through verification. [They’re included] only if there’s a need for the tool.
You can get a lot of what you need through inspection, depending on how you do the inspection, for adherence to the standard. In any case, when we talk about tools, the types of tools that we want to have are the ones where we automate the process so that the person gets in, does their stuff with the Verification Authority (VA), and then they get out. Like I said before, they don’t pay more than they need to get what they want from that VA.
When you think about conformance, there’s a lot of people within the consortium that are going back and looking at the requirements they’ve written, and ask: Does that make sense? Is it something that we can pull through or push through conformance, through verification and certification? If not, they either update the requirement or pull the requirement. The nice thing is that there’s a lot of review going on with the requirements themselves to make sure that they do make sense and that they’re written properly, and that we can get what we want out of it.
McHALE: It’s been said that MOSA initiatives like the SOSA Technical Standard will in the long run enable faster technology acquisition for the DoD, as the [initiatives] enable open architectures to use commercial technology. How does the SOSA consortium and other MOSA initiatives help bring new commercial innovation into DoD procurement channels?
COLLIER: These types of standards lower the barrier of entry because suppliers can build to these products. It gives them and the government the opportunity to display those products, and for the government to say:
Here’s another avenue to purchase those or acquire those products. From the standards perspective and the MOSA approach, the intent is always to pull these things into the acquisition process early, so that people start thinking about if they have a new program, new acquisition, or an upgrade, what can they do to make it so they maximize the use of these modular elements as much as they can, and by doing that, show that if they have these common interfaces for system modules, they know how they fit together, they know how they can build up the whole system early in the process. That then carries it along through the acquisition process and should allow them to both meet schedule and lower the cost.
McHALE: What are some common misconceptions about the SOSA Technical Standard? I know one of them is that it’s not sensors only, but also mission compute, among other areas.
COLLIER: One concern [about the standard] for people is that it stifles innovation. The intent of this standard, this effort in particular, is you build to the interfaces from the SOSA Technical Standard so that there’s a distinct place where we have standardization and anything behind that is left up to the supplier to distinguish themselves through innovation. None of this is meant to imply that we’re preventing anybody from doing something that makes them unique, that says, OK, you know this standard product is what I need, and the capability inside the interfaces is exactly what I need. That’s been a big misconception across standards in general, especially within the SOSA Technical Standard, because we always make it a point to say this is where we stop, and anything besides that is up to [your company] to do what you want to do to [distinguish] yourselves from your competitors and make your product the most innovative and unique thing that a customer would want to get.
Another concern is because, like you mentioned, it was just for sensors. It is, but it’s grown beyond that. Another one is that we tend to take too long to do things. I think for most people there’s a trade-off between getting something done right in a standard way. There’s always going to be cases where people have unique items that are nonstandard. For us, we maximize prevalent elements, those products we can standardize. But we don’t prevent people from doing things that are nonstandard.
› To view the MOSA Virtual Summit keynote session and audience Q and A, register here for the on-demand version.
By Ian Beavers
The Sensor Open Systems Architecture, or SOSA, Technical Standard has made deployment of new electronic warfare (EW) solutions faster and more modular now that a standardized chassis hardware framework has been established. No longer will the entire EW system need to be captive to a single supplier. The latest technology can now be released into the field without the need for new program specifications. EW integrators and their suppliers can focus on their specific area of expertise among the major system component blocks: radio-frequency (RF) front end, digital processing, and algorithms. Platform re-use can be accomplished with one or more of these three major components upgraded to a new solution. Integrators can now provide focused refresh upgrades in a more timely fashion based on the advancements in just one of these areas, without waiting for a revision through an entirely new program.
As the Sensor Open Systems Architecture, or SOSA, approach moves development away from a dedicated approach for a targeted electronic warfare (EW) or communications system, its modular approach enables updates of piecewise sections. Under this approach, open system architectures enable for repurposing for new use cases, while fixed radio configurations for radio-frequency (RF) bandwidths and postprocessing can now process different bands. For example, a system upgrade can now change the RF front-end module and keep the other incumbent hardware in place. Another example: A system that supported only a fixed observable X-band can now be fitted for a wide 2-GHz to 18-GHz observation, along with digital filtering and frequency-hopping to stare at selectable swaths up to 4 GHz of bandwidth.
With only an RF front-end modification, an entirely new system capability can be achieved with only partial discrete changes. Integrators can also add incremental secondary feature sets like low-latency loopback paths, fractional sample-rate precision, and linear signal correction as part of the RF updates. The SOSA approach now enables EW providers to innovate at the speed of silicon advancements in incremental fashion with rapid deployments to the field.
Before: New requirements called for new systems
Historically, the specifics of an RF system would need a new system if new requirements emerged. A heterodyne architecture for an X-band radio would require fixed band filtering and amplifiers, a defined local oscillator, and dedicated processing within an 8-GHz to 12-GHz spectrum. When an updated requirement for a more agile EW system observing 2 GHz to 18 Ghz is established, this legacy system would need to be replaced in its entirety, as it would not be flexible enough to support other wider frequency bands.
Targeted upgrades of technology were not easily accomplished, as the in-place system components could not be swapped with another vendor’s using different instruction sets, connectors, and standards. This situation created unwanted complexity for field teams that wanted to adapt or upgrade their intelligence, as the ability to adapt components would have provided faster operational readiness to defend against evolving threats.
As the SOSA approach enables modular hardware plug-in card profiles (PICPs), let’s modify this example: Instead of requiring a new full system of RF front end, digital processing, and algorithms, only the RF section needs to be replaced. Moreover, this update can be performed in the field without sending the original unit back to its manufacturing location. A 3U VPX module supporting a wideband 2-GHz to 18-GHz radio can be used as the upgrade impetus for the new solution. A wideband direct-RF software-defined radio (SDR) could enable even more flexibility as an alternate solution for the 3U VPX module to change RF configurations.
An SDR solution further enables full configurability for unique custom frequency bands of interest across a wide 2-GHz to 18-GHz range. A programmable filter within the RF signal chain allows for custom on-the-fly updates, while digital downconversion (DDC) in the digital domain provides further targeted filtering of noise. By targeting smaller bandwidths with digital filtering of wideband noise, the dynamic range is expanded approximately +6dB for each reduction in the bandwidth by a multiple of 4. A configurable SDR in the field realizes channel, dynamic range, and instantaneousbandwidth performance tradeoff options that might not have been possible with legacy closed systems. (Figure 1.)
By leveraging a companion numerically controlled oscillator (NCO) within the DDC block, an effective digital local oscillator (LO) provides further sampling power. The NCO enables tuning of the decimated bandwidth to the specific frequency of interest using precise frequency-tuning words, while multiple banks of preset filter coefficients allow for fast frequency hopping (FFH) between observable bandwidths. Rapidly changing NCO tuning words essentially permits observable bandwidths on demand. Digital-to-analog converter (DAC) transmit paths use the inverse digital up-conversion method, respectively, to achieve the same effect. Observation of multiple bands simultaneously within the SDR can be achieved using DDC filtering and NCO tuning. (Figure 2.)
The OpenVPX (VITA 65) and VPX (VITA 46) standards are fundamental to the technical success of both the U.S. Army’s Modular Open Radio Frequency Architecture (MORA) and the SOSA approach. The VITA standards provide a high-performance computing architecture that can handle the demanding data-processing requirements of modern EW systems. The switched-fabric architecture of VPX also enables data transfer at higher rates and wider scalability when compared to incumbent bus-based systems of the past. This common framework is imperative for processing the large quantities of data generated in real time by EW RF sensors and their respective algorithms.
A module that conforms to the MORA 2.4 compliance standard –defined for SDR, tuner, and radiohead payloads – will be compatible in a VPX chassis. MORA creates a standard for the controlling aspects of the VPX RF payloads like bandwidth, gain, and frequency; without it, each piece of hardware would have a unique identifying aspect that would require custom hardware configuration.
With MORA compliant modules, the new SDR hardware can conveniently be controlled through a standard instruction set, as standardization enables rapid RF payload integration. System upgrades are also streamlined as new technology becomes available for installation. Deployment of many similar upgraded systems enables a common proliferation of instructions to field teams.
The slow-update limitations of legacy closed EW systems appear to be fading. The SOSA Technical Standard and MORA framework enable faster technology updates at the speed of progress, rather than at the slow rate of closed-system programs. These approaches enable new pathways of flexible RF front-end changes for EW systems of the future. A wideband direct-RF SDR offers several alternate RF processing solutions for the 3U VPX module to change RF configurations. Practically, real-world modules such as the ADSY1100 carry a wideband multichannel RF digitizer in a 3U VPX SOSA aligned format, featuring DAC sample rates up to 28 GS/sec and analog-to-digital (ADC) sample rates up to 20 GS/sec. RF personality cards customize the signal path observations. With the help of standardization through the SOSA approach, MORA, and other compliance efforts, new EW capabilities will be able to catapult defense systems into the next generation. ■
Ian Beavers is a Field Applications Engineer and Customer Labs manager for the Aerospace and Defense Systems team at Analog Devices in Durham, North Carolina. He has worked for the company since 1996 and has more than 30 years of experience in the semiconductor industry. Ian earned a bachelor’s degree in electrical engineering from North Carolina State University and an MBA from the University of North Carolina at Greensboro. Readers may reach the author at Ian.Beavers@analog.com
Inc. • https://www.analog.com
By Dan Taylor
The prospect facing defense contractors is considerable: Pack more computing power, more sensors, and more capabilities into smaller spaces while extending mission endurance. As uncrewed platforms evolve from simple remote-controlled vehicles into autonomous systems with sophisticated sensor arrays, every milliwatt of power must be carefully managed.
A small reconnaissance uncrewed aerial system (UAS) launches into a contested airspace, and its internal systems immediately get to work. The tiny aircraft’s processors crunch real-time sensor data while running artificial intelligence (AI) algorithms, its phased-array radar scanning for threats.
Just a decade ago, placing capabilities such as AI and radar processing on a small UAS would have required a much larger vehicle – or would have drained the batteries in minutes. Now rapid advances in power management and electronics are shrinking what’s possible into increasingly compact packages.
The big challenge: Balancing SWaP-C
Adding capabilities to a platform means – almost inevitably – that power consumption will increase. The U.S. Department of Defense (DoD) has tasked contractors with doing exactly the opposite, however, and that requires a lot of creativity in the industry.
It’s a Herculean task to deliver high-performance processing, sensor fusion, radar, and communications capabilities while working within strict size, weight, power, and cost (SWaP-C) constraints, notes Jeff Massman, senior manager of phased-array platforms for aerospace and defense at Analog Devices (Colorado Springs, Colorado).
“Unmanned systems are becoming increasingly autonomous, requiring real-time AI-driven decision-making, phased-array radar for situational awareness, and high-bandwidth RF communication links, all of which drive up power consumption,” Massman says.
Mark Littlefield, director of systems products at Elma Electronic (Fremont, California), says because uncrewed systems are particularly SWaP-sensitive, “power management and the space taken by the payload hardware are probably the two prime concerns for the system integrator.”
Some experts see size constraints at the component level as the main concern.
“As you get smaller and smaller, all the necessary logistical components of an embedded product – i.e., connectors, power supplies, etc. – play an outsized role in the volume that the product fills,” says Noah Donaldson, chief technical officer at Annapolis Micro Systems (Annapolis, Maryland).
As processing performance increases, so does power-management complexity.
“High-performance computing continues to evolve exponentially and so does the requirement for power,” says Shaun Fischer, division vice president of business development at Abaco Systems (Huntsville, Alabama). “With the growing application of automation and autonomy, the need for more and more power will not subside.” (Figure 1.)
These mounting power needs are compounded by harsh operating environments. Massman notes that “these systems must operate in harsh and contested environments, such as high altitudes and extreme temperatures, where power efficiency directly impacts mission endurance.”
Defense contractors are developing solutions to handle increased sensor and processing loads while maintaining strict power constraints. They range from packaging techniques to advanced materials and intelligent power-management systems.
“We are developing high-efficiency power-conversion solutions leveraging GaN [gallium nitride] and SiC [silicon carbide] materials, which provide higher power density and faster switching speeds while reducing thermal losses,” Massman says. “These innovations are particularly beneficial for powering phased-array antennas, which require precise power distribution to multiple digitizers, beamforming ICs, and transceivers.”
Some companies are solving power management challenges through new packaging approaches.
“We’ve begun integrating new power supplies that meet environmental and performance requirements yet are packaged in unique ways to better fit in small form factors,” Donaldson says, pointing to a direct RF small-form-factor module the company has developed that is a fraction of the size of a 3U VPX board.
Analog Devices engineers developed a packaging technique called 3D heterogeneous integration and high-conductivity substrates, which “enhance heat dissipation while maintaining compact system footprints,” Massman says.
FIGURE 2
The WILDSTAR SAF1 small-formfactor module may be deployed as a single standalone unit for edge applications close to the sensor and in other tight-envelope environments, or dual-mounted on a 3U OpenVPX baseboard for processingintensive applications such as electronic warfare (EW) and signals intelligence (SIGINT). Image courtesy Annapolis Micro Systems.
As autonomous platforms pack more processing power into smaller spaces, thermal challenges grow.
“Thermal management is critical for maintaining performance and reliability in unmanned systems, particularly as they integrate power-dense electronics like phased arrays, AI processors, and multichannel RF transceivers,” Massman says.
Defense contractors are employing a range of solutions – and for some, traditional cooling works best.
“When we can, we use the same tried-and-true low-cost solutions we always have – conductioncooled solid metal frames,” Donaldson says. (Figure 2.)
“Where power density requires it, we use more sophisticated techniques, like heat pipes, vapor chambers, more exotic materials, or liquid,” he adds.
More complex cooling solutions also require more intelligent thermal-management systems. “Adaptive power scaling further optimizes thermal performance by dynamically adjusting power consumption based on sensor activity, RF load, and mission priorities,” ADI’s Massman explains. “These innovations help unmanned platforms maintain consistent phased-array radar performance, AI-driven decision-making, and high-speed communications, even in high-altitude, high-temperature, or contested environments.”
Engineers must keep the surrounding environment in mind when designing these electronics. Once drones get above 25,000 to 30,000 feet, exchanging heat with cooling surfaces gets more difficult.
That means even though the air itself is very cold, it’s difficult in that environment to keep the electronics cool, Littlefield says. “As a result, for extremely high altitudes one must take advantage of other methods to manage heat like using the airframe or fuel tanks as heat sinks, or even actively managing the electronics by turning things off if they are not needed for periods of time. This last approach requires a sophisticated chassis-management mechanism.”
Power efficiency is also enabled by advances in semiconductor materials and fabrication techniques. These developments range from wide-bandgap semiconductors to chiplet architectures.
For example, Analog Devices is using GaN-based power solutions that the company says generate less heat and offer better efficiency compared to silicon-based devices – which reduces the need for active cooling.
“Wide-bandgap semiconductors like GaN and SiC are revolutionizing power solutions by enhancing efficiency, reducing energy losses, and improving thermal performance, which is critical for unmanned systems and phased-array applications,” Massman says. “GaN’s higher switching speeds and lower conduction losses allow for more compact, power-efficient RF power amplifiers, beamforming ICs, and radar transceivers, significantly improving phased-array performance.” (Figure 3.)
Chiplets can help alleviate power challenges that come from high-performance processors and FPGAs. “The latest FPGAs and GPUs are extremely capable but also powerhungry and untargeted,” Donaldson says. “On the other hand, smaller, more modular chiplets can be mixed and matched at a quicker lead time and lower NRE to optimize power efficiency and performance for particular platforms.”
Fischer asserts that the industry is increasingly moving toward chiplet-based architectures. “The future of high-performance computing is moving towards advanced packaging, where the processing, memory, and other critical computing resources are evolving to chiplets or miniaturized building blocks of various functionalities. Regardless of the system function, the main advantage of chiplets for power consumption is the reduction of energy waste through advanced packaging.
“Reducing power consumption isn’t really an option moving forward, so improving efficiency is key,” he adds.
Open architectures like the Sensor Open Systems Architecture, or SOSA, Technical Standard, provide for small form factors and address SWaP challenges while also enabling interoperability and affordability.
“By leveraging SOSA aligned architectures, such as 3U VPX and VNX+, power-management solutions can be modular, allowing for seamless integration of next-generation beamforming ICs, RF transceivers, and AI processors,” Massman explains. “Standardizing power distribution, data interfaces, and thermal management across SOSA [aligned] platforms reduces development time and ensures compatibility with evolving mission needs.”
Still, there are additional considerations when it comes to using open standards in this area. Littlefield says the SOSA approach is useful for larger platforms, but uncrewed systems can be small enough where it’s hard to use standards-based commercial off-the-shelf (COTS) components.
“Fortunately, [the SOSA Consortium] saw this problem coming and started a small-form-factor effort several years ago, resulting in VNX+ (VITA 90) being adopted into the Technical Standard,” Littlefield says. “VNX+ is small enough that many uncrewed systems that in the past couldn’t use COTS due to SWaP constraints can now reap the benefits of [the SOSA approach].” ■
An E-2D Hawkeye attached to Airborne Command and Control Squadron (VAW-120) takes off on Nimitz-class aircraft carrier USS George Washington (CVN 73).
The E-2D carries AN/APY-9 radar, radio suite, mission computer, integrated satellite communications, and updated flight management system. The APY-9 radar features active electronically scanned array (AESA) radar, which employs electronic scanning to the mechanical rotation of the radar in its radome. U.S. Navy photo by Mass Communication Specialist 3rd Class August Clawson.
By Dan Taylor
Every second, military radar systems collect terabytes of data about potential threats in the skies above. But having data isn’t the same as having intelligence. In an age of information overflow, the U.S. Department of Defense faces a new kind of challenge: turning this tsunami of radar data into actionable battlefield insights.
The military stakes couldn’t be higher: Air and missile defense systems must detect, track, and respond to threats in real time. With hypersonic missiles, drone swarms, and other sophisticated threats becoming increasingly common, radar operators need to process and analyze massive amounts of data faster than ever before. A delay of even a few seconds in converting raw radar data into actionable intelligence could mean the difference between a successful intercept and a catastrophic failure.
Today’s military radar systems collect enormous amounts of data. Sorting through this mountain of information quickly enough to be useful in combat is the big problem facing industry.
The first hurdle is simply moving all this information around. “With direct digitization and wide bandwidth sensors, radar front-ends are producing more data that needs to be communicated to the back-end processor,” says Matt Alexander, chief engineer for sensor systems at Mercury Systems (Andover, Massachusetts). “This is driving the need for high-speed fabrics such as 100/400 Gbit Ethernet over fiber.”
Traditional processing power just isn’t enough anymore. “Even traditional radar processing becomes more computationally complex due to the increase in data,” he continues. “This is driving the need for the highestperforming processors.”
Carl Nardell, principal engineering fellow at Raytheon (Tucson, Arizona), says that while radar systems generate massive amounts of data, “most of this data is not very useful.” The solution? Process it immediately, he says. “The more we can process data at the point of collection, the more tractable the problem becomes.” (Figure 1.)
Industry is racing to develop smarter ways to handle this information. Dr. Justin Pearson, senior director of architecture and business growth in aerospace and defense at Wind River (Alameda, California), says that the most promising technology includes edge computing, high-performance data compression, and cloud integration for managing massive real-time data flows.
The role of artificial intelligence
Artificial intelligence (AI) is quickly becoming a useful tool for turning all this radar data into useful battlefield information. By processing information faster than humans and spotting patterns that might otherwise be missed, AI is changing how military forces collect and analyze radar data.
One of the big ways AI can help is that it is capable of spotting things that traditional processing methods might miss, Alexander says.
“AI has the ability to improve sensor effectiveness by leveraging the increase in data and by exploiting features in data not exploitable by conventional processing techniques,” he says.
He points out that AI could help with several key tasks: better filtering out enemy jamming, identifying the difference between real threats and false alarms, identifying what kind of object it’s seeing, and keeping track of targets in confusing situations and cluttered environments.
The crucial advantage of AI systems is speed. Nardell notes that “a single graphics processing unit (GPU) can perform millions of times more analysis operations than a human.” This amped processing power means faster decision-making in critical situations.
“By using AI, we can automate intelligence analysis to provide useful insights in seconds rather than hours, days or weeks,” he adds. “AI has the ability to massively scale up human operations. AI can help process reams of data into actionable intelligence and accurate targeting information at speed and scale in high-risk environments.”
However, there are limits to how AI can be used in military systems. Pearson notes that it’s still early days for AI, and it can’t be used yet in safety-certified elements. However, AI can still be helpful by helping radar systems work in difficult conditions, he says.
“[AI can] recognize and classify targets using image recognition and radar signal processing, with deep learning models identifying objects like vehicles, aircraft, or drones even in degraded environments such as heavy jamming or low visibility,” Pearson explains.
AI is also proving valuable in countering enemy actions. “AI will be able to more effectively make use of multifunction apertures,” Alexander says. “Dynamic scheduling of sub-apertures is a complex problem that AI will be able to optimize.”
While AI currently gets most of the attention, defense industry engineers are looking at other new ways to handle the massive amounts of radar data produced every day. One promising approach involves using light instead of electricity to process data.
“While digital signal processing remains a foundational component to radars, novel photonic and analog processors are being developed to process – on operationally relevant timescales – large quantities of data,” Alexander says. “We are seeing an increasing interest in photonic interconnects and inclusion of photonic processors.”
2
The Mercury Systems HDS6605 is a 6U OpenVPX server blade featuring Intel’s 2nd-generation Xeon scalable processor for edge-processing applications. (Image courtesy Mercury Systems)
Combining data from multiple sources is another strategy. “Data fusion, particularly across multiple platforms and multiple sensor types, assists in reducing false alarms and discriminating decoys,” he explains. (Figure 2.)
The challenge is similar to those faced in other technological areas, Nardell says. “Electronic warfare and sensor data analysis are fundamentally becoming big data problems,” he says. “The data is simply too large and complex to manage or process using traditional methods.”
Nardell believes traditional computer science offers some solutions to the data glut, pointing to relational databases, parallel compute techniques, and edge processing as tools that could help with the dataprocessing challenge.
High-performance computing is another important tool, Pearson says, as it can perform large-scale data processing through parallel computing, accelerating simulations, real-time decisions, and predictive modeling (such as in combat scenario planning).
Delivering intelligence to the battlefield
Edge computing is particularly promising. Processing data near the battlefield slashes latency and bandwidth needs, allowing for real-time analytics even in remote environments, Pearson says, noting that radar systems are able to analyze data locally “to trigger alarms without waiting for centralized systems.”
Raytheon is working to deploy GPUs at the point of intelligence collection to enable important, useful data to be refined and routed to the warfighter quickly, Nardell says.
“We now have the ability to process data at the point of collection with compute power that had only been available in a datacenter, mainframe, or server,” he says.
The goal is to reduce large amounts of data into useful information that can be easily shared, which “allows a very small amount of transferred data to impact the OODA [observe, orient, decide, and act] loop of an adjacent platform or even commander,” Alexander says.
The military can test these systems during training to ensure they work in combat. “Agreeing on what data and insights must be shared can be proven out in training exercises and thus ensure a robust networked effect during a future conflict,” Alexander adds.
Local storage systems are also important when communications are cut off. Pearson points to promising new tech like distributed storage systems with local caching that enable offline access during disruptions, as well as ruggedized tablets and augmented-reality goggles that can provide real-time mission insights. (Figure 3.)
Open standards like the Sensor Open Systems Architecture, or SOSA, Technical Standard are changing how the defense industry approaches radar system development and procurement, making it easier to integrate new technologies and work with multiple vendors.
“Open standards widen the pool of candidate technology and capability providers,” Alexander says. “For instance, some open standards allow for the insertion of 3rd-party radar modes. This type of model enables dozens of organi-
zations to develop and integrate radar mode IP in addition to the radar OEM [original equipment manufacturer], making the radar a best-of-breed system.”
Software containers have been particularly helpful in implementing these standards.
“Containerized software has been the biggest enabler for drawing upon the best AI capabilities from any source,” Nardell says. “The standardization of hardware has commoditized compute capability such as GPUs, enabling the latest and best hardware to be applied to this area without updating algorithmic software.”
At the end of the day, using SOSA aligned parts just makes it easier for systems to work together, Pearson says.
“The SOSA [approach] provides well-defined, standardized interfaces that enable seamless integration of hardware and software components from different vendors, ensuring that radar, sensor, and computing systems can exchange data securely and operate collaboratively, reducing proprietary lock-ins,” he says.
The modular nature of parts aligned with the SOSA Technical Standard also makes it easier to upgrade systems. “SOSA encourages modular components that are easily upgraded or replaced, allowing new capabilities like advanced data encryption modules, AI accelerators, or storage systems to be integrated without redesigning the entire system,” Pearson continues.
Adherence to open standards also helps the industry in another major way – saving money.
“Open standards lower development costs and extend system lifespan by allowing easy replacement or upgrading of components without requiring overhauls,” Pearson says. “A radar system with SOSA compliant components can receive upgrades to processors or storage modules without major redesigns.” ■
The capability to process military radar data is one thing – protecting it is quite
A
consequences for military operations, so the defense industry is building protection into systems from the
up rather than adding it later.
“Security must be built in, not bolted on as an afterthought,” says Matt Alexander, chief engineer for sensor systems at Mercury Systems (Andover, Massachusetts), noting that Mercury Systems uses various methods to protect sensitive information, including FPGA [field-programmable gate array]-based cryptography, root of security, secure boot, sensors, fingerprinting, and physical protections against system infiltration.
While the amount of data has increased dramatically, the fundamental security challenge remains familiar. Carl Nardell, principal engineering fellow at Raytheon (Tucson, Arizona), does not believe the industry will have trouble solving it.
“Data security is not a new problem, and [it’s] one that simply is compounded by the increased flow of data between sensors and consumers of data,” Nardell says. “While data security requires a certain amount of overhead, both in terms of data volume and processing, this does not represent a new or limiting challenge.”
When it comes to radar data, Dr. Justin Pearson, senior director of architecture and business growth in aerospace and defense at Wind River (Alameda, California), says good security practices include using “end-to-end encryption protocols like AES-256, TLS, and VPNs; applying zero-trust security models with continuous verification; and implementing strong key management systems.”
Physical protection is just as important as digital security. Alexander points out that advanced protection technologies “can mitigate reverse engineering” and “safeguard confidential data and IP against adversarial threats even when a system has been compromised.”
Regular testing and training are also essential parts of data protection. Pearson emphasizes the importance of conducting regular security audits and training personnel on cybersecurity best practices. ■