In the Aerospace field moving from concept to proof-of-concept quickly is vital to gain the edge. Validating ideas and testing early results with software is a key step that must happen before testing with real-world signals in the lab or on the range. In order to do that, radar researchers and systems engineers use modeling and simulation tools such as Python, C/C++, and MathWorks MATLAB® software.
The next step is migrating IP from simulation to a hardware testbed, which can be a big challenge if the software tools used are not designed to scale throughout the development cycle. And this is aggravated if researchers and engineers are forced to build custom hardware, rather than utilizing off-the-shelf technologies for RF and digital I/O, signal processing, data movement, and storage.
In this article, we analyze how to rapidly migrate from a model done with MathWorks tools for modeling and simulation to a radar prototyping testbed built upon COTS components from NI.
Radar Simulation: Where to start from
An idea to bring new capability to radar systems can entail new waveforms, algorithms, and architectures, and/or new RF or digital components. When consider new algorithms, we need to take into account that performance can be affected by other signals that drown it, and that it will not operate effectively in a congested spectrum. In this case, adaptive or cognitive techniques such as spectrum interference avoidance are important to ensure a radar could operate in less-congested spectrum. And what if the radar has difficulty determining targets against a cluttered background? Machine-learning, Gaussian-based approaches could be more effective than human operators at distinguishing targets from clutter.
All new ideas need to be validated before a highly costly and time-consuming implementation, and this is where modeling and simulation tools are key.
Modeling and Simulation
The first step for a researcher is to show that, conceptually, their idea is viable. It’s critical to explore the viability of a novel concept before spending time and money on testing it out with real-world hardware—and that’s why the modeling and simulation phase is so important.
Radar researchers and systems engineers often use tools such as MathWorks MATLAB software and MathWorks Simulink® software to interactively design waveforms and sensor arrays and to explore various complex trade-offs across the entire multifunction radar system workflow—from RF and antenna components to signal processing algorithms. Because you can design and debug complete radar models at the earliest stage of the project, you can preempt and eliminate costly redesigns and utilize automatically generated code within tactical systems.
For accelerated development, MathWorks offers libraries of algorithms—including matched filtering,
adaptive beamforming, target detection, space-time adaptive processing, and environmental and clutter modeling—that you can customize for your specific application. Additionally, you can model ground-based, airborne, and ship-borne radar platform scenarios, as well as moving targets across many domains.
Consider for example a scenario in which you need to upgrade an existing radar system to increase the maximum unambiguous range, detect targets with rapidly varying radar cross sections (RCS), and avoid interference with newly deployed 5G networks. Let’s say that the existing radar system uses a pulsed waveform, with relatively low transmission power and high pulse repetition frequency (PRF). It is logical that increasing the pulse interval (therefore, reducing PRF) will help to meet the increased maximum range requirement. Also, one way to detect targets with fluctuating RCS would be to boost the signal- to-noise ratio (SNR) by transmitting at higher power. One of these changes likely is trivial (a software parameter update to reduce the waveform’s PRF) but increasing transmission power may require significant and expensive hardware updates. Experimenting within a simulated environment helps you evaluate this design space— either increasing confidence or sparking a pivot to explore alternatives—before implementing such costly changes. For example, an alternative approach might replace the basic pulsed waveform with a linear FM waveform to use lower peak transmit power. For interference avoidance, you’d need to develop new algorithms that sense the RF spectrum, so that the radar would behave in a cognitive or adaptive manner, shifting its operating frequency to find the least-congested spectral areas.
To validate whether this approach works for you, you can simulate the radar model, its surrounding environment, targets, and other EM signals within MATLAB. To see whether the radar will detect targets with fluctuating RCS, create targets with a variety of Swerling models. You then can use MATLAB and Simulink to explore whether the radar system modifications are sufficient, demonstrate their impact on the rest of the system, and deploy to software defined radio (SDR) hardware for real-world testing and implementation.
Moving from Simulation to Testbed
Having simulated the approach and demonstrated initial results in software, the next stage is to build out a full testbed to validate performance in lab conditions. Traditionally, moving algorithmic IP from simulation into hardware has not been easy, since code must be rewritten for several reasons such as:
- Run optimally across multiple computing architectures, such as FPGAs and GPUs
- Account for data movement between RF/digital instrumentation and heterogeneous processors
- Operate within real-time latency constraints
- Consider real-world imperfections and parametrics
If software tool flows are not designed to scale through the development process, it can be time-consuming to rewrite code to run on hardware. Combining NI and MathWorks tools, the path to the testbed is much simpler and cost-effective.
At the most basic level, there are several ways to call MATLAB from LabVIEW, like MATLAB interfaces, which are documents in which you define calls to a MATLAB file in your G dataflow application, so that input data passes from the LabVIEW diagram to the MATLAB file for execution, then data is subsequently returned to the diagram.
Or the MATLAB Script Nodes, which are added to a LabVIEW block diagram and invoke the MATLAB software script server to execute scripts written in MATLAB language syntax.
In addition to linking NI and MathWorks software, there are more direct methods of targeting NI and Ettus Research Universal Software Radio Peripheral (USRP) SDR devices from MATLAB or Simulink. HDL Coder is a tool that generates portable, synthesizable VHDL and Verilog code from MATLAB functions and Simulink models. You can integrate the generated HDL code into LabVIEW FPGA designs to rapidly introduce into hardware testbeds with real-world inputs and outputs. With correct planning and execution, this is a more efficient way to reuse algorithmic IP from software simulations. You then can utilize IP migrated into LabVIEW FPGA within a testbed built upon NI COTS FPGA-based hardware such as FlexRIO, USRP devices, or Vector Signal Transceivers.
Building the Testbed
If initial simulation results are promising, the next task involves building out a full testbed within which to fully validate new techniques’, performance—either in the lab or on the range. There are a few ways that you can do this. One method
involves building a custom testbed from components or evaluation board, which has the advantage of being built to exact
specifications. However, custom designs usually require a larger team and specific skills, usually takes repetitive iteration and defocuses the team from the core task of algorithm development.
On the contrary, using COTS hardware can ease the burden of building a testbed by providing the RF I/O, data aggregation and processing, streaming architectures, and storage out of the box. For example, in the case of radar capability upgrades we discussed before, the software-defined nature of NI USRP and PXI RF hardware makes it straightforward to alter transmission parameters, with frequencies ranging up to Ka band and bandwidths of up to 1 GHz. With heterogeneous processing options, you can deploy IP related to the new waveform at various points within the hardware.
Final step: Moving from Testbed to Mission Hardware
The ultimate goal is to transition new technology ideas to the field. Once new techniques are validated, you can hand-off IP to other teams, departments, or organizations, either within a hardware-in-the- loop validation or for mission hardware deployment, reducing the cost of operational hardware development. Of course, if you need to rewrite the IP for deployment, this can be very time-consuming, but using tools such as LabVIEW FPGA IP Export Utility, a software add-on that allows to prototype algorithms within LabVIEW FPGA, on COTS hardware built upon Xilinx FPGAs. Then, you can export validated designs as VHDL source code or netlists for use on any Xilinx Vivado device of the same family.
Conclusion
Testing new ideas is the key to innovation, but doing it is neither cheap nor simple. However, with the right modeling, simulation, prototyping, and validation tools—plus the ability to migrate IP between those phases—we can significantly accelerate the process of proving out concepts.
Contact SAAB RDS to schedule a meeting with our experts and learn more about how to build a radar prototyping testbed using NI components.
MATLAB® and Simulink® are registered trademarks of The MathWorks, Inc
(Adapted with permission from Rapidly Transitioning from Radar Simulation to Testbed whitepaper published originally by NI)