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 Pilot 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 refining engineering specifications as needed, developing prototypical software components that exercise the draft specifications, and testing those components and specifications. The key
outcome of the initiative is an Interoperability Program Report. In the stages where the IPR is being developed and reviewed it will be typically referenced as a Draft Interoperability Program Report DIPR.
4
Figure 4 Pilot Execution
The participants in conjunction with one another, the Sponsors, and OGC 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.
The primary goal of a pilot from the perspective the sponsors is to implement a prototypical set of software components that exercise the set of OGC specifications and draft specifications for which the Sponsors
have requirements in terms of enabling interoperable geospatial technologies within their environment. This prototypical capability will be instantiated in an environment determined by the Sponsors. This
environment will form a node on the OGC Network. Therefore, participants will provide their prototypical software components and will conduct TIEs to determine if these components can function in an
interoperable environment. Typically there will be several “software builds” until interoperability in the environment is demonstrated via the TIEs. Various systems may be required by the Sponsors to measure the
performance of the system. Once the prototypical system is deemed complete it most likely will be demonstrated to the Sponsors and any audience they may indicate. The participants will support efforts to
install and integrate the system into the Sponsors designated environment. They will provide necessary documentation to support these efforts. The integrated prototypical system most likely will limited
compared to a fully operational system that the Sponsors may use in their day-to-day business. However
5
the prototypical system should exercise a reasonable subset of the functions the Sponsors use in their enterprise.
If, during the course of Pilot Project execution, modifications to an existing OpenGIS specification are found necessary, then a change proposal must be developed that documents the change. This change
proposal does not need to be adopted, rather it is intended to serve as documentation of both the change and the requirement that led to the change. The change proposal will be submitted to appropriate Revision
Working Group using OGC communications. If a RWG does not exist, then the TC Chair must be notified of the pending change proposals.
4 Execution Phase Tasks
This section describes a flexible framework of standard, repeatable tasks for the execution phase of a pilot. These tasks may be performed by any of the Pilot Team members. The task are adapted as necessary to
address the requirements of the specific Pilot. These tasks are executed with a Virtual Team Infrastructure. These tasks are used to define the SOW for in a Participant Agreement.
Figure 5 – Pilot Execution Phase Tasks
4.1 Coordination
