1 04-12-14

NextGen - SESAR Data Model Coordination Group (NSDMCG)

ICAO Global Interoperability Framework (IGIF) considerations

Version 1.0

4 December 2014

1 General

1.1 Mandate

The NSDMCG Terms of Reference specifies the following output:

• White papers outlining considerations for an ICAO AIRM and its governance.

• White papers outlining a Global Interoperability Framework and its semantic aspects.

As a part of the NSDMCG proceedings two white papers have been completed:

• “ICAO Air Traffic Management Information Reference Model (AIRM) considerations”.

• “ICAO Air Traffic Management Information Reference Model (AIRM) governance considerations”.

This paper builds upon the “SWIM Concept” document provided by the ICAO ATMRPP [Ref 1]. The

interoperability framework considerations therein are an acknowledged baseline. Following the

consultation on NSDMCG work, it was decided to further elaborate complementary considerations of an

ICAO Global Interoperability Framework (IGIF). This task supports the overall objective of the SESAR AIRM

and FAA NextGen OV-7 coordination. The NSDMCG has no mandate to define the IGIF as such since the

group participation is not representative of all potential IGIF stakeholders. However the IGIF considerations

proposed in this white paper put the ICAO Semantic Framework and ICAO AIRM work into a wider picture

[Ref 11]. This white paper can be the starting point for further work on global interoperability and “SWIM

Concept” as described by the ICAO ATMRPP [Ref 1].

The paper does not elaborate the content of the cited frameworks. This elaboration is expected to be

covered by dedicated white papers under the authorship of appropriate groups.

1.2 Scope

This paper contains ICAO Global Interoperability Framework (IGIF) considerations based on the

SESAR/NextGen harmonisation under the umbrella of the US/EU CP2.1 coordination activity. The IGIF

brings together business and technical aspects into a commonly agreed structure that will foster the

governance and management of interoperability as a whole and promote stakeholder buy-in. Although this

paper includes some governance related considerations at a level deemed appropriate, it is not the intent

to further address governance herein. Further elaborations with regards to the integration of the

considerations of this paper with the existing ICAO governance approach are not part of the scope.

1.3 Audience

The anticipated readership for this document includes:

• The NSDMCG team.

2 04-12-14

• The leadership of Coordination Plan 2.1 (CP2.1), CP3.1, CP3.2, and NextGen/SESAR leadership.

• Federal Aviation Administration (FAA) / EUROCONTROL.

• Members of the ICAO Information Management Panel (IMP) and relevant sub-groups.

1.4 Acronyms

AIRM ATM Information Reference Model

AIXM Aeronautical Information Exchange Model

ANC Air Navigation Conference

ARINC Aeronautical Radio Incorporated

ASBU Aviation System Block Upgrade

ASP ATM Service Provider

ASTERIX All-purpose Structured EUROCONTROL Surveillance Information Exchange

ATM Air Traffic Management

ATMRPP Air Traffic Management Requirements and Performance Panel

AU Airspace User

CONOPS Concept of Operations

CP Coordination Plan

EUROCAE European Organisation for Civil Aviation Equipment

EUROCONTROL European Organisation for the Safety of Air Navigation

Exchange Model Current ATM related Exchange Models such as AIXM, WXXM, iWXXM, FIXM,

ASTERIX, AIDX, etc…

FAA Federal Aviation Administration

FIXM Flight Information Exchange Model

GANP Global Air Navigation Plan

IATA International Air Transport Association

ICAO International Civil Aviation Organisation

ICAO AIRM The AIRM as considered in the global interoperability discussion at the ICAO level

IGIF ICAO Global Interoperability Framework

IMP ICAO Information Management Panel

ISO International Organisation for Standardisation

ISRM Information Service Reference Model

IWXXM ICAO Meteorological Information Exchange Model

NCOIC Network Centric Operations Industry Consortium

NextGen Next Generation Air Transportation System

NextGen OV-7 NextGen Operational View 7 Logical Data Model

NSDMCG NextGen - SESAR Data Model Coordination Group

OGC Open Geospatial Consortium

RTCA Radio Technical Commission for Aeronautics

SDCM Service Description Conceptual Model

SESAR Single European Sky ATM Research

SOA Service Oriented Architecture

SWIM System Wide Information Management

UML Unified Modelling Language

WMO World Meteorological Organisation

WXXM Weather Information Exchange Model

3 04-12-14

References

[Ref 1] ICAO ATMRPP, 2014 SWIM Concept

[Ref 2] EU,2011 European Interoperability Framework (EIF) for European public services

[Ref 3] NCOIC, 2014 NCOIC Interoperability Framework (NIF) (https://www.ncoic.org)

[Ref 4] CP2.1-NSDMCG, 2013 ICAO Air Traffic Management Information Reference Model (AIRM)

governance considerations

[Ref 5] SESAR, 2014 SWIM Conops

[Ref 6] EU PCP,2014 EU PCP deployment regulation

[Ref 7] FAA, 2013 System Wide Information Management (SWIM) solution Guide for

Segment 2A, Version 1.0, 25 June 2013, Federal Aviation Administration

[Ref 8] CP2.1, 2014 SWIM Common Registry (SCR)

[Ref 9] SESAR, 2013 SWIM Master class

https://www.eurocontrol.int/news/swim-master-class-2013

[Ref 10] FAA, 2014 Mini Global Demonstration, August 28, 2014

http://www.faa.gov/nextgen/media/NextGenUpdate2014.pdf

[Ref 11] CP2.1-NSDMCG, 2013 ICAO AIRM and Semantic Framework considerations

[Ref 12] CP 2.1, 2014 Service Description Conceptual Model (SDCM) 1.0, (link)

[Ref 13] ICAO Doc 9854, 2005 Global ATM Operational Concept

[Ref 14] ICAO, 2013 ICAO Global Air Navigation Plan

[Ref 15] INSPIRE, 2007 INSPIRE, Methodology for the development of data specifications

http://inspire.ec.europa.eu/reports/ImplementingRules/inspireDataspec

D2_6v2.0.pdf

[Ref 16] ICAO, 2013 Air Traffic Management Security Manual (Doc 9985)

[Ref 17] FAA, 2011 Federal Aviation Administration Handbook, Using FAA Standards to

Describe and Register Web Services, FAA-HDBK-008, February 4, 2011

1.5 Document Organisation

This document contains following sections:

• General.

• What is an interoperability framework?

• ICAO Global Interoperability Framework (IGIF).

• Recommendations.

• Summary.

1.6 Note to reader

In this white paper the term “ICAO AIRM” is used. It differentiates the “ATM Information Reference

Model” recognised in the Global Air Navigation Plan [Ref 14] from the “SESAR AIRM”, which is being

developed in the context of SESAR pan-European SWIM standardisation. Whether the term “ICAO AIRM”

will remain in use is subject of further discussion. The relationship between the “SESAR AIRM” and the

“ICAO AIRM” is explained in a dedicated white paper [Ref 11].

This paper uses the term “services” in the technical rather than the business sense. The technical

interpretation is that a service is software code that is running and performing a function that may be

invoked via a network. In most cases a “service” is an “information exchange service”. At the organisation

and business level “information services” [Ref 13] are parts of the overall service provision notion that an

organisation performs.

4 04-12-14

1.7 Key Assumptions

SWIM interoperability is not met by providing one solution that fits all.

Full SWIM interoperability is not achieved by technical interoperability alone.

2 What is an interoperability framework? An interoperability framework is a description of the essential components that need to be shared and

considered by all the involved stakeholders in order to effectively achieve interoperability.

The benefit of using an interoperability framework has been demonstrated in various industries and

institutional contexts. To quote two prominent examples,

• The Network Centric Operations Industry Consortium (NCOIC) Interoperability Framework (NIF)

developed to serve the needs of the U.S DoD [Ref 3], states that it is “implemented as a

development framework which helps system architects and system engineers to embed

interoperability elements throughout the life cycle of programs, beginning with requirements.

Whenever possible, those resources are based upon standards. The NIF approach supports the

creation and integration of specialized sub-frameworks for interoperable elements, recognizing that

a single framework will not address every need.”

• The European Interoperability Framework (EIF) developed to support the networking of the

European national agencies under the umbrella of shared EU provisions [Ref 2], states that it is

within the context of a political agreement, “an agreed approach to interoperability for

organisations that wish to work together towards the joint delivery of services. It specifies a set of

common elements such as vocabulary, concepts, principles, policies, guidelines, recommendations,

standards, specifications and practices.” The EIF appears as a grouping of frameworks aimed at

ensuring that all interoperability concerns are covered in an orderly way. Furthermore, it ensures a

complete approach needed to achieve and maintain interoperability, including governance and

management concerns.

Notably, both the NIF and EIF position an interoperability framework as a grouping of frameworks

scaffolding artefacts relevant to specific interoperability concerns. Specifically, the EIF suggests the

following top-level types of interoperability concerns:

• Legal.

• Organisational.

• Semantic.

• Technical.

The NIF, being more implementation driven, does not stress the legal and organisational levels, but

significantly proposes net-centric (i.e. service orientation) aspects to be considered as a separate top level

concern on a par with semantics and technology.

When stakeholders decide to interoperate based on stated and planned objectives, it is evident that, given

the multiple interoperability concerns to be managed, it requires a common interoperability framework to

organise work. An interoperability framework is therefore established early in the process so that all

stakeholders can relate to the different aspects to be discussed and agreed. In doing so the framework is a

key support aid for stakeholders to manage and use interoperability resources together, whilst evolving to

the ultimate goal of interoperability.

5 04-12-14

An important first step in achieving global interoperability is the ICAO ATMRPP “SWIM Concept”.

The ICAO ATMRPP “SWIM Concept” document describes a layered framework whereby it is stated: “The

layers of the framework are used to explain the functions, the combination of representative standards and

the mechanisms for interoperability.”

The layers of the framework comprise:

• SWIM enabled applications.

• Information Exchange Services.

• Information Exchange Models.

• SWIM Infrastructure.

• Network Connectivity.

The cited document further explains that “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.”, and summarizes that “The SWIM Global Interoperability Framework

describes a layered framework enabling further discussion on how interoperability between SWIM-enabled

applications will be achieved in practice.”

The ATMRPP SWIM Concept focusses on the implementation aspects of interoperability. The IGIF

presented in this paper widens the scope to include other essential aspects.

3 ICAO Global Interoperability Framework (IGIF)

3.1 Definition, use and benefits

3.1.1 What is the IGIF?

The IGIF is a description of the essential components that need to be shared and considered by all the

involved stakeholders in order to effectively achieve global aviation interoperability. It identifies the areas

in which interoperability agreements need to be reached. For this purpose it provides a logical structure

that serves as a classification and organisation of interoperability artefacts. This is necessary for the

establishment of SWIM as the enabler of aviation interoperability.

The IGIF covers the full scope of interoperability standardisation aspects to be considered. The IGIF

endorses the SWIM principles for ATM [Ref 1, Ref 5] and is focused on supporting interoperability of global

information services during all phases of flight: planning, execution and post-operations.

The IGIF covers the provision of information services as described in the Global Air Traffic Management

Operational Concept (Doc 9854, section 2.9). However it should also operate as the overarching framework

to ensure that interoperability is made possible for all the information exchanges currently required or

foreseen by ICAO provisions supporting ATM operations across all Data Domains. This includes the existing

data domains such as AIS, MET and ‘Flight’. [Ref 13]

3.1.2 Use of the IGIF

The IGIF is used as a supporting aid for the governance and management of SWIM resources such as

standards (e.g. technical specifications) and the provision of guidance materials.

6 04-12-14

3.1.3 Benefits of the IGIF

Today, it is possible to implement SWIM-style solutions as demonstrated by events such as the SESAR

SWIM Master class [Ref 9], SWIM exercise in FAA NextGen Mini-Global [Ref 10] and other R&D results. At

the technical level most of the obstacles are currently resolved or at least in a sufficient technical state to

start considering initial deployment [Ref 6, Ref 7, Ref 17].

However the scope of deploying SWIM involves not only technical aspects, but also essential elements

such as:

• Overall governance & steering.

• Standardisation and related planning.

• Implementation coordination (e.g. support to the implementation of the ASBUs).

• Policies.

These business oriented considerations should be an integral part of the overall interoperability goals of

SWIM.

The IGIF brings together the business and technical aspects into a bigger commonly agreed structure that

will support the governance and management of interoperability as a whole and promote stakeholder buy-

in. If the governance and management of SWIM is not sufficiently addressed it will negatively impact the

deployment and interoperability of SWIM services.

3.2 IGIF structure

The structure of the IGIF is depicted in Figure 1 below and further described in the sections hereafter:

Figure 1, ICAO Global Interoperability Framework (IGIF)

3.2.1 Legal Framework

As a minimum, the legal framework should contain the required converging legal elements necessary to

perform actual information exchange using SWIM. The use of the legal framework should lead to

sufficiently “aligned legislations” in support of lawful information exchange. This could further lead to

provide “rules of engagement” between SWIM stakeholders. For example, it should be clear for service

7 04-12-14

providers and service consumers what the applicable digital rights are when an actual information

exchange is performed via information service interactions.

The legal framework should include the provisions in the relevant ICAO Annexes for States to ensure a

regulated interoperable information exchange. These provisions should be prescribed within the State

territory in the form of State obligations to ensure that a State will make the appropriate arrangements to

manage all aspects of globally binding transactions between the various globally operating service

providers and consumers. These so-called Authority (State) related requirements for SWIM should be the

minimum set of formal principles States shall commit to and should be flexible in order to allow more

principles to be added when States decide to agree on a bilateral basis on specifically agreed information

exchanges.

Note: Consideration should be given at a later stage if the envisaged provisions should be included in

existing Annexes that deal with the provision, consumption, or both, of information or if this should be part

of an integrally applicable ‘SWIM-Annex’.

3.2.2 Organisational (Process) Framework

As a minimum, the organisational framework should contain the required converging organisational

elements necessary to perform actual information exchange using SWIM. The use of the organisational

framework should lead to sufficiently “aligned organisations” based on appropriate process alignment.

Coordinated and standardised processes enable SWIM responsible authorities as well as stakeholders to

work together based on sufficiently aligned processes (e.g. change management process).

The organisational framework should be instantiated by agreeing on the required organisational

alignments to ensure that service providers and service consumers achieve the envisaged global

interoperability. It may be required to instantiate provisions in the relevant ICAO Annexes to ensure the

desired organisational and process alignment.

The organisational framework may be supported by instruments such as Memoranda of Understanding

(MoUs), policies, and the definition of common key performance indicators.

Note: Consideration should be given at a later stage if the envisaged provisions should be included in

existing Annexes that deal with the provision, consumption, or both, of information or if this should be part

of an integrally applicable ‘SWIM-Annex’.

3.2.3 Semantic Framework

As a minimum, the semantic framework should contain the required converging information related

elements necessary to perform meaningful information exchange using SWIM. The defined and precise

meaning of exchanged information is to be preserved and understood by all SWIM stakeholders as they

use services to interoperate. As a result blocking factors due to information definition misalignments are

alleviated. Semantic interoperability is therefore a key asset, cost saver and potential safety related topic.

The semantic framework enables new interoperable services to be identified, designed and implemented

based on the Services Framework, thus enabling the bundling of information into meaningful messages.

The reason for this separation is that the same atomic information may be bundled into different

information exchange services. A key component of the Semantic Framework is the ICAO AIRM which is

further discussed in [Ref 11]. Other parts are the rulebook, the standards baseline and the manual.

8 04-12-14

Note: From an ICAO provisioning perspective, the ICAO AIRM is a technical specification referenced by the

relevant Annexes. For governance aspects of the ICAO AIRM see also [Ref 4].

3.2.4 Technical Framework

As a minimum, the technical framework should contain the required converging technology related

elements necessary to perform actual information exchange using SWIM. The technical framework is a key

asset in relation to the implementation of SWIM services. It should lead to acceptable technology

standards and their combination into reusable configurations. In addition, other technical elements (e.g.

testing, integration process validation concepts, namespaces, unique identification principles, syntax)

would also be placed here.

The ICAO ATMRPP SWIM Concept document [Ref 1] presents a layered technical “SWIM Global

Interoperability framework”, as depicted in Figure 2 below. According to the ICAO SWIM Concept, the

scope of SWIM is defined by the three middle layers (i.e., Information Exchange Services, Information

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

Figure 2, ICAO ATMRPP SWIM Global Interoperability Framework

The ATMRPP SWIM GIF is solution oriented and contains examples of actual standards. For example the

depicted Exchange Models can be put in relation to the ICAO Semantic Framework and the ICAO AIRM [Ref

11] as the relevant reference element provided by the IGIF. Hence the ICAO AIRM, as a reference semantic

artefact, is positioned as a governance instrument.

3.2.5 Services Framework

The services framework is at the heart of SWIM. As a minimum, the services framework should contain the

required converging service related elements necessary to perform and implement actual information

exchange using SWIM. For example it is required to be able to exchange in a meaningful way the service

definitions. If hindered this may lead to service definition misalignments.

An initial development in this area is the Service Description Conceptual Model (SDCM) provided under the

umbrella of the EU/US CP2.1 collaboration [Ref 12]. As stated within the SDCM 1.0 web resource, “The

Service Description Conceptual Model (SDCM) provides a graphical and lexical representation of the

properties, structure, and interrelationships of all service metadata elements, collectively known as a

Service Description.” The use of the SDCM enables common understanding of service definitions and thus

promotes the interoperability of service descriptions and their exchange between registries.

9 04-12-14

Note: from an ICAO provisioning perspective, an ICAO SDCM is a technical specification referenced by the

relevant Annexes. The cited SDCM is in fact a semantic resource but due to the evident prominence of

services in the context of SWIM, it is put in the dedicated Services Framework.

The services framework also includes clearly defined relationships between SWIM service providers and

service consumers, the formalisation of which is supported by instruments such as Service Level

Agreements (SLAs).

Within SWIM it should be clear that information will spread quickly; hence this is also true for errors the

data may contain. The performance expectations of services are captured as non-functional requirements

(NFR). One aspect herein is the quality of the data exchanged. This shall allow providers and consumers to

mutually understand the quality of the data exchanged. This may then further lead to potential

implications on intended use of the data. (E.g. an example is the use of aerodrome mapping data that

meets the 5m accuracy quality class intended for “situational awareness” applications. More stringent

applications such as for navigation purposes will require more accuracy.) Typically the quality measures

such as for accuracy are exchanged as part of the metadata that are related to the exchanged data.

Another element of the service framework is the definition of means and methods to assess that a given

service implementation implements information exchanges in line with the business needs, thus ensuring

that SWIM services are traced to stated business needs within an operational context. In line with the SOA

principles, the Services Framework can therefore be considered as a bridge between the ATM business

driven “upper” layers of the IGIF, and the underlying Technical Framework.

3.2.6 Security Framework

The Security Framework defines the security aspects that must be met by the other frameworks within the

IGIF. What security actually means in the context of ATM is further explained by ICAO Doc 9985.

ICAO Doc 9985 [Ref 16], Air Traffic Management – Security Manual, chapter 5 about information and

communication technology (ICT) system security (including cybersecurity) states that: “ICT security refers

to the application of security controls to protect ATM ICT systems against the degradation of integrity,

confidentiality and availability from intentional or accidental causes. The ATM ICT system security applies

to people, procedures, data, software, and hardware that are used to gather and analyse digital and

analogue information used in ATM.”

Furthermore, ICAO Doc 9985, Appendix B cybersecurity in ICT security, explains that:

“Integrity is a security objective that ensures information and systems are not modified improperly or

accidently. When integrity is compromised, information may be modified or destroyed. Confidentiality is a

security objective that ensures information is not disclosed to unauthorized entities. When confidentiality is

compromised, the unauthorized disclosure of information may occur. Confidentiality is often provided by

encrypting data that is in transit or stored. Availability is a security objective that ensures the reliability and

accessibility of data, services, and resources to authorized entities in a timely manner. When availability is

compromised, the system may experience a temporary service disruption or a complete loss of service.”

It is not the intent in this white paper to further elaborate the security framework as this shall be delegated

to the appropriate experts1.

1 A good further reading is the ITU-T document Security in Telecommunications and Information Technology – An overview of

issues and the deployment of existing ITO-T Recommendations for secure telecommunications.

10 04-12-14

3.3 Global interoperability governance & management

3.3.1 Interoperability, complexity and cost

The interoperability envisaged by SWIM requires standards to be agreed at the global, regional and local

levels. It is fair to assume that not all information needs to be exchanged amongst all in a highly

interoperable way at all levels. The operational context plays an important role in sub setting the scope of

the required interoperability, thus the need to delineate precisely the problem/solution space.

Furthermore, since levels of interoperability are correlated with levels of complexity (see Figure 3) it is

good practice to consider requiring interoperability only where needed (within an identified context) and

with the right level of complexity.

Figure 3: Scale of interoperability, complexity and cost [Ref 15]

3.3.2 Performance-based approach to global interoperability

This paper does not intend to explore governance matters, yet to understand the nature of the IGIF some

essential regulatory approaches are brought forward here:

• Prescriptive approach (sometimes referred to as design-based).

• Performance-based approach.

When performance-based, a rule incorporates its goal into the language of the rule, specifying the desired

level of performance and allowing the implementers to decide how to achieve the objectives stated.

Therefore the performance goals are defined in the rule rather than specifying behaviour. In contrast, a

prescriptive rule uses or references design standards or technology-based standards that specify exactly

how to achieve compliance; a performance standard sets a general goal and lets each regulated entity

decide how to meet it. An easy way to think of the difference is to think of the performance-based

approach as to specifying “what” is required whereas the prescriptive approach includes “how” elements,

thus rather being part of the solution space. Yet in reality, a combination of prescriptive and performance

based regulatory elements are present at different degrees in almost all rules.

To perform SWIM, i.e. to perform interoperable information exchange, in a well-managed global context

supported by standardisation, it is of paramount importance to set-up good governance and effective

management. The previous section discussed the IGIF as a grouping of frameworks. From a governance

point of view this means that the IGIF tends to be “performance based”, meaning that it defines the

“what” of interoperability and avoids the “how”. This facilitates the agreement building required to deploy

SWIM. The global interoperability governance defines the IGIF, whereas the global interoperability

management layer configures and manages the standards that meet the IGIF requirements. Consequently

global interoperability management works on a more regular basis (e.g. executing change control work) in

11 04-12-14

accordance with the expectations defined by global interoperability governance. Both aspects are pre-

requisites for the deployment of globally interoperable SWIM services and further discussed hereafter.

3.3.3 Global Interoperability Governance

To achieve global interoperability within a defined scope and based on SWIM it is essential to have a high

level agreement, approvals, and decisions based on agreed guiding statements provided by:

• An Interoperability Strategy.

• High Level Interoperability Principles & SWIM Concept.

This governance could be hosted in the ICAO IM Panel (IMP) which will start its activities in 2015. The IMP

would thus act as the owner of the IGIF and providing guidance towards the implementation of the globally

interoperable SWIM, including the management aspects thereof. Based on the high level documents the

IGIF is established and owned by the IMP.

3.3.4 Global Interoperability Management

In addition to the high-level agreements and the IGIF defined by the ICAO IM Panel (IMP), it should be

envisaged to delegate the required interoperability management aspects to a management board (to be

nominated) and acting as an “executive” reporting to the “council” (the IMP).

The mission of the management board would be to perform within the global context of ICAO:

• Change control management.

• Configuration management.

• SWIM standardisation planning.

The main tool used by the management board would be the registry as further described in the next

section.

3.3.5 Supporting implementation concepts

3.3.5.1 SWIM Configurations

In relation to a stated interoperability context, a SWIM Configuration (SC) consists of a consistent grouping

of SWIM standards and guidance documents.

A SC allows implementing a declared version of SWIM and thus it enables the building of global

interoperable SWIM services, whereby stakeholders who adhere to a particular version of a SC will be in an

interoperable state (i.e. being able to provide and consume SWIM services in an interoperable way).

Using a SC a solution provider builds solutions for SWIM stakeholders who aim to interoperate based on

the declared SC standards and guidance materials. A SC will thus be a consistent grouping of standards

with a particular version and be self-sufficient towards a solution provider that implements globally

interoperable SWIM solutions and a SWIM service consumer that wishes to consume these services.

It is to be noted that the IGIF is a unique reference whereas a SC may appear under different versions.

3.3.5.2 Role & Purpose of Registry

As stated in the SWIM Common Registry white paper [Ref 8] “it aims to improve visibility to consolidated

information on assets of common interest to a group of SWIM communities. This includes an inventory of

12 04-12-14

shared services, stakeholders (e.g. service providers), and news related to events of common interest. It also

supports the collaborative management of those interoperability resources (e.g. standards) that have been

selected to ensure interoperability in the implementation of SWIM between the various communities.”

The intent of this paper is not to further elaborate on registry related matters. Yet it is clear that the

envisaged common registry plays an important role. Indeed, as it supports the collaborative management

of interoperability artefacts, the registry can be seen as a management tool that publishes information

about SWIM artefacts. For example standards could be easily tagged with metadata tags that bring them in

context of a specific SC. It should also be clear that the content of the registries should be made

interoperable in terms of data exchange (e.g. this will enable the harvesting of shared registry content

between registries).

3.4 IGIF in relation to regional and local levels

An essential interoperability principle is that “not one size fits all”, as explained in the section above. This

means that different solutions can be implemented to reflect different technical requirements. However,

this principle can be taken further: different regions and States may enforce different regulations. Indeed,

they may take the regulations within an ICAO Annex and add additional regulations. Furthermore, it must

also be recognised that the footprint of the data to be exchanged differs between regions and States. In

addition, the local regulations may cover a larger footprint than at a global level as the needs become

more specific.

Therefore, it can be assumed that the demands placed on global interoperability will be different from

those placed on regional or national interoperability.

Given this, three geographical scopes should be recognised within the IGIF:

• Global interoperability.

• Regional interoperability.

• Local interoperability.

The aspects that need to be addressed to achieve an interoperable information exchange are the same

whether interoperability is at the global, regional or local level. This is a key insight which allows the IGIF

structural pattern to be repeated at the regional and local levels. This is depicted in Figure 4 below.

13 04-12-14

Figure 4, Interoperability Framework pattern at global, regional and local levels

Figure 4 shows how the IGIF, at the top of the pyramid, is further refined at the regional and local level.

However, these, in turn, can be seen as conforming to the IGIF.

Note: in a similar spirit, the SWIM concept introduces the notion of a SWIM Region [Ref 1]:

“A SWIM Region will be delimited by the area of influence of a given governance structure (i.e. the

governance structure which defines the standards, the policies, etc. that are applicable to all the enterprises

within the region). Within a SWIM Region, a collection of enterprises, for example ASPs or AUs, may choose

to inter-operate using standards established for that particular SWIM Region.”

A SWIM region may exist at the regional or even the local level. Hence the Interoperability Framework

pattern of Fig. 4 applies to the interoperability provisions both within a SWIM region and between SWIM

regions.

Global standards are produced by organisations working together. Frequently these organisations will have

a regional if not a global geographical footprint (e.g. ISO, EUROCAE, RTCA, ARINC, IATA, WMO). In some

cases, the standardisation effort will involve the participation of ICAO.

To complete the discussion on the different geographical scopes, it is important to note that in order to

achieve a cost effective deployment of SWIM, it will require organisations to act at a local and regional

level to also think about the global level. To achieve this, stakeholders should:

• Where feasible and opportune, build consensus around the necessary global standards.

• Submit elements which have global support to the level of ICAO.

14 04-12-14

4 Recommendations This paper recommends that:

• Work should be started on an ICAO Global Interoperability Framework (IGIF) as a continuation of

the ICAO ATMRPP SWIM Concept.

• The elaboration of the IGIF should be done using an iterative approach starting with the Semantic

Framework, the Services Framework and registry, using a performance-based approach.

• All the concerns targeted by the IGIF should be addressed by appropriate working groups with the

right expertise levels.

• The IGIF should be used at the global, regional and local levels to globally agree on SWIM and

manage the collaborative deployment of SWIM.

• Governance and management of the IGIF should be established early in the process.

5 Summary This paper introduced the notion of an ICAO Global Interoperability Framework (IGIF) as a grouping of

frameworks in support of SWIM interoperability, governance and management.

6 Contributors Name Organisation

Michael Burski FAA

Barbara L Cordell FAA

Joe Gorman NATMIG

Dennis Hart Eurocontrol

Stefan Keller DFS

Allen Perper FAA/BAH

Dennis Hart FAA

Robert Suzić Eurocontrol

Diana Takata FAA

Sam Van der Stricht Eurocontrol

Katrina Wilson FAA

Scott Wilson Eurocontrol