MANUAL ON SYSTEM WIDE INFORMATION MANAGEMENT

INTERIM ADVANCE EDITION

Doc 10039

AN/511

MANUAL ON SYSTEM WIDE

INFORMATION MANAGEMENT (SWIM)

CONCEPT

Disclaimer

This

document

is an

unedited version

of an

ICAO publication and has

not yet

been

approved

in final form. As content may still be

supplemented, removed,

otherwise modified during the editing

process,

the accuracy or reliability of this

version of the document cannot be

guaranteed. It

is made available

for

information purposes only and should neither be relied upon for complete

accuracy nor considered authoritative until officially approved

and

published in

its final form. ICAO does not warrant that the information contained in this

unedited document is complete and correct and shall not be liable

whatsoever

for any

damages incurred

as a

result

of its use.

Advanced edition (unedited)

International Civil Aviation Organization

(ii) Manual on System Wide Information Management (SWIM) Concept

Published in separate English, French, Russian

Spanish, Arabic and Chinese editions by the

INTERNATIONAL CIVIL AVIATION ORGANIZATION

999 Robert Bourassa Boulevard, Montréal, Quebec, Canada H3C 5H7

For ordering information and for a complete listing of sales agents

and booksellers, please go to the ICAO website at www.icao.int

Doc 10039, Manual on System Wide Information Management (SWIM) Concept

Order Number: xxxx

ISBN xxx-xx-xxxx-xxx-x

retrieval system or transmitted in any form or by any means, without prior

permission in writing from the International Civil Aviation Organization.

(iii)

AMENDMENTS

Amendments are announced in the supplements to the Publications

Catalogue; the Catalogue and its supplements are available on the ICAO

website at www.icao.int. The space below is provided to keep a record of

such amendments.

RECORD OF AMENDMENTS AND CORRIGENDA

AMENDMENTS CORRIGENDA

No. Date Entered by No. Date Entered by

(v)

TABLE OF CONTENTS

Page

Foreword .......................................................................................................................... (vii)

Abbreviations and Acronyms.................................................................................................... (ix)

Glossary of Terms

.................................................................................................................... (xiii)

Publications

.......................................................................................................................... (xvii)

Chapter 1. Introduction to the Manual ............................................................................. 1-1

1 Background ......................................................................................................... 1-1

1.2 Scope of the manual ............................................................................................ 1-2

1.3 Purpose/Objective of the manual ........................................................................... 1-2

1.4 Target audience ................................................................................................... 1-3

1.5 Organization of the manual ................................................................................... 1-3

1.6 Relationship to other documents ........................................................................... 1-4

Chapter 2. The SWIM Concept .......................................................................................... 2-1

2.1 The need for SWIM ........................................................................................................ 2-1

2.2 SWIM benefits ................................................................................................................ 2-1

2.3 SWIM definition .............................................................................................................. 2-2

2.4 SWIM use of service-oriented architecture (SOA) ......................................................... 2-3

2.5 ATM service delivery management (SDM) ................................................................... 2-4

2.6 Life-cycle management .................................................................................................. 2-5

2.7 SWIM Concept explained ............................................................................................... 2-7

2.7.1 SWIM principles

....................................................................................... 2-7

2.7.2 SWIM stakeholders .................................................................................. 2-8

2.8 Performance improvement via SWIM ..................................................................... 2-8

(vi) Manual on System Wide Information Management (SWIM) Concept

Page

Chapter 3. The SWIM Global Interoperability Framework .............................................. 3-1

3.1 SWIM layers ........................................................................................................ 3-1

3.2 Interoperability at different layers ........................................................................... 3-2

3.2.1 A flight data exchange example ................................................................. 3-3

3.2.2 SWIM enterprises and regions .................................................................. 3-5

3.3 Overview of functions and standards by layer ......................................................... 3-7

3.4 Information exchange services .............................................................................. 3-8

3.5 SWIM registry ...................................................................................................... 3-8

3.6 Information exchange models ............................................................................... 3-10

3.7 SWIM infrastructure ............................................................................................. 3-12

3.7.1 SWIM functional architecture example ....................................................... 3-14

3.7.2 SWIM Technical architecture .................................................................... 3-18

3.8 SWIM governance ............................................................................................... 3-20

3.8.1 Governance of information definition .......................................................... 3-21

3.8.2 Governance of information services ........................................................... 3-21

Chapter 4. Transition and Mixed Environment ............................................................... 4-1

4.1 Participants ......................................................................................................... 4-1

4.2 Roles and responsibilities ..................................................................................... 4-2

4.3 Key interactions ................................................................................................... 4-2

Chapter 5. Future Developments ...................................................................................... 5-1

5.1 GANP ASBU Modules on SWIM ............................................................................ 5-1

5.1.1 Technology requirements ......................................................................... 5-3

5.1.2 Deployment considerations ....................................................................... 5-3

5.2 SWIM air-ground .................................................................................................. 5-4

5.3 Interconnecting SWIM services across ASP/Regional boundaries ............................ 5-5

Appendices

A — SWIM and information domain management

B — Short description of potential candidate SWIM standards

C — Meeting the ATM system requirements

––––––––––––––––––––––

(vii)

FOREWORD

Today’s air traffic management (ATM) system comprises a wide variety of applications developed over time

for specific purposes. It is characterized by many custom communication protocols, each with their own self-

contained information systems: on board the aircraft, in the air traffic service unit, etc. Each of these

interfaces is custom designed, developed, managed, and maintained individually and locally at a significant

cost. Moreover, the ways in which ATM information is defined, structured, provided and used are specific to

most of the ATM systems.

With the expected growth in aviation demand, economic pressures and attention to environmental impact,

the ATM system will be increasingly reliant on accurate and timely information. Such information must be

organized and provided by solutions that support system-wide interoperability and secured seamless

information access and exchange.

Global improvements in information management are needed in order to integrate the ATM network for a

performance-enhancing operational scenario. These improvements are envisioned to be applied on a

System Wide Information Management (SWIM) basis. The development of SWIM infrastructure and services

should proceed in alignment with a globally-accepted operational concept that articulates the expected

SWIM implementation in terms of the benefits, enablers, features, and principles for development and

transition.

A global SWIM concept, presented in this manual, describes how stakeholders will participate in SWIM, how

it will be managed based on the agreed SWIM governance, and how it will be operated at the various levels

starting with the business and institutional down to the technical and implementation levels. As such it

provides the foundation for further developments.

Comments concerning the manual should be addressed to:

The Secretary General

International Civil Aviation Organization

999 Robert Bourassa Boulevard

Montréal, Québec H3C 5H7

Canada

(ix)

ABBREVIATIONS AND ACRONYMS

AAtS Aircraft Access to SWIM

AFTN Aeronautical Fixed Telecommunication Network

AI Aeronautical Information

AIDC ATS Inter-facility Data Communications

AIRM ATM Information Reference Model

AIS Aeronautical Information Services

AIXM Aeronautical Information Exchange Model

AMHS Aeronautical Message Handling System

ANS Air Navigation Services

ANSP Air Navigation Service Provider

AOC Airline Operations Center

API Application Program Interface

ASBU Aviation System Block Upgrades

ASP ATM Service Provider

ASTERIX All Purpose Structured Eurocontrol Surveillance Information Exchange

ATC Air Traffic Control

ATM Air Traffic Management

ATMRPP Air Traffic Management Requirements and Performance Panel

ATN Aeronautical Telecommunications Network

ATS Air Traffic Services

AU Airspace User

BP Boundary Protection

BPEL Business Process Execution Language

B2B Business to Business

CARATS Collaborative Action for Renovation of Air Traffic Systems

CDM Collaborative Decision Making

CIDIN Common ICAO Data Interchange Network

CNAS China New Generation ATM System

COI Community of Interest

COTS Commercial off-the-Shelf

DATM Digital ATM Information Management

(x) Manual on System Wide Information Management (SWIM) Concept

DDS Data Distribution Service

DNS Domain Name System (or Service)

eAIP Electronic Aeronautical Information Publication

EBP External Boundary Protection

EMB Enterprise Messaging Bus

ESB Enterprise Service Bus

ESM Enterprise Service Management

EUROCAE European Organization for Civil Aviation Equipment

FAA Federal Aviation Administration

FIXM Flight Information Exchange Model

FO Flight Object

FOC Flight Operations Center

GANP Global Air Navigation Plan

GATMOC Global ATM Operational Concept

GML Geography Markup Language

GUFI Globally Unique Flight Identifier

HTML Hypertext markup language

HTTP Hypertext Transfer Protocol

HTTPS HTTP Secure

I&A Identification and Authentication

IAIDQ International Association of Information and Data Quality

ICAO International Civil Aviation Organization

IETF Internet Engineering Task Force

IM Information Management

IP Internet Protocol

IPS Internet Protocol Suite

ISRM Information Service Reference Model

IT Information Technology

iWXXM ICAO WXXM (model)

Java EE Java Platform, Enterprise Edition

Java SE Java Platform, Standard Edition

JMS Java Messaging Service

JMX Java Management eXtension

KPA Key Performance Areas

MAC Message Authentication Code

Abbreviations and Acronyms (xi)

MEP Message Exchange Pattern

MET Meteorology

MOM Message-Oriented Middleware

MQ Message Queue

MTOM Message Transmission Optimization Mechanism

NAS National Airspace System (U.S.A)

NextGen Next Generation Air Transportation System

NOTAM Notice to Airmen

OASIS Organization for the Advancement of Structured Information Standards

OGC Open Geospatial Consortium

OLDI On-line Data Interchange

OMG Object Management Group

OWL Web Ontology Language

PEP Policy Enforcement Point

PKI Public Key Infrastructure

QoS Quality of Service

REST REpresentational State Transfer

ROI Return on Investment

SAML Security Authorization Markup Language

SAS SWIM Application Services

SASL Simple Authentication and Security Layer

SDM Service Delivery Management

SESAR Single European Sky ATM Research

SLA Service Level Agreement

SNMP Simple Network Management Protocol

SOA Service-Oriented Architecture

SSL Secure Sockets Layer

SWIM System Wide Information Management

TBD To be determined

TCP Transmission Control Protocol

TFM Traffic Flow Management

TLS Transport Layer Security

TMI Traffic Management Initiative

UDDI Universal Description, Discovery, and Integration

URL Uniform Resource Locator

(xii) Manual on System Wide Information Management (SWIM) Concept

VoIP Voice Over Internet Protocol

VPN Virtual Private Network

W3C World Wide Web Consortium

WAN Wide Area Network

WCS Web Coverage Service

WFS Web Feature Service

WMS Web Map Service

WS Web Services

WSDL Web Services Description Language

WSDM Web Services Distributed Management

WSF Web Services Framework

WS-RM WS-Reliable Messaging

WS-RT WS-Resource Transfer

WXXM Weather Information Exchange Model

XML eXtensible Markup Language

XPath XML Path Language

XQuery XML Query Language

XSD XML Schema Definition

XSLT eXtensible Stylesheet Language Transformations

––––––––––––––––––––––

(xiii)

GLOSSARY OF TERMS

When the subsequent terms are used in this manual, they have the following meanings:

Accessible. An information service that may be consumed by means of either the request/response or

publish-subscribe operational pattern is accessible.

Application. See SWIM-enabled application.

Authorization. Permission to engage in a specific activity. A SWIM-enabled application is authorized if it

has permission to engage in a specific activity, such as subscribing to a publication service.

Build-time. The lifecycle stage in which an information provider or consumer is under development, e.g.,

pre-operational. Also called design-time.

Community of interest (COI). A collaborative group of users who must exchange information in pursuit of

shared goals, interests, missions or business processes. COIs are established in a variety of ways and

may be composed of members from one or more functions and organizations as needed for a shared

mission.

Consumer. See Information consumer.

Core Services. Functional capabilities of the SWIM Infrastructure such as interface management, request-

reply and publish-subscribe messaging, service security, and enterprise service management.

Design-time. The lifecycle stage in which an information provider or consumer is under development, e.g.,

pre-operational. Also called build-time.

Discoverable. An information service that may be discovered by a potential user is discoverable.

Discovery. See Service Discovery.

Information Dissemination. The act of distributing information to one or more recipients.

Domain. A set of business activities that: (a) have a common mission or purpose; (b) share common

operational and functional requirements and capabilities; and (c) needs to be considered separately

from other activities, while maintaining the relevant relationships with them.

Enterprise. See SWIM Enterprise.

Enterprise Service Management (ESM). The SWIM core service addressing the management of SWIM-

enabled services, including performance and availability. ESM provides the ability to monitor, manage,

and scale services within the enterprise to ensure the capability offerings are available, responsive and

scalable to the operational environment supported.

Expose. To make a service interface discoverable. In SWIM, information services are exposed via one or

more SWIM Service Registries.

(xiv) Manual on System Wide Information Management (SWIM) Concept

Extensibility. A characteristic of an interface (or service) that continues to support previously conformant

users after it has been modified (i.e. extended) for new users.

Filtering rules. Filtering rules define constraints on an information provider with respect to the data to be

provided to a consumer.

Governance. SWIM governance is characterized by the people, policies, and processes required for

leading, communicating, guiding, and enforcing the stakeholder organizational behaviours needed for

global interoperability.

Information Consumer. The person, application or system consuming an information service. Also called

consumer.

Information Domain. Focused on identifying, defining, and satisfying the information needs of the set of

business activities associated with a specific domain.

Information Exchange Model. An Information Exchange Model is designed to enable the management and

distribution of information services data in digital format. Normally this is defined for a specific domain

such as aeronautical information.

Information Model. An information model is a representation of concepts and the relationships, constraints,

rules, and operations to specify data semantics for a chosen domain.

Information Producer. The person, application or system producing an information service. Also called

producer.

Information Provider. Information service provider. Also called provider.

Information Service. An information service provides information consumers access to one or more

applications or systems by means of the SWIM core services. It encapsulates a distinct set of

operations logic within a well-defined functional boundary.

Infrastructure. The logical and physical (i.e., hardware and software) elements that together provide

(SWIM) functionality.

Interface Management. The SWIM core service providing a standard interoperable means for description,

access, invocation and manipulation of resources to enable compatible communications between ATM

information providers and consumers.

Message. A structured information exchange package consisting of a header and payload.

Messaging. The SWIM core service that provides delivery of data and notifications between applications

and systems.

Middleware. Middleware is software that serves to "glue together" or mediate between two separate and

often already existing messaging standards. Typically considered as being at the messaging layer and

the transport layer.

Notification. An indication presented to a user regarding the status of a system or an element in a system.

In a publish-subscribe system, a publication may consist of notifications about data rather than the data

itself.

Glossary of terms (xv)

Operational Pattern. An operational pattern describes the essential flow of a SWIM-enabled service. It is

based on the term pattern, which describes the essential features of a common solution to a common

problem in software development.

Publication. An information service based on the publish-subscribe operational pattern.

Publisher. An information service provider utilizing the publish-subscribe operational pattern.

Publish-subscribe. A one-to-many operational pattern in which an information provider called a publisher

makes its services available (i.e. publishes) on a subscription basis. An information consumer in this

paradigm called a subscriber requests access to the publication service via a subscription request.

Based on the nature of their subscriptions, subscribers will continue to receive updates from the

publisher until they request the termination of their subscription.

Reliable Delivery. A characteristic of information transfer in which the transfer is either successful or the

sender of the information is notified of the failure of the transfer.

Request/Response. The operational pattern distinguished by a two-way interaction between a requesting

entity and a responding entity. This pattern is also called Request/reply.

REST. A REpresentational State Transfer (REST) architecture is a simpler way to implement web services

using HTTP and other application protocols (rather than SOAP and WSDL).

Runtime. The lifecycle stage in which an information provider or consumer is operational.

Security. The SWIM core service responsible for the protection of information, operation, assets and

participants from unauthorized access or attack.

Selection Criteria. Selection criteria provide the means by which a consumer identifies the data of interest

to an information provider.

Service. See Information Service.

Service Deregistration. The act of deleting an entry from the SWIM Service Registry.

Service Discovery. The act of locating and accessing the schema for a specific information service. Also

referred to as discovery.

Service-oriented. Pertaining to a service-oriented architecture.

Service-Oriented Architecture (SOA). An approach to integrate applications running on heterogeneous

platforms using industry-wide acceptable standards. Each application is exposed as one or more

services where each information service provides a particular functionality. Information services

(applications) communicate with each other in a coordinated sequence that is defined by a business

process.

Service Provider. An organization or entity providing a service. Refers (in this document) to ASPs or

vendors that provide network or other value-added services; distinct from an information provider.

Service Registration. The act of creating an entry in the SWIM Service Registry.

Service Registry. SWIM service registry.

(xvi) Manual on System Wide Information Management (SWIM) Concept

SOAP. XML based web service protocol.

State. An ICAO Member State.

Subscriber. A consumer of a publication service.

Subscription. The process of becoming a subscriber to a publication service. Subscription consists of

subscription administration and subscription activation.

Subscription Activation. The act of initiating dissemination of publication data and notifications to a

subscriber. Subscription can occur during either design-time or runtime.

Subscription Administration. The act of administering a subscription, including authorization, access list

and other database updates, etc.

System-Wide Information Management (SWIM). SWIM consists of standards, infrastructure and

governance enabling the management of ATM related information and its exchange between qualified

parties via interoperable services.

SWIM Access Point. A SWIM access point is a logical entity which bundles a number of technical

capabilities (e.g. messaging, security, logging, interface management, etc.).

SWIM core services. The fundamental SWIM mechanisms that enable information sharing: Interface

Management, Messaging, Enterprise Service Management (ESM) and Security. These services are

solution-agnostic (not limited to a single process or solution environment) and have a high degree of

autonomy so that they support reuse. Also referred to as “core services”.

SWIM core services infrastructure. Hardware and software elements that provide the SWIM core

services. Also referred to as “core services infrastructure”.

SWIM-enabled application. A SWIM enabled application consumes or provides SWIM information services

using SWIM standards. Also referred to as “application”.

SWIM-enabled service. An information service that may be accessed via SWIM.

SWIM Enterprise. A SWIM enterprise can be an ATM service provider (ASP), a group of ASPs, or an

Airspace User, or an ATM support industry that has full control of the implementation planning and

execution within the enterprise.

SWIM Region. A collection of SWIM enterprises that have agreed upon common regional governance and

internal standards. A region will be delineated by the area of influence of a given governance structure

that defines the standards, policies, etc. that are applicable to all the participants within the region.

SWIM Registry. A static registry or directory containing entries with the information necessary to discover

and access services. The Registry utilizes a formal registration process to store, catalog and manage

metadata relevant to the services, thereby enabling the search, identification and understanding of

resources. Also referred to as “Service Registry” or “Registry”.

SWIM User. Depending on context, a person, organization or application authorized to provide and/or

consume services via SWIM.

–––––––––––––––––––––––

(xvii)

PUBLICATIONS

(used in this manual)

[1] "Procedures for Air Navigation Services - Air Traffic Management, Doc. 4444, 15th edition," ICAO,

Montreal, Canada, 2007.

[2] "Annex 15 :Aeronautical Information Services (AIS)," ICAO, Montreal, Canada, 2009.

[3] "Global Air Traffic Management (ATM) Operational Concept, ICAO Doc. 9854," ICAO, Montreal,

Canada, First edition 2005.

[4] "Manual on Air Traffic Management System Requirements, ICAO Doc. 9882," ICAO, Montreal, Canada,

First edition 2007.

[5] "Global Air Navigation Plan, ICAO Doc. 9750," ICAO, Montreal, Canada, 4th edition 2013.

[6] "Manual on Flight and Flow - Information for a Collaborative Environment, ICAO Doc. 9965," ICAO,

Montreal, Canada, 2012.

[7] "Manual on Collaborative Air Traffic Flow Management, ICAO Doc. 9971," ICAO, Montreal, Canada,

2012.

[8] "Aviation System Block Upgrades - Working Document," ICAO, Montreal, Canada, Mar 2013.

[9] "AIXM - Aeronautical Information Exchange Model," FAA/Eurocontrol, March 2013. [Online]. Available:

www.aixm.aero.

[10] "FIXM - Flight Information Exchange Model," 2012. [Online]. Available: http://www.fixm.aero/.

[11] "WXXM - Weather Information Exchange Model," FAA/Eurocontrol, 2011. [Online]. Available:

http://www.wxxm.aero.

[12] "IWXXM - ICAO Meteorological Information Exchange Model," World Meteorological

Organization/ICAO, 2013. [Online]. Available: http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-

index.php?page=AvXML-1. [Accessed 27 02 2014].

[13] "AIDX - Aviation Information Data Exchange," 2012. [Online]. Available: http://www.aidx.aero.

[14] "World Wide Web Consortium (W3C)," W3C, 1 Apr 2013. [Online]. Available: www.w3c.org.

[15] "Unified Modeling Language (UML)," Object Management Group, [Online]. Available: www.uml.org.

[Accessed Aug 2013].

[16] "SESAR SWIM Concept of Operations, edition 00.02.03," SESAR Joint Undertaking, 8 Jun 2012.

[Online]. Available: http://www.eurocontrol.int/sites/default/files/content/documents/information-

management/del08.01.01-d40-swim_conops.pdf. [Accessed Sep 2013].

[17] "OASIS SOA Reference Model TC," OASIS, [Online]. Available: http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=soa-rm. [Accessed Sep 2013].

[18] "Air Traffic Management (ATM SDM) Description, Circular 335 - Advanced edition," ICAO, Montreal,

Canada, 2013.

[19] The Open Group, "SOA Governance Framework," Aug 2009. [Online]. Available:

pubs.opengroup.org/onlinepubs/9699909699/toc.pdf. [Accessed Sep 2013].

[20] "SWIM Service Life Management Processes, v1.0," Federal Aviation Administration, Washington, DC,

June 2010.

[21] "Manual on Performance of the

ir Navigation System, ICAO Doc. 9883," ICAO, Montreal, Canada, Feb

2008.

[22] "Airport Collaborative Decision Making," European Aiport CDM, Sep 2013. [Online]. Available:

http://www.euro-cdm.org/concept_introduction.php.

[23] E. Eyuboglu and J. Pouzet, "ATM Communications - AMHS," in 12th Air Navigation Conference,

Montreal, Canada, Nov 2012.

(xviii) Manual on System Wide Information Management (SWIM) Concept

[24] "Manual on detailed Technical Specifications for the ATN using ISO/OSI protocols - ATS Message

Handling Service (ICAO Doc 9880 Part IIB)," ICAO, Montreal, Canada, 2012.

[25] "Aircraft Access to SWIM (AAtS) Initial Concept of Operations (ConOps) - Draft Report," Federal

Aviation Administration, Washington, DC, May 2013.

[26] E. Lasschyut, M. van Hakken, W. Treurniet and M. Visser, "How to make an effective Information

Exchange Model or the Good and Bad aspects of the NATO JC3IEDM," in NATO RTO IST-042

Symposium on "Coalition C4ISR Architectures and Information Exchange Capabilities", The Hague, The

Netherlands, 2004.

[27] M. Eppler, Managing Information Quality: Increasign the value of information in Knowledge-intensive

products and processes (2nd ed.), Heidelberg, Germany: Springer, 2006.

[28] T. Heath and C. Bizer, Linked Data: Evolving the Web into a Global Data Space, U.S.A: Morgan and

Claypool Publishers, 2011.

[29] J. McGregor, "Validating Domain Models," unknown. [Online]. Available:

http://www.cs.clemson.edu/~johnmc/joop/col19/column19.html. [Accessed 1 Nov 2013].

[30] "OGC Web Feature Service," Open Geospatial Consortium, May 2005. [Online]. Available:

http://www.opengeospatial.org/standards/wfs.

[31] "OGC Web Map Service," Open Gepspatial Consortium, 2005. [Online]. Available:

http://www.opengeospatial.org/standards/wms.

[32] "OMG Data Distribution Service Portal," Object Management Group (OMG), September 2013. [Online].

Available: http://portals.omg.org/dds.

––––––––––––––––––––––

(1-1)

Chapter 1

INTRODUCTION TO THE MANUAL

1.1 Background

1.1.1

The System Wide Information Management (SWIM) will complement human-to-human with

machine-to-machine communication, and improve data distribution and accessibility in terms of quality of the

data exchanged. However, the flexibility whereby human intelligence and oral communication, by their very

nature, can adapt to situational nuances of communication and operations has to be engineered into

Information Technology (IT) systems. Hence, IT systems will increasingly need to “ask for / discover”

operationally-relevant facts, depending on the circumstances, rather than remain “being informed” by pre-

agreed messages.

1.1.2 Implementation of the SWIM Concept, outlined in this document, must address the challenge of

creating an “interoperability environment” which allows the SWIM IT systems to cope with the full complexity

of operational information exchanges. The SWIM Concept introduces a significant change in the business

practices of managing information during the entire life cycle of an ATM process. The implementation of

SWIM seeks to provide quality information to the right people with the right systems at the right time. The

SWIM environment shifts the ATM information architecture paradigm from point-to-point data exchanges to

system-wide interoperability.

1.1.3 According to the Convention on International Civil Aviation (Doc 7300) and its Annexes, the

International Civil Aviation Organization (ICAO) is entrusted, among others, with the role of establishing

communication and information standards. For example, the Procedures for Air Navigation Services — Air

Traffic Management (Doc 4444) standardizes both the phraseology used by pilots and controllers, and the

data exchanged to communicate flight intent and flight reports. Similarly, Annex 15 — Aeronautical

Information Services standardizes aeronautical information services and products. These documents

provide a template for the provision of aeronautical information with detailed requirements for aeronautical

data, implemented using technology that is becoming increasingly outdated.

1.1.4 The Global Air Traffic Management (ATM) Operational Concept (Doc 9854) envisages the

application of SWIM to promote information-based ATM integration, stated as follows:

“The ATM operational concept envisages the application of a system-wide information

management concept, where information management solutions will be defined at the overall

system level, rather than individually at each major subsystem (programme/ project/ process/

function) and interface level, as has happened in the past.”

1.1.5 The application of SWIM in support of the global ATM operational concept was further

reinforced in the Manual on Air Traffic Management System Requirements (Doc 9882).

1.1.6 SWIM is an integral part of the Global Air Navigation Plan (GANP) (Doc 9750), fourth edition,

and is covered in a number of the aviation system block upgrades (ASBU) modules. Additional information

on the way SWIM is currently integrated in the GANP/ASBUs is provided in Section 5.1.

(1-2) Manual on System Wide Information Management (SWIM) Concept

1.1.7 Over the course of the past years, research into SWIM concepts and solutions has taken place,

and is already at various stages of development in a non-harmonized way in different ICAO Member States.

Modernization programmes such as the Collaborative Action for Renovation of Air Traffic Systems

(CARATS) in Japan, the China New Generation ATM System (CNAS), the Next Generation Air

Transportation System (NextGen) in the United States and the Single European Sky ATM Research

(SESAR) in Europe, all consider the implementation of SWIM as a fundamental requirement for future ATM

systems.

1.2 SCOPE OF THE MANUAL

The scope of the manual is limited to articulating the concept for SWIM necessary to achieve global

interoperability. The manual further defines terms and describes a common framework to facilitate

discussions and promote interoperability.

1.3 PURPOSE/OBJECTIVE OF THE MANUAL

1.3.1

The purpose of the manual is to provide a vision for interoperable global information

management and addresses the transition to a mixed operational environment. Its objectives are two-fold: 1)

to assist in the creation of a common lexicon to ease communication when States/groups desire to

coordinate on related topics; and 2) to provide a background framework for assisting States/Regions which

have not yet undertaken the development and implementation of SWIM instantiations.

1.3.2 This manual establishes guidelines for providing information services via a Service-Oriented

Architecture (SOA) approach that enables ATM service providers (ASPs) to deliver global interoperability.

While standards will permit interoperability, the SWIM Concept does not prescribe, or expect, a single global

implementation of SWIM.

1.3.3 This manual further elaborates the information management concept articulated in the Global

ATM Operational Concept (Doc 9854). The manual addresses the following:

a) definition of terms of relevance to information management to enable international discourse

on system-wide information interoperability;

b) a layered description of SWIM enabling the reader to understand representative standards

that are applicable to different information management elements;

c) the layered model further enables an understanding of the separation of the information

management from the information being managed and the consumers

of that information;

d) a description, through operational scenarios including the actors, of the expected

roles and responsibilities of the actors in the scenarios, and the information

exchange through the various SWIM layers; and

e) a description of how SWIM will operate in a transitional environment with some

legacy ASPs.

Chapter 1. Introduction 1-3

1.4 TARGET AUDIENCE

This manual has been developed for members of the ATM community seeking information on integrating

their information management within a global SWIM construct. The manual does not specifically address

any individual member of the ATM community with interested parties to be found in all of the following

communities:

a) ATM service providers;

b) airspace providers;

c) airspace users;

d) aerodrome;

e) meteorological (MET) information providers;

f) ATM support industry;

g) ICAO;

h) regulatory authorities;

i) States; and

j) any direct consumer of information from the ATM system

1.5 ORGANIZATION OF THE MANUAL

.5.1 The manual is organized as follows:

a) Chapter 1 gives the background and the purpose and scope of the document;

b) Chapter 2 provides the need for a SWIM concept, the definition and the benefits of SWIM,

and explains the SWIM concept;

c) Chapter 3 considers the SWIM global interoperability framework and its details. These

consider interoperability and governance at the information exchange services, information

exchange models, and at the SWIM infrastructure level. The functions and representative

standards are provided;

d) Chapter 4 considers the transition to SWIM and operations in a mixed environment;

e) Chapter 5 considers some future developments; and

f) A number of appendices provide supporting material.

It is recognized that information from the ATM system that is publicly available may be re-packaged for

broader consumption outside of the scope of this document.

(1-4) Manual on System Wide Information Management (SWIM) Concept

1.6 RELATIONSHIP TO OTHER DOCUMENTS

1.6.1

The Global Air Traffic Management (ATM) Operational Concept (Doc 9854) describes a future

concept in which information is managed system-wide. Based upon this concept, the Manual on Air Traffic

Management System Requirements (Doc 9882) explicitly identifies the implementation of SWIM as a

requirement for the future ATM System.

1.6.2 The Manual on Flight and Flow Information for a Collaborative Environment (FF-ICE)

(Doc 9965) provides a vision specifically for flight information that relies on SWIM as a mechanism for

exchange of flight information while managing the consistency and timeliness of the information. The Manual

on Collaborative Air Traffic Flow Management (Doc 9971) describes the importance of information exchange

in establishing a collaborative environment.

1.6.3 There are two GANP (Doc 9750) ASBU modules that focus on SWIM development: B1-SWIM

and B2-SWIM. The ASBU module B1-SWIM is termed ‘Performance Improvement through the application of

SWIM’ and applies to the “implementation of SWIM services (applications and infrastructure) creating the

aviation intranet based on standard data models, and internet-based protocols to maximize interoperability”.

The ASBU module B2-SWIM is termed ‘Enabling Airborne Participation in collaborative ATM through SWIM’

and applies to the “connection of the aircraft as an information node in SWIM enabling participation in

collaborative ATM processes with access to rich voluminous dynamic data including meteorology”.

1.6.4 Closely related to the management of information, are the standards that define the information

content, format and rules for exchange. Some of these are described on websites articulating information

exchange standards applicable to aeronautical information (AIXM – Aeronautical Information Exchange

Model, 2013), flight information (FIXM – Flight Information Exchange Model, 2012), meteorological

information (WXXM – Weather Information Exchange Model, 2011), (IWXXM – ICAO Meteorological

Information Exchange Model, 2013), and aviation information (AIDX – Aviation Information Data Exchange,

2012).

1.6.5 Other existing standards are expected to be applied at all levels of the SWIM framework which

include the World Wide Web Consortium (W3C) (2013) specifications, Unified Modelling Language (UML),

and the standards for network layer exchange.

1.6.6 It is expected that international information technology standards will eventually be adopted for

SWIM implementations. However, associated technologies and technical standards necessary for

implementation of SWIM are presently evolving at a rapid pace. This manual, therefore, provides

representative examples in Appendix B of the types of standards and technologies necessary for

international harmonization but does not specify the standards at this point.

––––––––––––––––––––––––

2-1

Chapter 2

THE SWIM CONCEPT

2.1 THE NEED FOR SWIM

2.1.1

The present-day model for information exchange acts as a constraint on the forward-looking

implementation of future performance-enhancing operational improvements. Chief limitations are:

a) systems have not been designed and implemented to be globally interoperable within

globally-agreed parameters;

b) many interfaces, which were designed to support point-to-point or application-to-application

exchanges, have limited flexibility to accommodate new users, additional systems, new

content or changed formats;

c) message-size limitations and a non-scalable approach to information exchange with the

present infrastructure;

d) the current infrastructure can make it difficult and costly for one stakeholder to access, on a

timely basis, information originated by another stakeholder;

e) the current variety of systems and exchange models makes it challenging to devise security

frameworks across systems and stakeholders so as to support the increasing need for open

and timely data exchange whilst at the same time respecting the legitimate security

concerns of all stakeholders; and

f) currently, most organizations manage their ATM information in partial isolation leading to

duplication and inconsistencies.

2.1.2 The Global Air Traffic Management Operational Concept (Doc 9854) acknowledges that the

shortcomings of the current provision and management of ATM related information will be addressed, in

part, by improvements in information management (IM). The global improvements in information

management are intended to integrate the ATM network in the information sense, not just in the system

sense, and are envisioned to be applied as a SWIM concept.

2.2 SWIM BENEFITS

2.2.1 SWIM contributes to achieving the following benefits:

a) improved decision making by all stakeholders during all strategic and tactical phases of

flight (pre-flight, in-flight and post-flight) through:

(i) improved shared situational awareness; and

2-2

2.3.1

ATM-relat

2.3.2

the infrast

application

as used in

2.3.4

deployme

users ther

operationa

manual wi

concept. A

SDM is

(ii)

b) incr

c) mor

for i

d) loos

and

e) sup

SWIM con

d informatio

The scope

ucture requi

consume

this manual

SWIM is

t lies in the

of (a curved

ATM servic

l therefore r

detailed glo

discussed la

improved av

ased system

flexible and

formation ex

coupling w

onsumers;

ort of ATM S

ists of stand

and its exch

of SWIM is

ed to exch

r provide S

esignates a

ot meant to

needs of its

arrow is us

es through

ference thi

al interopera

er in Section

Manual o

ilability of q

performanc

cost-effectiv

hange;

ich minimiz

ervice Delive

2.3 S

ards, infrast

ange betwe

illustrated in

nge informa

IM informati

ATM SWIM

be a stand

client applic

d to indicat

pplications t

application

bility framew

Figure 1.

2.5

System Wi

ality data an

;

communic

s the impa

ry Managem

IM DEFINI

ucture and

n qualified p

Figure 1. It i

ion between

n services

enabled app

alone conce

tions which,

this associa

at define th

layer in ord

rk is introdu

he Scope o

e Informatio

information

tions by the

t of change

nt (SDM)

ION

overnance

rties via inte

ncludes info

SWIM-ena

sing SWIM

lication, unle

pt. The justi

although n

tion). SWIM

e scope an

r to facilitat

ed in Chapt

SWIM

Manageme

from authori

pplication o

between in

nabling the

roperable se

mation exch

led applicati

tandards. T

s stated oth

ication for it

t part of S

conveys the

quality of t

the prese

r 3.

t (SWIM) C

ative source

common st

ormation pr

managemen

vices.

nge standa

ns. SWIM-

e term ‘app

rwise.

s developm

IM, are the

requirement

e informatio

tation of the

ncept

;

ndards

ducers

of the

ds and

nabled

ication’

nt and

rimary

of the

n. This

SWIM

Chapter 2. The SWIM concept 2-3

2.3.5 Interoperability is achieved on a global scale through the use of common information exchange

models for information elements of interest, the use of common services for information exchange, and the

use of appropriate technology and standards.

2.3.6 These models for ATM information have been defined in harmonized conceptual and logical

data models. The models describe the data used in different information domains such as aeronautical,

flight, meteorology, and surveillance domains. They also describe logical format and structure of the data

elements that make up these domains.

2.3.7 Similarly, a definition of information services is necessary to indicate what types of services are

provided, their behaviour, their performance levels and ways they can be accessed.

2.3.8 SWIM operates over an interoperable (runtime) infrastructure (ground/ground and air/ground)

through which the data and information will be distributed. Its implementation may, depending on the specific

needs profile, differ from one stakeholder to another, both in terms of scope and method of implementation.

It will offer technical services based as much as possible on mainstream information technologies (IT). It will

preferably be based on commercial off-the-shelf (COTS) products and services, but it is possible that in

some cases specific software may need to be developed. Typically dedicated and secured IP networks and

the Internet will provide the underlying basic ground/ground connectivity.

2.3.9 Achieving interoperability across all areas illustrated in Figure 1 requires that SWIM adheres to

agreed-upon governance. Governance is further described in Section 3.8.

2.4 SWIM USE OF SERVICE-ORIENTED ARCHITECTURE (SOA)

2.4.1 Service-Oriented Architecture (SOA) is a general concept or paradigm for “organizing and

utilizing distributed capabilities that may be under the control of different owners” (OASIS SOA Reference

Model TC). While there is no formally-agreed definition of SOA, it is generally considered that partitioning of

functionality into unassociated, self-contained and, therefore, reusable services that can be discovered by

potential users is a key feature that discriminates SOA from more traditional architectural paradigms. The

SOA paradigm has been used successfully in many industries including manufacturing, banking, health

care, and merchandise retailing.

2.4.2 A service orientation is assumed for information exchanges between SWIM stakeholders, i.e.

an information provider publishes and exposes its services for the use of information consumers; this is

done via interconnected registries which list the services and the specific details for their use. One of the

benefits of SOA is the promotion of “loose coupling”. Loose coupling means that an information provider has

a reduced impact on the information consumer. Dependencies are minimized allowing components and

services to operate with as little knowledge as possible of other components or services (i.e. a consumer

should need to understand only what is absolutely required to invoke a service and no more).

2.4.3 While service orientation is necessary for global SWIM-enabled services, implementation of

SOA within individual stakeholders has to be balanced with any cost-benefit that it might endow.

2.4.4 SOA is being pursued internally by ASPs that have a large number of ATM systems which need

to cooperate in order to provide ATM functions. ASPs and other stakeholders with few systems may opt to

retain their current architectures as long as the SWIM information services that they wish to

provide/consume are exposed externally in a standardized SWIM manner. (See Section 3.4 on information

exchange services).

2-4 Manual on System Wide Information Management (SWIM) Concept

2.4.5 When empowered by SOA, SWIM will enable stakeholders to capitalize on opportunities, new

services and capabilities by drawing upon industry best practices which have been proven to provide these

benefits:

a) More agile service delivery: SOA enables organizations to respond quickly to new business

imperatives, develop distinctive new capabilities and leverage existing services for true

responsiveness by delivering information based services to the aviation industry;

b) Cost reductions: SOA promotes the reuse of existing assets, increasing efficiency and

reducing application development costs and by sharing the most readily available code

bases and services between ASPs. An integrated SWIM implementation improves

coordination across all components of the modern ATM system reducing costly and time-

consuming data conversion;

c) Return on Investment (ROI): SWIM and SOA do not necessarily only provide a financial

benefit on their own. SWIM and SOA also provide a foundation for the high performance

and future value to be found in the projects that they enable. Thus, even if they don’t have a

positive ROI on their own terms, SWIM/SOA projects must support a positive, combined ROI

with the projects they enable – and may also boost it;

d) Meet IT goals: The technological value of SWIM includes:

1) Simpler systems: SOA is based on industry standards and can reduce complexity

when compared with integrating systems on a solution-by-solution basis. It also

enables future applications to mesh seamlessly with existing standards-based

services;

2) Lowering maintenance costs: Simplicity and ease-of-maintenance signify that support

costs are reduced;

3) Enhancing architectural flexibility: SOA supports the building of next-generation

performance-driven composite solutions that consolidate numerous business

processes from multiple systems; and

4) Lowering integration costs: SOA makes it possible for organizations to develop,

implement and re-use processes that are technically enabled and integrated through

the use of open technology standards. In addition, connectivity, data exchange and

process integration efforts are simplified, reducing integration-related development

and support costs.

2.5 ATM SERVICE DELIVERY MANAGEMENT (SDM)

2.5.1 One of the components of the Global ATM Operational Concept (Doc 9854) is the ATM service

delivery management (ATM SDM). The ATM SDM concept component is described in Circular 335. The

ATM SDM will operate seamlessly from gate to gate for all phases of flight and across all service providers.

It will address the balance and consolidation of the decisions of the various other processes/services, as

well as the time horizon at which, and the conditions under which, these decisions are made. Key

conceptual changes include:

Chapter 2. The SWIM concept 2-5

a) services to be delivered by the ATM SDM component will be established on an as-required

basis subject to ATM system design. Once established, service provision will be done

through on-request or event-driven basis;

b) ATM system design will be determined through a collaborative decision-making (CDM)

process and by taking into account requirements of system-wide safety and performance

cases;

c) services delivered by the ATM SDM component will, through CDM, balance and optimize

user-requested trajectories to achieve the ATM community’s expectations; and

d) management by trajectory will involve the development of an agreement that extends

through all the physical phases of flight.

2.5.2 Carrying out ATM SDM entails analyzing and deciding what assets need to be deployed in order

to deliver the required services and obtain the expected performance, while considering the following:

a) across and within global concept components — airspace organization, aerodrome

operations, user operations, etc.;

b) across and within time horizons — from long-term planning through to tactical decisions; and

c) end-to-end — whether seen as gate-to-gate, or en route-to-en route.

2.5.3 Planning and conducting of SWIM will take place through ATM SDM. The ATM SDM defines the

rules and means for safe and secure information sharing between all the participants. It acts as a focal point

for coordination between the different service providers (i.e. through Letter of Agreement, Service Level

Agreement, information sharing, delegation of service provision).

2.5.4 Doing ATM SDM requires that accredited, quality-assured, timely information be shared by

decision makers on a system-wide basis to ensure the cohesion and linkage between concept components

and to build an integrated picture. Therefore, the needs established through ATM SDM set the overall

requirements for SWIM. Taking these needs into account, the SWIM concept provides consolidated

guidance, addressing topics such as SWIM scope (e.g. models, infrastructure, applications), principles (e.g.

open standards, service-oriented architecture), and governance (e.g. approval and evolution of standards,

allocation of functions/infrastructure to stakeholders, definition of roles and responsibilities).

2.6 LIFE-CYCLE MANAGEMENT

2.6.1

The important role in SWIM of the overall governance of the service approach is described in

Section 3.8. The SWIM registry is an important enabler for managing an information service. The service

lifecycle will need to be managed as a transparent process for the stakeholders.

2.6.2 The SOA Governance Framework (The Open Group, 2009) enables organizations to define and

deploy their own focused and customized SOA governance model. The framework uses the concept of a

solution portfolio (designed to meet business needs) and a service portfolio that results from the solution

portfolio. It then proposes a way to manage both the solutions and the services portfolios and their lifecycles

through the planning and through the design and operational phases.

2-6

2.6.3

example,

lifecycle fo

2.6.4

updates.

by consu

to the SL

There may

2.6.5

managing

use wides

service, w

Some SWI

ne SWIM pi

a producer.

a) iden

b) prop

c) defi

d) dev

e) verifi

f) prod

g) depr

h) retir

Changing r

pdates whic

ers (i.e. not

but not by

also be revi

While the

hanges to a

read. Produ

ile consum

pioneers

neer ANSP i

ification of th

sal as a S

ition of the in

lopment of t

cation of the

uction and d

cation of th

ment of the i

ure 1. Exa

ervice Ope

quirements,

require a c

ackward-co

ny known

ion updates

(

initial infor

service is m

ers will hav

rs are looki

Manual o

ave develo

entifies the

e business n

IM informati

formation se

e informatio

information

ployment of

information

nformation s

ple of a Ser

ator, and Se

during the li

ange to the

patible) are

onsumers (i.

(

i.e. bug fixe

ation servic

re complica

to balance

g for “stabi

System Wi

ed their cu

ollowing sta

ed;

n service (a

vice;

service;.

ervice;

he informati

service (afte

rvice.

ice Lifecycl

rvice Provid

fe of an info

Service Lev

considered

. are back

) where no c

e design a

ed once the i

the need to

ity” of the

e Informatio

tomized S

es and spe

d approval);

n service;

decision to

e for Servic

er (Includin

rmation serv

l Agreement

o be major.

ard-compati

anges are n

d deploym

nformation s

“improve” th

xisting servi

Manageme

IM Governa

ifies the pro

etire); and

Producer,

Brokers)

ce, can pro

(SLA) and a

Updates whi

le) are con

eeded to the

nt is relati

rvice has b

e functionali

es. This is

t (SWIM) C

nce Models.

esses in the

uce major o

lso require c

h require a

idered to be

SLA.

ely straightf

en deployed

y of the info

further com

ncept

As an

service

r minor

anges

hange

minor.

rward,

and its

mation

licated

Chapter 2. The SWIM concept 2-7

because some producers may not be aware of all the consumers. The deprecation cycle might have to be

prolonged and different versions of the service might have to be supported at a given time. Each enterprise

will need to coordinate with major stakeholders and within its region, as applicable. Similarly, regions will

need to coordinate with other regions.

2.7 SWIM CONCEPT EXPLAINED

2.7.1 SWIM Principles

2.7.1.1 SWIM should utilize the best practices from different information communities to meet the

needs of global ATM. The aim of SWIM is to provide information to users with access to relevant and

mutually understood information in an interoperable manner. Interoperability is the ability of diverse systems

belonging to different organizations to exchange information. This includes the ability, not only to

communicate and exchange data, but also to interpret the information exchanged in a meaningful manner.

Information should be of the right quality, provided at the right time and delivered to the right place, hence

enabling net-centric ATM operations. In order to achieve this objective efficiently the following SWIM

principles should be adhered to:

a) separation of information provision and information consumption to the extent possible. In

the ATM network, almost every participant is a producer and a consumer of information. It is

not always appropriate to decide in advance who will need what type of information and

from whom it would be obtained and when. The key issue is to decouple producers of

information from the possible consumers in such a way that the number and the nature of

the consumers can evolve through time;

b) loose system coupling. Where each of its components has, or makes use of, as little

knowledge as possible of the definitions of other distinct components. By doing this the

barriers between systems and applications are minimized, and interfaces are compatible;

c) use of open standards. An open standard is one that is publicly available and has various

rights of use associated with it. It may also have various properties describing its design

phase (e.g. open process); and

d) use of interoperable services. After an analysis of the processes and needs of business

domains, the required functionality is developed, packaged and implemented as a suite of

interoperable services that can be used in a flexible way within multiple separate systems.

2.7.1.2 In order to achieve global interoperability, the above SWIM principles should be applied.

Although this does not mandate the internal implementation of loose coupling and open standards (SOA), a

particular stakeholder, within its own system, may choose to do so or not. Some ASPs may implement SOA

internally for some of their systems to promote agile evolution, while other ASPs may choose not to, or plan

evolutions at a later stage. As a consequence the connectivity between SOA and non-SOA needs to be

ensured by means of Gateways. These Gateways may be shared by systems within a member state,

provided as a shared resource for the use of multiple member states, or provided by a new participant such

as a third-party provider. See Section 4 for descriptions of mixed SWIM and non-SWIM environments and

some transition scenarios.

2-8 Manual on System Wide Information Management (SWIM) Concept

2.7.2 SWIM Stakeholders

2.7.2.1 The Global ATM Operational Concept (Doc 9854) lists and describes the various members

comprising the ATM community, as follows:

a) aerodrome community;

b) airspace providers;

c) airspace users;

d) ATM service providers;

e) ATM support industry;

f) International Civil Aviation Organization (ICAO);

g) regulatory authorities; and

h) States.

2.7.2.3 Some of these members (e.g. ICAO, States and regulatory authorities) will be mainly

responsible for SWIM governance.

2.7.2.4 One of the main changes brought about by SWIM is that any of these members can act both as

information provider and as information consumer. Therefore, while the ASPs will continue to be at the core

of the ATM processes, SWIM will allow other information providers to play a bigger role, e.g. an ASP may

consume an information service from an airspace user to get a detailed trajectory profile for a given flight.

2.8 PERFORMANCE IMPROVEMENT VIA SWIM

.8.1 Given the international nature of SWIM, it is not likely that one solution, and certainly not one

single technology, will fit all. Individual ASPs are expected to implement suitable procedures in accordance

with target performance levels as described in the Manual on Global Performance of the Air Navigation

System (Doc 9883). Nevertheless, it is recognized that global interoperability and standardization are

essential for efficient and safe international aviation and SWIM will likely be an important driver for new and

updated standards.

2.8.2 The Global ATM Operational Concept (Doc 9854) equates Information Management (IM) with

SWIM, and this document uses the latter term to avoid any confusion. As discussed above, the ASBU

module B1-SWIM entitled “Performance Improvement through the application of SWIM” applies to the

implementation of SWIM services (applications and infrastructure) creating the aviation intranet based on

standard data models, and internet-based protocols to maximize interoperability.

2.8.4 As described in Circular 335 — Air Traffic Management Service Delivery Management (ATM

SDM) Description, the planning and conduct of SWIM will take place through the ATM SDM component of

the Global ATM Operational Concept, which acts as a focal point for coordination; while the needs

established through ATM SDM will set the overall requirements for SWIM.

Chapter 2. The SWIM concept 2-9

2.8.5 In the above context, performance-based SWIM signifies that performance requirements for

information management systems are not established from a technical perspective in isolation, but through a

top-down/bottom-up trade-off process. The process links such requirements clearly and strongly to the

Performance Case of the corresponding Operational Improvement which argues the benefits/disbenefits

across the eleven Key Performance Areas (KPAs) of the Global ATM Operational Concept.

2.8.6 For example, a particular characteristic would be (or may be deemed to be) ‘required’ for a type

of information transaction, not simply because it is technically feasible, or desirable, or because it would

enable a potentially quicker operational response time by an aircraft or group of aircraft. Rather, it would be

‘required’ only after establishing that the potentially quicker operational response time can be realized during

operations, and can also be taken full advantage of, to the extent that it will deliver tangible, justifiable

benefits overall. In other words, information management systems are just one link in the chain, and their

requirements must be in balance: (a) with those for the rest of the chain; and (b) with the overall benefits that

the chain can realize in practice.

2.8.7 Although one size may not fit all the needs of all stakeholders, it is of the utmost importance, for

the consistency of the global air transportation system, to achieve some level of interoperability between the

different solutions developed. The SWIM infrastructure and services should be developed in alignment with

a globally-accepted operational concept that articulates the expected SWIM implementation in terms of

benefits, enablers, features, and principles for development and transition.

2.8.8 The Global ATM Operational Concept (Doc 9854) states that “Key to the philosophy adopted

within the operational concept is the notion of global information utilization, management and interchange.

This philosophy is supported in large part by evolution to a holistic, cooperative and collaborative decision-

making environment ...”. As such, it will require an increase in information exchanges, both in terms of the

number of exchanges performed and the number of participants involved. Security will become a critical

factor, therefore the global SWIM concept encompasses aspects such as authentication, authorization,

encryption, intrusion detection, security policies, etc.

2.8.9 Information required to perform an organization/company 'business' is one of the most important

assets of any organization/company that allows it to deliver valuable services (to aviation, in this case).

––––––––––––––––––––––––––––

3-1

Chapter 3

THE SWIM GLOBAL INTEROPERABILITY FRAMEWORK

3.1 SWIM LAYERS

3.1.1

This section presents a five-layered SWIM Global Interoperability Framework to describe the

sharing of information via SWIM. The framework is based on several complementary descriptions of SWIM

that have been created by stakeholders. The layers explain the functions, the combination of representative

standards and the mechanisms for interoperability. This current description of the SWIM Global

Interoperability Framework focusses on the technical elements of the ground-ground SWIM segment and is

consistent with airborne segment solutions that are being developed.

3.1.2 The Global Interoperability Framework (see Figure 2) comprises the following layers:

a) SWIM-enabled Applications of information providers and information consumers around

the globe. Individuals and organizations, such as air traffic managers and airspace users,

will interact using applications that interoperate through SWIM;

b) Information Exchange Services defined for each ATM information domain and for cross

domain purposes, where opportune, following governance specifications and agreed upon

by SWIM stakeholders. SWIM-enabled applications will use information exchange services

for interaction;

c) Information Exchange Models using subject-specific standards for sharing information for

the above Information Exchange Services. The information exchange models define the

syntax and semantics of the data exchanged by applications;

d) SWIM Infrastructure for sharing information. It provides the core services such as interface

management, request-reply and publish-subscribe messaging, service security, and

enterprise service management; and

e) Network Connectivity provides consolidated telecommunications services, including

hardware. This infrastructure is a collection of the interconnected network infrastructures of

the different stakeholders. These will be private/public Internet Protocol (IP) networks.

3.1.3 The scope of SWIM is limited to the three middle layers (i.e. Information Exchange Services,

Information Exchange Models, and SWIM Infrastructure) and to the governance of these layers.

3.1.4 The currently identified Information exchange services of global interest pertain to aeronautical

information, meteorological information, surveillance information, and flight information. Additional domain

services and cross-domain composite services will likely be defined in the future. The most important task

for SWIM implementing stakeholders is to agree upon a set of services for information exchange and the

range of options that will be appropriate within each of these services (for member States with different

levels of ATM sophistication) and the standards for information exchange.

3-2

3.1.5

standards.

exchange

3.1.6

defined st

These infr

SP. T

it is based

The SWIM

how inter

paragraph

There can

In other w

tandard ma

The SWIM

ndards and

structures

e specific ty

n the SWIM

global inter

perability b

describes ho

Figure 2.

be a ma

rds, an exc

be used by

infrastructur

re not expe

ill also be

e of SWIM i

Concept obj

3.2 I

perability fra

tween SWI

informatio

Manual o

SWIM Glob

y-to-many r

hange servi

ne or more

and networ

ted to consti

radually im

plementati

ctives and i

TEROPER

mework des

-enabled a

from one S

System Wi

l Interoper

lationship

e may use

xchange se

connectivit

tute the maj

lemented a

ns will be le

teroperabilit

BILITY A

ribes a laye

pplications

IM-enabled

e Informatio

bility Fram

etween exc

one or mor

vices.

layers are li

r technical b

d interconn

t to that stak

with other s

DIFFERE

ed framewo

ill be achi

application i

Manageme

work

hange servi

e exchange

ely to be bui

arrier to the

cted by sta

holder’s org

takeholders i

T LAYERS

k enabling f

ved in pra

exchanged

t (SWIM) C

es and ex

standards,

lt upon a set

ealization of

keholders, s

anization as

s made poss

rther discus

tice. The f

ith another.

ncept

hange

nd an

of well-

SWIM.

uch as

long as

ible.

ion on

llowing

Chapter 3.

3.2.1.1

relevance

service pa

providers.

located an

the same t

The SWIM

s an exa

o a flight be

ticipants su

n a global S

where in th

pe (e.g. an

Figure 3. E

global intero

3.2.1

ple, consid

ing planned.

h as ATM

IM environ

world, and

SP and an

ample of flig

erability fra

A Flight

r two SWIM

These SWI

ervice provi

ent, the tw

ay be oper

U). The inte

t informatio

ework

ata Excha

enabled app

-enabled a

ers (ASPs),

interacting

ted by diffe

action proce

exchange b

nge examp

lications tha

plications m

airspace us

WIM-enabl

ent organiza

ds as descri

tween SWIM-

must share

y be used

rs (AUs) or

d applicatio

tions which

bed in Figur

enabled appli

flight inform

y a variety

emergency

s may be ph

o not need t

cations

3-3

tion of

f ATM

service

sically

o be of

3-4 Manual on System Wide Information Management (SWIM) Concept

3.2.1.2 The purpose of each layer in the SWIM global interoperability framework is described as follows:

a) at the highest layer, a SWIM-enabled application is used to request an information service.

Semantic interoperability based on a common understanding of the information used is

required. A SWIM-enabled application is capable of interacting with the layers below it

through implementation of standards that enable interoperability;

b) at the Information Exchange Services layer, the characteristics of the requested information

service are described in a technology-neutral manner. For example, a flight route provision

service may give a flight’s route upon request with the flight’s GUFI (Globally Unique Flight

Identifier). At this layer, the response characteristics including application-level error

conditions (e.g. GUFI unknown) and normal response (e.g. provide the route) are described;

c) at the information exchange models layer, the characteristics of the data being used by the

information exchange services are described to include information content, structure and

format. Continuing with the previous example, the GUFI and flight route would be described

via flight information exchange model (FIXM) compliant data elements. The combined

information exchange services and the information exchange models layers define individual

application-level messages that can be exchanged to deliver the requested service;

d) the SWIM Infrastructure layer provides core SWIM services such as interface management,

messaging, service security, and enterprise service management. At this layer, application-

level messages required to deliver the requested information service are implemented in

accordance with a defined protocol for interoperability with the service deliverer through

interface management functions that also manage performance requirements. Messaging

core services provide such functions as addressing and message assurance. Security

services such as authentication and authorization are also provided; and

e) the message is then transported over a global network, where it is delivered to a specified

recipient responsible for providing the application-level message to the recipient SWIM-

enabled application.

3.2.1.3 The process described above is somewhat analogous to a set of nesting dolls in which different

layers take the payload from the layer above (see Figure 4). Upon receipt of the lowest layer, the process is

reversed and each layer is unwrapped.

3.2.1.4 In order for the receiving party to successfully unwrap the messages received at each layer,

each of these layers must understand the protocol used when the message was constructed. Outside of the

scope of SWIM, at the network connectivity layer, interoperability is straightforward. At the SWIM Core

services layer, many standards exist (see 0) that allow an information service, aware of the encoding

standard, to recover the information. Information services do not need to operate with the same standards

internally, but may require a translation function for interoperability.

Chapter 3.

3.2.2.1

different st

a global S

standards

exchanges

U, or

the enterp

3.2.2.2

Flow – Inf

by the are

standards,

Region, a

establishe

standards

standards.

The SWIM

It is clear t

keholders

IM will be a

efined at a

within SWI

n ATM sup

ise.

The conce

rmation for

of influenc

the policies,

ollection of

for that pa

it deems ap

Furthermor

global intero

igure 4. La

3.2.

at “one siz

ill be driven

hieved thro

lobal level s

enterprises

ort industry t

t of a SWI

Collaborati

of a given

etc. that ar

nterprises,

rticular SWI

ropriate to

, a much ri

erability fra

ers encaps

SWIM E

fits all” ma

by differing

gh the inter-

all focus on

In this cont

at has full c

Region ha

e Environm

governance

applicable

r example

region. In

pply interna

cher set of

ework

late messa

terprises

not be the

erformance

peration of

the exchang

xt, a SWIM

ntrol of the

previously

nt (F

-ICE),

tructure (i.e

to all the e

SPs or AUs

turn, each

ly, provided

services wo

es from pri

nd region

most desira

expectations

otentially a

es between

enterprise c

implementati

een articula

(Doc 9965).

. the govern

terprises wi

may choos

nterprise m

they can int

ld likely be

or layers

ble solution

and circum

ariety of imp

WIM enterp

n be an AS

n planning

ed in the M

SWIM reg

nce structur

hin the regi

to interope

y organize

roperate wi

available

t a global l

tances. As

ementations

rises and no

, a group o

nd executio

nual on Fli

ion will be d

which defi

n). Within a

ate using st

itself with w

h the SWIM

ithin an ent

3-5

vel as

result,

SWIM

on the

ASPs,

within

ht and

limited

es the

SWIM

ndards

atever

region

rprise.

3-6

Provider/c

are logical

etc. SWIM

3.2.2.3

enterprise

in systems

AU-2 belo

chooses t

application

3.2.2.4

regions, th

for implem

gateways

nsumer syst

entities that

access point

Figure 4 pr

are shown

–

that connec

g to SWIM

belong to

; however,

Where circ

n interoper

nting these

r adapters, f

a) one en

Region

b) each e

enterpri

c) a new

with on

d) combin

ms belongi

provide SWI

are describ

vides an e

–

an ASP, a

to their res

Region A

a second

ecurity servi

Figure 4. I

umstances

bility will be

ateways is

r example:

erprise may

to its SWIM

terprise coul

e (illustrate

rganization

SWIM Regi

tion of the a

Manual o

g to an ente

M core servi

d later in S

ample of rel

d two AUs (

ective SWIM

hich shares

WIM Regi

es may limit

lustration o

re such th

chieved via

ot prescribe

implement t

Region;

be respons

in Figure 5

ay appear

n native sta

ove.

System Wi

prise will co

ces such as

ction 3.7, S

tionships b

U-1 and AU

access poin

a common

n B. Thus

the exposur

Enterprise

t full harmo

ateways/ad

. As a resul

e gateway/

ible for impl

or AU-2);

exposing se

dards; and

e Informatio

nect to SWI

messaging,

IM infrastru

tween enter

-2). The app

ts via servic

set of stand

there is po

of services

and SWIM

nization can

pters. How

, several opt

dapters and

menting gat

vices of oth

Manageme

via SWIM

interface ma

ture.

rises and S

lications in t

interfaces.

ards. The A

ential conn

o selected a

Region

not be achi

ver, the orga

ons exist for

expose ser

ways and a

r SWIM Re

t (SWIM) C

ccess point

nagement, s

IM regions

ese enterpri

he ASP,

U-2 enterpri

ctivity betw

thorized us

ved across

nization resp

implementin

ices in othe

apters for th

ions in acc

ncept

, which

ecurity,

Three

es are

-1 and

e also

en all

rs.

SWIM

onsible

these

SWIM

ir own

rdance

Chapter 3. The SWIM global interoperability framework 3-7

3.2.2.5 Through the use of the gateways and adapters, participants within a SWIM region may then

interoperate with SWIM-enabled applications in other regions by meeting global standards for

interoperability. The impact of the above implies that a service consumer may potentially obtain services

from global SWIM-enabled applications through a variety of paths. However, different service level

agreements (SLAs), governance and security policies, and relative service costs may limit these paths.

3.3 OVERVIEW OF FUNCTIONS AND STANDARDS BY LAYER

Table 1 provides an overview of the functions and standards associated with the different

layers of

the Global Interoperability Framework. The table includes an initial set of candidate standards; additional

standards may be added as needed. Sections 3.4 through 3.7 provide details on the three layers associated

with SWIM. Governance will apply to all these layers and is considered in Section 3.8. The SWIM standards

listed are examples. A brief description of these is provided in Appendix B.

Table 1. Global Interoperability Framework - Overview of Functions and Standards

Layer of Framework

Functions or

Sub layers

Candidate Standards, models,

implementations

SWIM-enabled

Applications

ATS, ATFM, Airline Ops

Information

Exchange Services

Service Interoperability No global standards as yet

Interface Definition

OGC CS-W, WSDL, WADL, WFS, WMS, WCS

Information

Exchange Models

and Schemas

For aeronautical, MET, and flight

information

AIXM, WXXM, IWXXM, FIXM, FIXS, AIXS,

WXXS

Semantic Interoperability

Domain Specific: AIRM

General: RDF/RDFS, OWL, SKOS

SWIM Infrastructure

Enterprise Service Management DDS, JMX, SNMP

Policy WS-Policy standards

Reliability WS-RM & WS-RM Policy

Security WS-Security & SSL

Interface Management (Service

Registration)

OASIS/ebXML

Data Representation

XML, XSD, GML

Messaging SOAP, JMS, DDS

Transport

HTTP, JMS, MQ

Boundary Protection No global standards as yet

Service Registry UDDI, work on-going

Network

Connectivity

Secure Network Connectivity IPv4, IPv6

Naming and Addressing DNS

Identity Management No global standards as yet

Incident Detection and Response No global standards as yet

3-8 Manual on System Wide Information Management (SWIM) Concept

3.4 INFORMATION EXCHANGE SERVICES

3.4.1 As mentioned before, information is a key enabler, shared through SWIM services, for ATM

innovation and performance improvements. SWIM is designed to improve information sharing by making the

right information available to the right stakeholders at the right time. However, the challenge is to do this in

an organized manner. More specifically it requires defining the information exchanges, based on

agreements between stakeholders, and commonly agreed means. Within the concept of SWIM the solution

to the above-mentioned challenge is based on the use of a SOA-based approach whereby application

functionality is exposed through services.

3.4.2 Within the SWIM Global Interoperability Framework, the Information Exchange layer is

instantiated by ‘information services’ as is further explained. Information services ensure interoperability

between ATM applications which consume and provide interoperable information services. Consequently,

the concept of information service is a fundamental building block of SWIM which enables interoperability

through well-defined information exchanges.

3.4.3 Furthermore, applications make use of information as they consume or provide standardized

information services based on the standards defined by SWIM. The definition of a standardized information

service indicates: (1) what a service provides; (2) the service message (the structure of the message at the

logical level); (3) the behaviour; (4) the performance levels; and (5) how the service can be accessed.

Note:— It is necessary to provide the complete definition through a Service Description Document.

3.4.5 Service message interoperability is achieved at the implementation level through the use of

commonly agreed information exchange models, appropriate technology and standards within the scope of

each service and related community of interest. The service definitions and implementation specifications

are made available as open standards. The service definitions also contain the non-functional requirements

and connect to one or more SWIM technical policies, hence providing well defined interfaces for

implementation purposes.

3.4.6 Service consumers can, in principle, combine services together. The role of the common

semantic reference is performed by the ATM Information Reference Model (AIRM) to which the service

message complies for service definition purposes. Service message syntax specifications are treated as a

separate concern based on constraints, opportunities and cost considerations at the implementation level.

3.5 SWIM REGISTRY

3.5.1 Design-time registries

help developers locate assets, make decisions about which ones are

best to use among many that might be similarly appropriate or adequate, and understand the various costs

involved in their consumption. Runtime registries help systems make automated, policy-based decisions

about service selection.

3.5.2 An important aspect of SWIM is the overall governance of the service approach. A key

component of the SWIM Concept is the service lifecycle, from the identification of the business needs

through the design until the development of the services. The service lifecycle will need to be managed with

a transparent process for the stakeholders. More information on a typical service life cycle process is

provided in Section 2.6.

Registries, as used in this document, include any necessary repository functionality to store registry

artifacts. A functional SWIM can exist without a service repository; it helps, but it is not required.

Chapter 3. The SWIM global interoperability framework 3-9

3.5.3 Achieving interoperability across all ATM areas requires governance. The registry is the key

element which brings SWIM-related interoperability artifacts together and enables policy enforcement where

required. It allows information providers to publish services and information consumers to find appropriate

services based on the information exposed by the registry. Furthermore, the registry brings together

qualified parties as trusted partners. Finally, the registry enables collaborative lifecycle management

enabling participants to progressively plan and engage.

3.5.4 As a consequence the information services and their lifecycles must be stored in a catalogue

and managed. Information service providers maintain and expose these services with their implemented

instances through a SWIM registry.

3.5.5 Although the term “SWIM registry” is used in the singular, there will likely be multiple SWIM

registries in different enterprises or regions; these will be linked together with the aim of functioning as a

single global logical registry for authorized users. The various means of achieving this goal continues to be a

topic of study.

3.5.6 Furthermore, the SWIM registry supports the governance of SWIM and provides the inventory of

reference for service related resources in SWIM. It improves the accessibility to information facilitating a

common understanding of SWIM. Figure 5 illustrates how a SWIM Registry is used by information providers

and consumers.

3.5.7 Given the importance of the registry in the overall SWIM concept, the resources contained

therein are further detailed. These are:

a) service instances (list of services available in SWIM from the various SWIM information

service providers);

b) service description documents;

c) reference models (common models for the implementation of services and information

structures i.e. AIRM);

d) information exchange standards (e.g. AIXM, WXXM, FIXM);

e) policies (constraints to be respected in SWIM for security or other purposes);

f) compliance (describe levels of conformity e.g. SWIM compliance); and

g) participants (e.g. information service providers).

3-10

3.5.8

.6.1

different p

interopera

other wor

informatio

The registry

a) publicati

b) discover

c) change

service li

d) notificati

and

e) depende

Information

rticipants a

ility, the inf

s, there is

both at the

may have th

n. Enabling t

. Facilitating

anagement.

ecycle;

n. Notifying

cy manage

3.6 I

exchange m

d made av

rmation nee

a need for

onceptual le

Manual o

ure 5. Con

following el

e registratio

he discover

Enabling the

takeholders

ent. Facilitat

FORMATI

odels are de

ailable to a

s to be cle

semantic in

el and at th

System Wi

ept of a SW

ments of fu

of new info

of informati

controlled a

about chan

ng the impa

N EXCHA

irable when

wide range

rly and un

eroperability

level of the

e Informatio

IM Registry

ctionality:

mation;

n with searc

d collaborati

es in servic

t analysis an

NGE MOD

information

of ATM inf

mbiguously

. This requi

ata that is e

Manageme

and brows

e change o

metadata

d identificati

s provided b

rmation co

efined and

es a detail

changed be

t (SWIM) C

capabilities;

information

nd lifecycle

n of depend

y a large nu

sumers. To

well underst

d definition

ween syste

ncept

nd the

status;

ncies.

ber of

permit

od. In

of the

Chapter 3. The SWIM global interoperability framework 3-11

3.6.2 Information exchange model constructs can be used, for example:

a) to define the information that is exchanged between providers and consumers

(e.g. in process models);

b) to define and manage domain models; and

c) to act as the reference for the definition of the payload of a shared ATM Service.

3.6.3 The concept of information domains can be used to manage the definition of exchange models

as smaller and more manageable units. The initial information domains were identified informally based on

the major service exchanges that were already in use (pre-SWIM). Figure 7 shows several ICAO identified

information domains. Individual States or organizations may choose to define other domains for their own

region, as necessary

. Appendix A provides more information on the criteria for the creation of a new

information domain; it also considers the major activities in managing an information domain.

Figure 6. Potential Information Domains

For example, the FAA initially defined a domain for NAS Infrastructure Management.

Thisishowwemanagedata

Thisishowusersseeinformation

Identified Information UserbasedInformationDomains

SignificantoverlapwithICAO

identifiedInformationDomains

SeamlessInformationSpace

achievedvia

SWIM‐enabledapplications,

InformationServices,

IRM&exchangemodels,

Registry

3-12 Manual on System Wide Information Management (SWIM) Concept

3.6.4 Current information domains are related to the current subdivision of identified activities. Users

however see the information in a more interrelated way than it is in its current information domain state.

Hence, within each solution space there is a tendency for users to expect seamless and interoperable

information which can be fused. The concept of progressively achieving a seamless information space,

supported by exchange models related to information domains within each user context, is realized by

SWIM-enabled applications. This means that applications which consume and provide information services

may relate to one or more domains, to one or more stakeholders, and to one or more points on the strategic-

tactical time axis.

3.6.5 The Global ATM Operational Concept (Doc 9854) provides guidelines for Information

Management. In particular, it requires that “information management will use globally harmonized

information attributes (2.9.11)”. In the GANP (Doc 9750), fourth edition, the B1-DATM (Service Improvement

through Integration of all Digital ATM Information) module is described as: “Implement the ATM information

reference model, integrating all ATM information, using common formats (UML/XML and WXXM)

for meteorological information, FIXM for flight and flow information and internet protocols”. Convergence to

an ATM information reference model may be achieved in practice through a variety of methods.

3.6.6 The ATM information reference model (AIRM) is defined as a complement to the current

exchange models and used as the semantic reference for SWIM information services. Existing exchange

models will be consistent with the AIRM and may be used to define services for SWIM.

3.6.7 Consequently, at the global level, the AIRM is envisioned to provide support across the various

individual exchange models (AIXM, FIXM, WXXM, AIDX, etc.). Specific examples of the types of support

include alignment in terms of the levels of abstractions, i.e. details provided, as well as in terms of horizontal

scope, i.e. content. The characteristics of the AIRM at this level would:

a) provide consistency with ICAO provisions;

b) complement and support the exchange models in a consistent manner;

c) foster convergence at the semantic level;

d) enable a model-driven approach;

e) provide an integrated reference across ICAO documents (annexes, manuals, etc.);

f) support global interoperability planning; and

g) support SWIM compliance criteria.

3.7 SWIM INFRASTRUCTURE

In a global environment, and considering that the service provision will not be restricted to the

air navigation service provider (ANSP), as has traditionally been the case, the SWIM infrastructure might

differ in the different SWIM implementations, be they local (e.g. ATM support industry), national or regional.

Therefore, the SWIM infrastructure might have different architectures (functional, physical) in

different SWIM implementations. An agreed architectural concept that shall be generic enough to

accommodate the differences in the implementations is needed at a global level. This architectural concept

is the ‘SWIM Access Point’.

Chapter 3.

messaging

SWIM acc

informatio

(either par

shared by

include on

point can

associated

specific S

Figure 8.

points in

different ar

ir Naviga

common e

The SWIM

A SWIM a

, security, lo

ss points.

consumers.

ially or com

ultiple syst

or more o

otentially co

s indicat

SWIM acce

IM enterpri

Global inte

ll the SWIM

chitectures. I

ion Agreeme

The intero

change sta

global intero

cess point i

ging, interfa

WIM acces

The function

letely) provi

ms. These

these optio

municate wi

Figure 7.

d previousl

s points) ma

e may defi

roperability

implementa

is anticipat

nts, following

erability bet

dards or thro

erability fra

a logical e

e manage

points will

of a SWIM

er and/or co

ptions are s

s. Subject t

th any provid

WIM Acces

y, the deta

y be differen

e for its S

oes not req

ions. Theref

d that some

appropriate

een the diff

ugh gateway

ework

ntity that bu

ent, etc.). T

be impleme

access point

sumer syst

own in Figur

authorizati

ers that are

Point Impl

led architec

in the differ

IM implem

ire the sam

re, each S

architectures

oordination

rent SWIM i

at the appr

dles a num

e SWIM infr

ted by info

may be impl

ms. Some

e 8. An ente

n, consume

onnected to

mentation

ture of the

nt SWIM im

ntation the

functional

IM enterpri

will be impl

ith affected

plementatio

priate levels

er of techni

structure is

mation provi

mented ext

WIM access

prise SWIM

s connected

ther SWIM

ptions

SWIM infr

lementation

unctional ar

rchitecture

e impleme

mented on t

SWIM stake

ns will be en

al capabiliti

the collectio

ders as well

rnal to or int

points may

mplementati

to a SWIM

ccess point

structure (a

. As an exa

hitecture sh

f the SWIM

tation may

e basis of R

olders.

ured either

3-13

s (e.g.

of the

as by

rnal to

lso be

n may

access

nd the

ple, a

own in

access

evelop

gional

hrough

3-14 Manual on System Wide Information Management (SWIM) Concept

Figure 8. Functions of a SWIM Access Point - Example Only

3.7.1 SWIM Functional architecture example

3.7.1.1 One example of a functional architecture of a SWIM access point is described assuming the

architecture in Figure 8. For convenience, the one on the right is considered as the primary one with

systems applications that it considers internal to the enterprise. The functions are logically divided into three

groups. At the top of the figure are the ATM functions which utilize the SWIM core service functions, shown

in the middle of the figure, to interoperate. At the bottom are the network connectivity functions such as

networking and security functions which are essential for the operation of higher level functions. The

boundary protection functions are split across the SWIM service and network connectivity levels. However,

for convenience, these are described under the SWIM core services.

3.7.1.2 The ATM functions provide specific functionality such as that provided by air traffic control

automation systems, flow management systems, and meteorological information systems. The dashed line

in Figure 8 shows the logical interaction between SWIM-enabled applications. Each application performs a

Service Interface function that makes a set of information services available; these information services may

be invoked by other applications via the SWIM core service functions in the SWIM access points.

3.7.1.3 SWIM distinguishes between SWIM application services (SAS) and SWIM core services. SAS

are available – i.e. visible, discoverable, usable – to authorized systems. The service application interface of

a system is the functional component that makes SAS services available to other authorized systems in a

manner that conforms to the technical standards identified by SWIM. Similarly, external applications outside

the enterprise interoperate with systems within the enterprise by accessing services and/or by providing

Service Security

Incident Detection

and Response

SWIM

Core

Service

Functions

Interface

Management

Messaging

Naming &

Addressing

ATM

Functions

Identity

Management

Enterprise Service

Management(ESM)

Boundary

Protection

Secure IP Network

Connectivity

Application

Service Interface

Authorized

Internal Users

Authorized Internal System

Application

Authorized

External Users

Authorized External System(s)

Application

Info

Exchange

Info

Exchange

Authorized

Internal Users

Authorized Internal System

Boundary

Protection

Service InterfaceService Interface

Service Security

Interface

Management

ESM

Messaging

Network

Connectivity

Functions

SWIM

Access

Point

SWIM

Access

Point

Chapter 3. The SWIM global interoperability framework 3-15

services across the boundary (using their own SWIM access point). ATM information exchanges between

internal and external applications via SWIM are mediated by boundary protection mechanisms which include

security controls at all layers (for both enterprises).

3.7.1.4 On the other hand, the SWIM core services are not visible to other systems but are fundamental

mechanisms that enable consumption of services and information sharing. These core services are solution-

agnostic (not limited to a single process or solution environment) and have a high degree of autonomy so

that they support reuse. The core services are:

a) interface management which provides a standard interoperable means for description,

access, invocation, and manipulation of resources to enable compatible communications

between ATM information providers and consumers. To assure interoperability in the SWIM

environment, interface management will maintain a set of standards for interface definition,

description and discovery. (This function is also termed registry management in some SWIM

documents);

b) messaging includes functions supporting message exchanges with a variety of relationships

between message end-points including one-to-one and one-to-many. It enables message

routing and the distribution of content, as well as functions for efficiently and reliably

delivering that content across SWIM in a secure fashion. It includes functions to support

synchronous and asynchronous information exchange;

c) service security provides functions that are used by systems and core services to ensure

that SWIM services are provided in accordance with established security policies. Service

security functions are used to enforce security policies at the core SWIM services level.

These functions include authentication, authorization, confidentiality, integrity, and access

control functions; and

d) enterprise service management (ESM) supports the management of the information

services associated with providers and consumers, as well as the management of

supporting SWIM core services themselves. ESM includes the monitoring and control of

faults, configuration, accounting, performance, and security.

3.7.1.5 A brief description of the SWIM service functions associated with the core services is in Table 2.

Table 2. Summary of SWIM Core Service Functions

SWIM Core

Service

Core Service

Functions

Function Description

Interface

Management

Service Exposure Provides the capability to expose service information

entities by using a registry.

Service Discovery Provides the capability for service consumers to be

able to easily find information on services sought

including alerts and registry content organization.

Metadata Management Provides the capability for managing the information

in the registry, including managing information about

multiple versions of a given service, as well as

managing information about service level

agreements (SLAs).

3-16 Manual on System Wide Information Management (SWIM) Concept

SWIM Core

Service

Core Service

Functions

Function Description

Messaging

Publish/Subscribe Provides support for publish/subscribe message

exchange pattern. (See Glossary for an expanded

description.)

Request/Response Provides support for request/response message

exchange pattern. (See Glossary for an expanded

description.)

Reliable Messaging Provides support for various types of guarantees for

message delivery.

Message Routing Provides support for message routing between

information providers and information consumers.

Mediation Provides the capability for various types of mediation,

such as data format transformation, between

message senders and receivers.

Message Transport Provides multiple application level transports to any

endpoint.

Security Services

Message Confidentiality Provides mechanisms to ensure that only intended

parties in a message exchange can view messages.

Message Integrity Provides mechanisms to ensure that messages are

not unintentionally altered, and provides assurances

that system data can be trusted to be accurate.

Transport-level

protections

Provide protections at the transport and session

layers to ensure confidentiality and integrity for

system communications.

Identity Management Provides mechanisms for managing the identity and

organizational role of service consumers and service

providers.

Data Access

Management

Provides management of access to data resources

that are based on the requesting entity’s identity,

organizational role, or other considerations such as

transaction state or application.

Security Policy

Management

Provides management of the rules that allow and

limit access privileges to SWIM data resources.

Security Policy

Enforcement

Provides mechanisms to enforce security policies.

Security Monitoring Provides monitoring of SWIM services for any

systems events that may indicate security breach or

fraudulent use of system resources.

Security Auditing Includes the review of security controls to ensure that

they are efficient and effective in controlling

unauthorized access to systems.

Enterprise Service

Management

Asset Management Manages SWIM hardware, software, and network

assets.

Chapter 3. The SWIM global interoperability framework 3-17

SWIM Core

Service

Core Service

Functions

Function Description

Configuration

Management

Manages in-development and operational baselines.

Event and Performance

Management

Monitors and controls faults, service quality including

reliability, availability, performance, diagnostics, and

policy.

Service Desk Support Supports personnel in the use of SWIM services and

resolution of reported problems.

Policy Management Storing, categorizing, updating, and distributing

policies.

Boundary

Protection

Enterprise Boundary

Protection

Prevents malicious content or attacks from being

passed between applications internal to an enterprise

and external applications. Allocation of appropriate

security controls to this function will be a result of a

properly conducted risk analysis by each enterprise.

The boundary protection mechanism may best serve

to limit protocols and communication destination

addresses, and to provide early detection of denial of

service attacks before their effects can be

propagated to the enterprise’s internal network and

systems.

3.7.1.6 Sample network connectivity functions include the networking and security support functions

described below in Table 3. This group of functions represents capabilities and services that are not specific

to SWIM but that SWIM needs to use in support of higher level SWIM services.

Table 3. Network Connectivity Functions

Network

Connectivity

Function

Function Description

Secure IP Network

Connectivity

Allows the components of the SWIM architecture to communicate with one

another using the Internet Protocol (IP). It may include network layer security

services, e.g. tunnels, encryption, network layer access control, etc. as needed.

Both IPv4 and IPv6 will be used within the global SWIM.

Incident Detection

and Response

Monitors the systems and networks of the SWIM architecture for indications of

information system security intrusions or incidents, and supports corrective

action when such intrusions or incidents are detected.

Naming and

Addressing

Provides a domain name system (DNS) that translates from fully qualified

domain names identifying systems to IP network addresses. It also includes the

administrative functions that provide for allocation and management of IP

address space.

Identity &

Credential

Management

Provides management of, and access to, identity information and credentials as

needed to support authentication, authorization, and access control decisions

that are made within the SWIM service security function.

3-18 Manual on System Wide Information Management (SWIM) Concept

3.7.1.7 Each enterprise is expected to implement its own IP infrastructure. Some enterprises may use

the facilities provided by regional partners or commercial service providers to access SWIM. There is no

implicit requirement that a dedicated IP network be set up solely for SWIM.

3.7.2 SWIM technical architecture

3.7.2.1 The SWIM technical architecture provides a view of the standards used in supporting the SWIM

functions. Standards in the SOA environment are evolving rapidly, and should be expected to change, in the

future. Compatibility among standards will be maintained via the use of conversion gateways.

3.7.2.2 SWIM emphasizes the use of web services standards, because these are, for the time being,

promising and widely used standards for implementing SOA in a way that improves interoperability and

flexibility. However, web services are not suitable for all applications. The intent of the SWIM architecture is

to allow other standards to be used when necessary while retaining general SOA principles. To accomplish

this, SWIM components should be capable of including information on services that are provided using a

variety of different technologies and standards. Similarly, SWIM enterprise service management and service

security components should be engineered, to the extent practical, to allow a variety of different

technologies and standards to be managed and secured.

3.7.2.3 Since the standards are evolving and need to accommodate a variety of applications being

considered by member states, an initial classification framework for SWIM technical standards (Figure 9) is

proposed for discussion. The top two layers deal with the exchange of information via SWIM while the others

are involved with the SWIM Infrastructure. The framework is extensible and additional layers may be

inserted or existing layers consolidated over time. As mentioned earlier, governance covers multiple areas

and will rely on the technical standards defined for ESM, interface management, security, policy, etc.

Chapter 3.

3.7.2.4

Some of t

ready for i

once they

efforts ar

meteorolo

3.7.2.5

that stand

not presen

of the pre

definition o

The SWIM

Figur

Examples

e standards

plementatio

re widely su

focusing o

ical data.

short ex

rds appeari

in the figure

ise standard

f SWIM Gov

global intero

9. Initial Cl

f some SWI

are supporte

n. Other sta

pported com

n service d

mple of pot

g in Figure 1

may be sele

s that will b

rnance.

erability fra

ssification

standards

by multiple

dards are u

ercially. Inf

finitions fo

ntial SWIM

0 may actua

ted as SWI

part of SW

ework

Framework

re shown in

commercial

der evaluati

rmation Exc

exchange

tandards is

ly not be sel

standards.

M is one of

or SWIM Te

Figure 10; o

vendors of S

n and may

ange Servi

of AIM dat

rovided in

cted as S

he process

the tasks to

hnical Sta

her standard

OA products

e considere

es are still u

, Flight Inf

ppendix C. I

IM standard

to select, as

be done as

dards

s may also b

and are con

for implem

der definitio

rmation dat

has to be s

and that st

ell as the s

part of the

3-19

used.

idered

ntation

; initial

a, and

ressed

ndards

lection

etailed

3-20

a number

appropriat

authority,

carry out t

important

Examples

In a loosel

of entities,

rules, polic

nd communi

eir roles an

nabler for S

The infrast

f this gover

a) define

b) define

c) define

provid

Figure

coupled en

governance

es, and sta

ation as wel

responsibili

IM governa

ructure, sta

ance include

who is invol

the process

the SWIM

ers);

Manual o

10. Example

3.8 SWI

ironment su

is essential.

dards are f

l as the mea

ies. As men

ce.

dards and

the need to:

ed in the ap

s to be follo

infrastructur

System Wi

s of SWIM T

GOVER

h as SWIM

Governanc

llowed. Gov

urement an

ioned earlier

managemen

roval and in

ed;

to be pro

e Informatio

echnical St

ANCE

here servic

establishe

ernance defi

control mec

, in Section

of informa

the evolution

ided by m

Manageme

ndards

s are provid

the proce

nes the chai

hanisms to e

.5, the SWI

tion all nee

of standard

mber State

t (SWIM) C

d and consu

ses to assu

ns of respo

able partici

registry wil

to be go

;

(or their

ncept

ed by

re that

sibility,

ants to

l be an

erned.

etwork

Chapter 3. The SWIM global interoperability framework 3-21

d) define the need and the nature of a national or regional SWIM Collaborative Authority and,

if so, which components could be provided or managed by that authority;

e) define which information access management functions

will be executed by each

information provider/consumer;

f) establish a common set of regulatory policies and standards;

g) promote semantic and structural interoperability among stakeholders by developing a

common set of semantic and structural artifacts (e.g. taxonomies, ontologies, controlled

vocabularies);

h) define the way costs will be shared by the parties participating in SWIM and the possible

cost-recovery mechanisms to be used; and

i) define and establish governance structures at global, regional and local levels.

3.8.1 Governance of information definition

3.8.1.1

SWIM requires governance for the collaborative specification and definition of information within

existing domains, across domains and within potential new domains.

3.8.1.2 Since not all solutions are equally fit-for-purpose for all, it is recognized that local and regional

differences will continue to be required for information items. What truly matters in this context is that the

information must be in a state which can be qualified as “known and managed”. This implies that

governance at the level of a Global Interoperability Framework should be applied to the local and regional

levels to allow for flexibility and take into account some differences necessary due to specific operational

requirements.

3.8.1.3 Appendix A provides additional information on the processes involved in managing an

information domain.

3.8.2 Governance of information services

3.8.2.1

An important aspect of SWIM is the overall governance of the service approach. A key

component of the SWIM concept is the service lifecycle, from the initial identification of the business need

for a possible information service through the following stages — proposal, definition, development,

verification, deployment, deprecation and decommissioning. During the life of an information service, one

should also expect that an information service will need to be changed for various reasons and updates will

be necessary. Managing the change of an information service once it is in widespread use is much more

challenging than creating the initial service; this is because of the countervailing pressures of stability versus

improvement. The Open Group’s SOA Governance Framework provides a good framework that can be

adapted by enterprises (and regions) for their SWIM information services. Section 2.6 provides additional

information on the service life cycle and its management. Thus, service governance addresses concerns

such as:

It is assumed here that some information providers within a SWIM region may have additional access

requirements, i.e. some information services may be available to certain consumers only.

3-22 Manual on System Wide Information Management (SWIM) Concept

a) service registration;

b) service versioning;

c) service ownership;

d) service funding;

e) service modeling;

f) service discovery and access;

g) deployment of services and composite applications;

h) security for services;

i) processes and procedures to support service publishing and service validation;

j) documenting the approach to support service lifecycle management and service reuse;

k) verify that the running services are the approved versions;

l) define mechanism to manage Service Level Agreements (SLAs) for services; and

m) provide a mechanism to enable runtime service look-up.

3.8.2.2 In a global context, the ICAO-level governance should stop at the information exchange

services layer. At lower layers, it is expected that global technical standards would be used outside the remit

of ICAO.

––––––––––––––––––––––––––––

4-1

Chapter 4

TRANSITION AND MIXED ENVIRONMENT

This section describes ground SWIM operation during transition and in a mixed (SWIM, non-SWIM)

environment. It is recognized that transition to SWIM may involve additional complexities beyond a mixed

environment.

4.1 PARTICIPANTS

4.1.1 Figure 11 shows a gradual introduction of SWIM with a few digital services and an eventual

merging into full SWIM functionality.

Figure 11. Air ground communications roadmap

AIDC– FlightCoordination

&Transfer

ATS–Messaging&Directory

SWIM

SOAPioneer

DigitalMET

NOTAM

FlightObjects

FullSWIM

Functionality

ATSLegacy

AFTN/CIDIN

AIDCLegacy

e.g.OLDI/X.25

AnalogVoice

SurveillanceData

AMHS

FMTP

VOIP

IPBACKBONE

BLOCK0BLOCK1BLOCK2BLOCK3

2013 2018 2023 >2028

4-2 Manual on System Wide Information Management (SWIM) Concept

4.1.2 ATN applications such as ATS inter-facility data communications (AIDC) and ATS messaging

will move to SWIM as and when their performance requirements can be met. Existing legacy aeronautical

fixed telecommunication network (AFTN) and AIDC networks will be modernized and their communications

infrastructure move to IP networks which will permit multiple applications to share the same network.

4.1.3 Given the large number of member States having different levels of needs and sophistication,

different technologies and ATM services are expected. A few States or regions may use SWIM extensively

in the near future. Others will continue to use legacy systems. Interoperability is needed, whether using

existing legacy systems or planning a transition for the long term. This is made possible via specialized

gateways for messaging and a staged transition.

4.2 ROLES AND RESPONSIBILITIES

It is assumed that each member State or a number of States in a specific geographical region will develop

their migration plans based on respective needs and timetables for their current ATM networks and services.

States with legacy systems will have interoperability with other States but will not be able to provide or

consume more complex services unless their systems are upgraded.

4.3 KEY INTERACTIONS

4.3.1

This section illustrates how a phased transition from AFTN/aeronautical message handling

system (AMHS) to SWIM can be accomplished. The description is done in a context of ASP exchanges

because ASPs are the main stakeholders using AFTN/AMHS protocols, but it can be extrapolated to other

stakeholders. At the time of publication of this document, no formal selection of SWIM standards had been

made, and no SWIM information services had been defined. As such the following description is just for

illustration purposes. The actual applicability of this description will depend on a number of factors that

cannot be determined yet.

4.3.2 The legacy AFTN/AMHS is used by many States, primarily to exchange flight plans, notices

essential to personnel concerned with flight operations (NOTAM), and meteorological information. AFTN is

character-oriented, limits character set, limits message length and its switches are interconnected using low

speed lines. The AMHS was specified in Manual on detailed Technical Specifications for the ATN using

ISO/OSI protocols - ATS Message Handling Service (Doc 9880), Part IIB, as a replacement for the outdated

AFTN/common ICAO data interchange network (CIDIN). AMHS is based on ITU-T X.400 messaging

standards. As such, AMHS ‘removes’ the restrictions and limitations imposed by AFTN. ICAO specified

AMHS/AFTN gateways have been implemented and can be used to accommodate a mix of AMHS and

AFTN exchanges (the AFTN limitations would still apply in this case). This mixed environment is shown in

Figure 12. Although the IP connections represented in the figure seem to be point-to-point lines, they will

very likely be implemented through IP networks.

4.3.4 ASPs will start implementing SWIM-enabled systems to take advantage of the benefits

provided by the SWIM services. Full benefits will only be achieved when interaction with other ASPs with

SWIM-enabled systems occurs.

4.3.4 ASPs without SWIM will continue to interoperate but will be limited to the applications they can

support.

Chapter 4. Transition and mixed environment 4-3

Figure 12. Current AFTN / AMHS environment

4.3.5 Due to the current early stage of the SWIM definition at a global level, different possibilities can

be contemplated for the transition period regarding interoperability. Actually, each (to be) defined SWIM

service may have different possibilities; therefore, the transition period and interoperability arrangements

can be different for the different services that will be implemented. A brief description of a number of such

possibilities is provided.

4.3.6 There can be SWIM services for which the interoperability with ‘legacy’ systems will have to be

ensured by the SWIM-enabled system, i.e. it might be up to the SWIM-enabled system to implement the

service in the “SWIM form” and to also support it in the legacy format. Therefore, the SWIM-enabled system

should support both ways of providing such services during a transition period to allow a SWIM migration

path. This case is represented in Figure 13. Again, while the IP connections represented in the figure are

shown as point-to-point lines, they will very likely be implemented through IP networks.

4-4 Manual on System Wide Information Management (SWIM) Concept

Figure 13. Interoperability ensured at application-level

4.3.7 As an example, the SWIM-enabled system A in Figure 13 might represent an upgrade or

replacement of a legacy system managing and distributing NOTAM messages. This new system would both

support the ‘legacy’ NOTAMs as well as a new SWIM service for digital NOTAMs. Other SWIM-enabled

systems (e.g. system B in the figure) will be able to take advantage of advanced functionality provided by

the digital NOTAM service (e.g. geographical filtering). Other ‘legacy’ systems will still be able to

interoperate with the system A with ‘legacy’ NOTAMs as before, but they will not be able to benefit from the

advanced functionality.

4.3.8 There might be other specific SWIM services which can justify (in operational and economic

terms) the definition and implementation of gateways between SWIM and AFTN/AMHS. It can be expected

that this case would be possible for SWIM services for which there is a straightforward mapping with existing

AFTN/AMHS messages, so allowing the definition and implementation of the corresponding gateways. This

case is represented in Figure 14

Chapter 4. Transition and mixed environment 4-5

Figure 14. Interoperability ensured in the gateway

4.3.9 In this case, the SWIM-enabled system A in Figure 14 might represent an upgrade or

replacement of a legacy system. This new system would implement a SWIM service (or several SWIM

services). Other SWIM-enabled systems (e.g. system B in the figure) will be able to take advantage of

advanced functionalities provided by such services. In this case, such SWIM service will have a

straightforward mapping with AFTN/AMHS messages

. Therefore, it can make sense in operational and

economic terms to define and implement gateways between SWIM and AFTN/AMHS which would allow

other ‘legacy’ systems to exchange information with system A.

4.3.10 Finally, there might be some specific SWIM services for which there will be no interoperability

with ‘legacy’ systems (Figure 16). Such services will be just provided and consumed by SWIM-enabled

systems. This can be the case for services with a full new business logic that is not implemented or

supported by the ‘legacy’ systems, so the interoperability with legacy systems cannot be justified in

operational / economic terms.

The straightforward mapping is not just required for the payload, but also for other aspects like

addressing.

4-6

4.3.11

FTN/AM

standardiz

transition

ure 15. So

In summar

S), it should

tion intends

lans will dep

e new SWI

, when cons

be noted tha

to cover up

nd on the s

Manual o

Services w

idering inter

t, while AFT

to the servic

ecific SWIM

–

–––––––––

–

System Wi

ll only be s

perability be

/AMHS are

e level. The

ervices to b

–

––––––––––

–

e Informatio

pported by

ween SWIM

elated mainl

efore, the in

defined an

–

––––––

Manageme

SWIM-enabl

and legacy

to the trans

eroperability

the differen

t (SWIM) C

d systems

ystems (in th

port protocol

and the ass

option(s) av

ncept

is case

SWIM

ciated

ilable.

5-1

Chapter 5

FUTURE DEVELOPMENTS

Three future SWIM-related developments that may be of interest to member States are introduced. The first

one refers to the GANP ASBU modules on SWIM. The second refers to activities exploring SWIM air-ground

alternatives. The third refers to the interconnections of SWIM services across regional boundaries.

5.1 GANP ASBU MODULES ON SWIM

5.1.1 SWIM is specifically included in the GANP (Doc 9750) as shown in Figure 16.

5-2

5.1.2

modules

integration

ICE (B1-FI

5.1.3

managing

Since a c

determine

be stagger

SWIM is

elating to s

(B0-DATM

E, B2 -FIC

SWIM will

information

st will be

if a positive

d throughou

ainly contai

ervice impr

B1-DATM)

, and B3-FI

introduce a

uring the en

ssociated wi

erformance

t the globe.

Manual o

igure 16. IC

ed in the

vement thr

s well as m

E) are impor

ignificant ch

ire life cycle

th implemen

case exists i

System Wi

O GANP R

SBU modul

ugh digital

dules for i

ant early co

nge in the

from data o

ting SWIM,

their areas

e Informatio

admap on

s B1-SWIM

aeronautical

proving ope

ponents of

usiness pra

rigination to

it is recom

. Consequen

Manageme

WIM

and B2-SW

information

ational perfo

he overall S

tices of the

its usage an

ended that

tly, the depl

t (SWIM) C

IM. In additi

manageme

mance thro

IM.

ATM commu

decommis

regions and

yment of S

ncept

n, the

nt and

gh FF-

nity for

ioning.

States

IM will

Chapter 5. Future Developments 5-3

5.1.1 Technology requirements

5.1.1.1

The technological requirements for deploying SWIM are significant and essential.

Harmonization of data communication infrastructure for air-ground communication at an appropriate

performance level is necessary. On the ground, internet protocol (IP) should be available on all systems and

the implementation of ATS inter-facility data communications (AIDC) as the basic means for automating

ground-ground communications between ATS units could be considered as a facilitating intermediate step.

A common data communication baseline is essential to ensure future benefits of SWIM developments. The

implementation of an agreed common time reference for all systems (air and ground) is important for

applications and services supported by SWIM.

5.1.1.2 At the first stage (Block 1), SWIM is composed of ground applications relying on IP networks,

while most air-ground data exchanges remain based on point-to-point communication. Air-ground data link

services and infrastructure are converging to ATN Baseline 2, along with development of enabling ground

network technology and new commercial satellite communication.

5.1.1.3 Starting from Block 2 and into Block 3, the aircraft should be fully connected to the network as a

SWIM access point, enabling full participation in collaborative ATM processes with access to voluminous

dynamic data including meteorology. Initial implementations will be for non-safety critical exchanges

supported by commercial data links.

5.1.1.4 Technological requirements and the linkages between the various blocks and modules of the

ASBU framework are detailed in the technology roadmaps of the GANP (Doc 9750), fourth edition.

5.1.2 Deployment considerations

5.1.2.1

The development of ICAO provisions for access to information and use of SWIM-enabled

applications is necessary. Performance requirements for various data-communication channels in terms of

safety, security, throughput and latency should also be developed. Evaluation of data transmission volumes

in relation to traffic forecasts as well as future applications and services will assist infrastructure planning

including spectrum and bandwidth requirements. The definition of common data formats and information

exchange protocols is considered a priority to support progressive deployment or adaptation of appropriate

ATM system architecture.

5.1.2.2 The impact of SWIM implementation on various ATM systems is likely to be complex and

should not be underestimated. Progressive deployments of SWIM in clearly-defined phases with transition

arrangements that allow for a mixture of SWIM and non-SWIM systems must be considered. SWIM is

intended to be implemented globally, as performance needs dictate. Agreement on global or regional

implementation milestones for some stages could be beneficial in harmonizing deployment.

5-4 Manual on System Wide Information Management (SWIM) Concept

5.2 SWIM AIR-GROUND

5.2.1 The Global Air Navigation Plan (Doc 9750) introduces ASBU B2-SWIM “Enabling Airborne

Participation in Collaborative ATM through SWIM” which considers the aircraft to be a fully connected

information node in SWIM, enabling full participation in collaborative ATM processes with exchange of data,

including meteorology, that starts with non-safety critical exchanges supported by commercial data links.

5.2.2 In general, the exchange and access to information between flight crews and ground

operations

facilities are often imbalanced. Specifically, flight crews do not have access to a common or

shared information platform to fulfil their advisory

needs in-flight or on the ground. The information

unavailability, whether on demand or in near real-time, prevents flight crews from making informed decisions

and hampers their ability to plan strategically and tactically.

5.2.3 Furthermore, ground-based systems and air traffic managers do not have a single mechanism

to obtain real-time information updates about a specific flight, its operation, and its surrounding airspace

conditions. These shortfalls inhibit the predictability, flexibility, and efficiency of the ATM system and have

motivated an exploration of airborne use of SWIM by ATM System participants.

5.2.4 Air-ground solutions are being explored and will leverage the SWIM infrastructure to give flight

crews access to relevant, system-wide information. The information delivered to flight crews via an

alternative communications medium will come from a common infrastructure – SWIM. However, not all ATM

information will be available in order to protect proprietary information and security. Making information

available will increase common situational awareness between flight crews and ground operations, while

promoting strategic/tactical planning and more informed decision making. It will also be the mechanism that

will afford airspace users the ability to provide near real-time input, such as atmospheric conditions, to

ground operations facilities and systems. This timely bi-directional communication link will help create a

shared ATM system picture and is expected to contribute to increased predictability, flexibility, and efficiency

within the ATM system

“Ground operations facilities” are defined as all ASP facilities (centers, terminal facilities, central traffic

flow management, towers, etc.) and operations centers (AOCs/FOCs).

The term “advisory”, here, is not synonymous with ATM advisories such as Traffic Management

Initiatives issued by traffic flow management. Advisory information is defined as supplemental information

that is not necessary for command and control of an aircraft.

Chapter 5.

5.2.5

environme

primary co

portrays a

The oper

boundary

managem

to their air

The da

SWIM, ma

Future De

Figure 17

t including

mand and

bi-directional

tions centre,

rotection se

nt service

raft are sho

a managem

ipulating th

elopments

gure 17. Ex

is a “to-be”

the importa

control met

commercial

pictured h

rvices) or th

On the right

nt service

t data, and d

mple Far-T

representati

t role air-g

ods are de

data link via

re, may re

ough the ai

the customa

ictured is a

stributing rel

rm Air-Gro

on of air-gr

ound soluti

icted (e.g. v

air-ground

eive adviso

borne soluti

ry connectio

endor(s) m

vant inform

nd Informa

und inform

ns will fill.

oice, data c

olutions use

y informatio

n (via the v

s between

naged servi

tion in a usa

ion Exchan

tion excha

On the left

mm). The

solely for

through ei

endor mana

irline operati

e, accessin

le format to

ge in the

side of the

iddle of th

dvisory infor

ther SWIM

(

ed air-grou

ns centres

(

raw ATM

their custom

5-5

ar-term

figure,

figure

ation.

(

across

d data

(

AOCs)

ata via

rs.

5-6 Manual on System Wide Information Management (SWIM) Concept

5.3 INTERCONNECTING SWIM SERVICES ACROSS

ASP/REGIONAL BOUNDARIES

5.3.1 Several ATM service providers have already begun implementing SWIM. During transition to a

global SWIM environment, these local SWIM enterprises are most likely to connect, by necessity, to similar

enterprises through a series of bilateral agreements to achieve interoperability. Unless planned upfront, a

global SWIM can, de-facto, emerge as a large collection of these agreements, thereby complicating the

achievement of global interoperability. The result would be inflexibility at a global level owing to the

complexity of managing change.

5.3.2 To avoid such an outcome, there needs to be a means for the global provision and connection

of services across SWIM enterprises. Several strategies may be applied, including:

a) prescriptive global and regional interface specifications, as is current practice for ATM

ground-ground communications. While this approach addresses the proliferation of

agreements, its lack of flexibility is at odds with the desired agility. SWIM is expected to be

agile and provide the information exchange necessary for future capabilities as they are

deployed;

b) use of industry standards and development of additional standards for areas where none

exist. Given the evolving nature of IT standards and the fact that differing SWIM Regions

will implement standards in accordance with their needs, the use of gateways through the

options as previously described in Section 3.2.2 will be required. Advantages include:

(i) the application of existing standards enables the use of developed tools and an

existing knowledge base thereby lowering development costs and risks; and

(ii) new standards may be adopted where required as they become mature.

c) accept the proliferation of bilateral agreements initially, with the assumption that

standardization will emerge organically as part of individual ASP’s performance-based

processes. The use of gateways remains during transition and has its advantages, as

follows:

(i) provides the simplest governance model;

(ii) enables individual ASPs and their Regions to consider interoperability as part of their

performance case; and

(iii) allows first adopters the flexibility of implementing the newest technology,

demonstrating tangible performance benefits for other ASPs.

d) use of a public/private partnership for global SWIM in which a SWIM enterprise may use a

third party provider, be it public or private, to enable the delivery and receipt of services

from other SWIM enterprises (Figure 18). This approach provides advantages, such as:

(i) enabling a service-based cost system for enterprises at different stages of SWIM

implementation;

(ii) cost-sharing of fixed development costs;

(iii) providers can more easily take advantage of the latest technologies, architectures

and governance models to manage interoperability; and

(iv) greater flexibility as lower-level implementation changes can occur, subject to

performance standards in accordance with service-level agreements, without

necessitating review and consensus across ASPs.

Chapter 5.

Note.

—

Future De

—

The select

elopments

Figure

d regions fo

8. Public/pr

SWIM are ill

–

–––––––––

–

vate model

strative as

–

––––––––––

–

or Global S

ore SWIM r

–

––––––

gions may

evelop.

5-7

A-1

Appendix A

SWIM AND INFORMATION DOMAIN MANAGEMENT

This Appendix explains the relationship of SWIM with Information definition and information domain

management. Section A.1 introduces four topics that arise regarding information management and

harmonization especially in a global context. Sections A.2 and 0A.3 introduce the concept of information

domains, and some criteria that may be applicable in ensuring consistency and avoiding duplication in

domain definition. Sections A.4 through A.5 describe a process to manage, perform, and oversee the

performance of activities within one or more information domains.

A.1 Major ATM IM Topics

The following four topics (in question/answer form) relating to information management are of interest to

SWIM stakeholders:

1. Who has the responsibility to define information relevant to ATM? Pioneer States and the

aviation stakeholders have cooperated in defining information relevant to ATM operations. These

activities have been coordinated with ICAO and the definition continues to evolve as more

sophisticated ATM concepts are introduced globally. As standardization of information is key to

SWIM, and as SWIM is at the heart of the future ATM concept, more collaboration and

coordination involving multiple parties will be required.

2. How is information organized so that one can understand its meaning and build means to

appropriately exchange and share? This has progressed via multilateral efforts in defining the

organization of information. This has led to the definition of data exchange models such as the

AIXM, the WXXM and the FIXM and in the most mature cases to concrete implementations and

commercially available solutions. ICAO has identified the ATM Information Reference Model

(AIRM) under the ASBU Digital ATM Information Management (DATM) module to capture all

types of information used by ATM in a consistent set of data and service models.

3. How is information mapped to services delivered? Traditionally each region defined its

services for specific domains and identified the information elements associated with those

services. The definition of agreed upon global information exchange services is still in progress.

Reference models for information services have been proposed in some regions. A global

service description template is required.

4. How does one avoid duplication and ensure consistency between formats and data

items? This requires multilateral cooperation and coordination at the level of the architectural

approaches to define the information elements applicable to ATM, and commonly agreed and

understood processes and criteria. Amongst these criteria there is a need for clearly defined

SWIM compliance criteria. The ICAO process is central to this cooperative endeavour.

A-2 Manual on System Wide Information Management (SWIM) Concept

A.2 Information Domains

An information domain is focused on identifying, defining, and satisfying the information needs of the set

of business activities associated with a specific area. The concept of information domains, information

exchange services, and information exchange models was introduced in Sections 3.4 and 3.5.

The concept of progressively achieving a seamless information space, supported by exchange models

related to information domains within each user context, is realized by SWIM-enabled applications. This

means applications may consume information services that relate to one or more domains. As a

consequence, the provider side with the current domain realities needs to be combined with the consumer

needs in a balanced and agile way. SWIM intends to address this balance.

Therefore, a first key SWIM concept is the separation between information provision and information

consumption. A second key concept is the use of logical information services that can be instantiated at

the physical level in different ways, thus enabling an architectural approach based on “one logic and

multiple potential solutions”.

This implies that both provider and consumer views need to be considered at the specification and

implementation levels to build fit-for-purpose solutions. To address this complex problem the ATM

Information Reference Model and the Exchange models play complementary but clearly delineated

roles.

Exchange models have been defined for the following domains of ATM operations: meteorological

information (WXXM), aeronautical information (AIXM), flight and flow information (FIXM), and surveillance

information (ASTERIX). In addition it is worth noting that other communities of interest are developing

exchange models such as is the case for the industry requirements for aerodrome mapping, terrain and

obstacle information involving organizations such as RTCA, EUROCAE and ARINC.

What ultimately binds the providers and the consumers together in data exchanges are the information

services which represent a formal contract between provider and consumer. Information services

themselves are identified and defined using the ATM information reference model. Information services

implementation specifications are based on exchange models since they are closer to the solution space.

Altogether Information services are made available through an information service reference model and

their implemented instances exposed through the SWIM registry.

SWIM-enabled applications are thus enabled to access to multiple information domains via their respective

domain services and via further cross domain services, built using SWIM-compliant exchange models,

altogether providing improved situational awareness to different classes of users.

A.3 Criteria applicable to Information Domains

Each information domain identified serves a distinct business need; however, these domains may consist

of shared interests and relationships. This means that harmonization must occur between information

domains to ensure element data and information content matches the intent. As the aggregate pool of

ATM data and information is quite broad, some criteria are necessary to identify which data and

information should be organized and defined within which domain. An outcome of the rationalized

framework for harmonization will be identification of dependencies. Examples include:

Appendix A. SWIM and Information Doman Management A-3

a) Information items that are contained in one domain but used by another.

b) Information items that might be ambiguously contained in two or more information

domains.

c) Information items with dependencies (value of one affects the other, or they are

correlated). These require processes for ensuring that update cycles are synchronized, or

versioned in a manner to prevent errors.

A specific example of a dependency that has already surfaced is the communication code and flight type

data represented in the aeronautical information domain and the flight information domain.

The paragraphs below provide a set of guidelines for identifying an information domain and the criteria are

described separately. It is recognized, however, that identifying a new information domain is not a

necessary task for most regions; most regions that are newly-adopting SWIM are likely to adopt those

recommended by ICAO.

Essentially, any candidate information domain should:

a) represent a distinctive set of mission-related business activities

Examples include: (a) navigation activities related to the Navigation Domain, and (b)

Trajectory Management related to a series of cross domain activities such AIM, Flight,

MET, etc. (these activity groupings may also be referred to as operational focus areas).

b) have requirements for data and information that are unique to it or can be used

differently from other mission-specific activities or existing information domains.

For example, surveillance and navigation activities both use geospatial data and

information; but they use it differently and each has a different view of it. Surveillance

activities use this data and information to answer the question “Where are you?” or “Are

you supposed to be there?” versus Navigation activities that use it to answer the questions

“Where am I?” and “How do I get there?” However in both cases the fundamental

geospatial nature of coordinate information and the way the information is understood

should not differ, hence allowing both domains to apply similar software components at a

lower level and thus providing cost savings to the organizations at a higher level. For this

reason the ATM information reference model provides foundation classes which could be

used throughout ATM as a common and standardized pattern, structurally enabling cost

savings. As a consequence this separation of concern is important in information

management as it allows each domain to focus on those aspects which are specific to

each of them. In this example neither the surveillance nor the navigation domain should

define what a coordinate is as it would be provided by SWIM whilst respecting the different

domain purposes.

c) represent the data and information needs of a specific group of people who perform

these mission-specific activities (the practitioners) and who may be involved with: (a)

the capture or generation and validation of data; or (b) the creation, update, processing,

distribution, or use of information within these domain-specific activities.

A-4 Manual on System Wide Information Management (SWIM) Concept

A.3.1 Quality Criteria for Information Domain

This section identifies and describes an initial set of guidelines to ensure the formation of an information

domain is of high-quality. The key criteria are presented in Table A-1, Information Domain Quality Criteria.

These criteria can be used to develop and maintain information domain models and were identified by

others who have created information domains and have passed on their recommendations, lessons

learned, and best practices. Therefore, the citation (from sources) of these criteria is provided within the

table, when a unique guideline was identified.

Table A-1. Information Domain Quality Criteria

Information

Domain Quality

Criterion

Information Domain Quality Criterion Guideline

Scope

One of the most important aspects to consider initially when developing an

information domain model is to ensure all involved parties agree to an explicitly

detailed definition of the scope. Specifically, where two or more organizations or

groups are involved, the information domain model should identify and describe): (a)

what activities and processes are to be modelled and whose are going to be

modelled; (b) what information is to be modelled and whose information is going to

be considered; (c) the applicable requirements and constraints, if any; and (d) the

intended and desired results and outcomes. This ensures that the effort will address

only those areas identified and eliminate any confusion later on. Also, the scope

must be manageable and do-able by the specified parties – too large a scope and

the process and products become unwieldy and costly and too small may not be

worth the effort or be a waste of resources. (Lasschyut, van Hakken, Treurniet, &

Visser, 2004) pp. 9-11, 9-12.

“A system is said to be part of a domain when it is able to interact with other

systems by making use of the domain’s exchange language… The size or scope of

a domain determines how many and what kind of systems belong to that domain.

Since a domain represents an information standard, its scope can also be specified

as the kind of information that is common and exchanged between systems within

the domain. The scope must be clearly defined in order to avoid wrong usage of the

standard.” (Lasschyut, van Hakken, Treurniet, & Visser, 2004) p. 9-30

In a large environment or industry like air transportation, “…having multiple domains

is usually unavoidable. The real challenge in this is finding an optimal partition of the

total interoperability area. This comes down to finding a proper scope for each

domain as well as the best subdivision of the whole area into domains.” (Lasschyut,

van Hakken, Treurniet, & Visser, 2004), 9-31

Purpose

The purpose of the modelling effort should be clearly and concisely stated and

agreed to by all involved parties. It should also include a description of the intended

and desired results and outcomes in as much detail as possible. It should include

the different artifacts that are required to satisfy the description of the model,

including (a) the type of artifacts to be provided, acquired, or developed; (b) the

applicable descriptions and models of the information and mappings down to the

types of data requirements involved; (c) the supporting scenarios and use cases

necessary to describe the activities involved; and (d) a description of the

development process methods, techniques, and tools to be employed. This will

ensure that the desired result is obtainable and it is achieved for exactly those

purposes for which it is meant to be (Lasschyut, van Hakken, Treurniet, & Visser,

2004), p. 9-11

Appendix A. SWIM and Information Doman Management A-5

Information

Domain Quality

Criterion

Information Domain Quality Criterion Guideline

Partitioning

Scope into

Multiple Domains

“A domain typically contains systems with much information in common, which is

exchanged between them relatively frequently. So a domain represents a clustering

of systems which are closely related [that can be based on similar information

content, functionality of systems, quality requirements (such as security and

timeliness), or the organizations that use or own the systems]. This implies that a

suitable initial set of domains is largely derived by grouping systems that exchange

much similar information. But enterprise-interoperability implies there is a need to

interconnect potentially any system with any other. This means that systems out of

different domains must be able to talk with each other as well. In other words,

domains have to be linked somehow. This happens in the same way individual

systems are clustered into domains; the initial (or ‘basic’) domains may be grouped

into new domains at a higher level. A higher-level domain represents a set of

domains (groups of systems) which are interconnected by means of a common

exchange language.” (Lasschyut, van Hakken, Treurniet, & Visser, 2004), p. 9-31

Level of Detail

All involved parties should agree at the outset on the level of detail desired.

Any modifications to that agreement should be documented and agreed before

any changes are made. (Lasschyut, van Hakken, Treurniet, & Visser, 2004), pp. 9-

12, 9-13

Shared

Information and

Artifacts

All involved parties should agree at the outset to information and artifacts that are to

be shared. The agreement should clearly state who is going to provide whom the

information or artifacts, where, when, and how often. The agreement should also

identify who “owns” what information and artifacts to be shared and what: (a) “rights”

are provided to or permitted by its recipients; and (b) “restrictions” or “constraints”

apply, given specified circumstances and situations. This is particularly sensitive if

commercial or “for profit” organizations are involved (Lasschyut, van Hakken,

Treurniet, & Visser, 2004) p. 9-12

Methods of

Communication

among Involved

Parties

It is always good project management practice to develop and execute a

communications plan that identifies who, when, and how managers, team members,

and stakeholders should be kept abreast of the involved parties efforts. The initial

agreement should clearly state the roles and responsibilities and the communication

expectations of these individuals. Of course, any amendments to the agreement

should be clearly documented, agreed, and communicated to the respective parties.

Comprehensive

The quality of information (necessary to adequately cover the scope or a specific

topic within the scope) must be: (a) determined up front; (b) agreed to by all

involved parties; and (c) stated in such a way that it is satisfactory to and meets, if

not exceeds, the needs of the information consumer. (Eppler, 2006). IAIDQ

Glossary

Information

should be

Uniquely

Identified and

Unambiguously

Defined

The information (and underlying data) must be captured and made available to all

involved parties, in accordance with the agreement(s) and Communication Plan.

The identity and definitions of this information (and corresponding data) should be

captured and documented in such a manner that it can be uniquely identified and

unambiguously defined across the specified organizational boundaries, domains,

and heterogeneous systems. (Heath & Bizer, 2011) pp. 7-15.

A-6 Manual on System Wide Information Management (SWIM) Concept

Information

Domain Quality

Criterion

Information Domain Quality Criterion Guideline

Knowledge

should be

Captured and

Available

Any knowledge (e.g. business rules, methods, techniques, best practices, lessons

learned), that is deemed important to the task at hand, should be captured and

made available to all involved parties as specified in the agreement. (Heath & Bizer,

2011) pp. 26-27

Flexible Design

The artifacts developed should be built or developed in such a way that they may

easily be maintained and updated. The requisite information (and corresponding

data) should be harmonized and semantically complete across the domain and

organizational boundaries of the involved parties. (Lasschyut, van Hakken,

Treurniet, & Visser, 2004) p. 9-14

Information

should be easily

Discoverable

The information (and underlying data) must be captured and made available to all

involved parties, in accordance with the agreement(s), should be seamlessly and

easily discoverable, and any new information (or underlying data) should be easily

integrated with the existing information in the artifacts, registries, and repositories.

(Heath & Bizer, 2011) p. 26

Complete

The description of the domain and associated information should be complete

based on the definition of the agreed scope and, secondly, on the desired output or

result specified in the purpose of the initiative.

“The usual defects related to completeness include:

a) The omission of domain concepts, and

b) The omission of relationships.

In a domain model there is actually a reverse kind of completeness fault. Domain

models may actually include too much information. There is a tendency to include

implementation details particularly when the project is reengineering an existing

application. The risk of “over completeness” is that implication decisions may be

made too soon. By inclusion in an analysis model these decisions may be viewed

as requirements rather than the target of critical examination.” (McGregor,

unknown).

Each Data item

should have a

Unique Identifier

To ensure different data items are the same and can be easily found, each data

item needs to have a unique identifier assigned. For those data items that are going

to be exchanged, we recommend a universal or globally unique identifier be

assigned. With the popularity of Web Ontology Language (OWL) [sic] and Resource

Description Framework (RDF) on one end of the spectrum and taxonomies and

ontologies on the other, semantic technologies are moving towards establishment of

unique identifiers for each data item. Due to the need to exchange information at the

global level, it is recommended the assignment of globally unique identifiers for

each data item that is shared. (Heath & Bizer, 2011) pp. 7-27

A.4 Major Activities in Information Domain Management

Five major activities are associated with managing a domain. These are executed by different individuals

or groups with different roles, as follows:

Appendix A. SWIM and Information Doman Management A-7

 Manage information domain community-related activities – this activity performed by the

community manager(s), establishes and manages the activities of the information domain. Sub-

activities include:

a) establish information domain community;

b) establish and maintain information domain membership; and

c) manage activities of information domain community.

 Manage activities across domains – performed by the management council, this activity evaluates

and resolves matters, interests, and issues which surface from the information domain communities

that have a conflict or which need to be considered and resolved. Sub-activities include:

a) resolve conflicts and issues within and among information domains;

b) establish, maintain and ensure compliance with applicable policies, directives, methods

and procedures; and

c) establish maintain and ensure compliance with applicable standards and standard

toolsets.

 Perform information domain community-related activities – performed by the community

members, this activity performs the “real work” associated with the activities of the information domain.

Sub-activities include:

a) maintain information about information domain community member;

b) perform activities of information domain community;

c) comply with applicable laws, regulations and rules;

d) comply with applicable policies, directives, methods and procedures;

e) comply with implementation and execution of standards; and

f) comply with implementation, execution and usage of standard toolsets.

 Oversee Performance and Management of Information Domain community-related activities –

performed by the regulator, this activity assures the communities’ compliance with applicable laws,

regulations, rules, policies, methods, practices, procedures, standards and tools. Sub-activities

include:

a) assures compliance with applicable laws, regulations and rules;

b) assures compliance with applicable policies, methods, practices and procedures; and

c) assures compliance with applicable standards and standard toolsets.

A-8 Manual on System Wide Information Management (SWIM) Concept

 Govern Information Domain community-related activities – performed by the governance body this

activity governs the activities of the communities at a global or international level. This activity

adjudicates conflicts and issues among information domains.

A.5 Relationship to SWIM

A.5.1 Information Management

Information Management requires a process where the management of an organization or group plans,

organizes, provides leadership, and controls the:

a) need for addition or improved information or information artifacts or resources based on

business requirements;

b) acquisition of data (to make information) and information (from external sources);

c) production of information or information artifacts or resources (which may also include content

management) that is fit for use/purpose of the domain;

d) processing (or transformation) of information;

e) retention, physical storage, and retrieval of desired information, information artifacts, and

information resources;

f) distribution of information, information artifacts, and information resources to primarily

information consumers and secondarily to information service brokers and information service

providers (see definitions below in this section);

g) utilization of information, information artifacts, and information resources to limit unauthorized

access and use, malicious and unintentional modification or destruction, and ensure

conformance with applicable laws and regulations; and

h) maintenance of information, information artifacts and information resources to ensure they are

up-to-date and remain relevant in their content or appearance or format.

Information management activities are performed by the management of information producers and are

referred to as “Information Managers.”

Table A-2 summarizes the differences in the roles between the areas of responsibility and functions:

information domain process, information operations, information management, information oversight, and

SWIM. Areas of responsibilities/functions are described following the table. Further explanations of the

terms used are in the following subsections.

Appendix A. SWIM and Information Doman Management A-9

Table A-2. Comparison of Roles among Information Domains, Information Management,

Information Oversight, and SWIM

Information

Domain Process

Information

Operations

Information

Management

Information

Oversight

SWIM Technical

Infrastructure

Data Perspective

Data Producer Data Manager Data Overseer

(Regulator)

Data Processor

Data Provider

Data Consumer

Information Perspective

Information

Producer

Information Manager Information

Overseer

(Regulator)

Information

Processor

Information

Provider

Information

Consumer

Community

Member

(Practitioner,

Involved Party,

Beneficiary)

Information

Overseer

(Regulator)

Community

Manager

Management

Council (group of

Community

Managers)

Service Perspective

Service Consumer Service

Overseer

(Regulator)

Service Producer

Service Broker

Service Operator

Service Provider

Service Manager

A.5.2 Information Oversight

Information Oversight requires a process where overseers and regulators monitor, examine, and

evaluate the performance of the operations and management to:

a) ascertain whether they are in compliance with the appropriate and applicable laws,

regulations, rules, policies, methods, practices, procedures, standards, and standard toolsets;

b) assert vested authority and work with operations or management when non-compliance is

identified to bring their actions back into the range of compliance; and

A-10 Manual on System Wide Information Management (SWIM) Concept

c) issue violations for infringements, or sanctions where enforcement is required, should

operations or management still remain outside the boundary of compliance after initial

notification of non-compliance.

Information oversight activities are performed by overseers; who may also be referred to as “Regulators.”

A.5.3 Information Service Management

Information Service Management is a process where the management of an organization or group

plans, organizes, provides leadership, and controls the:

a) need for new or improved information services;

b) design of new or re-engineering of existing information services to ensure they meet, if not

exceed, the needs of the information consumer;

c) development and subsequent implementation of new, re-engineering, or upgraded information

services;

d) operation of information services (whether manual or automated);

e) provision or delivery of information services (whether manual or automated – and includes the

provision of communications operations and management);

f) utilization of information services to: (a) limit unauthorized access, malicious and unintentional

disruption or cessation of service, and ensure conformance with applicable laws, regulations,

and service agreements and contracts; and (b) monitor the level of service provision and

utilization to ensure up-to-date information services and high-quality information is available to

information consumers to use to make informed, intelligent decisions or take action in

response to a stimulus and ensure they are satisfied with the services they consume; and

g) maintenance of the information services to ensure the information services are kept up-to-

date and appealing to the information consumers.

Information service management activities are performed by the management of Information service

brokers, providers, and operators and are referred to as “information service managers.”

In summary, the information management activities are related to the creation of the information artifacts

(products), and require an information manager role and information producer role. The information

domain community activities involve preparatory work to get the information harmonized across different

communities and made ready to be shared. The information service management activities are related to:

(a) the actual delivery of the information or information artifact to an information consumer; or (b) the

performance of an information-related service for an information consumer. The information service

management activities involve a service manager role, a service broker role (optional), one or more service

operator roles, and one or more service provider roles.

B-1

Appendix B

SHORT DESCRIPTION OF POTENTIAL CANDIDATE SWIM

STANDARDS

This appendix provides a short description of the potential candidate SWIM standards

that were

mentioned in Section 3.7.2 SWIM technical architecture.

B.1 Information Exchange Services

B.1.1 Service Interoperability

Information exchange services are still under definition and no interoperability standards for the services

exist. However, there is general agreement that the initial information exchange services need to be

defined for aeronautical information exchange, flight information exchange, and meteorological information

exchange. Individual ASPs and some SWIM regions have undertaken some efforts in defining these

services. The definition of these services is very important for member States in agreeing upon a global

SWIM services and how they can make use of such services. Additional information exchange services

are planned.

For example, Single European Sky ATM Research (SESAR) provided network operations plan Business-

to-Business (B2B) Web Services have been grouped over 4 domains:

a) flight services (flight preparation, flight plan filing and management);

b) airspace services (management and publication of airspace information);

c) general information services; and

d) flow services (flow & capacity management).

B.1.2 Interface Definition

 WSDL (Web Services Description Language)

WSDL describes the abstract interfaces, protocol bindings and deployment details of services. It can be

considered as a complement to the UDDI standard. Understanding the relationship between WSDL and

UDDI and establishing a mapping between them allows the automatic registering of WSDL definitions in

UDDI.

Not all potential candidate standards are listed in this appendix.

B-2 Manual on System Wide Information Management (SWIM) Concept

In SWIM services developed by the ASP, application systems will be exposed using WSDLs during

design-time. A WSDL provided by an information provider is stored in a registry in accordance with the

registry data model to be defined. Information consumers can then search the registry and discover the

service they are seeking based on service characteristics including deployment details as provided by the

WSDL. The information consumer is then able to invoke the service during run-time.

As part of the WS-I Basic standard and a widely used mechanism to describe services (e.g. ports and

binding information), WSDL is a key enabler of the kind of technology (web services and SOA) SWIM is

implementing for seamless information exchange.

 Web Feature Service (WFS)

WFS (OGC Web Feature Service, 2005) provides an interface allowing requests for geographical features

across the web using platform-independent calls. Basic WFS allows querying and retrieval of features.

Transactional WFS (WFS-T) allows creation, deletion, and updating of features.

 Web Map Service (WMS)

WMS (OGC Web Map Service, 2005) provides a simple HTTP interface for requesting geo-registered map

images from one or more distributed geospatial databases. A WMS request defines the geographic

layer(s) and area of interest to be processed. The response to the request is one or more geo-registered

map images (returned as JPEG, PNG, etc.) that can be displayed in a browser application. The interface

also supports the ability to specify whether the returned images should be transparent so that layers from

multiple servers can be combined or not.

Note.— WMS 1.3 and ISO 19128 are the same documents.

B.2 Information Exchange Models and Schemas

B.2.1 Aeronautical, Meteorological, and Flight Information

Information exchange standards are the standards that are needed for domain applications to interoperate.

The more mature domains are for flight data, aeronautical, and meteorological data. air traffic management

information reference models for these domains (and other domains) have or are being developed by

international bodies. While there are many exchange standards, examples include AIXM, WXXM, and

FIXM.

 AIXM

The aeronautical information exchange model (AIXM) is designed to enable the management and

distribution of aeronautical information services data in digital format. AIXM takes advantages of

established information engineering standards and supports current and future aeronautical information

system requirements. The major tenets are:

a) an exhaustive temporality model, including support for the temporary information contained

in NOTAM;

b) alignment with ISO standards for geospatial information, including the use of the geography

markup language (GML);

Appendix B. Short Description of Potential SWIM Candidates B-3

c) support for the latest ICAO and user requirements for aeronautical data including obstacles,

terminal procedures and airport mapping databases; and

d) modularity and extensibility.

 FIXM

The flight information exchange model (FIXM) is a data interchange format for sharing information about

flights throughout their lifecycle. FIXM is part of a family of technology independent, harmonized and

interoperable information exchange models designed to cover the information needs of air traffic

management.

 WXXM

The weather information exchange models and schema (WXCM-WXXM-WXXS) are designed to enable a

platform independent, harmonized and interoperable meteorological information exchange covering all the

needs of the air transport industry. [When the 3-tiered model (WXCM-WXXM-WXXS) is referred to as a

single entity, the term used is 'WXXM'.]

The WXCM-WXXM-WXXS takes advantages of existing and emerging information engineering standards

and supports current and future aeronautical meteorological information system requirements.

The major tenets are:

a) support for the latest ICAO and other user requirements for meteorological information by

one single representation;

b) alignment with ISO standards for geospatial information, including the use of the

geography markup language (GML);

c) alignment with OGC best practices for geospatial information, including the observation &

measurement model; and

d) modularity to support future requirements.

B.3 SWIM Infrastructure

B.3.1 Enterprise Service Management Standards

Long term standards for WS management are still evolving and are not readily available in products. Web

services manageability is defined as a set of capabilities for discovering the existence, availability, health,

performance, and usage, as well as the control and configuration of a Web service within the web services

architecture. This implies that web services can be managed using web services technologies. The

importance of a standardized management model for web services and the promise of web services as a

management integration technology is a future SWIM goal.

B-4 Manual on System Wide Information Management (SWIM) Concept

The most popular standards for monitoring and control in SWIM are likely to be the simple network

management protocol (SNMP) and java management eXtension (JMX). These are not strictly service

management standards such as WS-distributed management (WSDM). JMX only works for Java based

platforms, and SNMP does not really support management at the service layer, only at network/platform

infrastructure layer. Exchange of ESM information across organizations is also likely to be minimal unless

enough trust has been built up and is likely to be bilateral in nature.

B.3.2 Policy Standards

WS-policy defines a general-purpose framework for representing and combining statements about the

QoS properties. WS-policy is an extensible framework that can accommodate domain-specific dialects to

represent these assertions and allow the attachment of policies to arbitrary types of subjects through the

generic attachment mechanisms that WS-policy attachments define. One such example is the use of WS-

policy to implement WS-security policy as defined below. WS-policy (version 1.5) was released as a W3C

recommended standard in September 2007 though some vendor implementations have been available

since.

B.3.3 Security Standards

Security standards are still an area of discussion and evaluation. There seems to be agreement that the

two standards that are reasonably mature are WS-security and the secure sockets layer (SSL). A number

of supplemental security standards such as OASIS security assertion markup language (SAML) are under

consideration.

Agreements on security standards among organizations are more likely to be bilateral in practice and

require memoranda of agreement. Organizations develop a trust level slowly among their respective

communities of interest (stakeholders that they work with frequently). It is likely that each organization will

decide to expose an agreed upon set of information services at their boundary protection gateways.

 WS-Security 1.1

The OASIS standard WS-security 1.1 is recommended to provide secure SOAP message exchange from

message endpoint to message endpoint. The primary mechanism for implementing WS-Security is the

incorporation of enhancements to the SOAP header and body.

The WS-I basic security profile makes additional recommendations for the interoperability of services

defined by WS-Security; it also makes additional recommendations intended to improve the security of

web services.

 Secure Sockets Layer (SSL) Protocol v3.0

SSL and its successor TLS were developed to address transport level shortcomings in HTTP. SSL is the

commercially available implementation of the TLS standard. SSL and TLS are encryption technologies that

can be used to provide secure transactions. SSL and TLS can provide for both server-only or server and

client (mutual) authentication. SSL uses symmetric encryption for private connections and asymmetric

encryption for peer authentication. It also uses a message authentication code (MAC) for message

integrity checking.

Appendix B. Short Description of Potential SWIM Candidates B-5

While the use of transport level security may be simpler to deploy than WS-Security mechanisms, it can

only be used for securing information between two web services, or for point-to-point connections without

intermediaries.

B.3.4 Reliability Standards

 WS-Reliable Messaging

WS-reliable messaging is a standard for a reliable messaging architecture for web services.

While the use of a standard like WS-reliable messaging will allow the development of robust and reliable

web services as well as ensure transport independence, its use in early implementations of SWIM should

be predicated on the fact that it has matured. At this time the WS-reliable messaging standard has been

approved by OASIS but needs to be evaluated for maturity for use in SWIM.

This leads to the consideration of more traditional mechanisms like JMS which is recommended for use in

SWIM.

 WS-RM Policy

This standard may be considered for use in later SWIM implementations for distributing declarative policy

regarding use of reliable messaging.

B.3.5 Data Representation Standards

SWIM standards for data representation consist of XML and XML Schema Definition (XSD). XML provides

a standardized method for describing data structures and data types while XSD formalizes how elements

are described in an XML document.

Extensible stylesheet language transformations (XSLT) is a SWIM standard for XML data transformation.

XML path language (XPath) and XML query language (XQuery) are SWIM standards for querying for XML

data via web services.

XML is a universally accepted standard way of structuring data that is a basis for how data is represented

in web services. XSD, XSLT, XPath, and XQuery are all standards/tools which were created to facilitate

the use of XML and are widely used.

The geography markup language (GML) is the XML grammar defined by the open geospatial consortium

(OGC) to express geographical features. GML serves as a modeling language for geographic systems as

well as an open interchange format for geographic transactions on the internet.

B-6 Manual on System Wide Information Management (SWIM) Concept

B.3.6 Messaging Standards

 SOAP

SOAP is the messaging envelope used to exchange information between producers and consumers in

SWIM. SOAP can be transported either over HTTP or other transport mechanisms such as JMS or MQ.

SOAP is listed as a messaging standard for SWIM because it is mature and currently the most widely used

protocol for SOA implementations. In this context, a standard is mature if multiple commercial vendors

provide software implementations conforming to this standard.

However, when necessary, due to performance, security or other concerns, other approaches may be

used in SWIM. The REpresentational state transfer (REST) architectural style, using Plain old XML is also

possible. REST may work well across organizational boundaries because of its simplicity.

 JMS

JMS is an application program interface (API) for accessing enterprise messaging systems. It is part of the

java platform, enterprise edition (Java EE). JMS defines a common enterprise messaging API that is

designed to be easily and efficiently supported by a wide range of enterprise messaging products such as

IBM websphere MQ. JMS in conjunction with a product like IBM websphere MQ (via a Provider) can

provide a reliable transport for SOAP. It can also support the publish/subscribe MEP. In case WS-

notification and WS-reliable messaging are determined to be not suitable for SWIM, JMS is a viable

alternative until the WS* standards mature.

Note.— JMS is only an API standard; it does not provide an "on the wire" standard for machine-to-machine

message transfer. Interoperability of two communicators that use different JMS implementations may be

accommodated by supporting multiple message queueing (MQ) protocols. There is also an on-going effort

to define a common “on the wire” standard.

 Data Distribution Service for Real-Time Systems (DDS)

DDS is the first open international middleware

standard directly addressing publish-subscribe

communications for real-time and embedded systems. It is published by the object management group

(OMG) DDS portal. There are at least two commercial implementations available.

DDS introduces a virtual global data space where applications can share information by simply reading

and writing data-objects addressed by means of an application-defined name (Topic) and a key. DDS

features fine and extensive control of quality of service (QoS) parameters, including reliability, bandwidth,

delivery deadlines, and resource limits. DDS also supports the construction of local object models on top of

the global data space. The current DDS specification is version 1.2 and the current DDS interoperability

wire protocol specification (DDS-RTPS) is version 2.1.

Middleware is software that serves to "glue together" or mediate between two

separate and often already existing messaging standards (or implementations of an API such as JMS).

Appendix B. Short Description of Potential SWIM Candidates B-7

B.3.7 Transport Standards

 Hyper Text Transfer Protocol (HTTP)

HTTP is a widely available application layer transport mechanism. HTTP is listed as a transport protocol

because of its traditional role as an application transport mechanism for SOAP. It is an ideal application

transport for interactions that don’t require reliability. Once WS-reliable messaging matures, it is expected

that SOAP using WS-reliable messages can be transmitted reliably over HTTP.

 Java Messaging Service (JMS)

JMS was already described while considering the messaging layer. Because JMS is an API it can be

considered at either layer.

 Proprietary Message Oriented Middleware

IBM websphere MQ, Oracle AQ, and sonicMQ are examples of proprietary message oriented middleware

(MOM) that provide a reliable message transport infrastructure using message queueing. MQ products can

be used as standardized products within SWIM not only because of their support for reliable messaging,

but also because of their maturity and wide spread use in enterprises as well as its support for various

legacy host systems. MQ also has the capability to support publish/subscribe messaging as well as

reliable messaging.

MOM products and suitable bridges can ensure interoperability among communicators using different JMS

implementations.

B.3.8 Service Registry Standards

 UDDI (Universal Description, Discovery, and Integration)

UDDI is a standard interface to a directory used for storing information about web services including web

services interfaces. During design time developers are able to find WSDL files and create appropriate

consuming applications based on those files to consume discovered services. Run time service exposure

will be performed via a standard UDDI publishing service interface, defined as part of the UDDI

Specification.

Despite some concerns with the complexity of UDDI, it is supported by many COTS products, and is used

by many organizations. It is an established standard (also part of WS-I basic profile). The adoption of a

single standard for data registry access and retrieval is important for SWIM. Other standards like electronic

business using XML (ebXML) could be used in conjunction with UDDI.

C-1

Appendix C

MEETING THE ATM SYSTEM REQUIREMENTS

A summary of information management and services requirements identified in Section 2.2.1 of the

Manual on ATM System Requirements (Doc 9882) is provided below. Notes explaining how this

SWIM document addresses these requirements are also provided. The requirement number,

referenced in Doc 9882, is in brackets.

The explicit requirements on information management are described as follows:

a) implement system wide information management [R70];

(i) this document provides guidelines for this implementation.

b) establish information exchange protocols and procedures to ensure that appropriate

performance can be achieved within the agreed rules [R12];

(ii) this document describes the representative standards for exchange protocols

and describes the applicable procedures.

c) be capable of collecting and integrating information from diverse sources to produce

a complete and accurate view of the ATM system state [R76];

(iii) operational use of SWIM as described in Section 3 indicates how SWIM is

expected to accomplish this.

d) support a reduction in transactional friction for transmission of information across

systems [R78].

(iv) ensured through provision of interoperable information standards at all layers of

the SWIM framework.

The following characteristics ensure that the requirements are met:

a) provide to the ATM community accredited, quality-assured, and timely information

meeting the identified standards of performance, including quality of services [R74];

b) provide information systems that identify the nature of the information in terms of

timeframe - historical, current, or planned [R75]; and

c) ensure that a relevant validity period of ATM system information is evident to the user

of that information [R79].

The following requirements are met through the exchange of information (via SWIM) falling within

various domains (aeronautical, flight, and meteorological):

a) provide a global, common aviation data standard and reference system to allow

fusion and conflation and provide comprehensive situational awareness and conflict

management [R06];

C-2 Manual on System Wide Information Management (SWIM) Concept

b) assemble the best possible integrated picture of the historical, real-time, and planned

or foreseen future state of the ATM system situation and relevant, quality-assured

and accredited information shall be made available to the ATM system [R123];

c) ensure that the airspace user makes available relevant, operational information to the

ATM system [R07];

d) use relevant, airspace user operational information to optimize flight operation

management [R08];

e) use relevant data to dynamically optimize 4-D trajectory planning and operation

[R09];

f) provide the status of ATM system resources [R13];

g) make available to the ATM system flight parameters and aircraft performance

characteristics [R31];

h) establish standards for meteorological model accuracy and resolution and agree

performance requirements [R157];

i) provide timely access to all relevant meteorological information [R164]; and

j) utilize meteorological data, and information derived from it, to assist in analysis and

evaluation of agreed environmental performance targets [R96].

— END —