To test and demonstrate work performed under the above tasks, one or more scenarios will be developed, refined and used as high-level objectives for organizing the work in the Aviation Thread and as the basis for the final demonstrations of the results. The scenario(s) will exercise a variety of web services utilizing the AIXM and FIXM encodings. With respect to data sources:

Existing data sources should be used to the extent possible to test the requirements and support the thread scenarios.

The following sections define the requirements for the OGC Testbed 10 Aviation Thread.

Note: a general requirement for all service components used in OGC Testbed 10 Aviation is that the service provider shall deliver a WSDL description of the deployed service instance(s), for subsequent publication in the SESAR SWIM Registry.

Several documents referenced in the Aviation Thread are not publicly available, but available upon request. To receive these documents, send an email to techdesk@opengeospatial.org and the documents will be sent along with direction that the receiving organization is not permitted to send the document to any third parties without prior approval. Additionally, the receiving organization must abide by the Intellectual Property Requirements listed in the documents.

The Federal Aviation Administration (FAA) and EUROCONTROL, in conjunction with multiple other international partners as well, are currently in the process of developing the Flight Information Exchange Model (FIXM). FIXM is an exchange model capturing Flight and Flow information that is globally standardized. The need for FIXM was identified by the International Civil Aviation Organization (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.

Previous OGC IP initiatives developed an architecture that supports the exchange of AIXM and WXXM data. It is time to test and validate the exchange of flight information based upon the emerging FIXM standard within this architecture.

OGC Testbed 10 Requirements

The Aviation Thread of OGC Testbed 10 will advance the interoperable management and dissemination of aeronautical and flight information within the system.

Note: the first FIXM version deemed to be sufficiently mature enough and complete enough for global use is FIXM v3.0. Since FIXM v3.0 will not be available until Aug 2014, OGC Testbed 10 may need to modify (improve and/or fix) FIXM v2.0 so that the version of FIXM used in the testbed is sufficient to support OGC Testbed 10 use cases and scenario(s). Drafts of FIXM v3.0 may be made available during the testbed, which can be used for testing and development if all relevant participants and the Thread Architect agree to do so.

Support queries for AIXM and FIXM feature data.

Support creation, update and – if possible – deletion of AIXM and FIXM data.

Note: the most relevant FIXM feature type for this Testbed probably is the Flight.

Automatically generate a notification at WFS-T when aeronautical and flight information changed at the service (created, updated, deleted), and send this notification to the Event Service. Which events need to be detected will be determined and agreed during the testbed. It is expected that a limited set of events will be needed to support the demonstration scenario.

The exact encoding of FIXM updates will be determined during the testbed.

Basic filtering functionality defined by the Event Service (more specifically WS-Notification - see 1.6.2) is achieved via XPath based filtering of the XML encoded message. More advanced filtering supporting the OGC Filter Encoding Specification has been realized in previous OGC IP initiatives (for example OWS-8 and OWS-9). Support for XPath filtering is required. More advanced filtering functionality is of interest but not required.

Notification of clients (for any message with AIXM/FIXM data that matches their subscription criteria).

Support discovery of flight and other metadata via the CSW ebRIM Registry, more specifically:

Develop ebRIM models required to capture service and dataset (AIXM, FIXM) metadata relevant for the demonstration.

Harvest and load relevant metadata, as required to support the demonstration

Verify and validate (through tests and demonstrations) 1) the FIXM design and 2) the capability of the OGC Aviation Architecture to support interoperable exchange of FIXM data, and document the results (especially any improvements for FIXM).

Document potential enhancements and identified issues for relevant documents and references. For OGC documents, change requests (especially for Standard and Best Practice documents) will be created.

ICAO SARPS require the States to provide their electronic terrain and obstacle data (eTOD) in digital datasets. The datasets should provide eTOD with different numerical requirements defined by ICAO Annex 15 for 4 specific areas:

Area 1 - the territory of State

Area 2 - around the aerodrome up to 45 km, subdivided in 4 areas

Area 3 - around aerodrome movement area

Area 4 - strip before CAT II/III RWY

More information is available on the EUROCONTROL homepage (Terrain and Obstacle Data).

The ADQ defines additional requirements related to terrain data.

Currently there are many different formats to represent obstacle and terrain data. Obstacles are represented using AIXM. For terrain, however, there are a multitude of formats widely used today that do not completely satisfy ICAO and ADQ requirements (in particular for metadata - ISO 19115). EUROCONTROL has analyzed user and data originator preferred formats for terrain data in order to establish a list of commonly preferred terrain formats (see references from the TODWG).

It is of interest to the aviation community to have seamless terrain data throughout the region and not the terrain datasets ending at national borders. At present, due to the different national geodetic systems, there are issues with seamless integration of cross-border terrain data for Area 1 (sometimes Area 2 if an aerodrome is located close to the border).

As more and more states start providing their eTOD data there is also a growing interest in the possibility for web-based access to eTOD data in an INSPIRE compliant way.

OGC Testbed 10 Requirements

The Aviation Thread of OGC Testbed 10 will perform an assessment of the exchange of terrain data between states, including but not limited to:

Identification of possible formats - that are compliant with ICAO Annex 15 and ADQ requirements - for the exchange of terrain data.

Identification of possible ways to overcome the cross-border differences in terrain data due to differences in national geodetic systems and provision of seamless terrain data.

Investigation of possibilities for web-based access to eTOD data in an INSPIRE compliant way.

Documentation of potential enhancements and identified issues for relevant documents and references. For OGC documents, change requests (especially for Standard and Best Practice documents) will be created.

Note: the realization of an actual service infrastructure for and demonstration of terrain data exchange is not required. However, the Aviation sponsors welcome prototype implementations that realize (parts or all of) the recommendations for exchange of terrain data resulting from the assessment.

In 2004, the NOAA’s National Weather Service (NWS) created its Digital Services Program to meet their customers’ increasing need for digital weather, water, and climate services. The foundation of this program is the National Digital Forecast Database (NDFD). NDFD is a set of gridded forecasts of sensible weather elements. It contains a seamless mosaic of digital forecasts from NWS field offices working in collaboration with the National Centers for Environmental Prediction (NCEP). A companion to NDFD is the National Digital Guidance Database (NDGD) which contains guidance forecasts in gridded formats that are interoperable with NDFD.

NDFD and NDGD have offered an unprecedented opportunity for the NWS to automate, modernize, and improve products and services to meet the needs of their customers and partners. Users can download forecast grids that are encoded in the WMO’s FM-92 GRIB Edition 2 (GRIB2). Customers and partners can also access NDFD/NDGD data that have been formatted in Digital Weather Markup Language (DWML), an NWS-specific dialect of XML, via a web service that supports Simple Object Access Protocol (SOAP) and Representational State Transfer (REST).

This NDFD web service services millions of hits each day. Unfortunately, it is not OGC compliant. None of the established service models appears to fully support the functional requirements. The closest match seems to be Web Coverage Service (WCS). In response to this gap, the NWS has developed the Web Gridded Document Service (WGDS).

The WGDS implements a service model that is reminiscent of the Web Coverage Service (WCS). i.e., the WGDS responds to operations similar to getCapabilities, describeCoverage, and getCoverage. The following differences are noted between WGDS and WCS:

The response from a WGDS getCapabilities request includes a list of available products.

A WGDS describeCoverage request identifies a product and also a (list of) point location(s), instead of a (list of) coverage identifier(s). The describeCoverage response contains a list of available weather elements, time constraints, and a list of supported output representations/formats (WXXM, DWML).

The user chooses the weather elements as well as point locations he is interested in and provides them as parameter in the WGDS getCoverage request, along with time constraints, the desired product and representation/format. The response contains

OGC Testbed 10 Requirements

OGC Testbed 10 will analyze the WGDS and incorporate it in the Aviation architecture. More specifically, OGC Testbed 10 will:

Analyze to which extent WGDS functionality, models and operation parameters map to elements of the WCS 2.0 model and the GML Application Schema for Coverages. This includes, but is not limited to:

An assessment if WXXM data served by WGDS needs to be adapted to comply with the coverage model, and if improvements can be achieved through other adaptations.

An assessment and evaluation of:

the WGDS WSDL,

the usability and suitability of WGDS schema and encoded documents,

WGDS in comparison to established OGC standards (including, but not limited to, WCS 2.0).

Note: The legacy web service (NDFD) provides a simple interface to NWS users and partners. The WGDS maintains much of that simplicity. The analysis should try to determine if the same simplicity can be achieved with OGC standards, especially WCS.

Develop, test and demonstrate an adaptation of the WGDS to demonstrate the feasibility of wrapping certain aspects of WGDS in OGC web services:

The adapter is envisioned to be a service that is based on the WCS 2.0 model and the GML Application Schema for Coverages, extended as necessary.

An adaptation of the WXXM data served by WGDS may be required, in case it does not comply with the coverage model, or if improvements can be made. This will be determined during the assessment of WGDS.

The adapter should provide all functionality and data required for the air ambulance scenario (see chapter 1.4.1.1), which may be revised during OGC Testbed 10.

Document potential enhancements and identified issues for relevant documents and references. For OGC documents, change requests (especially for Standard and Best Practice documents) will be created.

An Aeronautical Information Working Group was formed within the SAE-G10 Aerospace Behavioral Engineering Technology Committee. This group establishes recommended practices with regards to the graphical display of NOTAM information on on-board systems (EFB, flight deck navigation displays…). The goal is to make it easy for users – such as the pilot – to process the information correctly and hard to do it wrong. As such, the work from SAE-G10 is also relevant for the graphical display of digital NOTAMs in ePIBs (Digitally Enhanced Pre-Flight Information Bulletin), such as maps of the departure and arrival airports. The recommendations from SAE-G10 are intended to complement existing portrayal requirements, for example from ICAO Annex 15.

OGC Testbed 10 Requirements

OGC Testbed 10 will advance the work from previous testbeds in portrayal of digital NOTAM information, focusing on test and development of recommendations for human factor based portrayal of aeronautical information updates.

More specifically, the Aviation Thread of OGC Testbed 10 will:

Analyze the human factors guidance from the SAE-G10 document, both the general guidance (chapter 4 in the SAE-G10 document) and the specific guidance for display of selected NOTAMs (chapter 5 in the SAE-G10 document), and:

Develop potential guidance for SLD and symbol libraries that realize requirements and recommendations from SAE-G10, with special emphasis on how this would change/extend the symbology defined by ICAO Annex 4.

Assess if the SAE-G10 requirements and recommendations can be realized using SLD/SE – which would be relevant input for (future) ePIB work.

Document the according results.

Document potential enhancements and identified issues for relevant documents and references. For OGC documents, change requests (especially for Standard and Best Practice documents) will be created.

The OWS-9 CITE thread has developed tests that check the conformance of a GML application schema and adherence of a given GML instance document to that schema.

Note: the GML test suite developed in OWS-9 covers the tests described in clauses A.3.1 to A.3.4 of the GML 3.2.1 standard. Clause A.3.5 is not yet covered, because it simply states to “verify that the GML document complies with all other constraints specified by this International Standard”. Apparently the abstract test suite in the GML 3.2.1 standard is lacking more specific coverage of additional rules and constraints defined for GML geometry types.

In other words, the GML application schema itself is tested against the rules for application schema defined by the GML standard. Testing of an instance document at the moment is rather only a validation against its GML application schema. A general capability exists to perform schematron constraint checking. There are no “standard” schematron tests to check further GML requirements. Consequently, there is room for improving the existing GML test suite to check additional GML rules/constraints. Within the Aviation domain, the geometry types defined in the “Guidance and Profile of GML for use with Aviation Data” OGC Discussion Paper are of particular interest.

The OWS Aviation Threads conducted over the past four years have demonstrated the successful use of WFS technology for on demand access to AIXM 5.1 data. However, a number of outstanding issues have also been identified when it comes to handling the AIXM 5.1 Temporality Model. During OWS-8 and OWS-9, the OGC WFS Temporality Extension specification was developed, to address these issues. The specification defines an extension of the WFS and FES 2.0 models, specifically designed to support dynamic feature data following the AIXM Temporality Model. It is available as an OGC Discussion Paper. Further work is required, though. On the one hand, the specification does not yet explicitly define requirements following the OGC Specification Model. On the other hand, it does not yet define an abstract conformance test suite.

OGC Testbed 10 Requirements

The Aviation Thread of OGC Testbed 10 shall advance compliance of GML in Aviation data as well as the WFS capability to manage AIXM dynamic feature data, through development of test suites and documentation.

Developing a test suite to check rules and constraints defined by the GML 3.2.1 standard for geometry types that are contained in the GML profile defined by the “Guidance and Profile of GML for use with Aviation Data”. In order to improve the overall capability of CITE testing for GML data, additional tests to check rules and constraints for GML geometry types (as referenced by the abstract test in clause A.3.5 of the GML 3.2.1 standard) shall be developed. Test development shall focus on the geometry types defined in the GML profile for Aviation data. This has a direct benefit for the Aviation domain but will also benefit other domains that use GML geometry types in their data.

The test suite should extend the GML 3.2.1 test suite developed in OWS-9.

The test suite shall be integrated with the OGC Team Engine.

At the end of OGC Testbed 10 the compliance of geometry types contained in AIXM datasets shall be tested using the OGC Team Engine. The test data shall be suited to cover the developed test cases and be taken from available data sources and/or created as necessary.

The test results shall be documented.

Revise and enhance the OGC WFS Temporality Extension. This includes:

Documenting the functional requirements of the WFS Temporality Extension following the OGC Specification Model and revising the WFS Temporality Extension accordingly.

Writing an abstract test suite for the WFS Temporality Extension and adding it to the WFS Temporality Extension document.

Document potential enhancements and identified issues for relevant documents and references as well as the CITE test environment (existing test suites and the test engine). For OGC documents and the CITE test environment, change requests (especially for Standard and Best Practice documents) will be created.

It is perceived by the community implementing applications based on ATM information exchange models that the binding of AIXM to development tools is not easy, due to the complexity/verbosity of GML and in particular the metadata schema.

Automated code generation in today’s popular development environments (e.g. Java: Glassfish/Metro, Microsoft: .NET with XSD.EXE) fails at the code generation itself, or produces code with poor quality/usability (e.g. generated code does not contain the required equivalence of some elements and attributes).

The W3C states that XSD schema can be used for code generation: “Since XSD supports associating data types with element and attribute content, it is also used for data binding, that is, for software components that read and write XML representations of computer programming-language objects.”(source: http://www.w3.org/standards/xml/schema)

OGC Testbed 10 Requirements

In order to improve the efficiency of AIXM component development, OGC Testbed 10 will investigate and document recommendations for improving the binding of AIXM XSDs to development tools.

More specifically, the Aviation Thread of OGC Testbed 10 will:

Investigate, test and document the creation and use of XML Schema bindings for AIXM in different development environments.

The goal is to auto-generate program code from the AIXM XML Schema and use this code in a software component to perform a complete round-trip (serialization/deserialization) of AIXM data.

Factors to take into account in the investigations and developments of AIXM binding code can include: code quality, usability, completeness, performance, etc.

Development environments to be investigated include, but are not limited to: Java – Glassfish/Metro and Microsoft .NET with XSD.EXE

Java – Glassfish/Metro

Document potential enhancements and identified issues for relevant documents and references. For OGC documents, change requests (especially for Standard and Best Practice documents) will be created.

Note: the focus of this task is in XML (Schema) binding technologies. However, investigations and testing could go further and analyze solutions that facilitate development of components that use AIXM. For example, it could include software libraries/APIs – preferably based on open source – that defines (via open interfaces) or supports (as actual code) more functional tasks related to AIXM data: evaluation of feature state (with or without schedule evaluation), geometry computations, change management, etc.

o An assessment if WXXM data served by WGDS needs to be adapted to comply with the coverage model, and if improvements can be achieved through other adaptations.

o An assessment and evaluation of:

the WGDS WSDL,

the usability and suitability of WGDS schema and encoded documents,

WGDS in comparison to established OGC standards (including, but not limited to, WCS 2.0).

Note: The legacy web service (NDFD) provides a simple interface to NWS users and partners. The WGDS maintains much of that simplicity. The analysis should try to determine if the same simplicity can be achieved with OGC standards, especially WCS.

The report shall document:

1. The results of the work performed in OGC Testbed 10 to incorporate WGDS in the OGC – especially the OGC Aviation - architecture (analysis, testing and development).

2. Identified issues, lessons learned, recommendations, future work items and accomplishments that result from the work on exploring WGDS as a new source of weather information.

1. Investigate, test and document the creation and use of XML Schema bindings for AIXM in different development environments.

a. An expected outcome is to auto-generate program code from the AIXM XML Schema and use this code in a software component to perform a complete round-trip (serialization/deserialization) of AIXM data.

b. Development environments to be investigated include, but are not limited to:

i. Java – Glassfish/Metro

ii. Microsoft .NET with XSD.EXE

2. Document identified issues, lessons learned, recommendations, future work items and accomplishments that result from the work on advancing support of AIXM in development tools.

2. Together with the participant responsible for the deliverable described in section 1.3.14:

o Develop potential guidance for SLD and symbol libraries that realize requirements and recommendations from SAE-G10, with special emphasis on how this would change/extend the symbology defined by ICAO Annex 4.

o Assess if the SAE-G10 requirements and recommendations can be realized using SLD/SE.

The report shall document:

1. The results of the work performed in OGC Testbed 10 on analysis as well as testing and development of the guidance from the SAE-G10 group including but not limited to:

a. Potential guidance for SLD and symbol libraries that realize requirements and recommendations from SAE-G10.

b. The results of the assessment if the SAE-G10 requirements and recommendations can be realized using SLD/SE.

2. Identified issues, lessons learned, recommendations, future work items and accomplishments that result from the work on advancing human factor based portrayal of Digital NOTAMs.

An assessment if WXXM data served by WGDS needs to be adapted to comply with the coverage model, and if improvements can be achieved through other adaptations.

An assessment and evaluation of:

the WGDS WSDL,

the usability and suitability of WGDS schema and encoded documents,

WGDS in comparison to established OGC standards (including, but not limited to, WCS 2.0).

Note: The legacy web service (NDFD) provides a simple interface to NWS users and partners. The WGDS maintains much of that simplicity. The analysis should try to determine if the same simplicity can be achieved with OGC standards, especially WCS.

The report shall document:

The results of the work performed in OGC Testbed 10 to incorporate WGDS in the OGC – especially the OGC Aviation - architecture (analysis, testing and development).

Identified issues, lessons learned, recommendations, future work items and accomplishments that result from the work on exploring WGDS as a new source of weather information.

Develop a test suite to check rules and constraints defined by the GML 3.2.1 standard for geometry types that are contained in the GML profile defined by the “Guidance and Profile of GML for use with Aviation Data”. The test suite should extend the GML 3.2.1 test suite developed in OWS-9.

Using the OGC Team Engine, test the compliance of geometry types contained in the AIXM test data.

Note: it is understood that it would require considerable efforts to create a test suite that covers all relevant rules and constraints for the geometry types defined by the GML Profile for Aviation data. RFQ responses addressing this deliverable should therefore clearly document which aspects of the GML standard will be covered by the test suite that is proposed to be developed in OGC Testbed 10.

The report shall document:

A brief overview of the test system (OGC TEAM Engine) and testing process – focusing on the test suite developed in OGC Testbed 10 Aviation.

The results of the GML for Aviation Compliance Test Suite development.

Identified issues, lessons learned, recommendations, future work items and accomplishments that result from the work on advancing compliance.

This deliverable covers the documentation of identified potential enhancements and issues in change requests against relevant OGC documents (like Standard and Best Practice documents) as well as the CITE test environment (existing test suites and the test engine).

This deliverable is related to all requirements stated in section 1.2.

An analysis to which extent Web Gridded Document Service (WGDS) functionality, models and operation parameters map to elements of the WCS 2.0 model and the GML Application Schema for Coverages.

Supporting the documentation tasks of the participant responsible for the Aviation Dissemination of Weather Data ER deliverable (see chapter 1.3.7).

Test and development of a service adapter for the WGDS that is based on the WCS 2.0 model and the GML Application Schema for Coverages, extended as necessary.

An adaptation of the WXXM data served by WGDS may be required, in case it does not comply with the coverage model, or if improvements can be made. This will be determined during the assessment of WGDS.

The adapter should provide all functionality and data required for the air ambulance scenario (see chapter 1.4.1.1), which may be revised during OGC Testbed 10.

Documentation of the component including, but not limited to:

Appropriate documentation of the requests that were used in support of the demo scenario(s) to retrieve data.

A description of the component for inclusion in the Aviation Architecture ER (see 1.3.2).

A WSDL file describing the service instance, for subsequent publication in the SESAR SWIM Registry.

NOTE: at least XPath based filtering shall be supported. More advanced filtering functionality, for example based on OGC FES (see 1.5.7) is of interest, but not required.

Support for subscription management and notification of clients (for any message with AIXM/FIXM data that matches their subscription criteria)

Documentation of the component including, but not limited to:

Appropriate documentation of the events and subscriptions that were used in support of the demo scenario(s).

A description of the component for inclusion in the Aviation Architecture ER (see 1.3.2).

A WSDL file describing the service instance, for subsequent publication in the SESAR SWIM Registry.

NOTE: in previous OGC IPs the Event Service was a standalone component that realized brokered notification functionality. However, basic Event Service functionality can also be realized by WFS components – they only need to implement the Publish/Subscribe interface.

The realization of this component deliverable will include interfacing with all OGC Testbed 10 Aviation service components, for testing and demonstrating the relevant service functionality. The client shall support the OGC Testbed 10 Aviation demonstration(s) based upon the OGC Testbed 10 Aviation scenario(s). Emphasis is on supporting and demonstrating new client and service functionality developed by the participants in the OGC Testbed 10 Aviation Thread.

In addition to this general requirement, the participant responsible for this deliverable shall especially also:

Analyze the human factors guidance from the SAE-G10 document.

Together with the participant responsible for the deliverable described in section 1.3.5:

Develop potential guidance for SLD and symbol libraries that realize requirements and recommendations from SAE-G10, with special emphasis on how this would change/extend the symbology defined by ICAO Annex 4.

Assess if the SAE-G10 requirements and recommendations can be realized using SLD/SE.

According to the FAA website, the air transportation system is stretched thin with forecasts indicating increases in passenger demand ranging from a factor of two to three by 2025. The current system is already straining with ever-increasing levels of congestion, declining on-time arrivals, increasing delays (and customer frustration) as well as increasing costs and environmental impacts. At the same time, according to EUROCONTROL, the European Airspace is fragmented and will become more and more congested, as traffic is forecast to grow steadily over the next 15 years. The legacy Air navigation services and their supporting systems are not fully integrated and are based on technologies that are already running at maximum. AirServices Australia (ASA) has acknowledged similar issues in the Commonwealth, as have other nations in the Pacific Rim and in economically emerging nations. In order to accommodate future Air Traffic needs, a “paradigm shift”, supported by state-of-the-art and innovative technologies, is required.

To realize this paradigm shift the Aviation industry is working on a framework built extensively on standards, digital data exchange and process automation.

Figure 1 – Towards a New ATM Information Management Paradigm

At the heart of this new ATM Information Management paradigm are standardized Information Exchange Models.

These models cover relevant information from ATM domains. Information encoded according to the models will be exchanged via standardized, reusable, and loosely coupled service interfaces. These services will enable System Wide Information Management (SWIM), on an international scale (see Figure 3).

Figure 3 – globally connected SWIM environments

Even though the general term “SWIM” as well as the general concept is the same, SWIM environments (for example developed by NextGen and SESAR) currently do not use exactly the same service interfaces. OGC web service interfaces can be used to adapt SWIM service interfaces and to disseminate ATM information from multiple SWIM environments in an interoperable way.

The Aviation domain is actively pursuing the goal of establishing a global, interoperable ATM Information Management system. Through projects and ongoing efforts by the community, a number of building blocks for this system have already been established: models to exchange aeronautical and weather information, services to discover, access and publish such information, as well as a number of supporting studies, analyses and assessments, to name but a few.

Additional building blocks are required to ensure system compliance, facilitation of software development, exchange of flight and terrain information, as well as portrayal and display of ATM information for human users. OGC Testbed 10 will address these tasks.

Aviation Thread scenarios provide a fictitious, but realistic context for a demonstration of the functionality that will be developed in the Aviation Thread of OGC Testbed 10, and for the interaction with other OWS components. The scenarios are intended to prompt the exercising of interfaces, components, tools and services as well as the use of encodings that will be developed or enhanced within OGC Testbed 10. This includes exercising a variety of web services and encodings.

Within the OGC Testbed 10 Aviation thread, the scenarios will revolve around the following theme(s):

Exchange of FIXM datasets as well as static and dynamic aeronautical information.

Portrayal of AIXM, FIXM, weather and potentially also terrain data.

Initial scenario(s) and use cases will be discussed and developed during the OGC Testbed 10 kickoff. They are subject to change as determined by various factors, most notably availability of suitable data. The scenarios and use cases will be revised and enhanced during OGC Testbed 10, as required.

The National Transportation Safety Board (NTSB) continues to be concerned with Air Ambulance safety, and for good reason. Emergency helicopter flights can be risky, often operating at night in low altitudes and in uncertain weather conditions. The International Civil Aviation Organization (ICAO) Annex 3, the Meteorological Services for International Air Navigation, provides standards and recommended practices covering Meteorological Terminal Aviation Routine Weather Report (METAR), SPECI (Special), Terminal Aerodrome Forecast (TAF) and Significant Meteorological Information (SIGMET), and the communication and dissemination of Meteorological information to pilots. Much of this meteorological information is available today at aerodrome locations (e.g. airports) only. What makes Air Ambulance missions so hard, is that weather information is not typically available in-flight and at the destination location.

The National Weather Service (NWS) issues operational gridded forecasts of sensible weather elements like clouds, temperature, dew point, relative humidity, probability of precipitation, wind direction, wind speed via the National Digital Forecast Database (NDFD). The NDFD also contains experimental gridded forecasts of ceiling height and visibility at a limited portion of the Contiguous United States (CONUS). NDFD weather data is available to the public to use in creating text, graphic, gridded and image products of their own, and is the type of weather information that is currently available for pilots. The NWS also has a Localized Aviation Model Output Statistics (MOS) Program (LAMP) statistical system that provides forecast guidance for sensible weather elements. An important feature of LAMP guidance is its probabilistic nature. LAMP forecasts for many weather elements are created as categorical probabilities. These guidance forecasts offer valuable information that can be used as a decision support tool in addition to the TAF. The NWS has developed a prototype probabilistic TAF product from LAMP that can be used as guidance.

Scenario

Winter night in north central Massachusetts. A coastal low pressure system has spread low clouds and snow across coastal Massachusetts. Traffic accident on US-202 near Gardiner, Massachusetts. Air ambulance pilots check official TAFs and METARs. Bedford, Massachusetts (KBED) METAR observation shows ceiling and visibility in the category named Low Instrument Flight Rules (LIFR) and the Terminal Aerodrome Forecast (TAF) shows poor conditions persisting for the next 3 hours. Fitchburg, Massachusetts (KFIT) METAR is a little better. No TAF is available, however, for KFIT. Air ambulance pilots access a time series forecast of wind, weather, ceiling height, and visibility for the gridpoint nearest the accident site. This gridded aviation forecast indicates that the accident site is far enough west to be out of the worst of the coastal storm’s weather. Conditions are flyable, and air ambulance completes its mission.

The Information Viewpoint describes the information models and encodings that will make up the content of the services and exchanges to be extended or developed to support the Aviation thread activities.

AIXM will be used for conformance testing work and within the Aviation Architecture that will be tested and demonstrated. Conformance tests will require standalone AIXM data (sets). In the demonstration, a client will access AIXM data from WFS and display it.

NOTE: the AIXM model is based on the concept of dynamic features. The AIXM Temporality Model defines rules for the handling of dynamic features in AIXM and is an integral part of AIXM. Applications and services managing and using AIXM data usually need to be able to take the specifics of dynamic feature data into account. Clients, for example, need to be able to compute the state of a dynamic feature for a given point in time from the time slices available in the representation of that feature. For more information, please refer to the AIXM Temporality Model specification.

DNOTAM v2.0 will be published in July 2013 and will be the basis for developments in OGC Testbed 10. This major revision primarily documents additional publication scenarios. Some of the DNOTAM scenarios are relevant for the human factor based portrayal work.

Web Coverage Service (WCS) 2.0 is based on the GML Application Schema (AS) for Coverages. OGC Testbed 10 shall assess and test how the NWS Web Gridded Document Service (WGDS) can be incorporated into the OGC Aviation Architecture, ideally through suitable adaptation via a WCS. As such, the Coverages GML AS is a crucial part of this work. An important aspect is to assess if the (WXXM) data served by the WGDS complies with the Coverages GML AS, and if any adaptations of the data and format(s) are necessary.

Service and client components should support the GML profile defined in the “Guidance and Profile of GML for use with Aviation Data”. The geometry types covered by this profile also define the scope for the GML conformance test development: the rules and constraints defined by the GML standard for the geometry types of the profile have priority for test development.

OGC Testbed 10 will perform an assessment of the exchange of terrain data. TICM and TIXM are designed to support the interoperable exchange of terrain data. As such, they should be considered in the assessment.

The Aviation Thread will verify and validate the current design of FIXM version 2.0.

OGC Web Feature Service(s) will be used to manage and disseminate FIXM data, while Aviation client component(s) will access and display FIXM data.

NOTE: the first FIXM version deemed to be sufficiently mature enough and complete enough for global use is FIXM v3.0. Since FIXM v3.0 will not be available until Aug 2014, OGC Testbed 10 may need to modify (improve and/or fix) FIXM v2.0 so that the version of FIXM used in the testbed is sufficient to support OGC Testbed 10 use cases and scenario(s). Drafts of FIXM v3.0 may be made available to OGC Testbed 10 during the testbed, which can be used for testing and development if all relevant participants and the Thread Architect agree to do so.

The OGC Testbed 10 Aviation Thread will analyze and test the implementation of requirements and recommendations from SAE-G10 for human factor based portrayal of NOTAMs. One important part of this work is to assess if the requirements and recommendations can be realized using SLD/SE, and to develop potential guidance for SLD (and symbol libraries) with special emphasis on changes/extensions to the symbology defined by ICAO Annex 4.

The executable conformance test suites for GML 3.2.1 developed in OWS-9 is realized with TestNG. The “GML for Aviation Compliance Test Suite” to be developed in the OGC Testbed 10 Aviation thread should extend the existing GML 3.2.1 test suite.

The computational viewpoint is concerned with the functional decomposition of the Aviation architecture into a set of services that interact at interfaces. It reflects the components, interfaces, interactions and constraints of the Service Architecture without regard to their distribution. For the Aviation thread of OGC Testbed 10, those components are:

Web Feature Service (WFS) for access to aeronautical and flight information.

Event Service (based on OASIS Web Services Notification) for the automatic delivery of information updates to interested clients

Catalog Service for the Web (CSW) ebRIM for managing metadata on services as well as aeronautical and especially flight information available in the system.

WFS 2.0 will be used in the Aviation thread to serve and query AIXM 5.1 aeronautical features as well as FIXM data. The WFS shall support transactions (for updates of feature data and combined automatic publication of according event information).

The Aviation Thread of OGC Testbed 10 will use the Event Service component developed in previous OGC IPs to enable information producers to publish notifications/events (such as Digital NOTAMs and updates of FIXM data) and to notify information consumers (Clients) of events that match their subscription criteria. An Event Service in OGC Testbed 10 Aviation needs to support filtering of AIXM and FIXM data.

The Aviation Clients in the Aviation Thread of OGC Testbed 10 are critical to demonstrating interoperability of the web services used in the thread as well as highlighting the potential value of interoperable access, filtering, integration and portrayal of AIXM/FIXM data and events.

The Aviation Clients can be developed as either thin or thick clients, and can act as proxies for EFB/handheld applications, avionic system applications, flight dispatch/airline operations applications, or any other applications that can benefit from the combination of functionality developed during the thread.

The Enterprise, Information, and Computation viewpoints describe a system in terms of its purposes, its content, and its functions. The Engineering viewpoint identifies component types in order to support distributed interaction between the components of the system. Those components interact based upon the services identified and described in the Computational viewpoint.

Figure 6 provides an overview of the components of the Aviation thread, organized based on the ISO 3-tier model with the top tier dealing with clients, the middle tier embodying the business processes required to respond to requests issued by clients, and a lower tier focusing on provision of data. Note that in order to minimize the complexity of the engineering viewpoint, the figure does not show all possible interactions amongst the identified components.