Testbed-12 Aviation Architecture Engineering Report

In OGC Testbed 11, a Data Broker concept was developed using the WFS 2.0 specification with augmented features to enable a data chain of cascading web service requests, in which the Data Broker would provide the client-interfacing web service and execute additional requests "behind-the-scenes" to other WFS instances to obtain required data.

The Data Broker is intended to provide a single interface for clients to connect to multiple WFS (or WMS/WMTS) web services. The long-term vision for Data Broker is to provide a central interface for filtering, conflating, and brokering all requests to any OGC web service to simplify queries by a client and implement secure connections based on business rules functionality. For the scope of Testbed 12, the Data Broker must satisfy two requirements:

Additionally, the following requirements are derived or assumed from Testbed-12 meetings: * Use of CSW is required for endpoint and feature discovery; and * Use of semantic mediation is of interest to the sponsors.

Luciad was selected to provide the Data Broker for Testbed 12, building off their implementation in Testbed 11.

The Data Broker provided by Luciad has the following functionality.

The Luciad Data Broker is based on Java Servlet technology. To run, it requires a Java servlet container or application server compatible with Java Servlet 3.0 or higher. Apache Tomcat 7 has been used by Luciad during Testbed 12. Other than being capable of running a Java Virtual Machine 1.7 (or higher) and an appropriate servlet container / application server, no requirements are posed on the underlying hardware or operating system.

The Luciad Data Broker for Testbed 11 was built based on WFS 2.0 specification. For Testbed 12, the requirements include investigation in implementing additional features that are not part of the WFS 2.0 specification. For example, the inclusion of a URL in which the client may use to request a map from a Web Map Service (WMS).

Additional challenges were met when considering how to semantically search across multiple WFS of differing data models. In the demonstration use cases, one WFS contained AIXM data while the other contained AMXM data. Both data sets contain aerodrome information, and the client requests all aerodrome information for an area defined by a geospatial filter query. The Data Broker must be able to implement a data transformation chain to convert AMXM to AIXM (or vice-a-versa) and return the entire feature sets back to the client.

The Luciad Data Broker implements the following capabilities.

Existing SWIM registries developed by the FAA and Eurocontrol are based on the Drupal content management system and incorporate concepts from the Service Description Conceptual Model (SDCM). However, they do not currently support spatial queries and do not readily accommodate OGC service descriptions.

Section 4.5 in Appendix B of the RFQ is concerned with advancing the use of catalog services in the aviation domain. Several functional requirements are presented:

The following figure is a simple UML component diagram summarizing the CSW-ebRIM interfaces.

A CSW-ebRIM implementation can process the service requests summarized below, most of which are common to all CSW-based catalog services.

The component provided for this thread is a complete implementation.

The catalog component exposes HTTP service endpoints as specified in the CSW-ebRIM specification. The implementation is Java-based and requires a Servlet container such as Apache Tomcat. It can be deployed in any operating environment for which the Java Development Kit (JDK) 8 is available.

The initial expectation was that the catalog would also harvest metadata from existing SWIM registries provided by FAA (NAS Service Registry/Repository - NSRR 2.0) and Eurocontrol. However, an API remains under development so no harvesting mechanism was available during the testbed.

Key accomplishments are listed below.

The Testbed 12 Aviation Client is built on top existing LuciadLightspeed Commercial Off The Shelf (COTS) components. The Testbed 12 Aviation Client is a continuation of the Aviation Client built for previous years, capable of connecting to various OGC Services and many file formats required by the thread.

The Testbed 12 Aviation Client requires the following functionality:

The Luciad Aviation client provides the following functionality to support the Aviation thread in Testbed 12.

All development is done in Java, using the Java Development Kit (JDK) 1.7. The client application is developed on top of Luciad’s COTS product LuciadLightspeed. The software runs on any operating system for which a Java Virtual Machine 1.7 or higher exists. For the 3D visualization, a graphics card with support for OpenGL 1.2 or higher is required.

The main challenges for Testbed 12 Aviation Client were the integration and workflow architecture with the various services offered in the thread. The Aviation Client has to be able to make connections to WFS, WMS, FPS and catalogue services, as well as the Data Broker component service. For these protocols, the aviation client needs to be able to parse, decode and visualize the FIXM 4.0, AIXM 5.1 and AMXM formats.

For some aspects of the demo scenario, we also have also added the ability to create and upload FIXM 4.0 trajectories on the fly to a transaction WFS service.

The key accomplishments for Luciad’s Aviation client component in Testbed 12 include:

Previous work in OGC testbeds on asynchronous message delivery has been prototyped into existing Aviation clients (e.g. Luciad). As the requirements for this testbed were very specific on the underlying technology, 52°North was selected to develop a client that is able to interact with the Asynchronous messaging server.

The Asynchronous Aviation Client requires the following functionality:

Aviation Client for Asynchronous Messaging (52°North aviationFX) is the client component for interfacing with the JMS/AMQP server (F009). It is expected that the client will be implemented based on OGC PubSub 1.0 standard guidance as an exploratory effort to study publish/subscribe messaging patterns on OGC queries and data. It is assumed that that use of Flight Information Exchange Model (FIXM) data will be utilized for live update event-based messages. The client will receive messages based on a subscription query with the Asynchronous Messaging Server.

The client has been developed using Java 8 (including JavaFX) and is therefore deployable on all platforms that support Java. There are no more specific requirements.

The main challenge was to set up a client that is capable of interacting with an OGC PubSub 1.0 server (in particular its SOAP binding extension). As this specification is rather new, no best practice documents and the like were available. In addition, the creation of an intuitive user interface that allows the subscription to interesting streams of data was a challenging efforts. In particular, streamlining this with the concepts of OGC PubSub 1.0 (such as Publications and Delivery Methods) required a few test runs.

The Aviation Client for Asynchronous Messaging has been developed and tested against the Asynchronous Messaging Server [F009].

In particular the following aspects have been accomplished:

Previous work in OGC testbeds on asynchronous messaging servers focused on the implementation of the OGC Event Service (OGC 11-088r1). Recently, the requirements for message dissemination methods in the Aviation domain have been sharpened (in particular usage of the AMQP 1.0 protocol). In addition, the OGC has released the Publish/Subscribe (PubSub) 1.0 specification. These two new aspects build the foundation for a new Asynchronous Messaging Server for Aviation.

52°North has been selected to develop the Asynchronous Messaging Server.

The requirements for the Asynchronous Messaging Server have been defined as follows:

A stretched requirement is the integration of the Harris Data Exchanged (DEX) service as both a source for data publishing as well as for delivering messages.

JMS/AMQP Asynchronous Messaging Server is the component responsible for handling events-based messaging compliant with the OGC PubSub 1.0 specification. The server will consume events based publications from data sources, and based on OGC stored subscription queries, will distribute the messages using a JMS or AMQP binding. It is also expected that the use of FAA NEMS, represented by the Harris DEX product, could be utilized as a stretch requirement to demonstrate an operationally compatible solution using the OGC PubSub 1.0 specification. Figure 3 below depicts the architecture for the Asynchronous Messaging interaction with a PubSub 1.0 client as well as through the Harris DEX.

52°North has developed an OGC PubSub 1.0 service (52°North subverse) using Java 8. It can be deployed to common Application Containers such as Tomcat, JBoss or Jetty. There are no more specific requirements.

The main challenge was to set up a server that implements the OGC PubSub 1.0 specification (in particular its SOAP binding extension). As this specification is rather new, no best practice documents and the like were available. An additional challenge was the implementation of the AMQP 1.0 layer for message delivery as common libraries (e.g. Apache Qpid) are rather limited in the documentation of implementation specifics.

An additional challenge was the integration of the Harris Data Exchange (DEX) service as a source for data streams. The DEX is a message brokering service that is in production within the FAA SWIM architecture. It supports JMS and AMQP as the message delivery protocol. In particular, the header-based routing that is used to identify the correct client destinations within DEX required a few test runs and adjustments.

In particular the following aspects have been accomplished:

The AMXM consists of the AMXM UML Model and a derived AMXM XML Schema. The schema is a ISO/OGC GML 3.2 specification for AMDB data exchange. It enables the sharing of AMDB data in accordance with EUROCAE / RTCA requirements. In combination with OGC Web Feature Service (WFS) it may be used to build SWIM information services for AMDB data. The AMXM is in a mature state of development and ready for publication.

The scope of Testbed 12 was to deploy an AMXM 2.0 WFS 2.0 within the data access tier of the aviation architecture for use in the Data Broker use case.

Data available from the AMXM 2.0 WFS is transformed from its original source format, AIXM 5.1.

The AMXM WFS provided by Snowflake Software has the following functionality:

The Snowflake Software AMXM WFS uses COTS software to provide a mapping from database schema to AMXM 2.0 format. This mapping is used in the deployment of a read-only WFS 2.0. The WFS is deployed on a Snowflake Software hosted demonstration server on an Apache Tomcat application server and is secured using HTTP basic access authentication. Each user accessing the WFS service is provided with a username and password. The data provided by the AMXM 2.0 WFS originates from AIXM 5.1; data transformation is based upon AIXM 5.1 to AMXM 2.0 transformation rules provided by Eurocontrol.

As the services are standard OGC compliant services and unambiguous AIXM 5.1 to AMXM 2.0 conversion rules were provided by the sponsor, no challenges were posed during setup and deployment of the AMXM 2.0 WFS 2.0.

Accomplishments for Snowflake Software’s AMXM WFS include:

The OGC-compliant WFS-TE (Web Feature Service Temporality Extension) is an aviation data repository responsible for AIXM 5.1 data management, both static documents and dynamic data such as Digital NOTAM messages. The WFS-TE service endpoint is an implementation of the OGC WFS Transactional 2.0 with additional functionalities for dealing with temporality aspects of aviation entities in accordance with the AIXM 5.1 temporality model (beyond the GML 3.2 temporality).

In Testbed 12 the AIXM WFS-TE component will demonstrate WFS Temporality Extension queries as well as serve AIXM data for the Data Broker use case.

The m-click.aero WFS-TE component supports special temporality functions as described in the WFS Temporality Extension document used for the AIXM 5.1 data management.

Additionally, the m-click.aero OGC WFS Transactional 2.0 component provides standard CRUD (create, read, update, delete) data management functions based on the WFS-T 2.0 service endpoint specification. The component supports all aspects and fulfills every requirement from the official OGC WFS-T specification.

The WFS-TE service consists of subcomponents as depicted in the following figure.

The WFS-TE implementation is based on the synchronous request-response message exchange pattern. Basically, the component is activated by an incoming data request call (query request). Further processing is performed in accordance with following activity diagram.

The m-click.aero WFS is implemented based on an OGC compliant WFS data repository called deegree. The WFS runs as a Java EE web application that is bundled with a Java EE 7 compliant Web Container, which implements the Java Servlet specification. The WFS-TE is deployed on an m-click.aero hosted demonstration server.

Additionally, for purposes of access control and security a dedicated HTTP server is placed in front of the Java web container as protective reverse proxy. Each user accessing the WFS-TE service is provided with a username and password.

The deegree based solution stack is also augmented with an additional, unique m-click.aero component, responsible for dealing with WFS dynamic feature queries based on the Temporality Extension for AIXM 5.1 (OGC discussion paper). This extension helps WFS clients deal with the intricacies of the AIXM Temporality Model when requesting AIXM data.

No challenges for WFS-TE in Testbed-12.

FIXM is an exchange model capturing Flight and Flow information that is globally standardized. FIXM is the equivalent for the flight domain, of AIXM and WXXM, which were developed to achieve global interoperability for AIS and MET information exchange respectively.

Built on a foundation of OGC and ISO standards, AIXM and WXXM have demonstrated that significant barriers to adoption (for example, complexity and cost of custom system builds) can be mitigated through engaging with the wider open standards community and reusing best practice patterns for application schema design and service delivery.

At the data level AIXM and WXXM share common types and patterns from ISO 19136 Geography Markup Language (GML) making them interoperable between each other as well as saving cost and time through the reuse of globally implemented types such as feature models and geometry. Being built on such a globally adopted standard as GML, AIXM and WXXM are compatible with existing tools as well as being understandable by communities across the globe.

The result has been a switch from industry specific custom software builds to off-the-shelf technology choices and with that a dramatic reduction in implementation cost. At the service level, standards such as the Web Feature Service (WFS) provide standards based web services to replace what was once a series of custom-built silo services.

Testbed 12 seeks to harmonize FIXM with AIXM and WXXM by extending it from GML. By doing so, data and service-level interoperability and standardization will be demonstrated through the component delivery of a WFS 2.0 serving GML-compliant FIXM data.

Testbed 12 seeks to integrate GML elements with FIXM for compatibility with OGC web services, in order to demonstrate the data and service-level harmonization and interoperability can be realized in FIXM, as it has been in AIXM and WXXM. To achieve this goal, FIXM will be extended from GML, reusing ISO 19136 (GML) types where applicable - thus harmonizing with AIXM and WXXM.

The FIXM WFS provided by Snowflake Software has the following functionality:

The Snowflake Software FIXM WFS uses COTS software to provide a mapping from database schema to FIXM (GML compliant) format. The mapping is used in the deployment of a read-only WFS 2.0. The WFS is deployed on a Snowflake Software hosted demonstration server on an Apache Tomcat application server and is secured using HTTP basic access authentication. Each user accessing the WFS service is provided with a username and password. The data provided by the FIXM WFS originates from FIXM 3.0.1 provided by Harris Corporation.

As the services are standard OGC compliant services no challenges were posed during setup and deployment of the FIXM 2.0 WFS 2.0 once a GML compliant version of FIXM was developed.

Accomplishments for Snowflake Software’s FIXM WFS include:

The OGC compliant WMS/WMTS/WCS service is a data repository responsible for providing background data to the testbed and its scenario.

The requirements for F007 include the availability of a service that features mapping data, to be used as background imagery for any demonstrations given during the testbed. The WMS/WMTS service features data such as satellite imagery, or airport layouts that can be retrieved as maps using BBOX queries. The WCS service features satellite imagery.

The services have been developed using Java 7 and is therefore deployable on all platforms that support Java. There are no more specific requirements.

As the proposed services are standard OGC compliant services, no challenges were posed during setup and deployment of the services.

List of accomplishments:

Catalog (and registry) services play an essential "matchmaker" role in a service-oriented architecture, enabling resource producers and consumers to interact without possessing prior knowledge about service capabilities and endpoints.

Within the aviation domain, the catalog role is fulfilled by a SWIM-compliant registry. However, existing SWIM registries currently under development by the FAA and Eurocontrol do not store spatial information about registered items and therefore are unable to support geospatial queries. Furthermore, they cannot readily accommodate OGC service descriptions.

This report explores the prospects for enhancing SWIM registries by a) integrating OGC catalog functionality, and b) accommodating OGC service descriptions. The technical content of this report covers two main topics:

In the same way that one cannot stroll into a library and just pluck a desired book off a shelf, discovering and accessing services and data of interest in an operational environment generally requires the use of a catalog or registry service. This report describes how catalog services can help to enable the realization of complex workflows and to make SWIM registries more accessible to a broader community of users.

Key accomplishments are listed below.

Implementing the OpenSearch GeoTemporal extensions is probably the easiest way to enable a spatial search capability for a SWIM registry. However, this falls short of complying with any OGC catalog standard. Implementing a CSW adapter for the SDCM information model would be one way to accomplish this, and restricting it to read-only interactions would reduce implementation effort. The goal of such an undertaking would be to achieve a "Basic" level of conformance.

The Data Broker Specifications Engineering Report authored in OGC Testbed 11 defined a WFS-based architecture to aggregate AIXM 5.1 data served by multiple WFS providers. In Testbed 12, the Data Broker research continues with a set of additional problem statements.

The Data Broker ER builds on top of the Data Broker Specifications ER authored in OGC Testbed 11 and defines an architecture to address the new problem statements. The figure below shows the high-level architecture of the Data Broker in Testbed 12. For each problem statement, approaches are evaluated in the ER based on functional requirements, interoperability aspects and feedback gathered through implementation experiments.

Modern-day geospatial architectures consist of a multitude of geospatial services, each dedicated to serve a specific data type to its users. This often comes with separate services to cover different areas of interest, leading to additional complexity for the user.

The Data Broker addresses this complexity by acting a single endpoint, in a hierarchy of OGC services with heterogenous data.

The business value is that using a Data Broker can drastically simplify the workflow required to look for, request and visualize data from the perspective of a client. This has a benefit for both architecture designers looking for a way to offer a set of services as a single endpoint, as well as client developers who will be able to write simpler applications with less coupling between it and the various OGC services involved in the architecture.

Aligned with the Data Broker’s problem statement, the following topics have been researched for the ER.

To support these research topics, an implementation of the Data Broker has been made during Testbed 12, building on top of the existing implementation developed in Testbed 11.

The results of the research and implementation experiments show that the new problem statements can be addressed in an extended Data Broker architecture. There have been a number of challenges, resulting in the following considerations and recommendations.

Asynchronous message dissemination played an important role in previous testbed’s Aviation threads. However, no standard is available that targets the specialized requirements of the OGC world and the geospatial domain in general. In addition, no interoperable and modern approach for the actual dissemination of data messages was available.

The Asynchronous Messaging ER therefore targets the following problem statements.

The Asynchronous Messaging for Aviation Engineering Report focuses on the design of an architecture to create an asynchronous messaging layer between different Aviation components such as clients, data provider instances and Data Brokers. In order to achieve interoperability among these components, the OGC PubSub 1.0 Specification forms the basis of this architecture. The design of this architecture will cover methods for subscribing for specific subsets of data (e.g. FIXM Flights intersecting a given Airspace), managing such subscriptions as well as publishing data to Aviation Asynchronous Service instances. Different delivery patterns such as AMQP, JMS and OASIS WS-Notification are considered. In particular, their harmonization with the PubSub 1.0 specification is evaluated. Figure Overview on the Asynchronous Messaging Architecture illustrates the high-level architecture of asynchronous messaging.

ATM data as well as Flight data changes frequently. In order to achieve an efficient and reliable publication of these changes, a pull-based approach using classical request/response web services is not sufficient.

The design of an asynchronous messaging architecture which is based on the OGC PubSub 1.0 standard and combines industry-established technologies such as AMQP 1.0 and Web Services Notification overcomes this gap and eases integration. By following a standards-based approach, an interoperable solution is available which, besides the Aviation domain, can be easily transferred to other fields that require near-real time, push-based data dissemination.

In order to address the above mentioned problem statements, the following work has been conducted.

The overall goal of designing and establishing a asynchronous messaging system has been achieved with the above described technologies. By defining an AMQP 1.0 profile for OGC PubSub 1.0, the solution is also made interoperable. However, additional work could be carried out on the following aspects:

The Guidance on Using Semantics of Business Vocabulary and Business Rules (SBVR) Engineering Report authored in OGC Testbed 11 described a vocabulary with a profile of core geospatial terms and concepts, which can be used to express geospatial constraints in business rules. The SBVR ER applies this vocabulary to capture rules that identify operational constraints based on aircraft characteristics and the infrastructure characteristics, including the actual status.

The SBVR standard is the base for writing AIXM business rules. They complement the structural rules that can be captured in the AIXM schemas, which are technically limited. The set of validation rules is not yet complete, and its expressiveness highly depends on the available vocabulary. The ER analyses the requested validation use cases, formulates suitable SBVR rules for them, and identifies possibilities and limits of the current vocabulary. It further documents how the existing toolset of SBVR processors (ShapeChange and m-click.aero’s AIXM Validator Service) was extended to support the spatial operators proposed in Testbed 11.

The validation of AIXM 5.1 data is important for ensuring data quality. Due to its complexity, both on technical level and domain model, it’s important to use a SBVR as a language that is both human-friendly and machine-readable. This ER advances the AIXM Business Rules based on SBVR by analyzing validation use cases that weren’t previously evaluated.

The following use cases were analyzed, and if possible, an SBVR rule formulated:

Further, the following tools were extended to support SBVR spatial operators:

The ER demonstrates that SBVR for AIXM validation benefits from an extended vocabulary as provided by the proposed spatial operators, and proves that their implementation in existing software is possible. However, some of the analyzed use cases revealed that the complexity of the domain model leads to very complex SBVR rules, that a very hard to write and understand, and sometimes even impossible to formulate. Further research is necessary to address these limitations.

Information security is the state of being protected against the unauthorized use of information and services, or the measures taken to achieve that. In the domain of aviation, within the system wide information management (SWIM), numerous services and data that need to be protected are exposed as OGC OWS compatible, SOA conformant web service endpoints. While the aviation modernization programs in the USA and the EU (NextGen, SESAR) have already defined security frameworks for modern aviation services, the Testbed-12 aviation architecture remains focused on its functional aspects letting the cross-cutting concerns such as information security to be evaluated somewhere else. It is the task given to this engineering report to provide an overview of possible security options, to apply the Testbed-11 recommendations regarding the OGC OWS security on the Testbed-12 Aviation Architecture, and to propose advanced security concepts related to identity management and geospatial based access control.

The document provides short introduction into the major elements of information security considering the related work preformed during the aviation modernization programs in the USA, the EU, and by ICAO. The methods of information security with concepts applicable to the OGC compatible aviation web services are presented in the form of security functions such as confidentiality, integrity, and availability. Terminology and categorization has been taken from Testbed-11 recommendations and is based on the ISO standards. The report highlights the differences between transport and message based security, puts them in the relation with communication message exchange patterns, and explains how those concepts are currently applied in the aviation domain. Finally, the focus is put on the digital identity management, as well as access right control with security policy enforcement based on geospatial attributes with GeoXACML

Geospatial enabled access control and approaches for securing OGC OWS services, as well as identity management methods proposed in this report greatly improve the overall security of aviations services and enable interoperability among regional and global aeronautical traffic management stake holders.

For the concrete case of aviation architecture in the Testbed 12, this engineering report has provided an overview of and proposal for the security architecture based on the security relevant outcomes from previous engineering reports. The testbed’s architecture originally doesn’t specify any security requirements. Based on some operational examples (FAA SWIM and SESAR SWIM) and a couple of preconditions, constraints and requirements have been made in order to distinct between several architectural options.

For security implementation in aviation, the researchers came to conclusion that the most efficient single organizational domain based solution would be network level security (VPN), but it is questionable whether such architecture would be applicable for integration between multiple organizational domains (for example in case of global SWIM integration based on federation and considering the existence of numerous aviation service providers and consumers operating from distinctive security domains). On the other side, brokered identity management and security functions applied on the message level represents the most flexible solution with trade-off in complexity and security. Application of security functions on the transport level, such as the TLS, seems to be the compromise between network and message approaches. Use of PKI infrastructure authentication and confidentiality could easily be established, but such a solution lacks in end-to-end security. Still, this option is the most frequently used in the published internet and fits well with OGC OWS service endpoints based on HTTP POST approach (for end-to-end security, OGC service endpoints must be secured on the message level using a SOAP extension mechanism). Finally, an access control approach based on geospatial features is possible for geospatial services and resources from the aviation domain. Such an approach could be implemented using the concept of declarative security policies and utilizing the OGC GeoXACML.

WSDOM is a formal ontological model based on OWL-S that is being developed by FAA for use in building applications that process and exchange web service information. It can be utilized to create, manage and query/discover service metadata instances using semantic technology. While it provides good basis for extensions and already contains some examples for concepts specified in the FAA Service Taxonomy, the ontology doesn’t contain enough metadata, for example to fully classify services according to the taxonomy or to express their geospatial properties.

This ER analyses the options for improvements of semantic description for (OGC compatible) web services with a focus on the aviation domain. It evaluates different options for further utilization of semantic technology to classify, describe, and discover OGC OWS compatible aviation services.

Geospatial enabled service discovery as proposed in this ER together with advanced semantic technologies, such as axioms and reasoning, improves the expressiveness of service catalogues and contributes to the interoperability among distinctive, regional, national, and global service catalogue formats, service providers, and consumers.

This ER provides briefly explanation of aviation domain and services, lists stake holders and aviation use case(s), and provides an overview into the service catalogues created as part of aviation modernization programs in the USA and the EU. It has evaluated approaches for semantic service discovery based on the FAA WSDOM ontology and demonstrated the application of FAA Service Taxonomy and OGC gGeoSPARQL on the service description methodology. Finally, the report has proposed an application’s solution stack and performed an investigation about how the semantic approach fits into overall service registry and repository infrastructure proposing possible integration scenarios.

WSDOM ontology based on the OWL-S provides basis to develop semantic service descriptions and operate service metadata repository based on semantic technology. The enhancements proposed here (together with those yet to be identified as part of future investigations) will eventually enable successful operational use adding missing concepts from the aviation domain. Service discovery is all about reasoning over and querying of semantic data. The fact that WSDOM schema has been created using OWL actually implies that SPARQL shall be used to express queries for service discovery. This ER has demonstrated a couple of such queries in conjunction with FAA Service Taxonomy. Using the FAA Service Taxonomy classification and GeoSPARQL extension it was possible to achieve basis for the service discovery of the same or better quality as it was the case with standard service catalogues having better extensibility capabilities. It is especially true for the semantic discovery approach based on axioms and reasoning. Thus, several important activities remain to be done in order to gain full ontological power required for efficient semantic service discovery beyond the standard approach based on pattern matching and attribute values.

The Flight Information Exchange Model (FIXM) resides within a family of ATM exchange models including AIXM and WXXM. Both AIXM and WXXM are based upon GML, whereas FIXM is based upon XML - this inconsistency contributes additional implementation costs. Aligning FIXM with AIXM and WXXM by basing it upon GML provides implementation benefits at the data, service and application levels.

Testbed 12 aims to advance the discussion of GML integration into FIXM by building upon previous OGC IP initiative and FIXM stakeholder inputs. The GML integration process will be documented in the FIXM GML ER, whilst a WFS deployment serving a GML compliant version of FIXM will act as a technical proof of concept.

FIXM is an exchange model capturing Flight and Flow information that is globally standardized. The need for FIXM was identified by the ICAO Air Traffic Management Requirements and Performance Panel (ATMRPP) in order to support the exchange of flight information as prescribed in Flight and Flow Information for a Collaborative Environment (FF-ICE). FIXM is the equivalent, for the Flight domain, of AIXM (Aeronautical Information Exchange Model) and WXXM (Weather Information Exchange Model), both of which were developed in order to achieve global interoperability for, respectively, AIS and MET information exchange. FIXM is therefore part of a family of technology-independent, harmonized, and interoperable information exchange models designed to cover the information needs of Air Traffic Management.

The OGC Testbed 12 FIXM Engineering Report seeks to harmonize FIXM with AIXM, and to permit the exchange of FIXM via a WFS. Testbed 12 seeks to build upon previous OGC IP initiatives and to demonstrate the integration of the ISO/OGC standard GML in a manner that meets the requirements of the FIXM community. Work undertaken in previous OGC IP initiatives seeks to integrate GML to FIXM via a model-driven approach.

Built on a foundation of OGC and ISO standards, AIXM and WXXM have demonstrated that significant barriers to adoption (aka, complexity and cost of custom system builds) can be mitigated through engaging with the wider open standards community and reusing best practice patterns for application schema design and service delivery. At the data level AIXM and WXXM share common types and patterns from ISO 19136 GML making them interoperable between one another as well as saving cost and time through the reuse of globally implemented types. At an application level, being built on globally adopted standards like GML, means AIXM and WXXM are compatible with a plethora of existing tools as well as being understandable by a global community. The result has been a switch from industry specific custom software builds to off-the-shelf technology choices and with that a dramatic reduction in implementation cost. At the service level, standards such as the Web Feature Service (WFS) provide standards based web services to replace what was once a series of custom-built silo services. This interoperability and openness is at the heart of the net-centric vision of SWIM.

To implement GML in FIXM whilst maintaining a compact data encoding, the following areas have been investigated:

The engineering report provides a set of recommendations for FIXM based on the FIXM 3.0.1. These recommendations were further developed into Change Requests which are expected to be brought forth to the FIXM Change Control Board (CCB) to be voted upon and enacted as changes for future versions of FIXM.

Currently, NOTAMs contain free text in a legacy format that requires a human to decipher. With the introduction of Digital NOTAMs, stakeholders are trying to determine a methodology to transfer the fluidity of free-text NOTAMs into a machine-readable format. NOTAMs are often generated without graphical verification resulting in incorrect depiction of NOTAM boundaries in pilot briefings. NOTAMs also violate FAA policy by remaining active beyond an expiration, or are created to depict a non-temporary restriction that should be represented in another format.

A real TFR NOTAM was used for this demonstration, taken from the FAA NOTAM website. The image below depicts the TFR NOTAM for aerial fire-fighting on the FAA NOTAM website.

The NOTAM was transferred from legacy format to digital AIXM format and loaded into the WFS-TE service. This service then allows the m-click.aero validation service to process FAA policy in the form of business rules. These business rules are encoded in Semantic Business Vocabulary and Rules (SBVR) format, an OMG standard. The business rules are then converted to Schematron format, and then used to validate the NOTAM data.

The result is the validation of the TFR NOTAM graphically, while ensuring validation prior to submission. The firefighting TFR NOTAM can now be submitted to the FAA with confidence.

Currently, flight plans are developed without verification and then submitted via either the Aeronautical Fixed Telecommunications Network (AFTN) or the Aeronautical Message Handling System (AMHS), both of which precede SWIM. These services are only message handlers and require alternate means to verify the flight plans. Flight plans currently are in ICAO FPL2012 format, and do not correlate aeronautical data in a machine-processable manner. The flight plan identifiers tend to be correlated to an aircraft ID which is not unique and may be re-used multiple times a day, making it difficult to identify a single unique flight.

In this scenario, service discovery is demonstrated for all services containing the relevant information for flight planning. A direct request to AIXM WFS-TE is made to retrieve features containing aeronautical geometries and constraints for relevant to a flight plan. By using the FIXM flight plan information containing the temporal information for active flight time, the route of flight can be used to query for any TFR NOTAMS within the constraints of the route and time. The FIXM schema was modified to include a minimal set of GML elements such that the information can be made available via a WFS. This enabled the correlation of the route information to the aeronautical information geography. The image below shows the result of the query using the WFS-Temporality Extension service which enables additional temporal query parameters. The image below shows the TFR based on the route of flight.

The results are compared to the current planned flight plan to determine an optimal flight plan trajectory. Then the flight plan is submitted to FAA and a direct request to FIXM WFS is made for the submitted flight plan as a query on the Globally Unique Flight Identifier.

Currently, aviation is in a transition period in which some pilots are able to retrieve digital pre-flight briefings, while others must call into an FAA service operations desk to get briefed by an operator. However, electronic pre-flight briefings may not have the latest information due to information delay, and this information is subject to change once in-flight.

In Testbed 12, the Data Broker was augmented with a WMS service along with its already existing WFS service. This service provides the ability to orchestrate a conversion of WFS retrieved XML data into a graphical image for display to the pilot. The figure below depicts the architecture of the Data Broker.

First, the pilot enters the flight GUFI and the data broker is able to retrieve the flight information and route.

Next, the data broker determines the departure and arrival airports and uses the embedded Xlink information to retrieve corresponding aeronautical geography from other WFS services. In this case, the departure airport is KSFO and the arrival airport is KATL. The WFS containing KSFO data is in AMXM format. The data broker is orchestrated to convert AMXM formatted data to AIXM format. The next figure shows the KSFO runway information with the lineage information and provenance showing that it was 'Transformed from AMXM 2.0'.

The data broker can then retrieve the KATL data in AIXM format.

Finally, all this information is converted to a graphical image by the WMS service and displayed to the pilot.

FAA SWIM provides publish-subscribe data feeds in the Java Message Service (JMS) protocol. This protocol was abandoned by the European aviation community due to lack of wire-level control over the messaging. AMQP was adopted, but no operational SWIM services have yet been deployed with AMQP 1.0. Messaging protocols only provide a means for transporting the data, but a means for managing the subscriptions and content has yet to see widespread adoption. The OGC PubSub 1.0 specification enables content management and subscription management in a publish-subscribe pattern with any protocol binding desired.

In this scenario, a client is connected to the Harris DEX service, which represents the FAA SWIM NEMS. The figure below depicts the messaging flow.

The 52North aviation client, AviationFX, is used to demonstrate setting up a subscription.

In this way, the airline operations center facility in San Francisco threatened by fire can be migrated to the Los Angeles location, and the subscription filters can be reconfigured to include both the San Francisco and Los Angeles areas.