system architecture and specification for an indian air traffic flow management system
TRANSCRIPT
System Architecture and Specification
For An Indian Air Traffic Flow Management System
May 6, 2011
Prepared by the
Volpe National Transportation Systems Center
For the
Federal Aviation Administration
For the use by the
Airports Authority of India
i
[This Page Intentionally Left Blank]
ii
Table of Contents
SECTION 1. INTRODUCTION................................................................................................................... 1
1.1 Scope ................................................................................................................................................. 1
1.2 Objectives ......................................................................................................................................... 1
1.3 Intended Audience ............................................................................................................................ 1
1.4 Document Overview ......................................................................................................................... 2
SECTION 2. ATFMS ARCHITECTURE .................................................................................................... 3
2.1 System Architecture Overview ......................................................................................................... 3
2.1.1 Critical Architectural Drivers .................................................................................................... 4
2.1.2 Architecture Type ..................................................................................................................... 4
2.2 System Architecture Detailed Description ........................................................................................ 4
2.2.1 ATFMS Services ....................................................................................................................... 5
2.2.1.1 Overview of the ATFMS Services ........................................................................................ 5
2.2.1.2 Services Definitions .............................................................................................................. 7
2.2.2 Overview of the ATFMS Interfaces ........................................................................................ 14
2.2.2.1 Major ATFMS Interfaces Descriptions ............................................................................... 14
2.2.2.1.1 Users Interface ............................................................................................................................. 14
2.2.2.1.2 Meteorological Systems Interface ............................................................................................... 15
2.2.2.1.3 Aeronautical Information System (AIS) Interface ........................................................................ 15
2.2.2.1.4 Surveillance Systems Interface .................................................................................................... 17
2.2.2.1.5 International Systems Interface ................................................................................................... 23
2.2.2.1.6 Flight Plan Services ....................................................................................................................... 23
2.2.2.1.7 Surface Movement Systems Interface ......................................................................................... 23
2.2.2.1.8 Airlines Operations Center Interface ........................................................................................... 24
2.2.2.1.9 Military Operations Interface ....................................................................................................... 27
2.2.3 ATFMS Data Items ................................................................................................................. 28
2.2.3.1 Overview of the ATFMS Data Items .................................................................................. 28
2.2.3.2 Major Data Items ................................................................................................................ 28
2.2.3.2.1 Flight Object Data Item ................................................................................................................ 29
2.2.3.2.2 Airspace Object Data Item ........................................................................................................... 31
2.2.3.2.3 Airport Object Data Item .............................................................................................................. 32
2.2.3.2.4 Alert Object Data Item ................................................................................................................. 33
2.2.3.2.5 Traffic Management Initiative Object Data Item ......................................................................... 33
2.2.3.2.6 Display Object Data Item ............................................................................................................. 35
iii
2.2.4 Decision Support Tools (DSTs) .............................................................................................. 35
2.2.4.1 Demand/Capacity Imbalance Tools .................................................................................... 36
2.2.4.2 TMI Development/Assessment Tools ................................................................................. 36
2.2.4.3 Collaborative Decision Making Tools ................................................................................ 37
2.2.4.4 TMI Implementation DSTs ................................................................................................. 38
2.2.4.5 Information Management DSTs .......................................................................................... 38
SECTION 3. ATFMS DISPLAYS AND TECHNOLOGY ....................................................................... 40
3.1 ATFM Specialist Displays .............................................................................................................. 40
3.1.1 Overview of the ATFM specialist Displays ............................................................................ 40
3.1.2 Strategic Slot Scheduling and Flight Plan System .................................................................. 40
3.1.3 Traffic Situation Display ......................................................................................................... 41
3.1.3.1 Types of TSDs .................................................................................................................... 41
3.1.3.1.1 CCC Specialist TSD ........................................................................................................................ 41
3.1.3.1.2 Remote ATFM specialist TSD ........................................................................................................ 42
3.1.3.1.3 Web-Based Text TSD .................................................................................................................... 43
3.1.3.2 Displaying the Data ........................................................................................................... 43
3.1.3.2.1 Maps Database ........................................................................................................................... 44
3.1.3.2.2 Traffic Situation Data .................................................................................................................. 44
3.1.3.2.3 Monitor Alert Displays ................................................................................................................. 46
3.1.3.2.4 Request Reports ......................................................................................................................... 47
3.1.3.2.5 Weather Displays ........................................................................................................................ 48
3.1.3.2.6 Reroute Displays ......................................................................................................................... 49
3.1.3.2.7 Display Data Sources .................................................................................................................. 50
3.1.4 TMI Modeling, Impact Assessment, and Execution ............................................................... 52
3.1.4.1 Displaying Ground Stops and Ground Delay Programs ..................................................... 52
3.1.4.1.1 FSM Display .................................................................................................................................. 53
3.1.4.1.2 Historical versus Live Mode ......................................................................................................... 53
3.1.4.1.3 Monitored Mode versus Ground Delay Tools Mode ................................................................... 54
3.1.4.1.4 GDP Modeling .............................................................................................................................. 54
3.1.4.1.6 Intra-Airline Compression ............................................................................................................ 54
3.1.4.1.7 Inter-Airline Compression ............................................................................................................ 54
3.1.4.1.8 Compress Flight ............................................................................................................................ 55
3.1.4.1.9 Move Up a Flight .......................................................................................................................... 55
3.1.4.1.10 Blanket (+/- Delay) Algorithm .................................................................................................... 55
3.1.4.1.11 Ground Stop Algorithm .............................................................................................................. 55
iv
3.1.4.2 Flight Level/ Altitude Adjustment TMI .............................................................................. 55
3.1.4.3 In-trail Spacing TMI ........................................................................................................... 56
3.1.4.4 Reroutes TMI ...................................................................................................................... 56
3.1.4.5 Fix Balancing TMI .............................................................................................................. 57
3.1.4.6 Airborne Holding TMI ........................................................................................................ 57
3.1.4.7 Sequencing and Spacing TMIs ........................................................................................... 58
3.1.5 Operational Performance Monitoring and Assessment ........................................................... 58
3.2 ATFMS Technology Selections ...................................................................................................... 59
3.2.1 Communication Application Programming Interface (API)s and Messaging ........................ 60
3.2.2 Databases ................................................................................................................................ 60
3.2.3 Programming Languages ........................................................................................................ 60
SECTION 4. OPERATIONAL REQUIREMENTS ................................................................................... 61
4.1 Air Traffic Flow Management System (ATFMS) General Specifications ..................................... 61
4.2 Required Modes of Operation ......................................................................................................... 61
4.3 Strategic and Pre-Tactical Operational Requirements .................................................................... 62
4.3.1 Determine the Strategic and Pre-tactical Situation ................................................................. 62
4.3.2 Disseminate Strategic and Pre-tactical Information ................................................................ 62
4.3.3 User Requests for Demand Projections ................................................................................... 63
4.3.3.1 User Requests for Capacity Projections .............................................................................. 63
4.3.4 Analyze Strategic and Pre-tactical Situations ......................................................................... 63
4.3.5 Generate Strategic and Pre-tactical Strategies ........................................................................ 64
4.3.6 Strategic Capacity Management ............................................................................................. 64
4.3.7 Pre-Tactical and Special Event Planning and Management.................................................... 64
4.4 Tactical Operational Requirements ................................................................................................. 64
4.4.1 Traffic Situation Monitoring and Problem Identification ....................................................... 65
4.4.1.1 Provide Capacity Projections. ............................................................................................. 66
4.4.1.1.1 Monitor Information Pertinent to Capacity ................................................................................. 66
4.4.1.1.2 Specialists' Inputs ......................................................................................................................... 66
4.4.1.1.3 Determine Current Demand and Capacity ................................................................................... 66
4.4.1.1.4 Determine Future Capacity .......................................................................................................... 67
4.4.1.1.5 Disseminate Capacity Information ............................................................................................... 67
4.4.1.2 Provide Demand Projections ............................................................................................... 68
4.4.1.2.1 Monitor Information Pertinent to Demand ................................................................................. 68
4.4.1.2.2 Determine Demand ...................................................................................................................... 68
v
4.4.1.2.3 Disseminate Demand Information ............................................................................................... 68
4.4.1.3 Evaluate Capacity and Demand .......................................................................................... 69
4.4.1.3.1 Analyze Traffic Saturation Conditions. ......................................................................................... 70
4.4.2 Flow Problem Resolution ........................................................................................................ 70
4.4.2.1 Coordinate Traffic Flow Strategies ..................................................................................... 70
4.4.2.1.1 Analyze Traffic Flow Alternatives ................................................................................................. 70
4.4.2.1.2 Coordinate Alternatives ............................................................................................................... 70
4.4.2.2 Modify Current Flow Strategies.......................................................................................... 71
4.4.3 Flight Plan Execution .............................................................................................................. 71
4.4.4 Disseminate Traffic Flow Guidance ....................................................................................... 71
4.4.4.1 Implement Traffic Flow Plans ............................................................................................ 71
4.4.4.2 Disseminate Traffic Flow Information ................................................................................ 72
4.4.4.3 Non-Compliance ................................................................................................................. 72
4.5 Logging and Post Analysis Operational Requirements .................................................................. 73
4.5.1 Data Logging .......................................................................................................................... 73
4.5.2 Real-time and Post Analysis ................................................................................................... 73
4.5.3 Evaluate Flow Performance .................................................................................................... 74
4.5.3.1 Store Flight Day Information .............................................................................................. 74
4.5.3.2 Evaluate Stored Information ............................................................................................... 75
4.5.3.3 Generate Performance Reports ........................................................................................... 75
4.5.4 Report Flow Performances ...................................................................................................... 75
4.6 Infrastructure Support ..................................................................................................................... 76
4.6.1 Airspace System Definitions ................................................................................................... 76
4.6.2 Centralized ATFM Processing ................................................................................................ 76
4.6.3 Computer Software Quality Program and Plan ....................................................................... 77
4.6.4 Distributed Dissemination and Modeling ............................................................................... 77
4.6.5 System Level Interfaces .......................................................................................................... 78
4.6.6 Testing and Evaluation ............................................................................................................ 78
4.6.7 Logistics .................................................................................................................................. 78
4.6.8 Configuration Management (CM) .......................................................................................... 78
4.7 System Security .............................................................................................................................. 79
4.7.1 User and Process Identification and Authentication ............................................................... 79
4.7.2 ATFMS Access ....................................................................................................................... 80
4.7.3 Security Management ............................................................................................................. 80
vi
4.7.4 Network Security Protection ................................................................................................... 81
4.7.5 Application Software and Data Protection .............................................................................. 81
SECTION 5. FUNCTIONAL SPECIFICATIONS .................................................................................... 83
5.1 Collect Traffic Management Information ....................................................................................... 83
5.2 Geographical Data Requirements ................................................................................................... 83
5.2.1 Input Geographical Data ......................................................................................................... 84
5.2.2 Dynamic Sector Processing .................................................................................................... 85
5.3 Scheduled Flight Data Processing ................................................................................................... 85
5.3.1 Source Schedule Data ............................................................................................................. 85
5.3.2 Schedule Data Processing ....................................................................................................... 85
5.4 Flight Plan Processing ..................................................................................................................... 86
5.4.1 Flight route - Filed Flight Path ................................................................................................ 86
5.5 Flight Modeling .............................................................................................................................. 86
5.5.1 Flight Profile Modeling ........................................................................................................... 87
5.6 Situation Awareness and Problem Identification ............................................................................ 87
5.6.1 Common Situational Awareness ............................................................................................. 87
5.6.2 Capacity Prediction ................................................................................................................. 88
5.6.3 Demand Prediction .................................................................................................................. 88
5.6.4 Analyze Constraints ................................................................................................................ 89
5.6.5 Congestion Identification and Reporting ................................................................................ 89
5.7 Collaborative Decision Making (CDM) ......................................................................................... 90
5.7.1 Distributed Planning ............................................................................................................... 90
5.7.2 Analytical Capability .............................................................................................................. 90
5.7.3 Generate Solutions .................................................................................................................. 91
5.8 Weather Data Processing ................................................................................................................ 91
5.8.1 Common weather picture ........................................................................................................ 91
5.8.2 Reliable Weather Data Input Requirements ............................................................................ 92
5.8.3 Update Frequency ................................................................................................................... 92
5.8.4 Weather Information Dissemination ....................................................................................... 92
5.8.5 Tailored Weather Data ............................................................................................................ 92
5.9 Flow Initiative Planning .................................................................................................................. 93
5.9.1 TMI Modeling ......................................................................................................................... 93
5.9.2 TMI Impact Assessment ......................................................................................................... 96
5.9.3 TMI Coordination and Collaboration...................................................................................... 96
vii
5.10 TMI Implementation ....................................................................................................................... 96
5.10.1 Communication and Distribution of Initiatives ....................................................................... 97
5.10.2 TMI Monitoring and Evaluation ............................................................................................. 97
5.10.3 TMI Termination..................................................................................................................... 97
5.11 Information Management ................................................................................................................ 98
5.11.1 Automated Collection and Distribution .................................................................................. 98
5.11.2 Data Recording ....................................................................................................................... 98
5.11.3 System Performance Assessment ............................................................................................ 98
5.12 ATFMS Training ............................................................................................................................ 98
5.13 System Performance ....................................................................................................................... 99
5.13.1 Communication ..................................................................................................................... 103
5.13.2 Reliability .............................................................................................................................. 105
5.13.3 Maintainability ...................................................................................................................... 105
5.13.4 Availability ........................................................................................................................... 105
5.13.5 System Recovery and Data Backup ...................................................................................... 105
SECTION 6. DESIGN AND CONSTRUCTION ..................................................................................... 106
6.1 Accessibility .................................................................................................................................. 106
6.2 Space Allocation ........................................................................................................................... 106
6.3 Structural and Seismic Stability .................................................................................................... 106
6.4 Operational Design Considerations .............................................................................................. 107
6.4.1 Energy Conservation ............................................................................................................. 107
6.4.2 Acoustic Noise ...................................................................................................................... 107
6.4.3 Operating Environment ......................................................................................................... 107
6.4.4 Non-Operating Environment ................................................................................................. 107
6.4.5 Heating, Ventilation, Air Conditioning ................................................................................. 108
6.4.6 Grounding, Bonding, Shielding, and Lightning Protection .................................................. 108
6.4.7 Cables .................................................................................................................................... 109
6.4.8 Hazardous Materials ............................................................................................................. 109
6.4.9 Power Systems and Commercial Power ............................................................................... 110
6.4.10 Electromagnetic Interference (EMI) / Electromagnetic Compatibility (EMC) ..................... 111
6.4.11 Special Considerations .......................................................................................................... 112
SECTION 7. VERIFICATION ................................................................................................................. 114
7.1 Methods of Verification ................................................................................................................ 114
7.1.1 General .................................................................................................................................. 114
viii
7.1.2 Requirement Verification by Demonstration ........................................................................ 114
7.1.3 Requirement Verification by Test ......................................................................................... 114
7.1.4 Requirement Verification by Analysis .................................................................................. 114
7.1.5 Requirement Verification by Inspection ............................................................................... 114
7.2 Requirements for Performance Tests ............................................................................................ 114
7.2.1 Success/Failure Criteria ........................................................................................................ 114
7.2.2 Verification Levels ................................................................................................................ 115
APPENDIX A. ABBREVIATIONS AND ACRONYMS........................................................................ 118
APPENDIX B. REFERENCES ................................................................................................................ 121
ix
LIST OF FIGURES
Figure 1 - ATFMS High Level System Architecture ..................................................................................................... 3
Figure 2 - ATFMS Open Architecture ........................................................................................................................... 5
Figure 3 - ATFMS Service Level Architecture ............................................................................................................. 7
Figure 4 - Utility Services Data Flow Diagram ............................................................................................................. 8
Figure 5 - Security Services Data Flow Diagram .......................................................................................................... 9
Figure 6 - Airspace and Airports Object Service Data Flow Diagram ........................................................................ 10
Figure 7 - Flight Object Service Data Flow Diagram .................................................................................................. 11
Figure 8 - Alerts Service Data Flow Diagram ............................................................................................................. 12
Figure 9 - TMI Services Data Flow Diagram Major ATFMS Interfaces ..................................................................... 13
Figure 10 - Integrated AIS Automation System .......................................................................................................... 16
Figure 11 - Example of Air Traffic Predictive Demand and Congestion Display ....................................................... 41
Figure 12 - Java Applet Situational Display ................................................................................................................ 42
Figure 13 - Web-Based Situational Display ................................................................................................................ 43
Figure 14 - Before and After Effect of a Modeled GDP .............................................................................................. 52
Figure 15 - Operational Performance Report on Departure Compliance..................................................................... 59
LIST OF TABLES
Table 1 - ATFMS Services ............................................................................................................................................ 6
Table 2 - ATFMS Data Item Hierarchy ....................................................................................................................... 28
Table 3 - TMI Modeling Parameters ........................................................................................................................... 93
x
[This Page Intentionally Left Blank]
1
Section 1. Introduction The purpose of this document is to define the high-level system architecture and system specification for
India’s future Air Traffic Flow Management System (ATFMS). This document provides the
decomposition of the system into its components in a manner that will allow for the creation of a roadmap
for the actual development and implementation of the system. In addition, this document describes the
services that the system provides, the ATFMS interfaces, the required decision support tools (DSTs), and
the operational and functional requirements that the system must satisfy. In addition, the displays
required for ATFMS operations are also described in detail.
This document is intended to be used to accomplish the following important tasks:
Communicating system detail to stakeholders
Serving as the baseline of information necessary for scheduling and estimating potential cost
Creation of a roadmap for the actual development and implementation of the ATFMS
Developing the procurement strategy
1.1 Scope
All system components such as hardware (servers / operating system, display units), application software,
and various ATFM tools will be documented. Baseline data requirements, interfaces with internal and
external systems, communication system requirements and protocols and other associated systems will be
considered in the architecture and documented in the specifications.”
By describing this document as a high-level System Architecture and Specification document, the
intention is that the most important features of the system will be described in sufficient detail to permit
the development of a path towards a future operational system. This document will describe the ATFMS
logical/functional architecture, but not the physical/subsystems architecture. Essentially, this means that
this document assumes dependencies on physical infrastructure such as networks, computer systems
hardware, software, and user workstations that may or may not currently exist.
1.2 Objectives
The objectives for this document are:
Provide a defined structure/architecture for India’s ATFMS
Provide a qualitative and quantitative ATFMS specification in sufficient detail for system
stakeholders to understand India’s ATFMS required capabilities
Clearly define the major components of India’s ATFMS
1.3 Intended Audience
The intended audience for this document is:
System architects/designers
System stakeholders
Development organizations
2
Operations analysts
1.4 Document Overview
This document consists of seven major sections and two appendices:
Introduction
ATFMS Architecture
ATFMS Displays and Technology
Operational Requirements
Functional Specifications
Design and Construction
Verification
The appendices include acronym definitions and document references.
3
Section 2. ATFMS Architecture
2.1 System Architecture Overview
Figure 1 depicts the high level architecture of India’s ATFM system. Critical to the success of ATFM is a
supporting infrastructure that provides:
Airport Surface Movement Systems that can maximize the efficiency of aircraft and vehicle
movements on the airport surface;
Seamless aircraft surveillance through all phases of flight that can provide a digitized national
aircraft position mosaic;
Satellite based navigation system that provides RNAV and RNP capabilities;
Voice and data communication (depicted by the blue arrows in the figure) between all
participants in the ATFM system;
A national weather picture that includes integrated weather sensor data and accurate forecasts;
and,
Automated decision support and display tools to aid all ATFM and collaborative decision making
(CDM) participants to maintain situational awareness and assess potential impacts of Traffic
Management Initiatives (TMIs) under consideration at any time.
Figure 1 - ATFMS High Level System Architecture
4
Technology and facility enhancements assumed to be in place include:
Upgrading of automation systems to include arrival and departure functions;
Precise surface guidance to improve safety and to maximize airport capacity in all weather
conditions;
Advanced Surface Movement Guidance and Control system (ASMGCS)
Seamless integrated surveillance from departure to destination via radar, ADS-B, ADS-C, and
Wide Area Multi-Lateration (WAM);
Improved information and control system interfaces between Approach Control (APP), Area
Control Centers (ACCs), towers (TWR), and METeorological (MET) systems;
More flexible routing, including connector routes in certain airspaces;
Data communications via CPDCL (Mode S, VDL-2, FANS-1A); and
Amalgamation of existing 11 ACCs into 4 ACCs initially and ultimately into 2 ACCs.
2.1.1 Critical Architectural Drivers
The critical architectural drivers for India’s Air Traffic Flow Management System are to:
Satisfy the operational and functional requirements as specified in Section 2 of this document
Incorporate not only the current sources of data, but also be easily adaptable to new sources of
information
Comply with the requirements placed upon the civil aviation system by India’s national military
interests
2.1.2 Architecture Type
India’s ATFMS shall be designed as an open architecture system of systems. The intent is to provide as
flexible a system as possible to allow the system to grow and evolve as the operations, technology, and
environment evolves in India. Therefore, the open architecture and the system of systems approach will
allow the integration of future ATFM capabilities into this system’s architecture. A description of the
ATFMS architecture is presented in section 2.2 below.
2.2 System Architecture Detailed Description
Figure 2 depicts India’s ATFMS open architecture that consists of four major ATFMS components:
Services
Major Interfaces
Data Items
Decision Support Tools
Note that this open architecture approach allows for the flexible addition of new services, data items,
interfaces and decision support tools without the need to change the fundamental architectural approach.
The only requirement is that there is consistency among the four major components. The ATFMS
Services are described in Section 2.2.1; the Major Interfaces in Section 2.2.2; the Data Items in 2.2.3; and,
the DSTs in Section 2.2.4.
5
Figure 2 - ATFMS Open Architecture
2.2.1 ATFMS Services
2.2.1.1 Overview of the ATFMS Services
The ATFMS services are presented from an operational view and their descriptions provide:
Definition of the ATFMS services and their interaction with other services
The source(s) of information needed by the services.
The output information provided by the services.
The data flow among the services and the Major ATFMS Interfaces
6
The list of first and second level services is presented below as Table 1:
Table 1 - ATFMS Services
Level 1 Services Level 2 Services
1. Utility Services
1.1 Display Service
1.2 Data Logging Service
1.3 User Input Service
2. Security Services
2.1 System Access Control Service
2.2 Data Access Control Service
2.3 Data Distribution Control Service
3. Airspace & Airports Objects Service
3.1 Create User Defined Object Service
3.2 Geographical Position Service
4. Flight Object Service
4.1 Flight Position Service
4.2 Flight Route Service
4.3 Flight Time Service
4.4 Flight Crossing Time Service
5. Alerts Service
5.1 Demand Service
5.2 Capacity Service
5.3 Impact Service
5.4 Weather Impact Service
6. Traffic Management Initiative Service
6.1 Flight Level Adjustment Service
6.2 Reroutes/Fix Balance Service
6.3 Airborne Holding Service
6.4 Metering, Sequencing, Spacing Service
6.5 Ground Stop/Ground Delay Program (GS/GDP) Service
The ATFMS Service Level Architecture is presented as Figure 3. In this figure, the orange icons
represent the Air Traffic Management (ATM) systems interfaces that provide critical information to the
ATFMS. The green arrows identify the critical data provided by the ATM system interface. Note that all
inputs to the ATFMS are processed by the security service in order to maintain the integrity of the
ATFMS.
The blue boxes are the Level 1 ATFMS Services. The yellow arrows are the data items that are developed
within a service and transmitted to other services.
7
Figure 3 - ATFMS Service Level Architecture
2.2.1.2 Services Definitions
1. Utility Services
This Level 1 Service provides computer system utility services. It is composed of the following three
level 2 services.
1.1 Display Service: This service displays types of data to the user on a display device.
1.2 Data Logging Service: This service archives operational data which includes: weather;
flight positions; TMIs in effect; capacities; demands; alerts; etc. This data will be used for post
operational analysis for improving system performance and specialist performance.
1.3 User Input Service: This service allows users to enter information into the system
that is not obtained through one of the system interfaces. An example of this may be a NAVAID
being not operational due to an equipment failure. It also allows Air Traffic Management (ATM)
and Airline’s Operations Center (AOC) inputs to the ATFMS for purposes of collaboration on the
development and selection of TMIs
The data flow diagram for these services is presented as Figure 4. Note that in these Services data
flow diagrams, the service being described is illustrated by a purple box around it to differentiate it
from the other ATFMS services and Interface Systems.
8
Figure 4 - Utility Services Data Flow Diagram
2. Security Services
This Level 1 Service provides computer security services which insure user and data integrity. It is
composed of the following two Level 2 Services. All inputs external to the ATFMS are processed
through the Security Service.
2.1 System Access Control Service: This service provides computer access security services.
2.2 Data Access Control Service: This service provides computer data security services.
2.3 Data Distribution Control Service: This service distributes the data to the other
services.
The data flow diagram for these services is presented as Figure 5.
9
Figure 5 - Security Services Data Flow Diagram
3. Airspace and Airports Objects Service
This Level 1 Service provides information about airspace and airport objects. It consists of the
following two Level 2 Services.
3.1 Create User Defined ATM System Object: This service allows the creation by a
user of an airspace object such as a Flow Constrained Area (FCA). The user can enter an airspace
object such as: a 3 dimensional polygon; a 2 dimensional airspace polygon; a line; or a point.
3.2 Geographical Position Service: This service provides the physical (geographical)
location of an airspace object. This service takes as input the name of a fixed airspace feature and
returns the latitude(s), longitude(s), and altitude(s) (if appropriate) of this feature. Examples of
airspace features are: fixes, waypoints, sectors, boundary crossings, flow evaluation areas, flow
evaluation lines, airports(with resolution down to the runway level), routes (including route
segments), Coded Departure Routes (CDR), Standard Terminal Arrival Routes (STARs),
Standard Instrument Departures (SIDs), Special Activity Airspace (SAA), etc.
The data flow diagram for this service is presented as Figure 6.
10
Figure 6 - Airspace and Airports Object Service Data Flow Diagram
4. Flight Object Service
This Level 1 Service provides information about flight objects. It is composed of the following four
Level 2 Services
4.1 Flight Position Service: This service provides a flights position at a specific time, which,
could be in the future. Input is the time or time frame that the position is queried for this can
either be in the future or the past. The output is latitude, longitude, altitude, and heading if
airborne, if the aircraft is not airborne at the query time then the gate, or taxiway, or non
movement area will be returned.
4.2 Flight Route Service: This service provides the route of a flight for the input time
frame, the output will either be the projected or actual waypoints, fixes, route segments that the
flight has already traversed or that the filed flight plan contains, or the trajectory modeler predicts
for the flight.
4.3 Flight Event Service: This service provides either the actual occurrence time or the
predicted time depending if the event has occurred or not. All event times that the system keeps
track of can be queried these are: estimated time of arrival (ETA), estimated departure clearance
time (EDCT), off block time, taxi time, etc. These values are either input into the ATFM system
by other systems or calculated by the ATFM system.
11
4.4 Flight Crossing Time Service: This service provides the time that the system predicts a
flight will cross an airspace feature. Examples of such airspace features are: sector boundaries;
fixes; waypoints. The airspace feature is an input to this service.
The data flow diagram for this service is presented as Figure 7.
Figure 7 - Flight Object Service Data Flow Diagram
5. Alerts Service:
This Level 1 Service provides warnings for demand/capacity imbalances in 15 minute time
increments from the current time up to 12 hours into the future. If the query concerns future days
(up to six months from the current day) then either peak demand is returned or minimum capacity
for that day. This service is made up of the following four Level 2 Services.
5.1 Demand Service: This service provides the demand for any airspace feature in 15 minute
time increments from the current time up to 12 hours into the future. Future days can be queried
up to 6 months from the current day. If a future day is queried then that day’s peak demand is
returned.
5.2 Capacity Service: This service provides the capacity for any airspace feature in 15 minute
time increments from the current time up to 12 hours into the future, Future days can be queried
up to 6 months from the current day. If a future day is queried then that day’s minimum capacity
is returned.
5.3 Capacity Impact Service: This service provides the capacity restriction for any airspace
restriction in 15 minute time increments from the current time up to 12 hours into the future due
12
to operational impacts such as a runway closure; NAVAID failure or maintenance; use of Special
Activity Airspace, etc. This service can also calculate minimum capacity restrictions for a day up
to 6 months in the future.
5.4 Weather Impact Service: This service calculates the capacity restriction for any airspace
feature in 15 minute time increments from the current time up to 12 hours into the future due to
weather impact. This service can also calculate minimum capacity restrictions for a day up to 10
days in the future. This service takes all the meteorological input and calculates an impact on the
airspace thus effectively reducing the airspaces capacity.
The data flow diagram for this service is presented as Figure 8.
Figure 8 - Alerts Service Data Flow Diagram
6. Traffic Management Initiative Services
This Level 1 Service provides the tools to implement and manage Traffic Management Initiatives
(TMIs). It is composed of the following five Level two services.
6.1 Flight Level Adjustment Service: This service allows specific flight(s) to be selected and
analyzed for implementing a flight level change. This service is made up of the: geographical
position service; flight position service; flight route service; flight time service; flight crossing
time service; demand service; capacity service; impact service; weather impact service; alerts
service.
6.2 Reroutes / Fix Balancing Service: This service allows specific flight(s) to be selected and
analyzed for implementing a reroute or fix balancing. This service is made up of the:
geographical position service; flight position service; flight route service; flight time service;
flight crossing time service; demand service; capacity service; impact service; weather impact
service; alerts service.
13
6.3Airborne Holding Service: This service allows specific flight(s) to be selected and
analyzed for implementing airborne holding. This service is made up of the: geographical
position service; flight position service; flight route service; flight time service; flight crossing
time service; demand service; capacity service; impact service; weather impact service; alerts
service.
6.4 Metering, Sequencing, and Spacing Service: This service provides all the
functionality needed to perform: miles in trail; minutes in trail; departure sequencing; arrival
sequencing; enroute sequencing traffic management initiatives. This service allows a route(s) or
fix to be selected and analyzed for implementing a distance or time restriction. This service is
made up of the: geographical position service; flight position service; flight route service; flight
time service; flight crossing time service; demand service; capacity service; impact service;
weather impact service; alerts service.
6.5 Ground Stop / Ground Delay Program (GS/GDP) Service: This service allows an
airport(s) to be selected and analyzed for implementing a ground stop or ground delay program.
This service is made up of the: : geographical position service; flight position service; flight route
service; flight time service; flight crossing time service; demand service; capacity service; impact
service; weather impact service; alerts service.
The data flow diagram for this service is presented as Figure 9.
Figure 9 - TMI Services Data Flow Diagram Major ATFMS Interfaces
14
2.2.2 Overview of the ATFMS Interfaces
ATFMS Interfaces are the element of the architecture responsible for integration and data exchange with
various external and legacy systems. According to the different types of external systems, this element
must contain several adapters or components which can implement the functions of data ingestion and
exchange.
Various vendors developed the legacy systems now being used by the different ATC facilities. Each of
these systems contains its own complexities, and industry best practices recommend a type of “black box”
approach where each of these systems produces a stream of data based on the ATFMS specification
(Section 3). Therefore, the ATFMS does not need to understand the complexities of the data in each of the
ATC systems. To implement the data integration, MQ or other messaging middleware is required.
Middleware is computer software that connects software components and their applications. The software
consists of a set of services that allows multiple processes running on one or more machines to interact.
This technology evolved to provide for interoperability in support of the move to coherent distributed
architectures, which are most often used to support and simplify complex distributed applications. It
includes web servers, application servers, and similar tools that support application development and
delivery. Middleware is especially integral to modern information technology based on eXtensible
Markup Language (XML), Simple Object Access Protocol (SOAP), Web services, and Service Oriented
Architecture (SOA). Middleware sits "in the middle" between application software that may be working
on different operating systems. It is similar to the middle layer of a three-tier single system architecture,
except that it is stretched across multiple systems or applications. Examples include Enterprise
Application Integration (EAI) software, telecommunications software, transaction monitors, and
messaging-and-queuing software.
2.2.2.1 Major ATFMS Interfaces Descriptions
To integrate ATFM and other relevant automation systems, major components must be designed to
implement data exchange between them.
2.2.2.1.1 Users Interface
The Users Interface allows Traffic Management Coordinators (TMC), Military, Airport, and Airlines
Operations Center (AOC) personnel to enter queries and / or data into the ATFMS system. This would of
course be dependent upon their individual operational function.
Functions
Input of data that is not available through automated means such as: a subsystem failure; last minute use
of Special Use Airspace; flight plan amendments; flight reroutes; flight substitutions; etc. System queries
and use of decision support tools.
Technologies
Web services
AAI intranet
SOAP
SOA
Dependencies
Communications facilities with users outside of AAI and within AAI.
15
2.2.2.1.2 Meteorological Systems Interface
The AAI in coordination with the India Meteorological Department (IMD) is preparing a road map for the
upgrading of meteorological facilities at the airports.
This will include provision of:
New integrated automated weather information system,
Web based meteorological information,
Interfacing of MET Computers with Air Traffic Services (ATS) - Automation System at major
airports for enhancing the efficiency of Pilots and Controllers.
Integrated MET data display of current and forecast Weather (Wx) data directly from the MET
computer in all ATC units in major airports/ centres
Real-time Satellite Wx picture with Wx warnings. Wake vortex warning.
OPMETF data exchange through AFTN
AFTN Wx database.
Uplink / downlink of MET data
Integrated ATS/MET/AIS pre-flight briefing to specialists and ATS personnel.
Functions
To accept wind, Runway Visual Range (RVR), weather radar mosaic, lightening, forecasts, and other
weather data from IMD.
To parse the messages and add data to the weather database.
Dependencies
Assume IMD can provide the necessary weather data with appropriate formats. Although an India
Aviation Weather Center does not currently exist, one is planned to be built in the future and in the
meantime, interface with the IMD facilities will provide these services.
Technologies
XML
SOAP
Web services
SOA
2.2.2.1.3 Aeronautical Information System (AIS) Interface
This interface imports data, which are produced by the Aeronautical Information System. The data
include airspace structure, jet routes, fixes, airports, NAVAIDS, restrictions, etc. This component
constructs an airspace digital model, which is directly used to make a traffic prediction with the flight
trajectories.
The planned AIS system is illustrated in Figure 10.
16
Figure 10 - Integrated AIS Automation System
Functions
To import aeronautical and geographical data such as sector structure, route, fix, NAVAIDS ,airspace and
airport configuration, standard instrument departure and arrival route, LOA (Letter of Agreement)
between ATC facilities, NOTAM, and etc.
To provide the process of copying and maintaining database objects in multiple databases that make up a
distributed database system.
Dependencies
Implementation of the AIS system
Technologies
Web services
XML integration
SOAP
SOA
17
2.2.2.1.4 Surveillance Systems Interface
This interface provides a National Mosaic of all surveillance system data. It provides an integrated
national picture of all aircraft. The surveillance system interface accepts flight data and aircrafts’ position
report containing radar track and ADS-B and -C data from 11 ACC systems presently located at:
Mumbai
Delhi
Chennai
Kolkata
Trivandrum
Mangalore
Hyderabad
Nagpur
Varanasi
Ahmedabad
Guwahati
These 11 ACCs will be amalgamated into four ACCs located at Delhi, Mumbai, Chennai and Kolkata.
In the long term, these four ACCs will be amalgamated into two ACCs.
Additionally, this interface sends flight plan or flight plan updates as input for ATC automation. This
system is known as the NAS Host.
This data is sent to the ATFMS by messages of the following types:
Scheduled Flight Plan (FS)
Purpose: Feeds a scheduled flight into the ATFMS live flight database.
Contents: Time stamp
Source (X)
Message type (FS)
Flight ID
Computer ID
Aircraft type
Cruising speed
Departure airport
Scheduled departure time
Cruising altitude
Flight path
Scheduled time en route
Julian departure date
18
Scheduled Flight Cancellation (RS)
Purpose: Cancels a scheduled flight previously fed into the ATFMS live flight
database.
Contents: Time stamp
Source (X)
Message type (RS)
Flight ID
Computer ID
Departure airport
Destination airport
Julian departure date
Scheduled departure time
Flight Plan (FZ)
Purpose: Transmits the intentions of a flight as filed with the NAS Host.
Contents: Time stamp
Source (facility code)
Message type (FZ)
Flight ID
Computer ID (proposed flights only)
Aircraft type and equipment code
Speed
Coordination fix
Coordination time
Cruising altitude
Flight path
Estimated time en route (ETE) (proposed flights only)
Estimated time of arrival (ETA) (active flights only)
Remarks field
Remarks: May be filed for proposed or active flights. Multiple flight plans may
be filed for the same flight.
19
Amendment (AF)
Purpose: Amends a flight’s intentions that were previously filed with the NAS
Host.
Contents: Time stamp
Source (facility code)
Message type (AF)
Flight ID
Computer ID (proposed flights only)
Departure point
Destination
Which fields to amend
New contents of fields
Remarks: May be filed for proposed or active flights.
Cancellation (RZ)
Purpose: Cancels a flight plan previously filed with the NAS Host.
Contents: Time stamp
Source (facility code)
Message type (RZ)
Flight ID
Computer ID (proposed flights only)
Departure point
Destination
Remarks: May be filed for proposed or active flights.
Departure (DZ)
Purpose: Signifies the activation of a proposed flight.
Contents: Time stamp
Source (facility code)
Message type (DZ)
Flight ID
Computer ID (proposed flights only)
Aircraft type and equipment code
Departure point
Activation time
Destination
ETA
Remarks: None.
ARTCC Boundary Crossing (UZ)
Purpose: Transmits the current flight plan data as sent from the ACC from
which a flight is leaving to the ACC into which the flight is entering.
Contents: Time stamp
Source (facility code)
20
Message type (UZ)
Flight ID
Aircraft type and equipment code
Speed
Boundary crossing point inbound
Calculated inbound boundary crossing time
Altitude
Flight path
Remarks: Flight path field usually specifies only the remainder of the flight’s
path.
Position Update (TZ)
Purpose: Transmits the current position, altitude, and speed of a flight as tracked
by the NAS Host.
Contents: Time stamp
Source (facility code)
Message type (TZ)
Flight ID
Computer ID
Speed
Altitude
Position
Remarks: A position update is generated for each flight at least once each minute.
A single TZ may contain position updates for multiple flights.
Beacon Code (BZ)
Purpose: Identifies a beacon code to be associated with a flight.
Contents: Time stamp
Source (facility code)
Message type (BZ)
Flight ID
Computer ID
Departure point
Destination
Beacon code
Remarks: The beacon code is a 4-digit octal number to be associated with a
flight while it is in the airspace of the ACC identified by the source
facility code.
21
Arrival (AZ)
Purpose: Signifies the termination of an active flight.
Contents: Time stamp
Source (facility code)
Message type (AZ)
Flight ID
Departure point
Destination
Deactivation time
Remarks: None.
Oceanic Position Update (TO) Messages
ATFMS obtains position updates for oceanic flights outside of radar and satellite coverage.
International flights are required to report their positions each time they cross 10 degrees of
longitude. These position updates are sent to ARINC. ATFMS reads the ARINC line and sends
the data to an OMP subsystem that produces TO messages. ATFMS also receives TO messages
from ATOPS. The TO messages are buffered and sent to the Parser. A TO message is
summarized as follows:
Purpose: Transmits speed, altitude, and position of oceanic flights as tracked by
OMP.
Contents: Time stamp
Source (x)
Flight ID
Speed
Time of current report
Altitude
Position
Time of next report
Altitude
Position
Time of next report (usually not given even though position is)
Altitude
Position
Remarks: None
Flight Control Messages
AAI manages airport arrival delay problems by applying different algorithms, or programs, available in
the Flight Schedule Monitor (FSM) tool. Together these programs are used to achieve a desired arrival
rate (AAR) at an airport or FCA by controlling departure times of flights.
22
The types of programs used are:
Ground Delay Program (GDP) – Used to first put an airport GDP into place, to extend the time
range of a GDP, or to modify the AAR or other program parameters for a GDP.
Compression (COMP) – Used to fill open slots in an already issued GDP or AFP.
Blanket (BLKT) – Used to make across the board adjustments of previously issued delays in a
GDP.
Ground Stop (GS) – Used to stop any departures for an arrival airport (not available for an FCA).
When any of these programs are run, FSM generates a number of outputs: the parameters used to compute
the program, the flight-specific control lists, and optionally DAS (FA) delays to be applied to newly
created flights (pop-ups). After a program has been issued, the airlines can adjust the controls for their
flights using flight substitution messages.
Slot List
Purpose: Transmits a controlled departure and arrival time for a flight to an
airline or ATM facility; also transmits control data to the flight
database.
Contents: Flight ID
Arrival Slot
Departure airport
Controlled time of departure time (CTD)
Controlled time of arrival (CTA) at the airport or FCA
Departure ACC
Control type (GDP, COMP, BLKT, GS)
Exempt flag
Cancel flag
Hold flag
Earliest runway time of arrival (ERTA), for a GDP
Initial gate time of departure (IGTD)
Functions
To import all available surveillance system information and to provide this information to support the
calculation of demand data and the display of traffic.
Dependencies
Creation of a Nationalized Mosaic of the surveillance system and the day of flight filed flight plans,
including amended flight plans, which include the route of flight contained in the ICAO flight plan field
15c this system is known as the NAS Host computer.
Technologies
XML
Web services
SOAP
23
SOA
2.2.2.1.5 International Systems Interface
This is a capability that is necessary for integration with the global aviation system
Functions
Increase global awareness of the airspace demand and capacity especially relative for incoming flights to
India and departing flights from India. To implement data exchange with foreign ATFM or ATC systems.
Dependencies
External systems’ interfaces.
Technologies
XML
Web services
SOAP
SOA
2.2.2.1.6 Flight Plan Services
This interface ingests flight schedule from the pre-flight management system, which is responsible for
most flights schedule’s application, examination and approval. It is one of the important flight data
sources for the flight database used by the ATFMS. This schedule data may contain the flight schedules
for up to 6 months in advance. It is also possible to obtain this data from other sources such as the
Official Airline Guide (OAG).
Functions
Obtain flight plans up to six months in the future
Dependencies
Interface with AAI’s pre-flight management system and / or OAG.
Technologies
XML
Web services
SOAP
SOA
2.2.2.1.7 Surface Movement Systems Interface
This interface receives airport aircraft parking stands and off-block time from airport operation control
automation systems. There are many airports in India and all major airports should be involved. The key
benefit of the interface to the ATFMS is better estimation of the Estimated Departure Clearance Time
which in turns leads to better estimation of arrival time and all subsequent times of the trip for a flight.
Functions
To ingest airports parking stand information and off-block time data from all major airports operation
control.
24
Dependencies
All major airports have a surface movement system and an interface to the ATFMS.
Technologies
XML
Web services
SOAP
SOA
2.2.2.1.8 Airlines Operations Center Interface
This interface is responsible for data exchange with airlines and their operational agents. The ATFMS can
receive flight plans directly from airlines. There shall be an independent operational flight plan
management system to examine and approve flight plans and to maintain a complete flight plan database.
This interface will also obtain aircraft registry information from airline dispatch systems. All major civil
airlines shall be involved.
The AOCs will send the ATFMS messages of the following types:
Flight Create (FC)
Purpose: Feeds a new flight into the ATFMS live flight database, or re-instates a
previously cancelled flight.
Contents: Flight ID
Departure airport
Arrival airport
Initial Gatetime for Departure (IGTD)
Aircraft type
Gate departure time
Gate arrival time
Runway departure time (optional)
Runway arrival time (optional)
Earliest runway departure time (optional)
Earliest runway arrival time (optional)
DVRSN remark (optional)
Original flight ID for a diversion recovery flight (optional)
Original IGTD for a diversion recovery flight (optional)
Flight Modify (FM)
Purpose: Modifies data for a previously created flight and can be used to
substitute flights during a GDP.
Contents: Flight ID
Departure airport
Arrival airport
Original gate departure date-time
Aircraft type (optional)
25
Gate departure time (optional)
Gate arrival time (optional)
Runway departure time (optional)
Runway arrival time (optional)
Actual gate departure time (optional)
Actual gate arrival time (optional)
Actual runway departure time (optional)
Actual runway arrival time (optional)
DVRSN remark (optional)
Flight Cancel (FX)
Purpose: Cancels a previously created flight.
Contents: Flight ID
Departure airport
Arrival airport
Original gate departure date-time
Hold flag (optional)
Airline Substitution Messages
When ATFMS issues a ground delay program, the EDCTs for each airline’s flights are sent to that airline.
Individual airlines can then adjust their controlled flights in two ways: by canceling them and by
swapping flights between the arrival slots assigned to the airline. The messages used to adjust controlled
flights are referred to collectively as flight substitution messages.
This section introduces the substitution messages and describes their contents.
With simplified sub (SS) messages, airlines modify their control times using the same message type – FM
– that they use for sending other data updates, and cancel flights using the same message type – FX – as
they normally do. However, when using these messages to substitute flights, the messages are sent using a
different packet type, allowing ATFMS to distinguish “simplified sub” FMs from “regular” FMs. A new
message type, slot create (SC), allows the airlines to assign controls to a previously uncontrolled flight.
Simplified Sub Flight Modify (FM)
Purpose: Assigns a previously controlled flight to a new arrival slot and/or
modifies the control times for that flight.
Contents: Time Stamp
Flight ID
Departure airport
Arrival airport
Original gate departure date-time
Controlled departure time
Controlled arrival time
Arrival slot
Simplified Sub Flight Cancel (FX)
26
Purpose: Cancels a previously controlled flight.
Contents: Time Stamp
Flight ID
Departure airport
Arrival airport
Original gate departure date-time
Hold flag (optional)
Slot Create (SC)
Purpose: Assigns controls to a previously uncontrolled flight.
Contents: Flight ID
Departure airport
Arrival airport
Original gate departure date-time
Controlled departure time
Controlled arrival time
Arrival slot
Slot Credit Substitution (SCS)
If an airline has a flight that can not make its controlled arrival time and the airline can not
substitute any of its other flights into that slot, then by use of the slot credit substitution message
it can offer to yield the slot back to the system in return for a later slot that it can use. AAI may
also submit SCS messages.
Purpose: Yields a slot for a flight in return for a new slot in a given time range.
Contents: Flight ID
Departure airport
Arrival airport
Original gate departure time
Yielded slot
Beginning of requested time range
End of requested time range
Airline Early Intent Messages
Early Intent messages provide a way for airlines to submit preliminary flight planning data directly to
ATFMS, prior to the time when a Flight Plan is formally filed with the NAS Host. Early Intent messages
can be submitted anytime up to 24 hours prior to a flight’s departure, and for traffic planning purposes
will be handled by ATFMS in much the same way that a filed Flight Plan is handled. However, Flight
Plan data filed with the NAS Host and forwarded by the NAS Host to ATFMS will always take
precedence over Early Intent data.
Early Intent (FP)
Purpose: Transmits the intentions of a flight.
Contents: Message type (FP)
27
Flight ID
Aircraft type
Speed
Coordination fix
Coordination time
Cruising altitude
Flight path
Estimated time en route (ETE)
Remarks: Multiple flight plans may be filed for the same flight.
Functions
To accept filed flight plan and amended flight plan messages on the flights’ operational day. The
messages are parsed to update the flight database.
To obtain flight data including ACID and aircraft performance data from the airline dispatch system.
To be able to involve the airline directly in: reroutes; slot substitutions; and cancelations due to ground
stops / ground delay programs.
Dependencies
The airline dispatch system has an interface to the ATFMS.
Communications infrastructure exists to support these data exchanges.
All major airlines are interfaced to the ATFMS.
Technologies
XML
Web services
SOAP
SOA
2.2.2.1.9 Military Operations Interface
This interface is responsible for data exchange with all branches of the Military. The ATFMS will receive
flight plans directly from the military for flights that will traverse civilian airspace.
Functions
To accept filed flight plan and amended flight plan messages on the flights’ operational day. The
messages are parsed to update the flight database.
To obtain flight data including ACID from the Military dispatch systems.
To obtain the status of Special Use Airspace that is not being used by the Military and is available for use
by civilian aircraft.
Dependencies
The Military dispatch systems have an interface to the ATFMS.
The Military will build and maintain a database of Special Use Airspace availability.
28
Communications infrastructure exists to support these data exchanges.
Technologies
XML
Web services
SOAP
SOA
2.2.3 ATFMS Data Items
2.2.3.1 Overview of the ATFMS Data Items
The ATFMS data items element of the ATFMS architecture is responsible for including all of the
information about the various objects in the system. This information describes each of the objects at any
moment in time.
2.2.3.2 Major Data Items
The major data items are the objects that fully describe flights, airspace elements, airports, and, traffic
management initiatives. The ATFMS data item hierarchy is presented as Table 2.
Table 2 - ATFMS Data Item Hierarchy
ATFMS Internal Data Items Data Item Elements
Flight Object Data
Aircraft Information
Flight Plan
Trajectory
Flight Path
Flight Events
Route of Flight
Airspace Feature Crossing Times
Airspace Object Data
Airspace Feature
Type
Name
Geospatial Description
NAVAID Frequency
Airport Object Data
Airport Name
INDIA/AAI Code
Airport Latitude/Longitude/Altitude
Runway Name/Altitude/True Heading
Threshold Latitude/Longitude
ILS Name/Frequency
Airport Stands
29
ATFMS Internal Data Items Data Item Elements
Taxiways
Standard Terminal Arrival Routes (STARs)
Standard Instrument Departures (SIDs)
Current and Forecasted Airport Capacity
Alert Object Data
Current & Forecasted Demand
Current & Forecasted Capacity
Capacity Impact Alerts
Wx Impact Alerts
TMI Object Data
Flight Level Adjustment TMI
Reroute/Fix Balance TMI
Airborne Holding TMI
Metering Sequencing Spacing TMI
GS/GDP TMI
Flow Constrained Areas (FCA)
Flow Evaluation Area (FEA)
Display Object Data
Current and Forecasted:
Airspace/Airport Demand
Airport/Airspace Capacity
Airport/Airspace Delay
Capacity Constraints.
Weather
Airspace Structure
Active and Projected TMIs
Calculated TMI Performance Metrics
These major data items are described in the following sections.
2.2.3.2.1 Flight Object Data Item
There is one flight object for each actual flight. A flight is defined as either a flight that is currently in the
air, scheduled for departure (up to 6 months in the future), or has arrived (up to 24 hours ago). Flight
objects use airspace objects as reference points to their flight path. Flight objects also use airport objects
as their destination point and their departure point. The following data is contained in the Flight Object
Aircraft Information: This data completely describes the aircraft. It contains 2 major subfields with a
total of 6 subfields and a total of 51 characters.
ID: Identification of the aircraft; it is a 7 character field
Airline - 3 letter ICAO carrier code; alphanumeric field
Flight Number - 4 Number carrier flight id code; numeric field
30
Equipment Type: aircraft information; total of 44 characters with 4 subfields
Model - Manufacturer and model number; 3 alphanumeric followed by 3 alphanumeric characters
for a total of 6 characters. For example, BOE777 for Boeing Model 777.
Series - The manufacturer’s series number for a particular type of model such as a BOE757-200;
3 alphanumeric characters in length
Flight Plan: This data completely describes the flight plan. It contains 6 major subfields and a total of 34
characters plus up to an additional 512 characters that describe the route.
Origin: Starting point of the flight; contains the 4 character alphanumeric ICAO code of the
starting airport
Destination: Ending point of the flight; contains the 4 character alphanumeric ICAO code of the
ending airport
Estimated Time of Departure: Time is in Universal Time Coordinated (UTC); consists of 8
alphanumeric characters in 24 hour format HH:MM:SS where HH is hour 0 through 23, MM is
minute 0 through 59 and SS is second 0 through 59.
Estimated Time of Arrival: Time is in Universal Time Coordinated (UTC); consists of 8
alphanumeric characters in 24 hour format HH:MM:SS where HH is hour 0 through 23, MM is
minute 0 through 59 and SS is second 0 through 59.
Route: Actual route is a list of what airway facilities the aircraft will pass through by name;
consists of up to 512 alphanumeric characters.
Waypoints - name of the waypoint; 6 alphanumeric characters.
Centers - name of the center; 6 alphanumeric characters.
Fixes - name of the fix; 6 alphanumeric characters.
Airways - name of the airway; 6 alphanumeric characters.
Sectors - name of the sector; 6 alphanumeric characters.
Status: Status of Flight Plan; 10 character alphabetic field which will be one of the following:
filed – filed not yet flown;
taxi-out – flight has pushed back from gate but not airborne;
taxi-in – flight has landed but not yet at the gate;
in-flight – flight is airborne;
flown – flight has arrived at the gate within the last hour;
not-active – flight has arrived more than an hour ago.
Trajectory: The trajectory is defined as the projected positional values in time (i.e., the projected flight
path). There is one entry per flight object and per position.
Time: Time is in Universal Time Coordinated (UTC); consists of 8 alphanumeric characters in
24hour format HH:MM:SS where HH is hour 0 through 23, MM is minute 0 through 59 and SS is
second 0 through 59.
Latitude: 14 alphanumeric characters in the format ±XX.XXXXXXXXXX.
Longitude: 15 alphanumeric characters in the format ±XXX.XXXXXXXXXX.
31
Air Space Feature: type of air space feature to describe the trajectory; will be one of the
following: waypoint, center, fix, airway, sector, airport it consists of 9 alphanumeric characters.
Type - a three letter alphabetic code to indicate the type of air space feature; will be one of the
following: wpt - waypoint, ctr - center, fix - fix, way - airway, sec - sector, apt - airport
Name - name of the airspace feature; 6 alphanumeric characters.
Altitude: the height of the aircraft above mean sea level measured in meters; 6 numeric
characters in length.
Ground Speed: the speed of the aircraft in kilometers per hour; 4 numeric characters in length.
Heading: direction the aircraft is flying; 3 numeric characters in length.
Flight Path: This data completely describes the actual path of the aircraft. There is one entry per flight
object and actual position. These position updates are based on time but are calculated based on actual
position at a particular time.
Time: Time is in Universal Time Coordinated (UTC); consists of 8 alphanumeric characters in
24hour format HH:MM:SS where HH is hour 0 through 23, MM is minute 0 through 59 and SS is
second 0 through 59.
Latitude: 14 alphanumeric characters in the format ±XX.XXXXXXXXXX
Longitude: 15 alphanumeric characters in the format ±XXX.XXXXXXXXXX
Air Space Feature: type of air space feature to describe the trajectory; will be one of the
following: waypoint, center, fix, airway, sector, airport it consists of 9 alphanumeric characters.
Type - a three letter alphabetic code to indicate the type of air space feature; will be one of the
following: wpt - waypoint, ctr - center, fix - fix, way - airway, sec - sector, apt - airport
Name - name of the airspace feature; 6 alphanumeric characters.
Altitude: the height of the aircraft above mean sea level measured in meters; 6 numeric
characters in length.
Ground Speed: the speed of the aircraft in kilometers per hour; 4 numeric characters in length.
Heading: the direction the aircraft is flying; 3 numeric characters in length.
2.2.3.2.2 Airspace Object Data Item
There is one airspace object per airspace feature. Flight objects use airspace objects as reference points.
The airspace object data consists of the following:
Airspace Feature: The different types of airspace features are: a fix; NAVAID; ACC; sector;
airways – all altitude levels; Special Use Areas.
Type: the type of airspace feature; 6 character alphabetic code as follows: FIX = fix; NAVAID =
NAVAID; ACC = area control center; AIRWAY = airways; SUA = Special Use Area.
Name: name of the airspace feature; 6 alphanumeric characters.
Latitude 1: First, or only point to describe the latitude of the air space feature. If it is a fix or
NAVAID there will only be a Latitude 1. If the air space feature describes a geometric area then
there will be as many as minimally necessary. For example if the area is a rectangle then it will
take 4 latitudes to describe it. The latitude is expressed in decimal format by 10 places after the
32
decimal and a leading sign to indicate north (+) or south (-). Thus, 14 characters are required to
express latitude including sign and decimal point ±XX.XXXXXXXXXX.
Longitude 1: First, or only point to describe the longitude of the air space feature. If it is a fix or
NAVAID there will only be a Longitude 1. If the air space feature describes a geometric area then
there will be as many as minimally necessary. For example if the area is a rectangle then it will
take 4 longitudes to describe it. It is comprised of 15 characters in the format
±XXX.XXXXXXXXXX.
Latitude n: Last, or final point to describe the latitude of the air space feature. If it is a fix or
NAVAID there will only be a Latitude 1. If the air space feature describes a geometric area then
there will be as many as minimally necessary. For example if the area is a rectangle then it will
take 4 latitudes to describe it. It is comprised of 14 alphanumeric characters in the format
±XX.XXXXXXXXXX
Longitude n: Last, or final point to describe the longitude of the air space feature. If it is a fix or
NAVAID there will only be a Longitude 1. If the air space feature describes a geometric area then
there will be as many as minimally necessary. For example if the area is a rectangle then it will
take 4 longitudes to describe it. It is comprised of 15 characters in the format
±XXX.XXXXXXXXXX.
Note: Altitude and Altitude Extent will range from 1 to as many altitudes are needed to describe
the airspace object.
Altitude 1: The low point of the first altitude level needed to describe this air space. The height
of the air space feature above mean sea level measured in meters. It is 6 numeric characters in
length.
Altitude Extent 1: The high point of the first altitude level needed to describe this air space. The
height of the air space feature above mean sea level measured in meters. It is 6 numeric characters
in length.
Altitude n: The low point of the last altitude level needed to describe this air space. The height of
the air space feature e measured in meters. It is 6 numeric characters in length.
Altitude Extent n: The high point of the last altitude level needed to describe this air space. The
height of the air space feature above mean sea level measured in meters. It is 6 numeric characters
in length.
Frequency: The frequency only applies to NAVAIDs and fixes because they are radio beacons.
It is the frequency that the radio beacon transmits on. It is 6 numeric characters in length.
2.2.3.2.3 Airport Object Data Item
There is one airport object per airport. Flight objects use airport objects as departure and arrival points.
The data fully defines the airport and consists of the following information:
Airport:
Full Name: Name of the airport this field consists of 60 alphanumeric characters.
ICAO Code: ICAO code of the airport consists of 4 alphanumeric characters.
INDIA/AAI Code: Used if the airport does not have an ICAO code; consists of 4 alphanumeric
characters.
Latitude: Consists of 14 alphanumeric characters in the format ±XX.XXXXXXXXXX.
33
Longitude: Consists of 15 alphanumeric characters in the format ±XXX.XXXXXXXXXX.
Altitude: The height of the airport above mean sea level measured in meters. It is 6 numeric
characters in length.
Runway Name: The name of the runway, an example is 22R or 22 Right. It is 4 alphanumeric
characters in length.
Threshold Latitude: This is the latitude at the runway threshold. It is 14 alphanumeric characters
in the format ±XX.XXXXXXXXXX.
Threshold Longitude: This is the longitude at the runway threshold it is 15 alphanumeric
characters in the format ±XXX.XXXXXXXXXX.
ILS Name: This is the name of the ILS for the runway. It is 20 alphanumeric characters in length.
ILS Frequency: The frequency that the ILS beacon transmits on. It is 6 numeric characters in
length.
Runway Altitude: The height of the runway threshold above mean sea level measured in meters.
It is 6 numeric characters in length.
Runway True Heading: The true bearing of the runway in degrees. It is 3 numeric characters in
length.
Stands: Description of aircraft stands. It contains: physical location, latitude and longitude;
name; geometric definition of its size.
Taxiways: Description of airport taxiways. It contains: physical location, latitude and longitude;
name; geometric definition of its route and size.
Standard Terminal Arrival Routes (STARs): Description of arrival procedures. It contains:
name; waypoints; latitude and longitude of each waypoint.
Standard Instrument Departures (SIDs): Description of departure procedures. It contains:
name; waypoints; latitude and longitude of each waypoint.
2.2.3.2.4 Alert Object Data Item
This data item consists of:
Current & Forecasted Demand
Current & Forecasted Capacity
Capacity Impact Alerts
Wx Impact Alerts
The current and forecasted demand and capacity is for each and every airspace feature and airport
configuration. The values are based on the number of active aircraft derived from the flight objects and
the flight schedules available from the AIS. The demand for airspace/airport resources is then compared
to available capacity and a capacity impact alert is issued when demand exceeds capacity. Weather
information is also considered in the estimation of the capacity of the airspace and airport resources.
When demand is estimated to exceed capacity due to weather, a weather impact alert is issued. These
alerts are provided to the TMI Service in order to enable the ATFMS to issue appropriate TMIs that will
provide a balance between demand and capacity.
2.2.3.2.5 Traffic Management Initiative Object Data Item
There is one traffic management initiative (TMI) object data item per TMI that has been initiated. If there
are no TMIs in the system then there are no TMI objects. The different types of TMIs include:
34
Flight Level Adjustment TMI
Reroute/Fix Balance TMI
Airborne Holding TMI
Metering Sequencing Spacing TMI
Ground Stop (GS)/Ground Delay Program (GDP) TMI
Flow Constrained Areas (FCA)
Flow Evaluation Area (FEA)
The data fully defines the object and consists of the following information:
Name: 40 alphanumeric characters for a descriptive name of the TMI
Type: 6 alphanumeric characters the types are: GDP - Ground Delay Program; KMIT –
Kilometers in Trail; MIT – Minutes in Trail; FLR – Flight Level Restriction; Reroute/Fix Balance
– RERTE; Metering Sequencing Spacing – METSEQ; Flow Constrained Area – FCA; Flow
Evaluation Area - FEA.
Affected Area: This is the airspace that is affected by a given TMI. It can be a single sector, a
set of sectors, a complete center, custom airspace, an airport, route(s) or a list of any combination
of the airspaces described below.
Airspace:
Sector(s): name of the affected sector(s); 6 alphanumeric characters in length per sector name.
Area(s): name of the affected area(s); 6 alphanumeric characters in length per area name.
Center(s): name of the affected center(s); 6 alphanumeric characters in length per center name.
Custom(s): name of the custom airspace; 6 alphanumeric characters in length per custom name.
Number of Points - needed to define the custom airspace 2 numeric characters.
Latitude 1 - First point to describe the latitude of the air space. There will be as many as
minimally necessary. For example if the area is a rectangle then it will take 4 latitudes to describe
it. It is comprised of 14 alphanumeric characters in the format ±XX.XXXXXXXXXX.
Longitude 1 - First point to describe the longitude of the air space. If the area is a rectangle then it
will take 4 longitudes to describe it. It is comprised of 15 alphanumeric characters in the format
±XXX.XXXXXXXXXX.
Latitude n - Last point to describe the latitude of the air space. There will be as many as
minimally necessary. For example if the area is a rectangle then it will take 4 latitudes to describe
it. It is comprised of 14 alphanumeric characters in the format ±XX.XXXXXXXXXX.
Longitude n - Last point to describe the longitude of the air space. If the area is a rectangle then it
will take 4 longitudes to describe it. It is comprised of 15 alphanumeric characters in the format
±XXX.XXXXXXXXXX.
Altitude 1 - The low point of the first altitude level needed to describe this air space. The height of
the air space feature above mean sea level measured in meters. It is 6 numeric characters in
length.
35
Altitude Extent 1 - The high point of the first altitude level needed to describe this air space. The
height of the air space feature above mean sea level measured in meters. It is 6 numeric characters
in length.
Altitude n - The low point of the last altitude level needed to describe this air space. The height of
the air space feature above mean sea level measured in meters. It is 6 numeric characters in
length.
Altitude Extent n - The high point of the last altitude level needed to describe this air space. The
height of the air space feature above mean sea level measured in meters. It is 6 numeric characters
in length.
Airport(s): name of the affected airport(s); 6 alphanumeric characters in length per airport name.
Route(s): name of the affected route(s); 6 alphanumeric characters in length per route name.
Boundary(s): name of the affected boundary(s); 6 alphanumeric characters in length per
boundary name.
Start Time: Time is in Universal Time Coordinated (UTC) it consists of 8 alphanumeric
characters in 24hour format HH:MM:SS where HH is hour 0 through 23, MM is minute 0
through 59 and SS is second 0 through 59.
End Time: Time is in Universal Time Coordinated (UTC) it consists of 8 alphanumeric
characters in 24hour format HH:MM:SS where HH is hour 0 through 23, MM is minute 0
through 59 and SS is second 0 through 59.
Reason: The reason this TMI was initiated this would include a description of the events that led
up to the implementation of this TMI. This field would be 512 alphanumeric characters.
Signature: The name of the person who is responsible for initiating this TMI. This field is 40
alphabetic characters.
2.2.3.2.6 Display Object Data Item
This data item consists of the following information:
Current and Forecasted:
o Airspace/Airport Demand
o Airport/Airspace Capacity
o Airport/Airspace Delay
o Capacity Constraints.
o Weather
o Airspace Structure
Active and Projected TMIs
Calculated TMI Performance Metrics
The formats of these data will be determined once an appropriate air traffic situation display is selected.
2.2.4 Decision Support Tools (DSTs)
The ATFMS DSTs are defined as those hardware and software elements that assist the ATFM specialist
in the performance of assigned tasks. These tools include the automation that develops the information
needed to make an informed decision and the displays that are used to provide this information to the
ATFM specialist. The ATFMS DSTs have been categorized as follows:
Demand Capacity Imbalance Tools
36
TMI Development/Assessment Tools
Collaborative Decision Making Tools
TMI Implementation Tools
Information Management Tools
Each of these categories of DSTs is described in the following paragraphs.
2.2.4.1 Demand/Capacity Imbalance Tools
Air Traffic Situation Display shall provide:
Airport, facility, airspace, sector, route demand and capacity display.
Weather data including current, forecast, planning with risk assessment, and other decision
support tools.
Airspace status information for conditional, military and non-military use display.
National internet-based operational information system that shall:
Provide air traffic system delay, demand, system planning, and capacity constraints.
Control information sharing depending upon authorization by appropriate authorities.
Airport status information DST shall provide:
Aircraft gate status and availability.
Weather information concerning local and regional conditions.
Delay information affecting stakeholders and air traffic service provider.
Capacity impact information (deicing, convective weather, fog, etc.).
Aircraft taxi queue information and lineup display.
Airport construction impacts (runway, taxiway, and other movement areas).
Runway configuration in use.
Probabilistic future traffic display information shall include:
Display of projected air traffic information based on current information and expected
trajectories.
Airport arrival and departure rate information based on weather, wind, and other predictive
information.
Airport specific demand and capacity balancing tool.
Demand/capacity constraints identification and alert tool (all levels of air traffic facilities).
2.2.4.2 TMI Development/Assessment Tools
Airspace specific traffic information DSTs including:
Air traffic demand and capacity at airports, air traffic facilities, and identified volumes of
airspace, sectors, and routes.
37
Weather data including current, forecast, planning with risk assessment, and other decision
support tools.
Airspace status information for conditional, military, and non-military use.
Current and future capabilities for national, regional, local, and tower specific facility, sector, or
tower demand.
Demand/Capacity identification with information sharing DSTs shall include common shared tools to
identify:
Demand on air traffic system resources (routes, sectors, airports, etc.).
Capacity of air traffic system resources reflected by agreed upon metrics and other impacts
(weather, staffing resources, sectorization, etc.)
Automated and/or reported ground and airborne tactical delay information
Common shared tools allowing all air traffic service providers the ability to identify and share system
delays and display information concerning system constraints to stakeholders.
Stakeholder communication and information tools allowing for direct sharing of issues, concerns, needs,
and expectations by means of:
Advisory/data sharing systems
Intranet/internet including e-mail and web sites
Voice and chat tools for air traffic intra/inter facility and system stakeholder communication, information
sharing, planning, and decision making.
Reroute assignment, availability, assessment demand/capacity information which is coordinated and
shared via common automated tools via:
Advisory/data sharing systems
Intranet/internet including e-mail and web sites
Telecons
Route management and information database with analysis capabilities. DSTs include preferred and
optional routes available for air traffic facility and system stakeholder use.
Traffic replay DST for system, facility, sector, or tower review and assessment of past events and ATFM
actions
The DST shall provide real-time and post-operation assessment of the performance of the ATM
operations.
Assessment shall include weather, demand/capacity information, and data concerning delays and
route usage and modifications.
2.2.4.3 Collaborative Decision Making Tools
Collaboration will involve common information sharing DSTs using dedicated systems, internet
connectivity and telephonic systems, information sharing systems to support:
TMI information and dissemination.
Airport ground status information situation display.
38
En route traffic situation display.
Air traffic information status tools.
National Logging program designed to share information as specified.
Automation based tactical actions request tools to address delays, diversion recovery, special
flights, and other system needs or user requests.
Automation based system status information including information concerning system demand,
delays, weather and other capacity constraints, special use airspace information. Access may be
information layered and privileged based.
Route information allowing for status of current route usage and possible options or changes.
2.2.4.4 TMI Implementation DSTs
Communication and coordination DSTs to identify, describe, modify, and implement actions concerning
ATFM proposals and actions. This process will utilize common informational tools utilizing dedicated
systems, internet connectivity and telephonic systems to provide support at all levels of the AAI team.
Automated advisory system that will provide information concerning ATFM actions, system status, future
plans, and other information as needed.
Web-based system capable of providing status information to reflect current initiatives. The system shall
provide information to all levels of AAI and ATFMS stakeholders as needed and designated.
Utilize automated procedures to update monitor DSTs reflecting initiatives and their impacts. The traffic
management log program shall interact directly with this system reducing communication and
coordination complexity.
Alarm or alerting system designed to monitor initiatives in real time. The system shall notify demand and
capacity and alert personnel to dynamically modify, cancel or extend ATFM actions as needed. The
system shall respond when demand, capacity, system impacts or user feedback justifies action.
2.2.4.5 Information Management DSTs
These DSTs include:
Air traffic replay and analysis system with tower, radar, and non-radar facility data.
Demand and delay analysis airport based tool.
Automated airborne delay analysis tool (holding, vectoring, reroutes).
Automated airborne metering, sequencing, and spacing delay analysis tool.
Air Traffic cause and effect delay reporting system identifying the correlation between:
Who is delayed, for how long, and how many?
What is the impact, cause, actions being taken to mitigate delays?
When did the delays begin and what is their expected duration?
Where are the delays taking place?
Why have the delays occurred?
Efficiency analysis tools (Air traffic and Stakeholder). These shall analyze system delays not just those
identified as air traffic (e.g., construction, maintenance, baggage handling).
39
Centralized data exchange and information database management tools.
Military/Special airspace usage tracking tools
Route analysis and allocation tool (what routes were required, filed, amended).
Airport efficiency and throughput analysis tool.
Demand and delay analysis airport based tool.
40
Section 3. ATFMS Displays and Technology
3.1 ATFM Specialist Displays
3.1.1 Overview of the ATFM specialist Displays
The ATFM Specialist Displays incorporate the data and functions that the system presents to a specialist
to enable human interaction and control over the ATFMS. The goal of this section is to identify the
capabilities that are necessary for ATFM and the dependencies these capabilities have on the remainder of
the ATFMS.
High level drivers for the displays identified in this section include:
Common situational awareness: a foundational goal of collaborative decision making is to provide
common situational awareness between and among all decision makers. Since ATFM at a national level
has so many key stakeholders, it is absolutely necessary to provide some portion of the ATFMS
information, within security and policy limits, to each of these stakeholders to ensure common goals and
intelligent decisions.
Ease of accessibility, maintenance, and support: this system must be available for ATFM specialists
across a wide geographical area. Therefore, many of these displays shall be designed using distributed
technologies that allow the appropriate level of interaction, but with relative ease of deployment and
maintenance across the various facilities in India.
The following description of each of the displays does not entirely answer the question of what
capabilities should exist in any single tool. Although having a single tool can have benefits in
maintenance and training, it may also severely limit the expansion of ATFM capabilities. Many of the
displays and their corresponding functions can be consolidated, but that is a decision that should be made
during the tender process through what is offered by the vendors and what the position of AAI is
regarding various proposals.
The following are the major displays envisioned for India’s ATFMS:
Strategic slot scheduling and flight plan system
Traffic situational display
TMI Modeling, Impact Assessment, and Execution
Operational Performance Monitoring and Assessment
3.1.2 Strategic Slot Scheduling and Flight Plan System
These systems exist to improve flight operations - on time performance, avoid diversions, fuel efficiency,
efficient flight planning.
An efficient slot management system based on the runway capacity shall be available. Slot conformance
monitoring system shall also be implemented.
Preflight briefing services is provided to airlines and pilots to facilitate them with updated information on
airport facilities and other related aeronautical facilities for efficient flight planning and safe conduct of
flight. The service is provided through establishment of ATS reporting office at all operational airports.
The architecture for main Control Centers would essentially include:
Single (centralized) Flight Data Processor (FDP) for the region – enables automated FDP
updates and transfer of control; the management of flight plans within the FIR is centralized
41
Flight plans and data link (Automatic Dependent Surveillance (ADS) / Controller Pilot Data
Link Communications (CPDLC)) from the Main Center
3.1.3 Traffic Situation Display
The Traffic Situation Display (TSD) should be the starting point for any ATFM specialist interaction with
the ATFMS. It is a visual display of current situational status, predicted future demand and congestion,
current TMIs, airspace status, and weather display. The TSD contains so much information, that it may be
appropriate for specialists with different responsibilities to have different displays.
The dependencies for the TSD are extensive, because of its requirement to be the primary display for all
ATFM information. All of the information gathered through the System interfaces, all the Data
substructure, and all the Services should be available through the ATFM specialists’ interface. However,
a distinction should be made regarding demand prediction vs. congestion prediction. It may be more
advantageous for the TSD to provide congestion prediction, so that various displays have the ability to
provide different variations on congestion display. An example of a congestion display is provided in
Figure 11
Figure 11 - Example of Air Traffic Predictive Demand and Congestion Display
3.1.3.1 Types of TSDs
Perhaps the best architecture of a TSD is one that varies depending on the ATFM specialist
responsibilities:
3.1.3.1.1 CCC Specialist TSD
This TSD is a more interactive display with a richer feature set, but it demands more powerful hardware
and higher prerequisites for system software. An example of this is in Figure 12, which depicts a web
browser accessible, Java applet TSD. This TSD could have a rich feature set, connect directly to the
services provided by the ATFMS, and hold a relatively large amount of data locally so that it responds
more quickly to specialist actions.
42
Figure 12 - Java Applet Situational Display
3.1.3.1.2 Remote ATFM specialist TSD
This TSD is a slightly less interactive display with a smaller feature set than the CCC Specialist display,
but the system hardware demands are minimal and the only software prerequisite is a standard browser.
An example of this TSD is in Figure 13 which depicts a web browser TSD. This TSD allows ease of
access with a standard set of features.
43
Figure 13 - Web-Based Situational Display
3.1.3.1.3 Web-Based Text TSD
The final TSD is a purely textual display that allows an ATFM specialist to quickly and simply find the
information. This display would allow low bandwidth connections and provide summary level
information to the specialist. It would be the most advantageous for the remote specialist that quickly
needs to discern system status.
3.1.3.2 Displaying the Data
The TSD displays data in four general forms: graphics drawn on a map, text reports, FEA/FCA time
lines and charts, and ATM System (ATMS) Monitors. The TSD may display data automatically or
only when requested by the user, depending on the data type. The TSD provides four ways for the user
to request data and control the way the data is displayed: menus, dialog boxes, keyboard commands, and
semicolon commands.
The ATFMS also displays data to the user through other User Interface Functions: Delay Manager, Traffic
Management (TM) Shell, Electronic Mail (EMail), and Flight Schedule Monitor (FSM). Delay
Manager displays bar charts and text reports automatically or by request. TM Shell displays text reports by
request. EMail can be used to send and receive text messages. FSM displays the schedule of arrivals or
44
departures for user-specified airports. The user can access any of the user functions using the operating
system desktop environment.
3.1.3.2.1 Maps Database
The TSD displays geographical data graphically on the screen when requested by the user. The TSD
can overlay various geographical data types with each other and with traffic situation, alert, reroute,
FEA/FCA, and weather data. The user can request map overlay displays by using dialog boxes and
keyboard commands. All this is included in the maps database.
The TSD displays geographical data, specified in spherical coordinates (i.e., latitudes and
longitudes), on an essentially flat screen. To do so, the TSD projects the spherical coordinates onto a
plane using a Lambert Azimuthal Equal-Area Projection (LAMP). The LAMP is a conical projection, which
intersects the earth in a circle with a given center point that is called the projection center point. The
LAMP is best suited for showing a large rectangular area with minimal distortion. Therefore, the
LAMP as used by the TSD provides a reasonably small amount of distortion over a large geographic area
around the center point of the projection at the expense of extreme distortion for other parts of the world.
Being an equal-area projection, the LAMP shows geographic areas according to their proper relative
sizes (e.g., a region that looks twice as big as another is really twice as big as the other). The LAMP
shows true directions from the center point.
NOTE: The projected coordinates are used only for displaying the data. The internal representation of the
geographical data used in the flight path processing is in spherical coordinates and does not contain any
distortion.
Users have the option to dynamically re-project the map display around the center point of the display
whenever the display center point is changed (e.g., move command). This option provides a map
display that has minimal distortion regardless of the display center point location anywhere on the surface of
the earth.
The TSD draws map overlays on the display as follows. For elements defined by a point (e.g., NAVAIDS,
fixes, airports), the TSD draws the element icon at the projected latitude and longitude of the element.
Circle icons are used for airports. Triangular icons are used for other elements of this type. The location
identifier (label) is drawn for these elements to the right of the element icon. For elements defined as
an area (e.g., sectors, ACCs, SUAs), the TSD draws the boundaries using solid lines. The TSD draws the
label for this element type at the approximate geographic center of the area. By using a dialog box, the
user can specify icon colors of map overlays and the fonts and sizes of the element labels.
3.1.3.2.2 Traffic Situation Data
The TSD displays traffic situation data graphically on the screen overlaid with geographical,
weather, alert, reroute, and FEA/FCA data as directed by the user, who can turn the data on or off using
a menu or keyboard command. Once the data is turned on, the TSD automatically refreshes the display
with the latest flight positions until the user turns it off. Other menu and dialog box entries, keyboard
commands, and semicolon commands allow the user to control which flights and data are displayed. The
TSD can also replay traffic situation data with alert and weather data up to six hours, as requested by the
user.
ATFMS generates a traffic situation update for the TSD every minute. The update contains an entry for
every flight in the flight database that is currently marked active. Each flight entry includes the flight
ID, aircraft type, equipment code, altitude, speed, heading, beacon code, current and future Required
Vertical Separation Minimum (RVSM) status, fix types, route types, special fields, waypoints, and
estimated position. When a user requests the display of traffic situation data, the TSD automatically
45
updates the display according to parameters selected by the user. These parameters control which
flights are displayed, the color and icon used to draw them, and the data displayed for those flights.
The TSD shows a flight on the display by drawing an icon at its estimated position. The user can select the
flight icon shape and color used by the TSD. The user has a choice of three icons: dot, airplane, or
automatic. When the dot is selected, the TSD uses the dot icon unless the zoom scale is less than 850,
in which case the TSD uses the airplane icon. When the airplane is selected, the TSD uses an icon shaped
to resemble a jet aircraft at all zoom scales. When the automatic icon is selected, the TSD shows the
flight as a wedge-shaped airplane icon for heavy aircraft or a straight-winged airplane icon for the prop
aircraft type. Otherwise, the TSD shows the flight using the airplane icon. When the TSD draws the
aircraft icons, the icons point in the approximate directions that the flights are heading.
The TSD will alter the user-selected icon shape under three conditions. A flight designated in the Flight
DataBase (FDB) as holding appears on the display as a racetrack icon. (The holding designation may
have been entered into the flight plan when filed or by an airborne control, or may have been
detected by the FDB from the flow of position reports.) A flight designated as ghosting, which is further
described in subsequent paragraphs, appears as a hollow (outlined) icon instead of a solid (filled) icon. A
flight that has landed appears on the display as a circle icon.
Flights that are RVSM non-conformant, or are predicted to become non-conformant, are shown with a
square box drawn around them. This highlighting may be disabled.
In addition to the icon, the flight may be drawn to show other data. For instance, a data block that
contains the flight ID, speed, altitude, aircraft type, equipment code, and minutes to destination may
be shown for each flight. The data block may contain the beacon code and it may also contain the origin
and destination or the route data. The flight may be drawn showing its route, last reported position,
and/or the history of previous flight positions. By using a dialog box, the user may specify the font and
size of the data block. The data block is drawn above and to the right of the flight icon; however, the user
may drag the data block to a new location relative to the flight icon to make it easier to read.
The flight may also be drawn to indicate its RVSM status and conformance with rerouting initiatives.
If the user chooses to have the TSD draw the RVSM non-conformance indicators for flights, the TSD draws
a square around any flight icons, currently being displayed, that ATFMS predicts will be RVSM non-
conformant at anytime during the future of the flight. If the user chooses to draw flights using the
Reroute Monitor function, the TSD will draw all flights in the reroute(s) being monitored and it will draw
a square around the flight icon if the flight is predicted to be non-conformant with the rerouting
initiative.
The TSD provides the user with multiple ways to control how flights are drawn. Except for the icon shape
and color, the display characteristics of all flights may be changed at once (e.g., all data blocks must be
displayed). The user may also specify display characteristics for individual flight sets or individual flights.
ATFMS estimates flight positions used by the TSD because the traffic situation data updates received from
the ATMS are not synchronized. Although ATFMS receives an update of the traffic situation data for
each flight typically every minute, these updates are not all received at the same time. Therefore, to
provide a more consistent display, ATFMS estimates the positions for all the flights at the same instant
in time when it generates the display update.
ATFMS estimates flight positions in a straightforward manner. The time over which the flight must be
extrapolated is the time of the update minus the time of the last position report. The difference (or delta
time) is used with the last reported speed and heading to compute the deltas in latitude and longitude.
The deltas are applied to the last reported latitude and longitude to produce the estimated position.
A danger in extrapolating aircraft positions is that if ATFMS were to stop receiving position updates
for a flight, the flight would appear to continue to move with each TSD update. Because the estimated
46
position for that flight would not have the same accuracy as positions estimated for flights with position
updates, ATFMS checks the last position update time when generating the update file. If a position
update is not received for more than seven minutes, a flag is set in the update file indicating that the
flight is ghosting. The TSD draws ghost aircraft on the display in outline form, rather than as solid
aircraft. The user can visually distinguish the more accurate positions from those that might be less
accurate.
When the user selects a flight subset (e.g., flights arriving at VIDP) for display, the TSD scans the flight
data in the traffic situation update to determine which flights meet the selection criteria. Included in the
selection criteria are some flight data that can be displayed (aircraft type, origin, destination, and altitude)
and some data that cannot be displayed (sectors, fixes, ACCs, or airways traversed). ATFMS includes
these additional data items in the updates for this purpose and extracts them from the event list
produced during the flight modeling.
The TSD displays old data by using ATFMS traffic situation updates that are stored on the file server. The
TSD retrieves updates specified by the user and replays them at a rate specified by the user. The display
of old flight data looks exactly like live flight data and can be controlled the same ways as live data.
Weather and Monitor Alert data can be replayed with the traffic data. Using a VCR-like control panel, the
user can pause, resume, single step forward or backward, or replay forward or backward as desired.
3.1.3.2.3 Monitor Alert Displays
The TSD displays alerts graphically on the screen with geographical, weather, reroute, FEA/FCA, and
traffic situation data as directed by the user, who can turn the alert display on or off using a menu option or
keyboard command. Once the alert display is turned on, the TSD automatically refreshes the display every
minute with the latest alerts until the user turns it off. Dialog box entries and semicolon commands allow
the user to control what alerts are displayed and request other Monitor Alert data.
The TSD draws alerts on the display as icons. The shape of the icon indicates the alert type: circles for
airports, triangles for fixes, and hatching within sector boundaries for sectors. The color of the alert
icon indicates the alert status. The direction of the hatching of sectors indicates the altitude level at which
a sector is alerted and if the sector is RVSM alerted. A short line(s) extending to the left from the triangle
indicates the altitude level(s) at which a fix is alerted. A line at the bottom of the triangle indicates that
the low level fix is alerted. A line from the middle of the triangle indicates that the high level fix is
alerted. A line from the top of the triangle indicates that the super-high level fix is alerted. If the
projected active traffic demand exceeds the alert threshold, the TSD displays new alerts in red. If the
proposed and/or scheduled demands exceed the threshold, the TSD draws a yellow alert icon. If the sector
is RVSM alerted and the display of RVSM alerts is selected, the TSD draws those sectors in blue if
they would not otherwise be drawn in red or yellow.
The alert icons that are drawn on the display represent the highest alert level for the element during the time
period (time limit) specified by the user. The time limit may be specified in quarter-hour increments from
0.25 to 6.0 hours.
Additionally, the TSD optionally provides sector alerts of RVSM non-conformant flights. Currently, the alert
threshold for non-conformant flights is set to one.
The TSD provides alert data beyond icons. For individual elements, the user can examine which 15-
minute intervals are alerted using a time line display in a ATMS Monitor, a bar chart of projected
traffic demands and alert thresholds, a flight list report of traffic at the alerted element, and current
flight positions that compose the traffic for a specified interval. The TSD draws the flight positions
directly on the map overlay. The ATMS Monitor, bar chart, and reports are displayed in separate
windows. These ATMS Monitor, charts, and reports also may indicate counts of RVSM non-conformant
47
flights. The TSD also allows the user to examine the same information for non-alerted elements,
which appear in magenta on the display. For sectors, the user can display a Time in Sector chart that
graphically depicts the flights that cross the sector during any 15-minute period up to six hours in the
future.
The TSD shows the alert status for multiple ATMS elements in ATMS Monitor displays where each
row in the monitor displays the alert status of one ATMS element for each 15-minute period up to 6
hours in the future. Each ATMS Monitor can be customized to display the alert status for selected
ATMS elements (airports, fixes, and sectors). The ATMS Monitor also may display counts of RVSM
non-conformant flights. The System Summary monitor displays a summary of the alert status of all
sectors in selected centers. These monitors and the Time in Sector chart are displayed in separate
windows that may be moved into a different workspace from the TSD display.
Authorized users can turn specific intervals of the time line green, indicating that they are resolving
the alert. Intervals that have been turned to green also have a red or yellow horizontal stripe, which
indicates that they had been alerted. If all intervals on the time line are green, the alert icon on the TSD
also turns green. The user who turns an interval green will see the effects immediately while users at the
other sites will see the effects after the next Monitor Alert update.
Generally, the TSD gets the data for the bar chart, ATM System Monitor and System Summary displays
from the alerts update. This update contains the data for all alerted elements and for specified
airports and sectors whether they are alerted or not. However, if the alert update does not contain the
data for the examined element, the TSD gets the data from the Traffic Demand Database (TDB).
The TSD gets the data for the list report, flight positions, and the Time in Sector chart from the
traffic demand and flight databases. Because ATFMS generates the alert updates every minute, while it
updates the databases continuously, it is possible to see inconsistencies between the time line/bar chart and
the report/flight positions. It is also possible to see inconsistencies between a report, the flight
positions and the Time in Sector chart because ATFMS may retrieve the data for these displays at
different times.
3.1.3.2.4 Request Reports
ATFMS produces request reports when requested by a user through the TSD or the TM Shell. Using the
TSD, the user can enter a request by the semicolon method. After making a request, the user can
continue to perform other TSD functions. When ATFMS is finished generating the report, the TSD
notifies the user by displaying a Report Notification dialog box. The user can view the report in a
separate window that appears on top of the TSD display. The TSD continues to show the map overlay,
update the display of traffic situation data, and interact with the user in the original window. In addition to
quickly requesting a report using the TM Shell, the user can control the TM Shell, the TSD, and other
user functions independently in separate windows.
The user can request reports containing flight data for a specified airport, fix, sector, FEA/FCA, or
ACC. The ATFMS processing of a report request consists of two steps: retrieving the data and
generating the report. When requested data for an airport, fix, sector, or ACC falls within the previous 12
hours or next 24 hours, ATFMS retrieves the requested data from the live traffic demand and flight
databases. Therefore, within the current 36-hour window, the user can see up-to-date flight data derived
from airline schedules, ATMS messages, EDCT messages, flight modeling, and the traffic demand
processing. However, because the reports are derived from the TDB, the user can see reports only for those
airports, sectors, and fixes that are defined as monitored.
Reports for arrival and departure fixes are processed differently from other reports because the arrival and
departure fixes are not monitored elements in the traffic database. ATFMS generates data for an arrival
or departure fix by first retrieving the flights that are arriving at or departing from the airport
48
associated with the specified fix. Then ATFMS examines each flight to determine which arrival or
departure fix it uses. Only those flights that use the requested arrival or departure fix are used to
generate the requested report.
Reports for FEA/FCAs are processed differently than reports for ATMS elements because Flow
Evaluation Areas and Flow Constrained Areas are not monitored elements in the traffic database. When a
report for an FEA/FCA is requested, ATFMS determines the flights that are predicted to intersect the
FEA/FCA during the specified time period using the current data that is contained in the live flight
database. The data for those flights are used to generate the requested report.
When the requested data is outside the current 36-hour window, ATFMS retrieves the data from the flight
schedule database; therefore, the user can see only the static values contained there. Because the flight
schedules do not contain the flight event lists that the live flight database contains, the user cannot obtain
sector and fix reports for flights outside the current 36-hour window.
Once the flight data is retrieved, ATFMS formats, sorts, and counts the data as requested by the user. The
following types of reports may be requested:
Flight list (LIST) - The user can view a list of flights and associated information and can specify
the data items to be shown in the report and how to sort the report.
Flight counts (COUNT) - The user can view a count of the number of flights departing from, arriving
at, or traversing an airport, fix, sector, FEA/FCA, or ACC and can specify the criteria for
counting the flights (e.g., count by airline).
Arrival delay prediction (ARRD) - The user uses this report to assess potential traffic congestion at
airports.
Fix loading (FIXL) - The user can view a count of the number of flights traversing a specified
arrival or departure fix or all arrival or departure fixes for a specified airport.
Verify time (VT) - The user can observe discrepancies between the actual flight arrival and
departure times and a specified time type (e.g., controlled time). The user can specify the flights,
time type, and report format.
List flight plan (LIFP) - The user can view lists of flight plans for selected aircraft.
List sector flight counts (AREA) – The user can request a report to display the number of flights
traversing a specified sector or multiple sectors.
Display FCA/FEA reports (FCATA) – The user can request the Count and List FCA reports using the
semicolon method.
Flight list original (LISTO) - The user can view a list of flights and associated information as in a
flight list (LIST), except that original times are displayed instead of controlled times for controlled
flights that have not departed.
Flight lists and counts may be filtered by RVSM conformance.
3.1.3.2.5 Weather Displays
The TSD displays weather graphically on the screen with geographical, traffic situation, reroute, FEA/FCA,
and alert data as directed by the user, who can turn the weather display on and off using a menu option,
keyboard commands, or a semicolon command. The user can use a dialog box, keyboard commands, or
semicolon commands to control which types of weather data are shown. Once the weather is turned on,
the TSD automatically refreshes the display when a new data update is received until the user turns it
off.
49
The TSD displays radar-determined precipitation data using a six-level color-coded solid overlay, drawn
below the other map elements so that they are still visible. The user can control which precipitation
levels are displayed by specifying the lowest level that is to be drawn.
The TSD can draw other weather overlays, including Jet Stream, Echo Tops, Lightning, Convective weather
forecasts, Fog forecasts, etc. The TSD displays jet stream winds of 70 knots or greater using an overlay
that shows the direction, speed, and altitude of these winds. The jet stream is shown using streamlines
that are drawn using solid lines in a color specified by the user. The arrows on the streamlines indicate the
direction of the jet stream.
The TSD displays the location of lightning strikes by drawing cross hairs at these locations. The user may
specify the color of these cross hairs. The TSD can also display historical lightning data using different
colors for each data update time. The TSD displays a Radar Tops overlay that shows the altitude of the
cloud tops in precipitation areas. The TSD displays the convective weather forecasts using polygons to
depict the one-hour forecast of the location of currently existing thunderstorms. Each polygon is
accompanied by an arrow and a number that indicate the storm’s current direction of motion and speed, in
knots. The user can control which forecast product is to be displayed by selecting the hourly or
hourly ranged forecast products.
ATFMS produces weather and Runway Visual Range (RVR) reports when requested by the user through
the TSD using a menu entry or semicolon command. When the METAR and TAF reports are received,
they are combined into a single report that is displayed in a separate window on top of the TSD display.
RVR reports are also displayed in a separate window on the TSD display.
ATFMS maintains a full set of the METAR/TAF data. When a user requests the weather reports for a
particular airport, ATFMS retrieves the most current terminal forecast and surface observations
received for that airport and format a report using standard weather terminology.
3.1.3.2.6 Reroute Displays
The TSD provides users with the ability to define and display reroutes for avoiding severe weather
conditions. These reroutes are stored in a distributed database so that they may be shared with other
ATFMS users. There are three types of reroutes: public, local, and private. Severe weather specialists
at the ACC typically create public reroutes that are shared with all ATFMS users. Users at ATFMS
field sites may create local reroutes and share them with other ATFMS users within their facility. Any user
may create private reroutes for viewing on their workstation. When the user turns on the display of
reroutes, the TSD display refreshes automatically to show the latest reroutes and new updates as they
are received.
The TSD provides users with the ability to query a database of Playbook reroutes. The user can thus tailor
the Playbook reroute as desired to define the rerouting necessary to avoid severe weather.
The TSD also provides users with the ability to query a database of Coded Departure Routes (CDR) that can
be used to define reroutes. Coded Departure Routes are standard routes to be used for flights between
designated origin and destination airports. The CDR database is maintained on a database at the CCC
and is updated every cycle.
The TSD also provides users with the ability to monitor the flights involved in a public reroute and
get periodic updates of these flight lists. Users can see which flights are affected by the rerouting
initiative, along with an indication of which flights have filed flight plans that comply with the reroute and
which have not. Authorized users can grant exceptions to individual flights and exempt them from the
reroute. The airlines can view a periodically updated list of their flights that are affected by the
rerouting initiative via the CCSD.
50
3.1.3.2.7 Display Data Sources
Table 3 summarizes sources for the ATFMS display data types. ATFMS uses several databases to
provide the data displays.
Geographical Data - When a user requests the display of a map overlay, the ATFMS accesses the data
directly from either the workstation’s memory and disk or the site’s file server. For static overlays, the
ATFMS accesses the Map Overlay Database that is stored on the workstation’s disk. This database
consists of a set of files that are cyclically updated. For sectors whose shapes have dynamically changed
(see Section 3.3) from the baseline shape defined in the Map Overlay Database, ATFMS maintains a
dynamic sectorization database on the file server at each site. ATFMS uses this data to display the overlays
for sectors that are not in their baseline shape.
Traffic Situation Data - The ATFMS maintains a flight database for currently active flights on the file
server at each site. Every minute, the file server generates a traffic situation data update, which is stored
in files on the file server’s disk.
Monitor Alert Displays - The TSD accesses Monitor Alert data from the file server and the Hubsite.
The TSD gets report, alert flight data, and Time in Sector chart data from the TDB at the Hubsite and the flight
database on the file server. Upon request from the TSD, the List Server requests (from the TDB) the IDs of
the flights that belong in the report or alerted flight display, and then sends a request to the flight
database for other flight data to generate the displays. If a report has been requested, the List Server
returns a formatted report to the TSD. Otherwise the List Server returns the flight data to the TSD. The
ATFMS maintains the alert threshold (i.e., MAP) data in the TDB at the Hubsite.
Request Reports - The List Server gets request report data in various ways, depending on the time range of
the data requested and the type of request. For requests pertaining to monitored ATMS elements (non-
FEA/FCA), where part or all of the time range is within +24 or -12 hours of the current time, List Server
first gets flight IDs from the TDB at the Hubsite and then gets other data for flights from the flights
database on the file server. List Server gets data from the airline schedule database for remaining
flights that are not in the TDB. For requests where the entire time range is beyond 24 hours of the
current time, List Server gets data from the airline schedule database at the Hubsite.
Two types of requests allow the user to specify the data source. For Hubsite requests, the flights database at
the Hubsite (rather than the flights database on the file server) is used to retrieve other data for the
flights retrieved from the TDB. For schedule database requests, List Server gets all report data from the
flight schedule database regardless of the time range requested.
NOTE: The data available in a request report is dependent on the data source. Flights accessed from the
flight schedule database will not have any ATFMS message data (e.g., proposed times, actual times, etc.).
Traffic Management Reports - The TSD gets traffic management reports from the EDCT database and from
the TDB.
Weather Displays - Weather display data is accessed from the weather database maintained on the file
server at each site.
Reroute Displays - The TSD gets reroute data from the Reroute database. ATFMS maintains a reroute
database on the file server at each site. Whenever this database is updated, the TSD is notified of the change
and the TSD then updates its display of reroutes.
Playbook and CDR Data – The TSD gets Playbook and CDR data from a database that is maintained at
the CCC. The TSD retrieves this data by sending a request to the Routing Database Proxy Server
(RDPS). The RDPS then queries the Oracle database at the CCC and forwards the query results to
the TSD.
51
Reroute Flight List Data – There are two sources of reroute flight list data. Upon request from the user
when creating a reroute, the TSD receives the list of flights that ATFMS predicts will be affected by the
proposed rerouting plan from the List Maker. The List Maker uses the rerouting plan to formulate a
sequence of requests to List Server. The List Maker formats the reports that are returned by List Server
into a single report that is returned to the TSD. Once a public reroute has been created, the Reroute
Monitor Process at the hubsite periodically generates a list of the flights that are affected by the reroute
and this list is distributed to the reroute database at all sites. Whenever this database is updated, the
TSD is notified of the change and the TSD then updates its display of reroute flight lists.
52
3.1.4 TMI Modeling, Impact Assessment, and Execution
TMI Modeling, Impact Assessment, and Execution can be considered the most critical element of the
entire ATFMS since it is the method in which the ATFM specialist can change the operational status.
There are really two parts to working with TMIs: the modeling and assessment; and, the execution.
The modeling and assessment must provide the ATFM specialist the ability to model different scenarios
and their impacts upon the system. For example, during a Ground Delay Program (GDP), it is essential to
visualize the before and after effect of the GDP, as in Figure 14. For each bar in the chart the left side
indicates the demand before the GDP and the right side the demand after the GDP. This allows the ATFM
specialist to quickly discern if the program will have the desired affect and achieve the appropriate rate. If
the ATFM specialist does not see the desired results, then the specialist can remodel the program with
different parameters prior to submitting the program through the operational system. This technique
greatly reduces operational error.
Figure 14 - Before and After Effect of a Modeled GDP
The execution is critical, because a TMI will not be successful without the appropriate distribution and
notification of the entire ATFM community. From air traffic controllers to airline dispatchers to air traffic
flow managers to airport ATFM specialists, there are many parties involved in the execution of a national
level TMI. Therefore, the appropriate notification is absolutely mandatory. Some notifications may
include actual reroutes through the automation to ATC, some notifications may be imposed ground delays
to the airlines, and some notifications will simply be an advisory that is posted for all to see.
3.1.4.1 Displaying Ground Stops and Ground Delay Programs
The FSM display offers several different operating modes and alternative displays. The various modes
allow for the monitoring of data in both live and historical modes and the modeling and/or issuing of
various TMIs.
53
3.1.4.1.1 FSM Display
The key FSM displays are the Control Panel, Open Data Set, Time Line, Bar Graph, Flight List, and Map
components. Each display offers a number of different coloring schemes to illustrate various data.
The Control Panel component allows a user to access all other FSM components for displaying,
monitoring, and managing traffic flow at any airport. The Control Panel consists of a menu bar and six
buttons. The menu items and buttons are enabled or disabled depending on the type of data set (Monitored
Live, Historical, and Ground Delay Tools (GDT)) the user views. When the user opens an airport, FCA,
FEA, or creates a User Defined Group (UDG) an associated button appears just above the Connected
Servers information. This allows the user easy access to information about the airport, FCA, FEA or UDG
if the user is monitoring several elements at once.
The Open Data Set component allows you to choose an FSM data mode and data set for monitoring and
managing air traffic flow. A data mode is the type of data you want to use: historical or live. A data set is
the airport, FEA, FCA or UDG and the components which you would like to display.
The Time Line displays individual flights and places them on a minute-by-minute timeline. Various
coloring schemes can then be applied to the flights to present various information in a visual manner.
Furthermore, the Time Line presents slots open due to canceled or delayed flights, or because a GDP with
a GAAP delay assignment has created unassigned slots to handle pop-up traffic. The slots open due to
cancellation are shown as squares, slots open due to delays are shown as triangles, and unassigned slots in
a GDP with a GAAP delay assignment are shown as white diamonds.
The Bar Graph displays cumulative demand as compared to capacity in various time frames (15, 30, and
60 minutes). Like the Time Line, various coloring schemes can be applied to present various data.
The Flight List displays a tabular listing of data for various subsets of flights. Various data elements can
be displayed, sorted, and organized in various ways. The Flight List is also accessible via a query function
which allows for user-defined flight lists to be created. All flight lists are based on data contained in the
ADL.
The Flight Information display provides two levels of flight information. The normal Flight Information
display provides key data elements for quick review. A flight details display is also available which
shows all ADL data elements for a specific flight.
The Map displays India with an overlay of all area control centers and an outline of the states,. Airports,
FEAs, and FCAs currently being monitored by appear. For airports a four-letter identifier (ICAO) and a
colored dot indicating the status of each airport appear on the map. For FEAs and FCAs, the map displays
colored lateral bounds, the color indicates the status of the FEA or FCA.
A key aspect of the FSM display is the connection between the various components. Each display
component is linked to other components, allowing them to be combined in a variety of ways. For
example, a user can click a Bar Graph segment to produce a flight list of the individual flights that make
up that segment. Then when the flight list first appears, a specific flight can be selected and the flight
details displayed.
3.1.4.1.2 Historical versus Live Mode
Users can switch the FSM display between two modes when displaying data; Live data and Historical
data. When in Historical mode, FSM is able to replay data previously collected and placed in a historical
data file. Historical mode allows for the review of TFM activities, training using saved scenarios, and
remodeling of alternative initiatives. When in Live mode, FSM displays data as received. Live data mode
is the most commonly used display.
54
3.1.4.1.3 Monitored Mode versus Ground Delay Tools Mode
Within both Historical and Live data modes, users can select either Monitored Live or Ground Delay
Tools (GDT) mode. When in Monitored Live mode, the user is able to display demand data using various
presentation schemes. If a user needs to model or issue any TMI, then GDT mode is selected. When
selecting GDT mode, the FSM client takes a snapshot of the currently displayed traffic demand data. That
snapshot is then used as a base, against which various algorithms are run.
3.1.4.1.4 GDP Modeling
The FSM DST is able to model and then transmit several different types of TMIs used to manage airport
demand. A key aspect of FSM-generated GDP events is the concept of Ration-by-Schedule (RBS). RBS
is a process to ration airport capacity of NAS used, based on the airport's original schedule. RBS allocates
airport capacity among NAS users based on their original schedule, including the assignment of capacity
to cancelled flights. The Ration-by-Schedule process is designed to ensure that users are not penalized for
having submitted schedule data or having provided cancellation information. RBS++ is the combination
of the RBS and Compressions processes.
Additionally, FSM is able to model but not issue a number of actions, which can be taken by system
users. These are typically used by airlines to determine their best course of action during a GDP:
Substitutions
Canceling Flights
Delaying Flights.
The various algorithms are summarized and details presented separately in the appendix of this manual.
3.1.4.1.5 Compression Algorithm (“Prioritize Member”)
The Compression algorithm is a process to reassign a slot among NAS users. Compression reassigns
airport capacity among NAS users to ensure that as much of the airport capacity that is available is used.
Compression fills unassigned slots (GAAP GDP only) and/or open slots that have been created by
cancelled or delayed flights. Open slots created by cancelled flights are shifted based on the current
projected arrival time of the delayed flights. The cancelled flights are in general moved to the end of the
delayed period. All slots, excluding Unassigned Slots, between the start and end time of the Ground
Delay initiative are eligible for Compression with the exception of pop-ups which receive a FA Control
Type. Compression is similar to the airline substitution process but is able to use all flights to fill the
available demand.
3.1.4.1.6 Intra-Airline Compression
Intra-Airline Compression is the process by which slots are reassigned within the flights of a
single major carrier to ensure complete usage of available capacity. The process fills open
capacity due to cancelled or delayed flights. If it is not possible to fill the open capacity with the
flight of the major carrier to which the slot was originally assigned, then the Inter-Airline
compression process will use a flight of other NAS users to fill that open slot.
3.1.4.1.7 Inter-Airline Compression
Inter-Airline Compression is the process by which slots are reassigned among all NAS users to
ensure complete usage of available capacity. This process reassigns slots to all NAS users when
55
the carrier to which the open capacity was originally assigned is unable to make use of it. The
concept of slot ownership is never lost.
3.1.4.1.8 Compress Flight
The Compress Flight algorithm is called from the Inter-Airline Compression algorithm to
facilitate the process of reassigning open slots and/or unassigned slots to all NAS users. The
Compress Flight algorithm finds the first eligible flight to swap with the open slot or unassigned
slot and then calls the Move Up a Flight algorithm.
3.1.4.1.9 Move Up a Flight
The Move Up a Flight algorithm is called directly from the Inter-Airline Compression Algorithm
and from the Compress Flight algorithm. Move Up a Flight swaps slot IDs between the flight and
the open slot or unassigned slot, in the process moving up the flight and moving back the slot.
3.1.4.1.10 Blanket (+/- Delay) Algorithm
The Blanket (formally known as +/- Delay) algorithm allows for the blanket reduction or increase
of assigned delays within a specific time period for arrivals. Arrivals are determined based on
their current projected arrival time. Adding or subtracting a set amount of delay minutes from
each flight can make the delay adjustment.
3.1.4.1.11 Ground Stop Algorithm
The Ground Stop algorithm allows the holding of all flights on the ground that are projected to
depart within a specified time period. Stopped flights are determined by their current projected
departure time.
3.1.4.2 Flight Level/ Altitude Adjustment TMI
The display will automatically be limited to affected sectors, fixes, and airports. This TMI will display
future sector, fix, airport alerts in what time period the user requests. These can be requested in 15 minute
increments for up to six hours in the future. The TSD will prominently indicate that this is a future view
and how far into the future. Demand / Capacity bar charts are also capable of being displayed that will
show future sector loadings. The Bar Graph displays cumulative demand as compared to capacity in
various time frames (15, 30, and 60 minutes). Various coloring schemes can be applied to present various
data.
The TSD draws alerts on the display as icons. The shape of the icon indicates the alert type: circles for
airports, triangles for fixes, and hatching within sector boundaries for sectors. The color of the alert
icon indicates the alert status. The direction of the hatching of sectors indicates the altitude level at which
a sector is alerted and if the sector is RVSM alerted. A short line(s) extending to the left from the triangle
indicates the altitude level(s) at which a fix is alerted. A line at the bottom of the triangle indicates that
the low level fix is alerted. A line from the middle of the triangle indicates that the high level fix is
alerted. A line from the top of the triangle indicates that the super-high level fix is alerted. If the
projected active traffic demand exceeds the alert threshold, the TSD displays new alerts in red. If the
proposed and/or scheduled demands exceed the threshold, the TSD draws a yellow alert icon. If the sector
is RVSM alerted and the display of RVSM alerts is selected, the TSD draws those sectors in blue if
they would not otherwise be drawn in red or yellow.
56
The alert icons that are drawn on the display represent the highest alert level for the element during the time
period (time limit) specified by the user. The time limit may be specified in quarter-hour increments from
0.25 to 6.0 hours.
3.1.4.3 In-trail Spacing TMI
The display will automatically be limited to affected sectors, fixes, and airports. This TMI will display
future sector, fix, airport alerts in what time period the user requests. These can be requested in 15 minute
increments for up to six hours in the future. The TSD will prominently indicate that this is a future view
and how far into the future. Demand / Capacity bar charts are also capable of being displayed that will
show future sector loadings. The Bar Graph displays cumulative demand as compared to capacity in
various time frames (15, 30, and 60 minutes). Various coloring schemes can be applied to present various
data.
The TSD draws alerts on the display as icons. The shape of the icon indicates the alert type: circles for
airports, triangles for fixes, and hatching within sector boundaries for sectors. The color of the alert
icon indicates the alert status. The direction of the hatching of sectors indicates the altitude level at which
a sector is alerted and if the sector is RVSM alerted. A short line(s) extending to the left from the triangle
indicates the altitude level(s) at which a fix is alerted. A line at the bottom of the triangle indicates that
the low level fix is alerted. A line from the middle of the triangle indicates that the high level fix is
alerted. A line from the top of the triangle indicates that the super-high level fix is alerted. If the
projected active traffic demand exceeds the alert threshold, the TSD displays new alerts in red. If the
proposed and/or scheduled demands exceed the threshold, the TSD draws a yellow alert icon. If the sector
is RVSM alerted and the display of RVSM alerts is selected, the TSD draws those sectors in blue if
they would not otherwise be drawn in red or yellow.
The alert icons that are drawn on the display represent the highest alert level for the element during the time
period (time limit) specified by the user. The time limit may be specified in quarter-hour increments from
0.25 to 6.0 hours.
3.1.4.4 Reroutes TMI
The display will automatically be limited to affected routes, sectors, and airports. This TMI will display
future route, sector, airport alerts in what time period the user requests. These can be requested in 15
minute increments for up to six hours in the future. The TSD will prominently indicate that this is a future
view and how far into the future. Demand / Capacity bar charts are also capable of being displayed that
will show future route (for the affected routes) and / or sector loadings. The Bar Graph displays
cumulative demand as compared to capacity in various time frames (15, 30, and 60 minutes). Various
coloring schemes can be applied to present various data.
The TSD draws alerts on the display as icons. The shape of the icon indicates the alert type: circles for
airports, triangles for fixes, and hatching within sector boundaries for sectors. The color of the alert
icon indicates the alert status. The direction of the hatching of sectors indicates the altitude level at which
a sector is alerted and if the sector is RVSM alerted. A short line(s) extending to the left from the triangle
indicates the altitude level(s) at which a fix is alerted. A line at the bottom of the triangle indicates that
the low level fix is alerted. A line from the middle of the triangle indicates that the high level fix is
alerted. A line from the top of the triangle indicates that the super-high level fix is alerted. If the
projected active traffic demand exceeds the alert threshold, the TSD displays new alerts in red. If the
57
proposed and/or scheduled demands exceed the threshold, the TSD draws a yellow alert icon. If the sector
is RVSM alerted and the display of RVSM alerts is selected, the TSD draws those sectors in blue if
they would not otherwise be drawn in red or yellow.
The alert icons that are drawn on the display represent the highest alert level for the element during the time
period (time limit) specified by the user. The time limit may be specified in quarter-hour increments from
0.25 to 6.0 hours.
3.1.4.5 Fix Balancing TMI
The display will automatically be limited to affected routes, sectors, fixes, and airports. This TMI will
display future route, sector, fix, airport alerts in what time period the user requests. These can be
requested in 15 minute increments for up to six hours in the future. The TSD will prominently indicate
that this is a future view and how far into the future. Demand / Capacity bar charts are also capable of
being displayed that will show future fix and / or sector loadings. The Bar Graph displays cumulative
demand as compared to capacity in various time frames (15, 30, and 60 minutes). Various coloring
schemes can be applied to present various data.
The TSD draws alerts on the display as icons. The shape of the icon indicates the alert type: circles for
airports, triangles for fixes, and hatching within sector boundaries for sectors. The color of the alert
icon indicates the alert status. The direction of the hatching of sectors indicates the altitude level at which
a sector is alerted and if the sector is RVSM alerted. A short line(s) extending to the left from the triangle
indicates the altitude level(s) at which a fix is alerted. A line at the bottom of the triangle indicates that
the low level fix is alerted. A line from the middle of the triangle indicates that the high level fix is
alerted. A line from the top of the triangle indicates that the super-high level fix is alerted. If the
projected active traffic demand exceeds the alert threshold, the TSD displays new alerts in red. If the
proposed and/or scheduled demands exceed the threshold, the TSD draws a yellow alert icon. If the sector
is RVSM alerted and the display of RVSM alerts is selected, the TSD draws those sectors in blue if
they would not otherwise be drawn in red or yellow.
The alert icons that are drawn on the display represent the highest alert level for the element during the time
period (time limit) specified by the user. The time limit may be specified in quarter-hour increments from
0.25 to 6.0 hours.
3.1.4.6 Airborne Holding TMI
The display will automatically be limited to affected sectors, fixes, and airports. This TMI will display
future sector, fix, airport alerts in what time period the user requests. These can be requested in 15 minute
increments for up to six hours in the future. The TSD will prominently indicate that this is a future view
and how far into the future. Demand / Capacity bar charts are also capable of being displayed that will
show future sector loadings in the vicinity of the holding area. The Bar Graph displays cumulative
demand as compared to capacity in various time frames (15, 30, and 60 minutes). Various coloring
schemes can be applied to present various data.
The TSD draws alerts on the display as icons. The shape of the icon indicates the alert type: circles for
airports, triangles for fixes, and hatching within sector boundaries for sectors. The color of the alert
icon indicates the alert status. The direction of the hatching of sectors indicates the altitude level at which
a sector is alerted and if the sector is RVSM alerted. A short line(s) extending to the left from the triangle
58
indicates the altitude level(s) at which a fix is alerted. A line at the bottom of the triangle indicates that
the low level fix is alerted. A line from the middle of the triangle indicates that the high level fix is
alerted. A line from the top of the triangle indicates that the super-high level fix is alerted. If the
projected active traffic demand exceeds the alert threshold, the TSD displays new alerts in red. If the
proposed and/or scheduled demands exceed the threshold, the TSD draws a yellow alert icon. If the sector
is RVSM alerted and the display of RVSM alerts is selected, the TSD draws those sectors in blue if
they would not otherwise be drawn in red or yellow.
The alert icons that are drawn on the display represent the highest alert level for the element during the time
period (time limit) specified by the user. The time limit may be specified in quarter-hour increments from
0.25 to 6.0 hours.
3.1.4.7 Sequencing and Spacing TMIs
The display will automatically be limited to affected routes, sectors, fixes, and airports. This TMI will
display future route, sector, fix, airport alerts in what time period the user requests. These can be
requested in 15 minute increments for up to six hours in the future. The TSD will prominently indicate
that this is a future view and how far into the future. Demand / Capacity bar charts are also capable of
being displayed that will show future sector loadings. The Bar Graph displays cumulative demand as
compared to capacity in various time frames (15, 30, and 60 minutes). Various coloring schemes can be
applied to present various data. A Time Line Display is ideal for showing how sequencing is operating. It
shows individual flights and places them on a minute-by-minute timeline. Various coloring schemes can
then be applied to the flights to present various information in a visual manner. Furthermore, the Time
Line presents open or unassigned slots.
The TSD draws alerts on the display as icons. The shape of the icon indicates the alert type: circles for
airports, triangles for fixes, and hatching within sector boundaries for sectors. The color of the alert
icon indicates the alert status. The direction of the hatching of sectors indicates the altitude level at which
a sector is alerted and if the sector is RVSM alerted. A short line(s) extending to the left from the triangle
indicates the altitude level(s) at which a fix is alerted. A line at the bottom of the triangle indicates that
the low level fix is alerted. A line from the middle of the triangle indicates that the high level fix is
alerted. A line from the top of the triangle indicates that the super-high level fix is alerted. If the
projected active traffic demand exceeds the alert threshold, the TSD displays new alerts in red. If the
proposed and/or scheduled demands exceed the threshold, the TSD draws a yellow alert icon. If the sector
is RVSM alerted and the display of RVSM alerts is selected, the TSD draws those sectors in blue if
they would not otherwise be drawn in red or yellow.
The alert icons that are drawn on the display represent the highest alert level for the element during the time
period (time limit) specified by the user. The time limit may be specified in quarter-hour increments from
0.25 to 6.0 hours.
3.1.5 Operational Performance Monitoring and Assessment
Operational performance monitoring and assessment should answer the simple question “How did we
do?” An organization that can answer that question is an organization focused on operational
improvement. A key dependency for operational performance measurement is the capture and storage of
operational data. It is best to build the ability to capture operational data for analysis and assessment into
the original design. In this system architecture, the relevant Data Management Services are responsible
for capturing and storing the operational system data.
Once the system captures the operational data, displays can provide the view into operational
performance. Figure 15 provides a report on the compliance to ground delay departure times. Many
59
different types of displays can be built, and analysts can directly query relational databases to calculate
operational statistics.
Figure 15 - Operational Performance Report on Departure Compliance
3.2 ATFMS Technology Selections
The intent of this section is to provide general guidelines regarding the selection of technologies for use
within the ATFMS. Since this system is a system of systems, the technologies can be heterogeneous.
60
3.2.1 Communication Application Programming Interface (API)s and Messaging
Whenever possible, the network protocol for communication will be TCP/IP (for legacy systems, this
may not be possible).
A strong note is that the communications infrastructure for TCP/IP connectivity between aviation
facilities, such as ACCs, must exist. This is a major dependency.
Whenever possible and reasonable, the system shall use eXtensible Markup Language (XML) to
encapsulate data.
The system shall use a messaging system to guarantee message transport, the protocols are vendor
dependent. Some form of message oriented middleware can fulfill this capacity.
The system shall use communications for sending certain information to the airline automation systems. It
is recommended that India require airlines to create their own TCP/IP connections to the AAI to
communicate data that allows them to play a more active role in CDM.
3.2.2 Databases
Databases are a key element in the system architecture for data caching, storage, retrieval, and
maintenance. Most enterprise frameworks use some form of data storage and retrieval. There are many
industry recognized, commercial databases on the marketplace today, but the most utilized are relational
databases from large software vendors. The most noteworthy of these are: Oracle’s Database, IBM’s
DB2, and Sybase’s DBMS. There are also open source database systems, such as MySQL or PostgreSQL.
Currently, the most prevalent database management system (DBMS) is Oracle’s database. The selection
of the appropriate database for ATFMS shall depend on industry proposals and AAI selection.
3.2.3 Programming Languages
The preferred programming language for the development of India’s ATFMS is Java. Currently, Java is
well-recognized in the industry for developing enterprise level systems, and it is up-to-date with current
and emerging standards within computer systems development. Java has increased in performance
significantly over the past 8 years, and it is now capable of handling intensive floating point calculations
such as trajectory prediction processing without negative performance impacts.
61
Section 4. Operational Requirements This section presents the operational capabilities required to implement ATFM as described in the
Concept of Operations for Indian Air Traffic Flow Management and the Indian ATFM Qualitative
Requirements. It addresses all four phases of ATFM: Strategic; Pre-tactical; Tactical; and, Logging and
Post Analysis. In addition, the ATFMS operational requirements for Infrastructure Support and System
Security are also presented.
4.1 Air Traffic Flow Management System (ATFMS) General Specifications
Traffic flow that matches user demand with available capacity results in maximum airport and airspace
safety and efficiency. This reduces congestion and unnecessary delays allowing delays to be taken on the
ground whenever possible, and accommodating military operations and national defense requirements.
Maintaining this type of traffic flow imposes a requirement for an air traffic flow management function,
which collects data on current and predicted airspace capacity and demand and compares these to detect
potential and actual airspace saturation.
Saturation of specific airspace or airports may require that aircraft be delayed or diverted in order to
maintain safety. Knowledge of actual or potential saturation during flight planning allows plans to be
adjusted for maximum efficiency. Therefore, the flow control and delay advisory information that affects
flight planning must be disseminated to airspace users.
The ATFMS and its supporting hardware and software need to operate at sufficient speed to be able to
process flight data information arriving at one minute intervals for all flights in the ATFMS. In addition
there needs to be enough reserve processing power to handle all user requests within 0.2 seconds.
The ATFMS shall be capable of updating all situational data within one minute. The ATFMS shall be
capable of responding to any user input within 0.2 seconds. The alert functions of the ATFMS shall be
made known to the users at the CCC, the ACCs, the APP and TWR TMUs within 0.2 seconds of being
calculated. The ACC, APP, and TWR TFM specialists shall be referred to as local air traffic flow
management (ATFM) specialists for the remainder of this section.
In addition, each independent system and network shall be 99.9% available and system recovery shall be
accomplished by having a “hot backup” which is a second complete system always receiving the same
data as the “operational” system and processing it at the same time.
4.2 Required Modes of Operation
The ATFMS shall be capable of the following modes of operation:
ATFMS Operational Mode - ATFMS Operational Mode is the mode for normal ATFMS operations
using live data and ATFMS users interacting and affecting changes in India’s air traffic environment.
Normal ATFMS operations include providing situation displays to monitor traffic flows, defining areas of
interests, establishing and receiving monitor alerts, developing Traffic Management Initiatives (TMIs),
and monitoring ATFMS functions.
Standby Mode - Standby Mode is primarily intended for the CCC backup capability. At the CCC
backup facility, ATFMS in Standby Mode is listening and buffering external and remote site data,
processing CCC-supplied synchronization, sustaining system maintenance and control connectivity, and
handshaking with the CCC. ATFMS in Standby Mode is ready to provide full ATFMS operational
capability should the primary processing site fail.
62
Shadow/Training Mode – Shadow/Training Mode is primarily to support training and testing of the
ATFMS. ATFMS in Shadow Mode receives live data from external interfaces and remote sites, but does
not perform any actual traffic flow management. A User/Trainee can follow actual development of air
traffic flows, create selections to monitor areas of interest, set up and receive alerts, and even construct
TMIs. The TMIs generated from this mode are not published and will never affect the real traffic flow
environment.
Replay Mode - In Replay Mode, recorded data is used to display the situation, as it existed during the
user selected time.
4.3 Strategic and Pre-Tactical Operational Requirements
Strategic and pre-tactical flow management consists of activities that take place before the day of
operations. These activities may take place from one day, up to several months, prior to the day of
operations. During this period, the following ATFMS capabilities shall be required:
4.3.1 Determine the Strategic and Pre-tactical Situation
The ATFMS shall determine strategic and pre-tactical situations based on demand and capacity
projections. To this end, the ATFMS shall:
Monitor strategic and pre-tactical information pertinent to demand projections.
Use strategic and pre-tactical information pertinent to demand projections.
Monitor strategic and pre-tactical information pertinent to capacity projections.
Use strategic and pre-tactical information pertinent to capacity projections.
4.3.2 Disseminate Strategic and Pre-tactical Information
The ATFMS shall disseminate strategic and pre-tactical information pertinent to capacity projections to
specialists. This includes IFR airport and airspace capacity projections to:
Local ATFM specialists for specified airports.
Local ATFM specialists for specified airway route segments.
Local ATFM specialists for specified sectors.
CCC specialists for specified airports.
CCC specialists for specified airway route segments.
CCC specialists for specified sectors.
The ATFMS shall disseminate strategic and pre-tactical information pertinent to demand projections to
specialists. This includes IFR airport and airspace demand projections to:
Local ATFM specialists for specified airports.
Local ATFM specialists for specified airway route segments.
Local ATFM specialists for specified sectors.
CCC specialists for specified airports.
CCC specialists for specified airway route segments.
CCC specialists for specified sectors
63
4.3.3 User Requests for Demand Projections
The ATFMS shall:
Accept requests for strategic and pre-tactical demand projections from local ATFM specialists.
Disseminate results of strategic and pre-tactical demand projection requests to local ATFM
specialists in no more than 10 seconds of a request.
Process strategic and pre-tactical demand projection requests from local ATFM specialists.
Accept strategic and pre-tactical demand projection requests from CCC specialists.
Disseminate results of strategic and pre-tactical demand projection requests to CCC specialists in
no more than 10 seconds of a request.
Process strategic and pre-tactical demand projection requests from CCC specialists.
Accept user requests for future flight day demand projections and disseminate that information to
qualified users.
4.3.3.1 User Requests for Capacity Projections
The ATFMS shall:
Accept requests for strategic and pre-tactical capacity from local ATFM specialists.
Accept strategic and pre-tactical capacity projection requests from CCC specialists.
Process strategic and pre-tactical capacity projection requests from CCC specialists.
Process strategic and pre-tactical capacity projection requests from local ATFM specialists.
Disseminate strategic and pre-tactical IFR traffic capacity projections to local ATFM specialists
for specified airports.
Disseminate results of strategic and pre-tactical capacity projection requests to local ATFM
specialists in no more than 10 seconds of a request.
Disseminate results of strategic and pre-tactical capacity projection requests to CCC specialists in
no more than 10 seconds of a request
Accept user requests for future flight day capacity projections and disseminate that information to
qualified users.
4.3.4 Analyze Strategic and Pre-tactical Situations
The ATFMS shall:
Analyze strategic and pre-tactical potential demand and capacity imbalances.
Input possible scenarios for strategic and pre-tactical situation resolution.
Analyze strategic and pre-tactical scenarios for imbalances in demand and capacity.
Predict the impact of imbalances found in possible strategic and pre-tactical scenarios.
64
4.3.5 Generate Strategic and Pre-tactical Strategies
The ATFMS shall:
Acquire traffic conditions information to determine future traffic patterns and active runway
selection.
Analyze the impact of developed strategies for possible strategic and pre-tactical situations.
Collaborate with users on the development of traffic flow management strategy alternatives.
Use impact assessment of possible future traffic flow management scenarios to develop new
traffic flow management strategy alternatives.
4.3.6 Strategic Capacity Management
In support of strategic capacity management, ATFM specialists shall:
Analyze post operations data to assess system performance at all levels of the ATFMS to identify
recurring positive and negative system performance trends and the conditions that contributed to
that performance.
Develop and coordinate strategies for resolving problems found during the course of post
operations analyses.
Evaluate the effectiveness of the current and planned airspace structure to identify where flows
can be made more effective.
Evaluate the effectiveness of ATFM decision support tools in meeting the demands of anticipated
operations, and where deficiencies are noted; identify needed enhancements or new functions.
4.3.7 Pre-Tactical and Special Event Planning and Management
In support of pre-tactical event planning and management the ATFM specialists shall:
Update, monitor and analyze demand predictions for the subject day of operations to identify
potential demand/capacity imbalances that might require ATFMS intervention.
Inform airspace users and other ATFM units of potential demand/capacity imbalances that might
require ATFMS intervention.
Develop and coordinate general flow strategies for addressing demand/capacity imbalances
expected because of historical trends or anticipated severe weather, military exercises or special
events.
Perform a comparison of anticipated demand (scheduled and unscheduled) and predicted capacity
(factoring in forecasted weather) to develop a general plan of operations for a specified day.
Coordinate or collaborate, where appropriate, with airspace users on strategies for adjusting flight
plans or schedules to meet anticipated capacity shortfalls.
4.4 Tactical Operational Requirements
Tactical flow management will focus on the management of events unfolding on the day of operations
that could result in excessive delay or flight schedule disruption at any point within the system. This shall
include:
65
Analyzing projected demand based on flight plans submitted in the strategic and/or pre-tactical
phases, or revised on the day of operations.
Monitoring traffic demand and resource capacities for potential capacity/demand imbalances
causing excessive delay in the system.
Resolving airport and airspace demand/capacity imbalances, where warranted. This shall include
defining flow initiatives for balancing flows across arrival fixes, determining departure release
time to merge departure into en route flows, limiting traffic flow into congested sectors, and
coordinating flight plan changes to deal with routes closed by weather.
Coordination and collaboration, where required by procedures, with adjacent facilities and
associated airspace users.
4.4.1 Traffic Situation Monitoring and Problem Identification
The ATFMS shall provide assistance in managing periods of congestion causing excessive delay. The
determination of what constitutes excessive delay shall be made by the ATFM specialists with the aid of
information and decision support tools that will assist them in determining the ability of available
capacity to handle current or projected demand. ATFM specialists in all four layers of the ATFM
structure shall participate in monitoring and assessing operations in India’s airspace. The scope of their
monitoring and assessment responsibilities shall be consistent with their geographic areas of
responsibility.
To ensure a broad understanding of operations in India’s airspace, ATFM specialists within the CCC,
ACC TMUs, APP TMUs, and TWR TMUs shall share in the responsibility for reporting on the status of
resources within their areas of responsibility. This shall include sharing of information on changes in
capacities for airport arrivals, airport departures, sectors, routes and fixes. All ATFM specialists at air
traffic operations facilities should:
Be aware of the traffic flow situations in the areas under their jurisdiction.
Be aware of predicted flow, capacity, and the operational conditions of their areas of
responsibility.
Take account of the operational status of neighboring areas and other areas around India.
Possess the ability and methods to collaboratively take effective measures to identify various
traffic factors in order to eliminate the imbalance between air traffic demands and system
capacity utilizing the least severe measures required.
Continually monitor and adjust those measures as the situation requires.
Document all significant activity and actions to assist in post event analysis.
Airspace users and the CCC shall be responsible for ensuring the timely availability of information about
changes in user demand. This broad sharing of information will support the collaborative identification of
air traffic flow problems at the local, regional and national levels, and will facilitate arriving at a
consensus on flow problem solutions.
The declaration of a flow management “problem” shall be made by ACC TMUs, for capacity/demand
situations contained within its jurisdiction, or by the CCC, for capacity/demand imbalances which cross
ACC boundaries. These units shall be responsible for:
Analyzing demand/capacity information provided by the APP TMUs and the TWR TMUs to their
respective ACC TMU.
66
Identifying the time and location where demand is expected to exceed capacity.
Ensuring that the appropriate units are informed of the anticipated flow management problem.
Providing the information upon which their assessment was based, to support collaboration with
other units, and airspace users where appropriate, on the severity of the problem and the need for
intervention.
4.4.1.1 Provide Capacity Projections.
The ATFMS shall:
Update capacity projections.
Use information pertinent to current tactical capacity projections.
4.4.1.1.1 Monitor Information Pertinent to Capacity
The ATFMS shall monitor information pertinent to capacity projections including:
Monitoring local acceptance rate data for each runway at designated airports.
Detecting flow restrictions changes.
Detecting airspace restrictions changes.
4.4.1.1.2 Specialists' Inputs
The ATFMS shall:
Accept specialists' inputs for airport arrival rates.
Accept specialists' inputs for airport departure rates.
4.4.1.1.3 Determine Current Demand and Capacity
The ATFMS shall determine current capacity conditions.
To calculate runway capacity at designated airports, the ATFMS shall consider:
Runway surface conditions
Winds aloft
Local acceptance rates
Terminal navigation equipment status
For designated airports, the ATFMS shall determine the number of:
Departures that can be handled on each runway per hour
Arrivals that can be handled on each runway per hour.
The ATFMS shall determine the current:
Demand on specified airway route segments.
Capacity of specified airway route segments.
Demand on specified sectors.
67
Capacity of specified sectors.
4.4.1.1.4 Determine Future Capacity
The ATFMS shall predict future capacity conditions for all specified airspace objects.
4.4.1.1.5 Disseminate Capacity Information
The ATFMS shall:
Disseminate capacity information to specialists.
Update airspace object projections when information pertinent to capacity projections changes.
Process requests for capacity information from specialists.
Accept and process capacity projection requests from local ATFM specialists.
Accept and process capacity projection requests from CCC specialists.
The ATFMS shall disseminate:
Airway route segment capacity projections to local ATFM specialists for up to 12 hours from the
current time.
IFR traffic capacity projections to local ATFM specialists for specified airway route segments.
Sector capacity projections to local ATFM specialists for up to 12 hours from the current time.
IFR traffic capacity projections to local ATFM specialists for specified sectors.
IFR traffic capacity projections to local ATFM specialists for specified airports.
Updated airport capacity projections to local ATFM specialists.
12-hour airport capacity projections to local ATFM specialists.
The ATFMS shall disseminate the results of local ATFM specialist capacity projection requests within a:
Mean response time of 3 seconds of the request.
99th percentile response time of 5 seconds of the request.
Maximum response time of 10 seconds of the request.
The ATFMS shall disseminate the results of CCC requested capacity projections within:
A mean response time of 3 seconds of the request.
The 99th percentile time of 5 seconds of the request.
A maximum time of 10 seconds of the request.
The ATFMS shall disseminate airport capacity projections by:
Aircraft performance type.
A specified time interval.
Number of aircraft per minute.
68
4.4.1.2 Provide Demand Projections
The ATFMS shall update demand projections.
4.4.1.2.1 Monitor Information Pertinent to Demand
The ATFMS shall:
Monitor information pertinent to demand projections
Acquire traffic count summary information for each sector in the ATFMS.
4.4.1.2.2 Determine Demand
The flight and flow management information shall pertain to the traffic management unit’s assigned
airspace structure boundary.
The ATFMS shall project demand up to 12 hours in the future for:
Airway route segments.
Sectors.
Fixes
Airports.
The ATFMS shall retrieve demand projections by:
Destination airport.
Altitude.
Route segments.
Geographic area.
Sectors
Number of aircraft per time interval.
4.4.1.2.3 Disseminate Demand Information
The ATFMS shall disseminate the number of planned IFR:
Arrivals for designated runways.
Departures for designated airports.
Arrivals for designated airports.
Departures for designated runways.
The ATFMS shall disseminate:
Demand projections to specialists.
12-hour airway route segment demand projections to CCC specialists.
12-hour sector demand projections to CCC specialists.
IFR traffic demand projections to CCC specialists for specified airway route segments.
69
Airway route segment demand projections to CCC specialists for up to 12 hours of the current
time.
Demand information for specified look-ahead times to the CCC specialist
Traffic count summary information for each sector in the ATFMS to the CCC specialist.
CCC flow information summaries to the local ATFM specialists.
IFR traffic demand projections to CCC specialists for specified sectors.
The ATFMS shall:
Accept and process demand projection requests from CCC specialists.
Accept and process demand projection requests from local ATFM specialists.
The ATFMS shall disseminate the results of CCC requested capacity projections within:
A mean response time of 3 seconds of the request.
The 99th percentile response time of 5 seconds of the request.
A maximum response time of 10 seconds of the request.
The ATFMS shall disseminate:
Airway route segment demand projections to local ATFM specialists for up to 12 hours from the
current time.
Sector demand projections to local ATFM specialists for up to 12 hours from the current time
Sector workload information for specified look-ahead times to the Local Traffic Management
specialists.
Traffic count summary information for each sector in the ATFMS to the Traffic Management
specialists.
Flow management information to the local ATFM specialists.
Flight data information to local ATFM specialists.
The ATFMS shall disseminate the results of local ATFM specialist demand projection requests within:
A mean response time of 3 seconds of the request.
The 99th percentile response time of 5 seconds of the request.
A maximum response time of 10 seconds of the request.
4.4.1.3 Evaluate Capacity and Demand
The ATFMS shall:
Evaluate capacity and demand.
Be capable of exchanging airport utilization data and scheduled airline data with appropriately
equipped airline dispatch offices.
70
Analyze available airport capacity based on saturation information.
Analyze airspace capacity based on saturation information.
4.4.1.3.1 Analyze Traffic Saturation Conditions.
The ATFMS shall measure, predict, analyze and distribute airport and airspace saturation 12 hours in
advance.
4.4.2 Flow Problem Resolution
The resolution of air traffic flow problems shall be accomplished through a collaborative process. Except
where delegated through policy or procedures, the CCC shall be the lead for the development,
coordination and approval of TMIs. In carrying out these responsibilities, the CCC or responsible ACC
TMU shall coordinate with airspace users and other facilities to:
Develop candidate resolution strategies.
Assess the impact of those candidate resolution strategies on the projected capacity/demand
imbalance.
Define the specifics of the TMIs needed to implement a selected strategy, including what
facilities and flights should be affected.
Ensure that the appropriate facilities and airspace users are given timely notice of pending TMIs.
4.4.2.1 Coordinate Traffic Flow Strategies
The ATFM specialist shall coordinate TMIs and flow strategies with other users, specialists, and
stakeholders.
4.4.2.1.1 Analyze Traffic Flow Alternatives
The ATFM specialists shall analyze:
Alternate trial rerouting of proposed aircraft flight plans to resolve or minimize saturation
conditions.
Operational alternatives based on saturation information.
Flight restrictions for specific aircraft based on saturation information.
Spacing advisories for:
o Clearance-based trajectories.
o Aircraft-aircraft conflicts.
o Aircraft intrusion into special use airspace.
4.4.2.1.2 Coordinate Alternatives
The ATFM specialist shall allocate available:
Airport capacity.
Airspace capacity.
The ATFMS shall:
71
Display derived alternatives to the:
o Specialist.
o AOC.
Disseminate inter-facility traffic flow plans.
Notify specialists controlling the affected flights upon detection of airspace changes.
Exchange:
o Traffic flow information between specialists.
o Data flow control information between CCC specialists.
o Data flow control information between local ATFM specialists and specialists.
Disseminate voice information between local ATFM specialists and specialists.
Have:
o Connectivity between the CCC and the military scheduling facilities.
o Data connectivity between selected air traffic control facilities and the CCC.
o Data connectivity between the CCC specialists and the local ATFM specialists.
o Voice connectivity between the CCC specialists and the local ATFM specialists.
o Voice connectivity between the local ATFM specialists and the CCC specialists.
4.4.2.2 Modify Current Flow Strategies
The ATFM specialist shall:
Modify current flow strategies.
Generate alternate plans to alleviate traffic flow problems.
4.4.3 Flight Plan Execution
While the ATFM organizations of AAI will responsible for the definition and implementation of TMIs,
the actual execution of TMIs shall be a responsibility shared among ATFM specialists and air traffic
controllers at en route sector, approach, and tower control positions.
When ATFM TMIs are implemented by the CCC, the CCC shall be responsible for disseminating the
initiatives to the appropriate ACC TMU(s). The ACC TMU(s) shall, in turn, be responsible for
disseminating the TMI to the appropriate lower level ATFM and ATC positions. The dissemination of the
specifics of the TMIs shall be done either manually or through the use of automation.
4.4.4 Disseminate Traffic Flow Guidance
4.4.4.1 Implement Traffic Flow Plans
The ATFM specialist shall:
Implement military air traffic control plans related to national emergencies.
Process requests for aircraft information relating to aircraft participating in TFM strategies.
Implement traffic flow initiatives.
72
The ATFM specialist shall disseminate:
Preferred route information at least 24 hours prior to it becoming effective.
Military air traffic control plans related to national emergencies.
Flow control information to users via external voice communications.
Flow control information to users via external data interfaces.
Inter-facility traffic flow plans.
4.4.4.2 Disseminate Traffic Flow Information
The ATFMS shall disseminate the following to specialists and authorized users:
Flight data information.
Flow management information.
CCC flow information summaries.
Flow control information.
Alternate trial rerouting to resolve or minimize saturation conditions.
Local flow restrictions.
Inter-facility flow restrictions.
Pre-departure airspace restriction alerts.
Pre-departure flow restriction alerts.
Future flight day information pertinent to capacity projections.
Derived restrictions.
Derived alternate courses of action.
Flight restrictions.
Alternate courses of action relative to flight restrictions.
Pre-departure flow restriction alerts.
Pre-departure airspace restriction alerts.
Derived alternate courses of action.
Requested delay advisory information to specialists within a mean response time of 3.0 seconds
of the request.
Requested delay advisory information to specialists within the 99th percentile response time of
5.0 seconds of the request.
4.4.4.3 Non-Compliance
The ATFMS shall:
Detect current clearance-based trajectories that are in noncompliance with flow restrictions.
73
Disseminate advisories to the specialist to resolve noncompliance of current clearance-based
trajectories with flow restrictions.
4.5 Logging and Post Analysis Operational Requirements
4.5.1 Data Logging
The ATFMS shall provide for recording, archiving, and analysis of ATFM operational data.
The ATFMS shall record operations data for historical analyses, modeling, and reference, and for
dynamic application for near-term flow planning and management. The system's data shall be available to
authorized users in near-real time. It will provide a standard interface capable of supplying operational
data to other AAI organizations and systems as well as providing information resources to system users
and/or other governmental organizations. Recording, storage, and collection and communication servers
will be strategically located at collector sites such as ACC TMUs, APP TMUs, and TWR TMUs and
selected approach and tower facilities that do not have TMUs, with a central data administration,
collection, and archiving function at the CCC.
The ATFMS shall have the capability to store, retrieve, and archive ATFMS performance information.
The data that shall be archived includes, but is not limited to:
All input data to the ATFMS consisting of:
o Aircraft position reports.
o Flight plans and flight plan amendments.
o Weather.
o Airline messages.
o Slot substitutions.
o Wheels up/down.
o Ground system messages.
o Taxi time.
o Gate arrival/departure time.
o Schedule data – such as Official Airline Guide (OAG).
All trajectories generated by the ATFMS.
All alerts generated by the ATFMS such as sector overcapacity alerts.
All TMIs implemented and the aircraft affected by the TMI:
o Delays on aircraft affected by the TMI.
o Reroutes generated by a TMI and respective aircraft affected by the reroute.
Actual route each aircraft flew.
4.5.2 Real-time and Post Analysis
The ATFM data shall be used to increase the reliability and accuracy of the predictions of the flight
trajectories of the aircraft. This data shall be made available in near-real-time to the ATFMS.
74
The first set of metrics that will be used to improve the ATFM system is the actual departure time versus
predicted departure time. Historical data needs to be saved in order for this prediction to be improved.
The actual may consistently be later than the predicted due to airport conditions, airline operations staff,
etc. These may consistently be a constant or may change due to season or weather conditions. If this data
is kept and then analyzed on a historical basis it can be used to improve the predictions of actual departure
time.
The same is true for actual arrival time versus estimated time of arrival. The data that needs to be saved
for these analyses is estimated/actual time of arrival/departure and the exact route including the ascent
and descent profiles that the aircraft actually flew. Keeping the historical ascent/descent profiles will
greatly help in the arrival prediction. Other data inherent to improving these predictions are gate times
and taxi times. When saving and analyzing this data the weather conditions also have to be saved, noted
and factored into the analysis.
Post analysis data shall be required in order to provide ATFM specialists a means to analyze decisions
and perform “what if” analyses. Analysis of how implemented TMIs affected the actual traffic including
measures of delay on all affected flights shall be performed and archived. This will enable AAI to
determine how effective their TMI solutions were, to correct identified deficiencies, and will enable them
to develop a “play book” similar to the FAA’s.
The ATFMS shall:
Assess the performance of the ATFMS.
Evaluate the effectiveness of flow restrictions implemented in the ATFMS.
Identify deficiencies in the capacity of selected airspace.
Generate proposals to correct the identified capacity deficiencies.
4.5.3 Evaluate Flow Performance
4.5.3.1 Store Flight Day Information
The ATFMS shall:
Record data processed by or displayed to the specialist.
Receive, store, retain, and readily retrieve all air-ground communications.
Record air-ground voice and data communications.
Retain recordings of air-ground voice transmissions for not less than 15 days.
Retain recordings of air-ground data messages for not less than 30 days.
Interface recorded coded time source at selected facilities voice and data recordings to provide
time-related data.
Receive, store, retain, and readily retrieve ATFMS inter-facility and intra-facility ground-ground
communications.
Record all voice communications entering or leaving each specialist's position at ACCs, ATCTs,
and the CCC.
Record all accountable data messages utilized at each specialist's position at each of these
facilities. The data recorded shall ensure that all information utilized by the specialist and/or
75
displayed at the specialist's position and all actions or messages initiated by the specialist can be
reconstructed.
Store voice recordings in "off-line" storage for not less than 15 days.
Store data recordings in "off-line" storage for not less than 15 days.
Retrieve individual voice recordings from "off-line" storage within 30 minutes of a request.
Retrieve individual data messages from "off-line" storage within 30 minutes of a request.
Record flight day performance information.
Archive flight day performance information.
Store communications.
Store flight day performance information.
4.5.3.2 Evaluate Stored Information
The ATFMS shall:
Analyze trends in maintenance problems.
Correlate equipment performance measurements for trend analysis.
Correlate equipment performance measurements for failure anticipation rates.
Evaluate the effectiveness of flow restrictions implemented in the ATFMS.
Identify deficiencies in the capacity of selected airspace.
Assess the s performance of the ATFMS.
Summarize reports on:
o Equipment performance.
o Preventive maintenance activities.
o Equipment repair activities.
4.5.3.3 Generate Performance Reports
The ATFMS shall generate proposals to correct the identified capacity deficiencies.
4.5.4 Report Flow Performances
The ATFMS shall disseminate reports on:
Equipment performance.
Maintenance activities.
Equipment repair activities.
The ATFMS shall disseminate equipment performance measurements for:
Trend analysis.
Failure anticipation rates.
The ATFMS shall retrieve flight day performance information.
76
4.6 Infrastructure Support
The most critical aspect of establishing an ATFM infrastructure is to support the primary goal of enabling
common and shared situational awareness amongst all traffic flow management stakeholders. Shared
situational awareness does not imply that all stakeholders have the exact same information or displays.
Rather, it means all stakeholders should have access to information derived from a common information
pool. The design of such an information sharing infrastructure shall enable stakeholders to both gather
appropriate levels of information from and submit information to a common set of data structures
accessible to a greater or lesser extent by all users.
Such an information sharing infrastructure shall have the following capabilities.
4.6.1 Airspace System Definitions
While individual users and facilities shall focus on different regions and aspects of traffic flow, they all
need a common set of definitions. Coordinated operations among facilities shall rely on common maps,
element names, codes, air routes, and so on. Some of this is relatively static, other elements may change
daily, and all users need to view the same data with a common understanding.
This data is best displayed using a common surface map, digitally encoded, capable of being displayed in
various formats and projections, including selectable elements such as:
Terrain features such as rivers.
Navigation hazards (e.g., tall towers near airports).
Geopolitical boundaries and features.
Aviation-specific fixed points such as navigational aids, coordination (handoff) waypoints,
airports, runways, traffic corridors.
Airspace volume restrictions (e.g., restricted use areas).
While the common data must be centrally controlled (in concept, at least), operational use generally calls
for distributed data storage and management. Updates shall be coordinated so that all users have the same
edition of the airspace data. For performance reasons the data may be cached in local storage, but the
controlled version governs all uses.
Aeronautical data may be characterized by its volatility (frequency of change). Fixed locations provide
the backdrop for more rapidly changing data including weather information, airport status, and the
location of aircraft. Static information can most conveniently be processed by a central organization and
distributed periodically to field sites. The US National Airspace System, for example, employs a 56-day
Chart Change Update schedule (with real-time amendments as necessary) to support the common view.
4.6.2 Centralized ATFM Processing
Dynamic traffic flow information, such as flight planning and aircraft position data, is typically generated
locally across the airspace. This information must be collected and integrated to provide the common
situation model needed for effective flow management. The infrastructure required to achieve this
common view includes both distributed and centralized elements.
Distributed data acquisition support, including:
Interfaces to surveillance systems and other data sources (e.g., local weather).
Processing (filtering, time stamping, metadata tagging, etc.) to support data quality and usability
(e.g., data aging) analysis.
77
Interface(s) to centralized processing components.
Single traffic flow management processing with a non co-located backup that generates:
Common traffic flow management geospatial display generation based on ATC surveillance
inputs.
Predictive traffic flows based on flight plan submissions and airline scheduling data.
Modeling ability to inject projected weather or other flow constraints for predictive planning
using projected traffic flows.
Data storage and archiving capability for:
Support of short-term post-event analysis and long-term historical trend studies.
Management of standardized and reusable ATFM actions such as pre-coordinated reroute plans
for typical adverse weather conditions and planning for infrequent (but predictable) high-traffic
occasions.
Back-up processor geographically separated for continuity of operations in an emergency situation.
Distribution interfaces to allow dissemination of traffic flow display data to subordinate traffic
management units as well as collaborative decision making partners.
4.6.3 Computer Software Quality Program and Plan
The ATFMS shall develop, implement, and maintain a computer software quality program.
The computer software quality program shall provide quality assurance controls throughout all phases of
software development, including requirements definition, design, implementation, test, installation and
checkout, and operations and maintenance portions of the software life cycle.
The ATFMS computer software quality program shall be described in a documented Computer Software
Quality Program Plan (CSQPP).
The CSQPP shall describe the ATFMS software development procedures, controls, methodologies and
organization.
4.6.4 Distributed Dissemination and Modeling
Traffic flow management is a mix of local and system-wide actions to monitor, forecast, and influence air
traffic. At the local level, traffic managers need the ability to view local conditions (such as weather) in
the context of broader events (such as projected inbound flights that may still be on the ground). Local
ATFM often involves coordination with other traffic management regions (e.g., ACC TMUs), based on a
common situational view. The ATFMS infrastructure must support this local/global integration of traffic
flow information. Specific capabilities include:
Common traffic flow management geospatial displays that can be focused and detailed for
specific areas of responsibility for each separate traffic flow management unit.
Modeling to inject projected local weather or other flow constraints for predictive planning using
projected traffic flows at separate traffic flow management units.
Transmission of individual traffic flow management unit actual or recommend TMIs to adjacent
units and to the CCC for coordination and collaboration.
78
4.6.5 System Level Interfaces
Traffic flow management operates, conceptually, on collections, or sets, of flights (rather than on
individual flights). This requires continual data exchanges with the operational (tactical) aspects of air
traffic including ATC and airlines and aircraft specialists. The shared situational ATFM model provides a
broader view than other air traffic operations. The ATFM infrastructure shall provide mechanisms for
sharing this view including the following interfaces:
Air traffic flow management display information, directions, and TMIs with the automation
systems used to support ATC functions in ACC, APP, and TWR facilities.
Information suppliers such as weather data, military airspace users, and other national or
international ATM organizations.
Airspace users such as airlines and aircraft specialists to provide consistent airspace status and
collaborative decision support.
4.6.6 Testing and Evaluation
For new systems introduced into the ATFMS, the appropriate AAI organization(s) shall:
Establish a test and evaluation program.
Participate in Production Acceptance Test and Evaluation (PAT&E).
Participate in Factory Acceptance Test (FAT).
Participate in Development Test and Evaluation (DT&E).
Conduct Operational Test and Evaluation (OT&E).
Establish a facility for conducting Operational Test and Evaluation.
Establish a Quality Assurance program.
Validate new or modified equipment or computer software for use in an operational environment.
Certify new systems for operational use.
4.6.7 Logistics
The appropriate AAI organization(s) shall:
Establish logistics support for all ATFMS systems.
Acquire replacement parts for ATFMS equipment.
Establish depot facilities to perform logistics activities.
Perform equipment repairs at depot facilities.
Acquire equipment to perform logistics activities.
Acquire systems to perform logistics activities.
4.6.8 Configuration Management (CM)
The appropriate AAI organization(s) shall be responsible for performing ATFMS CM. ATFMS CM
activities shall consist of planning and management, configuration identification (including baselining),
configuration control, configuration status accounting, audit and verification, and data management.
79
ATFMS planning and management shall ensure appropriate governance is in place for the assignment of
configuration management responsibility and decision-making.
ATFMS configuration identification activities shall establish the configuration baseline for each
configuration item. Baselining involves managerial agreement on the content of an investment program or
configuration item (e.g., acquisition program baseline (APB), program requirements document, system
specification, and product specification) by the designated configuration control board.
ATFMS configuration control is the process of developing, coordinating, approving, documenting, and
releasing changes to configuration items throughout solution implementation and in-service management,
again controlled by the designated configuration control board.
ATFMS configuration status accounting shall provide the means to record and report on configuration
data.
ATFMS audit and verification activities shall ensure that each investment or configuration item meets its
requirements and that requirements address the stated need.
ATFMS data management shall ensure shared information is appropriately accessible, provides
mechanisms for standardizing data formats, and enables control of program-related work products,
including baseline information and supporting program documentation.
4.7 System Security
Inappropriate access to, use of, or manipulation of ATFM capabilities and data can have extremely
negative consequences on the operation of India’s air traffic management system. To prevent such misuse
or abuse, the ATFMS shall possess system security functions that will provide the means for managing
and controlling access to system capabilities and data.
System security functions shall provide the means for ensuring that only the appropriate individuals and
software systems are allowed to access the ATFMS functions and data. The information management and
security functions shall provide for:
User and process identification and authentication.
Authorized ATFMS access.
ATFMS security management.
Network security protection.
Application software and data protection.
Database integrity.
4.7.1 User and Process Identification and Authentication
The ATFMS shall provide identification and authentication functions to establish and verify authorized
ATFMS users. Those functions shall provide the following capabilities:
Identify and authenticate system users, with a user being defined as a human, device or process.
Assign a unique identifier to each authenticated user, each subsystem process (including those not
running on behalf of a human user).
Each person or software process to identify itself before an ATFMS action is initiated on the
behalf of that person or software process. This is particularly important for the case of non-AAI
80
(i.e., airspace users involved in the CDM related activities) users of ATFMS data or system
functions. For example, one airline user shall not be allowed to access data of another airline.
Restricting ATFMS actions on behalf of an entity until that entity has been successfully
authenticated.
Authorized security administrator to incorporate installable authentication mechanisms into the
ATFMS.
Audit all uses of the identification and authentication functions.
Record and archive the actions of all entities
4.7.2 ATFMS Access
The system shall be designed to control system use and the distribution of system data only to authorized
users. ATFMS access control functions shall be incorporated in the system to enforce AAI policies,
procedures and memoranda of agreement with non-AAI organizations, (e.g., airlines participating in the
CDM process) governing use of AAI decision support automation. Those functions shall provide the
following capabilities:
Authorized security administrator to add or delete system users.
Authorized security administrator to define functions to be associated with each user.
Allow mapping of different access privilege levels for users to be permitted to perform different
functions.
Control the establishment of a user session on the ATFMS through the use of user IDs and
password protection.
Prevent logging in simultaneously on the same account (as defined by a unique user ID and
password combination) from two different workstations.
Automatically record access history information.
Authorized security administrator to retrieve and display access history information for an
individual, device, or process.
4.7.3 Security Management
Security management shall be directed to the management of several aspects of the ATFMS security
attributes, security-related data, system operations, and system functions.
Management of security attributes allows authorized security administrators control over the data that
define the degree of access and process control being applied by the security related ATFM functions. To
support security management, the ATFMS shall provide the following capabilities:
Restrict the ability to determine and disable, enable and modify the security behavior of the
ATFMS to only authorized security administrators.
Initialize security attributes with default values selected by an authorized security administrator.
Authorized security administrator to select the security attributes to be associated with an entity,
and to assign values to those attributes.
Audit all modifications to the behavior of the ATFMS security functions.
81
4.7.4 Network Security Protection
Because of ATFM’s need for collaboration and data exchange with organizations that operate outside the
AAI information network, network security protection is more critical for ATFMS than the ATC- related
components of the AAI information and communication infrastructure. Network security protection is
directed towards maintaining:
Protection of network communications between the ATFMS and other AAI systems.
Protection of network communications between the ATFMS and systems that are not a part of the
controlled AAI communication infrastructure, such as airline systems or commercial weather
service providers.
Countermeasures corresponding to special or unique vulnerabilities of the ATFMS.
In addition, the ATFMS shall provide the following capabilities:
Protection against cyber attacks, including computer viruses and worms.
Detection and removal of malicious code and data (e.g., viruses and worms) upon request.
Push out security updates or patches from one or more distribution locations to individual
software components.
Generate an audit record that identifies all attempted violations of the security policy enforced by
security policy enforcement technology.
4.7.5 Application Software and Data Protection
The application software and data protection functions specify ATFMS security policies for protecting the
ATFMS’s application software and data. The ATFMS shall:
Enforce ATFMS access control policy to objects, based on attributes or named group of
attributes.
Enforce rules specified by an authorized security administrator to determine if an operation is
allowed among controlled subjects and controlled objects.
Be able to detect the modification of software and/or data, substitution of data, reordering of data,
or deletion of data for all ATFMS application data and software code transmitted between
separate parts of the ATFMS.
Provide the capability to freeze and/or eliminate access to compromised or unauthorized
computer system accounts.
Provide, in the event of an actual computer network attack, the capability to isolate the affected
workstation or network.
Provide the capability to close all remote maintenance ports on routers, firewalls, servers and
electronic phone switches, disconnect itself from the Internet/Intranet.
Provide the capability to authenticate the source of all data from sources outside of the ATFMS
before entry of that data into the ATFMS.
For all network interfaces, provide the security administrator with the capability to define rules of
acceptance (e.g., filtering) based on at least the following attributes: packet source, packet
destination, protocol type (e.g., IP, X.25) protocol service (e.g., TCP, UDP0) and rate limits.
82
Provide the capability to generate audit records that identify the successful or unsuccessful
import/export of user data, including any security attributes.
Provide the capability to filter data sent to different non-AAI users.
83
Section 5. Functional Specifications This section presents the functional capabilities required to implement ATFM as described in the Concept
of Operations for Indian Air Traffic Flow Management. It addresses the following functional
requirements:
Collect Traffic Management Information
Geographical Data Requirements
Schedule Data Processing
Flight Data structure Maintenance
Flight Plan Processing
Flight Modeling
Situation Awareness and Problem Identification
Weather Data Processing
Flow Initiative Planning
TMI Implementation
Information Management
ATFMS Training
System Performance
5.1 Collect Traffic Management Information
The ATFMS shall perform the following data and information collection functions:
Store military air traffic control plans related to national emergencies.
Acquire military air traffic control plans related to national emergencies.
Store Non-ATFMS weather data for flow control use.
Detect airspace restrictions changes.
Detect flow restrictions changes.
Acquire traffic conditions information to determine future traffic patterns and active runway
selection.
Monitor future flight day information pertinent to demand projections.
Utilize future flight day information pertinent to demand projections.
Collaborate with users on the development of traffic flow management strategy alternatives.
5.2 Geographical Data Requirements
The ATFMS receives geographical data files whenever the geographical data changes from other
elements of the ATM system.
84
The traffic manager can graphically display this geographical data on the Traffic Situation Display
(TSD) and use the geographical data to interpret flight paths that support the generation of aircraft situation
and capacity situation data.
The ATFMS may at any time send messages to redefine sector boundaries. These messages
frequently create larger sectors in times of light traffic (such as late night) and restore a more fine-
grained sectorization at busier hours of the day. They are also used to re-configure sectors in response to
wind changes or changing patterns of air traffic.
5.2.1 Input Geographical Data
The ATFMS shall receive the following information and any changes thereto from India’s ATM
system:
Fixes - reporting points in India including aliases and holding fixes
Airspace fixes (arrival, departure, en route, military, oceanic)
Landing facilities - airports in India
Airspaces – military and civilian sector and facility responsibility boundaries in India
Airways – India’s airways
Navigation Aids
Oceanic airways - selected off-shore airways.
DPs - the Departure Procedures, formerly known as Standard Instrument Departure routes (SIDs)
STARs - the Standard Terminal Arrival Routes.
Military training routes
Coded departure routes
The following information about neighboring airspace (oceanic, neighboring countries) shall also be
provided:
Fixes
Landing facilities - airports
Airspaces - sector definitions within the country’s jurisdiction
Airways
STARs
Restricted Areas - the boundaries for restricted areas
Other data to be provided to the ATFMS includes:
ICAO location identifiers
Foreign location identifiers
Flight information regions (FIRs)
World geographical boundaries
85
5.2.2 Dynamic Sector Processing
ATFMS uses a dynamic model of airspace sectors in order to provide users with accurate and up-to-
the-minute information, including sector loading information. At the same time, the ATFMS retains
the capability to display baseline sector information, including baseline sector loading, so that users
have information to support their decisions as to when and how to re-sectorize.
5.3 Scheduled Flight Data Processing
The airlines scheduled flights are available from either filed flight plans or from a commercial source
such as the Official Airline Guide (OAG). This schedule data may contain the flight schedules for
up to 6 months in advance. The ATFMS uses this data to provide schedule information to the ATFM
specialists at the CCC and to provide scheduled flight data for traffic demand predictions.
5.3.1 Source Schedule Data
The scheduled flight data shall contain the following fields for each flight entry:
Departure country code
Departure airport
Departure time
Arrival country code
Arrival airport
Arrival time
Flag code
Aircraft type code
Airline code
Flight number
Days of service
Taxi or intrastate flight flag
Effective date - date flight begins within period
Discontinue date - date flight ends within period
5.3.2 Schedule Data Processing
Airport and sector arrival times are required by the ATFMS in order to respond to traffic manager
requests for arrival and/or departure data for an airport and/or an ACC.
The ATFMS requires flight paths, ground speeds, and altitudes for scheduled flights to estimate the
impact that the flight will have on the ATM system long before a flight plan is received. For this purpose,
the ATFMS shall maintain a data structure of flight paths, cruising speeds, and cruising altitudes observed
in recent flight plans. As the ATFMS adds a scheduled flight into the live data structure, it shall use the
most commonly filed flight path, speed, and altitude for the flight's city pair, airline, and/or aircraft type.
86
If a flight in the scheduled data does not correspond to a recently received flight plan (i.e., for a new
flight), ATFMS shall use a direct flight path between the departure and arrival airports for the flight.
ATFMS constructs the flight path to look like a normal flight plan trajectory.
5.4 Flight Plan Processing
One of the most significant parts of the ATFMS is the processing that interprets the flight route from
the filed or amended flight plan. The flight route is specified as a sequence of fixes and routes,
which can each be described in a variety of ways. The ATFMS shall parse the flight route text and
translate it into a sequence of waypoints defined in latitude and longitude. ATFMS shall use the
waypoints of the flight path to present flight trajectories on the TSD and to model the effects of the
flight on airports, sectors, and fixes.
Geographical data is the main source of data required to process the flight route. The ATFMS shall
use the geographical data to look up the positions of airports, fixes, and airways referred to by name
in the flight route.
5.4.1 Flight route - Filed Flight Path
A Flight route describes a flight path as a sequence of fixes and routes. A fix field can contain one of
the following fix types:
Airport
Named fix (NAVAID or adapted)
Fix-radial-distance
Special Use Airspace name
Latitude/longitude
Flight Information Region (FIR) name
A route field may contain one of the following route types:
Airway
Fix-radial
DP
STAR
5.5 Flight Modeling
ATFMS flight modeling shall use the waypoint list produced by the Flight route processing along with the
other flight data to predict the impact of the flight on the airports, sectors, and fixes along its flight
path. The modeling of a flight consists of three steps: determining the altitude and speed profile of the
flight (i.e., what altitude and speed the flight will have at any point along its flight path); determining
the flight events; and computing the event times. The flight events are airport arrivals and departures,
sector entries and exits, ACC entries and exits, airway entries and exits, and fix crossings. Each flight
event is defined as the event type, the position in latitude and longitude, the speed and altitude of the
aircraft at the event, and the time of the event.
87
5.5.1 Flight Profile Modeling
The flight profile modeling estimates the altitude and speed of a flight as a function of its distance
from the origin or destination airports. For the purposes of profile modeling, a flight can be broken
down into three segments: the ascent phase, where the aircraft climbs from its origin airport to some
altitude; the en route phase, where the aircraft travels at some altitude and speed; and the descent phase,
where the aircraft descends to the destination airport. ATFMS shall use custom ascent and descent
profile data when it is available for a specific flight; otherwise, ATFMS will use the standard ascent
and descent profile data that is stored in the aircraft profile data structure.
5.6 Situation Awareness and Problem Identification
ATFM specialists require information on current and future system demand, along with information on
situations that will result in capacity reductions within the system for effective situation awareness and
ATFM problem identification. Some of this information will be based on data collected and reported in
real-time. The remainder will be generated through computer-based demand and capacity modeling.
5.6.1 Common Situational Awareness
The ATFMS shall support common situational awareness among ATFM specialists and between ATFM
specialists and qualified airspace users. Common situation awareness between ATFM specialists and
ATC supervisors and between ATFM specialists and qualified airspace user personnel will be maintained
by providing them with a shared knowledge of the following:
Current positions of airborne air traffic
Current sector/airspace/runway configurations
Current and predicted traffic loads for sectors and airports
Current and forecasted convective weather
Current and predicted instances of sector or airport capacity being exceeded by current or
planned aircraft demand
Special airport activities such as de-icing, closed runways, or taxi-way repairs/maintenance
that will reduce an airport’s operating capacity
Active and planned TMIs
Availability of military/special use airspace for civilian use
Special events that will result in higher than normal levels of traffic in a particular portion
of airspace or at a specific airport
Communication, surveillance or navigation equipment failures affecting ATC or ATFM
service delivery
Common aircraft situational awareness shall be accomplished by providing for the graphical display of
current and predicted aircraft positions on a plan view situation display that includes sector boundaries,
airways, fixes, sector and airport alert indicators, military airspaces, military airspace status, and weather
information. The display of current aircraft positions shall present the positions of all airborne flights
operating in India’s airspace, as detected by ATC surveillance systems. The display of predicted aircraft
positions shall present the future positions of aircraft that are airborne or scheduled to be airborne at the
specified future time. The user of the future traffic display function shall be able to display future aircraft
positions at any selected future time within a parameter planning horizon. The future traffic display shall
88
also support assessment of the impact of TMIs being planned by the CCC or ACC TMUs by providing
for the display of future aircraft positions associated with the TMIs being assessed.
Airspace users qualifying for access to AAI data shall not receive all of the data made available to ATFM
specialists. The CCC will be responsible for establishing the policies and qualifying criteria for airspace
user access to AAI data.
Common situational awareness will be enhanced further by the sharing of system capacity related
information. The ATFMS shall provide the means for collecting, processing, distributing and displaying
current or proposed resource capacity information, traffic management initiative information, and
resource configuration information, such as open and closed sectors, active runways at airports.
Stakeholders and the AAI shall have a standardized web-, video- and/or telephony-based infrastructure
for collaboration.
Common displays shall be available to all stakeholders to achieve common situational awareness.
Exchange of weather information among stakeholders shall be implemented in order to provide a more
predictable system.
Standardized message sets shall be developed to enhance interoperability and understanding.
5.6.2 Capacity Prediction
The ATFMS shall provide continually-updated capacity predictions. It shall provide the capability to
collect, analyze, project and display capacity information for all sectors, airports, and runways managed
by India’s ATFMS. Capacity predictions for airports shall be provided by the TWR controllers, based on
anticipated runway configurations, and the arrival and departure capacities associated with those
configurations. For TWRs with an ATFM unit, the capacity information shall be entered into the ATFMS
by the ATFM specialist. For TWRs without an ATFM unit, the capacity information shall be forwarded
to the TWR’s parent ACC TMU. Arrival and departure capacities shall be expressed in terms of flights
per hour, for specified hours of operations. For example, “arrival rate of 55 flights/hour (for both VFR
and IFR); for an airport configuration using runways 1, 4, and 33; anticipated between the hours of 1300Z
and 1700Z”.
For sectors, capacity shall be expressed in terms of an adaptable, static threshold that defines the
maximum acceptable aircraft loading (i.e., aircraft count) for a specified time interval (e.g., 10 aircraft for
a 15 minute time interval). The capacity value shall remain constant throughout that time interval. The
determination of sector loading values, for sectors within an ACC, will be determined through a
collaborative effort involving ATFM and ATC representatives from that ACC. The ATFMS shall provide
a capability for electronically receiving and storing forecast sector loadings for a minimum forecast time
horizon of six hours. The ATFMS shall provide the means for modifying stored forecast values, to
accommodate changes in weather, traffic complexity, or other factors that may reduce the number of
aircraft that could safely accommodated within a subject sector. Access to this modification capability
shall be limited to designated specialists in the ACC TMU, and controlled through function access
controls.
The ATFMS shall transmit, and make accessible for display, near-real-time and planning capacity data to
all appropriate traffic management specialists and make that capacity data accessible to ATFM
subsystems requiring that data.
5.6.3 Demand Prediction
The ATFMS shall support the continuous determination of flight demand on airport and ACC airspace
resources. Airspace resources shall include sectors, airways and fixes. The ATFMS shall capture the
89
predicted and actual demand on various ACC and airport resources. The predicted demand shall be based
on airline schedule data. To support demand prediction, the ATFMS shall also capture actual flight
demand, as scheduled flights may be cancelled, or new flights may be added on the day of operations.
ATFM specialists at all of the ATFM units, from CCC down to those selected TWRs with TMUs, shall
have access to real-time traffic demand counts and predictions. The ATFMS shall be capable of providing
that demand information in textual/list form and in a graphical representation that displays predicted
individual aircraft positions based on their intended flight trajectory. In generating updates to demand
predictions, the ATFMS shall include revisions made to airline schedules during the course of the day of
operations. The ATFMS shall generate and maintain separate traffic demand counts for flights with
statuses of scheduled, active, and airborne. Scheduled flights will consist of those flights that have flight
plans submitted to the CCC, but have not been activated for processing by an ACC. Active flights will
consist of those flights whose flight plans have been activated, but have not yet departed. Airborne flights
will consist of those flights that have departed and are being managed by ATC.
ATFM specialists at all of the ATFM units shall have the capability to select and display current and
forecast demand for a user specified resource (e.g., flights traversing a route during a specified time
period) on an on-demand basis.
5.6.4 Analyze Constraints
The ATFMS shall:
Input possible scenarios for future flight days.
Determine future flight day situations.
Predict the impact of imbalances found in future flight day scenarios.
Evaluate capacity and demand.
Analyze:
o Actual traffic saturation for selected airspace.
o Actual traffic saturation for selected aerodromes.
o Airspace capacity based on saturation information.
o Available aerodrome capacity based on saturation information.
o Flight restrictions for specific aircraft based on saturation information.
o Operational alternatives based on saturation information.
o Alternate trial rerouting of proposed aircraft flight plans to resolve or minimize saturation
conditions.
o Future flight day situations.
o Future flight day scenarios for imbalances in demand and capacity.
5.6.5 Congestion Identification and Reporting
The ATFMS shall provide the capability for identifying three types of congestion problems:
Airport demand/capacity imbalances
Airspace demand/capacity imbalances
90
Avoidance of unusable and undesirable air space
The ATFMS shall continually compare actual and predicted capacity and demand, and shall report the
results of these comparisons to ATFM specialists and to qualifying airspace users. In reporting cases
where anticipated demand is expected to exceed available capacity, the ATFMS shall:
Automatically transmit and display congestion alerts
Identify the time and specific location(s) where demand is predicted to exceed capacity at
an unacceptable level
Identify the specific aircraft involved in the demand/capacity imbalance, including their
current flight status (i.e., scheduled, active or airborne)
Quantify the extent of the demand/capacity imbalance
Within the CCC, ACC TMUs APP TMUs, and at the TWR TMU, specialists, who are assigned
responsibility for monitoring and identifying airspace/airport capacity imbalances shall have access to
capabilities for analyzing traffic demand on user designated volumes of airspace, airways or segments of
an airway, navigation fixes, or airports. A user designated volume of airspace could be a sector, airspace
affected by weather, or any arbitrary volume of airspace selected by a user. These capabilities shall
provide the user with aggregate and flight specific information on aircraft involved, and volume and
temporal characteristics of the predicted congestion. Flight specific information provided for aircraft
involved shall include planned/filed route and altitude information, times when the flight is predicted to
enter and exit the designated volume of airspace/airport, and controlling ACCs for the remainder of the
aircraft’s flight.
5.7 Collaborative Decision Making (CDM)
Collaborative Decision Making (CDM) is a joint government/industry initiative aimed at improving air
traffic management through increased information exchange among the various parties in the aviation
community using improved automated decision support capabilities.
5.7.1 Distributed Planning
Equitable access to appropriate ATFM data information by stakeholders, especially airlines, shall be
provided.
Rapid transmission of high bandwidth data shall be provided.
Schedules shall be updated at a frequency to be determined by the stakeholders.
Decisions made by the AAI or the airlines shall be disseminated to stakeholders.
5.7.2 Analytical Capability
The ability to collect pertinent data and store for future analysis shall be provided.
Analysis of data to translate the effects of TMIs into easily-understood products shall be performed.
The capability to perform “what if” analysis and to assess ATFM performance during any given time-
period shall be provided.
The capability to expand the “what if” analysis to allow predictive assessments of the effectiveness of a
given suite of TMIs shall be included.
91
5.7.3 Generate Solutions
The ATFMS shall:
Utilize impact assessment of possible future traffic flow management scenarios to develop new
traffic flow management strategy alternatives.
Analyze the impact of developed strategies for future flight days.
Coordinate traffic flow strategies.
Modify current flow strategies.
Generate
o Inter-facility traffic flow plans.
o Alternate plans to alleviate traffic flow problems
o Local flow restrictions
o Future flight day strategies.
Allocate available:
o Airspace capacity.
o Airport capacity.
5.8 Weather Data Processing
The primary role of aviation weather processing is to incorporate critical weather data affecting safety,
schedule efficiency, and user operations into trajectory prediction. Weather information, both now-cast
and fore-cast, shall be integrated with and support ATFMS decision-oriented automation capabilities and
human decision making processes.
Five major functional requirements exist to effectively use weather data in flight plan processing.
5.8.1 Common weather picture
The most important requirement for aviation weather data processing is to establish a reliable, common
weather data set from surface, airborne, and satellite sources. Establishing this weather data set requires
capabilities for:
The collation of weather data from available weather forecasting sources including the
output of different forecast model data structures into a consistent set of usable aviation
related data. A consistent set infers the same forecast conclusions are drawn regardless of
the model.
Dissemination of weather data, either by subscription (push) or demand (pull) to all
requesting users, including, but not limited to, AAI, airlines, and flight crews.
Transformation of weather data from global, regional and/or local forecasts into aviation
specific products depicting potential weather impacted airspace/airports (both now and
forecasted) and providing estimates of reduced capacity and/or current or predictive no fly
airspace.
Segmentation of data for the specific ATFM TMUs.
92
Aviation specific weather product use shall begin in the strategic phase of ATFM planning, using
climatology to permit up to at least a 3 month pre-flight planning window. It shall include pre-tactical
and tactical phases (from 72 hours and in) via reliable forecasts to allow for multiple pre-planned flight
plans and airspace configuration scenarios.
5.8.2 Reliable Weather Data Input Requirements
Convective weather predictive information shall be reliable enough to enable effective
proactive operational traffic flow management decisions.
Automated ability to assess the quality/reliability of weather information forecasts to actual
weather shall allow for continuous forecast and data quality improvement.
5.8.3 Update Frequency
Real time/near real-time data for tracking/scheduling shall have variable update rates
commensurate with the requirement to react to unanticipated, rapidly changing
circumstances.
Updates shall come from numerous sources and generate a constant stream of persistent and
convective weather products such as growth and decay predictions for the next segment of
time – nominally a two hour period. These updates shall be used to update and refine other
airspace tools.
Winds aloft and precipitation data update rate shall be determined as a function of routing
and dynamic weather change along planned routes.
Updates shall be required every 30 to 60 minutes during times of weather constancy.
Increased refresh rate shall provide meaningful weather updates when needed.
Alerts, advisories, and warnings regarding significant weather changes shall be proactively
disseminated as soon as they are known.
5.8.4 Weather Information Dissemination
Weather information shall be disseminated to the providers and users of the airspace system including:
All levels of the AAI organization
Airline and other fleet specialists
Provided in a format compatible with the user’s needs via templates that allow the
repository to structure the data per user.
It shall also ensure that:
o All end users have the same weather data.
o An alert notification feature provides for real-time weather alerts, advisories, and
warnings regarding significant weather changes
5.8.5 Tailored Weather Data
Weather information that is disseminated shall be tailored to the operational needs of those
interested parties, maintaining a consistent view of weather information.
93
Versatile weather products shall allow user defined requests that tailor information presentation
to the operational need of that user. This versatility:
Allows for different resolutions, time scales, and geographic areas for different users
viewing the same information (e.g., the information for an airport is at a higher
resolution and more rapidly updated than that for adjacent en route locations).
Filters weather information to deliver the specific information a particular user requires,
rather than sifting through volumes of information.
5.9 Flow Initiative Planning
ATFMS automation shall provide a set of capabilities for developing, evaluating and coordinating TMIs
among the organizations associated with the subject flow problem. Those organizations include the CCC,
one or more ACC TMUs, APP TMUs, TWR TMUs involved in the flow problem, and airspace users (i.e.,
military, airline and aircraft specialists). These flow initiative planning capabilities shall provide
automated decision support in the areas of TMI modeling, TMI impact assessment, and TMI coordination
and collaboration.
5.9.1 TMI Modeling
CCC and ACC TMU ATFM specialists responsible for defining TMIs will be provided with decision
support automation that will assist them in defining the specifics of desired TMIs. TMI modeling
capabilities shall support the definition of the following TMI types:
Table 3 - TMI Modeling Parameters
TMI Type
Modeled Parameters
Flight Level/Altitude
Adjustment
Required start and end time for the TMI
Required starting and ending location for the new altitude
Specific FEA/FCA to be covered by the TMI
New required altitude for each flight
Effect of altitude change on each flight’s flight time and route length
Combined effect of TMI on projected sector aircraft loadings
94
TMI Type
Modeled Parameters
In-trail Spacing
Required start and end time for the TMI
Required location where the required spacing is to be executed, typically a
sector or ACC boundary crossing, a specified fix location, or a specified
destination airport
For distance-based In-trail Spacing (Miles-in-Trail/MIT), the number of
miles required between aircraft that meet a specific criteria. The criteria may
be separation, airport, fix, altitude, sector, or route specific
For time-based In-trail Spacing (Minutes-in-Trail) the number of minutes
required between aircraft that meet a specific criteria.
Effect of spacing TMI on each flight’s planned flight time
Combined effect of TMI on projected sector aircraft loadings
Reroutes
Required start and end time for the TMI
Specific FEA/FCA to be covered by the reroute TMI
Required route change for the reroute TMI
Effect of required route change on each flight’s flight time and route length
Combined effect of TMI on projected sector and airway aircraft loadings
Fix balancing
Required start and end time for the TMI
Specific FEA/FCA to be covered by the fix balancing TMI
New/assigned fix for each aircraft, for the load balancing
Effect of route change on each flight’s flight time and route length
Combined effect of TMI on projected sector and fix aircraft loadings
Airborne Holding
Required start and end time for the airborne holding
Planned location for holding
Specific FEA/FCA to be covered by the airborne holding TMI
Effect on each flight’s flight time and route length as a result of the TMI
Combined effect of TMI on projected sector aircraft loadings
95
TMI Type
Modeled Parameters
Sequencing and Spacing
Initiatives (Departure,
Arrivals, En route)
Required start and end time for the TMI
Specific FEA/FCA or fix or other airspace object to be covered by
sequencing TMI
For Departure Sequencing: Target departure fix; Desired interval between
aircraft; Departure times per flight to achieve the desired constant flow over
a common departure fix; Departure airports included
For Arrival Sequencing: Target arrival fix; Desired interval between aircraft;
Fix crossing times per flight for aircraft destined to the subject arrival airport
For En Route Sequencing: Designated merge fix; Desired interval between
aircraft; Departure times per flight that will facilitate integration into the en
route stream at the designated merge fix
Effect of sequencing delay on each flight’s flight time
Combined effect of TMI on projected fix and sector aircraft loadings
Ground Delay Programs
(GDP)
Required start and end time for the GDP
Geographical scope of the GDP
Arrival airport that is the focus of the GDP
Departure airports included in the GDP
ACCs affected by the GDP
Specific flights to be covered by the GDP TMI
Revised departure time for each flight subject to the GDP
Airline flight cancellations and substitutions
Revised arrival times for each flight subject to the GDP
Ground Stops (GS)
Anticipated duration of the GS
Aircraft or geographic criteria for selecting the aircraft to be covered by the
GS
Geographical scope of the GS
Arrival airport that is the focus of the GS
Departure airports included in the GS
ACCs affected by the GS
Specific flights to be covered by the Ground Stop TMI
Combined effect of GS on subject arrival airport’s arrival demand levels,
sector aircraft loadings
96
TMI modeling capabilities shall provide for the graphical display of modeled In-trail Spacing, Reroutes,
Fix balancing, Airborne Holding, and Sequencing and Spacing (Departure, Arrivals, En route) TMIs on a
traffic situation display. Graphical or tabular data presentation techniques shall be used to show the results
of Reroute, Ground Delay Program, Ground Stop, or Flight Level/Altitude Adjustment TMI modeling
efforts.
To support reuse of TMIs that address problems that occur frequently, the TMI modeling capability shall
allow the user to store modeled TMIs; retrieve them when desired; and, make modifications to retrieved
TMIs before assessing their potential impact.
5.9.2 TMI Impact Assessment
CCC and ACC TMU ATFM specialists defining TMIs will also be responsible for evaluating their
effectiveness in resolving the subject flow problem. TMI impact assessment capabilities will be provided
to assist them in carrying out this responsibility. The TMI impact assessment capability shall allow the
user to evaluate the predicted effects of a modeled TMI before it is implemented. Measures of impact
shall be specific to the type of TMI being evaluated. For instance, evaluation of proposed Ground Delay
Programs will address the number of flights affected, total and individual flight delay that will result, and
airport arrival demand reductions over time. Measures of impact for en route oriented TMIs such as In-
trail spacing or airborne holding will address en route-related measures such as changes in sector traffic
demand, traffic density levels, airway loading, and flight time and travel changes for affected flights.
To facilitate the interpretation of impact assessment, results shall be quantified. For In-trail spacing,
Reroutes, Fix balancing, Airborne Holding, and Sequencing and Spacing initiatives (Departure, Arrivals,
En route) TMIs, results shall be presented in graphical as well as tabular form.
For TMIs that will change the route or future projected en route position of aircraft, the impact assessment
capability shall provide for the graphical representation of projected future positions of aircraft that are
part of the TMI. The impact assessment capability shall also provide for the graphical display of projected
changes to traffic demand levels for sectors, airways, fixes and other airspace related resources.
5.9.3 TMI Coordination and Collaboration
To facilitate the coordination and collaboration activities that must take place in the TMI planning and
approval process, information sharing capabilities shall be provided for the person in charge of the
approval process. Those capabilities shall include the capability:
To select the graphical, tabular or textual information that person needs for a coordination
or collaboration discussion.
To select the individuals or TMU positions this information is to be shared with.
To conduct controlled access teleconferences, chat sessions, or video conferences.
For electronic sharing of TMI planning information with all facilities and airspace users
who will be affected by a TMI under discussion. TMIs to be covered include all of those
listed in Table 3.
5.10 TMI Implementation
Once a strategy and associated TMIs have been agreed upon, there is the need to implement that strategy
in a timely way. This requires disseminating the specifics of the strategy to the appropriate personnel and
decision support systems. A single strategy will consist of action(s) that may include one or more TMIs.
The ATFMS will support TMI implementation in a number of ways. The ATFMS shall provide the
means for:
97
Designating who is to receive information about the strategy
Electronically communicating the elements of that strategy (i.e., TMIs, reasons for the
TMIs, start and stop times, affected AAI facilities and airspace users, exceptions) to the
appropriate:
ATFM specialist workstation or workstations
CCC decision support system and/or data structure
ACC TFM decision support system and/or data structure
ATC workstation or workstations
ATC decision support system and/or data structure
Airspace user data portal (airspace users will be responsible for routing TMI implementation information
to their appropriate decisions support systems and staff workstations)
Internet access to allow for e-mail and/or web site data sharing (e.g. SharePoint)
5.10.1 Communication and Distribution of Initiatives
The ATFMS shall use available or planned AAI communication infrastructure and systems for the
distribution of TMI advisories or directives, wherever possible. New communication capabilities shall be
implemented to support information exchange requirements that cannot be satisfied with available or
planned AAI communication infrastructure and systems. The implemented communication distribution
system shall:
Support the distribution of TMIs between ATFM units and the associated ATC unit
supervisors located in their facility.
Enable the collection of required ATFMS input data from various sources
5.10.2 TMI Monitoring and Evaluation
Whenever a TMI is implemented, the CCC and TMUs who assisted in that implementation will be
responsible for determining if the TMI is resolving the flow problem as anticipated. ATFM automation
shall support the real-time monitoring and evaluation of the effectiveness of TMIs after they are
implemented. If a TMI is found to be ineffective or too restrictive in satisfying its intended objectives, the
ATFM specialist involved in its creation and monitoring will be responsible for either changing elements
of the TMI to improve its effectiveness or terminating the TMI. Decision support capabilities will be
provided to support those duties. Those decision support capabilities shall:
Continuously assess the conditions that led to the decision to implement a TMI
Present quantified measures of the effectiveness of the TMI in meeting objectives
Present alarms or other forms of notification to warn ATFM specialists that desired changes
in traffic levels are not being achieved
5.10.3 TMI Termination
TMIs will be terminated when they achieve their desired objectives or it is determined through system
monitoring and evaluation that they are ineffective in achieving those objectives. For both cases, the CCC
shall have the means to communicate, through automation, a directive to terminate a TMI. Automated
TMI ATFM decision support capabilities shall provide for the automatic formatting and routing of
termination directives to the appropriate ATFM personnel, ATC personnel and airspace users.
98
5.11 Information Management
Information management shall be used to provide appropriate and timely information to all parties
engaged in India’s ATFMS, while simultaneously ensuring that only appropriate software elements and
authorized system users are engaged in that information exchange process.
5.11.1 Automated Collection and Distribution
The ATFMS shall automatically collect and distribute the necessary elements of information for
appropriate ATFM decision makers and information consumers.
The ATFMS shall be designed in an open and flexible manner that will enable collection of various types
of aviation data relevant to ATFM. In addition, the system shall standardize the process of adapting and
ingesting new data sources so that new data that is vital to the use of the system can be easily integrated.
The ATFMS shall distribute data to end users as necessary to support decision support tools, analytical
data collection systems, external system tools and users, and other consumers as necessary to satisfy the
system’s requirements. The design of information distribution shall open and flexible to allow for ease of
integrating new data sources and new data consumers. Although such an enterprise level system will have
many different consumers of the distributed data, the method for distributing information shall be
standardized so that system maintenance is efficient.
5.11.2 Data Recording
The ATFMS shall provide for recording, archiving, and analysis of ATFM operational data.
The ATFMS shall record operations data to support training, historical analyses, modeling, and reference,
and for dynamic application for near-term flow planning and management. The system's data shall be
available to authorized users in near-real time. It will provide a standard interface capable of supplying
operational data to other AAI organizations and systems as well as providing information resources to
system users and/or other governmental organizations. Recording, storage, collection and communication
servers will be strategically located at collector sites such as Area Control Centers and selected approach
and tower facilities, with a central data administration, collection, and archiving function at the CCC.
5.11.3 System Performance Assessment
In order to achieve the organizational maturity of continual improvement, the ATFMS shall have the
ability to collect information and to provide system efficiency metrics based on this information in a post-
operational setting. The system shall enable system specialists to monitor and analyze system
performance. This monitoring shall enable an specialist, on the day following operations, to determine
whether operational decisions improved system efficiency. The system shall allow for both high level
performance assessment and detailed analysis of local congestion points.
The system performance assessment information shall be available to all users of the system.
5.12 ATFMS Training
In general, AAI shall provide for a training program which prepares specialists for the transition to new
ATFMS equipment, computer software, and procedures and which results in the continuous and
progressive improvement in the skill level of specialists.
The training program will train ATFM specialists (Traffic Management Coordinators) at the
various AAI ATFM facilities using the current equipment and supplying training materials.
99
Effective daily use and application of the various ATFMS functions will require training at locations
where those functions are installed and normally accessed. To facilitate that training, the ATFMSs shall
be able to operate using either archived or real-time data. Operation of the ATFMS with archived data
(hereafter referred to as the training mode) will allow operational hardware and software at an ATFM
position to be used for:
Familiarization and proficiency training on the decision support functions at an ATFM
position
Training of new personnel or personnel assuming new roles
Refresher training
When an ATFMS unit is operated in the training mode, functions receiving and processing previously
stored/archived data shall operate in the same way when receiving and processing real-time data.
However, when in the training mode, transfer of data to other systems shall be inhibited. Despite the
inability to share data between workstations, the training mode will still support training on individual
ATFMS functions and operational applications of those functions.
When a workstation is configured in the training mode, it shall allow an instructor to:
Retrieve archived data (e.g.,, flight, airspace, weather, winds, airport.) needed to support a
training exercise
Configure the workstation by designating the airspace and flights to be used in the training
session
Disable the subject workstation from interacting with the operational/real-time system
When a workstation is configured in the training mode, it shall allow a student to:
Access all of the functions associated with flight plan processing, situation awareness and
problem identification, weather data processing, flow initiative planning, information
management and infrastructure support
When in training mode a workstation can operate either one of the following two modes but
not both at the same time:
o Operate on archived data as it was real time data and allow execution of all
functions including creating and executing TMIs.
o Use real time data planning and set up TMIs but not actually executing them on the
live system.
When in the training mode, a workstation shall provide the same level of performance provided when
operating in the real-time/normal operating mode.
5.13 System Performance
The ATFMS hardware and software shall operate at sufficient speed to be able to process flight data
information arriving at one minute intervals for 6,400 flights. In addition there shall be sufficient reserve
processing power to accommodate all user requests within 0.2 seconds.
The ATFM system shall be capable of updating all situational data within one minute. The alert functions
of the ATFM system shall be made known to the users at the CCC, ACC TMU, APP TMU and the TWR
TMU within 0.2 seconds of being calculated. There shall be sufficient processing power to calculate
capacity/demand values and alerts for all system functions. There shall be sufficient processing power to
process 50 TMIs concurrently.
100
Specifically, the ATFMS shall:
Approve special use airspace reservations within 30 minutes of initial receipt of request.
Disapprove special use airspace reservations within 30 minutes of initial receipt of request.
Terminate ground-based navigation guidance, whose performance is outside of the acceptable
parameters within 10 seconds of detection.
Display geographical structure information to within .26 NMI (99th percentile) of its actual
position.
Utilize map outlines of runways that are accurate to within 12 feet of the actual edges of the
runways.
Use map outlines of taxiways that are accurate to within 12 feet of the actual edges of the
taxiways.
Assure ground-air transmission time for data messages not exceed 6 seconds.
Provide retrievable air-ground data messages within 30 minutes and from "off-line" storage
within 60 minutes.
Provide a capability for automatic track initiation and flight plan association in the backup
airspace within 60 seconds of an ACC failure.
Provide a capability for implementation of the backup operation within two minutes of an ACC
failure.
Restore routine system service to users/specialists within 1.68 hours of failure.
Restore essential system service to users/specialists within 10 minutes of failure.
Display airspace structure information to within .26 NMI (99th percentile) of its actual position.
In addition, the ATFMS shall disseminate:
Current flight activity information in military special use airspace within 1 minute of request.
Scheduled flight activity information in military special use airspace within 1 minute of request.
Requested aeronautical information to specialists within:
A mean response time of 3.0 seconds of the request.
A 99th percentile response time of 5.0 second of the request.
Requested flow control advisory information to:
Users within a mean response time of 3.0 seconds of the request.
ATFM specialists within a mean response time of 3.0 seconds of the request.
CCC specialists within a mean response time of 3.0 seconds of the request.
Requested delay advisory information to:
Users within a mean response time of 3.0 seconds of the request.
CCC specialists within a mean response time of 3.0 seconds of the request.
ATFM specialists within a mean response time of 3.0 seconds of the request.
101
The results of CCC requested :
Capacity projections within a mean response time of 3.0 seconds of the request.
Demand projections within a mean response time of 3.0 seconds of the request.
The results of ATFM specialist:
Capacity projection requests within a mean response time of 3.0 seconds of the request.
Demand projection requests within a mean response time of 3.0 seconds of the request.
Horizontal position information to ATFM specialists with an accuracy:
Of 2.04 (99th percentile) nautical miles for target ranges greater than 100 NMI of the primary
surveillance detector.
Greater than 1.0 (99th percentile) nautical miles for targets within a range up to 100 NMI of the
primary surveillance detector.
To the ATFM specialist, requested aircraft:
Track with accuracy greater than 5 degrees for in straight-line flight.
Speed with accuracy greater than 20 knots for an in constant straight-line flight.
Position information within a mean response time of 3.0 seconds of a request.
Altitude information within a mean response time of 3.0 seconds of a request.
Speed information within a mean response time of 3.0 seconds of a request.
Heading information within a mean response time of 3.0 seconds of a request.
CCC specialist requested aircraft position predictions within a mean response time of 3.0 seconds
of the request.
Results of future flight day capacity projection requests to:
CCC specialists in no more than 10 seconds of a request
ATFM specialists in no more than 10 seconds of a request.
Requested aeronautical information to:
Specialists within a maximum response time of 10.0 seconds of the request.
Users within a mean response time of 3.0 seconds of the request.
Users within a 99th percentile response time of 5.0 second of the request.
Users within a maximum response time of 10.0 seconds of the request.
Requested flow control advisory information to users within:
A 99th percentile response time of 5.0 seconds of the request.
A maximum response time of 10.0 seconds of the request.
Requested delay advisory information to:
Users within a 99th percentile response time of 5.0 seconds of the request.
Users within a maximum response time of 10.0 seconds of the request.
102
ATFM specialists within the 99th percentile response time of 5.0 seconds of the request.
ATFM specialists within a maximum response time of 10.0 seconds of the request.
Requested flow control advisory information to:
ATFM specialists within the 99th percentile response time of 5.0 seconds of the request.
ATFM specialists within a maximum response time of 10.0 seconds of the request.
CCC specialists within the 99th percentile response time of 5.0 seconds of the request.
CCC specialists within a maximum response time of 10.0 seconds of the request.
Requested delay advisory information to CCC specialists within:
The 99th percentile response time of 5.0 seconds of the request.
A maximum response time of 10.0 seconds of the request.
Results of CCC requested capacity projections within:
The 99th percentile response time of 5.0 seconds of the request.
A maximum response time of 10.0 seconds of the request.
Results of CCC requested demand projections within:
The 99th percentile response time of 5.0 seconds of the request.
A maximum response time of 10.0 seconds of the request.
Requested aircraft position information to ATFM specialists within:
The 99th percentile response time of 5.0 seconds of a request.
A maximum response time of 10.0 seconds of a request.
Requested aircraft heading information to ATFM specialists within:
The 99th percentile response time of 5.0 seconds of a request.
A maximum response time of 10.0 seconds of a request.
Requested aircraft speed information to ATFM specialists within:
The 99th percentile response time of 5.0 seconds of a request.
A maximum response time of 10.0 seconds of a request.
Requested aircraft altitude information to ATFM specialists within
The 99th percentile response time of 5.0 seconds of a request.
A maximum response time of 10.0 seconds of a request.
CCC specialist requested aircraft:
Position predictions within the 99th percentile response time of 5.0 seconds of the request.
Aircraft position predictions within a maximum response time of request of 10.0 seconds of the
request.
Altitude predictions within the 99th percentile response time of 5.0 seconds of the request.
103
Altitude predictions within a maximum response time of request of 10.0 seconds of the request.
Speed predictions within a mean response time of 3.0 seconds of the request.
Speed predictions within the 99th percentile response time of 5.0 seconds of the request.
Heading predictions within a maximum response time of request of 10.0 seconds of the request.
Heading predictions within a mean response time of 3.0 seconds of the request.
Heading predictions within the 99th percentile response time of 5.0 seconds of the request.
Aircraft speed predictions within a maximum response time of 10.0 seconds of the request.
The ATFMS shall also alert:
Users not more than 10 seconds after any failures of navigation guidance affecting operations
within the ATFMS.
Users not more than 10 seconds after any failures of portions of navigation guidance affecting
operations within the ATFMS.
Specialists not more than 10 seconds after any failures of portions of navigation guidance
affecting operations within the ATFMS.
Specialists not more than 10 seconds after any failures of navigation guidance affecting
operations within the ATFMS.
Users within 10 seconds, of failures to navigation guidance that affect operations.
Specialists within 10 seconds, of failures to navigation guidance that affect operations.
Users within 10 seconds, of failures to portions of navigation guidance that affect operations.
Specialists within 10 seconds, of failures to portions of navigation guidance that affect operations.
Individual air-ground data messages shall be retrievable from "off-line" storage within 5 minutes of a
request by authorized ATFMS personnel.
5.13.1 Communication
Communications capabilities shall be sufficient to support all ATFM specialists and users at all locations
with a 20% cushion over peak demand to support future expansion.
Specifically, The ATFMS shall:
Disseminate voice information between ATFM specialists and ATC specialists.
Exchange data flow control information between ATFM specialists and ATC specialists.
Be capable of exchanging airport utilization data and scheduled airline data, in both voice and
data formats.
Automate communications capabilities to reduce specialist and user workload.
Configure communications to support changes in operating position responsibilities.
Support peak busy hour exchange of data including short-term peaks that may occur within the
peak hour, with minimal change in the data transmission response times and no loss of data.
104
Reconfigure communication capabilities to support changes in operating responsibilities.
Configure communications for to provide the ACC’s redundant connectivity for ATFM data.
In addition, the ATFMS shall provide:
Voice connectivity between the ACC TFM specialists and the CCC specialists.
Voice connectivity between the CCC specialists and the ACC TFM specialists.
Data connectivity between the CCC specialists and the ACC TFM specialists.
Data connectivity between selected air traffic control facilities and the CCC.
Connectivity between the CCC and the military scheduling facilities.
Data channels in the frequency band appropriate for air-ground data communications equipment
for data communications coverage for both civil and military users.
Intelligible air-ground voice communications.
One channel modular expansion and/or one position at a time for ACC, APP and TWR air-ground
voice and data communications
Reconfiguration of communications capabilities without degradation of air-ground voice or data
communications.
Intelligible inter-facility voice communications.
Communication between and within the various ATFMS facilities.
Communication between selected operating, supervisory, maintenance, and administrative
positions within or between ATFMS facilities.
Direct-access voice communications capabilities between specified positions within ACCs, APPs,
TWRs, and the CCC.
The ATFM specialist to force urgent direct-access or indirect-access inter-facility and intra-
facility calls through to a busy receiver by overriding the existing call.
Queuing of indirect-access and direct-access inter-facility and intra-facility voice transmissions
entering the ATFM position.
An inter-facility data communications at each ACC facility and the CCC.
Inter-facility voice and data communications modular expansion.
Reconfiguration for distribution of inter-facility and intra-facility communications to permit an
ACC to service in airspace normally served by a failed ACC.
Computer assisted and/or supervisory control of the reconfiguration capabilities for inter-facility
and intra-facility data communications at designated specialist positions within an ACC, APP, or
a TWR.
Processing and communications capacities to support the required backup capabilities.
Appropriate voice and data communications connectivity between designated military facilities
and designated backup ACCs.
Configurable communications.
Data communications capabilities between ATFMS facilities.
105
The ATFMS shall also exchange:
Voice information between CCC specialists.
Scheduled airline data in voice communication format.
Scheduled airline data in data communication format.
Airport utilization data in voice communication format.
Scheduled airline data with Airlines
Airport utilization data in data communication format.
5.13.2 Reliability
The MTBF for ATFMS functions with:
Automatic recovery requirements and whose recovery time is less than the Automatic
Recovery Time shall be equal to or greater than 300 hours.
Automatic recovery requirements and whose recovery time is greater or equal to the
Automatic Recovery Time shall be equal to or greater than 50,000 hours.
5.13.3 Maintainability
The ATFMS shall restore:
Essential services within 10 minutes of failure.
Routine services within 1.68 hours of failure.
The Mean Time to Restore (MTTR) for ATFMS components shall be less than or equal to 0.5
hours.
5.13.4 Availability
Essential ATFMS Capabilities shall have availability equal to or greater than to .999.
Routine ATFMS Capabilities shall have availability equal to or greater than to .99.
5.13.5 System Recovery and Data Backup
System recovery is accomplished by having a “hot backup” which is a second complete system always
receiving the same data as the “operational” system and processing it at the same time. This is required
because it would take too much time to bring up a cold system and get it operationally ready by loading
all of the required data.
106
Section 6. Design and Construction
6.1 Accessibility
All system equipment shall meet the accessibility requirements of FAA-G-2100, paragraph 3.1.1.1
and 3.1.2.4.
The accessibility requirements of FAA-G-2100 paragraph 3.3.3.4 shall be satisfied by all newly
developed equipment.
The design of the equipment and equipment racks shall provide front or rear access or both, as needed
to support maintenance or repair activities.
All system equipment shall be maintainable by a work force with anthropometric and bio-mechanic
characteristics in accordance with HFDS-001, 2003, Section 14, Anthropometry and biomechanics,
published by the FAA William J. Hughes Technical Center, as amended.
No removable component shall weigh more than the maximum limits allowed for objects lifted by
one person using both hands as indicated in Exhibit 4.2.2.1 titled Maximum weight limits for objects
lifted by one person using both hands of the HFDS-001, 2003, unless mechanical devices are
provided for all necessary handling (e.g., carts, handles, etc.).
Where mismating of connectors could cause physical or electrical damage, positive means shall be
provided to prevent the inadvertent reversing or mismating of fittings, couplings, mechanical linkage,
instrument leads, or electrical connections.
Handles or suitable grasping mechanisms shall be provided for equipment units that require lifting,
removal, carrying or handling in accordance with the HFDS-001, 2003, Section 4.2.5, Handles.
The Uniform Federal Accessibility Standard (UFAS) FED-STD-795 shall apply to the design of
system workstations and facilities.
The Accessibility Standards as from Section 508 of the Rehabilitation Act of 1973, found at
http://www.access-board.gov/news/508-final.htm and http://fast.faa.gov/procurement_guide/html/3-2-
2.htm#5 shall apply to the design of system workstations and facilities.
USC 794D, The Rehabilitation Act Amendments (Section 508) shall apply to the design of system
workstations and facilities.
6.2 Space Allocation
The system equipment, not including peripheral support components, shall be configured such that the
equipment fits into the TMU.
The layout of the system equipment shall consider the equipment access and safety dimensions in
accordance with NFPA 70.
6.3 Structural and Seismic Stability
All equipment and equipment enclosures shall be designed and installed in accordance with FAA G-2100,
paragraphs 3.2.1.1 and 3.3.5.
107
6.4 Operational Design Considerations
6.4.1 Energy Conservation
The system shall meet the energy conservation requirements of the National Energy Conservation Policy
Act through compliance with Executive Order 12902, Energy Efficiency and Water Conservation At
Federal Facilities, The Energy Policy Act of 1992.
6.4.2 Acoustic Noise
The aggregate noise level for the system equipment procured for use in operational areas, measured at a
distance not greater than three (3) feet, shall be less than or equal to 55dbA and in accordance with 29
CFR 1910.95 and FAA-G-2100, paragraph 3.3.6.1.
The aggregate noise level for the system equipment procured for use in equipment areas, measured at a
distance not greater than three (3) feet, shall be less than or equal to 65dbA and in accordance with 29
CFR 1910.95 and FAA-G-2100, paragraph 3.3.6.1.
6.4.3 Operating Environment
The environmental limits specified in this section are for the steady state and shall apply to both forced air
and ambient air cooled systems.
Equipment that requires forced air cooling shall operate using under-floor, positive-pressure at a nominal
0.02-0.05 inches of water.
The system shall continuously operate, while maintaining Reliability and Maintainability requirements,
over the range of +16 degrees Celsius to + 29.4 degrees Celsius ambient temperature.
All system equipment shall continuously operate, while maintaining Reliability and Maintainability
requirements, over the range of 20 percent to 80 percent relative ambient humidity.
The system shall continuously operate, while maintaining Reliability and Maintainability requirements,
over the altitude range of 0 to 7000 feet above mean sea level.
6.4.4 Non-Operating Environment
108
System equipment exposed to any combination of the conditions specified below for a period of 96 hours
or less with power off and in the absence of an operational environment shall support operation without
degraded performance immediately after application of power and return of the environment to the
operations:
Temperature range of +10 degrees Celsius to +43 degrees Celsius, and
Relative humidity range of 20 percent to 80 percent.
6.4.5 Heating, Ventilation, Air Conditioning
Each cabinet requiring forced air ventilation shall contain its own blower system.
Each cabinet requiring forced air ventilation shall require no external ducts.
The equipment shall operate continuously without malfunctioning for up to eight (8) consecutive hours
with the access doors open, cover plates removed and drawers extended for servicing.
Cooling supply air shall be either from under the raised floor through openings located in the bottom of
the cabinet or from the ambient through openings or baffles located at floor level by removal of cover
plates.
Supply air openings in equipment cabinets shall be provided with air filters.
Exhaust shall be through openings located at the top of the equipment cabinets.
Cabinets shall be designed so that equipment exhaust presents no safety hazards to personnel in
accordance with MIL-HDBK-454A, Guideline 1.
6.4.6 Grounding, Bonding, Shielding, and Lightning Protection
The system shall meet all necessary FAA-STD-019D, Lightning Protection, Grounding, Bonding, and
Shielding for Facilities
The system grounding shall be in accordance with Section 3.80F FAA-STD-020B.
Note: AAI will furnish the multi-point ground system at all sites and the AC power ground at all sites.
The system shall be designed to avoid ground loops and shared impedance-coupling paths.
109
A common ground derived from the AC power source shall be used for all AC power in the system.
All surfaces of front panels, chassis, frames and cabinets shall have a common ground potential.
6.4.7 Cables
Cabinet and frame pre-wiring shall be complete even though the number of cabinets or frames used to
satisfy the capacity requirements specified at each site may not include a full complement of equipment or
modules.
Cables and cable routing systems shall comply with the NFPA 70, FAA-C-1217F, U.S. DOT FAA
Specification Electrical Work, Interior and applicable IEEE/ANSI standards.
Cabinet/frame cabling and wiring shall comply with FAA-G-2100, paragraph 3.3.1.3.10, the NFPA 70
and FAA-C-1217F.
Cable access shall be through the bottom of the cabinet or frame via the raised floor plenum.
Note: Where cable length is considered a critical factor in circuit performance, interconnecting cables
may be placed at least six inches above the top of the raised floor, through side walls of adjacent cabinets
or frames, as long as expandability is not compromised.
System equipment, frames, cabinets, enclosures and transition racks shall contain mechanical provisions
for cable strain relief in compliance with FAA-G-2100, paragraphs 3.3.1.2 and 3.3.1.3.
All cabinet/frame cabling shall permit accessibility to equipment for test, maintenance and replacement.
6.4.8 Hazardous Materials
Laboratory Certification
All COTS and developed equipment shall meet the requirements of, or be listed by, a testing laboratory
recognized by OSHA.
110
6.4.9 Power Systems and Commercial Power
Facility Power
The system shall use facility power compliant with an essential system.
Load Balancing
Load balance shall be achieved during equipment installation in accordance with FAA-G-2100, paragraph
3.1.1.4.
System loads shall be distributed among the AAI designated power panels to achieve load balance and
power redundancy, as approved by AAI.
Power Quality
The system’s limits for Inrush Current, for over current and duration, shall comply with FAA-G-2100,
paragraph 3.1.1.3.2, and Figure 2, Inrush Current Limit Ratios, for loads greater than 40A and equal to or
less than 80A.
The limits for system loads with power requirements of 40A or less shall comply with the values shown
in FAA-G-2100, paragraph 3.1.1.3.2, and Figure 2, Inrush Current Limit Ratios.
The power voltage tolerances for developed and commercial equipment shall be in accordance with FAA-
G-2100, paragraph 3.1.1.7.
The power factor for COTS and developed equipment shall be .6 lag to .7 lead in accordance with FAA-
G-2100, paragraph 3.1.1.3.1.
All equipment including the aggregate of multiple hardware items combined on a single power circuit
shall not exceed the limits listed in FAA-G-2100, paragraph 3.1.1.5, and Table I, Limits of Individual
Harmonics, as measured at the input side of the power panel.
For developed hardware, electrical overload protection shall be in accordance with FAA-G-2100,
paragraph 3.1.1.6.
Power Switches/Breakers
All power switches/breakers shall meet the requirements of the NFPA 70 and UL-1950.
Switches/breakers shall be listed by an OSHA approved testing laboratory.
111
Rack Power
All COTS and developed equipment shall be designed to operate on 120/208V AC, 60 Hz, and single-
phase 3-wire or 3-phase 4-wire power.
All rack assembly equipment shall operate from two separate 208V, 60 Hz power sources when redundant
hardware devices are contained in the rack or one 208V, 60Hz power source when non-redundant
hardware devices are contained in the rack.
All critical power receptacles shall be twist locks that are compliant with National Electrical
Manufacturers Association (NEMA) Standards Publication No. WD.6.
The critical power receptacles for the equipment racks shall be located below the raised floor and in close
proximity to the racks they serve.
All receptacles and power cords shall be in accordance with FAA-G-2100, paragraph 3.1.1.1.
AC convenience outlets, separate from the equipment critical power source, shall be provided for all
cabinets and frames in accordance with FAA-G-2100 paragraph 3.1.1.1.1f.
System equipment and critical power cable connectors shall be mechanically retained in place.
6.4.10 Electromagnetic Interference (EMI) / Electromagnetic Compatibility (EMC)
General
All commercial equipment shall meet the requirements of Federal Communications Commission (FCC)
Class A, (47 CFR Part 15) or better.
All developed hardware shall meet the requirements specified in FAA-G-2100, paragraph 3.3.2 and MIL-
STD-461E paragraph 5.3, as they relate to hardware emissions and susceptibility.
All AC power cables and wiring within the system shall be shielded from the data circuits.
EMI Emissions
The system, whether standalone or in racks, whether commercial or developed, shall not degrade other
NAS equipment.
112
All developed equipment shall meet the radiated emission limits of MIL-STD-461E, paragraph 5.3.
Any NAS equipment modified by the addition of COTS that meets the requirements of FCC Class A, (47
CFR Part 15) shall be deemed as meeting the radiated emission limits of MIL-STD-461E, paragraph 5.3.
EMI Susceptibility
The system, whether standalone or in racks, whether commercial or developed, shall not be degraded by
other NAS equipment.
All developed equipment shall meet the conducted susceptibility requirements of MIL-STD-461E,
paragraph 5.3.
6.4.11 Special Considerations
Equipment Workmanship
The system shall meet the workmanship standards of MIL-HDBK-454A, Guideline 9.
Note: A contractor workmanship standard deemed acceptable by AAI may be substituted for MIL-
HDBK-454A, Guideline 9.
The use of soft wires on production-level printed circuit boards shall be prohibited without prior approval
by AAI.
Finish and Color
Exposed surfaces shall be finished to resist wear and scuffing.
Equipment surface textures shall be easily cleaned.
All surfaces shall be free of rough, ragged, or sharp protrusions.
Cabinet and Frame Design Construction
The maximum dimensions of the room cabinets and frames shall be: height of 79 inches (2.01 meters)
above the raised floor; width of 49.5 inches (1.26 meters); depth of 37.125 inches (0.94 meters).
The loading conditions of each fully equipped cabinet and frame shall not exceed 125 pounds per square
foot.
113
The structural strength and rigidity of the cabinets and frames shall be such that normal handling in
loading, shipping, unloading and setting into position during installation will not result in any damage to
the equipment housed within the cabinet.
No deformation to the cabinets or frames shall occur as the result of removal or interchanging of
equipment or modules.
Cabinets or frames shall meet structural strength and rigidity requirements without contributory affects of
access doors.
Labeling
All cable connectors furnished on the equipment for making external connections shall be clearly
identified on the plug-in side by word labels descriptive of their specific function and by the proper
reference designation in accordance with FAA-G-2100, paragraph 3.3.1.3.
If labels are used as the positive means to prevent the inadvertent reversing or mismating of fittings,
couplings, mechanical linkage, instrument leads, or electrical connections, adjacent connections shall be
of different colors and approved by AAI.
Equipment labeling and redundant subsystem hardware configurations shall meet the requirements of the
HFDS-001, 2003, Section 6.1.2, Labeling and Marking Controls.
Note: Individual components such as switches have vendor markings but when multiple switches are
assembled together in a chassis or rack, additional identification labels are needed for maintenance
tasks. Specific labeling is needed to identify series number and/or redundant subsystem label.
Safety labeling shall meet the requirements of the HFDS-001, 2003, Section 12.16, Safety Labels and
Placards.
114
Section 7. Verification
7.1 Methods of Verification
7.1.1 General
This section defines a set of qualification methods for requirements in this System Specification.
7.1.2 Requirement Verification by Demonstration
Verification will be accomplished by operation, adjustment or reconfiguration of items performing their
design functions under specific scenarios. The items may be instrumented and quantitative limits of
performance monitored and recorded.
7.1.3 Requirement Verification by Test
Verification will be accomplished through systematic exercising of the application item under appropriate
conditions, with or without instrumentation, and the collection, analysis, and evaluation of quantitative
data.
7.1.4 Requirement Verification by Analysis
Verification will be accomplished by technical, mathematical evaluation, mathematical models or
simulation, algorithms, charts or circuit diagrams, walkthroughs and representative data.
7.1.5 Requirement Verification by Inspection
Verification will be accomplished by a visual examination of the item, reviewing descriptive
documentation, and comparing the appropriate characteristics with predetermined standards to determine
conformance to requirements without the use of laboratory equipment or procedures.
7.2 Requirements for Performance Tests
7.2.1 Success/Failure Criteria
115
The acceptance criteria will be evidenced by the ability of the system to meet the performance
requirements within the tolerances specified.
7.2.2 Verification Levels
General
For COTS/NDI hardware (H/W) or software (S/W) items, verification will focus on adapted or modified
COTS/NDI functions.
The functional integration of multiple COTS/NDI H/W and S/W items will be verified at both the
subsystem and system levels.
Unmodified and un-adapted COTS/NDI H/W and S/W items will be verified through COTS/NDI
screening.
Newly developed H/W or S/W items will go through full functional performance verification at both the
subsystem and system levels.
Hardware Subsystem Tests
The system Hardware Configuration Items (HWCIs) will be verified at the subsystem level to ensure that
the system, when assembled and fully integrated, meets the specified performance requirements.
Hardware subsystem testing will verify the performance of all related requirements of the ATFMS.
Special test fixtures required to simulate other subsystem interaction may be used.
Verification of requirements relating to stress, environmental impact, system interfaces, and system level
performance will be deferred to special and higher level verification.
Software Subsystem Tests
The system Computer Software Configuration Items (CSCIs) will be verified separately prior to their
introduction into the system.
116
To the maximum extent possible, the system software will be verified using a test fixture or test bed that
simulates the operational computer environment.
The software testing will verify the performance of all computer program related requirements of the
ATFMS.
Software testing will be conducted on a fully integrated CSCI.
The ability of each CSCI to detect and react properly to abnormal conditions and faulty inputs shall be
verified.
Processor loading, input and output loading (throughput), and memory requirements for each processor
will be explicitly demonstrated.
System Tests
System tests will be conducted to verify requirements on a fully assembled and fully integrated system.
The System Test verification activities will address no less than the following areas:
Integration and Interface Verification: The verification of subsystem integration and NAS
interfaces.
System Capacity and Response-time Performance Verification: The verification of system
processing time.
Failure Mode and Failure Recovery Verification: The verification of failure mode conditions and
system recovery capabilities.
Stability Verification: The verification of system performance under extended continuous system
use.
Reconfiguration Verification: The verification of system reconfiguration capabilities.
Functional Verification: The verification of functional performance with a fully integrated
system.
Site Verification: The verification of requirements that need actual operational site conditions and
configurations.
Computer Human Interface Verification: The verification of user interface, display and syntax
functions with a fully integrated system.
117
Verification of response time requirements will be accomplished with a minimum of eight traffic displays
running on a workstation and a minimum of six of the eight should be running Monitor Alert in the
graphical mode.
Verification of response time requirements for FSM and its functions will be accomplished with a
minimum of ten (10) FSM programs concurrently running on a workstation.
118
Appendix A. Abbreviations and Acronyms
AAI Airports Authority of India
AAR Airport Arrival Rate
AC Approach Control
ACC Area Control Center
ADR Airport Departure Rate
ADS-B Automatic Dependent Surveillance – Broadcast
ADS-C Automatic Dependent Surveillance – Command
AFSM Automated Flight Schedule Monitor
AFTN Aeronautical Fixed Telecommunication Network
AIS Aeronautical Information System
AOC Airline Operations Center
AM Airspace Management
API Application Programming Interface
APREQ Call for Release Approved Request
ASMGCS Advanced Surface Movement Ground Control Systems
ATC Air Traffic Control
ATFM Air Traffic Flow Management
ATM Air Traffic Management
ATN Aeronautical Telecommunication Network
ATS Air Traffic Services
ATSD Air Traffic Situation Display
CAT Level 1 Service
CCC Central Command Center
CDM Collaborative Decision Making
CFR Call For Release
CNS Communications, Navigation, and Surveillance
CP Capacity Position
CPDLC Controller Pilot Data Link Communications
CTOT Calculated Takeoff Time
EDCT Expected Departure Clearance Time
FAA Federal Aviation Administration
119
FANS Future Air Navigation System
FDP Flight Data Processor
FL Flight Level
FPL Filed Flight Plan
GDP Ground Delay Program
GS Ground Stop
IATA International Air Transport Association
IBAA India Business Aviation Association
ICAO International Civil Aviation Organization
IDS Information Display System
IGI Indira Gandhi International Airport
ILS Instrument Landing System
IMD India Meteorological Center
KMIT Kilometers-in-Trail
METAR Meteorological Aviation Report
MIC Manager in Charge
MID Meteorological Information Display
MINIT Minutes-in-Trail
NOTAM Notice to Airmen
OPMET Operational Meteorological
PIP Post Analysis & Information Dissemination Position
RNAV Area Navigation
RNP Required Navigation Performance
RVR Runway Visual Range
SFP Special Flight Position
SID Standard Instrument Departure
SNOTA Special Notice to Airmen
STAR Standard Terminal Arrival
SUA Special Use Airspace
TAF Terminal Area Forecast
TDB Traffic Demand Database
TMI Traffic Management Initiative
TMS Traffic Management Specialist
TMU Traffic Management U nit
120
TSD Traffic Situation Display
VDL VHF Data Link
VIDP Indira Gandhi International Airport
VIP Very Important Person
WAM Wide Area Multi-Lateration
121
Appendix B. References
FAA NASSR-1000, Revision B. Functional View, DOT, June 2008
FAA NASSR-1000 Revision A., DOT, January 2005
Computer Quality Program Requirements, FAA-STD-018A, September 30, 1987
FAA Reliability, Maintainability, and Availability (RMA) Handbook. FAA-HDBK-006A, January 7,
2008
FAA FAST System Process Flowcharts / Configuration Management Work Activities, Revised 01/2010
FAA FAST Template for the Requirements Document, 07/2001
Qualitative Requirements for an Indian Air Traffic Flow Management System, VNTSC, January 2011
Global Concept of Operations for Indian Air Traffic Flow Management, VNTSC, August 15, 2010
“ICAO Procedures for Air Navigation Services – Air Traffic Management,” ICAO Document 4444
NAS Requirements Document, ATMS-RD-2010, FAA DOT, September 30, 2010
ATM Strategic Plan, Volumes I, II, III; AAI, Version I, April 2008
The FAA Human Factors Design Standard, Ahlstrom, V, Longo, K. (2002). (Report Number #
DOT/FAA/CT-03/05, HF-STD-001)
CFR Title 29 Part 1910 (Code of Federal Regulations), Occupational Safety and Health Standards.
CFR Title 36 Part 1194 (Code of Federal Regulations), Implementation of Electronic and Information
Technology (EIT) Accessibility Standard.
CFR Title 29 CFR 1910.95 (Code of Federal Regulations), Occupational Safety and Health Standards
29USC 794D, The Rehabilitation Act Amendments (Section 508)
FAA-STD-019D, Lightning Protection, Grounding, Bonding and Shielding Requirements for Facilities,
August 9, 2002.
FED-STD-795, Uniform Federal Accessibility Standard (UFAS), April 1988.
MIL-HDBK-454A, General Guidelines for Electronic Equipment, Revision: A, 3 November 2000.
MIL-STD-461E, Requirements for the Control of the Electromagnetic Interference Characteristics of
Subsystems and Equipment, 20 August 1999.
FAA-C-1217F, Electrical Work, Interior, 26 February 1996.
FAA-G-2100, Electronic Equipment, General Requirements, 22 October 2001.
UL-1950, Underwriters Laboratory Safety Standards for Information Technology Equipment.
Executive Order (EO) 12902, Efficiency and Conservation at Federal Facilities, 8 March 1994.
National Fire Protection Association (NFPA) Standard 70, 1) Clearance Requirements and 2) National
Electrical Code.