Radar Development Using Model-Based Engineering (MBE)

The Radar lifecycle comprises development, deployment, maintenance, and enhancement for future requirements; each must be considered upfront for developing an effective and efficient system and to achieve low cost of ownership. Highly complex Radars have been developed and deployed in complex environments with great performance and superb results since World War II. Since then; however, signal complexity has gone up by several orders of magnitude and new technological innovations have been introduced to realize ever increasing capabilities. These two aspects alone make the Radar development lifecycle very complex. In fact, without modern tools and processes it would be almost impossible to meet today’s delivery times and budget requirements. Because of this, several big organizations in the Unites States—Raytheon, Northrop Grumman, Lockheed Martin, Boeing, and others— came together to evolve new methods for Radar development. Model Based Engineering (MBE) is one such technique.

This application note briefly reviews the MBE technique. It also examines in detail how a set of simulation and modeling tools can work together to support MBE.

MBE Basics

As per the final report¹ of the MBE subcommittee of National Defense Industrial Association (NDIA), MBE is defined as:

“An approach to engineering that uses models as an integral part of the technical baseline that includes the requirements, analysis, design, implementation, and verification of a capability, and/or a product throughout the acquisition cycle.”

During development, therefore, all aspects of Radar acquisition have to be considered. MBE was originally derived because of several gaps in the practice and the process of developing complex systems. While the negatives may have necessitated MBE, the advantages have accelerated the focus and attention on it. MBE’s main advantages include the ability to:

• Quickly evaluate what’s not possible by exploring the entire project scope
• Derive all downstream activities
• Come up with quick proposals and Rough Order of Magnitude (ROM) estimates
• Rapidly evaluate the system performance for changing requirements
• Use the top-level model as the beacon for every subsystem development

With a main system model, it’s possible to derive all subsystems’ requirements and partition the design margins more meaningfully; a process generally known as top-down design. In the case of MBE, the main system model not only guides the subsystem design, but also helps define the system test, manufacturability and cost of production, among other things. This also leads to the ability to generate a quick proposal that is totally devoid of impossibilities and has a decent probability of success, as well as a ROM estimate of cost.

What are the impossibilities in the context of Radar? Certainly Radar cannot have infinite range and a pulse Radar requires a minimum range dictated by the finite speed-of-light. A pulsed Doppler Radar does not receive while transmitting. Hence, any signal that returns during transmission is not detected. This limits the detection range and this limitation comes from the physics of the system. Similarly, we can identify other limitations associated with such things as resolution and Doppler ambiguity. With a good main system model upfront, one can quickly examine these limitations early in the design phase.

Clearly the first, and perhaps the only, critical step in MBE is the development of the model. When developing the model we need to consider two aspects:

Width and versatility. How wide should the model be? The Radar model has to predict the performance under a variety of conditions, such as frequency range, complex environments, waveforms, wide variety of threats, and various interferences. It is generally desirable to build a model as wide and versatile as possible so that one can explore all of the above conditions.

Depth. How deep should the model be? This is an engineering and business decision. There are tools that allow both the fidelity and accuracy of the building block models to be increased enormously. Doing so; however, would increase the simulation time enormously and could be prohibitive and counterproductive from a business point of view. Hence, a good main system model is one that has enough accuracy, but that also simulates quickly. A good main system model also has fidelity that can be progressively increased on demand.

Let’s now go to the question of: What is being engineered? In the context of Radar, this can be several systems. We can view Radar as a system of systems as shown in Figure 1.

For the rest of the discussion we will consider only the electronic system, which includes the DSP and RF/MW subsystems in the transmitter and receiver, and the antenna. However, the methodology applies to all other systems each requiring a set of special tools. The MBE approach can be efficiently described by a V-diagram (Figure 2). The V-diagram is adopted by systems engineering and is available from various papers and text books. The specific one shown in Figure 2 is from the presentation at the INCOSE workshop

Figure 2 shows both a top-down and bottom-up flow. The definition and decomposition flow dictates the specification of the subsystems and their margins. It is common that the subsystems themselves are pretty complex and hence, they can also be described with individual V-diagrams as shown in Figure 3.

Figure 3 implies that the subsystems themselves can be complex and as such need to be treated as individual systems that should also follow the MBE approach. For example, the phased-array subsystem in an antenna is very complex and needs to be treated with MBE. Similarly, the Transmit-Receive (TR) module, designed as an integrated circuit, may have to be treated like a system and all the system concepts should be applied. Each of these subsystems must be designed using an appropriate tool. Let’s call the V-diagram one level below a child-V, and the one above child-V, a mother-V. An important requirement of MBE is that a mother-V be able to call, command and control child-V. It should be able to simulate child-V, keep it in standby mode, examine the output from child-V, and change the inputs to child-V to continue with the simulation on demand.

The tools used to design each of these systems—which by itself is a subsystem for the higher level system—are very likely different tools. For example, a system-level simulation is done using popular tools like SystemVue, MATLAB, and System Tool Kit (STK), while the subsystem (e.g., a TR module) is designed using a circuit simulator like Advanced Design System (ADS). Depending on the situation, some of the subsystems could be actual hardware connected to measuring instruments. It quickly becomes clear that for maximum effectiveness, however, all of these tools should be interoperable. In other words, a higher level system simulating tool should be able to call a subsystem simulating tool and put it in a command and control mode.

Once the above requirements are satisfied, one can build the main system model to simulate the end-to-end performance of the system. Let’s see how such a main system model can be created for a Radar using a set of tools. On close observation of the V-diagram in Figure 2, notice that the left side of the V pertains to top-down design, while the right pertains to integration and verification.

Verification is usually done with actual hardware, meaning that it is not performed until the actual hardware is available. With modern tools like SystemVue and ADS, a top-level model can be built that allows verification to be done in simulation. To highlight the difficulty, imagine having to co-simulate RF and DSP circuits. Very few tools in the industry support this kind of co-simulation. With an improved co-simulation capability though, both sides of the V-diagram (top-down design and bottom-up verification) can be done entirely in simulation. Final verification is then done with actual hardware. Performing the entire V in simulation eliminates major risk factors early in the development cycle.