Radar Sensor Development | Next Generation Aerospace Series

Welcome, everyone, to this presentation, where we are going to discuss about the new generation of radars mounted on airplane platforms. We will speak about the challenges that such projects have, how to deal with them, and the tools that MathWorks provide to fulfill your project goals.

Here is the agenda that we are going to follow today. The first chapter will be just an introduction to the presentation subject. The second will present the work frame that we are going to use for dealing with the challenges. The third one is about how to simulate radar and the environment itself that MathWorks tools provide to you.

The fourth through the sixth, we will dive a little bit deeper about the specific topics that we are considering important while developing radar systems. The final one will be a summary to see the main topics that we have covered in this presentation. Then let's start with the introduction, the first chapter, where we will investigate about the complexity of these projects and the main challenges that have to be managed and solved.

When a project begins to deal with a radar system onboard in an airplane, the first thing to point out is complexity. One person is no longer capable of controlling everything, all the aspects of the project. It's not only about the performance of the system.

It is also about the environment and the limitations, but, moreover, airplane has now become a platform which interacts with many different actors present in the environment. It can be drones, satellites, ships, or even the ground or control centers. Such complexity requires some tasks to be fulfilled in order to maximize the probability of success in the project.

What are these tasks? Well, the tasks is a working environment that must be created when the people with different backgrounds and experience must share their outcomes and explain their challenges. It is also visible to be able to check if the system design is feasible and fulfills all the requirements as soon as possible in the design phase or in the project lifecycle.

This leads as a first approximation to a simulation environment, which can be highly detailed or with some assumptions and where no hardware is needed but the most important that can be done in the early stages of the project. Simulations, analysis, tests, reports, mini notes-- all these produce data which has to be stored, managed, and labeled. This is a major task in this kind of project, and commonly it is underestimated.

Because of the amount of info also that these new platforms will just produce also coming from the sensors, they will have to manage a huge amount of data that has to be shared with the humans. And then the humans need help in order to be able to process that amount of info. Humans directly cannot cope with such big amount. This extra help needed will commonly come in the form of software, and this software should have to do some tasks that before were being done by humans, or, for example, we'll just clean unprepared data to be presented to the humans to allow them to process it easier and also to obtain faster a decision about what to do.

Then in this environment that we are explaining, with all the complexity, all the actors, that cannot be considered as just a mere group of platforms or actors. It's better to consider it as a system of systems in which all of them interact, share, and influence each other to fulfill the mission requirements. The final task that I would like also to point out is cybersecurity. Commonly, it's considered as a side task, but because the amount of info and the greater goal of this specific topic, cybersecurity can just be considered a pillar of the project from the very beginning.

It is essential to establish and maintain communication between the actors but also to assure data integrity. It is important to remark that the goal of this presentation is not to speak or to solve all this. We are going to synthesize the main challenges behind these tasks, and map them with the MathWorks tools, and checking how they can help you in fulfilling this work, the work to be done, and fulfill the requirements of the project.

We have spoken about the tasks and its importance. Let's try to extract the challenges that this kind of development has to deal with. The first one is collaboration. This is a complex project. Complexity means that a big and heterogeneous team has to interact within itself.

In order to avoid later problems of development, all systems has to speak the same language and interact to each other, like the people has to do. To fulfill this, early proof of concepts and interchangeable just as scenarios are of key importance. When projects are so huge, development requires long periods of times. Technology never sleeps, and new opportunities and improvements will arise during the project lifecycle. To be capable of adapting existing designs to new technologies and hardware, it is also key for the success of the project.

Speaking about the radar system itself, major challenge is to fulfill several different tasks at the same time. As we will see later, according to administrate resources between the different tasks is a must. Moreover, depending on the specific application, info collected from the radar has to be used together with many other sensors located at the same platform or different, looking for an improved outcome that will be obtained just barely adding all the info collected.

This challenge commonly requires specific hardware and software, and they will have to be used to fuse the data, which all the data that is available. Finally, the big challenge of being able to drive everything together-- not only everything together but also during the whole lifecycle of the product. At initial stages, the most important thing is the requirements on how to determine the system architecture. Afterwards, architecture drives component selection, and then the output of the system has to be processed by algorithms embedded in a specific hardware to finally obtain results and check if they fulfill the initial requirements.

But that's not all. Once achieve this, everything has to be tested, verified, and, even more important, to be flexible to be modified if any of the intermediate steps changes. To have such tools that allow this degree of control and interaction are not mandatory but key for the success of the project. We will see in this presentation how to perform this task using MathWorks tools.

Today, we are going to map those challenges that we have explained with the MathWorks tools developed for such end. In the first section, we will speak about model-based system engineering. Why? Because it is a formalized methodology which will allow us to keep everything under control, and we will see the tools that we have at our disposal.

In chapter two, we will see how to create scenarios where it is feasible to test and validate technical designs, which are the initial project stages, reduce cost, and increase access possibilities. Once we have a design test and validated and fulfill all our different tasks and requirements, we must decide and optimize when and what to do not only using info collected from the radar itself but from many other systems. It has to be pointed out-- or it has already been pointed out-- that these long projects must be ready and flexible enough to adopt emerging technologies. Currently, in the radar field, there is one-- artificial intelligence. There is a growing interest in using it for radar applications, and we will see the specific workflow that MathWorks provides to be able to use it in the development of radar embarked in an airplane.

Finally, and to close the development cycle, the algorithms used for signal and data processing must be deployed in hardware. We will explore how to do that using the MathWorks tools. So let's begin.

First, what is model-based system engineering? Model-based system engineering is a formalized methodology that is used to support the requirements, design, analysis, verification, and validation associated with the development of a complex system. In a nutshell, this methodology allows us to keep track of the whole development process.

We'll start with the needs from our stakeholders from which we derive the requirements, and, finally, will end up in the functional architecture and the system model. For the architecture, MathWorks provide a System Composer tool. In summary, it allows us to create the blocks and the interfaces which form the system.

Later, MathWorks provides Simulink, where using behavioral blocks, you can just scope, or can just make, or can just produce the different functions of the previous step. And even if there is no block matching the specific required function, user can create model functions and insert them directly in the model. As an improvement, System Composer creates a bridge between the functional architecture and the Simulink model or models, solving the known gap between the functional description and the actual design of them.

One key aspect is also how to link these diagrams and models with the requirements. This is done by the Requirements Toolbox, which produces and maintains the relationship between the requirements and the functional architecture. Finally, to close the loop, the test verification and validation tool. This will links the requirements, the functional architecture, together with the tests to be simulated to check the fulfillment. Important characteristic is that this process can be done automatically together with the outcome, which can be a customizable report.

In the end, MathWorks tools create digital a thread which tie up everything from the beginning till the end, from the requirements to the test and validation but also backwards, allowing to easily manage whatever change that could happen and immediately address the impact of such changes in architecture, design, or tests. What are the tools that we have seen so far for model-based system engineering? We have seen the system composure, which allows us to create functional architecture and also to define interfaces and links with the system actual design, then, similarly, to be able to create a Simulink and to simulate the actual system design.

The Requirements Toolbox linking the functional architecture from the System Composer with the simulation environment, which is Simulink, will all solve the requirements, and, finally, with the test verification and validation tools. Now in this chapter, we can check what are the challenges addressed, and these are easiness to adopt changes, creation of an environment where collaboration is simple and also where complex designs can be handled, covering the full design cycle. Now we jump to the second section, where we are going to go into the details about how MathWorks tools allow the users to model radars and together with user-specified scenarios to obtain valid data to test or train signal and data processing algorithms.

A typical radar system consists of four blocks shown here-- the antenna layer of the system, signal processing, data processing, and the resource manager and control. This subsistence make up the radar system, and there are many detailed aspects that need to be considered-- things like the radar operating parameters, hardware gains and losses, and, in addition, to the processing and scanning gains and losses. But equally important are the target and environmental parameters-- variables like surface clutter, atmospheric conditions, and those very conditions at the deployment site need to be considered when selecting your system-level design parameters.

The goal is to create an environment with a radar sensor embedded in it, obtaining some open data, which has to be valid for signal and data processing. MathWorks provide a workflow with four points to create such a scenario. The first one is about creation of the actors which lie inside the environment. The second one is about the definition of the movement of such platforms or actors.

Third one is about the sensors. there are several types of sensors that you can just simulate, like cameras, inertial navigation systems, infrared cameras, radars, passive and active, but here we are going to be focused in active radars. The final one-- to play everything and instruct the info collected from the sensors. As we will see, there are two main ways of obtaining it, but it's important to point out that at this point is where statistical analysis can be done through Monte Carlo. It is feasible to perturb the simulation conditions to test robustness of the systems deployed.

If we are going to be focused about active radars, the way the different actors or platforms can be defined to interact to interact with the sensors is through the radar cross section. But take into account that other sensors-- user can define its way of interacting like, for example, the equivalent for infrared sensors, which are the infrared signature. In order to define the LCS, there are four ways to do that.

First one is to assume the platform as a point target and therefore define the radar cross section, in azimuth, and elevation. The second one is to consider the platform as a multi-scatterer but rigid body. There is no relative movement between different parts of the target. Its RCS can be expressed as an analytical result, which is only feasible for very simple shapes. But also it can be computed as the superposition of basic shapes.

The third way of simulating the platform is like a multi-scatterer but with the other possibility to define relative movements between the different parts. This feature is specifically interesting if you would like to cope with micro-Doppler analysis, which can just be used to identify or discriminate between different targets. The fourth one, which is the most accurate but also more complicated from computational point of view, is to calculate the radar cross section through electromagnetic simulation, which can be performed importing any 3D shape inside the Antenna Toolbox.

About the second point of the workflow, which is how to model trajectories, there are two main ways. The first way is defining kinematic properties of the platform, like accelerations, angular movements, together with an initial position. The second one is by defining different positions where the platform is going to be located together with the corresponding time. Finally, to complete the trajectory definition, the frame of reference-- it has to also be specified. There are different ones, like, for example, georeferenced.

For modeling the radar sensor, MathWorks provide tools to obtain two main different levels of abstraction-- waveform level and measurable level. The first one has the highest complexity and gives us output raw IQ signals. As an example, for adaptive radar, the output will be the voltage variation in time that the radar receiver would produce if it's present in such environments, while the second one, the measurable level, will produce or can produce three different sub-levels depending on the output that the user requires.

It can be pure detections. One single target can produce many clusters if user wants to only one detection per target or trucks when the output is the trajectory of each of the actors or platforms. In the measurement level, user has three different sub-levels as we have set for defining the behavior of such sensors. But it is limited at this level to define high-level characteristics like resolutions, biases, and limits.

In the other hand, when using the physics-based approximation or IQ samples, there is much more freedom when defining its behavior. It can be specified the type of waveform, the kind of antenna, polarization, current frequency, transmitted power, noise figures, and much more. To make it even clearer the difference between both levels of abstraction, I would like to show you one example, although it is for automotive purposes. So it's easily the difference between the output on the left part, where a radar is located in the front bumper of a car and produces the detections of another car in front changing lanes.

But also at the same time there are road barriers located on the right side, which produces echoes and even some ghost targets produced by multi-path. The key point is that the output are detections are the black dots. On the right side, with the waveform level, we have for the same situation the result is the background color map. Obviously, this result can be processed later to obtain the orange block detections and also the white dots, but in this case the abstractional level is much higher.

Finally, it is also important to mention that in the simulation environment it's feasible to change between both levels, depending on which outcome is needed. Finally, when we have just created the platforms, we have defined the trajectories, and we have located the sensors and specified the performance, what is left is just to play the scenario and obtain the results. It is worth mentioning that the scenarios can have multiple platforms, trajectories, and sensors all together.

In this example that we can just see in the video on this line, there are three main platforms with one radar each. The orange is for volumetric search and is mechanically rotating. The blue one is for surface surveillance, and it's also mechanically rotating, while the yellow one is a narrow-bezel radar for obtaining high-resolution data from the targets, and it is electronically still.

In summary, in this chapter, we have shown the workflow to model platforms, targets, and trajectories, how it's also possible to obtain different levels of abstraction and complexity out of the radar sensors and sensor areas, and, finally, how adding up all together. In this way, very complex a scenario can be simulated, comprising multiple targets, platforms, and sensors all at the same time.

The scenario creation is a possibility to improve collaboration among teams, especially useful when different sensors coming from different departments or locations must work together. Sharing these test scenarios is a key factor to align capabilities and enhance the fusion of the data. If a new sensor also is added to the platform, it can be placed in the simulation and obtain the results. Therefore, integration of new technologies or requirements is pretty straightforward.

Then we will jump now to the next chapter to the next point, which is to speak about multifunction and cognitive radars. In the previous chapter, we saw that scenario example where different radars have different applications-- volumetric search, surface surveillance, narrow pencil search. Nowadays, some-- if not all of these-- are discovered by only one single radar system. Obviously, as mentioned before, such system increases its complexity when the number of different functions to perform grows.

But there is one basic capability that has to fulfill-- flexibility. Such system must be, as it is called, a cognitive radar. It must be able to react to the environment and change its properties to adapt its performance depending on the environment or to which function must be fulfilled at each time. In this way, system has to be able to change some of its parameters like, for example, PRF, down-wave current frequency, and the simulation environment has to be able to operate in closed-loop conditions.

MathWorks provides the tools to be able to produce or to implement the feedback between the receiver and the transmitter and to mimic this kind of behavior. But this kind of capability carries out a lot of necessity. Optimization. If different functions has to be made at certain point, a decision about what and when to do has to be made. These tasks performed by the radar management is a key factor of the success of the system to conveniently fulfill all the functions.

Therefore, the final success of the design. Available in the online documentation, there are some examples of how to model cognitive radars which react to changing conditions and vary its characteristics accordingly. You can see some of them in this slide.

There are examples about frequency agility when interference or performance degradation is detected or period variation where a moving target is detected, increasing the maximum unambiguous velocity. But all of them has the same characteristic in common-- have feedback path between receiver outcome and the transmitter. This video in this slide shows how to use the radar resource management to efficiently track multiple maneuvering targets. There are two main ways that it can be done so.

It can be done by active tracking, where all the tracks are treated in the same way, but also there is adaptive trucking, which first you have to detect when a target is changing its trajectory, and, secondly, for the radar to revisit these targets more frequently that non-maneuvering ones, assigning the full priorities. In the video, it is solely an example of adaptive tracking where the interacting multiple model filter estimates when the target is maneuvering. This estimation optimized revisit time. This is clearly visible because all targets at certain moments has an increased time of occupancy of the radar, the blue columns on the bottom, and those types are specifically when the targets are just maneuvering.

As a summary, in this chapter, we have seen that it's feasible to model multifunction radars because closed loops are allowed, and therefore sensor parameters can change accordingly to external or internal control signals. One such systems are feasible optimization resources. Algorithms can be implemented in order to maximize the outcome of the multifunction radar. All of these can be embedded in the previously explained environments, where everything can be tested and validated.

The challenges that are covered in this chapter are the multifunction radars, which is obvious, but also the easiness of integration of new technologies. If there is a new algorithm for optimization of resources, it can be added to the simulation pretty straightforward. Now, the next step, the next topic, is when these very long projects are just done, it's very desirable the capability to adopt new emerging technologies or techniques.

Currently, there is one big trend in radar field, which is the usage of artificial intelligence for radar signal processing. Inside artificial intelligence, there are machine learning and deep learning. We are going to be focused today on this latter because it has a major interest in radar applications.

Deep learning is a subset of machine learning that performs automatic feature extraction. MathWorks has developed a workflow to overcome the key challenges while applying deep learning to radar. It is clear that you won't get a good model without good data to train it, and that's even more true for silent and time series data, like commonly we are all deal in radar systems.

Some work may be needed in these initial steps of the workflow. To train a deep neural network, a large quality data set is required. Not only that, but supervisory approach is required also labeled data sets. Labeling for a repetitive and time-consuming task is an essential part of the workload. Radar and wireless specific expertise tools play a key role when preparing and preprocessing data to train networks, especially since you won't feel quite as much published research in these application areas as you can find for other ones, like the ones based in computer vision.

Our tools helps you to pre-process, transform, and enhance the feature structure of the data, reducing therefore the time needed for training. While the training data is generated, finally the predictive model can be generated with MathWorks tools. They can be created from scratch or from imported models trained with the sets of data already prepared, and, if needed, with a specific acceleration of hardware, and finally to allow deeper parameters to be analyzed and tuned.

Once you have your model ready and optimized, last step is to deploy it. It is often a challenge in itself to write C, C++, or CUDA code for targeting embedded platforms or to deploy it to the cloud. But it will be seen in the last chapter of today's presentation how MathWorks tools can help you in developing this task. Also, again, it is feasible in this workflow to go forward and backwards, which is also a nice asset.

It is important to mention that for creation and training of the predictive models, MathWorks has created the Deep Network Designer app to build, visualize, and edit deep learning networks and the Experiment Manager app to manage and analyze multiple deep learning experiments, comparing results and code. Also, it's worth mentioning that because of this topic is clearly under development, there are many resources on formats. Our tools allow to use and operate with most common ones, like supporting Open Neural Network Exchange, sharing models with Python, TensorFlow, Caffe2, and other frameworks.

As a summary of this chapter, we have seen that there is an end-to-end workflow to prepare data sets, cleaning, labeling, transforming, and optimizing feature structure. Also, afterwards users can train the predictive models imported from other parties or even create new ones from scratch. Our tools allow to interface and operate with many other frameworks.

The challenges addressed in this chapter would be integration of new technologies because AI is currently looming but also because user can create its own predictive models and collaboration. Tools allow to operate and share many currently known frameworks, so it's easy to reuse or to share with teams using equivalent tools or even other frameworks. Last topic to discuss today is the deployment-- how to carry the algorithms developed previously and tested to specific hardware.

We have covered in more or less detail all the blocks presenting the initial radar diagram, which was shown at the very beginning of today's presentation. But now we are jumping to another phase of the development cycle, the deployment. In the deployment in previous sections of today's presentation, we have seen how to perform cycle processing data and data processing regarding radar systems. Now the focus is on deploying these algorithms.

MathWorks tools provides not only support for deployment but also for mixed structure between hardware and software, where the cycle and data processing can include deep learning or Simulink models, Stateflow algorithms, or even MATLAB functions and can be deployed totally or partially to CPUs, GPUs, or FPGAs. Even taking advantage of the new developments, algorithms can be deployed in a system of chips, for example, using MathWorks SoC Blockset, taking advantage of having on the same die the hard processor core and the programmable logic.

But MathWorks tools do not take advantage only of the latest technology improvements. Go also one step forward, allowing the analysis of the so-called performance together with the hardware resources utilization, like memory latency, bandwidth, or data transfer. This way, optimization of resources is feasible and easier to achieve.

As an example, I would like us to point out that Airbus Defense and Space, for instance, has been heavily using our tools for several projects both in hardware and software-oriented. And as they presented during the MATLAB Expo a couple of years ago, they have used our tools in some of their high-intensity components used for the A330, for the A400M, or the C295. Also, I would like just to mention that there is a video series on the MathWorks web page, which shows how to build, simulate, and deploy a pulsed Doppler radar system in Simulink using SoC Blockset. And targeted to be used on the Xilinx Zynq UltraScale RFSoC Evaluation Kit.

Using this example, you can detect and estimate the rates of velocity of moving targets and exploit the advantage of the system on chips. Why is that? Because the range Doppler processing is partitioned between the FPGA programmable logic, where the range happens, and the Doppler processing, which is held in the CPU. The FPGA also implements a radar target emulator to evaluate the performance of the radar.

In the result, it can be seen-- let's make a zoom. It can be seen on the left the power level for each range of velocity beam, while on the right the detection map shows the result of 2D course and false alarm rate detection together with a clustering algorithm, although it's important to remark that this detection processing is done on the host machine in MATLAB.

As a summary of this last chapter, it has been shown MathWorks capabilities of cycle and data processing algorithms deployments. Also, that profile and optimizing the hardware resources is feasible, and all those functions can be applied for last trends like this system on chips. About the project challenges covered, well, indeed all are covered because we are covering the last design step of the full radar design lifecycle. It is easy and straightforward to deploy new algorithms if developed.

Workflows and code can be shared, and the deployment can cover all the functions that the new radar system can just deal with. At this point, therefore, we are at the end of our presentation. The only thing that I would like to point out right now are the key takeaways-- what I want you to remember from this presentation. The first thing to remember is that MATLAB provides an easy and complete workflow to support you on the development of an Embark airplane.

We have seen how using model-based systems engineering and MATLAB tools creates a digital thread that joins from the requirements, passing by the architecture to the simulation, and ending with the test validation and verification process. This link provides forward and backward traceability and ease exchange implementations. It has been shown how to generate data to test your cycle and data algorithms through the creation of environments, where platforms and targets can move through trajectories and where statistical or IQ data can be obtained as a result.

MATLAB tools also provides support to complex multifunction radars, allowing closed-loop simulations where radar parameters can change to optimize sensor output to new conditions on the scenario simulating. MATLAB is already worldwide known to be used for signal and algorithm development, but we have been working hard to allow and ease the pain of using new trends in this field, like artificial intelligence. MATLAB offers a complete workflow with a specific apps to generate prediction models which can be used for real applications.

Finally, it has been shown that all previous cycle and data algorithms can be deployed in real hardware. There are tools that can help you to generate adequate code but also to analyze and optimize the resources available. That is all. Please follow us on the next episode of this series of aerospace series and see also in our link previous ones if you have missed them.

Thank you very much for attending this presentation, and please do not hesitate to contact me on my email if you need more info about this presentation or in general about error simulation tools that MATLAB currently provide. I will be eager to discuss with you your current challenges and explain how our tools can help you in solving them. Thanks again, until the next time.