University Of Central Florida

EEL 6875 Fall 99

Dr. Zalewski

Air Traffic Control System

Software Requirements Specification

Team No 3:

Anna koufakou

raymond bahana

radhika

TIEN NGUYEN

ananth Rajamani

Table of Contents

1. Introduction 2

1.1. Purpose 2

1.2. Scope 2

1.3. Definitions, Acronyms, and Abbreviations 2

1.4. References 2

1.5. Overview 3

2. General Description 3

2.1. Product Perspective 3

2.2. System Architecture 4

2.3. User Characteristics 5

3. Specific Software Requirements 6

3.1. General Functionality and Load Requirements 6

3.2. Input Data Requirements 7

3.3. Output Data Requirements 7

3.4. Joint Input / Output Data Requirements 9

3.5. Detailed Functional Requirements 9

1.  Introduction

1.1.  Purpose

The purpose of air-traffic control is to assure safe separation between en-route aircraft and the safe and efficient handling of aircraft operations at airports.

Air traffic control is a closed loop activity in which pilots state the intent by filing flight plans. Controllers then plan traffic flow based on the total number of flight plans and, when possible, give clearance to pilots to fly according to their plans. When planning conflicts arise, controllers resolve them by clearing pilots to fly alternatives to their plans to avoid the conflicts. If unpredicted atmospheric conditions (e.g., wind speed or direction) or pilot actions cause deviations from conflict-free planned routings, controllers issue clearances for tactical maneuvers that solve any resultant problem, albeit not necessarily in a way that furthers the pilot's goal of reaching the planned destination at a certain time.

1.2.  Scope

The scope of this project will be to express the Air Traffic Control System Design in UML and implement with ObjecTime. The primary objective of the ATCS is to provide separation services for aircraft that are flying in controlled airspace, or where poor visibility prevents from maintaining visual separation. Aircraft are separated from one another and from terrain hazards.

.

1.3.  Definitions, Acronyms, and Abbreviations

Advisory: Advice and information provided to assist pilots in the safe conduct of flight and aircraft movement

Air Route Traffic Control Center: Synonym with En Route Traffic Control Center.

Air Traffic Control System: The element of the National Airspace System, which uses Pilot-provided flight plans strategic plans in the form of traffic management directives, and Real-time aircraft positional information to provide immediate and near-term control and separation of aircraft altitude.

1.4.  References

·  Air Traffic Control System SRS, Rev3

·  How the Air Traffic Control System Works - P. Garrison

·  Fundamentals of Air Traffic Control - M. S. Nolan

·  International Air Traffic Control: Management of the World’s Air Space- A. Field

1.5.  Overview

This document contains the software requirements specifications for the Air Traffic Control System design. Below are the following sections of this document:

·  General Description

o  Product Perspective

o  Architecture and Context Diagram

o  User Characteristics

·  Specific Software Requirements
o  General Functionality and Load Requirements
o  Input Data Requirements
o  Output Data Requirements
o  Joint Input / Output Data Requirements
o  Detailed Functional Requirements

2.  General Description

2.1.  Product Perspective

The ATCS will consist of five modules:

§  Data Acquisition Module. The data from the radar(s) will be the input, then this module will handle the signals and it will finally send the formatted data to the processing unit (every 5 sec’s).

§  Communication Module. This module will provide the communication link between different ATC’s. In particular, it will supply the controllers with all the necessary functions they need to receive or hand off control, exchange/update messages, flight strips, flight plans and/or track information.

§  Graphic User Interface Module [GUI]. This module will provide the interface for the user, so it will handle all required display and edit functions.

§  Mass Storage Module. This module shall deal with mass storage units, so it will include the following functions: loading and unloading tape, formatting tape and reading and writing single or bulk records to the Mass Storage.

§  Processing Module. The last module will provide all the necessary processing for the rest of the modules.

2.2.  System Architecture

From Fig 1 in Appendix A, the Context Diagram (Fig 2., also shown below) is derived, containing all essential elements of the ATCS.


As mentioned before there are 5 characteristics task types present in any Data Acquisition System and they are depicted in Fig. 3 from Appendix A, also shown here as fig. 2.

2.3.  User Characteristics

The user will be the air traffic controller.

3.  Specific Software Requirements

The requirements of ATCS include real-time aspects. The ATCS is a ''dynamic'' real-time system. Its loading will vary significantly over time, and has no upper bound. Loading scenarios can vary significantly; hence the average loading of the ATCS is not a highly useful metric for schedulability and other analyses. Although an upper bound could possibly be imposed artificially, this may not be a cost-effective solution, since pre-allocation of computing resources for such a worst case would lead to very poor resource utilization. A dynamic resource management policy is thus preferred.

3.1.  General Functionality and Load Requirements

3.1.1.  The ATCS shall be able to provide the following functions:

·  Track prediction.

·  Conflict probe and alert.

·  Resolution advisories.

·  Minimum safe altitude advisory warnings.

·  Time-based arrival and departure metering.

3.1.2.  Full functionality: Due to the criticality of ATCS's functions, the ATCS shall continue to provide full functionality, even though some hardware processors or networks may fail. The system shall be able to continue to work if there at least a number of processors working, not determined yet.

3.1.3.  The ATCS shall be able to handle varying loads.

3.1.4.  As a minimum, the ATCS shall be capable of handling 2600 flight plans and 700 active tracks in one center’s airspace region.

3.1.5.  The ATCS also shall be able to handle loads that exceed, by a factor of 2, the minimum specified in requirement 3.1.4. Loads exceeding the minimum should be signaled to the controller.

3.2.  Input Data Requirements

3.2.1.  The ATCS shall be able to acquire data and convert them into a format the controller can use. For example, when the ATCS obtains the data from the radar, it shall provide the controller with a visual representation of these data.

3.2.2.  The ATCS shall be able to handle data inputs from a maximum of 25 long range and short-range radars total.

3.2.3.  The ATCS shall be able to handle new radar track information arriving every 5 seconds.

3.2.4.  As multiple radars can return radar hits on the same aircraft, from these multiple hits primary and secondary radar must be chosen for each aircraft.

3.2.5.  The ATCS shall allow controller inputs to manipulate not only the display, but also the track and flight plan information.

3.2.6.  The controller shall be able to update and modify the flight strip.

3.2.7.  The ATCS shall be able to handle flight plans to be input from other Centers, flight service stations and bulk flight plan (tape) storage. If more than one controller access the same data, the system shall display a warning and ask for the next step to be taken, i.e. if any of the controllers want to abort or continue.

3.3.  Output Data Requirements

3.3.1.  The ATCS shall be able to handle up to 120 separate controller displays that will display the following information:

·  Center and sector boundaries

·  Arrival and departure routes

·  Track data and current aircraft positions

·  Flight plans including aircraft data (such as aircraft ID, reported altitude, assigned altitude, ground speed)

·  Metering, arrival, and departure lists

·  Weather information

·  Electronic flight strips

3.3.2.  The data from all the different radar in the ATCS shall be mosaiced so that all the radar is projected onto a single plane of reference.

3.3.3.  Any changes the controller makes in a flight strip shall be reflected on any other flight strips that may be displayed in the ATCS.

3.3.4.  The displays shall provide the ability to hand-off control of an aircraft from one sector to another sector.

3.3.5.  The ATCS shall provide a comprehensive data recording facility that allows performance analysis and data reduction. In particular, specific information shall be recorded about:

·  Any and all aircraft (that is, flight, track, display, and controller input)

·  Internal process functionality

·  Inter-process communication (sent or received data)

·  Inter-Center and inter­Tracon communications (sent or received data)

3.3.6. The ATCS issue complete holding instruction of any additional en route or terminal delay.

Include the following information:

· Direction of holding from the fix in terms of the eight cardinal compass point.

· Holding fix

· Radial, course, bearing, airway or route on which the aircraft its to hold

· Leg length in miles

· Direction of turn

· Time to expect further clearance and any pertinnt additional delay information.

3.4.  Joint Input / Output Data Requirements

3.4.1.  The ATCS shall be able to send data to and receive data from surrounding Centers, Tracons, and Towers.

3.4.2.  Weather information shall be accepted so that it can be used later for track prediction and for display to the controller.

3.4.3.  Center­to­Center and Center­to­Tracon communications shall be provided so that flight plan data and track data can be passed to other Centers or Tracons that may be receiving arrival flights or handing off departure flights.

3.4.4.  The communication link referred to in Requirement 3.4.3 can also provide the Tracons with the ability to talk to one another when there are flights that are going from Tracon to Tracon and are not entering Center's airspace.

3.4.5.  The communication link referred to in Requirement 3.4.3 can be also used to provide arrival and departure metering lists to adjacent Centers as well as any flight plan or track information any Center may want to request.

3.5.  Detailed Functional Requirements

3.5.1.  The conflict alert function shall provide an alert to the controller, if two or more aircraft are too close in proximity to each other. The normal separation distances over US airspace are:

·  5 nautical miles horizontally.

§  1,000 to 2,000 feet vertically.

Since the ATCS is a real time system, there shall be a limit for the alert transfer time, not yet determined.

3.5.2.  The track prediction function shall provide an estimate of a future track position of a given aircraft, with 5 percent accuracy.

3.5.3.  The future track predictions of all aircraft shall be examined to determine, if any of the aircraft currently under control in the Center's airspace will be in conflict with each other in the immediate future. We have not determined yet how long the future prediction will be (e.g. 5 minutes).

3.5.4.  The resolution advisory shall provide the controller with a possible solution to current or future conflict. We will use certain algorithms that will provide this function with basic rules that have to be followed in order to resolve a conflict.

3.5.5.  A minimum safe altitude warning function shall be provided to determine, if an aircraft is flying in close proximity to any type of natural or man-made obstructions in the airspace, as follows: If an aircraft is flying at an unsafe altitude, the controller shall be alerted, so that an action can be taken to avoid a possible collision.

3.5.6.  A time based metering function shall be provided to optimize the arrival and departure aircraft flows and create a plan that satisfies the arrival rate restrictions as well as increase fuel efficiency and reduce delays.

3.5.7.  The time based metering function shall make use of performance models of all aircraft that fly in the Center and Tracon regions and adapt to changes in the air traffic situation, controller-imposed constraints, and pilot and airline preferences.

3.5.8.  Metering lists shall be provided to the appropriate controllers, for them to be able to manipulate the lists according to their aircraft sequence requirements.

3.5.9.  Each new track information, once received, shall be correlated with the flight plans stored in the ATCS.

3.5.10.  The metering lists shall be updated, by default, at the time of flight departure and every 30 minutes ever after, until arrival.

10

Team 3: Software Requirements Specification Document for ATCS