Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
Tower
User Guide
Issue:
Reviewed 4.0
Author:
Graffica
6ate:
1 July 2005
Company:
Graffica Ltd
Page 1 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
Table of Contents
1
2
3
Introduction ..................................................................................................................................... 4
1.1
Version History ....................................................................................................................... 4
1.2
References ............................................................................................................................... 4
1.3
Abbreviations .......................................................................................................................... 5
Resource Descriptions..................................................................................................................... 6
2.1
Convention .............................................................................................................................. 6
2.2
Overall View ........................................................................................................................... 6
2.3
Scenarios ................................................................................................................................. 6
2.4
Scenario Traffic File Format ................................................................................................... 6
2.4.1
AirportArrivals ................................................................................................................ 7
2.4.2
AirportDepartures ........................................................................................................... 7
2.4.3
VehiclePlans ................................................................................................................... 7
2.4.4
TaxiRoute ........................................................................................................................ 8
2.5
TWR Resources ...................................................................................................................... 9
2.6
Common Resource Files ......................................................................................................... 9
2.7
Airport.Dat File Format ........................................................................................................ 11
2.7.1
User Guide Example Airport ........................................................................................ 11
2.7.2
Gates ............................................................................................................................. 12
2.7.3
Taxipoints ..................................................................................................................... 12
2.7.4
Taxiways ....................................................................................................................... 12
2.7.5
RunwayPerimeters ........................................................................................................ 14
2.7.6
ExclusionAreas ............................................................................................................. 15
2.7.7
Ground Sectors.............................................................................................................. 16
2.7.8
Ground Units ................................................................................................................. 16
2.7.9
TCS Unit and Ground Unit ........................................................................................... 17
2.8
Airspace.Dat File Format ...................................................................................................... 17
2.9
Performance Resource File Format....................................................................................... 17
TAAM Airport Converter ............................................................................................................. 18
3.1
4
TAAM Airport Converter Interface ...................................................................................... 18
TAAM Traffic Converter .............................................................................................................. 19
4.1
Standalone Mode .................................................................................................................. 19
4.2
Connected Mode ................................................................................................................... 19
4.3
Truncate Mode ...................................................................................................................... 19
4.4
TAAM Traffic Sample .......................................................................................................... 20
4.4.1
ATC Route .................................................................................................................... 20
4.4.2
ATC Flight Plan ............................................................................................................ 21
Page 2 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
4.4.3
4.5
5
6
D:\81896423.doc
Tower Airport Plans ...................................................................................................... 21
TAAM Traffic Converter Interface....................................................................................... 22
The Launcher ................................................................................................................................ 23
5.1
Launcher Interface ................................................................................................................ 23
5.2
Launcher AWS Tab .............................................................................................................. 23
Future Enhancements .................................................................... Error! Bookmark not defined.
6.0
Activation 2 and 3 Tasks....................................................................................................... 25
6.1 ..................................................................................................................................................... 25
7
Outstanding Issues ........................................................................................................................ 26
7.1
Disallow direction reversal ................................................................................................... 26
7.2
Traffic rules........................................................................................................................... 26
7.3
Tower Airport Parser ............................................................................................................ 26
7.4
Notification of advance coordination .................................................................................... 27
7.5
Coordination states when parking ......................................................................................... 27
7.6
Arrival Departure List Time fields........................................................................................ 27
7.6.1
Time Fields ................................................................................................................... 27
7.6.2
Role field ....................................................................................................................... 27
7.7
Trajectory Synchronisation ................................................................................................... 27
7.8
TPM TFPM Interafce ............................................................................................................ 28
Page 3 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
1
D:\81896423.doc
INTRODUCTION
The aim of this document is to assist eDEP users with configuring and launching the Tower simulator.
Both the GSDK toolkit and the eDEP ATC software layer are required to build and run the Tower
simulator.
Users are assumed to have experience and knowledge of the eDEP system and to have read the eDEP
User Guide, which this document supplements. This note contains information detailing:

The set up of resource parameters.

The configuration and structure of files defining Airport entities e.g. arrivals, departures,
taxiways and taxipoints.

Outstanding issues.
For more information concerning the Tower design the user should read the Architecture Design
Document [Tower_ADD] or the Detailed Design Document [Tower_DDD].
1.1
VERSION HISTORY
Release
Author
0.1
Graffica
(Eveleigh)
1.0
Graffica
(Eveleigh)
2.0
3.0
Release Date
Release Description
Modifications (sections affected
and relevant information)
Initial
Created.
30 July 2004
Issued to EEC.
None other than version
Graffica
(Eveleigh)
10 Dec 2004
Iteration 2 issued to Iteration 2 Resources.
EEC.
Iteration 2 Possible enhancements
and outstanding issues.
Graffica
(Eveleigh)
7 Jan 2005
Response to EEC New examples added. Old examples
comments
on reformatted.
Iteration 2 delivery
Example airport added.
TAAM converter added
4.0
Graffica
6 June 2005
Tower2005
Activation 1 tasks
(Eveleigh)
5.0
Graffica
1 July 2005
2.7.6 Exclusion Areas
4 TAAM Traffic Converter.
Modifications after 4 TAAM Traffic Converter.
27/06/05 meeting at
7.9 Elastic Vector
EEC
7.10 Crossing runways.
(Eveleigh)
1.2 REFERENCES
The following documents are referenced.
1. Tower Architecture Design Document, [Tower_ADD].
2. Tower Detailed Design Document, [Tower_DDD].
3. Tower Component Test Script Document, [Tower_CTSD].
4. eDEP User Guide, Graffica, May 2004.
Page 4 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
1.3
D:\81896423.doc
ABBREVIATIONS
Abbreviation
Meaning
ADD
Architecture Design document.
AVD
Airport view display.
CTSD
Component Test Specification document.
DDD
Detailed Design document.
eDEP
Early Development Evaluation Platform.
TWR
Tower system.
Page 5 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
2
D:\81896423.doc
RESOURCE DESCRIPTIONS
2.1 CONVENTION
The following strategy has been employed to formally describe the syntax required when defining the
Tower and airport entities.

Text between quotes implies specific keywords and characters.

< A | B > = Must be one of either A or B.

( A ) = A is optional

n
[OPTION]m = OPTION is repeated between n and m times (inclusive).
Also unless otherwise stated heights are specified in feet, ground distances in metres, speeds m/s
while acceleration and deceleration are m/s2.
2.2 OVERALL VIEW
Under the Tower file structure a directory called TWR/src/twr/resources exists. The directory
corresponds to the ATC/src/atcapp/resources and extends the ATC definitions with Tower and airport
specific details.
Within the twr/resources directory a number of files can be found:

scenarios.dat – used as index to scenarios directory (when running Tower from a jar file).

scenarios (directory) – containing test scenarios demonstrating Tower functionality

TwrResources.java – code definition of all Tower specific resource parameters.

common (directory) – containing airport, graphical and aircraft data.
2.3 SCENARIOS
The twr/scenarios directory contains further directories, which contain files defining categories of
scenarios, which demonstrate the functionality of the Tower system. Each functional category will
contain one or more scenarios. Each scenario typically consists of the files as described below:
Directory
Description
<scenario_category>
<scenario>.gsdk
Defines Tower components and start, end times for
scenario.
Same format as ATC gsdk files.
<scenario>_traffic.dat
Defines ATC flight plans and Tower arrival, departure
plans
For a complete description of all the scenarios refer to the Tower Component Test Script document
[Tower_CTSD].
In the twr/resources directory a file called scenarios.dat exists which lists all the available scenarios
contained below the twr/resources/scenarios directory. This file can be used when running the Tower
system from a jar file, allowing the user to reference the scenario files contained in the jar file.
2.4 SCENARIO TRAFFIC FILE FORMAT
The scenario traffic.dat file contains eDEP ATC Flightplans and Tower airportarrivals, airport
departures and vehicleplans. Note the syntax for ATC Flightplans remain unchanged.
Page 6 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
The syntax for airportarrivals, airportdepartures and vehicleplans all incorporate a taxiroute. The
taxiroute specifies taxipoints and gates, which the aircraft/vehicles must travel to as they travel around
the airport. Note that the taxiroute does not necessarily define all points that the aircraft/vehicle must
travel to but will define the start and the end and optionally some intermediate points. The user can
also specify points, which must not be encountered when travelling from one point to another.
The syntax for taxiroutes, airportarrivals, airportdepartures and vehicleplans are described below:
2.4.1 AirportArrivals
An airport arrival for the specified callsign specifies an optional taxi speed that the aircraft should
attain at the airport (overrides any taxiway segment speed constraints). There is also an optional
turnaround parameter, which defines the callsign for the flight, which this arrival will depart as when
it completes its arrival taxi route and parks.
The AirportArrival must have a corresponding FlightPlan.
The taxiroute for an airportarrival must start with a named runway and finish with a named gate but
may contain further intermediate points with associated constraints. See 2.4.4 for complete
specification for a taxiroute.
Example
AIRPORTARRIVAL KLM_ARR
TAXI_SPEED 10
TURNAROUND KLM_DEP
TAXIROUTE
RUNWAY EGBH_R270
GATE
EGBH_APR1_GATE2
END
2.4.2 AirportDepartures
An airport departure for the specified callsign specifies an optional taxi speed that the aircraft should
attain at the airport (overrides any taxiway segment speed constraints).
The AirportDeparture must have a corresponding FlightPlan.
The taxiroute for an airportdeparture must start with a named gate and finish with a named runway but
may contain further intermediate points with associated constraints. See 2.4.4 for complete
specification for a taxiroute.
Example
AIRPORTDEPARTURE KLM_DEP
TAXI_SPEED 10
TAXIROUTE
GATE
EGBH_APR1_GATE2
RUNWAY
EGBH_R270
END
Note if the starting gate has been defined with a target pushback taxipoint then this aircraft will
pushback to the taxipoint before starting its taxiroute to the specified runway.
2.4.3 VehiclePlans
A VehiclePlan has no corresponding FlightPlan so must specify its activation time, originating airport,
size and type. The VehiclePlan can also specify an optional taxispeed that the vehicle should attain at
the airport (overrides any taxiway segment speed constraints).
The VehiclePlan’s taxiroute can consist of one or more taxipoints and constraints. See 2.4.4 for
complete specification for a taxiroute. Note if only one taxipoint is specified then the vehicle will
remain stationary at the specified point.
Page 7 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
Example
VEHICLEPLAN AMBULANCE
ACTIVATION "16:30:00"
ORIGIN
EGBH
SIZE
MEDIUM
TYPE
VAN
TAXI_SPEED 10
TAXIROUTE
TAXIPOINT APR1_GATE_EMG
END
2.4.4 TaxiRoute
A taxiroute defines the start and end points of a route with optional intermediate points. The
intermediate points may be further qualified with speed restrictions to be obeyed until further speed
restrictions are specified.
An intermediate taxipoint may also have a delay specified which overrides any default delay at the
taxipoint. These delays will hold the corresponding aircraft/vehicle at the taxipoint for the specified
duration.
The combination of gate, runway and intermediate points will be different for arrivals, departures and
vehicles. The valid combinations have been mentioned earlier but are now formalised in the
definitions below:
Definition
TAXIROUTE = “TAXIROUTE” + <ARRIVAL | DEPARTURE | VEHICLE> + “END”
DEPARTURE =
GATE_C +
0[(NOT_VIA_C) + TAXIPOINT_C ]N +
(NOT_VIA_C) + RUNWAY_C
ARRIVAL =
RUNWAY_C +
0[(NOT_VIA_C) + TAXIPOINT_C ]N +
(NOT_VIA_C) +GATE_C
VEHICLE =
1[TAXIPOINT_C ]N
0[(NOT_VIA_C) + TAXIPOINT_C]N
Where
GATE_C = “GATE” <name> + (SPEED_Q) + (WAIT_Q)
TAXIPOINT_C = “TAXIPOINT” <name> + (SPEED_Q) + (WAIT_Q)
NOT_VIA_C = “NOT_VIA” <name>
RUNWAY_C = “RUNWAY” <name>
And
SPEED_Q = “SPEED” <speed m/s>
WAIT_Q = “WAIT” <duration s>
The example below illustrates the additional constraints available for a departure.
The aircraft is planned to depart the gate APR1_GATE2 at a speed of 5m/s and to travel to TP1 then
continuing to TP2.
At TP2 the aircraft will wait for 30s before continuing to TP3 at a speed of 15m/s.
From TP3 the aircraft will travel to TP4 (still at 15m/s) but not via the point TPX.
Page 8 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
At TP4 the aircraft will wait indefinitely until it is given clearance at which point the aircraft moves
on to the runway at a speed of 10m/s
Note that to get from one specified taxipoint to another specified taxipoint; it may be necessary for
further taxipoints to be added by the Tower system to allow the aircraft to achieve the desired
destination. Also the route is a planned taxi route with the actual route possibly acquiring further time
and speed constraints.
Example
AIRPORTDEPARTURE KLM_DEP
TAXI_SPEED 5
TAXIROUTE
GATE
APR1_GATE2
TAXIPOINT TP1
TAXIPOINT TP2 WAIT 30 SPEED 15
TAXIPOINT TP3
NOT_VIA
TPX
TAXIPOINT TP4 WAIT -1 SPEED 10
RUNWAY
R270
END
2.5 TWR RESOURCES
When the Tower system is integrated with the ATC system, the combined systems will utilise
resources defined in the ATC structure (atcapp/resources) and those in the Tower structure
(twr/resources).
The TwrResources.java file defines all the Tower specific resource parameters. These parameters
define a wide range of attributes ranging from the size and scale of the Airport View Display to the
crossing time factors used when determining the current traffic situation.
By examining the javadoc generated for the file (TwrResources) the user can determine the complete
list of Tower resource parameters, how each resource is used and in which context it should be used.
2.6 COMMON RESOURCE FILES
Similar to the ATC resource files, the Tower system resource files define the geographic extent of
control of the airport, aircraft and vehicle performance and the mapping of logical colours on to the
colour palette and the standard physical colours.
All the common resource files and directories can be found under the directory twr/resources/common
as detailed below:
Directory
Description
airports
Tower airport descriptions
lfpg
Charles-de-Gaulle airport.
lfpg.map
Map representation of taxiways and
buildings.
lfpg_airport.dat
The user defined tower entities e.g.
runway perimeters, ground sectors and
possibly user defined taxiways and traffic
restrictions.
lfpg_airspace.dat
Defines the ATC airspace entities e.g.
airports, runways and sectors.
lfpg_defaults.gsdk
Defines the TCWP operator roles and
AVD configurations
Page 9 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
lfpg_defaults_air_t
cwp.gsdk
Defines the air TCWP roles and
resources.
lfpg_defaults_grou
nd_tcwp.gsdk
Defines the ground TCWP roles and
resources.
lfpg_defaults_hybr
id_tcwp.gsdk
Defines the hybrid TCWP roles and
resources.
lfpg_taam_airport.
dat
Defines the tower entities defined by the
converted TAAM data e.g. taxiways and
traffic restrictions.
r27x
Test scenario.
r27x.map
Similar to lfpg but used for testing.
r27x_airport.dat
Similar to lfpg but used for testing.
r27x_airspace.dat
Similar to lfpg but used for testing.
r27x_atc_defaults.
gsdk
Loads ATC state transition definitions
and defines the test Unit and GroundUnit.
r27x_defaults.gsdk
Similar to lfpg but used for testing.
france_airspace.dat
Defines the French ATC entities
surrounding the airport e.g FIXes, SIDs,
STARs, sectors, airways and
neighbouring airports.
france_defaults.dat
ATC CWP default settings.
atc
france
jurisdiction_std.gsdk
Defines state transition definition when
transferring and assuming jurisdiction of
flights in the Tower system.
manoeuvre_std.gsdk
Defines state transition definition when
manoeuvring a flight about the airport.
basePalette.gsdk
Overrides ATC basePalette.
logicalcColours.gsdk
Overrides ATC logicalColours.
performance.dat
Aircraft and vehicle performance
defining taxi, take-off and landing
speeds.
r27x.dat
Similar to performance.dat but used
specifically for testing.
graphics
performance
atc_defaults.gsdk
Loads ATC state transition definitions
and defines the TCS Unit and
GroundUnit for LFPG.
tcwp_defaults.gsdk
Loads Tower colour and palette
definitions. Defines Tower
screenmanager.
All files contain resource data, which follow the eDEP data format definition except for the
*_airport.dat files which define Tower specific data.
Page 10 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
2.7 AIRPORT.DAT FILE FORMAT
It is recommended that user defined taxiways (with travel restrictions), runway perimeters and ground
sectors are defined within a *_airport.dat file. While definitions automatically generated from TAAM
data are defined in *_taam_airport.dat.
2.7.1 User Guide Example Airport
The syntax required to specify gates, taxipoints, taxiways, runway perimeters and ground sectors are
described in the following sections supplemented with examples. The examples when combined build
the following example airport.
Figure 2-1: User Guide Example Airport
The example airport contains two runway entry/exit points RP_1, RP_2 for the runway R27. R27 is
denoted by the red strip (runway perimeter) in the diagram. In addition there are three line up points
LP_1, LP_2 and LP_3 which lead to the runway, plus three taxipoints TP_1, TP_2 and TP_3. TP_1
Page 11 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
and TP_3 are not denoted by any symbol on the map as the taxipoints merely mark a kink along a taxi
route. At the start of the taxi routes are two gates G1 and G2. The lines joining the gates to the
taxipoints to the lineup points to the runway entry/exit points illustrate the taxi routes that can be
followed at the airport.
Surrounding these points are two areas. The first the runway_sector defines the area of jurisdiction for
a controller. In this case a runway controller. Other ground sectors to be controlled can be defined but
in this example there is only one ground sector. The final area is the airport_ground_sector which
encompasses all the points and sectors of the airport
2.7.2 Gates
Gates are defined by a name, a position (latitude and longitude) and an optional pushback taxipoint.
When the pushback taxipoint is present departures leaving from the gate will require a pushback
clearance before taxiing to the runway.
In the example below gate G1 is defined with only a position while gate G2 has a position and a
pushback taxipoint.
Example
GATE G1 48.9013 2.9101
GATE G2 48.9014 2.9312 PUSHBACK TP_3
2.7.3 Taxipoints
Taxipoints are defined by a name, a position (latitude and longitude) and an optional delay. When the
delay is present aircraft and vehicles passing through this point will wait at the taxipoint for the
defined delay. If the delay is set as -1 then aircraft will require clearance to continue. Vehicles ignore
delays set to -1.
In the example below eight taxipoints are defined with taxipoint TP_2 having a delay of 60 seconds
defined.
Example
TAXIPOINT RP_1 48.9305 2.9414
TAXIPOINT RP_2 48.9304 2.9313
TAXIPOINT LP_1 48.9207 2.9127
TAXIPOINT LP_2 48.9208 2.9229
TAXIPOINT LP_3 48.9209 2.9303
TAXIPOINT TP_1 48.911 2.9161
TAXIPOINT TP_2 48.9111 2.9203 DELAY 60
TAXIPOINT TP_3 48.9112 2.9337
2.7.4 Taxiways
Taxiways consist of a set of taxiway segments. Each taxiway segment is defined by a list of connected
taxipoints and gates. As part of the definition travel restrictions can be defined to restrict the speed
(m/s) and size of aircraft that can travel along the segment, both from right to left and left to right. In
addition the segment can be designated for arrivals or departures only or closed/open for all traffic.
Note specifying a taxispeed in the tower airport departure/arrival flight plan overrides this speed
restriction.
Below is a formal definition of the syntax followed by an example.
Definition
taxiway =
“TAXIWAY” + <name>
1[taxiwaysegment]N
Page 12 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
“END_TAXIWAY”
taxiwaysegment =
“TAXIWAYSEGMENT” + <name>
“LEFT_RIGHT” + <status> + <allow> + <max_speed>
“RIGHT_LEFT” + <status> + <allow> + <max_speed>
“CONNECTS”
2[ <”GATE” + <name>| “TAXIPOINT” + <name> >]N
“END_CONNECTS”
“END_SEGMENT”
status =
“STATUS” +
<”OPEN” | “CLOSED” | “ARRIVALS_ONLY” | “DEPARTURES_ONLY>
allow =
“ALLOW (“ + (“HEAVY,”) +(“MEDIUM,”) + (“LIGHT”) + “)”
max_speed =
“MAX_SPEED” + <speed>
The example below illustrates the definition of two taxiways.
The first taxiway rwy_twy contains three segments. All three segments allow both departures and
arrivals; of all sizes but restricts their speed to 15m/s.
The second taxiway apron_twy contains two segments.
The first taxiway segment apron_twy_1 describes the path joining G1, TP_1 and TP_2.
Medium and light weight categories of departures and arrivals can travel from G1 to TP_1 to TP_2
but are restricted to the speed of 10m/s.
Only medium weight category arrivals can travel from TP_2 to TP_1 to G1 but are restricted to the
speed of 5m/s.
The second taxiway segment apron_twy_2 has similar weight and speed restrictions as apron_twy_1.
Note specifying a taxispeed in the tower airport departure/arrival flight plan overrides this speed
restriction.
Example
TAXIWAY rwy_twy
SEGMENT rwy_twy_1
LEFT_RIGHT STATUS
RIGHT_LEFT STATUS
CONNECTS
TAXIPOINT RP_1
TAXIPOINT LP_2
TAXIPOINT TP_2
END_CONNECTS
END_SEGMENT
SEGMENT rwy_twy_2
LEFT_RIGHT STATUS
RIGHT_LEFT STATUS
CONNECTS
TAXIPOINT RP_1
TAXIPOINT LP_3
TAXIPOINT TP_2
END_CONNECTS
END_SEGMENT
SEGMENT rwy_twy_3
LEFT_RIGHT STATUS
ALLOW_BOTH ALLOW (HEAVY,MEDIUM,LIGHT) MAXSPEED 15
ALLOW_BOTH ALLOW (HEAVY,MEDIUM,LIGHT) MAXSPEED 15
ALLOW_BOTH ALLOW (HEAVY,MEDIUM,LIGHT) MAXSPEED 15
ALLOW_BOTH ALLOW (HEAVY,MEDIUM,LIGHT) MAXSPEED 15
ALLOW_BOTH ALLOW (HEAVY,MEDIUM,LIGHT) MAXSPEED 15
Page 13 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
RIGHT_LEFT STATUS ALLOW_BOTH ALLOW (HEAVY,MEDIUM,LIGHT) MAXSPEED 15
CONNECTS
TAXIPOINT RP_2
TAXIPOINT LP_1
TAXIPOINT TP_2
END_CONNECTS
END_SEGMENT
END_TAXIWAY
TAXIWAY apron_twy
SEGMENT apron_twy_1
LEFT_RIGHT STATUS
RIGHT_LEFT STATUS
CONNECTS
GATE G1
TAXIPOINT TP_1
TAXIPOINT TP_2
END_CONNECTS
END_SEGMENT
SEGMENT apron_twy_2
LEFT_RIGHT STATUS
RIGHT_LEFT STATUS
CONNECTS
GATE G2
TAXIPOINT TP_3
TAXIPOINT TP_2
END_CONNECTS
END_SEGMENT
END_TAXIWAY
ALLOW_BOTH ALLOW (MEDIUM, LIGHT) MAX_SPEED 10
ARRIVALS_ONLY ALLOW (MEDIUM) MAX_SPEED 5
ALLOW_BOTH ALLOW (MEDIUM, LIGHT) MAX_SPEED 10
ARRIVALS_ONLY ALLOW (MEDIUM) MAX_SPEED 5
2.7.5 RunwayPerimeters
The runway perimeter defines the extent of a runway at an airport. It defines the start and end
thresholds for the runway by specifying two pairs of latitude and longitude positions (Note that the
average of each pair of points define the centreline for the runway). A touch down distance (m)
defines the point at which an aircraft lands on the runway centreline from the start threshold.
The runway perimeter also defines the taxipoints, which connect the runway to the taxiways at the
airport. Also associated with the runway are lineup points, which specify the taxipoints which aircraft
wait for clearance before entering the runway.
Below is a formal definition of the syntax followed by an example.
Definition
runway_perimeter =
“RUNWAY_PERIMETER” + <name> + “FOR_RUNWAY” + <runway_name>
“START_THRESHOLD” + <position> + <position>
“END_THRESHOLD” + <position> + <position>
“TOUCH_DOWN_DISTANCE” + <number>
“COMPRISING”
“LINEUP_POINTS”
0[<taxipoint_name>]N
“END”
“CONNECT_TO_RUNWAY_AT”
1[<taxipoint_name>]N
“END”
“END”
The example below illustrates the definition of one runway perimeter for runway R27.
The start threshold pair and end threshold pair of positions define the runway strip perimeter (red strip
in Figure 2-1). For arrivals a touch down distance from the start threshold is specified in metres.
Page 14 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
The rest of the runway perimeter definition comprises of three lineup points LP_1, LP_2 and LP_3
and two runway entry/exit points RP_1 and RP_2 where the runway joins approaching taxiways.
For a departure at the last lineup point before joining the runway a lineup clearance is required to
continue. After lining up and reaching the runway entry/exit point a takeoff clearance is required for
the departure to accelerate down the runway and takeoff.
Example
RUNWAYPERIMETER R27_BOUNDARY FOR_RUNWAY R27
START_THRESHOLD 48.9303 2.9415
48.9307 2.9415
END_THRESHOLD
48.9299 2.9024
48.9303 2.9024
TOUCH_DOWN_DISTANCE 50
COMPRISING
LINEUP_POINTS
LP_1
LP_2
LP_3
END
CONNECT_TO_RUNWAY_AT
RP_1
RP_2
END
END
2.7.6 ExclusionAreas
An Exclusion area defines a region for an associated runway where safety regulations are to be
applied. Alerts are raised if the runway is closed or if there is an obstructing aircraft or vehicle in the
region defined for the runway. The definition allows multiple aircraft to line up at the runway without
raising alerts.
When considering arrivals at the runway the estimated time of arrival is compared to the air boundary
short and final times to categorise the alerts.
The regulations can also be qualified by applying reduced spacing. Again two distances representing
the short and long final approach distances to the runway threshold are used to categorise the alerts
raised.
Below is a formal definition of the syntax followed by an example.
Definition
exclusion_area =
“EXCLUSION_AREA” + <name>
“REGION”
<position>
<position>
<position>
<position>
“END
“PROTECT RUNWAY” + <runway_name>
“ALLOW_LINEUPS” + <boolean>
“AIR_BOUNDARY” + <real> + <real>
“REDUCED_SPACING” + < “NONE” | “APPLY” + <real> + <real> >
“END”
Example
EXCLUSION_AREA EXCLUDE_R27
REGION
48.9303 2.9415
48.9307 2.9415
48.9303 2.9024
48.9299 2.9024
Page 15 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
END
PROTECT RUNWAY R27
ALLOW_LINEUPS false
AIR_BOUNDARY 50.0 100.0
REDUCED_SPACING APPLY 2000 2500
END
2.7.7 Ground Sectors
Ground sectors supplement the standard ATC REGION definition with the frequency to be used for
the ground sector, sector control type (AIRPORT, APRON, RUNWAY, TAXI) and the airport, which
the sector belongs.
Below is an example.
GROUND_SECTOR RUNWAY_SECTOR
REGION
ALTITUDE 0 0
48.9350 2.9000
48.9350 2.9500
48.9000 2.9500
48.9000 2.9000
END
FOR_AIRPORT UG
CONTROL_KIND RUNWAY
FREQUENCY 118.775
END
Ground sectors are the Tower’s equivalent to the ATC sectors with the difference that ATC sectors
define a 3D volume while ground sectors define 2D areas.
Another difference is in the implementation. ATC sectors must be defined to be mutually exclusive
while ground sectors can overlap thus giving a layered implementation.
So, when determining which ground sector has precedence for controlling an aircraft in a common
area the ground sectors are prioritised dependent on whether the aircraft is a departure or an arrival.
When the aircraft is an arrival the ground sectors are prioritised on their control kind with RUNWAYs
first, then APRONs and finally TAXIs. When the aircraft is a departure then the control kinds are
prioritised in the order APRONs, RUNWAYs then TAXis
If two like control kinds share a common area then the first encountered will be used.
AIRPORT control kinds are not considered, as there should be only one, which is associated to the
airport ground unit, which in turn is associated to the Tower Coordination Component TCS (See
2.7.9).
2.7.8 Ground Units
Ground units define the set of ground sectors that the TCWP ground unit has responsibility for. Once
defined the ground unit is associated to the TCWP using the appropriate Resource name. Note the
ATC unit for the TCWP is the airport unit while the Role is used as a descriptor for the AVD.
Below is an example.
GROUND_UNIT RUNWAY_UNIT
COMPRISING
GROUND_SECTOR RUNWAY_SECTOR
END
TCWP_RWY_P.GROUND_UNIT RUNWAY_UNIT
TCWP_RWY_P.UNIT AIRPORT_UNIT
TCWP_RWY_P.ROLE RWY
Page 16 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
2.7.9 TCS Unit and Ground Unit
The TCS Unit and Ground Unit form the bridge between the Tower and ATC Coordination systems.
The TCS Unit defines the ATC defined airport sector, while the TCS Ground Unit defines the
equivalent Tower ground sector. For consistency they should cover the same ground area. The Unit
and the Ground Unit are associated to TCS using the appropriate Resource name.
Below is an example.
TCS.UNIT AIRPORT_UNIT
TCS.GROUND_UNIT AIRPORT_GROUND_UNIT
2.8 AIRSPACE.DAT FILE FORMAT
The airspace.dat file contains data defined using ATC definitions whose syntax has remained
unchanged. Although for iteration 2 the airport definition will be enhanced with an optional parameter
defining the elevation (ft) of the airport above sea level.
2.9 PERFORMANCE RESOURCE FILE FORMAT
Vehicle and aircraft ground performance specify the queuing distance and maximum taxi speed for
vehicle/aircraft types while travelling at the airport.
In addition for arriving airborne flights the touch down speed is defined along with the dry and wet
deceleration speeds for the aircraft type. Similar values are defined for take-off. Only dry runway
values are supported at present.
Example
VEHICLE_PERFORMANCE AMBULANCE
TAXI_SPEED 20
QUEUE_DISTANCE 5
END
AIRCRAFT_PERFORMANCE
TAXI_SPEED
QUEUE_DISTANCE
TOUCHDOWN_SPEED
FINAL_APPROACH_SPEED
TAKEOFF_SPEED
DRY_RUNWAY_DECELERATION
DRY_RUNWAY_ACCELERATION
WET_RUNWAY_DECELERATION
WET_RUNWAY_ACCELERATION
END
B744
10
50
150
200
200
5
6
3
4
Note the final approach speed is not used in the simulation.
Page 17 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
3
D:\81896423.doc
TAAM AIRPORT CONVERTER
The TAAM airport converter reads the TAAM POL and USG files, processes the data, cross
references the data for consistency and then outputs the data to two eDEP formated files.
Data contained in the POL file is used to produce an eDEP format map file. The eDEP map file will
contain runway, building, taxiway, taxiway centrelines and apron centrelines map details.
Data contained in the POL file is also used to construct the taxiway, taxiway segment, taxipoints and
gate definitions used to determine taxi routes for aircraft and vehicles. These definitions are
supplemented with data contained in the USG file, which defines restrictions (speed, size, arrival use,
departure use) to be applied to these taxiway segments. The resulting enhanced definitions are then
output to an eDEP format airport file.
3.1 TAAM AIRPORT CONVERTER INTERFACE
The current TAAM Airport Converter, showing the available options, is shown in Figure 3-1 below.
Figure 3-1: TAAM Airport Converter
The user must supply the source POL and USG files to be used and the desired logic and map output
file specifications.
When supplied with these file specifications the calculate button becomes available and when selected
the logic and map output files are generated.
The Print Aliases qualifier allows the user to generate alias information which can be used to trace
back the newly named taxipoints to their TAAM origins.
Currently the Airport Code is not used within the converter.
Page 18 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
4
D:\81896423.doc
TAAM TRAFFIC CONVERTER
The TAAM Traffic converter is used to process the TAAM traffic information producing airport
plans, flight plans, derived routes (containing SID or STAR) and determining the activation times
from the TAAM actual off block times (AOBT) and actual time of arrivals (ATA).
Note that for the airports, fixes, SIDs and STARs, only the names will be referenced, it is assumed the
actual definitions can be imported from IPAS.
For departures the activation time is always taken as the AOBT.
For arrivals the activation time will depend on the mode selected. When processing for Standalone the
ATA is taken as the activation time. When processing for Truncate the flight plan route is truncated to
the final STAR of the derived route and the activation time calculated at the start of the STAR. For
Connected the activation time is calculated as the time at the start of the combined STAR and derived
route. Therefore the ATA will be the same no matter what mode is selected.
Before running the TAAM Traffic converter the TAAM Traffic Excel file must be saved as a comma
separated variable (csv) file. The TAAM Traffic converter can then be invoked to read the csv file
specifying the airport code and the required mode (STANDALONE, TRUNCATE, CONNECTED)
that the Tower system will run the generated data.
4.1 STANDALONE MODE
When STANDALONE selected the user must specify the location of the csv file and the location of
the three files where the generated airport plans, flight plans and airspace routes will be produced
before selecting CALCULATE.
The first file produced contains the ATC flight plans defining the aircraft callsign, type and activation
time, SID/STAR as well as a reference to a named route. The second file contains the Tower airport
plans defining gate and runway information. Finally the third file contains derived route information
associated to the named route referenced in the ATC flight plan file.
The Tower system can then be run in standalone mode utilising these files.
4.2 CONNECTED MODE
When CONNECTED mode has been selected, the user must specify the location of the airport plans,
flight plans and derived routes as before. The user must also specify the Tower resources that will be
used when the Tower system is run connected to the eDEP ATC layer. These resources must specify
the trajectory TP.CLIMB and DESCENT speed modifiers as well as the ACR.SCENARIO and
ASP.SCENARIO resources. The COMPONENTS resource must not be specified.
When selecting the CALCULATE button the TAAM traffic converter does some initial processing
before invoking an extended TIFPL Component to predict trajectory times and thus the activation
times. Finally the airport plans, flight plans and derived routes are generated.
The Tower system can then be run connected to the eDEP ATC layer utilising these files.
4.3 TRUNCATE MODE
Selecting TRUNCATE mode requires the same parameters as CONNECTED mode but process the
information such that the derived routes are truncated to the STAR at the end of the route.
The Tower system can then be run connected to the eDEP ATC layer utilising these files and
truncated routes.
Page 19 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
4.4 TAAM TRAFFIC SAMPLE
The TAAM Traffic Sample, which is supplied as a Microsoft Excel file, must be saved as a csv file
before it can be interpreted by the Traffic Converter. The format of the Excel file must contain the
following column headers, in the order specified, to identify the sample data:
Column
Description
CALLS
Aircraft callsign.
TYPE
Aircraft type.
MKSeg
Not used.
ROUTE_NAME
Route name.
RFL
Cruising altitude.
DEP_TIME
Departure time (off block time).
ARR_time
Arrival Time (Touchdown time).
P_RNAV
Not used.
ADS
Not used.
FLRANGE
Not used.
Reg
Aircraft registration number.
Dep_Rwy
Departure runway.
SID
Departure SID.
Arr_Rwy
Arrival runway.
STAR
Arrival STAR.
GD
Departure gate.
GA
Arrival gate.
DEP_Apt
Departure Airport.
WPOINTi
Route waypoint (None, one or many)
DEST_Apt
Destination airport.
These columns will then be used to identify the information and format the data into ATC Routes,
ATC Flight Plans, Tower AirportArrival and Tower AirportDeparture plans; which can be recognised
by eDEP.
4.4.1 ATC Route
The ATC Route is derived from the fields defined between and including the DEP_Apt and
DEST_Apt columns. For example for one entry in the TAAM data defined as:
DEP_Apt WPOINTi WPOINTi DEST_Apt
EDDM
1BRY
AE02
Would produce the following route definition:
ROUTE EDDM_LFPG
COMPRISING
FIX IBRY
FIX AE02
Page 20 of 28
LFPG
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
END
This route definition would then be referenced in the corresponding flightplan as:
ROUTE_SEGMENT ROUTE EDDM_LFPG
4.4.2 ATC Flight Plan
The ATC Flight Plan contains the activation time for flights in the ATC and Tower systems. The
activation time is derived as described earlier.
The example below maps the TAAM column data to the Flight Plan information where an entry will
be considered an arrival if the DEST_Apt is the airport being simulated and an ARR_TIME has been
defined. Similarly an entry will be considered a departure if the DEP_Apt is the airport being
simulated and a DEP_TIME has been defined.
FLIGHTPLAN
ACTIVATION
ORIGIN
DESTINATION
RFL
SSR_CODE
SSR_MODE
ETD
MODEL
WAKE
TAIL_NUMBER
DATALINK
AIRLINE
CALLS
If an arrival then derived from ARR_TIME
If a departure then DEP_TIME.
DEP_Apt
DEST_Apt
RFL
“3301”
“C”
Not used but set as activation time.
TYPE
“HEAVY”
Reg
“Non_Equipped”
First three characters of CALLS
ROUTE
For a departure
SID
“R” + Arr_Rwy + “_SID_” + SID
ROUTE_SEGMENT ROUTE_NAME
But if undefined then
DEP_Apt + “_” + DEST_Apt
END
ROUTE
For an arrival
ROUTE_SEGMENT ROUTE_NAME
But if undefined then
DEP_Apt + “_” + DEST_Apt
STAR
“R” + Arr_Rwy + “_STAR_” + STAR
END
Figure 4-1: ATC FlightPlan Template for TAAM
Notes
a. SSR_CODE, SSR_MODE, and WAKE can not be sourced from the TAAM data.
b. It is assumed that the TAIL_NUMBER is sourced from Reg.
c. As the ETD is not used in the simulation it is set to the activation time as an approximation.
4.4.3 Tower Airport Plans
The Tower Airport Plans define the airport departure and arrival routes to/from the runway and gate.
Page 21 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
The example below maps the TAAM column data to a Tower Airport Arrival:
AIRPORTARRIVAL CALLS
ROUTE
RUNWAY
“R” + Arr_Rwy
GATE
GA – “gate_” prefix
END
Figure 4-2: AirportArrival Template for TAAM
The example below maps the TAAM column data to a Tower Airport Departure:
AIRPORTDEPARTURE CALLS
ROUTE
GATE
GD – “gate_” prefix
RUNWAY
“R” + Dep_Rwy
END
Figure 4-3: AirportDeparture Template for TAAM
4.5 TAAM TRAFFIC CONVERTER INTERFACE
The current TAAM Traffic Converter, showing the available options, is shown in Figure 4-4 below.
Figure 4-4: TAAM Traffic Converter
When STANDALONE mode selected all fields, except the Traffic Sample Resources, must be
specified before the CALCULATE button becomes available.
When TRUNCATE or CONNECTED mode is selected all fields must be specified before the
CALCULATE button becomes available.
When the CALCULATE button is selected the airport plans, flight plans and airspace routes files are
generated.
Page 22 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
5
D:\81896423.doc
THE LAUNCHER
The Tower Launcher extends the ATC Launcher interface.
5.1 LAUNCHER INTERFACE
The current Tower Launcher, showing the available options, is below.
Figure 5-1: Launcher Interface
5.2 LAUNCHER AWS TAB
Extending the ATC Launcher provides the user with further AWS resources, which can be
configurable at, launch time by using the AWS tab.
The current AWS Tab, showing the available configurable resources, is shown in Figure 5-2
Page 23 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
Figure 5-2: Launcher Interface
Page 24 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
6
D:\81896423.doc
FUTURE ENHANCEMENTS
6.1 ACTIVATION 2 AND 3 TASKS
The following is a list of the second set of tasks to be completed in 2005.

Meteo Weather Conditions

Pre-defined Taxi Routes

TWR-ATC Trajectory Consistency

Deceleration on Taxiways

Ground Vehicle clearances

SIDs and STARs
Page 25 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
7
D:\81896423.doc
OUTSTANDING ISSUES
This section highlights outstanding issues and known problems with the current software prototype
release.
7.1 DISALLOW DIRECTION REVERSAL
Implementing disallowing direction reversal has given rise to problems when trying to determine a
route from X to Y if the only route allowed is to travel a loop.
Consider the example below where an aircraft is travelling from B to C and is told to “go to A”. The
current implementation of the DNS will not find a route as the only way to get to A is to backtrack
over a segment that it has already travelling on.
It is possible to get to A if the instruction to “go to A” is supplemented with a “go via E”. The aircraft
will then travel the loop and backtrack over the segment that it has already travelled.
To solve this problem would make the DNS algorithm even more processor intensive probably to a
point where it degrades the rest of the system.
As the problem could be overcome either by extending the airport ground point definitions or using
the elastic vector and the go via instruction it is probably not advisable to extend the DNS algorithm
at the present time.
Figure 7-1: Direction Reversal
7.2 TRAFFIC RULES
Traffic rules depend on a number of system resource parameters e.g., junction congestion radius; and
vehicle performance parameters e.g. queuing distance. Further refinement of the rules and extra
resources may need to be defined as the system matures. In particular the junction congestion radius
set to values representing the width of the taxiway at the junction.
7.3 TOWER AIRPORT PARSER
The ATC airport entity syntax has been extended with the airport elevation. This extension can only
be used with the Tower airport parser. The Tower airport parser should be incorporated in to the ATC
airport parser.
Page 26 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
7.4 NOTIFICATION OF ADVANCE COORDINATION
When running in integrated mode the flight plan information appears in the Arrival list before the
flight reaches the airport. When running in standalone mode the flight plan information appears in the
Arrival list at the same time that the track appears on the runway. If there is a need for controllers to
assume control of the flight before touch down then a Resource defined delay could be used to
distinguish the times at which the flight plan is announced and the flight appearing on the AVD.
7.5 COORDINATION STATES WHEN PARKING
It is not clear from the DSI specification what should be displayed in Arrival list and labels when a
flight has reached the last controller on its route to the parking gate. Neither is it clear what orders the
last controller issues when parking an aircraft. The current implementation uses the notion of a
dummy controller named GATE.
7.6
ARRIVAL DEPARTURE LIST TIME FIELDS
7.6.1 Time Fields
At present there are no time fields on the Arrival List. On the Departure List there are two time fields,
calculated time to takeoff (CTOT) and estimated off block time (EOBT) both of which are not
updated after the first calculation.
7.6.2 Role field
The GroundUnit (Role) field on the Arrival Departure list acts differently to the Unit field on the ATC
SIL. The ATC SIL unit field is insensitive while the GroundUnit field allows a Transfer/Assume
menu for the controlling operator.
Also, the GroundUnit field displays the current GroundUnit who has jurisdiction while the Unit field
displays the next Unit to have coordination control.
In addition the Arrival Departure List GroundUnit field displays the current GroundUnit while Tower
label displays the current Ground Unit for non controlling operators and next Ground Unit for
controlling operators.
As this gives a different look and feel to the EATMP lists and labels further refinements maybe
needed.
7.7 TRAJECTORY SYNCHRONISATION
ATC inbound events are scheduled by ATC CS when the flight plan is activated. When in integrated
mode, the time between the flight plan activation and the appearance of the flight as a track on the
PVD can be quite large due to delays in airport clearances.
This results in the CS becoming out of sync with the track as it progresses in the scenario. For
example the CS events indicate sector exited while the airport clearances have delayed the flight such
that the flight is still sector inbound. One visible symptom of this problem manifests itself in the times
reported in the SIL which become very inaccurate.
Similar problems may occur in FPM, MTCD and STCA if events are scheduled on flight plan
activation rather than the flights actual trajectory.
To solve this problem TCS could be improved so that it informs CS of changes to the previous TWRATC co-ordination conditions (i.e. takeoff times). This is normally done if the take-off time changes
by a threshold amount. That way, the CS can cause a trajectory update in ATC FM.
Also needed would be FPM to check the current time against the trajectory start time when an IAS
track becomes active (i.e. 1st track update). If there is a difference then a longitudinal/time deviation
is sent to FM, and the trajectory updated.
Page 27 of 28
Tower
Reference GL/<project>/<type>/<no>
1 July 2005
D:\81896423.doc
7.8 TPM TFPM INTERAFCE
Currently in the Tower system TFPM interfaces directly to the TPM obtaining
ProgressUpdateMessages. These messages contain not only the track position but also the last
taxipoint passed and the next taxipoint to pass. This “cheat” has been implemented to simplify the
processing done by TFPM. If airport radar blind spots are to be considered then this interface would
be better implemented to flow the data through TIAS first before it reaches TFPM.
7.9 ELASTIC VECTOR ROUTE EDITING (PRF 361)
The current elastic vector route editing facility is limited to only allowing one go via point.
Also for departures the end point must be a runway entry exit point. This disallows:

Cancellation of a departure.

Rerouting to a parking position to wait for new instructions.
For arrivals the end point must be a gate. This disallows:

Rerouting to a parking position to wait for new instructions.
7.10 CROSSING RUNWAYS AND ARRIVAL CLEARANCE (PRF 362)
To simulate the requirement to give clearance to cross a runway, junctions have been defined with
infinite delays either side of runways. Junctions with an infinite delay require taxi clearance before
continuing to taxi. This also accommodates arrivals, which require taxi clearance after leaving their
runway and reaching the first junction.
Using this implementation requires careful planning of arrival and departure taxiways and positioning
of junctions (with infinite delays). Instances can occur when an arrival lands at an outer runway,
leaves the runway waits and then receives taxi clearance. It continues to an inner runway where it
waits for clearance to cross. After receiving clearance the aircraft crosses the runway and reaches
another junction where it waits unnecessarily for another clearance.
A more flexible implementation is required where more intelligence is built in to the route finding
algorithm to determine taxiway crossing points of runways.
Page 28 of 28