Flight Data Object Dissemination (FDOD) Capability Pattern€¦ · Flight Data Object Dissemination...

Aviation IPT

Flight Data Object

Dissemination Capability Pattern

Approved for public release NCOIC FDOD Patt 20120330 v 2.1 Version 2.1-2012-03-30 1 / 48

Flight Data Object Dissemination (FDOD) Capability Pattern

Anton Walsdorf, Airbus S.A.S

Eric Helfers, North Star, Incorporated

Chet Ratcliffe, EADS

Jerry Sonnenberg, Harris Corporation

Al Secen, Lockheed Martin

Mary-Ellen Miller, Mosaic ATM, Inc.

Emile-Henri Balland, Thales

Mikael Laby, Cassidian

Allen Jones, The Boeing Company

30 March 2012

Abstract: A performance based Air Traffic Management (ATM) system can only be realized using performance based information management. The sharing of information of the required quality and timeliness in a secure environment is key to the Global ATM concept. The current ATM system is fragmented, with aircraft having limited data link capabilities. This pattern describes system wide information management dedicated to Flight Data Object Dissemination, where the ATM network is considered as a series of nodes (including the aircraft and the airspace users) providing or consuming information. The data object scope extends to all information of potential interest to ATM including trajectories, surveillance data, and aeronautical information of all types

Version History (Version Number) Description Author

100202 NCOIC_Pattern_FOD.doc Final Harmonization of the ATM Information Reference Mode

Eric Helfers, Anton Walsdorf

100126 NCOIC_Pattern_FOD.doc (Draft) Incorporation of comments of the CyberSecurity WG

Anton Walsdorf, Jerry Sonnenberg Chet Ratcliffe

100106 NCOIC_Pattern_FOD.doc (Draft) This is the consolidation of the 2009 changes as a result of Aviation IPT and Services WG joint work at the September 2009 Plenary meeting

Anton Walsdorf, Jerry Sonnenberg

100106 NCOIC_Pattern_FOD_Capability.doc Updated for standard format, additional detail

Jerry Sonnenberg

100107 NCOIC_FDOD_Capability_Pattern.doc Clean version to start group edits. Includes hyperlinks to lexicon elements

Jerry Sonnenberg

111223 NCOIC_FDOD_Capability_Pattern v1.4 Added Air to Air Dissemination, minor fixes

Allen Jones

120220 NCOIC_FDOD_Capability Pattern v1.6.1 Incorporated changes from Formal Review

Allen Jones

120330 NCOIC_FDOD_Capability Pattern v1.6.2 Minor changes prior to publication as v2.1

Allen Jones

120414 NCOIC FDOD Capability Pattern v2.1 Publish as v 2.1 Carl Schwab

Aviation IPT

Flight Data Object



Table of Contents

1 INTRODUCTION AND PROBLEM DESCRIPTION 3

1.1 PROBLEM 5 1.2 EXPECTED BENEFITS 7

2 RECOMMENDED SOLUTION 8

2.1 ACTORS 9 2.2 INTERFACES 11 2.3 PRE-CONDITIONS 11 2.4 STRUCTURE 12 2.4.1 SYSTEM WIDE INFORMATION MANAGEMENT (SWIM) 12 2.4.2 FLIGHT INFORMATION 15 2.4.3 CIVIL-MILITARY COORDINATION 15 2.4.4 ARCHITECTURE 16 2.4.5 COMPONENTS 23 2.5 BEHAVIOR 24 2.5.1 INTRA SWIM DISSEMINATION 26 2.5.2 INTER SWIM DISSEMINATION 27 2.5.3 SWIM TO NON SWIM DISSEMINATION 28 2.6 POST-CONDITIONS 29

3 ADDITIONAL INFORMATION 30

3.1 LESSONS LEARNED 30 3.2 CURRENT MODELING ACTIVITIES 31 3.3 RELATED & ASSOCIATED PATTERNS 31 3.3.1 RELATED PATTERNS 31 3.3.2 ASSOCIATED PATTERNS 33 3.4 DISSEMINATION IMPLEMENTATION GUIDANCE 34

4 VERIFICATION & CONFORMANCE 36

5 APPENDICES 43

5.1 REFERENCES 43 5.2 ACRONYMS 44 5.3 DEFINITIONS 45

Aviation IPT

Flight Data Object



1 Introduction and Problem Description The International Civil Aviation Organization (ICAO) Global Air Traffic Management (ATM) Operational Concept requires new air and ground capabilities and automation. Both Single European Sky ATM Research (SESAR) and the Federal Aviation Administration (FAA) Next Generation ATM System (NextGen) have summarized these requirements as a series of ATM Capabilities and Services. The Four Dimensional (4D) - Business / Mission Trajectory is at the core of the concept of operations, starting from the early business development stage up to post-operations activities. This trajectory represents the elementary object describing a flight, and thus the airspace user’s intention. To support activities linked to ATM planning, collaborative decision making processes and finally tactical operations, the Business/Mission trajectory will be shared by the ATM stakeholders and continuously refined based on the latest and most accurate data. In correlation with various ATM phases, the Business / Mission Trajectory lifecycle ensures the trajectory’s refinement until the complete execution of the flight as depicted in Figure 1. Over the lifecycle of the Business / Mission Trajectory, additional precision is applied and checked against constraints at each phase of the lifecycle. Initially the trajectory is checked against many other trajectories as they relate to limits of the airspace. As the flight progresses, the degree of fidelity is increased until, for separation, pair wise conflict avoidance is ensured.

Figure 1 -Lifecycle of the Business/Mission Trajectory (Ref [1], page 18)

The information to be exchanged needs to be modeled explicitly, to allow agreement on a precise and concrete definition. The information in the flight object including the Business / Mission trajectory must be exchanged among the various ATM systems and available to all (authorized) stakeholders. In addition, the method used for disseminating this information is System Wide Information Management (SWIM). SWIM manages standardized information and provides services needed to disseminate this standardized information.

NextGen and SESAR both plan to use SWIM for managing and disseminating the necessary shared ATM information. The SWIM services as proposed by SESAR will be organized around 6 data domains, as presented in Figure 2.

Aviation IPT

Flight Data Object



Figure 2 – SWIM Service Data Domains: (Ref [1], page 36)

Figure 3 – NextGen ATM Management Services (Ref [4], page 2-2)

Dividing the problem into specific domains has the advantages of keeping the activities at a manageable size, allowing requirements (e.g. performance or integrity) to be tailored to match the characteristics of the information. However this approach could lead to an inconsistent set of models since, in practice, the models are not completely independent. To address this problem, an overall ATM Information Reference Model is required to define the semantics of the ATM information to be shared. This model forms the master definition, subsets used in lower level models supporting interoperability for data-sharing domains. These domains are then implemented by services as shown in Figure 3. The Flight object, including the 4D Business / Mission trajectory, is contained in the Flight Plan Filing and Flight Data Management domain.

Aviation IPT

Flight Data Object



The ATM Information reference model provides a neutral (neutral meaning that the definition is domain agnostic and unambiguous for all the participants. An upper ontology could be used for that purpose, for instance DOLCE1) definition of the ATM information. It would contain well-known artifacts such as Aerodrome, ATS (Air Traffic System) route, Airspace, Flight Procedure, as well as a common definition of fundamental concepts such as geometry and time. It would be a key asset in the ATM System design and would sit above a set of domain specific platform independent models, which may overlap with each other, without being incompatible. The overall reference model and existing models will need to be reconciled.

Figure 4 combines the SESAR and NextGen views into an information reference model used as the basis of information elements within this pattern. This view contains 7 top level data service domains related to Air Traffic Management operations and 1 transversal data service domain to support management of safety and security services.

Figure 4 – Overall Information Reference Model for ATM: Source: NCOIC

1.1 Problem

The vision of a performance based ATM system can only be actualized with information required for performance management and flexibility to support performance driven changes. The Global ATM Operational Concept developed by the International Civil Aviation Organization (ICAO) has a larger set of data requirements than can be supported by the existing flight plan system. These include a secure architecture with trusted sharing of

1 DOLCE: a Descriptive Ontology for Linguistic and Cognitive Engineering

Aviation IPT

Flight Data Object



information system-wide, providing early intent data, management by trajectory, collaborative decision making, and high automation support requiring machine readability and unambiguous definition of information items.

The present-day flight planning provisions suffer from important limitations:

• Sharing Flight Information: currently, the means for sharing flight plan information among service providers and between service providers and airspace users rely on multiple two-party message exchanges. These exchanges do not provide the actual trajectory or associated business interest information, only the intended route, requested altitude and estimated time. In addition, each system uses its own definitions and encoding of the information which makes sharing the flight plan information difficult or impossible.

• Advanced Notification: currently, intention of flight is supplied in different ways for different systems. AOG lists intended scheduled flights month in advance while flight plans are filed 10s of hours in advance of a flight. Another limiting aspect of existing advance information is that some information is currently only communicated to service providers when voice contact is established with the appropriate unit. These limitations make organizing and planning for air traffic difficult and inefficient. Standardized information would allow efficient use of air traffic capacity and the aircraft involved.

• Inconsistent Flight Information: currently, determining the status or version of a flight plan requires reception and correct processing of the original flight plan and all subsequent modification messages. In addition, duplicate flight numbers can exist when a direct flight has an intermediate stop then continues to the final destination. There needs to be another piece of information added to make it unique, such as departure point. Sometimes there can be more than one version of the flight plan sent. Different systems processing the information differently lead to even more ambiguity.

• Information Distribution: the original method of information distribution for a flight plan was by lodging a paper flight plan at an Air Traffic Service Reporting Office for dissemination to relevant service providers. This was largely conducted through a system of peer-to-peer communications using protocols developed for teletype machines.

• Information Security: whether for commercial privacy sensitivity or aviation security purposes, there is a critical need for increased information security. Flight plans, modification messages, passenger and crew information, control system messages, management info, etc. must be protected from interception and/or modification enroute. Secure protocols with encryption and authentication of senders/receivers are paramount. A secure robust architecture to include boundary protection, intrusion detection, encryption and authentication must be incorporated. Additional protection and monitoring of data at rest should also be incorporated to ensure data integrity.

• Flexible Information Set: attempts to accommodate changing information needs at global, regional, and state levels have resulted in inefficient use of the flight plan.

Aviation IPT

Flight Data Object



There needs to be flexibility so that new data elements can be included and information no longer relevant deleted or not used.

• Derivable Information: The ICAO Global ATM Operational Concept articulates a vision for an information management system that ensures not only the integrity and consistency of information, but eliminates the need for re-entry if the data are already available to the ATM system. The current flight plan contains multiple instances of information that can be derived from other information elements.

To overcome these deficiencies and achieve a performance-based, secured seamless and global interoperable ATM system, a net-centric and secure environment, based on a globally consistent and unambiguous set of information elements, is needed.

1.2 Expected Benefits

The notion of a performance-based air navigation system emanated from good industry practices that have evolved over many years outside of aviation with the following expected benefits:

• Improving the effectiveness of the day-to-day economic management of Aviation

• Channeling efforts towards meeting stakeholder expectations as well as improving customer satisfaction

• Managing change in a dynamic environment

Flight and flow information in globally exchangeable formats in a collaborative environment are key for a performance based air navigation system. Flight plan information and associated trajectories are the principal mechanism through which ATM services of the air navigation system (e.g. separation of air traffic for safety) can meet day-to day operational performance.

Use of this pattern will allow the participants to meet the SESAR and NextGen key objectives with regard to the management of flight information by standardizing both the content of the flight object and the methods or sharing and refining the flight object among the global ATM stakeholders. Additionally, simplification of connectivity functions and gain on saving multiple connection infrastructures is a beneficial result of employing this flight object dissemination pattern. Patterns, as defined in the NCOIC pattern guide, help to standardize the methods of sharing information.

Aviation IPT

Flight Data Object



2 Recommended Solution Both the Single European Sky ATM Research (SESAR) and the US FAA Next

Generation (NextGen) efforts are aligned on key objectives with regard to the management of flight information:

• Information must be shared securely on a system-wide basis

• Pertinent information will be available when and where it is required

• Information may be personalized, filtered, and accessed, as needed.

• The system will include all tenets of Cybersecurity to include confidentiality, integrity, availability and protection of data, networks and control systems, continuity of operations and secure interoperable communications.

• Authentication for user access will be incorporated

• Initial quality of the information will be the responsibility of the originator; subsequent handling will not compromise its quality

• Information sharing can be adjusted to mitigate any proprietary concerns

• Information management will use globally harmonized information attributes

Implementation of these key objectives result in an ATM system architecture concept, based upon SWIM and the integration of the air and ground segment.

SWIM must insure dissemination of information in and outside of its borders, towards other system wide information and legacy systems. Just as today’s ATC system is composed of multiple regions, SWIM will be implemented piecewise such as within geographic, national or ATC administrative SWIM regions. The following cases of dissemination are identified:

1. Dissemination of flight object data between Air to Ground

2. Dissemination of flight object data between Ground to Ground

3. Dissemination of flight object data between Air to Air

4. Dissemination of flight object data inside the same SWIM region,

5. Dissemination of flight object data across regional SWIM instances

6. Dissemination of flight object data between a SWIM region and non-SWIM region. (This will be a transition case to be addressed separately.)

Dissemination cases one, two and three are independent of implementation and geography. Cases four, five and six overlay the first 3 cases and show transformation issues. The time

Aviation IPT

Flight Data Object



dimension also crosses all 6 cases and is addressed in the concept of Business trajectory planning, where all phases from strategic to tactical are defined.

To better understand the dissemination complexity and needs illustrating the cases described above, imagine the following operational scenario: an aircraft from a company with an Airline Operation Center in Germany, takes off from Washington, DC, goes through Canada and Norway and lands in Paris. This scenario illustrates the cases of air to ground, ground-to-ground exchanges between two SWIM regions (SESAR/NextGen Interoperability). The Civil-Military coordination could be considered as another dimension to these cases or as an equivalent to a SWIM region to SWIM region connectivity. Other operational scenarios will highlight the cases of regions, which have not deployed SWIM infrastructure.

NextGen and SESAR by their nature will cover the first 3 cases (Air to Ground, Ground to Ground and Air to Air) inside a single SWIM region but have difficulties providing clear solutions for the other cases (Enterprise centric behavior). This pattern is then providing a global picture using NextGen and SESAR advanced concepts to support an overall ATM Network Centric Ecosystem. This pattern, with the support of principles contained within the Net-Centric Services Framework, yields guidance described in later paragraphs. This pattern provides the basis for an ATM system architecture based on a Service Oriented Architecture with strong dissemination solution and key recommendation for these cases.

2.1 Actors

A future collaborative, secure and dynamic flight information process requires the interaction of multiple participants in the ATM community. This list of participants is significantly extended from the present day flight planning process as the process described herein begins at least a year prior to departure and extends until the flight plan has been closed. Figure 5 is a graphical representation of the participants/actors.

Aviation IPT

Flight Data Object



Figure 5: Participants / Stakeholders (Ref [1], page 33)

The following description for some of the participants follows: Aircraft and AOC ATM: The term airspace users refer to the organizations operating aircraft and their pilots. Airspace users include the flight operations centers responsible for the strategic planning of a flight and the entity responsible for the execution of a flight that is traditionally a flight deck.

Aerodrome ATC: Participating aerodrome operators include the operators of the departure, arrival, alternate, and any other airports requiring or providing information for planning purposes.

Air Navigation Service Providers: There are many ATM services provided to an airspace user from the earliest strategic planning through completion of a flight. Entities providing service or potentially providing service to an airspace user can require or provide information. These include the Air Navigation Service Provider (ANSP) within which the flight departs, transits or arrives, in addition to an ANSP where the flight is expected to transit an area of interest.

Airspace Provider: Flights transiting through airspace may require permission from an airspace provider. These flights are traditionally the responsibility of contracting nations.

Emergency Service Providers: Supporting the provision of emergency services in the event of such an occurrence.

Military: Military aviation, being an integral part of the defense / security forces, remains an important and essential user of airspace and as a result, an important stakeholder in Air Traffic Management.

Aviation IPT

Flight Data Object



2.2 Interfaces

The interfaces among the actors illustrated in Figure 5 inherit attributes of the generic Net-Centric Services within a service-oriented architecture. These attributes and the interrelationships of the service attributes are documented in the NCOIC Net-Centric Services Framework (NCSF). A key principle is the Service Interface principle described in Section 3.1.2 of the NCSF.

The service interface implements the contract between the consumer and provider. The service interface is a published set of service operations, along with the contract relationship between the service interface and its provider/consumer. The service interface offers the capabilities of the service. The service contract represents an agreement between the service provider and the service consumer. This contract allows an exchange of information even if they are members of different systems. The service interface is responsible for implementation details that perform this exchange. Additional detail is available in the NCSF.

The interfaces have two distinct natures:

• Interfaces at the OSI application layer, considering domain and technical interactions (management, statistics, recording, etc.)

• Interfaces at the OSI presentation layer for the sub-systems with interfaces with humans to harmonize principles of presentation and interaction (to the operator)

2.3 Pre-Conditions2

The sharing of information of the required quality and timeliness in a secure and trusted environment is a key enabler to the Global ATM concept. The current system is fragmented, with point-to-point communications and the aircraft is only connected by voice Receive/Transmit and very limited data link capabilities. SWIM will provide an ATM network as a series of nodes providing or consuming information; this network includes the aircraft and air space users.

2 Pre-Conditions defined by NCOIC Interoperability Framework, NCOIC-NIFv2.1NSD-RM-20101110,

Aviation IPT

Flight Data Object



2.4 Structure

This section describes logical static elements supporting the understanding and implementation of this Net-Centric Pattern.3

2.4.1 System Wide Information Management (SWIM)

SWIM enables Collaborative Decision Making (CDM), having the following features:

• Integrates relevant ATM data

• Forms the basis for information management of the entire ATM system,

• Is indispensable for efficient operation of the ATM. Supports collaborative decision-making processes using efficient end-user applications to exploit the power of shared information.

The scope extends to all information that is of potential interest to ATM including trajectories, surveillance data, and aeronautical information of all types including NOTAMS and airspace information, and meteorological data. It provides other organizations information for a security incident where civil and military security forces need to collaborate. SWIM provides a multi-faceted and multi-disciplinary architecture, consisting of the following diverse elements, to achieve a fully integrated, seamless ATM system: ·

• Physical Elements

o SWIM network is an ATM network as a series of nodes providing or consuming information; this network includes the aircraft and air space users.

o SWIM infrastructure consists of common, standardized IT technical services

o Legacy and future ATM systems are aligned to this architecture and integrated to relevant SWIM Service Interfaces and corresponding ATM Data

• Architectural Elements

o ATM system wide enterprise architecture model, that defines a common view on ATM business processes, the logical system architecture and the physical system architecture that realize these business processes

o Standardized domain-level interfaces within a Service Oriented Architecture, enabling interoperability, for accessing SWIM ATM Data and ATM Services ·

• Operational Elements

3 NCOIC-NIFv2.1NSD-RM-20101110, Section A1.7, Table A 3-3

Aviation IPT

Flight Data Object



o Agreed service contract and data standards for performance, quality, safety, security and interoperability

o Standardized and agreed rules, roles and responsibilities

o A suitable governance framework

SWIM contributes to ATM Service Delivery Management. It integrates Air-Ground and Ground-Ground information sharing and provides value-added information management services. Collaboration is essential for bringing value added to information management services, because it allows the best combination of timely and accurate information to be used. Service Oriented Architecture is a paradigm that facilitates Information Sharing through use of loosely coupled software services supporting the ATM business process and ATM users. For CDM, both segments, Air and Ground must be interoperable.

2.4.1.1 Ground Segment Information Management

The technical systems of stakeholders participating in SWIM environments shall meet SWIM requirements. The requirements shall be provided by a set of common and standard SWIM services available to any stakeholder through the SWIM infrastructure, which will be made of the two following layers:

• The SWIM middleware: a set of standard IOP middleware services that will rely as much as possible on standard existing IT technologies;

• SWIM applications offers high-level services to ATM systems that shall either publish or subscribe to shared data under specific conditions, or request modification of shared data.

Following the OSI4 model, lower layers (i.e. physical to transport layers) will be provided through an infrastructure based on secure Internet protocols. Systems and services not in the scope (some military systems, meteorological data suppliers, others) will also have the possibility to interact with the SWIM services under SWIM rules and requirements for civil and military users.

2.4.1.2 Air to Ground Segment Information Management

The architecture shown in Figure 6 shall provide a means to manage the participation of the aircraft in the SWIM environment transparently taking into account the inherent constraints of the Air-ground Data link.

4 Open Systems Interconnection Model (OSI Model) from the International Organization for Standardization (ISO)

http://en.wikipedia.org/wiki/International_Organization_for_Standardization

http://en.wikipedia.org/wiki/International_Organization_for_Standardization

Aviation IPT

Flight Data Object



This is done through the introduction of an A/G Data link Ground Management System. It offers the aircraft a single point of access to the ground part of the SWIM architecture with filtering of the shared information that is needed by the aircraft and at the gate to update onboard databases. Benefits are expected through simplification of connectivity functions and

Figure 6 – Air-Ground Links participating in SWIM Systems (Ref [1], page 38)

gain on saving multiple connection infrastructures. A high availability of the A/G Data link Ground Management System is key, because a failure at sub-region level jeopardizes the primary data link communication with the aircraft in the sub-region and therefore at the intended ground nodes. Secure encrypted links prevent malicious or terrorist intent. So, the data link connection between aircraft and ground stations must be trusted and secure. When a functional architecture is instantiated, key performance parameters are defined, validated, and verified. Performance parameters are not included with precision in a functional pattern.

Aviation IPT

Flight Data Object



2.4.1.3 Air to Air Segment Information Management

Current Air-to-Air functions consist of Collision Avoidance Systems (CAS) automated advisories and company radio communication via voice. Air to air information management is a concept in its infancy, and is beginning to be implemented through the ADS-B in capability. Also, SWIM may replace Air-to-Air functions with Air to Ground to Air implementation if the projected efficiencies are realized, with the exception of CAS for safety considerations.

2.4.2 Flight Information The future ATM system shall have a top level ATM reference model that provides the definition of interoperable ATM Information. This model, constructed as a federation of models developed by communities of interest or domains, forms the master definition of ATM information. Some of these COI models are described in section 5.3. From this model, one or more reference architecture are derived that result in physically architectures that provide interoperability for data sharing. Such a data model shall consider all flight information. The flight information exchanged shall be structured explicitly to allow agreement on a precise and concrete definition. The model shall include currently used flight information elements and should be able to expand to accommodate future information needs. This flight information should be structured into related groups of data elements that include the following Flight Information:

• Aircraft Identifiers: This includes Flight Numbers, Tail Numbers, Equipment, Ownership/Operator and constraints such as weight and aircraft limitations. Typical formats are TBD.

• Search and Rescue (SAR): This consists of plans that include patterns, altitudes, communication plans, target descriptions, weather options, alternate airfields and similar items.

• Route Preferences: This includes primary and secondary route plans, letdown plans, weather options and alternate airfields

• Trajectory: this covers all phases of flight from taxi out, takeoff, cruise, decent and taxi to field location. It is a living document.

• Additional Information structure developed through Mediation between COIs.

2.4.3 Civil-Military Coordination Military aviation plays a vital role for security and defense. Military Air Operations differ from Civil Operations in terms of peak vs. average demands on the Air Environment, providing a different periodicity in loading. Therefore, coordination between civil and military authorities in a SWIM environment to accommodate increasing capacity demands shall be mandatory. This implies integrated civil-military air traffic control, air defense, and air security using SWIM infrastructure. To meet national security needs for military aircraft flying in national airspace without identification, an anonymous aircraft identification address concept shall be implemented. This concept should include unmanned vehicles.

Aviation IPT

Flight Data Object



2.4.4 Architecture

This ATM pattern is written in the SOA paradigm that the NCOIC recommends as providing a low risk, best Life Cycle Cost path to interoperability.

Figure 7 – ATM operations in a Service-oriented environment (Ref [1], page 39)

The proposed SWIM architecture depicted in Figure 7 illustrates how remote sub-systems will interact using the SWIM environment (Systems B and C access some data and/or services from system A through their respective Ground-Ground Interoperability sub-systems). In more detail, it shows the principles for the segregation between the domain systems and the SWIM layer. For the long-term, it is expected that existing IT products deliver fully or at least partially the SWIM middleware and application layers services. ATM specific services may have to be developed and added to the IT standards in order to provision the full SWIM services. Semantic mediation (not explicitly highlighted in the picture above) is key to meet the interoperability requirements of the various domains and regions involved in ATM. The SWIM infrastructure will be supervised at different levels. At the local level, the technical supervision will monitor and control the capabilities of the element of the system that constitutes the local contribution to the SWIM system. At the regional level, the SWIM supervision will provide the overall management (including guarantees that partnership principles are respected) and performance monitoring functionalities.

The description of interoperability services has focused on the provision or reception of shared information but it is expected that the SWIM infrastructure will also support any point-to-point exchanges and/or dialogues. The SWIM infrastructure will allow to set-up virtual

Aviation IPT

Flight Data Object



point-to-point connections whereas the physical network will remain the same one as when the publish/subscribe pattern is used.

The architecture needs to provide a secure and trusted information environment which enables all stakeholders to have suitably controlled access to a set of data describing the latest confirmed status and intentions of each flight which concerns them, with the level of:

• Accuracy, as the degree of veracity

• Availability, as the proportion of time a system is in a functioning condition

• Performance, in assuring the information

• Consistency, to exclude contradictions

Non-repudiation, through a service that provides proof of the integrity and origin of data and authentication, that with high assurance can be asserted to be genuine and that is necessary for their operations

2.4.4.1 Domain Dependant Logical and Technical Architecture The Domain layer is decomposed into 3 main areas shown in Figure 8, each of which contains several clusters:

• ATM Operations: contains the domain concepts specifically needed to support one part of ATM. Its decomposition can be seen in relationship with the ICAO Operational Concept ATM components.

• ATM Support: contains the CNS domain concepts

• ATM Shared Concepts: contains the domain concepts that are used by more than one kind of organization – they do not fit easily into a single ATM Operations or ATM Support cluster.

Figure 8 – ATM Operations, Support and Middleware components (Ref [1], page 33)

Aviation IPT

Flight Data Object



SWIM systems will be implemented through federation of various sub-systems, achieved by the provision of standardized flight information via standard interfaces and (network) infrastructure that provides the required quality of service.

Figure 9 and Figure 10 identify which sub-systems are:

• Users [–] - those that are the expected/likely users of the Service provided information; they are shown in grey color. They will get the updated information for which they have subscribed;

• Publishers [P] – those that are responsible for the Service of information provision for a certain information domain; they are shown in white with a symbol ‘P’;

• Contributors [–] - those that provide the contributor provisions to feed a main/focal point Publisher (where information originates in different/diverse stakeholders systems/sub-systems, these are the sub-systems in the local domains that provide these contributions); they are shown in white without the symbol ‘P’.

Figure 9 -Flight data Users, Publishers & Contributors grouped by domain (Ref [1], page 37)

Aviation IPT

Flight Data Object



Figure 10 -Flight data Users, Publishers and Contributors grouped by actor type

Figures 11 and 12 illustrate the logical and technical architectures of Air Operations utilizing services.

Figure 11 – Air Operations Logical Architecture (Ref [3], page 10)

Aviation IPT

Flight Data Object



Figure 12 – Air Operations Technical Architecture (Ref [3], page 11)

Both Logical and Technical Architecture are based on the following assumptions:

• Each Flight Data Processing System (FDPS) is associated to one single Flight Object Server (FOS).

• The interface between the FDPS and the FOS is not defined since the limit between both is only logical. Although conceptually the FDOs are stored and managed by FOSs, in fact no distinction is made between the functionality of the FOS and the functionality of the associated FDPS. So in effect the FOS could be considered as a part of the FDPS functionality.

• Logically a single Flight Object (FO) is maintained for each flight. However this single logical FO is physically distributed over a network of ‘FO Servers (FOS)’, each FOS being associated with a Flight Data Processing System (FDPS). Each FOS holds physical copies of the FOs of interest to its clients. The network of FOSs, not the clients, is responsible for ensuring that the different physical copies of the FO are kept consistent. For each flight at any one time a single FOS is responsible for maintaining the FO and publishing it to its clients and the other FOSs on the network. This responsibility for maintaining and publishing the FO is passed from FOS to FOS at the same time as the operational responsibility for the flight is passed from FDPS to FDPS as the flight progresses on its route.

• One FDPS may support one or more Air Traffic Service Units, for example an ACC and an APP unit.

Aviation IPT

Flight Data Object



The Logical Architecture (derived within [3]) is first decomposed into 3 main layers:

• Interface: responsible for managing the interactions between the 'outside world' (external systems or human actors) and the system being defined. This layer is expected to change when the way the system is used changes, e.g. for a new operational concept.

• Domain: contains the modules that are directly related to the ATM operations. It is responsible for implementing the core business information, rules and transformations, specific to the ATM domain (area of business). Since these are related to real-world concepts, classes in the Domain layer are not expected to change much over time and should be capable of supporting various operational concepts, with some modifications.

• Infrastructure: contains the modules relating to technical aspects. These modules provide general non-domain specific services such as distribution infrastructure, persistence infrastructure, and general programming infrastructure.

2.4.4.2 Domain Independent Logical and Technical Architecture

A Service Oriented Architecture is a paradigm that uses "loosely coupled" services to support business processes and users. Loose coupling is a condition wherein a service acquires knowledge of another service while still remaining independent of that service.

New mechanisms for flight data exchange will be required to meet future requirements for:

• Increased amount of flight information and its wider sharing (more flights, more information about each, better and more often updated, and greater availability to interested parties)

• Increased number of involved information providers, collaborators and users

• Increased collaboration between airspace users and service providers

• Increased services supporting information accessibility and user collaboration

• Timely access to relevant information

• Increased level of service supported by new automation capabilities on the ground and in the air

• Increased technical quality of service including areas of security, reliability, and latency

• Increase levels of security to ensure integrity of data at rest, secure transmission of data between trusted endpoints, improved monitoring of data traffic, etc.,

• Improved interoperability

• Improved data consistency and availability for system performance evaluation

• Increase fulfillment of the operational ATM service expectations

Aviation IPT

Flight Data Object



The SWIM environment will shift the ATM information architecture paradigm. The SWIM architecture will allow exchange of data and ATM Services across the entire ATM system. SWIM services will

• Support flexible and modular sharing of information, as opposed to tightly coupled interfaces

• Provide transparent access to ATM services likely to be geographically distributed

• Facilitate the ability of applications to ensure the overall consistency of information and data.

The technical systems of stakeholders participating in SWIM operations will have to fulfill certain interoperability requirements. The range of interoperability services available to each stakeholder will depend upon stakeholder’s authorization. The services are:

• Interoperability application services

• Middleware services

• Standard IT services

The underlying infrastructure needs to provide interoperability mechanisms at a lower level than the domain dependant application. This includes infrastructure services for:

• Security – Security services must be provided to ensure such aspects as identification, authentication, authorization, integrity, and confidentiality and non-repudiation

• Reliability – the infrastructure must ensure a known level of reliability. For instance, delivery of messages should be assured with specification on delays and multiple deliveries

• Auditing – The infrastructure should support logging information flows to support troubleshooting and to enable issuance of responsibility for user-initiated faults

• Service Management – Delivery of services requires the ability to maintain and provide information regarding the services themselves. This can include services registration, and version control. Version control may include translation services to ensure backward compatibility. The first three Service Orientation Principles from the NCSF, Service Description, Service Interface and Service Contract are key for defining, identifying, locating and using the middleware services. The Service Management Principles from the NCOIC Net-Centric System Management Framework (NCSysMF), currently under development by NCOIC, are kept to proper management of these services.

http://wiki.ncoic.net/index.php/Service_Description

http://wiki.ncoic.net/index.php/Service_Interface

Aviation IPT

Flight Data Object



2.4.5 Components

Figure 13 identifies the management functions that are the components of a SWIM system. Figure 14 identifies the SWIM network components.

Figure 13: Flight Data Object Dissemination (Ref [1], page 35)

Figure 14 – SWIM Network components

Aviation IPT

Flight Data Object



2.5 Behavior

A key objective of the Flight Data Object Dissemination is to provide a consistent view of the flight data across all systems. At the heart of that flight data is the description of the expected flight path of the flight, commonly referred to as the 4D-flight trajectory. The Flight Data Object is a concept to support the sharing of consistent flight data between all stakeholders. Its purpose is to ensure that all systems have a correct, complete, and consistent view of the flight, and that the data is widely and easily available, subject to appropriate access controls, including Trust, Identification, Authentication, Authorization, Accountability and Non-repudiation. Having such a common view is the basis for interoperability. The fundamental idea is that a single logical entity, the Flight Data Object is kept up to date by all parties wishing to share information about a flight. All parties use the Flight Data Object as a reference and all keep it updated with the latest information, thereby ensuring that all systems have the most up to date and consistent view of the flight data. Conceptually the Flight Data Object shown in Figure 15 is a convergence of track5 and flight data and is intended to hold all flight data for Air Traffic Management (ATM) related purposes, and references to Aeronautical and Weather Information that are used to compute the FDO other than for separation assurance purposes.

Invoking services is the prime means for a user to retrieve information in the SWIM environment. Services can be categorized in a number of ways, but users and developers need to find appropriate categories to deal with the various services needed in their context.

5 NextGen and SESAR CONOPS, International Civil Aviation Organization

Aviation IPT

Flight Data Object



Figure 15 – Service categories in ATM Phases

The Net-Centric Service Framework (NCSF) contains the following three concepts.6: • Service Orientation • Service Oriented Architecture • Services

A more complete list of service principles is contained in Section 3.1 of the NCSF (Ref [2]).

Depending on the complexity of the information required and its distribution, SWIM Services can be classified as follows:

• Basic Services: Basic Data Service read or write data to or from one backend, Basic Logical Services require some input data and produce data as output

• Composed Services are derived from the execution of multiple basic services or other composed services. With the interaction of multiple back-ends, mechanisms are required to ensure transactional integrity.

6 The NCOIC Net-Centric Services Framework (NCSF) contains details on these Concepts (Section 2,Service Orientation Principles (Section 3.1) and Net Centric Service Principles (Section 3.2) (Ref [2)).

Aviation IPT

Flight Data Object



• Process Services are longer-lived services that maintain a state, using basic and composed services.

Figure 16 - Flight data Exchanges among Users, Publishers and Contributors grouped by domain

2.5.1 Intra SWIM Dissemination

Figure 16 illustrates several types of disseminations within a SWIM with emphasis on domain. Figure 17 illustrates dissemination between different actors within a SWIM for the 3 cases Air to Ground (red line), Ground to Ground (green line) and Air to Air (purple line). Note that each of these disseminations could occur across SWIM’s (inter-SWIM dissemination as discussed in Section 2.5.2). In such cases, the flight data is moved across the interface as shown in Figure 18. The dotted yellow line showing data dissemination from the Departure Management publisher to the Surface Movement Management subscriber can also illustrate a SWIM to non-SWIM dissemination as discussed in Section 2.5.3. For example, a civil Departure Management publisher working within a SWIM might publish data to a military Surface Movement Management module that predates the employment of a SWIM architecture at the military ATC site. In this case, the data object is transferred according to the ICAO mandate discussed in Section 2.5.3.

Aviation IPT

Flight Data Object



2.5.2 Inter SWIM Dissemination

Deploying the Flight Data Object Dissemination Pattern requires a common transition roadmap by the regions, which plan to receive the benefits. As a System Wide Information Management infrastructure becomes available in one region, it could initially support the flight plan format and content, but transmitted through publish/subscribe and request/reply mechanisms, and further support the FDO format as it becomes available.

As soon as two or more regions have implemented a SWIM infrastructure, the participants will be able to use it to securely share information, even if internal SWIM implementations have some technical differences, through use of region adaptors, shown in Figure 18. The rationale is that in any software system, there are versioning problems. With the exception of the year 2000 software change, there has never been a successful world wide transition, so it is expected that versioning difficulties that require a device such as a Regional Adapter, at least on an interim basis.

Figure 17 - Flight Data Object exchanges between Users, Publishers and Contributors grouped by actor type

Aviation IPT

Flight Data Object



Figure 18 - Connection between heterogeneous SWIM regions

2.5.3 SWIM to NON SWIM Dissemination

It can be anticipated that not all regions will transition to a SWIM infrastructure. This is a typical problem in achieving backward compatibility. This will require means for cooperative existing/SWIM flight planning to continue during this period, which will be defined through an ICAO mandate. This is illustrated in Figure 19. A non-SWIM region will have some benefits of the FDO dissemination within the SWIM region (e.g., better planning for the initial FP for instance) but will not contribute to the dissemination itself. It is assumed that there is an overlap in the information required for the FDO compared to the present flight plan. Interactions between Present Day Region and SWIM Region will be described through reuse of deployment roadmaps.

Figure 19 - Flight between Present-Day and SWIM Regions

Aviation IPT

Flight Data Object



2.6 Post-Conditions

The Global ATM Concept will enable upgrading the quality and timeliness of information to stakeholders who share their information in a secure and trusted environment is an essential enabler to the Global ATM concept. The resultant system will not have to rely upon point-to-point communications. Aircraft will be connected by broadband voice, data and video capability. System wide information management will be implemented in an ATM network (s) considered as a series of nodes providing or consuming information. The network will include aircraft, airspace users, and ground control, as well as the other actors mentioned.

Aviation IPT

Flight Data Object



3 Additional Information

3.1 Lessons Learned

Lessons Learned are derived from and are in line with the NCOIC Net Centric Services Framework. To analyze the ATM architecture considering the Enterprise, Technological, Information, Computational, and Engineering viewpoints and investigate RM-ODP for coping with it, the following is suggested

• Use Model Driven Architecture (MDA) approach for synthesizing the architecture. • Follow a component oriented architecture design approach. • Characterize the sub-systems by their interfaces, behavior and parameterization. • Define sufficient mandatory interfaces to support interoperability and allow optional

interfaces (part of the standard but may be not used) for sub-systems. • Recommend for sub-systems, minimal mandatory parameterization and the need for

optional parameterization. • Include the following kind of interfaces for sub-system definition:

o Interfaces at application layer, considering domain and technical (management, statistics, recording, etc.)

o Interfaces at presentation layer for the sub-systems with interfaces with humans to harmonize principles of presentation and interaction (to the operator)”

• Use the layering pattern for identifying the component model • Use the publish/subscribe pattern for event handling between sub-systems • Use layering pattern (tiers) as the basic architecture principle. • Use a middleware layer with publish/subscribe capabilities as the basic infrastructure

to support the sub-systems”. • Include, as a minimum, the container, remote method invocation, notification, naming,

supervision, fault tolerance, timing and tracing services as part of the middleware. • Use open standard, mature, reliable, extensible and scalable technologies to

implement the component infrastructure for the mid term, depending on the characteristics of the ATM domain

• Use SysML as the architecture design language, complementing it with OCL and a specific ATM profile

• Use of object oriented approach for encapsulation, abstraction and extension mechanisms

• To use a mix of Centralized and Distributed architecture redundancy (in HW and SW) to achieve the required availability.

Aviation IPT

Flight Data Object



3.2 Current Modeling Activities

The FOIPS model was developed by EUROCAE and its partners under contract with EUROCONTROL. EUROCAE Working Group 59 forms the review body for the FOIPS deliverables and is open to all EUROCAE members.

The main immediate clients for the FOIPS model are the ITEC and Co-flight Flight Data Processing Development Projects. These two projects cooperate in an “Interoperability Consultancy Group (ICOG)” and have used the Flight Object concept and the FOIPS model as the basis for the interoperability between their systems. They are using the FOIPS model in their developments and in particular in the definition of how they interoperate. These two projects cooperate in an “Interoperability Consultancy Group (ICOG)” which has proposed a set of architectural principles to support the development of a network of Flight Object Servers (FOS). These principles have been incorporated into the FOIPS model.

Following the FOIPS delivery, ICOG developed a detailed interface definition based on the FOIPS model. The resulting EUROCAE document “ED-133 Flight Object Interoperability Specification” defines the interface between different instances of civilian ATC Flight Data Processing Systems (FDPS), in support of En-route and Terminal ATC Operations, and is available from EUROCAE (September 2009). SESAR 10.02.05 is now refining ED-133, and it will be available soon.

The FAA is also implementing a flight object and EUROCONTROL and the FAA have held a number of joint workshops on the subject. EUROCONTROL and the FAA plan to present a joint proposal for the standardization of a flight object definition to the ICAP ATMRPP group.

3.3 Related & Associated Patterns

3.3.1 Related Patterns

Figure 20 illustrates that the services needed by the FDOD Capability Pattern can be both domain dependent and domain independent. A goal of the NCOIC, and in particular the Services WG, is to document the domain independent services and allow domain-specific patterns such as the FDOD to reference them. Service Orchestration and Service Choreography are discussed in sections 3.1.8 and 3.1.9, respectively, of the NCSF. This concept is notionally shown in the graphic of combined service “stacks’ in Figure 20.

http://wiki.ncoic.net/index.php/Service_Choreography

http://wiki.ncoic.net/index.php/Service_Choreography

Aviation IPT

Flight Data Object



Figure 20 – Domain Dependent Service Orchestrations and Domain Independent Services within ATM operations

Figure 21 illustrates how the FDOD Pattern can utilize the existing NCOIC Patterns, which are built on the principles of the NCOIC Specialized Frameworks.

Aviation IPT

Flight Data Object



Figure 21 – FDOD utilizes other NCOIC patterns, relying on Specialized Frameworks: Source: NCOIC

3.3.2 Associated Patterns

The Air Traffic Flow Demand & Capacity pattern will rely on the Flight Object pattern. Also the Surveillance pattern can be used in conjunction with the Flight Object pattern in order to ensure complementary cooperation on different ATM domains.

• 4D Trajectory Based Operations – Operational Pattern

• Weather Dissemination – Capability Pattern

Aviation IPT

Flight Data Object



3.4 Dissemination Implementation Guidance

The following summary / conclusion table describes where the pattern provides solutions for implementing the different dissemination cases defined earlier in the document. :

Dissemination of a flight object between Air to Ground

Dissemination of a flight object between Ground to Ground

Dissemination of a flight object between Air to Air

Dissemination of a flight object data inside the same SWIM region

Interface Chapter

Structure Chapter

Figure 6 – Air-Ground Links participating in SWIM systems

Figure 13 -Flight data Users, Publishers and Contributors grouped by domain

Figure 14 – Air Operations Logical Architecture

Figure 15 – Air Operations Technical Architecture

Domain Dependant Logical and Technical Architecture top down)

Interface Chapter

Structure Chapter

Figure 8 – SWIM Network components

Figure 13 -Flight data Users, Publishers and Contributors grouped by domain

Figure 16 – ATM Operations, Support and Middleware components

DPSI Pattern

SFIEG Pattern

DIL Pattern

Independent of SWIM region

Figure 7: Flight Data Object Dissemination

Dissemination of a flight object data between two SWIM regions

Partially discussed in this pattern

Figure 10 - Connection between heterogeneous SWIM regions

Net-Centric System Management Framework (NCSysMF)

IDSD Pattern

Legacy Pattern

Not Applicable

Dissemination of a flight object between a SWIM region and a non-SWIM region

Legacy Pattern Figure 11 - Flight between Present-Day and SWIM Regions

Legacy Pattern

Not Applicable

Moreover, the following implementations are recommended:

• SWIM Region TO SWIM Region Regional Adapter: Recommend following the NCSF, using the Net Centric Legacy Service patterns with the appropriate one of the five levels described therein, and the Design Phase Service Integration pattern for the development of a middleware infrastructure integrating COTS and Legacy.

Aviation IPT

Flight Data Object



• Third Party Broker: To avoid developing a SWIM infrastructure; some systems could step up to use SWIM information of another region.

• SWIM TO LEGACY Point to Point: A region without SWIM could be considered as a collection of legacy to be connected one by one to the SWIM

• SWIM Internal Exchanges Ground to Air and Air to Air and Ground to Ground: Most of the information is available in the NextGen and SESAR programs and is compliant with the concept describe in this pattern. This pattern does not intent to replace such documentation but helps other regions build similar solutions described in the pattern.

Aviation IPT

Flight Data Object



4 Verification & Conformance

Network Centric Capability Patterns such as the FDOD Capability Pattern are provided to capture the best practices of a cross-section of industry and government practitioners familiar with the issues of data movement required for an Air Traffic Management system. Requirements in this section provide a basis to verify key components in Net Centric Technical Patterns that inherit design direction from this pattern. The verification and conformance statements are grouped into nine categories that follow. Requirements as described in the NIF use the following terminology abstracted from RFC 2119:

• Mandatory requirements are denoted by the auxiliary verb “Shall” • Recommended requirements are denoted by the auxiliary verb “Should” • Optional requirements are denoted by the auxiliary verb “May”

Ground-Ground Interoperability requirements are in line with the NCOIC SFA and are derived from the [3]. Network Centric Technical Patterns developed to implement the ground -ground interoperability functions of an ATM system would have requirements that implement the following interoperability capabilities:

• A common ATM Information Reference Model shall standardize the definition of all ATM information. This model shall form the master definition, subsets of which would be used in lower level models supporting interoperability for data-sharing domains. Existing models (e.g. FOIPS (Flight Object Interoperability Proposed Standard), AIXM) must be reconciled with the ATM Information Reference model (Ref [2], Ref [3]).

• A Service Oriented Architecture (SOA) is an architectural paradigm supporting collaborative decision-making and SWIM Architecture in general. A SOA shall be adopted.

• The Flight Object (FO) concept shall be used to support the sharing of flight data, and shall incorporate Airports, Airlines, Military Units and the Aircraft use. The FO model shall be updated according to the roadmaps to the final ATM concept.

• Aeronautical Data shall be exchanged based on the set of exchange models as currently proposed in the AIM strategy. AIXM (Aeronautical Information Exchange Model), AMXM (Airport Mapping Exchange Model), ENXM (Environmental Information Exchange Model) shall be used.

• Meteo data shall be exchanged based on a common model as proposed by an AIM strategy (see [5]). The WXXM (Weather Information Exchange Model) is proposed in an AIM strategy.

• Surveillance Data shall continue to be exchanged using the ASTERIX (All Purpose Structured Eurocontrol Surveillance Information Exchange) standard.

• Mechanisms for accessing the flight data, aeronautical data and met data shall be the same. At least the management of roles, access control principles and techniques, and publish/subscribe principles and techniques shall be common.

• A formal ATM-business process model shall be put in place, agreed among different ATM stakeholders

Aviation IPT

Flight Data Object



• A design concept for SWIM shall be put in place. It shall validate the assumptions taken and should consider the adoption of a service oriented architecture.

Air-Ground Interoperability Network Centric Technical Patterns developed to implement the air-ground interoperability functions of an ATM system have requirements that implement the following capabilities:

• Design air-ground architecture taking into account criticality of services, applications and data (e.g. redundant data link, more robust CNS capabilities and higher integrity of automatic dependent surveillance or other data linked automated aircraft position reports data required to support ASAS Separation and Self Separation)

• Segregation of air-ground architectures and sub-systems to avoid a common point of failure and perform a thorough analysis of the integration of various components (e.g. aircraft position computed by navigation system to be used also by surveillance system)

• Sharing of safety requirements between air and ground to recover from abnormal situation such as engine failure (e.g. avoid putting all safety requirements on the aircraft in case of vertical or longitudinal containment, meaning high accuracy, continuity and integrity all along a 3D tube or a 4D contracted portion of the trajectory)

In addition to the architectural principles described in the NIF Over Arching Architecture (OAA) and the related Net-Centric Specialized Frameworks (e.g., the Net-Centric Services Framework), there are some architectural principles that the best practices embodied in this FDOD Capability Pattern pass on to any Network Centric Technical Pattern created to implement Air Traffic Management principles: (derived from [3]):

• Each Flight Data Processing system (FDPS) is associated to one single Flight Object Server (FOS). In general each FOS is also associated to one FDPS, but it could also be connected to several FDPSs. (see Figure 14 and Figure 15)

• One FDPS may support one or more Air Traffic Service Units, for example an ACC and an APP unit. (see Figure 14 and Figure 15)

The remaining groups of FDOD Capability Pattern Verification and Conformance statements embody a number of the Network Centric attributes that have been developed by the NCOIC. Please see the Net-Centric Service Framework (NCSF) v2.1, Appendix B for a mapping of these principles.

Quality of Service principles:

• Subscription / Contribution contracts shall describe Quality of Service and accessibility for each individual subscriber /contributor. Their capabilities shall fulfill the QoS and access requirements.

• The architecture shall be built to accommodate different Quality of Service for individual subscribers and contributors.

Aviation IPT

Flight Data Object



Consistency:

• The network of FOSs shall ensure that consistent flight data is presented to their ATC clients.

• For each logical FO there are potentially several physical copies distributed around the network of FOSs. Each copy holds the same information.

Extensibility:

• Conceptually the FO IOP environment is intended to provide any flight data that needs to be shared between any interested ATC stakeholders. It is assumed that the scope of the data held within a FO will grow in the future as more stakeholders implement the concept.

• The responsibility for maintaining and publishing the FDO is passed from FOS to FOS at the same time as the operational responsibility for the flight is passed from FDPS to FDPS as the flight progresses on its route

• The FO IOP environment shall ensure the successive integration of additional ATC stakeholders.

• The FO Data Model shall be extendable to add further flight data that might be necessary in the future.

• The FO is being thought of as containing significantly more data than just that of concern to the FDPS (security, hazardous material, flow management). This may also affect the FOS-to-FDPS assumptions.

Robustness:

• Each FDPS shall be able to operate independently of the FOS network. • The architecture shall not be subject to a single point of failure.

Seamlessness:

• Any changes in responsibility for a given FO shall be transparent to the clients of the FO, e.g. the trajectory should not change significantly as responsibility passes from one responsible entity to the next.

Access:

• There shall be an unambiguous set of access and eligibility rules for all stakeholders using the FO IOP Network.

Aviation IPT

Flight Data Object



Ground-Ground Interoperability requirements are in line with the NCOIC SFA and are derived from the [3]. Network Centric Technical Patterns developed to implement the ground -ground interoperability functions of an ATM system would have requirements that implement the following interoperability capabilities shown in Table 4-1.

Table 4-1. Ground-Ground Verification Cross Reference Index # Requirement Description Verification

Method Comment

1 Ground-Ground Interoperability A common ATM Information Reference Model shall standardize the definition of all ATM information.

Examination

2 Ground-Ground Interoperability This model shall form the master definition, subsets of which would be used in lower level models supporting interoperability for data-sharing domains.

Analysis

3 Ground-Ground Interoperability Existing models (e.g. FOIPS (Flight Object Interoperability Proposed Standard), AIXM) must be reconciled with the ATM Information Reference model (Ref [2], Ref [3]).

Analysis

4 Ground-Ground Interoperability A Service Oriented Architecture (SOA) is an architectural paradigm suitable to support collaborative decision-making and SWIM. A SOA shall be adopted

Examination

5 Ground-Ground Interoperability The Flight Object (FO) concept shall be used to support the sharing of flight data.

Analysis

6 Ground-Ground Interoperability The FO shall incorporate Airports, Airlines, Military Units and the Aircraft use. Examination 7 Ground-Ground Interoperability The FO model shall be updated according to the roadmaps to the final ATM

concept. Analysis

8 Ground-Ground Interoperability Aeronautical Data shall be exchanged based on the set of exchange models as currently proposed in the AIM strategy.

Examination

9 Ground-Ground Interoperability AMXM (Airport Mapping Exchange Model), ENXM (Environmental Information Exchange Model) shall be used.

Examination

10 Ground-Ground Interoperability Meta data shall be exchanged based on a common model as proposed by an AIM strategy (see [5]).

Analysis

11 Ground-Ground Interoperability The WXXM (Weather Information Exchange Model) should be used as proposed in an AIM strategy. Analysis

12 Ground-Ground Interoperability Surveillance Data shall be exchanged using the ASTERIX (All Purpose Structured Eurocontrol Surveillance Information Exchange) standard Examination

Aviation IPT

Flight Data Object



# Requirement Description Verification Method

Comment

13 Ground-Ground Interoperability Common mechanisms shall access flight data, aeronautical data and met data. Analysis

14 Ground-Ground Interoperability Management of roles, access control principles and techniques, and publish/subscribe principles and techniques shall be common. Analysis

15 Ground-Ground Interoperability A formal ATM-business process model shall be published. Examination 16 Ground-Ground Interoperability The formal ATM-business process model shall be ratified by ATM stakeholders Analysis 17 Ground-Ground Interoperability A design concept for SWIM shall be published. Examination 18 Ground-Ground Interoperability The design concept shall validate any assumptions contained therein. Examination

Air-Ground Interoperability Requirements: Network Centric Technical Patterns developed to implement the air-ground interoperability functions of an ATM system would have requirements that implement the following interoperability capabilities shown in Table 4 - 2.

Table 4-2. Air-Ground Verification Cross Reference Index # Requirement Description Verification

Method Comment

1 Air-Ground Interoperability The air-ground architecture shall consider the following for critical services, applications and data. (1) redundant data links, (2) more robust CNS capabilities, (3) higher integrity of automatic dependent surveillance or other data linked automated aircraft position reports (4) data required to support ASAS Separation and Self Separation

Analysis

2 Air-Ground Interoperability Air-ground architectures and sub-systems shall be segregated to avoid a common point of failure

Examination

Air-Ground Interoperability A component integration analysis shall be performed for embedded navigation systems and surveillance systems

Analysis

Aviation IPT

Flight Data Object




Comment

3 Air-Ground Interoperability Safety requirements shall be shared between air and ground. This sharing shall include (1) enabling recovery from abnormal situations such as engine failure. (2) avoidance of including all safety functions on board the aircraft to contain the aircraft within vertical or longitudinal boundaries, (3) providing high accuracy, continuity and integrity all along a 3D tube or a 4D contracted portion of the trajectory

Analysis

In addition to the architectural principles described in the NIF Over Arching Architecture (OAA) and the related Net-Centric Specialized Frameworks (e.g., the Net-Centric Services Framework), there are architectural principles that the best practices embodied in this FDOD Capability Pattern pass on to any Network Centric Technical Pattern created to implement Air Traffic Management system Architecture principles: (see [3]). Verification is described in Table 4-3.

Table 4-3. FDOD Architectural Principles Verification Cross Reference Index # Requirement Description Verification

Method Comment

1 FDOS Architectural Principles Each Flight Data Processing system (FDPS) shall be associated to one single Flight Object Server (FOS).

Examination

2 FDOS Architectural Principles Each FOS shall be associated with at least one FDPS. (Figure 14 & Figure 15) Examination 3 FDOS Architectural Principles One FDPS may support one or more Air Traffic Service Units, for example an

ACC and an APP unit. (see Figure 14 and Figure 15) Analysis

The remaining FDOD Capability Pattern Verification and Conformance statements embody a number of the Network Centric Attributes (NCA) that have been developed by the NCOIC. Please see the Net-Centric Service Framework (NCSF) v2.1, Appendix B for a mapping of these principles. See Table 4-4.

Table 4-4. NCA Verification Cross Reference Index # Requirement Description Verification

Method Comment

1 Quality of Service Subscription / Contribution contracts shall describe Quality of Service and accessibility for each individual subscriber /contributor according to their current requirements / capabilities.

Analysis

Aviation IPT

Flight Data Object




Comment

2 Quality of Service The architecture shall accommodate different Quality of Service for individual subscribers and contributors.

Analysis

3 Consistency The network of FOSs shall present consistent flight data to their ATC clients. Analysis 4 Consistency For each logical FO there may be several physical copies distributed around the

network of FOSs. Examination

5 Consistency Each physical FO copy shall contain identical information Analysis 6 Extensibility The FO IOP environment should provide any flight data that needs to be shared

between any interested ATC stakeholders. Analysis

7 Extensibility The scope of the data held within a FO may grow in the future as more stakeholders implement the FO.

Examination

8 Extensibility The responsibility for maintaining and publishing the FDO shall be passed from FOS to FOS at the same time as the operational responsibility for the flight is passed from FDPS to FDPS as the flight progresses on its route

Analysis

9 Extensibility The FO IOP environment shall ensure the successive integration of additional ATC stakeholders.

Analysis

10 Extensibility The FO Data Model shall be extendable to add further flight data that might be necessary in the future.

Analysis

11 Extensibility Since the FO may contain more data than just that of concern to the FDPS (security, hazardous material, flow management) FOS-to-FDPS assumptions should address this additional data.

Analysis

12 Robustness Each FDPS shall be able to operate independently of the FOS network. Analysis 13 Robustness The architecture shall not be subject to a single point of failure. Examination 14 Seamlessness Any changes in responsibility for a given FO shall be transparent to the clients of

the FO, e.g. the trajectory shall not change significantly as responsibility passes from one responsible entity to the next.

Analysis

15 Access There shall be an unambiguous set of access and eligibility rules for all stakeholders using the FO IOP Network.

Examination

Aviation IPT

Flight Data Object



5 Appendices

5.1 References

[1] SESAR Definition Phase " The ATM Target Concept", DLM-0612-001-02-00a, September 2007

[2] NCOIC NCSF – Network Centric Services Framework

[3] Eurocae WG 59 – ED 133, June 2009

[4] FOIPS – Flight Object Interoperability Proposed Standard, FOIPS_MOD-D7-MsWord Issue 1.4 Released, Contract No. C/1.290/HQ/BE/04.

[5] Eurocontrol, AIM Strategy, Ed. 4.0, 25 March 2006

[6] Aeronautical Models

• RTCA DO-272A/EUROCAE ED-99A: User Requirements for Aerodrome Mapping Information

• RTCA DO-291/EUROCAE ED-119: Interchange Standards for Terrain, Obstacle, and Aerodrome Mapping Data

• AIXM ICAO Annex 13

• AMXM / AMXS

• ARINC Specification 816

• ANXM ICAO Annex 14, Vol 1, Doc 444 for Airport Ops Information

• ICAO AIS-AIM Study Group

• Eurocae WG 44 / RTCA SC217

• ISO 19100 Std. FW

• ICAO ATM RPP - WP 437

[7] Mapping Models

• RTCA DO-272A/EUROCAE ED-99A: User Requirements for Aerodrome Mapping Information

• RTCA DO-291/EUROCAE ED-119: Interchange Standards for Terrain, Obstacle, and Aerodrome Mapping Data

• AIXM ICAO Annex 13

[7] Meteorological Model

Aviation IPT

Flight Data Object



• WXXM ICAO Annex 3, WMO 306 for Weather

[8] Flight Models

• ED-133

• EUROCAE WG59

• RTCA DO-291/EUROCAE ED-119AIXM ICAO Annex 13

• AMXM / AMXS

• ARINC Specification 816

5.2 Acronyms A/G Air / Ground

ADS-B Automatic Dependent Surveillance - Broadcast

AIXM Aeronautical Information Exchange Model

AMXM Airport Mapping Exchange Model

ANSP Air Navigation Service Provider

ANXM Airport Network information eXchange Model

AOC Airline Operation Center

AOG Air Operations Group

AOR Area of Responsibility

APP Approach

ARINC Aeronautical Radio, Incorporated

ARTCC Air Route Traffic Control Center

ASAS Airborne Separation Assistance System

ASTERIX All Purpose Structured Eurocontrol Surveillance Information Exchange

ATC Air Traffic Control

ATCO Air Traffic Control Office

ATFCM Air Traffic Flow and Capacity Management

ATM Air Traffic Management

ATS Air Traffic System

CNS Communication, Navigation, Surveillance

DIL Disconnected, Intermittent, Limited

ENXM Environmental Information Exchange Model

FAA (US) Federal Aviation Authority

Aviation IPT

Flight Data Object



FDO Flight Data Object

FDOP Flight Data Object Processing

FDP Flight Data Processing

FDPS Flight Data Processing System

FIXM Flight Information eXchange Model

FOIPS Flight Object Interoperability Proposed Standard

FOS Flight Object Server

G/G Ground / Ground

ICAO International Civil Aviation Organization

IOP Interoperability

ISO International Standards Organization

MDA Model Driven Architecture

NCSF Net-Centric Service Framework

NEXTGEN Next Generation ATM System

RM ODP Reference Model of Open Distributed Processing

SAR Search & Rescue

SESAR Single European Sky ATM Research

SOA Service Oriented Architecture

SWIM System Wide Information Management

WXXM Weather Information Exchange Model

5.3 Definitions

Sector: (1) a unit of airspace within a facility area, (2) an airspace defined to represent exactly the volume within which control of air traffic is the responsibility of the controller (s) at a single operational position

Area of Interest (AOI) Boundary: A boundary that extends a parameter distance beyond a facility’s airspace within which the system receives notification of the operation of any flight.

Area of Responsibility (AOR): The boundary that defines a facility’s airspace within which the control of air traffic is the responsibility of the facility (typically the ARTCC boundary).

Flight Information eXchange Model (FIXM): 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. FIXM is developed in close cooperation with all the stakeholders. The website http://www.fixm.aero/contact-us.htm is designed to be a nexus of information and a sounding board for all interested parties. The current version of the FIXM specification is fluid and the reader is directed to the "Documents" section on the website.

Aviation IPT

Flight Data Object



RTCA DO-272A/EUROCAE ED-99A: User Requirements for Aerodrome Mapping Information provides minimum requirements and reference material applicable to the content, origination, publication, updating, and enhancement of aerodrome mapping information. It is used to support development and application of AMDBs.

RTCA DO-291/EUROCAE ED-119: Interchange Standards for Terrain, Obstacle, and Aerodrome Mapping Data: This standard describes requirements for the interchange of an aerodrome mapping database. These requirements apply the concepts of the ISO 19100 series of standards. This includes requirements for scope, identification, metadata, content, reference system, quality, capture, and maintenance information. These requirements establish a basis that can be used by data originators, data integrators, and system designers to implement a physical interchange format that supports the required data flow.


AMXM / AMXS: The Airport Mapping models – AMXM and AMXS – are intended to be open and common models generated by EUROCONTROL in the interest of the community of users and their interoperability, but may be used to derive more specific application tailored structures should that be necessary. The Aerodrome Mapping Exchange Schema (AMXS) is an exchange format for airport mapping data, developed by EUROCONTROL and intended 1 for use by the aeronautical community. It is an XML Schema implementation of the Airport Mapping Exchange Model (AMXM). The AMXS is based on RTCA DO-291/EUROCAE ED- 119, RTCA DO-272A/EUROCAE ED-99A, ISO19139 and GML3.1.1

ARINC Specification 816: Embedded interchange Format for Airport Mapping Database, Section 3.0 and 4.0 define the schema for the airport mapping database. ·

ANXM ICAO Annex 14, Vol 1, Doc 444 for Airport Ops Information: The Airport Network information eXchange Model (ANXM), based on the airport related ICAO Annex 14 and Doc 4444, is a XML-based model that enables paper less mechanisms to be developed for timely and efficient airport information sharing for the purpose of airport strategic and tactical planning at local, regional, national, and international levels.

ISO 19100 Std. FW: ISO 19100 is a series of international standards for data exchange format, metadata, and methodologies for geospatial data. An application is in geographic information systems.

RTCA DO-272A/EUROCAE ED-99A: User Requirements for Aerodrome Mapping Information: This standard provides minimum requirements and reference material applicable to the content, origination, publication, updating, and enhancement of aerodrome mapping information. It is used to support development and application of AMDBs.

RTCA DO-291/EUROCAE ED-119: Interchange Standards for Terrain, Obstacle, and Aerodrome Mapping Data: This standard describes requirements for the interchange of an aerodrome mapping database. These requirements apply the concepts of the ISO 19100 series of standards. This includes

Aviation IPT

Flight Data Object



requirements for scope, identification, metadata, content, reference system, quality, capture, and maintenance information. These requirements establish a basis that can be used by data originators, data integrators, and system designers to implement a physical interchange format that supports the required data flow.

AIXM ICAO Annex 13: The Aeronautical Information Exchange Model (AIXM) is designed to enable the management and distribution of Aeronautical Information Services (AIS) data in digital format.


ARINC Specification 816: Embedded interchange Format for Airport Mapping Database, Section 3.0 and 4.0 define the schema for the airport mapping database.

ANXM ICAO Annex 14, Vol 1, Doc 444 for Airport Ops Information The Airport Network information eXchange Model (ANXM), based on the airport related ICAO Annex 14 and Doc 4444, is a XML-based model that enables paper less mechanisms to be developed for timely and efficient airport information sharing for the purpose of airport strategic and tactical planning at local, regional, national, and international levels.

EUROCAE WG59 has consolidated the FOIPS and ICOG work to produce the ED-133 document in support of a Community Specification for ATC-ATC Flight Data Processing Interoperability.

RTCA DO-272A/EUROCAE ED-99A: User Requirements for Aerodrome Mapping Information: This standard provides minimum requirements and reference material applicable to the content, origination, publication, updating, and enhancement of aerodrome mapping information. It is used to support development and application of AMDBs.


AIXM ICAO Annex 13: The Aeronautical Information Exchange Model (AIXM) is designed to enable the management and distribution of Aeronautical Information

EUROCAE WG59 has consolidated the FOIPS and ICOG work to produce the ED-133 document in support of a Community Specification for ATC-ATC Flight Data Processing Interoperability.

RTCA DO-272A/EUROCAE ED-99A: User Requirements for Aerodrome Mapping Information: This standard provides minimum requirements and reference material applicable to the content, origination,

Aviation IPT

Flight Data Object



publication, updating, and enhancement of aerodrome mapping information. It is used to support development and application of AMDBs.


AIXM ICAO Annex 13: The Aeronautical Information Exchange Model (AIXM) is designed to enable the management and distribution of Aeronautical Information Services (AIS) data in digital format.


ARINC Specification 816: Embedded interchange Format for Airport Mapping Database, Section 3.0 and 4.0 define the schema for the airport mapping database. ·

ANXM ICAO Annex 14, Vol 1, Doc 444 for Airport Ops Information: The Airport Network information eXchange Model (ANXM), based on the airport related ICAO Annex 14 and Doc 4444, is a XML-based model that enables paper less mechanisms to be developed for timely and efficient airport information sharing for the purpose of airport strategic and tactical planning at local, regional, national, and international levels.

ISO 19100 Std. FW: ISO 19100 is a series of international standards for data exchange format, metadata, and methodologies for geospatial data. An application is in geographic information systems.

Flight Data Object Dissemination (FDOD) Capability Pattern€¦ · Flight Data Object Dissemination...

Documents

Transcript of Flight Data Object Dissemination (FDOD) Capability Pattern€¦ · Flight Data Object Dissemination...