edep development project edep twr system … · development and evaluation platform reference...

Development and Evaluation Platform Reference GL/DEP/TWR/DDD/1/15.0

14 Aug 2007

of 76

eDEP Development Project

eDEP TWR System

DETAILED DESIGN DOCUMENT


14 Aug 2007

of 76

Document Change Log Release Author Date of the

release Description of the release Modifications (sections

affected and relevant information)

0.1 Ken Eveleigh 9 Feb 2004 Initial draft 1.0 Ken Eveleigh 24 Feb 2004 Internal Graffica review Throughout document 2.0 Ken Eveleigh 05 Mar 2004 External EEC review Throughout document 3.0 Ken Eveleigh 1 Jul 2004 Iteartion 1 delivery Minor changes throughout.

GroundSectors introduced. 4.0 Ken Eveleigh 10 Dec 2004 Iteration 2 delivery TCS uses TFM navigation

messages. TCS uses TFPM progress messages. TCS and TFM use TASP.

5.0 Ken Eveleigh 7 Jan 2005 Post Iteration 2 delivery Response to EEC comments 6.0 Ken Eveleigh 6 Jun 2005 Tower05 Atctivation 1 Tasks 3.2 Tower Airspace

3.8 Tower Integrated Air Surv. 3.10 Tower Working Position 3.12 Tower Safety Network 3.14 TAAM Traffic Converter

7.0 Ken Eveleigh 1 July 05 Tower TCR 3.12 TSN track rate aiding. 8.0 Ken Eveleigh 14 Feb 06 Tower06 APT tasks and

corrections 3.2 Tower Airspace 3.5 Tower Pilot Manager 3.8 Tower IAS 3.9 Tower Coordination

9.0 Ken Eveleigh 17 Feb 06 DMAN initial development 3.10 TCWP 3.15 DMAN

10.0 Ken Eveleigh 21 April 06 DMAN first delivery 3.5 TPM 3.6 TFM 3.13 DMAN

11.0 Ken Eveleigh 13 Nov 2006 Tower Pilot Position 3.5 TPM 3.12 TPWP

12.0 Ken Eveleigh 19 Dec 2006 DNS taxi route navigation queries

2 Overview 3.10 TCWP 3.12 TPWP

13.0 Tim Cooper 2 Apr 2007 TPWP updates 3.5 TPM (WP5.3d) 3.12 TPWP (WP5.3d) 3.2 Stop BARS (WP6.2)

14.0 Tim Cooper 7 June 2007 TPWP frequency updates. 3.5 TPM (WP5.3.8) 3.12 TPWP (WP5.3.8)

Paul Fletcher 11 June 2007 GateOccupied and GateVacated progress events added.

3.7 TFPM (WP6.2) 3.10 TCWP (WP6.2) 3.11 uTCWP (WP6.2)

15.0 Rob Thom 14 Aug 2007 Version number change to Graffica standard.

N/A

Acceptance and Reviewing Procedures Name (s) Date of acceptance/ review Date of approval

Document distribution to/cc Name Role


14 Aug 2007

of 76

Document distribution to/cc Name Role


14 Aug 2007

of 76

CONTENTS

1 INTRODUCTION............................................................................................................. 5

1.1 Document Purpose..................................................................................................... 5

1.2 References ................................................................................................................. 5

1.3 Documentation Set and Structure.............................................................................. 5

2 Overview ........................................................................................................................... 6

2.1 GSDK ........................................................................................................................ 6

2.2 ATC........................................................................................................................... 6

2.3 TWR.......................................................................................................................... 6

3 TWR Component Design .................................................................................................. 6

3.1 Tower Aircraft Performance Server (TACR)............................................................ 6

3.2 Tower Airspace Server (TASP)................................................................................. 6

3.3 Tower Initial Flight Plan (TIFPL) ............................................................................. 6

3.4 Detailed Navigation Server (DNS)............................................................................ 6

3.5 Tower Pilot Manager (TPM) ..................................................................................... 6

3.6 Tower Flight Manager (TFM) ................................................................................... 6

3.7 Tower Flight Progress Monitor (TFPM) ................................................................... 6

3.8 Tower Integrated Air Surveillance (TIAS)................................................................ 6

3.9 Tower Coordination Server (TCS) ............................................................................ 6

3.10 Manned tower CWP (TCWP) ................................................................................... 6

3.11 Unmanned tower CWP (uTCWP) ............................................................................. 6

3.12 Tower Pilot Working Position (TPWP)..................................................................... 6

3.13 Tower Safety Network (TSN) ................................................................................... 6

3.14 Departure Manager (DMAN) .................................................................................... 6

3.15 TAAM Airport Converter.......................................................................................... 6

3.16 TAAM Traffic Converter .......................................................................................... 6


14 Aug 2007

of 76

1 INTRODUCTION

This document provides the detailed design specification for the EUROCONTROL eDEP platform Tower system (TWR). The document focuses on the TWR domain software, providing a simulated airport traffic management services. This document covers the specification of each of the TWR components and the underlying design patterns used in the implementation of the components.

1.1 DOCUMENT PURPOSE

The purpose of this document is to provide a high level description of the internals of the TWR system, forming an intermediate level of documentation between the TWR Architecture document, describing the black box component view, and the detailed documentation provided by the Javadoc, embedded in the source code. The document is intended to take the developer from the interfaces identified in the Architecture document (the black box) through to the Javadoc (white box) description.

1.2 REFERENCES

Ref 1. Software Requirements Document Tower Simulator eDEP/TWR/SRD

Ref 2. eDEP TWR Architecture GL/eDEP/TWR/ADD

Ref 3. eDEP Architecture GL/eDEP/ADD

Ref 4. GSDK Design Document

Ref 5. eDEP Air Layer Design Document

Ref 6. eDEP ATC Layer Design Document

Ref 7. eDEP CWP Layer Design Document

Ref 8. TAAM to eDEP Data Conversion

Ref 9. DMAN3 General Gateway Specification, version 0.03, Meilin SCHAPER, DLR, dated September 2005

Ref 10. PVM Website, http://www.csm.ornl.gov/pvm/pvm_home.html.

1.3 DOCUMENTATION SET AND STRUCTURE

The defining Tower software requirements are specified in Ref 1.

The Tower architecture is described in the eDEP TWR Architectural Design Document Ref 2. This document describes the design.

The Javadoc comments generated from the source code are referenced using links from this design document.

The Tower system and documentation supplement the parent eDEP ATC system documentation.

The eDEP ATC architecture is described in Ref 3. The associated design documentation set is contained in Ref 4, Ref 5, Ref 6 and Ref 7.

How to build a complete component structure using standard design methods and patterns is described in Ref 4. These methods and patterns include descriptions for:

• application framework

• model management

• parser framework


14 Aug 2007

of 76

• events framework

• graphics framework

• middleware framework

This document supplements the parent design documentation and is structured with a brief overview of the TWR architecture followed by sections describing each of the TWR Components.


14 Aug 2007

of 76

2 OVERVIEW

This section provides an overview of the TWR system facility. It provides an overall context diagram for the facility described in terms of its inputs and outputs. It also outlines the relationships between the TWR entity classes and the underlying ATC and GSDK classes.

2.1 GSDK

The GSDK packages provide an abstracted real time system framework from which domain and concept specific objects may be derived, and into which implementation specific behaviour may be applied. The GSDK makes extensive use of Java interfaces to hide the implementation details from a using object or component, and thus allow many implementations to satisfy a single interface requirement. This allows the developer to selectively change the behaviour and functionality of any derived system. Coupled with the use of the Java reflection tools, a developer can make use of object factories to create the chosen object class, provided that object conforms to the defined interface.

The GSDK will also provide the timing, event scheduling and event distribution mechanisms. These provide a number of methods to de-couple the behaviours associated with an object from its implementation, allowing reuse of basic objects, through attached event processing behaviour.

2.2 ATC

The ATC software layer uses the abstract classes provided in the GSDK layer to derive tailored, system specific objects, which make use of the plug-in interfaces provided by the GSDK framework to add behaviour and user specific processing in response to system generated events.

The ATC packages define a layer of Java classes specific to the ATC domain, and as such define a baseline implementation for ATC object specifications and behaviours.

2.3 TWR

Each of the Tower components and their associated relationships are illustrated in the following diagrams. In the diagrams (e) represents an event, (w) represents a write and (R) a read operation. Events are raised in reply to components subscribing to the events.


14 Aug 2007

of 76

Figure 1: The Primary Relationships Between TWR Components

The Tower Movement Simulation diagram represents the relationship between the Tower components and their communication to support Airport activities. It illustrates the initiation of flights and associated flight plans from TIFPL, the simulation and reporting of actual motion by TPM, TIAS, planned route, coordination and flight progress by TFM, TCS, TFPM, TSN and then finally displayed and maintained by TCWP and TPWP.

For clarity the client only components TCWP, TPWP and DMAN are detailed below in Figure 2, Figure 3 and Figure 4.


14 Aug 2007

of 76

Figure 2: TCWP Relationships

TCWP requests track data from TIAS, planned route information from TFM, jurisdication information from TCS and monitoring information from TSN, TFPM to realise a visual display of the current planned situation at the airport.

Figure 3: TPWP Relationships

TPWP requests frequency, positional and actual route information from TPM, to realise a visual display of the current actual situation at the airport.


14 Aug 2007

of 76

Figure 4 : DMAN Relationships

DMAN requests track data from TIAS, planned route information from TFM, jurisdication information from TCS and monitoring information from TFPM to recommend clearances and manage times for depaertures.

Figure 5: Tower Environment Components

The TACR and TASP services provide clients with aircraft performance (e.g. taxi, touch down, take-off speeds) and airport environment information defining runways, taxiways and aprons.


14 Aug 2007

of 76

Figure 6: Tower and eDEP ATC Interface

To provide a fully integrated Air Traffic system the Tower simulator will interface to the eDEP ATM system. The supported interface will be between “like” components. The Tower and eDEP ATC flight plan coordination interface is between the Tower TCS and the eDEP ATC CS components. The flight activation and airborne state vector information interface is between the Tower TPM and eDEP ATC PM components. While air track information from IAS is relayed to the Tower system through TIAS.

2.3.1 Tower Aircraft Performance Server (TACR) The TACR maintains a database of performance data and provides this entity information to clients requiring an aircraft’s speed along the taxiways and acceleration/deceleration on the runways.

2.3.2 Tower Airspace Server (TASP) TASP maintains a database of airport entities describing Taxiways, TaxiwaySegments, Taxipoints, Aprons and Runways, as well as the conventional ATC airspace objects e.g. beacons, airways, etc.

2.3.3 Tower Initial Flight Plan (TIFPL) TowerFlightPlan entities are maintained and distributed by the TIFPL. The TowerFlightPlan entity describes the filed flight details for aircraft and airport service transport, as well as IFPL for eDEP ATC.

2.3.4 Detailed Navigation Server (DNS) The DNS provides a service to generate navigation scripts to plan the route of an aircraft from apron to runway, or vice versa, given flight plan constraints.

2.3.5 Tower Pilot Manager (TPM) PilotedTowerFlight entities are managed by the TPM. The TPM drives the entity on a time step basis by calculating new positions using the pilot DNS, and reporting the position and progress to its clients.

2.3.6 Tower Flight Manager (TFM) The TFM maintains a database of TowerFlight entities and their planned navigation route across the airport. It also holds the current status of the aircraft.


14 Aug 2007

of 76

2.3.7 Tower Flight Progress Monitor (TFPM) MonitoredTowerFlight entities are supervised by the TFPM. TFPM monitors the progress of the MonitoredTowerFlights reporting significant activities, passed points and manoeuvres to its clients.

2.3.8 Tower Integrated Air Surveillance (TIAS) The TIAS receives TPM reported positional information, buffering the updates and releasing the Track information to its clients at a selectable update rate.

2.3.9 Tower Coordination Server (TCS) TCS coordinates the distribution of CoordinatedFlights between controller positions.

2.3.10 Manned Tower Controller Working Position (TCWP) The controller working positions CWP maintain a visual picture of the current planned Traffic situation at the airport. Traffic information is presented as an airport situation picture and as arrival and departure lists.

2.3.11 Unmanned Tower CWP (uTCWP) The UTCWP is used to replace a TCWP to provide automated responses to a simulation scenario. This provides a means of simplifying the complexity of an experiment by substituting an unmanned position for a TCWP.

2.3.12 Manned Tower Pilot Working Position (TPWP) The pilot working positions TPWP maintain a visual picture of the current actual Piloted Traffic situation at the airport. Traffic information is presented as an airport situation picture and as arrival and departure lists.

2.3.13 Tower Safety Network (TSN) TSN maintains a set of Mobile entities and monitors received air and ground track information reporting incursions in closed or congested runway exclusion areas.

2.3.14 Departure Manager (DMAN) Using an external plugin departure algorithm DMAN submits recommended times for next clearance (RTUC), managed off-block times (MOBT) and take-off times (MTOT).

2.3.15 TAAM to eDEP Converter To aid data preparation for the Tower system an offline data converter will be utilised which converts TAAM data (as supplied by EEC) to a format recognised by the Tower syntax parsers. Note the TAAM converter does not read or write to other components nor does it raise or react to any system events.

2.3.16 Entity Model An Aircraft or service vehicle in the Tower simulator is identified as a TowerIdentity, which extends the GSDK concept of a MobileEntity.

The above entities and their relationship within the ATC and GSDK framework are presented in the following diagrams.


14 Aug 2007

of 76

Figure 7: Tower Entities

The TowerIdentity interface contains general pupose methods/attributes commonly shared between (TPM) PilotedFlight and (TFM) Flight. These will include get and set methods accessing the Tower initial flight plan, navigation script plus methods for determining if the entity is an arrival, departure or vehicle.

For Clarity the TASP entities are presented separately.


14 Aug 2007

of 76

Figure 8: TASP Entities


14 Aug 2007

of 76

3 TWR COMPONENT DESIGN

3.1 TOWER AIRCRAFT PERFORMANCE SERVER (TACR)

3.1.1 Server The TACR component defines a TACRController that provides the initialisation and run-time control of distributed components. This component is responsible for locating and parsing TACR performance files and creating a list of aircraft and service vehicle Performance objects defining their performance

3.1.2 Entities The TACR maintains a database of aircraft and vehicle performance data. This is illustrated in the following diagram, which shows the components entities and services.

Figure 9: TACR Component and Entities

3.1.2.1 VehiclePerformance

The VehiclePerformance entity contains details on:

• Maximum taxi speed.

• Queuing (give way) distance.

An associated serializable description class is also defined, which will hold a set of attributes from which this entity can be reconstructed.

3.1.2.2 AircraftPerformance

The AircraftPerformance entity extends the VehiclePerformance and contains details on:

• Normal touch down speed.

• Normal final approach speed.

• Normal take-off speed.

• Runway Deceleration (m/s2) in dry conditions.


14 Aug 2007

of 76

• Runway acceleration (m/s2) in dry conditions.

• Runway Deceleration (m/s2) in wet conditions (note: value will not be used in 2004).

• Runway acceleration (m/s2) in wet conditions (note: value will not be used in 2004).


3.1.3 Parsers The location of the TACR performance file is specified as a Resource e.g.

TACR.SCENARIO "twr/resources/scenario/tacrperforman ce.dat"

The items are read from the file using the parser objects derived from the EntityParser interface, and which are named <entity>Parser, as identified by the rules of the GSDK parser framework pattern and placed in the directory twr/tacr/parser.

TACR employs the following parsers:

• VehiclePerformanceParser

• AircraftPerformanceParser

3.1.4 Clients The TACRService is responsible for distributing the performance data to all subscribed client components.

3.1.5 Events No significant events are raised internally to the TACR component.

3.2 TOWER AIRSPACE SERVER (TASP)

3.2.1 Server The TASP component defines a TASPController that provides the initialisation and run-time control of distributed components. This component defines and maintains a set of airport object entities e.g. runway, taxiway definitions, etc. TASP extends the eDEP Airspace server (ASP) and provides a set of synchronous “get” methods to retrieve static information relating to airport entities. It also maintains the current state of airport stop bar entities, distributing the state information to clients when the state changes.

3.2.1.1 Airspace Orders

TASP supports airspace stop bar orders. On receipt of such an order the state of the named stop bar will be changed to that indicated i.e. “stop” or “go”.

3.2.2 Entities The following class diagram shows the environment in which the TASP entities exist.


14 Aug 2007

of 76

Figure 10: TASP Component and Entities

3.2.2.1 Taxipoint Class

The Taxipoint class is identified by a unique name and position and inherits from positioned entity. They also have a default-enforced delay for vehicles. The delay can take values ranging from 0 to infinity. The delay value is used when no user input value has been specified when constructing a vehicle’s navigation route.

The following example illustrates a Taxipoint called TP_05201_W00123 positioned at 52.01N 1.23W. It has a delay of 10s and has the added attribute of being a de-icing point. The delay and attribute are optional parameters. The delay has a default value of 0.

TAXIPOINT TP_N05201_W00123 52.01 1.23 DELAY 10 ATTR IBUTE DEICING

An associated serializable description class is defined, which holds a set of attributes from which this entity can be reconstructed.

3.2.2.2 Gate Class

The Gate Class extends the Taxipoint class and is defined by its position only.

GATE APR1_G1 52.01 1.23


14 Aug 2007

of 76

3.2.2.3 Taxiway Class

The Taxiway class is defined as a set of TaxiwaySegments. The collection of TaxiwaySegments can define different shaped taxiways varying from simple “string “like taxiways to a more “complex” star shaped taxiways.

3.2.2.4 TaxiwaySegment Class

The TaxiwaySegment class is defined as a set of joined Taxipoints and Gates with an optional set of associated traffic and speed constraints. The optional constraints define the status of the TaxiwaySegment (open [default], closed, arrivals only, departures only), the maximum speed [default set by resource TASP.TAXIWAY_MAX_SPEED] on the taxiway and the allowed vehicle size (heavy, medium, light [default is all set]). These constraints are pertinent to traffic travelling in both directions.

The Taxipoints and Gates can be either pre-defined or defined when specified in the Taxiway/TaxiwaySegment definition.

The following example illustrates a Taxiway with two TaxiwaySegments where the Taxipoints have been previously defined.

The first TaxiwaySegment t1_1 allows medium and light sized, arriving and departing aircraft to travel from Gate g1 to taxipoint tp3 via tp2 but must not exceed 10m/s. TaxiwaySegment t1_1 allows only medium sized arriving aircraft to travel from tp3 to tp2 to g1 at a maximum speed of 5m/s.

TAXIWAY t1 TAXIWAYSEGMENT t1_1 LEFT_RIGHT STATUS allow_both ALLOW (medium, l ight) MAX_SPEED 10 RIGHT_LEFT STATUS arrivals_only ALLOW (medium ) MAX_SPEED 5 CONNECTS GATE g1 TAXIPOINT tp2 TAXIPOINT tp3 END_CONNECTS

END_SEGMENT TAXIWAYSEGMENT t1_2 LEFT_RIGHT STATUS allow_both ALLOW (medium, l ight) MAX_SPEED 10 RIGHT_LEFT STATUS arrivals_only ALLOW (medium ) MAX_SPEED 5 CONNECTS TAXIPOINT tp3 TAXIPOINT tp4 TAXIPOINT tp5 END_CONNECTS

END_SEGMENT END_TAXIWAY


3.2.2.5 RunwayPerimeter Class

The RunwayPerimeter class defines a list of runway lineup points, a list of runway entry/exit points, start/end thresholds and touch down distance.


14 Aug 2007

of 76

Figure 11: RunwayPerimeter

The following example illustrates a runway with three holding points, two entry/exit points, start/end thresholds ad touch down distance from start threshold. The entry/exit points are assumed to join the runway centre line. All points are previously defined Taxipoints with their connectivity previously defined by a Taxiway definition.

RUNWAY_PERIMETER BHX_R21 FOR_RUNWAY BHX_R21 START_THRESHOLD 49.0241101 2.5704154 49.023707 2.5 704692 END_THRESHOLD 49.0204151 2.5130902 49.0208182 2.513 0398 TOUCH_DOWN_DISTANCE 50 COMPRISING LINEUP_POINTS BHX_R21_H1 BHX_R21_H2 BHX_R21_H3 END ENTRY_TO_RUNWAY_AT BHX_R21_EE1 BHX_R21_EE2 END EXIT_TO_RUNWAY_AT BHX_R21_EE1 BHX_R21_EE2 END END


3.2.2.6 GroundSector Class

The GroundSector class defines a geographic area at an airport. The ground sectors will partition jurisdication of runways, taxiways and aprons at the airport.


14 Aug 2007

of 76

Figure 12 Ground Sectors

The following example shows a ground sector defined by its bounding latitude and longitude points for a specified airport and the ground sector’s operating role and frequency.

GROUND_SECTOR LFPG_NORTH REGION 49.03 2.6 49.025 2.5 49.02 2.5 49.02 2.52 49.0227 2.5597 49.025 2.6 END

FOR_AIRPORT LFPG CONTROL_KIND TAXI

FREQUENCY 119.25 END


3.2.2.7 ExclusionArea Class

The ExclusionArea class defines a geographic area at an airport assocaited to a runway. The area will be used to enforce safety regulations at the runway, e.g whether multiple departures are allowed to lineup in the area. When defining safety rules for exclusion areas, an air boundary must be defined for arrivals referring to short and long final approach times to arrival. In addition an optional rule to apply reduced spacing can be applied where short and long final approach distances are used to qualify the approach safety rules.

Below are two examples of exclusion areas. The first area allows multiple lineup but does not apply reduced spacing rules. The second example disallows multiple lineups but does apply reduced spacing and so defines short and long final approach distances.


14 Aug 2007

of 76

EXCLUSION_AREA EXCLUDE_R27R REGION 49.0273 2.563 49.0263 2.563 49.0240 2.523 49.0249 2.523 END PROTECT RUNWAY R27R ALLOW_LINEUPS true AIR_BOUNDARY 50.0 100.0 REDUCED_SPACING NONE END EXCLUSION_AREA EXCLUDE_R27L REGION 49.0203 2.5131 49.0209 2.5131 49.0242 2.5705 49.0236 2.5705 END PROTECT RUNWAY R27L ALLOW_LINEUPS false AIR_BOUNDARY 50.0 100.0 REDUCED_SPACING APPLY 2000 2500 END


3.2.2.8 ATC Airport Class

Note the eDEP ATC Airport Class will be enhanced with an optional parameter defining the elevation of the airport above sea level.

AIRPORT KJFK 52.98 0.5 ELEVATION 1000 COMPRISING KJFK_R27 END

3.2.2.9 Stop Bar Class

The StopBar class is defined as a point from one taxipoint towards another taxipoint. The distance from the first taxipoint being specified as a distance or a percentage of the distance between the two taxipoints. Each stop bar will be named and have a state of “stop” or “go”.

3.2.3 Parsers The file containing the initial airport definitions is specified as a Resource e.g.

ASP.SCENARIO "twr/resources/scenario/airport.dat"

Development Note: The information required to derive the initial airport definitions will be extracted from the EEC supplied TAAM data using an offline conversion utility.

The airport items are read from the file using the parser objects derived from the EntityParser interface, and which are named <entity>Parser, as identified by the rules of the GSDK parser framework pattern and placed in the directory twr/tasp/parser.

TASP employs the following parsers:

• TaxiPointParser


14 Aug 2007

of 76

• TaxiwayParser

• RunwayPerimeterParser

• GateParser

• GroundSectorParser

• ExclusionAreaParser

• StopBarParser

3.2.4 Clients The TASPService object created on the client, distributes the entire airport data, or the complete subset of the airport data defined by the particular request, to all subscribed objects on the client component. Clients will also be able to register for Stop Bar state changes.

3.2.5 Events TASP signals the StopBarEvent to indicate the change of state of a Stop bar i.e. stop or go.

3.3 TOWER INITIAL FLIGHT PLAN (TIFPL)

3.3.1 Server The TIFPL component extends the eDEP Initial Flight Plan server (IFPL) and defines a TIFPLController that provides the initialisation and run-time control of distributed components. TIFPL provides the source of flight plans when the TWR system runs in stand-alone mode or when the TWR system runs in conjunction with the eDEP ATC system.

TIFPL enhances the flight plan with 2D taxi route information. For departures the taxi route will take the aircraft from an apron gate to a runway. For arrivals the taxi route will take the aircraft from runway to gate. It should be noted that a flight may depart from an airport and return to the same airport i.e. the origin and destination airports are the same. This may be the case when the TWR system is run in conjunction with the eDEP ATC system.

To simulate airport “service vehicles” a 2D taxi route can also specify a route from one point at the airport to another point.

Note for both vehicles and aircraft the route will not define the complete route plan. For example the route may only identify the runway and apron gate for an arriving aircraft.

3.3.2 Entities The following class diagram shows the environment in which the TIFPL entities exist.


14 Aug 2007

of 76

Figure 13: TIFPL Component and Entities

3.3.2.1 AirportArrival

Flights arriving at a Tower simulated airport are represented by the AirportArrival Class.

The AirportArrival defines the arriving aircraft’s callsign, optional taxi speed (default specified by Resource TIFPL.AIRCRAFT_TAXI_SPEED ) and taxi route.

The taxi route defines the runway that the named aircraft will touch down on and the final terminal gate at which the aircraft will park. The route to be taken from the runway to the gate can be further qualified with constraints (see TaxiRoutePlan). Given the runway, gate and optional constraints the route will be further expanded by the DNS.

Turnaround flight plans represent an arrival completing its journey and starting a new departure journey with a different callsign. To initiate a turnaround flight the AirportArrival specifies an optional TURNAROUND callsign.

Further flight plan information on the arriving aircraft and if present the turnaround aircraft can be extracted from the ATC IFPL using the specified callsigns.

A typical example of an AirportAriival command is shown below.

AIRPORTARRIVAL KLM_ARR TAXI_SPEED 10 TURNAROUND KLM_DEP TAXIROUTE RUNWAY EGBH_R270


14 Aug 2007

of 76

GATE EGBH_APR1_GATE2 END

3.3.2.2 AirportDeparture

Flights departing from a Tower simulated airport are represented by the AirportDeparture Class.

The AirportDeparture defines the departing aircraft’s callsign, optional taxi speed (default specified by Resource TIFPL.AIRCRAFT_TAXI_SPEED ) and taxi route.

The taxi route defines the apron gate (starting point) of an aircraft and the runway, which the aircraft will take-off from. The route to be taken from the gate to the runway can be further qualified with constraints (see TaxiRoutePlan). Given the gate, runway and optional constraints the route will be further expanded by the DNS.

A pushback manoeuvre can be associated with the first point. This will involve the aircraft requesting clearance for pushback before reversing down the taxiway to the first taxipoint where it is able to carry on in a forward direction.

Further flight plan information on the departing aircraft can be extracted from the ATC IFPL using the specified callsigns.

A typical example of an AirportDeparture command is shown below.

AIRPORTDEPARTURE KLM_DEP TAXI_SPEED 10 PUSHBACK TAXIROUTE GATE EGBH_APR1_GATE2 RUNWAY EGBH_R270 END

3.3.2.3 VehiclePlan

A VehiclePlan is analogous to the AirportArrival/AirportDeparture but for airport service vehicles. The plan defines the activation time, origin (i.e. airport), type, size (heavy, medium, light), optional taxi speed (default specified by Resource TIFPL.VEHICLE_TAXI_SPEED ) and route.

For airport service vehicles the only condition on the route definition is that there must be at least one point specified. The vehicle route to be taken can be further qualified with constraints (see TaxiRoutePlan). Given the taxi route and optional constraints the route will be further expanded by the DNS.

An example of a vehicle plan is shown below

VEHICLEPLAN AMBULANCE ACTIVATION "16:30:00" ORIGIN EGBH SIZE MEDIUM TYPE VAN TAXI_SPEED 10 TAXIROUTE TAXIPOINT APR1_GATE_EMG END

3.3.2.4 TaxiRoutePlan

A TowerFlighPlan can be defined for airport departures, arrivals and for airport service transport, which will be expanded by the DNS.


14 Aug 2007

of 76

The route and optional taxi speed may be supplemented further by specified or default constraints along the taxi route. 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.

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 DNS may add further points to achieve the desired destination. Also the route is a planned taxi route with the actual route possibly acquiring further time and speed constraints.

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

3.3.3 Parsers The file containing the Tower airport arrival, departure and vehicle plan definitions is specified as a Resource e.g.

IFPL.SCENARIO "twr/resources/scenario/towerplans.da t"

The airport items are read from the file using the parser objects derived from the EntityParser interface, and which are named <entity>Parser, as identified by the rules of the GSDK parser framework pattern and placed in the directory twr/tifpl/parser.

The TIFPL TowerFlightPlanParser extends the IFPL FlightPlanParser and employs the following parsers:

• AirportArrivalParser

• AirportDepartureParser

• TaxiRouteParser

• VehiclePlanParser

3.3.4 Clients At a parameterised time before the flight activation time of an arrival/departure, the TIFPLService signals a TifplEvent to indicate the activation of a new tower flight plan. This event may be subscribed to by interested components in both the Tower and eDEP ATC systems.


14 Aug 2007

of 76

3.3.5 Events The TIFPL signals the TowerFlightPlanEvent to indicate the introduction of a flight plan relevant to the TWR system. The event is raised in response to the server side generated AifplMessages and specifies the new callsign and flight plan details.

3.4 DETAILED NAVIGATION SERVER (DNS)

3.4.1 Server The DNS component defines a DNSController that provides the initialisation and run-time control of distributed components. The DNS comprises an application that converts a set of constraints in a constraint list into a navigation script comprising of a set of 2D points identifying the airport route and time estimates to be taken by a vehicle or aircraft.

The DNSController object initialises by fetching airport data from TASP and performance data from TACR. It then responds to subscriptions to navigation script generation where it processes flight plan route descriptions and associated constraints to determine the aircraft route. The flight plan route description defines the latest estimated location of the aircraft and the required destination. The constraints define waypoints that must be traversed or avoided.

The algorithm to determine the optimum route uses a simple exhaustive search algorithm, constrained by any intermediate constraint points that force the route through given points, or which force the route to avoid given points. The search is further constrained by applying a heuristic constraint, which orders the possible routes by calculating which route will have the effect of reducing the straight line distance from the aircraft to the runway entry point. If no route is found, then the algorithm widens its search to follow routes that take the aircraft away from the runway entry.

The diagram in Figure 14 below shows how the heuristic constraint might work in a simple network. A route needs to be established from an apron at A to a runway at R:

Figure 14: Example Airport Layout for DNS Calculation

The solution route is drawn from apron point A to runway entry point B. The taxiways drawn as curving routes from the runway indicate runway exit only routes. Each route point (or node) marked with a square identifies a taxiway intersection, and establishes the required route to the runway. The algorithm performs an exhaustive search from each of these nodes, filtered by the heuristic constraint, looking for a connected node that is closer to the target runway entry point, and a node that has not yet been traversed.


14 Aug 2007

of 76

Clients of DNS will submit navigation constraints through the DNSService (see Figure 15). These constraints are then scheduled by the DNSController and processed by the internal GenerateScriptEvent. The resulting NavigationScriptMessage is returned to the client interface.

Figure 15: DNS Calculate Navigation Script

The algorithm to calculate the navigation script is described in the following pseudo code:

public Route findPath( Node a, Node b ) { if ( a is not connected to b ) then for each unvisited node from a, a’ for each unvisited node from b, b’ set a’ and b’ visited = true if ( a’ and b’ meets the heuristic constraint ) then route = route(a, a’)+findPath(a’, b’)+route(b, b’) if ( route < optimum route ) optimum route = route end if end for end for return optimum route else return direct route(a, b) end if } // End method findPath


14 Aug 2007

of 76

It is assumed that the start point and the required end point will be inputs to the algorithm. The start and end points may not necessarily be a runway or an apron gate.

3.4.2 Entities To construct the network of taxiway segments DNS utilises existing GSDK network objects, including abstract definitions for nodes, pathways and the whole network. These provide a framework for developing network search algorithms. Each pathway comprises a set of path segments, which can each define a speed limit, the size of aircraft allowed and the current status (open, closed etc).

3.4.3 Parsers The DNS does not employ any parsers.

3.4.4 Clients The DNSService reports its results to the subscribed clients using a DNS script tag mechanism to filter the results to the appropriate destination. The generated navigation scripts are signalled to the client application through NavigationScript events.

3.4.5 Events The DNS tags and raises the NavigationScriptEvent in the DNS Service, after the service has processed the DNS server generated tagged NavigationScriptMessages. The event will specify the calculated route and associated constraints and time estimates.

3.5 TOWER PILOT MANAGER (TPM)

3.5.1 Server The TPM application models the movements and the interactions between aircraft and other service vehicles that impede the progress of the aircraft to its gate after landing or to the runway entry point on take-off. The TPM will model the motion at the parking gate, the motion along the taxiways, accounting for intersections, holding points, other traffic, taxiway speed limits and weather conditions. It will also model the aircraft acceleration on take-off and the deceleration on landing.

The TPM comprises an application made from a scenario database object defining each of the piloted tower flights.

The TPM component defines a TPMController that provides the initialisation and run-time control of distributed components. At initialisation TPM creates and enables the following services:

• TASP for airport data.

• TACR for performance data.

• Time service.

• eDEP PM ATC PilotedFlightService.

• DNS for navigation scripts.

• TIFPL for tower initial flight plans.


14 Aug 2007

of 76

3.5.1.1 Pilot Orders

The following pilot orders are supported. They are detailed in two lists, those that require TPM to interrogate DNS for a new navigation route and those that affect the state of the navigation.

Pilot orders implying new navigation route: •••• Change-route from runway exit point to gate (complete arrival taxi route). •••• Change-route from gate to runway entry point (complete departure taxi route). •••• Change-gate (partial arrival taxi route). •••• Change-runway (partial departure taxi route). •••• Change-SID (departure initial airborne route). •••• Change-route (complete or partial route with optional extra constraint points).

Pilot orders affecting navigation: •••• Pushback. •••• Stop. •••• Taxi. •••• Delete flight. •••• Line-up. •••• Take-off. •••• Transfer to frequency. •••• Conditional Line-up •••• Conditional Take-off •••• Stop-ahead •••• Taxi Speed

3.5.1.2 Pilot Frequency

TPM maintains a list of subscribed TPWP components and their associated frequencies. The Resource TPWP.DEFAULTS is used to define the name of the default TPWP to be used to control flights/vehicles. If undefined the first TPWP to register interest with TPM is nominated as the default. The ATC airspace is used to determine the ATC sectors and their associated frequencies, and the details added to the list of available transfer options with a flag indicating they are ATC positions.

The TPM will register as a pilot position to the PM to receive frequency transfer messages from the ATC system for the airport sector. Registration to the PM is made using a resource-defined frequency (TPM.FREQUENCY).

When a PilotedFlight or PilotedVehicle is first created its initial ground sector will be determined. The ground sector will have an associated frequency. If the frequency is one registered by a TPWP it is used as the initial frequency for the flight/vehicle. If the PM is connected and a new PilotedFlight is an arrival, then the TPM will not assign the frequency. The PM will assign the initial controlling pilot position. Airborne arrivals can be transferred into the Tower system by an ATC pilot, or will be assigned an initial frequency as above when they land. Departures under control of a TPWP will maintain their controller on takeoff until transferred to an ATC sector. If there are no TPWP positions available for a flight when the PM is connected, a default ATC frequency will be assigned (TPM.NEXT_ATC_FREQUENCY).

As ground sectors may not be mutually exclusive, a priority is given to the ground sectors when searching for the initial ground sector. When the flight is a departure, apron ground sectors will be searched followed by taxiway then runway ground sectors. When the flight is an arrival, runway ground sectors will be searched followed by taxiway then apron ground sectors. For vehicles the priority will be apron, runway then taxiway.

If the flight/vehicle is within a ground sector whose frequency does not match any registered TPWP frequency then it will be allocated to the default TPWP. If there is no default TPWP then the flight/vehicle will be left uncontrolled.


14 Aug 2007

of 76

Two variants of the FrequencyTransfer order will be implemented. The first will indicate the old and new frequencies, leaving TPM to determine the TPWP. The second order will extend the first and include the old and new TPWP names.

Two or more TPWPs may operate on the same frequency although a flight/vehicle will only be controlled by one TPWP.

No balancing of traffic to TPWP will be performed by TPM.

3.5.1.3 Manoeuvre Prompts

TPM will check each flight at regular intervals and assign a manoeuvre prompt to it based on its current state. The manoeuvre prompt will be distributed as part of the ProgressUpdateEvent, and specifie prompts for pushback, taxi, line-up and takeoff.

The pushback prompt will be displayed at a configurable interval before a flight’s estimated time of departure if the navigation script identifies a pushback is required and a pushback clearance has not been received.

The taxi prompt will be displayed whenever a flight has started on its navigation script and been subsequently stopped (e.g. via a hold order or stop-ahead order) while line-up and takeoff clearances are not required. The taxi prompt will also shown at a configurable interval before a flight’s estimated time of departure if a taxi prompt has not already been received and a pushback clearance is not required.

The line-up prompt will be displayed when a flight reaches the lineup point specified on its navigation script, if required, or at a configurable interval before it is reached, and no line-up or takeoff clearance has already been received.

The takeoff prompt will be displayed when a flight reaches the end of its navigation script, or at a configurable interval before it is reached, and no takeoff clearance has already been received.

3.5.1.4 Navigation Script

TPM then registers interest with DNS for NavigationScriptEvents and to TIFPL TifplEvents (see Figure 16).

On receipt of a TifplEvent the TPM will submit the flight plan (tagged with PILOT) to DNS to generate the Navigation script. When the DNS generated navigation script is returned TPM initialises its piloted tower flight.


14 Aug 2007

of 76

Figure 16: TPM Navigation Control

On receipt of a Navigation script TPM determines what type of movement simulation is required i.e. arrival or departure; and then assess if any clearance is required to initiate the motion. If a clearance is required then the aircraft remains stationary until a controller submits an order. When cleared to continue the TPM GMS (Ground Movement Simulator) object updates the aircraft position along the navigation route on a time step basis.

The GMS function of the TPM is designed to be a pluggable object, allowing a substituted algorithm to be used if required.

GMS assumes constant speed along taxiways, but will model the acceleration and deceleration of the aircraft on the runway on take off and landing respectively, using standard kinematics equations for initial speed u, final speed v, acceleration a, distance s and time t:

atuv

asuv

atuts

+=+=

+=

222

221

As GMS drives the piloted object along the navigation trajectory it checks that the next update does not contravene any traffic rules. Airport traffic rules include

• Vehicles/aircraft shall not overtake each other on taxiway routes i.e. taxiing speeds shall be varied to accommodate forward traffic.

• Vehicles/aircraft shall queue behind stationary traffic at a distance defined by the performance data.

• Arriving aircraft shall give way to departing aircraft at crossing points, and then Aircraft shall ‘give way to the right’ at crossing points.


14 Aug 2007

of 76

If the next update contravenes any of these rules then the vehicle/aircraft will pause until the congestion clears. This will necessitate the vehicle/aircraft to stop at a performance-defined distance before the congested segment.

As the GMS works on a time step basis the GMS takes into account any holding points, i.e. taxipoints defined with a delay, and pauses the vehicle/aircraft at that point This prevents any vehicle/aircraft from “hopping” over any holding points and missing any delay commands.

While traversing the navigation route more navigation orders may be required, for example if an aircraft encounters an airport taxipoint with holding information.

3.5.1.5 Apron Navigation

TPM models aircraft moving between a parking gate and the edge of the apron. This motion is modelled as a trajectory from a TASP taxipoint (of type gate) along a set of taxiway segments.

If an aircraft requires to pushback then TPM will simulate the aircraft reversing along the taxiway until it reaches a taxipoint where it can continue in a forward direction. On reaching such a taxipoint the aircraft will wait for clearance to continue.

An arrival aircraft that parks at a gate and occupies the gate for more than the parameterised Resource time (TPM.ARRIVAL_OCCUPANCY_TIME) will be terminated.

A departure aircraft whose initial position is at a gate occupies the gate for a parameterised time (TPM.DEPARTURE_OCCUPANCY_TIME) before it can proceed taxiing.

3.5.1.6 Taxiway Navigation

TPM models aircraft moving between the edge of the apron and the edge of the runway. This motion is modelled as motion along a set of taxiway segments and extends the motion along the apron taxiway segments.

3.5.1.7 Runway Navigation

TPM models aircraft moving between runway entry/exit points and the landing/takeoff point. This motion is modelled using a constant acceleration model for take-off and a constant deceleration model for landing. Given a take-off speed vt, starting speed utand acceleration at, and a landing speed ul, a runway exit speed for a landing aircraft of vl and deceleration al, the take-off and runway stop/exit distance (sl) and take-off distance (st) can be calculated by rearranging the kinematic equation:

l

lll

t

ttt a

vusand

a

uvs

asuv

22

22222

22

−=

−=

+=

The position on the runway can then be calculated at an arbitrary time up to the take-off point for departing aircraft and up to the stop/exit point for arriving aircraft. Where a landing aircraft is planned to leave the runway using a given runway exit, the aircraft will attempt to decelerate to the required speed for that exit to be taken. If the speed is not attained the aircraft will still exit the runway at that point obeying the taxiway speed restrictions but an error will report that the aircraft did not attain the correct speed before leaving the runway. In wet conditions, the wet weather acceleration and deceleration values are used. The weather conditions at the airport are indicated by a system Resource (<THE_AIRPORT_NAME>.WET = true)

Development Note: The ATC PM will be enhanced to provide an AirportControl service which:


14 Aug 2007

of 76

• Shows the availability of the service

• Allow clients to register interest in touchdown

• Allow clients to assume control of the activation of departures for the airport.

TPM controls the motion of arrivals as they touchdown and taxi to the gate where they park and departures as they leave the gate, taxi and takeoff (see Figure 18).

TPM determines the existence of the eDEP ATC PM component by checking the availability of the PM AirportControlService. If present TPM registers interest with PM TouchDown Events and State Vector information. TPM then uses the State Vector information to supplement its entities with airborne entities. The position of these airborne entites are only updated by receipt of further State vector information. TPM uses the TouchDown event to time the introduction of arrivals where by the corresponding airborne entity is no longer considered as airborne and its position will then be updated directly by TPM. Also, if PM is present TPM has the responsibility of activating a flight in the eDEP ATC system at the point of takeoff.

To maintain synchronisation PM must run at a rate equal or faster than TPM. When running at a faster rate the rates must be an exact multiple to maintain consistency e.g. equal rates of 1s or TPM every 0.5 s and TPM every 1s.

As the order of execution between TPM and PM can not be guaranteed and in fact can change, when running in connected mode TPM will only notify its subscribers to PilotPosition and ProgressUpdate messages when all expected PM messages have been received.

This is illustrated in the sequence diagram below where PM processes the T1 interval before TPM and TPM processes the T2 interval before PM. In the T2 interval TPM does not inform its clients until the PM StateVectorMessage has been received and processed.

This real time delay is necessary as PM processes all the simulation events that occur > T1 and <= T2 at the T2 boundary. Therefore if TPM processes the interval before PM, airborne positions would need to be extrapolated for T2 and any events that occur in the interval > T1 and <= T2 would not be serviced until T3. Thus arrivals at the point of touchdown in the >T1 and <=T2 interval could be misrepresented.


14 Aug 2007

of 76

Figure 17: TPM and PM Synchronisation

TPM uses the internal GMS events ArrivalTerminated and DepartureAirborne events to terminate its interest in the PilotedEntities.


14 Aug 2007

of 76

Figure 18: TPM Touchdown, Takeoff and Parking

3.5.2 Entities The TPM maintains a database of piloted flight objects, which provide an interface for not only piloted flights but also piloted vehicles. This is illustrated in the following diagram, which shows the components entities and services.


14 Aug 2007

of 76

Figure 19: TPM Component and Entities

3.5.2.1 PilotedVehicle

The PilotedVehicle entity defines an interface to the methods provided by a piloted tower vehicle implementation object, managed within the TPM database. This object provides methods to support the following key areas of functionality:

• Generation of navigation and manoeuvre progress.

• Generation of positional information.

• Processing client vehicle navigation orders and clearances e.g. taxi, pause.

3.5.2.2 PilotedFlight

The PilotedFlight entity extends PilotedVehicle and defines an interface to the methods provided by a piloted tower flight implementation object, managed within the TPM database. In addition to the PilotedVehicle methods this object provides methods to support the following key areas of functionality:

• Processing client aircraft navigation constraints e.g. takeoff

3.5.3 Parsers The TPM does not employ any parsers.


14 Aug 2007

of 76

3.5.4 Clients As TPM updates the piloted tower objects on a time step basis the TPM notifies clients who have registered interest in the TPMService PilotPositionEvents and ProgressUpdateEvents at the rate specified by the subscribed client.

The PilotPositionEvents can be qualified with a range and height relative to the airport. This allows the surrounding airspace to be filtered for only traffic in the vicinity of the airport.

The subject entities of these events can be solely ground moving traffic or ground moving traffic supplemented with airborne traffic.

TPM offers a service for clients to submit Navigation and Frequency Transfer orders.

After receiving a Navigation order, a new or modified Navigation script will be generated. TPM will then notify clients who have registered interest in the TPMService for PilotedNavigationEvents.

Navigation orders for Conditional Line-up or Take-off, Stop-ahead or Taxi speed will be applied. TPM will then notify clients who have registered interest in the TPMService for ConditionalOrderEvents, StopAheadEvents or TaxiSpeedEvents respectively.

After receiving a Frequency Transfer order TPM will determine the new controlling TPWP and frequency and notify clients who have registered interest in the TPMService for FrequencyTransfer Events.

3.5.5 Events The TPM raises a number of events for clients in the TPM Service, after the service has processed the TPM server generated messages:

• PilotedNavigationEvent indicates the Initial flight plan and current navigation script.

• PilotPositionEvent indicates the new aircraft positions. The event will indicate if it is the first, update or final report for the aircraft. The event is raised in response to the server side generated PilotPositionMessages.

• ProgressUpdateEvent indicates the new aircraft positions and manoeuvre status. The event is raised in response to the server side generated ProgressUpdateMessages. The event will contain the following information:

� Position � The manoeuvre = [pushback | taxi | takeoff | paused] � From Waypoint � To Waypoint � Airborne flag � Manoeuvre Prompt

• ConditionalOrderEvent indicates the list of conditional orders for the specified flight has changed. The event is raised in response to a conditional order being created, superseded by issuing a manoeuvre clearance or by the processing of a conditional order.

• StopAheadEvent indicates the new list of stop-ahead points for a flight or vehicle. The event is raised in response to a stop-ahead point being added or removed.

• TPWPFrequenciesEvent indicates the new list of frequency / TPWP pairs. The event is raised in response to the subscription of a new TPWP to the TPM.

• TransferFrequencyEvent indicates the controlling frequency and TPWP for the specified flight.


14 Aug 2007

of 76

3.6 TOWER FLIGHT MANAGER (TFM)

3.6.1 Server The TFM provides a set of functions to distribute navigation and coordination details, which plan the progress of aircraft in the Tower system. TFM comprises an application made from a scenario database object defining the planned flight and vehicle traffic at the airport.

The TFM component defines a TFMController that provides the initialisation and run-time control of distributed components. At initialisation TFM creates and enables the following services:

• Time service.

• TASP service.

• DNS for navigation scripts.

• TIFPL for tower initial flight plans.

• TFPM service for progress events

The TFM will initialise by registering interest in the Time Service, TASP airspace, DNS for navigation scripts, TIFPL for the generated tower initial flight plans and the TFPM for progress messages (see Figure 22).

On receipt of a TifplEvent the TFM will create a flight entity and submit the flight plan (tagged with the airport name) to DNS to generate the Navigation script. The TFM then relays this initial navigation information to any clients (e.g. TFPM). Also on receipt of the TifplEvent the TFM will notify subscribers of the creation of arrival/departure coordination for this flight.

As arrival flights progress, TFM maintains the estimate and actual landing (LDT) and in-block (IBT) times. Initially these times are estimated from the flight plan information.

When the Tower system is in connected mode estimate landing times (eLDT) are updated on receipt of Advance Boundary Information (ABI) and Inbound messages submitted by TCS.

When in connected or standalone mode LDT becomes actual on radar detecting touchdown. The IBT becomes actual on radar detecting parked at stand.


14 Aug 2007

of 76

Figure 20: LDT and IBT

As departure flights progress, TFM maintains the estimate, target and actual off block (OBT) and take off (TOT). Initially these times are estimated from the flight plan information.

OBT becomes actual on radar detecting movement from stand. At this point the TOT becomes a target TOT. The TOT becomes actual on radar detecting take-off.

Figure 21 : TOT and OBT.

On receipt of a turnaround progress message from TFPM the TFM will activate the corresponding flight plan in the TIFPL using the associated callsign.

On receipt of progress messages from TFPM indicating pushback, taxi, lineup or takeoff due then TFM will issue cleaeance due messages to its clients.


14 Aug 2007

of 76

Figure 22: TFM Navigation Control

When clients submit navigation orders to govern the manoeuvres of an aircraft around the airport, the TFM will interpret the orders and re-interrogate the DNS for an updated navigation script. When validated a new NavigationMessage is raised for the associated aircraft.


14 Aug 2007

of 76

Using radar detected movement and advance boundary information TFM will maintain estimated, target and actual times for off/in block, take-off and landing. When these times are updated a new NavigationMessage is raised for the associated aircraft.

When clients submit pushback, line-up or take-off clearances for an aircraft TFM will record the requested clearance and notify clients of the aircraft’s entity change of clearance state.

When clients (e.g. DMAN) submit managed off block, managed take-off and recommended time to next clearance for an aircraft TFM will record the managed data and notify clients of the aircraft’s entity change of managed data.

3.6.2 Entities The TFM maintains a database of flight objects, which provide an interface for not only flights but also service vehicles and managed departures. This is illustrated in the following diagram, which shows the components entities and services.

Figure 23: TFM Component and Entities

3.6.2.1 Vehicle

The Vehicle entity defines an interface to the methods provided by a tower vehicle implementation object, managed within the TFM database. This object provides methods to support the following key areas of functionality:

• Distribution of planned navigation.

• Generation of planned positional information.

• Processing client navigation constraints e.g. taxi, pause.

3.6.2.2 Flight

The Flight entity defines an interface to the methods provided by a tower flight implementation object, managed within the TFM database. This object provides methods to support the following key areas of functionality:


14 Aug 2007

of 76

• Processing client planned navigation constraints e.g. take-off.

• Flight status.

• Requested clearances.

3.6.2.3 ManagedDeparture

The ManagedDeparture defines an interface to the methods provided by the tower flight implementation object for Flight. This object provides methods to support the following key areas of functionality:

• Managed off block time (MOBT)

• Managed take-off time (MTOT)

• Recommneded time until clearance.

3.6.3 Parsers The TFM does not employ any parsers.

3.6.4 Clients After a new or modified Navigation script has been requested and generated the TFM notifies clients who have registered interest in the TFMService for NavigationEvents.

After a new clearance request TFM notifies clients who have registred interest in changes to an aircraft’s entity clearance state.

Receipt of a TifplEvent, indicating a new flight plan for the TWR system, triggers TFM to notify clients who have registered interest in InitialTowerFlightPlanEvents.

TFM offers a service for clients to submit navigation orders. The TFM interprets the orders and re-interrogates the DNS for planned navigation details.

3.6.5 Events The TFM raises a number of events for clients in the TFM Service, after the service has processed the corresponding TFM server generated message:

• NavigationEvent indicates new planned navigation details including route and time estimates. The event is raised in response to the server side generated NavigationMessage.

• InitialTowerFlightPlanEvent initiates controller coordination indicating coordination role, status and controlled object. The event is raised in response to the server side generated InitialTowerFlightPlanMessages.

3.7 TOWER FLIGHT PROGRESS MONITOR (TFPM)

3.7.1 Server The TFPM component comprises an application made from a scenario database object defining each tower aircraft and vehicle to be monitored, and for which progress events are to be generated.

The TFPM component defines a TFPMController that provides the initialisation and run-time control of distributed components. TFPM starts its initialisation by fetching airport data from TASP, then registers interest in:

• Time Service


14 Aug 2007

of 76

• NavigationEvents from TFM

• ProgressUpdateEvents from TPM.

As TFPM receives position progress updates from the TPM it checks them against the navigation information from the TFM. When any significant points/activities along the navigation are reached a ProgressMessage will be despatched. The following progress messages are defined for the TFPM:

3.7.1.1 TakeOff

The aircraft has taken-off when Manoeuvre is set to takeoff and ManoeuvreCompleted set true.

3.7.1.2 TouchDown

The aircraft has touched down when the first ProgressUpdate is received for an arrival aircraft.

3.7.1.3 PushBackStart

Push back will have started when Manoeuvre is set to pushback and ManoeuvreStarted is true.

3.7.1.4 PushBackCompleted

Push back will have completed when Manoeuvre is set to pushback and ManoeuvreCompleted is true.

3.7.1.5 StartTaxi

StartTaxi is indicated by the current Manoeuvre is set to taxi but is different to the last reported Manoeuvre.

3.7.1.6 GroundSectorExit

A GroundSectorExit message will be reported when an aircraft’s position is reported as outside the ground sector when the previous report placed the aircraft within the ground sector.

3.7.1.7 GroundSectorEntry

A GroundSectorEntry message will be reported when an aircraft’s position is reported as inside the ground sector when the previous report placed the aircraft outside the ground sector.

3.7.1.8 TaxipointPassed

A Taxipoint will have been passed when the Manoeuvre is not set to paused and the last reported ToTaxipoint becomes the new reported FromTaxipoint.

3.7.1.9 LineUpStart

Line Up has started when Manoeuvre is not set to paused and the FromTaxipoint is a runway holding Taxipoint for the runway identified in the NavigationMessage.

3.7.1.10 LineUpCompleted

Line Up has completed when the aircraft has reached the NavigationMessage’s runway entry/exit Taxipoint and has a heading equivalent to the runways’s heading.


14 Aug 2007

of 76

3.7.1.11 RunwayExit

A RunwayExit message will be reported when an aircraft’s position is reported as outside the area defined by the runway perimeter’s start and end threshold and when the previous report placed the aircraft within the start/end thresholds.

3.7.1.12 ParkedAtGate

An aircraft has parked when the FromTaxipoint and the ToTaxipoint are the same gate Taxipoint. This gate must also be the gate identified in the NavigationMessage.

3.7.1.13 Turnaround

Turnaround is indicated when an arrival has parked and its NavigationMessage indicates that it is a turnaround flight.

3.7.1.14 Terminated

An arrival aircraft will be terminated if the aircraft has been stationed at its NavigationMessage’s gate for a parameterised Resource (ARRIVAL_OCCUPANCY_TIME) time.

Any aircraft that takes-off will be reported as terminated.

3.7.1.15 GateOccupied

A GateOccupied message is raised when a departure is activated at a gate, and when an arrival parks at a gate.

3.7.1.16 GateVacated

A GateVacated message is raised when a pushback or taxi is initiated by an aircraft that is at a gate, or when an arrival is terminated at a gate.

3.7.2 Entities The TFPM maintains a database of monitored objects, which provide an interface for not only flights but also service vehicles. This is illustrated in the following diagram, which shows the components entities and services.


14 Aug 2007

of 76

Figure 24: TPFM Component and Entities

3.7.2.1 MonitoredVehicle

The MonitoredVehicle entity defines an interface to the methods provided by a monitored tower vehicle implementation object, managed within the TFPM database. This object provides methods to support the following key areas of functionality:

• Positional progress includes groundsector exit/entry, runway exit/entry, Taxipoint passed.

• Manoeuvre progress e.g. start taxi

3.7.2.2 MonitoredFlight

The MonitoredFlight entity extends the MonitoredVehicle entity and defines an interface to the methods provided by a monitored tower flight implementation object, managed within the TFPM database. In addition to the MonitoredVehicle methods this object provides methods to support the following key areas of functionality:

• Manoeuvre progress, includes pushback start/completed, lineup start/completed, turnaround, take-off, touchdown.

3.7.3 Parsers The TFPM does not employ any parsers.

3.7.4 Clients When any significant points/activities along the navigation are reached TFPM will notify any clients who have registered interest in the TFPMService ProgressEvents.

3.7.5 Events The TFPM raises a number of events for clients in the TFPMService, after the service has processed the corresponding TFPM server generated message: These events are:

• TakeOffEvent – Identifies aircraft and runway.

• TouchDownEvent – Identifies aircraft and runway.

• PushBackStartEvent - Identifies aircraft.

• PushBackCompleted Event - Identifies aircraft.

• StartTaxiEvent - Identifies aircraft.

• GroundSectorExitEvent - Identifies aircraft and ground sector.

• GroundSectorEntryEvent - Identifies aircraft and ground sector.

• TaxipointPassedEvent - Identifies aircraft and Taxipoint.

• LineUpStartEvent - Identifies aircraft and runway.

• LineUpCompletedEvent - Identifies aircraft and runway.

• RunwayExitEvent - Identifies aircraft and runway.

• ParkedAtGateEvent - Identifies aircraft and gate.

• TurnaroundEvent - Identifies aircraft and turnaround callsign.

• TerminatedEvent - Identifies aircraft.


14 Aug 2007

of 76

• GateOccupied – Identifies gate.

• GateVacated – Identifies gate.

3.8 TOWER INTEGRATED AIR SURVEILLANCE (TIAS)

3.8.1 Server The TIAS is comprised of an application made from a scenario database object defining Tower detected tracks. The TIAS component defines a TIASController that provides the initialisation and run-time control of distributed components. At initialisation TIAS creates and enables the following services:

• Time service.

• TPM for pilot reported positions.

• ATC IAS for airborne reported positions.

TIAS receives PilotPositionEvents from TPM and relays the information onto the client side service as PositionUpdateMessages. PositionUpdateMessages are transmitted at a parameterised Resource interval (TIAS.POSITION_UPDATE_INTERVAL), typically every 6 seconds and contain the latest reported pilot position. The PositionUpdateMessage may contain one or more entries for different flights, up to a maximum of about 10 entries. By grouping together in this way, the network load may be moderated, by reducing the total number of messages being sent to subscribed components.

TIAS receives TrackUpdateEvents from IAS and relays the information onto the client side service as AtcPositionUpdateMessages. AtcPositionUpdateMessages are transmitted to the client side immediately the TrackUpdateEvent is received.

Note when operating in standalone mode no IAS track information will be received, therefore only Tower ground track information will be distributed to clients.

3.8.2 Entities

3.8.2.1 Track

The Track entity extends the mobile entity to support an implementation object, managed within the TIAS database. The Track entity provides the positional and kinematic status of the object. The following class diagram shows the environment in which the Track class exists.


14 Aug 2007

of 76

Figure 25: TIAS Component and Entities

3.8.3 Parsers The TIAS does not employ any parsers.

3.8.4 Clients The TIASService provides a client side service to register for PositionUpdateEvents and AtcPositionUpdateEvents. PositionUpdateEvents are raised when the client service receives a PositionUpdateMessage from the server and AtcPositionUpdateEvents on receipt of AtcPositionUpdateMessages.

PositionUpdateEvents will contain ground moving tracks and possibly airborne tracks in the vicinity of the airport.

AtcPositionUpdateMessages will contain only airborne tracks.

3.8.5 Events The TIAS raises the PositionUpdateEvent in the client-side TIAS Service. The event contains an indication of the position update type i.e. creation, update or destroy, plus the x, y position for the named track.

The TIAS raises the AtcPositionUpdateEvent in the client-side TIAS Service. The event contains an indication of the position update type i.e. creation, update or destroy, plus the x, y, z position for the named airborne track.


14 Aug 2007

of 76

3.9 TOWER COORDINATION SERVER (TCS)

3.9.1 Server The TCS component comprises an application and a database of coordinated objects for which flight plans are available, and for which jurisdiction control state events are to be generated.

The TCS component also defines a TCSController that provides the initialisation and run-time control of distributed components. At initialisation TCS creates and enables the following services:

• Time service.

• TASP service.

• TFM service.

• TFPM service.

• eDEP CS ATC CoordinatedFlightService.

TCS then registers for InitialTowerFlightPlanEvents and NavigationMessages from TFM. NavigationMessages include details of updated (changed) routes, which require TCS to recalculate the next and future controllers who will have jurisdiction over the flight (see Figure 26).


14 Aug 2007

of 76

Figure 26: TCS Navigation Control

TCS also registers interest in takeoff, parking and touch down ProgressMessages from TFPM (see Figure 27).

When in standalone mode a Takeoff message is used to initiate the termination of Tower jurisdication. The actual termination time will be derived using a system resource to delay the action. When the ATC layer is connected termination of departures will be signalled by the ATC CS component.

A ParkedAtGate ProgressMessage will terminate the Tower jurisdiction for arrivals.

A Touchdown ProgressMessage will initiate the Tower jurisdiction for arrivals.


14 Aug 2007

of 76

Figure 27: TCS Touchdown, Takeoff and Parking


14 Aug 2007

of 76

At initialisation TCS instantiates its own eDEP ATC CS CoordinationMonitorService and if active receives/hands-over jurisdiction of flights to the CS component when flights enter or leave the TWR system (see Figure 28).

Development Note: The CS CoordinationMonitorService will be enhanced to provide the facility to indicate the availability of the service.

Figure 28: TCS Monitoring ATC CS Handovers

The CoordinationMonitorService will notify TCS of any relevant coordination events.

When the handover is from the airport’s neighbouring approach controller to the airport ATC unit, the CS coordination is transferred to the TCS for jurisdiction. The TCS transit lists will be updated and the TCS clients informed using a JurisdictionMessage.


14 Aug 2007

of 76

When the handover is from the airport’s neighbouring approach controller to another ATC controller, then the TCS transit lists will be updated and the TCS clients informed using a JurisdictionMessage.

When the handover event state indicates “not concerened” then the Jurisdiction will be marked for termination. The TCS transit lists will then be updated and the TCS clients informed using a JurisdictionMessage.

When the handover event state indicates “inbound” then the Jurisdiction will be marked active. The TCS transit lists will then be updated and the TCS clients informed using a JurisdictionMessage.

When the handover event state indicates “releasable”, the TCSController will immediately transfer the flight to the next ATC unit by informing the CSController.

When TCS is notified of advance boundary information (ABI) TCS will submit the information to TFM to update any planned time estimates for landing.

Figure 29: Advance Boundary Information

When the service is not active (i.e. no eDEP System is present) then the TCS will provide the necessary jurisdiction events to initiate/terminate the handover process.

TCS is responsible for maintaining the control state of an object as it moves through different controlled operator roles at an airport. TCS maintains a state transition object to supervise the necessary control state changes for an object as it moves from one operator role to another.

Departures pass through the following roles:

• Clearance Delivery (CLD)

• Apron Controller (APR)


14 Aug 2007

of 76

• Ground Controller (GND)

• Runway Controller (RWY)

• Approach Controller (eDEP ATC APP)

Arrivals pass through the following roles:

• Approach Controller (eDEP ATC APP)

• Runway Controller (RWY)

• Ground Controller (GND)

•• Apron Controller (APR)

The following diagram shows the state transition of an object’s control state as seen by a role (Role(N)) as it assumes and transfers control to its neighbouring roles (Role(N-1), Role(N+1)).

Figure 30 Transfer of Jurisdiction

The following tables illustrate the two stage TRANSFER and ASSUME of jurisdiction for arrivals and departures.

Action Runway (RWY) Taxiway (GND) Apron (APR)

Arrivals

“Activation” Advance Not concerned Not concerned

Standalone mode and parameter mins after activation.

AdvanceTransferred Advanced Not concerned


14 Aug 2007

of 76

Or

Integrated mode and neighbour to airport sector transfers

RWY assumes Assumed Advanced Not concerned

RWY transfers AssumeTransferred AdvanceTransferred Advance

GND assumes Concerned Assumed Advance

GND transfers Not concerned AssumeTransferred AdvanceTransferred

APR assumes Not concerned Concerned Assumed

Aircraft parks at gate Not concerned Not concerned Concerned

Departures

“Activation” Not concerned Advance AdvanceTransferred

APR assumes Not concerned Advance Assumed

APR taxi/pushback Not concerned Advance Assumed

APR transfers Advanced AdvanceTransferred AssumeTransferred

GND assumes Advanced Assumed Concerned

GND transfers AdvanceTransferred AssumeTransferred Not concerned

RWY assumes Assumed Concerned Not concerned

RWY Lineup Assumed Not concerned Not concerned

TakeOff Assumed Not concerned Not concerned

RWY transfer AssumeTransferred Not concerned Not concerned

Standalone mode and parameter mins after takeoff.

Or

Integrated mode and neighbour to airport sector assumes

Concerned Not concerned Not concerned

Parameter mins after assume.

Not concerned Not concerned Not concerned

When in standalone mode (i.e. no eDEP ATC system) “Activation” of arrivals and departures are triggered by the notification of the InitialFlightPlanEvent.

When in integrated mode the RWY controller is responsible for the Airport sector and the advance notification of entering the Airport sector triggers “Activation” for arrivals. Departures are still triggered by the InitialFlightPlanEvent.

The above situations can also arise when a controller is working with combined roles. The following two examples, the first with a combined role of GND+APR, the second with a


14 Aug 2007

of 76

combined role of RWY+GND+APR, illustrate the state changes as seen by these controller roles for an arrival. Departures and service vehicles follow a similar strategy.

Action RWY GND+APR

Arrivals

“Activation” AdvanceTransferred Advance

RWY assumes Assumed Advance

RWY transfers AssumeTransferred AdvanceTransferred

GND+APR assumes Concerned Assumed

Aircraft parks at gate Not concerned Concerned

Action RWY+GND+APR

Arrivals

“Activation” AdvanceTransferred

RWY+GND+APR assumes Assumed

Aircraft parks at gate Concerned

3.9.2 Entities The TCS maintains a database of coordinated objects, which provide an interface for not only coordinated flights but also service vehicles. This is illustrated in the following diagram, which shows the components entities and services.


14 Aug 2007

of 76

Figure 31: TCS Component and Entities

3.9.2.1 CoordinatedVehicle

The CoordinatedVehicle entity defines an interface to the methods provided by a tower coordinated vehicle implementation object, managed within the TCS database. This object provides methods to support the following key areas of functionality:

• Controller role assignment.

• Handover of jurisdiction.

3.9.2.2 CoordinatedFlight

The CoordinatedFlight entity extends the CoordinatedVehicle entity and defines an interface to the methods provided by a tower coordinated flight implementation object, managed within the TCS database. This object inherits the CoordinatedVehicle methods but supervises a slightly different state model for the coordination of flights

3.9.3 Parsers The TCS does not employ any parsers.

3.9.4 Clients When an object’s jurisdiction state changes the TCS notifies clients who have registered interest in the TCSService for JurisdictionEvents.

3.9.5 Events The JurisdictionEvent provides details of the current state of the transaction and the associated roles. The event is raised in response to the server side generated JurisdictionMessage. The event specifies the callsign of the monitored object, the current coordination state and the operator roles involved.

3.10 MANNED TOWER CWP (TCWP)

3.10.1 Server The TCWP component manages an arbitrary collection of graphics windows, centred around a large window showing the geographical plan of an airport known as an Airport View Display (AVD).

The screen and graphical interface management follow the Plan View Display guidelines identified in the eDEP CWP component design documentation.

This display shows traffic (aircraft and service vehicles) moving around the taxiways and runways at an airport, driven from track updates from the TIAS. It also shows the current tower flight plan information and jurisdiction status for aircraft and vehicles in the system.

The AVD is supplemented with the Arrival and Departure lists showing origin and destinations, predicted arrival and departure times.

The TCWP comprises an application made from a scenario object defining traffic at the airport, the TCWP’s role, taxiways and runways.

The TCWP component also defines a TCSController that provides the initialisation and run-time control of distributed components. At initialisation TCWP loads map and airport data from the TASP and registers interest in the:

• Time Service.


14 Aug 2007

of 76

• TASP service for stop bar status updates.

• TPM for ProgressUpdateEvents

• TFPM for ProgressUpdateEvents

• TIAS for regular position updates.

• TCS for jurisdiction data.

• TFM for Initial Tower flight plan information

• TSN for incursion alerts

• DNS for replies to taxi route navigation queries.

The TCWP component also privides an implemention which extends a CWP Controller to supplement the airport view with a companion ATC view of traffic if required.

The TCWP can be configured as a Ground (controller) working position, an Air (pilot) working position or a Hybrid combined air and ground working position.

In the example below the java class of the airport view display of three controllers has been defined. The first is a Ground controller, the second an Air controller and the last a Hybrid (Combined Air and Ground) controller. This pluggable method of defining the controller allows other variants of controllers to be defined and employed.

RWY_N_GRD.AVD.CLASS twr.dsigraphics.avd.GroundAVD

RWY_N_AIR.AVD.CLASS twr.dsigraphics.avd.AirAVD

TCWP_TWY_N.AVD.CLASS twr.dsigraphics.avd.HybridAVD

3.10.1.1 Ground TCWP

When configured as a Ground TCWP the position will affect the planned movement of aircraft and vehicles.

The TCWP can be designated as a Clearance Delivery (CLD), Apron (APR), Taxiway (GND) or Runway (RWY) controller; or a combination there of. The designations are used to configure how information is displayed in the Arrival and Departure lists and governs when the TCWP should assume and transfer jurisdiction of traffic to another TCWP role.

The TCWP also permits user interaction to allow controller orders to be submitted to the TPM to modify aircraft taxi routes, to give clearance and to control the motion of traffic.

The TCWP can also change the state of airport stop bars to “stop” or “go” by submitting a stop bar order to TASP.

The airport roles that a TCWP performs, depends on the ground sectors that have been assigned to the TCWP ground unit.

In the example below TCWP_RWY_N has been assigned the ground unit RWY_N. This ground unit comprises one ground sector LFPG_RWY_N which is defined to be of a RUNWAY control kind. Thus TCWP_RWY_N is performing a runway role at the airport.

TCWP_RWY_N.GROUND_UNIT RWY_N GROUND_UNIT RWY_N COMPRISING GROUND_SECTOR LFPG_RWY_N END GROUND_SECTOR LFPG_RWY_N REGION 49.029 2.575


14 Aug 2007

of 76

49.0235 2.575 49.0195 2.510 49.025 2.510 END FOR_AIRPORT LFPG CONTROL_KIND RUNWAY FREQUENCY 119.25 END

The roles performed by TCWP_RWY_N could have been extended by defining the ground unit to be comprised of more than one ground sector.

3.10.1.2 Air TCWP

When configured as an Air TCWP the position will affect the actual movement of aircraft and vehicles. Every Air TCWP is paired to a Ground Controller in a one to one relationship giving the Air TCWP the responsibility to drive the aircraft under jurisdication of the Ground TCWP. Thus as one Ground TCWP passes jurisdiction to a second Ground TCWP then so does the responsibility of driving the aircraft pass onto a second Air TCWP. The responsibility will not be enforeced but implied by the label colouring of tracks.

Information will be displayed to allow the position to govern the movement of aircraft and vehicles round the airport.

An Air TCWP also permits user interaction to allow controller orders to be submitted to the TPM to modify aircraft taxi route and the motion of an aircraft.

3.10.1.3 Hybrid TCWP

When configured a Hybrid TCWP the position will affect the planned and actual movement of aircraft and vehicle.

Information will be displayed to allow the position not only to govern the movement of aircraft and vehicles round the airport but also the control of jurisdication.

The combined Ground and Air Hybrid TCWP permits both sets of controller orders and airspace stop bar orders.

3.10.2 Entities The TCWP maintains a database of

• Tower traffic objects describing flights and service vehicles

• ATC traffic objects describing airborne flights.

This is illustrated in the following diagram, which shows the components entities and services.


14 Aug 2007

of 76

Figure 32: TCWP Component and Entities

3.10.2.1 Traffic

The Traffic entity extends the Flight and Vehicle entities.

3.10.3 Parsers The TCWP does not employ any parsers.

3.10.4 Clients TCWP provides a pure client component on the eDEP platform and therefore has no clients of its own.

3.10.5 Events TCWP does not raise any events.

3.11 UNMANNED TOWER CWP (UTCWP)

3.11.1 Server The UTCWP automatically controls vehicles in the Tower system. UTCWP offers no HMI.

The UTCWP will initialise by subscribing to

• Time Service

• TASP airspace service

• TIAS service for track position updates.

• TFM service.

• TFPM progress messages.


14 Aug 2007

of 76

• TPM for ProgressUpdateMessages

• TCS for jurisdiction data

UTCWP responds automatically to jurisdiction events such that any transfers to the UTCWP role are automatically assumed after a parameterised Resource time (TCWP.DURATION_BEFORE_ASSUME)

UTCWP responds automatically to progress events using the following parameterised Resource times:

• TakeOffEvent – No response required.

• TouchDownEvent – If runway controller, issue clear to taxi to gate. (TCWP.DURATION_BEFORE_TAXI)

• PushBackStartEvent – If apron controller issue clear for pushback. (TCWP.DURATION_BEFORE_PUSHBACK)

• PushBackCompleted Event – If apron controller issue clear to taxi to runway. (TCWP.DURATION_BEFORE_TAXI)

• StartTaxiEvent – No response required.

• GroundSectorExitEvent – Transfer between roles. (TCWP.DURATION_BEFORE_TRANSFER)

• GroundSectorEntryEvent – Transfer between roles. (TCWP.DURATION_BEFORE_TRANSFER)

• TaxipointPassedEvent – If taxiway controller and Taxipoint part of runway then transfer to runway role. (TCWP.DURATION_BEFORE_TRANSFER)

• LineUpStartEvent – If runway controller issue clear to line up on runway. (TCWP.DURATION_BEFORE_LINEUP)

• LineUpCompletedEvent – If runway controller, issue clear to take off. (TCWP.DURATION_BEFORE_TAKEOFF)

• RunwayExitEvent – If runway controller, transfer to taxiway role. (TCWP.DURATION_BEFORE_TRANSFER)

• ParkedAtGateEvent – No response required.

• TurnaroundEvent – No response required.

• TerminatedEvent – No response required.

• GateOccupiedEvent – No response required.

• GateVacatedEvent – No response required.

3.11.2 Entities No entities are defined.

3.11.3 Parsers The UTCWP does not employ any parsers.

3.11.4 Clients UTCWP provides a pure client component on the eDEP platform and therefore has no clients of its own.


14 Aug 2007

of 76

3.11.5 Events UTCWP does not raise any events.

3.12 TOWER PILOT WORKING POSITION (TPWP)

3.12.1 Server The TPWP component manages an arbitrary collection of graphics windows, centred around a large window showing the geographical plan of an airport known as an Airport View Display (AVD).

The screen and graphical interface management are similar to the TCWP.

This display shows traffic (aircraft and service vehicles) moving around the taxiways and runways at an airport, driven from progress updates from TPM.

The AVD is supplemented with the arrival, departure and vehicle traffic lists showing origin and destinations, predicted arrival and departure times.

From an AVD the TPWP will be able to submit orders to the TPM to modify taxi routes and the motion of traffic.

The following TPWP pilot orders are supported

•••• Pushback.

•••• Stop.

•••• Taxi.

•••• Change-route

o From runway exit point to gate for an arrival.

o From gate to runway entry point for departure.

o To an intermediate point for aircraft and vehicles.

•••• Change-gate.

•••• Change-runway.

•••• Change-SID.

•••• Delete flight.

•••• Line-up.

•••• Take-off.

•••• Transfer to frequency.

•••• Conditional line-up

•••• Conditional takeoff

•••• TaxiSpeed

The TPWP comprises an application made from a scenario object defining piloted traffic at the airport.

The TWP component also defines a TPWPController that provides the initialisation and run-time control of distributed components. At initialisation TPWP loads map and airport data from the TASP and registers interest in the:

• Time Service.

• TASP service for stop bar update status.


14 Aug 2007

of 76

• TPM for ProgressUpdateEvents.

• TPM for PilotedNavigationEvents.

• TPM for TransferFrequencyEvents.

• TPM for ConditionalOrderEvents.

• TPM for StopAheadEvents.

• TPM for FrequencyTransferEvents.

• TPM for TPWPFrequenciesEvents.

• DNS for replies to taxi route navigation queries.

Allocation of frequencies to TPWP and definition of default TPWP to handle undefined frequency channels are via resource e.g.

TPWP_LFPG_N.FREQUENCIES (119.25, 120.5) TPWP.DEFAULT TPWP_LFPG_N

Valid frequencies for FrequencyTransfer (frequency) orders are determined from the airport ground sectors and the ATC sectors defined for the scenario.

Valid TPWPs for FrequencyTransfer (TPWP and frequency) orders are determined from the TPM distributed TPWP Frequencies table.

A TPWP can transfer airborne arrivals or departures to any tower or ATC frequency. Arrivals and departures on the ground, and vehicles, can only be transferred to tower frequencies.

3.12.2 Entities The TPWP maintains a database of PilotedTraffic objects describing flights and service vehicles. This is illustrated in the following diagram, which shows the components entities and services.


14 Aug 2007

of 76

Figure 33: TPWP Component and Entities

3.12.2.1 PilotedTraffic

The PilotedTraffic entity extends the PilotedFlight (and PilotedVehicle) entity.

3.12.3 Parsers The TPWP does not employ any parsers.

3.12.4 Clients TPWP provides a pure client component on the eDEP platform and therefore has no clients of its own.

3.12.5 Events TPWP will not raise any events.

3.13 TOWER SAFETY NETWORK (TSN)

3.13.1 Server The Tower component, TSN (Tower Safety Network), defines a TSNController that provides the initialisation and run-time control of distributed components. TSN starts its initialisation by fetching airport data from TASP, in particular the exclusion areas. It then registers interest in:

• Time Service • Meteo Service • PositionUpdateEvents from TIAS. • AtcPositionUpdateEvents from TIAS


14 Aug 2007

of 76

The TSN component detects illegal aircraft/vehicle (mobile) intrusion into protected areas defined at airports. The legality of the intrusion will depend on the exclusion area and its associated runway i.e. whether the runway is closed or if other aircraft or vehicles are obstructing the runway. The full set of rules can be found in Ref 1.

The detection algorithm only uses information from the latest IAS (AtcPositionUpdateEvents) and TIAS (PositionUpdateEvents) track state vector information. As IAS and TIAS updates are likely to be at different rates the track position will be interpolated based on the current time and the last reported time for the track. Issued lineup and takeoff clearances are recognised and used in the detection algorithm if the exclusion area definition dictates.

The detection algorithm is not performed immediately on receipt of track updates but at a small delay afterwards. This allows the processing load to be spread over time. Also the Track Service classes will be instantiated with canCoalesce set to true. Thus in periods of overloading (e.g fast forward), old updates will be overwritten by new ones allowing the algorithm to process the most up-to-date information.

The detection algorithm checks each track against the state of the exclusion area and against other tracks in the proximity of the exclusion area. The track’s position and velocity will be used to estimate time to threshold and separation distances.

Any intrusions detected are reported to clients, in particular TCWP which presents the intrusions as alerts on the airport view displays.

The Tower Safety Network algorithm will be designed to be a pluggable object, allowing a substituted algorithm to be used if required.

TSN will maintain a set of current incursions. An incursion will record the offending mobile, the severity of the incursion, the exclusion area and when present the other party in the incursion.

3.13.1.1 TIAS PositionUpdateEvents

On receipt of a set of TIAS PositionUpdateEvents, TSN will check each non-airborne TIAS track against the set of exclusion areas. The TIAS track will be considered in the area if its track position is within the defined exclusion area. When the track lists have been updated TSN will check for incursions.

3.13.1.2 TIAS AtcPositionUpdateEvents

Similarly for TIAS AtcPositionUpdateEvents, TSN will check each ATC track against the set of exclusion areas. The ATC track will be considered if its ETA is within the long final time threshold. When the track lists have been updated TSN will check for incursions.

3.13.1.3 Clearances

On receipt of a lineup or takeoff clearance message from TFM, TSN will check for incursions using the current set track information.

3.13.1.4 Incursion Checks

When checking for incursions, TSN will check each exclusion area in turn taking position and current clearance situation into account.

After checking for incursions TSN will report to clients any new incursions, any deleted incursions and any updated incursions.

3.13.2 Entities The TSN maintains a database of Mobile objects, which provide an interface to record not only TIAS track information for vehicles and ground aircraft but also for IAS track


14 Aug 2007

of 76

information for airborne flights. This is illustrated in the following diagram, which shows the components entities and services.

Figure 34: TSN Component and Entities

3.13.2.1 Vehicle

The Mobile entity defines an interface to the methods provided by a tower flight implementation object, managed within the TSN database. This object provides methods to support the following key areas of functionality:

• Distinguish between vehicles, ground flights and airborne flights.

• Support ETA calculations for airborne flights.

• Extend Flight information to access navigation details.

3.13.3 Parsers TSN does not employ any parsers.

3.13.4 Clients When incursions are detected TSN will notify any clients who have registered interest in the TSNService IncursionAlerts.

3.13.5 Events The TSN raises events for clients in the TSN Service, after the service has processed the corresponding TSN server generated message:

• IncursionAlertCreationEvent. The server side generated IncursionAlertMessage is processed and any new alerts are signalled.

• UpdatedAlertsEvent: The server side generated IncursionAlertMessage is processed and any alerts that have changed state are signalled.


14 Aug 2007

of 76

• IncursionAlertDestructionEvent. The server side generated IncursionAlertMessage is processed and destroyed alerts are signalled.

3.14 DEPARTURE MANAGER (DMAN)

3.14.1 Server The Departure Manager (DMAN) provides a pure client component within eDEP.

DMAN comprises an application made from a scenario object defining flights at the airport.

DMAN also establishes a PVM (Parallel Virtual Machine, see Ref 10) interface to an “external algorithm” e.g. the DLR (Deutches Zentrum für Luft- und Raumfahrt) departure manager prototype (See Ref 9). Note the DLR-DMAN prototype has been developed using complex mathematical functions provided by the MATLAB software package.

The DMAN component supervises the distribution of flight information to the “external algorithm” (via PVM) for arrivals and departures at an airport.

The DMAN component also defines a DMANController that provides the initialisation and run-time control of distributed components. At initialisation DMAN will establish the PVM interface and will then register interest in the:

• Time Service.

• TASP service, loading map and airport data.

• TFM for Initial Tower Flight Plan and Navigation information

• TCS for jurisdiction data.

• TFPM for Progress Update messages.

• TIAS for regular position updates.

Figure 35 : DMAN Subscriptions and PVM Connection

The initial flight information will be sourced from the TFM Initial Tower Flight Plan and define departure CTOT, gate, runway and SID; arrival STAR, runway and gate.

Subsequent changes to the flight information e.g gate, runway; identified within TFM Navigation messages, are also distributed to the “external algorithm”.


14 Aug 2007

of 76

Changes in the Navigation message will also identify any new clearances given by controllers. These clearances will include enroute (new), start-up (new), pushback, taxi, hold, continue (i.e. subsequent taxi clearances), line-up and take-off.

As controllers Handover control of flights from one position to another, DMAN receives jurisdiction information from TCS. The jurisdiction information will detail the type of Handover control (Assume/Transfer) and the controlling positions taking part in the Handover.

The TFM Initial Tower Flight Plan will indicate the start of interest for a flight.

For departures the TFPM Progress Update message, TakeOffMessage will identify the end of interest.

For arrivals the start of interest will be qualified by the TFPM Progress Update message TouchDownMessage, while the ParkedAtGateMessage will identify the end of interest.

DMAN keeps the “external algorithm” informed of the current position of the flights. The positional information is sourced from the regular TIAS updates.

The DMAN component connects to the “external algorithm” through an object implementing the DMAN Connector interface. The PVM Connector class provides the wrapper methods for the required PVM functions to join a PVM group and to send and receive messages. The DMAN flight entity raises the corresponding change events to notify the DMAN Connector of the changes.

Figure 36 : DMANFlight Entity Change

The DMAN component also supervises the receipt of managed off block times, managed take-off times and recommended clearance times from the “external algorithm” (via PVM) for departures at an airport. On receipt, DMAN submits the recommendations and managed times to TFM.

The class PvmReceiver provides the functionality to receive and process messages from the PVM middleware. The PvmReceiver class runs as a separate Java Thread, implementing the Runnable interface.

An event local to the DMANController, the PVM event, encapsulates the message received asynchronously from PVM. The DMAN Controller registers interest in this event after the PvmReceiver has been created within the DMAN component initialisation.


14 Aug 2007

of 76

3.14.2 Entities DMAN maintains a database of DMANFlightImpl objects describing flights. This entity has an associated interface DMANFlight, which extends the existing TFM Flight interface. This is illustrated in the following diagram.

Figure 37 : DMAN Component and Entities

3.14.3 Parsers DMAN does not employ any parsers.

3.14.4 Clients DMAN provides a pure client component on the eDEP platform and therefore has no clients of its own but communicates with the DMAN algorithm through PVM.

3.14.5 Events DMAN does not raise any events for other Tower components

3.14.6 PVM Connectivity The DMAN server connects to the DMAN algorithm using PVM to forward the set of messages defined in the DMAN Gateway Specification document Ref 9, encoded into PVM message packets. The PVM API is described in the PVM website, Ref 10.

The connection to PVM is made through the Java Native Interface, JNI. The JNI Connector class provides the required methods, providing wrappers into the PVM C++ library. PVM based applications are linked with the PVM library, the latest version being libpvm3. This provides the facilities required by the application to enable communication with other applications in the PVM system. The DMAN Component uses the base PVM library


14 Aug 2007

of 76

(libpvm3.a) and the group functions library (libgpvm3.a) to support communication between groups of applications at the same time.

3.14.6.1 Starting PVM

After a PVM application has been written, it must be started within the PVM environment. This is achieved by running a PVM shell process. This provides PVM commands to start, control and stop the running processes on the PVM network. When a PVM shell is started, it will automatically start a PVM demon process, if one is not already running. Remote machines can be added to the PVM network using the ‘add <hostname>’ command.

3.14.6.2 Interfacing Using Shared Libraries

The DMAN component accesses PVM from Java through the use of a shared library to make the required calls into the PVM kernel software. Under the Linux operating system, simply using the following steps to compile and link a source file may create a shared library:

• Compile C/C++ source code using the GNU compiler with the compile only flag (-c), and the position independent code flag (-fPIC) set.

• Link the object file using the –shared option and designating the output library file with the argument –o libdman.so.

Under windows, the software is compiled using a suitable windows C++ compiler, such as Borland C++ or Microsoft Visual Studio. Note that attempts to use the Cygwin/GNU environment to convert a shared library into a DLL using the Cygwin dlltool have not been successful.

Under Borland C++ or MS Visual C++, use the DLL Wizard to create a DLL project, and create a C++ module, setting the Multi-Threaded and Visual C++ style options. Create the required PVM Connector wrapper functions, pvm.c, declaring the methods with the following signature:

• JNIEXPORT void JNICALL Java_Dman_xxxx( JNIEnv *, jc lass, ...) {...}

The created DLL must be loaded into the Java VM, using a call to the Java system method System.loadLibrary(“library”) . The name of the library is just the root name of the DLL file, without any path or extension. The library path must be set using a Java VM parameter, introduced with the –D option:

• Java –Djava.library.path=c:/dman/dll…

The name of the DMAN PVM connector library for the JNI interface is provided through a resource value, DMAN.PVM_LIBRARY. This enables the platform to be configured to load the appropriate library under Linux or Windows.

3.14.6.3 PVM Connector Class

The PVM connector class provides the wrapper methods for the required PVM functions to create new processes, join a PVM group and to send and receive messages. The JNI interface to the PVM middleware provides the following method calls:

• openConnection(); - maps to pvm_mytid • joinGroup( String group ); - maps to pvm_joingroup • isMessageAvailable( int task, int tag ); - maps to pvm_probe • receiveMessage( int task, int tag ); - maps to pvm_nrecv • getMessageString( int messageId ) - maps to pvm_upkstr • getMessageType( int messageId ) - maps to pvm_bufinfo • getMessageBytes( int messageId ) - maps to pvm_bufinfo


14 Aug 2007

of 76

• getMessageSource( int messageId ) - maps to pvm_bufinfo • sendMessage( String group, String message, int msgTag );

- maps to pvm_initsend, pvm_pkstr, pvm_bcast

3.14.7 PVM Synchronisation The eDEP platform delivers information asynchronously to avoid blocking the processor while waiting for responses from remote processes. In the PVM environment, messages may be sent asynchronously by making a call to pvm_bcast() , which sends the message placed in the PVM message buffer after preceding calls to pvm_initsend () and pvm_pkxxx() to clear and then pack data into the buffer. PVM provides both synchronous and asynchronous methods to receive messages from other components.

3.14.7.1 DMAN Kernel Class

The DMAN kernel class provides an abstraction of the interface to DMAN and makes calls to the PVM coordinator class that provides synchronised access to the generic PVM connector class.

3.14.7.2 Receiving Messages Via PVM

Figure 38: Receiving Messages Via PVM


14 Aug 2007

of 76

The DMAN component provides an asynchronous mechanism to receive messages from the PVM environment. The class DLRPvmReceiver implements the Java Runnable interface, and waits for messages to arrive from PVM by periodically polling the PvmConnector interface via the synchronised PvmCoordinator methods. The DLRPvmReceiver runs as an independent thread to avoid any blocking of the DMAN component. When a message is received from PVM, it is decoded into the corresponding DLRDMANCommunication object and processed by the DLRDMANKernelImpl to update entity states within the DMAN component. This in turn raises entity change events which are transmitted to the DMAN component client services.

3.14.7.3 Sending Messages Via PVM

Figure 39: Sending Messages Via PVM

Messages are sent synchronously from the eDEP DMAN component into PVM.

3.14.8 DLR-DMAN Messages The following paragraphs provide a brief summary of each of the DLR-DMAN messages to be implemented, and the source of the required information to populate the respective message parameters. The table entries identify the description of the message, the message tag


14 Aug 2007

of 76

number used in PVM, the name of the message and associated keywords defining the sub-messages e.g.

Message Description Tag No. Message Name Sub-Message

3.14.8.1 Reset Message

This message is sent by the DMAN component at initialisation time to reset DLR-DMAN.

Reset 1 RESET

3.14.8.2 Time Message

The time message is generated on each time tick update. The DMAN Controller registers interest in the time ticks from the TS component and sends the update in a time message.

Time 12 TIME

3.14.8.3 Initial Flight Plan Messages

The DMAN controller registers interest in TWR flight plans provided through the FM Navigation event. The type of flight plan (departure or arrival) determines which set of flight plan messages to be sent to DMAN.

300 Initial Departure Flight Plan Initial flight plan

301 Initial Arrival Flight Plan

3.14.8.4 Status Message

The status message is sent to activate the flight in DLR-DMAN. This message shall be sent immediately after the last element of the initial flight plan definition message has been sent.

20 UPDATE_STATUS_DEP pending Status.

21 UPDATE_STATUS_ARR pending

3.14.8.5 Change Arrival Stand

This message is generated from an arrival flight, when a navigation event changes the arrival stand in the flight plan and raises the corresponding entity change event in the DMAN flight entity. The new arrival stand is reported to DLR-DMAN in the message.

Change stand for arrivals 27 UPDATE_FD_ARR stand

3.14.8.6 Change Runway Entry

This message is generated from a departure flight, when a navigation event changes the runway entry point in the navigation script and raises the corresponding entity change event in the DMAN flight entity. The new runway entry point is reported to DLR-DMAN in the message.

Runway entry change 26 UPDATE_FD_DEP rwy_entry

3.14.8.7 Change Runway Exit

This message is generated from an arrival flight, when a navigation event changes the runway exit point in the navigation script and raises the corresponding entity change event in the DMAN flight entity. The new runway exit point is reported to DLR-DMAN in the message.

Runway exit change 27 UPDATE_FD_ARR rwy_exit


14 Aug 2007

of 76

3.14.8.8 Change Off Blocks Time

This message shall be generated from a departure flight, when a navigation event changes the off block time in the navigation script and raises the corresponding entity change event in the DMAN flight entity. Initially the flight plan defines an estimated off-blocks time, EOBT. After the update, the EOBT is left unchanged, and the plan defines a target off-blocks time, TOBT. When the aircraft actually starts to be pushed back, an actual off blocks time, AOBT, is reported by TFPM as a push back started event. The off blocks time (estimated, target or actual) is reported to DLR-DMAN in the message.

EOBT Change 26 UPDATE_FD_DEP ert

3.14.8.9 Change Estimated Arrival Time

This message is generated from an arrival flight, when a navigation event changes the estimated landing time, ELDT, in the navigation script and raises the corresponding entity change event in the DMAN flight entity. The ELDT shall be updated initially through an ABI SYSCO message from GRD CS server, reported to TCS, and generating a Change ETA order for TFM, which recalculates the DNS and pending clearance events, and subsequently generates a navigation event. The updated landing time is reported to DLR-DMAN in the message.

Estimated Arrival Time 27 UPDATE_FD_ARR eta

3.14.8.10 Remove Flight Plan

An arrival flight shall be removed from the DLR-DMAN when the TIAS component deletes its track, after it has parked at a gate. A departure flight shall be removed from DMAN when the TFPM component notifies a take-off message. In both cases, the message shall identify the callsign of the flight to be removed.

40 REMOVE_DEP Delete

41 REMOVE_ARR

3.14.8.11 Flight Clearances

The TFM generates clearance messages each time a flight is cleared to perform an airport manoeuvre.

28 UPDATE_CLCS_DEP enr, su, su+pb, pb, tx, lu, lu+to, to, hold, cont.

Clearances

29 UPDATE_CLCS_ARR ldg, tx, hold, cont, onb.

3.14.8.12 Flight Handover Messages

Handover messages are produced by the TCS component when a controller hands over control of a flight to the next airport controller. For arrivals the sequence is typically RUNWAY-TAXI-APRON and for departures APRON-TAXI-RUNWAY. The DMAN component subscribes to TCS handover messages and generates the corresponding message for DLR-DMAN.

24 UPDATE_OP_ST_DEP transfer_control Handover

25 UPDATE_OP_ST_ARR transfer_control


14 Aug 2007

of 76

3.14.8.13 Departure Runway Change

This message is generated from a departure flight, when a navigation event indicates the runway has changed and raises the corresponding entity change event in the DMAN flight entity. The new runway is reported to DLR-DMAN in the message.

Runway change 34 RWY_CHANGE_DEP rwy, sid, rwy_entry, rwy_index

3.14.8.14 Aircraft Progress Updates

The TWR surveillance server, TIAS, generates aircraft position updates. The DMAN component converts the Cartesian coordinates of the position update to spherical Latitude and Longitude, using the local scenario Projector object. The coordinates are reported to DLR-DMAN.

Topo Basic 42 TOPOLOGICAL_XY_DEP pos_x, pos_y

3.15 TAAM AIRPORT CONVERTER

3.15.1 Description 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.15.2 Server The TAAM Airport Converter runs as a stand-alone utility and is therefore not part of the Tower server-client configuration.

3.15.3 Entities No entities are defined.

3.15.4 Parsers The TAAM Airport Converter does not employ any parsers.

3.15.5 Clients The TAAM Airport Converter runs as a stand-alone utility and is therefore not part of the Tower server-client configuration. Although the resulting eDEP format map and airport files are used by the TASP component to construct its entities.

3.15.6 Events The TAAM Airport converter does not raise any events.


14 Aug 2007

of 76

3.16 TAAM TRAFFIC CONVERTER

3.16.1 Description When the TAAM Traffic Excel file has been saved as a comma separated variable (csv) file the TAAM Traffic converter is able to read the csv file, process the data and format the information into three files ready for use by eDEP and the Tower system.

The first file 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 TAAM Traffic information contains the actual off block time (AOBT) for departures and actual time of arrival (ATA) for arrivals. The Converter uses these times to determine the activation time required by eDEP.

For departures the activation time is always taken as the AOBT.

For arrivals three options are available Standalone, Truncate or Connected. 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.

3.16.2 Server When calculating the activation times for arrivals in Truncated and Connected mode the Converter runs as an extended version of TIFPL to utilise the Trajectory Service to predict trajectories.

3.16.3 Entities For Truncated and Connected mode the Converter maintains a database of Flight objects, which provide an interface to utilise Flight Identities in the trajectory predictionThis is illustrated in the following diagram, which shows the components entities and services.


14 Aug 2007

of 76

Figure 40: TAAM Traffic Components and Entities

3.16.4 Parsers The TAAM Traffic Converter does not employ any parsers.

3.16.5 Clients The TAAM Traffic Converter has no clients.

3.16.6 Events The TAAM Airport Converter does not raise any events.

edep development project edep twr system … · development and evaluation platform reference...

Documents