Straw Man

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION
EUROCONTROL
Production of Overall Architecture: Strawman
Edition Edition Date Status Class
: : : :
2.6 17 January 2001 Working Draft Restricted
EUROPEAN AIR TRAFFIC MANAGEMENT PROGRAMME
DOCUMENT IDENTIFICATION SHEET
DOCUMENT DESCRIPTION
Document Title Production of Overall Architecture: Strawman
EWP DELIVERABLE REFERENCE NUMBER: PROGRAMME REFERENCE INDEX: EDITION: EDITION DATE: Abstract 2.6 17 January 2001
Keywords
CONTACT PERSON:
P Abbott
TEL: 3304
UNIT:
SDE/SCS
DOCUMENT STATUS AND TYPE STATUS Working Draft Draft Proposed Issue Released Issue o o o CLASSIFICATION o General Public o EATMP Restricted
ELECTRONIC BACKUP INTERNAL REFERENCE NAME: HOST SYSTEM Microsoft Windows MEDIA Type: Hard disk Media Identification: SOFTWARE
DOCUMENT APPROVAL The following table identifies all management authorities who have successively approved the present issue of this document.
AUTHORITY
NAME AND SIGNATURE
DATE
Internal working document no sign off required
Edition: 2.6
Working Draft
Page iii
DOCUMENT CHANGE RECORD The following table records the history of the successive editions of the present document.
EDITION 2.2
DATE 16 June 2000
REASON FOR CHANGE First edition in EATMP template. Editorial changes and inclusion of new Avionics and CFMU input. Changes to incorporate comments from walkthrough of v2.2 and inclusion of new ASM and NAV input. Editorial changes. Changes to incorporate results of walkthrough of v2.3 and identification of cross-domain components. Addition of foreword and acronyms sections. Editorial changes Alignment with Management Overview document. Generation of text from UML model.
SECTIONS PAGES AFFECTED All
2.3
13 July 2000
3, 5.3, 5.4, 5.5, 5.6, 5.7, 5.10, 5.11, 5.12 All
2.4
6 Sept 2000
2.5 2.6
22 Sept 2000 17 Jan 2001
Sections 1 through 5 All
Page iv
Working Draft
Edition: 2.6
TABLE OF CONTENTS
DOCUMENT IDENTIFICATION SHEET..................................................................... ii DOCUMENT APPROVAL ......................................................................................... iii DOCUMENT CHANGE RECORD ............................................................................. iv FOREWORD .............................................................................................................. 1 EXECUTIVE SUMMARY ............................................................................................ 2 1. INTRODUCTION .................................................................................................. 2
1.1 1.2 1.3 1.4 1.5 The Business Need Being Addressed...................................................................................... 2 Phase 1: Summary of Goals .................................................................................................... 3 Development Process .............................................................................................................. 4 Component-Based Architecture ............................................................................................... 4 1.4.1 Process: Component identification - Component content definition................................. 7 Future Development ................................................................................................................. 7
2. SCOPE................................................................................................................. 9
2.1 Data processing systems: Scope and Structure .................................................................... 10 2.1.1 Partitioning and Segmentation........................................................................................ 11
3. CONTEXT .......................................................................................................... 13
3.1 Actors ..................................................................................................................................... 14 3.1.1 Pilot ................................................................................................................................. 14 3.1.2 Aircraft Operator ............................................................................................................. 15 3.1.3 Peer ATS Provider .......................................................................................................... 16 3.1.4 Airport Operator .............................................................................................................. 16 3.1.5 Meteo Service Provider .................................................................................................. 17 3.1.6 Time Service Provider .................................................................................................... 17 3.1.7 Environment Data Service Provider ............................................................................... 17 3.1.8 Sensor............................................................................................................................. 17 3.1.9 Internal Human Users..................................................................................................... 17 3.1.10 Actors Not Retained for Phase 1 .................................................................................... 20
4. ARCHITECTURE DRIVERS .............................................................................. 20
Edition: 2.6
Working Draft
Page v
4.1 4.2 4.3 4.4 4.5
Operational Context................................................................................................................ 20 Technical Context................................................................................................................... 20 Principles ................................................................................................................................ 20 Information Management ....................................................................................................... 21 Assumptions ........................................................................................................................... 21
5. EATMP OVERALL ARCHITECTURE - REPRESENTATION............................ 22

5.1 5.2 5.3 Structure (to be updated) ....................................................................................................... 22 Overview of Components ....................................................................................................... 23 Air Traffic Control.................................................................................................................... 25 5.3.1 Arrival Manager............................................................................................................... 25 5.3.2 Departure Manager......................................................................................................... 25 5.3.3 Controller Workstation Manager ..................................................................................... 26 5.3.4 Short-Term Conflict Manager ......................................................................................... 27 5.3.5 Medium-Term Conflict Manager ..................................................................................... 27 5.3.6 ATC Flight Manager........................................................................................................ 28 5.3.7 Correlation Manager ....................................................................................................... 28 5.3.8 ATC Overview................................................................................................................. 30 Air Traffic Flow Management ................................................................................................. 31 5.4.1 Load State Manager ....................................................................................................... 31 5.4.2 Air Traffic Flow Manager................................................................................................. 31 5.4.3 ATFM Overview .............................................................................................................. 33 Aeronautical Information Management .................................................................................. 34 Airport Operator...................................................................................................................... 35 5.6.1 Flight Information System ............................................................................................... 35 5.6.2 lnfrastructure Manager.................................................................................................... 35 5.6.3 Airport Operator Overview .............................................................................................. 36 Aircraft Operator ..................................................................................................................... 37 5.7.1 Flight Planning ................................................................................................................ 37 5.7.2 Aircraft Operator Overview ............................................................................................. 39 Navigation Infrastructure ........................................................................................................ 40 5.8.1 Ground-Based Bearing Provider..................................................................................... 40 5.8.2 Ground-Based Distance Measurement Provider............................................................ 40 5.8.3 Satellite-Based Bearing Provider.................................................................................... 40 5.8.4 Augmentation Provider ................................................................................................... 41 5.8.5 Ground-Based Landing System ..................................................................................... 41 5.8.6 Navigation Infrastructure Overview................................................................................. 41 Surveillance ............................................................................................................................ 42 5.9.1 Air Data Acquisition ........................................................................................................ 42
5.4
5.5 5.6
5.7
5.8
5.9
Page vi
Working Draft
Edition: 2.6
5.9.2 5.9.3 5.9.4 5.9.5 5.9.6
Air Surveillance Data Processing and Distribution ......................................................... 42 DAP Server ..................................................................................................................... 43 Ground Data Acquisition................................................................................................. 43 Ground Surveillance Data Processing and Distribution ................................................. 44 Surveillance Overview .................................................................................................... 45
5.10 Airspace Management ........................................................................................................... 46 5.10.1 Airspace Activation Manager .......................................................................................... 46 5.10.2 Airspace Plan Co-ordination Manager............................................................................ 47 5.10.3 ASM Communications Manager ..................................................................................... 47 5.11 Avionics .................................................................................................................................. 48 5.11.1 Radar & XPDRs .............................................................................................................. 48 5.11.2 Navigation ....................................................................................................................... 48 5.11.3 Surveillance .................................................................................................................... 49 5.11.4 Flight Deck Displays ....................................................................................................... 49 5.11.5 Crew Controls ................................................................................................................. 50 5.11.6 Communication Function ................................................................................................ 50 5.11.7 Flight Controls................................................................................................................. 50 5.11.8 Autonomous Sensors ..................................................................................................... 51 5.11.9 Navigation Radios........................................................................................................... 51 5.11.10 Communication Radios................................................................................................... 51 5.11.11 Avionics Overview .......................................................................................................... 52 5.12 Cross-domain Components.................................................................................................... 53 5.12.1 Component instances ..................................................................................................... 53 5.12.2 Flight Manager ................................................................................................................ 53 5.12.3 DAP Manager ................................................................................................................. 54 5.12.4 Configuration Manager ................................................................................................... 55 5.12.5 Environment Manager .................................................................................................... 56 5.12.6 HMI ................................................................................................................................. 57 5.13 Horizontal Components Distributed Systems Services....................................................... 58 5.13.1 Communications Management Services ........................................................................ 58 5.13.2 Distributed System (Middleware) services ..................................................................... 61 5.14 Data Dictionary ....................................................................................................................... 65 5.14.1 Flight Related Data ......................................................................................................... 65 5.14.2 Aircraft Related Data ...................................................................................................... 67 5.14.3 Environmental Data ........................................................................................................ 67
6. SCENARIOS ...................................................................................................... 69
6.1 Commercial IFR Flight 2010 Scenario ................................................................................... 69 6.1.1 Planning Overview.......................................................................................................... 69 6.1.2 Strategic Planning Process............................................................................................. 73 6.1.3 Tactical Planning Process .............................................................................................. 73
Edition: 2.6
Working Draft
Page vii
6.1.4 6.2
Sector Planning and Sector Control ............................................................................... 76
Changes and Assumptions to Meet 2010 Scenario ............................................................... 88
APPENDICES .......................................................................................................... 89 7. ARCHITECTURE SOURCES............................................................................. 89 8. AIRSPACE CONGESTION................................................................................ 90 9. MANAGED AIRSPACE CONTROL................................................................... 91

9.1 Structured Route Airspace Control......................................................................................... 91
10. DEFINITION OF DELAYS.................................................................................. 92 11. ENGINEERING REQUIREMENTS..................................................................... 93 12. COMPONENT-BASED DEVELOPMENT .......................................................... 95
12.1 Why CBD for the development of the Overall Architecture .................................................... 95 12.1.1 Motivation........................................................................................................................ 95 12.2 Component-Based Development (From AVENUE) ............................................................... 96 12.2.1 Components.................................................................................................................... 97
13. ACRONYMS....................................................................................................... 99
Page viii
Working Draft
Edition: 2.6
FOREWORD
This edition is being issued to make visible the latest status of the strawman document as an aid to production of the formal deliverable from the overall architecture activity. It incorporates the latest information from all contributors The cross-domain components identified in working meetings have been gathered together. However, not all of them have been fully described, and there are probably some extra ones. The document is now internally consistent with the management overview document, but requires review. The main unresolved issues in this edition are listed below: (a) The context section currently only gives the responsibilities of actors and does not state the dependencies/services used between the external actors and the system. It is normal to have these in both directions and they are of particular importance in relation to the scenario work. (b) The architecture drivers section is a repeat from the management overview more depth may be required. (c) The list of cross-domain components needs to be finalised, it is currently incomplete. Some components currently identified as cross-domain may not be, or should be part of another component. Others appear to be duplicates. Some text in the section doesn't actually identify components. If it should, they need to be made explicit and have the same kind of description as other components. (d) For each cross-domain component, the domains it is common to need to be identified. (e) With the changing of components, services and their names, there are many inconsistencies in the services provided to and dependencies/services used. Sometimes they mention components that don't exist, sometimes services that don't exist, sometimes its just a matter of name changes. Services provided to components are not always listed as dependencies/services used by the latter. (f) Service names need to be reviewed to make sure they are concise and as selfexplanatory as possible. In the deliverable, we won't have the space to explain all the services. (g) Data structures have not been fully addressed in all domains. (h) EAD domain needs to be converted to AIM. (i) Avionics section has been reviewed by ANM, but is not fully aligned with the rest of the document. Further analysis is needed to ensure consistency of content. There are many outstanding questions and issues raised by the modelling activity and other reviews. It is recommended that only those issues that contribute to the production of the overall architecture formal deliverable be addressed now.
Edition: 2.6
Working Draft
Page 1
1.
INTRODUCTION
Note to this draft (2.6): Editorial comments are in blue italics..
1.1
The Business Need Being Addressed

This document provides the architectural framework, or big picture, which captures all the disparate systems and their associated interfaces that support the Gate-to-Gate improvements being addressed in the Eurocontrol ATM 2000+ Strategy Vol. 2. This document provides an overall view of the impact of operational requirements and concepts on architectural issues through to 2010. In the short term, the results of this phase of development of the architecture will help to ensure adequate cross-domain and programme co-ordination at the technical interface level, and consequently early identification of inconsistencies. It will provide the basis for a Systems Engineering approach for the Agencys projects and programmes that will complement other activities. Mastering the overall scope of Gate-to-Gate from an Architectural view will demonstrate the Agencys role in providing technical leadership to the ATM community In the subsequent phase, the architecture will provide a blueprint for Stakeholder systems development. This will balance the interests and requirements of all stakeholders. The overall architecture for EATMP defines the system of systems that is formed by the integration of underlying systems - airport, air traffic services, and the air- and ground-based elements of airspace users Many of these systems already exist - and are independent operations. The architecture will provide a convergence point for these systems, nominally for the year 2010. This will demonstrate how the Operational Improvements identified in the EUROCONTROL ATM 2000+ Strategy will be incorporated into the system that today is non-uniform and largely disconnected. The role of the overall EATMP architecture is to show how to integrate these separate systems to provide a seamless distributed system of systems. The architecture will be developed through several iterations. The first phase of these is documented here. This will rationalise the Domain (Programme and Unit) architecture initiatives currently underway. It will also identify, through comparison against the expected scenario for 2010, what changes will be needed to fulfil the operational requirements for this target. The CHASEIT1 forum identified the production of the overall architecture as the priority item for future work. This group represents the architecture and
The Collaborative Harmonization of Architecture, S.E and Integration Techniques (CHASEIT) forum acts as an EUROCONTROL Agency-wide forum for co-ordinating architectural, system engineering and integration issues at the overall EATMP level. (See the CHASEIT terms of reference at http://orbite.eurocontrol.be:82/chaseit/chaseitproceedi_1/chaseittermsofr/index.html for more information.)
Page 2
Working Draft
Edition: 2.6
systems engineering interests from across the key Domains. They have the responsibility for the development of this document. Add scenario overview and mapping in here as a summary Clarify this as next steps or just refer to new subsection replacing future.
1.2
Phase 1: Summary of Goals

The goals are to provide a Gate-to-Gate Architecture Framework that will: 1) describe the Gate-to-Gate Architecture in terms of conceptual components with their relationships, the services they supply and the information that they need; identify common information, and those services that are pre-requisites for inter-connection or inter-working between major ATM components; provide a means to ensure consistency between the future Domain architectures maintain traceability between the Architecture and its base-line documents (in particular the EUROCONTROL ATM 2000+ Strategy documents) to serve as a uniform component vocabulary for users throughout the EATMP Domains and Member States.
2) 3) 4)
5)
The result of Phase 1 will primarily be used as a systems engineering and management tool to rationalise the Agency's current plans. A further phase is under consideration, where it will be used as the baseline from which to develop a more comprehensive, top-down, architecture in conjunction with the key stakeholders Airport, Airlines, ATM and other Service Providers, Industry and other interested parties.
Edition: 2.6
Working Draft
Page 3
1.3
Development Process
The following diagram outlines the process used to develop this initial version of the overall architecture. This diagram needs to be updated to show the actual process used.
Current (draft) Architectures CFMU Euro-ADD
Architecture Development
Mapping : Objects into components ARCHITECTURE Components + Identify: Changes/ assumptions for 2010 target Domain review
Enterprise Information Computational
Collation: Establish relationships
Other sources CDM EAD
Gate to gate extensions (a) Model Repository (b)
Target + by Time
STRATEGIES ATM 2000+ Domains

ATD SUR Concept Repository (c)
ROAD ROAD MAP MAP
Develop: Scenarios Use Cases
Concept Analysis
Model Analysis
Current tools/projects (a) - GATAF (b) - MERGER (c) - PATHFINDER
Figure 1: Overall Architecture Development Add diagram showing changes/assumptions/issues to meet requirements for 2010 defined by scenario (NB to be done refer to ISSUES section in management overview ). Provide reference to tools/repositories. The Architecture repository contains the results of concept analysis and architecture analysis in the form of models. This can be used as a high-level tool in support of a permanent monitoring of the various architecture initiatives within the EATMP Programmes and Units by the SCSU and PPM.
1.4
Component-Based Architecture
The most promising method for defining the future architecture is to use the principles of component-based architecture. This approach has been adopted by the CFMU and EEC. Initial analysis has indicated that this will provide the optimal level of granularity at which to define the architecture. A short description of the motivation for using this is given in Section 12. A description of component-based architecture from AVENUE2 is also appended
AVENUE is a European Commission project whose goal is the construction of an ATM validation platform An ATM Validation Environment for Use towards EATMS
Page 4
Working Draft
Edition: 2.6
The main advantages of component-based architecture are as follows: It provides the means to separate out the life-cycle of the different components. This meets the need for different communities or projects to plan transition steps that have a degree of independence. This is a key requirements for a multi-system environment such as EATMP. Transition. There will be concepts that cannot be realised by simply building on the existing component (sub-system); these are so radical that they will require new components to be developed. Size - for independent development. Recognisable components can form the basis for independent development and therefore can be built by Industry as pre-fabricated blocks to be integrated into systems by the stakeholders. This will provide the means for reusable, common development. Interface definition. (May remove IDL reference as being to CORBA specific as such and talk about ICDs (interface control documents)) The use of Interface Definition Language (IDL) allows interfaces and the semantics of information exchange to be uniformly and unambiguously defined Services and Functions.
Service
A system can be described in terms of the services it provides to its users (which may in turn be systems), and the services it requires from its users. This is an external (or black box) view of the system. A complex function is to be decomposed in order to make it manageable. This decomposition or factoring The philosophy is built on the core concept: responsibility. Which is unique to one component Two or components, or systems built of components) can interoperate (work together, exchanging information and actions) to accomplish the same function in different work-spaces (stakeholder systems) are said to be federated. Components have dependencies upon the services of other components for their operation.
The system shall provide notification information to each crossed sector, prior to
Responsibility
Arrival manager: Determine optimum arrival sequence and provide advisories for realising this sequence. Examples: such as environment, or flight DP systems.
Federation
Dependency
Edition: 2.6
Working Draft
Page 5
Trusted components
Components implement formally defined interfaces. This reflects that the component satisfies certain contractual obligations. These ensure that independently developed components that can interact in predictable ways. The process of extending systems by adding components, irrespective of origin of manufacture is greatly simplified. Systems can be rapidly built from components sourced from multiple suppliers
The service view concentrates on the externally visible characteristics of the system, and avoids making assumptions about its implementation. This avoids unnecessary dependencies (too strong coupling) between systems. The implementation of a system may change, however, as long as its services are not affected, these changes are immaterial to the users and other systems. New services may be added, but without impacting those that already exist.
The need for minimum coupling between systems (and maximum cohesion inside) has long been recognised. Over the years, considerable progress has been made in the field of software engineering to deal with the issues involved. Adoption of the above terms is a step towards benefiting from those achievements. It is expected that the state-of-the-art of today will have become the mainstream by the years 20052010 and that ATS systems built in that timeframe will be: Hosted on standardised computing platforms, with CORBA-compliant object request brokers and related services integrated into the operating system. Such platforms will hide most of the complexities of distributed systems, and will be fit for use in a demanding environment like ATS (real-time behaviour, dependability, security, etc.). Based on object oriented principles, with ATS business objects being largely standardised through the OMG standardisation process. Components based and open, allowing third party vendors to develop specialised components (In the OMG sense) that can be integrated on a plug and play basis.
The implications of the above are, on the one hand, that the (potential for) interoperability will significantly increase and that system evolution will be easier and faster to achieve. On the other hand, there will be an increasing reliance on off the shelf system elements (the platform and certain components) over which the ATS Provider has little or no control. This will lead to: The need for shorter procurement cycles. The need for continued vendor support for off the shelf items, including the requirement to continuously follow the evolution of those items. The need for rigorous, largely automated regression testing (including interoperability testing).
As illustrated by the boxed statement above, there are some significant directions in the standardisation process of industrial products. It is important to understand these and their implications, in order to make best use of the industrial capabilities.
Page 6
Working Draft
Edition: 2.6
1.4.1
Process: Component identification - Component content definition This is a placeholder to be updated by what we actually did also include the process for identification and documentation of cross-domain components refer also to section 5.2
For each component: Define the context Define the object classes that are the constituent parts define the Services provided and used (consumed) define the main information (data) flows identify where possible the semantics identify the interfaces and their construction (in outline) produce (where necessary) collaboration diagrams produce interaction diagrams to determine the dynamics (Use cases)
1.5
Future Development
Use of phase 1 as baseline for consortium approach but this would be more topdown. The Management document outlines the proposal for Phase 2. The result of Phase 1 will provide the Agency with a means to rationalise the current work on EATMP architecture, together with the assumptions and changes needed to meet the requirements of the proposed 2010 scenario. This will provide a foundation for the further architecture development. The goal for future developments should be to provide a target architecture that will be of benefit for all EATMP stakeholders. To achieve this goal, it is recommended that a consortium should be formed where all stakeholders and their interests are represented. The resultant design aims of this future work are the following: To identify information, computational and engineering components which are/will be common to two or more domains. To show which existing and new physical components will be required to support specific ATM 2000+ Improvements. The output from phase 1 is a logical architecture, however later development must provide a mapping of Operational Improvements to architecture. Further it must consider the physical (system) architecture in the context of non-functional requirements (QoS etc) To show the overall impact of all Improvements for each Stakeholder group whilst taking into considerations the Improvement priorities. To Expand on Phase 1 to cover: the non-automated elements; versions of the architecture for the non-core area; versions that correspond to different timeframes (2005, 2015);and evolution plans.
Edition: 2.6
Working Draft
Page 7
To provide a target Architecture that can be used for: decision making, for influencing research, development and production at a more detailed domain level; providing a means of appreciation of the problem domains and, ultimately, for representing Country Instantiations3 and providing the basis for transition planning. Identification of global architectural requirements and by working with global and regional organisations4, convergence towards common components; vocabulary and where appropriate, solutions
3 4
An instance (mapping) of the architecture as conceived by a particular country to fit its environment. For example FAA for Flight intent; IATA/AEEC /EUROCAE for common air/ground components
Page 8
Working Draft
Edition: 2.6
2.
SCOPE
The scope of the architecture encompasses all automated systems (including those that are relevant from aircraft, Airline Operations Centres (or similar services provided by third parties), and airports) and seeks to identify all other systems and humans that interact with those systems. The automated systems identified are those needed in the Core (high-complexity) area by the year 2010. Later work will cover the less complex areas. The phases of flight covered by the scope have been determined by the 1998 Gate-to-Gate task force. The scope is in consequence broader than that encompassed by ATM/CNS, as it covers ground planning, airspace planning and tactical activities in which Airport, Airline Operations and Aircraft are directly involved.
Planning Layers
strategic pre-tactical tactical short-term executive
Automated Support (Enablers) for Operational Improvements up to 2010, developed in EATMP Programmes
Phases of Flight
charging
Programmes
ground handling on-blocks / off-blocks arrival / departure
en-route 2005 2010 2015
ATM/CNS Airports (air-side) Aircraft (avionics) AOC (flight planning) Airports (land-side) Other AOC & Aircraft systems
Time Horizon
Domains
Figure 2: Scope of the Overall Architecture a global, multidimensional, but not yet all-encompassing view of the single ATM system of systems for the ECAC area. The Overall Architecture addresses the automated support for primary business processes of Air Traffic Management (ATM). Automated support for other business processes (such as maintenance, training, incident investigation, etc.) are not addressed in this initial version, nor are the procedural and human related areas covered at this stage. The Overall Architecture is not restricted to automated support for ATM Service Providers (ATFM, ATC, AIM, AMN), but also addresses those of the
Edition: 2.6 Working Draft Page 9
other actors in ATM. This includes the Airport Authorities, the Aircraft Operators and the Flight Crews, insofar that the automated support for those processes is related directly to Gate-to-Gate air traffic management. The Overall Architecture is a target architecture, envisaged to be in place by the year 2010. The choice of date was driven by pragmatics, as a point at which existing ATM systems could de converged to follow one architectural direction and at a time by which a significant number of Operational Improvements should be implemented. It represents the high level design of an integrated ATM system of systems5 across all ECAC States, as opposed to the current collection of individual national systems. The current lack of an overall, high-level design has led to a poor level of integration and interoperability. This situation must be rectified in order to enable the introduction of operational improvements, developed through EATMP Programmes, as envisaged in the EUROCONTROL ATM Strategy for the Years 2000+. The Overall Architecture is a Gate-to-Gate architecture it addresses all phases of flight, from pre-tactical planning, through off-blocks to on-blocks (off stand to on stand). Not currently covered are ground handling (the turnaround of the aircraft) and route charging, but it does include all ATM-related activities while the aircraft is still on-blocks or even in use for another mission (service or flight). This is better illustrated by consideration of the planning layers. The actual management or control of individual flights, traffic flows, and the environment in which flights take place, is handled in different, partly overlapping and interacting planning layers with increasing look-ahead times (minutes, hours, days and longer). All of these factors are addressed, except for those that aim at strategic planning (the planning activities that lead to the creation of new resources). Thus, the Overall Architecture presents a global view of a multidimensional, distributed system. In the past, it was acceptable to address certain dimensions in isolation. However, in order to keep up with the increasing demand, which is calling for increasing levels of automated support, integration and interoperability, this is no longer the case. Therefore, the Overall Architecture is a key enabler for the total system thinking that is now needed.
2.1
Data processing systems: Scope and Structure

The overall Data Processing (DP) infrastructure, i.e. the totality of DP elements (equipment and software), owned and operated by the Stakeholders, is decomposed as follows:6
The term system of systems is used to distinguish a logical system composed of integrated systems or elements of systems from the stakeholder population, that interact within a common framework according to rules determined by the common architecture. Source is DPS ADD Task Force report
Page 10
Working Draft
Edition: 2.6
(DP) Facility
The subset of the Infrastructure located at one place, in support of defined operations. The subset of the Facility that supports a coherent set of tasks.
[DP Infrastructure in] ACC Unit, APP Unit, Central Support Facility Operations, Test & Development, Training (different partitions are virtually identical in many cases) SDP, FDP, ODS
(DP) Partition
(DP) Segment
The subset of the Partition that provides a coherent set of functions. The subset of the Segment, consisting of a collection of components organised to accomplish a specific function or set of functions. The system is the unit of deployment management. A non-trivial, nearly independent, and replaceable part of a system that fulfils a clear function in the context of a well-defined architecture.
(DP) System
eFDP, Fallback FDP
(DP) Component
(probably the lowest level of interest)
2.1.1
Partitioning and Segmentation The ACC/APP Unit typically comprises the following partitions: The Operational Partition directly supports the daily ATS provision operations. It collects, processes, displays and distributes real-time surveillance- and flight information. The Test & Development Partition indirectly supports the operations by providing a reference environment to check-out and validate changed/new DP elements. It is typically a scaled-down instance of the Operational Partition. It may be connected to the Operation Partition to receive realtime data, but it will not be allowed or possible to distribute data to other than simulated data sinks. The Training Partition provides a training environment for system users. DP elements may be identical to those in the Operational Partition, or they may be different but provide the same look-and-feel for the users. In addition, simulators are there to mimic the external environment. As for the Test & Development Partition, it may be possible to feed in (possibly historic) real-time data, but again it will not be allowed or possible to distribute data to other than simulated data sinks. Other, very similar partitions may exist (e.g. a Playback Partition), or a generic partition may exist that can be configured for any of the different roles. For contingency purposes, it may be possible to reconfigure DP elements in order to make them part of a different partition. However, such reconfigurations are generally not done in real-time.
This document only considers the Operational Partition. Any DP elements that serve several partitions (e.g. data communication elements that receive
Edition: 2.6
Working Draft
Page 11
surveillance information and provide feeds to all partitions), are considered to be part of the Operational Partition. The Operational Partition typically comprises the following segments: Surveillance (Data Processing); Flight (Data Processing); Support (Data Processing); ODS; Others.
Such segmentation mainly exists for organisational (engineering) purposes, and may sometimes be rather artificial (but chosen for good reasons). Different segments require different specialised expertise to maintain and develop them. The drawback of segmentation is that it may give rise to artificial boundaries, leading to gaps, overlap or non-optimal solutions. In this document, all segments are considered, without trying to establish a formal segmentation model and without trying to make each segment complete. The next level of decomposition is the system level. Where a segment performs a coherent set of functions, each function may be implemented on one or several distinct physical DP elements, e.g.: A primary system; A first-level fallback system; A second-level fallback system.
The initial (Phase 1) version of the architecture, has the focus on a logical architecture.The next level of decomposition is the component level. Decomposition into components is done when a high degree of isolation is required, and provided for, between the functions performed by the system. Reasons for isolation may be safety/dependability related, but may also be because of different envisaged evolution paths. The component level is the primary level of interest in this document. Further decomposition of components into configuration items (modules, sub-components, or whatever other terminology is used), is beyond the scope of this document.
Page 12
Working Draft
Edition: 2.6
3.
CONTEXT
The section presents the actors, whether they be whole organisations, humans or automated systems, that interact with the components covered by this architecture. The following rules for selection were used to identify the relevant items:
Retained for Phase 1 Has a responsibility in the primary business process. Responsibility occur between the tactical planning phase and the post flight phase. Responsibility addressed by an Agency programme or project. Responsibility addresses 2010 Operational Improvement as defined by EUROCONTROL ATM 2000+ Strategy. Not Retained Responsible for a support process Strategic planning phase is excluded (see note below).
Note: Strategic Planning / Tactical Planning. In strategic planning, decisions must be taken on how to cope with the demand. It may mean adding resources such as airways, airports, runways and sectors etc. In tactical planning, resources are basically fixed but the remaining flexibility can be exercised to ensure efficient utilisation to cope with the actual demand. Basically fixed could mean that certain conditional routes (CDRs)7 are activated if needed and if agreed with the military, or a different scheme for sectorisation is used. It means pre-planned use of known resources, it does not mean building an additional runway overnight and it does not mean inventing completely new routes. This note and the description of the considered phases are repeated in section 6 Scenario.
Conditional Routes are those that may or may not be available, and example is those routes that cross Military airspace.
Edition: 2.6
Working Draft
Page 13
The following figure depicts the context for Overall Architecture strawman.
External Gate-to-Gate Automated System CNS/ATM Automated System
Airspace M anager <<domain>> Survei llance <<domain>> Airspace Management
Airport Operator
Air cra f t Operator
<<domain>> Navigation Infrastructure
<<dom ain >>

Air Traffic Flow Management
Pil ot
<<domain>>
Aeronautical Information Management Peer ATS Provider
<<domain>>
Air Tr aff ic Control
Flow Manager
Meteo Service Provider Controller
Sen sor
Time Servic e Prov der i
Environment Data Service Provider
Figure 3: Context of the Overall Architecture The two overlapping boxes highlight the distinction that is drawn between the core business process - ATM - and the peripheral processes that contribute to ATM, in the context of Gate-to-Gate, such as gate/stand planning, non-ATC controlled ground movement, etc. Humans actors are external to the CNS/ATM architecture addressed by this document, as only automated elements are considered.
3.1
Actors
This section describes the actors and their responsibilities with respect to ATM. For each actor, the sections below: provide a unique name; and define its responsibility with respect to the automated aspects of ATM as precisely as possible.
3.1.1
Pilot The pilot, assisted by the avionics system, has the following responsibilities: - Check/modify FPL and approve it.
Page 14
Working Draft
Edition: 2.6
- Execute the flight safely. Tasks relating to this responsibility are: react to the advisories/alerts of airborne safety nets; initiate corrective action whenever separation falls below a pre-determined safety threshold. - Execute the flight according to plan and following the instructions of ATC. Tasks relating to this responsibility are: maintain the planned aircraft trajectory when flying the aircraft manually; monitor the aircraft's conformance with its planned trajectory when it is under the guidance of the FMS; keep a pre-defined distance from the preceding aircraft on request of ATC. In addition the pilot has the possibility to negotiate with the appropriate controller flight trajectory modifications. If applicable the aircraft operator may be also consulted. 3.1.2 Aircraft Operator The Aircraft Operator is responsible for: preparing the seasonal flight schedules and providing data on commonly used routes (if appropriate); providing initial flight plans based on up-to-date information and negotiating subsequent modifications; ensuring availability of all resources required for the flight (including equipment, crew and data); managing disruptions to the planned execution of the flight. The tasks derived from this responsibility include the incorporation in the flight plans of CDR availability messages from the CFMU and AUP and UUP information from airspace management cells. - Provide commonly used routes (Route Catalogue used for re-routing) - Provide the initial flight plan, including preferred trajectory, to the CFMU, negotiate modifications. - Co-ordinate and finalise the availability of all resources (including pilot, aircraft equipment) 24 hours before the start of the flight. Study ANM/AIM/CRAM, traffic load in all sectors and choose optimal routing. - Declare to be 'ready' for the flight. - Manage delays, negotiate with CFMU (slot improvement proposal acceptance/rejection, slot revision request, slot missed information). - Advise the pilot before and during the flight about changes in the FPL. Transmit re-routing advice to the aircraft (both before takeoff and during the flight) as necessary to meet aircraft operator requirements. - Acquire the AIS data required by the aircraft's Flight Management System (FMS) for calculating and maintaining the aircraft's trajectory. - Provide dynamic information during the flight: en-route weather conditions, NOTAMs. In the context of ASM, the AOC is responsible for:
Edition: 2.6
Working Draft
Page 15
- Receiving AUPs and UUPs from AMCs. - Receiving consolidated CDR availability messages from the CFMU. - Incorporating AUP and UUP information into their flight planning process. - Examining UUP information on the day of operation and determining if any flight trajectories can be improved by taking advantage of newly opened CDRs, TSAs or CBAs. - Transmitting re-routing instructions to the aircraft (both before takeoff and during the flight) as necessary to take advantage of UUP information. 3.1.3 Peer ATS Provider There are two types of Peer ATS Provider considered: Non-ECAC Area Control Centres (units providing ATM services outside the ECAC area) and Military ATC Units (units providing ATM services for military air traffic or in military reserved airspace). They have responsibility to co-ordinate the flights that enter or leave civil airspace under the responsibility of ECAC ATSUs. (Air Traffic Service Units) 3.1.4 Airport Operator The main responsibilities of the Airport Operator are: to manage non-aircraft surface traffic on the apron; allocate stand / gate / parking to aircraft. In order to assess and manage the impact of unscheduled events (such as equipment failures, late arrivals/departures), the Aircraft Operator must participate in tactical re-planning of flights' arrivals and departures. There are four areas where Airport systems which, in the context considered by the Overall Architecture, will have an impact upon daily (tactical) gate to gate operations: - Gate/Stand allocation The provision of information on the gate/stand status and collaboration, primarily with the Airline, on occupancy and logistic support, in those cases where this responsibility rests with the Airport. - Surface movement management. Responsibility for the apron typically rests with the Airport. In addition, information is exchanged with ATC on the movement of ground vehicles. - Infrastructure management. The status of runways, taxiways and manoeuvring areas. The management of the lighting and ground guidance systems. - Tactical (re)-planning. This forms the basis for collaborative dynamic planning for those occasions where the scheduled departure or arrival of aircraft does not go according to plan.
Page 16
Working Draft
Edition: 2.6
In each of the above cases, there will be service provided and used by the Airport management systems. In addition, there are information display systems that will data sourced from components that are within the scope of the architecture. 3.1.5 Meteo Service Provider Meteo Service Providers have the responsibility to forecast, observe, provide and collect en-route and airfield weather forecasts (TAFs) and the corresponding WX actuals (METARS) / reports for all parties dealing with flight planning and flight operations. 3.1.6 Time Service Provider Time Service Providers are responsible for time to the appropriate standards. 3.1.7 Environment Data Service Provider Environment Data Service Providers are responsible for the validation, publication and the change management of all national Aeronautical Information Service (AIS) data. This covers all aspects of aeronautical information and is not confined to Annex 15 (AIS data) 3.1.8 Sensor There are a number of different kind of sensors in the context of surveillance, which are considered as external: primary / SSR / Mode S radars, ADS-B ground station, Multilateration sensors, ASDE radar (Airport Surveillance detection Equipment). 3.1.9 Internal Human Users This section presents the human actors that are part of ATM domains and their further decomposition.
Internal Human User
Controller Flow Ma nager Airspace Manager
ATC Supervisor
Executive Controller
Multi Sector Planner
Planning Controller
FMP
Pre-TACT Flow Manager TACT Flow Manager
Figure 4: Main Categories of Human Actors
Edition: 2.6
Working Draft
Page 17
3.1.9.1
Controller Controllers have the following responsibilities: to maintain separation between aircraft; to prevent collisions between aircraft on the manoeuvring area and obstructions on that area; to efficiently and economically expedite and maintain the flow of air traffic and to manage the transfer of control of flights from/to adjacent ATC units & sectors.
3.1.9.1.1 Executive Controller The Executive Controller responsibilities are: - Maintain the aircraft separation as part of the sector team's task. - Manage the transfer of responsibility for the aircraft to the next sector. The transfer will involve communication with the aircraft as well as with ATC. It can make use of automation and datalink or can occur through voice contact. 3.1.9.1.2 Planning Controller The Planning Controller responsibilities are: - To plan the aircraft separation as part of the sector team's task. - To plan the transfer of the aircraft from the previous sector / to the next sector. 3.1.9.1.3 Multi Sector Planner The aim of multi-sector planning is the early detection and resolution of conflicts concerning individual flights, typically in a timeframe of 2 hours before the entry in the ATC unit's airspace. The difference with sector planning is that flight may not have reached the area of interest of the ATC, no radar tracks are available, information is not provided through the co-ordination phase with the adjacent sector. This requests new collaborations with upstream ATC units or CFMU. A multi sector planner is responsible for : - Detecting and resolving flight conflicts within a centre airspace and over the border of the own ATC unit within an area of interest. Multi Sector Planners provide planning services over several sectors in MAS. (Caucus) 3.1.9.1.4 ATC Supervisor The ATC Supervisor responsibilities are: - To manage the resources of the ATC Unit (en-route centre, approach unit or airport tower) to cope with the actual demand, e.g. to determine sector
Page 18
Working Draft
Edition: 2.6
configuration, runway configuration used and to liase with respect to the use of the restricted airspace. - To manage the resources of the ATC Unit to cope with the emergency situations (e.g. hijacking) or other abnormal situations (e.g. extreme weather conditions). 3.1.9.2 Airspace Manager The Airspace Management Cell (AMC) is a joint civil/military cell responsible for managing the day-to-day and temporary allocation of national or subregional routes / airspace under the jurisdiction of one or more ECAC State(s). Approved Agencies other than ACC that perform airspace-related activities are responsible for submitting requests for the allocation of airspace or routes to the appropriate AMC and for incorporating AUP and UUP information into their planning process. 3.1.9.3 Flow Manager There are a number of different kinds of Flow Manager, each with distinct responsibilities. FMD (Flow Management Division) / Pre-Tactical Flow Managers are responsible for pre-tactical flow operations. FMD / TACT Flow Managers are responsible for optimising the use of available ATC capacity. 3.1.9.3.1 Pre-TACT Flow Manager FMD (Flow Management Division) / Pre-TACT Flow Managers. This group of users is located in Haren (one ops room). It is responsible for: - the pre-tactical operations. 3.1.9.3.2 TACT Flow Manager FMD / TACT Flow Managers. This group of users is located in Haren (one ops room). It is responsible for: - optimising the use of available ATC capacity. 3.1.9.3.3 FMP Flow Management Positions (FMP) are located in ATC Units and ensure liaison with CFMU. The FMP responsibility is: - locally manage the available capacity. The Flow Management Position at an Area Control Centre (ACC) is responsible for: - Submitting requests for the allocation of airspace or routes to the appropriate AMC. - Receiving AUPs and UUPs from AMCs. - Incorporating AUP and UUP information into their operational planning process.
Edition: 2.6
Working Draft
Page 19
3.1.10
Actors Not Retained for Phase 1 Central Office of Delay Analysis (CODA) Collate, analyse, and report on delays experienced by European air traffic. Central Route Charges Office (CRCO) Calculate and collect route charges on behalf of EUROCONTROL Member States and other Participating States. (Airport) Strategic Planning Manager The Strategic Planning Manager has responsibility to: Manage the strategic planning services for the airport, such as capacity management and flight planning. For flight planning, it provides six-monthly slot planning and resource allocation to flights.
4.
ARCHITECTURE DRIVERS
A summary for phase 1 is provided in the Management Overview. In addition to the drivers given in the overview the intent is to provide more depth and practical guidance in this section.
4.1
Operational Context
Insert the reference list of 2010 Operational Improvements. provide a traceability map. Add other relevant notes vis: Architecture must be capable of supporting centralised and distributed systems, since Airspace structure may change and not be bounded by national frontiers etc. The intention is to
4.2
Technical Context
Insert comments on need to interface to / encapsulate legacy systems. Need for (eventual) support of low- and high-complexity areas. Need for dynamic reconfiguration to support the virtual centre and for disaster / recovery.
4.3
Principles
Revised and summarised list of applicable SCS architecture principles to be inserted. This will include: Transparency (as in RM-OPD) for centralised or distributed operation;
Page 20
Working Draft
Edition: 2.6
Interoperability; Virtual centre; Open/component-based architecture.
4.4
Information Management
Apart from a few strategic statements, this may be incorporated into the cross-domain components section. (SWIM may be referenced in the context of Environment Information as a goal.)
4.5
Assumptions
This will contain a list of assumptions made: Institutional Regulatory Organisational Technical
Edition: 2.6
Working Draft
Page 21
5.
EATMP OVERALL ARCHITECTURE - REPRESENTATION

Two diagrams to be inserted: A high-level procedural model. An example of the granularity and content of such a procedural interpretation of the architecture is given below. Clearly the scope will be larger. A (UML) component model (current diagram to be updated/replaced).
5.1
Structure (to be updated)

HIGH LEVEL BUSINESS MODEL (Primary Process)
Strategic Planning (months) Meteo data
RPL (Scheduled Flights)
RPL
Sector Exit Time
AOC Dispatch Aircraft
Tactical Planning (days) Meteo data
FPL (Non-Scheduled Flights)
FPL
Sector Exit Time Pre-Flight FPL Updates & New FPL Schedule Flights (hours) Air Filed FPL?
Meteo data FPL Sector Exit Time FPL Sector Exit Time & ATA FPL ATD & ATG
Meteo data?
Meteo data
Supervise ACC
Holding Stack (De-)Activation
Supervise APP
Runways in Use
Supervise Airport
Meteo data? ATD & ATG Aircraft Pilot
ACC Plan
Sector Exit Time
APP Plan
Sector Exit Time & ATA
Slot Plan
Plan Sector
Clear ances Actual Times
Plan Departures Arrivals Sector Plan
Clear ances Actual Times & ATA
Plan Runways Taxiways Gates Slot Plan ATD & ATG
Trajectory Changes
Sector Plan
Air Filed FPL? Control Sector Control Departures Arrivals Hand Over Control Runways Taxiways
Trafic Situation Picture
Hand Over
Controller / Pilot Communication
Figure 5: ATM High-Level Business Model
Page 22
Working Draft
Edition: 2.6
This is a placeholder for a high-level business model. It will be changed or adapted to correspond to the gate to gate scope. The structure of the overall architecture is focussed on defining the interactions between subsystems and components. The purpose of the high-level architecture is to identify the inter-component dependencies (i.e. the interactions and exchanges between system elements). The content of the individual components is an internal issue that is addressed by the EATMP Domain or Programme owner responsible for its development. This will enable the Domains and eventually the stakeholders to understand and follow the structure defined by the architecture team. This structure will then provide the basis for the process of elaboration of detail. This will ensure that at every level of abstraction, the design of the system will follow common principles, from coarsest to the finest level of detail. For each area of the architecture, the following information is recorded, where identified: In the process of being updated in accordance with WJ template. Actor name and responsibility; Component name and purpose (responsibility) Main objects that they contain (either as a summary paragraph or itemised list) Interfaces (initially in the diagram cross reference table and specific details to be added); Services provided / used for both Actors and Components Each service is identified by a name (noun) and a qualifier if the name is generic (e.g. Information) and the source needs identification. Main data structures (owned and public) Events (maybe in the future?)
5.2
Overview of Components
The following diagram shows the components from the different domains and as well as the cross-domain components. In addition it depicts the colour code for the domains that is used throughout the document.
Edition: 2.6
Working Draft
Page 23
<<domain>> Air Traffic Control
<<domain>> Aircra ft Operat or
Controller Workstation Manager
Correlation Manager
I np ut () Co -ordi na tio n() AT C Co nstra in t I np ut() uses <<domain>> Airport Operator
Air Correlation() Ground Correlation()
Medium-Term Conf lict Manager
Short-Term Conf lict Manager
Advisory() Cross-Doma in Compo nents l nfrastru ct ure Ma na ge r

Airp ort In frastructure Mo nitoring( ) Control L ighting()
Warning()
Depar tur e Ma nager Gate Monitoring() Gate Serv ice Monitoring() Ground Vehicle Monitoring() Parking Position Notif ication()
Arriv al Manager
<< ou t o f sco pe >> Gate Manager
Advisory()
Advisory()
use s Flight Manager HMI uses

Display ()
<<domain >> Air Traffic Flow Management <<do main >> Avionics
Flight Inf ormation() Flight Plan Creation() Constraint() Trajectory () Distribution() ICAO Flight Plan Management()
Ai r Traf f ic Flow Manage r
Load State Manager uses DA P Manag er

Airborne Parameters() Aircraf t Conf iguration() En vironme nt Ma na ger
uses
Nav igation() Guidance() Flight Intent() Aircraf t State()
Flight Controls
Navigation
Surveillance
Surv eillance() Hazard Detection() Collision Av oidance()
Au tonom ous Se ns ors
Flight() Load State(f light) Flights Ov er(locations, period) Flights By (AOList) Geography () Airspace() Aerodrome() Sector() Meteo() A/C Perf ormances()
Manage Regulation() Manage Exceptional Condition() Manage Re-routing() Trajectory () Message() Slot List() Slot Inf ormation() Re-routing Inf ormation() Suspension()
Sensor Data()
Radar & XPDRs uses

Conf iguration Manager Horizontal Components Communications and Middleware (f rom Cross-Domain Components) Traf f ic Load() Sector Conf iguration() Aerodrome Conf iguration() Workload() Position and Future Trajectory Data() Local Meteo()
Communication Radios
Position and Future Trajectory Data()
Nav igation Radios Nav igation Data()
Commun ication Fu nct ion Protocol Translation()
<<do main >> Airspace Ma na gem en t
uses
Airspace Activ ation Manager
Airs pa ce P lan C o-o rdina tio n Man ag er
Input AUP() Input UUP() uses

uses
<<domain>> Navigation Infrastructure
ASM Communications Manager
Load AIS Data() Input Activ ation Request() Activ ate/Deactiv ate Airspace() Activ ate/Deactiv ate Route() Publish AUP() Publish UUP()
uses
Sat elli te- Ba se d Bea rin g Pro vider Ground-Based Bearing Prov ider
Bearing Signal()
Bearing Signal()
Ground-Based Distance Measurement Prov ider Augmentation Prov ider
<<domain>> Surveillance
Distance Measuring Signal()
<<domain>> Aeronautical Information Management
Ground-Based Landing Sy stem
Landing Beam()
Air Surv eillance Data Processing and Distribution
Air Data Acquisition
Air Traffic Situation Picture()

Ground Surv eillance Data Processing and Distribution
Broadcast()
Ground Data Acquisition
Ground Traffic Situation Picture()
Broadcast()
DAP Serv er
Figure 6: Component Overview

Working Draft Edition: 2.6
Page 24
5.3
Air Traffic Control

This architecture reuses and extends the Architecture Description Document (ADD) 'Eurocontrol Agency View' produced in the context of the DPS-ADD Task Force.
5.3.1
Arrival Manager
Responsibility
Determine optimum arrival sequence and provide advisories for realising this sequence. It will assist in scheduling traffic from arrival queue (holding stack) to runway.
Main Data Structures (owned and public)

Arrival Sequence: result of optimisation Advisory Optimisation rules: separation, maximum delay/swap applicable
Services Provided
Service Description Provide the set of constraints to be placed on flights in order to realise the optimum arrival sequence (apportion any delay equitably between all flights). Provided To Flight Manager
Advisory
5.3.2
Departure Manager
Responsibility
Determine an optimised sequence of departures for a runway and provide advisories for realising it. The component should schedule traffic from runway to the first point of the air route and/or the first point in en-route airspace. The calculation should be based on ETD (as determined by tactical planning) and wake turbulence category. The sequence time horizon is approx. between 100 min and 10 min before take-off.

Departure Sequence
Edition: 2.6
Working Draft
Page 25
Optimisation rules: separation, maximum delay /swap applicable
Services Provided
Service Description Provide an optimised sequence of departures for a runway. Provided To Flight Manager
Advisory
5.3.3
Controller Workstation Manager This component is expected to become an instantiation of a cross-domain component yet to be defined, dealing with HMI.
Responsibility
Provides automated support for various operator roles (Executive Controller, Planning Controller).

Flight Plan: trajectory position, ATC constraints (strategic and tactical), planned
Co-ordination: status, dialogs in progress
Services Provided
Service Description Provide appropriate input to other components, dependent on current role. Present/capture information on coordination and transfer process (coordination conditions). Ensure dialog between adjacent controllers is correctly conducted (timing). Flight Manager Planning Controller Executive Controller Provided To
Input Co-ordination
ATC Constraint Input
Present/capture ATC constraints decided or to be approved by the executive controller. If data link is used, ensure the dialog between controller and pilot is correctly conducted: - obtain from controller the approval of pilot request; - ensure clearances are received by the aircraft/pilot.
Flight Manager Planning Controller Executive Controller
Page 26
Working Draft
Edition: 2.6
5.3.4
Short-Term Conflict Manager
Responsibility
Detect based on ground information: imminent (< 2 min) violation of prescribed separation minima between aircraft in flight (STCA); or imminent violation of minimum safe altitude/height by aircraft in flight (MSAW); or imminent violation of active airspace restrictions by aircraft; or runway incursion. The component should have a time horizon of at least 1 minute more than the corresponding component in the air. Warning is a broadcast service.

Warning
Services Provided
Service Description Provided To Controller Workstation Manager
Warning 5.3.5 Medium-Term Conflict Manager
Responsibility
Detect: possible violation of prescribed separation minima between aircraft in flight; possible violation of minimum safe altitude/height by aircraft in flight; or possible violation of active/planned airspace restrictions by aircraft. The purpose of the service is to minimise the number of intervention performed by the executive controller. The Medium-Term Conflict Manager looks at potential problems approx. 20 min ahead based on flight data provided by different flight managers (centre and adjacent). Its coverage is defined by an AOI.
Edition: 2.6
Working Draft
Page 27
Main Data Structures

- Conflicts - Advisories
Services Provided
Service Description Provide the set of constraints to be placed on flights in order to resolve medium-term conflicts. Provided To Flight Manager
Advisory
5.3.6
ATC Flight Manager Instantiates the cross domain component (see section 5.3.5) and adds some additional services required to assist planning and executive controllers.
Services Provided
Service Description Detect when planned trajectory deviates significantly from aircraft current behaviour (based on surveillance data) and trigger appropriate actions (recalculation, notification). Answer "What if" questions related to getting the flight back on schedule. Typical parameters are related to direct routing (shorter distance), flight level changes (higher ground speed) and/or speed changes. Provided To Controller Workstation Manager
Conformance
SSR Code Allocation 5.3.7
Allocate SSR Codes to flight following Code Allocation Plan and flight situation.
Controller Workstation Manager
Correlation Manager
Responsibility
Establish and maintain the unique correlation of a flight from gate to gate between State Vectors (Surveillance) and flight plan information (ATC). Correlation will be established on a mode 3/A code or Flight Identification (Mode S or ADS) and maintained on the same attribute and/or the 24-bit aircraft identifier. Cross Checking will be performed on state vector information.

Correlation Information
Page 28
Working Draft
Edition: 2.6
Services Provided
Service Description Provide track / flight plan association information. The service is triggered for new tracks sent by Surveillance or for flight plans sent by the Flight Manager. Provided To Flight Manager Air Surveillance Data Processing and Distribution
Air Correlation
Ground Correlation
Provide correlation between track and identification data flight(Call sign, EOBT, ETOT) or service vehicles on runway, taxi route, apron and gate.
Flight Manager Ground Surveillance Data Processing and Distribution
Edition: 2.6
Working Draft
Page 29
5.3.8
ATC Overview
Flight Information( )
: Airport Operator Airline System : Flight Operations ATFM Instance : Flight Manager
r Traffic Situation Picture( )
Air Traffic Situation Picture( )
: Air Surveillance Data Processing and Dist ribution

Groun d Traffic Situation Picture ( ) : Ground Surveillance Data Processing and Distribution Air Correlation( ) Synchronis ation of flight information
Ground Traffic Situation Picture( )
Adjacent ATC Unit : Flight Manager : Arrival Manager ATC Instance : Flight Manager : Medium-Term Conflict Manager
Advisory( ) Flight Information( )
Ground Correla tion( )
: Correlation Manager
Advisory( )
: Departure Manager
Air Correlation( ) Ground Correla tion( ) Flight Information( ) Geography( ) Airspace( ) Aerodrom e( )
Advisory( )
Dial og Managem ent( ) Air borne Param eters( ) ATC Constraint Input( ) Co-ordination( ) Flight Information( ) Fli ght Pl an Crea ti on( ) Constraint( ) Trajectory( ) Distribution( )
Sector( ) Meteo( )
A/C Performances( )
Se cto r Configuration( ) Aerodrome Config urati on( )
Send( )
ATC Instance : Environment Manager Geography( ) Airspace( ) Aerodrome( )
ATC Instance : Configuration Manager Sector Con figuration( ) Aerodrome Configuration( )
: Controller Workstation Manager
: DAP Manager
: Mobile Communications Manager
Meteo( )
: Short-Term Conflict Manager
Warning( )
Conformance ATC Constaint (Deconflicting &Bottleneck Planning) Flight Information Trajectory
Traffic Load( ) Workload( ) Sector Configuration( ) Aerodrome Configuration( )
Transfer of Control ATC Constraint (Clearance) Flight Information Trajectory
ATC Constraint Input( ) Co-ordination( )
ATC Cons train t In put( ) Co-ordination( )
: Executive Controller : ATC Supervisor
: Pl anni ng Co ntrol ler
Figure 7: ATC Overview
Page 30
Working Draft
Edition: 2.6
5.4
Air Traffic Flow Management

The following has been derived from the CFMU corporate architecture version 0.300. The CFMU architecture is component-based, with components allocated to sub-systems to provide a (sort of) engineering view. Open questions are: The incorporation of ETFMS. The support for CDM. Involvement in trajectory management.
5.4.1
Load State Manager Note: internally, CFMU calls this component "Counter" as its basic function is to count the flight occurrences per location. The commonality between the Configuration Manager and Load State Manager needs further analysis.
Responsibility
- Provide load state - counting flight occurrences per location.
Services Provided
Service Description Inserts or updates a flight version on stimulus of message published by the Flight-Manager. Informs on the Load State of a location. Get flights over a location (point, aerodrome, airspace, set of aerodromes, air route, traffic volume, flow). Get flights belonging to an Aircraft Operator. Flow Manager ATC Supervisor Flow Manager Air Traffic Flow Manager ATC Supervisor Provided To
Flight
Load State Flights Over
Flights By
Aircraft Operator
5.4.2
Air Traffic Flow Manager
Responsibility
The Air Traffic Flow Manager is responsible for keeping track of and applying ATFM Regulations (i.e. negotiate re-routings and assign slots). More specifically, it is responsible for:
Edition: 2.6
Working Draft
Page 31
- handling regulation activation and application to a filed flight plans; - handling exceptional condition activation and application to a filed flight plans; - managing rerouting; and - ATFM co-ordination.
Services Provided
Service Description Create, activate, cancel, update regulation. Create, cancel, update of exceptional condition. Create, cancel, update of re-routing measure. Take into account new or updated trajectory information of a flight plan. Processes ATFM messages such as SDY, RJT, SRR, SRJ, SPA, SMM. Provide the slots of all flights affected by the specified regulation. Provide the slot (delay) information of a flight. Provide re-routing information of a flight. Provide suspension or shift information of a flight. Flow Manager Aircraft Operator Flight Manager Aircraft Operator Flight Manager Flow Manager Provided To Flow Manager
Manage Regulation Manage Exceptional Condition Manage Re-routing Trajectory Message Slot List Slot Information Re-routing Information Suspension
Page 32
Working Draft
Edition: 2.6
5.4.3
ATFM Overview
Flights By ()
: A ircraf t Operator ICAO flight plan creation, modification and deletion.

IC AO Fligh t Pla n Management( ) Re-routing Inf ormation( ) Slot Inf or mation( ) Manage Regulation( ) Ma nage Re-ro utin g( ) Slot Lis t( ) Re-routing Inf ormation( ) Slot In f orma ti on ( ) ATFM Insta nce : Flight Manager Flight Inf ormation( ) : Air Traf f ic Flow Manager Flights Ov er(, )
Re-routi ng and slot negot iat ion.

: Flow Man ag er
Load State() F light s Ov er(, )
: Load State Manager
Flight Inf ormation( )
Sector Conf igura tion ( ) Aerodrome Conf iguration( ) Sector Conf iguration( ) Aerodrome Conf iguration( )
Load State() Flights Ov er(, )
Meteo( )
: ATC Superv isor
Sy nchro nisa tion o f en v iron ment data Airspace( )
Sector( )
Aerodrome( ) ATFM Instance : Env ironment Manager ATFM In sta nc e : Conf iguration Manager ATC Instance : Conf iguration Manager ATC Instance : Env iro nmen t Man age r
Sy nchronisation of activ e or planned conf igurations (routes, sectors, airspace, aerodrome)
TSA, runway and sector conf iguration plan modif ication.
Figure 8: ATFM Overview
Edition: 2.6
Working Draft
Page 33
5.5
Aeronautical Information Management

Proposed architecture for Aeronautical Information Management (AIM). Source: draft AIS strategy.
: Environment Data Service Provide r NOTAM input( ) Data Co-ordination( )
: Meteo Service Provider
Airs pace( ) Forecast( ) Nowcast( )
Airspace( ) Aerodrome( ) Geography( ) AIM Ins tance : Environm ent Manager : Aircraft Operator Employee
Sector Configuration( ) Aerodrome Configuration( )
Sync hronisat ion of environment dat a

ATC Instance : Environment Manager
: Configurat ion Manager ATFM Instance : Environment Manager TSA, runway and sector configuration plan modification
: ATC Supervisor
Figure 9: AIM Overview
Page 34
Working Draft
Edition: 2.6
5.6
Airport Operator
This architecture offers two possibilities to interface with (Airport) ATC. The first option is intended for smaller airport where airport authorities will use remote access facilities offered by ATC. The second option is intended for large airports, which architecture will include one or more cross domain component allowing a seamless integration with CNS/ATM.
5.6.1
Flight Information System
Responsibility
- The component manages the repository of information concerning flights, stands, passenger information etc. It is aligned with the (external) flight information broadcast system.
Main Data Structures (Owned and Public)

Consolidated flight information
Services Provided
Service Description Provision of: - (pre-departure) flight information passenger; payload; stand etc. - (pre-arrival and arrival) flight information - ETA; cancellations; diversion etc. - tactical planning information - taxi times, routes etc. - airline operator information - air frame number; registration; engine type etc. Provided To
Flight Information Consolidation
5.6.2
lnfrastructure Manager
Responsibility
- The Infrastructure Manager monitors and manages Airport ground and terminal systems. These include lighting, communication, etc. in addition to terminal, gate, stand and taxiway. It includes airport surface vehicle management outside the area controlled by ATC. It may also include the monitoring of the regulatory function for noise and track keeping.
Main Data Structures (Owned and Public)

Airport infrastructure status -Taxiways; Apron etc
Edition: 2.6
Working Draft
Page 35
Airport environment status (visibility obstacles etc).
Services Provided
Service Description Monitoring of status of airport facilities: lighting, taxiways and runways. Monitoring of: - infrastructure (runway, taxiway, ground route lighting etc) - noise and track keeping; - ground vehicles; - airfield status (visibility, obstacles?). Provided To
Airport Infrastructure Monitoring
Control Lighting 5.6.3 Airport Operator Overview
Airport Operator Employee
Control Lighting( )
Display( )
: Airport Operator Empl oyee
Controls
Stand/Gate All ocation Notifi cation( )
Di spl ay( ) Flight Information( )
Gate/Stand allocation (Standard Airport / Advanced Airport)
ATC Fl igh t Informati on HMI : HMI
SUR Ground Surveillance HMI : HMI
AOP Instance : Flight Manager
: Ground Operations Manager

Stand/Gate Allocation Notification( )
: lnfrastructure Manager
2D+time state vector.

Display( ) Airc raft posit ion.
Synchronisation of flight information ATC Ins tance : Flight Manager

: Ground Surveillance Data Processing and Distribution
Figure 10: Airport Operator Overview
Page 36
Working Draft
Edition: 2.6
5.7
Aircraft Operator
This architecture offers two possibilities to interface to CNS/ATM. The first option is intended for small aircraft operators and/or start up airlines and based on the supply of a remote access facility (IFPS type of solution). The second option is aimed at larger, established airlines and based on the supply to the stakeholder of one or more cross domain component allowing a seamless integration of their systems with CNS/ATM. One kind of Aircraft Operator of particular interest is an Airline. operations are split into two main areas: Flight Operations Responsible for managing the aeronautical environment of flights, e.g. route planning etc. This area has one component: Flight Planning. Ground Operations Responsible for managing the "train set" - i.e. the logistical aspects of the flight. This includes ensuring that the aircraft, crew, catering, etc. are there in correct condition for the flight. This area has 3 components: Passenger/Freight Services, Ground Handling and Dispatch8. Note, the same person or organisation may operate in both ground handling and dispatch roles. All of these components are outside the scope of this architecture in Phase 1. Airline
5.7.1
Flight Planning
Responsibility
This component manages the day to day operation of flights. It is concerned with optimising airline resources across flights. Source: GATAF and discussions with Ken Reid, Keith Harman and Peter Stevenson.
Note that the European (not US) meaning of dispatch is used here. Dispatch is responsible for the management of individual flights arriving and departing the stand. It has responsibility for the expeditious departure of the aircraft. It manages the process and information flow associated with the arrival of the aircraft, and to ensure that the aircraft is ready for departure.
Edition: 2.6
Working Draft
Page 37
Services Provided
Service Description Determine the fuel required for a flight, based on its route, loading, weather conditions and overflight charge vs fuel cost reconciliation. Source: Discussions with KH and PS; comment from Ken Reid. Provided To
Fuel Requirement
Check Load
Determine the load available for the flight, given the aircraft assigned to it and check that against the anticipated load. Source: Discussions with KH and PS. Create and distribute ICAO and crew flight plans. The latter includes additional information such as predicted fuel burn along the route. The ICAO flight plan goes to the CFMU and the flight crew. The crew flight plan only goes to the flight crew. Flight planning will be able to make use of free-routes. Systems such as Jeppesen, SWORD (British Airways) and LIDO (Lufthansa) are used to produce both the ICAO and crew flight plans. Determine required changes to the flight plan and distribute as required. In particular, questions of rerouting (e.g. to get a better departure slot) will be decided here. Some flight plan changes will be negotiated with the pilot (e.g. inflight as part of CDM, a 3-way negotiation AOC <-> Pilot <-> ATC). Participate in negotiation of major trajectory changes. Provide information on schedule changes. Make airport slot change requests. Source: GATAF and discussions with KH and PS.
Tactical Flight Planning
Flight Briefing
Provide information relevant to the flight such as: - airports status; - meteo; - AIS. Source: Discussions with KH and PS.
Page 38
Working Draft
Edition: 2.6
Service
Description Monitor the flight and notify interested parties of: - any problems (ATC) - position (CFMU - APR (Aircraft Position Report) message). NB the latter aspect is a "patch" that is required since OLDI is not used outside Europe. Source: Discussions with KH and PS.
Provided To
Flight Monitoring
Departure Slot Negotiation
As a result of filing a flight plan, a departure slot will be allocated by the CFMU. Negotiation may be required with the CFMU to finalise the allocated slot. Any subsequent delays/cancellations are notified to the CFMU. In the case of a delay a new slot will be allocated. Source: Discussions with KH and PS.
5.7.2
Standard Airport Operator
Aircraft Operator Overview

Advanced Aircraft Operator
Flight Plan Creation( ) ICAO Flight Plan Management( )
: Aircraft Operator Employee
Display( )
ATFM Information HMI : HMI
AOC Instanc e : Flight Manager
AOC Instance : Configuration Manager
AOC Instance : Environment Manager
Aerodrome Configuration( )
Aerodrome( )
Meteo( ) ATFM Instance : Flight Manager Sy nchronisat ion of Flight Information

A/C Performances( ) Airspace( )
Figure 11: Aircraft Operator Overview
Edition: 2.6
Working Draft
Page 39
5.8
Navigation Infrastructure
The components of Navigation Infrastructure domain have been specified in a generic fashion, independent of the actual implementation. This has implications because, for example, to make use of GPS signals you need a receiver that is GPS-enabled (a standard GPS receiver, MMR etc). However, for documentation purposes a generic definition should be sufficient.
5.8.1
Ground-Based Bearing Provider Instances are NDB, VOR.
Responsibility
- Transmit a signal that allows any listener with suitable receiving equipment to determine its bearing with relation to the component.
Services Provided
Service Description Transmit bearing signal Provided To Navigation Radios
Bearing Signal 5.8.2
Ground-Based Distance Measurement Provider Instances are DME.
Responsibility
- Transmit a signal that allows any listener with suitable receiving equipment to determine its distance from the component.
Services Provided
Service Description Transmit distance measuring signal Provided To Navigation Radios
Distance Measuring Signal 5.8.3
Satellite-Based Bearing Provider Instances are: GPS, GNSS, GLONASS, Galilleo.
Responsibility
- Transmit a signal that allows any listener with suitable receiving equipment to determine its bearing with relation to the component.
Page 40
Working Draft
Edition: 2.6
Services Provided
Service Description Transmit bearing signal Provided To Navigation Radios
Bearing Signal 5.8.4
Augmentation Provider Instances are: GBAS, SBAS.
Responsibility
- Augments the signal transmitted by a space-based bearing provider in order to provide a higher degree of accuracy for receivers. 5.8.5 Ground-Based Landing System Instances are: ILS, MLS.
Responsibility
- Transmits a beam that an arriving aircraft can lock onto for guidance to the runway.
Services Provided
Service Description Transmit beam. Provided To Navigation Radios
Landing Beam 5.8.6
Navigation Infrastructure Overview

from Avionics : Navigation Radios
Distance Measuring Signal( )
La nding Beam ( )
: Ground-Based Distance Measurement Provider
: Ground-Based Landing System
Beari ng Sig nal( )
Bearing Signal( )
: Ground-Based Bearing Provider
: Satellite-Based Bearing Provider
Figure 12: Navigation Infrastructure Overview
Edition: 2.6
Working Draft
Page 41
5.9
Surveillance
The Surveillance Function will provide a Air Traffic Situation Picture and a Ground Traffic Situation Picture. Air Traffic Situation Picture, the traffic situation of all airborne aircraft in a defined geographical region. Ground Traffic Situation Picture, the traffic situation of all vehicles and aircraft on the aircraft movement area of an airport, including aircraft inbound for the runways. The Air Traffic Situation Picture is seamless and can be used by one or more ATM Centres and/or other surveillance users. The main object dealt with by the Surveillance Function is the aircraft and its attributes relevant for the executive control. Relevant attributes of the aircraft are 4D position, 4D speed vector, 4D acceleration, aircraft type, identification and others attributes deemed operationally relevant. The Ground Situation Picture is provided per Airport. The main object dealt with by the Surveillance Function is an aircraft or other vehicle and their attributes relevant for the executive control. Relevant attributes are 2D position, 2D speed vector, time stamp, aircraft type, identification and others attributes deemed operationally relevant.
5.9.1
Air Data Acquisition Responsible for collection of information from all indicated sensors for surveillance of aircraft while in the air. This Data Acquisition sub-system is implemented by one or more of the following components: Conventional radar, Mode-S radar or ADS-B ground station.
Services Provided
Service Description Provided To
Broadcast
Target reports.
Air Surveillance Data Processing and Distribution
5.9.2
Air Surveillance Data Processing and Distribution
Responsibility
Determine the State Vector for aircraft while in the air.
Page 42
Working Draft
Edition: 2.6
Note: ADS-C information is retrieved by the date link between avionics and the Mobile Comms Manager. The DAP Manager will store the Navigation State Vector. The SDPD encompasses all centre level functions required to provide an Air Traffic Situation Picture and includes e.g. multi sensor tracking.
Services Provided
Air Traffic Situation Picture 5.9.3
Correlation Manager Provision of surveillance data (TMA). Executive Controller
DAP Server The Downlink Aircraft Parameter Server (DAP Server) contains all functionality needed to collect and regionally manage all airborne parameters received from the aircraft. The DAP Server is considered to be a mix of communication and down-link aircraft parameter processing. Functions to be performed by the Downlink Aircraft Parameter (DAP) Server are: 1. Sub-network selection. 2. Ground station selection. 3. ATN End system. 4. Data Link Initiation and Control for ADS-C (DLIC). 5. Airborne Parameter retrieval and caching.
5.9.4
Ground Data Acquisition Responsible for collection of information from all indicated sensors for the surveillance of aircraft while on the ground and for vehicles in the manoeuvring area. This Ground Data Acquisition sub-system is implemented by the following components: ASDE radar (Airport Surveillance Detection Equipment); Multilateration component with at least three passive sensors listening to long or short squitter and optionally a transmitter for selective interrogation (Mode-S) of an aircraft; ADS-B ground station;
Edition: 2.6
Working Draft
Page 43
Approach radar (a primary radar combined with a SSR radar (Mode 3/A or Mode S).
Services Provided
Broadcast 5.9.5
Target reports.
Ground Surveillance Data Processing and Distribution
Ground Surveillance Data Processing and Distribution
Responsibility
Determine the State Vector (position, velocity, etc) for aircraft on the ground and for vehicles in the manoeuvring area. The SDPD encompasses all centre level functions required to provide a Ground Traffic Situation Picture and includes e.g. multi sensor tracking.
Services Provided
Ground Traffic Situation Picture
Provision of surveillance data (ground). Monitoring.
Correlation Manager Executive Controller
Page 44
Working Draft
Edition: 2.6
5.9.6
Surveillance Overview
Mode S, DAP Radars, ADS-B, Multi-Lateration sensors , ASDE : Sens or
: Executive Controller
Executive Controller Air Traffic Situation Picture( )
: Air Surveillance Data Processing and Dist ribution
: Air Data Acquisition

Broadcast( )
Surveillance Instance : DAP Manager
: Ground Data Acquisition
: Ground Surveillance Data Processing a nd D istribution Broadcast( )
Airborne Parameters( )
Air Correlation( )
Air Traffic Situatio n Picture( )
Airborne Parameters( )
Sen d( )
Airborne Paramete rs( )
Ground Correlation( )
Send( )
Di alog Ma nagement( ) : Mobile Communications Manager
: Correlation Manager
ATC Instance : DAP Manager
ATC Instance : Flight Manager ADS-C, Mode S data link
On board : Communication Function
Figure 13: Surveillance Overview
Edition: 2.6
Working Draft
Page 45
5.10
Airspace Management
This section presents a component architecture for Airspace Management (ASM).
5.10.1
Airspace Activation Manager This is basically an encapsulation of the airspace allocation services provided by an individual AMC, within its own area of responsibility. The component encapsulates a set of rules that, given a variety of inputs and parameters, determine the areas and routes to activate and the time frame over which to activate them.
Responsibility
- Manage the activation of CDRs, TSAs and CBAs over a given time period for a given area of responsibility.
Services Provided
Load AIS Data
Allows an AIS data set or a data update to be loaded into the internal AIS database. This includes definitions of CDRs, TSAs and CBAs. Allows a request for activation to be submitted for consideration in the allocation process. Overrides the internal rule set and allows a TSA or CBA to be explicitly activated or deactivated for a specified time period. Overrides the internal rule set and allows a CDR to be explicitly activated or deactivated for a specified time period. Produce an Airspace Use Plan based on the current allocation and requests received, and send this plan to the Communication Manager for distribution. Produce a Use Update Plan based on the current allocation and requests received, and the current AUP, and send this plan to the Communication Manager for distribution.
Input Activation Request Activate/Deactivate Airspace
Activate/Deactivate Route Publish AUP
Publish UUP
Page 46
Working Draft
Edition: 2.6
5.10.2
Airspace Plan Co-ordination Manager Within the ASM functional architecture, this component models the "other" Airspace Management Cells that an individual AMC interacts with during the normal course of daily operations, and the Centralised Airspace Data Function (CADF) within the CFMU. Co-ordination is required for several reasons: activation of CBAs, possible discontinuities between CDRs arising from different AUPs, and conditions detected by one AAM that requires an activation request to be sent to another.
Responsibility
- Manage the co-ordination between the AUPs and UUPs published by various AAMs.
Services Provided
Input AUP
Allows the information in AUPs published by AAMs to be recorded and used for coordination purposes. Allows the information in UUPs published by AAMs to be recorded and used for co-ordination purposes.
Input UUP
5.10.3
ASM Communications Manager Instantiates the Fixed (Ground) Communications Manager cross-domain component, together with a middleware service for registering users to receive information. The Send service is used for broadcasting a published AUP/UUP to all registered users and for transmitting an activation request to the AAM responsible for the airspace or route activation is being requested. The Receive service is used for receipt of: AUPs/UUPs and continuity warnings from the Co-ordination Manager; and activation requests from the Activation Manager.
Responsibility
Allow AUPs, UUPs and activation requests to be transferred to / from AMCs and external agencies, for example FMPs, AOCs and the CFMU. When data is received, the component that the data is intended for is identified and a service of that component is used to transfer the data.
Edition: 2.6
Working Draft
Page 47
5.11
Avionics
This architecture is based on ARINC Report 660A, especially the CNS Top Level Functional Architecture for the aircraft. For the purpose of the overall CNS/ATM Architecture the Navigation Function is decomposed in two functions: - Navigation (Aircraft State Estimation) is responsible for estimation of the current aircraft state. - Navigation (Flight Manager) is responsible for the trajectory which should be flown. Around 2010 trajectory information will be transferred through ADS from Aircraft to the Ground. The synchronisation between Flight Managers on the ground and Flight Managers in the air should be based on the same services or a subset of the ground-to-ground services .
5.11.1
Radar & XPDRs
Responsibility
- Radars & XPDRs are responsible for the detection of other aircraft in the vicinity, for the detection of bad weather ahead and for the exchange of data with other aircraft and the ground.
Services Provided
Position and Future Trajectory Data Local Meteo 5.11.2
Supply information on current position and future intentions - ADS-B, SSR Transponder. Provide information derived from weather radar.
Surveillance
Navigation
Responsibility
- Navigate the aircraft. - Predict future trajectory. - Provide inputs for flight controls as required to fly the aircraft along (or as close as can be achieved to) the desired trajectory, respecting various constraints.
Services Provided
Navigation
Determine where the aircraft is.
Page 48
Working Draft
Edition: 2.6
Service
Description
Provided To
Guidance Flight Intent Aircraft State
Guide the aircraft along its desired trajectory. Notify the crew of deviations. Perform trajectory predictions and provide information on flight path intent. Provide information on the position of the aircraft and its status. Includes data on RNP, and EPU. Flight Manager Surveillance
5.11.3
Surveillance
Responsibility
- Identify and present information on external hazards to air navigation. - Self-contained safety-net that provides warning to the pilot of impending collision risk with other aircraft. The warning is based on data from active SSR interrogation (range, (relative) altitude, coarse bearing, range rate, and altitude rate). - It also provides vertical plane resolution advice when the risk of collision exceeds certain parameters. The advice is co-ordinated with the other aircraft involved when that aircraft is also equipped with a TCAS.
Services Provided
Surveillance
Detect terrain, traffic, weather. Consolidate surveillance data. Provide integrated surveillance situation. Determine whether detected terrain, traffic, weather is hazardous. Prioritise alerts. Provide information on strategic and tactical conflicts detected. The service provided by ACAS, ASAS and GPWS. Provision of warnings (and sometimes also resolution advice) to avoid collision with other aircraft and obstacles.
Flight Deck Displays
Hazard Detection
Collision Avoidance
5.11.4
Responsibility
- Display information from systems to pilot.
Edition: 2.6
Working Draft
Page 49
Services Provided
Display
Display datalink messages; aircraft state, RNP, EPU data; flight path intent; navigation commands and deviations; strategic conflict advisories, tactical alerts; integrated surveillance situation.
Pilot
5.11.5
Crew Controls
Responsibility
- Allow flight crew (pilots) to input commands to the systems.
Services Provided
Input
Allow flight crew (pilots) to input commands to the airborne systems.
Pilot
5.11.6
Communication Function This component instantiates the common component Mobile Communications Manager and adds an additional gateway service: protocol translation.
Responsibility
- Allow data to be transferred to / from the aircraft and external agencies, for example AOC and ATC units. When data is received, the component that the data is intended for is identified and a service of that component is used to transfer the data.
Services Provided
Protocol Translation 5.11.7
Translation of one format and protocol into another.
Flight Controls
Responsibility
- Flight Controls are responsible for controlling the attitude of the aircraft.
Services Provided
Aircraft Configuration
Crew Controls Flight Manager
Page 50
Working Draft
Edition: 2.6
5.11.8
Autonomous Sensors
Responsibility
- Autonomous Sensors are responsible for estimation of the state of the environment.
Services Provided
Sensor Data
Provide air data, inertial and AOA (angle of attack).
Navigation Flight Manager
5.11.9
Navigation Radios
Responsibility
- Provide data from measurements of ground/space navaid signals.
Services Provided
Navigation Data
Accept tune commands and make use of navigation aids to provide basic position information to the navigation function.
Navigation
5.11.10
Communication Radios VHF/MDR/HF/SAT COM
Responsibility
- Communication Radios are responsible for managing the (voice and data) Message exchanges between air and ground.
Services Provided
Position and Future Trajectory Data
Supply information on current position and future intentions - ADS-B, SSR Transponder.
Surveillance
Edition: 2.6
Working Draft
Page 51
5.11.11
Avionics Overview
: Pilot
Display( )
Input( )
Air craft Config uration( ) : Flight Deck Displays Trajectory( ) Surveillance( ) Hazard Detection( ) Collision Avoidance( ) Aircraft Configuration( ) : Crew Controls
: Radar & XPDRs
: Surv eillance
Trajectory( )
A/C Navigation : Flight Manager
: Flight Controls
Aircr aft State( ) Position and F uture Tr aj ectory Data( ) Sensor D ata( )
Position and Future Trajectory Data( )
Aircraft State( ) Sensor Data( )
Navigati on Data( ) : Communication Radios : Navigation Radios
: Nav igati on
: Autonomous Sens ors
Distance Measuring Signal( ) Landing Beam( ) : Ground-Based Distance Measurement Provider : Ground-Based Landing System
Bearing Signal( ) : Ground-Based Bearing Provider
Bearing Signal( ) : Satellite-Based Bearing Provider
Figure 14: Avionics Overview
Page 52
Working Draft
Edition: 2.6
5.12
Cross-domain Components
Components that appear in more than one domain instantiations of these are ascribed to specific domains.
5.12.1
Component instances The Architecture contains some cross-domain components that will be instantiated in different functional contexts (Systems). E.g. Flight Manager will be instantiated in ATC (ATD) and Flow Management (CFMU) systems. It should be realised that different instantiations can offer different sub-sets of the services implemented offered by the component. Technically this implies that the instantiation of a component should be welldocumented: which services it offers, to which services it subscribes.
5.12.2
Flight Manager
Responsibility
Provide validated, up-to-date and accurate flight information when and where such information is needed. This includes keeping track of all constraints and regulations for individual flights. The flight manager ensures the correct distribution (ground to ground) of flight related information according to the flight trajectory or progression and rules.

- Flight Plan (ICAO) - Constraint: ATFM or ATC constraint - Flight Script: combination of Flight Plan and Constraints - Trajectory (Filed, Regulated, Predicted, Actual depending on the particular view ATFM / Sector Planning / Sector Control) - Posting List - Distribution rules - Trajectory Prediction rules
Edition: 2.6
Working Draft
Page 53
Services Provided
Flight Information
Provide the relevant flight information to the components or external systems. The content depends on recipient and distribution is monitored by the flight manager.
Air Traffic Flow Manager Airport Operator Airport Operator Employee Arrival Manager Controller Workstation Manager Correlation Manager Departure Manager Flight Manager Flight Operations HMI Load State Manager Medium-Term Conflict Manager
Flight Plan Creation
Create new flight plans based on information provided by a controller or IFPS or by an adjacent unit. Collect and monitor the ATC constraints (ATFM, Strategic or Tactical) placed on a flight. Provide the trajectory of a flight based on the flight script or possibly following a set of what-if constraints (tentative trajectory). For Ground/Ground communications, ensure the correct distribution of flight related information: - internally for Flight Manager services; - on behalf of external or internal components: identify recipients and trigger distribution at the correct time (e.g. co-ordination information to an adjacent unit).
Aircraft Operator Employee Controller Workstation Manager Controller Workstation Manager
Constraint
Trajectory
Surveillance Flight Deck Displays Controller Workstation Manager Controller Workstation Manager
Distribution
ICAO Flight Plan Management 5.12.3
Support the creation, modification and deletion of ICAO flight plans.
Aircraft Operator Aircraft Operator Employee
DAP Manager The DAP Manager is responsible for managing the timely access to Downlinked Aircraft Parameters (DAP). It collects and maintains the navigation state vector and other relevant aircraft attributes.
Page 54
Working Draft
Edition: 2.6
Services Provided
Airborne Parameters
Provide navigation state vector & other aircraft attributes.
Air Surveillance Data Processing and Distribution Ground Surveillance Data Processing and Distribution Flight Manager
5.12.4
Configuration Manager
Responsibility
The Configuration Manager is responsible for: - keeping track of the actual airspace configurations of all ATC Units (including the current status of conditional routes and the current sectorisations); - keeping track of aerodrome configuration planning; and - providing demand/capacity figures in order to help ATC Supervisor or Flow Manager in organising aerodrome or sectors.

- Sector configuration: new / planned grouping of sectors - Aerodrome configuration - Sector loading - Load statistics
Services Provided
Traffic Load
Indicate the actual and expected traffic load following the planned sector configuration or a 'what-if' configuration. Maintain and provide current/planned sectorisation schemes to be applied. Monitor the choice of a future configuration based on a set of predefined schemes. NB: in a typical implementation, the sector configuration is managed by the FDP.
ATC Supervisor
Sector Configuration
ATC Supervisor Environment Manager
Edition: 2.6
Working Draft
Page 55
Service
Description
Provided To
Aerodrome Configuration
Maintain and provide current/planned aerodrome configuration to be applied. Monitor the choice of a future configuration based on a set of predefined schemes.
ATC Supervisor Environment Manager
Workload
Provide the actual and expected controller position workload following the planned sector configuration or a 'what-if' configuration
ATC Supervisor
5.12.5
Environment Manager The design of this component will have to take into account that there are two significantly different contexts for this component: - Data management: data results from AIP, AIC, NOTAM, LoA - Data access services invocation: the components dependent upon Environment Manager should only see consistent environment data. For this reason the concept of Work Package, that extends the technical database transaction concept, should be supported. It should be realised that this component is of crucial importance for the performance of its dependent components, as most processing depends on Environment Services.
Responsibility
The Environment Manager manages and distributes (static and dynamic) Environment Data. In particular, it is responsible for keeping track of all aeronautical and meteorological information as well as predefined sectorisation options.
Services Provided
Geography
Provide maps, geographical information for terrain, obstacles.
Aircraft Operator Employee Flight Manager Controller Workstation Manager
Page 56
Working Draft
Edition: 2.6
Service
Description
Provided To
Airspace
Collect and provide air navigation data, i.e. information on points, routes, airspace areas: - geographical definition, waypoints, navaids; - associated restrictions or strategic constraints; - current/planned status (CRD or TSA opening/closing times); - applicable capacity (?). Provide also information on air navigation system configuration.
Environment Data Service Provider Aircraft Operator Employee Flight Manager Controller Workstation Manager
Aerodrome
Collect and provide information on aerodrome: - runway lat-long, threshold; - runway in use (current / planned); - applicable capacities; - stand / parking / taxi routes.
Aircraft Operator Employee Flight Manager Controller Workstation Manager
Sector
Provide information on sectors in an ATC Unit: - geographical definition (AoR, AoI); - predefined schemes for sectorisation; - applicable capacity. NB: the current/planned sector configuration is provided by the Configuration Manager.
Flight Manager
Meteo A/C Performances 5.12.6 HMI
Collect and provide meteo information. Provide aircraft performance data (model per aircraft type).
Flight Manager Controller Workstation Manager Flight Manager
The goal is to define a cross-domain component that encompasses both ATC and ATFM HMIs. There is a open question as to whether it should also cover the Aircraft HMI.
Services Provided
Display
Airport Operator Employee lnfrastructure Manager
Edition: 2.6
Working Draft
Page 57
5.13
Horizontal Components Distributed Systems Services
Communications and Middleware

The overall architecture must accommodate the geographic distribution of both function and information, but maintain the appearance of location transparency to the user. The Users view is of one seamless system. This is achieved through the use of standard software, termed middleware, which acts as the socket into which the components are plugged, and by an underlying layer of communications services. Communications information provides the services for the reliable transport of
Middleware is primarily a management layer, and is responsible for: Distribution of information and events. Many ATM applications are driven by changes to the state of information or events. These can be quasi real time, such as flight plan or trajectory changes, or more static, such as MET forecasts. This service publishes such information to those users (applications) that have subscribed to the particular service. Managing the life cycle of components. May be dynamically created or removed. Provision of a single interface for component storage and access. Managing the internal systems processes. Directory - allows components to locate other components (locally or remotely) by name, Security etc.).
Other services (accounting, trading etc.) may be required in the future. 5.13.1 Communications Management Services Communications is considered as a horizontal service, used by all components that require to exchange information (data or events). Two common components are defined: Fixed (Ground) Communications Manager; Mobile Communications Manager.
The communications components collaborate to provide a seamless end to end transmission service. Communications as defined here, represent the lower four layers of the ISO reference model, from the physical service layer through to the transport layer. Volume 3 of the Communication Strategy9 contains an outline of the possible communication architecture for ground and air/ground systems. This strategy covers three timeframes: current; up to 2005; and 2005 to 2015.
9
COM.ET.ST00-STR-01-00 Vol. 3 background.
Page 58
Working Draft
Edition: 2.6
5.13.1.1
Fixed (Ground) Communications Manager
Responsibility
Responsible for the end to end transport of information across the fixed (ground) communications infrastructure, according to required communications performance (Quality of Service requirements) and traffic characteristics, defined by the application. These may include reliability, integrity and security targets.
Services Provided
Service Network Selection Description To
Select transport and underlying network and subnetwork to achieve required quality of service. This will also determine routing and depending upon the network selection criteria and routing policy in operation. This service can be provided either explicitly (by the calling component requesting the use of a specific network service e.g. ATN) or implicitly by requesting a specific service quality.
System Management
Provides a range of network-related services:

Security; Directory; Network service management (service quality management and monitoring); links to upper layer (middleware/distributed system) services.
Send (request verify receipt) Receive (verify receipt)
Delivery of a message. Provides an option of guaranteed end to end delivery. Receipt of a message. Provides an option of guaranteed end to end delivery.
Dependencies
This component depends upon the availability and characteristics of the underlying sub-networks (asynchronous transfer mode, frame relay, LAN, etc). Upper layer (middleware) services are responsible for managing the exchange of information (messaging, files, signalling) between components.

Address (list) Quality of service parameters
Edition: 2.6
Working Draft
Page 59
5.13.1.2
Mobile Communications Manager
Responsibility
Provides communications services between mobile (air and surface movement) and fixed (ground based) components, according to required communications performance (Quality of Service requirements) and traffic characteristics, defined by the application. These may include reliability, integrity and security targets. It manages all Air/Ground communications (selection of the appropriate communication channel, establishing and terminating sessions, routing messages to the proper destinations). Also provides communications services air air for broadcast/data acquisition. Both voice and data traffic is supported. The manager is responsible for ensuring the separation of messages and routing traffic to multiple destinations (ATC, AOC, APC, Airport etc). This is achieved for air/ground datalink traffic by use of the services provided by the Aeronautical Telecommunication Network (ATN). Both ATN and non-ATN legacy services will be supported during the transition phase.
Services Provided
Service Network Selection Description To
Select transport and underlying network and subnetwork to achieve required quality of service. This will also determine routing and depend upon the network selection criteria and routing policy in operation. Provides a range of network-related services:
Security; Directory; Network service management (service quality management and monitoring); Fault reporting and service maintenance management; links to upper layer (middleware) services.
System management
Send (request verify receipt)
Delivery of a message. Provides options: guaranteed end to end delivery (typically this is a function of ATN); can provide certified delivery according to ICAO standards. Delivery of a message. Provides options: guaranteed end to end delivery (typically this is a function of ATN); can provide certified delivery according to ICAO standards.
Receive (verify receipt)
Page 60
Working Draft
Edition: 2.6
Service Dialog Management
Description
To
On request, tracks voice/data sessions between air and ground to ensure simultaneous handover.
Pilot/ controller (Automated within the air/ground comms server and avionics components) Pilot; other ground based Actors
Broadcast/ Multicast
Information distribution service (voice or data). Example uses of this service is the broadcast of: identification/position information; and status information (AIS/MET).
Dependencies
This component depends upon the availability and characteristics of the underlying sub-networks (Satcom, Mode S, VHF (VDL mode2, ACARS), GATELINK (wireless LAN), analogue voice, digital voice. Upper layer (middleware) services are responsible for managing the exchange of information (messaging, files, signalling) between components. Flight manager: to obtain flight information (Posting List)

Requested services, services in progress per flight Address (list) Quality of service parameters 5.13.1.3 Component instances Communications is a horizontal service, used by both locally and remotely connected components. The Communications Managers will be instantiated in systems that have a requirement to communicate, locally or remotely, either with instances of themselves (for example, interconnection of two or more Flight Managers) or between unlike components. 5.13.2 Distributed System (Middleware) services Work in progress The overall architecture must accommodate the geographic distribution of both function and information, but maintain the appearance of location transparency to the user. The client's view is of one seamless system of systems. The enabler for this is a set of cross-domain services that provide and manage the connection between components the distributed system services. Under this heading we provide some general architecture information concerning the collaboration between components.
Edition: 2.6
Working Draft
Page 61
Middleware includes a set of horizontal services that provide the following: Life cycle services defines operations for creating, moving, copying and deleting components. Naming services - allows components to locate other components (locally or remotely) by name. Persistence services provides a single interface for component storage. Event service - to permit components to request or be notified of events. Transaction service an update management service (two phase commit) to allow for recover/ back out of changes. Concurrency control service - provides a means for locking the transaction state or associated data during update.
5.13.2.1
Distribution Management Consider change to distribution management - also add section for component management. Also need a placeholder for real time management.
5.13.2.1.1 Message Management In general, all systems receive, process and distribute messages. Some common working practices: all incoming messages shall be logged, with the time stamp of reception and sender information (who, network, etc.); all outgoing messages shall be logged, with the time stamp of sending and addressee information (address, network, etc.); the parsing of the messages (support of different syntaxes) shall be separated from the business functions (behavioural knowledge).
It is common practice to have in systems a Message Router to organise the intra-component processing of messages. This Message Router is also responsible for avoiding loss of messages. 5.13.2.1.2 Information management Placeholder for management of distributed information. Part will occur in component services (i.e. here) - with a corresponding section under Information Architecture (in Principles). The success of the future ATM systems is contingent upon the accessibility and management of information. This has been borne out by
Page 62
Working Draft
Edition: 2.6
the analysis of the architectures. However, in many cases, the ownership and distribution of information involves multiple actors. requirements eventually derived from the System-Wide Information Management strategy (SWIM). 5.13.2.1.3 Transaction Management 5.13.2.1.4 Event Management Most systems will have to support internal time-out events. Examples Flight Manager shall distribute IFPL messages at well-defined times before EOBT, depending on the preferences of the addressees.
Technically it is proposed to define a generic Event Manager, that implements time-out event management. 5.13.2.2 Component Management TBD- Internal services for the management of components - Life cycle and persistence services etc. 5.13.2.3 Systems Management Responsible for managing the internal processes. This includes component dependencies the association and disassociation of components It is generally assumed that the so-called Observer (or publish-subscribe) pattern is used to organise the dependencies between components. More concretely, when one component changes state, all its dependants are notified and updated accordingly. The advantage of this is that the application of this pattern allows minimisation of coupling of components, and hence stimulates re-use. Technically: Subject - provides an interface to register and de-register observers. Observer - provides an interface for objects that should be notified of changes in a subject.
Edition: 2.6
Working Draft
Page 63
5.13.2.3.1 Access Manager
Responsibility
This technical component is responsible for the management of security services10 (i.e. confidentiality, integrity and accountability). the user access. More concretely, it is responsible for: Identification and Authentication (Login) Authorisation and Access Control Security Auditing Security of communications Non-repudiation Administration of security information
Services Provided
Service login () Description To
Tasks:
Identification and authentication of the client Checking for password expiry Ability to change password during the logon stage Apply special password rules Supporting active, suspended and revoked user states
In this security solution the logon parameters have the meaning as described below:
user_name user_password getProfile ()
Each component has a set of associated operations, which a client could theoretically invoke. The clients need to know after logon which components its user has access to and which operations within those components they have access to. This knowledge is required to allow the client process to tailor its menus, toolbars, etc. depending on what type of user has logged on.
10
See CORBA Security Services Specification, v1.5 May 2000
Page 64
Working Draft
Edition: 2.6
5.14
Data Dictionary
The tables below present the data dictionary associated with the architecture.
5.14.1
Object
Flight Related Data

Definition / Content Comments Owner
FPL Filed Flight Plan
Standardised by ICAO Validated by IFPS Used as common reference Stable, but not necessarily unique
Validation not yet perfect (validation is against environment data, but the different units do not have a consistent view on environment data) Routes are generally represented as a series of points
Flight Manager
SFPL System Flight Plan also called GS - FPL Ground System FPL Assigned SSR Code Constraint
FPL converted to internal FDPS representation and (re-)validated; relevant part of route extracted and expanded; stable and unique
Flight Manager
Flight Manager ATFM Constraints Strategic Constraint: Climb/Descent Profile, RVSM, LoAs based on AIPs, NOTAMs Open or closed Tactical Constraint Strategic constraints may be overruled by tactical constraints Flight Manager
Flight Script
Combination of flight plan and constraints data Before activation: describes all strategic constraints (RWY, SID, STAR, LoA constraints on transfer conditions) that are applicable to this flight; stable ATFM departure slot goes here At activation: + assigned SSR code After activation: + all tactical constraints (level, heading, speed instructions)
Allows the planned trajectory to be calculated Allows life cycle management as well as flight data distribution to be initiated and performed
Flight Manager
Allows correlation with surveillance data Allows the planned trajectory to be updated Allows the predicted trajectory to be calculated Flight Manager Flight Manager
Filed Trajectory Regulated Trajectory
(ATFM) (ATFM)
Edition: 2.6
Working Draft
Page 65
Object
Definition / Content
Comments
Owner
Planned Trajectory
Describes the 4D profile of the flight, based on the plan and confirmed deviations from the plan (relatively stable) Describes the 4D profile of the flight, based on the plan and all deviations from the plan (relatively unstable)
This trajectory represents the baseline for conformance monitoring Used for flight data distribution This trajectory represents the most accurate view of the trajectory in the near future Used for ATC tools (Note: For flights in the area of interest, but not yet in the area of responsibility, only planned trajectories exist. ATC tools therefore do not perform well close to centre boundaries. This must be resolved by enhanced interoperability.) When / Where flight information shall be provided, derived from the trajectory and the set of crossed sectors confirmed by a controller Allows simulation of the effect of an input
Flight Manager
Predicted Trajectory
Flight Manager
Posting List
Per flight: list of flight information addressees
Flight Manager
Proposed Constraint What-if
Advisory, Pilot Request Dummy flight script and trajectories for envisaged new tactical constraint Relationship data between Track (ID, Position, SSR Code, 24-bit aircraft address) and Flight Plan + Assigned SSR Code Per flight: data link status, registered AGDL services, dialog in progress Per flight: co-ordination conditions, transfer status
Flight Manager Flight Manager
Correlation Information
Correlation Manager
AGDL Information
Comms Manager Controller Workstation Manager
Co-ordination Information
Page 66
Working Draft
Edition: 2.6
5.14.2
Object
Aircraft Related Data

Definition Comments Owner
Aircraft Equipment
Aircraft Equipment: COM, NAV, approach aid Surveillance Equipment: Mode A/C, Mode S
Avionics
Aircraft Performances
Cruising Speed, Climb/Descent speed, Climb/Descent rate RVSM Position: 2D or 3D + timestamp SSR Code, 24-bit-aircraft address Vector: ground speed, heading, vertical rate
Environment Manager
State Vector
Surveillance
Navigation State Vector
selected FL, selected heading, selected air speed, roll angle, track angle rate
Avionics, distributed by DAP Manager
5.14.3
Object
Environmental Data
Definition Comments Owner
Geography Aerodrome
geographical maps, terrain and obstacles - runways lat-long, threshold - stands / parkings / taxi routes - predefined configurations - actual configuration: runways in use, applicable capacities
Environment Manager Environment Manager
Configuration Manager Predefined: AoR, TSA, ATS Routes, SID, STAR CDR Environment Manager (for capacities)
Airspace Data
Points, Routes, Airspace areas : - geographical definition, waypoints, navaids - predefined configuration - associated restrictions - applicable capacity - actual configuration: status of TSA, CDRs
Edition: 2.6
Working Draft
Page 67
Object
Definition
Comments
Owner
Sector
- geographical definition - predefined sectorisation and options: sector groupings, capacities - actual configuration: current/planned sector groupings
Environment Manager
External service
Meteo Data
Wind direction, Wind speed, Temperature, QNH/QFE
Page 68
Working Draft
Edition: 2.6
6.
SCENARIOS
Include the Gate-to-Gate model phase of flight illustration here. Summary of the 2010 scenario here. Tables to be included in the Annex. Process: there is a need for greater formality in the future. From the major operational concepts- develop Use Cases- and write scenarios (normal/ abnormal/ alternative) See RUP (Rational Unified Process) for possible process guidelines.
6.1
Commercial IFR Flight 2010 Scenario

The Flight is: an IFR commercial flight, belonging to a large airline; equipped with FMS, 4-D flight capability, ACAS and Datalink; operating in Managed Airspace; during normal weather conditions.
The Airports are:

Departure Arrival
large, high-complexity equipped with datalink equipped with SMS, AMS and DMS capable of all-weather operations situated in a TMA
large, high-complexity equipped with datalink equipped with SMS, AMS and DMS capable of all-weather operations situated in a TMA
6.1.1
Planning Overview Planning will be a seasonal, CDM process in which aeronautical, meteorological, capacity constraint data, etc., will be collected and analysed so as to produce an accurate picture of the demands and constraints that will affect European airspace. This will begin up to two years or more before the day of operations. A series of optimised airspace structure and forecast traffic models in the form of Operations Plans for the entire usable European airspace will be created, in which the allocation of European airspace will be balanced between the needs of Commercial, General and Military aviation and other users. The civil airspace will be assigned as MAS11 (in which the future ATM network will provide the majority of its services), FFAS and UMAS. These planning processes will be divided into 2 major processes:
11
MAS = Managed Airspace, UMAS = Unmanaged Airspace; FFAS = Free Flight Airspace
Edition: 2.6
Working Draft
Page 69
Strategic Planning - involving the long-term activities to produce a coordinated Strategic Plan of demand and capacity one year in advance. In strategic planning scenarios are defined for expected demand and decision must be taken how to cope with that demand. It means simulating the effect of additional resources like e.g. airways, airports, runways and sectors etc. Tactical Planning - in tactical planning resources are basically fixed and they must be used as efficiently as possible to cope with the actual demand. Basically fixed could mean that e.g. certain CDRs are activated if needed and if agreed with the military or a different scheme for sectorisation is used. It means pre-planned use of known and available resources, it does not mean building an additional runway overnight and it does not mean inventing completely new routes. Tactical planning has two main sub-processes: Pre-tactical Planning - involving the creation of the co-ordinated Tactical Plan from one year in advance to one day before. Tactical Flow Planning - involving final modifications to the plan within 24 hours of the time of operation of the flight.
To a large extent, airspace use and airport use for arrivals is not subject to advance reservation and limitation. Queuing is a logical consequence of free access to a resource with finite capacity. For example, one could say that travelling by urban bus or taxi is a free access process, subject to queuing. Conversely, travelling by High Speed Train or Aircraft is restricted by prior mandatory reservation. It is fundamental to recognise that airspace and airports are a scarce resource and ought to be subject to mandatory reservation (from Mr. Y. Lambert - see section 8).
The tactical planning process will take this into account by applying general planning principles, applied successfully in other application domains, known as Just in Time and Bottleneck Scheduling.
Just In Time
In this context Just in Time or JIT means, that an aircraft only is allowed to depart, if: the departure slot is allocated and all sectors on the route and the airport of arrival12 can handle the load.
To save fuel, reservation of capacity is performed prior to departure and the departure will be performed as late as possible to meet all prior reservations.
Bottleneck Scheduling
Bottleneck scheduling means that:
12
Note that it implies some form of arrival slot allocation, see also PRC Report.
Page 70
Working Draft
Edition: 2.6
Tactical planning should optimise the use of bottlenecks in advance, high priority should be given to the reservations for traffic between city pairs giving the largest delays. For those airports the balance between departures and arrivals is critical. Which sectors13 and airports are bottlenecks becomes perfectly clear from the reports of the Performance Review Commission. In real life no planning is exactly executed as expected, external disturbance will cause deviations from the plan. All kind of measures are foreseen to minimise it, but it is unrealistic to expect that the effects of all external events can be neutralised. To make sure that the loading of the bottleneck remains at 100%, some flexibility is required. Airlines solve the problem for their seat reservation through the use of a waiting list, limited in size, sometimes supplemented by a sophisticated yield management systems. Tactical planning should solve the imperfection of the planning by introducing; a small queue for arriving aircraft (limited size, size managed by the CFMU) and a small queue for departing aircraft (limited size, size managed by the airport).
These queues are only required for bottleneck airports during busy hours, but it is needed to avoid the loss of a slot, which would otherwise result in reduced capacity and increased delay for all flights during the remainder of the busy period. The size of the queue is a co-operative trade-off between: costs (fuel, aircraft turn around) and annoyance (missed connecting flights) caused by delays and costs (fuel) associated with the queuing time.
Better real time control, improved co-operation and air/ground data link can permit a shift to of more sophisticated holding techniques, such as on-line holding (speed control).14 Flights are currently planned in four de-coupled phases: a) Departure Taxi or Taxi Out Phase, from gate through departure queue to runway, which can be managed based on the subsidiary principles by Airport Ground Traffic Control. Any taxi delay of a particular aircraft will be neutralised by taking the next aircraft in the runway queue (FIFO by nature). The result is that e.g. 3 flights take off 1 slot early, while one flight
13
Airports have often real physical constraints caused by the limited capacity of their runways, while bottleneck sectors are a consequence of certain organisational decisions. It is expected that another organisation of sectors (e.g. cross boundary, along routes etc.) still can increase capacity. This area of the scenario requires further study in conjunction with operational staff.
14
Edition: 2.6
Working Draft
Page 71
takes off 3 slots late, but no capacity has been lost and after 4 flights the situation is back to plan15. b) Departure and En-Route Phases, from departure runway to arrival queue, which requires co-operation (feed back) between tactical planning and execution control. Procedures and tooling for in flight absorption of delays for flights to bottleneck16 airports and sectors will improve the results of the overall planning process and reduce the need for capacity safety margins. Arrival Phase, from arrival queue to runway, which requires the automated support of a local real time arrival manager (bottleneck scheduler). Arrival Taxi or Taxi In Phase, from runway to gate, which can be managed based on the subsidiary principles by Airport Ground Traffic Control. Local taxi problems have no influence on other flights in Europe. However Taxi In delay might result in the departure delay for the next flight of that aircraft.
c)
d)
Turn around of aircraft (departure delay due to late arrival of the incoming aircraft) will not be considered in the planning process, the aircraft operator knowing the (expected) arrival delay of an incoming flight has a number of options to deal with the situation, the aircraft operator could: speed up the ground handling of the aircraft; decide to use an alternative aircraft; or transfer the passengers to another flight.
If those measures are not possible or economically feasible, the delay of the flight should be made known to the tactical planning as early as possible, in order to be able to get the best possible departure slot. Only the aircraft operator can make the decisions required during aircraft turnaround, tactical planning only assists the delayed arriving aircraft in getting the best possible departure slot. The following diagram shows the relation between the planning process and the flight phases.
15
Aircraft should depart (start the take off) on time. If departures are late, en-route sectors might get overloaded, which might result in increased capacity safety margins for the busy sectors. The less deviations from estimated times, the less safety margin is required. The PRC claims that a 10% increase in safety margin can generate 50% more delay. Note that from a delay point of view only flights involving capacity bottlenecks require in flight absorption of delays. Flights crossing bottleneck sectors should enter the bottleneck sector on the estimated time to allow smaller safety margins for that sector.
16
Page 72
Working Draft
Edition: 2.6
Planning Levels
Political Constraints
Traffic Forecasts
Strategic Planning
(Plan Airspace (& Infrastructures))
Capacity Constraints FPL, including larger (In-flight) Changes Flow Regulated Flights
Delays
Tactical Planning
(Manage Available Capacity) (Match Demand and Capacity) Trajectory Changes & Actual Times
Co-ordination
(De-conflict Flights) (Maintain Plan Flow Critical Flights) Pilot Trajectory Change Requests
Sector Planning
De-conflicted Flights
Transfer of Control
Sector Control
(Maintain Separation) (Communicate with Pilot)
Pre-Departure
Taxi-Out
Departure En-Route
Arrival
Taxi-In
Post Flight
Flight Phases & Time
6.1.2 Strategic Planning Process The current version of the architecture document does address this aspect. 6.1.3 6.1.3.1 Tactical Planning Process Pre-Tactical Planning Phase The following resource related information will be known at the start of the pretactical phase: Airport Slot Ownership per Airline and reserve capacity if available; Airspace Structure; Anticipated Restricted Area Planning with anticipated Corresponding Conditional Route availability; Sector Configuration Plan including Sector Capacity; and Average weather conditions (needed for the trajectory calculation) to be used for each month.
The actual demand will initially be based on the same day in the previous period (e.g. same day of previous week(s) or the same day in the previous season).
Edition: 2.6
Working Draft
Page 73
Subject
Action
17
Object
Object
18
1 1.1
Pre-Tactical Planning
Flow Manager
optimises
Airport Loading
while
balancing Departures and Arrivals during busy hours
1.2
Flow Manager
optimises
19
Sector Loading
1.3
Flow Manager
calculates
Optimal Departure & Arrival Slot Allocation Plan Optimal Sector Configuration Plan Airspace Structure Sector Configuration Plan Slot Departure & Arrival Allocation Plan Airline (AOC), other Aircraft Operator and ATC Airline (AOC), other Aircraft Operator and ATC
for
approval by the airport .
1.4
Flow Manager
calculates
for
approval by the Supervisor
2 2.1
Reaction to Tactical Planning (Capacity adapted to Demand)
AFTMC
Adapts
with respect to based on
CDR availability
2.2
Flow Management Position and Supervisor Airport Operator
modify
the proposal from the flow manager
2.3
modifies
based on
the proposal from the flow manager
3 3.1
5 Reaction to Tactical Planning (Demand adapted to Capacity)

Flow Manager notifies about Flow regulation
3.2
Flow Manager
informs
about
Issues related to the traffic flow
6.1.3.2
Tactical Planning Phase The plans developed in the Pre-Tactical Phase are refined and detailed as specified in the following table.
17
Rules and algorithms to be defined by the component. In its simplest form it adds up all requests. More advanced, it will automatically re-schedule the flight based on agreed rules and known slot ownership See section 2 Rules and algorithms to be defined by the component
18 19
Page 74
Working Draft
Edition: 2.6
Subject Infrastructure Data
Action
Object
Object
1 1.1
AFTMC
provides
Restricted Area Planning weather conditions needed for the trajectory calculation FPL or Air Filed Flight plan (AFIL)
with
Corresponding Conditional Route availability
1.2
Met Office
provides
2 2.1
FPL Input
Airline (AOC) or other Aircraft Operator

Tactical Planning
creates
3 3.1
Flow Manager
periodically 20 optimises
Airport Loading
while
Balancing Departures and Arrivals during busy hours
3.2
Flow Manager
periodically optimises
Sector Loading
3.3
Flow Manager
proposes
Optimal Airport Slot Allocation Plan
for
approval by the airport for each bottleneck airport per busy hour approval by the Supervisor for each bottleneck sector per busy hour
3.4
Flow Manager
publishes
Optimal Sector Configuration Plan
for
4 4.1
Reaction to Tactical Planning (Capacity adapted to Demand)
Flow manager
modifies
Capacity reservation Airspace Structure
for
Non Scheduled FPLs based on current and expected demand CDR availability
4.2
AFTMC
Adapts
with respect to based on based
4.3
Flow management Position and Supervisor Airport Operator
modify
Sector Configuration Plan Airport Slot
the proposal from the flow manager the proposal from the
4.4
modifies
20
Note that for this phase the FPL will be updated automatically for flights, which have entered the ECAC Airspace, based of re-estimated times received from the FDP or based on position data from the RDP.
Edition: 2.6
Working Draft
Page 75
Subject
Action
Object
Object
Allocation Plan
on about
flow manager Each filed FPL with respect to estimated times & delays and the capacity bottlenecks causing the delay. Alternative routes for delayed FPLs.
5 5.1
Reaction to Tactical Planning (FPL related, Demand adapted to Capacity)
Flow Manager
notifies
5.2
Flow Manager
notifies
Airline (AOC) or other Aircraft Operator FPL

21
about
5.3
modifies or cancels
6.1.4 6.1.4.1
# Subject
Sector Planning and Sector Control Pre-departure Phase

Action Object Object
1 1.1 1.2
Planning: Briefing the pilot
Pilot Pilot
checks checks
Weather Forecast The flow regulation and the CDRs in Operation The start-up time The FPL FPL modification
as as
provided by the AOC provided by the AOC
1.3 1.4 2 2.1
Pilot Pilot Pilot
checks, or modifies checks, might initiate
after
Consultation with Airport ATC
Tactical re-planning
through
preferably the AOC
21
Airlines have the need sometimes to swap departure or arrival slots, dependent on their current business priorities. The same might be true for reservations at bottleneck sectors. By modifying both FPLs that effect can be achieved, however the emptied slot could be assigned to another flight before the second FPL has been modified. The algorithms determining slot allocations should support these types of slot swaps in a transparent way without giving way for misuse.
Page 76
Working Draft
Edition: 2.6
Subject Planning: Cockpit
Action
Object
Object
3 3.1
Pilot
transfers
the operational flight plan
from
the AOC to the Aircraft FMS Flight Plan (AF-FPL) based on an agreed, existing? Interface
3.2
Pilot
transfers
Weather Forecast
to
the aircraft based on an agreed, existing? Interface (printed copy?) manual input in FMS? Pre-departure Clearance containing Mode 3/A 22 code , Runway, SID and weather.
4 4.1
Control
The ATC system
provides
the pilot and the flow manager
with
6.1.4.2
Departure Taxi or Taxi Out Phase During the pre-departure phase the pilot will receive taxi instructions. How those instruction will be issued is a local responsibility. Possible solution include: use of taxiway lighting to illuminate the way ahead based on the known aircraft position; printed copy of the taxi route or taxi plan; electronic copies downloaded in the aircraft of the taxi plan; aircraft/vehicle navigation system comparable to e.g. existing car navigation systems.
Airport ATC will propose the start-up time to the pilot, based on local knowledge and taking into account the time needed for taxiing and the time in the runway queue. As today, ground controllers will be responsible for ensuring that flights can get to the runway in time. Controllers will have data on aircraft positions and intentions and on airport hazards as well as warning information on adverse weather and low visibility conditions. This data will be used: firstly, by controllers, filtered for their specific use, to maintain a picture of all aircraft movements;
22
The mode-3/A codes will be assigned based on the current ORCAM Method for all flights. A separate block of codes will be reserved for aircraft capable of transmitting 24-bit address. Codes from that code block will be treated by other centres as conspigueity codes
Edition: 2.6
Working Draft
Page 77
secondly by the ground service agencies units to organise their traffic, ensuring that ground vehicles and re-positioning aircraft remain clear of active flights; thirdly, by the pilot to remain clear from other traffic, see Note 1.
Note 1
The transfer of the airport situation picture to the aircraft, introduces an additional interface with aircraft avionics, the potential benefits are related to safety on the ground and taxi time precision, which would result during busy hours in maybe one or more minutes less fuel consumption on the ground. The interface would require a world wide ICAO standard. It is recommended not to mandate this requirement unless its cost benefits can be proven compared to other more conventional solutions (ground collision alert system, dynamic taxi way lighting and/or traffic lights, etc.).
At the appointed time they start up, push-back and start to taxi along routes that have been designed to minimise and eliminate; runway crossings and conflicts between departure and arrival taxi streams.
The pilot uses the taxi route and/or plan to enable them to arrive at the runway holding point on time.
# Subject Control: Start Up Action Object Object
1 1.1 1.2 1.3 1.4
Pilot Ground Controller ATC System ATC System
requests clears initiates correlates

23
start-up and taxi clearance The flight Ground Track Ground Track
by for
Data link or R/T Start-up and taxiing
with
Ground System Flight Plan (GSFPL) based on track position, Gate Position, EOBT and AOBT Flight Identification if available.
1.5 1.6
Pilot Ground Controller
taxies monitors and guides
The aircraft The aircraft
to during
The Runway Taxiing.
All agencies that are responsible for ground movements on the airport will have the same information on the positions and intentions of controlled aircraft moving between the runways and gates and of their own movements. The controlled aircraft will be the responsibility of Ground controllers and will have priority over all other movements (subject to safety) and the
23
It is assumed that on most airports ADS-B or multilateration system will be in use which will allow to retrieve the 24-bit address.
Page 78
Working Draft
Edition: 2.6
agencies will be responsible for co-ordination with controllers and to ensure that their vehicles and movements remain clear of the flights. 6.1.4.3 Departing flights should have priority over arriving flights during taxiing.
Departure Phase (Take-off)
6.1.4.3.1 Runway sub-phase Aerodrome controllers will have access to the same information pool on aircraft predicted and actual movements as Ground controllers and will have access to SMSs that will enable them to ensure that the runways are clear of any obstacles, vehicles or other aircraft which could hazard flights. On arrival at the holding point the pilot confirm their readiness for take-off (by R/T) with the Aerodrome Controller who, when appropriate, clears them to enter the runway and take-off (probably by R/T).
# Subject Control; Take Off Action object object
1 1.1 1.2 1.3 1.4 1.5
Pilot Pilot Aerodrome Controller ATC System ATC System
changes confirms clears initiates correlates

25
Voice and data channel their arrival the flight Air Track Air Track to GS-FPL based on Mode 3/A code, track position, ETD and ATD Flight Identification if available. at for the runway by data link or R/T runway entry
24
1.6 1.7 1.8 1.9
Pilot Pilot Aerodrome Controller ATC System
taxies confirms clears detects and records confirms proposes
the aircraft their readiness for take-off the flight take-off Take-off Departure Messages
onto by for
the runway Data link or R/T take off
1.10 Pilot 1.11 ATC System

24 25
to
Aerodrome Controller
Aircraft equipped with Mode-3A transponders will switch on the transponder now.
The Track/FPL Correlation for ADS and/or Mode-S areas will be based on down linked Flight Identification for flights, which remain for at least a pre-defined time period in that area.
Edition: 2.6
Working Draft
Page 79
Subject
Action
object
object
with detected ATD
1.12 ATC System 1.13 Aerodrome

Controller
proposes confirms sends guards
Transfer of Control Transfer of Control New RT Frequencies (Voice & Data Link) Acceptance
to to to by
Aerodrome Controller TMA unit Aircraft. TMA unit
1.14 ATC System 1.15 Aerodrome

Controller
2 2.1
Planning: Inform down stream sectors and CFMU
Aerodrome Controller
sends
Departure Message (incl. 24-bit address and ATD)
to
TMA unit, en-route centre, next FIR and CFMU
6.1.4.3.2 Climb sub-phase Perform Track/FPL Correlation based on Mode 3/A code, take off position and comparison of ETD and ATD. Conformance monitoring with respect to the SID for safety reasons (planned separation of inbound and outbound traffic) and for environmental restrictions (noise)26. Deviations from the planned trajectory will be reported to the controller to minimise the hazards. STCA and MSAW will provide real time safety assurance. Note 2
Already today noise budgets are used. Budget overruns will result in limitation of future capacity. Deviations from these type of SIDs and STARs will be less and less tolerated.
Note 3
Especially in busy TMAs the influence of TCAS and STCA on each other and on the actual aircraft behaviour need further analysis, before introducing another level of complexity by adding ground based conflict resolution.
Once instructed to do so, the pilot make contact with a TMA controller who will be responsible for SA for the flight. Note 4
Because the departure route or routing is established beforehand, there is no need for the pilot and controller to communicate with each other under normal conditions. Here, datalink assists both pilot and controller by making it possible for the passing of non time-critical messages to and from the flight to be made via datalink rather than R/T.
26
Exact SID profiles and the Take Off Wight will be required.
Page 80
Working Draft
Edition: 2.6
Subject
Action
object
object
1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
Departure Control (executed for each Approach Controller)
Avionics Pilot Pilot Approach Controller Pilot or Aircraft Approach Controller ATC System Approach Controller ATC System Controller
proposes confirms contacts accepts flies assures guards monitors proposes confirms sends guards watches
New voice and data channels voice and data channels change Approach Controller The transfer of control the SID the separation The adherence The adherence Transfer of Control Transfer of Control New voice and data channels Acceptance of the transfer Acceptance of the transfer
to
pilot
from as with to to to to to from from
Previous controller stored in the FMS other aircraft, the ground and restricted areas 4D SID profile 4D SID profile Approach Controller Next Controller Aircraft. Next Controller Next Controller
1.10 Approach 1.11 ATC System 1.12 ATC System 1.13 Approach
Controller
The pilots maintain their own situational awareness, assisted by ASAS which enables the pilot to be aware of the identity, position and short-term intentions of other flights operating in the airspace and within their area of interest. During climb-out pilots will monitor their flights conformance to its planned trajectory, which is controlled by the FMS. Although the responsibility for SA is with the Terminal controllers, partial delegation of some separation activities may be passed to the pilot. Pilots maintain their own situational awareness and to do this they can be assisted by the ASAS. ASAS will supply data on the position and short-term intentions of all other 'collaborating' flights within the area of interest; data which will be displayed to the pilot via the CDTI. Note 5
ASAS data may be gathered either by air-air data exchange between the flights or by data transmitted to the flight from the ground.
Edition: 2.6
Working Draft
Page 81
Note 6
ASAS will also be used when partial delegation of responsibility for some separation functions (in-trail climb, cross/climb when clear etc.) are transferred to the pilot by the controller.
Note 7
ASAS equipped aircraft will know about all aircraft in their vicinity.
As the flight exits the TMA and enters the En-Route phases, control of the flight and responsibility for separation is transferred to an En-route controller, again silently and with automatic R/T and datalink frequency changes. 6.1.4.4 En-Route Phase Note 8
The rigid route structures of today, that impose permanent constraints on flight operations, will have been improved by optimising them for flight economy and making them semi-dynamically adjustable in response to the differing capacity demands and traffic flow variations during the course of the day. The need to ensure adequate capacity and equity amongst users in areas of high traffic density means however, that there will be constraints on the freedom of flights to optimise their individual trajectories.
Note 9
Free-Routing will be possible when and where the traffic density permits and there is a economic benefit to users. It will be a development of the current practice of allowing flights to take up direct routing when possible. In the ATM network of 2010, by the development of automated support equipment in the air and on the ground, coupled to new procedures and working arrangements in ATM, Free-Routing will be used extensively by operators and will provide significant benefits in flight economy.
Note 10
As the flight proceeds and control is handed-off to different sectors, it may cross one or more national boundaries. However, the transition from the airspace of one State to that of another are transparent to the pilot.
Note 11
The procedures for control of flights will be improved. Flights will still be controlled by Controllers but will be assisted by automated support systems to detect and resolve short-term conflicts and in the monitoring of a flights conformance to its cleared trajectory. The flight finishes its climb-out and levels off at its requested flight level, with the pilot continuing to monitor the flights conformance to the flight plan and maintaining situational awareness.
6.1.4.4.1 Sector Control
Page 82
Working Draft
Edition: 2.6
Subject
Action
object
object
1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
En-Route Sector Control (executed for each Area Controller)
Avionics Pilot Pilot En-Route Controller Pilot En-Route Controller ATC System En-Route Controller ATC System Controller
New voice and data channels the voice and data channels change En-Route Controller The transfer of control the 4D trajectory The separation The adherence The adherence Transfer of Control Transfer of Control New voice and data channels Acceptance Acceptance
to
pilot
from
Previous controller
with to to to to to from from
other aircraft, restricted areas and the ground 4D trajectory 4D trajectory

27
En-Route Controller Next Controller Aircraft. Next Controller Next Controller
28
1.10 En-Route 1.11 ATC System 1.12 ATC System 1.13 En-Route
Controller
QUESTION: CFMU to be informed about hand-over and/or about sector crossing? The flight takes up its cleared, user-preferred trajectory. The flight is still in MAS and responsibility for SA remains with the En-Route controller, while the pilots responsibility will be to ensure that the flight conforms to the agreed trajectory. Under specific circumstances however, the controller may delegate some separation tasks to the pilot (e.g. station-keeping, turn/change levelwhen-clear etc.). 6.1.4.4.2 Sector Planning As the flight progresses, the pilot negotiate any minor deviations to their trajectory (e.g. to avoid adverse weather) with the en-route controller. Longer
27
The flights are classified as critical or non critical, Critical means that the flight is heading towards a bottleneck sector or a bottleneck airport. Critical flight must adhere to their 4D trajectory and the controller should take action to bring the flight back to its original plan. For bottlenecks airports during busy hours the last en-route controller will transfer the aircraft to the controller responsible for the arrival queue (short duration hold), else the transfer will be directly to the approach controller.
28
Edition: 2.6
Working Draft
Page 83
term changes (e.g. those requested by the AOC for company reasons or to avoid extensive bad weather) will need to be agreed between the AOC and the pilot, which happens outside the scope of the CNS/ATM system. Afterwards the pilot will contact the en-route controller and propose the trajectory changes. The proposed changes29 will be granted by the en-route controller if: the FIR exit time and point stays within a pre-defined window of the planned time and position or; the flight is non-critical (no bottlenecks ahead); or the change is made for safety reasons.
In all other cases the change should approved by the Multi Sector Planner and/or Flow Manager. Note 12
Controllers workload might also be eased by the involvement of Multi Sector Planners (MSP), in areas where the density of traffic makes their use necessary. MSPs will use computer support tools (MTCD) to oversee a number of sectors and be responsible for the resolution of medium-term traffic problems, to manage and balance the complexity of traffic flows and so ease the executive controllers workload.. Based on the proposed planning principles it could make sense to organise such function around bottleneck sectors. Those MSP would take over the responsibility of the sector planner and they could have some delegated responsibility from flow management. This function needs 30 more discussion, since first simulations do not show improvement .
6.1.4.5
Arrival Phase Principal aims for arrivals management at a busy airport are to fill the gaps in what could be an irregular arrival sequence and to avoid the bunching of flights. During busy hours this can be done by funnelling flights through an arrival queue (short-duration hold) to smooth out the irregularities and keep delays to a minimum. Flights in the TMA may also have speed constraints imposed and in extreme circumstances may have to enter a holding pattern. In general it is expected that the aircraft will have to fly a STAR, based on the entry point of approach and on the runway to be used. The STAR will conform
29
The CFMU will be informed by an ATC unit in case the deviation from the FPL exceed pre-defined thresholds with respect to FIR Exit Time or FIR Exit point. For critical flights the ATC Unit should always try to get the flight back to the agreed plan. The validation of the TORCH Operational Concept (page 31, first paragraph after the figure) has found that the multi sector planner does not improve the workload of the executive controller, because his work would have been performed by the sector planner otherwise. The multi sector planner does not increase the capacity of the sector.
30
Page 84
Working Draft
Edition: 2.6
to a set of pre-defined patterns, especially for bottleneck airports during busy hours and for airports with formal environmental constraints31.
# Subject Action object object
1 1.1 1.2 1.3 1.4 1.5
Arrival Sector Control (executed for each Approach Controller)
Avionics Pilot Pilot En-Route Controller Pilot
New voice and data channels the voice and data channels change Approach Controller
32
to
pilot
The transfer of control the 4D STAR trajectory The separation The adherence The adherence Transfer of Control Transfer of Control New voice and data channels Acceptance of the transfer Acceptance of the transfer Transfer of Control and Arrival Messages with detected ATA Transfer of Control New voice and data channels
from
Previous controller
1.14 Approach
Controller
with to to to to to from from
other aircraft, restricted areas and the ground 4D STAR trajectory 4D STAR trajectory Next Controller Next Controller Aircraft. Next Controller Next Controller
33
1.6 1.7 1.8 1.9
ATC System Approach Controller ATC System Approach Controller
1.10 ATC System 1.11 ATC System 1.12 Approach

Controller
2 2.1
Control: Transfer to airport ATC Unit
ATC System
proposes
to
Approach Controller
2.2 2.3
Approach Controller ATC System
confirms sends
to to
Airport ATC unit Aircraft.
31
It is expected, that most airports will have formal environmental constraints by 2010, based on e.g. noise measurement and noise budgets. For bottlenecks airports during busy hours the last en-route controller will transfer the aircraft to the controller responsible for the arrival queue (short duration hold), else the transfer will be directly to the approach controller. The last controller of the approach unit will hand over the control to the aerodrome controller
32
33
Edition: 2.6
Working Draft
Page 85
Subject
Action
object
object
2.4 2.5
Approach Controller Aerodrome Controller
guards sends
Acceptance of the transfer Arrival Message (incl. 24-bit address and ATA)
by to
Airport ATC TMA unit, en-route centre, next FIR and CFMU
Note 13
The methods of control and situational awareness for the pilot are the same as those in the Departure phase. However, a principal aim for arrival management where traffic density is not a problem is to grant as much freedom of operation as possible to the user. If the traffic level is low or if there are no environmental constraints, there is no need to restrict aircraft trajectories except to ensure separation from other traffic or reserved airspace
When appropriate, the flight begins descent in the initial stage of the approach. As in the climb-out, the pilot monitor and confirm that the aircrafts FMS is guiding the flight in conformance with its planned trajectory, is assisted by ASAS to maintain their situational awareness and ACAS as a safety-net. At higher traffic levels a Terminal Controller would be responsible for SA but could, as described before, delegate to the pilot the task to provide selfseparation from other traffic. Note 14
Once an arrival time for the flight has been established, the Ground controller, notified of the flights arrival, uses the SMS (which is linked to the AMS and En-route system) to determine the optimum taxi route for the aircraft to its gate.
As flights approach their destination the ATM system (using D-FIS) will up-link the latest weather actuals, the agreed time, position and flight conditions for the initial approach fix (level, heading, speed) and details of areas to be avoided in the approach. The controllers task will be similar to that for departures, using conflict detection and resolution and conformance monitoring systems to assist them. Note 15
The ATC System has updates on the progress of flights and, at the appropriate time, starts to assess the impact of a flights approach on the established arrival sequence and to formulate how to integrate it in order to ensure optimal use of runway and airport capacity. Using its knowledge of the flights performance capabilities and preferences contained in the flight plan and the known position and intentions of the flight, it formulates a 4-D trajectory for descent and approach for the flight in which its aim is optimising the top of descent, whilst planning a trajectory that will mean that the flight achieves its planned landing slot time.
Note 16
The Arrival Management System (AMS) will act in co-operation with the Departure Management System to fine tune the relative priorities of arriving and departing flights based on the balance defined by the tactical planning. As well as data on all flights in the TMA, the AMS will also receive timely and accurate data on the weather (from weather
Page 86
Working Draft
Edition: 2.6
forecasts, aircraft now-casts or ground-based weather radar) and so the controllers will be able to adjust the route structure in response to weather conditions before, rather than when, they become a problem.
6.1.4.6
Arrival Taxi or Taxi In Phase Once an arrival time for the flight has been established, the SMS determines the optimum taxi route for the aircraft to its gate. While a flight is in the approach and landing phase, the SMS will plan the most appropriate taxi-plan to take the flight to its gate. One problem that could arise is that an aircraft capable of landing in low visibility might not have the on-board capability to taxi to its gate. In these circumstances the Tower controller will have the facilities of SMS to guide the flight to its gate. The flight completes its approach and landing on the runway. The Ground controller, using SMS, confirms or modifies the taxi plan for the flight. Taxi from the runway to the gate is the same process as that described for the ground departure phase. Using ground-based detection systems on and around the airport, the controller can monitor and guide an aircraft to its destination and transmit its pseudo position to the displays of equipped aircraft and ground vehicles. In this way the controllers problems are eased since it is only necessary to be concerned with detailed assistance and guidance to the non-equipped aircraft. With these automated tools, the controller can monitor all airport traffic and ensure that they conform to the clearances given and provide assistance and guidance if needed.
6.1.4.7
Post-Flight Phase Our flight has reached its gate, the engines spooled down, passengers and pilot departed and the ground services now ready the aircraft for its next flight. But that is not the end of the involvement of the future ATM network. Firstly, the data from the flight are collated with all other data concerning it (e.g. from the AOC, Flow Management, ATC) in order to be able to provide a comprehensive and authoritative source of data on all completed flights. This data will be accessed by the States, service providers and airspace users for a number of reasons. The principal aims are to: keep a legal record of the flight for the required time; provide data for an integrated, consistent, accurate and efficient navigation charging system; confirm that any Quality Service Plans were satisfactorily achieved, or to identify any shortfalls or problems; analyse flight and performance data in order to improve the operation of the ATM network in the future, with due regard to the protection of confidential data.
Edition: 2.6
Working Draft
Page 87
6.2
Changes and Assumptions to Meet 2010 Scenario

Summarises the changes to the Strawman architecture. Refer to the ISSUES section in the management overview. Note that the ISSUES section has not been duplicated in the Strawman, as the work on the Overview document identified many of the issues, they were kept in the same document. May provide this as a table (Ref. B Nijhof's tables). Note the interpretation phases of flight (in particular pre-tactical) need to be made consistent. Interfaces/interop initially in the diagram cross reference table and specific details to be added that summarise the interoperability needs summarising the information exchange (CRUD) needs.
Page 88
Working Draft
Edition: 2.6
Appendices
7. ARCHITECTURE SOURCES
There are several significant current architecture initiatives which have been used to define the content and structure of the overall architecture. These include: ASE overall architecture for EATCHIP Euro- ATD (ADD task Force) CFMU corporate architecture Surveillance functional architecture Airport information requirements (ex BAA Heathrow) The EAD Programme Communications Strategy (Vol. 3 contains a description of the architecture) MERGER object model PATHFINDER links from Operational improvements to Concepts GATAF the Gate-to-Gate architecture model. This contains information that covers Airport and AOC activity; collaborative decision making and surface movement guidance.
Edition: 2.6
Working Draft
Page 89
8.
AIRSPACE CONGESTION
Airspace congestion is a relatively recent phenomenon. It has not been properly studied yet and even specialists find it difficult to understand. The following remarks are a small contribution of mine (Mr. Y. Lambert) to the unavoidable reconsideration of the current "free for all" doctrine. To a large extent, airspace use is not subject to advance reservation and limitation. Queuing is a logical consequence of free access to a resource with finite capacity. For example, one could say that travelling by urban bus or taxi is a free access process, subject to queuing. Conversely, travelling by High Speed Train is restricted by prior mandatory reservation. Airport access is generally subject to mandatory reservation. Main European airports follow a process of declared capacity leading to "co-ordination", i.e. an organised rationing to adjust supply and demand. Airports' business interests are a major incentive for them to increase capacity so as to accommodate demand; limitations are no doubt adopted as a last resort. Of course, there are other recent constraints which limit airport capacity (environmental factors: noise limitations, aircraft movement limitations, limits on the number of passengers, etc...). In contrast, ATS Providers have not yet reached the same level of integrating all factors in their strategies. Before the European Commission-driven process of competition, combined with the separation of regulatory and service provision functions, takes effect, it would be advisable to address the capacity/demand balance of the most critical city pairs of the ATM system. However, the principles of the Eurocontrol ATM 2000+ Strategy should be applied, so as to minimise the total cost of capacity and delays. Possible items for consideration could be: Action to improve the capacity of specific links; Co-ordination (as carried out at airports) of the use of these critical links. Such co-ordination could be performed jointly with existing airport coordination. Separate arrangements as currently undertaken seem to lead to inefficient results because of the double penalties imposed on airspace users by airports and ATFM.
It is fundamental to recognise that airspace is a scarce resource and ought to be subject to mandatory reservation.
Recommendation:
An independent study of the merits of strategic co-ordination of the use of some links (as selected by the PRC) against the current tactical limitations due to ATFM (Air Traffic Flow Management) should be carried out. (The ATFM study initiated by EUROCONTROL as recommended by the PRC should address this aspect. It will deliver recommendations in October 2000).
Page 90
Working Draft
Edition: 2.6
9.
MANAGED AIRSPACE CONTROL

In MAS, aircraft will either be operating in a route structure (Structured Route flight) or flying on a user-preferred trajectory (Free-Routing).
9.1
Structured Route Airspace Control

Research on the current sector working arrangements shows that it will be inadequate to handle the increase in traffic by 2010. One answer, in the past, to the problem of increased traffic has been to make sectors smaller. Many of the majority of sectors in Europe have transit times of less than 15 minutes, and some can be as short as 5 minutes. As said before however, MTCDR systems will be able to predict and assist in resolving potential conflicts up to 30 or so minutes in advance and so will be of benefit to controllers in larger sectors and to multi sector planners. In most, if not all, Centres in Europe, sectors are currently fixed in size with the only adjustment being to amalgamate two or more sectors into one when traffic levels permit. In 2010 however, it will be possible to adjust sector dimensions to respond to demand. The operational sector will be decoupled from a much smaller basic sector. Each operational sector will consist of a number of basic sectors (typically 4 or more), dependent on demand such a basic sector can be moved between neighbouring operational sectors. Any changes in the sector configuration will be reported to the CFMU.
Edition: 2.6
Working Draft
Page 91
10.
DEFINITION OF DELAYS
Out Off Take off On Landing In
The PRC defines delays as follows:

Figure 15 compares the flight schedule and actual flight, and shows how delays in the different phases (departure, taxi-out, en-route, taxi-in) affect arrival punctuality. Published airline schedules generally incorporate a buffer which is added to the planned flight time to accommodate statistically foreseeable delays. Where accumulated delays exceed the buffer, arrival delays occur. Delays and 34 buffer are linked by the following formula :
Arrival delay = Departure delay + taxi-out delay + airborne delay + taxi-in delay buffer
Unconstrained flight
Buffer Arrival delay
Flight schedule Actual

Departure Taxi Out delay Airborne Schedule Delay
Taxi In
Figure 15: Air transport delays and punctuality
34
Delays can be negative when actual time is shorter than planned (e.g. in case of a short cut).
Page 92
Working Draft
Edition: 2.6
11.
ENGINEERING REQUIREMENTS
From Euro-ADD + additions. Engineering requirements are shall statements on process and product, to ensure that the resulting systems exhibit the appropriate level of quality for use in the EATMP context. They should not be confused with operational requirements, which cover both functional and non-functional aspects (such as performance, capacity, availability) of the product, from an operational (user) point of view. Engineering requirements complement the operational requirements from a technical point of view. It is expected that a common set of engineering requirements will be established, and that these will have an increasing impact on DPS. The following list shows the main categories of engineering requirements that need to be established, in order to support achieving the architecture principles:
Product Standards Maintainability
Standards with which the product has to comply. A set of attributes that bear on the effort needed to make specified modifications (ISO/IEC 9126). Modifications may include corrections, improvements or adaptations of software to changes in environment, and in requirements and functional specifications. The extent to which the system can withstand corrupted or faulty data without crashing. The extent to which the system can degrade gracefully upon detection of fault conditions in the data or environment. Attributes of systems and of test environment that bear on the effort needed for testing the software, the associated environment data, and the hardware. A set of attributes that bear on the effort needed to easily adapt a system to some evolution of its own needs, i.e. for new operational needs or for environmental changes. The ease with which a system or a component can be transferred from one hardware or software environment to another. Synonym: transportability. (IEEE definition)
Robustness
Testability
Flexibility
Portability
Edition: 2.6
Working Draft
Page 93
Reusability
The extent to which a program can be used in other applications. (IEEE Software Quality Factor) Attributes of software that bear on its potential for complete or partial reuse in another software product. (ISO)
Manageability
Attributes of software that bear on the effort needed to (re)establish its running status. Also referred to as Requirements for Operating the System. Metrics to be collected in order to gauge and monitor the quality of the product. Metrics related to processes are captured in the sections where the processes are documented. The degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components. The approach to be used for the procurement and development of the system. Methods, rules and procedures, and the tools and tool set-ups to be used during the development of the system.
Product Metrics
Modularity
Development Process & Standards Requirements & Configuration Management
Page 94
Working Draft
Edition: 2.6
12. 12.1
COMPONENT-BASED DEVELOPMENT Why CBD for the development of the Overall Architecture
This section is about the motivation for applying a Component-Based Development (CBD) process over applying a procedural development process. In a procedural development process one defines the participating entities in a collaboration. For each of the entities one describes the procedures that are executed to implement the collaboration and the message or data flow that is generated between the entities. Nowadays the Software Development community has generally adopted the Component-Based Development process over the procedural one. Some of the motivations for this are listed hereafter.
12.1.1
Motivation One of the major weaknesses of the higher described procedural development process is that such an entity participating in a collaboration can only very rarely have an independent life. It exists only in the context of the collaboration. This leads to poor system design, as a similar procedure in a different interaction context will be re-implemented. One could say that the design and implementation will be done within a short-sighted context, without considering the big picture. This issue can be generalised:
The objective of any modelling activity is to represent correctly the user requirements as close as possible to the implementation realm (minimal distance), with minimal constraints imposed on this implementation. A message or data flow, as in use in the procedural approach, is an indirection. Both partners, the sender and the receiver, have to implement the knowledge to interpret the message.
The CBD approach is fundamentally different. A complex function is to be decomposed in order to make it manageable. This decomposition or factoring is to be done along a certain philosophy. This philosophy is built on the core concept: responsibility. For every activity in a function one should ask: who is responsible for it? This leads in general to a partition of components (the partition resulting from the factoring), each with a well-defined responsibility (Note: the partition elements are not overlapping, the partition is complete). This responsibility is expressed through the set of services that it offers and through the main data items that it owns. The message flow in a CBD approach is implicit, hidden behind the exposed services.
Edition: 2.6
Working Draft
Page 95
The advantages of this approach are obvious: Replication of functionality is avoided (only one component can be responsible for a certain functionality). A side effect of this that is very important, is that inconsistencies are minimised. If the same piece of data is interpreted in two different entities then this will lead sooner or later to inconsistencies and conflicts. A component can have its own life cycle, can be re-used in a different context. The CBD artefacts are directly linked to the implementation artefacts, the indirections are minimal. Development by Contract becomes possible. Note: Contract can be seen as the set of services that the component has to offer. Last but not least: every service is implemented by the most competent team, namely the one that is responsible for it and owns the data elements.
It has however also to be realised that the CBD management is more complex. As the overlap is minimal every component team has to rely on its partner components. This makes that the dependency management becomes much more important and complex.
12.2
Component-Based Development (From AVENUE)

Component-Based Development has become arguably one of the most important topics of current discussion within the computing industry. The popularity of standards such as COM, CORBA and Java, the deployment of distributed applications, and the need to shorter development times are naturally leading the software industry towards component-based technologies. The OMG and the ORB vendor industry in general, recognised that the above OMA, although fundamentally correct, could be extended. This led the OMG to organise a new level of CORBA standardisation called CORBA3. An essential part of this CORBA3 standard is the CORBA Component Model. This component model adds a number of new important concepts to CORBA: the component type A component is far bigger programming entity than a simple object. Hence, CORBA IDL35 has been extended to include the specification of component types, which goes far beyond the concept of interface type. the container
35
Interface definition language a language for clear and unambiguous definition of the semantics and associated properties for information and event exchange.
Page 96
Working Draft
Edition: 2.6
Previously, the OMG concentrated principally on core ORB functionality and the generic Object Services. This had the advantage of providing standardised flexibility, but still left the application developer with a myriad of choices and the problem of building an integrated solution. The concept of a Container partially solves this problem, by providing a cocoon for components, where much of the system complexity is automatically managed. the development process Previously, the OMG has focused on purely technical issues. However, the business process of developing distributed systems can no longer be ignored. 12.2.1 Components It is generally accepted that components are far bigger than simple objects (or interfaces). Therefore, the OMG Component specification extends IDL to include a component meta-type. Such a meta-type allows the following aspects of a component to be formally defined: Provided services A particular component may provide many different services/interfaces (e.g. admin, general, privileged services). CORBA3 IDL allows the relationship between component and service interfaces to be clearly defined Used Services CORBA3 IDL allows component dependencies to be specified. That is, a particular component, in order to function, may require the presence of a particular CORBA interface. Published Events A component may define what events it is capable of producing. Consumed Events A component may define what events it is capable of consuming. Configuration services CORBA3 IDL allows component developers to explicitly define entry points for component configuration (i.e. the definition of property values). Instantiation services A component in order to be used requires instantiation. CORBA3 IDL allows the developer to explicitly define instantiation services as required. This is called a Home interface. Inheritance A component may inherit from other components.
Edition: 2.6
Working Draft
Page 97
The proposed CORBA3 IDL allows software components to be formally defined in terms of: offered functionality (provided services, published events); dependencies (used services, consumed events); configurability.
In other words, components are defined in terms of overall input/output (like hardware components). Therefore, a component has a number of male and female connectors. The following diagram illustrates this.
Config services
Used service S2
Provided service S1
C
Consumed event E2 Published event E1
Figure 16: Component Definition Continuing the hardware analogy, CORBA components can then be wired together, with output connectors being attached to corresponding input connectors. Hence, through the act of component assembly systems (or subsystems) can be built.
Page 98
Working Draft
Edition: 2.6
13.
AAM ACARS ACAS ACC ADD ADEP ADES ADS-B ADS-C AGDL AHM AIC AIM AIP AIS AMC AMS ANM AO AOA AOC AOP AoI AoR APC APP ARINC ARO ASDE ASE ASM ATA ATC
ACRONYMS
Airspace Activation Manager Aircraft Communications Addressing and Reporting System Airborne Collision Avoidance System Area Control Centre Architecture Description Document Aerodrome of Departure Aerodrome of Destination Automatic Dependent Surveillance - Broadcast Automatic Dependent Surveillance - Contract Air-Ground Data Link Airport Handling Manual Aeronautical Information Circular Aeronautical Information Management Aeronautical Information Publication Aeronautical Information Services Airspace Management Cell Arrival Management System ATM Notification Message Aircraft Operator Angle Of Attack Airline Operations Centre Airport Operations (EATMP Unit) Area of Interest Area of Responsibility Airlines Passenger Communications Approach Control Aeronautical Radio Incorporated Airport Reporting Office Airport Surveillance Detection Equipment ATM System Engineering Airspace Management Actual Time of Arrival Air Traffic Control
Edition: 2.6
Working Draft
Page 99
ATD ATD ATFM ATM ATN ATS AUP AVENUE CADF CAP CASA CBA CBD CDM CDR CFMU CHASEIT CNS CODA COM CORBA CRAM CRCO CTOT DAP D-ATIS DLIC DME DMS DP EAD EATCHIP EATMP ECAC ECIT
ATC and Data Processing (EATMP Unit) Actual Time of Departure Air Traffic Flow Management Air Traffic Management Aeronautical Telecommunication Network Air Traffic Service(s) Airspace Use Plan ??? see Nigel Centralised Airspace Data Function Controller Access Parameters Computer-Assisted Slot Allocation Cross-Border Area Component-Based Development Collaborative Decision Making Conditional Route Central Flow Management Unit Collaborative Harmonisation of Architecture, System Engineering and Integration Techniques Communications, Navigation and Surveillance Central Office for Delay Analysis Communications Common Object Request Broker Architecture Conditional Route Activation Message Central Route Charges Office Calculated Take-Off Time Downlink Airborne Parameter Digital Automatic Terminal Information Service Data Link Initiation and Control Distance Measuring Equipment Departure Management System Data Processing European AIS Database European Air Traffic Control Harmonisation and Integration Programme European Air Traffic Management Programme European Civil Aviation Conference EAD Client Interface Terminal
Page 100
Working Draft
Edition: 2.6
EEC eFDP ENV EOBT EPU ETA ETFMS ETO FDO FDP FIR FIS FL FMD FMP FMS FPL GAT GATAF GBAS GLONASS GLS GNSS GPS HF HMI I/F IAS IATA ICAO ICD ID IDL IFPL IFPS
EUROCONTROL Experimental Centre European Flight Data Processing Programme Environment Estimated Off-Block Time Estimated Position Uncertainty Estimated Time of Arrival Enhanced Tactical Flow Management System Estimated Time Over Significant Point Flight Data Operations (division of CFMU) Flight Data Processing Flight Information Region Flight Information Service Flight Level Flow Management Division (CFMU) Flow Management Position Flight-Management System Flight Plan General Air Traffic Gate to Gate Architecture Framework Ground Based Augmentation System check with DH Global Navigation Satellite System ??? see SNF Global Navigation Satellite System Global Positioning System High Frequency Human-Machine Interface Interface Indicated Airspeed International Air Transport Association International Civil Aviation Organisation Interface Control Document Identity Interface Definition Language FPL processed by IFPS [Integrated] Initial Flight Plan Processing System
Edition: 2.6
Working Draft
Page 101
IFR ILS JIT LOA, LoA MCDU MET MLS MMR NAV NDB NOTAM OAT ODS ORD PIB PPM RF RJT RM-ODP RNP RPL SAP SBAS SCS SDP SDPD SDY SID SMGCS SMGS SMM SMS SPA SRJ SRR
Instrument Flight Rules Instrument Landing System Just In Time Letter of Agreement Multipurpose Control & Display Unit Meteorological / Meteorology Microwave Landing System ??? see DH Navigation Non-Directional Radio Beacon Notice to Airmen Operational Air Traffic Operational Display System Operational Requirements Document Pre-Flight Information Bulletin Programme Portfolio Management (EATMP Unit) Radio Frequency (ATFM message) Reference Model of Open Distributed Processing Required Navigation Performance Repetitive Flight Plan System Access Parameters Satellite Based Augmentation System check with DH Strategy Concept & System (EATMP Unit) Surveillance Data Processing Surveillance Data Processing and Distribution
TBD standby? (ATFM message)
Standard Instrument Departure Surface Movement Guidance and Control System Surface Movement Guidance System Slot Missed Message (ATFM message) Surface Management System Slot Proposal Acceptance (ATFM message) Slot Improvement Proposal Rejection (ATFM message) Slot Revision Request ATFM message)
Page 102
Working Draft
Edition: 2.6
SRS SSR STAR SUR SWIM TACT TAR TCAS TMA TOC TOD TSA UML UUP VFR VHF VOR XPDR
Standard Routing Scheme Secondary Surveillance Radar Standard Instrument Arrival Route Surveillance System-Wide Information Management Tactical Flow Management Temporary Airspace Request Traffic Alert and Collision-Avoidance System Terminal Control Area Top of Climb Top of Descent Temporary Segregated Area Universal Modelling Language Updated Use Plan Visual Flight Rules Very High Frequency VHF Omnidirectional Radio Range Transponder
Edition: 2.6
Working Draft
Page 103

Straw Man

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Straw Man

Transféré par

Droits d'auteur :

Formats disponibles

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION

Production of Overall Architecture: Strawman

Edition Edition Date Status Class

2.6 17 January 2001 Working Draft Restricted

EUROPEAN AIR TRAFFIC MANAGEMENT PROGRAMME

DOCUMENT IDENTIFICATION SHEET

Production of Overall Architecture: Strawman

NAME AND SIGNATURE

Internal working document no sign off required

Production of Overall Architecture: Strawman

DATE 16 June 2000

SECTIONS PAGES AFFECTED All

3, 5.3, 5.4, 5.5, 5.6, 5.7, 5.10, 5.11, 5.12 All

22 Sept 2000 17 Jan 2001

Sections 1 through 5 All

Production of Overall Architecture: Strawman

4. ARCHITECTURE DRIVERS .............................................................................. 20

Production of Overall Architecture: Strawman

4.1 4.2 4.3 4.4 4.5

5. EATMP OVERALL ARCHITECTURE - REPRESENTATION............................ 22

Production of Overall Architecture: Strawman

5.9.2 5.9.3 5.9.4 5.9.5 5.9.6

Production of Overall Architecture: Strawman

Sector Planning and Sector Control ............................................................................... 76

Changes and Assumptions to Meet 2010 Scenario ............................................................... 88

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

The Business Need Being Addressed

Production of Overall Architecture: Strawman

Phase 1: Summary of Goals

Production of Overall Architecture: Strawman

Collation: Establish relationships

Other sources CDM EAD

Gate to gate extensions (a) Model Repository (b)

STRATEGIES ATM 2000+ Domains

ROAD ROAD MAP MAP

Develop: Scenarios Use Cases

Current tools/projects (a) - GATAF (b) - MERGER (c) - PATHFINDER

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

ground handling on-blocks / off-blocks arrival / departure

en-route 2005 2010 2015

Production of Overall Architecture: Strawman

Data processing systems: Scope and Structure

Production of Overall Architecture: Strawman

eFDP, Fallback FDP

(probably the lowest level of interest)

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

Air cra f t Operator

<<domain>> Navigation Infrastructure

<<dom ain >>

Air Tr aff ic Control

Meteo Service Provider Controller

Time Servic e Prov der i

Environment Data Service Provider

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

Production of Overall Architecture: Strawman

Controller Flow Ma nager Airspace Manager