1

FLIGHT OBJECT ENGINEERING ANALYSIS MEMO

______________________________________________________________________________

From: Ken Howard

To: Phyllis Hutchinson

Subject: Flight Object High-level Architecture

Date: 20 May 2011

Introduction

What is Flight Object High-level Architecture?

This paper investigates the high-level architecture for the Flight Object. The high-level architecture maps out the overall implementation of the Flight Object across ANSPs, other stakeholders, and their systems.

The central issue is how data and services will be allocated to the physical and logical components that

together make up the systems that exchange Flight Object data.

Why is a High-level Architecture Needed?

It is possible that the flight data stakeholders could agree to a set of standards for exchanging flight data

and leave it up to every organization and system to determine how they would implement it. There are

several potential problems with this approach:

1. There would be a lot of duplication of effort. For example, does each individual system need to build its own user authentication service or could there be a shared service supporting many systems? Does

each system or ANSP need its own Enterprise Service Bus (ESB)?

2. There are potential services that require a system-wide view. For example, an airline might want to track current position for all its flights. These flights could be on the surface, in terminal airspace, or

in en route airspace. They could be in the United States, Canada, France, Germany, or anywhere. How would the airline get a single cohesive stream of best position data? (NOTE: It is not our

assertion that such a service is a requirement, but it seems reasonable that the Flight Object have the

potential to support such a service.)

3. Making each individual system meet the Flight Object data distribution requirements could distract those individual systems from focusing on their critical missions. Should an ATC system be focusing

on sophisticated functions to allow data consumers to select the data they want, or should it be

focused on improving safety and efficiency?

4. All the stakeholder systems have to work together using Flight Object in a seamless fashion. This is less likely to be achieved without a high-level architecture.

The Flight Object high-level architecture will also help clarify what the Flight Object is. Any concise, textual definition of the Flight Object leaves room for interpretation by different individuals. A high-level

architecture requires getting very specific about what we mean by the Flight Object, and will likely raise a

number of fundamental questions about what the Flight Object includes or excludes.

Defining the Flight Object

It might seem difficult to define the high-level architecture of something without a clear, agreed upon

definition of what that something is. Yet the Flight Object has somehow eluded a clear, widely agreed upon definition. For the purpose of investigating the high-level architecture, we consider the Flight Object

2

to be a standardized way to exchange flight data using a Service Oriented Architecture (SOA). The

primary goals of this Flight Object can be stated as follows:

To make it easier to exchange flight data by standardizing the way all stakeholders and systems exchange flight data.

To allow a stakeholder to get unambiguous and authoritative data about flights.

To allow systems to be loosely-coupled with respect to flight data; that is, less dependent on specific data, formats, functionality, and protocols provided by other systems using custom

interfaces.

To make it easier for an authorized system to get access to any type of data it needs, regardless of the source system.

Issues Related to the Flight Object High-level Architecture

Questions for Flight Object Architecture

A common picture used for illustrating the Flight Object, or improved data exchange in general, is shown

in Figures 1, from a Eurocontrol briefing on Flight Object [1], and 2, from the FAAs SWIM web site [2].

Figure 1. Flight Object for Dummies [1]

Figure 2. SWIM View of Information exchange [2]

3

Both of these diagrams show a web of point-to-point connections being simplified into a simple,

centralized information exchange; in the case of Figure 1, that simple circle in the middle is labeled as the Flight Object. This transformation from a web of lines to a simple, shared circle is visually appealing, but

what does it really mean? Following is a list of things that could possibly be inferred from this diagram.

1. A system should have a single network connection through which all flight data exchange can be performed.

2. A system should be able to use one consistent set of communication protocols for exchanging flight data.

3. A system should be able to use one consistent data format for exchanging flight data.

4. A system should be able to access a single, authoritative set of data describing a flight.

5. A system should be able to use one consistent set of services when exchanging flight data. (For example, a service for creating a flight should work the same in any target ATC or TFM system.)

6. A system should interact with a single, centralized data server rather than multiple systems.

It is probably safe to assume that the first five items on this list are implied by Figures 1 and 2. However,

while the sixth item a centralized data broker seems on the surface to be implied by Figures 1 and 2, it is unlikely that this is the intention. That is, the Flight Object as drawn in these figures is a conceptual entity, not a physical entity.

Further examination of the above lists shows that some items present architectural issues and some do

not. Item 1 a common network connection has an architectural implication only at the lowest level. Items 2 and 3 can be implemented by each individual system with no change to how data and

functionality is currently distributed to systems. It is items 4 and 5 that present the challenging questions

for the Flight Object high-level architecture. Item 6 suggests a way to achieve items 4 and 5; that is, a single centralized flight data server would be one way to provide a single authoritative set of data and

standardized flight data services. But there are other ways to achieve items 4 and 5; this is the initial focus

of the high-level architecture analysis.

Therefore, the two primary questions to be answered by the high-level architecture are:

1. Where is Flight Object data stored? It is a given that the vast majority of Flight Object data will be stored in the stakeholder systems that create and use that data. Airlines will maintain data for the

flights they operate. ATC systems will maintain data for the flights they are controlling. TFM systems will maintain data about the flights in their planning horizons. However, when one looks at the need

to provide a single authoritative data feed or a service to perform data reconstitution (providing a data

consumer the ability to recover previously transmitted data that it has missed), the possibility of

centralized data storage that is independent of any specific system seems worth at least considering.

2. Where are Flight Object services hosted? Again, it is expected that many services are hosted by the stakeholder systems, but again, there are services that could possibly be provided in a more efficient

or capable manner by centralizing them. For example, an airspace user currently files a flight plan with the departure ATC system, requiring that it be able to address possibly hundreds of individual

facilities. A centralized entry point for submitting a flight plan might provide an advantage to those

airspace users.

When we talk about services, we must be cognizant that there are different types of services. There are

core services that are needed to support general functions such as data discovery (where is the data or

service I need?) and user authentication. There are functional services that perform application-level

functions on the flight object data; some examples might be a service to validate a flight plan or a service to create a flight. All types of services must be addressed in the high-level architecture; however, the

4

functional services present the most interesting questions from an architectural standpoint. Therefore, the

initial focus of this analysis will be on functional services.

Terminology

The following terms and acronyms are needed to discuss the Flight Object. Generic terms have been used

to disassociate the discussion from any particular ANSP.

Air Navigation Service Provider (ANSP) An organization that provides ATC and/or TFM services (for example, FAA, Airservices Australia).

Air Traffic Control (ATC) A set of services offered by an ANSP that assure safe operation of aircraft in that ANSPs airspace.

ATC System An automation system that supports ATC.

Air Traffic Management (ATM) The combined services of ATC and TFM.

Airport Operations A set of services offered by an ANSP or airport operator that assure safe and efficient operation of aircraft on the ground.

Airport System An automation system that supports the management and control of flights on the surface at an airport.

Airspace User An airline, other business, or private individual who operates a flight.

Enterprise Service Bus (ESB) A set of software tools that allow systems to easily make services available to other systems and for other systems to access those services.

Flight Instance The set of data that describes a particular flight.

Flight Object Server (FOS) A collection of services that provide access to flight data and perform functions on flight data in a standardized SOA manner.

Service A software function, in this context, to be used between systems for providing data, getting access to data, or operating on data. For example, a service could be Create Flight,

Validate Flight Plan, or Subscribe for Flight Updates.

Service-Oriented Architecture A standardized approach to providing services that can be used flexibly by other systems or services within a given domain, such as the domain of flight data

exchange.

Traffic Flow Management (TFM) A set of services offered by an ANSP that assure efficient operation of aircraft in that ANSPs airspace.

TFM System An automation system that supports TFM.

Assumptions

In a Service-Oriented Architecture, systems make functions available to other systems as services. In the

case of the Flight Object, many of these services will be requests for data or subscriptions to data feeds. However, when we consider all the systems that are participating in the Flight Object data exchange, we

are assuming an asymmetry in how services are being allocated to systems, and how those systems use

those services to get or exchange data. The basic assumption is that all of the Flight Object services are

being provided by ANSP systems, which are a main source of the data. Airspace user systems will not be providing services, but will be accessing services provided by the ANSPs. The asymmetry in this

arrangement is as follows:

ANSP systems will provide to the airspace user systems by providing data services.

5

Airspace user systems will provide data to the ANSP systems by accessing services provided by the ANSP systems.

That is, in either case, the request for data or provision of data is triggered by the airspace user. The airspace user can only ever be a client in this relationship, not a server. An ANSP system can be either a

server, or a client to another ANSP system server. As a result, when the architectures are drawn, you will

only ever see a Flight Object Server (FOS) associated with an ANSP system, never with an airspace user

systems or other external system.

Research

Flight Object Architecture

Some work has been done at the conceptual level exploring possible Flight Object architectures. Work

that was reviewed for this analysis includes:

The Flight Object Interoperability Proposed Standard (FOIPS) Study [3,4]

The ICAO Flight Plan Study Group [5]

The ICAO Air Traffic Management Requirements and Performance Panel [6]

Much of the focus of these studies has been on creating a Flight Object for use only by en route ATC systems. The central question in these studies is: How is a flight instance created, updated, and managed

by the ATC systems whose airspace is traversed by that flight. While this is certainly a critical aspect of

the Flight Object to consider, it represents a very narrow view of the Flight Object, since these systems

have very homogeneous data requirements and functionality. The FOIPS work does introduce other types of clients, but not to the degree of considering an airspace user as a major part of the flight data exchange.

Taking a narrowed view is appealing as it reduces the problem to a more manageable size. However, it is

a risky approach, as it may lead to an architecture that is hard to sustain when the full functionality is considered.

The general approach adopted is these previous studies is that each ATC system has a Flight Object

Server (FOS), which would be networked together to exchange and maintain flight data. The role of the FOS is to present the data and functions of each system that are need by other systems as SOA services. A

number of assumptions and recommendations are made in these studies that allow this network of FOSes

to provide Flight Object functionality; some of the more significant ones are:

Any FOS must be able to construct and maintain the full data for a flight instance. In the context of this study, this is meant to include a full end-to-end trajectory for the flight.

One and only one FOS is responsible for maintaining and publishing the authoritative data for a flight instance at any given time. This authoritative source changes over the operation of a flight.

These assumptions might work for a network of ATC systems that have very similar functionality, such

as trajectory generation, and that each only care about a flight for a limited time, such as while it has positive control of that flight. But these assumptions might be hard to generalize to the full Flight Object

environment which includes a wide variety of stakeholders and systems. Nonetheless, these ideas are well

founded and explored further below.

Other, more detailed ideas were learned from this research and are included in the rest of this document.

General Requirements to Consider

A difficulty in engineering the Flight Object high level architecture is that it must support much more than the data exchanges currently performed between systems; in fact, it is envisioned that the Flight

Object will enable the global ATC and TFM systems to evolve to a much more sophisticated level of

6

functionality. While it is not the job of the Flight Object to design and implement this functionality, it is

helpful to plan for what some of the significant requirements will be. Following is a list of requirements and considerations to keep in mind as we explore the high level architecture. Many of these were learned

from the ICAO Global Air Traffic Management (ATM) document [7]. Some of these are requirements of

the current ATM environment.

Flight information must evolve gradually from more general information known well in advance to the more specific information needed to operate the flight.

Both ATC and TFM can place constraints on a flight when a flight plan is filed.

The airspace user is a major stakeholder in global ATM.

An airspace user wants end-to-end feedback when filing a flight plan.

A common future concept is the electronic negotiation of a full end-to-end trajectory between an airspace user and the various TFM and ATC systems that a flight traverses.

There are many different types data providers and consumers; airspace user, airport operator, ATC, TFM, security, a limo company. These provide very different data and have different data

needs. All must be supported by the Flight Object.

There is a commonly stated need to communicate trajectories, not routes. It might help to reinforce this by getting away from the terminology of filing a flight plan and speaking instead of creating a flight instance.

Alternative Approaches

There is a wide spectrum of approaches for distributing flight object data and services. A good place to

begin to define tradeoffs is to look at the extremes. In this case, the two extremes would seem to be fully

distributed and fully centralized.

Fully Distributed

A fully distributed approach applies the least possible standardization and centralization, and relies most

heavily on the individual systems to implement the solution. The idea is for each system to provide all the

same data and functions as it does today, but to do so in a standardized SOA approach using common data formats. Each system would deploy one or more Flight Object Servers (FOSes), which would present

the data and services for that system to other systems in a standardized SOA manner. Each FOS would

interface with its host systems in whatever manner works best for that system. A simplified view of this approach is shown in Figure 3. (NOTE: This is similar to the approach explored in the FOIPS study [3,

4].)

As shown in Figure 3, each instance of a deployed system has its own FOS that presents its data and services to other systems and clients through a common network. Each FOS would implement a local

Enterprise Service Bus (ESB); the ESBs would be networked together to form a distributed ESB. The

collection of these FOSes can be thought of as the Flight Object (shown as the oval in the center of Figure

3). However, in this approach, each system owns a piece of the Flight Object; the domain of the ATC 2 System (the oval in the upper right-hand corner of Figure 3) is shown as an example of this.

7

Figure 3. Fully Distributed Flight Object Architecture

In the fully distributed approach, the data for a flight instance would be distributed and replicated among

the FOSes. For example, a flight that is en route from ATC 1s airspace to ATC 2s airspace would probably exist in the FOS for both of those systems. The interaction of these FOSes would have to be managed in a way that assured that the data in both FOSes for that flight matched exactly, at least for

common data. A question raised by this approach is: How do the FOSes collectively provide a single

authoritative source of data? This question is answered in a reasonable manner in the FOIPS study, as follows.

In the FOIPS approach, the systems assure one authoritative source of data by defining unique roles for

the FOSes. One role for a FOS is the Manager for any given flight instance, and one role (presumably the

same FOS, in this architecture) is the Publisher for the given flight instance. Other FOSes can contribute data for a flight instance, but only one FOS (the Manager) maintains the official version of that flight

instance and one FOS (the Publisher) publishes the data for that flight instance. This means, for example,

that if a flight is currently in ATC System 1, and ATC System 2 applies a route modification to the flight (to take effect in its own airspace), ATC System 2 would send the update to ATC System 1, ATC System

1 would re-model the full flight trajectory, and ATC System 1 would publish the new trajectory for the

flight.

The role of Manager/Publisher can change as a flight progresses. For example, the ATC 1 System would

be the Manager/Publisher for an airborne flight while it has operational control, and then the ATC 2

System becomes the Manager/Publisher when it gains control of the flight. For a data client to get flight

position updates in this architecture, it would have to register for updates with every system that might be

8

ever the Publisher for a flight of interest. However, once a client did so, it would get updates from only

one system at a time for a flight, this providing authoritative, consistent, and unique data for each flight.

The fully distributed approach would work best in an environment that included only homogenous

systems. However, the real Flight Object environment includes different systems with different functions

requiring different data. One system might not want or be able to process and store the same data as

another system. For example, an airport system might not model and store sector entry events while an ATC system might not store taxiway assignments. This makes it difficult, if not impossible, for any one

system to be the Manager/Publisher for all data in a flight instance.

An alternative approach that would resolve this issue would be to divide the data into partitions and have different Managers/Publishers for different partitions of flight data. For example, TFM System 1 could be

Manager/Publisher for the TFM data while ATC system 2 was Manager/Publisher for the ATC data and

Airport 1 was the Manager/Publisher for the airport data. To make this work, each system would have to know what data was in its domain and keep track of the current Manager for that data domain. Making

this more difficult is that some data, such as an expected departure time, would cross multiple domains.

Some of the pros and cons of the fully distributed approach are:

Pro: A client has direct access to the authoritative data source, so data latency should be minimized.

Pro: A client has control over what the source of its data is. If an Airport System only ever wants data from one ATC System, it can subscribe directly to that system and only to that system.

Con: There will be duplication of functionality between the FOSes. For example, a desired function for a client would to get data updates for a specific subset of flights. In this approach,

each FOS would have to implement the ability to provide a custom-filtered data stream to a client. Similarly, a useful function would be for a client to be able to reconstitute data; that is,

request a full set of data for a flight instance for which it may have missed some updates. Again,

each FOS would have to implement a reconstitution capability.

Con: This approach requires a high degree of handshaking and coordination between the FOSes. Each FOS has to connect o many other FOSes to get all the data updates. Each has to keep track of who the Manager/Publisher is, so it knows who to send changes to. This increases complexity,

which increases cost and the risk of errors. For example, there would be a significant risk that two

systems would be publishing redundant or conflicting data for a flight instance at any given time.

Con: The role of Manager could be quite involved. Not only does the Manager have to maintain the authoritative data, but it has to arbitrate updates from other sources. That is, if the Manager

gets conflicting updates from two other sources, it needs to determine how to update the data for

that flight instance. Does every individual system want to take this job on? Would every system

do this in a consistent or correct manner?

Pro: This approach does not require any functionality to be developed independent of any of the implementing systems, which could make it easier to manage the procurement or support the

deployed functionality.

Con: This approach places a lot of new requirements on the implementing systems, which could distract those programs from their core missions.

Con: Deployment of the FOSes would likely be piecemeal, making it difficult to manage the transition. A client would likely be in a position where some data would be available via the FOSes and some data via legacy interfaces. A system would have to provide both its legacy

interfaces and FOS to allow all its clients to transition to the new interface.

9

Con: A client would need to subscribe to many individual data sources to get all the data it needs. It would probably have to include functionality to handle the case of redundant or conflicting

updates for a flight.

Con: There is easy way to detect failures or provide backup data in this approach. If the Manager/Publisher for a flight instance fails, how would some other system know to take over

that role?

Con: Despite the existence of standards, it would be hard to assure that every individual developer would implement them the same, thus leading to the risk of inconsistent services across

different ANSPs and systems.

Fully Centralized

A fully centralized approach applies the greatest possible standardization and centralization, and relieves the individual systems from nearly all the burden of implementing the solution. Each individual system

would continue to provide all the same data and services as it does today in the same formats and using

the same protocols. A centralized FOS would use the legacy interfaces to collect data and access existing

system functions. The centralized FOS would provide a common, standard, SOA-compliant access point to any Flight Object client. The centralized FOS would store data centrally, as needed, re-distribute data

to clients using standard formats, and re-direct service requests to individual systems. A simplified view

of this approach is shown in Figure 4.

Figure 4. Fully Centralized Flight Object Architecture

10

As shown in Figure 4, the building blocks of the fully centralized approach are a single, centralized FOS

and set of interfaces, labeled Flight Object Interfaces (FOIs), that would communicate between the centralized FOS and the individual systems. The FOIs are simply modules that either get data from legacy

interfaces (that is, using pre-existing formats and protocols) or that invoke legacy services (which may be

functions that are not being provided in a SOA manner). The FOIs would be developed and maintained by

the Flight Object and thus consider part of the Flight Object domain (the larger oval in Figure 4), thus making the development and implementation of the Flight Object independent from the individual

systems. However, those FOIs would not be strictly part of the Flight Object, the smaller oval in Figure 4.

(This is a semantic distinction that is not worth much thought or argument.)

To illustrate a difference between the fully centralized and fully distributed approaches, consider the

requirement to provide a single authoritative source of data. In order to provide an authoritative data

source in the fully distributed approach, the FOSes must handshake with each other to ensure that only one FOS is publishing a given type of data at a given time. In the fully centralized approach, every system

publishes all its data, all the time, to the centralized FOS. The centralized FOS would have business rules

and logic to determine which of the multiple data sources is the most authoritative, would store only that

data, and distribute only that data out to a client data subscriber. The centralized FOS could convert all data to the standard Flight Object data formats before sending any data out. Functionality, such as custom

filtering of data feeds, providing back-up data, data validation, data restoration and compression, would

be implemented only as part of the centralized FOS. This has the value of relieving each system from developing its own version of these functions, and ensuring that all data is provided in a consistent,

standardized manner. Also, since there is only one FOS, there is no debate over who the

Manager/Publisher is for any flight instance.

The fully centralized approach would allow a great deal of flexibility as to what services were provided.

For example, one might think that a client would no longer be able to subscribe to a dedicated feed from a

specific data source. However, it would be very easy for the centralized FOS to provide a service that

allowed a client to subscribe for all data from a given source. The centralized FOS would just convert that data to the standard formats and provide it using a standard protocol.

Some of the pros and cons of the fully centralized approach are:

Con: Data latency would be increased by having to pass all data through a centralized FOS. The increase could be significant and prohibit critical applications from using the Flight Object data.

Pro: There would be no duplication of functionality. For example, the ability to provide a custom-filtered data stream to a client would be developed only once, deployed once at the centralized

FOS. One set of software would be monitored and maintained. The same applies to many other

functions such as data reconstitution or user authentication. This should reduce the overall

development and support costs.

Pro: This approach requires no handshaking and coordination between individual FOSes. There is no ambiguity with respect to who the authoritative data source is. There is no chance for two

FOSes to be sending conflicting updates for the same flight. This decreases complexity, which

decreases cost and the risk of errors.

Con: The developer of the centralized FOS would have to develop and maintain a large number of customized legacy interfaces that use different connections, different data formats, and

different protocols. This could be costly.

Con: There is a data that is used by multiple systems but is not used by lots of systems. In this approach, every bit of data must go through the centralized FOS even if it is only used by one

other system.

Pro: This approach would facilitate the transition process. The legacy interfaces for each individual system would continue to exist even after the FOS was implemented. Clients could

11

switch over from the old to the new in a piecemeal fashion with no additional burden to the Flight

Object development or support.

Con: This approach requires all the Flight Object functionality to be developed independently of any of the implementing systems, which could make it harder to manage or support the

procurement. If we consider the Flight Object to be a global concept, this means that there would

be a FOS that would exist independently of any ANSP. What organization would develop and

maintain a FOS that would support all ANSPs across the world?

Pro: This approach puts no new requirements on the implementing systems, allowing those programs to focus on their core missions.

Pro: A client would need to subscribe to one data sources to get all the data it needs.

Pro: The centralized FOS could resolve data discrepancies and find back-up sources for data when there is a failure, thus providing a more robust data source.

Mixed Solutions

As stated at the beginning of this section, the extreme examples are useful for illustrating pros and cons of

different approaches. The interesting observation is that the pros and cons of the two approaches are

complementary; that is, one approachs pros address the other approachs cons. Consequently, it makes sense to look at how the approaches could be combined to the best overall advantage. This section gives

some specific examples of how the approaches could be mixed to provide some advantage.

Hierarchical Approach

There are very different types of clients that need to get flight data and flight data services, and it is

possible that different types of FOSes could be developed to serve them. Consider two client examples:

and Airport System and a limo service.

An Airport System is developed and supported by an ANSP, perhaps even the same ANSP that owns the ATC System above that airport. It has very stringent data needs in terms of quality, reliability, and

performance. It is very tightly linked with the ATC System that controls the airspace above that airport. It

needs to exchange lots of data with that ATC System. A good example of a tightly coupled link between an airport system and an ATC System is a flight plan clearance. The airport system may have

responsibility for making sure that the flight crew has the correct flight plan before departure. The main

impact of that flight plan is on the ATC system. It is critical to ensure that the cleared flight plan matches

exactly what the ATC system is expecting. This is especially difficult when the flight plan can change at any time. There must be a tight coupling between the airport system and the ATC system to ensure that

the flight plan is synchronized between the tower/flight crew and the ATC system.

A limo company could be using its own software, software provided by an ANSP, or some third-party software. It has limited data requirements: it has clients arriving on certain flights. It wants to know

whether those flights are cancelled or delayed, whether flights have departed, when flights will arrive, and

have flights arrived. The data requirements in terms of quality, reliability, and performance are pretty low. It is very loosely coupled with the Airport and ATC Systems. It wants data from any source system, and

doesnt really care where the data is coming from.

If you compare the requirements of these two clients to the two extreme approaches, it seems quite clear

that the needs of the airport system map more closely to the pros and cons of the fully distributed approach, while the needs of the limo company map more closely to the fully centralized approach. Could

the Flight Object architecture provide both solutions and allow clients to make use of the FOSes that best

suit their needs? A hierarchical solution that provides both solutions is shown in Figure 5.

12

Figure 5: Hierarchical Approach

Figure 5 shows two different types of FOSes. Lower-level, distributed FOSes (dFOSes) would be

developed by individual systems to make their core data and services available to privileged clients, such as the Airport Client shown in Figure 5. A higher-level, centralized FOS (cFOS) would aggregate data

from the individual dFOSes and make additional, more generic data and services available to other

clients, labeled External Client in Figure 5. (NOTE: The labeling of the clients as Airport and External is for demonstration and does not preclude an Airport or ATC client from getting data from the cFOS, if

needed.) Together, these two different level FOSes form a hierarchical Flight Object implementation.

The approach in Figure 5 has several advantages over the extreme approaches. A system that has a

rigorous, closely coupled interface with another system (such as airport to ATC) can directly interact with that systems dFOS. At the same time, that distributed FOS makes it easy for a centralized FOS to get the data in standardized formats using the SOA approach. Functionality that the limo company would find

useful, such as integrating data from any source and filtering out only the arrivals at one airport, could be provided by the centralized FOS, thus relieving all the distributed FOSes from having to do so.

Furthermore, if the dedicated airport system needed data in addition to what it gets directly from the ATC

System, it could do so from the centralized FOS using the same standardized data formats.

Some of the pros and cons of the hierarchical approach are:

Pro: Privileged clients with rigorous data requirements can connect more directly to the source of the data, thus improving performance and reliability.

13

Pro: Services that are more tightly coupled (that is, less likely to be of general use) can be kept on a more local basis in the individual dFOSes.

Pro: Shared, generic (that is, loosely-coupled) services can be provided by a single, centralized function, thus reducing redundancy and complexity.

Pro: Each individual system becomes part of the Flight Object, but is only required to provide the services that are closely related to its core mission.

Pro: It is easy to provide data feeds combining data from various sources with redundancies and discrepancies removed.

Pro: It is easier to develop and maintain the cFOS, as it can get data from individual systems using standard data formats and SOA services.

Con: There is still a single, global cFOS. It is not clear who would develop and maintain this.

Regional Approach

A problem with the fully centralized approach or the hierarchical approach is that is isnt clear who would build and maintain one global FOS. However, centralization offers the benefits of reducing redundancy

and complexity, thus lowering cost. A regional approach would allow an ANSP, or a group of ANSPs to develop and share a regional FOS, and then network the regional FOSes into a virtual Flight Object.

Figure 6: Regional Approach

14

Figure 6 shows an example of a regional approach. Each region has a centralized FOS. In this example,

Region 1 has implemented the hierarchical approach internally with both distributed and centralized FOSes. Region 2 has implemented a centralized approach, with a single FOS that interfaces with its

internal systems. The two centralized FOSes are networked together to form a global Flight Object that

provides data and services through a distributed ESB across both regions. An authorized client could

access services from any dFOS or cFOS anywhere on the global ESB.

A Region in this approach could be any entity. It could consist of a single ANSP, such as the FAA, that

manages many systems and facilities. Or it could be a group of ANSPs working together under a single

umbrella organization, such as Eurocontrol, to share the development and maintenance costs of implementing the Flight Object. One of the major advantages of this approach is that it allows autonomy

to an ANSP or group of ANSPs to make their own engineering decisions, as long as they provide services

and data that meet the Flight Object standards.

The regional approach re-introduces the problem of the fully distributed approach with respect to a single

authoritative source of data. Assuming that aggregated data feeds are available from the cFOSes, it is still

possible that a flight would exists in two or more cFOSes. There would be several ways to approach this

problem. The first would be to apply the Manager/Publisher role between the cFOSes as described in the fully distributed approach. That is, the cFOSes would handshake with each other to determine a unique

Manager/Publisher at any given time. Another approach would be to make each cFOS be the

Manager/Publisher of data for its region. A data client in the U.S., for example, would get all of its data from the U.S. cFOS. The U.S. cFOS would subscribe for updates from all the other cFOSes and keep a

complete set of data for all flights. This does not guarantee that all the cFOSes have the exact same data,

but probably comes pretty close and may be simpler to implement.

The pros and cons of the regional approach, of course, reflect how each region chooses to implement their

Flight Object. However, there are two additional pros and cons of this approach:

Pro: It allows ANSPs or groups of ANSPs to work autonomously and determine the best approach for themselves.

Con: It requires standard data formats and services to be implemented across multiple FOSes, increasing complexity and the risk that that are not completely standardized.

Con: It requires a solution to the problem of determining the authoritative source of data.

Transition

A major issue in developing and implementing the Flight Object will be the transition from how systems

exchange data today to they will exchange data in the Flight Object environment. Some of the difficulties

are as follows:

If a system replaces its legacy data feeds with a FOS, all of its clients would have to be ready to simultaneously switch from the old methods to the new methods. Each system could avoid this by

maintaining both methods for getting data for a transition period.

If one source of data for a client implements a FOS but another source does not, the client has to maintain two different methods for exchanging data. A client might not be incentivized to switch to the new data exchange methods until many systems had implemented it.

It may be that some systems never switch to the Flight Object approach and would have to be maintained indefinitely.

The fully centralized approach (Figure 4) naturally provides an easy path for transition. Since individual

systems are not converting to the Flight Object, it is easy to provide the legacy interfaces in parallel with the new FOS services. Since all the conversion is being done as one central effort, it is relatively easy to

convert a relatively large amount of data and interfaces to the FOS in a short time.

15

However, the fully centralized approach is not likely to be a workable end-state solution. So the question

becomes, how can the advantages of the centralized approach be applied to different end state at least during a transition period? The general answer is that this can be done as long as the end state solution

includes some kind of a centralized FOS. Figure 7 shows an example of how transition could be

facilitated assuming the desired end state is the hierarchical approach.

In Figure 7, we assume that every individual system is to develop a dFOS that will be connected to a cFOS; this is the hierarchical approach. Figure 7 shows what this might look like in a state of transition.

ATC System 1 has converted to the Flight Object approach. Authorized clients can connect to the ATC

System 1 dFOS and to the cFOS. (NOTE: ATC System 1 may also still be supporting its legacy interfaces during a transition period.) ATC System 2 has not yet converted. To make its data available as part of a

consolidated Flight Object data feed, the cFOS has implemented an FOI to get the data from ATC System

2 using the legacy interfaces. This allows an external client, such as the one shown in Figure 7, to get a complete data feed in a consistent, Flight-Object-like manner, regardless of whether the source has

converted to the Flight Object approach or not. Once ATC System 2 implements its own dFOS, the cFOS

is modified to get data using the new services and formats rather than through the legacy interface (via the

FOI). Individual systems, as a result, could transition over to the Flight Object approach in a piecemeal fashion, in a manner completely invisible to the External Client. In addition, internal clients, such as the

airport client shown in Figure 7, could also take advantage of the Flight Object data exchange, as long as

it was willing to go through the cFOS during the transition period.

Figure 7: Transition using Hierarchical Approach

Some of the pros and cons for this approach to transition are:

16

Pro: A complete, SOA-based data feed could be provided even though individual systems had not yet converted, thus allowing individual systems to convert one at a time.

Con: This approach would require developing throw away FOIs.

Pro: If some systems never convert to the Flight Object methods, their data can still be part of Flight Object data feeds.

There is another point that is not a con of this approach, but a transition problem that no approach seems to solve: An individual system might need to maintain its legacy interfaces in parallel with the new Flight

Object interfaces for some period of time to allow its clients to transition in an orderly manner.

Summary of Alternatives

Two extreme architectures, fully distributed and fully centralized, serve to highlight a number of the

issues related to the high-level architecture of the flight object. Interestingly, the pros of one seem to match with the cons of the other. A hierarchical approach that combines elements of the two extremes

seems to capture most of the benefits of the two extreme approaches. However, it has one big drawback:

it requires there to be a single, centralized FOS for the whole world. A regional, hierarchical approach

resolves this problem by splitting the world into regions for which some existing authority might be willing to develop and maintain a cFOS for that region. Finally, the existence of a centralized FOS in any

approach helps ease the problem of transitioning from the current ways of exchanging data to the Flight

Object approach.

Use Case Analysis

With any engineering task, it is quite common that the devil is in the details. Any general approach will be subject to many low-level decisions and many low-level problems to solve in order to become a feasible approach. It is important that we try to flush out these details and potential problems early on in

the architecture analysis. To do so, we will apply use cases to several of the potential architectures.

To perform these walkthroughs, we need a small number of alternative architecture. Two of these alternatives will be the fully centralized (on a global scale) approach and the fully distributed approach.

(Although the fully centralized approach may be practically infeasible, it still may serve to illuminate

issues.) In addition, we will use a regional, hierarchical approach, similar to that shown in Figure 6.

The specific use cases will be worked out throughout the analysis. The use case chosen will not necessarily accurately portray todays systems and functions or even a future state of the systems, but rather will be chosen to provide plausible scenarios that explore Flight Object issues. Some potential use

cases are:

Filing a flight plan using todays functionality (that is, the airspace user files a flight plan with the departure ACT system, gets feedback only from that system, other systems such as TFM get

copies of the validated flight plan).

Filing a flight plan and getting end-to-end route validation and feedback (similar to above but flight plan is validated with all traversed ATC and TFM systems).

Actively negotiating a full end-to-end trajectory.

Operation of a flight from departure to arrival.

Airspace user gets data feed including all data updates for any of its flights from any system.

Airspace user needs to reconstitute data for a flight or set of flights after having missed some updates.

17

The use cases will be developed in detail. They will include assigning GUFIs, validating data, user

authentication, and other issues. We expect to document this analysis using text and transaction diagrams.

TMA Case Study

An interesting case study is the development of the FAAs Traffic Management Advisor (TMA). TMA was originally developed to be deployed independently at each individual Air Route Traffic Control Center (ARTCC). It was therefore designed to use a local interface with the Host computer at a single

center. As its functionality grew, it required data from adjacent centers. As it grew more, it required data

from further out and from other ANSP systems (NavCanada). It may be interesting to examine the somewhat inefficient and costly manner in which this was done, and to contrast it with how it might have

been accomplished in a Flight Object environment. This analysis will be added to a future version of this

document.

Summary

This paper presents some alternative high-level architectures for implementing the Flight Object, starting

with two extremely different approaches: fully distributed and fully centralized. These two extremes offer some very differing pros and cons. By blending the two extremes in different ways, we can attempt to

maximize the pros and minimize the cons. One blend in particular seems to hold promise: a regional,

hierarchical architecture of Flight Object Servers. However, there is much more analysis to be done to

flush out detailed issues and problems with these approaches. This will be done primarily by applying specific data use cases to several of the alternative architectures.

References

1. David Isaacs, Eurocontrol, A Bit of Background, briefing presented to the Eurocontrol Flight Object Workshop, 2008.

2. Taken from the FAA System Wide Information Management web site: http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/atc_comms_services/swim/program_overview/

3. EUROCAE, Flight Object Interoperability Proposed Standard (FOIPS) Study, ID3 Methodology, EUR 135-05/FOIPS-019 Issue 01.01.

4. EUROCAE, Flight Object Interoperability Proposed Standard (FOIPS) Study, D8 Compatibility with WG59 Architectural Framework, EUR 146-06/FOIPS-052 Issue 1.00.

5. ICAO Flight Plan Study Group, Appendix- Flight Object Concept of Use, FPLSG/3-SN/24, 2006.

6. International Civil Aviation Organization, Air Traffic Management Requirements and Performance Panel, Flight and Flow Information for a Collaborative Environment A Concept, Version 1.0, September 10, 2010

7. International Civil Aviation Organization, Global Air Traffic Management Operational Concept, Document 9854, First Edition 2005.