SOFTWARE REQUIREMENTS SPECIFICATION

FOR

AUTOMATED AIR TRAFFIC CONTROL

VERSION <1.1>

PREPARED BY
GROUP MEMBERS:
MUSTAFA ALAM MUSLIM JAFERRY M. KHALIL-ULLAH YAHYA JAVED 2009-NUST-BE-BICSE-173 2009-NUST-BE-BICSE-179 2009-NUST-BE-BICSE-168 2009-NUST-BE-BICSE-184
09BICSEMALAM@SEECS.EDU.PK 09BICSEMJAFEERY @SEECS.EDU.PK 09BICSEKULLAH@SEECS.EDU.PK 09BICSEYJAVEED@SEECS.EDU.PK

INSTRUCTOR: COURSE: TEACHING ASSISTANT: DATE:

DR. AWAIS SHIBLI SOFTWARE ENGINEERING MS. RAHAT MASSOD, MS. FARIA MEHAK, MS. TAHIRA RASOOL 15TH MAY 2012

Software Requirements Specification for Automated Air Traffic Control System Page ii

Contents
CONTENTS ....................................................................................................................................................................... II SECTION 1: INTRODUCTION ........................................................................................................................................ 1 DOCUMENT PURPOSE ..................................................................................................................................................... 1 PRODUCT SCOPE ............................................................................................................................................................ 1 INTENDED AUDIENCE AND DOCUMENT OVERVIEW ......................................................................................................... 1 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ............................................................................................................. 1 REFERENCES ................................................................................................................................................................... 2 SECTION 2: OVERALL DESCRIPTION ....................................................................................................................... 3 2.1. PRODUCT PERSPECTIVE .......................................................................................................................................... 3 2.2. PRODUCT FUNCTIONALITY ....................................................................................................................................... 3 2.3. USERS AND CHARACTERISTICS ............................................................................................................................... 3 2.4. 2.5. 2.6. 2.7. OPERATING ENVIRONMENT ............................................................................................................................... 4 DESIGN AND IMPLEMENTATION CONSTRAINTS ................................................................................................. 4 USER DOCUMENTATION .................................................................................................................................... 5 ASSUMPTIONS AND DEPENDENCIES ................................................................................................................. 5

SECTION 3: SPECIFIC REQUIREMENTS ................................................................................................................... 6 3.1. EXTERNAL INTERFACE REQUIREMENTS .................................................................................................................. 6 3.2. FUNCTIONAL REQUIREMENTS ...................................................................................................................................... 9 3.3. BEHAVIOR REQUIREMENTS .................................................................................................................................... 10 3.3.1. USE CASE: PREDICT CONFLICT ............................................................................................................................. 10 3.3.2. USE CASE: RESOLVE CONFLICT ............................................................................................................................ 10 3.3.3. USE CASE: UPDATE WEATHER ............................................................................................................................. 11 3.3.4. USE CASE: RESOLVE BAD WEATHER CONFLICT ................................................................................................... 11 3.3.5. USE CASE: LANDING AIRCRAFT ............................................................................................................................ 12 3.3.6. AIRCRAFT TAKE-OFF ............................................................................................................................................. 12

Software Requirements Specification for Automated Air Traffic Control System Page iii 3.3.7. MAINTAIN SAFE AMPLITUDE ................................................................................................................................ 12 3.3.8. PROVIDE RUNWAY ASSIGNMENT ........................................................................................................................... 13 3.3.9. DOCKING THE AIRCRAFT ....................................................................................................................................... 13 3.3.10. ADD NEW FLIGHT ................................................................................................................................................ 13 3.3.11. DELETE FLIGHT ................................................................................................................................................... 14 3.3.12. UPDATE FLIGHT .................................................................................................................................................. 14 3.3.13. CALCULATE TOTT ............................................................................................................................................. 14 3.3.14. EDIT DEPARTURE LOG ........................................................................................................................................ 15 3.3.15. EDIT ARRIVAL LOG ............................................................................................................................................ 15 3.4. LOGICAL DATABASE REQUIREMENTS .......................................................................................................... 15 3.4.1. FLIGHT SCHEDULE: ............................................................................................................................................... 16 3.4.2. PARKING: .............................................................................................................................................................. 16 3.4.3. COMMUNICATIONS: .............................................................................................................................................. 16 3.4.4. RUNWAY RECORD: ................................................................................................................................................ 16 3.4.5. GENERATING REPORTS:......................................................................................................................................... 16 3.4.6. MANAGING MESSAGES: ......................................................................................................................................... 16 3.4.7. HANDLING WEATHER CHANGES: ........................................................................................................................... 16 3.5. ADMINISTRATIVE SOFTWARE REQUIREMENTS. ....................................................................................... 16 3.5.1. LOGIN: .................................................................................................................................................................. 16 3.5.2. ACCESS CONTROL/CHECK: .................................................................................................................................... 17 3.5.3. USER FRIENDLY: ................................................................................................................................................... 17 3.5.4. REAL TIME/SYNCHRONIZED: ................................................................................................................................. 17 3.5.5. COMPATIBILITY ISSUE:.......................................................................................................................................... 17 3.5.6. EDIT TASKS: .......................................................................................................................................................... 17 3.5.7. TASK LIST: ............................................................................................................................................................ 17 SECTION 4: OTHER NON-FUNCTIONAL REQUIREMENTS................................................................................. 18 4.1. PERFORMANCE REQUIREMENTS ............................................................................................................................... 18

Software Requirements Specification for Automated Air Traffic Control System Page iv 4.2. SAFETY AND SECURITY REQUIREMENTS .................................................................................................................. 18 4.3. SOFTWARE QUALITY ATTRIBUTES ........................................................................................................................... 18 SECTION 5: SYSTEM EVOLUTION ............................................................................................................................ 19 APPENDIX A GLOSSARY ......................................................................................................................................... 20 APPENDIX B ANALYSIS MODEL ............................................................................................................................ 21 CLASS DIAGRAM .......................................................................................................................................................... 21 USE CASE DIAGRAMS.................................................................................................................................................. 22 COLLABORATION DIAGRAM ................................................................................................................................... 24 ACTIVITY DIAGRAM ................................................................................................................................................... 25 DEPLOYMENT DIAGRAM ........................................................................................................................................... 28 BLOCK DIAGRAM .......................................................................................... ERROR! BOOKMARK NOT DEFINED.

Software Requirements Specification for Automated Air Traffic Control System Page 1

SECTION 1: INTRODUCTION
DOCUMENT PURPOSE
This document is intended to represent the software requirements specification of the Automated Air Traffic Control System. The scope of the document is to identify the requirements of the Automated Air Traffic Control System using UML diagrams and some interface designs. The document is the is the first version and additions are expected in further versions.

PRODUCT SCOPE
Automated Air Traffic Control System is aimed to provide software based automation to the operations of the Air Traffic Controller (ATC) for efficient and reliable services regarding the flow and control of the air traffic in the vicinity of the airports. The goal is to minimize the human participation in the operations of ATC so that the loss caused by human negligence can eliminated.

INTENDED AUDIENCE AND DOCUMENT OVERVIEW

This Document is intended for all those people who are involved with the air traffic control. The stakeholders of this Software include the following: Air Traffic controller (ATC) Pilot Arrival and Departure Manager System Administrator Software developers Project managers Software tester

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

Air Traffic Controller (ATC) Arrival Departure manager (ADM) System Coordination (SYSCO) Minimum Safe Altitude Warning (MSAW): Short Term Conflict Alert (STCA) Area Penetration Warning (APW)

Software Requirements Specification for Automated Air Traffic Control System Page 2 Controller Pilot Data Link Communications (CPDLC) User Request Evaluation Tool (URET)

REFERENCES
Sample SRS http://www.google.com.pk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CGYQFjAA&url=http%3 A%2F%2Fwww.jsu.edu%2Fmcis%2Fdocs%2FSRSSample.doc&ei=BJyyT8nVHujc4QSTttmPCQ&usg=A FQjCNFKFw_inOVTDfxPv4zn4kT_nkqIhQ http://www.google.com.pk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CGgQFjAB&url=http%3 A%2F%2Fwww.cse.msu.edu%2F~chengb%2FRE-491%2FPapers%2FSRSExamplewebapp.doc&ei=BJyyT8nVHujc4QSTttmPCQ&usg=AFQjCNFfJ46bf_7grmS-fT75fUkqkf5Zaw http://www.google.com.pk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CG4QFjAF&url=http%3 A%2F%2Fwww.slideshare.net%2FShikhaKumari3%2Fsamplesrs&ei=BJyyT8nVHujc4QSTttmPCQ&usg=AFQjCNGJKLmgVbrk4SMDhXzOaGYMt5pbZg http://www.gcreddy.net/2010/03/sample-srs-document.html http://www.slideshare.net/ShikhaKumari3/sample-srs CPDLC http://en.wikipedia.org/wiki/Controller_Pilot_Data_Link_Communications Air Traffic Control http://www.google.com.pk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CJkBEBYwAA&url=http %3A%2F%2Fen.wikipedia.org%2Fwiki%2FAir_traffic_control&ei=VJyyT6C4FuWH4gTmxKHmCQ&usg= AFQjCNEONOjpSAN-z2bccABj5KK9ZGMHfg

Software Requirements Specification for Automated Air Traffic Control System Page 3

SECTION 2: OVERALL DESCRIPTION

2.1. PRODUCT PERSPECTIVE
The main goal of this software development project is to develop a user-friendly mechanism that manages the air traffic flow around the airports to enhance safety and efficiency of the air traffic. The need for automation of the air traffic controller was sensed due to various catastrophes faced due to human negligence. The system should be stable so as to ensure smooth communication between the pilot and the control room operator. In case of emergencies there must be some emergency protocol in the system that would retain the communication between the pilot and the control room operator. A backup system should be present for this purpose. Cross communication between the crisis management team and the other departments is highly critical to facilitate quicker response and information exchange, minimizing property damage and loss of life. This is a new self-contained product which is to be developed for the Pakistani Civil Aviation in order to provide some level of automation to the Air Traffic Control.

2.2. PRODUCT FUNCTIONALITY

For our Automated Air Traffic Control system software we need to validate the user before any interaction with the software takes place. The users we are considering here include the air traffic controller, Arrival/Departure Admin. The log in process may be done whenever the related user tries to access the software. User needs to provide the log-in ID and a password for this process. The system should provide the ATC with necessary functions associated to his/her day to day operations. This includes separating aircrafts to prevent collisions, to organize and expedite the flow of traffic, and to provide information and other support for pilots when able.

2.3. USERS AND CHARACTERISTICS

We have identified most of the users of this system in the introduction of this document. The users that would use the system most frequently are: 1. The Air Traffic Controller The ATC is the most frequent user of this system. 2. The Arrival and departure manager Less frequent than the ATC. His output would be the input required by the ATC. Other users may include the flight administrator, the system administrator, system analyst, software tester etc.

Software Requirements Specification for Automated Air Traffic Control System Page 4

2.4. OPERATING ENVIRONMENT

The software would function in the air traffic control department and the functional wing of the PCAA where arrival and departure of the flights are managed. The hardware required for this software would be a number of servers which would manage the databases and the load of the users that are logged in at that time and the terminals associated to each air traffic controller. The server would have a UNIX-based operating system and the terminals would run on Linux 11.12. As our software is component based software several other programs are also required to run on the machine. The major sub-systems of the software include: 1. Air traffic control 2. Arrival Departure 3. Flight Administrator

2.5. DESIGN AND IMPLEMENTATION CONSTRAINTS

Design requirements and constraints respectively stand for non-functional requirements the final product should meet and restrictions the designer is faced with. The design requirements and constraints result from confronting and balancing the needs and vision of all stakeholders users, marketing department, product and project managers, developers They are summarized in the design brief, which forms the input for the design phase and the basis for subsequent test or evaluation phases. While the sources are varied, design constraints typically originate from one of three sources: Restriction of design options Conditions imposed on the development process Regulations and imposed standards

R ESTRICTION OF D ESIGN O PTIONS

Most requirements allow for more than one design option. Whenever possible, we want to leave that choice to the designers rather than specifying it in the requirements, for they will be in the best position to evaluate the technical and economic merits of each option. So, if we wont allow the designer to make choice, then design would be a constraint.

C ONDITIONS I MPOSED ON THE D EVELOPMENT P ROCESS

Our software is made up of different components. It also interacts with other hardware components to get the data to perform its functionality. So if any component is not working then software will not perform well and this problem will not be recovered from software and our results may be wrong.

R EGULATIONS AND I MPOSED S TANDARDS

Another important source of design constraints is the body of regulations and standards under which the project is being developed.

2.5.1.

H ANDLING D ESIGN C ONSTRAINTS

If we follow the steps mentioned below than we can handle these constraints.

Software Requirements Specification for Automated Air Traffic Control System Page 5 Distinguish them from the other requirements. For example, if we identified other software requirements with a tag, such as "SR," we might consider using "DC" for design constraints. We can include all design constraints in a special section of our requirements, or use a special attribute so they can be readily aggregated. That way, we can easily find them and review them when the factors that influenced them change. We need to identify the source of each design constraint. By doing so, you can use the reference later to question or revise the requirement. We may wish to supply a specific bibliographic reference in the case of regulatory standard references. That way, you can find the standard more easily when we need to refer to it later. Document the rationale for each design constraint. Write a sentence or two explaining why the design constraint was placed in the project. This will help remind we later of the motive for the design constraint.

2.6. USER DOCUMENTATION

The documentation to this software will be available on our official website. The documentation will involve every type of user guide. As it is our priority that the software should be designed in such a way that it should be easily use, so there will no need of any detailed documentation but still we will provide any type of guidance if needed. There are following supports that we will provide to user: Online documentation User manual Email support Software check service ( we will send our technical representative in case of any inconvenience) Workshop will be held for controllers after deployment of software There will be an official blog for this software to discuss problems

2.7. ASSUMPTIONS AND DEPENDENCIES

The software will run on computer machines. It is assumed that all the users have basic knowledge of computer. This will help them to easily understand the hierarchy of software. It is assumed that all the users have well knowledge of ATC field. They need to understand the different reading received from different of the whole ATC system. It is assumed that the different sensors which are installed at different places are working well and give accurate reading enough, which is necessary in ATC. It is assumed that the software is running on hardware of minimum specifications Pentium IV technology. Software is made automated. So, it is assumed that if there any emergency then the controller is able to operate it manually.

Software Requirements Specification for Automated Air Traffic Control System Page 6

SECTION 3: SPECIFIC REQUIREMENTS

3.1. EXTERNAL INTERFACE REQUIREMENTS
3.1.1. USER INTERFACES

Figure: Login screen for the user to enter the AATC system.

Software Requirements Specification for Automated Air Traffic Control System Page 7

Figure: The above figure shows three screenshots of warnings issued to the ATC

Software Requirements Specification for Automated Air Traffic Control System Page 8

Figure: Shows the main interface for the air traffic controller.

Figure: Shows instant messages being shared between the ATC and pilot.

Software Requirements Specification for Automated Air Traffic Control System Page 9

3.2. FUNCTIONAL REQUIREMENTS

The following represents a detailed list of functional requirements for the Automated Air Traffic Control System: All flights are in contact with our system. The System must follow the requirements set by CAA. The system gets regular updates from the Metrological department. The system locates the current position of the aircraft. A GUI is provided which gives the user a pictorial view of the aircrafts current position. A flight is only allowed to take off if the weather conditions are suitable. A flight is only allowed to land if the weather conditions are suitable. An emergency protocol should be executed in case of problem. Calculates a planned departure flow with the goal to maintain an optimal throughput at the runway, reduce queuing at holding point and distribute the information to various stakeholders at the airport Calculates a planned Arrival flow with the goal to maintain an optimal throughput at the runway, reduce arrival queuing and distribute the information to various stakeholders. Provides runway assignment and sequence number advisories to terminal controllers to improve the arrival rate at congested airports. System Coordination (SYSCO) to enable controller to negotiate the release of flights from one sector to another. Minimum Safe Altitude Warning (MSAW): a tool that alerts the controller if an aircraft appears to be flying too low to the ground or will impact terrain based on its current altitude and heading. Short Term Conflict Alert (STCA) that checks possible conflicting trajectories in a time horizon of about 2 or 3 minutes and alerts the controller prior to the loss of separation. The algorithms used may also provide in some systems a possible vectoring solution, that is, the manner in which to turn, descend, or climb the aircraft in order to avoid infringing the minimum safety distance or altitude clearance. Providing conflict advisories up to 30 minutes in advance and have a suite of assistance tools that assist in evaluating resolution options and pilot requests. Allows digital messages to be sent between controllers and pilots, avoiding the need to use radiotelephony. (CPDLC) Area Penetration Warning (APW) to inform a controller that a flight will penetrate a restricted area.

Software Requirements Specification for Automated Air Traffic Control System Page 10

3.3. BEHAVIOR REQUIREMENTS

USE CASE VIEW
In this section of the SRS document we have provided the reader with several user interactions with the system. The major Actors identified are as follows: 1. 2. 3. 4. Air Traffic Controller (ATC) Arrival and Departure Manager (ADM) Pilot System Administrator

3.3.1. USE CASE: PREDICT CONFLICT

Use Case: Predict Conflict Actors Air Traffic Controller, User Request Evaluation Tool Description The control room operator may check the URET system for potential conflicts. For this ATC may first select the check conflict->predict conflict. Then he/she is prompted for IDs of the concerned aircrafts. The ATC may select from the list of IDs in the database. The system computes the distance between the two aircrafts and issues an alarm signal on unsafe configuration of the airspace. Data Plane-IDs of two planes Stimulus User command issued by ATC Response Alert/Warning from the URET to the ATC for potential conflict between two planes Comments The ATC must have appropriate security permissions to access the URET.

3.3.2. USE CASE: RESOLVE CONFLICT

Use Case: Resolve Conflict Actors Air Traffic Controller, Pilot Description URET issues an alarm signal to the ATC for potential conflict. The system would give several options to the ATC for the resolution of the conflict from which some are listed here: altitude amendments horizontal route amendment speed changes The ATC will select one of the options to send one of the two pilots a message update and the other pilot would be informed of the situation. Data No data Stimulus User command issued by ATC i.e. selection of the above mentioned options. Response A message sent to one of the pilot to amend one of the above mentioned parameters. Comments The message to the pilot would be sent using a COTS Software i.e. AOL instant message.

Software Requirements Specification for Automated Air Traffic Control System Page 11

3.3.3. USE CASE: UPDATE WEATHER

Use Case: Update Weather Actors Air Traffic Controller, Metrological department Description The ATC in the control tower would send a query to the Met. Department to give an update of present weather conditions and the next 48 hour forecast of weather at the airport and local area. Data City-ID, Date/Time, User ID, password Stimulus User command issued by ATC Response The weather conditions of the current time and the forecast of the 24 hours would be updated at the ATCs system. Comments To access Meteorological department weather updates which are specifically catered for the air traffic control, we need authentication from the user. For this at the time of login the user must also login to the meteorological department website.

3.3.4. USE CASE: RESOLVE BAD WEATHER CONFLICT

Use Case: Resolve Bad Weather Conflict Actors Air Traffic Controller, Pilot Description If the ATC detects bad weather conditions in the airspace, he must inform the incoming air traffic about the weather condition to avoid any undesirable mishap. For this our software would have a feature that would help us to give a bad weather warning to all the approaching aircrafts to wait before the weather clears out. Based on the current position of the aircrafts and the radius of the bad weather airspace we would inform the aircraft to execute one of the following: Maneuver in the airspace having clear weather conditions until weather at destination airport is clear. Make a landing to a nearby airport where weather conditions are good enough. Data Current position of the aircraft, Radius of bad weather airspace Stimulus Weather warning Response A message signal would be received at Pilots end. After that he would execute the commands as instructed by the ATC. Comments We need to timely notify the aircraft about this condition at the airport and its resolution. Although weather conditions are available to the pilot but the job of the ATC is to coordinate with the pilot to make a safe landing.

Software Requirements Specification for Automated Air Traffic Control System Page 12

3.3.5. USE CASE: LANDING AIRCRAFT

Use Case: Landing aircraft Actors Air Traffic Controller, Pilot Description When an airplane is about to approach the airport, the pilot send a clear-toland query to the ATC. The ATC check whether some other airplane is landing on the same time. If yes the ATC send a NO message to the pilot. The airplane would then maneuver for about the 30mins until the runway is clear. If the ATC send a YES message, the airplane is allowed to land on the runway. Data No data Stimulus Pilots clear-to-land query message to the ATC. Response Response would be a YES/NO and time to maneuver message issued to the pilot from the ATC. Comments The timing of the approaching aircrafts must be set as such that no more than two planes arrive in the same time interval. The time interval may be kept according to the rules set by PCAA.

3.3.6. AIRCRAFT TAKE-OFF

Use Case: Aircraft take-off Actors Air Traffic Controller, Pilot Description When an airplane is about to take-off from the airport, the pilot send a clear-totakeoff query to the ATC. The ATC check whether some other airplane is takingoff on the same time. If yes the ATC send a NO message to the pilot. The airplane would then wait until the runway is clear. If the ATC send a YES message, the airplane is allowed to takeoff from the runway. Data No data Stimulus Pilots clear-to-takeoff query message to the ATC. Response Response would be a YES/NO and time to wait message issued to the pilot from the ATC. Comments The time between successive take-offs should be maintained as such that the two flight are maintained at a specific distance from each other to avoid conflicts. This is also set by the rules and regulations of the PCAA.

3.3.7. MAINTAIN SAFE AMPLITUDE

Use Case: Maintain Safe Amplitude Actors Air Traffic Controller, Minimum Safe Altitude Warning(MSAW) Description The Pilot would be provided with an interface in his cockpit that would show the minimum safe amplitude from ground. The cockpit would be equipped with a GPS database of the terrain to provide terrain warnings. If the height goes below the safe level the ATC would inform the pilot to set its height to a safe level. Data Aircrafts position and its height above the terrain. Stimulus User command issued by the ATC. Response Caution or Warning event. Comments MSAW is an automated warning system for ATC. It is a ground-based safety net intended to warn the controller about increased risk of controlled flight into

Software Requirements Specification for Automated Air Traffic Control System Page 13 terrain accidents by generating, in a timely manner, an alert of aircraft proximity to terrain or obstacles.

3.3.8. PROVIDE RUNWAY ASSIGNMENT

Use Case: Provide runway assignments Actors Air Traffic Controller, Pilot, Runway-Database Description The ATC would assign a sequence no. to an aircraft which is ready for departure with the help of the AATC software. The ATC would open the Departure interface of the software system. He would select assign runway option. The software would then prompt for necessary details related to the aircraft and automatically generate a sequence number. This sequence number would then be assigned to the concerned aircraft. Data ATC ID, Plane-ID, Date/Time Stimulus User command issued by the ATC. Response Sequence Number which would be assigned to the concerned aircraft and the pilot would be informed. Comments The runway assignments would take place as soon as the aircraft is fueled and filled with passengers.

3.3.9. DOCKING THE AIRCRAFT

Use Case: Docking the aircraft Actors Air Traffic Controller, Pilot Description Our software has provided us with and interface that shows reserved and free parking slots at the Docking terminal. Whenever the aircraft is landed on an airport, the next task the ATC should perform is to assign the Docking slot to the aircraft depending on the size of the aircraft. The ATC would look for available slots and assign the slot to the aircraft. Each slot has a fixed identification number associated with it which is well communicated to both the ATC and the pilot. Data Flight Number, Slot_no. Stimulus Pilot issues a user command to the system for parking Response The system would assign the parking slot to the aircraft that has landed and the docking time shall be provided beginning from the time an aircraft docks-in into the Aerobridge and when it leaves the Aerobridge. Comments The slots that are occupied by aircrafts should not appear in the list of available slots.

3.3.10. ADD NEW FLIGHT

Use Case: Add New Flight Actors Flight Admin, Flight Database Description In order to add a new flight in the flight database the AATC must provide a functionality to take necessary information related to the aircraft. And make a new object in the database. Data Flight Number, Flight operator, Plane type, Capacity Stimulus User command issued by the Flight Admin

Software Requirements Specification for Automated Air Traffic Control System Page 14 Response Comments A new object would be created in the database. In order to add a new flight in the database, authentication is necessary.

3.3.11. DELETE FLIGHT

Use Case: Delete Flight Actors Description Flight Admin, Flight Database In order to delete a flight in the flight database the user must search a flight with its flight number. On successful hit, the user can choose between update/delete. On choosing delete option the AATC system would delete the concerned flight from the database. Flight number(which is a unique identifier) User commands issued by the flight admin Deletion of the concerned flight from the database. In order to delete flight in the database, authentication is necessary.

Data Stimulus Response Comments

3.3.12. UPDATE FLIGHT

Use Case: Update Flight Actors Flight Admin, Flight Database Description In order to update a flight in the flight database the user must search a flight with its flight number. On successful hit, the user can choose between update/delete. On choosing update option the AATC system would update the concerned flight from the database. Data Flight number(which is a unique identifier) Stimulus User commands issued by the flight admin Response Deletion of the concerned flight from the database. Comments In order to update flight in the database, authentication is necessary.

3.3.13. CALCULATE TOTT

Use Case: Calculate Target Take Off Times (TTOT) Actors Arrival/Departure Manager Description The ADM would be creating a stable departure sequence so that different operators can plan their work more efficiently. By gathering necessary information related to the aircrafts at the airport and the weather conditions, the departure manager shall calculate the TOTT for each aircraft with the help of stochastic approximation algorithms. This would support the ATC in an airport to make new plan based on current situation and quickly distribute the information to the different operators and stakeholders at the airport. Data Number of aircrafts at the airport and their respective IDs, Destination information, time of departure related to each aircraft. Stimulus User commands issued by the Departure manager. Response TOTT for each aircraft. Comments The Departure manager would be a sub system of our overall AATC system

Software Requirements Specification for Automated Air Traffic Control System Page 15 whose purpose is to get the TOTT for each aircraft from related information available of each aircraft.

3.3.14. EDIT DEPARTURE LOG

Use Case: Edit Departure Log Actors Description Arrival/Departure Manager, Departure-Database. The ADM can add a new entry in the departure log, update it if there is any change in plans of the flight and delete it. The Departure manager has the authority to make changes in the departure log. Others can only view it. Flight number, Departure Date/time, Destination, Expected time of arrival User commands issued by the ADM. Updated departure log. The Departure managers responsibility is to maintain the Departure log for the facility of the ATC for smooth air traffic operations.

Data Stimulus Response Comments

3.3.15. EDIT ARRIVAL LOG

Use Case: Edit Arrival Log Actors Description Arrival/Departure Manager, Departure-Database. The ADM can add a new entry in the arrival log, update it if there is any change in plans of the flight and delete it. The ADM has the authority to make changes in the Arrival log. Flight number, Arrival Date/time, Expected time of arrival User commands issued by the ADM. Updated departure log. The ADM responsibility is to maintain the Arrival log for the facility of the ATC for smooth air traffic operations.

Data Stimulus Response Comments

3.4. LOGICAL DATABASE REQUIREMENTS

All the communications between aircraft and tower must be recorded and standardized and for this reason we need a database for our system. Here two databases will be used and will be maintained separately. They may interact with one another, but their usage and effect will be separate. One database will be OF AIRCRAFT that will be maintaining entities related to it for example its altitude at a specific time, the tower it connects to, communication of the aircraft i.e. by which tower it was connected to at a specific time and how many messages were interchanged between the two, it keeps a track of path plane followed and weather condition updates it received at different times. It will also keep recording fuel levels at different times during flight. The other database will be of ground and this is the database of our interest as it performs activities that are required in ATCS by managing and recording functions on the ground e.g.

Software Requirements Specification for Automated Air Traffic Control System Page 16

3.4.1. FLIGHT SCHEDULE:

Maintain flight schedule using the database. Must also manage list of all aircrafts that are expected to land and take of in near future separately.

3.4.2. PARKING:
Managing parking at airport using this system

3.4.3. COMMUNICATIONS:
Keeping record of all the communication done by the ground and also specify time and aircraft at and with which communication was performed.

3.4.4. RUNWAY RECORD:

Keep record of runway history that is it was provided to which plane at a certain time, it will also keep record of officers on duty for security purpose that will enable it to interact with officer whose duty is at specific time and thus ensuring security.

3.4.5. GENERATING REPORTS :

It will also enable privileged stake holders such as chief manager and director to print a report of performed and queued operations on ground, category wise.

3.4.6. MANAGING MESSAGES :

It will also be generating messages using different systems to airports for which a flight is departed upon departure of a flight.

3.4.7. HANDLING WEATHER CHANGES:

If a certain and unexpected change occurs in climate then it will be performing all operations then it must send an alarm or special message signal to all related planes that will be in system for that time .

3.5. ADMINISTRATIVE SOFTWARE REQUIREMENTS .

3.5.1. LOGIN:
Anyone to work on the system or interact with the system must login first with a username and password and also a thumb impression for complete security in a very delicate environment. All the activities he or she performs during the login period must be recorded in data base for future record.

Software Requirements Specification for Automated Air Traffic Control System Page 17

3.5.2. ACCESS CONTROL /CHECK:

Access controls to data base must be defined that is everyone must not be allowed to access every part of the system and if anyone tries to access restricted section a signal or alarm must be generated to higher authorities.

3.5.3. USER FRIENDLY:

It must be user friendly interfaces for the people to be using this system might lack software related skills for example database handling etc. so the software must be of such level that anyone after 1 or 2 hours of training must be able to use it within restricted access. (Familiarization with ATCS basic terms and procedures is a pre requisite condition for using the software).

3.5.4. REAL TIME/SYNCHRONIZED:

The software must be real time and synchronized for a station that is anyone must not be able to turn it off and all stakeholders accessing it at a certain time on one station must see same information and if any command or change is ordered to system, this change must be notified to all users online at that time without any delay. So that contradictory orders are not given to the system or same order is not repeated.

3.5.5. COMPATIBILITY ISSUE:

The software must be developed or coded in language that is compatible with the instruments and computers in the Air Traffic Control Tower. It doesnt matter that it is compatible with all platforms or not, it must be compatible with desired machines for which it is being developed. Even it is better if it is not compatible with most generally deployed machines and operating systems for security reasons.

3.5.6. EDIT TASKS :

It should give an option of editing and rescheduling shifts head and appointing new people for special shifts and creating special tasks assignments for different employees.

3.5.7. TASK LIST:

Software must contain a Tab of task list which contain number of tasks that are pending for a user and must give a notification to the user showing his number of pending tasks every time he login. Also, when a user log off at end of duty system must prompt if any of his tasks were incomplete and show a success percentage giving how many of his tasks are successfully completed during current session.

Software Requirements Specification for Automated Air Traffic Control System Page 18

SECTION 4: OTHER NON-FUNCTIONAL REQUIREMENTS

4.1. PERFORMANCE REQUIREMENTS
The software should have good performance. In order to ensure good performance of the AATC software the hardware must be compatible with all the sub systems of the software. The system should be designed and implemented as such that it could handle errors and exceptions efficiently. In case of system failure, there must be a backup system to resume the operations without much time overhead as for the AATC system time is a major constraint.

4.2. SAFETY AND SECURITY REQUIREMENTS

The software should be secure. It should only be used by the authorized user. It should also be security attack proof. Any third party application or something like virus should not affect the software performance. There should be login for different employees. The software should keep track of the user login time, activities (which flight was controlled which time, which response was given to the flight request, which information was given to flight pilot etc.) on software and logout time. Nobody can access the software without authentication.

4.3. SOFTWARE QUALITY A TTRIBUTES

4.3.1. 4.3.2. RELIABILITY: The software should be reliable. It should be accurate enough to ensure that all the reading are precise. SECURITY:
The software should be secure. It should only be used by the authorized user. It should also be security attack proof. Any third party application or something like virus should not affect the software performance. There should be login for different employees. The software should keep track of the user login time, activities (which flight was controlled which time, which response was given to the flight request, which information was given to flight pilot etc.) on software and logout time. Nobody can access the software without authentication.

4.3.3.

M AINTAINABILITY :

Unless the product customized or source code is changed, any maintenance support shall be provided by parent organization. Backing up of the database is not required.

4.3.4.

PORTABILITY: The software should be portable from hardware to hardware, so that if there is a hardware upgrade so we wont need to start the whole software from scratch. 4.3.5. S UPPORTABILITY :

Software Requirements Specification for Automated Air Traffic Control System Page 19 The system should be supportive. It should be supported to maximum number of operating systems like and different distributions of the operating systems. As we know, this is very important that the software should be supportive to operating system, there is also important that it should also support the hardware, so that it may able to give the performance at it bests.

4.3.6.

M AINTAINABILITY : The software should be written in such a manner that there is not a big issue to maintain it. The whole code should be easily understandable. There should be ease of realizing updates of the software. Any maintenance support shall be provided by parent organization.

SECTION 5: SYSTEM EVOLUTION

In future following modification can be made in the software to enhance the functionality of the software. There can be different steps that can be taken to enhance to performance and quality of the software. There can be added a module to provide the track predicting functionality. The track prediction function shall provide an estimate of a future track position of a given aircraft, with 5 percent accuracy. There can be added a module which can notify the different conflicts or problems in the system or any other component which are interacting with the system. The software will provide the functionality even if there are some problems in the different components which are interacting with the software. The AATC software also shall be able to handle a load that is exceeded. The resolution advisory shall provide the controller with a possible solution to current or future conflict.

Software Requirements Specification for Automated Air Traffic Control System Page 20

Appendix A Glossary
Air Traffic Controller (ATC) Arrival Departure manager (ADM) System Coordination (SYSCO) Minimum Safe Altitude Warning (MSAW): Short Term Conflict Alert (STCA) Area Penetration Warning (APW) Controller Pilot Data Link Communications (CPDLC): Controller Pilot Data Link Communications (CPDLC), also referred to as Controller Pilot Data Link (CPDL), is a method by which air traffic controllers can communicate with pilots over a data link system. User Request Evaluation Tool (URET): User Request Evaluation Tool or URET is a tool to help air traffic controllers to detect and resolve potential conflicts between aircraft and between aircraft and airspace. The goal of URET is to help air traffic controllers to support a greater number of user-preferred flight profiles, increase user flexibility, and increase system capacity.

Software Requirements Specification for Automated Air Traffic Control System Page 21

Appendix B Analysis Model

CLASS DIAGRAM

Software Requirements Specification for Automated Air Traffic Control System Page 22

USE CASE DIAGRAMS

Software Requirements Specification for Automated Air Traffic Control System Page 23

Software Requirements Specification for Automated Air Traffic Control System Page 24

COLLABORATION DIAGRAM

Software Requirements Specification for Automated Air Traffic Control System Page 25

ACTIVITY DIAGRAM

Figure: Activity diagram to assign runway

Software Requirements Specification for Automated Air Traffic Control System Page 26

Figure: Activity Diagram for Weather check

Software Requirements Specification for Automated Air Traffic Control System Page 27

Figure: Activity Diagram for Minimum Safe Amplitude Warning

Software Requirements Specification for Automated Air Traffic Control System Page 28

DEPLOYMENT DIAGRAM

ATC Terminal trying to run the Weather application present on the Met. Department website