OGC Interoperability Testbed Policies and Procedures

Date: 2006-03-20

Reference number of this OGC document: OGC 05-129r1

Version: 1.0 Category: OGC Policies and Procedures Editor: George Percivall

Interoperability Testbed Policies and Procedures

This document is an OGC Member approved Policies and Procedures Document.

Copyright © 2006 Open Geospatial Consortium (2006) All Rights Reserved. To obtain additional rights of use, visit http://www.opengeospatial.org/legal

Table of Contents

1

Introduction...1

2

Referenced Documents...1

3

Testbed Phases...1

3.1 Concept Development...2

3.2 Request for Quotation/Call for Participation (RFQ/CFP)...2

3.3 Testbed Team Formation and Kick-off...3

3.4 Testbed Execution...4

4

Execution Phase Tasks...5

4.1 Coordination...5

4.2 Assessment and Analysis...6

4.3 Architecture Development...6

4.4 Initiative Preparation...6

4.5 Specification Development...6

4.6 Component Development...6

4.7 Testing and Integration...6

4.8 Solution Transfer...7

4.9 Demonstration...7

4.10 Documentation...7

4.11 Compliance Testing...7

5

Testbed Policies...7

1 Revision history

Date Version Editor Primary

clauses modified

Description

2005-07-01 0.1 George Percivall N/A Initial Version 2005-12-17 0.2 George Percivall All Edits throughout

2006-03-20 1.0 George Percivall All Slight edits to release the document as approved by the SMAC, e.g., version number, dates, document references, etc.

1 Introduction

This document defines the policies and procedures for the conduct of an Open Geospatial Consortium (OGC) Interoperability Testbed.

Testbeds are governed by policies and procedures in “The OGC Interoperability Program”.

2 Referenced Documents

The following documents are referenced in this document. In all cases the latest version of the referenced document will be used.

 OGC Intellectual Property Rights Policy and Procedure http://www.opengeospatial.org/about/? page=ipr

 OGC Reference Model. http://orm.opengeospatial.org/

 OGC Adopted Technical Baseline. http://www.opengeospatial.org/specs/?page=baseline

 The OGC Interoperability Program, OGC Document 05-127-r1, 2005-03-20

3 Testbed Phases

An OGC IP Testbed is a research and development activity emphasizing the evaluation of what should be in a specification, how the specification should act, and how specification-based software should respond. While development is done during testbeds in terms of defining, documenting, and distributing

specifications and in terms of developing prototypical software that exercises the specification, this development is generally along the lines of proof-of-concept rather than in deliverable software. The general approach to performing testbeds is to go through a four step process as shown in Figure 1.

Concept Concept Development Development Task A Task A RFQ/CFP* RFQ/CFP* Development Development Task B Task B Team Formation Team Formation and Kick-of and Kick-of Task C Task C Testbed Testbed Execution Execution Task C Task C

3.1 Concept Development

Concept Development is an optional task for a Testbed and so is defined in a separate document.

Concept development begins with the Sponsors and IP Team working together to determine the Sponsors’ requirements. The main result is a feasibility report which documents a response from industry, the probable costs and benefits of given industry recommendations, an appraisal of where the recommendation seems to fit within the overall context of industry practice, and a draft technical architecture for the Sponsors’ consideration.

3.2 Request for Quotation/Call for Participation (RFQ/CFP)

Task B of an IP testbed is to release a Request for Quote/Call for Participation (RFQ/CFP or simply RFQ) and to receive and evaluate responses to this RFQ back from Industry. The RFQ consists of general statements pertaining to contracts and relationships between potential testbed participants and OGC, general response instructions, Sponsor requirements (refined from the ones used for the RFT by the responses to that RFT), a Work Breakdown Structure (WBS) that details tasks associated with the initiative, the initiative architecture, a Concept of Operations for the testbed, a schedule of work for the testbed, a communications plan for the initiative, and other miscellaneous information that a particular testbed may require. The responses should include the proposing organization’s technical solution, their cost-sharing requests for funding, and their in-kind contributions to the testbed.

Figure 2 – RFQ/CFP Development and Release

On completion of Task A and the acceptance of the feasibility study results by the potential initiative Sponsors. At this time, the potential sponsors also decide whether to be full sponsors and to provide human, technology, facilities, and/or financial resources to support the new initiative.

Given that the sponsors decide to move ahead with the initiatve, the IP Team will begin to develop the Request for Quote/Call for Participation. This exercise will include developing a budget for the activities required to address the Sponsors’ requirements, a prioritization of those requirements, an architecture that

incorporates the requirements, a work breakdown structure defining the tasks that will achieve meeting the requirements, and a concept of operations for conducting the initiative.

Once a draft RFQ is available, it will be presented to the Sponsors’ for their review and comments. Their comments will be addressed and incorporated by IP Team into the next version of the RFQ. The RFQ will again be presented to the Sponsors and will be either released or go through a second comment iteration. Once the Sponsors’ agree to the release, the RFQ is provided to Industry for response. The intention is that Industry (i.e., individual companies, universities, and governmental organizations within the geospatial industry) will submit proposals that explain the technical contribution they intend to make, how their contribution maps to the requirements and the WBS, the cost-sharing funds they are requesting to offset their engineering costs, and the in-kind contributions they will make to the test bed. These proposals are sent to the OGC and then submitted to the IP Team and the Sponsors.

3.3 Testbed Team Formation and Kick-off

Figure 3 – Testbed Kick-off Preparation Context

On receipt of the proposals, the Sponsors and IP Team perform a review process that includes two Decision Technical Exchange Meetings (Decision TEMs I and II). For all funded initiatives, the Sponsors determine the proposal review criteria. The Sponsors and IP Team use the sponsor defined review criteria and weight those criteria in relation the Sponsors’ objectives and requirements for the initiative.

Standing criteria for every initiative RFP proposal evaluation include the technical merits of the proposal, past performance of the participant within OGC (particularly OGC IP initiatives), adherence in the proposal to the work breakdown structure, and financial considerations (cost-sharing funding requests and in-kind contributions). The Sponsors may direct IP Team to evaluate other criteria that help discriminate amongst the proposing organizations in terms of meeting the Sponsors’ objectives. IP Team will review the

proposals in light of the criteria, especially a proposals planned technology and architecture approach, and make a recommendation to the Sponsors at Decision TEM I. The Sponsors and IP Team will review the IP Team recommendations in light of the Sponsors’ own evaluations. If questions arise regarding one or more proposals, IP Team will contact the proposing organization to seek clarification. If the sponsors raise other issues, IP Team will seek to resolve them and bring the resolution to the Sponsors. At Decision TEM II, IP Team will make a final funding recommendation to the Sponsors and the Sponsors will decide which

proposing organizations they will fund as well as the actual level of funding. Typically in test beds, a minimum of three proposing organizations will be funded per requirement or work item.

When the Sponsors have made their decisions with regard to participant funding, IP Team will notify the proposing organizations of the outcome of the Decision TEMs. Once the selected participants have been notified, The OGC will begin negotiations with the selected participants. These negotiations will discuss funding, tasks to be performed, in-kind contributions that will be provided by the participant, the nature of the statement of work and the work breakdown. These negotiations will form the basis of an agreed to Statement of Work (SOW) and a contract between OGC and the participant in question. While this process is expected to be iterative as terms of the contract are finalized, the contract is the basis for the relationship between OGC and the participant.

If a selected Participant is not an OGC member, they should begin the membership registration process. Membership will be required before the final Participant contract is signed.

Once the OGC IP Team has decided that negotiations are at a reasonable state of completion, they will complete work on the work package of materials to be provided to the Sponsors and participants at the Kickoff. This will include an updated technical architecture, an initiative schedule, the initiative concept of operations, and the final work breakdown. One goal of the Test Bed kickoff meeting is to obtain consensus agreement of the work package by all stakeholders within the initiative.

Additionally, OGC IP Team will provide templates for statements of work (SOW) to participants. The participants will complete the templates based on the tasks they accepted during the negotiations. Upon completion, the participants will submit their SOWs to OGC. OGC will review the SOWs for accuracy and may iterate with the participants until mutual agreement is achieved. On completion of the SOWs, OGC will develop a contract containing a Profession Services Agreement (PSA) and a statement of Rights of Patent. These contracts will follow OGC membership and other contractual precedents.

3.4 Testbed Execution

Figure 4 - Testbed Execution

4

The Kick-off marks the beginning of the Execution phase of the initiative. Using the agreed upon work package as the governing documents for the conduct of the initiative, the stakeholders will begin the principal tasks of developing or enhancing engineering specifications, developing prototypical software components that exercise the newly developed specifications, and testing those components and

specifications. The key outcome of the initiative is an Interoperability Program Report (see section 13.6 for a detailed explanation of Interoperability Program Reports or IPRs). In the stages where the IPR is being developed and reviewed it will be typically referenced as a Draft Interoperability Program Report (DIPR). The participants in conjunction with one another, the Sponsors, and IP Team will begin developing relevant DIPRs pertaining to requirements identified by the Sponsors. One stakeholder representative will act as the lead author for the document, but a group of participants are expected and obligated to support the actual creation and development of the DIPR; this group is referred to as a Work Group. The author may be a participant technical representative, a Sponsor representative (typically technical), or on some rare occasions an IP Team member. The DIPR is iterated until the Work Group believes it to be sound enough for prototypical interoperable software components to be developed or enhanced to test the specification. This act of testing specifications and the prototypical software components exercising them is called a Technology Integration Experiment (TIE). It is anticipated that a TIE will go through some number of iterations before Prototypical Software Components share information interoperably. A TIE is generally understood to minimally include a participant providing a client component and another participant providing a server component working in conjunction to test the implementation of a particular specification.

4 Execution Phase Tasks

This section describes a flexible framework of standard, repeatable tasks for the execution phase of a testbed. These tasks may be performed by any of the Testbed Team members. The task are adapted as necessary to address the requirements of the specific Testbed. These tasks are executed with a Virtual Team Infrastructure. These tasks are used to define the SOW for in a Participant Agreement.

Figure 5 – Testbed Execution Phase Tasks

4.1 Coordination

This task enables overall Testbed coordination between OGC Staff, OGC IP Team, Sponsors, Participants, and other TC/PC Members as required. Initiative Coordination includes the following Subtasks:

 Collaborative Environment - OGC IP Team provides synchronous and asynchronous

collaboration environments for cross organizational, globally distributed, virtual teams working interdependently to execute Initiative Orders

.

Activities under this subtask include reading email and engaging in collaborative discussions such as regular teleconferences.

 Initiative Plan Development – Support development of Project Plans, Project Schedules and Work Breakdown Structures (Work Package). May include Technical and Project Management Approach, Tasks/Schedules, Communications Plans, Resource Plans, Risk and Mitigation Strategies, and definition of the Specification and/or Component Development and Integration Tasks necessary to realize the Technical, Operational and Systems Architectures.

 Management - Services ensuring Initiative Order participants are staying within designated budgets, that the work is progressing according to the agreed schedule, and that the tasks identified in the Statement of Work, including status reporting, are executed..

 Communication – Includes communicating ongoing and planned Initiative and Work Item Status to OGC and other organizations such as ISO. This task does not include IP Business Development functions.

4.2 Assessment and Analysis

This task analyzes and documents an organization’s or domains existing capabilities and assesses

requirements for OGC compliant technology. This task can occur as part of any testbed planning process. .

4.3 Architecture Development

This task defines the architectural views for any given Initiative. In the context of the Open GIS

Interoperability Program, there are potentially three–and perhaps more - architectural views for any given effort. These views are the Operational Architecture, Technical Architecture, and System Architecture. Part of the Architecture Development task may be the use of an RFQ/CFP to industry to enable

organizations interested in participating in an Interoperability Initiative to respond with a proposal. This task may also be implemented during Planning Studies.

4.4 Initiative Preparation

This task defines the participant budget (if any) and defines and executes agreements and contracts that outline roles and responsibilities of each participant. This task may refine the Work Package.

4.5 Specification Development

This task defines and develops models, schemas, encodings, and interfaces necessary to realize required Architectures. It includes specification Pre-design and Design tasks. This task may also include activities to coordinate ongoing Initiatives with Specification Program activities.

4.6 Component Development

This task develops prototype interoperable commercial software components based on draft candidate implementation specifications or adopted specifications necessary to realize the required Architecture.

4.7 Testing and Integration

This task integrates, documents and tests functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements. Includes Technology Integration Experiments (TIEs).

4.8 Solution Transfer

This task prepares prototypical interoperable components so that they can be assembled at required sites.

4.9 Demonstration

This task defines, develops and deploys functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements.

4.10 Documentation

This Task ensures development and maintenance of the pre-specification, pre-conformant interoperable OpenGIS technologies (including Interoperability Program Reports) and the systems level documentation (example user documentation, etc.) necessary to execute the Initiative. This task may include coordination with OGC Specification Program activities including the Documentation Team.

4.11 Compliance Testing

This Task ensures development of draft compliance test guidelines (at a minimum) and test suites for engineering specifications detailed in Interoperability Program Reports. This task includes coordination with OGC Specification Program activities including the Compliance Testing and Interoperability Evaluation Subcommittee.

5 Testbed Policies

Policies defined in the OGC Document “The OGC Interoperability Program” apply to all Testbeds. This section contains additional policies that apply specifically to Testbeds.

5.1 Financial Model for a Testbed

An IP testbed works on a model of participant in-kind contributions of engineering resources, technology, and/or facilities and cost-share funding provided by the Sponsors. The coordinating organization for initiative funding activities is the OGC. Individual Initiatives fall within this spectrum, wherein participants may provide 100% of their funding as in-kind contributions to the initiative or the initiative may cover some percentage of the participants engineering costs. OGC will not cover the costs of equipment or software required for the normal development of participant software products. Nor will OGC fund the purchase of additional hardware or software. OGC will support the unique costs associated with

engineering labor and travel in direct support of the initiative. This would include, but not necessarily be limited to, labor to develop engineering requirements, engineering specification reports, prototypical software component development exercising OGC specifications, instantiating new services based on existing software that exercises relevant OGC specifications, documentation of specifications,

demonstrations of prototypical or existing software components that exercise OGC specifications or draft specifications, travel to meetings scheduled for discussion of specification development and initiative activities, and travel to demonstrations. A given initiative may be purely in-kind meaning that cost-share funds will not be provided. This will be clearly spelled out in the relevant RFQ/CFP.

3.1 Concept Development

Concept Development is an optional task for a Testbed and so is defined in a separate document.

Concept development begins with the Sponsors and IP Team working together to determine the Sponsors’ requirements. The main result is a feasibility report which documents a response from industry, the probable costs and benefits of given industry recommendations, an appraisal of where the recommendation seems to fit within the overall context of industry practice, and a draft technical architecture for the Sponsors’ consideration.

3.2 Request for Quotation/Call for Participation (RFQ/CFP)

Task B of an IP testbed is to release a Request for Quote/Call for Participation (RFQ/CFP or simply RFQ) and to receive and evaluate responses to this RFQ back from Industry. The RFQ consists of general statements pertaining to contracts and relationships between potential testbed participants and OGC, general response instructions, Sponsor requirements (refined from the ones used for the RFT by the responses to that RFT), a Work Breakdown Structure (WBS) that details tasks associated with the initiative, the initiative architecture, a Concept of Operations for the testbed, a schedule of work for the testbed, a communications plan for the initiative, and other miscellaneous information that a particular testbed may require. The responses should include the proposing organization’s technical solution, their cost-sharing requests for funding, and their in-kind contributions to the testbed.

Figure 2 – RFQ/CFP Development and Release

On completion of Task A and the acceptance of the feasibility study results by the potential initiative Sponsors. At this time, the potential sponsors also decide whether to be full sponsors and to provide human, technology, facilities, and/or financial resources to support the new initiative.

Given that the sponsors decide to move ahead with the initiatve, the IP Team will begin to develop the Request for Quote/Call for Participation. This exercise will include developing a budget for the activities required to address the Sponsors’ requirements, a prioritization of those requirements, an architecture that

incorporates the requirements, a work breakdown structure defining the tasks that will achieve meeting the requirements, and a concept of operations for conducting the initiative.

Once a draft RFQ is available, it will be presented to the Sponsors’ for their review and comments. Their comments will be addressed and incorporated by IP Team into the next version of the RFQ. The RFQ will again be presented to the Sponsors and will be either released or go through a second comment iteration. Once the Sponsors’ agree to the release, the RFQ is provided to Industry for response. The intention is that Industry (i.e., individual companies, universities, and governmental organizations within the geospatial industry) will submit proposals that explain the technical contribution they intend to make, how their contribution maps to the requirements and the WBS, the cost-sharing funds they are requesting to offset their engineering costs, and the in-kind contributions they will make to the test bed. These proposals are sent to the OGC and then submitted to the IP Team and the Sponsors.

3.3 Testbed Team Formation and Kick-off

Figure 3 – Testbed Kick-off Preparation Context

On receipt of the proposals, the Sponsors and IP Team perform a review process that includes two Decision Technical Exchange Meetings (Decision TEMs I and II). For all funded initiatives, the Sponsors determine the proposal review criteria. The Sponsors and IP Team use the sponsor defined review criteria and weight those criteria in relation the Sponsors’ objectives and requirements for the initiative.

Standing criteria for every initiative RFP proposal evaluation include the technical merits of the proposal, past performance of the participant within OGC (particularly OGC IP initiatives), adherence in the proposal to the work breakdown structure, and financial considerations (cost-sharing funding requests and in-kind contributions). The Sponsors may direct IP Team to evaluate other criteria that help discriminate amongst the proposing organizations in terms of meeting the Sponsors’ objectives. IP Team will review the

proposals in light of the criteria, especially a proposals planned technology and architecture approach, and make a recommendation to the Sponsors at Decision TEM I. The Sponsors and IP Team will review the IP Team recommendations in light of the Sponsors’ own evaluations. If questions arise regarding one or more proposals, IP Team will contact the proposing organization to seek clarification. If the sponsors raise other issues, IP Team will seek to resolve them and bring the resolution to the Sponsors. At Decision TEM II, IP Team will make a final funding recommendation to the Sponsors and the Sponsors will decide which

proposing organizations they will fund as well as the actual level of funding. Typically in test beds, a minimum of three proposing organizations will be funded per requirement or work item.

When the Sponsors have made their decisions with regard to participant funding, IP Team will notify the proposing organizations of the outcome of the Decision TEMs. Once the selected participants have been notified, The OGC will begin negotiations with the selected participants. These negotiations will discuss funding, tasks to be performed, in-kind contributions that will be provided by the participant, the nature of the statement of work and the work breakdown. These negotiations will form the basis of an agreed to Statement of Work (SOW) and a contract between OGC and the participant in question. While this process is expected to be iterative as terms of the contract are finalized, the contract is the basis for the relationship between OGC and the participant.

If a selected Participant is not an OGC member, they should begin the membership registration process. Membership will be required before the final Participant contract is signed.

Once the OGC IP Team has decided that negotiations are at a reasonable state of completion, they will complete work on the work package of materials to be provided to the Sponsors and participants at the Kickoff. This will include an updated technical architecture, an initiative schedule, the initiative concept of operations, and the final work breakdown. One goal of the Test Bed kickoff meeting is to obtain consensus agreement of the work package by all stakeholders within the initiative.

Additionally, OGC IP Team will provide templates for statements of work (SOW) to participants. The participants will complete the templates based on the tasks they accepted during the negotiations. Upon completion, the participants will submit their SOWs to OGC. OGC will review the SOWs for accuracy and may iterate with the participants until mutual agreement is achieved. On completion of the SOWs, OGC will develop a contract containing a Profession Services Agreement (PSA) and a statement of Rights of Patent. These contracts will follow OGC membership and other contractual precedents.

3.4 Testbed Execution

The Kick-off marks the beginning of the Execution phase of the initiative. Using the agreed upon work package as the governing documents for the conduct of the initiative, the stakeholders will begin the principal tasks of developing or enhancing engineering specifications, developing prototypical software components that exercise the newly developed specifications, and testing those components and

specifications. The key outcome of the initiative is an Interoperability Program Report (see section 13.6 for a detailed explanation of Interoperability Program Reports or IPRs). In the stages where the IPR is being developed and reviewed it will be typically referenced as a Draft Interoperability Program Report (DIPR). The participants in conjunction with one another, the Sponsors, and IP Team will begin developing relevant DIPRs pertaining to requirements identified by the Sponsors. One stakeholder representative will act as the lead author for the document, but a group of participants are expected and obligated to support the actual creation and development of the DIPR; this group is referred to as a Work Group. The author may be a participant technical representative, a Sponsor representative (typically technical), or on some rare occasions an IP Team member. The DIPR is iterated until the Work Group believes it to be sound enough for prototypical interoperable software components to be developed or enhanced to test the specification. This act of testing specifications and the prototypical software components exercising them is called a Technology Integration Experiment (TIE). It is anticipated that a TIE will go through some number of iterations before Prototypical Software Components share information interoperably. A TIE is generally understood to minimally include a participant providing a client component and another participant providing a server component working in conjunction to test the implementation of a particular specification.

4 Execution Phase Tasks

This section describes a flexible framework of standard, repeatable tasks for the execution phase of a testbed. These tasks may be performed by any of the Testbed Team members. The task are adapted as necessary to address the requirements of the specific Testbed. These tasks are executed with a Virtual Team Infrastructure. These tasks are used to define the SOW for in a Participant Agreement.

Figure 5 – Testbed Execution Phase Tasks

4.1 Coordination

This task enables overall Testbed coordination between OGC Staff, OGC IP Team, Sponsors, Participants, and other TC/PC Members as required. Initiative Coordination includes the following Subtasks:

 Collaborative Environment - OGC IP Team provides synchronous and asynchronous

collaboration environments for cross organizational, globally distributed, virtual teams working interdependently to execute Initiative Orders

.

Activities under this subtask include reading email and engaging in collaborative discussions such as regular teleconferences.

 Initiative Plan Development – Support development of Project Plans, Project Schedules and Work Breakdown Structures (Work Package). May include Technical and Project Management Approach, Tasks/Schedules, Communications Plans, Resource Plans, Risk and Mitigation Strategies, and definition of the Specification and/or Component Development and Integration Tasks necessary to realize the Technical, Operational and Systems Architectures.

 Management - Services ensuring Initiative Order participants are staying within designated budgets, that the work is progressing according to the agreed schedule, and that the tasks identified in the Statement of Work, including status reporting, are executed..

 Communication – Includes communicating ongoing and planned Initiative and Work Item Status to OGC and other organizations such as ISO. This task does not include IP Business Development functions.

4.2 Assessment and Analysis

This task analyzes and documents an organization’s or domains existing capabilities and assesses

requirements for OGC compliant technology. This task can occur as part of any testbed planning process. .

4.3 Architecture Development

This task defines the architectural views for any given Initiative. In the context of the Open GIS

Interoperability Program, there are potentially three–and perhaps more - architectural views for any given effort. These views are the Operational Architecture, Technical Architecture, and System Architecture. Part of the Architecture Development task may be the use of an RFQ/CFP to industry to enable

organizations interested in participating in an Interoperability Initiative to respond with a proposal. This task may also be implemented during Planning Studies.

4.4 Initiative Preparation

This task defines the participant budget (if any) and defines and executes agreements and contracts that outline roles and responsibilities of each participant. This task may refine the Work Package.

4.5 Specification Development

This task defines and develops models, schemas, encodings, and interfaces necessary to realize required Architectures. It includes specification Pre-design and Design tasks. This task may also include activities to coordinate ongoing Initiatives with Specification Program activities.

4.6 Component Development

This task develops prototype interoperable commercial software components based on draft candidate implementation specifications or adopted specifications necessary to realize the required Architecture.

4.7 Testing and Integration

This task integrates, documents and tests functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements. Includes Technology Integration Experiments (TIEs).

4.8 Solution Transfer

This task prepares prototypical interoperable components so that they can be assembled at required sites.

4.9 Demonstration

This task defines, develops and deploys functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements.

4.10 Documentation

This Task ensures development and maintenance of the pre-specification, pre-conformant interoperable OpenGIS technologies (including Interoperability Program Reports) and the systems level documentation (example user documentation, etc.) necessary to execute the Initiative. This task may include coordination with OGC Specification Program activities including the Documentation Team.

4.11 Compliance Testing

This Task ensures development of draft compliance test guidelines (at a minimum) and test suites for engineering specifications detailed in Interoperability Program Reports. This task includes coordination with OGC Specification Program activities including the Compliance Testing and Interoperability Evaluation Subcommittee.

5 Testbed Policies

Policies defined in the OGC Document “The OGC Interoperability Program” apply to all Testbeds. This section contains additional policies that apply specifically to Testbeds.

5.1 Financial Model for a Testbed

An IP testbed works on a model of participant in-kind contributions of engineering resources, technology, and/or facilities and cost-share funding provided by the Sponsors. The coordinating organization for initiative funding activities is the OGC. Individual Initiatives fall within this spectrum, wherein participants may provide 100% of their funding as in-kind contributions to the initiative or the initiative may cover some percentage of the participants engineering costs. OGC will not cover the costs of equipment or software required for the normal development of participant software products. Nor will OGC fund the purchase of additional hardware or software. OGC will support the unique costs associated with

engineering labor and travel in direct support of the initiative. This would include, but not necessarily be limited to, labor to develop engineering requirements, engineering specification reports, prototypical software component development exercising OGC specifications, instantiating new services based on existing software that exercises relevant OGC specifications, documentation of specifications,

demonstrations of prototypical or existing software components that exercise OGC specifications or draft specifications, travel to meetings scheduled for discussion of specification development and initiative activities, and travel to demonstrations. A given initiative may be purely in-kind meaning that cost-share funds will not be provided. This will be clearly spelled out in the relevant RFQ/CFP.