SWIM Concept of Operations

Transcription

1 SWIM Concept of Operations Document information Operational Requirements & Demands concerning organisation of the Project Title ATM Information Management within the scope of the European ATM Enterprise Architecture Project Number Project Manager Deliverable Name Deliverable ID EUROCONTROL SWIM Concept of Operations D41 Edition Template Version Task contributors EUROCONTROL, INDRA, SELEX, Frequentis, Thales, DSNA, DFS, Noracon Abstract This document describes the SWIM Concept of Operations. It provides the definition of SWIM and related aspects such as the vision, principles, needs and benefits, and governance. The set of usecases provided in this document describes a proposal for the SWIM lifecycle. It aims to establish a common understanding of the SWIM concept and how SWIM Services will be designed, used, maintained and operated. Together, the elements of the SWIM ConOps constitute a common foundation from which concrete requirements can be derived to steer the SWIM activities in the SESAR Programme.

2 Authoring & Approval Prepared By - Authors of the document. Name & Company Position & Title Date Pedro Cruellas / EUROCONTROL Project member 10/04/2013 Eric Roelants / EUROCONTROL P Project manager 10/04/2013 Reviewed By - Reviewers internal to the project. Name & Company Position & Title Date Stéphane Dubet / DSNA P Project member 10/04/2013 Jan-Philippe Lauer / DFS P Project member 10/04/2013 Pedro Cruellas / EUROCONTROL P Project member 10/04/2013 Susanne Biermann-Hoeller / DFS P Project member 10/04/2013 Sam Van Der Stricht / EUROCONTROL P08.01 Project manager 10/04/2013 Eric Roelants / EUROCONTROL P Project manager 10/04/2013 Reviewed By - Other SESAR projects, Airspace Users, staff association, military, Industrial Support, other organisations. Name & Company Position & Title Date Dirk Janssens / EUROCONTROL P14.04 Project manager 10/06/2013 Alex Petrovsky / EUROCONTROL P Project contributor 10/06/2013 Marc Brochard / EUROCONTROL B4.3 Project manager 10/06/2013 Antonio Strano / SELEX P14.04 Project member 10/06/2013 Dario Di Crescenzo / SELEX P14.04 Project member 10/06/2013 Petr Gotthard / Honeywell P14.04 Project member 10/06/2013 Roman Nossal / Austrocontrol P14.04 Project member 10/06/2013 Georg Trausmuth / Frequentis P14.04 Project member 10/06/2013 Tord Pola / Noracon P Project Manager 10/06/2013 Peder Blomqvist / LFV WP8 Leader 10/06/2013 Mikael Månström / LFV WP 8.0 Project Member 10/06/2013 Juan Lopez / Indra P14.04 Project member 10/06/2013 David Martín Baz / Indra P14.04 Project member 10/06/2013 Yann Le Bars / Thales P14.04 Project member 10/06/2013 Mike Taylor / NATS B4.3 Project member 10/06/2013 Approved for submission to the SJU By - Representatives of the company involved in the project. Name & Company Position & Title Date Dirk Janssens / EUROCONTROL P14.04 Project manager 10/06/2013 Alex Petrovsky / EUROCONTROL P Project contributor 10/06/2013 Marc Brochard / EUROCONTROL B4.3 Project manager 10/06/2013 Antonio Strano / SELEX P14.04 Project member 10/06/2013 Dario Di Crescenzo / SELEX P14.04 Project member 10/06/2013 Petr Gotthard / Honeywell P14.04 Project member 10/06/2013 Roman Nossal / Austrocontrol P14.04 Project member 10/06/2013 Georg Trausmuth / Frequentis P14.04 Project member 10/06/2013 Tord Pola / Noracon P Project Manager 10/06/ of 71

3 Peder Blomqvist / LFV WP8 Leader 10/06/2013 Mikael Månström / LFV WP 8.0 Project Member 10/06/2013 Juan Lopez / Indra P14.04 Project member 10/06/2013 David Martín Baz / Indra P14.04 Project member 10/06/2013 Yann Le Bars / Thales P14.04 Project member 10/06/2013 Stéphane Dubet / DSNA B4.3 Project member 10/06/2013 Jan-Philippe Lauer / DFS P Project member 10/06/2013 Pedro Cruellas / EUROCONTROL P Project member 10/06/2013 Susanne Biermann-Hoeller / DFS P Project member 10/06/2013 Sam Van Der Stricht / EUROCONTROL P08.01 Project manager 10/06/2013 Eric Roelants / EUROCONTROL P Project manager 10/06/2013 Mike Taylor / NATS B4.3 Project member 10/06/2013 Rejected By - Representatives of the company involved in the project. Name & Company Position & Title Date Rational for rejection None. Document History Edition Date Status Author Justification /01/2012 Draft Eric Roelants Consolidation of different chapters in one document /02/2012 Draft Eric Roelants Update of sections: abstract, executive summary, introduction chapters, needs and benefits, assumptions /02/2012 Draft Eric Roelants Minor lexical modifications /02/2012 Draft Eric Roelants Update of assumptions chapter /02/2012 Draft Eric Roelants Added the use-cases. Update of the needs and benefits with Pedro s review. Aligned the definitions with WP B - D /02/2012 Draft Eric Roelants Changes from proofreading. Update on assumptions /02/2012 Draft Eric Roelants Update with comments of Pedro (all taken into account) and Stéphane (most of them taken into account some to be discussed) /02/2012 Draft Eric Roelants Update on comments of Stéphane (e.g. chapter 4). Update during webex /02/2012 Draft Eric Roelants Update of drawings in SWIM in practice chapter /02/2012 Draft Eric Roelants Included comments from Georg. Update of terms: 3 of 71

4 SWIM Node and SWIM common component during webex of 14 Feb /02/2012 Final Eric Roelants Status to Final version /04/2012 Draft Eric Roelants Update comments SJU /04/2012 Draft Pedro Cruellas Requirements and assumptions in formal statements (appendix engineering artefacts) /06/2012 Final Eric Roelants On request of SJU, removed in the unnecessary amount of technical details in this section that are not relevant and are expected to be produced by the SWIM Profile white paper /10/2012 Final Pedro Cruellas Integration of a subset of SJU comments to ed /11/2012 Draft Eric Roelants Update on the complete set of comments, after meeting 24/10/ /11/2012 Draft Pedro Cruellas Update of use-case 12, lifecycle of a service and additional changes following meeting 21/10/ /01/2013 Final draft Eric Roelants Minor update (remove paragraph that this version is a preliminary version from abstract and executive summary. Intended readership: removed last paragraph on preliminary version. Removed reference to IM document in chapter 1.2. Changes in Chapter 5 on request of SJU-IS to change SWIM-enabled ATM system into SWIM-enabled domain system /01/2013 Final draft Eric Roelants Added SWIM Key Principles from the A /02/2013 Final draft Eric Roelants Key Principles review after webex /02/2013 Final Eric Roelants Final version /04/2013 Final Eric Roelants Update following comments SJU, National Authorities and EASA /06/2013 Final Eric Roelants Update following comments F2F meetings on 10 th and 11 th June (with A6) /06/2013 Final Jan-Philipp Lauer Proofreading and editorial changes 4 of 71

5 Intellectual Property Rights (foreground) This deliverable consists of SJU foreground. SESAR JOINT UNDERTAKING, Created by EUROCONTROL, INDRA, SELEX, Frequentis, Thales, DSNA, DFS and Noracon for the SESAR Joint Undertaking within the frame of the SESAR Programme co-financed by the EU and EUROCONTROL. The opinions expressed herein reflect the authors view only. The SESAR Joint Undertaking is not liable for the use of any of the information included herein. Reprint with approval of publisher and with reference to source code only. 5 of 71

6 Table of Contents EXECUTIVE SUMMARY INTRODUCTION BACKGROUND PURPOSE OF THE DOCUMENT INTENDED READERSHIP INPUTS FROM OTHER PROJECTS ACRONYMS AND TERMINOLOGY VISION AND DEFINITION VISION SWIM DEFINITION SWIM PRINCIPLES SWIM CONTRIBUTION TO THE FUTURE EUROPEAN ATM SYSTEM CURRENT SYSTEM AND SITUATION Current ATM system Information management in the European ATM system Weaknesses of current information management in ATM SWIM AND THE FUTURE EUROPEAN ATM SYSTEM SWIM IN PRACTICE SWIM Technical Infrastructure SWIM Use case timeline SWIM Actors and their roles SWIM GOVERNANCE IMPLEMENTING SWIM THROUGH GRADUAL CHANGE REFERENCES APPENDIX A DETAILED DESCRIPTION OF THE GOVERNANCE GROUPS A.1 SWIM STEERING GROUP A.2 SWIM COMPLIANCE GROUP A.3 SWIM STANDARDS AND ARCHITECTURE GROUP A.4 SWIM ASSESSMENT GROUP A.5 SWIM TECHNICAL MANAGER GROUP APPENDIX B OUTSTANDING QUESTIONS APPENDIX C ASSUMPTIONS C.1 GENERAL ASSUMPTIONS C.2 SWIM REGISTRY C.3 DESIGN ASSUMPTIONS C.4 INFORMATION AND SERVICE MANAGEMENT APPENDIX D USE CASES D.1 UC01 A STAKEHOLDER JOINS SWIM D.2 UC02 THE SWIM COLLABORATION AUTHORITY ASSESSES A STAKEHOLDER D.3 UC03 A STAKEHOLDER PROPOSES A NEW OR UPGRADED SERVICE DEFINITION D.4 UC04 THE SWIM COLLABORATION AUTHORITY MANAGES THE LIFECYCLE OF THE REFERENCE MODELS (AIRM / ISRM) D.5 UC05 A PROVIDER PROPOSES A NEW OR UPGRADED SERVICE INSTANCE of 71

7 D.6 UC06 A PROVIDER DEVELOPS A NEW SERVICE INSTANCE D.7 UC07 A STAKEHOLDER UPGRADES THE SWIM INFRASTRUCTURE D.8 UC08 THE SWIM COLLABORATION AUTHORITY / PROVIDER ASSESSES THE COMPLIANCE OF A SERVICE INSTANCE D.9 UC09 A PROVIDER DEPLOYS A NEW OR UPGRADED SERVICE INSTANCE ON THE SWIM INFRASTRUCTURE D.10 UC10 A CONSUMER PREPARES TO USE AN EXISTING SERVICE VIA THE SWIM INFRASTRUCTURE 61 D.11 UC11 A PROVIDER DECOMMISSIONS A SERVICE INSTANCE ON THE SWIM INFRASTRUCTURE D.12 UC12 THE SWIM COLLABORATION AUTHORITY DEPRECATES A SERVICE DEFINITION APPENDIX E ENGINEERING ARTEFACTS E.1 REQUIREMENTS IN THE MAIN PART OF THE DOCUMENT E.2 GENERAL ASSUMPTIONS E.3 SWIM REGISTRY ASSUMPTIONS E.4 DESIGN ASSUMPTIONS E.5 INFORMATION AND SERVICE MANAGEMENT ASSUMPTIONS of 71

8 List of tables Table 1 SWIM Actors description Table 2: Description of the main roles Table 3: Actors and their main roles in SWIM List of figures Figure 1: The aspects that are brought together by SWIM Figure 2: Inter-relationships and connectivity in today's European ATM System Figure 3: Overview of SWIM benefits As depicted in Figure 3, SWIM will enable technical improvements, e.g. cheaper design, early (or easier) adoption, etc. These technical improvements will in turn enable operational improvements such as better shared situational awareness. The operational improvements will contribute to the ATM Key Performance Areas (KPA) identified in the SESAR Programme Figure 4: Service aspects Figure 5: SWIM-TI high-level architecture Figure 6: Use-cases part Figure 7: Use-cases part Figure 8: Normal lifecycle of a SWIM service Figure 9: Proposal for a SWIM Governance Structure of 71

9 Executive summary SWIM is frequently positioned as an enabler that facilitates interoperable information exchange in the European ATM system. However, this requires a clear and commonly agreed description and definition of what SWIM is and how it is used. The SWIM ConOps provides a definition of SWIM and, through a set of representative use-cases, a view of how SWIM is applied in the SESAR Programme and in the future European ATM system. As a result of the SWIM ConOps work, the definition of SWIM is as follows: SWIM consists of standards, infrastructure and governance enabling the management of ATM information and its exchange between qualified parties via interoperable services. The implementation of SWIM is not a big-bang replacement of the existing ATM environment, but rather an evolutionary process based on a gradual transition towards a service-oriented European ATM system. The adoption of SWIM will be flexible, fostering increased levels of collaboration within business domains and enabling supporting systems to interact in an interoperable and standardised way. The concept of SWIM, due to its definition, will remain the same during the different SESAR Steps. The SESAR Steps will impact the SWIM implementation with the continuous improvement and evolution mentioned in the previous paragraph. In addition to the SWIM definition, this document describes SWIM-related aspects such as the vision, principles, needs and benefits, and governance. The current version of the SWIM ConOps explains how stakeholders will participate in SWIM, and how it will be managed and used at various levels (from the business and institutional level to the technical/implementation level). The content of this deliverable needs to be understood as a basis which requires future iterations providing the necessary refinements. The document also provides a list of use-cases whereby a proposal for the SWIM life cycle is detailed. This ranges from the registration of the stakeholders and their definition of needs to the deployment of solutions, which will cover regulatory and technical aspects. Together, the elements of the SWIM ConOps constitute a common foundation from which concrete requirements can be derived to steer the SWIM activities in the SESAR Programme. 9 of 71

10 1 Introduction 1.1 Background Within the scope of P , the D39 deliverable provided an initial version of the SWIM ConOps with information on "what is the problem", "how to solve it", "the use-case objectives", a list of "usecase key elements (actors, process steps, assumptions, issues)", "types of use-cases", "next steps and need for regular update" for the SWIM Concept of Operations. This document provides the SWIM Concept of Operations as a contribution to Action 01 of the SWIM Action Plan. The objective of this Action 01 (see ref [1]) is to establish a written description of the overall SWIM concept covering all relevant aspects. 1.2 Purpose of the document The purpose of this document is to provide a concrete definition of what SWIM is, setting out the principles behind the SWIM concept, why SWIM is needed in European ATM and how the SWIM concept is expected to be put into practice (including the means by which it should be governed and by which decisions about it should be taken). This document also aims to describe how SWIM can be implemented through gradual changes which will enable the various European ATM stakeholders to adapt to this new vision of information sharing. With the objective of clarifying the use of SWIM, a list of use-cases has been provided to further explain the concept. One of the key aspects of SWIM is Information Management, which is partly covered in the "Use Cases" section of this document (and which will be further detailed in subsequent SESAR SWIM projects). 1.3 Intended readership The SWIM ConOps is expected to be widely used not only at SESAR Programme level but also after the SESAR Programme ends. The document is both the cornerstone for the use of SWIM in the information exchanges which will occur within the Single European Sky but also for the interface with other regions. Within the SESAR Programme, the SWIM ConOps is of special interest for the following projects: SACG + SWIM Action Plan main actors SJU WPB (specially for B4.1, B4.2 and B4.3) WP8 (specially for P , P and P ) WP14 (specially for P14.04, P and P ) 1.4 Inputs from other projects As stated above, this document has considered diverse material already existing in the Programme. Concretely, the following input has been considered in the production of this document: B4.1 Performance and Business aspects of the EAEA B4.2 Concept of Operations and Business Services B4.3 ADD B4.3 Working Method on Services P Information Services Reference Model P ATM Information Reference Model 10 of 71

11 WP14 Technical and Technological Aspects D03-SWIM Technical Infrastructure Definition doc D05 SWIM technical requirements specification for Step1-update1_edn doc 1.5 Acronyms and Terminology Term Definition AIRM AOP ATM ATM Service B2B Capability DNM E-ATMS ISRM NFR NOP SACG Service Service attribute Service contract Service interface ATM Information Reference Model Airport Operations Plan Air traffic management A unit of functionality by which the needs of potential Service Subscribers are satisfied by a Service Provider according to a Contract. (Source: SESAR ATM Lexicon). Business to Business The collective ability to deliver a specified type of effect or a specified course of action. Within the context of the SESAR Programme a capability is therefore the ability to support the delivery of a specific operational concept to an agreed level of performance. (Source: Common working meeting between B41 EA study and B43 T5) EUROCONTROL Directorate Network Manager (former CFMU) European air traffic management system Information Service Reference Model Non-functional requirement Network Operations Plan SWIM Architect Co-ordination Group The contractual provision of something (a non-physical object), by one, for the use of one or more others. Services involve interactions between providers and consumers, which may be performed in a digital form (data exchanges) or through voice communication or written processes and procedures. (source: B4.3 T5 study) A Service Attribute defines a property of a service. Examples: Response time, Frequency of invocation, Message Exchange Pattern. (source: B4.3 T5 study) A service contract represents an agreement between the stakeholders involved for how a service is to be provided and consumed. (source: B4.3 T5 study) The mechanism by which a service communicates. Service providers and consumers need to implement service interfaces to be able to collaborate. A service interface includes service operations that enable access to the functionality of the services identified, as well as the data used 11 of 71

12 Term Service Level SESAR SESAR Programme SJU Definition in the service interaction. (source: B4.3 T5 study) A value specification for one or more Service Attributes indicating the level to which a Technical system (or Resource if including non-automated services) delivers a service in a particular environment. Example: A Service Attribute Response time may be defined against a service. A given Technical system could have a corresponding Service Level e.g. Less than 3 seconds. (source: B4.3 T5 study) Single European Sky ATM Research Programme The programme which defines the research and development activities and projects for the SJU SESAR Joint Undertaking (Agency of the European Commission) SJU Work Programme The programme which addresses all activities of the SESAR Joint Undertaking Agency. SOA Service Oriented Architecture The following terms and definitions are meant to clarify the terminology within this document. They were built at the start of the A01 action, to have a common understanding of the terms between all members. They are logically grouped per subject to make the relations between the terms better understandable. Term Architecture principles Definition A set of driving rules, principles and design patterns to be applied when the SWIM-TI and the associated architecture paradigms are designed. Typically, in the system design process, the term design principles is used instead of architecture principles. These are the principles which must be applied when the system (in our case the SWIM-TI) is designed. The design principles can be grouped into several categories such as general (e.g. standards-based, user-centred design, modularity, extensibility and reusability) and methodology (e.g. functions are delivered incrementally). For each design/architecture principle, its rationale (why it has been introduced) and its implications for subsequent design activities are typically provided. Architectural item Whenever the modularity design principle is applied during a system design process, it is possible to break down the target system into several parts. The latter are typically called architectural Items, architecture building blocks, system components or subsystems. WP14 uses both architectural items and SWIM-TI architecture building blocks. In the context depicted in this document, all of these terms have the same meaning. In the context of the overall SWIM-TI design, an architecture building block represents a sub-part/sub-component of the SWIM-TI node, or a component 12 of 71

13 Certificate Term Common Components Governance Legal recording Policy Policy enforcement Registry Service Service definition Service instance Service catalogue Service implementation Service Level ATM-specific service Enabling service Service version Definition which is shared (among SWIM-TI nodes), such as the registry. The result of a certification, which is the confirmation of certain characteristics of an object, person, or organisation. This confirmation is often, but not always, provided by some form of external review, education, assessment, or audit (ATM service "certificate" of compliance). The common components implement shared capabilities to all the distributed SWIM nodes. Ability of decision-makers to set policies regarding stakeholders, services, and their relationships Secure log recording for legal use Principle or rule with a view to guiding decisions and achieving one or more rational outcomes Action to compel the application of a policy The SWIM Registry is the inventory of reference for service related resources in SWIM. It improves access to information facilitating a common understanding of SWIM. It has benefits for its various stakeholders: o Allowing service providers to keep track of relevant regulations and increases the visibility (and consequent adoption) of their services. o Improving the efficiency of service consumers in identifying the right providers and services, and monitoring the evolution of these. o Facilitating the governance of SWIM and collaborative evolution of related policies and standards (e.g. approvals, notifications for AIRM, ISRM) (see P D19 for more information on the registry) A service is constituted by a service definition, implemented by zero, one or several service instances. Service specification as it appears in the service catalogue. Service which has been implemented in accordance with its specification in the service catalogue (during the SESAR Development Phase, the service definitions are available in the ISRM) by a service provider (by itself or contracted to a third party) A set of the service instances and service definitions available through SWIM. Process for the implementation of a service instance List of values of every non functional requirement for a service A service meeting a need specific to the ATM domain, i.e. not a service provided by the SWIM-TI. In the context of this document, this term is restricted to services being part of the Service catalogue. A service provided by the SWIM-TI Version of a service 13 of 71

14 Term Service status Lifecycle SLA monitoring SWIM SWIM Infrastructure Definition The current phase of a service in its life cycle The lifecycle defines the sequence of phases. Monitoring to ascertain that the actual behaviour of a service instance complies with its specified service level agreement System-wide information management. SWIM consists of standards, infrastructure and governance enabling the management of ATM information and its exchange between qualified parties via interoperable services. The sum of all the SWIM infrastructure elements which are needed to support SWIM services SWIM Component Common A SWIM infrastructure element managed by the SWIM Collaboration Authority and implementing a shared capability, e.g. registry, PKI, etc. SWIM Infrastructure element A technical element (hardware, software or network) which is part of the SWIM infrastructure SWIM Enabled system A system providing or consuming ATM-specific services SWIM Profile SWIM-TI SWIM-TI capability SWIM node A SWIM profile is a coherent, appropriately-sized grouping of middleware functions/services for a given set of technical constraints/requirements that permits a set of stakeholders to realize Information sharing. It will also define the mandated open standards and technologies required to realize this coherent grouping of middleware functions/services (source ref [2]). SWIM technical infrastructure, a synonym of SWIM infrastructure A given type of SWIM-TI system functionality A SWIM Node is a logical collection of SWIM-TI capabilities, compliant with one or more SWIM profiles and allowing a given ATM application to use the SWIM-TI. 14 of 71

15 2 Vision and definition 2.1 Vision For the domain system and its users to operate at their full potential, pertinent information needs to be available when and where required. Indeed, the ATM community increasingly depends on the provision of timely, relevant, accurate, accredited and quality-assured information in order to collaborate and make informed decisions. Sharing the best possible integrated picture of the historical, real-time and planned or expected future state of the ATM situation on a system-wide basis will allow the ATM community to conduct its business and operations in a safer and more efficient manner. This is supported by System Wide Information Management, through an interconnected set of domain systems providing or consuming information, including human users and aircraft. Through SWIM, information is made available and processed through services which need to conform to applicable standards and be registered so that they are accessible. In addition, SWIM improves the interconnectivity of domain systems. SWIM promotes and contributes to open standards, and it also provides technology recommendations. The aim of this is to improve information management and therefore information sharing on a wide basis, providing support for permanent dialogue between the various partners. SWIM will cover the security requirements associated with the information exchanges. SWIM also enables wider discoverability of pertinent information, while making it easier and less costly to share. Aircraft operators will have up-to-date, accurate and integrated information on which to base decisions about their flights, while ATM service providers, including aerodrome operators, will have a better knowledge of flight intentions for operational and planning purposes. Thereby, controllers, pilots, dispatchers and other flight operational personnel will share a common situational awareness with regard to the status and condition of the aeronautical infrastructure, the weather, the air traffic situation and other operationally significant information. On the basis of this shared situational awareness, the ATM actors will make better and faster decisions collaboratively for the purpose of orchestrating and conducting highly efficient operations. 2.2 SWIM Definition The definition of SWIM is as follows: SWIM consists of standards, infrastructure and governance enabling the management of ATM information and its exchange between qualified parties via interoperable services. 15 of 71

16 3 SWIM principles In order to avoid a chaotic implementation of the SWIM Concept the need for a set of guiding principles is envisaged. These principles provide direction for all stakeholders in respect of the design, provision, evolution of SWIM, and with regard to the information/solution providers and consumers, the processes, standards, and technologies. The 10 Key Principles 1 of SWIM, a holistic set, are aligned with the operational business for SWIM to increasingly provide: the right information, to the right people, at the right place, and at the right time. SWIM brings together the three aspects, the ATM stakeholders; shared information and common processes, and the underpinning use of technology as indicated below. Figure 1: The aspects that are brought together by SWIM 1. Accessibility ATM stakeholders can directly offer, and consume, ATM information using common service interfaces and network connectivity. 2. Equity No individual stakeholder dominates, or constrains, what may be offered, or consumed, by other stakeholders. 3. Flexibility Capability for adequate, responsive, timely, dynamic and asynchronous changes of providers and users and the information and services they offer and consume. 1 These principles were based on the 7 Key Principles proposed by the A6 SWIM group. 16 of 71

17 4. Performance Combined ATM stakeholder and infrastructure provisions must ensure required levels of performance, safety, and resilience, and provide effective incident and evolution management. 5. Quality, Integrity & Security ATM Stakeholders retain responsibility for the quality, integrity, security, and availability of the information, whilst interface and infrastructure technology ensures integrity of exchanges. ATM Stakeholder identification allows information to only be exchanged with appropriate parties and security measures applied. 6. Implementation & Evolution Clear vision and roadmap for operational, technical, and institutional, implementation and evolution; aligned with reduction in the use of individually specialised interfaces and connectivity. 7. Cost Reduced costs for on-going information exchanges, with costs for ATM evolution proportionate to needs, benefits and stakeholder affordability. 8. Service orientation Service orientation methods are expected to be applied to support the ATM stakeholders use of services to share information. 9. Open standards SWIM is expected to make use of applicable open and internationally recognised standards for the information, the content, the processes, and the provision of services Global applicability SWIM will need both international and local agreements, to achieve a seamless ATM information environment and therefore adequate governance needs to be established. 2 Standard from SESAR ATM lexicon. Open from European Interoperability Framework for pan- European egovernment Services, Version 1.0 (2004) ISBN X page 9:The word "open" is used here in the sense of fulfilling the following requirements: The standard is adopted and will be maintained by a not-for-profit organization, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.). The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee. The intellectual property - potentially including patents - of (parts of) the standard is made irrevocably available on a royalty-free basis. There are no constraints on the re-use of the standard 17 of 71

18 4 SWIM contribution to the future European ATM system This chapter describes how SWIM contributes to the future European ATM system. Prior to this description, an overview of the current European ATM system and its weaknesses is presented. 4.1 Current system and situation Current ATM system Air Traffic Management (ATM) is defined by ICAO as the dynamic, integrated management of air traffic and airspace safely, economically and efficiently through the provision of facilities and seamless services in collaboration with all parties. 3 The primary functions of the European ATM system, based on the provision of services, are to enable flights from/to an aerodrome through airspace, safely separated from hazards, within capacity limits, making optimum use of all system resources. This service-based framework considers all resources, inter alia airspace, aerodromes, aircraft and humans, to be part of the European ATM system. ATM services are provided using procedures, people and engineering systems located mainly at en-route ATC centres and airports. At these locations, data-processing systems are connected to ground-based communication, navigation and surveillance (CNS) infrastructure systems providing information support services which are functionally compatible with corresponding systems on board the aircraft. Europe has numerous ATM/CNS legacy systems and operational procedures in service today, which have varying capabilities and various degrees of complexity. These heterogeneous technology solutions, sometimes with overlapping capabilities, make up Europe s current ATM system enablers for the provision of ATM services. The figure below shows, for information purposes, the principal inter-relationships and connectivity between the major processing entities and domain systems in today's European ATM system. Figure 2: Inter-relationships and connectivity in today's European ATM System The business value of present-day ATM service provision is based on: Safety: The fundamental basis for performing ATM Service sustainability/continuity: Avoiding significant degradation in services and maintaining a flexible response to external circumstances Growing capacity: Fully exploiting physical airport capacities and safely handling the future growth in air transport 3 EC Regulation 549/2004 defines ATM as the aggregation of the airborne and ground-based functions (air traffic services, airspace management and air traffic flow management) required to ensure the safe and efficient movement of aircraft during all phases of operations. 18 of 71

19 Predictability: Assisting airlines to maintain robust schedules Access to airspace: Ensuring equity for all airspace users Flight efficiency: Enabling the use of efficient flight profiles for all airspace users including military, subject to meeting safety and capacity priorities Security and the environment: Meeting expectations and standards Cost-effectiveness: Minimising the direct and the indirect costs Information management in the European ATM system Information management in ATM can be seen as a complex, distributed information processing community which covers the logistics and distribution of accredited, quality-assured and timely information used to support all ATM components, thus forming the glue between them. It is the basis for performing collaborative decision-making. This community is made up of a large number of humans and automated systems in the roles of information providers, decision makers and information users - all collaborating to ensure a safe, expeditious and efficient flow of air traffic. The objective of information management is to collect, organise, control, process and deliver information 4 in order to provide the decision makers and information users with the right information at the right time and in the right place Weaknesses of current information management in ATM One of the major weaknesses of current practices is considered to be the limited interconnectivity of services and systems. Furthermore, the limited data sharing and under-exploitation of the capabilities of on-board aircraft avionics all contribute to airspace capacity not being optimally used. Interoperability and information exchange: ANS organisations have individually worked on solving their own information management problems, and the information exchange between domain systems significantly improved as a result of the local solutions developed, but this has been done without considering the need for global interoperability. The current level of interoperability between domain systems in Europe is low, especially in ground systems. This is due to the current fragmentation of systems, inconsistencies in the definition and use of data and the overall lack of a common understanding of what needs to be standardised. This is particularly true for airport and airspace user support services such as ground handling, de-icing and others, which form an integral part of the overall collaborative decision-making process. It limits the coordination between the parties in prioritising the allocation of resources. The result is inefficient and non-collaborative use of the available capacity, and a lack of flexibility to cope with unusual occurrences. Standardised information models: The current European ATM system lacks a standardised (digital) information format and model. This is manifested in the lack of consistency of the information contained in various databases. It is also a severe weakness for a network which aims to share information to improve services and introduce advanced automation. A well-defined, consistent information structure which enables a cohesive set of databases to be used is needed. Availability, sharing and management of information: Initial steps have been taken to improve coordination between stakeholders in order to build 4-D traffic pictures. The operation is hindered, however, by the limited availability of information and constraints on the sharing of information between the stakeholders, as well as the fragmentation of airspace and the resulting inefficient coordination processes between all participants. Overall poor information sharing and management prevents proper coordination between all stakeholders, resulting in less effective use of available assets and thereby hidden costs to the airspace users in the form of operational inefficiencies. New technologies: The current technologies in operation can, to a limited extent, support growth within the current ATC paradigm, but the implementation of new technologies, together with a change of paradigm for the performance of ATM, is considered essential to support traffic growth of the 4 The collection and management of information from one or more sources and the distribution of that information to one or more audiences. Management means the organization of and control over the structure, processing and delivery of information. (Wikipedia) 19 of 71

20 forecast level. The legacy information architecture and technology cannot easily adapt to the use of up-to-date methods for data exchange, and will need to evolve bearing in mind the security requirements considered necessary to meet emerging cyber security threats. 4.2 SWIM and the future European ATM system The European air traffic management system is operating close to its capacity limit and is faced with the challenge of continuously growing air transport demand. In order to meet all of the goals set by the European Commission 5 and strengthen the air transport value chain, the airspace users requirements need to be better accommodated. To this end, each flight must be executed as closely aligned with the intentions of its owner as possible, while at the same time maximising network performance. This is the main driving principle for the future European ATM system, which is centred on the characteristic of the business trajectory (known in the military as the mission trajectory ) representing an airspace user s intentions with respect to a given flight. There is a need to validate and deploy the new capabilities in the period. Based on the main drivers for performance improvements (flight efficiency, productivity increase, increased predictability...), the following list of 5 high priority strategic business needs driven by operational needs across stakeholder groups was identified 6 : 1. Traffic Synchronization Traffic synchronisation covers all aspects related to improvements in arrival/departure management and sequencing in en-route and TMA environments to achieve an optimized traffic flow resulting in significantly fewer tactical ATC interventions, and the optimisation of vertical traffic profiles. As a consequence flights are able to fly closer to their optimum trajectories and thus improving predictability, efficiency, safety, capacity, and environmental impact. 2. Airport Integration and Throughput Integrated Airport Management aims at achieving the full integration of airports into the ATM network as nodes in the ATM system, ensuring a seamless process through CDM. Airports will contribute to achieving SESAR performance goals through the increase of runway throughput and improved surface movement management in combination with Trajectory Management, Airborne Spacing tools and precision navigation techniques, e.g. reducing air and ground holding, leading to reduced noise and environmental emissions per flight. 3. Moving from Airspace to 4D Trajectory Management Moving from Airspace to Trajectory Management entails the systematic sharing of aircraft trajectories between various participants in the ATM process to ensure that all partners have a common view of a flight and have access to the most up-to-date data available to perform their tasks. It enables the dynamic adaptation of airspace characteristics to meet predicted demand whilst adjustments to the business/mission trajectories are kept to a minimum. Whenever possible, necessary tactical interventions are considered at the gate to gate trajectory level and not just at 5 The EC's political vision and goals for the design of the future ATM system: Enable a 3-fold increase in capacity which will also reduce delays, both on the ground and in the air, Improve the safety performance by a factor of 10, Enable a 10% reduction in the effects flights have on the environment and Provide ATM services at a cost to the airspace users which is at least 50% less. 6 A Tiger Team was formed to profile and review SESAR priorities on the basis of the business needs of service providers and to suggest and explore opportunities to further enhance Programme Management principles to implement those priorities. With this goal in mind, the team reviewed Programme data, including planning information provided by projects. As a result of this exercise, 5 priority strategic business needs were identified. 20 of 71

21 sector level. This holistic approach minimizes the negative impact on the trajectories concerned as well as on the Network. This is based on the operational and technology scope definition of the trajectory management framework, its content, performance and access across all flight phases and associated concept and technology developments. The SESAR Trajectory Management Framework (TMF) specifies the structure needed to achieve the safe and efficient creation, amendment and distribution of the Reference Business/Mission Trajectory (RBT/MT) including the RBT/MT information content & quality, the Actors involved, and the Services associated with trajectory information (e.g. creation, proposed revision and update processes). 4. Network Collaborative Management and Dynamic/Capacity Balancing Enhanced Network Management through a dynamic, on-line, collaborative NOP fully integrated with AOP considering all relevant actors planning aspects including airports, airspace users, decision makers, etc. The Network Manager assesses the development of traffic and airspace demand, identifies capacity/traffic imbalances, develops ATFCM scenarios for capacity shortfalls through an Airport-CDM process involving all concerned actors and publishes the agreed scenarios in the NOP. When necessary he proposes modified routes to aircraft operators based on the published alternative routes. Aircraft Operators then submit their revised user preferred trajectories integrating the ATFCM constraints. The Network Manager monitors demand capacity imbalances, liaises with Local Traffic Managers, TWR/ACC Supervisors and APOCs to take appropriate actions for demand capacity balancing. NOP and AOP are then updated accordingly. This linking of AOP/NOP parameters (ABT and User Preferred Trajectory) optimise the network and airport management by timely and simultaneously updating AOP and NOP via SWIM, providing Network and Airport Managers with a commonly updated, consistent and accurate Plan. The NOP becomes the Information Delivery Service Unit for all planning units in the Network: Airport Operators, ANSPs, Airspace Users and Network Manager. Throughout the lifecycle of a flight, a layered and collaborative planning consists of successive planning phases from long term to medium and short term, involving all ATM stakeholders in Collaborative Decision Making (CDM) processes to progressively build the Network Operation Plan (NOP) through the sharing of more and more up to date and precise data once the day of operations approaches. As the day of operation nears, the Aircraft Operator s plans and the details regarding airspace management become richer in detail and vary less. For military flights, if a specific airspace configuration is needed, it is fully integrated into the trajectory description. A collaborative planning process is applied to the trajectory in a number of iterations, refining it with constraints arising from new and more accurate information. If ATM constraints have to be applied, the preferred way to integrate them is through a collaborative process that encompasses the Airspace Users in order to achieve the best business or mission outcome. 5. Conflict Management and Automation Conflict Management and Automation aims at substantially reducing controller task load per flight, while meeting safety and environmental SESAR goals without incurring significantly higher ANSP costs, through an increase in ATM automation. However, human operators will remain at the core of the system (overall system managers) using automated systems with the required degree of safety, integrity and redundancy. 21 of 71

22 System Wide Information Management (SWIM) integrating all ATM business-related data, the SWIM environment underpins the entire European ATM system and is essential to its efficient operation. This includes aircraft and all ground facilities. It will support these 5 high priority strategic business objectives by making possible efficient end-user applications to exploit the power of shared information. SWIM will completely change how information is managed throughout its lifecycle across the ATM system. SWIM is a key enabler for the future SESAR system, and as such SWIM enables direct business, operational and technical ATM benefits as represented in the following figure. ATM KPA cost efficient new operational opportunities improvements technical improvements flexibility better situational awareness trust security SWIM enablers governance, infrastructure, standards cheaper design early adoption improved system performance secure access secure exchange improved decision making interoperable Figure 3: Overview of SWIM benefits As depicted in Figure 4, SWIM will enable technical improvements, e.g. cheaper design, early (or easier) adoption, etc. These technical improvements will in turn enable operational improvements such as better shared situational awareness. The operational improvements will contribute to the ATM Key Performance Areas (KPA) identified in the SESAR Programme. SWIM enables better financial performance and unlocks new opportunities. By using mainstream technologies, open formats and standardised interfaces, it is expected to reduce the costs associated with the development and deployment of new applications and services. The service standardisation will facilitate the reuse of information in other contexts, thus contributing to cost efficiency. The increased interoperability of data formats and interfaces will make a modular system architecture possible, in which domain systems from different manufacturers can be seamlessly connected, eliminating the need for expensive tailor-made interfaces. Four examples are provided hereafter on how SWIM can contribute to the aforementioned benefits and improvements. Although these examples initially do not require complete SWIM implementation, their full potential can only be realized in a SWIM environment. Network Operations Plan (NOP) 22 of 71

23 The Network Operations Plan (NOP) B2B interface is the DNM web interface for system to system interoperability. This DNM web interface separates the information provision from the information consumption, is based on open standards (e.g. AIXM) as well as mainstream IT technologies (Web Services) and is fully SOA compliant. The DNM NOP B2B is already operational and demonstrates the added value of SWIM concepts. Therefore, the DNM NOP B2B is considered as a SWIM pioneer and a first step on the way to the full deployment of SWIM. Airport Collaborative Decision Making (A-CDM) Every airport currently implementing A-CDM may have its own interfaces with ground handlers, airline operators, MET service providers, etc. This implies that an airline operator serving several airports may have to implement several bespoke interfaces to participate in each airport s A-CDM process. By standardizing the interfaces, participation will become easier and cheaper. SWIM will bring a coordinated approach to standardisation across stakeholder groups to ensure interoperability. Initial Trajectory Information Sharing (i4d) - Ground / Ground exchanges The implementation of this concept will require exchanges of information between aircraft and FDPS systems and among the FDPS systems themselves. SWIM will enable such FDPS information exchanges required for the implementation of i4d. Digital NOTAM At any given moment globally more than 20,000 NOTAMs (on average) are in force today. These NOTAMs are text messages that can hardly be automatically processed for a variety of reasons. In order to allow the electronic exchange and processing of NOTAMs, encoding rules have been standardised as part of the digital NOTAM concept. With the digital NOTAM it will be possible to combine, filter and fuse the NOTAM information with other digital information sources that are also being standardised (meteorological, airport mapping, etc). This will enable the development of new services or the improvement of existing ones like the following: DMAN Pre-flight briefing The taxiways that can be provided by DMAN systems currently might not take into account the restricted / forbidden areas (e.g. work in progress). The processing of digital NOTAMs by DMAN would improve the guidance provided by such systems by taking into account the current status and avoiding conflict situations (e.g. an aircraft taxiing into a restricted / forbidden area). At present flight crews may receive Pre-flight Information Bulletins (PIBs) of around pages for an intra-european flight. Between 40% and up to 90% of the information given in PIBs has no direct impact on the flight for which it was provided. Yet the probability of pilots not being aware of important and pertinent NOTAM is increasing. In the case of pre-flight information bulletins, digital NOTAMs will make it possible to better accommodate human factors in the design of the pre-flight briefing process, such as: prioritise information by criticality; organise information by item concerned (runway, gate, etc.); embed graphics where appropriate ("a picture is worth a thousand words") and even completely graphical PIBs may be possible; better filtering capabilities compared to what can currently be achieved (this will reduce the potential for information overload and the time spent on analysing irrelevant information) SWIM will further ease the exploitation of digital NOTAMs for the benefit of the entire European ATM system. 23 of 71