Rick Gentile is product manager for Signal Processing, Radar, and RF products at MathWorks. He’s well-known to Microwaves & RF’s readers as an author of the popular Algorithms to Antennas blog. We spoke to Rick about emerging trends in the military and commercial aerospace industries, and the following is an edited transcript of our conversation.
Could you just start by telling me a little bit about yourself?
Sure. I've been at MathWorks for about five years, during which time I've focused on tools that are built on MATLAB and Simulink, particularly those focused on signal processing, RF, radar, and wireless. Before MathWorks, I started off in the radar business in roles at MITRE and MIT Lincoln Laboratory. And in the middle, I was in the signal-processing group at Analog Devices. Here at MathWorks, I've focused on the tools that help customers simulate their systems before they start building them. So, I've had a broad background in terms of RF, microwaves, signal processing, and now system modeling.
What made you want to be an engineer in the first place?
I always was kind of a hobbyist and my uncle was an electrical engineer. I’d see some of the projects he worked on when I was a kid and from then on, I knew that's what I wanted to do.
What are some of the similarities (and differences) between the requirements of military and commercial aerospace customers?
We've seen a lot of convergence in terms of what they're looking for; I think there's a lot of overlap. For example, in the past, some of the mil/aero customers might have started off building radars. Now, they build multifunction RF systems, radar systems with built-in communication systems as well as electronic-warfare functionality, all in the same form factor. So, they now want to squeeze in a lot of different capabilities.
The other similarity is that the systems are much more complex. The requirements their systems must satisfy are a huge step up from previous generations, especially on the aerospace/defense side, where they’re building one system that performs multiple roles. That creates a lot of very different challenges, especially as the need for bandwidth and security are balanced with cost, power, and smaller form factors.
We've also seen mil/aero customers adopting fast-moving technologies from areas driven by LTE and now 5G. They had been used to working at a much slower pace in building a mil/aero system, where the technology may have derived from a custom development. Now, they make a conscious effort to adopt new technologies like software-defined radios or more generally using commercially available technology in their designs to stay competitive. They don't have to develop it themselves and, theoretically, it should help them get to market faster.
One big difference is that military-focused development often involves upgrading existing systems, which may add constraints that would be present in a new commercial system.
The military has standardized on a lot of RF technology. What’s been the impact of that trend?
Across the industry, this standardization has helped to shorten development time for new systems and for system upgrades. In many ways, it makes it easier to adopt commercial technology at larger scales. It also helped to ensure commonality across systems, which also is more friendly to the logistics and fielding of military systems.
From a MathWorks perspective, we have seen a large adoption of our standards-based products. For example, many of our military customers have adopted our 5G Toolbox. We saw this with LTE as well, where they’re using these commercially available standards. Sometimes they're doing it for communications. Sometimes, in passive-radar or signal intelligence systems, they might be using the transmitters for these kinds of systems.
There's more overlap than one would think.
There is overlap.
As the wireless community moves to millimeter-wave (mmWave) frequencies, we find them asking for help in areas where mil/aero customers have been working for a long time. For example, mil/aero applications have had large, phased arrays for a long time. Now, we see wireless customers adopting some of those technologies that we might have engaged with mil/aero customers in the past. Areas like hybrid beamforming, implementing subarrays, and designing how they’re partitioned.
The other big area is that the systems have to coexist in a crowded RF spectrum. This is an area where the overlap must also involve shared algorithmic techniques and resource management to ensure peaceful coexistence when systems operate together.
They seed each other to some extent.
Yes. On one hand, the aero/def industry benefits from the technology that's been driven by the move to 5G. Meanwhile, the wireless folks benefit from years of work the mil/aero industry has helped to drive with systems that implement phased-array systems.
Let’s hear more about the newer integrated systems with radar, communications, and so on.
On the aero/def side, especially for new starts or modernizations, a lot of projects are viewed as not just radar, communications, or electronic warfare, but likely to be a multifunction RF system. It’s a single system, but the flexibility of having a phased-array front end enables switching between different functions as needs shift while systems are operational (Fig. 1).
Sometimes they might operate as a radar, at another time as a communication system, or in passive signal-analysis mode. But it's not three different systems; rather, it's a system that, because of the flexibility that the phased array provides, has the spatial awareness of what's going on around it. It changes how these systems can operate, and a lot more engineering goes into making them work. It's that upfront design activity that drives the complexity, and that's where we come in to help our customers model and simulate their designs to ensure rework isn’t needed at stages later in the project, where it becomes much more costly.
Systems that once did one thing repeatedly now must intersperse these different functions, so areas like resource management become more critical. How do you manage more than one function at the same time? We also see this in a complex system like a 5G base station. You want to achieve the highest possible bandwidth and the lowest latency in a complex, multi-user environment. It’s about that layer above the physical layer, where you're managing the system operations.
So, how does that translate into the challenges faced by customers?
Most often, it’s coming up with a scalable architecture that meets their requirements. The front end of that process is ensuring their design will work when it’s built. That's where our tools start to add value, and it’s where we have a lot of our customer engagements. The challenge for the customer is in making sure that what they end up building is the same system that they modeled in the front-end portion. So, we've seen adoption of our tools across those workflows.
Customers also want to be able to generate code from their models to implement in the system. That’s made trickier for smaller companies and smaller design teams, which is often the case in recent years. So, there are people who have more than one responsibility and those responsibilities cross disciplines. It’s helpful for them to have a technical starting point at each stage of their system design. In the past, there would be specialized engineers for software and hardware, but now the lines get blurred because they have to move from algorithm to hardware much more seamlessly.
I tend to think of MathWorks in that realm of high-level algorithmic modeling. Do you now find yourself being pulled across into the hardware side? Or is it more like creating a bridge that can be crossed from software into hardware?
We're pulled into hardware in the sense that customers use our tools to generate C code, or code for a GPU or FPGA, directly from their models. We also support workflows in which we can connect to software-defined radios and radars, controlling these systems and collecting data from these systems in MATLAB and Simulink. Customers also use our tools to connect to test equipment.
Customers want to ensure the algorithms they have developed match the ones they implement on their end system. The generated code, whether it’s HDL, C, or CUDA code, will run on some end processing element, an FPGA, a processor, or a GPU. There’s a direct connection into deployment from their algorithms. That starts from the upfront prototyping and requirements analysis.
The other connection to hardware that you see is in test and measurement. It’s in being able to feed, say, 5G waveforms into a signal generator and into your system, or taking data off the test equipment. Our IMS demos this year were hardware-based, tightly integrated to radios, radars, and test equipment.
Can you envision your tools touching things like electromagnetic simulation?
Well, our solver-based Antenna Toolbox lets you define an antenna or antenna array, and then we can solve those structures for analyzing currents and the resulting near- and far-field patterns. Our solvers also can be used for installed antenna analysis on electrically large structures. Then, after you’ve done the analysis, one of our workflows directly generates the Gerber files. It’s a full design system.
We have customers that then put that design into larger system models to increase the fidelity of their models. We have a set of apps that make it easy to design elements and arrays using solvers.
A design flow like this gives all engineers a voice at the modeling table. The engineer doing the solver-based antenna can use the outputs of that process to get a prototype built, and then it can be integrated into the system engineers’ flow to see that it works together before doing the end integration. They can smoke out problems beforehand. Some customers get data from anechoic chamber tests, from other testing, or from other solvers, and the design environment can bring that information into the model as well to increase the model fidelity.
So, what comes out of the solver can be pulled back up into the higher-level model.
Exactly. The antenna designers can prototype and analyze to determine the best pattern, and that pattern can be brought into the system model where they can steer it. If a signal were in the null of the pattern, they’d see in the system model that their pattern wasn’t going to work. It’s closing the loop.
Back when I started out, these things would have been done standalone. Maybe we would find such problems in the lab, but most likely we had to bring it out to the site. Today, we have much more insight into whether a design will work, and if it doesn't, we have a model to go back to and tweak until it does.
What about broad trends that you're seeing in aerospace and defense?
There are the multifunction RF systems. Another big one is the broad adoption of artificial intelligence (AI) for things like modulation identification for communication systems or electronic-warfare (EW) systems, target identification, channel estimation, and, more recently, RF fingerprinting, which is the ability for people to use AI to identify trusted nodes.
The other trend is broad adoption of commercially available software-defined radios and radars by the aerospace and defense community. These systems, because they’re all moving into the same RF spectral area, must be more efficient and smarter about interference and coexistence. Some people are looking to AI to help with smart spectrum management, avoiding airport radars and things like that.
Let’s end with an overview of MathWorks’ tools and how they support aerospace and defense.
MATLAB and Simulink are our platform products: MATLAB provides a great platform for algorithm development. Simulink is used widely for multi-domain simulation (baseband and RF), deployment, and as an integration platform for diverse engineering teams (Fig. 2).
In the case of wireless and aero/defense, we've also seen strong adoption of our toolboxes. On both the commercial and aero/defense sides, our standards-based 5G Toolbox and LTE Toolbox see a lot of use. Collectively, our tools are used to develop the layers of media-access control (MAC) and PHY, where they’re building right up from requirements analysis through development and into deployment, putting algorithms on hardware.
Many of our customers are using the tools across the different phases of their project lifecycle, so that the antenna engineer, the RF engineer, and the signal-processing engineer all work on a common simulation framework (Fig. 3). It’s being able to do quick tradeoffs and what-if analysis.
As you build up, say, the channel model, it gradually expands into something looking very much like what the system will be. You’re taking data from the chamber and incorporating that into the system. And each time, you’re taking controlled steps in the design and not having big incremental changes. If something doesn’t work, you can always dial back to something that’s known to work and figure out what you changed.
