Validation Test Plan CDG

Transcription

1 EUROPEAN AIRPORT MOVEMENT MANAGEMENT BY A-SMGCS, Part 2 Contract No. TREN/04/FP6AE/S / Caroline Chabrol, Philippe Montebello DSNA Document No: 2-D6.1.2 Version No Classification: Public Number of pages: 68 Project Funded by European Commission, DG TREN The Sixth Framework Programme Strengthening the competitiveness Contract No. TREN/04/FP6AE/S / Project Manager M. Röder Deutsches Zentrum für Luft und Raumfahrt Lilienthalplatz 7, D Braunschweig, Germany Phone: +49 (0) , Fax: +49 (0) fp6-emma@dlr.de Web page: , - 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.

2 Distribution List Member Type No. Name POC Distributed 1 Web Contractor Sub-Contractor Internet Intranet 1 DLR Michael Roeder 2 AENA José Félix Porras 3 AIF Marianne Moller 4 SELEX Giuliano D Auria 5 ANS_CR Jan Kubicek 8 DSNA Philippe Montebello 9 ENAV Antonio Nuzzo 10 NLR Jürgen Teutsch 11 PAS Alan Gilbert 12 TATM Corinne Heinrich 13 THAV Joseph E. Huysseune 15 AUEB Konstantinos G.Zografos 16 CSL Libor Kurzweil 17 DAS Joachim Bader 18 DFS Klaus-Ruediger Täglich 19 EEC Stéphane Dubuisson 20 ERA Jan Hrabanek 21 ETG Thomas Wittig 23 SICTA Salvatore Carotenuto 24 TUD Christoph Vernaleken 25 SOF Lionel Bernard-Peyre CSA Karel Muendel Customer EC Doris Schroecker Additional EUROCONTROL Paul Adamson 1 Please insert an X, when the PoC of a company receives this document. Do not use the date of issue! Save date: Public Page 2

3 Document Control Sheet 2-SPx Project Manager Michael Roeder Responsible Author Philippe Montebello DSNA Additional Authors Caroline Chabrol EGISAVIA Subject / Title of Document: Related Task( s): 2-WP6.1.2 Deliverable No. 2-D6.1.2 Save Date of File: Document Version: 1.00 Reference / File Name 2-D612_CDG-TP_V1.0.doc Number of Pages 68 Dissemination Level Public Target Date DTI ID No. DTI/R&D/ /MTC Change Control List (Change Log) Date Release Changed Items/Chapters Comment Initial Draft Caroline Chabrol Edition and comments Philippe Montebello Chapter 4 Caroline Chabrol Chapter 2, 3 and 4 Caroline Chabrol All document Philippe Montebello All document Caroline Chabrol, Philippe Montebello All document (edition) Philippe Montebello All document (minor changes for GA Caroline Chabrol review) Paragraphs addressing DIGISCUS Caroline Chabrol experiment No EC comments. Approved Final Version 1.0 Save date: Public Page 3

4 Table of Contents Distribution List... 2 Document Control Sheet... 3 Change Control List (Change Log)... 3 Table of Contents Introduction Project overview Methodology EMMA 2-WP6.2 context Scope of the document Evaluation aims Abbreviations and acronyms CDG Tower Control Positions Clearance Delivery control position Ground control position Runway control position Simulation objectives, hypothesis and metrics Introduction Experimental constraints Objectives, hypotheses and metrics FISSA PRIMA objectives DMAN - VigieStrips objectives DMAN - DIGISCUS objectives Experimental plan Operational environment Armed controller and pilot positions Roissy CDG platform and airspace Traffic samples Technical environment Simulation platform characteristics Tower Control Tools and Functions Working positions equipment Simulation control rooms Scenarios FISSA - PRIMA scenarios DIGISCUS and VigieStrips scenarios Experimental design Experimental variables Simulation exercises plan Actors involved and roles Experimental Management Training Measurements specification Observation Questionnaires Debriefing System Recordings Simulation schedule Annex I References List of Figures List of Tables Annex II Save date: Public Page 4

5 6.1 Simulation exercises description Annex III Pre-experiment questionnaire Post-experiment questionnaires FISSA - PRIMA DIGISCUS - VIGIESTRIPS General Post-exercise questionnaires FISSA - PRIMA DIGISCUS General Save date: Public Page 5

6 1 Introduction 1.1 Project overview The project is named European Airport Movement Management by A-SMGCS, phase 2 with the acronym EMMA2. The duration of the project is 36 months, as a follow-up of the EMMA project (25 months). The project is organised in six different subprojects, which are co-ordinated by five different partners. There are three ground-related subprojects and one onboard-related subproject. Based on an advanced operational concept, three A-SMGCS (with focus on higher services) will be implemented at three European airports: Prague- Ruzynĕ, Toulouse-Blagnac and Milano-Malpensa. The systems are to be tested operationally (i.e. with live traffic). In addition validation activities are also performed at Paris CDG using the implemented A-SMGCS services. The three ground-related subprojects and the onboard-related subproject are autonomous and independent, but they are inter-linked with the concept and validation subprojects to guarantee that the different systems are based on a common A-SMGCS interoperable air-ground co-operation concept and that all are validated with the same criteria. On-site trials and real time simulations are to ensure the assessment of its operational feasibility and operational improvements. 1.2 Methodology To develop the real-time simulation Validation Test Plan, the European - Operational Concept Validation Methodology (E-OCVM) especially designed for this kind of exercise is applied. E-OCVM (Version 2) establishes a uniform framework for the validation of ATM concepts such as A- SMGCS. This methodology is helpful to provide guidelines along the entire validation process. This methodology allows asking the good questions related to validation and presents concrete examples of applications of the methodology. Its step-by-step approach helps the validation team to address the validation activity in an exhaustive way. The E-OCVM approach consists of six steps (and 24 activities) as outlined below. It should be noted that E-OCVM only considers validation, like its predecessor MAEVA. Instead of the E-OCVM terms programme validation objectives (from activity 1.4) and exercise validation objectives (from activity 2.2) the more conventionally used terms High Level Objectives (HLO) and Low Level Objectives (LLO) are used in EMMA2. Save date: Public Page 6

7 Step Activity Description 2-D6.1.1a & b sections Step 0 State 0.1 Understand the problem Section 4.1, 2-D6.1.1a Concept and 0.2 Understand the proposed solution(s) Section 4.2, 2-D6.1.1a Assumptions 1.1 Identify the stakeholders, their needs, and involvement Section 5.1, 2-D6.1.1a 1.2 Identify the existing information, Section 5.2, 2-D6.1.1a including current and target levels of maturity 1.3 Describe validation expectations and Section 5.3, 2-D6.1.1a Step 1 Set outline cases outcomes, products, what Validation will success look like Strategy 1.4 Identify programme validation objectives Section 5.4, 2-D6.1.1a in key performance areas 1.5 Establish initial validation requirements, Section 5.5, 2-D6.1.1a and draft validation strategy 1.6 Select validation tools or techniques Section 5.5, 2-D6.1.1a 1.7 Define validation strategy Section 5.6, 2-D6.1.1a 2.1 Identify stakeholders acceptance criteria and performance requirements Guidance for specific validation test plans in: Section 3.1, 2-D6.1.1b 2.2 Identify project and exercise validation Section 3.2, 2-D6.1.1b Step 2 Determine the Experimental Needs Step 3 Conduct the Experiment Step 4 Determine the Results Step 5 Information for Dissemination to Stakeholders objectives 2.3 Refine validation strategy Section 3.3, 2-D6.1.1b 2.4 Identify indicators and metrics Section 3.4, 2-D6.1.1b 2.5 Specify validation scenarios Section 3.5, 2-D6.1.1b 2.6 Produce validation exercise plan Section 3.6, 2-D6.1.1b Section 3.7, 2-D6.1.1b Section 3.8, 2-D6.1.1b 2.7 Prepare the platform or facility Section 3.9, 2-D6.1.1b 2.8 Conduct pre-exercise testing and training Section 3.10, 2-D6.1.1b 3.1 Conduct validation experiment Section 4, 2-D6.1.1b 3.2 Assess for unexpected effects or Section 4, 2-D6.1.1b behaviours 4.1 Perform analysis specified in the analysis plan Guidance for validation reports in: Section 5.1, 2-D6.1.1b 4.2 Prepare analysis contributions Section 5.2, 2-D6.1.1b 4.3 Prepare validation report Section 5.2, 2-D6.1.1b 5.1 Disseminate information to stakeholders and decision makers Section 6.1, 2-D6.1.1b 5.2 Draw conclusions and decide on actions Section 6.2, 2-D6.1.1b feedback to validation strategy. Table 1: E-OCVM sub-steps and traceability in EMMA2 deliverables 1.3 EMMA 2-WP6.2 context 2-WP6.2 of EMMA2 focuses on validation activities for the HL A-SMGCS functionalities of Paris- CDG operations reproduced on DSNA R&D Athis-Mons simulator. The controllers have an early participation in the specification of the new products. For that reason, specification, development and validation are temporally intertwined. Most specifications were expressed and retrieved independently from EMMA2 (cf. [4], [5], [6]). EMMA2-WP6.2 is the occasion to validate HL A-SMGCS and to disseminate the result at European level. Save date: Public Page 7

8 1.4 Scope of the document The present document 2-D6.1.2, the Validation Test Plan for higher A-SMGCS services at Paris-CDG Airport defines the human in the loop real-time simulations that will be performed in the DSNA R&D Athis-Mons during summer 2008 to validate EMMA2 functions in the CDG airport environment. The document follows the E-OCVM guidelines. It is organised as follows: 1. Introduction Describes, in chapter 1, the project overview, the methodology, the scope of the document, the evaluation aims and gives an explanation of the abbreviations and acronyms used throughout the document. 2. CDG Tower Control Positions Describes, in chapter 2, the ATC control positions that will be simulated. 3. Simulation objectives, hypothesis and metrics Describes, in chapter 3, the objectives of the evaluation as well as the hypotheses and metrics. It also presents the main experimental constraints. 4. Experimental plan Describes, in chapter 4, the operational and technical environment, the functions that will be evaluated in the experiment, the scenarios, the experimental design, the measurements specification and the simulation schedule. 5. Annex I Describes, in chapter 5, the references and the lists of figures and tables. 6. Annex II Describes, in chapter 6, the seven exercises planned for the real-time experiments. 7. Annex III Describes, in chapter 7, the pre-simulation questionnaire, the post-exercise questionnaire and the postsimulation exercise used for the FISSA-PRIMA and DIGISCUS experiments. 1.5 Evaluation aims A human in the loop real-time simulation involves the participation of actors (controllers, pilots) performing their operational tasks in a realistic environment. Three CDG tower control positions (CLD, Ground and Runway positions) will be simulated in order to test the hypotheses related to EMMA2 evaluation objectives. The experiments aim at evaluating: The DMAN interoperability with A-SMGCS and in particular with: an electronic flight strip system for the Ground and Runway controllers, and an electronic flight management tool for the Clearance Delivery controller. An advanced runway safety net (ARSN) based on the controllers instructions (FISSA), enhancing capabilities of A-SMGCS level II. Some of the DMAN and the electronic flight strip (VigieStrips) functions developed by the DSNA R&D department have already been evaluated separately (cf. [5], [8], [9]). The EMMA2 experiment objective is to connect the systems together (interoperability) and to perform an evaluation of the advanced functionalities (HL A-SMGCS). The validation aims are broken down and further analysed in section 2. Save date: Public Page 8

9 1.6 Abbreviations and acronyms ACT AIDA ARSN Acronym A-SMGCS ATC ATIS ATFM BOSSA CAUTRA CDG CDM CENA CFMU CLD CTOT CWP DECOR DEP DISCUS DIGISCUS DMAN DTI DYP EOBT E-OCVM FISSA GND HLO HMI ILS Meaning ACTivation message, to initiate the life of a flight plan Aide à l intégration des Départs des Aéroports : support to integrate departures on an airport Advanced Runway Safety Net Advanced Surface Movement Guidance and Control System Air Traffic Control Aeronautical Traffic Information Service Air Traffic Flow Management Banc d Outils et de Serveurs pour Simulation Aéroport : Bench of tools and servers for aiport simulation Coordinateur Automatique du Trafic Aérien : Automated Air Traffic Manager Roissy Charles De Gaulle airport Collaborative Decision Making Centre d Etudes de la Navigation Aérienne, now DSNA/DTI/R&D Central Flow Management Unit Clearance Delivery Calculated Take Off Time (based on CFMU slot) Controller Working Position Données d Environnement de Contrôle d Orly et de Roissy : broadcasting system for control environment data at Paris-Orly and Paris-CDG Departure Déport d Information de Supervision et de Clairance pour les Utilisateurs dans les approches : clearance delivery controller interface operational in Paris-CDG Tool developed by DSNA R&D displaying information from DISCUS and the DMAN on the same interface Departure Manager Direction de la Technique et de l Innovation DYnamic flight Plan. Type of representation of flight information. Estimated Off-Block Time European Operational Concept Validation Methodology Filet de Sauvegarde Sol Avancé : advanced safety net based on clearance input Ground High Level Objective Human-Machine Interaction Instrument Landing System Save date: Public Page 9

10 Acronym LLO MANEX MER MOBT MTOT MAEVA MVT NOVA OFZ PLN OFZ Outside world QFU RIMCAS RIP RPA RSN RWY SALADIN SALSA SID SPOC STPV TMA TWR TWY VigieStrips VOCALISE Low Level Objective Meaning Manuel d Exploitation : reference document for control operations of a given airport Mise En Route : clearance and parameters provided by the CLD controller about 10 minutes before block departure Managed Off Block Time (planned by the DMAN) Managed Take Off Time (planned by the DMAN) Master ATM European Validation plan Transaction STPV MouVemenT. data exchange forcing coordination Nouveaux Outils et Visu Avancée : new tools and advanced tower cabin Obstacle Free Zone, often assimilated with RPA (Runway Protection Area) Flight Plan Obstacle Free Zone : virtual volume around a runway. This zone is used to detect an alert situation. During a simulation, part of the exercise which is not simulated (either automated or left to operators). Magnetic orientation of runway in use Runway Incursion and Conflict Alert System installed at Paris-CDG Ré-impression de strip : re print of strip Runway Protection Area, often assimilated with OFZ (Obstacle Free Zone) Runway Safety Net Runway Système d Aide à LA Détection des Intrusions : supporting system for intrusion detection Simulateur Aéroport Sol et Approche: airport tower and approach simulator Standard Instrument Departure Serveur POsition de Contrôle : server for controller working position Système de Traitement Plans de Vol : French flight data processing system Terminal Manoeuvring Area Tower Taxiway HMI developed by DSNA R&D for GND and RWY control positions ; endeavours to bring modern solutions for paper strip replacement and enhanced coordination Project consisting in a series of studies related to the use of voice (VHF) in pilots air traffic controllers communication Save date: Public Page 10

11 2 CDG Tower Control Positions There are two to three control positions in the CDG towers: CLD control position: the controller prepares the flight and initiates the process of control. Ground control position: the controller handles the aircraft and vehicles movement on the manoeuvring area, except the runways. Runway control position: the controller handles the aircraft movement on the runways and in the vicinity of the airport. The tower control positions in Roissy have been studied and fully described in several DSNA/DTI documents (cf. [3], [4]). 2.1 Clearance Delivery control position The CLD controller gives departure clearances (SSR code, QFU, SID, Ground R/T frequency) following pilot s requests (via R/T or data-link). At the same time, he gives the start up authorization. The CLD controller also verifies the possibility to comply with the departure slots. He can refuse a start-up authorization if the slot is missed or if the start-up request is too anticipated regarding the slot. Currently, the CLD controller has no available tool that could help him to estimate whether the pilot can comply or not with a slot. The CLD controller also has to try to establish a balance in the use of the take-off runways, according to the strategy defined by the tower supervisor. He can direct some traffic flows toward the less busy runway or delay the start-ups to prevent runway holding points congestion. 2.2 Ground control position The Ground controller handles aircraft on the manoeuvring area out of the runways restricted areas. He manages the ground taxiing of the incoming aircraft from the runway exit to the gate, and of the departing aircraft from the gate to the runway holding points. He also manages the taxiing of towed aircraft (gate to gate movements) and of the tractors when empty. He provides push-back clearances following the pilots requests via R/T. A push-back authorization is given depending on the slots and on the movements in the vicinity of the gate of the concerned aircraft in order to optimise the traffic flow in this area. The Ground controller pre-organises the departing sequence by carrying out ground overtaking when possible and suggesting intermediate access taxiways. To carry out this task, the Ground controller takes account of the slots, the traffic flow distribution on the exit points (SID), the performances and wake vortex category of the aircraft. He can change the take-of runway in order to alleviate the load of a runway, in coordination with the tower supervisor. It may happen that the Ground controller manages a lack of availability of gates. He then can authorize a departure, anticipating on its slot, and making it wait in another place. Several handovers are possible for a departing aircraft before reaching the Runway R/T frequency. In CDG, two apron agents manage the A, B, C, D, E and F gates of the air terminal 2. They handle push-back and taxiing up to the traffic area limits, and then handover the aircraft to the adjacent Ground sub-sectors. Apron agents and ground controllers have almost the same task, but neither the same level of responsibility, nor the same tools. Save date: Public Page 11

12 2.3 Runway control position The Runway controller manages the runways and their restricted areas. Regarding the incoming aircraft : he controls the aircraft spacing in final (adjusting speeds), provides information, gives landing authorisation, initiates go-around when necessary, manages the take-off runway crossing by the incoming aircraft. Regarding the departing aircraft : he gives line-up and take-off clearances in an order taking into account slots, SID distribution, aircraft performances, wake vortex categories and aircraft position on the access taxiways. The take-offs are transferred to the departure controllers when they have reached 1000ft. Incoming aircraft are stocked on intermediate ways before crossing the take-off runway. There may be several simultaneous crossings. Tactically, the Runway controller tries to make an incoming aircraft cross the take-off runway when a pause is needed between two departures because of the wake vortex. In good weather conditions, incoming and departing flows are independent. 3 Simulation objectives, hypothesis and metrics 3.1 Introduction The purpose of the following section is to convert the evaluation aims presented in the section 1.5 into high-level and low-level objectives that can be measured in real-time simulation exercises. This section clearly lists which objectives will be addressed in the real-time activity and which ones will not be addressed. Before addressing the high-level and low-level objectives, it is important to consider the experimental constraints that limit the scope of the real-time simulation. 3.2 Experimental constraints It is important to assess the experimental constraints for real-time simulations, in order to consider their impact on the evaluation objectives. Three main experimental constraints have been identified in the scope of the real time simulations. First, the limited number of sessions (cf. 4.6) will impact on the validity of the results (particularly for statistic interpretation). But the real-time simulations should be seen as helping to identify specific issues, which will be more studied in pre-operational trials. Secondly, the DSNA R&D Athis-Mons platform used for the real-time simulations replicates as far as possible the real environment, but some differences still remain (e.g. the 3D visualisation does not allow a full 360 view; however 320 can be visualised through central and ancillary screens). It is important to keep in mind these differences between the simulated and the real environment when the interpretation of results is done. At last, the real time simulation will not cover all possible cases of operational scenarios. Indeed, the Roissy Charles de Gaulle simulated airport is representative, but an exhaustive approach can not be conducted on the basis of this environment. An extensive validation would require long term assessment. The exercises will depict nominal conditions (CAVOK, daytime operations), in both configurations of the southern doublet of Roissy CDG (facing East and facing West). Save date: Public Page 12

13 3.3 Objectives, hypotheses and metrics Generic validation objectives have been defined in 2-D611b. Area High Level Objectives Low Level Objective Operational Feasibility Operational Improvements Verification of EMMA2 Operational Requirements and Procedures [HLO1] Increase of Safety [HLO2] Increase of Capacity & Efficiency [HLO3] Suitability of Behaviour and Working Performance [HLO4] Reduction of Environmental Impact [HLO5] Verification of the general requirements (services requirements) [LLO1.1] Verification of the general requirements (performance requirements) [LLO1.2] Verification of the surveillance requirements [LLO1.3] Verification of the requirements regarding conflict prediction, detection and alert [LLO1.4] Verification of the requirements regarding conflict resolution [LLO1.5] Verification of the TAXI-CPDLC requirements [LLO1.6] Verification of the routing / planning requirements [LLO1.7] Verification of the guidance requirements [LLO1.8] Verification of the aircraft onboard requirements [LLO1.9] Verification of the vehicle onboard requirements [LLO1.10] Verification of the requirements related to ATCO HMIs [LLO1.11] General usability of new services [LLO1.12] Faster identification of safety hazards [LLO2.1] Increment of safety perception by users [LLO2.2] Improvement the overall punctuality of the departing flights [LLO3.1] Reduction of total holding time [LLO3.2] Reduction of global taxiing time [LLO3.3] Increment of throughput [LLO3.4] Decrement of R/T communication [LLO3.5] Appropriate level of user s workload [LLO4.1] Improved situational awareness of users [LLO4.2] Less human errors [LLO4.3] Reduction of pollutions [LLO5.1] Reduction of noise [LLO5.2] The experiments objectives, hypotheses and metrics of the experiment are presented in the table Save date: Public Page 13

14 below: Save date: Public Page 14

15 3.3.1 FISSA PRIMA objectives The objective of the FISSA PRIMA experiment is to assess an advanced runway safety net (ARSN) based on the controllers instructions (FISSA), enhancing capabilities of A-SMGCS level II. The hypotheses and metrics of the experiment are presented in the table below. N Hypothesis Objective Indicator Metric [HLO1] SPOR Conformance [LLO1.1] Recovery from failure is safe GEN_Serv- 32_Back-up [IND1.1.32] [LLO1.5] ALERT_Serv- 06_Conflict Detection 7 [IND1.5.6] ALERT_Serv- 06_Conflict Detection 7 [IND1.5.6] The controller can manage the traffic without the use of the advanced runway safety net. Assess the controller s ability to safely handle the traffic without the alerting system. Verification of requirements regarding conflict resolution The level of alert displayed for each case of alert is relevant. The triggering alert rules are adapted to the existing procedures. Assess the relevance of the level of alert information displayed. Assess the conformance of the triggering alert rules with the existing procedures. Controller s ability to prevent conflicts on the runway and the restricted areas without the alerting system. Time to detect an incident or an incursion. Controller s feeling on level of alert relevance. Controller s opinion on the conformance of the triggering alert rules to existing procedures. Number of incidents or incursions (with and without the ARSN). Seconds between the conflict occurrence and the controller s action (with and without the ARSN). Decision criteria positive. positive. Save date: Public Page 15

16 ALERT_Serv- 09_Alert Continuity [IND1.5.9] ALERT_Serv- 10_Unambiguity HMI_Serv- 22_Presentation of Conflict Alerts 1 [IND1.5.10] ALERT_Serv- 16_Stages of Alert [IND1.5.16] [LLO1.11] HMI_Serv- 03_Efficient Input Devices [IND1.11.3] The alert is displayed continuously while the conflict is detected The conflict information is clearly, visibly and unambiguously displayed on a surveillance display and on the electronic flight strips system. The runway safety net provides the controller with two types of alerts, named Information & Alarm. The runway safety net uses both the surveillance data and the controller s clearances input. Assess if the alert remains until the end of the conflict. Assess the presentation quality of the alert information displayed by the radar & E-strips HMI. Assess if the ARSN provides the two levels of alerts. Assess if the alerts take into account the surveillance data and controller s input. Verification of the requirements related to ATCO HMIs The electronic flight strips system enables timely clearances input that can be used to trigger alerts. Assess the electronic flight strip system usability (operational usability of the e-strips + safety net). Controller s opinion on the correspondence between the duration of the alert display and the duration of the conflict. Controller s feeling on alert presentation quality. Triggering of Information alerts. Triggering of Alarm alerts. Triggering of surveillance alerts. Triggering of clearance alerts. Time to input a clearance. Controller s feeling on input efficiency Number of Information alerts. Number of Alarm alerts. Number of surveillance alerts. Number of clearance alerts. Seconds between the start and the end of the input. positive. positive equal to or less than with paper strips (cf. [16]). positive Save date: Public Page 16

17 HMI_Serv- 12_Traffic Situation Display [IND ] HMI_Serv- 22_Presentation of Conflict Alerts 1 [IND ] [LLO1.12] The alert display enables the controller to easily understand the situation. The controller is provided with an indication of a conflict alert as soon as a potential conflict is detected. The surveillance display and the electronic flight strips system display the alerts at the same time. General usability of new services No other enabler would be better suited to the task of the Runway controller. An aircraft detected landing without clearance and < T1 from threshold shall trigger an INFORMATION coding. A movement entering the runway protection area without clearance triggers an alert (information). An aircraft detected crossing or lining up without clearance shall trigger an INFORMATION coding. Assess the ability of the controller to understand the situation. Assess the relevance of the alert information displayed by the radar & E-strip HMI. Assess the simultaneity of the alert display on both HMI. Assess if controllers have other ideas about possible enablers. Assess if an INFO coding is triggered when an a/c lands without clearance. Assess if an INFO coding is triggered when an a/c enters the RPA without clearance. Assess if an INFO coding is triggered when an a/c crosses the runway or lines up without clearance. Controller s opinion on his/her ability to easily understand the alert situation. Controller s feeling on alert relevance at every instant from detection till the end. Moment of the alert display. Open list of enablers. Triggering of Information alert. Triggering of Information alert. Triggering of Information alert. An aircraft detected taking off Assess if an INFO coding Triggering of Seconds between the alert display on the radar HMI & on the E-strips HMI. Number of (significant) enablers. Number of positive. positive. null. 0. Save date: Public Page 17

18 without clearance shall trigger an INFORMATION coding. An aircraft cleared to take off with traffic on the runway protection area shall trigger an ALARM coding An aircraft cleared to take off with a movement cleared to line up, cross or taxi ahead shall trigger an ALARM coding An aircraft detected taking off without clearance with a movement cleared to cross, line up or taxi shall trigger an ALARM coding. An aircraft cleared to land with a movement on the Runway Protection Area shall trigger an ALARM coding. An aircraft detected landing and < T1 from threshold while an aircraft is cleared to line up on the same runway shall trigger an INFORMATION coding. An aircraft detected landing and < T2 from threshold while an aircraft is triggered when an a/c takes off without clearance. Assess if an ALARM coding is triggered when an a/c is cleared to take off while a traffic is on the RPA. Assess if an ALARM coding is triggered when an a/c is cleared to take off while a traffic is cleared to line up, cross or taxi ahead. Assess if an ALARM coding is triggered when an a/c takes off without clearance while a traffic is cleared to line up, cross or taxi ahead. Assess if an ALARM coding is triggered when an a/c is cleared to land while a traffic is on the RPA. Assess if an INFO coding is triggered when an a/c lands without clearance and <T1 while an a/c is cleared to line up on the same runway. Assess if an ALARM coding is triggered when Information alert. Triggering of Alarm alert. Triggering of Alarm alert. Triggering of Alarm alert. Triggering of Alarm alert. Triggering of Information alert. Triggering of Alarm alert. Save date: Public Page 18

19 is cleared to line up on the same runway shall trigger an ALARM coding. An aircraft cleared to take off while an aircraft is detected landing and < T1 from threshold on the same runway shall trigger an INFORMATION coding. An aircraft cleared to take off while an aircraft is detected landing and < T2 from threshold on the same runway shall trigger an ALARM coding. An aircraft cleared to land and < T1 from threshold while an aircraft is detected lining up on the same runway shall trigger an INFORMATION coding. An aircraft cleared to land and < T2 from threshold while an aircraft is detected lining up on the same runway shall trigger an ALARM coding. An aircraft cleared to land and < T1 from threshold while an aircraft is cleared to cross shall trigger an INFORMATION coding. an a/c lands without clearance and <T2 while an a/c is cleared to line up on the same runway. Assess if an INFO coding is triggered when an a/c is cleared to take off while an a/c lands and <T1 without clearance on the same runway. Assess if an ALARM coding is triggered when an a/c is cleared to take off while an a/c lands and <T2 without clearance on the same runway. Assess if an INFO coding is triggered when an a/c is cleared to land and <T1 while an a/c lines up without clearance on the same runway. Assess if an ALARM coding is triggered when an a/c is cleared to land and <T2 while an a/c lines up without clearance on the same runway. Assess if an INFO coding is triggered when an a/c is cleared to land and <T1 while an a/c crosses Triggering of Information alert. Triggering of Alarm alert. Triggering of Information alert. Triggering of Alarm alert. Triggering of Information alert. Save date: Public Page 19

20 without clearance. Assess if an ALARM An aircraft detected landing and < coding is triggered when T2 from threshold while an aircraft an a/c is cleared to land is cleared to cross shall trigger an ALARM coding. and <T2 while an a/c crosses without clearance. [HLO2] Increase of safety [LLO2.1] Reduced number of incident and accident The advanced runway safety net Assess the improvement enables the runway controller to in terms of prevention prevent and better handle and handling of unexpected events. unexpected events [LLO2.2] Assess the improvement of detection of restricted or prohibited areas incursions Assess the improvement in terms of prevention of incidents caused by ATC/pilot errors Faster identification of safety hazards The clearance alerts are triggered before the surveillance alerts. The alerts are provided by the advanced runway safety net within enough time to enable the appropriate remedial action. Assess if the clearance alerts are triggered before the surveillance alerts. Assess the available time between the alert triggering and the action to perform. Triggering of Alarm alert. Incidents on the runway Incursions of the restricted areas Controller s opinion on the clearance alerts utility. Time between a clearance alert and a surveillance alert. Controller s opinion on the time left following an alert triggering. Number of incidents on the runway Number of go around Number of restricted areas incursions Seconds between the clearance alert and the surveillance alert. Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. positive. positive. Save date: Public Page 20

21 [LLO2.3] Increment of safety perception by users The number of false and nuisance alerts is low enough to meet local safety objectives and to ensure that the controller does not downgrade the importance of alerts. [HLO3] Increase of capacity and efficiency [HLO4] Behaviour & working performance [LLO4.1] Appropriate level of user s workload The necessary input of the clearances into the e-strip does not increase the controller s workload. [LLO4.2] The method of work is still appropriate (i.e. input a clearance after having giving it and waiting for pilot s read-back). The recovery from an alert to the control activity is easy and quick. Improved situational awareness of users The controller does not delegate the surveillance to the system (i.e. remains proactive). [LLO4.3] Less human errors An error of input does not induce major consequences. [HLO5] Decreased environment impact Assess the occurrence of false and nuisance alerts. Assess the controller s workload using the E- strips system. Assess if the method of work is still appropriate or if it should be modified. Assess the ability of the controller to perform his/her tasks after an alert. Assess the ability of the controller to anticipate conflicts. Assess the consequence of input errors. Triggering of false alerts. Controller s opinion on the limited number of false or nuisance alerts. Controller s feeling on his/her workload with the E-strips. Controller s opinion on the method of work. Controller s opinion on his/her ability to recover from an alert. Situation awareness Controller s opinion on the consequences of input errors. Number of false alerts. Not assessed in the 2008 experiment. positive. positive. positive. positive positive. positive. Save date: Public Page 21

22 3.3.2 DMAN - VigieStrips objectives The objective of DIGISCUS VigieStrips experiment is to assess the DMAN interoperability with an electronic flight management tool for the Clearance Delivery controller (i.e. DIGISCUS) and with an electronic flight strip system for the Ground and Runway controllers (i.e. VigieStrips). VigieStrips has already been evaluated. Only the alerts display provided by the DMAN is new and to be assessed. The hypotheses and metrics of the experiment regarding VigieStrips are presented in the table below. N Hypothesis Objective Indicator Metric [HLO1] SPOR Conformance [LLO1.1] Verification of the general requirements (services requirements) GEN_Serv- 16_Failure Effect [IND1.1.16] As an optimisation tool, the DMAN has no impact on safety. Assess the risk of loss of strips due to DMAN failure. GEN_Serv- 17_Failure Indication [IND1.1.17] The system informs the controller when a failure occurs. Assess the risk of a loss of another function. Assess if the system notifies failures. Assess if planning data is explicitly displayed as obsolete in case of DMAN failure. Verification of the routing / planning requirements [LLO1.7] ROUT_Serv- 17_Surface The slot & slot alerts information Traffic Flow provided by the DMAN allows for a Optimisation more efficient traffic management. [IND1.7.17] [LLO1.12] General usability of new services Assess the relevance of the slot & slot alerts information displayed by the E-strip HMI. Loss of strips after a DMAN failure. Loss of control capabilities. Conformance of indicator to system status. Obsolete data indicator. Controller s feeling on slot & slot alerts information relevance. Save date: Public Page 22 Number of lost strips after a DMAN failure. Number of lost capabilities. Difference between real status and declared status. Number of obsolete datum without a obsolete indicator. Decision criteria Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. positive.

23 No other enabler would be better suited to the task of the ground & runway controllers. [HLO2] Increase of safety [HLO3] Increase of capacity and efficiency [LLO3.5] Decrement of R/T communication The R/T communications efficiency is increased due to the provision of accurate information. [HLO4] Behaviour & working performance [LLO4.1] Appropriate level of user s workload The coordination efficiency is HMI_Servincreased due to the sharing of 46 to 54 information. Assess if controllers have other ideas about possible enablers. Assess if the R/T communications are facilitated Assess if the coordination is facilitated Open list of enablers. Messages exchanged between the controllers and the pilots. Controller s opinion on the increase of R/T communication efficiency Messages exchanged between the controllers. Controller s opinion on the increase of Number of (significant) enablers. Number of coordination by mobile. Length of the messages. Content of the messages. Number of coordination by mobile. Length of the messages. Content of the messages. 0. (cf. [17]) Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. positive. Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. positive. Save date: Public Page 23

24 The workload of the Ground and Runway controllers is reduced due to an improved parking management. It is helpful for the Ground controller to be provided with a list of e-strips in start-up clearance order. Assess if the workload of the Ground and Runway controller is reduced Assess if the display of a list of e-strips in start-up clearance order is helpful for the Ground controller. [LLO4.2] Improved situational awareness of users The quality of the Ground & Runway Assess the presentation of controllers display, with respect to the DMAN information information provided by the DMAN, displayed by the E-strips allows an efficient traffic HMI. management. [HLO5] Decreased environment impact 2 coordination efficiency Controller s feeling on his/her workload. Controller s feeling on the relevance of the display of a list of e-strips in start-up clearance order. Controller s feeling on information presentation. positive. positive. positive. 2 The environmental impact is not a validation objective as the DMAN is not assessed here. Save date: Public Page 24

25 3.3.3 DMAN - DIGISCUS objectives The objective of DIGISCUS VigieStrips experiment is to assess the DMAN interoperability with an electronic flight management tool for the Clearance Delivery controller (i.e. DIGISCUS) and with an electronic flight strip system for the Ground and Runway controllers (i.e. VigieStrips). The hypotheses and metrics of the experiment regarding DIGISCUS are presented in the table below. N Hypothesis Objective Indicator Metric [HLO1] SPOR conformance [LLO1.1] Verification of the general requirements (services requirements) GEN_Serv- 16_Failure As an optimisation tool, the DMAN Assess the risk of loss of Effect [IND1.1.16] has no impact on safety. strips due to DMAN failure. GEN_Serv- 17_Failure Indication [IND1.1.17] The system informs the controller when a failure occurs. Assess the risk of a loss of another function. Assess if the system notifies failures. Assess if planning data is explicitly displayed as obsolete in case of DMAN failure. Verification of the requirements related to ATCO HMIs Loss of strips after a DMAN failure. Loss of control capabilities. Conformance of indicator to system status. Obsolete data indicator. Number of lost strips after a DMAN failure. Number of lost capabilities. Difference between real status and declared status. Number of obsolete datum without a obsolete indicator. Decision criteria Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. [LLO1.11] HMI_Serv- The CLD controller easily 15_Accessible Assess if the CLD controller Controller s opinion understands all the alerts Traffic easily understands the on alerts information displayed on his/her positive. Information different alerts information. understanding. HMI. [IND ] HMI_Serv- The departure traffic data is Assess departure traffic data Time of departure Minutes between more Save date: Public Page 25

26 44_EFS Timing of Departure Traffic Data [IND ] [LLO1.12] displayed on the concerned positions at a time parameter (locally defined) before the expected off-block time (POBT 3 ). All the alerts provided by the DMAN are useful to the CLD controller. General usability of new services No other enabler would be better suited to the task of the ground & runway controllers. The control instructions provided by the controller (e.g. clearances, time of input, etc.) allow the DMAN to compute an optimised MOBT. It is acceptable for the controller to have sequence information integrated into his/her tool. availability. traffic data display. departure traffic data display and POBT display. Assess if the CLD controller wants to be provided with all the alerts provided by the DMAN. Assess if controllers have other ideas about possible enablers. Assess the utility of the interoperability between DMAN and CLD HMI. Assess if the integration of the sequence information is acceptable for the controller. [HLO2] Increase of safety [HLO3] Increase of capacity and efficiency [LLO3.1] Improvement of overall punctuality of the departing flights Controller s opinion on DMAN alerts usefulness. Open list of enablers. Impact of control instruction on the MOBT. New MOBT following controller input is better than previous one. Controller feeling on the acceptability of the sequence information integration. Number of (significant) enablers. Number of recalculation following controller inputs. Frequency of recalculation. than 30 minutes. positive. 0. strictly positive. positive. positive. 3 POBT (Planned Off-Block Time) is the flight plan reference off-block time. Save date: Public Page 26

27 HMI_Serv- 15_Accessible Traffic Information [LLO3.2] The estimated waiting time at the stand provided by the DMAN allows an efficient traffic management. The MOBT provided by the DMAN allows an efficient traffic management. Reduction of total holding time The estimated waiting time at threshold provided by the DMAN allows an efficient traffic management. [LLO3.3] Reduction of global taxiing time [LLO3.4] [LLO3.5] HMI_Serv-46 to 54 The estimated taxiing time provided by the DMAN allows an efficient traffic management. Increment of throughput The ETOT provided by the DMAN allows an efficient traffic management. Decrement of R/T communication The coordination efficiency is increased due to the sharing of information between airport stakeholders. The R/T communications efficiency is increased due to the provision of accurate information. Assess the presentation of the estimated waiting time at stand displayed by the CLD HMI. Assess the presentation of the MOBT information displayed by the CLD HMI. Assess the presentation of the estimated waiting time at threshold information displayed by the CLD HMI. Assess the presentation of the estimated taxiing time information displayed by the CLD HMI. Assess the presentation of the ETOT information displayed by the CLD HMI. Assess if the coordination is facilitated Assess if the R/T communications are facilitated Controller s feeling on information presentation. Controller s feeling on information presentation. Controller s feeling on information presentation. Controller s feeling on information presentation. Controller s feeling on information presentation. Data exchanged between airport stakeholders. Messages exchanged between the controllers and the pilots. Length of the messages. Content of the messages. Number of coordination by mobile. Length of the positive. positive. positive. positive. positive. Not assessed in the 2008 experiment. Not assessed in the 2008 experiment. (cf. [17]) Not assessed in Save date: Public Page 27

28 [HLO4] Behaviour and working performance [LLO4.1] Appropriate level of user s workload The workload of the Ground and Runway controllers is reduced due to an improved parking management. [LLO4.2] HMI_Serv- 39_EFS Data Format HMI_Serv- 39_EFS Data Format HMI_Serv- 39_EFS Data Format The workload of the CLD controller is reduced due to an improved parking management. Improved situational awareness of users The start-up & start-up alerts information 4 provided by the DMAN allows for a more efficient traffic management. The slot & slot alerts information provided by the DMAN allows for a more efficient traffic management. The ACARS alert 5 information provided by the DMAN allows for a more efficient traffic management. Assess if the workload of the ground and runway controllers is reduced Assess if the workload of the CDL controller is reduced Assess the relevance of the start-up alerts information displayed by the CLD HMI. Assess the relevance of the slot & slot alerts information displayed by the CLD HMI. Assess the relevance of the ACARS alert information displayed by the CLD HMI. Controller s opinion on the increase of R/T communication efficiency Controller s feeling on his/her workload. Controller s feeling on his/her workload. Controller s feeling on start-up & start-up alerts information relevance. Controller s feeling on slot & slot alerts information relevance. Controller s feeling on ACARS alert information relevance. messages. the 2008 experiment. Not assessed in Content of the the 2008 messages. experiment. positive. positive. positive. positive. positive. Not assessed in the 2008 experiment. 4 The start-up information provides the aircraft status regarding its MOBT. The start-up alert information is only used for aircraft having a slot. 5 An ACARS alert is displayed when it takes more than 5 minutes to the pilot to acknowledge the CLD controller s authorisation (given by data link) to start-up. Save date: Public Page 28

29 HMI_Serv- 39_EFS Data Format HMI_Serv- 39_EFS Data Format The Push-back alert 6 information provided by the DMAN allows for a more efficient traffic management. The de-icing alert information provided by the DMAN allows for a more efficient traffic management. [HLO5] Decreased environment impact Assess the relevance of the Push-back alert information displayed by the CLD HMI. Assess the relevance of the de-icing alert information displayed by the CLD HMI. Controller s feeling on Push-back alert information relevance. Controller s feeling on de-icing alert information relevance. positive. Not assessed in the 2008 experiment. 6 The push-back alert informs the controller about the aircraft authorised to start-up more than 20 minutes ago, which have not yet received or asked for a push-back clearance. Save date: Public Page 29

30 4 Experimental plan 4.1 Operational environment The Roissy Charles de Gaulle (CDG) operational environment is simulated involving three tower control positions (i.e. one Clearance Delivery control position, one Ground control position and one Runway control position) Armed controller and pilot positions Air traffic control positions In the FISSA/PRIMA experiment, two TWR control positions will be assessed in the CDG environment: 1 Ground control position, 1 Runway control position. These two control positions are simulated so that during validation, there will be simultaneously one controller in front of each of these positions. In the DIGISCUS VigieStrips experiment, three TWR control positions will be assessed in the CDG environment: 1 CLD control position, 1 Ground control position, 1 Runway control position. These three control positions are simulated so that during validation, there will be simultaneously one controller in front of each of these positions. The controllers will rotate between the different roles (i.e. the controller working positions) in order to get the widest possible set of data Pseudo-pilots control positions There will be 4 to 5 pseudo-pilot positions (managed each by one pseudo-pilot). In the FISSA/PRIMA experiment: One to handle all the traffic in the North part of the airfield (runways + ground) without any radio contact (only the South runways being simulated). One to handle the traffic in contact with the S/E Ground controller (depending on the airport configuration). One to handle the traffic in contact with the S/S/W Ground controller (depending on the airport configuration). One to handle the traffic in contact with the South Runway controller. In the DIGISCUS VigieStrips experiment: One to handle all the traffic in the North part of the airfield (runways + ground) without any radio contact (only the South runways being simulated) 7. One to handle all the traffic departures in contact with the CLD controller to initiate the start-up. One to handle the traffic in contact with the S/E Ground controller (depending on the airport configuration) 8. One to handle the traffic in contact with the S/S/W Ground controller (depending on the airport configuration) 9. One to handle the traffic in contact with the South Runway controller. 7 This role will be held by DSNA staff. 8 Depending on the airport configuration, this role will be held by DSNA staff. 9 Depending on the airport configuration, this role will be held by DSNA staff. Save date: Public Page 30

31 Note: The pilot in charge with ground traffic (S/E or S/S/W depending on the traffic configuration), will also manage the traffic usually handled by the apron (i.e. push-back and taxiing manoeuvres in Air France stands (CDG2-ABCDEF)) Pseudo-controller position A position called Pseudo-Controller TSF (TSF for Transfer) is created to transfer the e-strips of the aircraft handled by the Pseudo-Pilots who are not directly in contact with the controllers (e.g. the PP handling the traffic in the North part of the airfield; these areas, not managed by the controllers in the context of this experiment are called the outside world, cf ). The pseudo-controller has two interfaces available: An e-strip interface (VigieStrips) for transfer to an active ATCO; A simulator interface (SALSA) for transfer to an active pseudo-pilot. When an aircraft has to be taken in charge by the Pseudo-Pilot of the ground part of the airfield that is managed by the Ground Controller simulated in the experiment, the outside world Pseudo-Pilot transfers it to the PC TSF. When the PC TSF receives the e-strip on his VigieStrips HMI, he transfers the corresponding e-strip to the Ground Controller via his VigieStrips HMI, and then transfers the aircraft to the Pseudo-Pilot in contact with the Ground controller via his simulator (SALSA) HMI. A Pseudo-Pilot, a VigieStrips specialist or anyone formerly trained to accomplish these tasks, can hold this position. The Pseudo-Controller TSF role is to: 1. Manage via his VigieStrips HMI, all the e-strips of the outside world sectors (North, Apron, South Ground not simulated): 2. Write Pushback and Taxi instructions. 3. Discard the useless e-strips (i.e. of the arriving and departing aircraft that will never cross the South Ground sector simulated: SSE or SSW, some Apron exits...). 4. Transfer the e-strips of the aircraft coming from the outside world sectors to the South Ground Controller simulated. Figure 1 : Scheme of the control areas at Paris-CDG Save date: Public Page 31

32 4.1.2 Roissy CDG platform and airspace Traffic configurations Eastward and Westward RWY configurations will be supported during experiments. Dealing with the southern runways, the aircraft land on the runway 26L (westward configuration) or 08R (eastward configuration), and thus take-off from runway 26R (westward configuration) or 08L (eastward configuration). Figure 2 : Map of the runways at Paris-CDG Airport areas simulated / external world Only the southern part of the platform, which encompasses CDG2 and runways 08L/26R 08R/26L, will be simulated. The mobiles (aircraft and vehicles) that circulate in this area will be placed under the responsibility of Ground and Runway controllers. The northern part (CDG1 and northern runways) will be assimilated to the outside world. In the westward configuration, only the south east ground position will be simulated whilst the other position (south west) will be part of the outside world. In this latter case, the pseudo-pilot who manages the south west area will use instructions to guide the traffic in an optimal manner towards the simulated ground position. The reverse situation applies in eastward configuration. Regarding the air part (concerning mainly the Runway position), the departing aircraft are displayed on the air radar image when they are 40 ft high. The aircraft simultaneously disappear from the ground image. The arriving aircraft are displayed on the ground image when they are 40 ft high. The aircraft on final are visible as far as 10NM from the runway threshold. The air part is assimilated to the outside world as far as aircraft are not guided via the RWY position. Save date: Public Page 32

33 4.1.3 Traffic samples The samples used for the simulation have been built using real data sources. These rough data have been used to generate elaborated exercises for pilots training, controllers training, pre-experiments and experiments. They were made to cope with the project simulation needs. 4.2 Technical environment Simulation platform characteristics SALSA Figure 3: SALSA HMI SALSA is a real-time human in the loop tower simulator developed by DSNA R&D (ex CENA) department. SALSA constitutes a testing and experimental platform being integrated within the scope of studies carried out in the DSNA R&D department. SALSA is the airport simulator that provides radar tracks and flight plan information to TSD HMI (SALADIN) and FISSA PRIMA (enhanced safety layers). SALSA enables to meet the following objectives: To test and validate new tools devised for control (e.g. VigieStrips, DIGISCUS HMI). To test new control procedures or new configuration of the airport platform. To analyse a situation through the replay of a recording. To provide ground events for other simulation systems. This simulator is dedicated as System devised for air traffic control and so addresses only airport events that can pertain to the control tower and more precisely to the staff assigned in the watchtower that is to say the controllers working as CLD, ground, runway controllers and the tower supervisor. Save date: Public Page 33

34 The simulated events encompass: Movement of aircraft. Movement of vehicles such as flycos, firemen, ambulances, motor sweepers, etc. Data related to an aircraft and concerning operational supervision aspects (i.e. flight status as created, awakened, activated...), who is in charge of managing the aircraft, etc. Platform events such as taxiway closure, modification of runways configuration, lighting system failure, unusable stand, etc. Modifications linked to operational configuration: control positions pooling or splitting, Some meteorological parameters such as the wind, the visibility, the runway adherence depending on rain, snow or black ice. SALSA enables a wide range of possibilities that depend on the operating mode and the simulator environment. It is designed to enable easy connection with other simulators: air simulator, other SALSA simulator, HMI components, etc. PRIMA R&D tools to validate (NOVA tools) Servers Tower simulator BOSSA server Bossa adapter SALSA FISSA SPOC Digiscus SALADIN Vigiestrips Figure 4: Technical architecture of the simulation SPOC SPOC is a server meant to dispatch information to NOVA tools. It constitutes the middleware between BOSSA server and SALADIN, VigieStrips and DIGISCUS HMI (cf. Figure 4: Technical architecture of the simulation). SPOC is also used as a supervision module for control positions. It is responsible for the sectors/positions assignment and for the flight plan management and broadcast to different positions Tower Control Tools and Functions The tower control tools developed by the DSNA R&D department will be used and tested during the simulations. They are described in the following sections presenting the functions provided to the controllers for the simulation. Save date: Public Page 34

35 DMAN The Departure MANager (DMAN) is a support tool aiming at helping the ATCOs in the management of a departure flight sequence (cf. [10]). DMAN functions are: To establish a provisional and reliable view of the traffic departing from the main airports and the adjacent airfield, and to present it as sequences intended to the different runways and significant TMA beacons. To provide the optimal time to make an aircraft leave its stand from a calculated take-off sequence taking into account all the ATFM and TMA constraints to achieve an optimal use of the capacity while maintaining a high level of security. To verify that the actual take-off sequence complies with the constraints (ATFM and TMA). The DMAN receives, exchanges, and provides information to external systems such as the Advanced Surface Movement Guidance and Control System (A-SMGCS) and the electronic flight strip system. AIDA, SALADIN, VigieStrips and DIGISCUS are respectively the DMAN, the A-SMGCS, the electronic flight strip and the CLD HMIs developed at the DTI Athis-Mons. AIDA HMI was validated before (cf. [9]). It will not be validated again during this simulation, for the purpose of the CLD HMI (namely DIGISCUS) is to see how to integrate DMAN information in an existing CLD HMI (namely, DISCUS, operational in French significant airports) SALADIN Figure 5: SALADIN HMI for the Ground controller SALADIN is the A-SMGCS traffic situation display for the Runway and Ground control positions. It collects, gathers and processes in real time the information coming from the different sensors and other systems to which it is connected. It communicates the relevant information (including the alerts) to the controllers. Save date: Public Page 35

36 The objectives of SALADIN are: To increase safety on the ground in all visibility conditions. To help the authorised aircraft and vehicles manoeuvring effectively on the manoeuvring area in defined visibility conditions. To attain these objectives, SALADIN mainly provides a support to ground traffic monitoring (aircraft and vehicles automatically identified) VigieStrips Description C G A E F D B Figure 6: VigieStrips HMI Function A Pending departures table B Pending arrivals table C Operational table D Transfer area E Arrival e-strip F Departure e-strip G RWY pending e-strips window Description Receives DEP e-strips newly created in Pending format (CLD ACT) Receives ARR e-strips newly created Controller s working area (free positioning of e-strips on 2 columns + central position) The ATCO directs e-strips to this area for transfer to the next sector ARR e-strip in operational format DEP e-strip in operational format Placing area of DEP e-strips for the Runway controller Table 2: Description of Vigiestrips HMI VigieStrips is an electronic flight strips system for the Ground and Runway controllers aiming at maintaining the qualities of the paper strips while being able to integrate the strip information in a coherent information system. It offers simple and intuitive interactions through tactile interaction and writing recognition based on current operational symbols. Save date: Public Page 36

37 VigieStrips HMI, via the electronic strips, the manipulation and the colour coding, is adapted to receive the DMAN sequence information. It allows integrating the data the controller inputs onto the strips: the clearances (e.g. push-back, taxi, line-up, take-off) and additional information as the allocated stand exit or the runway access taxiway. Designed for the Ground and Runway controllers, VigieStrips facilitates inter sectors dialogues such as the transfer of control responsibility of a flight from a sector to the following one (Ground to Runway or Runway to Ground). This functionality corresponds to the current manual transfer of the flight paper strips to the controller of the following sector. The system directs automatically the e- strips toward the relevant next control position. Once an e-strip is transferred from one HMI, it is displayed on the HMI of the following control sector (in its pending e-strips table in chronological order of transfer), or if already existing on the following sector HMI (with reading rights only), the controller obtains writing rights. The Ground controller also has the possibility to replace the automatic transfer by a manual one (e.g. to prepare a departure sequence), placing directly the e-strip in the Runway controller pending e-strips table via a specific window (displaying a capture of the Runway controller pending e-strips table, see Figure 6 above). The e-strip automatically transferred disappears from the transfer area of the sending controller HMI when the receiving controller removes it from the pending e-strips table (Ground controller) or as soon as a place becomes free in the pending e-strips table (Runway controller). The data related to each transferred e-strip is automatically recorded by the system. The VigieStrips HMI also displays the FISSA PRIMA alerts information in consistency (and redundancy) with the A-SMGCS display DMAN VigieStrips interoperability The services identified for VigieStrips and the DMAN are described in the table below, terms are explained in Table 2. Each function described is linked to a low level validation objective to show the means proposed to the controller to achieve his task. However, not all the functions described below are represented in the table of objectives in paragraph 3.3.1, and 3.3.3, for some of the function checks are considered to be more verification than validation. Save date: Public Page 37

38 Function Description Remark Configure the e-strips allocation into each container of the pending table. Choose a position for the pending e-strips table. Select an automatic classification into the pending e-strips table. Cancel the incoming e-strips feed of the pending e-strips table. Move manually an e-strip from the pending table toward the operational table. Shift manually an e-strip in a column of the operational table. Access the e-strip extended format. Choose to direct the departing e-strips into the inferior or superior container of the pending table. Place the pending e-strips table on the left or right side of the HMI. Choose an automatic classification for the e- strips into the pending e-strips table. Choose not to visualise anymore the incoming e- strips on the HMI. For anticipation need, move a departing or incoming e-strip from the pending table toward the operational table. Shift an e-strip on the right or left of a column to show a flight (flight pushing back, waiting to cross the runway, etc.) Access the extended size of a departing or incoming e-strip to access free writing or complementary information (including modification field of the following sector). 8 Export a free writing. Export not possible Carry out a modification of the Modify the SID letter information directly via the 9 SID letter / Particularise the e-strip and via a simple and quick dialog. item only. Carry out a modification of the Modify the QFU information directly via the e- 10 QFU / Particularise the item strip and via a simple and quick dialog. 11 Carry out a same action on a Apply the effect of one action on several e-strips. Not developed. Function not developed. By default allocation. The location of the pending e-strips table cannot be configured: it is on the left by default. Several sorting criteria are available to the controller: Alphabetic Numeric Stand Start-up order (flight activation order) It is feasible by playing with the size of the pending table, opening a discharge spout for hidden e-strips. This is meant to help the controller in his situational awareness (organisation of the board; working method ) Working method currently applied with the paper strips reproduced. The following sector cannot be modified. Free text writing is implemented but the writing is not transferred to the adjacent sector. The SID letter can be modified by the controller, but the flight plan is not updated. For information The QFU can be modified by the controller, but the flight plan is not updated. For information only. Associated LLO [LLO4.1] [LLO4.1] [LLO4.2] [LLO4.2] [LLO3.5] Save date: Public Page 38

39 group of e-strips 12 Particularise a flight 13 Acknowledge an alarm Function Description Remark Select / de-select a runway for occupation Be informed of a flight ahead of its departure slot. Order manually the Runway controller s departing pending e-strips through a specific window. Display the optimal time to make an aircraft leave its stand. Display the estimated take-off time. Particularise a flight in order to highlight it on the radar image and on the e-strips operational table. Cancel flash indicator related to the alarm coding. Choose the runway that will be occupied by a vehicle. Be informed of a flight ahead of its CFMU slot. Interact directly with the Runway controller s pending e-strips table to suggest a specific departing queuing different from the chronological one in order to sequence the departures. Display the Managed Off Block Time (MOBT), i.e. time limit to comply with CFMU slot. Display the estimated take-off time updated following the clearances provided: Push-back, Taxi, Line-up authorization, Take-off. The controller can select a flight from the e-strip HMI and highlight it on the radar image. The flight is unselected when the e-strip is released. The alarm colour coding (red) remains, only the flash indicator is stopped. Not developed: vehicle e-strips bear no other information than call sign. A visual signal is provided on the e-strip, yellow if the flight is early, red if late. For instance, the Ground controller can organise the pending e-strips of the Runway controller by access way to the runway. Display of a blue label presenting the text P= when the Ground controller takes the departing e- strip in the pending e-strips table. The ETOT is permanently displayed in the extended format of the e-strip. Associated LLO [LLO4.2] [LLO1.12] [LLO1.7] [LLO3.5] [LLO4.1] [LLO4.1] [LLO4.1] Table 3: Description of VigieStrips functions Save date: Public Page 39

40 DIGISCUS Description A B G C RWY North E Pending flights F Waiting flights H D RWY South I J K Figure 7: DIGISCUS HMI Function A Awakened page button B Activated page button C North area D South area E Pending flights F Waiting flights G North departure DYP H South departure DYP I Sorting buttons J Search button K Re-initialisation of the windows button Description Button giving access to the page displaying the flights having not yet received the start-up clearance. Also indicating the number of N/S awakened flights. Button giving access to the page displaying the flights having received the start-up clearance. Also indicating the number of N/S activated flights. Lists of flights departing from the north runways. Lists of flights departing from the south runways. List of flights having not asked yet for their start-up clearance. List of flights for which the start-up clearance is postponed. Strips presenting the information related to a flight departing from the North runways (call sign, exit point, destination, slot ). Strips presenting the information related to a flight departing from the South runways (call sign, exit point, destination, slot ). Buttons MOBT and Alphabetic allowing modification of the sorting criteria used by the system to sort the flights into the lists. Gives access to an input window to look for flight plans. Restores the initial state of the HMI presentation. Save date: Public Page 40

41 Figure 8: Information window DIGISCUS is a tool integrating the current functionalities of DISCUS (the system currently operational in CDG) and some DMAN services (cf. [5]). DIGISCUS is an HMI specified and developed for CDG CLD position. Among DIGISCUS functions, there are: The visualisation of departure flights awakened and activated sorted by runway. The display of runways load estimated according to runway capacity. The visualisation of the flight plans information. A search function by call sign. The activation and cancellation of an awakened flight. The modification of a flight plan. This tool allows the CLD controller to accomplish his/her main tasks: To check flight plan data, the ATIS letter retrieved by the pilot, to set up a priori the departing runway, the SID, the transponder number and to confirm the CFMU slot. To provide departure and start up clearances 10 min before the estimated departure time. To regulate the departure flow by splitting the traffic between the two departure runways (and delay clearances in case of overload). To ensure the respect of CFMU slot before start-up and to manage the de-icing pads DMAN DIGISCUS interoperability DMAN services for CLD controller are essentially focused on the management of aircraft at stand. The principle is to optimise the departure flow giving start-up instructions in accordance with operational constraints (airport layout, traffic load ). The objective is to provide an electronic HMI of control merging capabilities of DMAN/CDM sequence information HMI and CLD clearances provision. The services identified for DIGISCUS and the DMAN are described in the table below. Each function described is linked to a low level validation objective to show the means proposed to the controller to achieve his/her task. However, not all the functions described below are represented in the table of objectives in paragraphs 3.3.1, and 3.3.3, for some of the function checks are considered to be more verification than validation. Save date: Public Page 41

42 Function Description Remark Buttons to select the type of sorting LDAS alerts indicator on the activated flight. Indicators of the number of North/South awakened / activated flight Indicators of estimated takeoff waiting and runway pressure 5 N/S partition 6 Waiting flight area 7 Flight in push-back alert 2 buttons allow modifying the sorting criteria used by the system to sort the flights into the lists. A button pushed shows the user the sorting selected. Information of displayed on the flight DYP. Allows knowing whether one or several flight in one of the activated flight lists are in LDAS alert. A flight in LDAS alert is an activated ACARS flight for which the pilot did not collect information via ACARS. The information of the number of N/S activated flights is important to compensate the fact that the activated flights are in another list in another page. The number of activated flights has an influence on the start-up strategy. Presentation of the foreseeable waiting time at the runway threshold, and of the foreseeable evolution of the waiting (i.e. tendency). Presentation of the maximum and acceptable waiting time at the runway threshold (i.e. configurable parameter used by the DMAN to calculate the MOBT). In CDG, the lists of flights departing from the north runways are placed on the top of the IHM and those departing from the south runways are on the bottom. List(s) of flights having contacted and waiting for the start-up clearance. List(s) of flights having been cleared to start-up, and for which no push-back clearance has been detected after a configurable time. 2 buttons, for MOBT and Alphabetic sorting, are available. No ACARS flights. The number of flights in each list is indicated on the buttons giving access to the lists. The display is planned but not connected to BOSSA. Top/bottom North/South partition This area is located on the right side of the HMI and is sizeable. The flight can easily be moved from the Pending area to the Waiting area. Useful information to be prepared for the pilot to call back (or for the Ground controller to signal that the flight push-back must be cancelled). Associated LLO [LLO4.2] [LLO4.2] [LLO4.2] [LLO4.2] [LLO4.2] 8 Delay information Information of slot delay displayed on the flight DYP. Between MOBT (or ETOT) and [LLO4.2] Save date: Public Page 42

43 Function Description Remark Associated LLO MOBT > 5 minutes, an orange button informs the controller that the MOBT is past. Over 10 minutes, the button turns red for the flight having a slot. 9 MOBT field Information displayed on the flight DYP. [LLO4.2] 10 CFMU slot indicator field Information displayed on the flight DYP. A c is displayed at the end of the Shows that a flight has a CFMU slot. flight DYP. [LLO4.2] 11 De-icing indicator field Shows that a flight has requested a de-icing phase. Not developed. 12 Consult CTOT Access CTOT value of the flight Assign a de-icing state to a pending or activated flight Consult supplementary information of a flight Consult a message of an excessive de-icing end time Consult the information concerning the regulation Table 4: Description of DIGISCUS functions Input a de-icing state to a flight with possibly a de-icing area. Not developed. Access MOBT, POBT, ETOT, estimated in block time, estimated runway access time and estimated take-off waiting time for the flight. Display a message informing the CLD controller about an excessive waiting time before accessing the runway regarding the continued efficiency of the de-icing product. Access the tool tip displaying the more penalising regulation for a flight and the other regulations when they exist. Information displayed on the information window accessible from the flight DYP. Information displayed on the information window accessible from the flight DYP. Not developed. Not developed. [LLO4.2] [LLO3.2] [LLO3.3] [LLO3.4] Save date: Public Page 43

44 Runway Safety Net interoperability PRIMA DSNA R&D developed a Runway Incursion Monitoring System (RSN) named PRIMA. This system aims at detecting runway incursions and to prevent collisions and boarding on and above runways (cf. [12]). It is based on A-SMGCS level I information (convergence of trajectories, speed ) FISSA FISSA adds a safety layer to PRIMA by taking into account the instructions given by the controllers via the VigieStrips HMI (cf. [13]), i.e. A-SMGCS level II information. FISSA should be considered as an add-on to PRIMA safety net. FISSA is designed to anticipate the situations operationally abnormal and to generate alerts as soon as possible to allow the controllers to better manage the situation. To do so, it takes into account the movements sensor data fusion reports and the instructions given by the ATCO. As it is connected to the BOSSA sever, it processes the flight plan data. FISSA algorithms detect conflicts on runway and on runway protection areas. It also takes into account the arrival aircraft in final being at a certain distance from the runway. FISSA detects aircraft in the RPA (Runway Protection Area) which behaviour is incompatible with the instructions given by the ATCO (e.g. movement without instruction or not complying with the instruction). Two levels of alert are defined: Orange (information): If the aircraft is in the OFZ without instruction and the OFZ is not occupied. If the aircraft has been given an instruction, but its status does not correspond to its instruction. Red (alarm): If the aircraft is in the OFZ without instruction and the OFZ is occupied. The table below presents a list of conflict situations that will be evaluated during the experiment. These situations are part of the list proposed in the A-SMGCS Services, Procedures, and Operational Requirements document (cf. [2]). Save date: Public Page 44

45 Configuration for tests Position 1. On final approach 2. Between stop-bar & runway 3. Lined-up on the runway 4. Taking off 5. Crossing the runway 6. Lined-up on runway 26R 7. Lined-up on runway 26R 8. Taxiing on runway 26R 9. Taxiing on runway Near Aircraft A FISSA status OFZ before the runway On the runway Acceleration On the runway On the runway On the runway Acceleration Acceleration Aircraft B (ahead of aircraft A) Clearance Position FISSA status Clearance Without clearance Without clearance Without clearance Without clearance Without clearance TAKE-OFF TAKE-OFF Without clearance Without clearance Taxiing between stop-bar & runway 26R Stopped before runway 26R stopbar Stopped before runway 26R stopbar Taxiing between stop-bar & runway OFZ before the runway Out of OFZ or OFZ before runway Out of OFZ OFZ before the runway Without clearance LINE-UP LINE-UP LINE-UP FISSA behaviour Alert: Yes Type: Info Who: A Alert: Yes Type: Info Who: A Alert: Yes Type: Info Who: A Alert: Yes Type: Info Who: A Alert: Yes Type: Info Who: A Alert: Yes Type: Alarm Who: A + B Alert: Yes Type: Alarm Who: A + B Alert: Yes Type: Alarm Who: A + B Alert: Yes Type: Alarm Comments Manoeuvre without clearance Aircraft without clearance in the OFZ Aircraft without clearance in the OFZ Aircraft without clearance in the OFZ Aircraft without clearance in the OFZ Conflict between an a/c taking off & an a/c without clearance in the OFZ Conflict between two incompatible clearances Conflict between an a/c taking off without clearance & an a/c cleared out of the OFZ Conflict between an a/c taking off without clearance Save date: Public Page 45

46 26R 26R Who: A + B & an a/c cleared in the OFZ 10. Taking off runway 26R 11. Taking off runway 26R 12. On final approach runway 26R 13. On final approach runway 26R 14. Taxiing on runway 26R Acceleration Without clearance Acceleration TAKE-OFF Far Far Near Very near LANDING Without clearance Acceleration TAKE-OFF B1: Authorised to cross runway 26R B2: Authorised to cross runway 26R B : Crossing runway 26R Between stop-bar & runway 26R to line up Between stop-bar & runway 26R to line up On final approach runway 26R OFZ before the runway OFZ before the runway OFZ before the runway OFZ before the runway Far Near Very near CROSSING Without clearance Without clearance LINE-UP Without clearance Alert: Yes Type: Alarm Who: A + B1 + B2 Alert: Yes Type: Alarm Who: A + B Alert: Yes Type: Alarm Who: A + B Alert: Type: Who: Alert: Type: Who: Yes Yes Yes Info Alarm Alarm A+B A+B A+B Yes Yes Yes Info, Alarm Alarm A+B A+B Conflict between an a/c taking off without clearance & two a/c cleared in the OFZ cleared to cross. Conflict between an a/c cleared for take off & an a/c without clearance in the OFZ Conflict between an a/c cleared to land & an a/c without clearance in the OFZ Conflict between an a/c on final approach without clearance & an a/c in the OFZ cleared to line up. On the same runway, conflict between an a/c cleared to take off and an a/c on final approach Save date: Public Page 46

47 15. On final approach runway 26R Very far Far LANDING Between stop-bar & runway 26R to cross OFZ before the runway Without clearance A+B Yes Alert: Yes Info Type: Alarm A + B Who: A + B On the same runway, conflict between an a/c on final approach with clearance & an a/c without clearance in the OFZ 16. On final approach runway 26R 17. On final approach runway 26R Far Near LANDING Without clearance Between stop-bar & runway 26R to cross Between stop-bar & runway 26R to cross OFZ before the runway OFZ before the runway CROSSING CROSSING Alert: Yes Type: Info Who: A Alert: Yes Type: Alarm Who: A + B On the same runway, conflict between two incompatible clearances. On the same runway, conflict between an a/c on final approach without clearance & an a/c in the OFZ cleared to cross. Table 5: Description of alert cases Save date: Public Page 47

48 4.2.3 Working positions equipment Air traffic control positions equipment G D E A B F C A B F C D RWY control position GND control position Figure 9: Ground and Runway control positions Function Description A Ground and air radar images Cathode screen, 21, resolution 1600x1200. B VigieStrips HMI C Accessory screen D Radio chain + Telephone E Communication peripheral (VHF) F Peripheral of interaction with A H External view WACOM tactile screen 18 of diagonal Tactile screen LCD mounted on an adjustable arm 15 of diagonal 1024x760 AUDIOLAN screen + telephone handset Microphone + Headset Mouse Airfield 3D view Save date: Public Page 48

49 Pseudo-pilots positions equipment A C B Figure 10: Pseudo-pilots positions Function A - SALSA pseudo-pilot screen B - Peripherals of interaction C - Radio chain + Telephone Description Cathode screen, 21, resolution 1600x1200 Mouse + keyboard AUDIOLAN screen + telephone handset Pseudo-controller position equipment Function SALSA pseudo-pilot screen Peripheral of interaction VigieStrips HMI Radio chain + Telephone Description 2 cathode screens, 21, resolution 1600x1200 Mouse 3 WACOM tactile screens 18 of diagonal AUDIOLAN screen + telephone handset Supervision position equipment The technical and operational supervision of the simulation enables to launch the controllers and pseudo-pilots HMIs, to start the simulation exercises and to log the data. Function Screen (supervision HMI) Peripherals of interaction Description Cathode screen, 21, resolution 1600x1200 Mouse + keyboard Save date: Public Page 49

50 4.2.4 Simulation control rooms The controllers working positions will be physically separated from the pseudo-pilots and supervision positions. This will help in being as close as possible from the real controllers working environment by compartmentalising information exchanges between the different actors. Room A will be dedicated to the CLD, Runway and Ground controller positions, and to the simulation supervision. Room B will be dedicated, pseudo-controller position. Room C will be dedicated to the pseudo-pilots positions. Figure 11: Simulation rooms scheme 4.3 Scenarios Each exercise will last about 45 minutes comprising 10 minutes preparation. The simulator will have to run for 10 minutes before the controllers can start controlling in order the traffic to be in place. After this, the controllers will need 5 minutes to build a picture of the situation. The measured exercise will begin following this preparation phase and will last 30 to 45 minutes. A list of exercises is provided in Annex FISSA - PRIMA scenarios A few events among those that have been identified as relevant for the objective of the experiment (cf ) will be disseminated into the simulation exercises respecting the realism of the situation as much as possible. There will be a maximum of three events by exercise, which is quite a lot compared to what happens in CDG today, but can be acceptable as long as the controllers are informed of the experimental needs. One exercise will be run twice: once with the safety nets, once with a 10 to 15 minutes safety nets deactivation to look at FISSA PRIMA effect. FISSA and PRIMA will work together and the time the alerts are triggered will be recorded and compared to verify which of both systems better anticipate a conflict. Save date: Public Page 50