OGC Testbed-16: Aviation Engineering Report

The OGC Working Group for review of this ER is the Geosemantics Domain Working Group (DWG). This Testbed work may also be applicable to the Aviation DWG which is co-chaired by the FAA and EUROCONTROL.

The scope of the Geosemantics DWG is any aspect of semantic conceptual modeling and formal representation of data models that advances the geospatial interoperability mission of the OGC. The mission of the Geosemantics DWG is to establish an interoperable and actionable semantic framework for representing the geospatial knowledge domains of information communities as well as mediating between them.

The Geosemantics DWG has reviewed several ERs that served as baseline for the Testbed-16 Aviation Task, most notably the Semantically Enabled Aviation Data Models ER of Testbed-14 (OGC 18-035), making this DWG the ideal reviewer of this Testbed-16 Aviation ER. This Task took a step further from the conceptual elements explored in previous work and generated a working example of a modern and semantically-enabled system of interconnected aviation data sources. The lessons learnt from the development of this system will help advance the objectives of this DWG and the OGC.

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The Semantic Web is a Web of Data — of dates and titles and any other data one might conceive of. The collection of Semantic Web technologies (RDF, OWL, SKOS, SPARQL, etc.) provides an environment where applications can query that data and draw inferences using vocabularies, among others [4].

To enable wider adoption of the Semantic Web, the term of Linked Data was introduced in 2008. Linked data provides a simplified view of the Semantic Web as a web of linkage between data nodes. The idea of linked data is similar to the web of hypertext. However the semantic web is not merely about publishing data on the web but more about making links in such a way that a person or a machine can explore the data [3]. The linked data leads to other related data. The semantic web is also constructed in such a way that it can be parsed and reasoned about. The web of hypertext is constructed with links anchored in HTML documents. At the same time the semantic web is constructed in such a way that arbitrary links between entities are described by Triples in RDF. URIs are used to identify any kind of concept [5].

OGC has investigated the use of Linked Data and Semantic Web Technologies in numerous past Testbeds:

The topic of semantic-enablement of models used in the domain of aviation has been explored previously in OGC Testbeds.

Testbed-12 participants focused on semantic-enablement by means of parallel initiatives that worked on topics of semantic portrayal, semantic search and semantic mediation (OGC 16-046r1). An OGC ER (OGC 16-039r2) examined the role of geospatial semantic technology within aviation by proposing extensions to WSDOM that enabled an efficient discovery of OGC-compatible web services (OWS) and helped to create a service knowledge base. A Semantic Registry Information Model (SRIM) was defined as a superset of the W3C Data Catalog (DCAT) ontology that defined the set of classes and properties commonly used to represent any item in a register (OGC 16-059).

Other initiatives within Testbed-12 reviewed the topic of cyber security within the aviation domain in conjunction with OGC Web Services (OWS) (OGC 16-040r1), provided recommendations for the implementation of GML elements into FIXM (OGC 16-028r1), and advanced previous work in the area of business rules for AIXM 5 based on SBVR (OGC 16-061).

Testbed-13 saw the implementation of a RESTful Semantic Registry that supported the Semantic Registry Information Model (SRIM) (OGC 17-040). This work served as a foundation for the Semantic Registry built in Testbed-16.

Further work in Testbed-13 focused on formulating geospatial taxonomies to support the classification of aviation services based on their geospatial characteristics and integrating them with SDCM in order to enable the discovery of those services (OGC 17-036).

Finally, Testbed-13 also focused on aviation data quality. The Aviation Abstract Quality Model ER (OGC 17-032r2) describes a taxonomy and a model for the fundamental concepts related to data quality. The OGC Data Quality Specification ER (OGC 17-018) provided methods to quantify the quality concepts described in the AQM, and extended the SDCM to be able to support this quality information for each service described in the registry.

The Testbed-14 Semantically Enabled Aviation Data Models ER (OGC 18-035) describes work on semantically-enabling existing data and metadata models used in the aviation industry. Before Testbed-14, these models were already using Linked Data standards to represent information. However, these models were failing to provide enough semantics to facilitate the integration of information and services, improve search and discovery in the current registry, and increase the level of automation in systems. OGC 18-035 laid out a series of recommendations for future work, many of which were addressed in Testbed-16: Managing controlled vocabularies, developing a Semantic Registry, investigating the modularization and encoding of aviation ontologies, as well as demonstrating the use of semantic enablement of aviation data.

Finally, the Testbed-15 Semantic Web Link Builder and Triple Generator (OGC 19-021) described a generalized approach towards performing data fusion from multiple heterogeneous geospatial linked data sources. Despite the use case in this Testbed was not aviation focused, the concepts developed were deemed reusable within any other domain and were therefore utilized for the Testbed 16 Aviation task.

There are many documented benefits for using Web APIs in the context of data retrieval and processing like SWIM. Benefits include faster time to market for products, more flexibility in deployment models, and straight forward upgrade paths as standards evolve.

The goal of the OpenAPI Specification is to define a standard, language-agnostic interface description for HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interfaces have done for lower-level programming, OpenAPI removes the guesswork in calling the service [6].

OGC members have been investigating the use of OpenAPI since 2016. This investigation was in part due to recognizing that OGC’s existing web service standards (aka W*S or OWS) were in effect web APIs. Modernizing the OGC model for getting content on the web required a fairly fundamental change in underlying design [7].

Work in Testbed-14 initiated OGC developments in OpenAPI. A major revision of the OGC Web Feature Service (WFS) was revised by proposing a set of innovations, including the support of the OpenAPI specification (OGC 18-021, OGC 18-045). OGC built upon that experience and one year later published OGC API - Features (OGC 17-069r3), the first OGC standard defined and documented using OpenAPI. Concurrently, Testbed-15 proposed an OpenAPI-based API specification for maps and tiles (OGC 19-069), as well as styles (OGC 19-010r2).

At the time of publication of this ER, the OGC members are actively working on nine API standards, each one focused on serving a specific set of elements:

This section next describes two of the OGC APIs that are most relevant to this Testbed-16 Aviation task.

OGC API - Features

The OGC API – Features Standard is a multi-part standard that defines the capability to create, modify, and query vector feature data on the Web and specifies requirements and recommendations for APIs that want to follow a standard way of accessing and sharing feature data [8].

This OGC API was considered as the foundation for the SWIM Data Relay API and the SWIM Data Client developed in this Testbed, as the data retrieved from SWIM services would ultimately be displayed as geospatial elements on maps.

OGC API - Records

The OGC API – Records document is a multi-part draft specification that defines the capability to create, modify, and query metadata on the Web. The draft specification enables the discovery of geospatial resources by standardizing the way collections of descriptive information about the resources (metadata) are exposed [9].

This draft OGC API was initially considered as the foundation for the Semantic Registry developed in this Testbed, as metadata querying was a fundamental part of these components, but was eventually replaced by a standard REST API.

The System-Wide Information Management (SWIM) initiative supports the sharing of aeronautical, air traffic and weather information by providing communications infrastructure and architectural solutions for identifying, developing, provisioning, and operating a network of highly-distributed, interoperable, and reusable services.

As part of the SWIM architecture, data providers create services for consumers to access their data. Each service is designed to be stand-alone. However, the value of data increases when combined with other data. Real-world situations are often not related to data from not just one but from several SWIM Data Services. Having consumers retrieving data from several SWIM services raises the need for interoperability between those services. In recent years OGC members have worked on the development of a standardized family of Web APIs defined using OpenAPI for the various geospatial resource types utilized by the geospatial community. Currently, there are no SWIM services implemented using the new generation of OGC APIs.

The diversity of actors providing SWIM Services requires measures ensuring the data being transmitted can be successfully consumed. Traditionally, SWIM Data Services are designed with "data-centric approaches" consisting of defining and standardizing logical data models. These models in turn drive the implementation of dictionaries (what to call things), metadata (a means to discover things) and services (how to access and process things). As the implementations that result from these approaches fall short of providing sufficient semantics and context, the interoperability between them becomes limited [1].

The FAA has engaged in initiatives to facilitate the integration of heterogeneous data sources, including:

Testbed-16 required investigating data integration options based on semantic web technologies and analyzing the current status of achievable interoperability.

The goals of the Testbed-16 Aviation Task were classified into two areas:

The following questions were proposed in the Testbed 16 Call for Participation (CFP) as guidance for the Task efforts:

The long-term goal for the FAA is, as seen on Figure 3, to facilitate access to SWIM services and registries from not only the FAA but also other aviation partners as well such as EUROCONTROL or the Korea Aviation Corporation (KAC), Republic of Korea (ROK). For the purposes of this Testbed, only FAA SWIM services were considered as part of the scope.

As shown in Figure 4, the Aviation Task architecture was organized into a system of six interconnected components. All six components were developed simultaneously throughout the Testbed, with permanent communication and cooperation among participant organizations. The following is an overview of each component and their interactions between them. A more thorough description of their internal architecture and lessons learned can be found in the following chapters in this ER.

Each component, as well as their interactions, was designed to help answer the questions laid out by the main Testbed goals:

There are different services to enable the discovery and access of data within a System Wide Information Management (SWIM) system for aeronautic information. For the Federal Aviation Administration (FAA) SWIM, the NAS (National Aviation Services) Service Registry and Repository (NSRR) provides a centralized registry to hold detailed information about all existing and planned SWIM-enabled services. This includes information on where services and documents can be registered and searched. In addition, the FAA System Wide Information Management (SWIM) Cloud Distribution Service (SCDS) provides near real-time FAA SWIM data to the public via Solace Java Message Service (JMS) messaging.

Among the data services in SCDS, there are:

There are different schemas for discovering and accessing data with the FAA SWIM. For example, the AIM FNS delivers messages that contain encoding in the Aeronautical Information Exchange Model (AIXM) 5.1 format with different extensions (e.g. FAA extension, Event extension). The SFDPS delivers en-route flight information in Flight Information Exchange Model (FIXM) NAS 3.0. The ITWS in production delivers weather information in legacy ITWS data models.

Standard exchange information models have been developed in the aviation domain. AIXM is designed to exchange information on aerodrome/heliport including movement areas, services, facilities, airspace structures, organizations and units (including services), points and NAVAIDs, procedures, routes, and flying restrictions. The latest version of AIXM is 5.1.1. FIXM is designed to exchange information on flight and flow Information. Version 4.2.0 is the latest version of FIXM. The Weather Information Exchange Model (WXXM) is designed to deliver weather data. The latest version of WXXM is version 2.0. The implementation and support of these standard exchange information models differs among different services and organizations.

SWIM data are time sensitive. Most SWIM data are delivered through message services in near real time or real time. Data volume is high volume and velocity. Over 1.6 trillion messages per day and 4.3 terabytes of data per day are passing through the SWIM. There is no direct support of spatiotemporal searching.

The emerging suite of OGC APIs is a new generation of OGC standard interfaces to enable the interoperation of geospatial resource discovery and access. The currently approved OGC API – Features is defined and documented using the OpenAPI 3.0 specification. OpenAPI supports the automation of coding for servers and clients in unified RESTful services, i.e. those implementing Representational State Transfer (REST). To the knowledge of this Testbed’s participants, there is currently no SWIM data service implemented as a service described using OpenAPI.

This component acts as a proxy service to relay information from SWIM data services. SWIM data is normally delivered by SWIM Data Providers through publish/subscribe services. Since APIs defined using the OpenAPI specification deliver data through on-demand RESTful calls, the SWIM Data Relay API Component had to restructure the retrieved SWIM data before making it available through its REST endpoint. To achieve this, the component consists of four interconnected subcomponents:

Figure 7 breaks down the SWIM Data Relay API, and outlines how data flows through its subcomponents. The workflow sequence of its elements, as well as their connections to external components, is outlined on Figure 8.