Mapping Among Independently Developed Aviation Information Systems Increases Interoperability

Catherine Bolczak, Len Seligman, Nels Broste, Ron Schwarz, and Shawne Lampert

ccurate aeronautical data—such as airway definitions, airport/runway descriptions, and navigational aid locations and frequencies—are essential to air traffic management. The data, which must be updated regularly, are validated and certified prior to use by pilots, service providers, and operational systems.

To improve interoperability of global air traffic management systems, aviation data must be shared across national boundaries and among civil and military aviation authorities, their customers, regulatory agencies, and third-party vendors. The sharing of aeronautical data with common structures and definitions enhances aviation efficiencies worldwide.

An essential step in establishing information interoperability is the development of mappings: formulas or relationships that define how to transform related data from source systems to a target system. To develop these mappings, you must first determine semantic compatibility—i.e., are the different systems talking about the same concepts (even if they use different vocabularies) and making similar assumptions? For example, the United States uses seven coded values for airport type (A, B, C, G, H, S, U), while Europe uses three values (AD, AH, HP). Such differences are common.

Where compatibility of meaning exists, source data representations must be transformed to formats that the target system will properly interpret. Examples include converting from feet to meters, pre-tax U.S. dollars to after-tax Japanese yen, and boxes to cases.

Developing mappings is laborious and thus usually expensive and time-consuming. To do a mapping, you must typically examine voluminous documentation and actual data values and then interview subject matter experts to fill in gaps left by the documentation to determine to what extent the documentation reflects the current state of the system.

MITRE has extensive experience helping customers to scope and develop intersystem mappings among diverse databases. In this article we describe our effort to develop mappings among two aeronautical databases and the challenges encountered. We then describe a MITRE research project designed to address some of these challenges, particularly the labor required in developing intersystem mappings.

Air Traffic Management Databases

The aeronautical data essential to air traffic management are updated on a 28- or 56-day cycle and are then validated and certified by data providers, such as the National Flight Data Center (NFDC). It is important that users—including a wide range of national and international organizations—have access to the data in a timely fashion so that they are processing and acting on the same data. These data are needed to support air traffic management operations and interoperability.

The aeronautical information system used by the Federal Aviation Administration (FAA) is the National Airspace System Resources (NASR). NASR and its predecessor have been supplying aeronautical data to internal FAA and external aviation customers for more than 30 years. NASR is the primary source for U.S. aeronautical data for external aviation authorities and third-party data providers; however, NASR does not contain a complete set of U.S. aeronautical data. NASR is working to add additional data to its database, as well as to coordinate its data with related data sources and organizations.

Eurocontrol is the European Organization for the Safety of Air Navigation and represents 41 countries. It has developed the Aeronautical Information eXchange Model (AIXM) to unify the diverse aeronautical information systems in each of its member nations. Eurocontrol and the FAA have proposed the use of AIXM as an international aeronautical data exchange standard. Such a standard will greatly enhance information interoperability.

The AIXM is a relational data model that reflects European-based aeronautical data structures. It was the logical data model for the European Aeronautical Information System Database (EAD), which became operational in 2003. This system accepts, stores, and distributes aeronautical data from its members, storing the data in a common, managed format for access and use by its member aviation systems.

A major challenge for U.S. aeronautical information systems, such as NASR, is to find a way to use AIXM data, which may deviate greatly from their structure, semantics, and content. For example, the two groups use equivalent but different terms for the same runway surface type: "TURF" (Eurocontrol) and "GRASS" (FAA).

Data exchange between Europe and the United States is currently accomplished through the use of authoritative paper documents, such as the FAA's Aeronautical Information Publication, military databases, and commercial data products. An organization that wants aeronautical data needs to consult several sources to get it all and then processes the data to fit into its particular data schema. Data sharing among these systems would provide a more consistent picture of aeronautical information and mechanisms for the efficient routine exchange of processed data.

Mapping Across Boundaries

To facilitate the exchange of aeronautical information between the FAA and Eurocontrol, the FAA asked MITRE to assess the compatibility of the two data models to support data exchange. To accomplish this, we performed several mapping analyses. Initially, the exercise focused on sending FAA data to Eurocontrol because European civil aviation authorities and airlines that operate in the United States have an immediate interest in accessing U.S. data.
One of our initial steps in the mapping process was to look for applicable data integration tools, but we found none of sufficient maturity to be useful. Instead, we relied on data modeling application tools and spreadsheets.

Information about the NASR database was derived primarily from an entity-relationship model of NASR. Information about the AIXM data model was downloaded from the Eurocontrol Web site. We then created a repository for each model that contains information about entity names and definitions; attribute names, definitions, and type; and domain definitions, names, and values. Migrated key attributes reflecting relationships between entities, such as airports and runways, are in the NASR data model, but we needed an additional process to derive migrated keys for the AIXM model.

We used a combination of automation-aided searches and manual assessments of semantic matches to discover where NASR data could be used to cover an AIXM attribute. We then added a brief note describing how NASR data could be transformed to populate the AIXM attribute. This process was repeated for each of the AIXM concept areas: Aerodrome, Navigational Aid, Route, Airspace Service Organization, Standard Instrument Departure, Standard Terminal Arrival Route Instru-ment Approach Procedure, and Document.

We then merged the mappings from the six concepts into a single mapping database. The team derived migrated key mappings by mapping primary keys: for example, AIRPORT_ID in an AIRPORT entity becomes a migrated key in a RUNWAY related to the AIRPORT entity. All migrated keys can be traced back through a series of entity relationships to a primary key. If a primary key can be mapped, then the migrated key can be mapped.

MITRE is working with the Federal Aviation Administration and Eurocontrol to develop mappings among their two aeronautical databases. This will allow them to share information more quickly and easily.

Although the information concepts to be managed by the two systems are similar, NASR reflects FAA-unique constructs, while AIXM reflects an International Civil Aviation Organization view, leading to several differences, including:

• Data content. There are NASR data structures not found in AIXM (e.g., communications facilities) and AIXM data structures not found in NASR (e.g., taxiways and gateways).
• Data concepts. These include, in AIXM, the implementation of "time-stamping" to identify when events happen, the larger issue of temporality, and the specific way in which facilities are defined to exist in a range of time, such as the explicit assignment of a date range in AIXM, and implicit date of validity in NASR. Another difference is generalization versus specification in modeling various aeronautical data concepts. An example is the handling of navigation aid information types. In AIXM, each type (e.g., VHF Omnidirectional Radio) is an entity in itself. In the FAA system, navigational aid itself is an entity, one of whose attributes is "TYPE." Legal values for the TYPE include analogs to the AIXM NAVAID entities.
• Data structures. There are some data at the entity level in one model and equivalent data at the data attribute or data value level in the other, as in the example above. Data common to both systems are modeled differently so that data sent from one system to the other cannot easily be captured by the other.
• Semantic and value differences. There are differences in names for data with similar meanings, including fundamental terms such as airport (FAA) and aero- drome (Eurocontrol). There are also differences in data values for similar attributes (e.g., run- way surface type of "GRASS" as opposed to "TURF").

Of the 3,010 AIXM entity/attribute pairs, 54 percent had a mapping from NASR. Percentages were smaller for required AIXM attributes, i.e., the primary keys and the non-key mandatory attributes (such as the latitude and longitude location of an airport). Further analysis and resolution of differences in key areas, along with modest modification of the two data models, will facilitate additional mappings.

As you can see, developing mappings is a big job, and organizations routinely underestimate the effort required. For this project, the early analysis of the situation took four staff-months and the NASR/AIXM mapping took eight staff-months. The team was made up of staff with prior experience in specifying intersystem mappings for NATO and with a good understanding of air traffic management. The job would have taken longer with a less experienced team. Roughly 20 percent of the team's effort involved acquiring the data models and setting up the analysis databases.

MITRE is developing prototype tools to reduce the human time and effort required in the intersystem mapping process.

Research Could Lead to New Methods

How can the intersystem mapping process be improved? Several research groups have recently developed prototype tools to try to reduce the human time and effort required. MITRE has experimented with some of the most promising new tools from Microsoft and IBM's research labs, applying them to a different set of aviation databases.

IBM's Clio showed particular promise, demonstrating how mappings can be specified in an implementation-independent manner and how executable software interfaces can be automatically generated for a variety of environments. MITRE engineers gave the Clio team extensive feedback and influenced the design of subsequent versions. Some of these capabilities are now appearing in IBM products. (Influencing future commercial products is one important way that MITRE's own technology program can benefit both our sponsors and the public.)

There are still many challenges to overcome, however, before the mapping process becomes significantly automated. For example, research prototypes that perform schema matching (i.e., identifying potential semantic correspondences across different systems) are not yet practical. We applied one to the problem of matching two small schemas (i.e., roughly 20 attributes each) from another government agency and found the tool provided no benefit over the primarily manual methods used to match NASR and AIXM. The existing research prototypes, built by database experts, are limited by unsophisticated linguistic processing and an inability to learn from positive and negative feedback from a human in the loop.

To address these shortcomings, MITRE initiated a new research project in late 2003 in collaboration with Professor AnHai Doan of the University of Illinois, a leading data integration researcher. Our hypothesis is that by incorporating machine learning and linguistic techniques, the performance of existing schema matchers can be significantly improved.

Whereas schema matching will never be a fully automated task, we believe our interdisciplinary team—consisting of experts in information integration, language processing, and machine learning—will be able to develop new tools that will allow system integrators to more rapidly integrate diverse information sources
such as the FAA's NASR and Eurocontrol's AIXM.

Subsequent to the NASR-AIXM analysis, the FAA is exploring the use of the AIXM model as a vehicle to harmonize several of its own aeronautical data systems (of which NASR is one). The FAA also supports the adoption of AIXM as the international standard for aeronautical data exchange. As these initiatives move forward, we will perform additional mapping analyses for other FAA systems, as well as those from other organizations. In addition, we will continue to provide guidance on approaches for transitioning NASR to an AIXM environment.

For more information, please contact Catherine Bolczak or Len Seligman using the employee directory.

Solutions That Make a Difference.®
Copyright © 1997-2013, The MITRE Corporation. All rights reserved.
MITRE is a registered trademark of The MITRE Corporation.
Material on this site may be copied and distributed with permission only.

Privacy Policy | Contact Us