SWIM Concept of Operations - Eurocontrol · This document describes the SWIM Concept of Operations. It provides the definition of SWIM and related aspects such as the vision, principles,

SWIM Concept of Operations

Document information

Project Title Operational Requirements & Demands concerning organisation of the ATM Information Management within the scope of the European ATM Enterprise Architecture

Project Number 08.01.01

Project Manager EUROCONTROL

Deliverable Name SWIM Concept of Operations

Deliverable ID D41

Edition 00.03.03

Template Version 03.00.00

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 use-cases 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.

Project Number 08.01.01 Edition 00.03.03 D41 - SWIM Concept of Operations

2 of 71

©SESAR JOINT UNDERTAKING, 2011. 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. Reprint with approval of publisher and the source properly acknowledged.

Authoring & Approval Prepared By - Authors of the document.

Name & Company Position & Title Date

Pedro Cruellas / EUROCONTROL Project member 10/04/2013

Eric Roelants / EUROCONTROL P08.01.01 Project manager 10/04/2013 Reviewed By - Reviewers internal to the project.


Stéphane Dubet / DSNA P08.01.01 Project member 10/04/2013

Jan-Philippe Lauer / DFS P08.01.01 Project member 10/04/2013

Pedro Cruellas / EUROCONTROL P08.01.01 Project member 10/04/2013

Susanne Biermann-Hoeller / DFS P08.01.01 Project member 10/04/2013

Sam Van Der Stricht / EUROCONTROL P08.01 Project manager 10/04/2013

Eric Roelants / EUROCONTROL P08.01.01 Project manager 10/04/2013

Reviewed By - Other SESAR projects, Airspace Users, staff association, military, Industrial Support, other organisations.


Dirk Janssens / EUROCONTROL P14.04 Project manager 10/06/2013

Alex Petrovsky / EUROCONTROL P08.01.01 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 P08.03.10 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.


Dirk Janssens / EUROCONTROL P14.04 Project manager 10/06/2013

Alex Petrovsky / EUROCONTROL P08.01.01 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 P08.03.10 Project Manager 10/06/2013


3 of 71



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 P08.01.01 Project member 10/06/2013

Pedro Cruellas / EUROCONTROL P08.01.01 Project member 10/06/2013

Susanne Biermann-Hoeller / DFS P08.01.01 Project member 10/06/2013

Sam Van Der Stricht / EUROCONTROL P08.01 Project manager 10/06/2013

Eric Roelants / EUROCONTROL P08.01.01 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

00.01.01 24/01/2012 Draft Eric Roelants Consolidation of different chapters in one document

00.01.02 01/02/2012 Draft Eric Roelants Update of sections: abstract, executive summary, introduction chapters, needs and benefits, assumptions

00.01.03 03/02/2012 Draft Eric Roelants Minor lexical modifications

00.01.04 06/02/2012 Draft Eric Roelants Update of assumptions chapter

00.01.05 06/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 - D35

00.01.06 07/02/2012 Draft Eric Roelants Changes from proofreading. Update on assumptions.

00.01.07 09/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)

00.01.08 13/02/2012 Draft Eric Roelants Update on comments of Stéphane (e.g. chapter 4). Update during webex.

00.01.09 13/02/2012 Draft Eric Roelants Update of drawings 5-6-7 in ‘SWIM in practice’ chapter

00.01.10 14/02/2012 Draft Eric Roelants Included comments from Georg. Update of terms:


4 of 71



SWIM Node and SWIM common component during webex of 14 Feb. 12

00.02.00 14/02/2012 Final Eric Roelants Status to Final version

00.02.01 18/04/2012 Draft Eric Roelants Update comments SJU

00.02.02 20/04/2012 Draft Pedro Cruellas Requirements and assumptions in formal statements (appendix – engineering artefacts)

00.02.03 08/06/2012 Final Eric Roelants On request of SJU, removed in 5.1.1. 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

00.02.04 11/10/2012 Final Pedro Cruellas Integration of a subset of SJU comments to ed 00.02.00

00.02.05 05/11/2012 Draft Eric Roelants Update on the complete set of comments, after meeting 24/10/2012

00.02.06 07/11/2012 Draft Pedro Cruellas Update of use-case 12, lifecycle of a service and additional changes following meeting 21/10/2012

00.02.07 07/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.

00.02.08 25/01/2013 Final draft Eric Roelants Added SWIM Key Principles from the A6

00.02.09 06/02/2013 Final draft Eric Roelants Key Principles review after webex.

00.03.00 06/02/2013 Final Eric Roelants Final version.

00.03.01 29/04/2013 Final Eric Roelants Update following comments SJU, National Authorities and EASA.

00.03.02 13/06/2013 Final Eric Roelants Update following comments F2F meetings on 10th and 11th June (with A6).

00.03.03 20/06/2013 Final Jan-Philipp Lauer Proofreading and editorial changes


5 of 71



Intellectual Property Rights (foreground)

This deliverable consists of SJU foreground.

© SESAR JOINT UNDERTAKING, 2013. 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.


6 of 71



Table of Contents

EXECUTIVE SUMMARY .................................................................................................................................... 9

1 INTRODUCTION ........................................................................................................................................ 10

1.1 BACKGROUND ....................................................................................................................................... 10

1.2 PURPOSE OF THE DOCUMENT .............................................................................................................. 10

1.3 INTENDED READERSHIP ........................................................................................................................ 10

1.4 INPUTS FROM OTHER PROJECTS .......................................................................................................... 10

1.5 ACRONYMS AND TERMINOLOGY ........................................................................................................... 11

2 VISION AND DEFINITION ....................................................................................................................... 15

2.1 VISION ................................................................................................................................................... 15

2.2 SWIM DEFINITION ................................................................................................................................ 15

3 SWIM PRINCIPLES .................................................................................................................................. 16

4 SWIM CONTRIBUTION TO THE FUTURE EUROPEAN ATM SYSTEM ........................................ 18

4.1 CURRENT SYSTEM AND SITUATION ....................................................................................................... 18

4.1.1 Current ATM system .................................................................................................................. 18

4.1.2 Information management in the European ATM system ...................................................... 19

4.1.3 Weaknesses of current information management in ATM ................................................... 19

4.2 SWIM AND THE FUTURE EUROPEAN ATM SYSTEM ............................................................................ 20

5 SWIM IN PRACTICE ................................................................................................................................. 24

5.1.1 SWIM Technical Infrastructure ................................................................................................ 25

5.1.2 SWIM Use case timeline ........................................................................................................... 27

5.1.3 SWIM Actors and their roles ..................................................................................................... 31

6 SWIM GOVERNANCE .............................................................................................................................. 34

7 IMPLEMENTING SWIM THROUGH GRADUAL CHANGE ............................................................... 35

8 REFERENCES ........................................................................................................................................... 37

APPENDIX A DETAILED DESCRIPTION OF THE GOVERNANCE GROUPS ............................... 38

A.1 SWIM STEERING GROUP..................................................................................................................... 38

A.2 SWIM COMPLIANCE GROUP ................................................................................................................ 39

A.3 SWIM STANDARDS AND ARCHITECTURE GROUP ............................................................................... 40

A.4 SWIM ASSESSMENT GROUP ............................................................................................................... 41

A.5 SWIM TECHNICAL MANAGER GROUP ................................................................................................. 42

APPENDIX B OUTSTANDING QUESTIONS ......................................................................................... 43

APPENDIX C ASSUMPTIONS ................................................................................................................. 44

C.1 GENERAL ASSUMPTIONS ...................................................................................................................... 44

C.2 SWIM REGISTRY .................................................................................................................................. 44

C.3 DESIGN ASSUMPTIONS ......................................................................................................................... 44

C.4 INFORMATION AND SERVICE MANAGEMENT .......................................................................................... 45

APPENDIX D USE CASES ....................................................................................................................... 47

D.1 UC01 A STAKEHOLDER JOINS SWIM .................................................................................................. 47

D.2 UC02 THE “SWIM COLLABORATION AUTHORITY” ASSESSES A STAKEHOLDER ................................. 48

D.3 UC03 A STAKEHOLDER PROPOSES A NEW OR UPGRADED SERVICE DEFINITION ................................ 50

D.4 UC04 THE “SWIM COLLABORATION AUTHORITY” MANAGES THE LIFECYCLE OF THE REFERENCE MODELS (AIRM / ISRM) .................................................................................................................................. 52

D.5 UC05 A PROVIDER PROPOSES A NEW OR UPGRADED SERVICE INSTANCE ......................................... 54


7 of 71



D.6 UC06 A PROVIDER DEVELOPS A NEW SERVICE INSTANCE .................................................................. 55

D.7 UC07 A STAKEHOLDER UPGRADES THE SWIM INFRASTRUCTURE. .................................................... 56

D.8 UC08 THE “SWIM COLLABORATION AUTHORITY” / PROVIDER ASSESSES THE COMPLIANCE OF A SERVICE INSTANCE ........................................................................................................................................... 58

D.9 UC09 A PROVIDER DEPLOYS A NEW OR UPGRADED SERVICE INSTANCE ON THE SWIM INFRASTRUCTURE ............................................................................................................................................. 59

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 ...... 63

D.12 UC12 THE SWIM COLLABORATION AUTHORITY DEPRECATES A SERVICE DEFINITION .................. 64

APPENDIX E ENGINEERING ARTEFACTS ......................................................................................... 67

E.1 REQUIREMENTS IN THE MAIN PART OF THE DOCUMENT ....................................................................... 67

E.2 GENERAL ASSUMPTIONS ...................................................................................................................... 67

E.3 SWIM REGISTRY ASSUMPTIONS .......................................................................................................... 67

E.4 DESIGN ASSUMPTIONS ......................................................................................................................... 68

E.5 INFORMATION AND SERVICE MANAGEMENT ASSUMPTIONS .................................................................. 70


8 of 71



List of tables Table 1 SWIM Actors description .......................................................................................................... 31

Table 2: Description of the main roles .................................................................................................. 32

Table 3: Actors and their main roles in SWIM....................................................................................... 33

List of figures Figure 1: The aspects that are brought together by SWIM ................................................................... 16

Figure 2: Inter-relationships and connectivity in today's European ATM System ................................. 18

Figure 3: Overview of SWIM benefits ................................................................................................... 22

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. .................................. 22

Figure 4: Service aspects ...................................................................................................................... 25

Figure 5: SWIM-TI high-level architecture ............................................................................................ 26

Figure 6: Use-cases part 1 .................................................................................................................... 27

Figure 7: Use-cases part 2 .................................................................................................................... 28

Figure 8: Normal lifecycle of a SWIM service ....................................................................................... 30

Figure 9: Proposal for a SWIM Governance Structure ......................................................................... 38


9 of 71



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.


10 of 71



1 Introduction

1.1 Background Within the scope of P08.01.01, 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 "use-case 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 P08.01.01, P08.03.10 and P08.01.03) • WP14 (specially for P14.04, P14.01.03 and P14.01.04)

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 • P08.03.10 Information Services Reference Model • P08.01.03 ATM Information Reference Model


11 of 71



• WP14 Technical and Technological Aspects • 14.2.9.D03-SWIM Technical Infrastructure Definition-00.01.02.doc • 14.1.4.D05 SWIM technical requirements specification for Step1-update1_edn00.02.00.doc

1.5 Acronyms and Terminology

Term Definition

AIRM ATM Information Reference Model

AOP Airport Operations Plan

ATM Air traffic management

ATM Service 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).

B2B Business to Business

Capability 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)

DNM EUROCONTROL Directorate Network Manager (former CFMU)

E-ATMS European air traffic management system

ISRM Information Service Reference Model

NFR Non-functional requirement

NOP Network Operations Plan

SACG SWIM Architect Co-ordination Group

Service 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)

Service attribute A Service Attribute defines a property of a service. Examples: Response time, Frequency of invocation, Message Exchange Pattern. (source: B4.3 T5 study)

Service contract 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)

Service interface 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


12 of 71



Term Definition

in the service interaction. (source: B4.3 T5 study)

Service Level 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)

SESAR Single European Sky ATM Research Programme

SESAR Programme The programme which defines the research and development activities and projects for the SJU

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 Definition

Architecture principles

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


13 of 71



Term Definition

which is shared (among SWIM-TI nodes), such as the registry.

Certificate 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).

Common Components

The common components implement shared capabilities to all the distributed SWIM nodes.

Governance Ability of decision-makers to set policies regarding stakeholders, services, and their relationships

Legal recording Secure log recording for legal use

Policy Principle or rule with a view to guiding decisions and achieving one or more rational outcomes

Policy enforcement Action to compel the application of a policy

Registry 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 P08.03.02 – D19 for more information on the registry)

Service A service is constituted by a service definition, implemented by zero, one or several service instances.

Service definition Service specification as it appears in the service catalogue.

Service instance 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)

Service catalogue A set of the service instances and service definitions available through SWIM.

Service implementation

Process for the implementation of a service instance

Service Level List of values of every non functional requirement for a service

ATM-specific 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.

Enabling service A service provided by the SWIM-TI

Service version Version of a service


14 of 71



Term Definition

Service status The current phase of a service in its life cycle

Lifecycle The lifecycle defines the sequence of phases.

SLA monitoring Monitoring to ascertain that the actual behaviour of a service instance complies with its specified service level agreement

SWIM 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.

SWIM Infrastructure The sum of all the SWIM infrastructure elements which are needed to support SWIM services

SWIM Common Component

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 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-TI SWIM technical infrastructure, a synonym of SWIM infrastructure

SWIM-TI capability A given type of SWIM-TI system functionality

SWIM node 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.


15 of 71



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.


16 of 71



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 Principles1 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.


17 of 71



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. 2

10. 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 92-894-8389-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


18 of 71



4 SWIM contribution to the future European ATM syst em 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

4.1.1 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 t oday'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.


19 of 71



• 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

4.1.2 Information management in the European ATM sy stem 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 information4 in order to provide the decision makers and information users with the right information at the right time and in the right place.

4.1.3 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)


20 of 71



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 Commission5 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 2015-2025 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 identified6: 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.


21 of 71



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/Cap acity 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.


22 of 71



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.

costefficient

flexi-bility

secureexchange

secureaccess

interoperable

governance,

infrastructure,

cheaperdesign

standardsearly

adoptionsecurity

new opportunities

bettersituational

aware-ness

improveddecision making

improvedsystemperfor-mance

trust SWIM enablers

technicalimprovements

operationalimprovements

ATM KPA

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)


23 of 71



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 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).

Pre-flight briefing

At present flight crews may receive Pre-flight Information Bulletins (PIBs) of around 10-50 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.


24 of 71



5 SWIM in practice In order to build SWIM (i.e. SWIM in practice) the following elements are needed:

• Standards: an ATM information model representing the standard definitions of all ATM information, through harmonised conceptual and logical data models. In the context of the SESAR Programme, this is instantiated in the AIRM (ATM Information Reference Model); an ATM services model representing the logical breakdown of required information services and their behavioural patterns. These services are also called ATM-specific services. The SESAR Programme has decided to instantiate these services in the ISRM (Information Service Reference Model);

• Governance: information management functions, such as operational and organisational functions for the management of user identities, discoverability of resources, security solutions for aspects such as authentication, encryption and authorisation, notification services and registration. These functions need to be defined to support information sharing. The SWIM governance functions affect almost all of the roles and their interactions within the European ATM system;

• Infrastructure: the SWIM technical infrastructure (SWIM-TI) is the interoperable (runtime) infrastructure (ground/ground and air/ground) over which SWIM services are provided and ATM data are distributed, shared and consumed. Its implementation may, depending on the specific needs profile, differ from one stakeholder to another in terms of scope and type of implementation. SWIM Air/Ground will allow aircraft to access ground-based SWIM. It will complement the existing datalink applications (e.g. CPDLC) that provide end-to-end data exchange capabilities between aircraft and the ground. SWIM Air/Ground will enable information sharing between aircraft and multiple ground SWIM enabled systems. For the time being, the scope of SWIM A/G does not cover time-critical services. The SWIM Technical Infrastructure will mostly be based on commercial off-the-shelf (COTS) standards-based and interoperable products and services, but it is possible that in some cases specific software may need to be developed;

• SWIM-enabled applications: the application of SWIM standards and principles to the interfaces of ATM applications enables ATM business benefits by assuring the provision of commonly understood high quality information to the right people at the right time.

As described in Chapter 3 (SWIM principles), SWIM is built based on a number of principles driving its definition and design. One of the key principles is the service oriented approach, which aims to use the service concept to describe ATM information exchanges among domain systems in the European ATM system. In this context (ref Error! Reference source not found. ), a service can be described using various perspectives or aspects:

• The business aspect of a service generally addresses the reasons for the service and is therefore related to its goals and value proposition. The business aspect can also address the business and legal entities which provide and use the service, i.e. the ATM stakeholders.

• The operational aspect of a service describes what the service is about, and how it relates to operational processes in European ATM and the surrounding environment. This description acts as input for determining how the service is to be implemented.

• The solution aspect of a service defines how it is provided within European ATM. This includes a determination of the appropriate level of automation.

• Timelines are of course also important so that there can be agreement on when the various services will be available.


25 of 71



Figure 5: Service aspects

5.1.1 SWIM Technical Infrastructure 7

The SWIM Technical Infrastructure (SWIM-TI) contributes to the services’ solution aspects providing capabilities in support of effective and secure ATM-specific service provision and consumption among SWIM-enabled domain systems. SWIM-enabled domain systems collaborate using a ATM-specific services and this collaboration is supported by technical capabilities offered by the SWIM-TI.

The SWIM-TI is a set of software components distributed over a network infrastructure providing capabilities enabling collaboration among domain systems. These capabilities are instantiated in a set of SWIM nodes (stakeholders’ endpoints) and common components (providing capabilities to all the distributed SWIM nodes):

• The SWIM node concept therefore represents a bundle of SWIM-TI capabilities, allowing a given domain system to use the SWIM-TI.

• Examples of common components are:

• the registry, which is used to enable the sharing of information (metadata) about services at design time;

• the public key infrastructure (PKI) that aims to manage the trusted digital certificates which will be used.

7 Although it is recognised that a section for the SWIM-TI (SWIM Technical Infrastructure) should logically be placed in an architecture document, it has been considered important to place a minimum of information in this document to achieve a self-contained document. The justification for such a decision is based on the fact that a number of assumptions concerning the Information Management functions (the IM part in the SWIM acronym) demand some high level architecture concepts. Moreover, it is also expected that the information provided can contribute to dispel from this high-level document a number of misunderstandings and wrong expectations concerning what SWIM is and what it provides.


26 of 71



SWIM Enableddomain System

Distributed SWIM Nodes

SWIMNode

SWIMNode



SWIMNode


Physical deployment

1

2

3

CommonComponents

Registry

PKI

Figure 6: SWIM-TI high-level architecture

As depicted in Figure 6, the SWIM node logical architecture component can physically be deployed/instantiated in various ways. These options are highlighted with dotted blue lines in Figure 6. We can thus have:

• The case represented by SWIM node 1. In this case the SWIM node is deployed as a software component integrated together with other software components of the domain system.

• The case represented by SWIM nodes 2 and 3. In this case the SWIM nodes are deployed in their own dedicated environment, which is independent of the software components of the domain system.


27 of 71



5.1.2 SWIM Use case timeline

In the interests of readability, the description of the time-line makes reference to only three actors: service consumer, service provider and “SWIM Collaboration Authority8” (the actors may need to be changed for the runtime use-cases).

The following two diagrams represent the SWIM use-cases in a common diagram to showcase their interactions.

Look for information

Register as service

consumer

service consumer

SWIM authority

Receive access to registry

Registration is evaluated

service provider

Look for information

Register as service provider

Propose a new service

instance

request for a new service instance is evaluated

Lifecycle Process

Update of standards

(ISRM, AIRM,..)

request for a new service definition

is evaluatedRegistry

published services

Registrydefinitions


defintion

Registrystakeholders

Registryinstances

Develop the service

instance

Registryservicestatus

Upgrade SWIM

infrastructure

plan update of TIplan update of TI

Receive access to registry

UC01

UC02


defintion

UC03

UC04

UC05 UC06

UC07

Step, tinked to runtime or Technical Infrastructure

use-case grouping of the steps Optional stepuse-case reference Step of the process

Figure 7: Use-cases part 1

8 The SWIM “authority” can be authoritative either through consensus or regulation. Authority through consensus means that all stakeholders agree on the authoritative nature of the ‘SWIM Authority’.


28 of 71



Evaluate access to service

Identify required service

consume the service

instance

Negotiate with service

consumer

Request access to

the service

‘authority’ can perform actions in name of consumer / provider

Registryinstances

Decommision the service

instance

Stop using the service

instance

Registryinstances service status

Registryrelations

stakeholders services

Deploy the service

instance

Registryservice status

Validate Service instance

compliance

Provide the service

instance

upgrade SWIM infrastructure

coordinate update of TI

Develop consuming part of

the service

UC08 UC10

UC07

UC11

UC09

Registryservice status

service consumer

SWIM authority

service provider

Upgrade SWIM

infrastructure

UC07

Step, tinked to runtime or Technical Infrastructure

use-case grouping of the steps Optional stepuse-case reference Step of the process

Figure 8: Use-cases part 2

Whilst any ATM Stakeholder can potentially provide or consume SWIM Services, the maintenance of a list identifying recognised providers will provide assurance to consumers. There may also be benefit to consumers to be similarly identified. In order to gain such recognition, service providers and consumers need to register. [UC01: Stakeholder joins SWIM]. The “SWIM Collaboration Authority” will evaluate the registration request and will be able to accept or deny it on the basis of predefined criteria [UC02: “SWIM Collaboration Authority” assesses a stakeholder].

Whilst the provision of a service will be the responsibility of the provider, those recognised as being “SWIM-compliant”, will provide assurance of standardisation to consumers.

For a service offered as “SWIM-compliant”, its definition will first need to be "standardised" (AIRM, ISRM or future service catalogue/portfolio). The proposal to "standardise" a service definition can be submitted by a service consumer or a service provider or the “SWIM Collaboration Authority” itself (e.g. in order to include as a SWIM "standard" a service definition which has been defined by the FAA) [UC03: A stakeholder proposes a new or upgraded service definition]. Once it is "standardised"[UC04: The Collaboration Authority manages the life cycle of the reference models (AIRM/ISRM)], such a service can, in principle, be "instantiated" by one or more service providers as a service instance.

A service provider who wants to provide a “SWIM Compliant” service instance, i.e., to instantiate the corresponding standardised service definition, must first submit the corresponding request to the “SWIM Collaboration Authority”. The “SWIM Collaboration Authority” will evaluate the request and, depending on predefined criteria, will accept or deny it [UC05: A provider proposes a new or upgraded service instance].

Once the “SWIM Collaboration Authority” accepts this request from the service provider, the service provider can start development of the service instance [UC06: A provider develops a new service instance] and [UC07: A stakeholder upgrades the SWIM infrastructure]


29 of 71



For compliance, a service instance, once its development is completed, will need to be assessed9 [UC08: The “SWIM Collaboration Authority” / provider assesses the compliance of a service instance], i.e. it will need to be checked that such a service is compliant with the corresponding standard. After assessment, the service can be deployed [UC09: A provider deploys a new or upgraded service instance]. Such compliance assessment will be performed in accordance with the policy defined by the “SWIM Collaboration Authority”. Proposed upgrades of the SWIM infrastructure will need to be carried out by the stakeholders concerned [UC07: A stakeholder upgrades the SWIM infrastructure].

Once a service instance is deployed by a service provider, the service instance is available for consumption by service consumers.

A service consumer, becoming aware of the availability of a given service instance, may request access. Once access is authorised, the service consumer can use the service. However, consumers can naturally make the necessary preparations to use the service beforehand. [UC10: A consumer prepares to use a service via the SWIM infrastructure], [UC07: A stakeholder upgrades the SWIM infrastructure].

As time goes by service instances are expected to be decommissioned, for example because no service consumers are using it anymore, because the corresponding service provider has planned to replace it with a new service, or for any other reason. Providers of service instances that are planned to be decommissioned will need to make appropriate decommissioning plans [UC11: A provider decommissions a service instance]. Such plans will need to foresee (among other things) informing current and potential service consumers of the planned decommissioning date so that they may plan accordingly.

Finally, a service defined in the ISRM (or future service catalogue/portfolio) can at any given point in time be ‘deprecated’ [UC12: The SWIM Collaboration Authority deprecates a service definition]10. There can be different reasons to deprecate a service definition in the ISRM: for example because there is no service instance implementing it anymore, because it refers to data models or other service definitions that are themselves ‘deprecated’, etc.

The SWIM Registry will fully support the processes described including indications of SWIM Compliance.

In line with the descriptions above, the normal SWIM service lifecycle will be as follows:

9 For such assessments the EN ISO/IEC 17000 series of international standards on conformity assessment may provide valuable guidance. 10 This Use Case is not represented in the Use Cases figure above.


30 of 71



Servicedefinition proposal

accepted?

Service definitionnot part of ISRM

Servicedefinitionproposed

Definition of the service

Servicedefinedin ISRM

Serviceimplementation

requested

ServiceImplementation

requestaccepted?

Implementation of the service

Serviceinstance

implemented

ServiceInstance achievesSWIM Compliancy

level?

Service instance compliance assessment

Provision of the Service

Decommission of the service

instance

Serviceinstance

decommissioned

Deprecation of the service definition

Servicedefinition

deprecated

Yes

No

Yes

Yes

No

The service can be put into operations as non SWIM

compliant

No

If implemented, service instance can not be SWIM compliant

Not in scope of SWIM

No

Event

Process

Legend

Figure 9: Normal lifecycle of a SWIM service


31 of 71



5.1.3 SWIM Actors and their roles To describe SWIM actors and their main roles, a matrix that sets out actors and roles is provided here. To ensure alignment with existing documents on ATM actors, this list of actors is an extract from the Global Air Traffic Management (ATM) Operational Concept (ICAO Doc 9854). Additions to the ICAO Doc 9854 content are stated in notes in the table below.

Actor Description

Aerodrome community Aerodromes, the aerodrome operator and other parties involved in the provision and operation of the physical infrastructure needed to support the take-off, landing and ground handling of aircraft.

Airspace providers

Airspace providers generally refers to Contracting States in their capacity as airspace owners with the legal authority to allow or deny access to their sovereign airspace; it may also apply to organizations of States that have been assigned responsibility for establishing the rules and guidelines for the use of airspace.

Airspace users The term ‘airspace users’ mainly refers to the organizations operating aircraft and their pilots.

ATM service providers

ATM service providers comprise all those organizations and personnel (e.g. controllers, engineers, technicians) that are engaged in the provision of ATM services to airspace users. ATM service provider responsibilities include CNS/ATM facility planning, investment and implementation, procedure development, training; and ongoing system operation and maintenance of seamless CNS/ATM services. Note: This would include ANSPs and EUROCONTROL.

ATM support industry

The ATM support industry comprises all those organizations that offer systems and services used by ATM service providers to provide CNS/ATM facilities and seamless services that achieve the ATM operational concept vision. Note: This group includes companies like Jeppesen, Lufthansa Systems, etc.

ICAO

The aims and objectives of ICAO in accordance with Article 44 of the Convention on International Civil Aviation are to develop the principles and techniques of international air navigation and foster the planning and development of international air transport. ICAO is also responsible for the adoption and amendment of relevant international SARPs and procedures.

Regulatory authorities The aviation regulatory authorities include: aviation safety regulators, certification authorities (e.g. aircraft, systems, pilots, controllers, maintenance technicians), standardization organizations, environmental regulators and independent accident/incident investigation authorities.

States

States are generally responsible for acting as the regulatory authority, airspace provider and ATM service provider for aviation activities within their sovereign airspace and in the flight information regions for which they are responsible. This may be subject to special institutional arrangements (e.g. multinational regulatory organizations, harmonized airspace planning and organization across several States, and autonomous ATM service providers).

Table 1 SWIM Actors description We also focussed on the main roles in SWIM for these actors. It is understood that any of the actors can perform any of the roles (in most cases).


32 of 71



Below is a description of the main roles within the SWIM context:

Role Details Description

Consuming Consuming an ATM specific service Consumes an ATM information service Operating

SWIM nodes A SWIM Node is a logical collection of SWIM-TI capabilities.

SWIM common components (e.g. registry) Operating a SWIM shared capability supporting the SWIM infrastructure

ATM specific services Operating specific ATM services as a provider

Developing

SWIM nodes

Developing a logical collection of SWIM technical infrastructure capabilities supporting one or several services

SWIM common components (e.g. registry) Developing a SWIM shared capability supporting the SWIM infrastructure

ATM specific services Developing ATM specific services as a provider

Governing

Steering and managing Guiding, organizing and coordinating actions related to the SWIM concept

Developing regulation and policies Production of regulation and policies related to SWIM

Supervising Supervising ATM-specific services

Overseeing the performance or operation of SWIM services

Assessing compliance Measuring compliance of SWIM elements with reference to standards or objectives

Table 2: Description of the main roles


33 of 71



The matrix below indicates the main roles for the actors. There will always be exceptional cases, where some of the actors perform other roles.

ACTORS Aerodrome Community

Airspace providers

Airspace users

ATM service

providers

ATM support industry ICAO

Regulatory authorities States

ROLES

Consuming

Consuming an ATM information service

X X X X

Operating SWIM nodes X X

SWIM common components (e.g. registry)

X X

ATM specific services X X X X X

Developing SWIM nodes X

SWIM common components (e.g. registry)

X

ATM specific services X X X

Governing Steering and managing X

Developing regulation and policies X X11 X X

Supervising

Supervising ATM information services 12

X X

Assessing compliance13 X X

Table 3: Actors and their main roles in SWIM

11 ICAO: SARPS for SWIM 12 Actual supervision will also be ensured by the service providers. 13 In the case of self-assessment, it will be done by either the ones developing or operating the service


34 of 71



6 SWIM governance In accordance with the definition of SWIM provided above, standards, infrastructure and governance are part of SWIM. Governance is an integral part of all SWIM elements1415. Examples include:

- defining who is involved in the approval and evolution of standards16, what process is followed in order to do this, etc.;

- defining which parts of the SWIM infrastructure will need to be provided either by the service provider/consumer or by the “SWIM authority”; 17

- defining requirements on service definitions and implementations, controlling and managing and approving service definitions and implementations to be exchanged using SWIM

- defining which IM functions18 will be performed either by the service provider/consumer or by the “SWIM authority”;

- defining how the costs for the common components will be financed. - etc.

A governance structure therefore needs to be defined and put in place to issues outlined above. A governance structure proposal is presented in “Appendix A: Detailed description of the Governance groups”. This material is an early draft to illustrate current thinking on the matter. It is acknowledged that such proposal will require further coordination with all concerned parties and will evolve as the SWIM concept matures.

14 The 'SWIM Collaboration Authority' could also delegate functions to already existing organisations, e.g. verifying compliance of infrastructure and services could be delegated to 'accredited testing organisations'. 15 This could also be a ‘light’ form of governance. A rule could be ‘this process is not governed’, which is also considered to be governance. 16 Standards will be defined for information models, service models and technology. 17 It could be that the ‘common components’ are provided by the ‘SWIM Authority’ (see also this notion of common components as defined in the TAD (14.01.03.D31)) 18 The IM functions will need to be addressed in terms of governance aspects and these functions will be further developed after endorsement of the SWIM ConOps.


35 of 71



7 Implementing SWIM through gradual change The implementation of SWIM is not a big-bang replacement of the existing ATM environment, but an evolutionary process based on a gradual transition towards a service-oriented European ATM system architecture. The adoption of SWIM will be flexible and foster increased levels of collaboration within business domains. It will enable supporting systems to interact in an interoperable and standardised way. The transition itself will be simplified by decoupling providers from consumers of services, i.e. between providers and consumers of information. This will allow gradual growth in the number of SWIM participants and diversification in their nature, as well as a continuous increase in SWIM-enabled applications. The implementation roadmap should thus reflect an iterative process that foresees continuous improvement and evolution in step with business needs. Services will be added as necessary to support ATM stakeholders’ requirements. Other key components of SWIM, such as the AIRM, the ISRM, the registry, information management functions, infrastructure elements and governance will gradually evolve and be aligned with the requirements of the services available at any given point in time. Although the adoption will be gradual, a number of preliminary agreements are required and certain minimum conditions need to be met. These are:

• buy-in to the SWIM principles from the stakeholders; • an initial SWIM governance and management structure, including a legal framework; • availability of an AIRM and ISRM release; • initial set of defined SWIM profiles; • initial policies including service level agreements; • availability of initial infrastructure and a first set of deployed services compliant with the AIRM

and ISRM; • initial policies on information sharing, restricted information and non-dissemination right,

especially with regard to military data; • availability of the SWIM registry to share information about the initial set of services; • suitable arrangements to ensure global interoperability.

All of the above aspects should achieve a minimum level of standardisation to enable interoperable information-sharing in a federated way. Furthermore, it should provide a sound foundation for SWIM to grow on. This foundation is needed to set the right direction, whereby some of the fundamental SWIM principles will be safeguarded from the start.

Next, SWIM will continue to mature as:

• the buy-in to the concept increases through first positive experiences; • thus more services are provided and consumed; • SWIM governance and management mature further; • the AIRM and ISRM grow and more services are defined; • the registry continues to be populated; • standards (including technical) supporting global interoperability become available and are

gradually implemented. • additional requirements drive the evolution of the SWIM infrastructure.

Together, the above aspects drive the SWIM deployment, whereby increased levels of service orientation are achieved. Consequently, the evolution towards SWIM will be progressive in the sense that:

• SWIM participation grows based on business needs and decisions; • interoperability will be achieved on the basis of using common services.


36 of 71



The gradual change towards SWIM also clearly encompasses a global dimension. It should be noted that because not all regions move towards SWIM at the same speed, legacy means of interaction may need to be maintained for some time.

Note:

(i) At the time of writing, work is in progress at the EU level regarding the SESAR Deployment. The European Commission intends to select the Deployment Manager and a set of implementation projects in early 2014. As an input to support such selection process, the European Commission requested the SJU to produce a proposal for a Pilot Common Project (PCP). The proposal currently being developed by the SJU contains, among others, an ATM Functionality called "initial SWIM (iSWIM): Ground-ground integration and aeronautical management and sharing" with a deployment period between 2016 and 2024.


37 of 71



8 References [1] SWIM Action Plan 00[1].01.00.pdf

[2] DLM-0612-001-02-00a The ATM Target Concept D3


38 of 71



Appendix A Detailed description of the Governance groups

This material is provided to illustrate current thinking on this matter. It is acknowledged that this definition will require further coordination with all concerned parties and will evolve as the concept matures. The following figure provides a proposal for this governance structure.

SWIM

Steering Group

SWIM

Standards and

Architecture Group

SWIM Technical

Manager Group

SWIM

Validation

Manager Group

Compliance validation

(Service / Provider / Consumer)

Standards

Policies

Legal

Definition of Transtion Plans

Overall technical coordination (Change management)

Execution transition plan

Impact analysis

Public Key Infrastructure (PKI)

Registry (changes + communication of changes)

Management of other common components

ACCEPT

ENDORSE

EXECUTE

MANAGE

APPLY

DEFINE

PROPOSE

General Oversight

Financial decisions

SWIM

Compliance Group

Assessment rules (criteria)

Escalation

Figure 10: Proposal for a SWIM Governance Structure

No details about the composition of each group (leadership, participation, method of taking decisions, etc.) are provided. Such points will need to be worked out as the concept matures. It is also acknowledged that cost and efficiency aspects will have to be considered in the detailed definition of the SWIM governance, especially in terms of financing the governance structure itself and the trade-off between governance and implementation/evolution agility.

A.1 SWIM Steering Group The SWIM Steering Group should be a committee representing the interests of the service providers and consumers. This group will:

- carry out general oversight of the other governance and management bodies;

- provide overall guidance on policy and "standard" settings to the SWIM Standards and Architecture Group;


39 of 71



- provide overall guidance to the SWIM Compliance Group;

- decide on the method of financing the costs associated with the management entities (especially the SWIM Assessment Group and SWIM Technical Manager Group) and with the common components, and how this method will adapt to changing conditions and new requirements;

- act as the last escalation body in the event of conflict in a resolution concerning a request which has not been solved at the previous escalation level.

The SWIM Steering Group is responsible for accepting and endorsing (or rejecting) any proposals made by the SWIM Compliance Group and the SWIM Standards and Architecture Group which have a significant impact in either technical, operational, or financial terms. Below are a number of examples which would require the approval of the SWIM Steering Group:

- The SWIM Standards and Architecture Group proposes that a standard be replaced by another one in a relatively short time-frame which will require significant expenses from both the service providers and consumers making use of the standard in question.

- The SWIM Compliance Group proposes that a criterion involving a significant cost to the potential service providers be included among the compliance criteria for the acceptance of a request to become a service provider.

- The SWIM Standards and Architecture Group proposes that the common components be extended to messaging brokers, meaning that the purchase, installation and operation of such components will need to be performed by the SWIM Technical Manager Group (which might also require the provision of specific training to the SWIM Technical Manager Group's staff and possibly even an increase in the number of such staff).

SWIM in Europe will not be working in a closed and isolated environment. It will be part of a complex environment with different sources of "regulations" which can have an impact on it: ICAO, the EU, EASA, etc. This means that there will be cases in which the decision of the SWIM Steering Group will already have been dictated by other sources, e.g.:

- If the EU approves an Implementing Rule concerning SWIM, the SWIM Standards and Architecture Group will have to analyse its impact and propose the corresponding plans to have it applied. The SWIM Steering Group will still need to approve the corresponding plans proposed by the SWIM Standards and Architecture Group, but this approval will actually be, in principle, no more than a formality.19

A.2 SWIM Compliance Group This group will be responsible for:

- defining, in accordance with the SWIM Steering Group's guidance, and proposing to that Group for endorsement, the SWIM Compliance Framework, including the conformance criteria which will be used by the SWIM Assessment Group when evaluating:

o requests to be registered as a service consumer, o requests to be registered as a service provider, o requests for provision of a "standardised" service,20 o compliance of the service instances before they are deployed, o compliance of the SWIM infrastructure elements before they are deployed, o other “objects” that are decided to be subject to compliance assessment;

- liaising with ICAO, EU, EASA and other regulatory bodies in order to stay up to date with regulations which could have an impact on the SWIM compliance part of the governance.

19 The SWIM Steering Group can reject the plan presented to it, but this rejection cannot refer to the Implementing Rule itself, only to the proposed plan to have it applied. 20 Requests for standardisation of a new service will be handled by the SWIM Assessment Group in coordination with the SWIM Standards and Architecture Group.


40 of 71



When new regulations impact this part, the SWIM Compliance Group will prepare the appropriate changes and propose them to the Steering Group for endorsement;

- liaising with the SWIM Standards and Architecture Group with a view to being up to date with standard status changes in order to define and update the corresponding assessment rules;

- acting as the first escalation body in the event of conflict relating to a resolution of the SWIM Assessment Group;21

- overseeing the performance of the SWIM Assessment Group.

This group will very probably require members with two different profiles:

- One part of the group's members will need to be staff with a background in the definition of certification processes, compliance rules, etc., related to EASA and/or EU Implementing Rules. These members should also have a background in the legal aspects of ATM data ownership and liability.

- Another part of the group's members might also require a background in certification processes, but with a more technical orientation (e.g. software/system quality assurance, etc.).

A.3 SWIM Standards and Architecture Group The SWIM Standards and Architecture Group should be a committee focused on the operational, technical, and financial aspects of SWIM in Europe and its evolutions. This group will be responsible for:

- defining the SWIM standards regarding the data, services and technical aspects, as well as maintaining and developing them in the framework of other standardisation bodies, where appropriate, and proposing them to the SWIM Steering Group for endorsement with an analysis of the impact of their adoption;

- liaising with international bodies involved in similar standardisation activities, e.g. the ICAO, EUROCAE/RTCA, ISO, OGC, ARINC, FAA, etc.,

o participating in the corresponding working groups and collaborating with them in the definition and agreement of worldwide standards,

o evaluating the impact of other standards (e.g. from ICAO or the FAA) on SWIM and deciding on the need to make changes to the current SWIM standards, and, where such changes are needed, preparing the appropriate change plans and proposing them with an impact analysis to the Steering Group for endorsement:

- defining and proposing to the SWIM Steering Group for endorsement the policies to be applied in service provision and consumption (e.g. policies on security, authentication, etc);

- liaising with ICAO, the EU, EASA and other regulatory bodies in order to stay up to date with regulations which could have an impact on SWIM standards, e.g. the EU Implementing Rule on the use of IPv6, and, where new regulations will impact the services, technical standards or policies, preparing the appropriate change plans and proposing them with an impact analysis to the SWIM Steering Group for endorsement;

- liaising with the SWIM Compliance Group to keep it up to date with standard status changes which could have an impact on the assessment criteria produced by it;

- defining, in accordance with the SWIM Steering Group's guidance, and proposing to that Group for endorsement, the assessment criteria which will be used for the evaluation of

21 In the event of disagreement with a resolution of the SWIM Compliance Group, the affected party can still present its case to the SWIM Steering Group.


41 of 71



requests for standardisation of a new service, and evaluating such requests in accordance with the endorsed criteria in coordination with the SWIM Assessment Group;22

- defining, in conjunction with the SWIM Technical Manager Group, the transition plans required in order to make changes to the SWIM infrastructure elements which require overall coordination to avoid significant disruption to the services provided;

- preparing, in conjunction with the SWIM Technical Manager Group, following a request from it or in response to newly identified needs, requests to upgrade the existing SWIM common components (registry, PKI and others), in terms of software, hardware or both, submitting the proposals with an indicative financial impact to the SWIM Steering Group for assessment, and, if agreed, proceeding in conjunction with the SWIM Technical Manager Group with the corresponding purchase and implementation procedure for such upgrades;

- identifying the need for the existing SWIM common components to be extended to new ones (e.g. a messaging broker) following requests from service providers and consumers, preparing the corresponding material with the anticipated impact in terms of cost, SWIM Technical Manager Group staff, etc., submitting that material to the SWIM Steering Group for assessment, and, if agreed, proceeding, in conjunction with the SWIM Technical Manager Group, with the corresponding purchase and implementation procedure for such extensions;

- performing tasks requested by the SWIM Steering Group concerning operational, technical or financial aspects for which the SWIM Standards and Technical Group has the appropriate expertise;

- overseeing the performance of the SWIM Technical Manager Group and the SWIM common components under its management.

This group should be composed of staff with a wide range of expertise:

- Expertise in the various ATM domains will be required for the responsibilities regarding standardisation activities in the fields of data and services.

- Expertise in technological domains will be required for the responsibilities regarding standardisation activities in the fields of communications, middleware, modelling, security, etc.

A.4 SWIM Assessment Group In accordance with the compliance assessment criteria provided by the SWIM Compliance Group, this entity will be responsible for assessing the following:

- requests to be registered as a service consumer, - requests to be registered as a service provider, - requests for provision of a "standardised" service,23 - compliance of the service instances before they are deployed, - compliance of the SWIM infrastructure elements before they are deployed, - other “objects” that are decided to be subject to compliance assessment.

This entity will update the registry to reflect the status of the requests while they are being processed. This entity will report to the SWIM Compliance Group about its performance in accordance with the guidance and criteria defined by the former body.

22 In the event of disagreement with a resolution of the SWIM Standards and Architecture Group, the affected party can still present its case to the SWIM Steering Group. 23 Requests for the standardisation of a new service will be evaluated in coordination with the SWIM Standards and Architecture Group.


42 of 71



The above-mentioned tasks are either of an administrative or of a technical nature (compliance assessment).24 Therefore, two approaches are possible: either two types of profile are required for members of the SWIM Assessment Group, and each type is dedicated to its corresponding tasks; or the members of this entity must match the most demanding profile, i.e. the one required to perform the compliance assessment. In the latter scenario, the members of this entity would need a background involving software/system technical expertise, ideally in testing activities.

A.5 SWIM Technical Manager Group This entity will be responsible for:

- daily management of the common components. This management encompasses:

o ensuring that the system and services of the common components are up and running (supervision of such common components);

o updating the registry contents under the Group's responsibility when needed/requested;

o issuing certificates and managing the certificate revocation list;

o defining the users with their corresponding access rights (restricted to the common components);

o other daily management actions specifically required for other common components under the Group's responsibility if allocated to it by the SWIM Steering Group;

o provision of support to the SWIM Standards and Architecture Group in order to define the transition plans required to make changes to the SWIM infrastructure elements which require overall coordination to avoid significant disruption to the services provided;

- conducting change/performance management of the common components, identifying when upgrades will be required (hardware and/or software), and, when upgrades are needed, informing the SWIM Standards and Architecture Group, cooperating with it to define the appropriate upgrade plans and implementing them where they are endorsed by the SWIM Steering Group;

- providing other support to the SWIM Standards and Architecture Group as required, e.g. conducting an impact analysis for a change under consideration;

- performing the actual overall coordination for the implementation of changes which need such coordination to avoid significant disruption to the services provided;

- reporting to the SWIM Standards and Architecture Group about its performance in accordance with the guidance and criteria defined by the former body.

The profile of the staff allocated to this entity should be technical, ideally with a background in system/application operation management.

24 The potential scope of the technical compliance assessment work done by the SWIM Assessment Group will need to be in accordance with the relevant regulations. There will also be a trade-off between the scope of this work and the staff/means required by this Group.


43 of 71



Appendix B Outstanding Questions The list below contains a number of items that are 'R&D Needs' to be further investigated. This is a separate list that is used and managed to assure full coverage of all outstanding questions.

1. The alternatives on financing the common components of the SWIM infrastructure and the “SWIM Collaboration Authority” have not been discussed. This requires further analysis and discussions between the partners.

2. The “SWIM Collaboration Authority” will define a set of rules for who (as a company, as an individual) is allowed to access SWIM (e.g. the criteria for accessing SWIM as a consumer or provider). The criteria for refusal of access will be documented and backed by appropriate legal arguments. This policy25 encompasses the applicable regulations from NSA/EASA26 (e.g. such regulations might require a service provider to be certified by NSA or EASA). The escalation process in case of conflict in the result of the compliance assessment will be defined27.

3. The SWIM Node is defined as a logical entity (see assumptions). The implications (e.g. on the possibility of outsourcing; implementing in the future the control part of a pan-European supervision; implementing in the future policy enforcement mechanisms etc…) need to be further identified and analysed.28

4. Will the ISRM have to define all the services? The list of services could get long over time. The evaluation of a new request within the list of services (and within the ISRM, in order to check if it is a new service or not) could become more difficult, so this could lead to a problem of the management of the ISRM in the long term.

5. The time to complete the addition to the ISRM of a new service. Do the requests to implement service instances for new services being defined would have to be blocked until the ISRM/AIRM update process is fully finished? There will be a trade-off between agility to define and implement new service instances and the ISRM/AIRM control.

6. If a new service requires an update / upgrade of the SWIM infrastructure and assuming such update / upgrade is granted, there will be a dependency between the development / provision of the new service and the update of the SWIM infrastructure (i.e. it makes no sense to be ready to deploy the service instance much earlier than the target date for the SWIM infrastructure update and vice versa).

7. Are licenses needed to use AIRM and ISRM in order to financially support the quality control & governance required?

8. How is it ensured that AIRM and ISRM are compatible with other regions in the world? 9. Further analysis is needed on a) the possible support of multiple releases of the Reference

Model, b) the frequency of developing / approving / … publishing new releases, c) how to review the stakeholder compliance for a new release, d) time to complete the addition of a new service to the ISRM, e) management of the ISRM, when this becomes a long list of services.

25 The SWIM policies may need to make a difference between various types of providers (e.g. States vs. ANSPs vs. private sector) 26 The role and the scope of work of the SWIM Authority with regard to NSA/EASA need further discussion. Certification procedures (at the level of NSA/EASA) and compliance procedures (at the level of SWIM Authority) will need to be coordinated between the various regions. Mutual recognition of certificates / compliance declarations needs to be addressed. The needs for certification are addressed in compliancy framework (08.01.01. D43). 27 Legal aspects concerning escalation procedures and cases over compliance denials need to be thoroughly addressed. 28 The issue on superivision is still open (there is a pending B.04.02/B.04.03 PCG action to look at supervision in the SESAR programme and provide guidance) and we will include the impact of the outcome in a future iteration.


44 of 71



Appendix C Assumptions This document has been produced on the basis of a number of assumptions. This section provides the major assumptions which could have a relevant impact on potential expectations relating to SWIM. These assumptions need to be agreed on and, even if agreed on, are subject to change in the future.

C.1 General assumptions

1. SWIM can be implemented differently in various regions of the world but interoperability must be ensured through common standards.

C.2 SWIM Registry 29

1. The SWIM registry stores information about the service in all the steps of the lifecycle management, excluding the runtime.

2. It is not mandatory for the services to access the SWIM registry during runtime. 3. It is assumed that only registered stakeholders (service consumer / service provider) can access

the resources available on SWIM. Before a stakeholder can join SWIM, the stakeholder registers by providing the necessary information as defined / required by the “SWIM Collaboration Authority”. The registration is required to keep SWIM governed as a trusted partnership between the stakeholders.

4. The registration of SWIM Stakeholders can be performed at the level of an organisation, and / or at the level of an individual.30

5. The SWIM registry has a public and private part. When the provider agrees and if no security conditions apply, the public part provides, in addition to generic information regarding SWIM, a high-level description of what is available in the private part.

6. The public part can be accessed by anyone. Only registered users can access the private part, provided they have the proper authorisation. The scope of the information accessible to a registered user in the private part of the SWIM registry will depend on the authorisation rights of the user.

7. The “SWIM Registry” can also contain the ‘non-compliant’ services from SWIM Stakeholders to have a complete overview of all services available in ATM.

8. The “SWIM Collaboration Authority” manages the authorisation rights for accessing the SWIM registry.

9. The “SWIM Collaboration Authority” will define the attributes to be provided during registration. 10. Both the general information (web pages) on SWIM and the registration form will be publicly

available for the stakeholders to submit their registration request. 11. The SWIM registry contains information (e.g. service descriptions, standards, policies,

certifications, regulations …) that is only available after registration (i.e. information in the private part of the registry).

12. The SWIM registry maintains the information on compliance declarations.

C.3 Design assumptions

1. The common components of the SWIM infrastructure (PKI and Registry) are provided at the start of SWIM deployment.

2. The policies to be applied in the service provision and consumption (e.g. policies on security, on authentication, etc) will be defined by the SWIM Standards and Architecture Group. Once endorsed by the SWIM Steering Group, the implementation of such policies will be done on a

29 See P14.01.03 D31 TAD on the architecture of the registry 30 Further analysis regarding the appropriate registration level (organisation, individual) is needed.


45 of 71



voluntary and collaborative basis by the impacted stakeholders. Therefore, there will be no common component under the control of the SWIM Technical Manager Group that will be able to force the activation of a policy in the different SWIM infrastructure elements. Every time new policies or changes to the existing policies are defined:

a. The SWIM Compliance Group will update the concerned assessment criteria if needed and the SWIM Assessment Group will apply such new criteria for the new requests and compliance assessments31.

b. The SWIM Standards and Technical Group will perform an impact analysis and define transition plans when such policy changes will impact existing services. The SWIM Technical Manager Group will be the responsible to co-ordinate the execution of such plans once agreed.

3. It is assumed that there will be no pan-European supervision of the SWIM infrastructure elements and ATM-specific services32. I.e., it is assumed that there will be no common component under the management of the SWIM Technical Manager Group or another entity that would provide an overall monitoring and control of the entire SWIM infrastructure and all ATM-specific services.

4. Supervision encompassing one or more SWIM nodes and ATM-Specific services (e.g. the part under the responsibility of an ANSP, or under the responsibility of a FAB) might be needed.

5. The sub-regional SWIM supervision will be defined and the required data and services, interfaces and technologies will be standardised in the corresponding projects of the SESAR programme. When such SWIM supervision capability is implemented, it must follow the standards.

6. It is assumed that there will be no common component dedicated to the legal recording function. This implies that each service provider and consumer will have to check the necessity to implement legal recording for the services it provides or consumes.

7. It is assumed for the time being that there will be no common component dedicated to the Security and Authentication functions (except for the PKI), although this matter is still subject to further analysis in the context of the SESAR Programme. SWIM will define the Security and Authentication standards and policies to be applied.

8. The common PKI component will issue and revoke certificates. Certificates to be used by the SWIM consumers and providers can be issued either by the common PKI component or by other certification authorities (e.g. one under the ANSP responsibility management, private or commercial ones).

9. SWIM will not provide common components to manage user profiles or access rights; this management will have to be done by each individual service provider.

10. The SWIM Node is defined as a logical entity. This implies that they can be implemented and deployed a) as their own dedicated environment, independent of the software components of the domain system or b) as a software component integrated together with other software components of the domain system.

11. The interfaces between the SWIM node and the software components of the domain systems can be standardised (open) or proprietary33 defined.

12. It is assumed that co-ordination of the standards is done with other regions in the world.

C.4 Information and service management

1. The “SWIM Collaboration Authority” can be authoritative either through consensus or regulation.34 2. The management of the lifecycle of the Reference Models (AIRM / ISRM) will be under the

responsibility of the “SWIM Collaboration Authority”. 3. The SWIM Governance will provide a mechanism whereby all stakeholders (service consumers,

service providers and “SWIM Collaboration Authority”) with an interest in the Reference Models

31 The SWIM Compliance Group will analyse the potential impact of these changes to the compliance declarations already allocated. 32 It is assumed that the common components and the enabling services provided by them will be supervised by the SWIM Technical Manager Group. 33 The analysis of the cases where such standardisation could be needed is ongoing. 34 Authority through consensus means that all stakeholders agree on the authoritative nature of the ‘SWIM Authority’.


46 of 71



interact between each other in such lifecycle management. It is assumed that the ISRM and AIRM follow the same change management process.

4. The definition of this lifecycle management will have to consider the following issues: a. The “SWIM Collaboration Authority” analyses the impact on the SWIM infrastructure

when a new service is requested. b. The “SWIM Collaboration Authority” will perform compliance assessments on

stakeholders, the common SWIM infrastructure components as well as the service provision.

c. The “SWIM Collaboration Authority” will assess the compliance of the stakeholder on the SWIM infrastructure. It is assumed that compliance assessment of a service provider35 is required when:

i. It is a new service provider; ii. It provides a new type of services; iii. Its previous compliance declaration has expired.

d. The “SWIM Collaboration Authority” will define the types of services ‘subject to compliance assessment’ / ‘not subject to compliance assessment’. A specific policy applicable to the various types of services36 will be defined. Depending on the ‘object under assessment’, the compliance assessment will be defined (e.g, self-assessment, run tests and upload the result, …)

e. The definition of the previous assessment tasks of the “SWIM Collaboration Authority” will have to consider the impact to stakeholders located outside the EUR region.

35 The compliance criteria for the assessment of the consumer still need to be defined. The case of a service consumer is not addressed in this version. A clear definition and categorization of a service consumer is needed. 36 The compliance assessment procedures need to take into account that the service development and/or the service provision can be outsourced to a third party.


47 of 71



Appendix D Use Cases The detail of these use cases are currently indicative proposals and are expected to be refined in the next version.

D.1 Uc01 A Stakeholder joins SWIM Use Case Uc01 stakeholder joins SWIM

Description Before a stakeholder can join SWIM, the stakeholder needs to be registered. In order to do that, the stakeholder provides the necessary information as defined / required by the “SWIM Collaboration Authority”. The registration of SWIM Stakeholders can be performed at the level of an organisation, and / or at the level of an individual.

Primary Actor SWIM service provider registers to - access the private part of the registry, - provide services on SWIM.

SWIM service consumer registers to

- access the private part of the registry, - subscribe and consume services available on SWIM.

Supporting Actors “SWIM Collaboration Authority” • Defines the set of rules for who (as a company, as an individual) is

allowed to access SWIM (criteria for accessing SWIM as a consumer or provider).

• Defines the attributes to be provided during registration. • Provides a registration service for the stakeholders to register • Analyses the request for access to SWIM • Classifies the stakeholders of SWIM • Keeps track of all SWIM stakeholders in the SWIM registry

Preconditions / assumptions

• It assumes that only registered stakeholders (service consumer / service provider) can access the resources available on SWIM.

• The SWIM registry has a public and private part. When the provider agrees and if no security conditions apply, the public part provides a high-level description of what is available in the private part. Only registered users can access the private part, provided they have the proper authorisation. The public part is accessible through the Internet by everybody.

• The SWIM registry contains information (e.g. service descriptions, standards, policies, certifications, regulations …) that is only available after registration (i.e. information in the private part of the registry). At this stage the registry is considered as a common service that is available as part of the SWIM concept.

• This use-case concerns only registration (an additional request to access a service is another use-case)


48 of 71



Basic flow

1. The use case starts when the stakeholder (service consumer / provider) submits his request to be registered in the SWIM registry. This is done through the registration service (e.g. web registration form) which is operated by the “SWIM Collaboration Authority”.

2. The stakeholder provides an initial set of attributes that were previously defined by the “SWIM Collaboration Authority”.

3. The “SWIM Collaboration Authority” analyses the request and performs the necessary administration in the SWIM Registry.

4. The stakeholder gets a confirmation and authorisation to the SWIM private part of the registry or refusal to access the SWIM registry (alternative flow # 1).

5. The stakeholder receives the authorisation to the private part of the registry from the “SWIM Collaboration Authority” depending on the profile of the stakeholder (i.e. access control still applies, e.g. military information might only be available to military stakeholders).

Postconditions The stakeholder has access to the private part of the SWIM registry and will be know as a member of SWIM.

Alternative flow #1 The “SWIM Collaboration Authority” refuses the access based on the attribute evaluation based on the rules were previously defined by the “SWIM Collaboration Authority”. When refused, the stakeholder receives explanation of the refusal.

Postconditions The stakeholder is refused access to SWIM.

D.2 Uc02 The “SWIM Collaboration Authority” assess es a stakeholder

Use Case Uc02 “SWIM Collaboration Authority” assesses a stakeholder

Description The “SWIM Collaboration Authority” needs to assess the compliance of a stakeholder on the SWIM infrastructure. This needs to be done in the case of a service provider when:

- It is a new service provider; - It provides a new type of services (see assumptions); - Its previous compliance declaration has expired.

This needs to be done in the case of a service consumer when:

- To be defined

Primary Actor • SWIM service provider who intends to provide a service or a set of services over SWIM


49 of 71



Supporting Actors • “SWIM Collaboration Authority”

o Provides the rules for assessment and the escalation process in case of conflict in the result of the compliance assessment.

o Assess the provider request and issues compliance declarations

o Maintains the information on compliance declarations in the SWIM registry


Applicable for service provider assessment. It is assumed that compliance assessment of service providers is required. • The compliance assessment is done by the “SWIM Collaboration

Authority”. • The types of services ‘subject to compliance assessment’ / ‘not

subject to compliance assessment’ have been identified. • A general policy applicable to service providers has been defined.

This policy encompasses the applicable regulations from NSA/EASA (e.g. such regulations might require a service provider to be certified by NSA or EASA).

• A specific policy applicable to the various types of services has been defined.

• The SWIM policies (general for those provisions applicable to all service providers and specific for those provisions attached to a specific type of service) needs to be explicit and backed by legal analysis

• The service provider is registered as a SWIM participant.

Basic flow (for service provide assessment)

1. A service provider requests to the “SWIM Collaboration Authority” to be allowed to provide (a) given type(s) of services (e.g. through a webform)

2. The “SWIM Collaboration Authority” evaluates the request as follows:

o Assess if the service provider meets the general policy (defined by the “SWIM Collaboration Authority”) that is applicable to all SWIM service providers (e.g. legal status, credentials)

o Assess if the service provider meets the specific policy applicable to the type of service(s) requested (see Assumptions regarding the service ‘types’ that require compliance checking or not)

o Requests a formal agreement (signature) of a “service provider agreement” which includes legal obligations (liability, copyright, charging, etc) as applicable and compliance with the applicable regulation (ICAO, SES, EASA/NSA).

3. The service provider signs the formal agreements referred to in step 2.

4. The “SWIM Collaboration Authority” grants the service provider a compliance declaration corresponding to the request, which includes termination / expiration conditions. This information is also maintained in the SWIM registry.

Note: in case of re- assessment, the same steps apply but the process may be eased by availability of previous compliance declarations.

Postconditions The service provider is allowed to provide the type of service(s) detailed in the compliance declaration.


50 of 71



Alternative flow #1 Request from the service provider is refused by the “SWIM Collaboration Authority”. Compliance denials are fully documented and backed by legal rationale (information provided by the “SWIM Collaboration Authority”).

Postconditions • Service provider is denied access to SWIM, or denied the permission to provide a type of service(s).

• Escalation process in case of disagreement between parties over the interpretation of the SWIM general or specific policies.

Issues • The SWIM policies may need to make a difference between various types of providers (e.g. States vs. ANSPs vs. private sector)

• The role and the scope of work of the “SWIM Collaboration Authority” with regard to NSA/EASA needs further discussion

• Certification procedures (at the level of NSA/EASA) and compliance procedures (at the level of “SWIM Collaboration Authority”) will need to be coordinated between the various regions. Mutual recognition of certificates / compliance declarations needs to be addressed.

• Implications in certification procedures / compliance procedures if the service development and/or the service provision are outsourced to a third party.

• Legal aspects concerning escalation procedures and cases over compliance denials need to be thoroughly addressed.

• The case of a service consumer is not addressed in this version. Its definition will require a clear definition and categorization of a service consumer.

D.3 Uc03 A stakeholder proposes a new or upgraded service definition

Use Case Uc03 A stakeholder proposes a new or upgraded service definition

Description A SWIM stakeholder wants to have SWIM extended with a new or upgraded service definition.

Primary Actor SWIM stakeholder. Such new or upgraded service definition can be requested • from a business perspective • because it is imposed by regulation (ICAO, EC, EASA, …) • based on a request from service consumer(s)

Supporting Actors “SWIM Collaboration Authority” • Provides the rules for the evaluation of the requests for new

service definitions, \, … (e.g. data model compliance with AIRM) and the escalation process in case of conflict in the evaluation result .

• Checks the consistency of the proposed new service with the

existing ones (is it redundant?....).


51 of 71



• Assesses the changes that will be required to current standards, SWIM infrastructure, etc if such new service definition is accepted.

• Decides on the acceptance/refusal of the request • Launches the necessary processes to have the required changes

(standards, SWIM infrastructure, etc) performed if the request is accepted


• The stakeholder making the request is registered as SWIM participant (uc01)

• This use cases (and others) makes reference to ISRM/AIRM. This shall be understood as the standards defining the data and service models as well as the interfaces, regardless as how these could be called after the SESAR program.

Basic flow

1. The SWIM stakeholder proposes a new service or an upgrade of an existing service. This is done through a request that is stored in the SWIM registry.

2. The request is forwarded to the “SWIM Collaboration Authority” for evaluation.

o If the proposed service is already in the ISRM or the established criteria indicates that the request shall be rejected, the SWIM stakeholder is informed that his request has been rejected (alternative #1)

o If the proposed service is not in the ISRM, the “SWIM Collaboration Authority” assess the request for the new or upgraded service:

� Safety and Security implications (for both providers and consumers)

� Legal obligations (liability, copyright, evaluation of the charging policy, SLA (requirements for access are indicated) …)

� Data Quality requirements (data source, data format - AIRM, consistency, timeliness, ...)

� Service Quality requirements (ISRM, service technical interface, …) , constraints if any imposed at consumer side, consumer side constraints if any, “SWIM Collaboration Authority” constraints if any, QoS (performance, safety, security),…

� Updates required in the SWIM infrastructure, if any, and their potential impact.

� Compliance to the regulatory requirements (e.g. whether the service being proposed is compliant with the ICAO regulations)

3. If the request is accepted, the SWIM stakeholder receives a positive evaluation. (or alternative #1)

4. The SWIM registry is updated with this information, where the service status is set as ‘service under definition’.

5. The “SWIM Collaboration Authority” launches the corresponding processes to have ISRM and eventually the AIRM updated accordingly (see uc04)


52 of 71



6. If the new service will require updates in the SWIM infrastructure, the “SWIM Collaboration Authority” will agree and co-ordinate with the concerned stakeholders an implementation plan for such updates.

7. Subscribers receive notifications that a new service is ‘under definition’.

Postconditions • The service definition is added to the ISRM • Service providers can request the development of instances of

such service (uc05)

Alternative flow #1 The “SWIM Collaboration Authority” refuses the service definition proposed.

Postconditions • Escalation process in case the SWIM stakeholder does not agree on the refusal from the “SWIM Collaboration Authority”.

Issues • What if Service upgrade is proposed (imposed) by the Collaboration Authority to comply with new regulations? Who will support the costs associated with the services upgrade?

• If the new service requires an update of the SWIM infrastructure, has the decision on accepting or refusing the new service definition to be dependent on the acceptance of the SWIM infrastructure update, especially if this infrastructure update might impact common components or existing SWIM Nodes owned by stakeholders that will not be concerned by the new service?

D.4 Uc04 The “SWIM Collaboration Authority” manage s the lifecycle of the Reference Models (AIRM / ISRM)

Use Case Uc04 The Collaboration Authority manages the lifecycle of the Reference Models (AIRM / ISRM)

Description Both the AIRM and ISRM (Reference Models) are subject to changes and updates. The lifecycle steps to be taken into account are :

- definition - development - compliance assessment - operation - deprecation

The management of such lifecycle is under the responsibility of the “SWIM Collaboration Authority”. The SWIM Governance provides a mechanism whereby all stakeholders (service consumers, service providers and “SWIM Collaboration Authority”) with an interest in the Reference Models interact between each other in such lifecycle management.

Primary Actor • “SWIM Collaboration Authority” • Analyse CR • Decide on CR • Follow-up and implement CR • Decide on release plan (exceptional interim releases)


53 of 71



Supporting Actors • SWIM Stakeholder (e.g. service consumer, service provider, etc) • Put forward CRs • Take notice of new release • Follow-up CRs


• This use cases (and others) makes reference to ISRM/AIRM. This shall be understood as the standards defining the data and service models as well as the interfaces, regardless as how these could be called after the SESAR program.

• AIRM and ISRM follow the same process. • At a given moment a Change Request (“CR”) has a single

status (e.g. pending, approved, rejected etc.).

Basic flow

1. Stakeholders issue / raise Change Requests (“CRs”).

2. CRs are analysed by the “SWIM Collaboration Authority” which determines how to handle them + impact analysis (e.g. which of the logical / physical models are impacted).

3. The “SWIM Collaboration Authority” follows-up and informs stakeholders.

4. The “SWIM Collaboration Authority” takes decision and changes / administers the elements impacted (change of the model / translation of logical into physical).

5. The “SWIM Collaboration Authority” performs/delegates quality control + approval.

6. The “SWIM Collaboration Authority” publishes new release.

7. The “SWIM Collaboration Authority” communicates a new release to stakeholders (consumers and providers).

8. The “SWIM Collaboration Authority” coordinates the implementation of a new release.

Postconditions A new release is available. If applicable, the planning for removal of deprecated services can be performed.

Issues • The frequency of developing / approving / … publishing new releases requires further analysis? There could be some pre-defined release cycle for the Reference Models

• How to review the stakeholder compliance for a new release? • Time to complete the addition of a new service to the ISRM. • The list of services could get long over time. The evaluation of a

new request within the list of services (and within the ISRM, in order to check if it is a new service or not) could become more difficult.


54 of 71



D.5 UC05 A provider proposes a new or upgraded ser vice instance

Use Case Uc05: A provider proposes a new or upgraded service instance

Description A service provider wants to develop a new or upgraded service instance on SWIM. He needs an agreement from the “SWIM Collaboration Authority” before starting the development and before any deployment of a new (or upgraded) service on SWIM.

Primary Actor SWIM service provider who intends to • provide the service from a business perspective • provide the service because it is imposed by regulation (ICAO,

EC, EASA, …) • provide the service based on a request from a service consumer

Supporting Actors “SWIM Collaboration Authority” • Provides the rules for the evaluation of the requests and the

escalation process in case of conflict in the evaluation result. • Assesses if the provider is allowed to provide the service and

issues compliance declarations. • Maintains the status of the service (in the registry, …)


• The service provider is registered as a SWIM provider (see uc01) • The service definition is available in the ISRM.

Basic flow

1. The service provider proposes a new or an upgrade of existing service instance. This is done through a notification that is stored in the SWIM registry.

2. The notification is forwarded to the “SWIM Collaboration Authority” for evaluation.

3. The “SWIM Collaboration Authority” evaluates the notification as follows:

o Checks that the service provider has a compliance declaration to provide this type of service -see uc02- (e.g. legal checks, copyright of data being provided, compliance with applicable regulations …)

o Advises on the conditions for the provision of the service for the provider (the ISRM contains these conditions in the service contract)

o In case the proposed service instance is actually an upgrade of an existing service:

� Impact on other services

� The service provider has an transition plan

o …

4. The “SWIM Collaboration Authority” can request further details on the services and its compliance to applicable principles to the service providers. (or alternative #1)

5. The SWIM registry is updated with this information, where the service status is set as ‘service under development/upgrade’.

6. If the new service will require updates in the SWIM infrastructure, the “SWIM Collaboration


55 of 71



Authority” will agree and co-ordinate with the concerned stakeholders an implementation plan for such updates.

7. Subscribers receive notifications that a new service is ‘under development’.

Postconditions The service provider can start the development of a SWIM compliant service instance.

Alternative flow #1 The service instance will not be accepted as SWIM Compliant.

Postconditions Escalation process in case the provider does not agree on the refusal from the “SWIM Collaboration Authority”.

D.6 Uc06 A provider develops a new service instanc e Use Case Uc06 A provider develops a new service instance

Description The provider develops a new instance of an existing ISRM defined service. I.e., it is assumed that either the ISRM already contained the definition of such service or the ISRM was already updated to include this service.

Primary Actor SWIM service provider • Develops the service instance • Optional: Provides the means to verify the service in a pre-

operational (test) environment

Supporting Actors SWIM service consumer • The service consumers who have subscribed to notifications from

this provider are informed. • The service consumers who requested this development are

informed. Optional: The service consumer participates to the pre-operational testing.

Preconditions / assumptions • The service provider received the agreement from the “SWIM

Collaboration Authority” to develop the service (provider has access to the data, data format is known, service interface is agreed, etc)

• The service description is available in the ISRM

• The service provider develops according to the SWIM standards (AIRM, ISRM)

• Optional: The provider has access to a test and pre-operational environment.


56 of 71



Basic flow

1. The service provider develops the service instance.

2. Optional: The service provider deploys the service instance in a pre-operation validation environment and performs testing with a limited number of selected service consumers.

3. The service provider plans the needed actions to have the SWIM infrastructure under its ownership (e.g., upgrade it (uc07)) to be ready to support the developed service when needed. His SWIM infrastructure may need to be ready either for the service instance development, or for the compliance assessment of this service instance (uc08) or for the deployment of this service instance (uc09). This should be consistent with the plan agreed with the “SWIM Collaboration Authority” to update other SWIM infrastructure required, if any, to support such service (see uc03, uc05).

4. The “SWIM Collaboration Authority” updates the registry (service catalogue); ‘subscribed’ stakeholders are informed about the development of the new service.

Postconditions The service provider will have to request the “SWIM Collaboration Authority” to assess the compliance of the new service (see Uc08).

D.7 Uc07 A stakeholder upgrades the SWIM infrastru cture. Use Case A stakeholder upgrades the SWIM infrastructure.

Description This use case concerns the description of all the steps needed to upgrade or modify the SWIM-TI (e.g. configuration change or a new or updated capability).

Primary Actor SWIM-TI Provider • Provides the updated version of the SWIM-TI implementation

under its responsibility / ownership.

Supporting Actors “SWIM Collaboration Authority” • Assesses the compliance of the updated SWIM-TI

implementations when needed. • Co-ordinates the deployment of such implementations among

the concerned stakeholders.


57 of 71




1. The events triggering the use case come from registered SWIM stakeholders.

2. The “SWIM Collaboration Authority”, as part of uc03 or uc05 or in a later stage, already evaluated and identified the changes in the SWIM-TI that were required and their impact: • Just configurations changes of existing capabilities • Implementation of a new capability • Upgrade of an existing capability.

3. The events triggering the use cases have been analyzed and the “SWIM Collaboration Authority” agreed that either a configuration change in the existing SWIM-TI is needed or there are no existing SWIM-TI capabilities that are able (or that could be updated) to support the new requirements. Examples when upgrades or new capabilities could be needed are:

a. One or several requirements for an existing ATM-specific service are modified or added and this requires a new SWIM-TI capability.

b. A new ATM-specific service is defined and this requires a new SWIM-TI capability.

c. During the SWIM-TI maintenance activities is identified a new capability that better supports ATM-specific services non-functional requirements.

4. The “SWIM Collaboration Authority” has defined the SWIM-TI capability according to the required technical specifications (functional and non functional requirements).

5. The “SWIM Collaboration Authority” already agreed and defined a plan to have the SWIM-TI updated in a co-ordinated manner.

6. The basic flow described below assumes that a new capability (or an upgrade of an existing one) will be required. The alternative flow described below assumes that just a configuration change of the existing SWIM-TI is required.

Basic flow 1. The SWIM-TI providers develop the capability according to its specification. 2. The “SWIM Collaboration Authority” assesses the compliance of the new or upgraded capability

implementations from the relevant SWIM-TI providers if needed. If the assessment result is not successful, the appropriate corrections will be required and the assessment will have to be redone afterwards.

3. The SWIM-TI provider deploys the updated or new capability in accordance with the plan defined by the “SWIM Collaboration Authority” and under its co-ordination.

Postconditions • The SWIM-TI is successfully upgraded with a new capability. • The new capability is implemented in all the relevant SWIM-TI

provider implementations. • The implementations of this new capability are interoperable.

Alternative flow The SWIM-TI provider performs the required configuration changes in accordance with the plan defined by the “SWIM Collaboration Authority” and under its co-ordination.

Postconditions


58 of 71



D.8 Uc08 The “SWIM Collaboration Authority” / prov ider assesses the compliance of a service instance

Use Case Uc08 The “SWIM Collaboration Authority” / provider assesses the compliance of a service instance

Description The compliance of a new service instance has to be assessed by the “SWIM Collaboration Authority”, prior to its deployment on the SWIM infrastructure. The service provider requests the “SWIM Collaboration Authority” to perform such assessment.

Primary Actor “SWIM Collaboration Authority” • Provides the rules for assessment and the escalation process

in case of conflict in the result of the compliance assessment. • Assesses the requests and issues compliance declarations.

Supporting Actors SWIM service provider o Intends to provide a new service instance over SWIM


1. The service has been developed (or upgraded) according to the SWIM practices (see use case uc06).

2. The relevance of compliance assessment prior to implementation on the SWIM infrastructure has been confirmed.

3. The “SWIM Collaboration Authority” entity is identified and operational.

4. The main types of services provided on SWIM has been defined (eg awareness / operational / safety critical).

5. A SWIM service policy has been defined and addresses the relevant legal and financial aspects.

6. The SWIM infrastructure update (upgrade of existing infrastructure or new infrastructure), if any, required to perform the compliance assessment of this service instance is already deployed

- The part under the ownership of the service provider either was already provided because it was needed for the development of the service instance (uc06) or it is provided for the compliance assessment.

- The part under the responsibility of the “SWIM Collaboration Authority”, if any, is provided for the compliance assessment following the planning defined either at the time the new service definition was agreed (uc03) or at the time the development of the service instance was agreed (uc05).

Basic flow

1. In the context described above, the service provider issues a request to the “SWIM Collaboration Authority” for a new service being subject to compliance assessment.

2. The “SWIM Collaboration Authority” checks that the service provider has a compliance declaration to provide this type of service (see uc02) and an agreement to develop such service instance (uc05).

3. The “SWIM Collaboration Authority” assesses, for this particular service instance, its compliance


59 of 71



to the predefined criteria. E,g,:

o Compliance with applicable technical standards (eg AIRM, ISRM)

o Compliance with applicable technical specifications (technical contents, data quality, interfaces, technology)

o Availability and validity of service assessment and validation reports

o Impact on other services

o Availability of a reference Service Level Agreement including characteristics of the service (metrics, hours of operations, restrictions as applicable, etc.)

If the evaluation result is negative (Alternative flow #1), the list of issues and non-compliance are sent to the service provider for remedial action and re-submission of a new request.

4. The “SWIM Collaboration Authority” grants the service provider a compliance declaration for the new service instance, which includes restrictions as appropriate (e.g. scope limited to a given region, time period,…) as well as termination / expiration conditions.

Postconditions 1. The service provider can deploy the service instance (uc09).

Alternative flow #1 Compliance denial is issued by the “SWIM Collaboration Authority”. It is fully documented and backed by technical and/or legal rationale. The service provider cannot deploy the service instance and needs to go through compliance assessment again.

Postconditions 1. Escalation process in case of disagreement between the service provider and the “SWIM Collaboration Authority” over the result of the compliance assessment.

D.9 Uc09 A provider deploys a new or upgraded serv ice instance on the SWIM infrastructure

Use Case Uc09 A provider deploys a new or upgraded service instance on the SWIM infrastructure

Description This use-case concerns the deployment of a service instance.

Primary Actor • SWIM service provider o Deploys and activates the service in its own

infrastructure, making it available through the SWIM infrastructure.

o Monitors the service

Supporting Actors • “SWIM Collaboration Authority” o Maintains the information on service status in the

SWIM registry. o Ensures that the required SWIM infrastructure update

to support such service, if any, has been done before


60 of 71



or is going to be done as part of the plan to deploy the service.

• SWIM service consumer

o Is informed (when he subscribed to receive such information) about the availability of a new service instance.


1. The service has been developed by the service provider and it has received the compliance declaration from the “SWIM Collaboration Authority”

2. The deployment of this service does not have any impact on other services already available, i.e., it is not an upgrade of an existing service or it is not supposed to replace an existing service.

3. The required SWIM infrastructure update to support such service, if any, was already planned and coordinated by the “SWIM Collaboration Authority” either at the time the service definition was accepted (uc03) or at the time the development of the service instance was agreed (uc05) or such plan has been or is being executed in order to have the needed updates available at the appropriate time for both the service provider(s) and the “SWIM Collaboration Authority”.

Basic flow

1. The service provider makes available the service instance on the SWIM infrastructure.

2. Pending updates of the SWIM infrastructure required by the service are implemented by the concerned stakeholders according to the plan elaborated and co-ordinated by the “SWIM Collaboration Authority”.

3. The security of the SWIM infrastructure is updated to allow access to the service.

4. The ‘provider’ supervision includes the monitoring of the new service.

5. The “SWIM Collaboration Authority” updates the registry (service catalogue) with the information (e.g. status, endpoints …) of the new service instance.

6. The “SWIM Collaboration Authority” updates the registry (service catalogue) on the dependencies between this new service instance and other available service instances.

7. The ‘subscribed’ stakeholders are informed about the deployment of the new service..

Postconditions The service consumers can start requesting access to the service.


61 of 71



Alternative flow #1 In the case of deploying a new service that actually is an upgrade of an existing one or is supposed to replace an existing one, the previous steps are still applicable. Nevertheless, in this variation, it would be worth to further detail the previous bullet point 7 to make the impact clearer to the consumers of the service as follows:

• In addition to be informed about the new upgraded service availability, they will also have to be informed about the time period when the ‘old’ service will continue to be available in order to prepare their migration to the upgraded one. The upgrade plan needs to be available to the consumers (via a reference in the registry).

This will lead to another use case: uc11 Stakeholder decommissioning a service on the SWIM infrastructure

Postconditions The service consumers can start requesting access to the service.

Issues • The impact on the SWIM infrastructure will need to be further analysed and explained.

• If the new service requires an update of the SWIM infrastructure and assuming such update was granted, we have a dependency between the development / provision of the new service and the update of the SWIM infrastructure, including the SWIM test environment (i.e. it makes no sense to be ready to deploy the service instance much earlier than the target date for the SWIM infrastructure update and vice versa).

• Charging. General issue about how to finance the SWIM infrastructure and the “SWIM Collaboration Authority” by the SWIM stakeholders.

D.10 Uc10 A consumer prepares to use an existing s ervice via the SWIM infrastructure

Use Case Uc10 consumer prepares to use an existing service via the SWIM infrastructure

Description The SWIM consumer is registered to SWIM and prepares to consume / prepares to use an existing service offered through/deployed on the SWIM infrastructure

Primary Actor SWIM service consumer • Wants to access the data provided by the service; • Develops and deploy the service consuming software, as required.

Supporting Actors SWIM service provider • If needed, authorises the access to the service; • If needed, validates the new service consuming software; • If needed, monitors the service consumption. “SWIM Collaboration Authority” • Register (Registry) and/or keeps track of service consumers, using

the services; • Enforces security on critical services and plan/co-ordinates the


62 of 71



update of the SWIM infrastructure that may be required, if any.

Preconditions / assumptions • The SWIM service consumer has a compliant SWIM technical

infrastructure, if needed, to access the service

• The SWIM service consumer evaluates the service and its SLA and has determined he is interested on the service.

Basic flow

1. If needed, the service consumer requests access to the service:

- The request is automatically forwarded to the service provider;

- The service provider evaluates if the service consumer is allowed to access and to consume the service (non-technical). There could be an Collaboration Authority/third party as interface between service provider and consumer for this evaluation

- The service consumer might need to sign a formal agreement (charging rules, responsibility, accountability …) with the service provider to get access to the service instance;

- The service consumer might need to obtain the proper access permissions (user-id, token, security is enforced …) from the service provider (or the “SWIM Collaboration Authority” or a process involving both);

2. Potentially, when access to the service is granted by the service provider:

- The “SWIM Collaboration Authority” updates the registry, adding the new service consumer for the concerned service instance.

- In case the service requires a service consumer development, the service consumer develops the service consuming software (and if needed, adapts its backend system to exploit the information provided from the service consumed)

o The service consumer informs the “SWIM Collaboration Authority” and the service provider that service consuming software is ready

o The service consumer might have to assess that the new service consuming software is compliant with the standards for access to the service and does not generate negative side effect on the overall SWIM Technical Infrastructure or in the service provider infrastructure (e.g. firewalls, networks, servers). I.e., a technical validation on the service provider test environment might have to be performed before the service consumer is allowed to consume the service (e.g. DNM ).

- The SWIM infrastructure might need to be upgraded. If so, the required updates, if any, are implemented by the concerned stakeholders under the co-ordination of the “SWIM Collaboration Authority” (see uc07).

3. When the previous steps are successfully achieved, the service consumer can access (consume) the service.


63 of 71



Postconditions

Alternative flow #1

Refusal of using/consuming a given service is based on pre-defined criteria not met by the service consumer:

- Service consumer does not have a compliant SWIM Technical Infrastructure when needed;.

- Service consumer does not meet pre-defined criteria set for a given service by the service provider (no compliance to service provider standard or side effect on the service provider infrastructure or service provision…).

- Service consumer does not meet pre-defined criteria set for a given service by the “SWIM Collaboration Authority” (no compliance to SWIM standard or side effect on the SWIM infrastructure …).

Postconditions Escalation process in case the provider does not agree on the refusal from the “SWIM Collaboration Authority”

Issues • The assessment of the service consuming software, when needed, may have to distinguish between the SWIM Technical infrastructure and the service provider infrastructure. In principle, the responsible for such assessment is different for each case. So, logically, this assessment /certification implies two different processes, although in practice they might be merged if proper co-ordination is achieved.

D.11 Uc11 A provider decommissions a service insta nce on the SWIM infrastructure

Use Case Uc11 A provider decommissions a service instance on the SWIM infrastructure

Description This use-case concerns the decommissioning of a service instance.

Primary Actor SWIM service provider • Stops the service instance that was running in its own

infrastructure.

Supporting Actors SWIM service consumer • Stop using such service instance and, if needed, use another one

or an upgraded one. “SWIM Collaboration Authority” • Assesses the decommissioning request impact and approves the

decommissioning (or not, or with reservations) - Plans and co-ordinates the updates of the SWIM infrastructure

when needed.


64 of 71




1. The service instance was deployed in the past and is currently being used by stakeholders (service consumers and other services)

2. The registry is up-to-date concerning the dependencies linked to this service and the service consumers of it.

Basic flow

1. The concerned stakeholders agree on the date at which the service will be decommissioned (see issue 1).

2. The service provider informs all the concerned stakeholders on the target date for the actual decommissioning. The “SWIM Collaboration Authority” updates the registry (service catalogue) with this information.

3. The “SWIM Collaboration Authority”, once informed of the decommissioning, plans any needed SWIM infrastructure update (e.g. DNS update, supervision, etc).

4. At the planned date, the service provider stops the concerned service instance.

5. The concerned stakeholders under the co-ordination of the “SWIM Collaboration Authority” perform the SWIM infrastructure update, if needed, at the planned date (logically later than step 4).

6. The “SWIM Collaboration Authority” updates the registry (service catalogue); the service is declared as decommissioned.

Postconditions If applicable, the AIRM/ISRM may have to be updated (e.g. if the service is not provided by any other provider and it makes no sense to keep it in the model because it is obsolete) – see uc04 -.

Alternative flow #1 In case the service was not used anymore by any user, the use case would be basically the same. There would be just minor differences, e.g., the step 2 would not be needed and it would be easier to fix the date at which the service would be stopped and decommissioned.

Postconditions

Issues 1. How to agree the target date for the decommissioning? 2. Who will agree on the date (the service provider, by a negotiation

between the service provider and the concerned consumers, involvement of the “SWIM Collaboration Authority”?)

D.12 Uc12 The SWIM Collaboration Authority depreca tes a service definition

Use Case Uc12 The SWIM Collaboration Authority deprecates a service


65 of 71



definition

Description This use-case concerns the deprecation of a service definition.

Primary Actor SWIM Auhtority • Deprecates a service defined in the ISRM (or future service

catalogue/portfolio).

Supporting Actors SWIM service provider • If still providing a service instance for such service definition,

considers the migration to another service definition.


1. The registry is up-to-date concerning the dependencies linked to this service

2. There is no provider that still provides this service.

Basic flow

1. The “SWIM Collaboration Authority”, as part of its regular ISRM ‘’support” detects that concerned service definition should be deprecated for whatever valid reason (see Issue 1).

2. The “SWIM Collaboration Authority” deprecates the concerned service definition in the ISRM

3. The “SWIM Collaboration Authority” updates the registry (service catalogue); the service is declared as deprecated.

Note: This Basic flow for this Use Case is basically a specific case of Uc04. The main interest of this Uc is its Alternate flow below.

Postconditions

Alternative flow #1 In case there were service providers still providing instances of such service definition, the flow that would be followed would be:

1. The SWIM Collaboration Authority contacts the concerned service provider(s) and informs them of its intention to deprecate the service definition in the ISRM.

2. The date for the deprecation of the service definition in the ISRM is fixed by the SWIM Collaboration Authority considering the feedback received from the concerned service provider(s).

3. At the fixed date, the SWIM Collaboration Authority deprecates the concerned service definition in the ISRM and updates the registry accordingly.


66 of 71



Postconditions Instances that continue to provide the deprecated service will lose their SWIM compliance assessment after the service definition deprecation.

Issues 1. The ‘valid’ reasons to deprecate a service will have to be defined.


67 of 71



Appendix E Engineering Artefacts

This Appendix lists the requirements stated in the main part of the document and the assumptions listed in Appendix C in the formal format defined by the SJU.

Concerning the assumptions, it is reminded that, as it was indicated in Appendix C , they need to be agreed on and, even if agreed on, are subject to change in the future.

E.1 Requirements in the main part of the document Identifier REQ-08.01.01-CONOPS-REMP.0010 Requirement An ATM information model representing the standard definition of all ATM

information shall be defined through harmonised conceptual and logical data models.

Identifier REQ-08.01.01-CONOPS-REMP.0020 Requirement An ATM services model representing the logical breakdown of required

information services and their behavioural patterns shall be defined. These services are also called ATM-specific services.

Identifier REQ-08.01.01-CONOPS-REMP.0030 Requirement information management functions (including governance), such as

operational and organisational functions for the management of user identities, discoverability of resources, security aspects such as authentication, encryption and authorisation, notification services and registration shall be defined.

Identifier REQ-08.01.01-CONOPS-REMP.0040 Requirement Specification of the SWIM technical infrastructure (SWIM-TI), i.e., the

interoperable (runtime) infrastructure (ground/ground and air/ground) via which ATM data and services are distributed, shared and consumed, shall be defined.

E.2 General assumptions Identifier REQ-08.01.01-CONOPS-ASGE.0010 Requirement SWIM can be implemented differently in various regions of the world but

interoperability shall be ensured through common standards.

E.3 SWIM Registry assumptions Identifier REQ-08.01.01-CONOPS-ASRE.0010 Requirement It is assumed that the SWIM registry stores information about the service in

all the steps of the lifecycle management, excluding the runtime.


68 of 71



Identifier REQ-08.01.01-CONOPS-ASRE.0020 Requirement It is assumed that it is not mandatory for the services to access the SWIM

registry during runtime. Identifier REQ-08.01.01-CONOPS-ASRE.0030 Requirement It is assumed that only registered stakeholders (service consumer / service

provider) can access the resources available on SWIM. Before a stakeholder can join SWIM, the stakeholder registers by providing the necessary information as defined / required by the “SWIM Collaboration Authority”.

Identifier REQ-08.01.01-CONOPS-ASRE.0040 Requirement The registration of SWIM Stakeholders can be performed at the level of an

organisation, and / or at the level of an individual. Further analysis regarding the appropriate registration level (organisation, individual) is needed.

Identifier REQ-08.01.01-CONOPS-ASRE.0050 Requirement It is assumed that the SWIM registry has a public and private part. When the

provider agrees and if no security conditions apply, the public part provides, in addition to generic information regarding SWIM, a high-level description of what is available in the private part.

Identifier REQ-08.01.01-CONOPS-ASRE.0060 Requirement It is assumed that only registered users can access the private part, provided

they have the proper authorisation. The scope of the information accessible to a registered user in the private part of the SWIM registry will depend on the authorisation rights of the user.

Identifier REQ-08.01.01-CONOPS-ASRE.0070 Requirement It is assumed that the “SWIM Collaboration Authority” manages the

authorisation rights for accessing the SWIM registry. Identifier REQ-08.01.01-CONOPS-ASRE.0080 Requirement It is assumed that the “SWIM Collaboration Authority” will define the

attributes to be provided during registration. Identifier REQ-08.01.01-CONOPS-ASRE.0090 Requirement It is assumed that both the general information (web pages) on SWIM and

the registration form will be publicly available for the stakeholders to submit their registration request.

Identifier REQ-08.01.01-CONOPS-ASRE.0100 Requirement It is assumed that the SWIM registry contains information (e.g. service

descriptions, standards, policies, certifications, regulations …) that is only available after registration (i.e. information in the private part of the registry).

Identifier REQ-08.01.01-CONOPS-ASRE.0110 Requirement It is assumed that the SWIM registry maintains the information on

compliance declarations.

E.4 Design assumptions Identifier REQ-08.01.01-CONOPS-ASDE.0010 Requirement It is assumed that the common components of the SWIM infrastructure (PKI

and Registry) are provided at the start of SWIM deployment.


69 of 71



Identifier REQ-08.01.01-CONOPS-ASDE.0020 Requirement It is assumed that the policies to be applied in the service provision and

consumption (e.g. policies on security, on authentication, etc) will be defined by the SWIM Standards and Architecture Group. Once endorsed by the SWIM Steering Group, the implementation of such policies will be done on a voluntary and collaborative basis by the impacted stakeholders.

a) assessments Identifier REQ-08.01.01-CONOPS-ASDE.0030 Requirement It is assumed that there will be no pan-European supervision of the SWIM

infrastructure elements and ATM-specific services. It is assumed that the common components and the enabling services provided by them will be supervised by the SWIM Technical Manager Group.

Identifier REQ-08.01.01-CONOPS-ASDE.0040 Requirement It is assumed that supervision encompassing one or more SWIM nodes and

ATM-Specific services (e.g. the part under the responsibility of an ANSP, or under the responsibility of a FAB) can be needed.

Identifier REQ-08.01.01-CONOPS-ASDE.0050 Requirement It is assumed that the sub-regional SWIM supervision will be defined and the

required data and services, interfaces and technologies will be standardised in the corresponding projects of the SESAR programme. When such SWIM supervision capability is implemented, it must follow the standards.

Identifier REQ-08.01.01-CONOPS-ASDE.0060 Requirement It is assumed that there will be no common component dedicated to the legal

recording function. This implies that each service provider and consumer will have to check the necessity to implement legal recording for the services it provides or consumes.

Identifier REQ-08.01.01-CONOPS-ASDE.0070 Requirement It is assumed for the time being that there will be no common component

dedicated to the Security and Authentication functions (except for the PKI), although this matter is still subject to further analysis in the context of the SESAR Programme. SWIM will define the Security and Authentication standards and policies to be applied.

Identifier REQ-08.01.01-CONOPS-ASDE.0080 Requirement It is assumed that the common PKI component will issue and revoke

certificates. Certificates to be used by the SWIM consumers and providers can be issued either by the common PKI component or by other certification authorities (e.g. one under the ANSP responsibility management, private or commercial ones)

Identifier REQ-08.01.01-CONOPS-ASDE.0090 Requirement It is assumed that SWIM will not provide common components to manage

user profiles or access rights; this management will have to be done by each individual service provider.

Identifier REQ-08.01.01-CONOPS-ASDE.0100 Requirement It is assumed that the SWIM Node is defined as a logical entity. This implies

that they can be implemented and deployed a) as their own dedicated environment, independent of the software components of the domain system or b) as a software component integrated together with other software


70 of 71



components of the domain system. Identifier REQ-08.01.01-CONOPS-ASDE.0110 Requirement It is assumed that the interfaces between the SWIM node and the software

components of the domain systems can be standardised (open) or proprietary defined. The analysis of the cases where such standardisation could be needed is ongoing.

Identifier REQ-08.01.01-CONOPS-ASDE.0120 Requirement It is assumed that co-ordination of the standards is done with other regions in

the world.

E.5 Information and service management assumptions Identifier REQ-08.01.01-CONOPS-ASIM.0010 Requirement It is assumed that the management of the lifecycle of the Reference Models

(AIRM / ISRM) will be under the responsibility of the “SWIM Collaboration Authority”.

Identifier REQ-08.01.01-CONOPS-ASIM.0020 Requirement It is assumed that the SWIM Governance will provide a mechanism whereby

all stakeholders (service consumers, service providers and “SWIM Collaboration Authority”) with an interest in the Reference Models interact between each other in such lifecycle management. It is assumed that the ISRM and AIRM follow the same change management process

Identifier REQ-08.01.01-CONOPS-ASIM.0030 Requirement It is assumed that the definition of this lifecycle management will have to

consider the following issues: a. The “SWIM Collaboration Authority” analyses the impact on

the SWIM infrastructure when a new service is requested. b. The “SWIM Collaboration Authority” will perform compliance

assessments on stakeholders, the common SWIM infrastructure components as well as the service provision.

c. The “SWIM Collaboration Authority” will assess the compliance of the stakeholder on the SWIM infrastructure. It is assumed that compliance assessment of a service provider is required when:

i. It is a new service provider; ii. It provides a new type of services; iii. Its previous compliance declaration has expired.

d. The “SWIM Collaboration Authority” will define the types of services ‘subject to compliance assessment’ / ‘not subject to compliance assessment’. A specific policy applicable to the various types of services will be defined. Depending on the ‘object under assessment’, the compliance assessment will be defined (e.g, self-assessment, run tests and upload the result, …)

e. The definition of the previous assessment tasks of the “SWIM Collaboration Authority” will have to consider the impact to stakeholders located outside the EUR region.


71 of 71



-END OF DOCUMENT-

Documents

SWIM Concept of Operations - Eurocontrol · This document describes the SWIM Concept of Operations. It provides the definition of SWIM and related aspects such as the vision, principles,