Air Traffic Control System

Software Requirements Specification



 
Janusz Zalewski 
 
 
Dept. ECE University of Central Florida 
 
Revision 2, January 16, 1998
 


1. Introduction

This document is a translation of the official Problem Statement [1] for
the Sixth Workshop on Parallel and Distributed Real-Time Systems. 

The August 1997 issue of IEEE Spectrum features an article on air traffic
control [4] that describes some of the challenging problems in distributed
real-time computing.  Thus, an air traffic control has been chosen as the
problem to be solved for present ation during a special session of the
above mentioned Workshop.  (Source: PS Para1)

Solutions to the Problem Statement should be in the form of a design, a
prototype, or an architecture, and should provide sufficient detail to be
critically evaluated.  A session at the Workshop will be dedicated to
presentations and discussion of the sol utions.  Problem solutions
presented at the previous Workshop (1996) can be found in the Proceedings
(to be published by IEEE Computer Society Press, but not yet available at
the time of this writing). (Source: PS Para1)

The original Problem Statement [1] has been developed in coordination with
engineers who are involved with software upgrades to the US air traffic
control system (ATCS).  Additionally, a US air traffic controller was
involved in producing the Problem Stat ement.  Thus, the Problem Statement
reflectss characteristics of the US ATCS. (Source: PS Para2)

2. Definitions and Acronims

active track - The track referring to an aircraft in currently monitored
part of an airspace. 

beacon code - A unique numeric identifier that only one aircraft can have
in a particular Center's airspace at any given instant. (Source: PS Para5)

ATCS - Abbreviation for Air Traffic Control System.

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 directires, and real-time aircraft positional information
to provide immediate and near-term control and separation of aircraft
[to cntrollers] [5].  Subject of this Software Requirements Specification.

Center - Abbreviation for En Route Traffic Control Center.

controller - Abbreviation for Air Traffic Controller -- an operator of 
the ATCS.

En Route Traffic Control Center - On of 20 U.S. air traffic control
facilities that control aircraft traveling at altitudes above 18,000 
feet. [3]

flight plan - Data consisting of the following items:
- aircraft identification
- aircraft type and equipment
- beacon code
- filed air speed
- coordination fix
- coordination time
- requested altitude, and
- route of flight.
(Source: PS Para5)

flight service station - A facility providing services to pilots, such as
flight plan filing, preflight and en route weather briefings (including 
the status of navigational aids), airport condition reports, search and 
rescue operations, assistance to lost or disoriented aircraft pilots, 
instrumental flight rule or special visual flight rule clearances, 
soliciting pilot reports on flying conditions, and providing other 
special services. [6]

flight strip - Data the controller needs to know about the aircraft in
order to control it.  It consists, at minimum, of the following items:
- flight identification
- aircraft data
- true air speed
- estimated ground speed
- sector number
- computer identification number
- strip number
- previous posted fix
- assigned altitude
- coordination fix
- coordination time
- beacon code, and
- any remarks.
(Source: PS Para8)

load - The number of flight plans and active tracks that need to be
handled simultaneously by the ATCS. 

mile - As used in this document, a nautical mile, equal to 1,852 meters. 

PS - Problem Statement as presented in [1].

Terminal Radar Approach Control - One of 150 U.S. air traffic control
facilities that are responsible for areas designated as terminal control
areas, the exact size of which differs depending on the facility, but
typically extends to about 30 miles from the airport Tower.

Tower - One of approximately 430 facilities located at major airports that
provides control of [aircraft on] the airport surface and control within
the immediate airspace surrounding the airport. [5]

track - The information about the aircraft consisting of the following items:
- an aircraft's (x,y) coordinates
- altitude, and
- beacon code.
(Source: PS Para5)

Tracon - Abbreviation for Terminal Radar Approach Control.

3. References

[1] Problem Statement for the Sixth Workshop on Parallel and Distributed
Real-Time Systems, URL: http://www.ippsxx.org

[2] Debelack A.S. et al.,
Next Generation Air Traffic Control Automation,
IBM Systems Journal, Vol. 34, No. 1, pp. 63-77, January 1995

[3] Perry T.S. et al.,
Improving the World's Largest, Most Advanced Systems,
IEEE Spectrum, Vol. 28, No. 2, pp. 22-36, February 1991

[4] Perry T.S.,
In Search of the Future Air Traffic Control,
IEEE Spectrum, Vol. 34, No. 8, pp. 18-35, August 1997

[5] Pozesky M.T., M.K. Mann,
The US Air Traffic Control System Architecture,
Proceedings of teh IEEE, Vol. 77, No. 11, pp. 1605-1617, November 1989

[6] Wickens C.D., A.S. Mavor, J.P. McGee (Eds.),
Flight to the Future: Human Factors in Air Traffic Control,
National Academy Press, Washington, DC, 1997

4. Software Requirements

4.1 Background

The United States air space is divided into 20 regions called En Route
Traffic Control Centers. Each Center is further divided into sectors.  An
air traffic controller can control one or more air traffic sectors in a
Center.  The air space surrounding an airport is termed the Tracon
(Terminal Radar Approach Control Area).  The Tracon area is usually
defined as 40-mile radius around a major airport, having an altitude of
around 10,000 feet.  The Tracon receives control of aircraft that are
landing at the Tracon's airport and passes control of aircraft that are
leaving the Tracon airspace.  The Tower has final approach control of an
arriving aircraft and departure control of aircraft wanting to leave the
airport. (Source: PS Para2)

More specifically, the planes start their flight with a clearence from one
of more than 400 airport Towers.  At about two miles away from the runway,
one of 185 Tracon facilities takes over, tracking the planes in lower
altitudes to, typically, 40 miles to and from an airport.  Twenty eight
Tracons are separate sites, the rest are part of an airport Tower. [4]

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 pla ns.  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
confli ct-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. [4]

4.2 Problem Formulation

Design an air traffic control system (ATCS) that is fault tolerant and
scalable, according to the specific requirements listed in the following
sections. (Source: PS Para3)

Note. The primary objective of the ATCS is to provide separation services
for aircraft that are flying in controlled air space, or where poor
visibility prevents from maintaining visual separation.  Aircraft are
separated from one another and from terrain hazards. [2]

4.3 Specific Software Requirements

The requirements of ATCSs 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 scenarions can vary significantly,
hence the average loading of the ATCS is no t 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
preallocation of computing resources for such a worst case would lead to
very poor resource utilization.  A dynamic resource management policy is
thus preferred. (Source: PS Para11)

4.3.1 General Functionality and Load Requirements

4.3.1.1 The ATCS shall be able to provide:
- track prediction
- conflict probe and alert
- resolution advisories
- minimum safe altitude advisory warnings, and
- time-based arrival and departure metering.
(Source: PS Para4)

4.3.1.2 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. 
(Source: PS Para3)

4.3.1.3 The ATCS shall be able to handle varying loads. 
(Source: PS Para3)

4.3.1.4 As a minimum, the ATCS shall be capable of handling 2600 flight
plans and 700 active tracks in one Center's air space region.  (Source: PS
Para3)

4.3.1.5 The ATCS also shall be able to handle loads that exceed this minimum. 
(Source: PS Para3)

Note 1. There is no upper bound (or worst case) load. (Source: PS Para3)

Note 2. There is significant variance in loading, so that the average load
is a virtually useless characterization. (Source: PS Para3)

4.3.2 Input Data Requirements

4.3.2.1 The ATCS shall be able to acquire data and convert them into a
format the controller can use. (Source: PS Para4)

4.3.2.2 Data inputs include a maximum of 25 long range and short range
radars. (Source: PS Para5)

4.3.2.3 The new radar or track information is arriving every 5 seconds.
(Source: PS Para5)

4.3.2.4 As multiple radars can return radar hits on the same aircraft,
from these multiple hits a primary and secondary radar must be chosen for
each aircraft. (Source: PS Para5)

4.3.2.5 The ATCS shall allow various controller inputs to manipulate not
only the display but also the track and flight plan information. (Source:
PS Para4)

4.3.2.6 The controller shall be able to update and modify the flight strip.
(Source: PS Para8)

4.3.2.7 The displays shall be able to accept controller inputs that modify
the flight plan information and track data. (Source: PS Para8)

4.3.2.8 The ATCS shall be able to handle flight plans to be input from
other Centers, flight service stations, and bulk flight plan (tape)
storage. (Source: PS Para5)

4.3.3 Output Data Requirements

4.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
- aircraft positions
- aircraft data (including aircraft ID, reported altitude, assigned altitude, ground speed)
- metering arrival and departure lists
- weather information, and
- electronic flight strips.
(Source: PS Para8)

4.3.3.2 The information displayed shall include all of the following:
- track
- flight plan
- metering lists
- arrival lists
- departure lists
- flight strips
- weather data.
(Source: PS Para4)

4.3.3.3 The ATCS shall be able to display the available information listed
in Requirement 4.3.4.1 to up to 120 displays. (Source: PS Para4)

4.3.3.4 The data from all the different radars in the system shall be
mosaiced so that all the radar is projected onto a single plane of
reference. (Source: PS Para5)

4.3.3.5 Any changes the controller makes in a flight strip shall be
reflected on any other flight strips that may be displayed in the ATCS.
(Source: PS Para8)

4.3.3.8 The displays shall provide the ability to hand-off control of an
aircraft from one sector to another sector. (Source: PS Para8)

4.3.3.9 The ATCS shall to be able to provide for data recording of any
sent or received data between processes and/or remote systems, as well as
data while process is running. (Source: PS Para4)

4.3.3.10 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
- interprocess communication
- inter-Center and inter-Tracon communications.
(Source: PS Para10)

4.3.4 Joint Input/Output Data Requirements

4.3.4.1 The ATCS shall be able to send data to and receive data from
surrounding Centers, Tracons, and Towers. (Source: PS Para4)

4.3.4.2 Weather information shall be accepted so that it can be used later
for track prediction and to be displayed to the controller. (Source: PS
Para5)

4.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. (Source: PS Para9)

4.3.4.4 The communication link referred to in Requirement 39 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. (Source: PS Para9)

4.3.4.5 The communication link referred to in Requirement 39 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. (Source: PS Para9)

4.3.5 Detailed Functional Requirements

The following requirement is void.
4.3.5.1 Several alert and advisory functions shall be provided to ensure
safe separation of aircraft in the Center's airspace.  The specific
functions shall be as follows: 
- track prediction function 
- conflict probe and alert function
- resolution advisory function.
(Source: PS Para6)

4.3.5.2 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 air space are: 
- 5 miles horizontally, and
- 1,000 to 2,000 feet vertically.
(Source: PS Para6)

4.3.5.3 The track prediction function shall provide a future track
position of a given aircraft. (Source: PS Para6)

4.3.5.4 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.
(Source: PS Para6)

4.3.5.5 The resolution advisory shall provide the controller with a
possible solution to current or future conflict. (Source: PS Para6)

4.3.5.6 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 air space, 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. (Source: PS
Para6)

4.3.5.7 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. (Source: PS Para7)

4.3.5.8 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. (Source: PS Para7)

4.3.5.9 Metering lists shall be provided to the appropriate controllers,
for them to be able to manipulate the lists according to their aircraft
sequence requirements. (Source: PS Para7)

4.3.5.10 Each new track information, once received, shall be correlated
with the flight plans stored in the ATCS. (Source: PS Para5)

Appendix.  Defects found in the original Problem Statement [1] and
corrected herewith.

1. Typographical Errors

2. Completeness

Completeness is the property of the specification document that ensures
inclusion of all the information necessary to develop a specified system. 

2.1 The following terms are left undefined in [1]:

active track

flight service station 

2.2 The following items are not defined in [1]:

"format the controller can use" in 4.3.2.1

3. Consistency

Consistency is the property of the specification document which ensures 
that there is no contradictory information in this document. 

In fact, consistency should also ensure non-redundancy, because the same 
concept explained more than once is likely to be misinterpreted.

The following requirements were incosistent with one another and needed 
to be rephrased (see original wording in [1]):

4.3.3.1/4.3.3.2/4.3.3.3

4.3.1.1/4.3.5.1

4.3.1.4/4.3.2.8

4.3.3.9/4.3.3.10

4. Correctness

Correctness is the property of the specification document that ensures
this document's compliance with external requirements, such as related
documents, standards, scientific knowledge, common sense, etc. 

Examples of incorrectess in [1]:
- use of word "will" while "shall" shouls be used
- use of the term "mile" without definition may have implied "statute mile"
while it's a nautical mile
- no upper bound on load in 4.3.1.5 implies infinite memory requirements,
which is incorrect (real memory size must be finite).

5. Clarity

Clarity is the property of the specification document that ensures its
understanding and non-ambiguous interpretation by the reader proficient in
the specification language. 

5.1 Paragraph 10 is absolutely unclear.  Its interpretation is included as
Requirement 4.3.3.10. 

5.2 The system to be developed is termed "system", in most cases, or
"ATCS", in some cases, in [1].  The term used throught this Software
Requirements Specification has been unified to "ATCS". 

End of Document