Development and Evaluation Platform Software Requirements ... · Development and Evaluation...

Development and Evaluation Platform Reference GL/eDEP/TWR/SRD/1/15.0

14 Aug 2007

Page 1 of 69

Development and Evaluation Platform

Software Requirements Document

eDEP Tower Software Requirements

Issue: 15.0

Author: Ken Eveleigh

Date: 14 Aug 2007

Company: Graffica Ltd


14 Aug 2007

Page 2 of 69

Document Change Log Release Author Date of the

release Description of the release Modifications (sections affected

and relevant information) 0.1 Ken Eveleigh 6 Jan 2004 Initial draft 0.2 Ken Eveleigh 6 Feb 2004 Modifications after 02/02/04

meeting at EEC All sections affected. Some renaming. New section for TIAS.

1.0 Ken Eveleigh 25 Feb 2004 Modifications after Graffica review.

Overview diagram split and some rewording to sequence diagrams

2.0 Ken Eveleigh 5 Mar 2004 Modifications after EEC review

Throughout document

3.0 Ken Eveleigh 1 July 2004 Iteration 1 delivery Minor changes throughout Added G101. Traffic Rules section added. Arrivals and Departures section added.

4.0 Ken Eveleigh 10 Dec 2004 Iteration2 delivery Updates to MMI specifications. Plus other minor changes.

5.0 Ken Eveleigh 7 Jan 2005 Post Iteration2 delivery Response to EEC comments.

6.0 Ken Eveleigh 6 Jun 2005 Tower05 Activation 1 tasks 1.4 Overview of Document 3.13 TSN Tower Safety Network 3.11 TCWP Tower Working Position 3.14 Data Preparation 5 Graphical Requirements

7.0 Ken Eveleigh 1 Jul 2005 Modifications after 27/06/05 meeting at EEC

3.13 TSN. 3.14 Data Preparation. 5 Graphical Requirements.

8.0 Ken Eveleigh 14 Feb 2006 Modifications for Tower 2005 APT tasks.

3.1 Architecture 3.11 TCWP 5 Graphical Representation

9.0 Ken Eveleigh 19 Apr 2006 Modifications for DMAN 2006 tasks.

3.1 Architecture 3.14 DMAN (new section) 5.1.1.2 Clearance Delivery Window

10.0 Ken Eveleigh 2 May 2006 EEC review comments DMAN 110 requirement reworded. 3.14.5 "should" and not "shall". 3.14.5 Stated not implemented.

11.0 Ken Eveleigh 13 Nov 2006 Tower Pilot Position 3.11 Removed AirTCWP subsection 3.13 Added TPWP section.

12.0 Paul Fletcher 22 Mar 2007 3.8.3, 6.6, and 8.4 Sections updated for new runway deceleration and fast exit requirements.

13.0 Ken Eveleigh 3 Apr 2007 EDEP Release 2007 Q1 G160 Activation delta time. 3.8 TPM orders (WP5.3d) 3.13 TPWP orders (WP5.3d) Reference external departure manager algorithm. CTOT from ATC flight plan

14.0 Tim Cooper 7 June 2007 TPWP frequency update 3.13 Added TPWP requirement. Tim Cooper 20 July 2007 Updated with WPE5.3

requirements. Throughout

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


14 Aug 2007

Page 3 of 69

Document distribution

to/cc Name Role


14 Aug 2007

Page 4 of 69

Table Of Contents

1 Introduction.....................................................................................................................................8

1.1 Purpose of the Tower Simulator .............................................................................................8

1.2 Scope.......................................................................................................................................8

1.2.1 Scope of Component.......................................................................................................8

1.2.2 Scope of Software Requirement Document....................................................................8

1.3 Definitions...............................................................................................................................8

1.4 Overview of Document...........................................................................................................8

2 General Description ......................................................................................................................10

2.1 Tower Simulator ...................................................................................................................10

2.2 Summary of Component Functions ......................................................................................10

2.3 Assumptions and Dependencies............................................................................................10

3 Specific Tower Requirements.......................................................................................................12

3.1 Architecture Requirements ...................................................................................................12

3.2 TACR (Tower Aircraft Type Data) ......................................................................................14

3.3 TASP (Tower Airspace)........................................................................................................14

3.4 TIFPL (Tower Initial Flight Plans) .......................................................................................17

3.5 DNS (Detailed Navigation Scripts).......................................................................................18

3.5.1 Data Definition..............................................................................................................18

3.5.2 Detailed Navigation Scripts ..........................................................................................19

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

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

3.8 TPM (Tower Pilot Manager).................................................................................................21

3.8.1 Basic Airport Navigation ..............................................................................................21

3.8.2 Apron Navigation..........................................................................................................23

3.8.3 Runway Navigation.......................................................................................................25

3.9 TIAS (Tower Integrated Airspace Surveillance) ..................................................................27

3.10 TCS (Tower Coordination Server)........................................................................................27

3.11 TCWP (Tower Controller Working Position).......................................................................28

3.11.1 Ground Controller Position...........................................................................................28

3.11.2 Hybrid Position .............................................................................................................28

3.11.3 Navigation Orders.........................................................................................................28

3.11.4 Airport situation view ...................................................................................................29

3.11.5 APP Radar View Display..............................................................................................30

3.11.6 Ground Radar Simulation .............................................................................................30


14 Aug 2007

Page 5 of 69

3.11.7 Operator Roles ..............................................................................................................30

3.11.8 Traffic Lists (Electronic Flight Strips)..........................................................................33

3.12 uTCWP (Demo mode) ..........................................................................................................34

3.13 TPWP (Tower Pilot Working Position) ................................................................................34

3.13.1 Ground Controller Position...........................................................................................34

3.13.2 Graphical Requirement .................................................................................................36

3.14 TSN (Tower Safety Network)...............................................................................................37

3.14.1 Closed Exclusion Area..................................................................................................38

3.14.2 Open Exclusion Area ....................................................................................................39

3.15 DMAN (Departure Manager)................................................................................................41

3.15.1 External Departure Manager Algorithm .......................................................................41

3.15.2 Airspace ........................................................................................................................42

3.15.3 Message Summary ........................................................................................................42

3.15.4 Departure Management.................................................................................................43

3.15.5 Multi Platform Requirements........................................................................................47

3.16 Data Preparation [optional]...................................................................................................47

4 Tower and eDEP ATC Interface Requirements............................................................................49

4.1 Interface Requirements .........................................................................................................49

4.2 Approach Enroute Enhancements.........................................................................................49

4.3 Approach Enroute Considerations ........................................................................................50

5 Graphical Requirements................................................................................................................52

5.1 Views ....................................................................................................................................52

5.1.1 Airport Views................................................................................................................52

5.1.2 Approach Radar Views .................................................................................................55

5.2 Menus....................................................................................................................................55

5.2.1 Callsign .........................................................................................................................55

5.2.2 Runway .........................................................................................................................56

5.2.3 Stand .............................................................................................................................57

6 Arrival and Departues ...................................................................................................................58

6.1 Runway Perimeter.................................................................................................................58

6.2 Aircraft and Taxiway Segment Speeds.................................................................................59

6.3 Gate to Runway Departures ..................................................................................................59

6.4 Gate to Runway Via Intermediate Points..............................................................................60

6.5 Runway to Gate Arrivals.......................................................................................................61

6.6 Runway To Gate Via Intermediate Points ............................................................................61

7 Traffic Rules .................................................................................................................................63

7.1 Terminology..........................................................................................................................63


14 Aug 2007

Page 6 of 69

7.2 Traffic Parameters.................................................................................................................63

7.3 On-Coming Traffic More than One Junction Away .............................................................65

7.4 Traffic Approaching Same Junction But Leaving On Different Paths .................................65

7.5 Traffic Approaching The Same Junction Leaving On Same Path ........................................66

7.6 Fast and Slow Traffic Leaving On Different Paths...............................................................67

8 DNS Route Finding.......................................................................................................................68

8.1 Introduction...........................................................................................................................68

8.2 Input/Output Specification....................................................................................................68

8.3 Route Finding Criteria ..........................................................................................................68

8.4 Speed Calculation .................................................................................................................68

8.5 Runway Entry/Exit Point ......................................................................................................68


14 Aug 2007

Page 7 of 69

References

1. eDEP Technical Document TRS eDEP Core 2004 (Ref TRSB128/2003)

2. eDEP Tower Simulator and ACE Integration Technical Proposal (Ref STA/R/011/415/1)

3. DSI HMI Specification (V1.1 Dec1999)

4. Operational Concept and Requirements for A-SMGS Implementation Level II (http://www.eurocontrol.int/airports/projects/asmgcs/index.html)

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

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

7. EVP eDEP/DMAN Technical Annex to A14PT/2005, dated 12 August 2005.


14 Aug 2007

Page 8 of 69

1 INTRODUCTION

1.1 PURPOSE OF THE TOWER SIMULATOR

The Tower Simulator (TWR) defines the eDEP subsystem TWR that simulates the ground movement activity at an airport. It models ground movements including aircraft landing, aircraft taxi to gate, gate pushback, taxi to runway and take-off.

1.2 SCOPE

1.2.1 Scope of Component While the TWR subsystem will draw on the existing eDEP implementation, it will comprise a distinct set of component servers and services. This will allow it to be clearly distinguished from its eDEP ATC counterpart.

1.2.2 Scope of Software Requirement Document This document contains only the software requirement specifications relevant to the TWR, which have been sourced from the eDEP Technical Document TRS eDEP Core 2004 (Ref TRSB128/2003) and the eDEP Tower Simulator and ACE Integration Technical Proposal (Ref STA/R/011/415/1).

It should be emphasised that the ‘whats’ describe the requirements for the Tower Simulator and not ‘how’ those requirements are to be fulfilled.

1.3 DEFINITIONS

In order to ensure clarity and readability, the following conventions are applied in this document:

(1) ‘shall’: the word ‘shall’ is used whenever a mandatory requirement is expressed.

(2) ‘should’: the word ‘should’ is used in order to express a recommendation.

(3) ‘may’: the word ‘may’ is used to express optional requirements.

(4) ‘will’: the word ‘will’ is used to express something that will happen in the future.

(5) ‘He’: to be read as He/She

1.4 OVERVIEW OF DOCUMENT

The following sections of this document provide a general overview of the Tower Simulator, and describe in detail each of the specific requirements.

The general description consists of a brief overview of the Tower simulator highlighting its main functionality. The description also includes any assumptions and dependencies that may or will affect the development of the Tower simulator.

The section dealing with specific requirements takes each requirement in turn and describes it in detail. The original requirement extracted from the eDEP Technical Document TRS eDEP Core 2004 (Ref TRSB128/2003) will be printed in italics. Where further explanation is required it is added in normal text. Any self-imposed Graffica requirement will be printed in normal text.

Each requirement is tagged with a unique requirement number and several attributes to further clarify its description. This tag takes the following format:

<Component Name> <Number> <Priority> <Requirement Subject>


14 Aug 2007

Page 9 of 69

where:

• <Component Name> is the identifier or acronym of the component.

• <Number> is the unique requirement number allocated to the requirement. In the first version of the document, the numbers shall be in an ascending order stepping from 10 to 10 so that any future requirement could be easily added with any available number. Note that a requirement numbered 270 will cross reference to the TRS requirement number [27]. Any self-imposed Graffica requirement will follow the ascending order of 10 scheme but will be pre-fixed with G or with <year>G. Requirements prefixed with a D are source from the DMAN TRS reference 7.

• <Priority> can take three values:

• Mandatory: implying that the component will not be acceptable unless this requirement is fulfilled.

• Desirable: implying that the requirement would enhance the component but would not make it unacceptable if absent.

• Optional: implying that this requirement is not mandatory or desirable at present but may become so in the future.

• <Requirement Subject> is used to give a keyword-type description of the requirement.

Each of these tagged requirements shall be traceable in all of the resulting design documents and final acceptance and validation test documents.


14 Aug 2007

Page 10 of 69

2 GENERAL DESCRIPTION

2.1 TOWER SIMULATOR

The Tower Simulator (TWR) will define a major new eDEP subsystem that will simulate the ground movement activity at an airport. It will model ground movements including aircraft landing, aircraft taxi to gate, gate pushback, taxi to runway and take-off.

2.2 SUMMARY OF COMPONENT FUNCTIONS

The TWR will provide a configurable Tower HMI to display the static airport configuration, including the display of aprons, taxiways and runways. It will also show the real-time display of the aircraft, as they move from gate to runway and from runway to gate. A range of input and data display menus will also be provided. As the aircraft are handed to the eDEP ATC system, the aircraft will disappear from the Tower display. Similarly, when the aircraft are on final approach, and are released from the eDEP ATC system, they will appear on the TWR displays.

The TWR will provide an algorithm to calculate an aircraft’s optimum route from its position on the apron to the nominated runway, and from the runway to its parking position on the apron. This will provide uninhibited push back and taxiing time estimates. It will also provide a time-evolving simulation of ground movement, where the aircraft will adjust speed according to taxiway speed restrictions and any crossing traffic encountered.

The TWR will provide a well-defined interface to the existing eDEP platform components. Additional coordination functions will be provided in the eDEP ATC system to perform handover from the Tower as the flight clears the runway on take-off, and will release an aircraft to the Tower as it comes in to land.

2.3 ASSUMPTIONS AND DEPENDENCIES

TWR G10 Mandatory Assumption TAAM data

Assumption 1. It will be assumed that EEC will supply TAAM data, which on tailored conversion to the appropriate eDEP format can be used in the Tower simulator.

TWR G20 Mandatory Assumption DSI HMI guideline

Assumption 2. The DSI HMI Specification (V1.1 Dec1999) will be consulted as a guideline for the required HMI but the objective is NOT to implement a DSI HMI but to build a sample HMI that demonstrates key elements.

TWR G30 Mandatory Assumption aircraft restricted to taxiways

Assumption 3. Aircraft shall be restricted to travelling along the network of taxiways and runways.

TWR G40 Mandatory Assumption vehicles restricted to taxiways

Assumption 4. All ground vehicles (e.g. cars, rescue services etc) shall also be restricted to taxiways and runways.

TWR G50 Mandatory Assumption turn realistically


14 Aug 2007

Page 11 of 69

Assumption 5. Aircraft and ground vehicles shall not cut corners when manoeuvring from one taxi segment to another, but shall turn in a realistic manner.

TWR G60 Mandatory Assumption buildings drawn as map

Assumption 6. No account shall be taken of physical surroundings. Note that as buildings will be drawn as map items it will be left to the user to ensure that no taxiway or runway intersects any (drawn) buildings. [i.e. algorithm will not be required to detect the presence of fixed obstacles, like buildings.]

TWR G70 Mandatory Assumption no coupling decoupling

Assumption 7. Coupling and decoupling of towed aircraft shall not be simulated [but push back will be simulated, with timing dictated by push back event.].

TWR G80 Mandatory Assumption no coupling decoupling

Assumption 8. Coordination between operator roles for departure will be from Apron to Taxi To Runway controllers and vice versa for arrivals. Although there may be many Apron, many Taxi and many Runway controllers the Tower simulator will not support coordination between named controllers.


14 Aug 2007

Page 12 of 69

3 SPECIFIC TOWER REQUIREMENTS

3.1 ARCHITECTURE REQUIREMENTS

Figure 1: Proposed Tower Subsystem Architecture


14 Aug 2007

Page 13 of 69

The components shown in the diagram are:

• TACR Tower Aircraft Performance Server

• TASP Tower Airspace Server

• TIFPL Tower Initial Flight Plan

• DNS Detailed Navigation Server

• TPM Tower Pilot Manager

• TFM Tower Flight Manager

• TFPM Tower Flight Progress Monitor

• TIAS Tower Integrated Air Surveillance

• TCS Tower Coordination Server

• TCWP Manned Tower Controller Working Position

• TPWP Manned Tower Pilot Working Position

• UTCWP Unmanned tower CWP

• TSN Tower Safety Network

• DMAN Departure Manager

While the TWR subsystem will draw on the existing eDEP implementation, it will comprise a distinct set of component servers and services. This will allow it to be clearly distinguished from its eDEP ATC counterpart.

TWR 10 Mandatory Architecture distinct components.

The Airport components shall be distinct from the normal ATC (en-route/approach) components. Rationale : the ground movement capability should not increase the size & complexity of existing functional blocks (IAS, FM, etc)

TWR 20 Mandatory Architecture integrated enroute/approach.

However, the airport & en-route/approach components will form an integrated solution

TWR 30 Mandatory Architecture basic components backwards compatibility.

Note: basic components such as ASP & IFPL may be extended to cover both airport & ATC views, as long as they maintain backwards compatibility

TWR 40 Mandatory Architecture built upon exiting GSDK and eDEP.

Notably, the airport components shall be built upon existing GSDK & eDEP building blocks

For example, the atc.airspace.entity.Runway entity will have an associated twr.airport.entity.RunwayPerimeter with a reference to the runway.

TWR 60 Mandatory Architecture document concerns.


14 Aug 2007

Page 14 of 69

The required design documentation shall explicitly address these architectural concerns.

TWR 2005APT80 Mandatory DEMONSTRATION SCENARIOS

The Tower project shall support the development of demonstration scenarios exhibiting different controller and pilot configurations.

3.2 TACR (TOWER AIRCRAFT TYPE DATA)

TWR 70 Mandatory TACR eDEP type extended.

The eDEP aircraft type data shall be enriched to include

• Normal touch down speed

• Normal final approach speed

• Normal take-off speed

• Runway Deceleration (m/s2) in dry conditions

• 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)

• [optional] minimum take-off and landing distances

Minimum take-off and landing distances shall be derived from runway kinematics.

Additional parameters for taxi speed and queuing information shall also be included.

3.3 TASP (TOWER AIRSPACE)

The TASP will provide airport definition data including taxiways, aprons, runways and ground definition points defining holding points and de-icing points. Each item will be modelled as a GSDK entity, stored in the APS database and distributed to client components through a client side Airport service object.

TWR 80 Mandatory TASP, eDEP entity model extended.

The eDEP entity model shall be extended to cover airport related entities

TWR 90 Mandatory TASP static entity.

The static entities include

• Runways

• Taxiways

• Ground Definition (GD) points

• Aprons

• Gates

• Airport

GD points shall define Holding, De-icing, Gate, Parking and Runway Entry points.


14 Aug 2007

Page 15 of 69

TWR 100 Mandatory

(modified)

TASP taxiway entity

The taxiway entity will contain the following attributes

• Name

• Allowed A/c types (i.e. (L)ight and/or (M)edium, and/or (H)eavy combinations)

• Status (open / open-for-arrivals-only / open-for-departures-only / closed)

• List of taxiway segments

• Taxiing max speed

• List of ground definition points

Note: A taxiway may contain segments – e.g. one straight stretch with taxi speed=20knots, and then a bend segment with speed=10knots

Each taxiway shall be defined using:

• Name

• List of GD points

A taxiway segment shall be defined by a set of consecutive GD points and shall have the following attributes:

• Allowed aircraft types (combinations of L(ight),M(edium),H(eavy))

• Taxiing max speed.

• Status (open, arrivals only, departures only, closed)

Each segment shall have two such sets of data. One set representing travelling from “A to B” and the second representing travelling from “B to A”.

Any taxiway segment allowing two-way traffic shall only be wide enough to take one aircraft.

Bends shall be approximated using a set of elemental straight segments.

TWR 110 Mandatory TASP runway entity.

The runway entity shall define

• Normal attributes (as already found in eDEP – name, direction, …)

• Touch down distance (distance from runway threshold)

• List of runway exit/entry points

Two GD points will represent the start and end of the runway.

TWR 120 Mandatory TASP runway entry/exit point.

For taxiways leading to the runway, the last ground definition point shall be the runway entry/exit point. (Hence, the system may derive that the taxiway is joined to the runway)

Associated GD exit/entry points shall be defined along the runway.

TWR 130 Mandatory TASP ground definition point

Ground Definition Points (within taxiway, runway, apron definitions) shall be defined as


14 Aug 2007

Page 16 of 69

• Latitude, longitude

• (Internal ID) Name

• Holding point – i.e. are a/c requested to stop here? If so, for how long (-1 : stop, >0 : a delay)

• Type = (De-icing point, gate point, parking point, runway point, runway entry hold point.)

If an aircraft is requested to stop at a GD point then it may only continue from that point when the delay has expired or its controller has given it clearance to continue its taxi.

No specific manoeuvre shall be performed when parking an aircraft. Parking will be simulated by taxiing the aircraft to a GD point where it will hold for an indefinite amount of time.

TWR 140 Mandatory TASP apron entity.

The apron entity shall define

• name

• [optional] Dimensions

• List of contained gates

Dimensions shall not be simulated. An airport shall be partitioned into ground sectors which may cover all or part of the airport. Each apron shall be modelled using a ground sector where any gates within the geographic boundaries of the ground sector will be associated to that apron.

TWR 150 Mandatory TASP gate entity.

The Gate entity shall define

• Name

• Latitude / Longitude. (or associated point)

• Default occupancy time (time a/c is there before departing, time stays after arrival)

A Gate shall be defined as a GD point and shall be part of a taxiway segment, not necessarily at the end of a taxiway.

Departing aircraft will appear at the gate at “occupancy time” seconds before EOBT. When arriving aircraft reach an apron gate they shall remain active until “occupancy delay” seconds before they are removed from the simulator. A single system “occupancy time” will be used for all gates.

TWR 160 Mandatory TASP entity altitude.

The airport entity (already existing in eDEP) shall be extended to include ‘airport altitude’ (the issue of transition altitudes shall not be considered within eDEP)

The airport altitude shall be used to define the aircraft flight level when entering or leaving the eDEP ATC system.

TWR 170 Mandatory TASP eDEP file formats.

eDEP file formats shall be extended to cover the above entities.

Note that to achieve backwards compatibility, existing formats will be preserved, and for new entries extra fields will be added – new parser objects will then inherit from the existing parsers.


14 Aug 2007

Page 17 of 69

TWR 180 Desirable TASP import TAAM data.

[optional] A TAAM –> eDEP file converter utility shall be required to import such data into eDEP. Note: this conversion process is not expected to be 100% automated – some human intervention will be necessary. However, a concrete example of what can be automated is described below : In TAAM Ground Definition points are not named. Within TAAM, taxiways are defined as ‘crossing’ if both taxiways contain a point with identical lat/long locations. Hence, the TAAM->eDEP conversion process would be required to (a) analyse all TAAM points (b) determine those that are identical (c) allocate eDEP named Ground Definition points in consequence.

It is assumed that EEC will supply the TAAM data files (See Assumption 1).

TWR 190 Optional TASP XML import utility.

[optional] A STORIA XML -> eDEP file converter utility may be required to import such data into eDEP.

TWR 200 Mandatory TASP entity backwards compatible.

The current eDEP platform (approach/en-route ATC) shall continue to function correctly in the absence of the above data (i.e. backwards compatibility for existing file formats) Rationale : ‘normal’ eDEP simulations will be derived from IPAS data, which does not extend to airport operations.

3.4 TIFPL (TOWER INITIAL FLIGHT PLANS)

TWR 240 Mandatory TIFPL airport flight plans.

The airport flight plans (AIFPL) will include

• Callsign

• Vehicle type (aircraft, car, towed-aircraft etc)

• (arrival or departure) Runway Name

• (arrival or departure) Gate number

• Initial Navigation constraints

• [optional] taxiing speed

• ETA (for arrivals, when running in standalone mode)

• EOBT (Estimated Off Block Time) for departures

• Next callsign (used for turnarounds whereby a/c changes IFPL)

TWR G80 Mandatory TIFPL coupling de-coupling not supported

Towed aircraft shall be simulated by specifying the aircraft’s type as a “towed aircraft”. Simulation of coupling and de-coupling vehicles shall not be specifically supported (Assumption 7). Although a towed aircraft which is manoeuvred to a point ready for taxiing and then take-off can be scripted by using three types of vehicles. The first vehicle whose type is towed aircraft that is later superseded by two other vehicles one a tractor and the other an aircraft. The tractor and aircraft become active as the towed aircraft is destroyed.

TWR G90 Mandatory TIFPL turnarounds


14 Aug 2007

Page 18 of 69

“Turnarounds” shall be simulated by destroying the current aircraft, then immediately activating the new flight plan and aircraft with the “next” callsign [necessary as aircraft callsign defines reference key to all flight data]. The “next” callsign shall be specified in the first aircraft flight plan.

TWR 250 Mandatory TIFPL extends IFPL.

Airport flight plans (AIFPLs) shall be associated to traditional flight plans (IFPLs) – hence, AIFPLs shall not duplicate unnecessarily information available within IFPLs. Note: the implementation may wish to extend IFPL structures to include AIFPL data – as long as backwards capability is guaranteed. For example, a subclass of atc.airspace.entity.FlightPlan would be acceptable.

TIFPL will extend IFPL. When the Tower and eDEP ATC systems are used together, TIFPL will act as a single server and service both systems.

3.5 DNS (DETAILED NAVIGATION SCRIPTS)

The algorithm to determine the optimum route both from apron gate to the runway take-off point, and from runway landing point to the apron gate will use 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 shall be 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 will widen its search to follow routes that take the aircraft away from the runway entry.

3.5.1 Data Definition TWR 210 Mandatory DNS aircraft airport movements.

It shall be possible to define aircraft airport movements in terms of constraints. This includes,

• Start constraint

• optional intermediate constraints (i.e. via constraints)

• optional NOT-via constraint (i.e. points through which the a/c must not pass)

• Note: This is to prevent the system choosing certain paths, which are deemed operationally incorrect.

• End constraint

An aircraft’s route about an airport shall be defined in terms of airport ground definition points. It shall be possible for example, to construct a route from point A to B via point X. Then to continue from B to C but not via point Y. A navigation script will then be calculated to take the aircraft on an optimum route that goes from A, X, B, C that may contain further intermediate points (but not Y between B and C) e.g. A, a1, a2, X, a3, B, b1, b2, C.

TWR 220 Mandatory DNS airport movement constraint.

A navigation constraint shall be defined as :

• Point name (or taxiway name for VIA points)

• Simulation command

o Nothing (i.e. follow the default behaviour associated with the point)

o Pause <duration> (i.e. causes the a/c to pause for a given period)


14 Aug 2007

Page 19 of 69

Note: This will be used for pushback, where a/c pause for 1 minute as the tractor is removed.

o Stop (i.e. a/c will wait for further clearances)

Note: This is the default behaviour for aircraft passing HOLDING points.

If no controller defined qualifier is present then the default behaviour shall be adhered too.

Any default qualifiers on intermediate points introduced when calculating the navigation script shall also be adhered too.

TWR 230 Mandatory DNS calculation

The system shall be responsible for calculating the DNS ‘detailed navigation script’ (see below).

3.5.2 Detailed Navigation Scripts TWR 260 Mandatory DNS calculated from AIFPL.

Given the AIFPL navigation constraints (see requirement 210) then the system shall compute the detailed navigation script (i.e. the complete list of points to traverse). The computation shall :

• Find the shortest route without violating defined restrictions (e.g. taxiway directions).

• Disallow direction reversal (i.e. U turns)

• [optional] involve a minimum number of taxiway changes

• Each point in the list shall contain simulation command qualifiers (e.g. pause/stop) which are inherited from either the navigation constraints, or the airport points.

All taxiways shall be defined as a set of taxiway segments. Each taxiway segment, (specified by GD points A and B) defines the allowed type of traffic flow for both directions (i.e. A to B and B to A). The type of traffic flow allowed will be one of open, closed, arrivals only, departures only.

3.6 TFM (TOWER FLIGHT MANAGER)

The Tower Flight Manager (TFM) component will provide the main source of planned (i.e. estimated) flight data in the system. It shall accept initial flight plans from the TIFPL server and from the initial flight plan constraints process them into navigation objects. The TFM will also maintain the current clearance state for the aircraft.

TWR 690 Mandatory TFM estimate trajectory.

Based on the Detailed Navigation Script, the FDPS shall determine an estimate ‘trajectory’.

In conjunction with the navigation script TFM shall maintain estimate off block (OBT) and take off (TOT) times for departures and estimate landing (LDT) and in block (IBT) times for arrivals. TFM shall manage these estimates and promote them to targets and finally to actual as the aircraft progress on their travels.

TWR 700 Mandatory TFM trajectory airport point with time.

This ‘trajectory’ shall simply be a list of (Airport Point, Time) values (i.e. the supplier is not expected to provide a detailed trajectory with estimates every 5 seconds).

TWR 710 Mandatory TFM determination of taxiing times.

This trajectory shall be used to determine approximate [in fact it will provide nominal taxi times] taxiing times


14 Aug 2007

Page 20 of 69

Note: approximate since it cannot take into account queuing etc.

DMAN D150 Mandatory Arrival and Departure clearances

For departing aircraft, as the flight moves from its stand to the runway, it shall be handed over from apron controller to taxiway controller and from taxiway controller to the runway controller. For an arriving flight, it shall be assumed and cleared to land by the runway controller, then handed on to the taxiway controller, and finally from taxiway controller to the apron controller.

Taxi/Take-Off State Transitions Landing/Taxi State Transitions

Figure 2: Clearance State Transition Diagrams for Take-off and Landing

The diagrams in Figure 2 above show the allowed transitions for departing aircraft on the left, and arriving aircraft on the right.

3.7 TFPM (TOWER FLIGHT PROGRESS MONITOR)

The Tower Flight Progress Monitor (TFPM) component is responsible for monitoring the progress of a flight along its plan, by comparing its predicted position against the actual position. The predicted tracks are determined from the DNS while the actual position is generated by the TPM. TPM will aid the monitoring by supplementing the positional data with manoeuvre specific details.

TWR 580 Mandatory TFPM Event

The TWR simulator shall generate important simulation events for

• A/C Start up

• A/C Push Back Request

• A/C Push Back Complete

• A/C Arrival at Holding Point (e.g. runway holding point)

• A/C Line up Complete


14 Aug 2007

Page 21 of 69

• A/C Take Off

• A/C Landing

Note: These events simulate the R/T communication between Pilot and TWR system

The TFPM component shall allow subscription to the following progress events:

• Push Back Start Event and Push Back Completed Event

• Start Taxi Event

• Hold Point Reached Event and Hold Point Crossed Event

• Runway Line Up Start Event and Line Up Completed Event

• Take Off Event

• Land Event

• Runway Exit Event

• Apron Entry and Exit Event

• Park At Gate Event

• Ground point passed.

3.8 TPM (TOWER PILOT MANAGER)

The Tower Pilot Manager (TPM) component will model the aircraft movements and the interactions between aircraft and other airport 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 on the apron containing the parking gate, the motion along the taxiways, accounting for intersections, holding points and other traffic. It will also model the aircraft acceleration on take-off and the deceleration on landing.

3.8.1 Basic Airport Navigation Once the aircraft has entered the taxiway network, it will follow the constraints identified in the DNS, stepping the aircraft along its route ‘navigation’ one time step at a time. The speed of the aircraft will be adjusted to account for holding constraints, crossing traffic and slower aircraft ahead on the same taxiway.

TWR G100 Mandatory TPM no taxi acceleration

The baseline simulation shall not model acceleration during taxi, but will assume instantaneous changes in speed. So when travelling at their taxiing speed aircraft will be able to instantaneously stop.

Requirement removed as a result of TWR 2006TWR220

TWR G101 Mandatory TPM expandable changeable GMS

The design of the TPM ground movement simulation will allow an easily expandable and changeable model for aircraft and ground vehicles.

TWR G110 Mandatory TPM crossing traffic

Crossing traffic only needs to be assessed when the aircraft reaches a junction point. If the aircraft is about to reach a junction point at a given time interval ahead of the next crossing aircraft, then it shall be allowed to proceed. If a crossing aircraft is currently passing the entry to the taxiway, the aircraft


14 Aug 2007

Page 22 of 69

must wait at a predefined distance before the junction, until the crossing aircraft has passed, and the situation will be reassessed.

TWR 270 Mandatory TPM navigation dynamic for aircraft.

Dynamic aircraft navigation shall be based upon the computed DNS

The aircraft motion shall be simulated using a time-stepped integration of the detailed navigation script (DNS). This will include any DNS constraints and interactions with other vehicles along its path. The model will account for constraint and taxiway speed limits and weather conditions [namely wet or dry].

TWR 280 Mandatory TPM navigation taxiing speed restricted.

The AIFPL taxiing speed will override any taxiway maximum speed constraint.

In the TIFPL the user shall be able to define an optional taxi speed for the aircraft. If taxi speed is greater than that allowed on the taxiway, then the TIFPL taxi speed shall apply. A slower aircraft or vehicle travelling in front on the same taxi segment may restrict the taxiing speed.

TWR G120 Mandatory TPM traffic congestion

When an aircraft catches and follows another aircraft at a nominal distance ahead on the same taxiway, it will slow to the same speed as the lead aircraft. If the lead aircraft slows down or stops, then after a short interval (given as a function of the current distance between the aircraft) the following aircraft will adjust its speed accordingly.

TWR 2006TWR220 Mandatory TPM GMS Acceleration Deceleration

Aircraft and vehicles shall display acceleration and deceleration characteristics while travelling on taxiways. They shall:

• Accelerate from rest to their taxi speed.

• Decelerate/accelerate for changes in speed due to taxiway segments.

• Decelerate for fast exits.

• Decelerate for traffic complexity.

Note, in all circumstances aircraft/vehicle shall apply an immediate stop if a collision (or overshoot) is about to occur.

Note: This requirement replaces TWRG100 and TWR350.

TWR 2006TWR230 Mandatory TPM GMS Reaction Time

When free to move after being stationary as a result of blocking traffic (i.e. traffic jam), aircraft and vehicles shall not react immediately but shall incur a reaction time delay before recommencing to taxi.

TWR 2006TWR240 Mandatory TPM GMS Speed Adjustment

Aircraft taxi speed shall be adjusted with respect to the aircraft wake vortex category.

It is assumed that this requirement is already satisfied as speeds are per vehicle type.


14 Aug 2007

Page 23 of 69

TWR 350 Mandatory TPM navigation no taxiway acceleration/deceleration.

Aircraft acceleration / deceleration simulation is not required (except for takeoff & landing – see below)

Requirement removed as a result of TWR 2006TWR220.

TWR 360 Mandatory TPM navigation aircraft remain within taxiway.

The navigation simulation should ensure that taxiway corners are not cut – the aircraft shall remain within the taxiway width.

All traffic movement will be restricted to the predefined taxiways and runways (See Assumption 3 and Assumption 4).

As traffic manoeuvres from one taxi segment to another the aircraft will travel the route exactly and in a realistic manner. This shall ensure that corners are not cut and that all traffic, aircraft and ground vehicles, remain within the taxiway width (See Assumption 5).

Drawn buildings shall not impede movement along taxiway segments (See Assumption 6).

3.8.1.1 Traffic Rules

TWR 290 Mandatory TPM navigation pilot intelligent DNS.

The simulator shall adjust the DNS in real-time to ensure basic ‘pilot intelligence’ is simulated.

The TWR simulator, to ensure a realistic environment shall implement traffic rules for pilots while taxiing at an airport. These rules will vary a vehicles speed and if necessary bring the vehicle to a stop to prevent any conflict with another vehicle.

TWR 310 Mandatory TPM navigation accommodates forward taxiway traffic.

Aircraft shall not overtake each other on taxiway routes (i.e. taxiing speeds shall be varied to accommodate forward traffic)

TWR 320 Mandatory TPM navigation queue behind stationary aircraft.

Hence, aircraft shall queue behind stationary aircraft (with an appropriate distance between a/c)

TWR 330 Mandatory TPM navigation aircraft give way rules.

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

TWR 340 Mandatory TPM navigation traffic give way rules.

Autonomous vehicles (e.g. cars) shall always give way in case of crossing aircraft.

3.8.2 Apron Navigation The Apron simulation provides a simple model that identifies the times of key events in the movement of aircraft while on the apron. An aircraft shall be considered to be on the apron if the aircraft’s reported position places it within the apron’s associated ground sector.


14 Aug 2007

Page 24 of 69

Typically an aircraft shall perform a push back manoeuvre at the start of its journey from an apron gate to the destination runway. The push back shall involve the aircraft travelling backwards until reaching a junction between two taxiway segments that allow the aircraft to travel forwards towards its destination runway.

The apron simulation shall generate events to mark

a) The start and end of the pushback

b) The entry and exit of the apron.

c) Passing taxiway junction.

d) Parking at apron gate.

Aircraft positions shall be calculated at regular intervals on the basis of a nominal apron manoeuvring speeds for pushback and the apron taxi.

TWR 370 Mandatory TPM Apron gate occupancy time.

Once the aircraft arrives at its gate, assuming this is the last point in the AIFPL, the flight shall remain active (including radar plots) for a given period (as indicated by the Gate default occupancy time).

TWR 380 Mandatory TPM Apron deactivation delay.

Once the deactivation delay is passed, the flight will be killed within the system.

TWR 390 Mandatory TPM Apron AIFPL activation.

For departing a/c the AIFPL shall become active ‘x’ minutes before EOBT.

TWR 400 Mandatory TPM Apron simulate turnaround.

In order to simulate turnarounds two AIFPLs will be filed – with the 1st flight being de-activated, as the 2nd one becomes active. (note : AFIPL1.next_callsign == AFIPL2.callsign : informing the system of a turnaround).

Note: Turnaround – an aircraft arriving on one callsign, and departing soon after (e.g. 1 hr) as another callsign

TWR 410 Optional TPM Apron pause for de-icing.

[optional] Certain departing aircraft shall be sent to de-icing points : these points shall have an associated PAUSE parameter. This will simulate the process of de-icing.

TWR 420 Optional TPM Apron destination parking.

[optional] Certain arriving aircraft, after a period at the gate, shall be sent to the parking area. This shall be simulated by filing AIFPLs with constraints (start-point=runway-exit, via=gate-23 [with associated pause], destination=parking).

TWR 430 Optional TPM Apron departing from parking.

[optional] Certain departing aircraft shall begin their navigation at the parking area. They shall then proceed to the gate, where after a given delay (e.g. 30 minutes) they shall push-back for taxing to runway. This shall be simulated by filing AIFPLs as (start point=parking [with pause], via=gate-23 [with pause], destination=runway-entry)


14 Aug 2007

Page 25 of 69

3.8.3 Runway Navigation The motion of the aircraft on the runway shall be modelled by using a constant acceleration model for take-off and a constant deceleration model for landing. Given a take-off speed vt, and 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

tt a

vusand

a

vs

asuv

22

2222

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.

TWR 2005APT90 Mandatory TPM arrival leave runway

By default landing aircraft will decelerate at a rate, as to leave the runway at the first possible exit.

Landing aircraft will decelerate at a rate such that they will reach their taxispeed at the runway exit, providing that the required deceleration rate is within the aircraft performance limits.

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 required speed can not be achieved then the aircraft will still take the exit and continue to decelerate to the required taxiing speed.

In wet conditions, the wet weather acceleration and deceleration values will be defined by the tower aircraft performance data.

TWR 440 Mandatory TPM Runway navigation rules.

When entering the runway (i.e. beyond the runway entry point) the aircraft shall follow ‘runway navigation’ rules

TWR G130 Mandatory TPM Runway line-up

At the last taxiway point (runway entry hold point) before encountering the runway entry point an aircraft shall stop and await clearance to LINEUP. Once the clearance is given the aircraft will move to the runway entry point. Note that the aircraft may already have been given the LINEUP clearance in which case the aircraft will not stop at the runway entry hold point.

TWR 300 Mandatory TPM navigation await take-off clearance.

Aircraft shall line-up and await take-off clearances when entering runways.

TWR 450 Mandatory TPM Runway line-up.

Following the instruction to line-up the aircraft shall enter the runway & then turn to the required heading (as defined by the runway name). For example, for runway 29, the aircraft shall face 290.

A conditional line-up instruction shall allow the user to perform the line-up after a named vehicle/aircraft has left the runway perimeter.

Note a runway may be named 29 but the exact heading may be 293.

TWR 460 Mandatory TPM Runway accelerate to take-off


14 Aug 2007

Page 26 of 69

Following an instruction to take-off the aircraft shall accelerate in a realistic manner along the runway

A conditional takeoff instruction shall allow the user to perform the takeoff after a named vehicle/aircraft has left the runway perimeter.

On take-off aircraft will either accelerate from a stationary position or from their taxiing speed to their take-off speed.

TWR 470 Mandatory TPM Runway take-off speed

Once the aircraft attains the required take-off speed (as specified in the aircraft type data) the aircraft shall be considered airborne.

TWR 480 Mandatory TPM Runway airborne aircraft not simulated.

Once an aircraft is airborne it shall no longer be simulated within the ground movement simulator (hence, no radar update for this track shall be produced)

When the Tower system runs in standalone mode (i.e. without the eDEP ATC system) airborne aircraft shall be removed from the Airport View.

When the Tower system runs in connected mode (i.e. with the eDEP ATC system) airborne aircraft shall remain on the Airport view while in close proximity to the airport. Once an aircraft is airborne it shall appear on the Approach View.

TWR 490 Mandatory TPM Runway touchdown

Landing aircraft shall touchdown at the specified distance from the threshold point (as defined in the runway definition).

TWR 500 Mandatory TPM Runway touched down aircraft simulated.

Once an aircraft has touched down it shall be simulated within the ground movement simulator (hence, radar updates for this track shall be produced)

When the Tower system runs in standalone mode (i.e. without the eDEP ATC system) an aircraft shall appear on the Airport View when the aircraft has touched down.

When the Tower system runs in connected mode (i.e. with the eDEP ATC system) airborne aircraft shall appear on the Airport view while in close proximity to the airport. Once an aircraft has touched down it shall be removed from the Approach View.

TWR 510 Mandatory TPM Runway decelerate on landing.

Landing aircraft shall decelerate in a realistic manner along the runway (until taxiing speeds have been attained)

When reaching the final point on the approach aircraft will have attained their final approach speed (i.e. as late as possible). On touch down aircraft (are assumed to) have attained their touch down speed.

TWR 520 Mandatory

(modified)

TPM Runway leave at designated exit point.

The landing aircraft shall leave the runway at the designated runway exit point (the start constraint in the AIFPL). The aircraft now passes to ‘Basic Airport Navigation’


14 Aug 2007

Page 27 of 69

TWR G131 Mandatory TPM Clearance to proceed

Aircraft encountering a taxipoint with an indefinite delay require a clearance to proceed. These taxipoints can be positioned at the edge of runway perimeters. Therefore any arrival, which encounters such a taxipoint, will require a taxi clearance to continue to its gate.

TWR 530 Mandatory TPM Runway clearance to traverse runway.

The runway exit point (and its associated taxiway) may lead the aircraft to another runway (In other words, the airport has 2 parallel & adjacent runways.). The aircraft shall stop at the 2nd runway entry point, until a clearance has been given to traverse the runway.

Clearance to cross a runway will be simulated by defining and using taxipoints with an indefinite delay (i.e require clearance to proceed) positioned at or near the runway perimeter. Therefore any arrival or departure, which encounters such a taxipoint, will require a taxi clearance to cross the runway.

TWR 540 Mandatory TPM Runway dry weather.

The supplier shall assume dry-weather conditions (related to a/c acceleration & deceleration rates)

3.9 TIAS (TOWER INTEGRATED AIRSPACE SURVEILLANCE)

TWR 50 Mandatory TIAS distinct air ground components.

The Airport components shall maintain a clear AIR/GRD distinction (i.e. predicted trajectories versus actual trajectories). However, may propose simple architecture choices which allow, in the future, a fully distributed AIR / GRD distinction.

The Tower Integrated Air Surveillance (TIAS) provides a source of tracks for the eDEP facility based upon pilot position reports. The tracks shall be reported periodically (time based upon system parameters) and will contain the latest pilot reported position. The reported positions shall represent the actual positions, compared to the planned positions maintained by the TFM.

3.10 TCS (TOWER COORDINATION SERVER)

The Tower Coordination Server (TCS) provides a routeing protocol for the handover of aircraft between the respective tower roles (Apron – APR, Taxiway – GRD, Runway –RWY). TCS shall operate using a similar protocol to that defined for the ATC coordination server.

TWR G140 Mandatory TCS handover

Handover will be modelled using a Handover Event, which shall identify the controller role handing the aircraft over, and the controller role assuming control. The TCS shall keep track of the current controller, and hence the coordination status of the aircraft.

TWR G150 Mandatory TCS coordination

The TCS shall ensure that coordination messages are distributed to all the concerned controllers. The airport may define more than one apron and have more than one controller managing the taxiways. It is assumed that all controllers will see all the traffic, but the status will be maintained such that only the relevant role will have access to aircraft under their control. (See Assumption 8)


14 Aug 2007

Page 28 of 69

3.11 TCWP (TOWER CONTROLLER WORKING POSITION)

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

Only those navigation orders that plan the movement of aircraft and vehicles will be available to ground controllers.

TWR 2005APT70 Mandatory SHORT CUT ORDERS

There are a number of state transitions, which imply a subsequent transition, and hence can be combined into a short-cut order. These include:

• Pushback, Taxi, Hold, Lineup, Abort clearances imply Assume.

• Take-Off clearance implies Lineup Clearance.

• Cleared-To-Land implies Assume

3.11.2 Hybrid Position When configured as a Hybrid, the position will affect the planned and actual movement of aircraft and vehicles.

TWR 2005G70 Mandatory Hybrid Working positions

A hybrid pilot and ground controlling working position will be supported to provide “feeder” working positions.

TWR 560 Mandatory TCWP Navigation orders hybrid.

Hence, the navigation orders shall be hybrid (GMS & TWR FPDS updates)

The combined set of ground and air controller orders will be available to a Hybrid controller.

3.11.3 Navigation Orders

TWR 570 Mandatory TCWP Navigation orders, pause, resume, start, change, kill, take-off, line-up, taxi

The following order types shall be supported

• Pause <delay> Causes the flight to pause for the given <delay>. A negative delay implies the a/c will stop indefinitely until given a resume order.

• Resume Causes a paused flight to resume navigation.

• Nav Start <time> If <time> is null then forces the flight to immediately begin navigation according to its AIFPL. Otherwise, the flight will begin navigation at time <time> (i.e. AIFPL.activation_time = <time>)

• Change Route Defines a new destination point, and potentially a number of ‘go via’ points. The system should compute the shortest legal route to achieve these path constraints.

• Kill The flight is deleted from the system


14 Aug 2007

Page 29 of 69

• Take-off Causes a lined up aircraft to accelerate and take-off

• Line up The a/c is cleared to line up. This instruction shall be issued when the a/c is stopped at (or when the a/c is approaching) the runway entry hold point,

• Taxi <destination point> The destination point is optional – if not present then the AIFPL destination point is taken.

The DNS shall be updated each time an order (e.g. pushback, taxi) is given. This will ensure that the predicted and actual situations are kept in step.

3.11.4 Airport situation view

TWR 720 Mandatory TCWP airport view display.

The HMI’s principle element shall be the Airport view display.

TWR 730 Mandatory TCWP airport map

The AVD shall contain a detailed 2D airport Map detailing taxiways, runways, buildings, aprons/gates etc

TWR 2005APT60 Mandatory CONFIGURE COLOUR SCHEME

The TWR colour scheme shall be configurable enabling it to match the example Paris CDG airport display.

TWR 740 Mandatory TCWP airport map in TAAM format.

The detailed map data shall be provided by the EEC in a TAAM format (polygon ASCII files). This will be converted by the supplier into eDEP file format.

TWR 750 Mandatory TCWP airport plot movements.

The AVD shall display all airport traffic movements (plot position, vector line, data block)

TWR 2005APT10 Mandatory EXTEND AIRPORT VIEW

The Tower simulator shall be modified to display aircraft tracks whilst in flight, prior to landing and after take-off. The tracks shall be displayed to an arbitrary range from the airport (typically 10nm), and below an arbitrary altitude (typically 2000 feet). The range and altitude values shall be set from GSDK resources.

TWR 2005APT20 Mandatory COMPANION VIEW ADJACENT SEPARATE

The airport view display (AVD) shall support the display of companion windows. The companion windows shall be configurable such that they can be displayed adjacent to the AVD or as a separate window.

TWR 2005APT30 Mandatory COMPANION VIEW INDEPENDENT

The management of centring and magnification of companion windows shall be independent of the parent AVD.

TWR 2005APT40 Mandatory COMPANION VIEW HIGHLIGHT


14 Aug 2007

Page 30 of 69

Highlighting an aircraft entity on the AVD shall also highlight any corresponding entity on the companion window. Similarly, highlighting an aircraft entity on the companion window shall highlight any corresponding entity on the AVD.

TWR 2005APT50 Mandatory COMPANION VIEW DECORATION

The AVD shall support the use of window decoration e.g. File, Zoom utility functions. The AVD shall be configurable such that these decorations may be replaced by a separate independent toolbar.

3.11.5 APP Radar View Display TWR 760 Mandatory TCWP App radar view

From an operational viewpoint, the TWR controller (in particular the Runway controller) shall equally have a radar view display.

TWR 770 Mandatory TCWP App radar view information only

From a technical viewpoint, this radar view display belongs to the APP system (note: the TWR radar display is normally for ‘information only’.)

The Approach (APP) Radar View shall only be available when the Tower system is run in tandem with the eDEP ATC system. The information used to populate the APP view will be sourced solely from the eDEP ATC system.

3.11.6 Ground Radar Simulation The Ground Radar simulation characteristics shall apply to plots on the Airport Situation view and on the Approach Radar view. It will be possible to configure different update rates for the two views.

TWR 590 Mandatory TCWP Ground radar true updates.

Radar updates (plots) shall be identical to ground movement state vectors (i.e. no error modelling and/or radar coverage modelling is required)

TWR 600 Mandatory TCWP Ground radar variable update rate.

Radar updates (plots) shall be generated at a variable rate (by default : 1 second)

3.11.7 Operator Roles TWR 780 Mandatory TCWP Operator roles.

The TWR HMI system shall have a concept of controller roles.

TWR 790 Mandatory TCWP Operator roles, apron, ground, runway.

The roles shall be

• Apron Controller (APR) [optional]

• Ground Controller (GND)

• Runway Controller (RWY)

• Clearance Delivery (CLD


14 Aug 2007

Page 31 of 69

Ground definition points shall be grouped to gates for pushback manoeuvres, grouped to runways for lineup and entry/exit points.

TWR 800 Mandatory TCWP Operator roles assigned.

Each TWR CWP instance shall have an associated list of assigned roles (1 or more).

The geographic areas that the controller has responsibility for will determine the roles that a TWR CWP controller is performing.

TWR 810 Mandatory TCWP Operator roles combination.

The roles shall be typically

• CWP1=RWY, CWP2=GND, CWP3=APR

• CWP1=RWY, CWP2=GRD (and no apron)

• CWP1=RWY+GRD (and no apron)

TWR 820 Mandatory TCWP Operator roles aircraft handover.

Although the airport is considered as a single sector (from a co-ordination view point) actual a/c control shall be transferred across several controller positions. I.e. Aircraft shall be transferred from one CWP instance to the next dependent upon the assigned controller roles

TWR 830 Mandatory TCWP Operator roles arrivals handover.

Arriving a/c shall move through the following controller roles APProach => RWY => GRD => APR

TWR 840 Mandatory TCWP Operator roles departures handover.

Departing a/c shall move through the following controller roles CLD => APR => GRD => RWY => APProach

TWR 850 Mandatory TCWP Operator roles not done by eDEP Coordination server.

The issue of transferring a/c between Controller roles shall NOT be done within the eDEP Coordination Server (i.e. it is NOT a SYSCO co-ordination function).

TWR 860 Mandatory TCWP Operator roles typical departure.

A typical departure shall progress as follows:

• Aircraft appears in CLD departure list ‘x’ minutes before EOBT

• CLD gives aircraft necessary clearance (informs pilot of SID, and optionally the CTOT (Note: Calculated Take Off Time – implies the CFMU has imposed a regulation on this flight.) and TRANSFERS a/c to Apron

• APR assumes the a/c.

• Pilot Requests Push back at the appropriate time (TakeOff Time minus estimated taxiing time).

• [optional] APR gives PUSHBACK instruction


14 Aug 2007

Page 32 of 69

• A/c is pushed back and then stops.

• Pilot informs APR that Push back is complete.

• APR gives TAXI instruction (Note: initially this taxi instruction will follow the planned AIFPL. The taxi instruction may specify a different runway entry point, which will require the calculation of a new DNS.)

• The a/c taxis through the apron area.

• Before the a/c reaches the apron boundary, the APR-D shall TRANSFER the a/c to the GRD controller.

• The GRD controller shall ASSUME the a/c

• The GRD controller shall be able to intervene (stop, resume the a/c navigation, change the required runway entry point)

• Once the a/c reaches the runway entry holding point it shall stop (unless it has been given in advance the line-up instruction)

• The GRD controller shall TRANSFER the a/c to RWY

• The RWY controller shall ASSUME the a/c

• The RWY controller shall issue the LINEUP instruction

• The a/c shall line-up on the runway and stop awaiting further instruction

• The RWY shall issue the TAKE-OFF instruction

• The a/c shall proceed down the runway and take-off.

• RYW transfers to APP (usually once the a/c has been correlated in the APP IAS).

TWR 870 Mandatory TCWP Operator roles typical arrival.

A typical arrival shall proceed as follows

• The a/c appears in the RWY Arrival list ‘x’ minutes before arrival (i.e. from the Co-ordination ACT)

• The a/c is transferred from APP to RWY at approx. 7nmiles from touch down.

• [optional] The a/c is cleared to land (Note: in eDEP all a/c will land – there is no go-around instruction)

• The a/c shall decelerate along the runway

• The aircraft shall leave the runway at the appropriate runway exit point & stop (unless a TAXI instruction has been given)

• The RWY shall TRANSFER the aircraft to GRD

• The GRD shall ASSUME the aircraft

• The GRD issues the TAXI instruction to the required Gate.

• The a/c taxis.

• The GRD controller shall be able to intervene (stop, resume the a/c navigation, change the required gate)

• The GRD shall transfer to APR

• The APR ASSUMES the a/c.


14 Aug 2007

Page 33 of 69

• The APR controller shall be able to intervene (stop, resume the a/c navigation, change the required gate)

• The a/c arrives at its gate.

TWR 880 Mandatory TCWP Operator roles label colour coding.

Labels / data etc shall follow the usual EATMP colour coding rules

Colour will also be used to reflect the TWR controller roles.

TWR 890 Mandatory TCWP Operator roles coordination sub states.

Although the TWR is seen as a single ATC sector, within the TWR system there will be ‘coordination’ sub states corresponding to controller roles.

• Flight approaching: RWY=Announced, GRD=Announced, APR=Announced

• Flight on runway: RWY=Assumed, GRD=Announced, APR=Announced

• Flight on taxiways (and transferred) RWY=Not Concerned, GRD=Assumed, APR=Announced

• Etc

The Tower coordination system will use the DSI Specification as guidelines for implementation.

Within the Tower system there will be coordination sub states corresponding to the position in the chain of coordination responsibility, similar to the eDEP ATC coordination system. The chain of coordination responsibility will be determined by ground sectorisation of the airport.

The table below illustrates the sub states for previous and next controllers when an airport ground controller assumes and transfers control of an aircraft.

Previous Previous Controller

Previous Controller

Current Controller

Next Controller

Next Next Controller

Not concerned Concerned Assumed Advance Not concerned

Not concerned Not concerned AssumedTransferred AdvanceTransferred Advance

3.11.8 Traffic Lists (Electronic Flight Strips) TWR 900 Mandatory TCWP Traffic lists arrivals, departures.

The TWR HMI shall display Traffic Lists : Arrival Traffic List and a Departure Traffic List.

TWR 910 Mandatory TCWP Traffic lists divided by role.

The lists shall be divided into subsections – defined by role.

TWR 920 Mandatory TCWP Traffic lists demonstrate DSI key elements.

The DSI Specification shall be consulted for these traffic list definitions : Note: the objective is NOT to implement a DSI HMI. The objective is to build a sample HMI which demonstrates key elements.


14 Aug 2007

Page 34 of 69

See Assumption 2.

TWR 930 Mandatory TCWP Traffic lists transfer as aircraft changes state

It shall be possible to transfer aircraft from one position (or rather role) to another (as the aircraft changes state).

3.12 UTCWP (DEMO MODE)

TWR 940 Optional Demo automatic arrivals and departures

(optional) The TWR system should incorporate a demo mode, whereby arrivals & departures occur without human intervention.

TWR 950 940 => Optional Demo UCWP type automatic responses.

This demo mode shall be build upon UCWP type technology (automated responses to system generated messages).

TWR 960 940 => Optional Demo UCWP acts as APP controller.

The demo mode shall cover the case whereby the APR controller is not present. In this case, the UCWP will respond to push back requests, and pushed-back-complete events, in order to get the aircraft to the GRD controller.

3.13 TPWP (TOWER PILOT WORKING POSITION)

The TPWP will affect the planned movement of aircraft and vehicles while they are at the airport.

The initial implementation will not implement any orders for airborne flights near to the airport.

TWR 2007TWR200 Mandatory TPWP indicate illegal selection

The TPWP shall indicate erroneous selection, in particular selecting unattainable runway for departures and unattainable stands for arrivals.

TWR 2007TWR210 Mandatory TPWP prompts

The TPWP shall indicate prompts for aircraft movement e.g. pushback, taxi, lineup and takeoff.

TWR 2005G60 Mandatory Pilot working positions

Pilots may inadvertently delay their response to clearance requests or even perform the request incorrectly.

Response to clearances will be instigated at the pilot’s discretion.

3.13.1 Ground Controller Position

TWR 2006TWR10 Mandatory TPWP Architecture TCWP-like

The design and implementation of the Tower PWP (TPWP) shall be

•••• Architecturally sound.

•••• Offer similar functionality to what is available today (e.g. hybrid TCWPs)


14 Aug 2007

Page 35 of 69

•••• Offer an HMI that is “TCWP-like”.

TWR 2006TWR20 Mandatory TPWP TOWER AIR Dependent

The TPWP shall depend upon services/events provided by AIR-side or ‘Environment’ tower components (TPM, TASP, TIFPL and Time Server).

TWR 2006TWR30 Mandatory TPWP GROUND Independent

The TWR Airborne side (TPM & TPWP) shall not depend upon (i.e. import) TWR GROUND side classes (TFM, TCS, TSN, TFPM). Neither shall the TWR Airborne side depend upon the services/events provided by GROUND-side components.

TWR 2006TWR40 Mandatory TPWP Displays Airport Airborne Traffic

The final HMI shall require that the TPWP display both airport and locally airborne traffic. Therefore, this shall require that the PM and TPM exchange state vector information.

TWR 2006TWR50 Mandatory TPWP PilotedFlight Dependent

The TPWP entity model shall depend upon AIR-side entities such as PilotedFlight.

TWR 2006TWR60 Mandatory TPWP TCWP Share TowerIdentity

TPWP and TCWP shall be allowed to share a common interface (TowerIdentity) to allow reuse of graphical widgets. This shared common interface must be generic such that it does not contravene the Air Ground distinction.

TWR 2006TWR70 Mandatory TPWP Multiple Ground Sector Frequencies

The TPWP instance shall be allocated to a number (1+) of airport frequencies (as found in GROUND_SECTOR definitions)

TWR 2006TWR80 Mandatory TPWP Transfer Frequency

The TPWP shall allow aircraft to be transferred to another ground sector’s frequency.

Advanced functionality such as multiple load balanced TPWPs for a single frequency shall not be required in this work package.

TWR 2006TWR90 Optional TPWP Transfer Named Position

The TPWP should allow aircraft to be transferred to a given TPWP position.

TWR 2006TWR100 Mandatory TPWP Orders

The following TPWP pilot orders shall be supported

•••• pushback,

•••• stop,

•••• taxi,

•••• change-route (from runway exit point to gate, from gate to runway entry point)


14 Aug 2007

Page 36 of 69

•••• change-gate,

•••• change-runway,

•••• change-sid,

•••• delete flight,

•••• line-up,

•••• take-off,

•••• transfer to frequency,

•••• accept on frequency

TPWP acceptance of frequency will be automatic.

The normal TPM “pilot intelligence logic” shall be retained (give way, queuing, no overtaking etc)

TWR 2006TWR110 Mandatory TPWP Re-Route Prior Landing Pushback

It shall be possible to enter re-routing (change-route, change-gate etc) piloting orders prior to a/c landing or pushback.

TWR 2006TWR190 Mandatory TPWP Conditional Orders

The TPWP shall offer the following conditional orders:

•••• “line up after a/c <callsign> vacates runway”.

•••• “line up and take off after a/c <callsign> vacates runway”.

TWR 2006TWR200 Mandatory TPWP Additional Orders

The TPWP shall offer the following navigation orders:

•••• Ability to “stop at a given point (ahead)”.

•••• Ability to vacate the runway at a given point.

•••• Change a/c taxi-speed.

TWR 2007TWR100 Optional TPWP Airborne Transfer Frequency

The TPWP shall allow aircraft to be transferred to another ATC sector’s frequency.

3.13.2 Graphical Requirement

TWR 2006TWR120 Mandatory TPWP HMI TCWP-like

The TPWP HMI shall have a “TCWP-like” look & feel with

•••• Geographical 2D airport view showing the airport layout (buildings, taxiways, aprons, gates) and the immediate surrounding airspace (typically 10nmiles, depending on the zoom setting).

•••• Radar labels and radar tracks for all vehicles & aircraft moving on the airport surface.

•••• Radar labels and radar tracks for all airborne aircraft within a given distance of the airport.

•••• Zoom / centre functionality.


14 Aug 2007

Page 37 of 69

•••• Traffic list windows.

The TPWP will offer an HMI similar to that of the current TCWP and not like the MASS PWP used on the ESCAPE platform.

TWR 2006TWR130 Mandatory TPWP Follows EATMP Select Highlight

The TPWP shall follow the EATMP look & feel principle - select and highlight all graphics related to the selected graphic.

TWR 2006TWR140 Mandatory TPWP TCWP-like Labels

The TPWP shall offer labels similar to the TCWP (excluding GRD-only data such co-ordination state).

TWR 2006TWR150 Mandatory TPWP Access Air-Derived Information

The TPWP shall offer full access to Air-derived data (e.g. indicated air speed, a/c trajectory etc)

TWR 2006TWR160 Mandatory TPWP Access Initial Flight Plan Information

The TPWP shall offer full access to flight plan (AIFPL & IFPL) data.

TWR 2006TWR170 Mandatory TPWP Traffic Lists

The TPWP shall offer traffic list windows, with data such as

•••• (for arrivals) predicted landing time, arrival gate

•••• (for departures) predicted request for pushback time, departure runway

3.14 TSN (TOWER SAFETY NETWORK)

This TSN component will detect illegal aircraft/vehicle (mobile) intrusion into protected areas defined at airports. The legality of entering a runway protected area is detailed under the requirements below.

The following requirements have been extracted from Operational Concept and Requirements for A-SMGS Implementation Level II (http://www.eurocontrol.int/airports/projects/asmgcs/index.html) and describe the rules that will be used to report and measure the severity of illegal intrusions into runway exclusion areas.

TSN will use track vector information (position and velocity) to determine when intrusions into protected areas occur. In addition TSN will use flight clearances such as lineup and take-off when deciding if an incursion should be reported.

Note in the following requirements T1 and T2 are the long and short final times to threshold.


14 Aug 2007

Page 38 of 69

Figure 3: Short and Long Time to Threshold

3.14.1 Closed Exclusion Area TWR 2005G90 Mandatory Closed area T1 alarm

In a closed exclusion area an arrival whose time from threshold is less than T1 will initiate an ALARM alert.

Figure 4: Closed Area T1 Alarm

TWR 2005G100 Mandatory Closed area lineup takeoff alarm

A departure lining-up or taking-off in a closed exclusion area will initiate an ALARM alert.

Figure 5: Closed Area Lineup Takeoff Alarm

TSN will use track vector information (heading) to determine if an aircraft is lining-up. TSN will use track vector information (speed) to determine if an aircraft is taking-off. Line-up and take-off clearances will also be used to determine if an aircraft is about to line-up or take-off.

TWR 2005G110 Mandatory Closed area incursion information

A mobile (vehicle/aircraft) in a closed exclusion area will initiate an INFORMATION alert.

Figure 6: Closed Area Incursion Information


14 Aug 2007

Page 39 of 69

3.14.2 Open Exclusion Area

TWR 2005G120 Mandatory Arriving on wrong runway

Aircraft arriving on the runway in the wrong direction will NOT initiate an alert except if another mobile is on the runway. (See 2005G140 etc).

Figure 7: Arriving on Wrong Runway

TWR 2005G130 Mandatory Lineup Takeoff in Wrong Direction

Departure lining-up on the center line in the wrong direction will initiate an INFORMATION alert.

Departure taking off in the wrong direction will initiate an ALARM alert.

Figure 8: Lineup Takeoff in Wrong Direction

TSN will use track vector information (heading) to determine if an aircraft is lining-up. TSN will use track vector information (speed) to determine if an aircraft is taking-off. Line-up and take-off clearances will also be used to determine if an aircraft is about to line-up or take-off.

TWR 2005G140 Mandatory Arrival with Mobile on Runway

If a mobile (aircraft or vehicle) is in the runway exclusion area and:

• The arriving aircraft < T1 from threshold will initiate an INFORMATION alert.

• The arriving aircraft < T2 from threshold will initiate an ALARM, until the arriving aircraft has passed the mobile (mobile behind the arriving aircraft)

Figure 9: Arrival with Mobile on Runway

TWR 2005G150 Mandatory Arrival with Departure on Runway

If there is a slower preceding departing aircraft which has not crossed the end of the runway-in-use or has not started a turn ([ICAO-4444] 7.9.1), and:

• The arriving aircraft < T1 from threshold => INFORMATION

• The arriving aircraft < T2 from

Figure 10: Arrival with Departure on Runway


14 Aug 2007

Page 40 of 69

threshold => ALARM If reduced spacing procedures are in force, the previous case shall be adapted as following according to D, the distance between both aircraft:

• Arriving aircraft < T2 from threshold and D > 2500 m => INFORMATION. • Arriving aircraft < T2 from threshold and 2000m < D < 2500 m and departing aircraft

has taken off => INFORMATION. • Arriving aircraft < T2 from threshold and 2000m < D < 2500 m and the departing

aircraft has not yet taken off => ALARM; • Arriving aircraft < T2 from threshold and D < 2000 m => ALARM.

The distances 2000m and 2500 will be implemented as parameterised distances D1 and D2 and will be known as the long and short final distances to the runway threshold.

TWR 2005G160 Mandatory Arrival with Arrival on Runway

If there is a preceding arriving aircraft which has not cleared the runway area ([ICAO-4444] 7.9.1), and:

• The arriving aircraft < T1 from threshold => INFORMATION

• The arriving aircraft < T2 from threshold => ALARM.

Figure 11: Arrival with Arrival on Runway

If reduced spacing procedures are in force the previous case shall be adapted as following according to D, the distance between both aircraft:

• Arriving aircraft < T2 from threshold and D > 2500 m => INFORMATION. • Arriving aircraft < T2 from threshold and D < 2500 m => ALARM.

TWR 2005G170 Mandatory Departure with Mobile on Runway

If a mobile (aircraft or vehicle) is on the runway exclusion area surface and not behind the departing aircraft:

• The departing aircraft is not yet taking-off => INFORMATION.

• The departing aircraft is taking-off => ALARM.

Figure 12: Departure with Mobile on Runway

TWR 2005G180 Mandatory Departure and Multiple Lineups

If multiple line-up is applied, the system shall trigger a ALARM, only if the departing aircraft which is behind has started its take-off and not when it is lining-up. The use of INFORMATION in this case is left to local decision.

Figure 13: Departure and Multiple Lineups


14 Aug 2007

Page 41 of 69

For all departures TSN will use track vector information (heading) to determine if an aircraft is lining-up. TSN will use track vector information (speed) to determine if an aircraft is taking-off. Line-up and take-off clearances will also be used to determine if an aircraft is about to line-up or take-off.

TWR 2005G190 Mandatory Efficient intrusion detection algorithm

The intrusion detection algorithm will ensure its processing does not have a detrimental impact on the overall performance of the system.

TWR 2005G200 Mandatory Intrusion detection during system loading

The intrusion detection algorithm will operate efficiently in periods of obvious system overloading

3.15 DMAN (DEPARTURE MANAGER)

Utilising a PVM (Parallel Virtual Machine) interface the Departure Manager Component (DMAN) shall provide a means of communicating with any external algorithm that also communicates via PVM and supports the planning and optimisation of departure flights. For more information on PVM see Reference 5.

The TWR subsystem will be capable of running without the presence of the DMAN component using the raw flight plan information to derive estimate off block and take off times.

DMAN D10 Mandatory DMAN Dependencies on eDEP TWR

There shall be no TWR dependencies in the ATC ground packages. All method invocations shall be from TWR to GND ATC. As the DMAN component is a package within TWR, it shall also adhere to this rule. The DMAN component shall have no direct dependencies on ATC GND components.

The TWR subsystem shall be capable of running without the presence of the DMAN component.

3.15.1 External Departure Manager Algorithm The external algorithm to be utilised in the Tower system is the Deutches Zentrum für Luft- und Raumfahrt Departure Manager (DLR-DMAN).

The DLR-DMAN algorithm has been developed using complex mathematical functions provided by the MATLAB software package. The algorithm has been designed to produce departure schedules that are optimised to minimise the delays to departing flights, generating:

• Recommended time for push-back/start-up, known as managed off block time (MOBT)

• Recommended time and line-up/take-off, known as managed take off time (MTOT).

• The next recommended clearance (RTUC) for departure flights.

The DMAN component shall provide the Tower Flight Management (TFM) with these recommended/optimised times and clearance.

DMAN D30 Mandatory DMAN connectivity through PVM

The external departure manager algorithm shall be integrated through PVM middleware, interfacing through a Java connector using JNI. At a minimum, the DMAN PVM connector software shall run under Linux, Red Hat 7, and Windows XP operating systems.


14 Aug 2007

Page 42 of 69

3.15.2 Airspace DMAN D40 Mandatory DMAN airspace service requirements

The DMAN component shall load available airspace and airport data into its local database from the TASP component. It shall require the following airspace data to support its flight plans:

• Gates/stands

• Runways

• Runway entry and exit points

• SID for each runway

• STAR for each runway

The DMAN component shall use existing servers within TWR to provide airspace and airport layout information, and a source of flight plan information. Note that the external algorithm must provides its own airspace definition, which must be consistent with the eDEP airspace. The DMAN component shall maintain its airspace independently of the external departure manager algorithm. The DMAN component shall not pass airspace messages to the external algorithm but will provide the flight plan data.

3.15.3 Message Summary The following paragraphs briefly describe the content of the messages exchanged between the DMAN component and the external algorithm. The full details of the message content and syntax are given in Reference 6.

3.15.3.1 Messages To Be Sent DMAN Component:

Description Msgtag Name Keywords

Reset 1 RESET

Time 12 TIME

300 Initial Departure Flight Plan Initial flight plan

301 Initial Arrival Flight Plan

20 UPDATE_STATUS_DEP pending Status.

Note the only keyword used is PENDING which activates processing for that flight.

21 UPDATE_STATUS_ARR pending

Change stand for arrivals 27 UPDATE_FD_ARR stand

Runway entry Change

Note does not change runway.

26 UPDATE_FD_DEP rwy_entry

Runway exit Change

Note does not change runway.

27 UPDATE_FD_ARR rwy_exit

CFMU slot change 26 UPDATE_FD_DEP slot

EOBT Change 26 UPDATE_FD_DEP ert

Estimated Arrival Time 27 UPDATE_FD_ARR eta

40 REMOVE_DEP Delete

41 REMOVE_ARR


14 Aug 2007

Page 43 of 69

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

Clearances

xng not supported.

Note ma (missed approach) clearance not supported for arrivals.

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

24 UPDATE_OP_ST_DEP transfer_control Handover

25 UPDATE_OP_ST_ARR transfer_control

Runway change

Note only for departures.

34 RWY_CHANGE_DEP rwy, sid, rwy_entry, rwy_index

42 TOPOLOGICAL_XY_DEP pos_x, pos_y Topo Basic

Note position will be given as Lat Long and not as an XY.

43 TOPOLOGICAL_XY_ARR pos_x, pos_y

3.15.3.2 Messages To Be Received by the DMAN Component:

Description Msgtag Name Keywords

Initialisation 200 INIT_READY

Status Message 202 ALIVE

Managed take off time 22 UPDATE_DATA_DEP mtot

Managed off block time 22 UPDATE_DATA_DEP mobt

Recommended Time until next clearance (RTUC)

30 TIME_TILL_ CLEARANCE_DEP

urgent, due, normal

3.15.4 Departure Management

DMAN D50 Mandatory DMAN flight plan service requirements

The DMAN component shall generate its departure time estimates from the system flight plans available in the TWR sub-system, provided by the TFM component service. Immediately after the initial flight plan has been sent, the DMAN component shall send a STATUS message to the external algorithm with a pending status, which will activate the flight.

DMAN D60 Mandatory DMAN time service requirements

The DMAN component shall subscribe to the time service provided by the TS component in TWR and send regular time tick updates at a configurable rate using the TIME message to the external departure manager algorithm.

DMAN D70 Mandatory DMAN clearance service requirements


14 Aug 2007

Page 44 of 69

DMAN shall subscribe to clearances given by the tower controller. These clearances shall be forwarded to the external departure manager algorithm; separate messages shall be issued for arrivals and departures.

DMAN D80 Mandatory DMAN connectivity.

The TWR subsystem shall operate with DMAN in DETACHED mode (without a connected external algorithm) and in ATTACHED mode (with a connected external algorithm through PVM). For all client demonstrations, only ATTACHED mode shall be used.

Initially, attached mode shall use the DLR-DMAN algorithm connected via PVM, and detached mode shall offer no DMAN functionality.

DMAN D100 Mandatory DMAN initialisation and reset

A RESET message shall be sent from the DMAN component to initialise the external departure manager algorithm. The DMAN component shall wait for an INIT_READY response to confirm that initialisation has been completed.

DMAN D110 Mandatory Changes to arrival flight plan

The TWR arrival flight plan shall include an initial estimated landing time (ELDT). This value shall be updated from the ABI message sent from the ATC subsystem, which shall contain the estimated time of entry into the airport sector. The ELDT shall be estimated from this value by adding a nominal final approach time.

Subsequent changes to arrival time estimates in the ATC subsystem shall generate additional ABI messages, and update the ELDT.

Any changes made to the flight plan for an arriving aircraft (arrival) shall be reported to through the respective update message. The arriving aircraft shall be monitored within the GND subsystem and report changes in ETA through SYSCO between GND CS and TWR TCS components. DMAN shall support the following changes for arrivals:

• Change estimated arrival time (coordinated through GND-TWR SYSCO)

• Change runway exit point for arrival (TWR function)

• Change arrival stand (TWR function)

DMAN D120 Mandatory Departure flight plan time attributes

The departure flight plan shall include a CFMU departure slot, an estimated off-blocks time (EOBT) and an estimated take-off time (ETOT), determined from EOBT + taxi time.

DMAN D121 Mandatory Changes to departure flight plan

Any changes made to the flight plan for a departing aircraft (departure) shall be reported through the respective update message. The TFM shall report changes to the navigation script through the Navigation event. It shall support the following changes for departures:

• Change CFMU slot for departure (CTOT-5 minutes to CTOT+10 minutes)

• Change calculated take-off time CTOT (derived from CFMU slot)

• Change estimated off-block time (EOBT -> TOBT)


14 Aug 2007

Page 45 of 69

• Change runway entry point for flight departure (TWR function)

• Change runway for flight departure (TWR function)

Initially changing CFMU (and therefore CTOT) and EOBT will not be supported.

DMAN D130 Mandatory Reporting departure clearances

Clearances given to the flight while manoeuvring at the airport, shall be reported to the DMAN component, and passed to the external departure manager algorithm. The clearances shall comprise:

• ENR – en-route: aircraft is ready for departure from gate

• SU – start-up

• SU+PB – start-up and push back

• PB – push back

• TX – start to taxi

• XNG – allow to cross [not supported]

• LU – line-up

• LU+T0 – line-up and take-off

• TO – take-off

• HOLD – hold at a given hold point

• CONT – continue after hold

DMAN D140 Mandatory Reporting arrival clearances

Clearances given to the arriving flight while manoeuvring at the airport, shall be reported to the DMAN component, and passed to the external departure manager algorithm. The clearances shall comprise:

• LDG – aircraft has been cleared for landing

• XNG – allow to cross [not supported]

• TX – start to taxi

• HOLD – hold at a given hold point

• CONT – continue after hold

• ONB – On-blocks

DMAN D160 Mandatory Reporting handover

DMAN shall register interest in handover of control of a flight from one controller to another. Handover given to the arriving flight while manoeuvring at the airport, shall be reported to the DMAN component, and passed to the external departure manager algorithm.

DMAN D170 Mandatory Reporting aircraft progress

DMAN shall register interest in aircraft progress as the flights move around the airport. The resulting track updates from TIAS shall be sent to the external departure manager algorithm in a


14 Aug 2007

Page 46 of 69

TOPOLOGICAL_XY message after conversion from local eDEP Cartesian coordinates (x, y) to Spherical (latitude, longitude) coordinates.

DMAN D180 Mandatory Removing aircraft from simulation

For arriving flights, when the flight is no longer active in the simulation, the DMAN component shall receive notification from the TWR IAS component of the removal of the flight and its track. This shall be forwarded to the external departure manager algorithm in the form of a REMOVE_ARR message.

For departing flights, when the flight is no longer active in the simulation, the DMAN component shall receive notification from the TWR FPM component that the aircraft has taken off. This shall be forwarded to the external departure manager algorithm in the form of a REMOVE_DEP message.

DMAN D190 Enhancement Changing Departure SID

The controller may change the SID for a departing flight. If the new SID identifies a different runway, the runway shall also be changed. Changes to the SID shall be coordinated using a SYSCO protocol, with messages exchanged between the TWR TCS component and the GND CS component, if present.

Changing the SID in TWR shall cause the TWR navigation script to update (for both TPM and TFM in hybrid mode). The GND ATC subsystem, if present, shall recalculate its trajectory through notification from CS of a completed coordination dialogue to change the SID. This will cause its trajectory to update (for both PM and FM in hybrid mode).

Note that at present the Tower system only supports changing the runway for departures. The Tower system does not support explicitly changing the SID other than by changing the runway. Changing the runway implies a change in the SID.

DMAN D200 Enhancement Changing Arrival STAR

The controller may change the STAR for an arriving flight. If the new STAR identifies a different runway, the runway shall also be changed. Changing the STAR from TWR shall be coordinated through SYSCO (TWR TCS will dialogue with GND CS), and shall cause the TWR navigation script to update (for both TPM and TFM in hybrid mode) and notify the GND ATC subsystem of the change, if present, to cause its trajectory to update (for both PM and FM in hybrid mode).

DMAN D210 Mandatory Changing Departure Runway

The controller may change the runway for a departing flight. A new SID shall automatically be selected by using a reference to the first SID defined for the runway. Changing the runway in TWR shall cause the TWR navigation script to update (for both TPM and TFM in hybrid mode) and notify the GND ATC subsystem of the change, if present, to cause its trajectory to update (for both PM and FM in hybrid mode).

DMAN D220 Mandatory DMAN notification of managed times

The DMAN component shall generate Managed Departure messages containing the managed (optimised) times for off blocks (MOBT) and take-off (MTOT).

DMAN D230 Mandatory DMAN notification clearances


14 Aug 2007

Page 47 of 69

The DMAN component shall generate Next Clearance messages containing the type and time of the next clearance.

3.15.5 Multi Platform Requirements

DMAN D400 Enhancement

Not implemented.

UDP Multi-Platform Connection

The multi-platform simulator should comprise of the TWR/eDEP platform offering a UDP connection providing ASTERIX Category 21 messages to the i-acs Tower and Approach HMI, integrated with DLR-DMAN.

DMAN D410 Enhancement

Not implemented.

Provision of ASTERIX Cat21

In the multi-platform environment, TWR/eDEP should serve as a traffic generator, providing ADS-B messages only. The flight plan scenario shall be provided in eDEP format. The TWR pilot manager, TPM shall be capable of providing ADS-B messages for ground movements at the airport.

The eDEP platform generates edition 20 of the Category 21 ASTERIX message. It is understood that i-acs can support any edition of the message.

3.16 DATA PREPARATION [OPTIONAL]

TWR 970 Optional Data Preparation

(optional) Improve the eDEP Traffic editor to allow

• visualisation of airport data

• visualisation of airport map data

• edition of AIFPL data.

• visualisation of computed DNS (Detailed Navigation Script) & trajectory data (available via TWR FDPS)

Note: (d) will be useful for debugging & acceptance testing of DNS computation algorithms.

TWR 2005G20 Mandatory TAAM traffic converter

TAAM traffic samples are to be converted to eDEP TWR format and used within the Tower simulator.

For arrivals the TAAM traffic samples define journeys from originating airport to destination airport using enroute waypoints and STARs, followed by runway and gate to be used at destination airport.

For departures the TAAM traffic samples define the departure gate and runway, SID and following enroute waypoints.

A TAAM Traffic Converter shall convert the traffic samples into ATC flight plans, routes and Tower airport taxi plans which can then be used by the Tower system in standalone mode or if required in connected mode with the ATC system.

Note that for the airports, fixes, SIDs and STARs, only the names will be referenced, it is assumed the actual definitions can be imported from IPAS.

The TAAM Traffic data will be supplied as a Microsoft Excel file containing the following columns:


14 Aug 2007

Page 48 of 69

Column Description

CALLS Aircraft callsign.

TYPE Aircraft type.

MKSeg Not used.

ROUTE_NAME Route name.

RFL Cruising altitude.

DEP_TIME Departure time (off block time).

ARR_time Arrival Time (Touchdown time).

P_RNAV Not used.

ADS Not used.

FLRANGE Not used.

Reg Aircraft registration number.

Dep_Rwy Departure runway.

SID Departure SID.

Arr_Rwy Arrival runway.

STAR Arrival STAR.

GD Departure gate.

GA Arrival gate.

DEP_Apt Departure Airport.

WPOINTi Route waypoint (None, one or many)

DEST_Apt Destination airport.

This information shall be saved as a comma separated variable file for input to the TAAM Traffic converter.

The time, DEP_TIME, shall be used as the off block time for departures. The ARR_TIME shall be used as the touch down time and also used to calculate the activation time when running in connected mode.


14 Aug 2007

Page 49 of 69

4 TOWER AND EDEP ATC INTERFACE REQUIREMENTS

4.1 INTERFACE REQUIREMENTS

Figure 14 Interface between Tower and ATC Systems

TWR G160 Mandatory TWR eDEP ATC flight plan activation

The interface between the TWR simulator and the eDEP ATC system shall require the transfer of flight plan details between TWR and the eDEP ATC. As TIFPL serves both TWR and eDEP ATC systems it shall make the flight plan available to both systems at some arbitrary delta time before activation time. These times may be defined through GSDK resources

TWR G170 Mandatory TWR eDEP ATC aircraft activation

The TWR simulator shall require the activation of an aircraft at touch down. Similarly the eDEP ATC system will require the activation of an aircraft at takeoff. This shall be achieved through the TWR TPM and its eDEP ATC counterpart PM. The interface shall be designed such that the eDEP ATC system has no dependency on TWR.

TWR G180 Mandatory TWR eDEP ATC coordination

The interface between the TWR simulator and the eDEP ATC system shall require the transfer of coordination status between TWR and the eDEP ATC. This shall be achieved through the TWR TCS and its eDEP ATC counterpart CS. The interface shall be designed such that the eDEP ATC system has no dependency on TWR.

To provide TSN with airborne track information TIAS will utilise the IAS service to relay airborne track information. As this relationship is only one way the eDEP ATC system has no dependency on TWR.

4.2 APPROACH ENROUTE ENHANCEMENTS

TWR 610 Optional Approach autoland change SID/STAR

[optional] Possible improvements to the eDEP ATC simulator (APP/En-route) include

• Change SID/STAR (also change runway)

• AutoLand (capture localizer/ILS/glide slope)


14 Aug 2007

Page 50 of 69

Other possible improvements could involve a ‘Go around command’ for aircraft, to simulate overshoot of airport and to retry and land.

4.3 APPROACH ENROUTE CONSIDERATIONS

TWR 620 Mandatory Approach airport single sector.

From an ATC viewpoint, the airport (TWR & GRD movement) shall be seen as a single ATC sector.

TWR 630 Mandatory Approach coordination between airport and APP sector

Hence, from a co-ordination viewpoint :

• Arrivals : ACT messages are sent from the last APP sector to airport (hence to all Airport CWP positions)

• Departures : ACT messages are sent from the Airport system to the first APP sector

ACT messages shall be simulated using the eDEP ANNOUNCED co-ordination messsage. Coordination shall be achieved and simulated through TWR TCS and eDEP ATC CS.

DMAN D90 Mandatory DMAN flight arrival notification

Arriving flights shall be notified to the TWR subsystem through the SYSCO interface from the ATC GND subsystem.

ATC GND shall signal an Advanced Boundary Information message (ABI) typically 30 minutes prior to airport sector entry. The ABI message shall contain the same details as the activation message (ACT), typically received 10 minutes prior to sector entry, including the entry time. The ABI and ACT notification interval prior to sector entry shall be configurable through resource parameters.

The estimated landing time ELDT shall be derived from the ABI/ACT entry times, by adding the time interval between airport sector entry (threshold) and touch down, typically 2 minutes. This figure shall be configurable using a resource parameter. Similarly, the estimated time in blocks (EIBT) shall be derived from the ELDT plus the taxi time to the stand.

TWR 640 Mandatory Approach coordination handover.

Hence, from a hand-over point of view:

• Arrivals : are handed over during final approach, approx. 7n.miles from runway

• Departure : are handed over once airborne (Note: Some countries handover once the a/c is correlated on the APP radar.)

Arrivals are handed over during final approach. The distance from the runway shall be determined by sector size and controller interaction.

TWR 650 Mandatory Approach dual mode.

The Ground movement simulation can operate in one of two modes :

• Standalone mode

• Integrated mode (i.e. approach / en-route system present)


14 Aug 2007

Page 51 of 69

The TWR system shall be able to operate in stand-alone mode or in integrated mode with the eDEP ATC system. To maintain backwards compatibility the eDEP system will be able to operate in standalone mode.

TWR 660 Mandatory Approach standalone mode.

In standalone mode :

• arrivals shall automatically land on the runway at the defined ‘AIFPL.ETA time

• Departures shall leave the system after takeoff + ‘delta’ time.

Arrivals shall land at the specified activation time and Departures leave the system at takeoff. The associated flight plan will enter the system at a system-defined time before the activation time.

When the Tower system runs in standalone mode (i.e. without the eDEP ATC system) airborne aircraft shall be removed from the Airport View while an arrival will appear on the Airport View when the arrival has touched down.

TWR 670 Mandatory Approach integrated mode.

In integrated mode:

• Arrivals shall enter the TWR simulator once the Approach system informs the a/c has landed.

• Departures shall enter the APP system once the TWR simulator informs the a/c has taken-off

In integrated mode arrivals shall enter the eDEP ATC system at activation time while the flight plan enters the eDEP ATC and the TWR systems at a system-defined time before the activation time. The aircraft shall enter the TWR system when signalled by the eDEP ATC system.

Departures shall enter the TWR system at activation while the associated flight plan enters the TWR and the eDEP ATC systems at a system-defined time before the activation time. The departure shall enter the eDEP ATC system when activated by the TWR system.

When the Tower system runs in integrated mode (i.e. with the eDEP ATC system) airborne aircraft shall remain on the Airport view while in close proximity to the airport. Once a departure is airborne it shall appear on the Approach View. Once an arrival has touched down it shall be removed from the Approach View.

TWR 680 Mandatory Approach departure minimum altitude detection.

Departures shall be detected by the APP IAS (Radar) once the aircraft has attained a minimum altitude (parameter).

The initial altitude of a departure flight shall be the altitude of the airport. Information on the APP view shall be sourced from the eDEP ATC system and only available when the eDEP ATC system is running.

DMAN D20 Mandatory Departure Flight Plan Updates

Changes to departure flight plans shall be made only through TWR menus and the changes shall be coordinated with the GND ATC subsystem through SYSCO protocols. The TWR FM (TFM) and GND FM shall synchronise changes to their respective flight plan information via the TWR and GND coordination servers (TCS and CS respectively).


14 Aug 2007

Page 52 of 69

5 GRAPHICAL REQUIREMENTS

5.1 VIEWS

5.1.1 Airport Views The airport situation view, or Airport View Display (AVD), shall be implemented using a standard AWS Panel, with the terminal buildings, aprons, taxiways and runways displayed as simple AWS polygon objects. The display will locate the aircraft using GSDK AWS widgets to indicate the latest reported position, and an associated AWS label data block that holds callsign and status information.

Typical formats of arrival and departure aircraft and ground vehicle labels are outlined below demonstrating labels extending when selected:

Standard Extended

Arrival: Callsign

Stand

Callsign Type/WV

Stand

Departure: Callsign

Runway

Callsign Type/WV

Runway CTOT

Vehicle: Callsign

Callsign

The background can be defined opaque (default) or transparent and coloured to differentiate between arrivals, departures and vehicles.

The label text canbe coloured according to coordination jurisdiction i.e. advance, assumed, concerned, not-concerned.

Fields within the label can be made sensitive, for example:

Field Content Sensitivity

Callsign Derived from flight plan. Fixed value. Sensitive and invokes the Callsign Menu.

Type/WV Type is aircraft type derived from flight plan.

WV is the wake vortex derived from the flight plan. The WV can be Light (L), Small(S), Medium(M) or Heavy(H).

Type and WV are fixed values.

Insensitive.

Stand Stand is initially derived from Tower flight plan. Sensitive and invokes the Stand Menu, which may change the value.

Runway Initially derived from Tower flight plan. Sensitive and invokes the Runway Menu, which may change the value.

CTOT CTOT is derived from the CTOT field in the ATC flight plan.

Insensitive.


14 Aug 2007

Page 53 of 69

At present a fixed value.

TWR 2005G10 Mandatory Symbol implies orientation

Aircraft and vehicle symbols will be drawn to imply orientation.

TWR 2005APT100 Mandatory Symbol implies size

The Tower aircraft symbology shall be representative of the aircraft wake vortex category.

This will clarify the situation when an aircraft performs a pushback. When performing a pushback the aircraft travels in reverse with the symbol orientated in the opposite direction to the movement of the aircraft.

Aircraft and vehicle symbols will be drawn and displayed to represent shape and size of the aircraft/vehicle. The implementation will allow different shapes to be tailored and substituted.

The lists of arriving and departing aircraft shall be maintained using tailored implementations of existing GSDK AWS list widgets that are currently used in the sector inbound list and message windows of the eDEP EATMP CWP. The arrival and the departure traffic lists will show a column of aircraft details organised into sections defined by current aircraft status. The information contained in the list entry will identify the aircraft callsign and type and the expected times of the key events.

5.1.1.1 Arrival / Departure Flight Strip Lists

The Arrival / Departure Lists display flight strip information concerning aircraft planned to arrive / depart from an airport and will be based upon the existing GSDK (AWS list widgets).

The lists are divided into several sections each representing the progression of an arriving / departing flight, e.g. start, pushback, taxi, lineup and takeoff.

Although the Operator roles imply the sections to be displayed the user is not limited to the sets shown below but can include and merge sections.

Figure 15 : Runway Controller List

Figure 16 : Apron Controller List


14 Aug 2007

Page 54 of 69

5.1.1.2 Clearance Delivery List Window

The clearance delivery list window will be a stylised Departure list displaying the CLD section of the list and any other sections that are deemed of interest.

Figure 17 : Clearance Delivery List

DMAN D300 Mandatory Clearance Delivery Window

The system shall provide a CWP dedicated to Clearance Delivery. This CWP shall display a Clearance Delivery Window, holding a list of active departure flight plans that have yet to start.

Initially a departure will be displayed in the Clearance Delivery Window (CLD), after the IFPL has been received, but before the flight receives its first clearance. The CD CWP shall not make any amendments to the flight plan. Once the flight is deemed ‘ready’, the CD controller shall handover control of the flight to the apron controller.

The initial clearance is provided by the Clearance Delivery message. This message activates the flight plan, and indicates an expected ready time, ERT. ERT is assumed to represent the same time as EOBT. Note that the initial state change for clearance delivery is made a configurable time before EOBT, typically 3-5 minutes. The flight goes into an initial en-route, ENR, state. The following time line shows the order of the initial events:

Table 5-1: Activation and Clearance Delivery Timeline

DMAN D310 Enhancement CDW Update Off Blocks Time

The Clearance Delivery Window shall provide a menu to change the initial EOBT value, creating a target off blocks time, TOBT. Changing this value shall generate a change EOBT order, which shall update the navigation script and the recalculation of clearance events.

5.1.1.3 Tools

Each Airport View display shall have a set of display tools and functions. These shall include

• Elastic vector to resize and zoom in on viewing area.

• Drag and re-centre viewing area.

• Toolbox.

Activate IFPL

DMAN next clearance

CD

t0

ERT/EOBT

3-5 minutes Actual CD

5-7 minutes ENR state… SU/PB/SU+PB state…


14 Aug 2007

Page 55 of 69

The toolbox shall be resource configurable to allow it to be fixed to the display top border (Similar to Windows File decoration) or to be independent and moved around the display. The independent toolbox will have the typical format:

MAP LABEL ARR DEP ZOOM HH:MM

Figure 18 : AVD Toolbox

The Toolbox window shall allow the controller quick access to frequently used display functions. These shall include map, label and zoom functions.

Selecting MAP, LABEL, ARR, DEP or ZOOM shall display the associated tools. Re-selecting the button shall hide the associated tools.

The Map tools shall provide tick boxes to filter on/off the map layers.

The Label tools shall provide tick boxes to filter on/off the fields in track labels.

The ARR tools shall provide tick boxes to filter on/off the fields in arrival list.

The DEP tools shall provide tick boxes to filter on/off the fields in departure list.

The Zoom tools shall provide a slider bar to zoom in and zoom out. It will also allow centring and resetting the zoom attributes.

The last field in the toolbox displays the time but shall also allow the controller to drag and reposition the toolbox.

5.1.2 Approach Radar Views The approach radar view (APP) will be provided by the existing eDEP CWP Radar display.

5.2 MENUS

5.2.1 Callsign The Callsign menu shall be invoked by single click Action Button (AB) on the callsign field in the Arrival, Departure Lists or in aircraft’s label.

The Callsign menu shall typically contain the following options.

Callsign

C/S

ASSUME

TRANSFER

TAXI

HOLD

LINEUP

TAKEOFF

STARTUP

PUSHBACK

MARK

ABORT

CANCEL

If coordination state is advance + transferred then default position on opening menu will be at Assume.

Otherwise the next clearance required will be the default position.

For departures this will follow the order of Startup, Pushback, Taxi, Lineup, Takeoff, Abort.

For arrivals this will follow the order Taxi, Hold.

Note the CANCEL option closes the menu with no action being taken.


14 Aug 2007

Page 56 of 69

Figure 19 Callsign Menu

Only options available for action will be displayed. This depends on the state of the flight i.e.

• The flight plan state

• The control state

• Arriving or departing flight.

Field Displayed Selection

Assume Shown when coordination jurisdiction is advance + transfer for this controller.

Selection changes state to assumed by this controller.

Transfer Shown when coordination jurisdiction is assumed for this controller.

Selection changes state to concerned by this controller.

Taxi Shown when taxi clearance required. Selection gives taxi clearance.

(Also gives startup clearance if not already given)

Hold Shown when track is moving. Selection requests stop.

Lineup Shown for departures that will pass through a lineup point but lineup clearance has not been given.

Selection gives lineup clearance.

Takeoff Shown for departures but takeoff clearance has not been given.

Selection gives takeoff clearance.

(Also gives lineup clearance if not already given)

Startup Shown for departures that have not been given startup clearance.

Selection gives startup clearance.

Pushback Shown for departures requiring pushback but have not been given pushback clearance.

Selection gives pushback clearance.

(Also gives startup clearance if not already given)

Mark Same as described for arrival and departure list T. Same as described for arrival and departure list T.

Abort Shown when takeoff clearance has been given. Selection rescinds takeoff clearance and TOT field becomes a target TOT.

When in hybrid mode also stops aircraft.

Cancel Always displayed Cancels menu.

Selecting any option in the Callsign menu (other than Mark and Cancel) for flights in Advance + Transfer coordination state shall cause an implicit assume.

5.2.2 Runway The runway (RWY) menu shall be invoked by single click Action Button (AB) on the Runway field in the Departure/Arrival list to change the aircraft’s runway. A change of runway will initiate a recalculation the navigation script.


14 Aug 2007

Page 57 of 69

The menu header shall contain the name “RWY” and the subject aircraft callsign. Below the header the menu displays the runways available at the airport. If the aircraft is departing only departure runways that are open will be displayed. Similarly for arrivals, when invoked the current value will be set as the default.

Callsign

RUNWAY

01L

.

.

27R

Cancel

On opening the menu the default position will be centred on the current runway selected.

Note the CANCEL option closes the menu with no action being taken.

Figure 20 : Runway Menu

5.2.3 Stand The Stand menu shall be invoked by single click Action Button (AB) on the Stand field in the Arrival list to change the associated stand for the aircraft.

The Stand menu shall contain a header with the name “STAND” and the subject aircraft callsign. Below the header the menu will display up to 10 stand numbers in descending order from the top with scrolling areas above and below the list of numbers. When invoked the current value will be set as the default.

Callsign

STAND

A1

.

.

.

A9

On opening the menu the default position will be centred on the current stand selected.

Figure 21 : Stand Menu


14 Aug 2007

Page 58 of 69

6 ARRIVAL AND DEPARTUES

The following section contains implementation notes for aircraft arrivals and departures at an airport. The section starts by describing the data definitions necessary to support the implementation, followed by the test cases and algorithms to follow.

6.1 RUNWAY PERIMETER

RunwayPerimeters will be defined by the following attributes:

a. StartThreshold. Two points defining the start of the runway strip. These points can be obtained from the TAAM data.

b. EndThreshold. Two points defining the end of the runway strip. These points can be obtained from the TAAM data.

c. TouchDownDistance. The distance from the StartThreshold defining the touchdown point for all aircraft using the runway.

d. A set of lineup points. e. A set of points defining the connection of taxiways to the runway centrelines.

Below is an example RunwayPerimeter command:

RUNWAYPERIMETER R27_BOUNDARY FOR_RUNWAY R27 COMPRISING START_THRESHOLD 49.0269632 2.5616519 49.0264257 2.5617247 END_THRESHOLD 49.0243095 2.5248363 49.024847 2.5247645 TOUCH_DOWN_DISTANCE 50 LINEUP_POINTS H1 H2 END ENTRY_TO_RUNWAY_AT E1 E2 E3 E4 END EXIT_TO_RUNWAY_AT E1 E2 E3 E4 END END

Below is an example runway, R09 (heading of 090) containing:

a. Four entry exit points E1, E2, E3, E4. b. Two lineup points H1, H2. c. Start Threshold. d. End Threshold. e. Other taxipoints P1, . . ,P8

The connectivity of these points is defined using the Taxiway and TaxiwaySegment commands (Note the use of the points P1..P8 are used only to approximate a curved path).


14 Aug 2007

Page 59 of 69

6.2 AIRCRAFT AND TAXIWAY SEGMENT SPEEDS

Each taxiway segment has an associated maximum taxi speed for aircraft and vehicles travelling along that segment (segment taxispeed).

Each aircraft has an associated (TACR) performance specifying general acceleration, deceleration rates and takeoff, touchdown and taxi speeds (performance taxispeed).

When travelling along a taxiway segment an aircraft will travel at the minimum of these two speeds.

Each Tower aircraft will have either an AirportArrival or AirportDeparture specifying routes about the airport. These routes have an initial optional taxispeed and further optional taxispeeds when heading towards taxipoints (flight plan taxispeed).

When an AirportArrival or AirportDeparture flight plan specifies a taxispeed this will have precedence over the segment taxispeed and the performance taxispeed.

When an aircraft lands at a runway it will decelerate towards its nominated taxispeed.

The exception to this rule is when an aircraft is allowed to exit fast from a runway. See later section on arrivals.

6.3 GATE TO RUNWAY DEPARTURES

When only the Gate and Runway have been defined in the Tower AirportDeparture route, the DNS calculates the taxi route from the Gate to the entry/exit point furthest away from the EndThreshold (as illustrated below):


14 Aug 2007

Page 60 of 69

The aircraft will then taxi to the entry/exit point, line-up and accelerate down the runway towards the EndThreshold.

If the aircraft can not reach its takeoff speed before the EndThreshold, the aircraft will still take-off but a warning will be raised (by TPM) on reaching the EndThreshold.

6.4 GATE TO RUNWAY VIA INTERMEDIATE POINTS

The Tower AirportDeparture route can be supplemented with intermediate points between the Gate and the Runway.

Assuming the last intermediate point is not an entry/exit point, the DNS will calculate the shortest route encompassing the intermediate points to the runway, where the entry/exit point to be used for line-up and take-off will be the one nearest the last intermediate point. The DNS will disregard the distance needed to reach takeoff speed when calculating an entry/exit point.

When the last intermediate point in a Tower AirportDeparture is an entry/exit point, the DNS will calculate the shortest route to the specified entry/exit point.

In both the above cases aircraft will taxi to the entry/exit point, line-up and accelerate towards the EndThreshold and when reaching take off speed will be assumed airborne and removed from the Tower AVD.

If the aircraft can not reach its takeoff speed before the EndThreshold a warning will be raised (by TPM) on reaching the EndThreshold, although the aircraft will still take-off

In the example below the AirportDeparture contains E2 as the last intermediate point.


14 Aug 2007

Page 61 of 69

6.5 RUNWAY TO GATE ARRIVALS

Aircraft will touch down on the runway at TouchDownDistance from the StartThreshold and decelerate to either its nominated taxispeed or to an exit speed (default) equivalent to a connecting exit taxiway segment (i.e. a fast runway exit). When decelerating to an exit speed the deceleration will be such that the speed will be reached at the exit point.

When only the Runway and Gate have been defined in the Tower AirportArrival route, the DNS will calculate the first exit point to be encountered on the runway, which the aircraft can decelerate to the exit speed and also still find a route to its stand. If no such exit point exists then the exit point furthest from the StartThreshold will be used.

If the aircraft can not attain its exit taxispeed before the exit point a warning will be raised (by TPM) on reaching the exit point. Although the aircraft will still exit the runway at this point and continue to decelerate.

In the example diagram below the aircraft can not decelerate to the exit speed at E3 but can decelerate to the exit speed at E4.

6.6 RUNWAY TO GATE VIA INTERMEDIATE POINTS

The Tower AirportArrival route can be supplemented with intermediate points between the Runway and the Gate.

Assuming the first point is not an exit point, the DNS will calculate the shortest route encompassing the intermediate points to the Stand, where the start of the taxiroute will be the first exit point on the runway where the aircraft has attained its exit taxispeed. If no such exit point exists then the exit point furthest from the StartThreshold will be used.

When the first point is an exit point, the DNS will calculate the shortest route encompassing the intermediate points to the Stand from the exit point.

Aircraft will touch down on the runway at TouchDownDistance from the StartThreshold and decelerate towards the exit point.

If the aircraft can not attain its exit taxispeed before the exit point a warning will be raised (by TPM) on reaching the exit point, although the aircraft will still leave the runway at this point and continue to decelerate to the max speed allowed for the taxiway segment.

Given the same kinematics i.e. deceleration rate as in the previous diagram but with the aircraft being instructed to leave the runway at E3, the following diagram illustrates the aircraft decelerating to the exit point E3, leaving the runway at E3 and then continuing to decelerate along the taxiway segment.


14 Aug 2007

Page 62 of 69


14 Aug 2007

Page 63 of 69

7 TRAFFIC RULES

The following section contains implementation notes on traffic rules at an airport. The section starts by describing the data definitions necessary to support the implementation, followed by test cases and algorithms to be employed.

The following test cases do not describe all traffic situations that may arise but highlight the more pertinent cases implied by requirements 290, 310, 320, 330 and 340.

7.1 TERMINOLOGY

Taxipoints

A, B, C, D and E are all taxipoints.

Junctions

Junctions are taxipoints where there is a choice of three or more paths to take.

C is a junction.

Cul-De-Sacs

A cul-de-sac is a taxipoint where there is only one path from it.

A, D and E are cul-de-sacs.

7.2 TRAFFIC PARAMETERS

The following performance and Resource defined parameters will be used when assessing the traffic situation:

• QueuingDistance (TACR performance) Distance to be maintained when encountering slower or stationary traffic. The total queuing distance for an aircraft/vehicle includes the radius of both the following and the followed aircraft/vehicle, to prevent symbol overlap.

• JunctionCongestionRadius If an aircraft/vehicle is within this radius then the junction is assumed to be occupied. The total junction congestion radius includes the radius of the vehicle checking the junction, to prevent symbol overlap. Note JunctionCongestionRadius should be less than any QueuingDistance

• DecisionDistance (QueuingDistance + JunctionCongestionRadius)


14 Aug 2007

Page 64 of 69

Distance to next junction within which decision is made to give way to other traffic or to continue on prescribed route.

• CrossingTimeFactor (Resource) When deciding to cross a junction the speed of other traffic travelling toward that junction is considered. For example, given X and Y are both arrivals and X will take Tx to reach the junction and Y will take Ty then X will give way to Y if:

Tx * CrossingTimeFactor > Ty


14 Aug 2007

Page 65 of 69

7.3 ON-COMING TRAFFIC MORE THAN ONE JUNCTION AWAY

X is a vehicle travelling A, B, C to D.

Y is an aircraft travelling F, C, B to E.

X approaches within the DecisionDistance of B before Y gets to C.

As no on-coming traffic travelling C to B, X enters the segment BC.

Y approaches within the DecisionDistance of C.

As X is on-coming Y waits until X travels past C towards D before proceeding.

In the above case a vehicle and aircraft were used to highlight the fact that although vehicles give way to aircraft they only look ahead to the next junction.

Note 1: When looking for on-coming traffic only the segments adjoining the next junction are checked.

7.4 TRAFFIC APPROACHING SAME JUNCTION BUT LEAVING ON DIFFERENT PATHS

X is travelling A, B to C.

Y is travelling E, B to D.


14 Aug 2007

Page 66 of 69

X approaches within the DecisionDistance of B and assess the traffic situation.

The time for X to reach B is Xt. The time for Y to reach B is Yt.

Using Resource CrossingSpeedFactor (CSF) then X continues if Xt*CSF<Yt

The above is regardless of X and Y being aircraft or vehicles.

But if Xt*CSF>Yt then the table below details if X gives way to Y

X Y Arrival Departure Vehicle

Arrival Givesway (to right) Givesway No

Departure No Givesway (to right) No

Vehicle Givesway Givesway Givesway (to right)

Similarly when Y approaches within the DecisionDistance of B and Yt*CSF>Xt then the table below details if Y gives way to X.

X Y Arrival Departure Vehicle

Arrival No (to right) No Givesway

Departure Givesway No (to right) Givesway

Vehicle No No No (to right)

Note corresponding entries in the two above tables have opposite values implying there will be no “traffic jam” at junction.

7.5 TRAFFIC APPROACHING THE SAME JUNCTION LEAVING ON SAME PATH

X is travelling A, B to C.

Y is travelling E, B to C.

The decisions to give way at junction B are the same to the previous section regardless of the speeds of X and Y between B and C.


14 Aug 2007

Page 67 of 69

Note 2: The decision to give way at a junction is regardless of the speeds of traffic after the junction.

7.6 FAST AND SLOW TRAFFIC LEAVING ON DIFFERENT PATHS

X travels A to B to C.

Y travels A to B to D.

X travels faster than Y.

Between A and B, X catches up with Y and slows down to Y’s speed and remains behind Y at QueuingDistance.

After B, Y turns towards D.

To prevent faster traffic clipping slower traffic when junction turn is small, X will now continue at the slower speed if the distance to B is less than (QueuingDistance + Distance travelled at the slower speed in one update). On reaching B, X continues to C at its own speed.

Note 3: To prevent faster traffic “clipping” slower traffic when junction turn is small, following traffic will continue at the slower speed for a time determined by the JunctionCongestionRadius.

(Similar “clipping” problem may occur when traffic waits just before a junction allowing other traffic to pass the junction.)


14 Aug 2007

Page 68 of 69

8 DNS ROUTE FINDING

8.1 INTRODUCTION

This section details the specific requirements for the DNS route finding search.

8.2 INPUT/OUTPUT SPECIFICATION

The DNS shall accept a TowerConstraintList object as the primary specification of a search. This comprises a list of constraints, each one specifying a geographical entity. These entities may be Gates, Taxipoints, or Runways. Associated with each point is either a requirement for the plan to pass through this point, or to avoid this point. In addition, there are optional requirements for an aircraft to pause at this point, and for an aircraft to leave this point at a specific speed.

The DNS shall return a NavigationScript object, which lists every single taxipoint traversed by an aircraft on the journey (as such, the taxipoints on any two adjacent script steps will be separated by an atomic journey). Associated with each step shall also be the total time taken to reach this step, the speed leaving this step and (if applicable) the delay at this point (this delay will be added on to the cumulative time, starting at the next step).

8.3 ROUTE FINDING CRITERIA

By default, the DNS shall search by time (i.e. return the fastest valid route). In this case, it shall take taxiway speed limit restrictions, as well as any delays on the taxipoints. It shall be possible to constrain the DNS to search by distance (ie return the shortest valid route). The constraints for a valid route are:

a) Only travel by taxiways specified in the Airspace.

b) If a taxiway has a direction constraint, arrival/departure only marker, or weight limit, the aircraft will honour it.

c) If there is a negative constraint (NOT_VIA point) between two positive constraints (VIA point), the journey segment between the two positive constraints must avoid via the negative constraint. (Note: the negative constraint only applies for this segment of the journey).

d) Unless required by a dead-end, there must not be any U-turns; the pattern <Point A> - <Point B> - <Point A> must be avoided. If, however, adherence to this would produce a null route, this criteria shall be relaxed.

8.4 SPEED CALCULATION

An aircraft will always be assumed to travel at the maximum speed possible. This speed is defined as the lesser of the taxiway speed limit and the performance speed, unless a ‘flight plan’ speed is specified which then takes precedence Note arrivals leaving the runway will decelerate to this “maximum” speed i.e. fast runway exit. Taxiway speed limits are defined for each taxiway. The flight plan speed limit is equal to the most recent speed limit specified in the flight plan, i.e. the first member of the following list:

i) The most recent speed constraint on a taxipoint.

ii) The default Flight plan speed.

8.5 RUNWAY ENTRY/EXIT POINT

Where a constraint point for the DNS is a runway, the DNS must calculate the optimal taxipoint to enter or exit the runway. This point must be one point listed as a Runway join point (in the airspace


14 Aug 2007

Page 69 of 69

definition). The rules for calculation runway entry/exit point are specified in section 6, “Arrivals and Departures”, this section is to supplement these rules.

i) The calculation for runway entry/exit point must not interact with negative constraints. In cases where there is a NOT_VIA constraint adjacent to the runway constraint, it must be ignored for this calculation.

ii) The DNS must ensure that its calculation of the runway entry/exit point does not result in a null route. If the optimal choice for runway entry/exit point would prevent a complete route from being found, the next-best choice must be examined.

Date post:	13-Apr-2018
Category:	Documents
Upload:	lybao
View:	218 times
Download:	2 times

Development and Evaluation Platform Software Requirements ... · Development and Evaluation...

Documents