# Radar Architecture: Part 1 – System components and requirements allocation

This example is the first part of a two-part series on using Simulink to design and test a radar system given a set of requirements. It starts by introducing a set of performance requirements that must be satisfied by the final design. A radar system architecture is then developed using Simulink System Composer. The example next demonstrates how to connect the radar requirements to the architecture and a corresponding design. Finally, a functioning model of a radar system is created by providing concrete implementations to the components of the architecture.

The second example in the series discusses testing of the developed model and verification of the requirements. It shows how to use Simulink Test to set up test suites and run Monte Carlo simulations to verify the linked requirements. Part 2 also explores a scenario when the stated requirements have been revised. It demonstrates how to trace the changes in the requirements to the corresponding components of the design and make modifications to the implementation and tests.

### Performance Requirements

Radar system design typically begins with a set of requirements. The real-world radar systems must satisfy dozens or hundreds of requirements. In this example we consider an X-band radar system that must satisfy the following two performance requirements:

• R1: The radar must detect a Swerling 1 Case target with a radar cross section (RCS) of 1 m${}^{2}$ at the range of 6000 m with a probability of detection of 0.9 and the probability of false alarm of 1e-6;

• R2: When returns are detected from two Swerling 1 Case targets separated in range by 70 m, with the same azimuth and elevation, the radar must resolve the two targets and generate two unique target reports 80 percent of the time.

### Virtual Test Bed

As the first step we set up a virtual test bed for a radar system that will be used to implement and test our design. We will demonstrate that this test bed is useful for tracing of the performance requirements to the individual components of the system, making iterative design changes, and testing and verifying the system’s performance. We start by creating a general top-level architecture model using Simulink System Composer. We then show in more detail an architecture of a radar sensor component and the part of the test bed that simulates the environment and the radar targets.

#### Top-Level Architecture

The architecture model specifies only the conceptual components of the system, their interfaces, and links between them. The components of the architecture model are not required to have a concrete implementation. As will be shown further in this example, Simulink System Composer allows for defining specific Simulink behavior for some of the components while leaving other components specified only at the architecture level. Such a modular-based design is convenient and flexible since the behavior of the individual components can be modified or completely changed without the need to make any changes to other parts of the system.

In addition to the `Radar Sensor` component that models the actual radar sensor, the test bed also includes:

• `Power Substation - S`upplies power to the radar sensor;

• `Control Center` - Passes control commands to the radar sensor through `Communications Link` and receives the radar data back;

• `Targets and Environment` - Models the radar waveform propagation through the environment and the interaction of the waveform with the targets. `Radar` Sensor is connected to `Target and Environment` through a set of ports marked `Tx`, `Rx`, and `TargetsPos`. `Tx` and `Rx` links are used to pass the radar waveform to and from `Targets and Environment`. `TargetsPos` is used to pass the information about the targets positions to `Radar Sensor` in order to simulate the transmitted and received waveform in the directions of the targets.

Open the top-level architecture.

`open_system('slexRadarArchitectureExample')`

Each component in an architecture model can be further decomposed into subcomponents. As a next step we define architecture for a radar sensor. When `Radar` Sensor is decomposed, `Power`, `Tx`, `Rx`, `CmdRx`, and `DataTx` ports defined at the top level become available as the external ports. Open the `Radar` Sensor component.

`open_system("slexRadarArchitectureExample/Radar Sensor");`

We define the following components to create an architecture model of a radar sensor:

• `Resource Scheduler` is responsible for allocating the system resources within a dwell. It receives control commands from `Control Center` through the external CmdRx port. To indicate the flow of the control signals in the radar sensor architecture, `Resource Scheduler` is also linked to every component inside `Radar`.

• `Waveform Generator` produces samples of the radar waveform.

• `Transmit Array` passes the transmitted waveform to `Target and Environment` through the external `Tx` port.

• `Receiver Array `receives back the reflected waveform from `Target and Environment` through the external `Rx` port.

• `Signal Processor` performs beamforming, matched filtering, and pulse integration and passes the detections to `Data Processor`.

• `Data Processor `creates radar reports or radar tracks and passes them back to `Control Center.`

Notice that this architecture model of a radar sensor is very general. It does not make any assumptions about the type of a transmitted waveform, the shape or size of the antenna array, or the implementation of the signal and the data processing chains. The same architecture can be used to implement a large variety of different radar sensors. Further in this example we will implement only a subset of the above listed components leaving out `Resource Scheduler` and `Data Processor`.

#### Targets and Environment

`Targets and Environment` can be decomposed into two subcomponents:

• `Targets` outputs targets positions and velocities.

• `Propagation `models the propagation of the plane wave emitted by `Transmit Array` through the environment, reflection from the radar targets, and propagation back to `Receive Array`.

Open `Targets and Environment` component.

`open_system("slexRadarArchitectureExample/Targets and Environment");`

#### Requirements Traceability

Simulink Requirements is a tool that provides a way to link the requirements to the components of the architecture responsible for implementing the corresponding functionality. When either the requirements or the model change, Simulink Requirements provides a convenient way to trace the changes to the corresponding tests and verify that the model's performance and the requirements are always in agreement.

Requirements Manager can be launched through the Apps tab. Requirements Editor then can be accessed by navigating to the Requirements tab and selecting Requirements Editor. To create a new set of requirements for the model, click on New Requirement Set. For this example, we create a requirements set and add R1 and R2 to it. Open these requirements in Requirements Editor.

`open('slreqRadarArchitectureExampleRequirements.slreqx')`

Requirements Editor lists the maximum range and the range resolution requirements. In the left panel it also shows the `Verified` and `Implemented` status for each requirement. At this moment, both requirements are not implemented and not verified. In order to change the `Implemented` status of a requirement it must be linked to a component of the architecture that implements the corresponding function. We link both requirements to `Waveform Generator` and `Signal Processor`. Notice that Requirements Manager at the bottom also shows the status of R1 and R2. After linking the requirements to the components, Requirements Manager shows that the status of R1 and R2 has changed to `Implemented`. When a requirement is selected in Requirements Manager, the components to which it is linked are highlighted with a purple frame. The linked components are also shown in the Links sections of the Details tab on the right.

Another convenient way to visualize the links between the requirements and the components of the architecture is the Traceability Matrix that can be generated by clicking on Traceability Matrix in the Requirements tab of Requirements Editor. It clearly shows which components are responsible for implementation of each requirement.

### Component Implementation

To simulate a radar system, we now need to provide a concrete behavior to the components of the architecture model. System Composer allows for specifying a Simulink behavior for some components while leaving the behavior of other components undefined. This provides a lot of flexibility to the design and simulation since we can build a functioning and testable model with some of the components modeled in detail while other components defined only at the abstract level. In this example we will only specify the concrete behavior for the components of the radar sensor needed to implement generation, transmission, reception, and processing of the radar signal. We will also provide a concrete implementation to `Targets and Environment.`

To specify the dimensions of signals within the model, the example assumes that the targets positions are specified by a three-row matrix `tgtpos`, the targets velocities are specified by a three-row matrix `tgtvel`, and the targets RCS are specified by a vector `tgtrcs`.

#### System Parameters

To provide the Simulink behavior to the components of the radar sensor we first need to identify a set of radar design parameters that could satisfy the stated requirements. A set of parameters for a radar system that would satisfy R1 and R2 can be quickly found by performing a radar range equation analysis in the Radar Designer app. The app computes a variety of radar performance metrics and visualizes the detection performance of the radar system as a function of range. We use the `Metrics and Requirements` table to set the objective values of the maximum range and the range resolution requirements to the desired values specified in R1 and R2. Then we adjust the system parameters until the stoplight chart indicates that the system’s performance satisfies the objective requirement. The resulting set of the radar design parameters is:

• radar frequency - 10 GHz;

• peak power - 6000 W;

• pulse duration - 0.4 $\mu s$;

• pulse bandwidth - 2.5 MHz;

• pulse repetition frequency – 20 kHz;

• number of transmitted pulses – 10;

• antenna gain – 26 dB;

• noise figure – 0 dB;

```radarDesigner('RadarDesigner_RectangularWaveform.mat'); ```

#### Waveform Generator

The analysis performed in the Radar Designer app assumes the time-bandwidth product to be equal to 1. This means that the transmitted waveform is an unmodulated rectangular pulse. We can use the Pulse Waveform Analyzer app to confirm that the derived waveform parameters will result in the desired performance and satisfy R1 and R2.

Start the Pulse Waveform Analyzer app with the waveform parameters defined in this example.

```pulseWaveformAnalyzer('PulseWaveformAnalyzer_RectangularWaveform.mat'); ```

The app shows that the range resolution and the unambiguous range agree well with our requirements.

To implement this behavior in the radar model, the` Waveform Generator` component needs to contain only a single Simulink block generating a rectangular waveform. The output of the `Rectangular Waveform` block is connected to the external `Waveform` port linked to the `Transmit Array` component. Since in this example we are not modeling the command signals, `Cmd` input is linked to a terminator.

We set the `Output signal format` property of the block to `Pulses`, which means that every pulse repetition interval (PRI) of `1/prf` seconds, the block will produce a column vector of `fs/prf` complex waveform samples.

#### Transmit Array

The Transmit Array component comprises the following Simulink blocks:

• `Transmitter -` transmits the waveform generated by `Waveform Generator` with the specified peak power and transmit gain.

• `Range Angle Calculator` - computes the directions towards the targets assuming the radar is placed on static platform located at the origin. The target directions are used as `Ang` input to `Narrowband Tx Array.`

• `Narrowband Tx Array - `models an antenna array for transmitting narrowband signals. It outputs copies of the transmitted waveform radiated in the directions of the targets.

The radar range equation analysis identified that the transmit gain should be 26 dB. We set the `Gain` property of the `Transmitter` block to 20 dB and use an antenna array to get an additional gain of 6 dB. A phased array antenna with the desired properties can be designed using the Sensor Array Analyzer app. In this example we use a 4-element uniform linear array that has array gain of approximately 6 dB.

Open the array model in the Sensor Array Analyzer app.

```sensorArrayAnalyzer('SensorArrayAnalyzer_ULA.mat'); ```

Simulink System Composer requires explicit specification of the dimensions, sample time, and complexity of the input signals. We set the dimensions of the `Waveform` input to `[fs/prf 1]`, the sample time to `1/prf`, and the complexity to `'complex'`. The dimensions of `TargetsPos` input are set to `size(tgtpos)`, leaving the default setting for the corresponding sample time and complexity.

• `Narrowband Rx Array -` models the receive antenna array. It is configured using the same properties as the corresponding block in the `Transmit Array `component. At each array element the block combines the signals received from every target adding appropriate phase shifts given the targets directions computed by `Range Angle Calculator`. The output of the Narrowband Rx Array block is a `[fs/prf num_array_elements]` matrix.

• `Receiver Preamp` - adds gain of 20 dB to the received signal.

The `Rx` input is a matrix of received waveform samples with columns corresponding to `size(tgtpos,2)` targets. The dimensions of `Rx` must be set to [fs/prf `size(tgtpos,2)`], the sample time to `1/prf`, and the complexity to `'complex'`.

#### Signal Processor

`Signal Processor` implements a simple signal processing chain that consists of:

• `Phase Shift Beamformer` - combines the received signals at each array element. In this example the beamforming direction is set to the broadside.

• `Matched Filter` - performs matched filtering to improve SNR. The coefficients of the matched filter are set to match the transmitted waveform.

• `Time Varying Gain - `compensates for the free space propagation loss.

• `Noncoherent Integrator -` integrates the magnitudes of the 10 received pulses to further improve SNR.

The dimensions of the `Signal` input must be configured to `[fs/prf num_array_elements]`, the sample time to `1/prf`, and the complexity must be set to `'complex'`

#### Targets and Environment

The `Targets` component is implemented using a single `Platform` block.

The `Propagation` component consists of :

• `Free Space Channel` - models the two-way propagation path of the radar waveform. The origin position and velocity inputs of the `Free Space Channe`l block are set to zero to indicate that the radar is located at the origin and that it is not moving. The destination position and velocity inputs are connected to the targets positions and velocities through `TargetsPos` and `TargetVel` ports.

• `Radar Target` - models the RCS and target fluctuation effects. Since in this example we are considering slow fluctuating Swerling 1 Case targets, the `Update` input is set to false. We also set the simulation stop time to `10/prf` indicating that a single simulation run constitutes a single coherent processing interval (CPI).

The dimensions of `Tx` input must be set to` [fs/prf size(tgtpos,2)]`, the sample time to `1/prf`, and complexity to `'complex'`.

### Simulation Output

Specifying Simulink behavior for the above blocks is enough to obtain a model of a radar system that can produce radar detections. Prior to proceeding with testing the model and verifying the specific performance requirements, we want to run the simulation and check whether it generates the results as expected. Consider three targets with the following parameters:

```% Target positions tgtpos = [[2024.66;0;0],[3518.63;0;0],[3845.04;0;0]]; % Target velocities tgtvel = [[0;0;0],[0;0;0],[0;0;0]]; % Target RCS tgtrcs = [1.0 1.0 1.0];```

Adding the Simulation Data Inspector to log the output of the `Signal Processer` component and running a simulation, results in the range profile shown below. As expected, we get three distinct peeks corresponding to the three targets in the simulation.

```% Set the model parameters helperslexRadarArchitectureParameters; % Run the simulation simOut = sim('slexRadarArchitectureExample'); data = simOut.logsout{1}.Values.Data; % Plot results figure; plot(range_gates, data(numel(range_gates)+1:end)); xlabel('Range (m)'); ylabel('Power (W)'); title('Signal Processor Output'); grid on;```

### Summary

This example is the first part of a two-part series on how to design and verify a radar system in Simulink starting from a list of performance requirements. It shows how to build a radar system architecture using Simulink System Composer which can be used as a virtual test bed for designing and testing radar system. Part 1 also demonstrates how to link the performance requirements to the components of the architecture and how to implement the behavior of the components using Simulink to obtain a functioning and testable model.

In Part 2 of this example we show how to set up test suites to test the created radar design and how to verify that the stated performance requirements are satisfied.