Testbed-14 Call for Participation (CFP)

In general, Bidders should propose specifically against the list of deliverables described under the Summary of Testbed Deliverables section below. But Bidders may go beyond funded deliverables to propose in-kind contributions that will address unfunded requirements as well. Participants should note, however, that Sponsors have committed to fund only those deliverables identified as being funded.

This Testbed provides a business opportunity for stakeholders to mutually define, refine, and evolve service interfaces and protocols in the context of hands-on experience and feedback. The outcomes are expected to shape the future of geospatial software development and data publication. The Sponsors are supporting this vision with cost-sharing funds to partially offset the costs associated with development, engineering, and demonstration of these outcomes. This offers selected Participants a unique opportunity to recoup a portion of their Testbed expenses.

This CFP incorporates the following additional documents:

This Testbed will be conducted in accordance with OGC Innovation Program Policies and Procedures.

OGC Principles of Conduct will govern all personal and public interactions in this initiative.

One Testbed objective is to support the OGC Standards Program in the development and publication of open standards. Each Participant will be required to allow OGC to copyright and publish documents based in whole or in part upon intellectual property contributed by the Participant during Testbed performance. Specific requirements are described under the "Copyrights" clauses of the OGC Intellectual Property Rights Policy.

The roles generally played in any OCG Innovation Program initiative are defined in the OGC Innovation Program Policies and Procedures, including Sponsors, Bidders, Participants, Observers, and the Innovation Program Team ("IP Team").

Additional explanations of the roles of Sponsors, Bidders, Participants, and Observers are provided in the Tips for New Bidders.

The IP Team for this Testbed will include an Initiative Director, an Initiative Architect, and multiple Thread Architects. Unless otherwise stated, the Initiative Director will serve as the primary point of contact (POC) for the OGC.

Thread Architects will work with Participants, Sponsors, and each other to ensure that Testbed activities and deliverables are properly assigned and performed. They are responsible for scope and schedule control, as well as for within-thread and cross-thread communications. They will also provide timely escalation to the Initiative Director regarding any severe issues or risks that happen to arise.

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Clarifications page. Instructions for accessing this page are included under Proposal Submission Procedures.

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk (techdesk@opengeospatial.org). Question submitters will remain anonymous, and answers will be regularly compiled and published on the CFP clarifications page.

OGC may also choose to conduct a Bidder’s question-and-answer webinar to review the clarifications and invite follow-on questions.

The following diagram provides a notional schedule of major Testbed events and milestones, and their approximate sequence of occurrence. The Testbed will use rolling-wave project management whereby more detailed scheduling will take place as each milestone draws near.

Participant Selection and Agreements:

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Clarifications page. Instructions for accessing this page are included under Proposal Submission Procedures.

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk (techdesk@opengeospatial.org). Question submitters will remain anonymous, and answers will be regularly compiled and published in the CFP clarifications document.

OGC may also choose to conduct a Bidder’s question-and-answer webinar to review the clarifications and invite follow-on questions.

Following the closing date for submission of proposals, OGC will evaluate received proposals, review recommendations with Sponsors, and negotiate Participation Agreement (PA) contracts, including statements of work (SOWs), with selected Bidders. Participant selection will be complete once PA contracts have been signed with all Participants.

Kickoff Workshop: A Kickoff Workshop ("Kickoff") is a face-to-face meeting where Participants, guided by thread architects, will refine the Testbed architecture and settle upon specific interface models to be used as a baseline for prototype component interoperability. Participants will be required to attend the Kickoff, including the breakout sessions of each thread for which they were selected. Participants will be expected to use these breakouts to collaborate with other Participants and confirm intended Component Interface Designs.

After the face-to-face Kickoff, most Testbed activities will be conducted remotely via web meetings and teleconferences until the Demonstration Event near the end of Testbed execution.

Development of Engineering Reports, Change Requests, and Other Document Deliverables: Development of Engineering Reports (ERs), Change Requests (CRs) and other document deliverables will commence during or immediately after Kickoff. Participants will deliver an Initial Engineering Report (IER) plus several iterations of a Draft Engineering Report (DER). Full process details can be found in the OGC ER Process.

Under the Participation Agreement (PA) contracts to be formed with selected Bidders, ALL Participants will be responsible for contributing content to the ERs. But the ER Editor role will assume the duty of being the primary ER author.

Component Design, Development, and Preliminary Testing: Participants will continue documenting detailed and final Component Interface Designs in the Testbed wiki. This documentation will allow task Participants to confirm a mutual understanding of each other’s interfaces so that subsequent interoperability testing can take place. A preliminary Technology Integration Experiment ("TIE", sometimes also referred to as a "Technology Interoperability Experiment") Connectivity Test milestone will be used to ensure that Testbed service endpoints can be reached by Testbed clients.

TIE Readiness Review: A TIE Readiness Review will be conducted with a Thread Architect to confirm that each TIE Participant is prepared to start conducting TIE testing with counterpart Participants.

Component Interoperability Testing, and Acceptance: Participants should deliver completed and fully TIE-tested component implementations no later than the 30 September milestone (unless an earlier milestone is identified in Appendix B Technical Architecture). The primary acceptance criterion for a component implementation deliverable is the conduct and recording of the TIE test. This test can also prove useful in accelerating the development of Demonstration Event assets such as video recordings.

Draft Engineering Reports: Participants should also deliver complete and clean Draft Engineering Report (DERs) by the 30 September milestone. A complete DER is one for which all major clauses have been populated with meaningful content. A clean is one where all known editorial defects have been repaired. This milestone will impact ALL Testbed Participants, even component implementers, who will be responsible for making necessary documentation material available to the ER Editor for use in authoring the ER. Testbed Sponsors and Thread Architects will review these DERs in the weeks following delivery.

DER Rework and SWG/DWG Reviews: Participants will be required to perform rework based on the reviews from Sponsors and Thread Architects. The ER editor will then make a request to the selected OGC SWG or DWG to perform its review and to consider making a request that the DER be voted on by the OGC Technical Committee (TC) for publication. The OGC 3-week rule must be followed if the DER is to receive a vote at a TC Meeting. The DER must be posted to the members-only OGC Pending Documents directory to enable this TC vote. Participants will likely have to perform one final round of rework based on SWG/DWG feedback. The further along the DER is when submitted to the WG, the less rework will be required.

Final Summary Reports and Demonstration Event: Participants Final Summary Reports will constitute the close of funded activity. Further development work might take place to prepare and refine assets to be shown at the Demonstration Event.

Assurance of Service Availability: Participants selected to implement service components must maintain availability for a period of no less than one year after the Final Delivery Milestone. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

Detailed requirements for meeting all these milestones are provided in Appendix A Management Requirements.

Additional technical details can be found in Appendix B Technical Architecture.

< end of main body >

The process for completing a Testbed 14 proposal is essentially embodied in the online Bid Submission Form. A summary is provided here for the reader’s convenience.

Once an online account has been created, the user will be taken to a home page indicating the "Status of Your Proposal." If any defects in the form are discovered, this page includes a link for notifying OGC. The user can return to this page at any time by clicking the OGC logo in the upper left corner.

Clicking on the Clarifications link will navigate to the CFP clarifications page.

On the far right, the Review link navigates to a page summarizing all the deliverables the Bidder is proposing.

Once the final version of the information for all the proposed deliverables has been entered, the Bidder can submit the completed proposal to OGC by clicking the Submit button at the bottom.

The user is provided an opportunity under Attached Documentation at the bottom of this page to attach collateral documentation (one document per proposal). This document could conceivably contain any specialized information that wasn’t suitable for entry into a Proposed Contribution field under an individual deliverable. It should be noted, however, that this additional documentation will only be read on a best-effort basis. There is no guarantee it will be used during evaluation to make selection decisions; rather, it could optionally be examined if the evaluation team feels that it might help in understanding any specialized (and particularly promising) contributions.

The Propose link takes the user to the first page of the proposal entry form. This form contains fields to be completed once per proposal such as names and contact information.

It also contains an optional Organizational Background field where Bidders (particularly those with no experience participating in an OGC testbed) may provide a description of their organization. It also contains a click-through check box where each Bidder will required (before entering any data for individual deliverables) to acknowledge its understanding and acceptance of the requirements described in this appendix.

Clicking the Update and Continue button then navigates to the form for submitting deliverable-by-deliverable bids. On this page, existing deliverable bids can be modified or deleted by clicking the appropriate icon next to the deliverable name. Any attempt to delete a proposed deliverable will require scrolling down to click a Confirm Deletion button.

To add a new deliverable, the user would scroll down to the Add Deliverable section and click the Deliverable drop-down list to select the particular deliverable of interest.

The user would then enter the required information for each of the following fields (for this deliverable only). Required fields are indicated by an asterisk ("*"):

Cost-sharing funds may only be used for the purpose of offsetting burdened labor costs of development, engineering, and demonstration of Testbed outcomes related to the Participant’s assigned deliverables. By contrast, the costs used to formulate the Bidder’s in-kind contribution may be much broader, including supporting labor, travel, software licenses, data, IT infrastructure, etc.

Finally, a Bidder proposing to deliver a Service Component Implementation should use the Proposed Contribution (Please include any proposed datasets) field to identify what suitable datasets would be contributed (or what data should be acquired from another identified source) to support the proposed service. Full details of this requirement can be found under Data Requirements.

This field Proposed Contribution (Please include any proposed datasets) could also be used to provide a succinct description of what the Bidder intends to deliver for this work item to meet the requirements expressed in Appendix B Technical Architecture. This language could potentially include a brief elaboration on how the proposed deliverable will contribute to advancing the OGC technical baseline, or how implementations enabled by the specification embodied in this deliverable could add specific value to end-user experiences.

However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the Testbed as a platform for introducing new requirements not included in Appendix B Technical Architecture. Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in Testbed scope or not. Items deemed out-of-Testbed-scope might be more appropriate for inclusion in another OGC Innovation Program initiative.

The statements of work (SOWs) in the Participation Agreement (PA) contracts will ultimately require performance during testbed execution against the deliverables as described in Appendix B Technical Architecture plus any subsequent Corrigenda.

A single bid may propose deliverables arising from any number of Testbed threads. To ensure that the full set of sponsored deliverables are made, OGC might negotiate with individual Bidders to drop and/or add certain deliverables from their proposals.

A selected Bidder will become a Testbed Participant by executing a Participation Agreement (PA) contract with OGC, which will require the following conditions:

Specific proposal evaluation criteria were presented earlier. Several process steps to be conducted by the IP Team are presented below to aid readers in understanding the overall process.

Soon after the proposal submission deadline, the IP Team and Sponsors will begin reviewing proposals, examining suitability of the proposed deliverables in light of the CFP requirements. During this analysis, the IP Team might need to contact Bidders to obtain clarifications and better understand what is being proposed.

At the Decision Technical Evaluation Meeting I (TEM I), the IP Team will present Sponsors with draft recommendations regarding which parts of which proposals should be offered cost-share funding. Sponsors will use this opportunity to suggest modifications.

The IP Team will notify each Bidder of their selection, including a description of the particular deliverables being offered, and OGC’s intent to enter into a Participation Agreement (PA) with them. Selected Bidders must be available for these contacts to be made to enable confirmation of continued interest. Bidder acceptance of the offer essentially locks in the scope that will be used to form the SOW to be attached to the forthcoming PA. A Bidder may reject the offer (for example, if the offer is to deliver only a small subset of its proposed deliverables).

A Decision Technical Evaluation Meeting II (TEM II) meeting will be conducted to review the outcomes of initial offers to selected Bidders, and any modifications that were needed due to Bidder rejections.

Following TEM II, the IP Team will develop the formal SOW and attach it to the full PA for each selected Bidder. Selected Bidders must be available to enable finalization of their PA contract.

Each PA will include a final identification of all assigned deliverables. The specific requirements that these deliverables must meet will be those documented in Appendix B Technical Architecture (plus any subsequent corrigenda).

Because Testbeds tend to deal with the lowest maturity level of OGC standards technology, they operate under the principle that “interoperable running code wins” (based loosely on an Internet Engineering Task Force founding belief).

In contrast with ordinary commercial contracts, which often focus on delivering a single-customer solution, the Participation Agreement contracts will encourage Participants to work in the broader interests of the OGC community. These interests are generally represented in the OGC Standards Working Groups (SWGs) and Domain Working Groups (DWGs). Testbed sponsorship enables a selected subset of these interests to be brought to bear on the production of interoperable running code and the reporting back of findings and recommendations as Change Requests (CRs) and document deliverables under the OGC Engineering Report Process.

In general, at least one Participant will be assigned for each client-server pair as an Engineering Report (ER) Editor, who will be responsible for authoring the ER, though there might be exceptions. See General Requirements for Proposing Deliverables for details. An ER Template will be provided to assist in the breakdown of content into multiple chapters describing specific findings and recommendations, a summary chapter, and supporting chapters (e.g., containing references and revision history).

OGC members who who are not selected to make any deliverables may still observe all Testbed activities by visiting the (members-only) OGC Observer Agreements page and registering to become a Testbed-14 Observer. The Observer Agreement will require that Observers follow the same intellectual property protection rules as apply to other Testbed stakeholders (e.g., to avoid sharing other stakeholder’s confidential information with individuals outside the Testbed).

Testbed stakeholders should also avoid making any representations that any of the intermediate technical decisions made internally during Testbed execution reflect any sort of endorsed position of the OGC. Formal Testbed recommendations will become "official" once the containing ER has received approval to be made public.

Testbed execution will commence with a Kickoff Workshop event ("Kickoff"). In general, the Kickoff ensures a common Participant understanding of the overall Testbed architecture and of all interfaces relevant to their assigned deliverables. Under the Testbed’s rapid pace, and guided by the Thread Architect, periods of development will be followed by synchronization among component developers, so that the likelihood of interoperation is maximized at each iteration. To maintain interoperability, each Participant should diligently adhere to the latest agreed specifications so that other Participants may rely on the anticipated interfaces in subsequent TIE testing.

Since Participants will be relying on one another to deliver interoperable components, all Participation Agreement (PA) contracts should be settled by the start of Kickoff. Any Participant that has not yet executed a PA by start of Kickoff will be required to attest to its commitment to a PA Statement of Work (SOW). The full PA must then be executed with OGC no later than Kickoff completion (two days after Kickoff start).

The Kickoff will include both plenary and thread-based breakout sessions. Thread breakouts will be used to ensure a mutual understanding of the detailed interfaces that will support component interoperability. The Kickoff will also present an opportunity to finalize regularly scheduled thread and subthread teleconferences ("telecons").

All selected Participants must send at least one technical representative per assigned thread to the Kickoff Workshop, and a representative should be present at the breakout sessions for every thread for which the Participant has been assigned a deliverable.

These requirements will also apply to Participants not requesting any cost-share funding (i.e., purely in-kind contribution) since their deliverables are still being relied upon by other Participants.

In general, Participants will be required to make deliverables meeting the requirements stated in CFP Appendix B Technical Architecture.

Under the Participation Agreement (PA) contracts to be formed with selected Bidders, all Participants will be responsible for contributing content to the ERs.

But the ER Editor role will assume the duty of being the primary ER author. As compared to the ER Editor role in Testbed-13, ER Editors in Testbed-14 must adopt a more proactive approach to consuming and documenting the knowledge being generated during component implementation. In other words, ER Editors serve as primary authors in addition to their editor role. All other participants are required to support the editors by making necessary documentation material available.

In addition, component implementers (Participants selected to deliver component implementations) will be responsible for contributing completed technical artifacts for inclusion as ER annexes. These include UML diagrams, XML schemas and instances, and abstract test suites, all of which have their own specialized clauses in the ER Template. Component implementers will also be responsible for contributing demo assets such as video recordings of component operation.

ER Editors will be responsible for observing the component implementation work and documenting (in the assigned ER) all findings and recommendations (except the technical artifacts identified above). They will also be responsible for ensuring the document’s overall integrity, authoring summary material and ensuring that global sections (e.g., References, Terms, Revision History, Bibliography) have all been completed.

ER Editors will also be responsible for enabling all required ER reviews (and subsequent rework), including internal reviews by Thread Architects and Sponsors, as well as requests for reviews by an appropriate OGC Standard Working Group (SWG) or Domain Working Group (DWG).

ER Editors will also be responsible for creating (and referencing) any Change Requests (CRs) arising from the work described in the assigned ER. CRs can be created using the OGC CR system.

The primary acceptance criterion for a document deliverable (e.g., an ER) will be approval from a Thread Architect to post the document to an OGC (members-only) folder called the OGC Pending directory. Permission to post will not be granted until the full OGC Engineering Report Process has been followed, including the step to request a review from an OGC SWG or DWG. All appropriate tooling should also have been utilized (ER Template, Asciidoc, GitHub), and the document should have achieved a satisfactory level of consensus among all assigned Participants.

In general, prototype component implementation deliverables (including services, clients, datasets, and tools) will be provided by methods suitable to its type and stated requirements. A service (e.g. a WFS instance or even an intermediary component) will be delivered by deployment for use in the Testbed via an accessible URL. A client will be used to exercise a service to test and demonstrate interoperability. Components will be developed and deployed in all threads for integration and interoperability testing in support of agreed-upon thread scenario(s) and technical architecture. The Kickoff will provide the opportunity to establish many of the agreed-upon details. These technical artifacts could also be utilized for cross-thread scenarios in demonstration events.

More specifically, the first acceptance criterion for any component implementation deliverable will be a successful demonstration of capability in a Technology Integration Experiment ("TIE") test.

The next acceptance criterion will be assurance that the work-package ER Editor has access to sufficient documentation material to record all findings and recommendations in the ER and associated CRs.

Another criterion will be evidence that the implementer has directly authored full ER content for any relevant Abstract Test Suite (ER Template Annex A), XML Schema Document (ER Template Annex B), or UML Model (ER Template Annex C).

A Participant assigned to deliver a client component implementation should, in addition, record TIE test execution (as evidence of delivery) and create demo assets, brief (several-minute) video recordings of client operation reflecting the newly enabled capabilities. These assets will become candidates for incorporation into executive-level briefings to be shown at the Demonstration Event near the end of the Testbed.

A Participant assigned to deliver a service component implementation should, in addition, provide assurance that the service endpoint will remain available to OGC and Sponsors for a period of no less than one year after Testbed execution. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

A Participant assigned to deliver a service component implementation should, in addition, identify of one or more particular datasets that would be suitable for the proposed service. Details are provided under Data Requirements for Proposing Service Component Implementation Deliverables.

Some requirements might request delivery of a packaged prototype component (e.g., using a virtual machine or container). Consult the specific language in the Appendix B Technical Architecture for details regarding these requirements.

Testbed execution monitoring and control will follow an encapsulation principle. As long as a Participant continues [1] supporting activities on which other Testbed stakeholders are relying (e.g., telecons, TIEs, ER inputs) and [2] making timely delivery of their own deliverables, the question of what’s "going on" inside the Participant organization will likely not be raised.

Otherwise, any issues (or risks) that block (or threaten to block) timely delivery will enter a remediation status requiring the following responses:

The following definitions will be used to communicate and track deliverable status:

In general, risks and issues that are contained within a particular thread will be monitored and managed by the assigned Thread Architect, who will report ongoing status to other stakeholders. Any risks or issues that cross threads should be brought to the attention of all relevant Thread Architects and the Initiative Director.

Bidders who are new to OGC Testbeds are encouraged to review the following tips, extracted and updated from the Testbed-13 Clarifications document.

< end of appendix >

This Annex B provides background information on the OGC baseline, describes the Testbed-14 architecture and thread-based organization, and identifies all requirements and corresponding work items. For general information on Testbed-14, including deadlines, funding requirements and opportunities, please be referred to the Testbed-14 CFP Main Body.

Each thread aggregates a number of tasks. Each task specifies a number of requirements that need to be fulfilled by work items. The work items are funded by different sponsors.

An overview of all threads and assigned tasks is provided further below.

Testbed-14 is organized in a number of threads. Each thread combines a number of tasks that are further defined in the following chapters. The threads integrate both an architectural and a thematic view, which allows to keep related work items closely together and to remove dependencies across threads.

Each of the following sections provides a detailed description of a particular task.

One of the most interesting recent developments in Machine Learning (ML) has been in Deep Learning, a specialization of Artificial Neural Networks.

Deep Learning (DL) can be defined as a neural network approach that involves a large number of parameters and layers in one of four fundamental network architectures: unsupervised pre-trained networks, convolutional neural networks, recurrent neural networks and recursive neural networks. Automatic feature extraction is one of the areas where DL has shown great promise.

OGC Web services play a pivotal role in many geospatial work flows. Facading any type of geospatial data store and processing system, they can be used to support Machine Learning, Deep Learning & Artificial Intelligence systems. The goal of this task is to develop a holistic understanding and to derive best practices for integrating Machine Learning, Deep Learning, and Artificial Intelligence tools and principles into OGC Web service contexts. Even though an image analysis workflow is used here to describe interactions between components and interface requirements, it is emphasized that this task is not constraint to image analysis but should work with all types of data including vector information!

Essentially, the following two questions shall be answered:

To some extent, these questions can build on previous work, which allows to integrate machine learning tools behind OGC Web service interfaces by revising OGC Web Image Classification Service Discussion Paper (OGC 05-017) to support image classification using Machine Learning and Artificial Intelligence.

Previous Work OGC previously prototyped a Web Image Classification Service (WICS) interface (OGC 05-017) that defines these operations:

Using these operations, the WICS provides three types of classifications:

The previous work was not done with a Deep Learning Classifier and with focus on gridded imagery data, but that may not affect the Interface operations that are independent of algorithm type. The WICS operations directly match the functions shown in Figure 3 of the CFP.

Implementation of Components and Services

On the implementation side, this task shall support an image analysis and processing scenario. Imagine satellite imagery is stored in an image archive that is available to human image analysts and Machine Learning tools. An image analyst identifies a set of feature types on the images and makes this data available to the data store. These annotated data are available to both consumers and Machine Learning tools that use that data for training purposes. Depending on the type of available imagery data, Testbed-14 may differentiate two scenarios. In the first scenario, the image analyst uses prior- and post event data to identify for example areas destroyed by a natural disaster such as a hurricane. In the second scenario, the image analyst identifies feature types that do not take any change detection into account. The identified features could be compliant with Geography Mark-up Language (GML) application schemas such as the e.g. Multinational Geospatial Co-production Program (MGCP) Application Schema and the NSG Application Schema (NAS).

The Image Analyst queries image data (or is informed about new data by push notifications), identifies specific feature types, and provides the results of the analysis back to the system. These data include the identified feature types, the associated snippets (set of pixels in an image), as well as additional metadata as defined in Testbed-14.

A Machine Learning tool uses the Image Analysts' results as input training data to improve its learning algorithm. Rather than concentrating on the quality of the feature identification results, Testbed-14 shall explore the best workflows, service interaction patterns, an application schemata to express both analysis results and associated metadata such as trust levels and confidence, associated body of evidence, associated imagery, and optimized learning capabilities. The general workflow is illustrated in the figure below. The "Learning" box in the lower right corner shall illustrate the iterative nature of the workflow that uses results from the "Machine Learning and Artificial Intelligence" box to further train the model (e.g. by using external processes or data).

All data shall be made available at OGC data access services (e.g. WFS, WCS, SOS) as identified in responses to this Call for Participation. Additional catalog services might become part of the overall scenarios if necessary. This Call for Participation does not specify details on the involved service technology (i.e. participants can identify services types), but provides suggestions for possible implementations in the figure below.

Concept Study and Engineering Report

The Testbed-14 Machine Learning Engineering Report shall describe all experiences and lessons learned of the Machine Learning, Deep Learning & Artificial Intelligence implementations. In addition, it shall includes the results of a concept study that provides a truly holistic approach on the integration of machine learning and OGC Web services. This holistic approach may require some experimentation and shall include the following items:

In addition, the concept study shall analyze a geospatial feature extraction workflow that is slightly more complex than what can be realized in the implementation scenario described above. For simplicity, the process is outlined here in the form of Input-Process-Output stages. Issues that affect the Input stage include:

Some of the issues that affect the Process stage of a geospatial feature extraction workflow include:

Some of the issues that affect the Output stage of a geospatial feature extraction workflow include:

In the last decade, a technological framework known as SWIM (System Wide Information Management) has been developed in the FAA, EUROCONTROL, and more recently the Asia-Pacific Region as a viable model for Air Traffic Management (ATM) applications. "SWIM is a Federal Aviation Administration (FAA) advanced technology program designed to facilitate greater sharing of Air Traffic Management (ATM) system information, such as airport operational status, weather information, flight data, status of special use airspace, and National Airspace System (NAS) restrictions. SWIM will support current and future NAS programs by providing a flexible and secure information management architecture for sharing NAS information. SWIM will use commercial off-the-shelf hardware and software to support a Service Oriented Architecture (SOA) that will facilitate the addition of new systems and data exchanges and increase common situational awareness." (wikipedia)

SWIM addresses the communications and interoperability requirements of highly-distributed, loosely-coupled, and platform-independent components by consistently applying the principals of Service-Oriented Architecture (SOA). The major goal of SWIM is providing information to members of the civil aviation community. This information includes (but is not limited to) aeronautical, meteorological, and flight information, and it is rendered in a formal language such as XML.

The work in Testbed-14 is primarily motivated by the following aspects:

These aspects are subject of the following, simplified but realistic use case:

Testbed-14 shall address the following requirements:

This task combines a number of OGC technologies. It addresses both new capabilities at the service level as well as complex interaction patterns between services. In addition to the components described in this chapter, it makes use of WPS instances developed as part of the Exploitation Platform task.

The task consists of the four main topics WFS3.0, Federated Clouds, Security, and Workflows that make use of components provided by the Exploitation Platform task. The following figure provides an overview.

The following diagram provides an overview of all work items of this task. Elements from this diagram are used repeatedly further below to emphasize the various foci of the different topics.