aero_atc.mdl | Open this Model |
Air Traffic Control Demonstration
This interactive demonstration introduces you to the following concepts.
If you haven't already, open the Simulink/Stateflow model atc.mdl.
This model is a conceptual air traffic control (ATC) radar simulation based on the radar range equation. To make parameters easier to change and easier to determine their values, a GUI is supplied with this model. Radar and weather parameters may be changed from this GUI. While simulating, the effects of these parameters can be seen on the scope display which shows the actual aircraft range in yellow and the estimated aircraft range from the radar in magenta. Another output that can be viewed is the calculated signal to noise ratio (SNR) is compared to the ideal SNR. Ideal SNR is also specified from the GUI. The result is shown in the display block and will be either 1 (SNR>= ideal SNR) or 0 (SNR< ideal SNR).
Within this model, Simulink and Stateflow are used. The model is divided into three subsystems, radar, aircraft, and weather. Using subsystems is helpful in two ways: the model is organized and easier to understand and the work can be split between multiple engineers by subsystems. The a Stateflow machine labeled check SNR performs the logic comparing calculated SNR is compared to the ideal SNR and output data based on this comparison.
You can run the simulation to determine if the radar can pick up the aircraft by the output on the scope. Using the GUI, the radar and the weather parameters can be altered and will change the range where the aircraft can be "seen".
Radar systems are designed for a specific purpose and can very seldom be used for other applications effectively. Each new radar specification requires a "re-design". When designing a radar for an application, there are a number of parameters which shape the design. Some of these parameters are contained or derived logically from the customer specification. Others are selected arbitrarily using the design engineer's best judgement. This is the first approximate solution for the system design. From here, continual refinement of the design parameters takes place until an optimum design is reached. If any changes occur in the customer specification, it could cause a need to the whole design process over from the beginning.
We're interested in performing conceptual design for a ground-based air traffic control (ATC) radar. Let's take a look at a potential customer specification.
This is an example of a customer specification upon which a design process would be based. The customer, possibly the FAA, provides some basic requirements for the radar design leaving a number of parameter selections up to the design engineer.
It should be noted that some of the logically derived parameters are dependent on the assumption of the engineer and would need to be re-calculated each time the best-judgement parameters are optimized. This problem lends itself well to simulation. By using Simulink and Stateflow, the design engineer has the analysis capability of having time-varying design cases for his Monte Carlo test cases, i.e.: aircraft cross-sections and locations, weather cross-sections and locations.
Here's how the MathWorks products fit the job of conceptual radar design.
Using the customer specification and the radar range equations along with equations describing the physics of the system, a model is built in MATLAB, Simulink, and Stateflow. Using the model in batch mode (see sim command), those best-judgement parameters can be optimized for various conditions, weather,aircraft, etc in a Monte Carlo situation. The resultant is optimized radar parameter that can be used to build a block diagram model of the full radar system for further system analysis in Simulink with the Signal Processing blockset.