emma2.dlr.deemma2.dlr.de/maindoc/2-D631_PRG-TR_V1.0.pdf · EUROPEAN AIRPORT MOVEMENT MANAGEMENT BY A-SMGCS, Part 2 Contract No. TREN/04/FP6AE/S07.45797/513522 Project Funded by European

EUROPEAN AIRPORT MOVEMENT MANAGEMENT BY A-SMGCS, Part 2 Contract No. TREN/04/FP6AE/S07.45797/513522

Project Funded by European Commission, DG TREN The Sixth Framework Programme Strengthening the competitiveness

Contract No. TREN/04/FP6AE/S07.45797/513522

Project Manager M. Röder

Deutsches Zentrum für Luft und Raumfahrt Lilienthalplatz 7, D-38108 Braunschweig, Germany

Phone: +49 (0) 531 295 3026, Fax: +49 (0) 531 295 2180 email: [email protected]

Web page: http://www.dlr.de/emma2

© 2010, - All rights reserved - EMMA Project Partners The reproduction, distribution and utilization of this document as well as the communication of its contents to other without explicit authorization is prohibited. This document and the information contained herein is the property of Deutsches Zentrum für Luft- und Raumfahrt and the EMMA project partners. Offenders will be held liable for the payment of damages. All rights reserved in the event of the grant of a patent, utility model or design. The results and findings described in this document have been elaborated under a contract awarded by the European Commission.

Prague - A-SMGCS Test Report

J. Jakobi

DLR

Document No: 2-D6.3.1 Version No. 1.0

Classification: Public Number of pages: 143

EMMA2


Save date: 2010-01-05 Public Page 2 File Name: 2-D631_PRG-TR_V1.0.doc Version: 1.0

Distribution List

Member Type No. Name POC Distributed

Internet http://www.dlr.de/emma2 Web

Intranet https://extsites.dlr.de/fl/emma X 1 DLR Marcus Biella X 2 AENA Giulio Maira X 3 AIF Marianne Moller X 4 SELEX Giuliano D'Auria X 5 ANS_CR Jan Kubicek X 8 DSNA Philippe Montebello X 9 ENAV Antonio Nuzzo X 10 NLR Jürgen Teutsch X 11 PAS Alan Gilbert X 12 TATM Corinne Heinrich X 13 THAV Marc Fabreguettes X 15 AUEB Konstantinos G. Zografos X 16 Airport Prague Libor Kurzweil X 17 DAS Benno Petersen X 18 DFS Klaus-Ruediger Täglich X 19 EEC Stéphane Dubuisson X 20 ERA Jan Hrabanek X 21 FAV Thomas Wittig X 23 SICTA Mariacarmela Supino X 24 TUD Carole Urvoy X

Contractor

25 EGIS Lionel Bernard-Peyre X CSA Karel Muendel X

Sub-Contractor Körte Max Körte X

Customer EC Doris Schroecker

Additional EUROCONTROL Bengt Collin

EMMA2



Document Control Sheet 2-SP6 Project Manager Marcus Biella Responsible Author J. Jakobi DLR

Marcus Biella DLR

Additional Authors

Subject / Title of Document: Prague - A-SMGCS Test Report Related Task('s): 2-WP6.3 Deliverable No. 2-D6.3.1 Save Date of File: 2010-01-05 Document Version: 1.0 Reference / File Name 2-D631_PRG-TR_V1.0.doc Number of Pages 143 Dissemination Level Public Target Dates to be sent to WP partners: 2008-12-05

to be sent to GA: 2008-12-12 report to be sent to EC: 2008-12-19

Change Control List (Change Log)

Date Release Changed Items/Chapters Comment 2006-07-24 0.01 Initial skeleton 2008-09-26 0.02 Initial draft Including RTS1 & RTS2a results 2008-12-10 0.02_19 Incorporation of OST results §3 Initial draft to WP Partner 2008-12-12 0.03 §5 Conclusions Final draft to GA 2008-12-19 0.04 GA comments processed

§1 Executive summery included Final draft for EC approval

2010-01-05 1.0 No EC comments. Approved Final Version 1.0

EMMA2



Table of Contents Distribution List ...................................................................................................................................... 2 Document Control Sheet ......................................................................................................................... 3 Change Control List (Change Log) ......................................................................................................... 3 Table of Contents .................................................................................................................................... 4 1 Executive Summery ............................................................................................................................. 6 2 Introduction .......................................................................................................................................... 7

2.1 Scope of Document ....................................................................................................................... 7 2.2 Validation Approach ..................................................................................................................... 7 2.3 Schedule of 2-WP6.3 Activities .................................................................................................... 8

3 Real Time Simulation Results .............................................................................................................. 9 3.1 Set Up............................................................................................................................................ 9

3.1.1 The validation platform .......................................................................................................... 9 3.1.2 Experimental Design ............................................................................................................ 10 3.1.3 Traffic Scenarios .................................................................................................................. 11 3.1.4 Participants ........................................................................................................................... 14 3.1.5 Schedule of Executed Test Runs .......................................................................................... 15 3.1.6 Metrics and Indicators .......................................................................................................... 17

3.2 Results to Operational Feasibility (RTS) .................................................................................... 21 3.2.1 Operational Feasibility Questionnaire (QE-OF)................................................................... 21 3.2.2 Debriefing Comments .......................................................................................................... 34

3.3 Results to Operational Improvements (RTS) .............................................................................. 44 3.3.1 Punctuality of Departing Flights (LLO_3.1) ........................................................................ 46 3.3.2 Stop Time during Taxiing (LLO_3.2) .................................................................................. 47 3.3.3 Taxi Time (LLO_3.3)........................................................................................................... 49 3.3.4 Throughput (LLO_3.4)......................................................................................................... 50 3.3.5 Queue Length [LLO_3.5]..................................................................................................... 50 3.3.6 R/T communication [LLO_3.7]............................................................................................ 51 3.3.7 Workload [LLO4.1].............................................................................................................. 51 3.3.8 Situation Awareness [LLO4.2]............................................................................................. 53 3.3.9 Operational Improvement Questionnaire (QE-OI)............................................................... 54

4 Operational Field Trials Results......................................................................................................... 58 4.1 Set Up.......................................................................................................................................... 58

4.1.1 The validation platform ........................................................................................................ 58 4.1.2 Experimental Design ............................................................................................................ 59 4.1.3 Traffic Scenarios .................................................................................................................. 60 4.1.4 Participants ........................................................................................................................... 61 4.1.5 Schedule of Executed Test Runs .......................................................................................... 61 4.1.6 Metrics and Indicators .......................................................................................................... 62

4.2 Results to Operational Feasibility (OST) .................................................................................... 62 4.2.1 Traffic Situation Display (TSD)........................................................................................... 63 4.2.2 Electronic Flight Strips (EFS) .............................................................................................. 63 4.2.3 Routing ................................................................................................................................. 63 4.2.4 Departure Management ........................................................................................................ 64 4.2.5 TAXI-CPDLC ...................................................................................................................... 64 4.2.6 Alerts .................................................................................................................................... 66

5 Conclusions ........................................................................................................................................ 67 5.1 Conclusions to the new A-SMGCS services ............................................................................... 67 5.2 Conclusions to Operational Improvements ................................................................................. 70

6 Annex I............................................................................................................................................... 72 6.1 References ................................................................................................................................... 72 6.2 Abbreviations .............................................................................................................................. 73 6.3 List of Figures ............................................................................................................................. 76

EMMA2



6.4 List of Tables............................................................................................................................... 76 7 Annex II.............................................................................................................................................. 78

7.1 Decision on EMMA2 Operational Requirements (Checklist)..................................................... 78 7.2 Flight Plans of the Traffic Scenarios EXE02 and EXE04......................................................... 137 7.3 Raw Data of RTS1 .................................................................................................................... 139

7.3.1 QE-QF ................................................................................................................................ 139 7.3.2 QE-OI ................................................................................................................................. 140 7.3.3 Workload ............................................................................................................................ 141 7.3.4 Situation Awareness ........................................................................................................... 141 7.3.5 System Usability Scale (SUS) ............................................................................................ 141

7.4 Raw Data of RTS2 + OST......................................................................................................... 141

EMMA2



1 Executive Summery This document reports the results of the validation activities carried out in EMMA2 WP6.3, A-SMGCS validation at the test site Prague. There were three test campaigns: real time simulation phase 1 (RTS1) in 2007 and RTS2 in 2008 at DLR premises, and the onsite trials at Airport Prague in November 2008. During the Prague validation trials a complete A-SMGCS was implemented and under evaluation. Following A-SMGCS services were operated by seven ANS CR controllers:

• Traffic situation display (TSD) • Runway incursion alerting (surveillance based alerting) • Electronic Flight Strips (EFS) • Departure Management Planning (DMAN) • Routing • Control by TAXI-CPDLC, Controller-Pilot Communication by data link • Conformance Monitoring Alerting (incl. route deviation alerting and clearance conformance

monitoring) Additionally, a cockpit simulator with commercial Pilots was linked to the Tower simulation environment, and at the on-site trials, carried out in the test bed room of the Prague Tower in shadow mode, the DLR ATTAS test aircraft supported the trials enabling a comprehensive and realistic testing of the TAXI-CPDLC service. Generally speaking, the overall system provided a very high maturity and could fulfil the high operational expectations. The ATCOs approved its operational feasibility by accepting nearly all of the operational requirements and new procedures (compare the checklist in section 7.1). Operational improvements were measured objectively and subjectively. Subjectively the ATCOs rated significantly that

• the DMAN enables them to work more efficiently, • DMAN avoids excessive queues at the runway entry points, and • reduces taxi times. • The EFS and DMAN improve the ATCOs situation awareness and • TAXI-CPDLC reduces the time spent by R/T voice.

These subjectively gained results were also supported by the objectively measured ones.

EMMA2



2 Introduction

2.1 Scope of Document This document is positioned within the framework of activities for the ‘European airport Movement Management by A-SMGCS, part 2 (EMMA2)’ project. Based on the technical annex, the sub-project 2-SP6 deals with the validation A-SMGCS services implemented at four ground sites (Paris Charles de Gaulle, Prague-Ruzynĕ, Toulouse-Blagnac, and Milano-Malpensa) and the airborne site. Specific validation test plans and test reports were developed at each site of the project, presenting the site-specific validation process and strategy and their respective results. This document reports the results of the validation activities carried out in WP6.3, the test site Prague. It comprises results from real time simulations (RTS) and onsite trials at Airport Prague with ATCOs from ANS CR and Pilots from CSA, DLH, Hapaq-Lloyd, and DLR by support of the industry PAS, FAV, ETG, Airtel ATN and the R&D enterprises EEC and DLR. There were three test campaigns: RTS1 in 2007 and RTS2 in 2008 at DLR premises, and the onsite trials at Airport Prague in autumn 2008. RTS1 focussed exclusively on the technical and operational feasibility of the new A-SMGCS services. Results were mainly used to improve the services for RTS2 eight months later. In RTS1 the operational feedback of the ATCOs was compiled and is documented in this report (cf. §7.3) but since the same ATCOs in RTS2 eight months later assessed the operational feasibility of a more mature system, only these RTS2 results, plus results of the on-site trials (OST), are used to extract proper conclusions. In RTS2 a cockpit simulator with commercial Pilots was also linked to the Tower simulation environment in order to get more realistic results to the interaction between ATCOs and Pilots supported by new A-SMGCS services like TAXI-CPDLC or onboard ground traffic displays (GTD). Results compiled by the cockpit simulation (incl. feedback of the pilots) can be found in a separate EMMA2 document (2-D6.6.1A, [6]); the present document focuses on the ATCO perspective exclusively. In RTS2 the services were mature enough that in addition to operational feasibility operational improvements could be assessed. The on-site trials were carried out in the test bed room of the Prague Tower in shadow mode by support of the DLR ATTAS test aircraft. On-site trials were used to prove technical and operational feasibility aspects in real life that could not be assessed in a simulated environment. The details to the planning of those test campaigns can be found in the EMMA2 SP6 “Validation Test Plan – Prague” (2-D6.1.3, [5]). This documents describes the results achieved and derived conclusions but also repeats some core aspects of the test plan to make the document readable as a stand alone document. The “Validation Comparative Analysis Report” document (2-D6.7.1, [7]) then comprises all results of the EMMA2 validation activities and provides overall conclusions.

2.2 Validation Approach During the proposal phase of EMMA2, it was decided to use the ‘Master European Validation Plan (MAEVA)’ project approach to validation as the basis for EMMA2 validation activities. With the start of EMMA2 it was decided to use E-OCVM. The E-OCVM constitutes a widely accepted Validation Methodology which has been based on the experience gained in ATM R&D activities within the framework of EC and EUROCONTROL funded projects [1].

EMMA2



In EMMA2 the E-OCVM approach has been applied and adapted to the EMMA2 needs. The EMMA2 “Validation Plan” [3] and the “Generic Experimental Test Plan” [4] are the outcome documents of this process. They are the valid generic validation plans for all EMMA2 validation activities. Based on those generic EMMA2 validation documents the specific “Validation Test Plan Prague” [5] has been produced to plan all validation activities carried out in SP6 WP6.3.

2.3 Schedule of 2-WP6.3 Activities 2-WP6.3 of EMMA2 focuses on validation activities for the A-SMGCS test-bed at Prague Airport, implemented by the Sub-Project 2-SP3 of EMMA2. Here, two validation platforms will be used:

• Real-time simulation platform • Shadow Mode trials at an on-site test bed platform.

The series of tests started with real-time simulations at DLR-Braunschweig’s Tower Simulator, concentrating on Electronic Flight Strips (EFS), Departure Manager (DMAN), and TAXI CPDLC. Here the whole system was to be validated, by measuring operational feasibility and operational improvements (safety, capacity/efficiency, human factors issues). These real-time simulations were a preparatory step for the operational shadow mode trials at Prague Airport, which are aimed at proving the higher A-SMGCS services under real operational conditions. The Gantt chart below represents all perform validation activities for Prague test site:

ID Vorgangsname Start Finish

47 2-WP6.3 Validation at PRG Mon 05.11.07 Fri 19.12.0848 RTS1 Mon 05.11.07 Thu 15.11.0749 Preparations RTS 2 Mon 21.04.08 Thu 24.04.0850 RTS2a Mon 23.06.08 Thu 26.06.0851 RTS2b Mon 13.10.08 Fri 17.10.0852 On-Site Trials (Prag) Tue 18.11.08 Wed 26.11.0853 2-D6.3.1 to WP partners Fri 05.12.08 Fri 05.12.0854 2-D6.3.1 to EMMA2 GA Fri 12.12.08 Fri 12.12.0855 2-D6.3.1 to EC for approval Fri 19.12.08 Fri 19.12.08

EFS, DMAN

EFS, DMAN, TAXI-CPDLC, RPEFS, DMAN, TAXI-CPDLC, RP

EFS, DMAN, TAXI-CPDLC, RP05.1212.12

19.12

11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 062008 2009

Figure 2-1: Gantt Chart of Validation Activities in 2-WP6.3

EMMA2



3 Real Time Simulation Results

3.1 Set Up

3.1.1 The validation platform The RTS validation exercises used the Apron & Tower Simulator (ATS) and the Generic Experimental Cockpit Simulator (GECO) facilities at DLR-Braunschweig. Detailed information to the GECO platform can be found in document 2-D6.6.1.A [6], detailed information to the Tower Simulator ATS is further described in the following. The Apron & Tower Simulator (ATS) at DLR-Braunschweig is an ATC real-time simulation facility for human-in-the-loop simulation. It has been configured to accurately simulate the Prague-Ruzynĕ Airport control tower environment. Basically, the ATS set-up used for the simulation runs consists of a dynamic module that generates aircraft movements according to aircraft dynamic models and a visual system that generates and displays the synthetic vision. Pseudo-pilots in a separate building control the simulated aircraft and communicate with the controllers via a radio transmission line. In addition cockpit simulation facilities with real pilots can be included in the traffic scenarios. The supervisor of the simulation uses a master station to control the simulation. A variety of editing tools is available for modelling and generating scenarios for the preparation of simulations. The visual system consists of a six-channel image generator based on a Linux PC cluster and a 300° projection system where the images are projected on a spherical screen of seven metres diameter. Using 10° overlap and specific image transition hardware, no image boundaries are visible. The vertical angle of vision is 48°. Using this 300° projection, the complete Prague-Ruzynĕ aerodrome is visible to the ATCOs, thus enabling testing of all runway configuration modes and of taxiing traffic on all taxiways and aprons. To make the simulations as realistic as possible, the controller working positions are equipped with the same hardware and software, which are currently used in the Tower at Prague-Ruzynĕ. The test set-up includes TECAMS, RPS, SDS (with RIMCAS) and three CWPs.

Figure 3-1: ATS 300° Visual System

EMMA2



TPC TEC GEC CDD Tower Planning Not simulated

Tower Executive Ground Executive Clearance Delivery

Figure 3-2: Set-up of the Controller Working Positions of the Experimental System

3.1.2 Experimental Design The experimental design fulfils the criteria of real experiments. In real experiments it is aimed to achieve ceteris paribus conditions, that is, all possibly influencing side conditions (like VFR/IFR mix, test subjects, light conditions, etc.) are kept “neutral” and only the to be investigated A-SMGCS setting is varied by different levels of the treatment factor(s). This guarantees that measured differences of the dependent variables (indicators) can only be caused by the variance of the treatment and not be other systematically influencing effects. In this experimental design there were three levels of the treatment “A-SMGCS Services”:

Level 1 “Baseline” (A-SMGCS level 2), Level 2 “EFS”, (A-SMGCS level 2 + EFS), Level 3 “DMAN”. (A-SMGCS level 2 + EFS + DMAN)

The condition “TAXI-CPDLC” (A-SMGCS level 2 + EFS + DMAN + TAXI-CPDLC) was not used for experimental comparison to deviate operational improvements but was used to check the operational feasibility initially since the maturity level was not to be expected to be V3 (in accordance to E-OCVM [1]. Per experimental treatment level (Baseline, EFS, DMAN) there were six test runs each, in total 18. There were six ATCOs (1 – 6) available that have been randomised to those 3x6 test runs. The randomisation to the six test runs per treatment level is always the same and thus reduces the between subject error variance. A reduced error variance improves the test power finally. Following pattern of allocation of the ATCOs to the CWPs was established (cf. Table 3-1). In all 18 test runs the same traffic scenario was used (EXE06) in order to support the ceteris paribus conditions. However, in order to avoid too strong habitation by the ATCOs to the traffic scenario, it was estranged by variation of the call signs within the traffic scenario (EXE061 to EXE069). For more details to the traffic scenarios see §3.1.3)

EMMA2



Treatment Level ATCO Role configuration

Baseline = A-SMGCS

level 2

EFS = A-SMGCS

level 2 + EFS

DMAN = A-SMGCS

level 2 + EFS + DMAN

A = TEC1, GEC2, CDD3 EXE061 EXE066 EXE067

B = TEC3, GEC1, CDD2 EXE063 EXE065 EXE068

C = TEC2, GEC3, CDD1 EXE062 EXE064 EXE069

D = TEC4, GEC5,CDD6 EXE061 EXE066 EXE067

E = TEC6, GEC4, CDD5 EXE063 EXE065 EXE068

F = TEC5, GEC6, CDD4 EXE062 EXE064 EXE069

Remark: TEC = Tower Executive Controller GEC = Ground Executive Controller CDD = Clearance Delivery Controller

Table 3-1: Experimental Design: Treatment Levels and Allocation of ATCO Role & Traffic Scenarios

For the additional 15 TAXI-CPDLC test runs, analysing the operational feasibility of TAXI-CPDLC, two additional traffic scenarios were used; EXE02 and EXE04. These lasted shorter (approx. 30min) and effects of both runway scenarios RWY06 vs. RWY24 could be investigated (cf. 3.1.3, 7.2, and Table 3-4).

3.1.3 Traffic Scenarios There were three traffic scenario used: EXE02, EXE04, and EXE06. They showed following main characteristics: EXE 02

• ~ 30 min duration • RWY Config.: 24 • Departures: 10 • Arrivals: 11

EXE 04


EXE 06


In EXE06 the Generic Experimental Cockpit (GECO) had two departures and one arrival, with EXE02 and EXE04 the GECO departed and landed only once. For the flight plan details of the traffic scenario EXE06 see Table 3-2, for EXE02 and EXE06 see §7.1.

EMMA2



ARRIVALS ID STARs ETA Aircraft Type WTC Stand

6 on final 00:01 B735 M 52 39 on final 00:05 B733 M 31 15 ILS24_SW 00:08 B735 M 10 4 ILS24_NW 00:11 A320 M 54 59 ILS24_NW 00:14 AT43 M 37 46 ILS24_NW 00:16 B735 M 23 47 DOBEN 3S, ILS24_SW 00:18 B733 M 21 11 ILS24_NW 00:21 B735 M 9 60 ILS24_SW 00:23 A310 H E2B 57 OKX 1S, ILS24_NW 00:26 B735 M 15 GECO on final 00:28 A320 M S6 8 BODAL 1S, ILS24_SW 00:30 B733 M 4 65 BODAL 1S,ILS24_SW 00:32 B733 M 8 48 LOMKI 1S, ILS24_NW 00:34 A320 M 22A 17 LALUK 1S, ILS24_NW 00:37 A310 H 1 62 LOMKI 1S,ILS24_N 00:41 RJ85 M 53 7 BODAL 1S, ILS24_SW 00:43 B763 H 38 63 HDO 1S, ILS24_NW 00:47 B752 M 16 27 DOBEN 3S, ILS24_SW 00:52 B735 M 24A 28 LOMKI 1S, ILS24_N 00:56 B763 H 14 21 TABEM 1S, ILS24_SW 00:58 F100 M 33 64 LOMKI 1S, ILS24_N 01:00 B738 M 19 ∑ 22

EMMA2



DEPARTURES ETD (without CTOT)

ID SIDs CTOT Aircraft

Type WTC Stand1 DONAD 2A 10:00 B735 M 10 42 VOZ 3M 10:05 AT43 M 41 38 VOZ 3M 10:05 AT72 M 43 GECO MEDOV 1A 10:09 A320 M 55 68 DEKOVSA_5 10:09 AT43 M S17 40 DONAD 2A 10:09 A320 M 23 41 VOZ 2A 10:12 A310 H 1 5 DONAD 2A 10:14 B733 M 21 43 MEDOV 1A 10:17 AT43 M 45 61 DONAD 2A 10:20 AT72 M 42 13 MEDOV 1A 10:27 B735 M 15 9 DONAD 2A 10:29 A320 M 6 16 DONAD 2A 10:30 B735 M 3 22 VOZ 3M 10:32 AT72 M 44 25 OKX 2M 10:35 E145 M 33 23 MEDOV 1A 10:35 A320 M 18 52 DONAD 2A 10:40 A319 M 11 51 VOZ 3M 10:40 AT72 M 36A 10 DONAD 2A 10:40 A310 H 2 53 VOZ 3M 10:40 AT72 M 47 26 DONAD 2A 10:40 B735 M 19 GECO MEDOV 1A 10:40 A320 M S6 29 DONAD 2A 10:45 A320 M 17 49 VOZ 3M 10:45 AT72 M 35A 71 DONAD 2A 10:49 B744 H E6 56 DONAD 2A 10:50 A319 M 14B 66 DONAD 2A 10:50 B735 M 20 3 DONAD 2A 10:50 B738 M 13A 14 OKX 2A 10:54 B735 M 7 19 DONAD 2A 10:55 AT72 M 40 30 DEKOV 1A 11:00 B735 M 12 ∑ 31

Table 3-2: Traffic details of the used Traffic Scenario EXE06

EMMA2



3.1.4 Participants There were six Czech air traffic controllers from the Czech air traffic service provider ANS CR. All six are currently working on the Control Tower at Airport Prague.

ATCO Age sex NationalityATCO

Experience (years)

A-SMGCS Experience

(years) Participation

C1 55 male Czech 30 7 RTS1 & RTS2, OST C2 43 male Czech 16 7 RTS1 & RTS2, OST C3 37 male Czech 9 3 RTS1 & RTS2, OST C4 47 male Czech 24 5 RTS1 & RTS2, OST C5 40 male Czech 14 5 RTS1 & RTS2, OST C6 38 male Czech 9 5 RTS1 & RTS2, OST

Table 3-3: Demographical Description of the ATCOs participating at the RTS1 & RTS2



3.1.5 Schedule of Executed Test Runs

ATS GECO Validation Area Traffic Scenario Day No. Treatment TEC GEC CDD CM1 CM2 Treatment

1 Training (EFS/DMAN) 2 1 3 1 2 Training Training EXE04 RWY06 2 Training(TAXI-CPDLC) 1 3 2 2 1 Training TAXI-CPDLC Training EXE02 RWY24 3 Training(TAXI-CPDLC) 3 2 1 2 1 TAXI-CPDLC

standard Op. Feasibility EXE04 RWY06

4 Baseline 1 2 3 1 2 Baseline Op. Improvement EXE061 RWY24 5 EFS 3 1 2 1 2 GT Op. Improvement EXE065 RWY24

Mo, 6/23

6 Baseline 2 3 1 2 1 Baseline Op. Improvement EXE062 RWY24 7 EFS 1 2 3 2 1 GT Op. Improvement EXE066 RWY24 8 TAXI-CPDLC + Routing 1 2 3 1 2 TAXI-CPDLC


9 TAXI-CPDLC + Routing 3 1 2 2 1 TAXI-CPDLC revised expected taxi-out: H Z → H A

Op. Feasibility EXE02 RWY24

Tu, 6/24

10 TAXI-CPDLC + Routing 2 3 1 1 2 TAXI-CPDLC revised actual taxi-out H Z → H A, taxi-in 31 → 34


11 Without Tower Simulation 3 4 Training Training EXE04 RWY06 12 Baseline 3 1 2 4 3 Training Op. Improvement EXE063 RWY24 13 EFS 2 3 1 3 4 Baseline Op. Improvement EXE064 RWY24 14 EFS+DMAN 1 2 3 4 3 Baseline Op. Improvement EXE067 RWY24 15 EFS+DMAN 3 1 2 3 4 GT Op. Improvement EXE068 RWY24

We, 6/25

16 EFS+DMAN 2 3 1 4 3 GT Op. Improvement EXE069 RWY24 17 TAXI-CPDLC + Routing 2 3 1 3 4 TAXI-CPDLC


18 TAXI-CPDLC + Routing 3 1 2 4 3 TAXI-CPDLC standard


19 TAXI-CPDLC + Routing 1 2 3 3 4 TAXI-CPDLC rev. exp. taxi-out: H Z → H A


Th, 6/26

20 TAXI-CPDLC + Routing 2 3 1 4 3 TAXI-CPDLC revised actual taxi-out H Z → H A, taxi-in 31 → 34




ATS GECO Validation Area Traffic Scenario Day No. Treatment TEC GEC CDD CM1 CM2 Treatment

21 Training (EFS/DMAN) 5 4 6 5 6 Training Training EXE04 RWY06 22 Training(TAXI-CPDLC) 4 6 5 6 5 Training TAXI-CPDLC Training EXE02 RWY24 23 Training(TAXI-CPDLC) 6 5 4 6 5 TAXI-CPDLC stand. Op. Feasibility EXE04 RWY06 24 Baseline 4 5 6 5 6 Baseline Op. Improvement EXE061 RWY24 25 EFS 6 4 5 5 6 GT Op. Improvement EXE065 RWY24

Mo, 10/13

26 Baseline 5 6 4 6 5 Baseline Op. Improvement EXE062 RWY24 27 EFS 4 5 6 6 5 GT Op. Improvement EXE066 RWY24 28 TAXI-CPDLC + Routing 4 5 6 5 6 TAXI-CPDLC stand. Op. Feasibility EXE04 RWY06 29 TAXI-CPDLC + Routing 5 6 4 6 5 TAXI-CPDLC

revised exp. taxi-out route: G A → H A


Tu, 10/14

30 TAXI-CPDLC + Routing 6 4 5 5 6 TAXI-CPDLC revis. actual taxi-out H1 H Z A → H1 H A, in 50 → 51


31 Without Tower Simulation 7 8 Training Training EXE04 RWY06 32 Baseline 6 4 5 8 7 Training Op. Improvement EXE063 RWY24 33 EFS 5 6 4 7 8 Baseline Op. Improvement EXE064 RWY24 34 EFS+DMAN 4 5 6 8 7 Baseline Op. Improvement EXE067 RWY24 35 EFS+DMAN 6 4 5 7 8 GT Op. Improvement EXE068 RWY24

We, 10/15

36 EFS+DMAN 5 6 4 8 7 GT Op. Improvement EXE069 RWY24 37 TAXI-CPDLC + Routing 5 6 4 7 8 TAXI-CPDLC stand. Op. Feasibility EXE04 RWY06 38 TAXI-CPDLC + Routing 6 4 5 8 7 TAXI-CPDLC stand. Op. Feasibility EXE04 RWY06 39 TAXI-CPDLC + Routing 4 5 6 7 8 TAXI-CPDLC

revised expected taxi-out route: H1 H Z A→H1 H A


40 TAXI-CPDLC + Routing 5 6 4 8 7 TAXI-CPDLC revised actual taxi-out H Z A → H A, taxi-in 18→17


Th, 10/16

41 TAXI-CPDLC + Routing 6 4 5 7 8 TAXI-CPDLC revised actual taxi-out H Z →H A, in 34→18


Table 3-4: Test Schedule including treatment, allocation of ATCOs to the CWP and Pilots to the Cockpit positions, Validation Area and the used traffic scenario

EMMA2



3.1.6 Metrics and Indicators In accordance to the EMMA2 high and low level objectives, the following table outlines the respective indicators and metrics that were used in WP6.3 Prague validation activities. They were derived from the general EMMA2 validation documents: the “Validation Plan” [3] and the “Generic Experimental Test Plan” [4]. Area HLO LLO Indicator Metric Operational Feasibility

Verification of EMMA2 Operational Requirements and Procedures [HLO_1]

Fulfilment of EMMA2 Operational Requirements and Procedures [LLO_1.1]

134 items of the QE-OF Questionnaire [IND_1.1.1]

6 point Likert scale to each item proved for their significance by a non-parametric binominal test [M_1.1.1.1]

Mid-run questionnaire I.S.A. for Situation Awareness [IND_2.2.1]

10 min Mid-run self assessed situational awareness -11 point Likert scale - ANOVA of mean per test run are compared [M_2.2.1.1]

Increase of Safety [HLO_2]

Situational awareness according to the operator will be preserved or improved [LLO_2.2]

Post-trial self assessed Situation Awareness [IND_2.2.2]

Item 8 in QE-OI Questionnaire for EMMA2 – a 6 point Likert scale to each item proved for their significance by a non-parametric binominal test [M_2.2.2.1]

Mean Departure Delays - Total departure delays in a given time period (e.g. one hour). The departure delay of a single aircraft is calculated by the difference between the planned and the actual departure time.1 [IND_3.1.1]

ANOVA of mean [min] of the absolute deviation of the planned ETD/CTOT [M_3.1.1.1]

Operational Improvements

Increase of Capacity & Efficiency [HLO_3]

Improvement of the overall punctuality of the departing flights [LLO_3.1]

Amount of flights that missed its CTOT [IND_3.1.2]

ANOVA of amount of missed CTOT per test run [M_3.1.2.1]

1 So long the CTOT is not missed, a departure delay is not that important. Frequently a delay or an earlier departure cannot be avoided due to same CTOTs of several aircraft. In contrary, the DMAN attempts to smooth such peaks of departure by earlier and later TTOT but always considering not violating the CTOT.

EMMA2



Area HLO LLO Indicator Metric Self assessed improvement of the overall punctuality of the departing flights [IND_3.1.3]


Mean stop time of an outbound aircraft between pushed-back and lift-up and touched down and on-blocked for inbound [IND_3.2.1]

ANOVA of mean stop time of all outbound traffic per test run [M_3.2.1.1]

Self assessed reduction of total stop time [IND_3.2.2]


Reduction of total stop time during taxiing [LLO_3.2]

Self assessed reduction of the amount of inbound flights waiting for their final parking position, which is still occupied by an outbound flight [IND_3.2.3]


Mean taxiing time of an outbound aircraft between pushed-back and lift-up and touched down and on-blocked for inbound [IND_3.3.1]

ANOVA of mean taxiing time of an test run [M_3.3.1.1]

Reduction of global taxiing time [LLO_3.3]

Self assessed reduction of global taxiing time [IND_3.3.2]


EMMA2



Area HLO LLO Indicator Metric Maximum departure throughput - maximum number of departing aircraft within a given time period (given a permanent demand for departures)2 [IND_3.4.1]

ANOVA of amount of maximum number of departing aircraft within a given time period [M_3.4.1.1]

Increment of throughput [LLO_3.4]

Self assessed increment of throughput [IND_3.4.2]


Maximum queue length - the maximum queue length of each test run is noted [IND_3.5.1]

ANOVA of amount of maximum queue length of each test run

Avoidance of excessive departure queue length at the runway entry point [LLO_3.5]

Self assessed avoidance of excessive departure queue length at the runway entry point [IND_3.5.2]


Average time required for radio-frequency communication between the pilot and the ATCO [IND_3.7.1]

Descriptive analysis of the ratio of the total time spent by ATCOs on R/F communication in a given time period (e.g. 60 min per test run) [M_3.7.1.1]

Decrement of R/T communication [LLO_3.7]

Self assessed decrement of R/T communication [IND_3.7.2]


2 Count the runway movements between the 35 and 55 minute.

EMMA2



Area HLO LLO Indicator Metric Appropriate level of user’s workload [LLO_4.1]

Mid-run questionnaire I.S.A. for workload [IND_4.1.1]

10 min Mid-run self assessed workload -5 point Likert scale - ANOVA of mean per test run are compared [M_4.1.1.2]

Mid-run questionnaire I.S.A. for Situation Awareness [IND_4.2.1]

10 min Mid-run self assessed situational awareness -11 point Likert scale - ANOVA of mean per test run are compared [M_4.2.1.1]

Improved situational awareness [LLO_4.2]

Post-trial self assessed Situation Awareness [IND_4.2.2]


Suitability of Behaviour and Working Performance [HLO_4]

Less human errors [LLO_4.3]

Self assessment of human errors [IND_4.3.1]


Table 3-5: Metrics and Indicators (RTS)

EMMA2



3.2 Results to Operational Feasibility (RTS) This chapter describes the results gained to decide on the operational feasibility of the new A-SMGCS services. In particular, its aim was to decide on the fulfilment of the EMMA2 operational requirements from an operational and technical point of view. The operational part is covered by debriefings and the EMMA2 Operational Feasibility Questionnaire (QE-OF) asking the users for their acceptance to service or performance requirements. However some operational requirements had also to be verified from a technical point of view, which was done by technical WP6.3 experts: They were required to complete a checklist asking whether a specific requirement had been fulfilled or not. Sometimes both technician and user had to decide on an operational requirement. All decisions about the EMMA2 operational requirements met by the Prague test team (WP6.3) can be found in the ANNEX 7.1. Additionally, the QE-OF focussed on the operational feasibility of new procedures by asking the users for their acceptance, or by giving them room to provide recommendations, how to improve the new procedures. All results can be found in the following two sections.

3.2.1 Operational Feasibility Questionnaire (QE-OF) The following hypotheses pair was applied to each of the item of the QE-OF: Identifier Hypothesis

OF-H0 The users’ opinion does not agree to the “operational feasibility” aspects of a specific item.

OF-H1 The users’ opinion agrees to the “operational feasibility” aspects of a specific item.

3.2.1.1 Raw Data After finishing off all of test runs, the “Operational Feasibility Questionnaire” (QE-OF) was given to the ATCOs. The questionnaire consisted of 134 items ordered by the EMMA2 services and with reference to their operational requirements and procedures described in the SPOR [2]. Not all items could be answered because not every feature of a service was implemented or could be tested. Sometimes ATCOs were not even affected by a situation that was asked (for instance a runway conflict) – in this case the Controller could answer “not affected” (n.a.). Additionally they could answer with “not important” (n.i.) when they felt that a requirement is not that important anymore after experiencing the whole service. The following instruction has been given to them before they were requested to fill in the questionnaire:

“Introduction: Below you find questions/statements for which we are interested in your personal opinion how far you can agree to or not (answers from 1 “Strongly disagree” to 6 “Strongly agree”). Your answers will help us to decide if the system design, system performances or new procedures have met your demands. There are two additional columns where you can make a cross: If you feel that the content of a statement is of no value for you “NOT IMPORTANT” or you were not affected by this item

EMMA2



during the test: “NOT AFFECTED”, make your cross in those columns. For instance, you are asked to an alert performance but you wasn’t affected by such an alert. Please refer your answers to the experiences you gained while you were using the new A-SMGCS services (EFS, TAXI-CPDLC, DMAN, and route planning). If you want to provide additional comments/explanations you can use the whole row. Particularly when you do not agree to a statement we would be interested in the reason why. Your data will be kept confidential. Thank you in advance.”

In section 7.4 Table 7-8 all answers (raw data) of the ATCOs in the QE-OF can be found.

3.2.1.2 Results Since the sample size is only six different ATCOs per item, the binominal test as a non-parametric statistic was used to prove the results for its statistical significance. The binominal distribution can be seen as a rather conventional and robust statistic, which is supporting the H0 hypothesis, meaning that results become harder significant in the expected direction (H1). The advantage is that results, which become significant, are more likely to be really meaningful. By use of a binominal test for a single sample size, each item was proven for its statistical significance by following conditions:

• Binominal Test • Answers from 1 (disagreement) through 6 (agreement) • Expected mean value = 3,5 • Test ratio: .50 • N = 6 • α = 0.05 • when more than one ATCO was not affected by a statement (N < 5) the mean is not reported

here to avoid misinterpretations of an obviously non powerful mean value A star (*) attached to the p-value means that a questionnaire item has been answered significantly because the p-value is equal or less than the critical error probability α, which is 0.05. Additionally, such items were coloured green. When controller comments were given to an item, they are reported directly below the statement. Table 3-6 shows the respective results. Rows coloured in green indicate a statistical significance. Rows coloured in amber indicate a negative attitude to this statement, what means that average answers were below the expected mean value of 3,5. Items written in italic are results gained by the same ATCOs but after the on-site trials exercises. They are reported in this list too in order to have a complete list of all answered items.

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3

1-G The A-SMGCS was able to integrate new movements (e.g. arrivals, VFR flights).

5,00 7 0,58 ,02* GEN_Serv-04

2-G When working with the A-SMGCS responsibilities and functions are clearly defined.

5,17 6 0,75 ,03* GEN_Serv-06

3-G I think the new A-SMGCS services were well integrated into the existing ATC systems.

4,33 6 0,52 ,03* GEN_Serv-10

4-G The new A-SMGCS services supported operations of all aircraft types.

5,29 7 0,49 ,02* GEN_Serv-11

5-G The new A-SMGCS services are capable of being used by appropriately equipped vehicles operating within the movement area.

5,29 7 0,76 ,02* GEN_Serv-13

6-G The A-SMGCS wasn’t effected by any kind of radio interference, adverse meteorological conditions, or signal reflections or shadowing caused by aircraft, vehicles, buildings, snow banks.

4,83 6 1,17 ,22 GEN_Serv-14

7-G Even in case of a failure of an element of an A-SMGCS, the failure effect was such that the status was always in the "safe" condition.

4,40 5 0,55 ,05* GEN_Serv-16

8-G The new A-SMGCS services are capable of accommodating any change in the layout of the aerodrome (runways, taxiways and aprons).

5,00 6 0,63 ,03* GEN_Serv-20

9-G The new A-SMGCS services enabled me to interface and function efficiently.

4,00 6 1,10 ,22 GEN_Serv-22

10-G The new A-SMGCS services are configurable to adapt to local ATC procedures and working methods. Comments: C5:

• I hope

5,00 5 0,00 ,05* GEN_Serv-23

11-G The design of the new A-SMGCS services exclude failures that result in erroneous data for operationally significant time periods.

4,33 6 1,03 ,22 GEN_Serv-24

12-G The A-SMGCS has the ability to provide continuous validation of data and timely alerts to the user when the system must not be used for the intended operation.

5,29 7 0,76 ,02* GEN_Serv-25

13-G The availability of the A-SMGCS is sufficient to support the safe, orderly and expeditious flow of traffic on the movement area of an aerodrome down to its AVOL.

5,14 7 0,69 ,02* GEN_Serv-26

3 Reference to the EMMA2 operational requirements and procedures compiled in the 2-D1.1.1 SPOR [2].

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 14-G The A-SMGCS provides a continuous service. 5,67 6 0,52 ,03* GEN_Serv-27

15-G Any unscheduled break in operations was sufficiently short or rare as not to affect the safety of aircraft using the system.

n.a. GEN_Serv-28

16-G I was able to detect significant failures and could initiate remedial action to restore the service or provide a reduced level of service.

n.a. GEN_Serv-29

17-G The A-SMGCS allows me for a reversion to adequate back-up procedures if failures in excess of the operationally significant period occur.

5,00 6 0,63 ,03* GEN_Serv-32

18-G Any operationally significant failure in the system was clearly indicated to me.

n.a. GEN_Serv-33

19-G The system is capable of supporting operations of aircraft and vehicles within their minimum and maximum speeds and any heading.

5,17 6 0,75 ,03* GEN_Perf-01

20-G The new A-SMGCS services are able to handle all aircraft and vehicles that are on the movement area at any time. Comments: C4:

• movements must be equipped

5,17 6 0,41 ,03* GEN_Perf-02

1-S4 The surveillance function provided me with accurate position information on all movements within the movement area that I could work safely and efficiently.

5,50 6 0,55 ,03* SURV_Serv-01

2-S The surveillance function provided me identification and labelling of authorized movements that I could work safely and efficiently.

5,33 6 0,52 ,03* SURV_Serv-02

3-S The surveillance function was coping with moving and static aircraft and vehicles, within the coverage area of the surveillance function that I could work safely and efficiently.

5,33 6 0,52 ,03* SURV_Serv-03

4-S The surveillance function was sufficiently capable of updating surveillance data that I could work safely and efficiently.

5,33 6 0,52 ,03* SURV_Serv-04

5-S (While I was using it) The surveillance function was unaffected by operationally significant effects such as adverse weather and topographical conditions.

5,17 6 0,75 ,03* SURV_Serv-05

4 In a simulation environment it is not possible to address the operational feasibility of a surveillance service since the performance of the service itself is simulated. However the operational feasibility of the simulated surveillance performance can be questioned here.

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 6-S A seamless transition was provided between the

surveillance for an A-SMGCS and the surveillance of traffic in the vicinity of an aerodrome that I could work safely and efficiently.

5,17 6 0,41 ,03* SURV_Serv-08

7-S The surveillance service provided me in an efficient way with the ability to manually put the right call sign in the label associated to a co-operative vehicle.

4,83 6 1,17 ,22 SURV_Serv-13

1-A In general, the A-SMGCS conflict prediction, detection and alerting services supported me to identify conflicts in time.

4,67 6 0,82 ,03* ALERT_Serv-01 ALERT_Serv-08

2-A The A-SMGCS conflict prediction, detection and alerting services supported me to identify incursions onto runways within enough time to enable the appropriate remedial action.

5,00 5 0,71 ,05* ALERT_Serv-02 ALERT_Serv-07

3-A The A-SMGCS conflict prediction, detection and alerting services supported me to identify incursions onto taxiways within enough time to enable the appropriate remedial action.

n.a. ALERT_Serv-03 ALERT_Serv-07

4-A The A-SMGCS conflict prediction, detection and alerting services supported me to identify incursions into critical and sensitive areas within enough time to enable the appropriate remedial action.


5-A The A-SMGCS conflict prediction, detection and alerting services supported me to identify incursions into emergency areas within enough time to enable the appropriate remedial action.

n.a. ALERT_Serv-05

6-A The A-SMGCS conflict prediction, detection and alerting services supported me to identify route deviations of aircraft.


7-A I appreciated that the conflict information was displayed continuously while the conflict is present.

5,00 6 0,63 ,03* ALERT_Serv-09

8-A The conflict information was unambiguously displayed on the traffic situation display.

5,00 6 0,63 ,03* ALERT_Serv-10

9-A The number of false alerts was sufficiently low. I did not, consciously or sub-consciously, downgraded the importance of alerts.

4,80 5 0,84 ,05* ALERT_Serv-11

10-A I appreciated that the runway protection area was composed of two boundaries: a ground boundary to detect the aircraft/vehicles on the surface, an air boundary to detect airborne aircraft.

5,20 5 0,45 ,05* ALERT_Serv-12

11-A I found it useful that the ground boundary includes at least the runway strip and that its width is defined according to ILS holding positions (CAT I and CAT II/III).

5,50 6 0,55 ,03* ALERT_Serv-13

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 12-A I found it useful that the air boundary is defined

by the flight time instead of the flight distance. 4,80 5 0,45 ,05* ALERT_Serv-14

13-A I found it useful that for the conflict/infringement detection, additional updated and correct traffic context information was provided to the system such as runways in use, runways status, restricted areas, LVP, or multiple line-up.

5,17 6 0,41 ,03* ALERT_Serv-15

14-A I liked the two stages of alert: INFORMATION and ALARM. Comments: C2: set up with operational system is better tuned amber sometime to early

5,83 6 0,41 ,03* ALERT_Serv-16

1-R The routing function was always able to designate a route for each aircraft or vehicle within the movement area in a safe and efficient manner.

2,83 6 0,75 ,22 ROUT_Serv-01

2-R I was allowed to change the route destination at any time in a safe and efficient manner.

2,67 6 0,52 ,03 ROUT_Serv-02

3-R An existing or already used taxi route could easily be changed or cancelled.

2,50 6 1,05 ,22 ROUT_Serv-03 ROUT_Serv-20

4-R Even in dense traffic the routing function worked properly. Comments: C5:

• it worked but changing the route was not always possible

3,40 5 1,14 1,00 ROUT_Serv-04

5-R The provided inbound taxi routes did not constrain the pilot’s choice of exit.

4,00 6 1,41 ,69 ROUT_Serv-05

6-R The routing function was able to provide me with the probable most suitable taxi route that included the shortest taxi distance by considering current constraints.

3,50 6 0,55 1,00 ROUT_Serv-07 ROUT_Serv-09

7-R When the routing function assigned a route, the taxi route was reasonable and reliable and kept manual intervention to a minimum.

4,00 6 1,26 ,69 ROUT_Serv-08

8-R When the routing function assigned a route, crossing conflicts were kept to a minimum.

n.a. ROUT_Serv-10

9-R Assigned taxi routes were reasonable responsive to operational changes (e.g. runway changes, routes closed for maintenance, and temporary hazards or obstacles).

n.a. ROUT_Serv-11

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 10-R The used terminology or symbology to

represent a taxi route was easy to interpret. Comments: C4:

• but difficult to find and operate

4,17 6 0,75 ,22 ROUT_Serv-12

11-R Taxi routes were provided as and when they were required by me. Comments: C2: agreed, but only when they will be improved

3,40 5 0,55 1,00 ROUT_Serv-13

12-R I could easily check whether an assigned taxi route is valid or not.

3,33 6 0,52 ,69 ROUT_Serv-14

13-R When requested by me an alternative taxi route was available and could easily be selected.

2,83 6 0,75 ,22 ROUT_Serv-19

14-R I could easily define intermediate waypoints (e.g. for de-icing operations) that was considered by the routing function.

n.a. ROUT_Serv-18

15-R Besides the taxi route information, I was also provided with respective time information (TSAT, TTOT) that helped me to plan the outbound traffic.

4,00 6 0,89 ,69 ROUT_Serv-16

18-R When I deviated from the DMAN proposed times or sequences, the DMAN was able to adapt to the new situation immediately.

4,40 5 0,55 ,05* EMMA2 SPOR

19-R The coloured indication of the CTOT helped me to better monitor if a flight is too early, too late or just in time in accordance to its allocated slot.

4,17 6 0,98 ,69 EMMA2 SPOR

1-H The operation of the electronic strip display did not interfere with other ATC responsibilities.

4,50 6 1,05 ,22 HMI_Serv-01

2-H The electronic strip display maintained a balance between human and machine tasks.

4,33 6 0,82 ,22 HMI_Serv-02a

3-H The electronic strip display permitted me to retain the power to make decisions as to those functions for which I was responsible.

4,67 6 0,82 ,03* HMI_Serv-02b

4-H The electronic strip display provided a balanced mix of visual, audio and tactile inputs and responses.

4,17 6 0,98 ,69 HMI_Serv-02c

5-H Input devices were functionally simple - involving me in a minimum number of input actions.

4,67 6 0,52 ,03* HMI_Serv-03

6-H It was possible to view displays in all prevailing light levels.

5,50 6 0,84 ,03* HMI_Serv-04

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 7-H The electronic strip display allowed me to

manage the new A-SMGCS services in a safe and efficient manner.

4,67 6 0,52 ,03* HMI_Serv-07

8-H The electronic strip display were harmonised where possible with already existing ATM HMI components (e.g. A-SMGCS TSD, AMS).

4,67 6 0,52 ,03* HMI_Serv-08

9-H The electronic strip display design took into account my working environment under various operational conditions, means, the electronic strip display was adaptable to the various circumstances.

4,50 6 0,55 ,03* HMI_Serv-09

10-H The electronic strip display allowed me to configure the display capabilities (e.g. range scale selection, brightness, map overlays).

n.a. HMI_Serv-10

11-H The A-SMGCS TSD displayed the complete airport traffic situation, allowing a rapid situation assessment.

5,00 6 0,00 ,03* HMI_Serv-12

12-H I was always aware of the currently selected traffic, whose data was examining or modifying.

4,67 6 0,52 ,03* HMI_Serv-13

13-H I was provided with a clear indication that a movement was entering my area of responsibility, being under my responsibility, and leaving my area of responsibility.

5,17 6 0,75 ,03* HMI_Serv-14

14-H I was presented with a clear 'picture' to easily locate and identify aircraft and vehicles and to have a direct access to essential information.

5,17 6 0,41 ,03* HMI_Serv-15

15-H Only the minimum traffic information to fulfil my control task was permanently displayed.

5,00 6 0,00 ,03* HMI_Serv-21

16-H In case of an alert, I was provided with clear and visible indication as soon as the alert existed.

5,17 6 0,41 ,03* HMI_Serv-22

17-H Conflict information was unambiguously displayed.

5,00 6 1,10 ,22 HMI_Serv-23

18-H I was provided with clear and visible indication when a movement was deviating from its cleared route.

n.a. HMI_Serv-29

19-H I was provided with clear and visible indication when a movement was deviating from its clearance, or was operating without clearance.

n.a. HMI_Perf-30

20-H The electronic strip display reliably displayed the flight strips for flights under my control, as well as flights that will become controlled in the near future.

5,33 6 0,82 ,03* HMI_Perf-34

21-H The flight strips were logically grouped in bays to my needs.

4,83 6 0,75 ,03* HMI_Serv-35

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 22-H The flight strips in the bays could easily be

selected, sorted and presented according to my configurable criteria. Comments:

• C1: Some problem with electronic pan

4,83 6 0,75 ,03* HMI_Serv-36

23-H All traffic data items which were relevant to me were presented in clear and pre-defined formats that helped me to prioritise planning and control actions.

4,50 6 0,55 ,03* HMI_Serv-39

24-H Depending on my operational needs, the A-SMGCS HMIs were highly configurable with regard to layout, size, shape, fonts, colours and interaction capability.

4,67 6 0,52 ,03* HMI_Serv-40

25-H Arrival traffic data were displayed on concerned positions at the right time before the expected landing time (ELDT).

5,33 6 0,52 ,03* HMI_Serv-43

26-H Departure traffic data were displayed on concerned positions at the right time before the expected off-block time (EOBT).

5,17 6 0,41 ,03* HMI_Serv-44

27-H I was provided with an easy and simple means to manually create a new flight plan or modify an existing flight plan.

3,80 5 1,30 1,00 HMI_Serv-45

28-H The electronic strip display provided me with a simple and secure means for handover of electronic flight strips to another control position. Comments:

• C1: Some problem with electronic pan

5,17 6 0,98 ,03* HMI_Serv-46

29-H I was reliably supported by automatic distribution/exchange of flight data and co-ordination with other control positions.

5,00 5 1,00 ,05* HMI_Serv-47

30-H The electronic strip display assisted me for transferring aircraft control from my to another control position.

5,50 6 0,55 ,03* HMI_Serv-48

31-H There were no loss of annotations or information on the flight strips (including any hand-written notes, etc.) when they are handed over from one controller working position to another.

5,17 6 0,75 ,03* HMI_Serv-49

32-H It was reliably possible to trigger the “transfer of control” procedure either manually, e.g. by my input on a flight strip, or automatically, i.e. based on a significant flight event (e.g. with handover to departure).

5,17 6 0,41 ,03* HMI_Serv-50

33-H It was reliably possible to perform the “assumption of control” manually or automatically depending upon local operational practices.

5,00 6 0,63 ,03* HMI_Serv-51

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 34-H The automation of surface movement planning

and electronic flight strips supported me with my coordination to adjacent control positions.

n.a. HMI_Serv-52

35-H I was reliably presented with a means to operated clearances via the electronic flight stripes.

5,17 6 0,75 ,03* HMI_Serv-55

36-H It was possible to easily correct a mistaken action. Comments: C1: drag and drop did not work properly Test Coordinator: This was because the drag and drop facility was turned off to avoid disturbing DMAN and CPDLC

4,00 6 1,26 ,69 HMI_Serv-58

37-H The A-SMGCS HMIs were reliably able to show and to assign the most probable/standard route to individual aircraft and vehicles.

3,83 6 0,75 ,69 HMI_Serv-59

38-H I was provided with a quick and efficient means to modify a system assigned route to an aircraft.

2,83 6 0,75 ,22 HMI_Serv-61

39-H I could always easily intervene with the electronic flight strips to set additional constraints unknown to the routing function.

n.a. HMI_Serv-62

40-H The display of stop bars was well integrated into the A-SMGCS HMI.

5,33 6 0,52 ,03* HMI_Serv-67

41-H The current status of stop bars was reliably presented to me.

n.a. HMI_Serv-68

42-H Switching (i.e. activate or de-activate) status of stop bars was reliably changed automatically according to ATCO clearances and a/c position.

n.a. HMI_Serv-69

43-H I was reliably informed if an aircraft was datalink equipped or not.

5,33 6 0,52 ,03* HMI_Serv-71

44-H An alert was reliably presented when a datalink dialogue has failed. Comments: C1: not during the tests

n.a. HMI_Serv-72

45-H The accuracy of all map information presented on the traffic situation display (TSD) was sufficient to ensure that each movement is seen in the correct position with respect to the aerodrome layout and other traffic, and particularly with respect to hold lines and stop bars.

5,17 6 0,75 ,03* HMI_Perf-01

46-H The resolution of the displays was sufficient to not noticeably degrade the accuracy of the information being presented.

5,00 6 0,89 ,03* HMI_Perf-02

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 47-H The presentation of surveillance data was not

delayed to an extent where it is no longer operationally acceptable.

5,50 6 0,55 ,03* HMI_Perf-04

48-H The response time of the HMI was adequate to allow making inputs without having to wait unduly for the system to process and validate the input.

5,50 6 0,55 ,03* HMI_Perf-05

1-T In any data link dialogue, I was able to positively identify the other end-user. Comments:

• C1: no confirmation of receiving of CPDLC data by pilot

Test Coordinator: with test run 9 there were some problems with the Pseudopilot’s interface

3,33 6 0,82 1,00 TAXI-CPDLC_Serv-01

2-T When needed, it was always possible to switch back from data link communication to direct pilot-controller voice communications in a safe and efficient manner.

5,50 6 0,55 ,03* TAXI-CPDLC_Serv-02

3-T I was provided with an effective human-machine interface to permit data link efficient communication with the pilots.

4,50 6 0,55 ,03* TAXI-CPDLC_Serv-06a

4-T I was provided with an effective human-machine interface to permit efficient data link communication with other ATCOs.

4,17 6 0,41 ,03* TAXI-CPDLC_Serv-06b

5-T I was provided with an effective human-machine interface to permit efficient interaction with other ground systems to get the needed information (e.g. routing function).

n.a. TAXI-CPDLC_Serv-06c

6-T In the event of an unexpected termination of a data link application I was sufficiently notified of the failure.

n.a. TAXI-CPDLC_Serv-09

7-T Messages were delivered in the order that they are sent.

4,40 5 0,55 ,05* TAXI-CPDLC_Serv-10

8-T I was always provided with the capability to respond to messages, to issue clearances, instructions and advisories, and to request and provide information, as appropriate.

4,67 6 0,52 ,03* TAXI-CPDLC_Serv-13

9-T I was provided with the capability to exchange messages which do not conform to defined formats (i.e. free text messages) in a safe and efficient manner.


10-T Messages were appropriately displayed, could be printed when required and stored in a manner that permitted timely and convenient retrieval when such actions were necessary.


11-T Aircraft were always under the control of only one ATC unit at a time.

5,43 7 0,53 ,02* TAXI-CPDLC_Serv-17

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 12-T When intended, I was able to look up the

timestamp of the message when it was dispatched by the originating user.


13-T Each data link message transmission was followed by a positive technical acknowledgement, which informed me that the message has completely been transmitted and is available on the recipient’s display. Comments: C1: But presented in not convenient way Test Coordinator: The TAXI-CPDLC feedback window is only an interims solution, as the pilot’s feedback could not be shown directly in the EFS

4,50 6 0,84 ,22 TAXI-CPDLC_Serv-19

14-T The time I need to spend to monitor the traffic situation on the TSD or by looking outside was not impaired by operating TAXI-CPDLC.

4,50 6 0,84 ,03* Anticipated constraint, SPOR §3.7

15-T Input requests by keyboard or mouse to operate TAXI-CPDLC were reasonably low.


16-T The total time required for selecting a TAXI-CPDLC message, transmission of the message, or reading and interpretation of a received message was adequate to communicate in a safe and efficient manner.

4,50 6 0,84 ,22 ICAO Doc9694 PART IV, §1.8

17-T The pilot’s TAXI-CPDLC response time was quick enough to work in a safe and efficient manner. Comments: C1: But probable that Pseudopilot expected CPDLC message


18-T The mix of TAXI-CPDLC or voice handled aircraft did not lead to additional workload or communication errors.


19-T The mix of TAXI-CPDLC and voice communication for different phases of a single flight did not lead to confusion and safety critical communication errors.


20-T The automatic generation of the taxi route for a flight handled by TAXI-CPDLC was appropriate and met my demands.

3,50 6 1,05 1,00 Anticipated constraint, SPOR §3.7

21-T If the automatic generation of the taxi route failed or did not meet my expectation I could easily select or compose an adequate taxi route manually.

3,20 5 1,30 1,00 Anticipated constraint, SPOR §3.7

EMMA2



ID Questions / Statements M N SD p EMMA2 OR3 22-T The TAXI-CPDLC requests or clearances were

easy to understand and could be handled in a safe and efficient way. If not please write down which one should be improved and how: Comments: C1:

• to display routing from beginning (pending bay)

• improve manual selection of route

4,80 5 0,84 ,05* EMMA2 message set

23-T It was easy to recognise an incoming data link message or request.

3,83 6 0,75 ,69 EMMA2 SPOR §3.7.3f

24-T I never sent unintentionally a TAXI-CPDLC message to a wrong aircraft.

5,17 6 0,75 ,03* EMMA2 SPOR §3.7.3h

25-T Sending taxi route information to the cockpit in advance of the real taxi route clearance is an appropriate procedure to provide an enhanced service to the flight crews.

5,00 6 0,63 ,03* EMMA2 SPOR §3.7.3j

26-T Sending taxi route information in advance of the real taxi route clearance did not exceed my available mental and time resources.

n.a. EMMA2 SPOR §3.7.3j

27-T TAXI-CPDLC communication while the aircraft was taxiing could be performed in a safe and efficient way. Comments: C3: I am not sure if it is safe. Question is how soon in advance of the next taxiway intersection to pass revision.

4,40 5 0,55 ,05* EMMA2 SPOR §3.7.3m

28-T The frequency of the next control position can be transmitted silently by a TAXI-CPDLC massage, but the initial call from the pilot at the next control position should be retained by voice. Comments: C3: Initial call must be kept to a minimum. Perhaps only the call sign.

5,17 6 0,98 ,03* EMMA2 SPOR §3.7.3p

Table 3-6: QE-OF - Means, N, SD, and P-Value

Conclusions There were 134 questionnaire items asking the ATCOs’ acceptance to specific operational requirements and procedures of the new higher-level A-SMGCS services. 24 of them could not be addressed in the trials, because the addressed feature of a service was not implemented or could not be tested. To conclude, 110 items were answered by the ATCOs. The ATCOs disagreed on only 10 of the 110 items, and respectively could not accept the experienced performance. Those 10 negative answers are

EMMA2



mainly caused by a limited routing function that could not provide all taxi routes the ATCO need but only standard ones and some alternatives. On the other hand there were 100 of 110 answered positively. 79 of these 100 items became statistically significant, proven by a non-parametric binominal test. Finally, 79 operational requirements or procedures could be verified in the Prague test campaign, 21 were accepted but not with a probability it can doubtlessly relied on, and 10 were not answered positively.

3.2.2 Debriefing Comments5 This chapter summarizes statements made by the ATCOs at the debriefings after the RTS1and the RTS2 trials. The comments reflect a common opinion of all six ATCOs. If there were contrary opinions; they are marked by “needs further testing”. The comments mainly address aspects of the operational feasibility and proposals for improvements of the new A-SMGCS services. When such proposals could already be implemented within EMMA2 they are coloured in “green”, amber when partly addressed, and “blue” when it could not be solved yet. The comments were allocated to the headlines of the different services and the experienced test environment:

• Traffic Situation Display • Electronic Flight Strips • Routing • Departure Manager • TAXI-CPDLC • Tower Simulation Environment

3.2.2.1 Traffic Situation Display

3.2.2.1.1 RTS1 • no comments given by the ATCOs

o The TSD in the simulation was the same they are using operationally in the Tower nowadays. It is already accepted by them.

3.2.2.1.2 RTS2a • The graphical representation of a taxi route on the TSD should be able to be triggered by the

TSD itself by clicking on the label, but also by clicking on the respective flight strip (route text field), as the ATCOs work with the EFS and normally do not operate the traffic situation display.

solved in RTS2b • The editing or assigning of a taxi route is done by operating the EFS but should also be able to

operate via the TSD, but it needs further testing. • partly solved in RTS2b

3.2.2.1.3 RTS2b • The red coloured label in case of a route deviation seemed to be too severe and would

probably interfere with the most critical red runway alerts. An amber alert (stage 1 alert –“information”) would probably better fit the ATCOs needs. Eventually the taxi route field in the EFS could be highlighted instead of the label on the TSD.

Needs further testing.

5 It must be considered that the same six controllers were participating to RTS1 and RTS2. RTS1 was operating with TSD, EFS, and DMAN, whereas RTS2 was operating also with rout planning and TAXI-CPDLC and used a more challenging traffic scenario. Apart from some HMI design improvements, RTS2a and RTS2b are identical and belong to RTS2. Due to a lack of controller availability they had to be performed time shifted. RTSa was performed in June 2008 with ATCO 1, 2, & 3; RTS2b was performed in October 2008 with ATCO 4, 5, & 6.

EMMA2



• Labels on the final approach should not cover the drawn line of the final approach – ATCOs need to see it to estimate the separation between two flights and the distance to the runway threshold

3.2.2.2 Electronic Flight Strips

3.2.2.2.1 RTS1 • RWY Active Bay

o After Take-Off clearance the stripes are moved to the „after departure“ bay, but it shall stay in the active bay until the flight is detected outside of the runway strip and is then moved automatically to the “after departure” bay

solved in RTS2

o With arrival the ATCOs propose to automate the „vacation“ event when the flight has left the runway boundaries CATI or CATII/III instead of the obligatory manual EXIT click

solved in RTS2

o BUT, when the flight has to cross another runway after vacation of the arrival runway, the EFS shall remain linked to the RWY active bay (no common proposal how) – it could be shown as a full EFS directly below the active bay

not implemented yet

• CDD Pending Bay o ATCO wants to have the chance to mark an EFS indicating that the pilot has already

requested start-up but was refused by the CDD due to the proposed RTUC (TSAT) time (or too early in general)

solved in RTS2 • Sequence of pending arrival EFS should always be in accordance to the radar sequence

solved in RTS2 • In addition to the arrival stripes that were handed over by the TEC, the GND also wants to see

pending arrivals on his EFS display to be more ahead of the traffic solved in RTS2

• The field to touch and move the stripes should be larger or the pen more precise and sensitive

solved in RTS2 – sensitive touch field enlarged but pen accuracy depends on the hardware that has not been changed

ATCOs also liked to work with the mouse that is more precise but not that fast as the pen

• Could imagine that some of the action buttons could be replaced by the “drag and drop”

function partly solved in RTS2, drag and drop can be used instead of clicking all

clearance events to move the EFS over the different bays and CWPs, but other functions (like DMAN or TAXI-CPDLC), which need the “clearance status information” must be informed about this action

• Editing not fully possible

partly improved in RTS2

• Free hand text written with the pen on the EFS could be a possible solution allowing remarks on the strip that are apart from standard inputs– but no consensus about it

needs further testing

EMMA2



• Editing window changes the size of the bay and afterwards EFSs are hidden

solved in RTS2

• If an EFS is edited by an ATCO or simply not handed over it must not be allowed to assume it by another ATCO

solved in RTS2

3.2.2.2.2 RTS2a • In general:

o EFS design is rated as rather optimal now o The design of EFS to operate additional services like routing or TAXI-CPDLC via the

EFSs must be further improved o Supreme priority: Input actions should always be kept to an acceptable minimum.

• The taxi route should always be displayed textually on flight strip - standard route assigned and visible.

improved in RTS2b • Via a select menu the ATCO should also have the possibility to select any other valid route

(sorted by probability of fitness). partly solved in RTS2b – selection was implemented but routing software

could not always deal with all needed routes

• Even when an EFS is assumed at CWP 2 it should already be disappeared at the former CWP 1, not only after a clearance has been given at CWP 2.

implemented in RTS2a&b • Opened EFS menus must not cover any information that is to be used at this time.

• needs further testing

• The necessity or usefulness of the go-around button was put into question. • needs further testing

3.2.2.2.3 RTS2b • In general:

o EFS design is rated as rather optimal now o The design of EFS to operate additional services like routing or TAXI-CPDLC via the

EFSs must be further improved o ATCO comment: Printed strips are history now!

• Pen is not accurate enough to always operate the buttons of the flight strips in an easy way. The mouse was preferred by this group. They could also imagine one singular mouse to operate different screens.

• Needs further testing.

• At the TEC Position: when an arrival flight has vacated the runway it is automatically dropped down to the bottom of the bay, what is well accepted, but when the flight has to cross another runway after vacation of the arrival runway, the EFS shall remain linked to the RWY active bay – it could be shown as a full EFS directly below the active bay.

Needs further testing. • The field showing the squawk (SSR code) might be too dominant in contrast to the more

important flight time information CTOT, RTUC, TSAT, TTOT – it should be discussed

EMMA2



whether the squawk has to be shown at all on the TEC and GEC strips, as corrections are rather rare, and if happens so, the full flight plan window with all information can be opened.

• Needs further testing. • The fields showing the flight time information in the strips should always be at the same place

at the different CWPs. • The runway entry point letter could be more dominant in the strip.

• When the new A-SMGCS display would show even information like QNH, runway in use,

wind speed and direction, lightning status; EUROCAT 2000 and AMS could be replaced by the new displays.

• The display offered a night colour view, what is appreciated principally, but the colour codes

of fields in the EFS must appear in the same colors as in the daylight condition, what is not the case so far.

• A noise in kind of a rustle could be used at the CDD position to make the ATCO aware of

when start-up clearance should be given in accordance to the RTUC • Needs further testing.

3.2.2.3 Routing6

3.2.2.3.1 RTS2a

• The automatically assigned taxi route quite sometimes did not meet the operational needs of a valid one or was not assigned or available. The pool of taxi routes and the automatic assignment must be improved by support of an ATCO.

solved in RTS2b • Editing (select, correct, assign, change) a taxi route was not sufficiently worked out and thus

of course did not get the ATCOs acceptance. partly solved in RTS2b

• Accuracy of start and end point of the route must be improved, in order to better serve other

services like “route deviation alerting” for instance. • not solved yet

3.2.2.3.2 RTS2b • In general, it worked quite well, but with a number of limitations, primarily due to the fact that

only a limited number of routes had been implemented. The current routing software can only deal with a tenth of the over 1500 possible taxi routes. As long as there was a flight plan with a valid runway exit/entry point and a valid Stand ID, a valid route was presented on the flight strip. In many cases clicking on the route field enabled the choice of one or two valid alternative routes.

• Standard taxi routes were proposed for each departure and arrival. If another runway entry

point was chosen by the ATCO the taxi route adapted automatically. For inbound the routes were not that sensible – the actual runway exit was not told the routing function, thus the ATCO had to do it manually, when the aircraft vacated another exit as was expected.

6 Not available in RTS1

EMMA2



• That is, all the standard taxi routes were available as needed. Problem occurred particularly, when routes were needed, which deviate from standard taxi routes, they could not always be offered by the routing function (due to the above mentioned limitations).

3.2.2.4 Departure Management

3.2.2.4.1 RTS1 • In general:

o The ATCOs observed the first time the planned DMAN times, which were displayed in the flight strips. A final judgement could not be given at that early stage of testing but the ATCO gave some other hints how could a DMAN further be improved.

• Punctuality effects:

o In real life there is another huge effect that influences punctuality - CFMU slots are allocated without consideration of the current SIDs – depending on the SID the flight can be too early or too late at the entrance point to the next sector although its departure complied with the CTOT. A DMAN should use that additional information.

• If a DMAN plans RTUCs for pushbacks of two flights at the same time and the pushback

procedures of those two flights are spatially not independent from each other, both flights cannot be pushed at the same time – such location constraints are not considered so far by the DMAN – however the DMAN would re-plan the TTOT when the second pushback was deferred due to the first pushed a/c. Pushback capacity is sometimes lower than the runway capacity

not solved yet

• If an ATCO is aware of that an a/c is too early for its slot at the time it is requesting START-UP, even today the ATCO keeps the a/c at the gate as long as the gate is not needed by an arrival. However, the DMAN calculated and displayed TSAT (respectively the RTUC) is a helpful means to support the ATCO to keep her/him aware of.

• On the CDD position DMAN information (TSAT/RTUC) is rated as quite useful – with the

succeeding CWPs GEC & TEC, when the aircraft started taxiing already, the RTUC can hardly be considered anymore.

3.2.2.4.2 RTS2a • In general the planned DMAN times indicated in the flight strips were appreciated by the

ATCOs and were found quite reasonable and helpful to better plan the turn around. • However, in the strips, instead of all: RTUC, TSAT, TTOT; the DMAN should show only one

planned time. It was discussed, whether on the CDD working position the RTUC or TSAT should be shown. The latter would require comparing the clearance time with the current time. A green colour marking of the TSAT or RTUC could signal that the clearance is due and can be given. Further it was said that there was no necessity to display the TTOT on the CDD working position.

solved in RTS2b • Comment made by a technician: The DMAN requires receiving change information for the

assigned runway of a flight as soon as possible, even BEFORE the departure clearance is requested. When the controller decides for RWY 13 instead of the formerly scheduled RWY 24, he must update the strip immediately (even in CDD-pending bay). Otherwise the DMAN’s planning quality is decreased.

solved in RTS2b

EMMA2



• Calculation of start-up and pushback times should be better adapted to reality. Nearly always start-up and pushback is performed simultaneously in reality, because of starting up the engines at the pier is prohibited usually.

• not solved yet • DMAN does not consider gate/stand allocation. For instance, a departure hold back at the

stand may block an arrival flight that is planned for that stand. That information is not known to the DMAN.

solved in RTS2b

• Concerning the assessment of the DMAN performance it was highlighted, that more benefits could be expected with:

o Longer scenarios with more traffic, o departure peak times as actually happening in Prague, where in a short time period in

the morning and in the late afternoon a lot of aircraft want to make start-up and pushback at the same time, whilst in between these times traffic is steady or sparse.

o It was said that for the future RTS trials the scenarios should be adapted accordingly. partly solved in RTS2b – Six additional departure flights were allocated a

CTOT time but traffic scenarios could even be more challenging

3.2.2.4.3 RTS2b • In general the planned DMAN times indicated in the flight strips were appreciated by the

ATCOs and were found quite reasonable and helpful to better plan the turn around. • ATCOs like the DMAN support by delivering an optimal TSAT to keep traffic back on the

stands instead of have them waiting on the runway, but there is also room for further improvements:

o Severe jumping TSAT times are irritating for the CDD ATCO – it was explained to the ATCOs that the DMAN is permanently reacting on the current traffic situation and thus is permanently updating all the times. For instance, a non-slotted flight CSA001 is planned by the DMAN: TSAT 1005 and TTOT 1017. At 1004 DLH123 with a 1007 CTOT time is requesting start-up and thus becomes active. The DMAN prioritises the DLH123 due to its CTOT and calculates a 1017 TTOT and a TSAT of 1005 for this new flight to get its CFMU slot that expires at 1017. The non-slotted flight CSA001 is now planned later for its TTOT. But the next free runway slot is not before 1027, resulting in a TSAT update to 1015. The CSA001 RTUC jumps from 1 to 11. Such severe updates would be prevented when the DMAN is integrated into a CDM process and would be provided by negotiated and reliable TOBT. This would increase the planning certainty and thus would result in less severe updates.

o ATCOs reported that sometimes they had no waiting departure traffic on the runway

although there was a slot for a departing flight in between of two arrivals – DMAN can be adapted to this respect. There are many variables in a complex airport environment that cannot be predicted at all and thus situations can occur where the DMAN cannot react in time. To overcome this problem the DMAN can be tuned that way that, when the demand is there, at least one aircraft would be waiting on the runway to exploit not foreseeable departure slots in between of arriving flights.

o The RTUC, TSAT and the sequence number are found rather reasonable to support

the ATCOs’ flight management. The TTOT information instead is rated as rather redundant information as the UTC, CTOT and the sequence number already contain all needed information.

o The DMAN takes into account the wake vortex category of aircraft that results in

“heavy”, “medium”, and “light”, but for a most efficient planning even the aircraft type should be taken into account. Particularly jets in contrast to props, which can

EMMA2



belong to the same WVC, but have different flight performances like take-off speed and climb rates, influence the decisions of the ATCO to sequence the runway traffic and thus should also be known to a departure manager.

o When a flight is cancelled and the respective EFS is binned by the ATCO, the DMAN

must be informed about this event. Otherwise the DMAN is permanently re-planning this flight what would result in an inefficient planning.

3.2.2.5 TAXI-CPDLC7

3.2.2.5.1 RTS2a

• In general - TAXI-CPDLC with Start-up, Pushback, Taxi-out and TAXI-in, and the silent handover worked fine and with some exceptions was fully accepted by the RTS2a ATCOs.

• The pilots acknowledgement to a datalink clearance (WILCO, ROGER, UNABLE, STAND

BY) should be presented on the strip, as well as a transmission failure, instead of a positive LACK each time.

not solved yet in RTS2b– Pilot feedback and all other messages was shown in a separate windows

• The PUSH clearance could comprise all possible push position. For several stands there are up

to 4 alternative push positions. A special push position could be given by TAXI-CPDLC or by voice in addition to the TAXI-CPDLC pushback clearance.

Needs further testing

• The TAXI-CPDLC message “ON-BLOCKED” was discussed. The reception of it could be used to automate the strip transfer to BIN.

Needs further testing

• Proposal of the ATCOs to be tested in RTS2b: Initial call when using TAXI-CPDLC could be shorten as both ATCO and Pilot are aware of their data link connection.

o RTS2a procedure: Pilot: “Ruzynĕ Ground, DLH621 on your frequency” ATC: “DLH621 follow data link” Pilot: “Following data link, DLH621”

o RTS2b proposal: Pilot: “DLH621 on your frequency” ATC: “DLH621, Ruzynĕ Ground” Pilot: “DLH621”

• Needs further testing

• Discussed: Concerning the TAXI-CPDLC message set, a “stop clearance” might be useful. The stop clearance should make use both of real and of virtual stop bars. But this proposal was also questioned afterwards by the ATCOs because an operational “stop” message also needs to inform the pilot where and why they are expected to stop. Particularly the WHY is hard to handle via data link, because the reason or additional “conditional clearances” are hard to handle via data link.

• Dealing with a revised taxi route while taxiing via data link was seen as potential feasible by

the ATCOs. Needs further testing.

7 Not available in RTS1

EMMA2



• The issue with the initial taxi route information was discussed, its usefulness, the time when to

be issued for departure and approach, and who should issue it. It was explained, that on pilot’s request the system issues the message automatically, as long as a taxi route has been proposed by the routing function. This procedure was accepted by the ATCOs as long as they are the supreme authority who clears a taxi route.

• It was stated by an ATCO that a TAXI-CPDLC message for crossing might be interesting for

test purposes. On the other hand, landing, go-around, line-up and take-off should be cleared by voice, as formerly agreed. A crossing clearance would also solve the operational problem that the pilots have to switch off the red stop bar8 by their own, which is not correct from an operational point of view.


• It was discussed, how the controller can assess, whether a TAXI-CPDLC message has been received onboard. It was explained, that the separate TAXI-CPDLC message window on the EFS display for now is more technically than operationally useful. It was explained, that in a technically fully mature system the transmission of a clearance triggers two timers: One for receiving a LACK message in time, and one for receiving the operational reply (WILCO, UNABLE,…) in time. When one of the timers expires, a marking will signal either a technical or an operational failure. This was accepted by the ATCOs so far but needs further testing.

Needs further testing. • An acoustic signal for incoming TAXI-CPLDC could be helpful to attract attention to an

incoming message. But, could also be annoying. Needs further testing.

3.2.2.5.2 RTS2b • In general - TAXI-CPDLC with Start-up, Pushback, Taxi-out and TAXI-in, and the silent

handover worked fine and with some exceptions was fully accepted by the RTS2b ATCOs • A TAXI-CPDLC standard “PUSHBACK APPROVAL” does not have to be extended by

additional messages that would allow sending special pushback positions. If this would be needed standard voice communication can be used.

needs further testing as RTS2a group saw this possibility • RTS2b group instead does not see the potential to provide crossing clearances by TAXI-

CPDLC needs further testing as RTS2a group saw this possibility

• The pilots request, e.g. a pushback request, is not visible on the EFS when the strip is

(intended or untruly) already in the “TAXI” bay since the pushback button is then the TAXI button and thus cannot be yellow highlighted. However, each pilot request, whatever it is, should be forwarded and recognisable to the ATCO.

Needs further testing. • Some aircraft types (turbo props) on some remote stands do not need a conventional pushback

but push back by own power by a powerback procedures. However, having a separate TAXI-CPDLC message for a powerback procedure seems not to be obligatory as those aircraft receive immediately a taxi clearance. Nevertheless, those aircraft types and stands should be considered by the A-SMGCS by offering a TAXI button after the START-UP button instead of a superfluous PUSHBACK button.

8 at the clearance limit of their initial TAXI-CPDLC taxi-out clearance on their graphical display, which is a runway crossing quite often

EMMA2



Needs further testing. • The ATCOs remarked that the phraseology of the data link TAXI clearance is different from a

voice clearance, for instance the ATCO verbally clears a taxi route to the runway by “Taxi to holding point RWY 24 via Hotel and Bravo” instead of the data link message that says “TAXI TO HOLDINGPOINT B RWY 24 VIA TWY H B”

• Following phraseology with the initial call was preferred by the RTS2b group:

o Pilot: “Ruzynĕ Ground, DLH621 on your frequency” o ATC: “DLH621 follow data link” o Pilot: “Following data link, DLH621”

needs further testing

• TAXI Update9 was successfully tested and potentially accepted by the ATCOs. o By sending a new taxi route, some drawbacks have been observed

the new taxi route should be selectable, a manual input of the route would never be accepted

as the EFS TAXI field turns to the XFER field after having sent the original taxi route the strip must take back to the TAXI bay

• this causes additional workload what should be avoided • a DISREGARD message is sent to the pilot, what should be avoided

at this stage, because the taxi route has not been changed so far • when sent the new taxi route a REVISED message was linked to the

taxi route, what was appreciated • an immediate pilot feedback (WILCO or UNABLE) is needed by the

ATCO, otherwise he tends to take the mike to get the pilot feedback and have them informed

o pilots’ reaction was sufficiently prompt that the ATCOs felt this procedure safe and efficiently


3.2.2.6 Tower Simulation Environment

3.2.2.6.1 RTS1 • Traffic scenarios

o Scenarios must be more challenging – more traffic up to 55 movements would be conceivable to allow the new services to show their operational improvements

o Scenario should be better tuned by support of ANS CR In RTS2 a new traffic scenarios with up to 50 movements per hour was used.

The traffic scenario was generated and already used by ANS CR and thus was already properly tuned.

• Immediate take-off actions take longer in simulation than in real life solved in RTS2

3.2.2.6.2 RTS2a

• Concerning the workload of the pseudo-pilots, which sometimes led to delays in reacting on clearances, it was stated that more pseudo-pilots should be available for the future RTS trials.

3.2.2.6.3 RTS2b • no further comments

9 the taxi route was updated meanwhile taxiing

EMMA2



EMMA2



3.3 Results to Operational Improvements (RTS) This chapter describes the results gained to decide on the operational improvement of the new A-SMGCS services, which were under test. Objective and subjective data were recorded and analysed. Objective data are gained by measuring traffic movements, subjective data are gained by opinions of the ATCO, who are asked to estimate the potential of a new service to provide operational improvement. Such subjective data are a useful resource to decide on a hypothesis and finally to validate a new service. They can support equivalent objective results or even put them in question. Subjective data were gained by the EMMA2 Operational Improvement questionnaire QE-OI. The following hypotheses pair was applied to each of the item of the QE-OFI Hypothesis

CE1-H0 An increment of capacity & efficiency while using [higher services of A-SMGCS] is perceived by the ATCOs.

CE1-H1 An increment of capacity while using [higher services of A-SMGCS] is not perceived by the ATCOs.

Furthermore, objective measurements will be conducted. Here the following hypotheses will be tested: Hypothesis

CE2-H0 An increment of capacity & efficiency while using [higher services of A-SMGCS] is indicated by the simulation parameters.

CE2-H1 An increment of capacity while using [higher services of A-SMGCS] is not indicated by the simulation parameters.

18 test runs with respect to measured operational improvements were performed. Following particularities to each test run must be reported: Test Run No. Treatment

# Dep

# Arr Duration Remarks

ATCO Role

Traffic Scenario

4 Base A 30 22 1:06:48 • The CDD pseudopilot calls in for ATC

clearance in accordance to the proposed TSAT, which was a mistake.

TEC 1 GEC 2 CDD 3

EXE061

12 Base B 31 21 1:01:42

• GECO DLH622 crashed during landing – following CSA532 had to do a go-around. The GECO DLH622 reappeared on RWY24 at exit Foxtrot and proceeded taxiing to its final parking position.

TEC 3 GEC 1 CDD 2

EXE063

6 Base C 30 22 0:59:48 • nothing to report TEC 2 GEC 3 CDD 1

EXE062

24 Base D 31 21 1:06:58

• GECO DLH622 too close to the predecessor landing LOT141 – that DLH621 had to go around, were re-vectored and landed 10:38 UTC

• BER477C had to go-around at 10:58, too close to predecessor aircraft

TEC 4 GEC 5 CDD 6

EXE061

32 Base E 31 21 0:59:43 • nothing to report TEC 6 GEC 4 CDD 5

EXE063

EMMA2



Test Run No. Treatment

# Dep

# Arr Duration Remarks

ATCO Role

Traffic Scenario

26 Base F 31 21 1:05:12 • nothing to report TEC 5 GEC 6 CDD 4

EXE062

7 EFS A 31 22 1:06:30

• 2x Go-around, one by the GECO DLH622 which has been re-vectored by the ATCO to approach again RWY24 and to land finally and BER0941, GECO due to an ATCO mistake who was distracted by an visitor

• BER0941 was attempted to re-vectored but missed RWY24 again

TEC 1 GEC 2 CDD 3

EXE066

5 EFS B 28 19 0:58:48 • 1x Go around CSA720 caused by the

GECO DLH622, which was visible rather late by the ATCO

TEC 3 GEC 1 CDD 2

EXE065

13 EFS C 31 21 1:03:48 • nothing to report TEC 2 GEC 3 CDD 1

EXE064

27 EFS D 31 21 1:03:27 • GECO DLH622 too close to the

predecessor landing ID57 that DLH621 had to go around, were re-vectored and landed behind ID8

TEC 4 GEC 5 CDD 6

EXE066

25 EFS E 31 21 1:07:18 • GECO DLH622 crashed and reappeared on

exit E, missed it to vacate and vacated via exit L finally

TEC 6 GEC 4 CDD 5

EXE065

33 EFS F 31 19 11:04:40

• GECO DLH621 aborted take-off due to a failure of the throttle settings at 1016 so that ID40 had to go-around, DLH621 vacated via TWY L and taxied back to stand 34, departed on RWY24

• Inbound GECO DLH622 too close to the predecessor landing ID8, but this time ID8 was ordered to go-around that DLH622 could land safely

TEC 5 GEC 6 CDD 4

EXE064

14 DMAN A 31 22 1:10:24 • Missing clearance and traffic reports to

DMAN → test run 14 is not used for analysis of op. improvement to be caused by a DMAN service, e.g. punctuality

TEC 1 GEC 2 CDD 3

EXE067

15 DMAN B 31 22 1:10:12 • Arrival stand blocked by a departure, whom pushback was deferred by DMAN

TEC 3 GEC 1 CDD 2

EXE068

16 DMAN C 31 22 1:05:24 • DMAN parameter adapted to increase the departure throughput

TEC 2 GEC 3 CDD 1

EXE069

34 DMAN D 31 22 1:11:11

• GECO DLH621 aborted take-off due to a failure of the throttle setting, DLH621 vacated via TWY L and taxied back to stand 34, departed on RWY24 at 1038 – no go-around this time

TEC 4 GEC 5 CDD 6

EXE067

35 DMAN E 31 22 1:09:41 • nothing to report TEC 6 GEC 4 CDD 5

EXE068

36 DMAN F 31 22 1:06:47 • DMAN tuned to have more traffic on the runway

TEC 5 GEC 6 CDD 4

EXE069

Table 3-7: Particularities occurred with each test run

EMMA2



3.3.1 Punctuality of Departing Flights (LLO_3.1) Mean Departure Deviation (LLO_3.1.1) The departure deviation of a single aircraft is calculated by the absolute time difference of the planned CTOT and the actual departure time (ATOT)10. Per test run a mean departure deviation among all CTOT departures has been calculated. For instance, with test run “Baseline A” CTOT departures missed their planned departure time in average by + 3:40 minutes.

ATCO allocation (1-6) to CWP Baseline EFS DMAN A: TEC1 / GEC2 / CDD3 3:40 1:51 4:42 B: TEC3 / GEC1 / CDD2 3:08 2:29 2:08 C: TEC2 / GEC3 / CDD1 1:35 2:35 1:49 D: TEC4 / GEC5 / CDD6 4:24 4:32 5:46 E: TEC6 / GEC4 / CDD5 2:43 2:38 4:23 F: TEC5 / GEC6 / CDD4 2:38 3:34 4:18

M 3:01 2:57 3:51

Table 3-8: Raw data “Mean Departure Deviation” (absolute, minutes)

Following main effects have been calculated:

Treatment

Mean Departure Deviation (abs.)(min)

SD (min) N

Baseline 3:01 0:58 6 EFS 2:57 0:57 6 DMAN 3:51 1:33 6

Factors df square

sum F Significance

p-value A-SMGCS treatment 2 5460,4 2,2,27 ,154

error 10 2402,1

Table 3-9: One-way repeated measures ANOVA “Mean Departure Deviation”

Conclusion As the DMAN exploits the whole 15 minutes of a CTOT slot to propose a most efficient departure time (TTOT) to equalise departure peaks, the punctuality decreases apparently. DMAN planned flights deviate 50 seconds more from the initial CTOT or ETD than flights in the baseline conditions. In this test campaign punctuality has been defined by the “Mean Departure Deviation” from a planned take-off time (ETD or CTOT, resulting from the flight plan). However punctuality can also be defined by departing within the CTOT or at the time that was calculated, e.g. a target Take-off time (TTOT). Efficiency parameters are often contradicting among themselves. An equalised outbound peak with less stop and go and less excessive runway queues is probably associated with an increased deviation from the ETD. It remains the decision of the stakeholders, which efficiency parameters are most important for them. Planning tools can then be adapted to their needs.

10 Because of slotted flights have a more severe claim for punctuality (they must depart in a time window of 15 min) only slotted flights have been considered in this analysis

EMMA2



CTOT Violation (LLO_3.1.2) Treatment

level Test Run # CTOT Violation ATOT CTOT

too early(min)

too late (min)

Sum

Base A 1 10:39:58 10:40:00 – 10:55:00 0:02 Base B 0

10:06:59 10:07:00 – 10:22:00 0:01 10:26:17 10:27:00 – 10:42:00 0:43 Base C 3 10:39:08 10:40:00 – 10:55:00 0:52 10:51:51 10:35:00 – 10:50:00 1:51 Base D 2 11:03:19 10:44:00 – 10:59:00 4:19

Base E 0

Baseline

Base F 0

6

EFS A 1 10:39:37 10:40:00 – 10:55:00 0:23 10:11:23 10:12:00 – 10:27:00 0:37

EFS B 2 10:15:28 10:00:00 – 10:15:00 0:28

EFS C 1 10:38:36 10:40:00 – 10:55:00 1:24 EFS E 1 11:01:27 10:45:00 – 11:00:00 1:27 EFS F 1 10:51:03 10:35:00 – 10:50:00 1:03

EFS

EFS G 1 11:01:32 10:45:00 – 11:00:00 1:32

7

DMAN A 0 DMAN B 0 DMAN C 1 10:26:56 10:27:00 – 10:42:00 0:04

10:52:10 10:35:00 – 10:50:00 2:10 10:55:41 10:35:00 – 10:50:00 5:41 DMAN E 3 11:01:48 10:45:00 – 11:00:00 1:48 11:02:19 10:44:00 – 10:59:00 3:19 DMAN F 2 11:05:23 10:49:00 – 11:04:00 1:23 10:58:44 10:35:00 – 10:50:00 8:44 11:01:54 10:44:00 – 10:59:00 2:54

DMAN

DMAN G 3 11:05:47 10:45:00 – 11:00:00 5:47

9

Table 3-10: CTOT Violations

Conclusion Due to a chosen traffic scenario with an intensive departure demand, CTOT violations nearly occurred in each test run. The hypothesis was that CTOT violation would be less when the outbound traffic is planned by support of a DMAN. This hypothesis could not be proven by this test setting. From a statistical point of view, there are still too few CTOT violations per treatment level to get a reliable statistical power and although the traffic scenarios are always the same, they developed an own dynamic that makes it hard to reveal such small effects like differences in CTOT violations.

3.3.2 Stop Time during Taxiing (LLO_3.2) In this analysis, stop times have been extracted from the taxi times. This was done because aircraft in a simulation driven by pseudo pilots, always taxi with the same speed and effects caused by different speeds could not be expected. Therefore, if the total taxi time is cleaned by times when the aircraft are moving, effects of the stop times are better visible (cf. §3.3.2). As mentioned above, the stop times are the times during taxiing, when the aircraft is not moving. Taxi time is defined in accordance to the CDM Implementation Manual [§3.4.2, [8]]: “Definition of taxi time: For Airport CDM purposes, taxi time is considered to be:

EMMA2



• For arriving flights: the taxi-in time is the period between the Actual Landing Time (ALDT) and the Actual In-Block Time (AIBT).

• For departing flights: the taxi-out time is the period between the Actual Off-Block Time (AOBT) and the Actual Take Off Time (ATOT).”

ATCO allocation (1-6) to CWP Baseline EFS DMAN

A: TEC1 / GEC2 / CDD3 1:47 1:38 0:52 B: TEC3 / GEC1 / CDD2 1:22 1:32 0:53 C: TEC2 / GEC3 / CDD1 1:04 1:21 1:00 D: TEC4 / GEC5 / CDD6 2:41 2:08 1:18 E: TEC6 / GEC4 / CDD5 1:10 1:56 1:14 F: TEC5 / GEC6 / CDD4 1:12 1:51 1:38

Table 3-11: Raw Data “Stop Time During Taxiing” (minutes)

01:33 01:44

01:09

00:00

00:20

00:40

01:00

01:20

01:40

02:00

Baseline EFS DMAN

Table 3-12: Bar chart for means of “Stop Time During Taxiing” (minutes)

Treatment level

Mean Stop Time

(min) SD

(min) N Baseline 1:33 0:36,8 6

EFS 1:44 0:17,2 6 DMAN 1:09 0:17,7 6

Factors df square

sum F Significance

p-value A-SMGCS treatment 2 3850,1 4,24 ,046*

error 10 4539,9

Table 3-13: One-way repeated measures ANOVA “Stop Time During Taxiing”

Conclusion There is a significant positive effect for DMAN. Taxiing traffic in the DMAN test conditions takes 24 seconds (26%) less than in the baseline conditions (F(2,10) = 4,24; p = .046*). There seem to be less waiting times at the runway entry points and less stop and go during taxiing due to DMAN’s equalisation of the outbound traffic.

EMMA2



3.3.3 Taxi Time (LLO_3.3) Following taxi times (moving traffic) have been recorded:

ATCO allocation (1-6) to CWP Baseline EFS DMAN A: TEC1 / GEC2 / CDD3 7:02 6:50 6:06 B: TEC3 / GEC1 / CDD2 6:14 6:36 5:57 C: TEC2 / GEC3 / CDD1 6:12 6:28 6:10 D: TEC4 / GEC5 / CDD6 7:58 7:10 6:33 E: TEC6 / GEC4 / CDD5 5:55 7:10 6:21 F: TEC5 / GEC6 / CDD4 6:12 6:55 6:39

Table 3-14: Raw data “Taxi Time” (minutes)

06:35 06:5106:17

00:0001:0002:0003:0004:0005:0006:0007:0008:00

Baseline EFS DMAN

Table 3-15: Bar chart for means of “Taxi Time” (minutes)

Treatment

Mean Taxi Time (min)

SD (min) N

Baseline 6:35,5 0:46,3 6 EFS 6:51,5 0:17,3 6 DMAN 6:17,6 0:16,3 6

Factors df square

sum F Significance

p-value A-SMGCS treatment 2 3437,4 2,55 ,127

error 10 6738,5

Table 3-16: One-way repeated measures ANOVA “Taxi Time”

Conclusions As mentioned above, aircraft in a simulation driven by pseudo pilots do always taxiing with the same speed thus effects caused by different speeds could not be expected. However, the proven less stop times during taxiing in the DMAN condition are also visible when comparing the taxiing times, even when they get not significant (MBaseline = 6:36 min, MEFS = 6:52 min, and MDMAN = 6:18 min).

EMMA2



3.3.4 Throughput (LLO_3.4) In EMMA2 the maximum departure throughput is defined by “maximum number of departing aircraft within a given time period (given a permanent demand for departures) [M_3.4.1.1]”. “Given a permanent demand” was most probably achieved between the 35th and 55th minute of the simulation, with a demand of 16 departures by 7 arrivals on mainly one runway. RWY24 was the main departure and only arrival runway but departures could also request RWY 31/31. 11 of the 16 departures were slotted, that is, they had to depart within a time window of 15 minutes.

ATCO allocation (1-6) to CWP Baseline EFS DMAN A: TEC1 / GEC2 / CDD3 11 14 10 B: TEC3 / GEC1 / CDD2 14 13 11 C: TEC2 / GEC3 / CDD1 14 12 11 D: TEC4 / GEC5 / CDD6 10 13 10 E: TEC6 / GEC4 / CDD5 13 11 9 F: TEC5 / GEC6 / CDD4 12 13 10

M 12,3 12,6 10,2

Table 3-17: Mean Departure Throughput11

Conclusions Effects of the DMAN are also visible here: the DMAN aims to equalise excessive departure peaks. CTOT flight are prioritised and depart within their time window but non-slotted flights are planned in remaining departure slots, guaranteeing punctuality and less queues at the runway entry points, burning fuel wastefully.

3.3.5 Queue Length [LLO_3.5] The LLO_3.5 “Avoidance of excessive departure queue length at the runway entry point” has been defined as follows: “Within one hour of each test run the maximum queue length is noted and related to the amount of test runs for each experimental treatment”. Following maximum queue lengths have been measured at runway 24 entry point Alpha:

ATCO allocation (1-6) to CWP Baseline EFS DMAN A: TEC1 / GEC2 / CDD3 2 2 2 B: TEC3 / GEC1 / CDD2 2 2 2 C: TEC2 / GEC3 / CDD1 2 5 2 D: TEC4 / GEC5 / CDD6 4 4 3 E: TEC6 / GEC4 / CDD5 2 3 2 F: TEC5 / GEC6 / CDD4 2 4 2

M 2,3 3,3 2,2

Table 3-18: Maximum Queue Length

Conclusions The indicator “maximum queue length” does not show an effect that can be used to identify differences in terms of efficiency. Additionally, it has to be considered that waiting aircraft at other runway entry points, like “Bravo” or “Golf”, could not be considered in this analysis, as they were not recorded. However, those aircraft waiting at other runway entry points then “Alpha” do manifested in longer lasting “stop times” during taxiing, which were proven significantly.

11 No of Departures within 20 min by a departure demand of 16 and an arrival demand of 7 movements

EMMA2



3.3.6 R/T communication [LLO_3.7] The Indicator 3.5.1 “Average time required for radio-frequency communication between the pilot and the ATCO” has been defined by the metric: “ratio of the total time spent by ATCOs on R/F communication in a given time period [M_3.5.1.1]” In this analysis the times spent for radio communication are compared between TAXI-CPDLC test runs and baseline test runs. Since the traffic scenario used for TAXI-CPDLC slightly differs from the baseline traffic scenario, this experiment is not a real one, but nevertheless provides a reasonable estimation of the R/T communication savings.

R/T channel occupancy GEC position

18,3

30,6

0,0

5,0

10,0

15,0

20,0

25,0

30,0

35,0

40,0

% of total scenario

time

CPDLCNON CPDLC

R/T channel occupancy CDD position

16,6

24,2

0,0

5,0

10,0

15,0

20,0

25,0

30,0

% of total scenario

time

CPDLCNON CPDLC

Table 3-19: R/T Communication

3.3.7 Workload [LLO4.1] Identifier Hypothesis

HF3-H0 An increment of workload while using [higher services of A-SMGCS] is perceived by the users.

HF3-H1 An increment of workload while using [higher services of A-SMGCS] is not perceived by the users.

Within every test run every controller was asked to give his perceived workload rating every 10 minutes. The controller could choose one of five I.S.A. workload categories:

1 = underutilised 2 = relaxed 3 = comfortable 4 = high 5 = excessive

Table 3-20 shows the raw results compiled by each questioning:

EMMA2



ATCO

10203040m50 M 1020304050 M 102030m4050 M 1020m304050 M 1020m304050 M 1020304050 M 10m20304050mM 1020304050mM 10203040m50 M MC1 3 3 3 3 2 2,8 2 2 2 2 3 2,2 1 1 2 2 1 1,4 3 3 3 2 2 2,6 3 1 1 2 2 1,8 1 1 1 2 1 1,2 2 1 2 2 2 1,8 2 2 2 2 2 2 2 2 1 2 2 1,8 1,96C2 2 3 2 2 2 2,2 3 2 3 3 3 2,8 2 1 1 1 1 1,2 3 3 3 3 3 3 2 2 2 3 3 2,4 2 2 1 1 1 1,4 3 3 3 3 3 3 2 2 3 3 2 2,4 2 2 2 2 1 1,8 2,24C3 4 4 3 4 3 3,6 2 3 3 3 3 2,8 3 2 2 1 1 1,8 3 4 3 4 4 3,6 2 2 3 2 2 2,2 2 2 2 1 1 1,6 3 3 3 3 3 3 2 2 2 3 2 2,2 2 2 1 1 1 1,4 2,47C4 2 3 3 2 2 2,4 1 1 1 3 1 1,4 2 1 3 3 1 2 2 1 4 3 3 2,6 3 3 2 2 2 2,4 1 2 2 1 1 1,4 1 1 2 2 2 1,6 1 2 2 1 1,5 1 2 2 1 1 1,4 1,86C5 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 2,6 3 3 3 4 4 3,4 3 2 3 3 2 2,6 2 2 2 2 2 2 3 3 3 4 4 3,4 2 2 2 2 2 2 2 2 2 2 2 2,45C6 3 3 3 3 1 2,6 3 3 3 3 3 3 3 3 2 2 2 2,4 3 3 3 3 2 2,8 2 2 3 3 3 2,6 2 2 2 2 2 2 3 2 3 2 2,5 2 2 3 3 3 2,6 2 2 3 3 2 2,4 2,55M 2,6 2,4 1,9 3 2,3 1,6 2,6 2,1 1,8M 2,16

TEC GEC

2,29 2,31

CDD TECBaseline

CDDEFS EFS + DMAN

GECTEC GEC CDD

Table 3-20: Raw Data I.S.A for Workload

For the analysis, the I.S.A. mid-run workload scores were summed up over each ATCO for each test run and respective mean scores were calculated (cf. the second to last row of Table 3-20 and Figure 3-3).

1

2

3

4

5

Baseline EFS EFS+DMAN

TECGECCDD

Figure 3-3: Means for I.S.A.12 Workload w.r.t. the A-SMGCS treatment and the ATCO role

Factors df square

sum F-value Significance

p-value A-SMGCS treatment 2 155,8 ,998 ,40

error 10 780.6 ATCO role 2 579,7 3,259 ,08

error 10 889,4 Treat * role interaction 4 465,2 1,026 ,41

error 20 2268,3

Table 3-21: Two-way repeated measures ANOVA “I.S.A. Workload”

The means of each test run were analysed in a 3 x 3 (A-SMGCS treatment x ATCO role) two-way repeated measures analyses of variance (ANOVA). The ANOVA revealed no significant main effect of the A-SMGCS treatment (F(2,10) = 0,998; p = 0.40) with a mean of M = 2,29 for the baseline, respectively M = 2,31 for EFS and M = 2,16 for EFS+DMAN on a scale reaching from 1-5. There is

12 “Instantaneous Self Assessment” workload scale is a mid-run assessment tool with five dimensions ranging from “underutilised” through “excessive”.

EMMA2



also no significant main effect for the ATCO role (F(2,10) = 3,259; p = 0.08), whereas this result is closed to significance, presuming that the TEC position seems to be the workload most intensive position followed by GEC and CDD. Concluding Results Most of the time the controllers felt relaxed and comfortable in the simulation runs, independent of the treatment level. Although the traffic scenarios were quite demanding with respect to the amount of traffic the workload did not exceed the wanted relaxed and comfortable workload level towards the not wanted high workload level. Since a “An increment of workload while using [higher services of A-SMGCS] is not perceived by the users.” is not proven, OI-HF3-H0 must be rejected and OI-HF3-H1 must be assumed: “An increment of workload while using [higher services of A-SMGCS] is not perceived by the users.”.

3.3.8 Situation Awareness [LLO4.2] Identifier Hypothesis

S2-HO Situation awareness of users is not improved while using [higher services of A-SMGCS].

S2-H1 Situation awareness of users is improved while using [higher services of A-SMGCS]. Table 3-22 shows the raw results compiled by each questioning: ATCO

10203040m50M 1020304050M 102030m4050M 1020m304050M 1020m304050M 1020304050M 10m20304050mM 1020304050mM 10203040m50M MC1 10 10 101010 1010 101010 10 1010 10101010 1010101010 10 1010101010 10 10101010 10 10 10101010 1010 101010 10 1010 101010 101010 1010,00C2 10 9 101010 9,810 101010 10 1010 10101010 1010101010 10 1010101010 10 10101010 10 10 10101010 1010 101010 10 1010 101010 101010 10 9,98C3 9 9 10 910 9,410 91010 10 9,810 10101010 10 9 9 9 8 8 8,610101010 10 101010 9 9 9 9,4101010 1010 101010 10 1010 101010 101010 10 9,69C4 10 10 101010 1010 101010 10 1010 10101010 1010101010 10 10101010 9 10 9,8101010 10 10 10101010 1010 101010 10 10 101010 101010 10 9,98C5 10 10 101010 10 8 81010 10 9,210 10 9 9 8 9,210 9 9 8 9 9 91010 9 7 9101010 10 10 1010 9 9 8 9 9 8 8 10 810 8,81010 10 8 9,5 9,30C6 8 8 9 910 8,8 7 9 910 10 9 6 8 9 910 8,4 9 910 9 10 9,41010 9 8 8 910 910 9 10 9,6 910 9 8 91010 9 8 8 9 8 8 8 9 9 8,4 8,95M 9,7 9,7 9,6 9,5 9,6 9,8 9,7 9,6 9,7M 9,64 9,66 9,65

BaselineCDD

EFS EFS + DMANGECTEC GEC CDD TEC GEC CDD TEC

Table 3-22: Raw Data I.S.A for Situation Awareness

For the analysis, the I.S.A. mid-run situation awareness scores were summed up over each ATCO for each test condition and respective mean scores were calculated (cf. the second to last row of Table 3-22 and Figure 3-4).

EMMA2



0123456789

10

Baseline EFS EFS+DMAN

TECGECCDD

Figure 3-4: Means for I.S.A.13 Situation Awareness w.r.t. the A-SMGCS treatment and the ATCO role

Factors df square

sum F-value Significance

p-value A-SMGCS treatment 2 ,111 ,004 ,996

error 10 154,778 ATCO role 2 6,333 ,275 ,765

error 10 115,222 Treat * role interaction 4 29,556 ,878 ,494

error 20 168,222

Table 3-23: Two-way repeated measures ANOVA “ I.S.A. Situation Awareness”

The means of each test run were analysed in a 3 x 3 (A-SMGCS treatment x ATCO role) two-way repeated measures analyses of variance (ANOVA). The ANOVA revealed no significant main effect of the A-SMGCS treatment (F(2,10) = 0,004; p = .996) with a mean of M = 9,64 for the baseline, respectively M = 9,66 for EFS and M = 9,65 for DMAN on a scale reaching from 0-10. There is also no significant main effect for the ATCO role (F(2,10) = 0,275; p = .765), all ATCO positions seems to have always the same high situation awareness. Concluding Results The results that SA is not affected at all is in contradiction to the ATCOs statement in the QE-OI (see item 8-OI Table 3-25), wherein they admit that their SA was felt to be increased when supported by EFS and DMAN. It is assumed that the “I.S.A for Situation Awareness” measurement tool is not that sensitive to reveal actual SA effects. The OI-S2-H1 “Situation awareness of users is improved while using [higher services of A-SMGCS].” can not be assumed by this setting.

3.3.9 Operational Improvement Questionnaire (QE-OI) After finishing all test runs the “Operational Improvement Questionnaire” (QE-OI) was given to the ATCOs. The questionnaire consists of 10 items addressing operational improvements that could be expected due to the implementation and operational use of the higher-level A-SMGCS services. The

13 “Instantaneous Self Assessment” situation awareness scale is a mid-run assessment tool with a single 11 point Likert scale ranging from “0” through “10”.

EMMA2



items refer either to “expected benefits” that were identified in the 2-D1.1.1 SPOR document [2] or refer directly to a low level objective (cf. [3] and §3.1.6).

3.3.9.1 Results Following Instruction has been given to them before they were requested to fill in the questionnaire:

“Introduction: Below you find statements for which we are interested in your personal opinion how far you can agree to or not (answers from 1 “Strongly disagree” to 6 “Strongly agree”). Your answers will help us to decide if the new services are able to provide operational improvements in terms of supporting you in aerodrome operations. Please refer your answers to the experiences you gained while you were using the new EMMA2 A-SMGCS services (EFS and DMAN) and compare with the current situation in the Tower, where you operate the A-SMGCS traffic situation display (TSD) and printed stripes. Do not consider the trials with TAXI-CPDLC and route planning. If you want to provide additional comments/explanations you can use the whole row. Your data will be kept confidential. Thank you in advance.”

Table 7-8 shows all answers of the ATCOs given in the QE-OI:

ID C1 C2 C3 C4 C5 C6 1-G 5 4 4 5 4 4 2-G 4 4 5 6 5 6 3-G 4 4 5 3 4 4 4-G 4 5 4 6 5 6 5-G 4 4 4 5 4 4 6-G 5 2 5 3 4 3 7-G 2 4 4 3 2 8-G 5 4 6 4 5 4 9-G 5 3 6 5 3 5 10-G 5 4 6 6 5 6

Table 3-24: Raw Data of the QE-QI

Since the sample size is only six different ATCO per item, the binominal test as a non-parametric statistic were used to prove the results for their statistical significance. By use of a binominal test for a single sample size, each item was proved for its statistical significance by following conditions: Binominal Test

• Expected mean value = 3,5 • Test ratio: .50 • Answers from 1 (disagreement) through 6 (agreement) • N = 6 • α = 0.05

EMMA2



A star (*) attached to the p-value means that a questionnaire item has been answered significantly because the p-value is equal or less than the critical error probability α, which is 0.05. Additionally, such items are coloured green. When controller comments were given to an item, they are reported directly below the statement. Table 3-6 shows the respective results. Rows coloured in green indicate a statistical significance. Rows coloured in amber indicate a negative attitude to this statement, what means that average answers were below the expected mean value of 3,5.

ID Questions / Statements M N SD p Reference

1-OI The DMAN calculated times (TSAT, TTOT) and the recommended time until the next clearance (RTUC) helped me to perform my control task more efficiently. Comments: C3: need more traffic, higher volume in test run

4,33 6 0,52 .03* EMMA2 SPOR

2-OI The DMAN calculations help me to avoid excessive departure queue length at the runway entry point. Comments: C3: I would suggest to have 1 or 2 a/c in queue, sometimes there was no a/c for dep within an arrival gap

5,00 6 0,89 .03* [LLO3.5]

3-OI The DMAN supported me to improve the overall punctuality of the departing flights. Comments: C4: Punctuality is even today ok, but aircraft frequently waiting in queue on runway entry point

4,00 6 0,63 .22 [LLO3.1]

4-OI The new A-SMGCS services (EFS + DMAN) support me to reduce the average stop time of the aircraft.

5,00 6 0,89 .03* [LLO3.2]

5-OI The new A-SMGCS services (EFS + DMAN) support me to reduce the average taxi time of the aircraft.

4,17 6 0,41 .03* [LLO3.3]

6-OI When the traffic demand is higher than the current throughput, I think the new A-SMGCS services enable me to increase the traffic throughput.

3,67 6 1,21 1,00 [LLO3.4]

7-OI The new A-SMGCS services help me to reduce the amount of inbound flights waiting for their final parking position, which is still occupied by an outbound flight. Comments: C1: inbound flights has no influence on new A-SMGCS services

3,00 5 1,00 1,00 [LLO3.2]

EMMA2



ID Questions / Statements M N SD p Reference

8-OI The clearance status and current flight plan data of a flight displayed by the electronic flight stripes (EFS) improves my situation awareness.

4,67 6 0,82 .03* [LLO4.2]

9-OI The new A-SMGCS services help me to reduce the potential of human error.

4,50 6 1,22 .69 [LLO4.3]

10-OI When using TAXI-CPDLC I recognised a reduction with the time spent by R/T voice communication.

5,33 6 0,82 .03* EMMA SPOR §1.5 [LLO3.5]

Table 3-25: QE-OI - Means, N, SD, and P-Value

Conclusions There were 10 questionnaire items asking for the ATCOs’ agreement to “expected benefit” caused by the new higher-level A-SMGCS services. Only with item 7 “reduced stop times for inbound flights” the ATCOs disagreed, respectively could not agree to the “expected benefit”. 9 of 10 items have been positively answered and six of them even statistically significant, proven by a non-parametric binominal test. To conclude, the ANS CR ATCOs experienced the new high-level A-SMGCS services as very good candidates to increase safety and efficiency. In spite of they could not agree on whether punctuality or throughput can be increased, and human errors could be decreased, they significantly agreed on that those new services contribute to:

• an improved situation awareness, [LLO2.2 & LLO4.2], • a more efficient control task caused by a DMAN, • a reduction of the average stop time of the aircraft on the aerodrome [LLO3.2], • a reduction of the average taxi time of the aircraft on the aerodrome [LLO3.3], • an avoidance of excessive departure queue length at the runway entry point [LLO3.5], • a reduction with the time spent by R/T voice communication supported by TAXI-CPDLC,

[LLO3.5].

EMMA2



4 Operational Field Trials Results

4.1 Set Up

4.1.1 The validation platform The on-site validation exercises used the A-SMGCS test-bed components at Prague-Ruzynĕ airport, established under 2-SP3 of the EMMA2 Project. The test bed is the former control room, is beneath the actual Control room now and has still a perfect outside view. Identically to the set up in the Tower Simulator there were three CWPs equipped (cf. also 3.1.1): TEC, GEC, and CDD. All the EMMA2 systems were linked to the real environment: surveillance and flight plan data. The ATCOs could listen to the three different control radio telecommunication (CDD, GEC, TEC) but worked in shadow mode, that is, they did not interact with the traffic (except of the ATTAS test aircraft) put only moved the EFS in accordance to the real world and checked the feasibility of the EFS and the DMAN proposed times.

• Tower Test Bed: o 3 CWPs: TEC, GEC, CDD o TSD, EFS, DMAN, Routing, TAXI-CPDLC, RIMCAS, basic conformance

monitoring o Frequency monitors (black box with loudspeaker and volume control) o Handsets with predefined buttons for communication with operational TWR

Figure 4-1: Three ANS CR ATCOs working in Shadow Mode at the three EMMA2 CWPs in the test bed room of the Tower Prague

• ATTAS test aircraft:

o EMM, Ground traffic display (fed by TIS-B), Traffic Conflict Detection (TCD), TAXI-CPDLC (CDTI + Graphical presentation on the EMM), ADS-B out/in

EMMA2



Figure 4-2: DLR ATTAS Test Aircraft (D-ADAM)

For more detailed information see the SP6 “Validation Test Plan – Prague” (2-D6.1.3, [5]).

4.1.2 Experimental Design There is no real experimental design possible in field trials since very less can be controlled to perform real experiments. Nevertheless, shadow mode trails provide an excellent opportunity to check aspects of the technical and operation feasibility that cannot be checked in simulation trials, where for instance the traffic and real interfaces are simulated. Therefore, two different “experimental arrangements” have been used, one for EFS/DMAN and one for the TAXI-CPDLC service.

• DMAN + EFS trials o 3 ATCOs working in shadow mode in busy traffic environment (ca. 1,5h) o Listen to the R/T frequencies (CDD, GEC, TEC) o Handle the EFS in accordance to the regular ATCOs’ action o Check the operational feasibility of DMAN times and the EFS handling (QE-OF) o Debriefing afterwards (1h)

• TAXI-CPDLC trials o the ATTAS is controlled by voice via the regular ATCOs o in parallel the ATTAS communicates via TAXI-CPDLC with the EMMA2 ATCOs in

the test bed the respective clearances / messages o Three EMMA2 ATCOs operate the EFS via the test bed consoles o Procedure would be, as tested in simulation (cf. [2]) o ATTAS performs an outbound / inbound scenario (2 aerodrome circling, ca. 80min)

(4 IFR flight plans (two outbound, two inbound)) o Operational feasibility in the field can be answered after the trials by ATCOs and

Pilots in a debriefing session (45min) o responsibilities:

During the Tests, the regular controllers have the ATTAS (D-ADAM) under control, but

The actual ATCO (CDD/GEC) would only perform the initial call with the ATTAS pilots, they are briefed about the silent START-UP, PUSHBACK,

EMMA2



and TAXI clearance given by TAXI-CPDLC from the EMMA2 ATCOs, stay in contact with EMMA2 ATCOs, monitor the ATTAS movement and intervene by R/T in case of critical situations

4.1.3 Traffic Scenarios Based on the general winter flight plan following amounts of traffic had been estimated beforehand the trials in order to identify “high amount” traffic periods to test the EFS/DMAN services and to identify “low amount” traffic periods to have the test aircraft flying. The traffic forecasts rather exactly met the real traffic amounts during the trials.

Local time Tu We Th

from to Dep Arr Dep Arr Dep Arr1 - 02 2 - 03 3 - 04 4 - 05 5 - 06 6 1 7 5 6 - 07 6 9 3 9 3 137 - 08 22 10 23 8 21 9 8 - 09 7 9 6 12 7 139 - 10 12 17 9 16 16 19

10 - 11 10 24 13 21 14 2211 - 12 7 4 19 7 19 1012 - 13 29 9 17 10 25 1613 - 14 9 8 8 9 9 1014 - 15 9 10 12 6 18 7 15 - 16 12 14 9 18 8 1316 - 17 11 27 8 24 8 3117 - 18 25 12 26 10 26 1218 - 19 12 10 7 8 11 1419 - 20 5 11 8 13 9 1420 - 21 13 26 14 22 16 2221 - 22 17 4 17 10 21 9 22 - 23 4 5 15 8 11 7 23 - 24 5 5 5 5 5 4 24 - 01 2 6 5 2

Table 4-1: Estimated traffic amount (local time)

Low traffic <25/h High traffic >25/h

EMMA2



4.1.4 Participants There were the same six Czech air traffic controllers from the Czech air traffic service provider ANS CR that already participated in the real time simulation campaigns plus one additional ATCO. All seven are currently working on the Control Tower at Airport Prague.

ATCO Age sex NationalityATCO

Experience (years)

A-SMGCS Experience

(years) Participation

C1 55 male Czech 30 7 RTS1 & RTS2, OST C2 47 male Czech 24 5 RTS1 & RTS2, OST C3 37 male Czech 9 4 RTS1 & RTS2, OST C4 38 male Czech 9 3 RTS1 & RTS2, OST C5 40 male Czech 14 4 RTS1 & RTS2, OST C6 41 male Czech 15 3 RTS1 & RTS2, OST C7 43 male Czech 16 7 OST

Table 4-2: Demographical Description of the ATCOs participating at the Prague On-site Trials

4.1.5 Schedule of Executed Test Runs In total there were 10 “EFS/DMAN” trials and five aerodrome circuits by the test aircraft to test TAXI-CPDLC in real life. Each “EFS/DMAN” trail lasted approximately 45 - 60 min,

Tu, 18. 11. We, 19. 11. We, 26. 11. Th, 27. 11. 1130-1300 1400-1500 1000-1200 1300-1500 1100-1300 1000-1300 1300-1500 ATCOs

EFS/DMAN CPDLC EFS/DMAN CPDLC EFS/DMAN EFS/DMAN CPDLC

C1 GEC GEC C2 CDD CDD TEC GEC GEC TECC3 GEC CDD TEC GED TEC

C4 GEC CDD TEC CDD CDD GEC

C5 CDD GEC TEC CDD CDD GEC

TEC TEC CDD

C6 CDD GEC TEC

TEC GEC CDD GEC

C7 TEC TEC CDD GEC Low traffic <25/h High traffic >25/h

Table 4-3: ATCOs’ executed Test Runs in the Tower Test Bed

Pilots’ initials Tu, 18. 11. We, 19. 11. We, 26. 11. Th, 27. 11.

1100-1300 1400-1500 0800-1000 1300-1500 1000-1230 1300-1500

TIS-B CPDLC TIS-B CPDLC TIS-B CPDLC

AW (DLR) X X X (X) X X SS (DLR) X X X X AH (DLR) X X KM (CSA) X X

Table 4-4: Pilots’ executed Test Runs in the ATTAS Test Aircraft

EMMA2



4.1.6 Metrics and Indicators In accordance to the EMMA2 high and low level objectives, the following table outlines the respective indicators and metrics that were used in the on-site trials at Prague Airport. As real experiments with real baseline comparisons cannot be done in the field, the test focussed on the assessment of the operational feasibility of the new A-SMGCS services, concentrating on those aspects that could not be covered yet by the real time simulation trials. After the trials the QE-OF, which statements had been adapted to the on-site trials circumstances, was filled in by each ATCO. Additionally interviews were carried out at the end of the day to allow the ATCO to address aspects of the operational feasibility of the new A-SMGCS services that had not been covered by the QE-OF. Area HLO LLO Indicator Metric Operational Feasibility

Verification of EMMA2 Operational Requirements and Procedures [HLO_1]

Fulfilment of EMMA2 Operational Requirements and Procedures [LLO_1.1]

134 items of the QE-OF Questionnaire [IND_1.1.1]

6 point Likert scale to each item proved for their significance by a non-parametric binominal test [M_1.1.1.1]

Table 4-5: Metrics and Indicators (OST)

4.2 Results to Operational Feasibility (OST) This chapter describes the results in terms of “operational feasibility” gained by the on-site trials. Results mainly base on the QE-OF questionnaire, notes by the test observers during the test runs, and open discussions among the whole test team performed in the debriefing sessions. Results gained by QE-OF can be found as raw data in section §7.4, as results in section §3.2.1, and the overall feedback to the operational requirements in the checklist §7.1. The following sections summarize observations made by the test team during the trials and comments given by the ATCOs at the debriefings after the Prague on-site trials. The comments reflect a common opinion of all seven ATCOs. If there were contrary opinions; they are marked by “needs further testing”. The comments mainly address aspects of the operational feasibility and proposals for improvements of the new A-SMGCS services. In general, it must be stated that the system worked very well. It could cope with the real traffic without any problems. Therefore, the ATCOs experienced nearly the same installed system as they already experienced and commented in the simulation trials. New comments of the ATCOs therefore were rather rare. The comments were allocated to the headlines of the different services:

• Traffic Situation Display • Electronic Flight Strips • Routing • Departure Manager • TAXI-CPDLC • Tower Simulation Environment

EMMA2



4.2.1 Traffic Situation Display (TSD) • The TSD is already operational at Prague Tower since 2005. Therefore, in EMMA2 the TSD

was not subject of testing anymore but served as the current baseline system in the trials. • In general it is still very appreciated by the ATCOs and there were no further comments to it.

4.2.2 Electronic Flight Strips (EFS) • EFSs at the three CWPs in the test bed were fed by the operational flight data processing

system. All needed flight plan data were reliably available and could be processed by the ATCOs.

• There were some minor observations that have to be corrected, mainly caused by the

integration of the new taxiway D and the new remote stands 70 – 76: o for departure RWY 13 entry point P must be selectable o for departure RWY 13 all 70s and 60s stands need D as standard entry points instead

of R o for departure RWY 31 instead of RWY as runway entry point provide R

• The CDD test bed position was set up to delete the departure strips when they were out of time in order to prevent an accumulation of stripes when the CWP was not operated by an ATCO. However, when a flight was really delayed severely it happened that a strip was deleted automatically. The strip could be retrieved of course out of the bin, but some data were sometimes lost then. This circumstance is mentioned here to explain why sometimes data were reported missing by the ATCOs. It was caused by a special setting of the CWP under test conditions and is not to be expected when the EFSs are operated in the right way.

• The EFS for departures at the TEC position provides an automatically started counter. It starts

counting the time after take off to provide the ATCO with accurate time based separation means which is very appreciated by the ATCOs. It starts counting when the departure reaches 1000 feet but after some discussions the ATCOs would prefer an earlier trigger, e.g. when the departing aircraft exceeds 40 knots. More testing would be needed here.

4.2.3 Routing • The routing function had nearly the same status as it had in the simulation trials. • In general, it worked quite well, but with a number of limitations, primarily due to the fact that

only a limited number of routes had been implemented. The current routing software can only deal with a tenth of the over 1500 possible taxi routes.

• As long as there was a flight plan with a valid runway exit/entry point and a valid Stand ID, a

valid route was presented on the flight strip. In many cases clicking on the route field enabled the choice of one or two valid alternative routes.

• Standard taxi routes were proposed for each departure and arrival. If another runway entry

point was chosen by the ATCO the taxi route adapted automatically. For inbounds the routes were not that sensible – the actual runway exit was not forwarded to the routing function by the surveillance function, thus the ATCO had to do it manually, when the aircraft vacated another exit than standard.

• That is, all the standard taxi routes were available as needed. Problem occurred particularly,

when routes were needed, which deviate from standard taxi routes, they could not always be offered by the routing function (due to the above mentioned limitations).

EMMA2



• The ATCOs admitted they were provided with a very well designed HMI to operate the taxi routes. Besides, ATCOs could also imagine having only one mouse to operate both displays (TSD + EFS) in order to have the possibility to update a route via the TSD as well – but more testing would be needed here to see whether this opportunity would bring additional benefit.

4.2.4 Departure Management • In general the planned DMAN times indicated in the flight strips were appreciated by the

ATCOs and were found to be quite reasonable and helpful to better plan the outbound traffic. The ATCOs also responded that DMAN would be a prerequisite for many future services in a CDM environment. They estimated that they could provide a more efficient service for surface movements.

• However, at the current stage there is also room for improving and adapting the tool. Following subjects were addressed and discussed:

o When the DMAN times (TSAT, TTOT, RTUC, sequence information) would be reliable enough they would prefer to see only the DMAN times in the EFS – ETD/EOBT/CTOT would be superfluous then.

o Even today the DMAN times could be more dominant in the strips. o The positioning of the times in the stripes must not be varied. o It was discussed when the DMAN should abandon its proposed sequence by adapting

to the real implemented sequence and when the DMAN should stick to it allowing the ATCO to implement the DMAN proposal. Further testing would be needed here.

o DMAN must distinguish between stands were the engine start up is done simultaneously with the pushback operation. This would further improve the accuracy of planning.

o At the moment the ETA are permanently updated but the ETA and the ATA can still very by some minutes – if the ETA accuracy could be improved the occupancy times of the runway can be better predicted by the DMAN.

o In general, the more the DMAN is informed about operational side conditions the better the planning outcome will be.

o Further testing and adaptation would be needed to answer those subjects and to get the DMAN operational.

4.2.5 TAXI-CPDLC • In general, the TAXI-CPDLC service worked perfectly. There were some initial problems

with respect to doubled EFS caused by successive aerodrome circuits and one link lost due to the ATTAS leaving off the VDLm2 range, but this could be solved easily.

• In detail, there were five aerodrome circuits performed by the ATTAS test aircraft: o 1st circuit, 2008-11-18, 14:20 – 15:00

unintentionally there were created two departure EFSs for the ATTAS (call sign D-ADAM), which caused trouble with the log on – the log on was done on the former created but at this time already deleted EFS – after retrieving the deleted EFS and binning the actual EFS this problem was solved and the test could start

the transmission of all TAXI-CPDLC clearances run perfectly during the flight phase, when the ATTAS was 15,5 miles the log off was

performed intentionally With inbound the ATTAS logged on again (green log on sign was seen on the

D-ADAM inbound EFS) After crossing RWY13/31 and handover to the regular GEC, the regular GEC

instructed “follow data link” and the test bed GEC provided the inbound taxi route to the final stand by TAXI-CPDLC

o 2nd circuit, 2008-11-19, 12:20 – 13:15

EMMA2



all TAXI-CPDLC outbound clearances worked perfectly (see also a screenshot of the EFS display Figure 4-3)

during the aerodrome circuit the link was lost as the ATTAS distance to the VDLm2 antenna was too far

hence, with inbound the log on failed

Figure 4-3: EFS Screenshot: Test Aircraft (D-ADAM) requests a Taxi-out Clearance by TAXI-CPDLC14

o 3rd circuit, 2008-11-19, 13:15 – 15:00

Call sign ADAM was chosen instead of D-ADAM in order to avoid allocation problems with the log on

All out- and inbound clearances worked perfectly

o 4th circuit, 2008-11-27, 12:35 – 13:25 All out- and inbound clearances worked perfectly

o 5th circuit, 2008-11-27, 13:30 – 14:10

All out- and inbound clearances worked perfectly

• Following subjects were addressed and discussed in the debriefing sessions: o In general the ATCOs reacted very positive to the new service and its performance.

START-UP, PUSHBACK, and HANDOVER instruction can easily be given by TAXI-CPDLC.

o The taxi clearances however would depend on the maturity and the design of the routing function. When in operation, the right taxi route must always be available or easily been selectable. In the trials this could be guaranteed, but the requirements of daily operations would of course even more challenging.

14 There is a time shift between ground equipment time and ATTAS test aircraft time because of they were not synchronised beforehand, but without causing any trouble.

EMMA2



o Instead of a separate TAXI-CPDLC window, Pilots’ acknowledgement must be integrated into the respective flight strips (this was planned from the very beginning but could not be implemented yet when the trials were performed).

o Further testing is needed to get the service operational.

4.2.6 Alerts • The surveillance based runway incursion alerts have already been investigated by the previous

EU projects EMMA. Therefore, in EMMA2 these runway incursion alerts were not subject of testing anymore but served as the current baseline system in the trials.

• In general they are still very appreciated by the ATCOs and there were no further comments to those alerts.

• Additionally, the EMMA2 test system provided further alerts: o route deviation alerts and o clearance conformance monitoring alerts.

• Both were observed by the ATCOs for a certain while and they could imagine a potential safety benefit, but they must be properly tuned in order to avoid unwanted alerts or warning as much as possible.

• At the times of the tests those alerts had not been tuned yet – further testing would be needed.

EMMA2



5 Conclusions

5.1 Conclusions to the new A-SMGCS services During the Prague validation trials a nearly complete A-SMGCS was implemented and under evaluation. Following A-SMGCS services were operated by the ATCOs:

• Traffic situation display (TSD) • Runway incursion alerting (surveillance based alerting) • Electronic Flight Strips (EFS) • Departure Management Planning (DMAN) • Routing • Control by TAXI-CPDLC, Controller-Pilot Communication by data link • Conformance Monitoring Alerting (incl. route deviation alerting and clearance conformance

monitoring) Generally speaking, the overall system provided a very high maturity and could fulfil the high operational expectations. The ATCOs approved its operational feasibility by accepting nearly all of the operational requirements and new procedures (compare the checklist in section 7.1). The ATCOs also admitted that the new services would enable them to provide a safer and more efficient service to the Pilots and Airlines. A DMAN for instance would allow to plan the outbound traffic more efficiently to avoid excessive queues at the runway entry points with waiting aircraft with running engines without moving (cf. QE-OI, Table 3-25). Via TAXI-CPDLC they can provide the pilots a more efficient guidance service. They can transmit actual taxi clearance by data link that can be displayed onboard and would facilitate the pilots’ navigation task. Additionally they would save a lot of time spent for routine communication like a handover instruction for instance (cf. Table 3-19). All this is enabled by an electronic flight strip environment, which would allow the ATCOs to more easily exchange flight plan among them, to forward information to other units, or to have immediate access to updated flight plan information. In the following, general results of each new service will be reported: Traffic situation display (TSD) and Runway incursion alerting (surveillance based alerting) These two basic A-SMGCS services (also known as level 1&2) were already validated in the previous EU projects BETA and EMMA. Since 2005 they have been operational in Prague Tower. Therefore these services were not the subject of testing in EMMA2 but served as the current baseline in the trials. Electronic Flight Strips (EFS) After several iterative evaluation cycles that nearly lasted the whole duration of EMMA2, the ATCOs rated the EFS platform as well defined and considered them ready to go into operational. In the trials the EFS platform could prove that its HMI design fits the ATCOs needs, that it is able to carry other A-SMGCS services like DMAN, TAXI-CPDLC, Routing, and alerting, that it is reliable, intuitive and interactive. It does not impair a comfortable workload level and the displayed clearance status and current flight plan increases the ATCOs’ situation awareness (cf. QE-OI, Table 3-25). With respect to monetary benefits, EFS would also save on costs for printing paper strips. With the example of Prague Tower per day approximately 1000 strips are printed out, and that would

EMMA2



correspond to an annual sum of 10.000 Euros that could be saved by implementing electronic stripes. Departure Management Planning (DMAN) The DMAN provided the ATCOs with three calculated flight plan data, which were shown in the electronic strips: TSAT, TTOT, RTUC. In addition the sequence number for each outbound flight, proposed by DMAN, was always displayed on the strip. The ATCOs liked this additional information and admitted that it would help them to perform their control task more efficiently, to avoid excessive queues at the runway holding points and to shorten the stop times during taxiing. These results could also be proven by objective traffic data (cf. QE-OI, Table 3-25; Table 3-12). Nevertheless, the DMAN could only show portions of its anticipated benefit. To receive the full benefit the tool would need to further be adapted to the particularities of Prague Airport and its local procedures, but this would need further testing time. Furthermore, the integration into a CDM environment would enable the DMAN to work with a broader planning horizon, which would of course also improve the DMAN planning output. Routing The routing function itself is not a service ATCOs benefit directly on; it is more an important enabler for other A-SMGCS services, like TAXI-CPDLC, the DMAN, and route conformance monitoring. In general, it worked quite well, but due to a number of limitations, primarily because only a limited number of routes had been implemented, it got only partial acceptance by the ATCOs (cf. QE-OF, Table 3-6). However, standard taxi routes were proposed for each departure and arrival flight. As long as there was a flight plan with a valid runway exit/entry point and a valid stand ID, a valid route was presented on the flight strip. In many cases clicking on the route field enabled the choice of one or two alternative routes. This means that most standard taxi routes were available. Problems occurred particularly, when routes were needed, which deviated from the standard taxi routes. These routes could not always be offered by the routing function (due to the above mentioned limitations). TAXI-CPDLC In the Prague real-time simulation trials a complete experimental setting including both ATCOs in a tower and pilots in a cockpit environment was set up. The simulation was run with three ANS ATCOs, a cockpit crew, and five pseudo-pilots. In total there were six ATCOs and eight commercial pilots who performed 15 test runs resulting in more than 350 movements and more than nine hours of TAXI-CPDLC testing. In the simulation trials controllers worked with a data link equipage rate of 50% of the participating traffic, which was considered a very likely future traffic scenario. The Ground Executive Controller (GEC) and the Clearance Delivery Dispatcher (CDD) handled START-UP, PUSHBACK, TAXI-in, TAXI-out, and HANDOVER by data link. The Tower Executive Controller (TEC), who was responsible for the runways, used voice exclusively. The ATCO feedback for handling those clearances by TAXI-CPDLC was predominantly positive. The ATCOs admitted that they were provided with an effective human-machine interface to permit an efficient data link communication with the pilots and that a mix of TAXI-CPDLC and voice communication for different phases of a single flight and a mix of equipped and non-equipped aircraft did not lead to confusion and safety critical communication errors (cf. item 4-T, 18-T. and 19-T, Table 3-6). They also rejected formerly mentioned constraints, that they would be distracted by TAXI-CPDLC from looking outside and that they would be unsettled by too many input requests to operate TAXI-CPDLC (cf. item 14-T and 15-T, Table 3-6).

EMMA2



In the on-site trials at Prague Airport the technical and operational feasibility was proven as well. Via VDL Mode 2 and ATN clearances could be exchanged between the flying test aircraft, operated by pilots via the CDTI, and the controller working positions, operated by the ATCOs in the Tower. During the debriefing sessions also interviews were performed with the ATCOs. The following conclusions reflect a common opinion of all six ATCOs. If there were contrary opinions or assumption only, it was added that further testing would be necessary. The concluding notes mainly address aspects of the operational feasibility and proposals for improvement of the new A-SMGCS services:

• In general - TAXI-CPDLC with Start-up, Pushback, Taxi-out and TAXI-in, and the silent

handover worked fine and with some exceptions was fully accepted by the ATCOs. • The handover was initiated by data link by “CONTACT LKPR GROUND 121.900” but the

initial call with the next control position was done by voice. This procedure was very much appreciated by the ATCOs because it would ensure that voice contact is established and can act as back up in case TAXI-CPDLC failed or for non-routine communication. Following phraseology was tested and accepted:

o Pilot: “Ruzynĕ Ground, DLH621 on your frequency” o ATC: “DLH621 follow data link” o Pilot: “Following data link, DLH621”

This phraseology was seen as safe and unambiguous. However, it was proposed that this phraseology can even be shorten when the TAXI-CPDLC is used operational and users are more familiar with this new service.

• With outbound traffic the GEC transmitted the complete taxi-out clearance including the

clearance limit, which is usually a runway to be crossed: “TAXI TO HOLDINGPOINT F RWY 06 VIA TWY P L F HOLD SHORT OF RWY 13 NEXT EXPECT VIA TWY F” or the holding point of the departure runway itself: “TAXI TO HOLDINGPOINT A RWY 24 VIA TWY P L H A”. Close to that clearance limit the GEC handed over the flight to TEC by “CONTACT LKPR TOWER 118.100” and the TEC continued control by voice communication only. This procedure worked very in the ATCOs’ opinion.

• It was stated by an ATCO that a TAXI-CPDLC message for crossing might be an option

worth to be tested. A TAXI-CPDLC crossing clearance would also solve the operational problem that the stop bar on the pilots onboard display would be switched off by an ATC clearance instead of pilots switch it off in accordance to the voice crossing clearance, which is not correct from an operational point of view.

• On the other hand, time and safety-critical instructions or clearances like line-up, take-off and

landing, or a “hold position” command, should be given by voice for the time being. To finally validate or reject them would need further investigation.

• With inbound traffic the GEC provided the taxi-in route to the final parking position by

TAXI-CPDLC , e.g. “TAXI TO STAND S17 VIA TWY F L P”. This procedures was well accepted by the ATCOs.

• Dealing with a TAXI-CPDLC revised taxi route while taxiing was seen as potential feasible

by the ATCOs, but would need further testing to confirm it definitely. It seemed that this procedure is very much dependent on the actual traffic situation. However, ATCOs are never forced to do use TAXI-CPDLC.

• Prerequisite for transmitting taxi clearances by data link is that the correct taxi route has been

computed and pre-selected by the routing function or that alternative routes can easily be selected. A manual input of a taxi route would hardly be accepted.

EMMA2



• The pilots acknowledgement to a datalink clearance by a “WILCO” or “UNABLE” message was well appreciated by the ATCOs. A “ROGE”R or “STAND BY” answer was not tested.

• Instead of a positive LACK each time, indicating that a message has been successfully

delivered to the pilots CDTI, the ATCOs would wish to be informed only in case of a transmission failure.

• An acoustic signal for incoming TAXI-CPLDC could be helpful to attract attention to an

incoming message. Further testing would be necessary to confirm this. Conformance Monitoring Alerting When the system is informed about the cleared taxi route, the current clearance status, and also knows the current position of a flight, additional safety nets can be exploited by an A-SMGCS. Two of these safety nets, route deviation alerting and clearance conformance monitoring have been implemented in the A-SMGCS at Prague Tower. During the trials the new safety nets were shown to the ATCOs, but their feedback was not taken into account in this report because it became clear that these safety nets would need further tuning and testing in order to minimise nuisance alerts and provide the desired alerts at the right time. This tuning could not be completed during the simulation trails and would need further long-term testing and adjustment.

5.2 Conclusions to Operational Improvements Having proven the services for their operational feasibility, questions to their contribution to operational improvements arise, which will be summarised in this section. In accordance to the EMMA2 high level objectives [4] indicators were derived in this document (cf. 3.1.6), and the outcome is reported in the following: In the present test setting, it has to be considered that an A-SMGCS level 1&2 was the baseline, which was compared against the higher-level A-SMGCS services. Since A-SMGCS level 1&2 already contributes a lot to safety and efficiency the benefit effects to be expected were not that high that they could be revealed easily in the present test setting. Additionally, new services like TAXI-CPDLC and new safety nets are rather new services with an E-OCVM target level of maturity from V1-V2 and thus were tested for their operational feasibility primarily. A V3 level of maturity was allocated to EFS and DMAN. EFS itself however is not expected to contribute directly to safety and efficiency but is more a carrier for the new services, but with DMAN some effects in terms of operational improvements were gained. Operational improvements were measured objectively and subjectively. Subjectively the ATCOs rated significantly that

• the DMAN enables them to work more efficiently, • DMAN avoids excessive queues at the runway entry points, and • reduces taxi times. • The EFS improve their situation awareness and • TAXI-CPDLC reduces the time spent by R/T voice communication (cf. Table 3-6 and

§3.3.6). These subjectively gained results are supported by the objectively measured ones: Taxi times and Stop times As the taxi speed in the simulation trials is constant due to the fact they are managed by the simulation itself, stop times during taxiing from stand until take-off and from runway vacation until the final stand is the more interesting indicator. When DMAN was used, stop times during taxing could

EMMA2



significantly be reduced from an average of 1:33 to 1:09 minutes, which correspond to a 26% reduction of stop times (see results in Table 3-13). This effect of reduced stop times during taxiing is caused by the DMAN’s smoothing of departure peaks by exploiting the 15 minutes CTOT time window. The problem nowadays is that during departure peaks, there are frequently several outbound flights taxiing to the runway at the same time, resulting in an accumulation of aircraft at the runway entry point. Instead, the DMAN would keep the aircraft at the stand until a free “runway slot” is predicted, as long as the stand is not needed by another flight. Taking into account this calculated “runway slot” (TTOT), the DMAN computes a TSAT that is in accordance to the flight plan constraints and the current traffic situation. This procedures smoothes the outbound peak which can also be seen in “Table 3-17: Mean Departure Throughput”: During the departure peak, that lasted 20min of the overall 60min simulated traffic scenario, 12.3 aircraft were taking off in average, with DMAN’s equalisation process there were only 10.2 departing aircraft in this period. Such a balanced outbound traffic deals with less waiting at the runway entry point. As long as the CTOTs are not violated, stands for arrivals are not blocked by withhold departures, such a procedure is probably more efficient than pushing the departures going outbound in a short period, which would result in a high throughput peak but increased stop and go traffic in throughout the manoeuvring area. Nevertheless, it has been shown again that the planning of outbound traffic is a very complex process. There are many variables, which have to be considered by a departure manager: some of them well known in advance, others can hardly be predicted or can change suddenly. Additionally there are local particularities that have to be taken into account by a departure planning (e.g. different possibilities for runway entry points, standard taxi routes and times, runway dependencies, SID dependencies, etc.). The simulation revealed that there is still room to better adapt the DMAN to the Airport Prague constraints and also, that such an adaptation would take a certain amount of time. The integration of a DMAN into a CDM environment is also considered beneficial, as the DMAN would have access to more reliable flight plan information.

EMMA2



6 Annex I

6.1 References [1] EC/EUROCONTROL, European Operational Concept Validation Methodology – E-OCVM,

Version 2, 2008. March 2007.

[2] EMMA2, 2-D1.1.1, A-SMGCS Services, Procedures, and Operational Requirements (SPOR), V1.0, December 2008, www.dlr.de/emma2.

[3] EMMA2, 2-D6.1.1A, Validation Plan, V1.0, October 2008, www.dlr.de/emma2. [4] EMMA2, 2-D6.1.1B, Generic Experimental and Test Plan, V1.0, 2010 [5] EMMA2, 2-D6.1.3, Validation Test Plan Prague, V1.0, 2008, www.dlr.de/emma2. [6] EMMA2, 2-D6.6.1A, Airborne Validation Results Part A, V1.0, 2010. [7] EMMA2, 2-D6.7.1, Validation Comparative Analysis Report, V1.0, 2009. [8] EUROCONTROL, Airport CDM Implementation, October 2006. [9] ICAO, Doc 9830 AN/452, Advanced Surface Movement Guidance and Control System (A-

SMGCS) Manual, First Edition, 2004 [10] Jürgen Bortz, Statistik für Sozialwissenschaftler, Springer Verlag Berlin Heidelberg, 1993.

EMMA2



6.2 Abbreviations Acronym Meaning ACAS Airborne Collision Avoidance System ADS Automatic Dependent Surveillance ADS-B Automatic Dependent Surveillance Broadcast AGL Aerodrome Ground Lighting AGL Above Ground Level AIBT Actual In-Block Time AIP Aeronautical Information Publication ALDT Actual Landing Time AMAN Arrival Manager AMM Airport Moving Map AMS ANS CR Air Navigation Services of the Czech Republic ANSP Air Navigation Service Provider AOBT Actual Off-Block Time AOCC Air Operations Control Centre APN Apron Control ARP Aerodrome Reference Point A-SMGCS Advanced Surface Movement Guidance and Control Systems ASR Airport Surveillance Radar ASTERIX All-purpose Structured Eurocontrol Radar Information Exchanged ATC Air Traffic Control ATCO Air Traffic Controller ATFM Air Traffic Flow Management ATIS Automatic Terminal Information Service ATM Air Traffic Management ATOT Actual Take Off Time ATS Air Traffic Services ATSU Air Traffic Service Unit AVOL Aerodrome Visibility Operational Level AXIT Actual Taxi-In Time AXOT Actual Taxi-Out Time BETA operational Benefit Evaluation by Testing an A-SMGCS BITE Built-In Test Equipment CDD Clearance Delivery Dispatch(er) CDM Collaborative Decision Making CPDLC Controller Pilot Data Link Communication CPT Captain (Flight Crew) CTOT Calculated Take Off Time (CFMU) CWP Controller Working Position DCDU Data Link Control And Display Unit DCL Departure Clearance df Degrees of freedom DMAN Departure Manager EC European Commission EFIS Electronic Flight Instrument System EFS Electronic Flight Strips EIBT Estimated In-Block Time

EMMA2



Acronym Meaning ELDT Estimated Landing Time EMM Electronic Moving Map EMMA European airport Movement Management by A-SMGCS EOBT Estimated Off-Block Time E-OCVM ‘EUROPEAN’ Operational Concept Validation Methodology ESUP Eurocat Support system ETA Estimated Time of Arrival ETD Estimated Time of Departure ETOT Estimated Take Off Time ETTT Estimated Turn-round Time EU European Union EUROCAE European Organisation for Civil Aviation Equipment EUROCONTROL European Organisation for the Safety of Air Navigation EXOT Estimated Taxi-Out Time F F value in the F statistics FAT Factory Acceptance Test FDPS Flight Data Processing System FMS Flight Management System FO First Officer (Flight Crew) FPL Filed Flight Plan GEC Ground Executive Controller GFS Gap Filler System GTD Ground Traffic Display HLO High Level Objectives HMI Human-Machine Interaction HW Hardware ICAO International Civil Aviation Organisation ID Identifier IFR Instrument Flight Rules IHP Intermediate Holding Position ILS Instrument Landing System IMC Instrument Meteorological Conditions IP Internet Protocol LAN Local Area Network LAT Latitude LCD Liquid Crystal Display LLO Low Level Objectives LON Longitude LVP Low Visibility Procedures M Mean MASPS Minimum Aircraft System Performance Specification MCDU Multifunctional Control and Display Unit MET Meteorological MLAT Multi-Lateration p p-value (error probability that the measured mean belongs to the H0 hypothesis) PAS Park Air Systems AS PF Pilot Flying PFD Probability of False Detection PNF Pilot Non-Flying PRG Prague PSR Primary Surveillance Radar

EMMA2



Acronym Meaning QE-OF EMMA2 Operational Feasibility Questionnaire (PRG) QE-QI EMMA2 Operational Improvement Questionnaire (PRG) R/T Radio telephony RCMS Remote Control and Monitoring System RDPS Radar Data Processing System RET Rapid Exit Taxiway RIMS Runway Incursion Monitoring System RP Route Planning RPA Reported Position Accuracy RPS Recording and Playback System RTUC Recommended Time Until next Clearance RVR Runway Visual Range RWY Runway SARPS Standards and Recommended Practices SAT Site Acceptance Test SD Standard Deviation SDF Sensor Data Fusion SDS Surveillance Data Server SGMAN Stand and Gate Manager SID Standard Instrument Departure SIT1 CFMU Slot Issue Time SMGCS Surface Movement Guidance and Control Systems SMR Surface Movement Radar SOBT Scheduled Off-Block Time SP Sub-Project SPOR A-SMGCS Services, Procedures, and Operational Requirements SQB Squitter Beacon SSR Secondary Surveillance Radar STAR Standard Terminal Arrival Route STBY Stand By STCA Short Time Conflict Alert SW Software SWIM System Wide Information Management TA/RA Traffic Advisory/Resolution Advisory TAXI-CPDLC TAXI – Controller Pilot Data Link Communication TCAS Traffic alert and Collision Avoidance System TCD Traffic Conflict Detection TEC Tower Executive Controller TECAMS Technical Control and Monitoring System TIS-B Traffic Information System Broadcast TOBT Target Off-Block Time TPC Tower Planning Controller TRD Technical Requirements Document TSAT Target Start-up Approval Time TSD Traffic Situation Display TTOT Target Take-Off Time TWR Aerodrome Control Tower TWY Taxiway V&V Verification and Validation VFR Visual Flight Rules VMC Visual Meteorological Conditions

EMMA2



Acronym Meaning WP Work-Package WVC Wake Vortex Category

6.3 List of Figures Figure 2-1: Gantt Chart of Validation Activities in 2-WP6.3 ............................................................ 8 Figure 3-1: ATS 300° Visual System...................................................................................................... 9 Figure 3-2: Set-up of the Controller Working Positions of the Experimental System.......................... 10 Figure 3-3: Means for I.S.A. Workload w.r.t. the A-SMGCS treatment and the ATCO role............... 52 Figure 3-4: Means for I.S.A. Situation Awareness w.r.t. the A-SMGCS treatment and the ATCO role

....................................................................................................................................................... 54 Figure 4-1: Three ANS CR ATCOs working in Shadow Mode at the three EMMA2 CWPs in the test

bed room of the Tower Prague ...................................................................................................... 58 Figure 4-2: DLR ATTAS Test Aircraft (D-ADAM)............................................................................. 59 Figure 4-3: EFS Screenshot: Test Aircraft (D-ADAM) requests a Taxi-out Clearance by TAXI-

CPDLC .......................................................................................................................................... 65

6.4 List of Tables Table 3-1: Experimental Design: Treatment Levels and Allocation of ATCO Role & Traffic Scenarios

....................................................................................................................................................... 11 Table 3-2: Traffic details of the used Traffic Scenario EXE06............................................................. 13 Table 3-3: Demographical Description of the ATCOs participating at the RTS1 & RTS2 .................. 14 Table 3-4: Test Schedule including treatment, allocation of ATCOs to the CWP and Pilots to the

Cockpit positions, Validation Area and the used traffic scenario ................................................. 16 Table 3-5: Metrics and Indicators (RTS)............................................................................................... 20 Table 3-6: QE-OF - Means, N, SD, and P-Value.................................................................................. 33 Table 3-7: Particularities occurred with each test run ........................................................................... 45 Table 3-8: Raw data “Mean Departure Deviation” (absolute, minutes)................................................ 46 Table 3-9: One-way repeated measures ANOVA “Mean Departure Deviation”.................................. 46 Table 3-10: CTOT Violations ............................................................................................................... 47 Table 3-11: Raw Data “Stop Time During Taxiing” (minutes) ............................................................ 48 Table 3-12: Bar chart for means of “Stop Time During Taxiing” (minutes) ........................................ 48 Table 3-13: One-way repeated measures ANOVA “Stop Time During Taxiing” ................................ 48 Table 3-14: Raw data “Taxi Time” (minutes) ....................................................................................... 49 Table 3-15: Bar chart for means of “Taxi Time” (minutes) .................................................................. 49 Table 3-16: One-way repeated measures ANOVA “Taxi Time”.......................................................... 49 Table 3-17: Mean Departure Throughput.............................................................................................. 50 Table 3-18: Maximum Queue Length ................................................................................................... 50 Table 3-19: R/T Communication .......................................................................................................... 51 Table 3-20: Raw Data I.S.A for Workload............................................................................................ 52 Table 3-21: Two-way repeated measures ANOVA “I.S.A. Workload” ............................................... 52 Table 3-22: Raw Data I.S.A for Situation Awareness........................................................................... 53 Table 3-23: Two-way repeated measures ANOVA “ I.S.A. Situation Awareness”.............................. 54 Table 3-24: Raw Data of the QE-QI ..................................................................................................... 55 Table 3-25: QE-OI - Means, N, SD, and P-Value................................................................................. 57 Table 4-1: Estimated traffic amount (local time) .................................................................................. 60 Table 4-2: Demographical Description of the ATCOs participating at the Prague On-site Trials........ 61 Table 4-3: ATCOs’ executed Test Runs in the Tower Test Bed........................................................... 61 Table 4-4: Pilots’ executed Test Runs in the ATTAS Test Aircraft ..................................................... 61 Table 4-5: Metrics and Indicators (OST) .............................................................................................. 62 Table 7-1: Flight Plan of Traffic Scenario EXE02.............................................................................. 137

EMMA2



Table 7-2: Flight Plan of Traffic Scenario EXE04.............................................................................. 138 Table 7-3: Raw Data of the QE-OF (RTS1)........................................................................................ 140 Table 7-4: Raw Data of the QE-OI (RTS1)......................................................................................... 140 Table 7-5: Raw Data I.S.A for Workload (RTS1)............................................................................... 141 Table 7-6: Raw Data of SASHA questionnaire (RTS1)...................................................................... 141 Table 7-7: Raw Data of SUS questionnaire (RTS1) ........................................................................... 141 Table 7-8: Raw Data of the QE-QF (RTS2 + OST)............................................................................ 143

EMMA2



7 Annex II

7.1 Decision on EMMA2 Operational Requirements (Checklist) The following checklist contains the decision about the EMMA2 operational requirements based on V&V activities performed in WP6.3 – “Test-site Prague”. They can either be fully VERIFIED, PARTLY VERIFIED, NOT VERIFIED or OTHERS (e.g. not tested or only partly implemented). Dependent on the character of the requirement this decision is met by a technician of the Prague test team, by the answers of the user after the operational use of the system, or by both. There is an additional field COMMENTS giving the chance to explain the judgements or results. When requirements need to be verified also by a user, they were transformed into statements/questions in the “EMMA2 Operational Feasibility Questionnaire, (QE-OF)”, which was presented to the user after having operated the new system in real time simulations and in on-site shadow mode trials. Those requirements are marked in the third column by having written down the ID of the QE-OF, followed by the column, which indicates the MEAN value of the answers and their significance15. Date: 2008-12-04 Scrutiniser: Gilbert (PAS) / Jakobi (DLR) Test Subjects 7 ANS CR ATCOs Test Site: Prague Test Phase: RTS1, RTS2, OST

15 Answers are possible between 1 and 6, that is, the mean value is expected by 3,5. Lower means indicate the users’ disagreement to the fulfilment of an operational requirement. Those means will be colored in red. Means higher than the expected mean value 3,5 have been tested for their statistical significance by a binominal test with an α error probability of .05. Significant answers are colored in green. Only MEAN values caused by more than four ATCOs are reported in order to not to pretend common ATCO opinions, which are not in fact.



General Requirements

Op. Requ. ID (SPOR) Operational Requirement

ID EMMA2 QE-OF

item

Mean of QE-OF

item (* marks signific.) Ve

rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GEN_Serv-01 An A-SMGCS should support the following primary functions:

a) Surveillance By definition

b) Routing By definition

c) Guidance By definition

d) Control By definition

GEN_Serv-02_ Planning Function

In order to achieve the maximum benefits of each level of A-SMGCS implementation, a supporting planning function should be included.

By definition

GEN_Serv-03_ Visibility Conditions

A-SMGCS should be capable of operating at a specified movement rate in visibility conditions down to AVOL. When visibility conditions are reduced to below AVOL, an A-SMGCS should provide for a reduction of surface movements of aircraft and vehicles to a level acceptable for the new situation.

Not tested in EMMA2 in Prague, but has been verified by operational use of A-SMGCS.

GEN_Serv-04_ Provision of Information

The system should integrate movements to provide complete situational information to all users, 1-G 5,00*

and to provide conflict prediction and resolution for aircraft and vehicle movements.

Automated conflict resolution has not been addressed by EMMA2 in Prague.




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GEN_Serv-05_ Modularity

A-SMGCS should be modular so that the appropriate level of service can be provided to different aerodromes as well as to different areas of an aerodrome. Note: [EMMA2] Each aerodrome has its own operational needs and technological constraints. So each aerodrome will only implement the A-SMGCS modules fitting its needs and its technological choices in order to minimize the cost of I-SMGCS. Consequently, A-SMGCS consists of many elements which, when integrated, are designed to meet the specific operational requirements of an aerodrome.

Verified by technical tests.

GEN_Serv-06_ Users’ Responsibilities

Although the responsibilities and functions may vary, they should be clearly defined for all users of the system. 2-G 5,17*

GEN_Serv-07_Responsibility Assignment

An A-SMGCS should be designed so that the responsibilities and functions may be assigned to the following:

e) the automated system; f) controllers; g) pilots; h) vehicle drivers; i) marshallers; j) emergency services; k) airport authorities; l) regulatory authorities; and m) security services

Note: When A-SMGCS is in operation, pilots remain responsible for the safety and control of aircraft. Note 1: [EUROCONTROL] The allocation of functions and/or responsibilities might differ depending on visibility condition,

Not tested in EMMA2 in Prague, but has been verified by operational use of A-SMGCS.




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

level of automation and level of implementation of an A-SMGCS. A different division of functions among the control personnel (e.g. between authorities responsible for aerodrome movement control and apron management services) may also be necessary as a result of possible changes in procedures caused by automation. Note 2: [EUROCONTROL] ATC will be responsible for the management and overall operation of the system. When certain functions will be delegated to automated elements of the system, responsibilities for the integrity and reliability of those functions lie with the service providers, certification authorities, manufacturers and software suppliers. Note 3: [EUROCONTROL] ATC controllers and pilots are the only critical decision makers. Their decisions are based on surveillance data which have a specified integrity.

GEN_Serv-08_ Modular Enhancement

The design principle of an A-SMGCS should permit modular enhancements. Note: [EMMA2] A-SMGCS will evolve from a SMGCS by progressive enhancements to match the desired level of operations. The competent authority will determine, in consultation with the users, whether existing SMGCS needs to be upgraded to A-SMGCS. A-SMGCS for each aerodrome will comprise a different mix of modular components dependent upon operational factors.

The EMMA2 test-bed system in Prague was built by modular enhancement of the EMMA test-bed.




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GEN_Serv-09_ Equipment Status

The operational status of surveillance equipment should be monitored by the system, and alerts should be provided as appropriate. Note: [EMMA2]: For this requirement ‘surveillance equipment’ should be replaced by ‘all A-SMGCS equipment’.


GEN_Serv-10_ Design Concept

The A-SMGCS design concept should be built upon the integration of the fundamental and principal system elements and facilitate the upgrading of those elements whilst maintaining, where possible, the same HMI and references. This is important when considering harmonisation, familiarisation and training requirements, and will allow the evolution of the system design to a full A-SMGCS with the minimum negative impact on the users’ ability to interface with the system.

3-G 4,33*

GEN_Serv-11_ Aircraft Types 1

An A-SMGCS should support operations involving all aircraft types. 4-G 5,29*

Verified for all aircraft types using the aerodrome during the test period.

GEN_Serv-12_ Aircraft Types 2

An A-SMGCS should be capable of adaptation to cater for future aircraft types. Note: [EMMA2] Future ‘aircraft types’ have to be restricted to those ‘aircraft types’ that are already foreseeable to exist in the future.

There are no obvious limitations in the A-SMGCS equipment regarding aircraft types. There may be restrictions due to aerodrome layout, wake vortex separation requirements, etc.




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GEN_Serv-13_ Vehicle

An A-SMGCS should be capable of being used by appropriately equipped vehicles operating within the movement area.

5-G 5,29* All vehicles using the movement area of the aerodrome are equipped with Mode S squitter beacons.

GEN_Serv-14_ Susceptibility

The system should not be affected by: a) Radio interference, including that produced by

navigation, telecommunications and radar facilities (including airborne equipment);

b) Signal reflections and shadowing caused by aircraft, vehicles, buildings, snow banks or other raised obstacles (fixed or temporary) in or near the aerodrome environment; and

c) Meteorological conditions or any state of the aerodrome resulting from adverse weather in which operations would otherwise be possible.

6-G 4,83 Not subject to specific testing in EMMA2 in Prague, but has been verified by operational use of A-SMGCS.

GEN_Serv-15_ System Status

Equipment that shows control data should be both fail-safe and fail-soft. Note: The term ‘fail-safe’ in this context means that sufficient redundancy is provided to carry data to the display equipment to permit some components of the equipment to fail without any resultant loss of data displayed. The term ‘fail-soft’ means that the system is so designed that, even if equipment fails to the extent that loss of some data occurs, sufficient data remain on the display to enable the controller to continue operations.

Not subject to specific testing in EMMA2 in Prague, but has been verified by operational use of A-SMGCS.




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GEN_Serv-16_ Failure Effect

In case of a failure of an element of an A-SMGCS, the failure effect should be such that the status is always in the ‘safe’ condition. Note: [EMMA2] For instance, the element should not provide wrong data that could impact on safety.

7-G 4,40* Not subject to specific testing in EMMA2 in Prague, but has been verified by operational use of A-SMGCS.

GEN_Serv-17_ Failure Indication

All critical elements of the system should be provided with timely audio and visual indications of failure.

Verified by technical tests. No common statement of ANS CR ATCOs whether they need them or not – requires more testing.

GEN_Serv-18_ Self-Restartable

An A-SMGCS should be self-restartable. The recovery time should be a few seconds. Note: [EMMA2] ICAO gives no rationale for this requirement. It is unlikely that current equipment would meet this requirement. ‘Few minutes’ would be more realistic.

The equipment elements of A-SMGCS are self-restartable, but recovery times of a few seconds are unrealistic for modern computer equipment.

GEN_Serv-19_ Restart

The restart of an A-SMGCS should include the restoration of pertinent information on actual traffic and system performance.


GEN_Serv-20_ Operational Change

An A-SMGCS should be capable of accommodating any change in the layout of the aerodrome (runways, taxiways and aprons). Note: [EUROCONTROL] The A-SMGCS should also be capable of accommodating any change in procedures and operational rules at the aerodrome.

8-G 5,00* Verified for actual layout changes at Prague during the implementation and test period.




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

In order to fully benefit from an A-SMGCS by all parties concerned, the system should be capable of interfacing with the following:

The A-SMGCS test-bed at Prague was interfaced existing ATM and airport systems.

a) Air traffic management (ATM), including:

1) Arrival and departure management; Only DMAN implemented for EMMA2

2) Arrival and departure coordination;

3) Optimized start-up sequence and times;

4) Optimized push-back sequence and times; and

5) Integrated initial flight plan processing system, central flow management unit, etc.;

Connection to CFMU not implemented for EMMA2 in Prague.

b) Aerodrome management systems;

c) Existing and future ATS systems;

d) Meteorological systems; Not implemented for EMMA2

e) Visual aids;

GEN_Serv-21_ Interfaces

f) Existing and future avionics;




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

g) Aerodrome handling systems; Not implemented for EMMA2

h) Aircraft operators; Not implemented for EMMA2

i) Emergency authorities; Not implemented for EMMA2

j) Police/security authorities; and Not implemented for EMMA2

k) Other customers or users. Not implemented for EMMA2

GEN_Serv-22_ User Interface

A-SMGCS should enable users to interface and function efficiently. 9-G 4,00

GEN_Serv-23_ Adaptation to Local Procedures

In order to efficiently assist the ATCO, the automated A-SMGCS services should be configurable to adapt to local ATC procedures and working methods.

10-G 5,00*

GEN_Serv-24_ Integrity

The system design should preclude failures that result in erroneous data for operationally significant time periods. 11-G 4,33

GEN_Serv-25_ Data Validation

The system should have the ability to provide continuous validation of data and timely alerts to the user when the system must not be used for the intended operation.

12-G 5,29*

GEN Serv-26Availability

The availability of an A-SMGCS should be sufficient to support the safe, orderly and expeditious flow of traffic on the movement area of an aerodrome down to its AVOL.

13-G 5,14*




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GEN Serv-27Continuity of Service 1

An A-SMGCS should provide a continuous service.

14-G 5,67*

GEN Serv-28Continuity of Service 2

Any unscheduled break in operations should be sufficiently short or rare as not to affect the safety of aircraft using the system. 15-G not affected

(n.a.) No breaks in operations occurred during the test sessions.

GEN_Serv-29_ Performance Monitoring

Monitoring of the performance of an A-SMGCS should be provided such that operationally significant failures are detected and remedial action is initiated to restore the service or provide a reduced level of service.

16-G not affected (n.a.)

Verified by technical tests and by operational use of A-SMGCS at Prague.

GEN_Serv-30_ Self-Checking System

An A-SMGCS should be designed with the appropriate level of redundancy and fault tolerance in accordance with the safety requirements. A self-checking system with failure alerts should be included in the system design.

Redundancy not implemented for EMMA2 in Prague, but has been verified by operational use of A-SMGCS.

GEN Serv-31Reliability

A failure of equipment should not cause: a) A reduction in safety (fail soft); and


b) The loss of basic functions.





ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GEN_Serv-32_ Back-up

The system should allow for a reversion to adequate back-up procedures if failures in excess of the operationally significant period occur.

17-G 5,00*

Not subject to specific testing in EMMA2 in Prague, means, not all possible failures occurred or were evoked. But Level 2 services have been verified by operational use of A-SMGCS.

GEN_Serv-33_ System Failures

Operationally significant failures in the system should be clearly indicated to the control authority and any affected user. 18-G not affected

(n.a.) Not subject to specific testing in EMMA2 in Prague, but has been verified by operational use of A-SMGCS.

The system should be capable of supporting operations of aircraft and vehicles within the following parameters: a) Minimum and maximum speeds for aircraft on final

approach, missed approach and runways;

19-G 5,17* Not subject to specific testing in EMMA2 in Prague, but has been verified by operational use of A-SMGCS.

b) Minimum and maximum speeds for aircraft on taxiways;


c) Minimum and maximum speeds for vehicles; and


GEN_Perf-01_ Speeds and Orientations

d) Any heading.





ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GEN_Perf-02_ Capacity

The A-SMGCS should be able to handle all aircraft and vehicles that are on the movement area at any time. Note 1: [EMMA2] Since capacity is a site-specific parameter, the determination of the maximum number of aircraft on the movement area should be based on the assumed peak traffic at the aerodrome. Aerodromes continually strive to increase capacity and therefore the number of movements, and hence aircraft and vehicles will probably increase over time. The A-SMGCS capacity figure should be sufficient to cater for expansion of this nature and reviewed on a regular basis to ensure that it is sufficient. Note 2: [EMMA2] The A-SMGCS also needs sufficient capacity to handle obstacles on the movement area and traffic within the other areas of interest, e.g. aircraft on approach, helicopters, etc.

20-G not affected (n.a.) Not subject to specific testing

in EMMA2 in Prague, but has been verified by simulation.

The A-SMGCS should be able to accommodate the following speeds determined to within ± 2 km/h (1 kt):

a) 0 to 93 km/h (50 kt) for aircraft on straight taxiways;

Not subject to specific testing in EMMA2 in Prague.

b) 0 to 36 km/h (20 kt) for aircraft on taxiway curves; Not subject to specific testing in EMMA2 in Prague.

c) 0 to 20 km/h (10 kt) for aircraft and vehicles on stands and stand taxi lanes. Not subject to specific testing

in EMMA2 in Prague.

GEN_Perf-03_ Velocity

d) 0 to 150 km/h (80 kt) for aircraft on runway exits; Not subject to specific testing in EMMA2 in Prague.




ID EMMA2 QE-OF

item

Mean of QE-OF


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

e) 0 to 460 km/h (250 knots) for aircraft on final approach, missed approach and runways; Not subject to specific testing

in EMMA2 in Prague.

f) 0 to 150 km/h (80 kt) for vehicles on the movement area; and Not subject to specific testing

in EMMA2 in Prague.

Note 1: [EMMA2] ICAO provides no rationale for the 1 kt accuracy requirement, which seems unnecessarily stringent and is not consistent with the surveillance position accuracy and update rate requirements. It may be useful for the pilot/driver to know own aircraft/vehicle speed with such accuracy, but for the controller it is not important. [EUROCAE-MASPS] requires Reported Velocity Accuracy < 5m/s (10 kt), which is more realistic.

Surveillance Requirements


ID EMMA2 OF QE item

Mean of EMMA2 QE item (* marks signific.) Ve

rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

SURV_Serv-01_Surveillance Function 1

The surveillance function of an A-SMGCS should provide accurate position information on all movements within the movement area. Note: [EMMA2] ‘Movement area’ should be replaced by ‘A-SMGCS coverage area’, which includes the approach area.

1-S 5,50*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments


The surveillance function of an A-SMGCS should provide identification and labelling of authorized movements.

2-S 5,33*


The surveillance function of an A-SMGCS should cope with moving and static aircraft and vehicles, within the coverage area of the surveillance function.

3-S 5,33*


The surveillance function of an A-SMGCS should be capable of updating data needed for the guidance and control requirements both in time and position along the route. Note: [EMMA2] ‘Data to be updated’ are not sufficiently identified by this requirement.

4-S 5,33*

SURV_Serv-05_Operating Conditions

The surveillance function of an A-SMGCS should be unaffected by operationally significant effects such as adverse weather and topographical conditions. Note: [EMMA2] This is already covered by ICAO requirement §2.6.5.

5-S 5,17*


SURV_Serv-06_Coverage 1

Within the required area of the aerodrome, surveillance should be provided up to an altitude so as to cover missed approaches and low-level helicopter operations.

Not subject to specific testing in EMMA2 in Prague, but has been verified in EMMA and by operational use of A-SMGCS.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

SURV_Serv-07_Coverage 2

Surveillance should be provided for aircraft on approach to each runway at such a distance that inbound aircraft can be integrated into an A-SMGCS operation so that aerodrome movements, including aircraft departures or aircraft crossing active runways, can be managed.


SURV_Serv-08_Seamless Transition

A seamless transition should be provided between the surveillance for an A-SMGCS and the surveillance of traffic in the vicinity of an aerodrome.

6-S 5,17*

SURV_Serv-09_Detection of Obstacles

The A-SMGCS should detect obstacles, whether moving or stationary, located anywhere on the movement area of the aerodrome and having an equivalent radar cross section of 1 square metre or more. Note 1: [EMMA2] An A-SMGCS is not designed to detect every kind of obstacle. The ATCO, as the main user of an A-SMGCS, is also not responsible for detecting obstacles. The airport authority is responsible for ensuring that the manoeuvring area is ‘free of obstacles’ [ICAO Annex 14 & Doc. 9476].

Not subject to specific testing in EMMA2 in Prague, but has been verified by operational use of A-SMGCS and by technical tests.

SURV_Serv-10_Airport Traffic Situation

The surveillance service should continuously provide the airport traffic situation, comprising:

Traffic information; Traffic context.





ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

SURV_Serv-11_Traffic Information 1

The surveillance service should continuously provide the following traffic information on the movement area, excluding passive and empty stands:

a) Position of all vehicles, b) Identity of all cooperative vehicles, c) Position of all aircraft, d) Identity of all cooperative aircraft, e) Position of all obstacles (cf. SURV_Serv-

09_Detection of Obstacles) f) History of the aircraft/vehicle positions (e. g. the 3 last

positions displayed) Note: The surveillance service should continuously provide the position and identity of all cooperative aircraft, including helicopters, within the entire coverage area.


SURV_Serv-12_Traffic Information 2

Other information about traffic is a local issue to be decided by the ATC Service provider, but should include at least the following information:

a) Vehicle type b) Aircraft type c) Aircraft gate d) Departure runway


SURV_Serv-13_Manual Labelling

The surveillance service should provide to the user the ability to manually put the right call sign in the label associated to a vehicle equipped with co-operative equipment used for different vehicles.

7-S 4,83 Was not properly working in the simulation trails, but has been verified by operational use of A-SMGCS.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

In order to determine the reliability of the A-SMGCS surveillance function, the following parameters should be considered in the specification of surveillance equipment:

a) Probability of detection (PD) – the probability that an aircraft, vehicle or object is detected and displayed;

(1-S) 5,50*

b) Probability of false detection (PFD) – the probability that anything other than an aircraft, vehicle or object is detected and displayed;

(1-S) 5,50*

c) Probability of identification (PID) – the probability that the correct identity of an aircraft, vehicle or object is displayed; and

2-S 5,33*

d) Probability of false identification (PFID) – the probability that the displayed identity of the aircraft, vehicle or object is not correct.

2-S 5,33*

SURV_Perf-01_ Surveillance Reliability

Note: [EMMA2] In order to reasonably assess the reliability of an A-SMGCS surveillance service from an operational point of view, it is suggested to assess not only the overall probability of detection and identification of each movement but also the continuity of all aircraft and vehicle tracks over a longer period. ‘Continuity’ would be expressed by the number and lengths of detection or identification gaps related to the expected number of tracks.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

SURV_Perf-02_ Speed

The A-SMGCS should accommodate all aircraft and vehicle speeds that will be used within the coverage area with sufficient accuracy.


SURV_Perf-03_ Reported Position Accuracy

The actual position of an aircraft, vehicle or obstacle on the surface should be determined within a radius of 7.5 m. Note 1: [EUROCAE] The reported position accuracy should not exceed 7.5m on the manoeuvring area and 12m on the aprons (both at a confidence level of 95%). Note 2: [EMMA2] The operational need for a specific accuracy may vary with different areas of interest (e.g. on runways, on taxiway, on stop bars). This is not specified by ICAO. It should be sufficient to meet the various needs of the users.

1-S 5,50* Not subject to specific testing in EMMA2 in Prague, but has been verified by operational use of A-SMGCS and by technical tests.

SURV_Perf-04_ Altitude Accuracy

Where airborne traffic participates in the A-SMGCS, the level of an aircraft when airborne should be determined within ±10m. Note: [EMMA2] Justification has not been provided for the need of this accuracy of aircraft altitude for A-SMGCS. However, it has been decided to keep this requirement as such in the document because it is provided by ICAO. If no more information about this requirement is provided so far, the validation activity will determine the status of this requirement.

1-S 5,50* Not subject to specific testing in EMMA2 in Prague.

SURV_Perf-05_ Update Rate

The position and identification data of aircraft and vehicles should be updated at least once per second. 4-S 5,33*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

Note 1: [EUROCAE-MASPS] 3.2.3 and [ICAO-A-SMGCS] 4.2.4 require the update rate should be at least 1s. For example, in one second, an aircraft rolling at 10 knots covers a distance of approximately 5 metres. A vehicle at 35 km/h will move approximately 10 metres. In that case, the position displayed to the controller can differ by 10 metres from the actual position before being updated with the new reported value. If we take the maximum speed of 50 kts for aircraft on straight taxiways ([ICAO-A-SMGCS] 4.1.1.8), the displayed position can differ by 25 metres along the direction of motion. Note 2: [EMMA2] With current technology, it is not possible to achieve an update rate of once per second for identification of stationary aircraft. This is because the on-board Mode S transponder automatically selects ‘low squitter rate’ (4.8s – 5.2s) when the aircraft is stationary on the ground. The use of multiple sensors will ensure an update rate of at least once per second for position data, but there is currently only one source for identification data (i.e. the aircraft’s transponder).



Alert Requirements


ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

ALERT_Serv-01_Conflict Detection 1

The control function of an A-SMGCS should detect conflicts and provide resolutions. Note: [EMMA2]: ATCOs do not want the A-SMGCS to provide resolution directly to aircraft and vehicles, but they would accept suggestions for possible resolutions.

1-A 5,40* Automated conflict resolution has not been addressed by EMMA2 in Prague.


The control function of an A-SMGCS should provide alerts for incursions onto runways and activate protection devices (e.g. stop bars or alarms).

2-A 5,00*


The control function of an A-SMGCS should provide alerts for incursions onto taxiways and activate protection devices (e.g. stop bars or alarms).

3-A not affected Not implemented for EMMA2 in WP6.3.


The control function of an A-SMGCS should provide alerts for incursions into critical and sensitive areas established for radio navigation aids.

4-A not affected Not subject to specific testing in EMMA2 in WP6.3.


The control function of an A-SMGCS should provide alerts for incursions into emergency areas.

5-A not affected Not subject to specific testing in EMMA2 in WP6.3.


With EMMA2 the conflict prediction, detection and alerting service should detect the conflicts/infringements provided in the SPOR document §3.4.

Not subject to specific testing in EMMA2 in WP6.3.

a) An aircraft cleared to line-up on a closed runway should trigger an INFORMATION coding




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

b) An aircraft cleared to take off on a closed runway should trigger an ALARM coding

c) An aircraft detected lining-up on a closed runway without clearance should trigger an INFORMATION coding

d) An aircraft detected taking off on a closed runway without clearance should trigger an ALARM coding

e) An arriving aircraft proceeding to a closed runway should trigger an ALARM coding

f) An aircraft cleared to take off with traffic on the runway protection area should trigger an ALARM coding

g) An aircraft detected crossing or lining up without clearance with traffic on the runway protection area should trigger an INFORMATION coding

h) An aircraft detected taking off without clearance with traffic on the runway protection area should trigger an ALARM coding

i) An aircraft cleared to take off with a movement cleared to line up, cross or taxi ahead should trigger an ALARM coding




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

j) An aircraft detected crossing or lining up without clearance with a movement cleared to cross, line up or taxi should trigger an INFORMATION coding

k) An aircraft detected taking off without clearance with a movement cleared to cross, line up or taxi should trigger an ALARM coding

l) An aircraft cleared to take off with an aircraft ahead cleared to take off should trigger an ALARM coding

m) An aircraft detected crossing or lining up without clearance while an aircraft ahead is cleared to take off should trigger an INFORMATION coding

n) An aircraft detected taking off without clearance while an aircraft ahead is cleared to take off should trigger an ALARM coding

o) An aircraft < T1 from threshold with a movement on the RPA should trigger an INFORMATION coding

p) An aircraft < T2 from threshold with a movement on the RPA should trigger an ALARM coding

q) A movement cleared to cross, line-up or taxi on a runway while an aircraft < T1 from threshold should trigger an INFORMATION coding




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

r) A movement cleared to cross, line-up or taxi on a runway while an aircraft is < T2 from threshold should trigger an ALARM coding

s) An aircraft cleared to land and < T2 from threshold while an aircraft is cleared to take off should trigger an ALARM coding

t) An aircraft detected landing and < T1 from threshold while an aircraft is cleared to take off should trigger an INFORMATION coding

u) An aircraft detected landing and < T2 from threshold while an aircraft is cleared to take off should trigger an ALARM coding

v) Arriving or departing aircraft with moving traffic to or on a converging or intersecting runway should trigger an alert Note: The management of converging or intersecting runways depends very much from one airport to another. This case was not described in the current SPOR document. However, the proposed concept of alerting should allow to easily describe the case of converging or intersecting runways.

w) An aircraft cleared to line-up on a runway ‘opposite direction’ should trigger an INFORMATION coding




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

x) An aircraft cleared to take-off on a runway ‘opposite direction’ should trigger an INFORMATION coding

y) An aircraft detected crossing or lining-up on a runway ‘opposite direction’ without clearance should trigger an INFORMATION coding

z) An aircraft detected taking off on a runway ‘opposite direction’ without clearance should trigger an ALARM coding

aa) An arriving aircraft with other traffic departing or landing on the same runway strip, opposite direction should trigger an ALARM coding

bb) An aircraft detected exiting the runway on the wrong side should trigger an INFORMATION coding. Note: In general there is neither expressed intention nor approval from the ATCO regarding the runway exit used by an aircraft. There cannot be conformance monitoring without prior agreement (or clearance).

cc) An unauthorised movement entering the runway protection area should trigger an INFORMATION coding

dd) An unidentified movement entering the runway protection area should trigger an INFORMATION coding




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

ee) An aircraft entering (or predicted to enter) a restricted area should trigger an INFORMATION coding

ff) An aircraft to be cleared to enter a restricted area should trigger an INFORMATION coding

gg) Aircraft approaching stationary traffic should trigger an alert Note: Triggering of alerts for such cases was tried during EMMA and has faced a lot of conceptual and technical issues. Operationally, aircraft approach stationary traffic every day on every airport without that being a hazardous situation (queue of aircraft on runway ramp access…). Besides, there is no operational definition of spacing between movements on the ground, except in low visibility conditions if block wise control is applied.

hh) Aircraft overtaking same direction traffic should trigger an alert

ii) Aircraft with opposite direction traffic




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

jj) Aircraft approaching taxiway intersections with converging traffic Note: Single aircraft approaching taxiway intersections could trigger an alert based on the routing information (taxi route conformance monitoring). Surrounding traffic will be considered to predict conflicts only if it is concerned by the routing function, i.e. subject to routing and thus to route conformance monitoring algorithms.

kk) An aircraft detected taxiing with excessive speed should trigger an INFORMATION coding

ll) A movement deviating from its assigned route should trigger at least an INFORMATION coding

mm) Unidentified traffic on the taxiwaysNote: On a theoretical point of view, a traffic not identified by A-SMGCS on the manoeuvring area should trigger an INFORMATION coding. However, the fact that all movement driving on such an area are not equipped yet lead to restrict this alerting to the runway protection area. Its extension to the whole manoeuvring area depends on the level of equipment of the fleet on the concerned airport.

nn) A movement detected to crossing a lit stop bar should trigger an ALARM




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

oo) Aircraft movement with conflicting traffic on an Apron should trigger an alertNote: The definition of a conflict on a taxiway is difficult because there is no standard separation. On apron, it is even more complex since some movements are in contact (baggage truck with aircraft…). This case will not be assessed in EMMA2.

pp) Aircraft movement with conflicting stationary objects on an Apron should trigger an alertNote: As mentioned above, there is no way to distinguish a conflict from regular traffic.

qq) Aircraft exiting the apron/stand/gate area at unintended or non-approved location should trigger an alert Note: This case is considered as taxi route conformance monitoring, since the taxi lanes leading to an apron/stand/gate area can be considered easily considered as taxiways.

rr) Unidentified traffic in the apron/stand/gate area should trigger an alertNote: Traffic in the apron/stand/gate area is not necessarily identified by A-SMGCS. Most of the traffic in this area is not in contact with the control tower (not even radio equipped). This case is then discarded from the concept.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

The following short-term alerts should be provided by the A-SMGCS within enough time to enable the appropriate remedial action:

a) Short-term conflict alert: when the predicted spacing will be below preset/predefined minima;

1-A 5,40*

b) Area penetration alert: whereby an alert is triggered when a movement likely to enter a critical or restricted area is detected;

4-A not affected (n.a.)

Not subject to specific testing in EMMA2 in Prague, but verified in technical tests in EMMA.

c) Deviation alert: whereby an alert is triggered when the computed deviation will be more than the preset/predefined maximum deviation;

6-A not affected (n.a.)

d) Runway incursion alert: whereby an alert is triggered when a movement likely to enter an active runway (runway strip) is detected; and

2-A 4,67* The alert is triggered when a target enters the pre-defined runway strip area, not when it is predicted to do so.

ALERT_Serv-07_Short-Term Alerts

e) Taxiway (or an inactive runway being used as a taxiway) or apron incursion alert: whereby an alert is triggered when a movement likely to enter a taxiway or apron in use, which does not belong to its assigned route, is detected.

3-A not affected (n.a.) Not implemented for EMMA2

in Prague.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

Note 1: [EMMA2] Meeting these requirements is liable to result in an unacceptably high level of false or unwanted alerts. The use of ‘entering’ rather than ‘likely to enter’ would be more appropriate. Note 2: [EMMA2] In b) and d) it is suggested to replace ‘movement’ by ‘unauthorised movement’. Note 3: [EMMA2] There are currently no separation minima defined by ICAO for surface movements.

Distinctive medium-term alerts should be provided well in advance to enable the appropriate remedial action to be taken with respect to:

a) Conflict prediction;

2-A 4,67*

b) Conflict detection; and 2-A 4,67*

ALERT_Serv-08_Medium-Term Alerts

c) Conflict resolution. Note 1: [EMMA2] Instead of short and medium term alerts, EMMA2 and EUROCONTROL are defining two stages of alert, which reflect the severity of conflicts.

Conflict resolution not implemented for EMMA2 in Prague.

ALERT_Serv-09_Alert Continuity

The information should be displayed continuously while the conflict is present.

7-A 5,00*

ALERT_Serv-10_Unambiguity

Conflict information should be unambiguously displayed on a surveillance display or by other appropriate means.

8-A 5,00*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

ALERT_Serv-11_False Alerts

The number of false alerts should be sufficiently low to meet local safety objectives and to ensure that users do not, consciously or sub-consciously, downgrade the importance of alerts.

9-A 4,80*

ALERT_Serv-12_Runway Protection Area

The runway protection area should be composed of two boundaries: a ground boundary to detect the aircraft/vehicles on the surface, an air boundary to detect airborne aircraft.

10-A 5,20*

ALERT_Serv-13_Ground Boundary

The length of the ground boundary should at least include the runway strip. The width should be defined differently according to the meteorological conditions. EUROCONTROL Note 1: As an example based on today’s ILS holding positions: - In Non-LVP: ground boundary defined by Cat I holding position - In LVP: ground boundary defined by Cat II / III holding position This ground boundary will be used for both INFORMATION and ALARM stages. EUROCONTROL Note2: In order to avoid unnecessary alerts to the controllers, it may be necessary to wait until the aircraft/vehicle has crossed the boundary.

11-A 5,50*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

ALERT_Serv-14_Air Boundary

The air boundary should be defined as a flight time to threshold and would take into account the two stages of alert, INFORMATION and ALARM, as well as the meteorological conditions:

• Non-LVP: INFORMATION around T1 = 30 seconds, ALARM around T2 = 15 seconds

• LVP: INFORMATION around T1 = 45 seconds, ALARM around T2 = 30 seconds

EUROCONTROL Note: Theses times should be configurable, depending upon optimisation at the aerodrome.

12-A 4,80*

ALERT_Serv-15_Traffic Context Update

For the conflict/infringement detection, additional updated and correct traffic context information should be provided to the system such as: - Airport configuration: runways in use, runways status, restricted areas - Applied procedures and working methods: LVP, multiple line-up.

13-A 5,17*

ALERT_Serv-16_Stages of Alert

The conflict prediction, detection and alerting service should provide 2 stages of alert: Stage 1 alert is used to inform the controller that a situation which is potentially dangerous may occur that he/she needs to be made aware of. According to the situation, the controller receiving a Stage 1 alert may take a specific action to resolve the alert if needed. This is called the INFORMATION step. Stage 2 alert is used to inform the controller that a critical situation is developing which needs immediate action. This is called the ALARM step.

14-A 5,83*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

EUROCONTROL Note: Controllers have different preferences, some of them want to be alerted only when the situation is critical (only Stage 2 alerts), and others wish more anticipation (2 stages of alert). This is confirmed by the evaluations performed in the BETA project. As a consequence, some ATS providers may choose to have ALARM only, and not use INFORMATION. The choice of having several stages of alerts presented to the controller, according to the conflict / infringement, should be left to the ATS providers.

ALERT_Serv-17_Alert Priority

Priorities should be established so as to ensure system logic performs efficiently. Conflict alerting priorities should be as follows:

a) Runway related conflicts. b) Taxiway related conflicts c) Apron related conflicts

Not implemented for EMMA2 in Prague.

RESOL_Serv-01_Conflict Resolution

Once a conflict has been detected, an A-SMGCS should either automatically resolve the conflict or, on request from the controller, provide the most suitable solution. Note: [EMMA2] It was rejected by the ATCOs in WG2 that a conflict situation would be solved automatically.

Conflict resolution not implemented for EMMA2 in Prague.

RESOL_Serv-02_Responsibility

The ATCO should remain the supreme authority to resolve a conflict situation. Not subject to specific testing

in EMMA2 in Prague.

RESOL_Serv-03_Traffic Information

A prerequisite for a reasonable and efficiently working automatic support is that the conflict resolution function is provided with at least all traffic information the ATCO is aware of.




TAXI-CPDLC Requirements


ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

TAXI-CPDLC_Serv-01_User Identification

In any data link dialogue, the end-user should be able to positively identify the other end-user.

1-T 3,33

Pilots acknowledgement (WILCO) was not directly seen in the EFS as intended but in a separate window, what was of course not intended but was the only solution to implement the pilots feedback within the short implementation phase. The identified user was always right, but the ATCOs did not like it of course, because the effort to allocate the feedback to the right flight was rather high.

TAXI-CPDLC_Serv-02_Direct Voice Communication

In any data link based ATS, provision should always be made for direct pilot-controller voice communications. 2-T 5,50*

TAXI-CPDLC_Serv-03_Emergency Communication

The pilot or controller should be capable of initiating direct controller-pilot communication by voice in emergency or urgent, non-routine, safety-related situations.

Independent of EMMA2




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

TAXI-CPDLC_Serv-04_User Interface

Simple actions should be used by either the pilot or controller to initiate voice communications.

Independent of EMMA2

TAXI-CPDLC_Serv-05_Flight Information Distribution

Air traffic control facilities providing a data link based ATS should be capable of receiving, storing, processing, displaying and disseminating specific flight information relating to flights equipped for and operating within environments where a data link service is provided.


Effective human-machine interfaces should exist on the ground and in the air to permit efficient interactivity between the:

a) pilot,

3-T 4,50*

b) controller, and 4-T 4,17*

TAXI-CPDLC_Serv-06_Human Machine Interface

c) ground automation 5-T n.a. Not subject to specific testing in EMMA2 in Prague.

TAXI-CPDLC_Serv-07_Transfer

The system should be capable of facilitating automatic transfer of data link authority within data link based ATS airspace using digital data interchange.


TAXI-CPDLC_Serv-08_Contingency Procedures

In case of complete communications failure, procedures should be in accordance with ICAO provisions. Not subject to specific testing

in EMMA2.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

TAXI-CPDLC_Serv-09_Service Termination Notification

In the event of an unexpected termination of a data link application, both the aircraft and the ground should be notified of the failure.

6-T n.a. The green “on-logged” button on the EFS disappeared when the link was lost or turned to yellow when the aircraft had logged out.

The CPDLC application requires that: a) Messages should be generated and sent in a time

ordered sequence; and Verified by technical tests.

TAXI-CPDLC_Serv-10_Message Emission b) Messages should be delivered in the order that they

are sent. 7-T 4,40* Verified by technical tests.

TAXI-CPDLC_Serv-11_Message Recipient

The system should ensure that messages are sent to the specified recipient. Verified by technical tests.

TAXI-CPDLC_Serv-12_Unsupported Service

When a ground system receives a message requesting an unsupported function or service, the ground system should respond indicating that the requested service is unsupported.


TAXI-CPDLC_Serv-13_Controller Interactions

The controller should be provided with the capability to respond to messages, including emergencies, to issue clearances, instructions and advisories, and to request and provide information, as appropriate. Note: [EMMA2] The defined TAXI-CPDLC Service does not handle ‘emergency’ messages.

8-T 4,67*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

TAXI-CPDLC_Serv-14_Pilot Interactions

The pilot should be provided with the capability to respond to messages, to request clearances and information, to report information, and to declare or cancel an emergency. Note: [EMMA2] The defined TAXI-CPDLC Service does not handle ‘emergency’ messages.

Emergency situations are not handled by TAXI-CPDLC, but by reverting to voice.

TAXI-CPDLC_Serv-15_Pilot and Controller Message Exchanges

The pilot and the controller should be provided with the capability to exchange messages which do not conform to defined formats (i.e. free text messages). Note: [EMMA2] This requirement may not be feasible for A-SMGCS operations.

9-T not affected (n.a.) Not implemented for EMMA2

in Prague.

TAXI-CPDLC_Serv-16_Messages Management

Ground and airborne systems should allow for messages to be appropriately displayed, printed when required and stored in a manner that permits timely and convenient retrieval should such action be necessary.

10-T not affected (n.a.) Verified by technical tests.

TAXI-CPDLC_Serv-17_Aircraft Control

Aircraft should be under the control of only one ATC unit at a time, whether or not data link applications are being used. 11-T 5,43*

TAXI-CPDLC_Serv-18_Time Stamping

Time stamping should be available for all messages. The timestamp should consist of the date (YYMMDD) and time (HHMMSS). The timestamp should be the time the message is dispatched by the originating user.

12-T not affected (n.a.) Verified by technical tests.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

TAXI-CPDLC_Serv-19_LACK

Each data link message transmission is followed by a logical (technical) acknowledgement (LACK), i.e. the sender gets an immediate feedback that the message has completely been transmitted and is available on the recipient’s display.

13-T 4,50

TAXI-CPDLC_Perf-01 _Time Accuracy

Wherever time is used in the CPDLC application, it should be accurate to within 1 second of UTC.


Routing Requirements


ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

ROUT_Serv-01 _Routing Function

Either manually or automatically, the routing function of an A-SMGCS should be able to designate a route for each aircraft or vehicle within the movement area. 1-R 2,83

The number of available routes implemented for EMMA2 was not sufficient to meet the needs of Prague. Those routes that were implemented met the requirement.

ROUT_Serv-02 _Destination Change

Either manually or automatically, the routing function of an A-SMGCS should allow for a change of destination at any time.

2-R 2,67 The requirement was met for those routes that were implemented.

ROUT_Serv-03 _Route Change

Either manually or automatically, the routing function of an A-SMGCS should allow for a change of route. 3-R 2,50

The requirement was met for those routes that were implemented.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

ROUT_Serv-04 _Routing Capability

The routing function of an A-SMGCS should be capable of meeting the needs of dense traffic at complex aerodromes. Source: [ICAO A-SMGCS] 2.5.2.1.d

4-R 3,40

ROUT_Serv-05 _Runway Exit

The routing function of an A-SMGCS should not constrain the pilot’s choice of exit following the landing. 5-R 4,00

ROUT_Serv-06 _Manual Routing

In a manual routing mode, the routing function should be able to compute a valid taxi route between a given start point and a given end point taking into account local standard routes.

For the EMMA2 implementation, the start and end points must be a stand or runway exit/entry point.

ROUT_Serv-07 _Semi-Automatic Routing

In a semi-automatic mode, the routing function should also provide the control authority with advisory information on designated routes. Note: [EMMA2] Advisory information of semi-automatic routing should indicate the probable most suitable taxi route that includes the shortest taxi distance and current constraints that are known to the function.

6-R 3,50

ROUT_Serv-08 _Automatic Routing

In an automatic mode, the routing function should also: Assign routes; and provide adequate information to enable manual intervention in the event of a failure or at the discretion of the control authority Note: [EMMA2] To put a route into action (in terms of giving clearances to pilots and vehicle drivers) remains a control task and is still under responsibility of the ATCO. However, the automatic assignment should not be the only criterion; furthermore it should be guaranteed that the assignment of a taxi route is reasonable and reliable to best meet all current

7-R 4,00 Only standard routes were used for the EMMA2 implementation in Prague. Route assignment was semi-automatic.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

constraints and to minimise manual intervention by the ATCO. Therefore, the routing function needs all information the ATCO usually needs to generate a taxi route.

ROUT_Serv-09 _Route Assignment 1

When assigning routes, an A-SMGCS should minimise taxi distances in accordance with the most efficient operational configuration.

6-R 3,50 Only standard routes were used for the EMMA2 implementation in Prague.


When assigning routes, an A-SMGCS should be interactive with the control function to minimise crossing conflicts.

8-R not affected (n.a.)

Only standard routes were used for the EMMA2 implementation in Prague.


When assigning routes, an A-SMGCS should be responsive to operational changes (e.g. runway changes, routes closed for maintenance, and temporary hazards or obstacles).



ROUT_Serv-12 _Standard Terminology

When assigning routes, an A-SMGCS should use standardised terminology or symbology. 10-R 4,17

ROUT_Serv-13 _Route Availability

An A-SMGCS should be capable of providing routes as and when required by authorised users.

11-R 3,40 The requirement was met for those routes that were implemented.

ROUT_Serv-14 _Route Validation

An A-SMGCS should provide a means of validating routes. 12-R 3,33





ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

ROUT_Serv-15 _Provision of Routing Information 1

The routing function should be capable of providing routing information for aircraft and vehicles on the movement area and, where necessary, other areas used by vehicles. Source: [ICAO A-SMGCS] 3.4.2.2


ROUT_Serv-16 _Provision of Routing Information 2

The routing function should provide an optimised route for each participating aircraft and vehicle. It should consider the overall time for an aircraft or vehicle to complete the route in all visibility conditions. Note: [EMMA2] With an automatic routing function, the ATCO should be provided with a most efficient taxi route that consists of route (taxi path) and time information, whereas the path and times are permanently updated downwards to a tactical planning level, [EMMA2 SPOR] §2.1.3.1.3.


ROUT_Serv-17 _Surface Traffic Flow Optimisation

The routing function should optimise the traffic flow of aircraft and vehicle surface movements, including aircraft under tow, with respect to:

a) Reducing delay – when planning a route, an effort should be made to permit an aircraft to meet its assigned take-off time or reach its allocated gate on time.

b) Potential conflict; the wing-tip to wing-tip spacing between certain types of aircraft on parallel taxiways should be taken into account.

c) Longitudinal spacing when visibility becomes a factor, including jet blast and propeller / rotor wash

d) Obstructed, unavailable or temporarily closed parts of the movement area; and





ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

e) Taxi speeds (to reduce braking and acceleration, and fuel burn).

ROUT_Serv-18 _Intermediate Waypoints

The routing function should be able to handle predefined or user-defined intermediate waypoints (e.g. routing through de-icing stations).



ROUT_Serv-19 _Use of Alternative Routes

An alternative route should always be available on request. Note: [EMMA2] If the ATCO objects to the computed taxi route because of additional information/constraints that are not known to the routing function, the ATCO should be able to easily select an alternative route, [EMMA2 SPOR] §2.1.3.1.2.

13-R 2,83

The requirement was met for those routes that were implemented.

ROUT_Serv-20 _Route Modification / Cancellation

By human-initiated means, or as a result of a conflict, it should be possible to cancel or change an existing and used route. In the event that a route is cancelled, a new route to continue should be provided.

3-R 2,50 Only standard routes were used for the EMMA2 implementation in Prague.

ROUT_Perf-01 _Routing Failure Rate

The requirements listed in the table below should be used in the design of the routing function. Visibility conditions Requirement

(Failures per hour)

1 1.5E-03

2 1.5E-04

3 3.0E-06

4 1.5E-06

Not relevant. The requirement is meaningless and out of context.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

Note 1: [EMMA2] ICAO gives no rationale for these figures, nor does it give the corresponding requirements for the other functions. Failure rate requirements will need to be estimated for each aerodrome. Note 2: [EMMA2] A failure of the routing function may reduce efficiency of operations but it is unlikely that it would affect safety.

ROUT_Perf-02 _Processing Time

The time taken to process an initial route should not exceed 10 seconds. Reprocessing to account for tactical changes once the aircraft or vehicle is in motion should not exceed 1s.


ROUT_Perf-03 _Timing and Distance Resolution

In the processing of optimised routes, the length of taxi distances should be computed to a resolution better than 10m, and timing to a resolution better than 1s. Note: It is suggested to inform ICAO that there is no point in specifying resolution when no accuracy requirement is specified. Perhaps they mean accuracy, not resolution? If so, the requirement seems unnecessarily demanding.




Guidance Requirements


ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GUID_Serv-01 _Guidance Function

The guidance function of an A-SMGCS should provide guidance necessary for any authorised movement and be available for all possible route selections. Note: [ICAO] When visibility conditions permit a safe, orderly and expeditious flow of authorised movements, the guidance function will primarily be based on standardised ground visual aids. If expeditious flow is restricted due to reduced visibility, additional equipment or systems will be required to supplement visual aids in order to maintain flow rates. Note 1: [EMMA2] §3.4.3.4 [ICAO A-SMGCS] says: - Once a route has been assigned, the pilot or vehicle driver requires adequate information to follow that route. Guidance aids indicate where on the taxiway or apron the aircraft or vehicle can be manoeuvred safely. Switched centre line lights and/or addressable signs enable routes to be uniquely designated. With EMMA2 Ground guidance aids will not be implemented.


GUID_Serv-02 _Indication to Pilots/Drivers

The guidance function of an A-SMGCS should provide clear indications to pilots and vehicle drivers to allow them to follow their assigned routes. Source: [ICAO A-SMGCS] 2.5.3.b Note: [EMMA2] When guidance information is transferred onboard, the flight crew and the vehicle drivers should be presented with information about the own with respect to the airport layout, the restricted areas such as active runways, the destination and the taxi route to be followed.

The transmitted alphanumerical taxi route was interpreted onboard and graphically shown on the EMM.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

GUID_Serv-03 _Pilot/Driver Situational Awareness

The guidance function of an A-SMGCS should enable all pilots and vehicle drivers to maintain situational awareness of their positions on the assigned routes.

GUID_Serv-04 _Route Change

The guidance function of an A-SMGCS should be capable of accepting a change of route at any time.

The requirement was met for the standard routes that were implemented.

GUID_Serv-05 _Restricted Areas

The guidance function of an A-SMGCS should be capable of indicating routes and areas that are either restricted or not available for use.

Not implemented for EMMA2 in Prague

GUID_Perf-01 _Response Time

The overall response time of initiation of the guidance to verification that the correct route of information has been provided should not exceed 2 seconds. Note: [EMMA2] This requirement refers to the activation of taxiway guidance lights. The rationale is given in [ICAO A-SMGCS] 3.4.3.10.

Not relevant for TAXI-CPDLC guidance means.

GUID_Perf-02 _Reversion Time

The reversion time should be a maximum of 0.5s. Note: [EMMA2] This requirement refers to the deactivation of taxiway guidance lights.

Not relevant for TAXI-CPDLC guidance means.



ATCO HMI Requirements


ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-01 _Interference

The operation of the A-SMGCS ATCO HMI should not interfere with other ATC responsibilities. 1-H 4,50

The A-SMGCS ATCO HMI should: a) Maintain a balance between human and machine

functions; 2-H 4,33

b) Permit the human to retain the power to make decisions as to those functions for which the human is responsible;

3-H 4,67*

HMI_Serv-02_ Human/Machine Work Share

c) Provide for a balanced mix of visual, audio and tactile inputs and responses. 4-H 4,17

HMI_Serv-03 _Efficient Input Devices

Input devices for the controllers should be functionally simple - involving the controllers in a minimum number of input actions.

5-H 4,67*

HMI_Serv-04 _Ambient Light

It should be possible to view displays in all ambient light levels typical of an aerodrome control tower environment. 6-H 5,50*

HMI_Serv-05 _Onboard HMI 1

Account should be taken of the ability of the flight crew and vehicle drivers to respond to the guidance and control indications of the system.

Pilots could answered by a WILCO or UNABLE, which was shown on the ATCO HMI.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-06 _Onboard HMI 2

The system should provide pilots and vehicle drivers with essential routing, guidance and control data in a standardized form that at all times is conspicuous, legible, comprehensible and credible. Guidance should be implemented in such a way as to minimize the pilots’/ vehicle drivers’ head down time, while maximizing the use of visual cues.

The taxi route indication was conspicuous, legible, comprehensible and credible but the CDTI HMI did not meet the Pilots’ needs of an easy to operate HMI.

HMI_Serv-07 _Ease of Use

For control staff, the system should have interfaces that allow them to manage the routing, guidance and control functions in a safe and efficient manner. Note: [EMMA2] The A-SMGCS ATCO HMI should employ user friendly and familiar data entry means.

7-H 4,67*

HMI_Serv-08 _Harmonisation

The A-SMGCS ATCO HMI should be harmonised where possible with existing ATM HMI. Note: ATM HMI may be specific to each local implementation.

8-H 4,67*

HMI_Serv-09 _Adaptability

The HMI design should take into account the working environment of the user under various operational conditions. In this respect, the HMI should be adaptable to the various circumstances of the user. Note: As an example, good visibility operations with high traffic throughput will require a different A-SMGCS set-up than that required for low visibility operations with reduced throughput.

9-H 4,50*

HMI_Serv-10 _Display Configuration 1

The HMI should allow the user to configure the display capabilities (e.g. range scale selection, pan/zoom, brightness, map overlays).

10-H not affected (n.a.)




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-11 _Display Configuration 2

Where appropriate, it should be possible to configure the HMI according to local requirements.

Not specifically tested in EMMA2, but verified in operational A-SMGCS.

HMI_Serv-12 _Traffic Situation Display

The HMI should display the complete airport traffic situation, allowing a rapid situation assessment. 11-H 5,00*

The notion of selection relates to the intention to interact with the traffic label and/or with the associated symbol and trajectory, and/or its representation through traffic data. The interface should support the notion of the currently selected traffic whose data the controller is currently examining or modifying. The selection of an aircraft or vehicle should:

a) Highlight all the available representations of that traffic wherever such information appears, allowing for an easy location of the traffic information.

12-H 4,67*

HMI_Serv-13 _Target Selection

b) Show the surveillance label in the appropriate selected format. 12-H 4,67*

The controller should be provided with a clear indication that a movement is:

a) Entering her/his area of responsibility; 13-H 5,17*

b) Being under her/his responsibility; 13-H 5,17*

HMI_Serv-14 _Indication of Responsibility

c) Leaving her/his area of responsibility. 13-H 5,17*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-15 _Accessible Traffic Information

Controllers should be presented with a clear 'picture' of the actual traffic situation in their areas of responsibility, and with all the necessary traffic data to assist them in their control and guidance tasks, i.e. to easily locate and identify aircraft and vehicles and to have a direct access to essential information.

14-H 5,17*

HMI_Serv-16 _Traffic Data Sets

Different sets of traffic data should be provided in order to assist the controllers in different types of tasks (e.g. updating of data, planning of actions, traffic monitoring and conflict detection). These sets of data should be presented in a combination of graphical and textual formats.


HMI_Serv-17 _Graphical Traffic Information

Traffic position and trajectory should be provided in graphical format with labels to help the controller to easily locate each aircraft or vehicle and visualise its progress.


Textual data should be provided in several formats: a) Isolated sets of data related to each aircraft or vehicle,

i.e. labels. Access to current flight parameters should be provided through interaction with any aircraft or vehicle label.


b) Lists of data allowing comparisons to help the controller to detect conflicts and to prioritise the planning of actions.


HMI_Serv-18 _Textual Information

c) Electronic flight strips allowing the controllers to visualise the planned movements and to enter clearances.





ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-19 _Indication of Unauthorised Traffic

The HMI should continuously indicate the position of unauthorised aircraft, vehicles and obstacles, whilst they are in the movement area, the runway strips and within any designated protected area as required by airport authorities.


The traffic representation should be updated following: a) Updates of the surveillance system Verified by technical tests. HMI_Serv-20

_Update of Information b) Controller or system initiated update of data. Verified by technical tests.

HMI_Serv-21 _Minimal Screen Congestion

To avoid screen congestion and minimise overlap of displayed information, the permanently displayed traffic data should be only the minimum information needed by the controller.

15-H 5,00*

HMI_Serv-22 _Presentation of Conflict Alerts 1

The controller should be provided with clear and visible indication of a conflict alert as soon as the alert exists. The provided information should include, at the minimum the identification of the involved aircraft and/or vehicle, wherever present.

16-H 5,17*


Conflict information should be unambiguously displayed on a traffic situation display or by other appropriate means.

17-H 5,00


An alert should always be associated with a visual signal. The use of aural signal should be restricted to highly critical events requiring immediate action.

Aural alerts not required for Prague.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-25 _Continuity of Alert

The HMI should continuously display a Conflict/Infringement alert while the conflict is detected.


HMI_Serv-26 _Alert Stages

An alert associated with a detected conflict should be provided with an adequate time and brought to the attention of the controller (ALARM coding). An alert associated with a predicted conflict (INFORMATION coding) should also be provided.


Priorities should be established to ensure that system logic performs efficiently. Conflict alerting priorities should be as follows:

a) Runway incursions


HMI_Serv-27 _Conflict Alert Priorities

b) Restricted area incursions Verified by technical tests.

HMI_Serv-28 _Display of Lighting Status

The information about the status of the lighting system and protection devices such as stop bars (on/off) should be easily accessible to the controller.


HMI_Serv-29_Indication of Route Deviation

The controller should be provided with clear and visible indication when a movement is deviating from its cleared route. The provided information should include, at the minimum, the identification of the involved aircraft, wherever present.





ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-30 _Indication of Clearance Deviation

The controller should be provided with clear and visible indication when a movement is deviating from its clearance, or is operating without clearance. Note: As an example, an aircraft not cleared to line up enters the runway, while an aircraft not cleared to land is on final approach.


HMI_Serv-31 _EFS display

The HMI should be capable of displaying electronic flight strips (EFS) to replace the use of paper strips and support the controller by reducing workload.


HMI_Serv-32 _EFS Content

The flight strips should contain data fields with all flight plan data relevant for the controller role at each position. Verified by technical tests.

HMI_Serv-33 _EFS Display Layout

The presentation of electronic flight strips should be harmonised with current paper strips and the way they are stacked in flight strip bays.


HMI_Serv-34 _EFS Responsibility

The HMI at each working position should display the flight strips for flights under control of that position, as well as flights that will become controlled in the near future.

20-H 5,33*

HMI_Serv-35 _EFS Grouping

Flight strips should be logically grouped in bays according to the phase of flight and user requirements (e.g. inbound, outbound, pending, etc.).

21-H 4,83*

HMI_Serv-36 _EFS Sorting Criteria

The flight strip bays should contain lists of flight strips that are selected, sorted and presented according to configurable criteria.

22-H 4,83*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-37 _EFS Interaction

Controllers should have the capabilities to sort, move, and create new traffic data items in the traffic data lists. Verified by technical tests.

HMI_Serv-38 _EFS Initialisation

Depending on the controller role, flight strips should appear in the entry (pending) area a pre-defined time before expected arrival or departure or when transferred from another control position.


HMI_Serv-39 _EFS Data Format

All traffic data items pertinent to a controller should be presented in clear and pre-defined formats that help to prioritise planning and control actions.

23-H Verified by technical tests.

HMI_Serv-40 _EFS Configurability

Depending on operational needs, traffic data items should be highly configurable with regard to layout, size, shape, fonts, colours and interaction capability.

24-H Verified by technical tests.

HMI_Serv-41 _EFS Extended Data Format

Traffic Data Items should be represented in minimum format or extended format based on controllers’ choice. It should be possible to configure independently the extended format of traffic data items from the minimum format, by displaying and removing additional data.


HMI_Serv-42 _EFS Access to Additional Data

The controller should be able to expand the format of a displayed traffic data item to access additional data. By default, traffic data items should be presented under normal (minimum) format.





ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-43 _EFS Timing of Arrival Traffic Data

Arrival traffic data should be displayed on concerned positions at a time parameter before the expected landing time (ELDT). The time parameter should be defined at local level.

25-H 5,33*

HMI_Serv-44 _EFS Timing of Departure Traffic Data

Departure traffic data should be displayed on concerned positions at a time parameter before the expected off-block time (EOBT). The time parameter should be defined at local level.

26-H 5,17*

HMI_Serv-45 _EFS Editing

If required locally, the controller should be provided with an easy and simple means to manually create a new flight plan or modify an existing flight plan. Note: It may be necessary to create flight plans for towing operations and ground vehicle movements.

27-H 3,80

HMI_Serv-46 _EFS Handover 1

The HMI should provide a simple and secure means for handover of electronic flight strips between controllers. 28-H 5,17*


The system should support the controller by automatic distribution/exchange of flight data and co-ordination between control positions.

29-H 5,00*


Controllers should be provided with system assistance for transferring aircraft control from one to another control position.

30-H 5,50*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments


The durability of annotations and instructions should be ensured during handover. Note [EMMA2] There shall be no loss of information on the flight strips (including any hand-written notes, etc.) when they are handed over from one controller working position to another.

31-H 5,17*

HMI_Serv-50 _Transfer of Control Procedure

It should be possible to trigger the ‘transfer of control’ procedure either manually, e.g. by ATCO’s input on a flight strip, or automatically, i.e. based on a significant flight event.

32 H- 5,17*

HMI_Serv-51 _Assumption of Control Procedure

Similarly, it should be possible to perform the ‘assumption of control’ manually or automatically depending upon local operational practices.

33-H 5,00*

HMI_Serv-52 _Coordination Support

The introduction of automation of surface movement planning and electronic flight strips should support the ATCOs coordination between Ground and Tower controllers and adjacent Approach controllers.

34-H n.a. Coordination with Approach control not implemented for EMMA2 in Prague.

HMI_Serv-53 _Ground Sectorisation

The ground sectorisation in a tower should be based on the following types of logical sectors:

a) Apron / Clearance Delivery, b) Ground, c) Tower





ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-54 _Combined Roles

It should be possible to combine the operational roles in a number (1 to n) of physical controller working positions based on operational constraints, e.g. traffic load, time of day, etc.


HMI_Serv-55 _Clearance Input

Controllers should be presented with a means to input clearances into the system (via the electronic flight strip and/or labels).

35-H 5,17*

HMI_Serv-56 _Clearance Types

Clearances should represent the normal set of clearances a controller gives to an aircraft, such as: ‘cleared to land’, ‘continue approach’, ‘go-around’, ‘vacate’, ‘cross’, taxi’, ‘start-up’, ‘push-back’, ‘hold’, ‘line-up’, ‘conditional line-up’, ‘take-off’, ‘abort take-off’, etc.


HMI_Serv-57 _Clearance Durability

The durability of the clearances input should be ensured until the next clearance has been input. Note [EMMA2]: As an example, there should be a clearance button which the controller presses when the clearance is given. The text on the button automatically changes to the next logical clearance in the sequence. In most cases, the strip will also be automatically transferred to another strip bay area on the controller's screen or to another control position; in any case, the clearance given is no longer shown on the e-strip. It is recorded, however, and it is possible for the controller to take back a clearance by use of the "regress" button.


HMI_Serv-58 _Correction of Mistakes

It should be possible for the controller to easily correct a mistaken action.

36-H 4,00




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-59 _Route Assignment

The HMI should be able to show and to assign the most probable/standard route to individual aircraft and vehicles to provide safe, expeditious, efficient and free conflict movement from its current position to its intended position.

37-H 3,83 Only a set of standard routes was implemented for EMMA2 in Prague.

HMI_Serv-60 _Route Presentation

The route (path) information should be indicated alphanumerically within the EFS but should also be linked with the traffic situation display (TSD) (on request of the ATCO the route could be presented graphically).


HMI_Serv-61 _Route Modification

The controller should be provided with a quick and efficient means to modify a system assigned route to an aircraft.

38-H 2,83 Only a set of standard routes was implemented for EMMA2 in Prague.

HMI_Serv-62 _Route Manual Intervention

The ATCO can always intervene with the electronic flight strips to set additional constraints unknown to the routing function.


Only a set of standard routes was implemented for EMMA2 in Prague.

HMI_Serv-63 _Minimum Weather Information

Minimum weather information should always be displayed and available to the controller and should include (per runway): surface wind direction (touch down) and strength (graphical and text), QNH (mb), ATIS code, temperature and dew point.





ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-64 _Additional Weather Information

The controller should be provided with an easy means to access to additional weather information that should include surface wind (Touch Down and Stop End), visibility, current weather, cloud ceiling, QNH and QFE (mb and inches), weather forecast information, RVR conditions and a remarks section. The display should either be provided on controller request or automatically triggered on specific events defined at local level.


HMI_Serv-65 _NAVAIDS Status Indication

The controller should be provided with an easy means to display on request the status of airport NAVAIDS equipment.


HMI_Serv-66 _NAVAIDS Serviceability

The controller should be warned automatically in case of modification of airport NAVAIDS equipment serviceability.


HMI_Serv-67 _Stop Bars Integration

The display of stop bars should be integrated into the A-SMGCS HMI.

40-H 5,33*

HMI_Serv-68 _Stop Bars Status

The current status of stop bars should always be presented to the controller.


HMI_Serv-69 _Automatic Switching of Stop Bars

Switching (i.e. activate or de-activate) status of stop bars should be changed automatically according to ATCO clearances and a/c position.

42-H not affected (n.a.) Not implemented for EMMA2

in Prague.




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Serv-70 Manual Switching of Stop Bars

It should also be possible to manually switch (i.e. activate or de-activate) protection devices such as stop bars. Not implemented for EMMA2

in Prague.

HMI_Serv-71 _Datalink Equipment

The controller should be informed if an aircraft is datalink equipped or not.

43-H 5,33*

HMI_Serv-72 _Datalink Dialogue Failure

An alert should be presented to the controller when a datalink dialogue has failed.


HMI_Serv-73 _Datalink Dialogue De-activation

The controller should have the means to de-activate the datalink dialogue for a particular aircraft. Data link was initiated

automatically.

HMI_Perf-01 _Map Accuracy

The accuracy of all map information presented on the traffic situation displays should be sufficient to ensure that each movement is seen in the correct position with respect to the aerodrome layout and other traffic, and particularly with respect to hold lines and stop bars.

45-H 5,17*

HMI_Perf-02 _Display Resolution

The resolution of the HMI displays should be sufficient to not noticeably degrade the accuracy of the information being presented.

46-H 5,00*




ID EMMA2 OF QE item


rifie

d Pa

rtly

ve

rifie

d N

ot

verif

ied

othe

rs

Comments

HMI_Perf-03 _Position Registration Accuracy

The accuracy with which the HMI registers position information on the display should be sufficient to not appreciably degrade the accuracy of the information it receives from surveillance.

Not specifically tested for EMMA2 in Prague, but has been verified in EMMA.

HMI_Perf-04 _Display Latency

The presentation of surveillance data to controllers should not be delayed to an extent where it is no longer operationally acceptable. A worst-case value of 500ms is appropriate. Note: For [ICAO A-SMGCS], the latency and validation of position data for aircraft and vehicles should not exceed one second.

47-H 5,50

HMI_Perf-05 _Response Time

The response time of the ATCO HMI should be adequate to allow the controller to make inputs without having to wait unduly for the system to process and validate the input. This should be less than 250ms on average and should never exceed 500 ms. Note: Where external systems are being activated by input at the ATCO HMI, the response time does not include the time taken for the external system to respond. In such cases, the controller should be given an immediate acknowledgement that a message has been sent and a further acknowledgement once the reply has been received from the external system.

48-H 5,50

EMMA2



7.2 Flight Plans of the Traffic Scenarios EXE02 and EXE04 ARRIVALS

ID Callsign STARs ETA Aircraft Type WTC Stand

38 AZE11A on final 00:02 D328 M E2 6 LOT143 on final 00:03 B735 M 12 15 CSA189 ILS24_S 00:07 A310 H 3

32 CSA881 ILS24_NW 00:11 B735 M 37 4 RYR64S ILS24_NW 00:13 B738 M 6 39 AFR1982 ILS24_NW 00:15 A320 M 24B 40 CSA9LP ILS24_NW 00:18 B735 M 1 30 N126G OKX 1S,ILS24_NW 00:20 B733 M S9 8 CSA025 ILS24_S 00:24 AT43 M 44 GECO DLH73C on final 00:28 A320 M 18 41 AZA2S LOMKI 1S, ILS24_NW 00:30 A320 M 51 42 KLM609 ILS24_SW,TABEM 1S 00:35 B733 M 15

DEPARTURES

ID Callsign SIDs ETD Aircraft Type WTC Stand

1 BAW854 DONAD 2A 00:01 B763 H 15 3 DLH3281 DONAD 2A 00:01 A320 M 17 13 CSA72C OKX 2A 00:01 B735 M 3

GECO DLH72C MEDOV 1A 00:10 A320 M 18 36 CSA7322 DEKOV SA 5 00:11 AT43 M S12 9 FGAXN DONAD 2A 00:11 SB20 M S11 37 THY1748 VOZ 2A 00:11 B738 M 4 14 LOT104 OKX 2A 00:11 B735 M 9 2 CSA856 VOZ 2A 00:21 B735 M 36 10 CSA972 VOZ 3M 00:21 AT72 M 44 16 CSA9301 VOZ 3M 00:31 AT72 M S2 29 CSA962 VOZ 3M 00:31 AT72 M 41 5 AZA53S MEDOV 1A 00:36 A320 M 22

Table 7-1: Flight Plan of Traffic Scenario EXE02

EMMA2



ARRIVALS

ID Callsign STARs ETA Aircraft Type WTC Stand

17 SWR1499 on final 00:01 A320 M 15 6 TVS647 on final 00:04 B738 M 56 7 CSA109 on final 00:06 A310 H 3 8 LOT523 ILS06_N 00:10 B735 M 10 4 CSA449 ILS06_N 00:12 B735 M 20 37 AFR1982 LOMKI 2T, ILS06_W 00:16 A320 M 22A 35 BAW854 LOMKI 2T, ILS06_W 00:19 B763 H 16 48 RYR62L LOMKI 2T,ILS06_W 00:22 B738 M 52 15 EZY6534 ILS06_N, LALUK 1T 00:23 A319 M 6 11 BER257L LOMKI 2T, ILS06_W 00:26 B738 M 23 GECO DLH473 on final 00:28 A320 M 18 49 AFL141 OKX 3T, ILS06_N 00:30 A320 M 14 38 CSA653 LOMKI 2T, ILS06_W 00:32 B735 M 8

DEPARTURES

ID Callsign SIDs ETD Aircraft Type WTC Stand

1 THY1768 BODAL 1E 00:01 B738 M 38 52 DAT2813 DONAD 4D 00:01 RJ85 M 9 9 CSA972 BODAL SA 5 00:05 AT43 M 47 33 CSA814 TABEM 2D 00:06 AT72 M 45 3 DLH7KJ DONAD 4D 00:08 A320 M 17 50 CSA644 DONAD 4D 00:10 B735 M 36 GECO DLH472 TABEM 2D 00:12 A320 M 18 36 TVS606 TABEM 1E 00:14 B738 M 37 51 CSA772 BODAL 2D 00:15 AT43 M 42 5 CSA876 HOLAN 2E 00:16 B735 M 4 10 AZA517 MEDOV 3E 00:17 A320 M 22A 32 EZY4936 DONAD 4D 00:21 A319 M 12 14 AIZ6541 BODAL 1E 00:21 B752 M 1 34 CSA4BG BODAL 1E 00:26 B735 M 32 13 LOT144 HOLAN 2E 00:29 B735 M 14

Table 7-2: Flight Plan of Traffic Scenario EXE04

EMMA2



7.3 Raw Data of RTS1 In RTS1 the operational feedback of the ATCOs was compiled and is documented in this section but since the same ATCOs in RTS2 eight months later assessed the operational feasibility of an improved systems, only those RTS2 results were used to extract proper conclusions.

7.3.1 QE-QF

ID C1 C2 C3 C4 C5 C6 ID C1 C2 C3 C4 C5 C6 1-G 6 6 5 6 5 5 10-H 6 6 4 6 6 5 2-G 5 6 4 5 5 6 11-H 6 6 5 6 5 4 3-G 4 5 5 5 6 5 12-H 6 6 5 6 5 5 4-G 6 5 5 5 5 5 13-H 4 4 4 5 5 5 5-G 14-H 4 6 5 6 5 6 6-G 15-H 2 1 4 5 2 5 7-G 4 16-H 3 6 6 6 4 8-G 17-H 3 6 6 6 6 9-G 6 6 2 6 5 4 18-H 1 1 10-G 4 5 4 6 6 5 19-H 11-G 1 5 2 1 20-H 5 5 4 5 5 12-G 4 5 5 5 4 6 21-H 5 5 4 4 6 13-G 6 5 5 6 6 6 22-H 5 5 4 5 4 14-G 6 5 5 6 6 6 23-H 5 5 4 3 4 15-G 5 2 4 4 24-H 5 4 4 3 3 16-G 5 5 6 2 2 25-H 5 4 4 6 5 5 17-G 4 5 4 4 2 26-H 6 6 5 18-G 5 27-H 3 2 19-G 28-H 5 5 4 5 4 4 20-G 29-H 5 5 4 6 5 5 1-S 30-H 5 4 4 5 6 5 2-S 31-H 5 4 4 5 5 4 3-S 32-H 4-S 33-H 5-S 34-H 5 2 3 5 6 4 6-S 35-H 5 2 4 5 6 5 7-S 36-H 5 1 4 5 6 5 1-A 6 6 6 37-H 1 1 2 2-A 6 6 6 38-H 1 1 2 3-A 39-H 1 1 2 4-A 6 6 40-H 5 5 4 6 5-A 6 6 41-H 5 6 6 5 6-A 42-H 7-A 6 6 6 43-H 8-A 5 6 44-H 9-A 5 6 5 45-H 10-A 6 6 4 46-H 11-A 6 6 6 47-H 12-A 5 4 48-H 5 5 5 6 5 4 13-A 6 5 1-T 14-A 6 6 6 2-T 1-R 1 1 2 3-T 2-R 1 1 2 4-T

EMMA2



3-R 1 1 2 5-T 4-R 1 2 2 6-T 5-R 2 7-T 6-R 1 2 2 8-T 7-R 1 2 2 9-T 8-R 10-T 9-R 11-T 10-R 1 2 2 12-T 11-R 1 2 2 13-T 12-R 1 2 2 14-T 13-R 1 2 1 15-T 14-R 16-T 15-R 3 2 1 6 5 5 17-T 18-R 4 4 2 5 5 3 18-T 19-R 4 4 4 5 3 3 19-T 1-H 6 6 5 6 2 2 20-T 2-H 6 6 5 5 5 5 21-T 3-H 6 6 5 6 5 5 22-T 4-H 6 5 5 4 5 6 23-T 5-H 5 5 5 4 3 4 24-T 6-H 5 6 4 6 4 6 25-T 7-H 2 1 4 5 26-T 8-H 5 5 4 5 4 5 27-T 9-H 5 5 4 5 5 5 28-T

Table 7-3: Raw Data of the QE-OF (RTS1)

7.3.2 QE-OI ID C1 C2 C3 C4 C5 C6

1-OI 5 5 4 6 4 4 2-OI 3 3 2 5 5 5 3-OI 6 6 6 4-OI 5 6 5 6 5-OI 4 3 6 3 4 6-OI 4 4 4 4 7-OI 4 2 4 4 5 8-OI 4 2 4 4 4 9-OI 3 3 4 4 10-OI

Table 7-4: Raw Data of the QE-OI (RTS1)

EMMA2



7.3.3 Workload BA SE EFS DMAN VIS1 VIS2 VIS1 VIS2 TEC GEC CDD TEC GEC CDD TEC GEC CDD TEC GEC CDD Mean

C1 2,50 2,00 1,00 2,00 2,00 1,00 2,75 2,67 1,50 2,50 2,00 1,00 1,91C2 3,00 2,50 1,00 3,00 2,75 1,00 3,00 2,50 1,67 2,75 2,50 1,50 2,26C3 2,25 2,00 1,00 2,00 2,00 1,00 2,00 2,00 1,00 3,00 2,00 1,00 1,77C4 2,25 2,33 1,25 2,25 2,00 1,00 2,25 1,75 1,25 2,25 2,00 1,25 1,82C5 2,75 2,00 1,00 2,50 2,50 2,00 2,50 2,25 2,00 1,75 2,75 1,50 2,13C6 2,33 2,50 1,50 2,50 2,25 2,25 3,00 2,50 2,00 2,50 2,25 1,50 2,26

2,51 2,22 1,13 2,38 2,25 1,38 2,58 2,28 1,57 2,46 2,25 1,29 1,95 2,00 2,14 2,00 Mean 1,98 2,07

Table 7-5: Raw Data I.S.A for Workload (RTS1)

7.3.4 Situation Awareness SASHA items ATCO 1 2 3 4 5 6 7 8 9 10 11 12

C1 5 5 1 1 2 2 4 3 4 1 1 5 C2 5 3 2 2 1 3 4 2 4 n.a. n.a. 4 C3 5 5 2 2 2 2 4 3 3 n.a. n.a. 4 C4 5 5 1 1 1 1 5 4 4 n.a. n.a. 5 C5 5 5 2 2 1 2 4 2 4 n.a. n.a. 5 C6 5 4 1 2 4 2 4 3 4 n.a. n.a. 5

mean 5,0 4,5 1,5 1,7 1,8 2,0 4,2 2,8 3,8 4,7std 0 0,8 0,5 0,5 1,2 0,6 0,4 0,8 0,4 0,5

Table 7-6: Raw Data of SASHA questionnaire (RTS1)

7.3.5 System Usability Scale (SUS) SUS items ATCO 1 2 3 4 5 6 7 8 9 10

C1 4 4 4 1 4 2 4 1 4 2 C2 4 2 4 1 4 2 5 1 4 1 C3 4 4 4 2 3 2 4 2 4 2 C4 5 2 4 1 3 2 5 1 5 1 C5 4 4 4 2 3 3 4 2 4 2 C6 5 4 4 1 3 2 4 1 4 1

mean 4,3 3,3 4,0 1,3 3,3 2,2 4,3 1,3 4,2 1,5std 0,5 1,0 0,0 0,5 0,5 0,4 0,5 0,5 0,4 0,5

Table 7-7: Raw Data of SUS questionnaire (RTS1)

7.4 Raw Data of RTS2 + OST

EMMA2



ID C1 C2 C3 C4 C5 C6 C716 ID C1 C2 C3 C4 C5 C6 C7 1-

G17 5 5 5 6 4 5 5 10-H n.a. 4 5 n.a. 3 5

2-G 5 5 5 6 4 6 11-H 5 5 5 5 5 5 3-G 4 5 5 4 4 4 12-H 5 4 5 4 5 5 4-G 5 5 5 6 5 6 5 13-H 5 4 5 6 6 5 5-G 5 6 5 6 5 6 4 14-H 5 5 6 5 5 5 6-G 4 n.a. 5 6 5 6 3 15-H 5 5 5 5 5 5 7-G 5 4 5 4 n.a. 4 16-H 5 5 5 5 6 5 8-G 5 4 5 5 5 6 17-H 5 3 5 6 6 5 9-G 5 2 5 4 4 4 18-H n.a. 4 5 n.a. 6 5 10-G 5 5 5 5 n.a. 5 19-H n.a. 4 5 n.a. 4 n.a. 11-G 3 n.a. 4 6 4 5 4 20-H 5 4 5 6 6 6 12-G 5 6 5 6 4 6 5 21-H 5 5 5 6 4 4 13-G 5 5 5 6 4 6 5 22-H 4 4 5 6 5 5 14-G 5 5 6 6 6 6 23-H 5 4 5 5 4 4 15-G 4 4 5 n.a. n.a. n.a. 24-H 4 5 5 5 4 5 16-G 5 4 5 n.a n.a n.a 25-H 5 5 5 6 6 5 17-G 5 5 n.a. 5 4 6 5 26-H 5 5 5 6 5 5 18-G 5 5 5 n.a. n.a. n.a. 27-H n.a. 3 n.a. 4 3 6 3 19-G 5 n.a. 5 6 4 6 5 28-H 4 4 5 6 6 6 20-G 5 5 5 5 5 6 29-H n.a. 4 5 4 6 6 1-S 5 5 6 6 5 6 30-H 5 5 5 6 6 6 2-S 5 5 6 6 5 5 31-H 5 4 5 6 6 5 3-S 5 5 6 6 5 5 32-H 5 5 5 6 5 5 4-S 5 5 6 6 5 5 33-H 5 4 5 6 5 5 5-S 6 5 5 6 5 n.a. 4 34-H n.a. n.a. n.a. n.a. n.a. n.a. 6-S 5 5 5 6 5 5 35-H 5 5 5 6 4 6 7-S n.a. 4 6 5 5 6 3 36-H 3 2 5 5 5 4 1-A 4 4 5 6 4 5 37-H 4 5 4 3 4 3 2-A 4 5 n.a. 6 5 5 38-H 2 4 3 3 2 3 3-A n.a. n.a. n.a. n.a. n.a. n.a. 39-H 2 4 3 n.a. 3 n.a. 4-A n.a. n.a. n.a. n.a. n.a. n.a. 40-H 5 n.a. 5 6 5 6 5 5-A n.a. n.a. n.a. n.a. n.a. n.a. 41-H 5 n.a. 5 6 n.a. n.a. 5 6-A n.a. n.a. n.a. n.a. n.a. n.a. 42-H n.a. n.a. n.a. n.a. n.a. n.a. 7-A 5 4 5 5 5 6 43-H 5 5 5 6 6 5 8-A 5 4 5 5 5 6 44-H n.a. 3 3 n.a. n.a. 2 9-A n.a. n.a. 4 5 5 6 4 45-H 5 4 5 6 5 6 10-A n.a. n.a. 5 5 5 6 5 46-H 5 4 5 6 4 6 11-A 6 n.a. 5 6 5 6 5 47-H 5 5 5 6 6 6 12-A n.i. 4 5 5 5 5 48-H 5 5 5 6 6 6 13-A n.a. 5 5 5 5 6 5 1-T 3 3 4 4 2 4 14-A 6 n.a. 6 6 6 6 5 2-T 5 5 5 6 6 6 1-R 4 3 3 3 2 2 3-T 5 4 4 5 5 4 2-R 2 3 3 3 2 3 4-T 4 4 4 4 5 4 3-R 2 3 4 3 2 1 5-T n.a. n.a. n.a. n.a. n.a. n.a. 4-R 2 3 3 4 5 6-T n.a. 3 2 n.a. n.a. 3 5-R 5 4 4 6 2 3 7-T n.a. 4 4 5 5 4 6-R 3 4 4 4 3 3 8-T 5 5 4 4 5 5

16 The additional ATCO C7 was only available in the on-site trials. Hence he only answered questioned there were questioned at the on-sit trials. 17 Numbers in italic origin from the onsite trials.

EMMA2



7-R 3 5 5 5 4 2 9-T n.a. n.a. n.a. n.a. n.a. n.a. 8-R n.a. 3 4 n.a. 3 2 10-T n.a. n.a. n.a. n.a. n.a. n.a. 9-R n.a. 4 n.a. n.a. n.a. n.a. 11-T 5 6 5 6 5 6 5 10-R 4 5 4 4 5 3 12-T n.a. n.a. n.a. 4 2 4 11-R 4 4 3 3 3 13-T 5 3 4 5 5 5 12-R 4 3 4 3 3 3 14-T n.a. 4 4 5 4 6 4 13-R 2 2 3 3 3 4 15-T 5 5 5 5 5 6 14-R n.a 2 n.a. n.a. n.a. 1 16-T 4 5 3 5 5 5 15-R 5 3 4 5 4 3 17-T n.a. 5 5 5 4 5 18-R n.a. 5 5 4 4 4 18-T 4 4 4 5 5 5 19-R 5 3 5 5 4 3 19-T 5 5 5 5 5 5 1-H 5 3 6 5 4 4 20-T 3 3 4 4 2 5 2-H 5 4 5 5 4 3 21-T 2 3 4 n.a. 2 5 3-H 5 4 6 5 4 4 22-T 5 4 4 5 6 4-H 5 3 5 5 4 3 23-T 5 3 3 4 4 4 5-H 5 4 5 5 5 4 24-T 4 5 5 6 5 6 6-H 6 6 6 5 n.a. 6 4 25-T 5 4 5 6 5 5 7-H 5 5 5 4 5 4 26-T 8-H 5 4 5 5 5 4 27-T 5 4 4 4 5 9-H 5 4 5 5 4 4 28-T 4 5 4 6 6 6

Table 7-8: Raw Data of the QE-QF (RTS2 + OST)

Documents

emma2.dlr.deemma2.dlr.de/maindoc/2-D631_PRG-TR_V1.0.pdf · EUROPEAN AIRPORT MOVEMENT MANAGEMENT BY A-SMGCS, Part 2 Contract No. TREN/04/FP6AE/S07.45797/513522 Project Funded by European