Skip to end of metadata
Go to start of metadata

1. Introduction

This document outlines the plan for Release 2 Elaboration. It provides a high level overview of all aspects of the elaboration phase and will be used as the basis for planning all Release 2 Elaboration activities.

1.1. References

1.2. Elaboration Schedule for Release 2

The following schedule will be followed for the three Elaboration phase iterations:

  • R2E1: 09/05/11 - 10/28/11
  • R2E2: 10/31/11 - 12/23/11
  • R2E3: 01/03/12 - 02/28/12

The Life Cycle Architecture Review period will occupy the two weeks following the third iteration of Elaboration, with the review itself tentatively planned for the week of March 11, 2012. (Although the Elaboration phase schedule nominally ends on a Tuesday, the team will bring the bulk of its technical work to a close the Friday before, 2/24/2012.)

1.3. Themes and Features for Release 2

This section is drawn from the Release 2 Construction Plan.

CI Release 2 is designated the Managed Instrument Network release, reflecting our primary theme of developing integrated support for OOI Marine Observatory instrument providers and operators. Secondary themes are support for operational management of the CI infrastructure and network, integration of computational tools for data manipulation, analysis, and visualization, and early prototyping of release 3 capabilities.

Managed Instrument Network (Primary Theme)

The goal of the primary theme is to provide end-to-end control of data collection and advanced control of managed instruments for OOI Marine Observatory instrument providers and operators. The features planned under this theme are:

Operate Observatory

This includes activities such as managing policies for marine resources (observatories, platforms, instruments, etc.), managing resources and their use, and tracking and auditing access to resources and services

Operate Platforms and Instruments

This includes activities such as configuring and deploying instruments, monitoring platform and instrument state and usage, and performing platform- or instrument-specific commands

Manage Instrument Lifecycle

This includes most instrument lifecycle activities such as commissioning and decommissioning, testing for marine network qualification, and managing instrument participation in the OOI network.

Test and Troubleshoot Instruments

This includes activities such as applying test procedures to test and troubleshoot an instrument, testing its data for OOI format compliance, and accessing supporting materials for resources in the OOI network (manuals, pictures, logs etc.).

Acquire Data and Generate Data Products

This includes activities related to data acquisition and data product generation processes, including accessing and processing an instrument’s raw data, and controlling acquisition, dissemination, and persistence of data from platforms, instruments, or observatories.

CI Infrastructure and Network Management (Secondary Theme)

The goal of this theme is to support those parts of operations and management of the CI portion of the OOI network that are not covered by existing network management tools. The features planned under this theme are:

Monitor resource status

This includes activities related to determining location, repair state, etc. throughout the life of the resource

Enhanced user accounts

This introduces personalized profiles for individual users, and supports association between a single user id and multiple external identities

Define and manage data persistence

Enhanced Data Interaction and Visualization (Secondary Theme)

This theme is aimed at providing more powerful support to science end-users, particularly in the areas of locating and working with data of interest. The features planned under this theme are:

Improved search tools

This expands the tools provided for search-by-query of OOI data resources, introducing more sophisticated metadata search capabilities, filtering and organizing search results, saved query and prospective query capabilities

Data history and provenance

This introduces concepts of versions of data resources, and expands concepts of provenance

Visualization tool integration

This allows externally created tools for generating data visualizations to be registered and used through the OOI ION interface, focusing specifically on developer-created visualization workflows and tools, and MatLab-based visualizations

Early Prototyping (Secondary Theme)

The Early Prototyping theme allows for experimentation with features or technologies to be introduced in a later release. So far only one feature is planned:

Mobile Delivery Prototyping

Experiment with the opportunities presented by use of the OOI on handheld devices such as smartphones or tablet computers, and develop understanding of user desires and development requirements

2. Product Management Activities

2.1 Release 2 Product Specification Activities

The Product Specification will be refined in Elaboration to completely characterize activities that can be performed for all key resources of the OOI system.

An initial update from the Inception phase version will be delivered in Elaboration Iteration 1. This will make any corrections required due to the development of detailed architectural concepts in the iteration. This revision will also reflect inputs received from OOI stakeholders after the initial delivery.

During Elaboration Iteration 3, the Product Specification for Release 2 will be finalized, and draft Product Specification materials for Release 3 and Release 4 will be developed.

2.2 Release 2 Product Description Activities

The Product Description will be refined in Elaboration to completely specify the use cases that will be accomplished during Release 2.

An initial update of use cases from the Inception phase will be delivered in Elaboration Iteration 1. This will make any corrections required due to the development of detailed architectural concepts in the iteration, and reflect inputs received from OOI stakeholders after the Inception delivery.

During Elaboration Iteration 3, the Product Description and Use Cases for Release 2 will be published in its final form for this release.

2.3 Release 2 Adoption and Engagement Activities

Interest in OOI is increasing in the scientific and technical community. Within the OOI team, implementing organizations are playing increasingly active roles in defining the functions and algorithms to be implemented by the CI, which is in turn responding to increasing requests for information about the current and proposed implementations.

With the completion of Release 1, internal and external communities alike are interested in seeing the capabilities and ideas represented by the work performed so far. In turn, the OOI CI team is eager to obtain feedback about the degree to which Release 1 goals were accomplished, and information about what is needed in the coming release.

For these goals to be met, the internal and external communities, including both users and stakeholders, must be engaged in the CI mission and activities. Furthermore, as each release is completed, tested, and rolled out for inspection and use, the CI team and OOI team must encourage its adoption in the target communities. Strategies to increase engagement and adoption must be appropriate to the maturity of the system, the stage of the program, and the target audiences.

With this in mind, the CI team will develop an Engagement and Adoption Road Map during the Elaboration phase, in consultation and coordination with Ocean Leadership and marine Implementing Organizations. The principals for this Road Map will will be outlined at the Release 2 LCO review, and discussed and refined during the development of the document in the Elaboration phase.

The initial document will be released for review by Ocean Leadership and Implementing Organizations in Elaboration Iteration 1.

3. Requirements and Engineering Activities

The Elaboration phase calls for "baselining the system and subsystem requirements", with the Chief System Engineer managing the system engineering process of requirements definition. At the end of the phase, the requirements should be stable and complete, and correctly allocated to use cases and service components. (Reference the Elaboration Phase description for further details.)

To accomplish these activities, the Chief System Engineer and supporting team members will perform or coordinate the following tasks during this phase:

  • mapping of Requirements to Use Cases and Components;
  • baselining of system and subsystem Requirements;
  • development of an Integration and Verification Plan;
  • development of candidate Integration and Verification procedures; and
  • continued support of Risk Analysis and Configuration Control activities.

4. Design and Development Activities

The principal goals of the Elaboration phase are:

  • Baselining the use cases and performance stress cases,
  • Baselining the system and subsystem requirements,
  • Baselining the architecture as quickly as possible, recognizing that significant prototyping activities are necessary to mitigate risk,
  • Demonstrating that the baseline architecture will support the use cases and implement the baseline requirements,
  • Defining all of the major risks and capturing them in the Risk Register,
  • Defining plans and procedures for integration and verification,
  • Defining a plan for the Construction phase.

Essential activities during the Elaboration phase include:

  • Building an executable architecture prototype that is end-to-end across all relevant subsystems, and that integrates all core technologies,
  • Producing production quality code. While the development of throwaway, exploratory prototypes is not excluded, and an evolutionary development approach is encouraged, the goal of Elaboration remains usable code for the release,
  • Establishing an understanding of the use cases and defining a complete set of requirements in much greater detail than occurred during Inception,
  • Elaborating the processes to be used during the Construction phase, including writing Integration and Verification Plans and a candidate set of Integration and Verification Procedures,
  • Finalizing technology selections to implement the baseline architecture, including documented trade studies and analysis.

4.1. Overview of Activities

These activities must be performed for Release 2 components (as appropriate).

Applies to ALL service components Applies to service components marked LCA
Applies to ALL use cases Applies to use cases marked LCA
Product content Produced to these criteria In this artifact
X   X   related Use Cases, Components and Requirements mapped formal mapping exists following our described process Use cases on Confluence linked from requirements in DOORS linked to services and their elements on Confluence (baselined at end of elaboration)
X       any risks associated with the component are updated reflecting results of work performed on component during phase Risk register in SAF
X   X   required User Interfaces mocked up, reviewed, coded initial user review has taken place; code viable (but not integrated) UX specifications
    X   end-to-end function of use case is allocated to components sequence diagram exists showing components involved Enterprise Architect
X       changes and refinements to system architecture and technology list as found out by prototyping and implementation
reviewed and baselined for milestone Architecture Specification in Confluence and Enterprise Architect
X       Integration Test descriptions for LCA and IOC tests complete reviewed and baselined for milestone Test Plan

X     required LCA level Integration Tests complete
integration test code or scenario written and passes Integration tests documented in ?
  X     working integrated core code and unit tests checked in all unit and integration tests pass; stubs/remaining work detailed Unit tests documented in Confluence design page for task; integration tests documented in ?
  X   X item's pending tasks are fully described described as explicit DesignITs of 5d scope Iteration task specifications
  X   X related User/Operator documentation outlined outline includes main topics to address Document Register

4.2. Architecture Activities

In Elaboration, the Architecture team will build an executable architecture prototype that is end-to-end across all relevant subsystems, and that integrates all core technologies. The principal architectural goals are to baseline the architecture as quickly as possible, recognizing that significant prototyping activities are necessary to mitigate risk; and to demonstrate that the baseline architecture will support the use cases and implement the baseline requirements.

In addition, the Architecture team has a leadership role in completing several deliverable artifacts for the LCA review at the end of Elaboration. The team must provide updates to, and complete the presentation of, the following artifacts:

  • the Architecture and Design document in Confluence, incorporating designs for candidate user interfaces as developed by the UX team;
  • the architectural drawings comprising the specifications for the CI, which are maintained in Enterprise Architect; and
  • the Technology List of technologies that have been evaluated for the Release, including technologies that have been selected for the Release as well as significant technologies that were not chosen.

The team will also provide significant inputs to the following artifacts:

  • the Risk Register list of identified risks;
  • the Construction Execution Plan;
  • Integration and Verification Plans and a Candidate set of Integration and Verification procedures;
  • a baselined set of use cases;
  • baselined system and subsystem requirements;
  • software prototypes specification, advice, and reports;
  • external workshops leadership, participation, and reports; and
  • performance stress cases.

The specific tasks associated with the above artifact deliveries are described the same way for all subsystems, and are listed and tracked within each subsystem as part of the task tracking activities of the project (see next subsection and the Appendix).

4.3 Subsystem Activities

For each subsystem, a set of activities will be performed in Elaboration that accomplish the necessary technical progress for each component of the subsystem. The broad set of activities to be performed is described in detail in the project pages referenced in Table 4.1-1.

The broad scope of work for each subsystem is described here in Table 4.3-1 for the key subsystems of Release 2: COI, CEI, DM, SA, AS, EOI, and UX, with specific subsystem construction plans referenced by the link in the first column.

Finally, detailed tasks for each subsystem are reflected in the Appendix.

PageSubsystem NameSubsystem DescriptionRelease 2 Focus
MI Construction PlanMarine Integration

This Marine Integration subsystem is responsible for the design and implementation of the Instrument Platform Agent Architecture (IPAA). The IPAA is part of the CI Marine Network Integration which will implement, integrate and activate each of the Marine Nodes into the Integrated Observatory Network. The IPAA is responsible for the specification, development and prototyping of the OOI standard instrument agent and instrument/device driver strategy.

The focus of MI is to deliver the design and implementation of the Instrument Platform Agent Architecture (IPAA). The IPAA is part of the CI Marine Network Integration which will implement, integrate and activate each of the Marine Nodes into the Integrated Observatory Network. The IPAA is responsible for the specification, development and prototyping of the OOI standard instrument agent and instrument/device driver strategy.

R2 AS Construction PlanAnalysis & Synthesis

The Analysis & Synthesis subsystem supports a wide variety of data and data product analysis, manipulation, generation and presentation, especially through visualization. It also provides the virtual collaboration platform that will be applied to realize virtual observatories, classrooms and laboratories.

The focus of A&S-R2 is delivery of the following services:

  • Data Analysis and Visualization Services—provides a generalized analysis and synthesis framework for transforming, analyzing, and visualizing data through the application of user and community developed processes.
R2 CEI Construction PlanCommon Execution Infrastructure

The Common Execution Infrastructure subsystem is responsible for the services to manage the distributed, immediate mode execution of processes.

The focus of CEI-R2 is to extend and utilize the CEI-R1 functionality by delivering the following services:

  • Elastic Computing Services-extends the elastic processing unit infrastructure
  • Execution Engine Catalog & Repository Services-provides the models and capabilities to describe execution engines for processes
  • Resource Management Services-establishes standard models for the operational management (monitor & control) of stateful and taskable resources.
  • Process Management Services—provides the scheduling, and management services for policy-driven process execution at specified execution sites. The service supports the coupling of the dynamic data distribution service with the process and its triggering. Provenance and citation annotation are registered associating the input and output products with the execution process and its operating context.
  • Process Catalog and Repository Services—maintains process definitions and references to registered process engine configurations and execution sites.
  • Integration with National Computing Infrastructure—provide the capability to deploy OOI processing, in particular data stream processing on to the national/commercial computing infrastructure, focused on the Amazon Web Services (EC2)
R2 COI Construction PlanCommon Operating Infrastructure

The Common Operating Infrastructure subsystem is a task and product account responsible for providing the services and distributed infrastructure to build a secure, scalable, fault-tolerant federated system of independently operated observatory components.

The focus of COI-R2 is to extend and utilize the COI-R1 functionality by delivering the following services:

  • Federated Facility Services—provides management and governance services for a collection of resources on behalf of a group or individual. It represents the domain of authority for the set of resources managed by the facility. The governance services provide for the following set of collaboration agreements: membership, partnership, federation, and delegation. Delegation, for example, is used to give a marine observatory the rights to operate/manage a research team’s instrument on their behalf.
  • Capability Container & Distributed Service Infrastructure — provides the distributed service infrastructure for the secure, scalable, and fault-tolerant operation and federation of the Facilities (operational domains of authority) that comprise the deployed system of systems: Presentation Framework - the web services and browser presentation containers as well as the web user interface “portlet” building blocks; Governance Framework - identity and policy management to govern the use of resources by participants through policy enforcement and decision services; Service Framework - provisioning, federating, delegating, and binding service interactions between resources; Resource Framework - provisioning, managing, and tracking the use of resources; Distributed State Management - managing active and persisted distributed state; Federated Message Exchange - messaging, bulk data transfer, guaranteed data transfer, and provisioning streaming media channels.
  • Resource Lifecycle Services—resource management services to transition a resource from cradle to grave.
R2 DM Construction PlanData Management

The Data Management Subsystem is responsible for providing life cycle management, federation, preservation and presentation of OOI data holdings and associated metadata via data streams, repositories and catalogs.

The focus of DM-R2 is to extend and utilize the DM-R1 functionality by delivering the following services:

  • OOI Common Data and Metadata Model—provides the common data and metadata model for the Integrated Observatory into which all integrated data products must translate, if required, for shared syntactic and semantic access. The scope of syntactic representation of observed data shall be extendable and comprehensive. The scope of the observatory metadata model and semantic representation shall be extendable yet constrained in implementation to at least meet all data requirements imposed by the set "Core" OOI sensors and their associated Quality Assurance/Quality Control processing.
  • Persistent Archive Services—provides cataloging, preservation, validation, and curation services to organize, persist, and maintain data holdings with their associated metadata for an individual, group, and/or community.
  • Search and Navigation Services—provides query and browsing services by context, based on the content metadata and semantics of the data holdings.
  • External Data Access Services—provides an extensible suite of access interfaces and data formats for interoperability with external communities and applications
R2 EOI Construction PlanExternal Observatories Integration

This subsystem ensures the Integrated Observatory Network (ION) interoperates with Integrated Ocean Observing System (IOOS), Neptune Canada and the World Meteorological Organization (WMO). It is responsible for exploiting the CI integration strategy for external interoperations with independent observatory systems.

The focus of EOI-R2 is to deliver the functionality to interoperate with a core set of applications and services used widely within the IOOS community. This effort is developed in close association with the NOAA IOOS office and its Data Integration Framework project. This effort is also the top level application concern for ION-R2 that provides the external application integration context for the design and testing of the four active ION subsystem development efforts in ION-R2; Sensing and Acquisition, Data Management, Common Operating Infrastructure, and Common Execution Infrastructure.

R2 SA Construction PlanSensing & Acquisition

The Sensing and Acquisition subsystem is a task and product account responsible for providing the life cycle and operational management of sensor network environments as well as observing activities (i.e., scheduling, collecting, processing) associated with sensor data acquisition.

The focus of S&A-R2 is to deliver the functionality to access, control, modify, monitor, and document the complete operational life cycle of all instruments and external data sources within the OOI domain of responsibility. This effort is developed in close association with the “Instrument and Platform Agent Architecture” Control Account. This effort is also the top level application concern for this release and provides the application context for the design and testing of the four active infrastructure subsystem development efforts in ION-R2; Data Management, Common Operating Infrastructure, and Common Execution Infrastructure.

R2 UX Construction PlanUser Experience

User Interfaces, designs, templates presenting the capabilities of the Integrated Observatory to its users. Every release has a different target user audience and adds incrementally to the capabilities of preceding releases.

The focus of UX-R2 is on the following areas:

  • Product Analysis, UX Design Goals & Constraints Specification – This involves the development of a detailed specification of the user-facing features that must be enabled to meet release objectives, along with specific goals for design outcomes and definition of the targeted design space (characteristics of targeted users, the tasks to be supported, where the users are assumed to work, what tools they use).
  • User Workflow, Interaction & Visual Design – This develops a map of the workflows, conceptual interactions and visual components required to deliver the user-facing features. It also includes the development of high level descriptions of all workflows, interaction architecture and visual flows.
  • Design & Specification Evaluation – Validates the detailed designs and documentation of all workflows, interactions and views with respect to usability and design goals.
  • UI Component Specification – Produces detailed specifications of non-development interface elements (e.g., graphical elements) and coding requirements.
  • UI Component Development - Builds and integrates prototypes as needed to illustrate and test proposed interface solutions to critical user-facing features.

4.4. Cross-Subsystem Integration and Dependencies

As part of the Elaboration phase, task deliverables from each subsystem will be continuously integrated and tested to maintain a full working system throughout. Each task deliverable will identify any cross-subsystem dependencies at the start of each iteration (or as soon as they are identified) to allow for prioritization of work across the entire development team. Cross-subsystem dependencies are maintained and tracked by the System Development Manager and are the responsibility of the appropriate subsystem leads.

4.5. Integration and Test

The CI software will be integrated in an iterative way, building from the unit level up to the subsystem level and then to the CI system level. Integration testing will be planned for, designed, and built along with the subsystem functionality being integrated and tested. This will allow for integration as early as possible during the elaboration phase, and will ensure working and integrated functionality by the end of each iteration.

The subsystem development teams are responsible for integration and testing of components or services within their subsystems. It is the responsibility of the ITV team (with the assistance of the subsystem teams) to test multiple subsystems together to ensure an integrated system.

5. Implementation Activities

In addition to subsystem development activities, a number of implementation activities will take place in parallel to the Elaboration phase for Marine Integration and CyberPoP Development and deployment. While these activities are phased in parallel to the system development phases, they are nonetheless connected to the system development activities, and so are reviewed here.

5.1 Marine Integration

The Marine integration team will design and build an instrument development kit (IDK), begin to develop drivers as part of the sensor set construction, provide for platform and instrument integration, and facilitate the integration of data related to marine IO activities.

5.1.1 Instrument Development Kit

The Instrument Development Kit is a software and hardware environment for developing instrument drivers. For developing drivers, the IDK provides access to the instrument driver development framework, a collection of modules containing samples, utilities, and existing patterns from which to base new drivers. For testing drivers, the IDK emulates a node on a stand-alone CI implementation. Since the IDK updates itself from the main CI code base, it remains up-to-date with recent CI changes and therefore provides a valid suite of qualification tests to verify instrument OOI system compatibility. The IDK should also be usable for developing instrument drivers that are run from deployed platforms (such as the TS-7370). This will involve a system for deploying software from the IDK to the platform where it can be tested.

5.1.2 Drivers for Sensor Set 1

With the availability of the Instrument Development Kit, the team will begin developing drivers for Sensor Set 1 (as part of the Sensor Set 1 Construction phase). As circumstances and resources warrant, the team may begin developing drivers for Sensor Set 2 (running the Sensor Set 2 Construction phase in parallel).

5.1.3 Platform and Instrument Integration

During the Elaboration phase, the team will conduct extended discussions with the marine Implementing Organizations to establish the use cases and requirements for platform and instrument integration. Draft procedures will be established to support all phases of the instrument and platform life cycles. An interim instrument information collection and management plan (see next subsection) will be developed during Elaboration phase.

5.1.4 Data Related to Marine IO Activities

Several data resources will be produced by the OOI before the completion of Release 2. For these resources, interim strategies must be developed to capture and manage the data in the short term, and transition it to the working system upon completion of Release 2. While ION is not scheduled to be formally commissioned until the end of Release 3, the team expects to make a good faith effort to manage OOI data arriving before that milestone.

The data types known at this time to be arriving before completion of Release 2 include:

  • data from test mooring deployments by the marine implementing organizations
  • cruise data from cruises conducted by the marine implementing organizations
  • science and engineering data from deployed gliders
  • metadata associated with procured or developed sensors and platforms
  • images associated with operations and development of OOI systems

In each case, interim measures may already be in place to at least capture the data being produced — for example, the CGSN IO is already capturing and publishing data from a test mooring deployment, and the Sensor Database application written by PMO is being modified to capture additional metadata about sensors. In some cases (for example, the test mooring data) this data is being acquired by ION, though possibly not in the final desired form.

In Elaboration, the Marine Integration team will work with the External Observatory Integration, the Product Management team, and the marine IOs to propose data paths for managing each of these assets. Most of the data paths will involve interim collections of the data, which will be transitioned to permanent collections once Release 2 is operational.

5.2 CyberPoP Development and Deployment

5.2.1 Introduction

The primary deployment element of the OOI Integrated Observatory is the Cyberinfrastructure Point of Presence (CyberPoP). CyberPoPs provide hardware environments, deployed within a protected data center facility, that provide computation, storage and network resources.

A Terrestrial CyberPoP is the primary physical hardware and software deployment location of the OOI Integrated Observatory. Terrestrial CyberPoPs are OOI Configuration Items and are commissioned according to the Transition to Operations plan, including 2 Observatory Acquisition Points (OAP), 2 Observatory Distribution Points (ODP), and 1 Operations Management Point (OMP). The Observatory Execution Point (OEP) is a form of Terrestrial CyberPoP which is operated on the infrastructure of marine and cloud computation and cloud providers.

Marine CyberPoPs are OOI deployment sites in the Marine Networks, operated by the CGSN and RSN Marine Observatories (see External Interfaces), hosting CI developed Integrated Observatory Network software deployments, such as Instrument and Platform agents.

CyberPoPs provide the central connection points to the OOI National Internet Infrastructure (NII), as specified in the network architecture.

5.2.1.1 OOI-Hosted Terrestrial CyberPoPs

There are three types of OOI-hosted Terrestrial CyberPoPs:

  • Observatory Acquisition Point (OAP): provides the primary point of access for Marine observatories to the CI, data acquisition, initial data processing such as Quality Assurance and Quality Control, and data preservation
  • Observatory Distribution Point (ODP): provides data distribution across the ION distribution network and for peering with external network providers, cloud execution and storage environments such as the Amazon Elastic Cloud and the Teragrid
  • Operations Management Point (OMP): provides observatory network and resource operations and state of health monitoring capabilities, and is deployed close to marine observatory and CI control centers
5.2.1.2 Non OOI-Hosted Terrestrial CyberPoPs

In addition, there is a Terrestrial CyberPoP hosted on the infrastructure of computation and cloud service providers:

  • Observatory Execution Point (OEP): provides computational capabilities that can be provisioned on demand, to support the elastic provisioning in cloud environments (such as the Amazon EC2 and Scientific Clouds based on the TeraGrid) of Common Execution Infrastructure and other OOI services needed for execution of user processes such as numerical models and data visualizations.

5.2.2 Deployment Strategies During Elaboration

Key infrastructure components need to be in place before the ION application can be used. The OOI National Internet Wide Area Network must be deployed to connect each of the CyberPoP locations by a high speed 10 Gbps network managed by third party provider. The selection of the provider will be done through an RFP process starting in Elaboration Iteration 1 with an award planned for Elaboration Iteration 2.

Another key component is the deployment of a high speed messaging system using the AMQP protocol and running on the national network. This provides direct application-level connectivity between capability containers in ION at users' sites. The selection of the vendor to provide this service will be done by a RFP process starting in Elaboration Iteration 1 with an award planned for Elaboration Iteration 2.

There will be five terrestrial CyberPoPs with the functions, locations, and deployment schedule as shown in Table 5.3-1. In Elaboration phase, the initial hardware configurations of the CyberPoPs will be built at UCSD and the ION software configurations will be loaded on the equipment. Upon verification that all components are operational, we will ship the rack to the CyberPoP location and connect it to the high speed network.

CyberPoP Function Location R2 Deployment Phase
Acquisition Point Pittock Building, Portland, OR Elaboration Iteration 3
Acquisition Point Woods Hole Oceanographic Institution Construction
Distribution Point RSN facility at Univ. of Washington, Seattle, WA Elaboration Iteration 3
Distribution Point Starlight Facility, Northwestern University, Chicago, IL Elaboration Iteration 3
Management Point University of California San Diego, San Diego, CA Elaboration Iteration 1

5.2.3 Operational Considerations During Elaboration

This section describes the ION operational and integration activities taking place during the Elaboration phase of Release 2. This is the first phase in which the Release 1 software will be operating in a production environment. Although not available for general public use, the Release 1 software will be tested by early adopters and members of the OOI team, and used by members of the CI team to evaluate and demonstrate operational features.

5.2.3.1 Operational Activities

During Release 2 Elaboration phase, the Release 1 software will be deployed in a production configuration on one CyberPoP of the Integrated Observatory Network. This will provide the opportunity for users and operational managers to become experienced with the nature of the core Release 1 Integrated Observatory Network, and to develop and refine operational practices for this system. Changes to the Release 1 software will be minimized, to favor Release 2 development achievements.

In addition, Release 2 software will be deployed in a development configuration on multiple CyberPoPs simultaneously. This presents the opportunity for early construction, integration, and testing of a distributed ION system, and gives the operations team the chance to verify the operational configurations of the newly deployed CyberPoPs.

The schedule for the deployment of the Release 2 system to multiple distributed CyberPoPs will depend on availability of the appropriately configured hardware and software, and may be delayed into the beginning of Construction phase for maximum deployment efficiencies.

5.2.3.2 Operational Overview

The following bullets describe the support attributes planned for Release 1 during Elaboration phase and beyond. The focus is on acquiring necessary expertise and maintaining a viable and compelling test system, while devoting the maximum possible resources to Release 2 feature development.

  • Once launched, Release 1 will be operated as a 24x7 system, targeting the availability requirements of the formally released ION system in Release 3.
  • Backup processes and equipment will be designed, deployed, and tested as needed during the Elaboration phase to achieve the targeted operational uptime.
  • The CI Operations team will be the initial interface with the user community for any questions or problems encountered. They will dispatch and provide initial responses for all user inquiries, and will address most problems within the Operations team.
  • JIRA will be the primary tool for documenting all problems and user communications, and tracking any follow-on work and disposition.
  • An R1 Feedback committee made up of the Operations Manager, System Development Manager, Product Manager, Architecture Manager and User Experience Manager will meet regularly to review tickets that represent possible Release 1 scope increase, and identify appropriate resolution strategies. Any significant scope impacts will be identified and discussed with Ocean Leadership as appropriate. Tickets to be reviewed will include
    • requests for new features (primary assessor: Product Manager);
    • bug fixes that do not imminently impact the usability or acceptance of the Release 1 system (primary assessor: System Development Manager); and
    • requests for operational scope beyond that budgeted for Release 1 (primary assessor: Operations Manager).
  • The Release 1 system will be operated within a single CyberPoP, which will be deployed to Portland as soon as that site is fully configured.

5.2.3.3 Operations Analytics

During Elaboration Iteration 1, the CI team will devise and deploy usage measurement software to enable the OOI to monitor key metrics of system usage. Since the Release 1 system is not a commissioned system, it is not targeted as a high-usage system with a wide range of capabilities and mature user interfaces. Therefore, metrics will be targeted to obtain simple overall metrics of system use, and to give the operations, product management, and user experience teams experience with these metrics.

The Operations will monitor and report on collected Release 1 metrics during R1 Feedback committee meetings.

6. Highlighted Activities

6.1. Prototypes

Several prototypes will receive attention during the Elaboration phase, to identify and/or confirm optimum strategies for the release architecture. These will be front-loaded, with most completed by the end of Elaboration Iteration 1.

The specific prototypes to be performed will be called out in the tasks listed in the appendix.

6.2 Workshops

In the Elaboration phase, workshops will focus on specific technical designs for the release.

The specific workshops to be performed will be called out in the tasks listed in the appendix.

6.3 Conferences, Meetings, and Presentations

As the OOI and CI development gains community visibility and becomes more concrete, the interest in these systems from both technical and science communities increases. This interest represents both opportunity and risk — opportunity to influence other communities to compatible or even interoperable solutions, and the risk that development attention will be diverted to support external activities.

The technical accomplishments and directions of the OOI Cyberinfrastructure are of particular interest to the broad marine science data systems community, which in many cases is starting similar, parallel, or dependent tracks of development. With properly tuned participation, the OOI CI team can obtain synergistic results from external communities that will accelerate our own progress, and enable better scientific results in the release.

The broader marine and earth science community is watching OOI progress ever more closely as the work progresses, which is likely to foster speculation about our progress if we are not specifically providing information. Toward this end, it will be important during Release 2 Elaboration phase to begin communicating actual progress and strategies to that community, through appropriate presentations and presence in community forums.

To explicitly respond to these opportunities and risks, an Engagement and Adoption Road Map will be documented and initiated during the Elaboration phase, in consultation and coordination with Ocean Leadership activities. The principals to be followed will be outlined at the Release 2 LCO review.

The specific conferences, meetings, and presentations to be attended and given will be identified by the Management Team as the Elaboration phase progresses, and reported (in advance) in the appropriate section of the Monthly Progress Report. Pre-eminent conferences during this period include the Oceans 2011 conference, and the Fall American Geophysical Union in San Francisco, CA.

7. Milestones

Key Milestone Elaboration
Iteration 1
Elaboration
Iteration 2
Elaboration
Iteration 3
Development      
Direct access and control of an instrument      
Control instrument via on-board CI components      
Configure and execute a data process      
Browse and query for system resources      
Register, activate and commission an instrument      
Caching and archiving of science data      
Define and enforce marine observatory facility policies      
Deliver gevent based Python Capability Container with new Object Model      
Deliver Governance Prototype with Conversation Monitoring and Commitment Tracking      
Develop a proof of concept: an Execution Engine agent shell that takes an operation to launch an ION process       
Prototype of a non-ION process (process adapter, IO mgmt etc)      
Show an example of elastic scaling in action      
Show an example of multi-site deployment (two CyberPOPs as well as one CyberPOP and EC2)      
Marine/CyberPoP      
Marine IO/CI Use Case meeting      
Instrument Development Kit built      
Interim Data Management paths proposed      
San Diego Management Point deployed      
Portland Acquisition Point deployed      
Seattle Distribution Point deployed      
Chicago Distribution Point deployed      
Operations      
R1 ION deployed (San Diego)      
R1 system operations      
R1 Metric collection initiated      
Product Management      
Product Specification      
Product Description      
Engagement and Adoption strategy document      

8. Appendices

8.1 Subsystem Elaboration Task Lists

These are PDF exports of the draft subsystem task lists for Elaboration:

The following table contains the list of subsystems with a link to the latest subsystem development task list (a Google Document spreadsheet).

Subsystem NameSubsystem Description Subsystem Tasks GD
Marine Integration

This Marine Integration subsystem is responsible for the design and implementation of the Instrument Platform Agent Architecture (IPAA). The IPAA is part of the CI Marine Network Integration which will implement, integrate and activate each of the Marine Nodes into the Integrated Observatory Network. The IPAA is responsible for the specification, development and prototyping of the OOI standard instrument agent and instrument/device driver strategy.

R2 MI Tasks
Analysis & Synthesis

The Analysis & Synthesis subsystem supports a wide variety of data and data product analysis, manipulation, generation and presentation, especially through visualization. It also provides the virtual collaboration platform that will be applied to realize virtual observatories, classrooms and laboratories.

R2 AS Tasks
Common Execution Infrastructure

The Common Execution Infrastructure subsystem is responsible for the services to manage the distributed, immediate mode execution of processes.

R2 CEI Tasks
Common Operating Infrastructure

The Common Operating Infrastructure subsystem is a task and product account responsible for providing the services and distributed infrastructure to build a secure, scalable, fault-tolerant federated system of independently operated observatory components.

R2 COI Tasks
Data Management

The Data Management Subsystem is responsible for providing life cycle management, federation, preservation and presentation of OOI data holdings and associated metadata via data streams, repositories and catalogs.

R2 DM Tasks
External Observatories Integration

This subsystem ensures the Integrated Observatory Network (ION) interoperates with Integrated Ocean Observing System (IOOS), Neptune Canada and the World Meteorological Organization (WMO). It is responsible for exploiting the CI integration strategy for external interoperations with independent observatory systems.

R2 EOI Tasks
Sensing & Acquisition

The Sensing and Acquisition subsystem is a task and product account responsible for providing the life cycle and operational management of sensor network environments as well as observing activities (i.e., scheduling, collecting, processing) associated with sensor data acquisition.

R2 SA Tasks
User Experience

User Interfaces, designs, templates presenting the capabilities of the Integrated Observatory to its users. Every release has a different target user audience and adds incrementally to the capabilities of preceding releases.

R2 UX Tasks

Labels

elaboration-plan elaboration-plan Delete
r2-elaboration-plan r2-elaboration-plan Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.