CARE/ASAS/Activity 2 Follow up: Validation Framework WP 1 Deliverable 1

Transcription

1 CARE/ASAS Action CARE/ASAS/Activity 2 Follow up: Validation Framework WP 1 Deliverable 1 INITIAL VALIDATION FRAMEWORK AND SCENARIO REPORT Eurocontrol Reference: CARE/ASAS/Isdefe/ CARE/ASAS Activity 2: VF Project-WP1-D1

2 This page intentionally left blank CARE/ASAS Activity 2: VF Project-WP1-D1 page i

3 DOCUMENT REVIEW Version Date Description Modifications /02/02 First draft of WP1 Deliverable 1 0.1/NAT 04/03/02 Comments from NATS /03/02 Draft of WP1 Deliverable 1 All /04/02 Final draft of WP1 Deliverable 1 All /08/02 First issue EEC comments DISTRIBUTION LIST Consortium EUROCONTROL and CARE/ASAS Action Manager Rosalind Eveleigh NATS Mick van Gool EUROCONTROL Agency Jose Miguel de Pablo Aena Francis Casaux EUROCONTROL Agency John Bennett QinetiQ Ulrich Borkenhagen EUROCONTROL Agency Juan Alberto Herreria Brian Hilburn Isdefe NLR CARE/ASAS Activity 2: VF Project-WP1-D1 page ii

4 EXECUTIVE SUMMARY This document presents the CARE/ASAS Activity 2 Follow Up: Validation Framework project and the Initial Validation Framework from its WP1 Identification of Airborne Separation Assurance Systems (ASAS) Operational Scenarios. This project is part of the EUROCONTROL Co-operative Actions of Research and Development (CARE) programme, whose purpose is to encourage ATM R&D interests to focus on the priorities identified by the ATM2000+ strategy. The project is being carried out by a consortium of organisations formed by Aena, Isdefe, NATS (leader), NLR and QinetiQ, and benefits from the ASAS expertise available within the EUROCONTROL Experimental Centre. The CARE/ASAS Activity 2 Follow up: Validation Framework project follows on the early work performed within CARE-ASAS Activity 2. This work identified the consistency of scenarios and metrics as the key elements in the VF. Scenarios and metrics used in previous ATM validation studies have been reviewed and presented in the Activity 2 report [1]. The next step, which is the subject of Activity 2 Follow Up, is to follow this approach and develop firm recommendations for a feasible generic Validation Framework (VF), and to provide guidance materials and case study examples for its application. The high level approach described in the CARE-ASAS Technical Specification [2] states that the following four work packages (WP) should be completed: WP1: Identification of ASAS operational scenarios; WP2: Identification of system performance metrics; WP3: Identification of human performance metrics; WP4: Application of validation framework. Within WP1, the work has been broken down into six Work Items (WI). The first four WIs constitute a continuous process leading to the definition of the initial validation framework and scenarios for ASAS applications. WI 1.1: generation of a draft template to specifically design validation scenarios for ASAS applications, adding also the possibility of selecting in the same template to more parts of the validation framework: the ASAS application to be validated and the high level objectives. This template is complemented with a set of guidelines describing the way in which a scenario designer should use the template to obtain a suitable scenario. WI 1.2: selection of previous ASAS related projects (from the partners involved in the current project) containing validation scenarios for ASAS applications. The scenarios defined in these projects have been used to calibrate the template. A rationale to guide the selection of the projects was provided to support the selector task. WI 1.3: the draft template defined in WI 1.1 was applied to the scenarios contained in the reference projects selected in WI 1.2, in order to detect gaps, inconsistencies or misleading items. Therefore, the template was calibrated and refined with previous experience. The goal was to derive the template to be used by scenario designers to define scenarios for ASAS applications. WI 1.4: the process finished with the use of the template to perform some example scenarios typified for different validation techniques for the following three selected ASAS applications: CARE/ASAS Activity 2: VF Project-WP1-D1 page iii

5 Airborne self-separation in approach and descent, from Airborne Self-Separation ASAS category [3]. Airborne self-separation in segregated en-route airspace in cruise, from Airborne Self-Separation ASAS category [3]. Time based sequencing in approach, from Airborne Separation ASAS category [3]. Complementing these WIs, two more have been performed within WP1: WI 1.5: creation of an ASAS scenario repository with data from all the available scenarios used to validate ASAS applications to date. For this task, the collaboration of organisations external to the consortium (CENA, EUROCONTROL Experimental Centre and the University of Glasgow) was required. WI 1.6: final report summarising the work performed within WP1. The current report is the result of this WI. The name of the current document should not confuse the reader, since the complete CARE/ASAS/VF is to be developed in the WP4. What is understood by Initial Validation Framework is a first approach to the definition of the validation framework for ASAS applications to be performed within the CARE/ASAS/VF project. It is not the intention of this document to provide the complete validation framework but defining some parts of it, developing only three actions (Selection of the ASAS Application, Definition of the High Level Objectives and Scenario Definition) of that compounding the CARE/ASAS/VF. These three parts are defined with the view focused at MAEVA guidelines, in order to ease the alignment of the CARE/ASAS/VF with MAEVA to be performed in the WP4. The reader will find in this document the outputs from the WIs 1.1, 1.2, 1.3 and 1.4. As output from WI 1.1 a draft template for designing VF and scenarios has been obtained, complemented with guidelines for applying the template. The scenario designer will find specific templates for each of the four ASAS categories [3]. The VF definition is driven by the items addressed in the templates, beginning with the fixing of the ASAS application used for implementing the operational concept, following with defining the high level objectives that the validation exercises are to assess and finishing with the definition of the validation scenario as the ultimate result provided by the template. The expected benefits of having a template as a common reference to design VF and scenarios are the following: Standardized validation scenarios for ASAS applications. Easy traceability of the scenarios. Support to designers in the creation of validation scenarios for ASAS applications. Thorough and consistent validation of ASAS applications. Most of the elements proposed in the template are mandatory for any scenario (all the validation scenarios must contain these elements) to be designed and some others are freely selectable by the designer. The items selected from the template must be described in greater detail in a text to obtain a clear definition of the validation scenario. This task is for the designer; the aim of the template is only to list the items that are necessary for the scenario definition. Within WI 1.2, the following projects have been selected to extract from them the reference scenarios to be used to calibrate the draft template: EMERALD. Scenarios have been selected from EMERALD [6] for the following ASAS applications: CARE/ASAS Activity 2: VF Project-WP1-D1 page iv

6 Longitudinal Station keeping. Closely Spaced Parallel Approaches in IMC. Autonomous Aircraft. EMERTA. Scenarios have been selected from EMERTA [7] for the following ASAS applications: Enhanced Visual Acquisition. Station Keeping on Approach. Scenarios from NLR: Basic Cruise Free Flight (from NLR-NASA project). TMA Airborne Self Separation. Scenarios from NATS [13]: Longitudinal Station Keeping. The above scenarios were used with the draft template within WI 1.3 to refine the template, by detecting gaps or inconsistencies during its application to the reference scenarios. This produced the final template [11] to design scenarios, the first main output of this WP, and the associated user guide [12] explaining how to use the final template. The next step was to produce example scenarios based on the template [14], to illustrate how to use it. These example scenarios were created within WI 1.4 activities and considered the following combinations of ASAS applications and validation tools: ASAS Applications: airborne self separation in segregated en-route airspace in cruise, airborne self-separation in approach and descent and time-based sequencing in approach. Validation tools: Analytical Models, Fast Time Simulation tools (FTS) and Real Time Simulation tools (RTS). To conclude WP1 tasks, WI 1.5 collected previous scenarios performed to validate ASAS applications and created an ASAS scenario repository, Deliverable 2 of the project [15]. The ASAS repository has been integrated in the EUROCONTROL Validation Data Repository (VDR). This task has been a success thanks to the collaboration of external organisations (CENA, EUROCONTROL Experimental Centre and the University of Glasgow), that provided relevant documentation about their ASAS validation scenarios. CARE/ASAS Activity 2: VF Project-WP1-D1 page v

7 ACRONYM LIST A/C 4D AA ACAS ACC ADS-B AIP APP ASAS A-SMGCS ATC ATFM ATM CARE CD CDM CD&R CDTI CNS CP CPDCL CR CWP EATMS EC EEC EFIS EMERALD EMERTA ETCAS EUROCAE EVA E-TIBA FAF FFAS FGCS FIS FMS FTS GNSS GPS HMI HUD ICAO ID IMC IFR ILS IMC INS IRS MAEVA Aircraft Four Dimensions (e.g. latitude, longitude, altitude and time) Autonomous Aircraft Airborne Collision Avoidance System Area Control Centre Automatic Dependent Surveillance Broadcast Aeronautical Information Publication Approach Airborne Separation Assurance System Advanced Surface Movement Guidance and Control System Air Traffic Control Air Traffic Flow Management Air Traffic Management Co-operative Actions of Research and development in EUROCONTROL Conflict Detection Collaborative Decision Making Conflict Detection and Resolution Cockpit Display of Traffic Information Communication, Navigation and Surveillance Conflict Prevention Controller Pilot Data Link communications Conflict Resolution Controller Working Position European Air Traffic Management System European Community EUROCONTROL Experimental Centre Electronic Flight Instrument System Emerging RTD Activities of Relevance for ATM Concept Definition Emerging Technologies Opportunities, Issues and Impact on ATM Enhanced Traffic alert and Collision Avoidance System European Organisation for Civil Aviation Electronics Enhanced Visual Acquisition Enhanced Traffic information Broadcast by Aircraft Final Approach Fix Free Flight Air Space Flight Guidance Control System Flight Information Service Flight Management System Fast Time Simulation Global Navigation Satellite System Global Positioning System Human Machine Interface Head Up Display International Civil Aviation Organisation Identification Instrumental Meteorological Conditions Instrument Flight Rules Instrument Landing System Instrument Meteorological Conditions Inertial Navigation System Inertial Reference System Master ATM European Validation Plan CARE/ASAS Activity 2: VF Project-WP1-D1 page vi

8 MAS MCDU MFF MONA NATS NLR PFD PRM RTS RNAV RNP R/T RTCA RTD RVSM SMGCS SSR TCAS TIS TIS-B TMA ToD UMAS VF VDR VFR VHF WI VMC WP Managed Air Space Multifunction Control and Display Unit Mediterranean Free Flight Monitoring Aids National Air Traffic Services National Aerospace Laboratory Primary Flight Display Precision Radar Monitoring Real Time Simulation Area Navigation Required Navigation Precision Radio Transmissions Radio Technical Commission for Aeronautics Research and Technical Development Reduced Vertical Separation Minima Surface Movement Guidance and Control System Secondary Surveillance Radar Traffic alert and Collision Avoidance System Traffic Information Service Traffic Information Service Broadcast Terminal Manoeuvring Area Top of Descent Unmanaged Air Space Validation Framework Validation Data Repository Visual Flight Rules Very High Frequency Work Item Visual Meteorological Conditions Work Package CARE/ASAS Activity 2: VF Project-WP1-D1 page vii

9 REFERENCE LIST [1] CARE-ASAS Activity 2, Towards a validation framework for ASAS applications, report, Edition 1, June [2] NATS. Technical Proposal: CARE-ASAS Activity 2 Follow-up: Validation Framework. Version 1.0, September [3] CARE-ASAS, Principles of Operation for the Use of ASAS. Version 7.1. June [4] CARE-ASAS Activity 1, Problem Dimension / Evaluation of Past studies European ASAS literature and study review, [5] CARE-ASAS Activity 3, Presentation of the two selected applications, technical note, Ref: CARE/ASAS/Sofreavia/01-022, January [6] EMERALD, WP5 Assessment of emerging technologies: the specific case of ADS- B/ASAS. Version 2.0, October [7] EMERTA, WP 3.1: ASAS feasibility and transition issues. Version 2.0. March [8] MAEVA, Validation Guideline Handbook. Version 1.1, November [9] EUROCONTROL Operational Concept Document (OCD) Edition 1.1, January [10] FAA/EUROCONTROL COOPERATIVE R&D, Principles of Operation for the Use of Airborne Separation Assurance Systems, Version7.1, June [11] Isdefe. CARE-ASAS Activity 2, Template for Validation of ASAS Applications, Version 3.2, ISCARE L, August [12] Isdefe. CARE-ASAS Activity 2, Validation of ASAS Applications Template User Guide, Version 3.1, ISCARE L, February [13] NATS. Towards an Operational Scenario for Longitudinal station keeping: An ASAS Application, November [14] Isdefe. CARE-ASAS Activity 2, Example Scenarios using the Template, Version 0.1, ISCARE L, February [15] Isdefe. CARE-ASAS Activity 2, D2: ASAS Scenario Repository, Version 1.0, ISCARE L, August [16] EEC. FREER FLIGHT-EACAC Real time experiment June 99, Controller Handbook, May [17] EEC. FREER FLIGHT-EACAC Real time experiment June 99, Pilot Notes, May1999. [18] EEC. FREER FLIGHT, Investigations into Limited Delegation of Separation Assurance to the Cockpit, June CARE/ASAS Activity 2: VF Project-WP1-D1 page viii

10 [19] EEC. FREER FLIGHT-EACAC Real time experiment June 00, Controller Handbook, Version 1.0, May [20] EEC. FREER FLIGHT-EACAC Real time experiment June 00, Pilot Notes, June [21] EEC. FREER FLIGHT, Procedures of delegation from the controller to the pilot, Version 1.1, June [22] EEC. FREER FLIGHT-EACAC Real time experiment November 2000, Controller Handbook, Version 2.1, November [23] EEC. FREER FLIGHT-EACAC Real time experiment November 2000, MCS Pilot Notes, Version 1.0, November [24] EEC. FREER FLIGHT-EACAC Real time experiment November 2000, Pilot Notes, November [25] EEC. FREER FLIGHT, Procedures of delegation from the controller to the pilot, Version 2.1, November [26] EEC. FREER FLIGHT-EACAC Real time experiment November 2001, Controller Handbook, Version 2.0, November [27] EEC. FREER FLIGHT-EACAC Real time experiment November 2001, MCS Pilot Notes, November [28] EEC. FREER FLIGHT-EACAC Real time experiment November 2001, Pilot Notes, November [29] EEC. FREER FLIGHT, Procedures of delegation from the controller to the pilot, Version 2.2, November [30] MFF. MFF Operational Procedures, Version 2.0, November [31] MFF. ScenariosModelling Specifications and Development, Version 0.5, December CARE/ASAS Activity 2: VF Project-WP1-D1 page ix

11 GLOSSARY Actor: An organisation or agency, formal or informal, or an individual involved in a validation activity or any of its tasks [8]. High Level Objective (HLO): Formulation of the validation aim in terms of measurable factors for ATM validation exercises [8]. The ASAS Validation Framework provides the following five high level validation objectives: safety, capacity, economics, environment and security. Initial Validation Framework: Set of parts of the ultimate Validation Framework initially developed as first approach to the ASAS Validation Framework. The Initial Validation Framework is formed by: the definition of the High Level Objectives, the selection of the ASAS application and the definition of the validation scenario. Low Level Objective (LLO): Clear, unambiguous definition in terms of measurable factors of what is to be achieved through the conduct of a validation exercise. Metric: A system parameter measured in a validation exercise to provide the data used to derive conclusions [8]. Operational Concept: One of the possible ways of performing all or part of the ATM process, including the options chosen for: (a) the functions provided and the way to provide them; (b) the infrastructures required, (c) the respective responsibilities of people participating in all or part of the ATM process (e.g., responsibility sharing between pilots and controllers, or between ATC and ATFM organizations); and (d) the respective responsibilities of humans and machines. Reference Scenario: Validation scenario defined by the template as a reference to guide the scenarios designers on the creation of validation scenarios for ASAS applications. Validation: The process through which a desired level of confidence in the ability of an operational concept to operate in a real-life environment may be demonstrated to the user, against the actual needs captured as a pre-defined level of functionality, operability and performance [8]. Validation Exercise: The set of one or several tests performed to determine whether an ATM configuration meets the validation requirements specified for it, which may range from a formal meeting of experts to the performance of empirical trials in validation environments and platforms [8]. Validation Scenario: Representation of an operational situation in which an ATM operational concept is validated within one or several validation exercises, to enable the measurement and characterisation of the operational concept's performance. Descriptions of validation scenarios should cover location, timeframe, events and ATM environment [8]. Validation Technique: Method used to achieve the validation objectives of a specific validation exercise [8]. Validation Tool: The means, usually computer-based, of making a validation method quicker or easier to perform [8]. CARE/ASAS Activity 2: VF Project-WP1-D1 page x

12 TABLE OF CONTENTS 1. INTRODUCTION Document Objectives Structure of the Document CARE/ASAS Activity 2 Overview Organisation of the Project Workpackage 1 Overview INITIAL VALIDATION FRAMEWORK AND SCENARIO Template for the Validation of ASAS Applications Evolution of the Template Generation of the Draft Template Review of selected ASAS previous Experiment Scenarios Dimension definition for ASAS Reference Scenario APPLICATION OF THE VALIDATION TEMPLATE First Step: ASAS Application Selection Second Step: High Level Objectives (HLO) Definition Third Step: Scenario Creation Airspace Traffic Air Traffic Services Involved Rules Tasks Actors Technology Text Description of the Scenario EXAMPLE SCENARIOS BASED ON THE TEMPLATE FOR VALIDATION OF ASAS APPLICATIONS Time-based Sequencing in Approach with Analytical and Fast Time Simulation Tools General co-ordinates for the Initial Validation Framework Template for defining the Initial Validation Framework Initial Validation Framework and Scenario Description...22 FIRST STEP: ASAS APPLICATION SELECTION...22 SECOND STEP: OBJECTIVES High Level Objectives...22 THIRD STEP: SCENARIO CREATION Airspace...22 CARE/ASAS Activity 2: VF Project-WP1-D1 page xi

13 Restrictions Types Areas Elements TMA borders Sectors Waypoints Arrival and departure procedures Geographical Scope Traffic Volume Complexity Timeframe Aircraft Type Flight Schedule Equipment Type Aircraft Performance Air Traffic Services Involved Rules Flight Rules Separation Phraseology RVSM Aircraft Sequencing Conflict Resolution Strategy Co-ordination and Transfer Procedures Trained Flight Crews Tasks And Actors Technology Airborne Self-Separation in Segregated En-route Airspace in Cruise with Analytical and Fast Time Simulation tools General co-ordinates for the Initial Validation Framework Template for defining the Initial Validation Framework Initial Validation Framework and Scenario Description...33 FIRST STEP: ASAS APPLICATION SELECTION...33 SECOND STEP: OBJECTIVES High Level Objectives...33 THIRD STEP: SCENARIO CREATION Airspace Restrictions Types...34 CARE/ASAS Activity 2: VF Project-WP1-D1 page xii

14 Areas Elements Restricted or Special Areas Sectors Waypoints Routes Geographical Scope Traffic Volume Complexity Timeframe Aircraft Type Flight Schedule Equipment Type Aircraft Performance Air Traffic Services Involved Rules Flight Rules Separation Phraseology RVSM Aircraft Sequencing Conflict Resolution Strategy Co-ordination and Transfer Procedures Trained Flight crews Tasks And Actors Technology Airborne Self-Separation in Approach and Descent with Real Time Simulation tools General co-ordinates for the Initial Validation Framework Template for defining the Initial Validation Framework Initial Validation Framework and Scenario Description...41 FIRST STEP: ASAS APPLICATION SELECTION...41 SECOND STEP: OBJECTIVES High Level Objectives...41 THIRD STEP: SCENARIO CREATION Airspace Restrictions Type Areas Elements...41 CARE/ASAS Activity 2: VF Project-WP1-D1 page xiii

15 Geographical Scope Traffic Volume Complexity Timeframe Aircraft Type Flight Schedule Equipment Type Aircraft Performance Air Traffic Services Involved Rules Flight Rules Separation Phraseology RVSM Aircraft Sequencing Conflict Resolution Strategy Co-ordination and Transfer procedures Trained Flight Crews Tasks and Actors Obtain surveillance data Manage and process surveillance data Broadcast surveillance data Perform separation assurance Assure separation from surrounding aircraft Maintain traffic situational awareness Request exit from FFAS See and avoid other traffic Use TCAS Technology Ground Communications Surveillance ATM Airborne Communications Surveillance Navigation Display Airborne Self-separation in Segregated En-route Airspace in Cruise with Real Time Simulation tools General co-ordinates of the Initial Validation Framework...46 CARE/ASAS Activity 2: VF Project-WP1-D1 page xiv

16 Template for defining the Initial Validation Framework Initial Validation Framework and Scenario Description...46 FIRST STEP: ASAS APPLICATION SELECTION...46 SECOND STEP: OBJECTIVES High Level Objectives...46 THIRD STEP: SCENARIO CREATION Airspace Restrictions Type Areas Elements Geographical Scope Traffic Volume Complexity Timeframe Aircraft Type Flight Schedule Equipment Type Aircraft performance Air Traffic Services Involved Rules Flight Rules Separation Phraseology RVSM Aircraft Sequencing Conflict Resolution Strategy Co-ordination and Transfer procedures Trained flight crews Tasks and Actors Obtain surveillance data Manage and process surveillance data Broadcast surveillance data Perform separation assurance Assure separation from surrounding aircraft Maintain traffic situational awareness Request exit from FFAS See and avoid other traffic Use TCAS Technology Ground...50 CARE/ASAS Activity 2: VF Project-WP1-D1 page xv

17 Communications Surveillance ATM Airborne Communications Surveillance Navigation Display DATA REPOSITORY OF ASAS SCENARIOS WP1 CONCLUSIONS...52 ANNEX A. ANNEX B. TEMPLATE FOR THE VALIDATION OF ASAS APPLICATIONS. TEMPLATES FOR THE EXAMPLE SCENARIOS FOR VALIDATION OF ASAS APPLICATIONS. 1. EXAMPLE SCENARIO TEMPLATE: TIME-BASED SEQUENCING IN APPROACH WITH FAST TIME SIMULATION TOOLS EXAMPLE SCENARIO TEMPLATE: AIRBORNE SELF-SEPARATION IN SEGREGATED EN-ROUTE AIRSPACE IN CRUISE WITH FAST TIME SIMULATION TOOLS EXAMPLE SCENARIO TEMPLATE: AIRBORNE SELF-SEPARATION IN APPROACH AND DESCENT WITH REAL TIME SIMULATION TOOLS EXAMPLE SCENARIO TEMPLATE: AIRBORNE SELF-SEPARATION IN SEGREGATED EN-ROUTE AIRSPACE IN CRUISE WITH REAL TIME SIMULATION TOOLS...4 ANNEX C. COMPLEMENTARY INFORMATION OF THE EXAMPLE SCENARIOS. 1. ADDITIONAL INFORMATION FOR THE SCENARIO EXAMPLE: TIME-BASED SEQUENCING IN APPROACH WITH ANALYTICAL AND FAST TIME SIMULATION TOOLS ASAS Application Selection Airspace Restrictions Types Areas Elements TMA Borders Sectors Waypoints Arrival and Departure Procedures Geographical Scope Traffic Volumen Complexity Timeframe...5 CARE/ASAS Activity 2: VF Project-WP1-D1 page xvi

18 Aircraft Type Flight Schedule Air Traffic Services Involved Rules Flight Rules New Rules: New Clearance Procedures Separation Phraseology RVSM Aircraft Sequencing Conflict Resolution Strategy Co-ordination and Transfer Procedures Trained Flight Crews Tasks and Actors ATC Tasks Specification Pilot Task Specifications Operational Procedures Model Detailed Description of the Operational Model Technology Ground Airborne Communications Surveillance Navigation Display ADDITIONAL INFORMATION FOR THE SCENARIO EXAMPLE: AIRBORNE SELF-SEPARATION IN SEGREGATED EN-ROUTE AIRSPACE IN CRUISE WITH ANALYTICAL AND FAST TIME SIMULATION TOOLS ASAS Application Selection Airspace Restrictions Types Areas Elements Military Areas Sectors Waypoints Geographical Scope Traffic 33 CARE/ASAS Activity 2: VF Project-WP1-D1 page xvii

19 Volumes Complexity Timeframe Aircraft Type Flight Schedule Equipment Type Aircraft Performances Air Traffic Services Involved Rules Flight Rules Separation Phraseology RVSM Aircraft Sequencing Conflict Resolution Strategy Co-ordination and Transfer Procedures Trained Flight Crews Tasks and Actors Technology Ground Airborne ADDITIONAL INFORMATION FOR THE SCENARIO EXAMPLE AIRBORNE SELF-SEPARATION IN APPROACH AND DESCENT WITH REAL TIME SIMULATION TOOLS ADDITIONAL INFORMATION FOR THE SCENARIO EXAMPLE: AIRBORNE SELF-SEPARATION IN SEGREGATED EN-ROUTE AIRSPACE IN CRUISE WITH REAL TIME SIMULATION-TOOLS...47 CARE/ASAS Activity 2: VF Project-WP1-D1 page xviii

20 1. INTRODUCTION 1.1. Document Objectives This document is the first deliverable (D1) of the CARE/ASAS/VF project. It contains a report on the work done to define the Initial Validation Framework and Scenario. the content of the document is the result of the technical work carried out in WP1, as well as the results of technical meetings and discussions maintained within the project team in order to design the initial validation framework to be applied in the validation of ASAS applications. The name of this document should not confuse the reader, since the complete CARE/ASAS/VF is to be developed in the WP4. What is understood by Initial Validation Framework is a first approach to the definition of the validation framework for ASAS applications to be performed within the CARE/ASAS/VF project. It is not the intention of this document to provide the complete validation framework but defining some parts of it, developing only three actions of that compounding the CARE/ASAS/VF. These three parts are defined with the view focused at MAEVA guidelines, in order to ease the alignment of the CARE/ASAS/VF with MAEVA to be performed in the WP4. Along the text, linkage with MAEVA guidelines and the Final Report will be performed to guide the reader Structure of the Document This document is organised in the following parts and sections: Executive summary: provides an executive summary of the document. Section 1: introduces the purpose of the document and describes the project objectives and the WP1 activities. Section 2: describes the evolution of the template. Section 3: presents the methodology followed in WP1 to create the initial validation framework and scenario. Section 4: presents the example scenarios created based on the initial validation framework and scenario. Section 5: describes the data repository of ASAS scenarios. Section 6: gives conclusions for the work package. Annex A: presents the template for validation of ASAS applications. Annex B: presents the templates carried out to guide the example scenarios elaboration. Annex C: additional data of the example scenarios CARE/ASAS Activity 2 Overview The aim of the CARE-ASAS Validation Framework (VF) stated in an early Activity 2 Plan is to allow for comparability and consolidation of results. The wide range of potential operational concepts and the diverse techniques that may be used to validate them have led to a CARE/ASAS Activity 2: VF Project-WP1-D1 page 1

21 requirement for the framework to be generic. The EMERALD RTD is a constant reference taken into account to make the framework as compatible as possible with its spirit. CARE-ASAS Activity 2 has already identified the consistency of scenarios and metrics as the key elements in the VF. Scenarios and metrics used in previous ATM validation studies have been reviewed and presented in the Activity 2 report [1]. The next step, which is the subject of Activity 2 Follow on, is to take this approach and develop firm recommendations for a feasible generic VF and to provide guidance materials and case study examples for its application, assuring the alignment with the MAEVA guidelines. The high level approach described in the CARE-ASAS Technical Specification states that the following four work packages should be completed: WP1: Identification of ASAS operational scenarios; WP2: Identification of system performance metrics; WP3: Identification of human performance metrics; WP4: Application of validation framework. An additional high-level work package, WP0, has been defined. This work package will be responsible for overall co-ordination, delivery of the Interim and Final reports and organisation of the Dissemination Forum. Figure 1 presents a breakdown of the Work Packages and the relationship between them. Overall Management and Coordination WP0 Validation Framework Components Framework Applicability WP4 Scenario WP1 Metrics Application Guidelines Two Detailed Plans System Performance Metrics WP2 Human Performance Metrics WP3 Figure 1 Project Breaddown Through their experience, the companies forming the consortium have a good understanding of validation. Their experience covers the development of a programme of validation through to execution of the design and subsequent performance analysis and reporting. This understanding will be brought to the process of defining the CARE-ASAS Validation Framework in WP1, WP2 and WP3, and ensuring that the linkage with the MAEVA project in WP4 is efficient and provides added value to the ASAS framework Organisation of the Project The CARE-ASAS Activity 2 follow up: Validation Framework project is carried out by a consortium consisting of several partners: Aena, Isdefe, NATS, NLR and QinetiQ. It is led by CARE/ASAS Activity 2: VF Project-WP1-D1 page 2

22 and benefits from the ASAS expertise already available within the EUROCONTROL Experimental Centre. The EUROCONTROL CARE-ASAS manager, supported by the CARE manager, follows the project on behalf of EUROCONTROL Workpackage 1 Overview Work Package 1 (WP1) of the CARE-ASAS-VF study, "Identification of ASAS Operational Scenarios", has as its objective to describe operating environments for en-route and TMA operations that are relevant to ASAS applications. Drawing on work done in other CARE/ASAS activities and European projects dealing with validation or ASAS, WP1 has defined a initial validation framework and scenarios for ASAS applications, including at least the applications defined in Activity 3. This work is being undertaken in six work items (WI), as follows: WI 1.1: Consolidation of a draft scenario template; generation of a draft template to specifically design validation scenarios for ASAS applications, adding also the possibility of selecting in the same template to more parts of the validation framework: the high level objectives and the ASAS application to be validated. This template is complemented with a set of guidelines describing the way in which a scenario designer should use the template to obtain a suitable scenario. WI 1.2: Review of selected previous ASAS experiment scenarios; selection of previous ASAS related projects (from the partners involved in the current project) containing validation scenarios for ASAS applications. The scenarios defined in these projects are used to calibrate the template. A rationale to guide the selection of the projects is provided to support the selector task. WI 1.3: Definition of dimensions for an ASAS reference scenario; the draft template defined in WI 1.1 is applied to the scenarios contained in the reference projects selected in WI 1.2, in order to detect gaps, inconsistencies or misleading items. Therefore, the template is calibrated and refined with previous experience. The goal is to derive the template to be used by scenario designers to define scenarios for ASAS applications, this is, to create what has been named ASAS reference scenario. WI 1.4: Definition of the reference scenario; the process finishes with the use of the template to perform some example scenarios typified for different validation techniques for the following three selected ASAS applications: Airborne self-separation in approach and descent, from Airborne Self-Separation ASAS category [3]. Airborne self-separation in segregated en-route airspace in cruise, from Airborne Self-Separation ASAS category [3]. Time based sequencing in approach, from Airborne Separation ASAS category [3]. WI 1.5: Creation of an ASAS scenario repository [15]; creation of an ASAS scenario repository with data from all the available scenarios used to validate ASAS applications to date. For this task, the collaboration of organisations external to the consortium (CENA, EUROCONTROL Experimental Centre and the University of Glasgow) is required, and WI 1.6: Final report summarising all of the work done in WP1. The current report is the result of this WI. Figure 2 presents the organisation and relationships between the WP1 Work Items. CARE/ASAS Activity 2: VF Project-WP1-D1 page 3

23 Figure 2 WP1 Breakdown The scenarios so defined will meet the overall objective of CARE/ASAS/VF, to make recommendations for a feasible generic validation framework, and provide guidance materials and case studies for applying the framework. To perform this work the main inputs have been the documents referenced as [1], [2], [3], [6], [7] and [8]. CARE/ASAS Activity 2: VF Project-WP1-D1 page 4

24 2. INITIAL VALIDATION FRAMEWORK AND SCENARIO 2.1. Template for the Validation of ASAS Applications The Initial Validation Framework introduced in this section must be understood as a first approach to the CARE/ASAS Validation Framework (CARE/ASAS/VF) to be presented in the later WP4. Anticipating the work to be done in WP4, the definition of the validation scenario for ASAS application has been complemented with two more actions following the MAEVA guidelines: selection of the ASAS application to be validated and definition of the validation High Level Objectives (HLO). These two additional actions will be part of the complete CARE/ASAS/VF and provides the scenario designer with general conditions and references to ease a better definition of the validation scenario. For this reason it has been decided to enrich the scenario definition anticipating these two actions resulting in what has been named Initial Validation Framework. Among the goals of WP1 of Activity 2 of CARE/ASAS, one of the most important is the elaboration of templates to be used as a reference for the validation of ASAS applications. These templates fulfill two objectives: As a general objective, to introduce the CARE/ASAS/VF for the validation of ASAS applications through the definition of three of the steps forming the CARE/ASAS/VF: the selection of the ASAS applications, that corresponds to the Action 2 of the CARE/ASAS/VF to be introduced in WP4 and also to the Activity 1.1 of the MAEVA VGH, and the definition of the validation High Level Objectives (HLO), that corresponds to the Action 5 of the CARE/ASAS/VF to be introduced in WP4 and also to the Activity 1.4 of the MAEVA Validation Guidelines Handbook (VGH), the creation of the validation scenario, that corresponds to the Action 12 of the CARE/ASAS/VF to be introduced in WP4 and also to the Activity 2.3 of the MAEVA VGH. As it has been said hereafter, these three actions form what has been named as Initial Validation Framework, which main output is the validation scenario definition. More specifically, to be the basis for the creation of the validation scenario, supporting the scenario designer during its development. The template also introduces some general data of the validation exercise to perfectly trace each of them. These general data are: Validation Technique: validation technique to be used in the validation exercise and for which the validation exercise is designed (i.e., survey, analytical, FTS or RTS); Scenario ID: code to name the validation exercise which the validation scenario belongs to; Project: name of the project under which the validation scenario is created; Organisation: name of the organisation that has developed the validation scenario; Creation Date: date corresponding the creation of the validation scenario. An overall goal has been to define a complete template for the creation of initial validation frameworks and scenarios. This has been done in order to cover the specific needs of a wide range of validation methods, considering the individual features of analytic tools, fast time simulation tools and real time simulation tools. The benefits of defining such a template are: CARE/ASAS Activity 2: VF Project-WP1-D1 page 5

25 Standardized validation scenarios for ASAS applications: Using a common reference, designers will use the same terminology to refer to the concepts and elements, and will structure the scenarios in the same way. Easy traceability of the scenarios: As the scenarios will be structured under the same rules, the persons involved in the validation process will easily follow each exercise. Even people from other organisations that are interested in analysing the scenario will be able to perform the analysis more easily, because the design complies with a well-known structure. Support to designers in the creation of scenarios for ASAS applications: The template addresses the elements to be considered in the elaboration of a validation scenario for ASAS applications. Thorough and consistent validation of ASAS applications: in applying the template, the risks of omission are reduced, guaranteeing consistency and completeness of the scenario. Enriching the production of the validation scenario thanks to the introduction within the template of two complementary actions of the validation framework, selection of ASAS application and definition of HLO, that will provide a clearer view of the complete problem and its scope and will help other designers to trace the scenario designed. These two new features of the template will help the global traceability of the validation scenarios designed for validation exercises of ASAS applications. To support the templates, this document provides guidelines for their correct use to define a initial validation framework for validating ASAS applications. The ultimate result of the templates is to create the validation scenarios. The document describes the information that should be included in each scenario designed using this set of templates. In order to make the templates easier to use, separate templates have been provided for each of the four ASAS categories defined in Sections 4.3 to 4.6 of Principles of Operation for the Use of ASAS Systems [3]. In the same document [3], several ASAS applications are proposed for each ASAS category. According with the ASAS application to be validated, the scenario designer will have to select the template corresponding the ASAS category where this application is included. This approach has been considered as the most appropriate to assure that the specific characteristics of each of the ASAS categories are taken into account. As a result, consideration by the designer of the special features of the ASAS categories will be guaranteed when creating a validation scenario for an ASAS application. In order to assist the scenario designer in selecting the proper template for the scenario to be designed, each template gives the name of the ASAS category for which it has been designed and provides a brief definition of the category as provided in [3]. The four templates developed are for the following four ASAS categories, one template for each category, comprising the ASAS applications addressed in each ASAS category bullet: Airborne Traffic Situational Awareness: Enhanced Visual Acquisition (EVA) Enhanced visual approaches Enhanced See and Avoid Enhanced Traffic Information Broadcast by Aircraft (E-TIBA) Improved taxi/runway occupancy awareness (on ground application) Airborne Spacing: In-descent spacing Level flight spacing CARE/ASAS Activity 2: VF Project-WP1-D1 page 6

26 Lateral crossing and passing Vertical crossing Airborne Separation: Time based sequencing ASAS crossing procedure in en-route airspace Station keeping in en-route airspace Station keeping in TMA Vertical crossing Closely spaced parallel approach Airborne Self-Separation: Airborne self separation in ATC controlled airspace Airborne self separation in segregated en-route airspace Airborne self-separation in mixed equipage en-route airspace The templates have been designed to be as identical and comprehensive as possible, given the differences in ASAS categories, in an attempt to facilitate the work of later Activity 2 workpackages. Further description of the template and recommendations for its use will be provided in section 3 of this document, which presents the template user guide almost literally Evolution of the Template Generation of the Draft Template WI 1.1 focused on generating a first draft of a template for validation of ASAS applications and its associated user guide. As stated above, the purpose of the guide is to drive the user to correct use of the template as the basis for the creation of an initial validation framework and scenario for ASAS applications Review of selected ASAS previous Experiment Scenarios The result of the work done in WI 1.1 work was applied in WI 1.2 activities to a representative set of previous ASAS experiment scenarios. These scenarios were selected from a list of projects proposed by the partners from among those available within their organisations. This list includes the following projects/scenarios: NLR-NASA Baseline En-route FF Scenario, relative to Airborne Self-separation ASAS category. NLR TMA ASAS Scenario, relative to Airborne Self-separation ASAS category. Scenario defined in the EMERTA project's "WP3.1Ver2.0" report [7], for the following ASAS applications: Enhanced Visual Acquisition (EVA), relative to Airborne Traffic Situational Awareness ASAS category. Station Keeping on Approach (SKA), relative to Airborne Separation ASAS category. Scenario defined in the EMERALD project's WP6 report [6] for the following ASAS applications: Longitudinal Station Keeping, relative to Airborne Separation ASAS category. Closely Spaced Parallel Approach, relative to Airborne Separation ASAS category. Autonomous Aircraft, relative to Airborne Self-separation ASAS category. NATS scenarios for Longitudinal Station Keeping, relative to Airborne Separation ASAS category. CARE/ASAS Activity 2: VF Project-WP1-D1 page 7

27 A document was produced with the rationale for selecting the most appropriate projects from the list. These guidelines provided the requirements to be met by the candidate projects to extract reference validation scenarios. The rationale ranges from the general to the specific, and from the mandatory to the desirable. More specifically, they are the following: The projects and the validation scenario(s) proposed in them shall relate, in whole or in part, to ASAS applications. The selected projects should cover all four ASAS categories and provide scenarios for more than one ASAS application within the four categories. The projects shall have clearly-defined scenarios for validation trials. The scenarios extracted from the projects should clearly identify the tasks to be performed in the trials, the actors that will participate in the trials, the required or desired skills of these actors, and the sharing of tasks and responsibilities among the actors. The scenarios should provide a clear description of the environment in which the trials are to be performed, the technology to be used, the rules to be applied and the airspace elements and organisation to be considered. The scenarios should clearly state the geographical scope and timeframe intended for the application validated in trials. The scenarios should state the objectives and expected numerical values for the gains to be achieved Dimension definition for ASAS Reference Scenario After the scenario template was applied to the selected previous experiments, gaps, ambiguities and inconsistencies were identified, as was expected. Modifications were extracted from an analysis of the gaps, resulting in a new scenario template and user guide. This new te3mplate is what has been named as reference scenario. This initial exercise in checking the suitability of the template gave rise to several modifications that have been included in the latest version of the templates [11] (also included as Annex A to this document) and the user guide [12]. The definitive templates resulting from the work performed in WI 1.4 are in the form of a table with nine columns: ASAS application and phases of flight, scenario objectives, airspace, traffic, air traffic services involved, rules, tasks, actors and technology. The parameters are presented as a checklist to make it easier for the scenario designer to define the intended scenario. For example, the parameters for traffic are volume, complexity, aircraft type, equipment type, flight schedule, timeframe, geographical scope and aircraft performance; the choices available for geographical scope include Central Europe, Eastern Europe, Scandinavia, North Atlantic and Mediterranean. The scenario proposed by the template has been named as ASAS reference scenario, it is a reference to guide the scenarios designers. The template presented in this deliverable is to be refined in the WP4 of the CARE/ASAS/VF thanks to the expected inputs from experts in both areas, ASAS applications and validation, CARE/ASAS Activity 2: VF Project-WP1-D1 page 8

28 that are intended to assess the template. The final issue of the template will be presented as a result of WP4. The scenario template user guide states which parameters are mandatory, whether any of the choices are exclusive and whether there is a minimum or maximum number of choices that can be made for each parameter. It also sets out the content of the free-text document that should be included with each completed scenario. In the next section, the application of the template is explained in detail. CARE/ASAS Activity 2: VF Project-WP1-D1 page 9

29 3. APPLICATION OF THE VALIDATION TEMPLATE The application of the template to define an initial validation framework (ASAS application + HLO + validation scenario) and, ultimately, a validation scenario for ASAS applications is a three-step process. These three steps correspond to the actions 2, 5 and 12 of the CARE/ASASVF to be defined in the WP4, and also are linked with the activities proposed in the MAEVA VGH [8]. As a first action in the use of the template, the scenario designer should define the general data listed in the template and previously introduced in the section 2.1: validation technique, scenario ID, project, organisation and creation date. Previous to the validation scenario definition, the selection of the ASAS application to be validated and the definition of the High Level Objectives for the validation exercises have been considered necessary for a clear understanding of the problem and to permit the traceability of the validation exercises. Both issues provides a constant reference to what to validate (ASAS application) and what to obtain (HLO) to the scenario designer on the same paper (the template) in which he/she is drafting the validation scenario. In this way, the scenario designer gets the definition of the validation scenario without loosing the view on the problem and the solution that has to validate. The steps in this template application process, illustrated in Figure 3, are as follows: First step: In response to the question what to validate?, the selection of the ASAS APPLICATION to be validated is needed. In section 2.1 of this document, the reader can find the complete list of ASAS applications clustered by ASAS categories addressed on the templates. Second step: Responding to the question what to obtain?, a definition of the HIGH LEVEL OBJECTIVES to be reached when operating the new concept (ASAS application, e.g., enhanced visual acquisition, in-descent spacing, time-based sequencing or any of the airborne self-separation ones) is required. This first step required by the template corresponds to the action 1 of the CARE/ASAS/VF and to the activity 1.4 proposed by MAEVA VGH. The HLO are understood as what the operational concept (ASAS application) aims to improve, e.g., will the new operational concept improve safety? or will the new operational concept achieve fuel savings? Third step: Responding to the question how to test?, the creation of the specific VALIDATION SCENARIO for the validation exercises of the selected ASAS application is fundamental. 1st STEP What to validate? ASAS APPLICATION 2nd STEP What to obtain? HIGH LEVEL OBJECTIVES 3rd STEP How to test? VALIDATION SCENARIO Figure 3 Initial Validation Framework and Scenario Creation Process The scenario designer must keep in mind that the validation template is intended as a checklist that will guide him/her through the different items to be considered in the creation of a validation CARE/ASAS Activity 2: VF Project-WP1-D1 page 11

30 scenario. The template is very detailed to support the definition of validation scenarios for ASAS applications, and it is complemented with the inclusion in the same template of introductory issues to the problem, such as the ASAS application and the HLO. The items in the template are presented in nine columns, clustered by types. They have been selected to be as consistent as possible with the descriptions given in sections of [3]. The groups of items defined in the template are as follows: ASAS Application and Associated Flight Phases. High Level Objectives. Airspace. Traffic. Air Traffic Services Involved. Rules. Tasks. Actors (subdivided into the Performer and the Supervisor). Technology. The templates introduce the items to be considered for the initial validation framework (ASAS application + HLO + validation scenario) and validation scenario creation in two ways: 1. Within each of the nine columns (group of type of items), some categories are preceded by a bullet point. Each option within a category is preceded by a checkbox, which scenario designers can mark to indicate their selected option. In some cases, only one option is provided for a category (e.g. CDTI/EFIS/MCDU for Display category in some ASAS categories associated templates). This means that only this option is available for this category in accordance with [3] (e.g., complexity, aircraft sequencing, conflict resolution strategy). 2. In other cases, options are introduced directly (preceded by a checkbox) without being included in any category. These options are also available for designer selection though they are not included in a category (e.g., complexity, aircraft sequencing, conflict resolution strategy). After selecting the ASAS application to be validated and the HLO, the next step is the creation of the validation scenario. With the selected items marked in the template, the designer has the skeleton of the scenario, but further development of the scenario is still needed for it to become a validation scenario to be used in the validation exercises. The scenario designer must develop each of the selected items, providing descriptions and detailed information regarding the different elements forming the scenario: e.g., co-ordinates of the area, definition of the waypoints, airways, flight schedule, rules and tasks. This information must be included in a document (hereafter referred as the document ), that will complement the template (see section 4 and annex C of this document or [14]). This document will form part of the validation framework created for the validation exercise of the particular ASAS application according with the guides that will be proposed by the WP4. Section 4 and annex C of this document state what is required in the description of each of the items needed to define an initial validation scenario, providing example of validation scenarios based on the template. To summarise, the template is the first approach to create the scenario. The designer is invited to use the template as a mean for having a quick reference of what the scenario must contain, to design the scenario skeleton. But, the template is not the scenario, which must be documented in a more complete and specific way as proposed with the document. CARE/ASAS Activity 2: VF Project-WP1-D1 page 12

31 3.1. First Step: ASAS Application Selection As the first action when using the template, the scenario designer must decide the ASAS application to be validated, which will be selected from the first column of the template. The available choices in this column are specific to each of the ASAS categories, as defined in [3]: For Airborne Traffic Situational Awareness, four airborne and one ground-based applications are listed, clearly distinguishing between the airborne applications and the ground application. This is so because the choice of one or the other will predetermine certain choices in the remaining columns. Following ASAS applications and the flight phases proposed for each of them are addressed on the template within this ASAS category: Enhanced Visual Acquisition (EVA), in two associated flight phases: Cruise Flight level change Enhanced visual approaches, in one associated flight phase: Approach Enhanced See and Avoid, in two associated flight phases: Cruise Flight level change Enhanced Traffic Information Broadcast by Aircraft (E-TIBA), in three associated flight phases: Cruise Flight level change Approach Improved taxi/runway occupancy awareness, in one associated flight phase: On the ground For Airborne Spacing, four applications are listed. Following ASAS applications and the flight phases proposed for each of them are addressed on the template within this ASAS category: In-descent spacing, in one associated flight phase: Approach Level flight spacing, in one associated flight phase: Cruise Lateral crossing and passing, in one associated flight phase: Cruise Vertical crossing, in one associated flight phase: Cruise For Airborne Separation, the scenario designer may select one or more of six possible applications. Following ASAS applications and the flight phases proposed for each of them are addressed on the template within this ASAS category: Time based sequencing, in two associated flight phases: Ascent Approach ASAS crossing procedure in en-route airspace, in one associated flight phase: Cruise Station keeping in en-route airspace, in one associated flight phase: Cruise CARE/ASAS Activity 2: VF Project-WP1-D1 page 13

32 Station keeping in TMA, in two associated flight phases: Flight level changes Approach Vertical crossing, in one associated flight phase: Cruise Closely spaced parallel approach, in one associated flight phase: Approach Finally, for Airborne Self-Separation, the scenario designer may select one or more of three possible applications. Following ASAS applications and the flight phases proposed for each of them are addressed on the template within this ASAS category: Airborne self separation in ATC controlled airspace, in three associated flight phases: Cruise Flight level change TMA Airborne self separation in segregated en-route airspace, in two associated flight phases: Cruise TMA Airborne self-separation in mixed equipage en-route airspace, in two associated flight phases: Cruise TMA The definitions of the applications in [3] predetermine the options for phase of flight for the scenario. For this reason, the options for phase of flight are listed directly under the relevant application. At least one ASAS application and one associated flight phase must be selected. If more than one application is selected, the scenario designer must make certain that the choices made in the following columns are compatible with all of the applications selected in the second column. If more than one application will be used in the scenario but the choices in the following columns cannot be fully compatible with all of the applications selected, the scenario designer should complete one template page for each of the applications. The scenario designer should, in this case, clearly state that all of the selected applications will be used in the scenario, each with its own conditions. As this step in the creation of the initial validation framework will be the action 2 in the CARE/ASAS/VF, the selection of the ASAS application should be explained and the characteristics of the ASAS application briefly enunciated as a description of one of the parts of the validation framework Second Step: High Level Objectives (HLO) Definition The High Level Objectives (HLO) are defined as a formulation of the validation aim in terms of measurable factors for ATM validation exercises. The High Level Objectives (HLO) provide the outline of what is expected to be achieved with the implementation of the solutions proposed (ASAS application) and, therefore, what is to be assessed through the exercise. The selection of the HLO is related with the validation scenario defined by the template since they can induce some scenario characteristics. The scenario designer decides one or several CARE/ASAS Activity 2: VF Project-WP1-D1 page 14

33 HLO for the scenario being designed in the second column of the template. The options provided are clustered in the following categories: Safety. Capacity. Economics. Environment. Security. The available choices are general objectives that can be achieved when implementing each of the ASAS categories (e.g., airborne spacing, airborne self-separation). The designer will also provide figures of the expected gains for selected objectives, if available. At least one HLO must be selected. Additionally, the designer will be invited to define specific objectives for the validation exercise in a later action on the CARE/ASAS/VF. These specific objectives will be named Low Level Objectives (LLO). The template does not provide any support in this area, because it will entirely depend on the designer. LLO, in combination with the HLO, will guide the selection of the metrics from those proposed in WP2 and WP3 on a later action within the CARE/ASAS/VF. As this step in the creation of the initial validation framework will be the action 5 in the CARE/ASAS/VF, the definition of the HLO should be explained and the characteristics of the HLO enunciated as a description of one of the parts of the validation framework Third Step: Scenario Creation This step is the first approach for the definition of the validation scenario. The template provides the list of the items to be considered for the scenario definition. Though some of the items proposed as potential components of the validation scenario are optional, the document describing the scenario must address all of the items proposed for an scenario, marking those not applicable to the scenario as N/A, and keeping the order proposed by the template, as it is done on the examples presented in the chapter 4 of this document. These will grant the same structure for all the scenarios designed using the template and ease the traceability and ulterior understanding and study of the validation scenarios designed using the template Airspace In the third column of the template, the scenario designer makes a series of choices to define the airspace in which the scenario will take place. The available choices are, to some extent, dependent on the ASAS application (e.g., enhanced visual acquisition, in-descent spacing, time-based sequencing or any of the airborne self-separation ones). In most cases, more than one option can be selected. In this column the scenario designer selects from the following: Restrictions to the airspace use are dependent on the ASAS category (e.g., airborne spacing, airborne self-separation). The selection and definition of restrictions are optional. Airspace types (e.g., UMAS). At least one type must be selected. Airspace areas (e.g., TMA). At least one area must be selected. CARE/ASAS Activity 2: VF Project-WP1-D1 page 15

34 The elements that will define the airspace for the scenario (e.g., waypoints or terrain topography). Elements that will form the structure of the scenario airspace must be selected. In the document complementing the template, descriptions of each of the selected elements must be included, providing the names of the sectors, identification of the waypoints and routes, co-ordinates, etc. All of the data needed to define the airspace portion and structure in which the trial will be carried out and the adjoining conditions must be included in the document. Geographical scope. The scenario designer selects one or several options for the geographical scope for implementation of the ASAS application. A description of the area where the trial is to be carried out should be included in the document. In the Improved Taxi/Runway Occupancy Awareness application within the Airborne Traffic Situational Awareness category, the scenario designer should also define the category of the airport (e.g., Cat II) Traffic In the fourth column of the template, the scenario designer defines the characteristics of the traffic that will fly the scenario. Here, the designer selects options for the following categories: Traffic volume (e.g., high). A traffic volume must be selected, if possible providing in the document a value for this parameter. It is difficult to propose sensible numbers, as these will depend on the particular sectors or ACC of interest. As a first approach, the following reference classification is proposed: High = 100% of the current or predicted (declared) sector capacity for the sector or group of sectors being assessed (majority of measured runs). Low = 50% of the current or predicted (declared) sector capacity (suitable for training). Complexity. The scenario designer should provide a description of the complexity of the traffic flow to be managed in the scenario. This description will be included in the document and can be based on the following reference document proposed for this purpose: Mogford's FAA/CT-TN95/22 The Complexity Construct in Air Traffic Control: A Review and Synthesis of the Literature, Appendix A. The complexity needs to be calculated using the table. Any other procedure accepted by the expert community will also be valid. If such a procedure is used, it must be referenced in the document. Aircraft type 1 (e.g., Type C or Medium turbojet). Two classifications are provided: ICAO (used for airports) and FAA (used for simulation tools). The scenario designer must select the applicable categories and the percentage of each of them that will be considered in the exercise. Both types of information must be included in the document. Equipment type (e.g., unequipped). In this option category, not all of the options are provided for all of the ASAS categories (e.g., airborne spacing, airborne self-separation). 1 As defined in Table 1.1 of Annex 14, "Aerodromes", of the Convention on International Civil Aviation of 7 December CARE/ASAS Activity 2: VF Project-WP1-D1 page 16

35 Furthermore, the inclusion of at least one equipped aircraft in the traffic mix is mandatory for three of the four ASAS categories, as stated in this column of the templates. This general option is related to the flight schedule, for which the level of equipment must be defined for each aircraft. The level of equipment for each aircraft will be later on described using the technology column options. Flight schedule. The scenario designer must define in the document all of the options included within this item for each of the aircraft involved in the exercise. The needs for flight plan granularity depend on the ASAS application (e.g., enhanced visual acquisition, in-descent spacing, time-based sequencing or any of the airborne self-separation ones) and the tool to be used for the validation. As a reference, the ICAO flight plan can be considered, although the ICAO flight plan contains no data relevant for ASAS validation purposes. Forcing the designer to gather all of this information can be ambitious. The template addresses the minimum flight plan data. The designer will have to decide the source (ICAO flight plan, FMS trajectory, real trajectory) of the data depending on the objective of the validation exercise. Furthermore in some trials the flight plan can be changed in real time. Timeframe. The scenario designer must select the expected (future) date for implementation of the ASAS application, providing a concrete date if possible. Aircraft performance. The scenario designer must provide in the document a description of the performance required from the aircraft involved in the trials (e.g. cruising and approach speeds, climb rate, etc). It is proposed to use the BADA database as a general reference. The designer is free to select another one or to define the performance on his/her own. In any case, the selected aircraft performance must be referenced to in the document. In the Airborne Self-Separation category, the scenario designer must state the user-preferred trajectory for each flight (or, in the worst case, the user-preferred trajectory for each airline company, each type of aircraft and each trajectory between two airports). Alternative trajectories or strategies should be provided in the event of congestion along the preferred trajectory. This information is to be included in the document Air Traffic Services Involved The scenario designer selects the air traffic services that will be involved in the scenario (e.g., ATC or GNSS) in the fifth column. If the designer selects the "new services" box, the scenario designer should provide a text description of the new services in the document Rules Column 6 of the template provides a series of option categories that will define the rules to be followed during the evolution of the scenario. The option categories in this column are as follows: Flight rules (e.g., IFR). If the scenario designer selects the "new rules" box, a text description of these rules should be included in the document. Special rules for dealing with particular traffic should be stated (e.g., equipped traffic will follow SID XX and unequipped traffic will be assigned to SID YY). The selection of one option is mandatory. The options are exclusive. CARE/ASAS Activity 2: VF Project-WP1-D1 page 17

36 Longitudinal Separation (time or distance and tolerance). The selection of one option (time/distance) is mandatory. The options are exclusive. The scenario designer must also select the tolerance applicable to the application. In both cases, the designer must provide values. It is mandatory to include this information in the document. Lateral Separation. The scenario designer must define values for the separation distance and its associated tolerance permitted in the application. It is mandatory to include this information in the document. Phraseology. If the scenario designer selects "Standard", the desired rules should be identified in the document. If the scenario designer selects "New", the desired phraseology should be described in the document. The selection of one option is mandatory. RVSM. The scenario designer must state whether reduced vertical separation minima will be used in the scenario. Aircraft sequencing. The scenario designer must define the rules for aircraft sequencing that will be used in the scenario in the document. Conflict resolution strategy. The scenario designer must identify the strategy and rules used to resolve conflicts arising within the scenario in the document. Co-ordination and transfer procedures. If more than one sector or airspace type will be involved in the scenario, the scenario designer must identify the procedures that will be used for co-ordination and transfer between sectors in the document. The need for trained flight crews. Three of the four ASAS categories (i.e. airborne spacing, airborne separation and airborne self-separation) as defined in [3] require at least one equipped aircraft in the traffic mix, additionally requiring that the crew aboard the equipped aircraft be trained. This option is mandatory if equipped aircraft has been selected. For the Airborne Traffic Situational Awareness category, ground operations, information must be provided on the rules of the airport usage (e.g., gate assignment, low visibility procedures, standard taxiways or airport operation rules) Tasks The seventh column of the template provides a series of options for tasks to be performed during the scenario. This list has been designed to be as exhaustive as possible. Nevertheless, the scenario designer may include additional tasks in the document. A tasks is defined in the current validation framework as an air traffic management, control or guidance event within the validation exercise. The tasks will vary depending on the validation technique, i.e. survey or judgmental, analytical, fast time simulation (FTS) and real time simulation (RTS), even more on the tool selected within each technique. The definition of the tasks will also depend on the actors involved and on the results aimed at. The template provides the scenario designer with some references regarding possible tasks to be considered in the validation scenario. More tasks, depending on the particular characteristics of the validation exercise can be identified and defined. Even more, the definition of a same task can vary depending on the conditionings described hereafter. CARE/ASAS Activity 2: VF Project-WP1-D1 page 18

37 The tasks should be described in the document in the greatest possible detail, giving at least the following information for each task: Elementary actions carried out in each task (e.g., listening to the pilot, talking to the pilot or writing on Paper Flight Strips). Tentative duration of the actions. Forecast start time of the actions. Based on the real operation of the systems and the human behaviour even on previous validation exercises, the scenario designer can suppose the duration of the tasks to be performed in the validation exercise by both, machines and human actors. Derived from this times, a tentative schedule for the validation exercise can be performed. For sure, in RTS this tentative schedule will not be accomplished, but it can provide a good approach to the extension and how ambitious the exercise is. For FTS and analytical models, this schedule is needed. Clear information on the type of system support and automation should also be provided (e.g., if the action is writing on Flight Strips, it should be stated whether the strips are paper or electronic). This column is linked to the eighth column (actors). For each task selected by the scenario designer in the seventh column, one of the predetermined choices for actors for the task must be selected in the eighth column Actors The eighth column of the template provides options for the actors for each task in the scenario. This column has been subdivided into a "performer" (responsible for executing the task) column and a "supervisor" (ultimately responsible for the task) column. At least one performer and one supervisor choice must be made for each task. The full set of available choices for actors, of which more than one may be selected for any particular task if appropriate, are: Planning controller. Tactical controller. Tower controller (for the Improved Taxi/Runway Occupancy Awareness application within the Airborne Traffic Situational Awareness ASAS Category). Flight crew. Technology (i.e., the task is performed automatically by the system). The available choices for actors listed in the eighth column for each of the tasks listed in the seventh column are intended to be exhaustive. Nevertheless, in the document the scenario designer may provide additional actors for a listed task (e.g., differentiating the flight crew tasks between those affecting the PF and the ones affecting the PNF), or specify actors for an additional task defined in the seventh column Technology CARE/ASAS Activity 2: VF Project-WP1-D1 page 19

38 The ninth column of the template lists available options for the technology that will be required by the scenario. Separate option categories are provided for ground technology and airborne technology. The categories available for ground technology are communications and surveillance. The categories available for airborne technology are communications, surveillance, navigation and display. The choices for technology in the ninth column are not exhaustive. They are listed as the most logical choices that will be required for each of the applications within each of the ASAS categories (i.e. airborne spacing, airborne self-separation). If the scenario designer wishes to include other technology in the scenario, this can be done in the document Text Description of the Scenario The completed template will give an overall idea of the scenario. Nevertheless, a text description of what the scenario is intended to do when it runs should also be provided to complement the initial validation framework and scenario definition. No guidelines are given here for the length or content of such a description, but it should provide some insight into what the scenario designer has in mind for the validation exercise. This description should be included in the document widely mentioned in the previous sections. The following section presents several initial validation frameworks and scenario examples for several combinations of ASAS applications and validation tools to illustrate the use of the template. Additional examples on the application of the template and such documents describing the scenarios can be found in the case studies to be performed in the WP4. CARE/ASAS Activity 2: VF Project-WP1-D1 page 20

39 4. EXAMPLE SCENARIOS BASED ON THE TEMPLATE FOR VALIDATION OF ASAS APPLICATIONS The objective of Work Item 1.4 (WI 1.4) of CARE/ASAS/VF was to create several generic initial validation frameworks (ASAS application + HLO + validation scenario) covering different ASAS applications (e.g., enhanced visual acquisition, in-descent spacing, timebased sequencing or any of the airborne self-separation ones), making use of the template defined in WP1.3 [11]. Each initial validation framework will provide a complete description of the procedure and resultant dimensions and parameters. The example scenarios are split into two parts: one presented in this chapter, depicting in a schematic way the main characteristics and components of the scenarios; and a second part presented in the annex C, providing a complete description of the components of the scenarios or a reference to documents containing this information. Initially, the most detailed document is expected from the scenario designer. Anywise, the complexity and granularity of the document can be adapted to the particular circumstances of each validation exercises. The proposed initial validation frameworks and scenarios will cover the needs for Real-Time Simulation (RTS), Fast-Time Simulation (FTS), Statistical and Analytical validation techniques, defining clearly the dimensions and parameters for each technique in each application. It is important to highlight that scenario requirements usually play a significant role in determining the decision on validation technique, which is needed before selecting the metrics. The combinations of validation methodologies and ASAS applications selected to create the examples for VF and scenarios are presented in Table 1: VALIDATION METHODOLOGY ASAS APPLICATION FTS RTS ANALYTICAL Time-based sequencing, in approach X X Airborne Self-Separation, in approach and descent X Airborne self-separation in segregated en-route airspace, in cruise X X X Table 1 Combinations Selected to Create the Example VF and Scenarios Due to the high similarity of the needs for the initial validation frameworks and scenarios created for analytical and FST tools, both are presented within the same sections to avoid repetitions. The differences, if any, between the initial validation framework for analytical techniques and for FTS tools are highlighted Time-based Sequencing in Approach with Analytical and Fast Time Simulation Tools General co-ordinates for the Initial Validation Framework VF Identification: Example for Time-based Sequencing in Approach with Analytical and Fast Time Simulation tools. VF version: 0.1. Author: Rosa Arnaldo. Organisation: Aena. Creation Date: 06/03/02. Execution Date: Not defined. CARE/ASAS Activity 2: VF Project-WP1-D1 page 21

40 Name of the Project/Study: CARE/ASAS Activity 2. Validation Methodology: Analytic and Fast Time Simulation. Validation Tool: Not defined Template for defining the Initial Validation Framework See annex B, TEMPLATES FOR THE EXAMPLE SCENARIOS FOR VALIDATION OF ASAS APPLICATIONS Initial Validation Framework and Scenario Description FIRST STEP: ASAS APPLICATION SELECTION The ASAS application to be validated by the exercise described in this section is: ASAS Category: Airborne Separation. ASAS Application: Time-Based Sequencing in TMA See annex C, chapter 1.1, for further information. SECOND STEP: OBJECTIVES High Level Objectives The high level objectives from those addressed on the template, which the validation exercise is focused at, are the following: SAFETY Guarantee the present safety level. CAPACITY Improve airport arrival planning. ECONOMICS Improve reliability of flight times. THIRD STEP: SCENARIO CREATION For the creation of the scenario for this application example, following documents from the FREER and FREER FLIGHT-EACAC projects (both EEC projects) have been used as references: [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28] and [29] Airspace Restrictions Speed and flow rate restrictions are considered in this scenario. See annex C, chapter 1.2, for further information. CARE/ASAS Activity 2: VF Project-WP1-D1 page 22

41 Types Application (Id) ASAS Time-based sequencing Airspace MAS Areas Application (Id) ASAS Time-based sequencing Flight Phase TMA The airspace of the TMA phase includes 10 Spanish ATC sectors located within a circular area of 120NM radius around Madrid-Barajas airport: Upper vertical limit: FL250; Lower vertical limit: normal sector limits apply Elements The description of the airspace areas is briefly presented hereafter. No restricted nor special areas are consider, only sectorisation is to be taken into account. Further information for the elements can be found in the annex C, chapter The elements considered for the airspace definition forms part of the new Madrid TMA which is currently under evaluation and are the following: TMA borders. Sectors. Final approach sector for runways 33L and 33R. Director sectors. Departure sectors. Feeder sectors West and East. Waypoints. Arrival and departure procedures. Figures of all the TMA borders and sectors are provided hereafter. Further description of the TMA borders, sectors, waypoints and procedures are provided in the Annex C. CARE/ASAS Activity 2: VF Project-WP1-D1 page 23

42 TMA borders Please, refer to annex C, chapter , for further description of the TMA borders RBIS SO MO SIERRA BARAHO NA ZARZUELA DEL MONTE ESCORIAL MIRAFLORES COLMENAR CASAR RO BLEDILLO GUADALAJARA CAÑIZAR SIG ÜENZA TOMELLOSA PINAR NAVAS TOLEDO CAMARENA HENARES BRA SAN MARTIN DE LA VEGA ARGANDA PERALES TORRES MONDEJAR CASTEJÓN VILLATOBAS Figure 4 TMA External Limits CARE/ASAS Activity 2: VF Project-WP1-D1 page 24

43 Sectors See annex C, chapter , for further description of the sectors. Final approach sector for runways 33L and 33R TORRES NAVAS HENARES BRA MONDEJAR SAN MARTIN DE LA VEGA ARGANDA PERALES CASTEJÓN VILLATOBAS Figure 5 Final Approach Sectors External Limits CARE/ASAS Activity 2: VF Project-WP1-D1 page 25

44 Director sectors RBIS ZARZUELA DEL MONTE ESC ORIAL MIRAFLORES COLMENAR SO MO SIERRA CASAR RO BLEDILLO GUADALAJARA CAÑIZAR SIG ÜENZA TOMELLOSA BARAHONA PINAR NAVAS TOLEDO CAMARENA HENARES BRA SAN MARTIN DE LA VEGA ARGANDA PERALES TORRES VILLATOBAS MONDEJAR CASTEJÓN Figure 6 Director Sectors External Limits CARE/ASAS Activity 2: VF Project-WP1-D1 page 26

45 Departure sectors. ZARZUELA DEL MONTE NAVAS CAMARENA MIRAFLORES COLMENAR HENARES BRA CASAR ARGANDA SAN MARTIN DE LA VEGA PERALES ROBLEDILLO GUADALAJARA TORRES CAÑIZAR MONDEJAR Figure 7 Departure Sector External Limits SIG ÜENZA TOMELLOSA CARE/ASAS Activity 2: VF Project-WP1-D1 page 27

46 Feeder sectors West and East RBIS SO MO SIERRA BARAHONA RO BLEDILLO PINAR COLMENAR CASAR NAVAS BRA CASTEJÓN PERALES VILLATOBAS Figure 8 East Feeder Sector External Limits CARE/ASAS Activity 2: VF Project-WP1-D1 page 28

47 RBIS SO MO SIERRA ZARZUELA DEL MONTE ESC ORIAL NAVAS TOLEDO CAMARENA MIRAFLORES COLMENAR HENARES BRA SAN MARTIN DE LA VEGA CASAR ARGANDA PERALES RO BLEDILLO GUADALAJARA TORRES CAÑIZAR MONDEJAR SIG ÜENZA TOMELLOSA VILLATOBAS Figure 9 West Feeder Sectors External Limits Waypoints See annex C, chapter , for the waypoints list and co-ordinates Arrival and departure procedures See annex C, chapter , for the procedures list and description Geographical Scope It corresponds to the Mediterranean area. CARE/ASAS Activity 2: VF Project-WP1-D1 page 29

48 Traffic The traffic sample adopted has been derived from CFMU data, and relevant to a current busiest day (1 st of September 2000), increased by 30% to have a load equivalent to Only flights entering into the Madrid TMA on the reference day (1 st of September 2000)are provided in the attached file, for the simulation of 30% of the traffic increases should be applied homogeneously Volume The volume of traffic is high. A total of 1984 movements are included in the simulation Complexity The traffic simulated is the result of incrementing in a 30% the current traffic. Complexity was defined in terms of the number of conflicts arising in the original traffic scenario. This increases non-linearly with traffic (e.g. twice the number of aircraft might result in four times the number of conflicts). Conflict rates up to 1,3 times the current rate were used Timeframe The traffic selected states the timeframe in the year Aircraft Type Aircraft type FAA classification is applied, so aircraft are divided into Heavy, Medium Turboprop, Medium Turbojet and Light. The following table indicates the percentages of each of these categories included in the traffic sample corresponding to the 1 st of September 2000 (these figures should be increased by 30% to reflect the expected situation around 2005). Type of Aircraft (FAA) Percentage (%) Heavy 19,25 Medium Turbojet 61,75 Medium Turboprop 12,60 Light 6, Flight Schedule The structure of the flight schedule is provided in the annex C, chapter The information regarding the 1984 movements included in the flight schedule is sorted as defined in the structure Equipment Type Regarding the application, three levels of equipment are distinguished: CARE/ASAS Activity 2: VF Project-WP1-D1 page 30

49 Aircraft with the appropriate equipment to perform the time based sequencing application, including ADS-B/TIS-B capabilities, an output interface and a specific function providing the required information to perform the application. Aircraft with ADS-B capability only. Aircraft with the current level of equipment, i.e. neither ASAS, nor ADS-B equipment, only TCAS. The distribution of aircraft equipped to perform the application is mix according to the following criteria: All heavy and medium turbojet aircraft are supposed to be equipped with appropriate equipment; medium turboprop aircraft are supposed to be equipped with only ADS-B capability and light aircraft are supposed to maintain the current level of equipment. This section is not applicable to analytical models Aircraft Performance The characteristics of each aircraft are taken as the default characteristics defined by Eurocontrol (BADA v3.3) Air Traffic Services Involved APP, ATC and TIS-B are considered for validation purposes Rules Flight Rules IFR and new rules are selected for use in the scenario. See annex C, chapter 1.5.1, for further information Separation Minimum radar separation Wake vortex minimum separation criteria shall be applied for final approach as indicated in Annex C, section 1.5.5, table 5. As average separations, approach sectors will apply 68 seconds separation and the rest of the sectors will apply 75 seconds separation. Vertical separation minima are 1000' Phraseology This section is not applicable for analytical tools. New phraseology is proposed in the scenario. When defining the scenario, some FTS tools (e.g., TAAM) has the capability to delay the change in one aircraft status (e.g., heading, flight CARE/ASAS Activity 2: VF Project-WP1-D1 page 31

50 level, route ) in a time equivalent to the needed by the controller and the pilot to communicate and agree on the order. Defining the phraseology, a mean time (e.g., 5 or10 seconds) can be estimated for each order and introduced in the model. Further information is provided in the annex C, chapter RVSM Not applicable for TMA and airspace below 250 FL Aircraft Sequencing Aircraft sequencing rules have been defined. See annex C, chapter Conflict Resolution Strategy No new conflict resolution strategies or procedures are considered. Conflict detection and resolution will be the same as in normal radar environment. Possible actions for conflicts will be radar vectoring, FL change and speed adjustment Co-ordination and Transfer Procedures This section is not applicable for analytical tools. Specific co-ordination and transfer procedures are defined in this scenario. For some fast time simulation tools (e.g., TAAM) the definition of the co-ordination and transfer procedures is needed in the case the validation exercises uses the TAAM feature of considering the controller action in the control of the aircraft, in order to measure the time spent in the action. This time will be considered in the simulation. Further information is provided in the annex C, chapter Trained Flight Crews Not applicable for ATC analytical and fast time simulations Tasks And Actors This section is not applicable for analytical tools. Tasks and the roles of the associated actors in the development of the tasks are defined and described in the annex C, chapter Technology This section is not applicable for analytical tools. CARE/ASAS Activity 2: VF Project-WP1-D1 page 32

51 Further information in the technology selected for the FTS can be found in the annex C, chapter Airborne Self-Separation in Segregated En-route Airspace in Cruise with Analytical and Fast Time Simulation tools General co-ordinates for the Initial Validation Framework VF Identification: Example for Airborne self-separation in segregated en-route airspace in cruise with Analytical and Fast Time Simulation tools. VF version: 0.1. Author: Rosa Arnaldo. Organisation: Aena. Creation Date: 06/03/02. Execution Date: not defined. Name of the Project/Study: CARE/ASAS Activity 2. Validation Methodology: Analytic and Fast Time Simulation. Validation Tool: not defined Template for defining the Initial Validation Framework See annex B, TEMPLATES FOR THE EXAMPLE SCENARIOS FOR VALIDATION OF ASAS APPLICATIONS Initial Validation Framework and Scenario Description FIRST STEP: ASAS APPLICATION SELECTION The ASAS application selected for the definition of this validation scenario is: ASAS Category: Airborne Self-Separation ASAS Application: Airborne self separation in segregated en-route airspace in cruise See annex C, chapter 2.1, for further information. SECOND STEP: OBJECTIVES High Level Objectives The high level objectives are: Safety: Maintain or improve safety: Pilots are provided with an airborne situation awareness that improves aircrew mental pictures regarding the surrounding traffic. Efficiency: Optimised flight efficiency: Flight efficiency can be optimised by flying "direct routes" at optimal FL in FFAS. Flight time, fuel consumption and cost should be reduced accordingly. CARE/ASAS Activity 2: VF Project-WP1-D1 page 33

52 Enhanced flexibility for airspace users: Airspace user can choose their 4D preferred routes in FFAS with any ATC constrains except in FFAS-MAS transition zones. Capacity: Increased airspace capacity: The potential benefit of this application is still an open issue. THIRD STEP: SCENARIO CREATION This scenario is part of the one Aena is creating for autonomous operation within the Mediterranean Free Flight (MFF) project. For the creation of the scenario for this application example, following documents from the MFF (EC sponsored project) have been used as references: [30] and [31]. The following general hypothesis will be made for FFAS model based simulations: Ideal equipment: no failures, no time delays in ADS-B equipment, etc.; this also means no emergencies take place. No (bad) weather effects modelled. All aircraft flying in FFAS have full ASAS capability. Military traffic will only be taken into account if it follows the normal civil traffic routes (i.e. aircraft participating in military exercises will not be considered). When active, military areas will be avoided by 5NM Airspace Restrictions Airborne Separation Assurance will be only for en-route sectors above FL280. Only equipped aircraft are allowed to enter in FFAS. For the sake of the simulation all the aircraft included inside the traffic sample are supposed properly equipped. No Flow restriction on entry and exit points will be considered for this simulation. Military areas defined hereafter are considered as restrictions to the desired flight profile and should be avoided by 5NM Types Airborne Separation Assurance only can be applicable on FFAS. Application (Id) ASAS Airborne self separation in segregated en-route airspace Airspace FFAS CARE/ASAS Activity 2: VF Project-WP1-D1 page 34

53 The routes will be modified in such way that aircraft flying in FFAS have direct-to routes from FFAS entry to FFAS exit, avoiding military areas Areas Application (Id) ASAS Airborne self separation in segregated en-route airspace Flight Phase Route above FL280 Airborne Separation Assurance will be only for en-route sectors above FL Elements The elements forming the airspace are the following. Further information on them is presented in the annex C, chapter 2.2.4: Restricted or special areas. Sectors. Waypoints. Routes. The airspace selected aims to be a typical airspace where the application could be implemented and bring significant benefits. In the framework of this study the application is defined within FFAS surrounded by MAS, the UMAS are not concerned Restricted or Special Areas The restricted or special areas considered are defined accordingly to the present military areas of Morocco, Algeria and south of Spain as publish in the corresponding AIP. The corresponding data, extracted from Spain, Morocco and Algeria AIPs are included in the annex C, chapter Sectors The sectors that will constitute the FFAS above FL280 are the ones for the present Sevilla FIR, Casablanca FIR and Algeria FIR. The following figure indicates the mentioned sectors whose co-ordinates are provided in the tables included in the annex C, chapter CARE/ASAS Activity 2: VF Project-WP1-D1 page 35

54 Figure 10 FFAS Area of Applicability Waypoints The waypoints and their co-ordinates are listed in the annex C, chapter They are also published at the Aeronautical Information Publication (AIP) of Spain Routes Within the FFAS there are no fixed routes: aircraft fly their user-preferred routes between the entry and exit points. Consequently unless there are bad weather areas or military areas to avoid or conflict resolution actions, aircraft are expected to fly direct routes between the entry and exit points. For purposes of the simulations these direct routes are great circular routes between the entry and exit points. The entry and exit points will be those from the flight profile that match the frontier of the previously mentioned FFAS sectors. On the border of MAS areas, a buffer zone will be defined (5 NM horizontally 1 Flight Level vertically). No traffic is allowed in this buffer zone. This is to avoid predicted conflicts and intrusions of protected zones between ATC managed traffic and free flight traffic Geographical Scope The following figure illustrates the identified MFF Airspace, and the airspace area selected to develop the specific MFF application models: CARE/ASAS Activity 2: VF Project-WP1-D1 page 36

55 49 MAS1 MAS2 MAS3 MAS FFAS1 FFAS2 FFAS3 FFAS Figure 11 MFF Airspace For this particular case the area of application correspond to Selected Application s Area Top Left 39N14W Bottom Right 29N6E See annex C, chapter 2.2.5, for further information Traffic The traffic sample adopted has been derived from CFMU data, and is relevant to a current busiest day (1 st of September 2000), increased by 30% to have a load equivalent to Only flights entering into the defined area (Sevilla, Argelia, Morocco FIR) considered. For the simulation, the 30% traffic increase should is homogeneously Volume Medium. A total of 725 movements are considered in the simulation. CARE/ASAS Activity 2: VF Project-WP1-D1 page 37