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

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]

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

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.

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

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.

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
7

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.

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

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 customfiltered 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
10

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.

11

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.

12

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

13

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.

14

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:

15

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.

16

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_serv
ices/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.

17