Skip to end of metadata
Go to start of metadata

1. Introduction

This document outlines the plan for Release 3 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 3 Elaboration activities.

1.1. References

1.2. Elaboration Schedule for Release 3

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

  • R3E1: January 11 2013 — March 7 2013
  • R3E2: March 8 2013 — May 2 2013

The Life Cycle Architecture Review period will occupy the two weeks following the second iteration of Elaboration, with the review itself tentatively planned for the week of May 13, 2013. (Although the Elaboration phase schedule nominally ends on a Thursday, the team will bring the bulk of its technical work to a close the Friday before, April 26.)

1.3. Themes and Features for Release 3

This section is drawn from the Release 3 Construction Plan.

Operate Observatory

  • Perform interactive quality assurance on instruments and interactive quality control on data products
  • Register user-contributed data calibration workflows
  • Track data calibration and validation processes applied to instrument data
  • Define new, user-created data acquisition processes
  • Define new, user-created algorithms and workflows to produce new data products
  • Define and validate interactive observatory mission workflows
  • Interactively plan, test, monitor, and manage observation missions
  • Allocate and schedule observatory resource usage
  • Register user-contributed instruments

Operate Virtual Labs and Classrooms

  • Define and create virtual workspaces and workspace policies
  • Set up and manage social networks for scientists and educators
  • Collaborate with other virtual classrooms and labs
  • Share resources

Acquire Data and Work With Data Products

  • Access, transform, and integrate data from multiple sources including external sources
  • Interactively apply analysis tools of the user’s choice
  • Create and register new resources by combining data from multiple resources.
  • Integrate and work with data from external sources
  • Annotate data with comments, tags, ratings, and other user-contributed information
  • Uniquely identify a data subset and create annotations for any data subset
  • Describe physical samples and physical analytical results
  • Classify resources by type, (seismic, water column, etc.), using system and user-defined taxonomies
  • Cross-reference external data catalogs, maintain metadata, pointers and functions (such as check for updates)

Manage and Use Workflows and Models

  • Create and register new, user-created workflows as OOI resources
  • Create and register new, user-created models or analyses as OOI resources
  • Use event detection in workflows and models

Visualize Data

  • Use user and community-developed processes for transformation, analysis, and visualization
  • Use integrated third-party analysis and visualization capabilities
  • Search for and use existing scientific workflows

Manage OOI Network

  • Monitor and control data processes anywhere in OOI network
  • Test power, communications, and time interfaces
  • Test environmental compliance
  • Track status of non-physical resources such as memory, executables, etc.
  • Track faults through a dedicated fault-monitoring interface

Use ION on Mobile Devices

  • Interact with all suitable ION services by way of mobile devices

2. Product Management Activities

2.1 Release 3 Product Specification Activities

The Product Specification will be produced in Elaboration to completely characterize activities that can be performed with all principal resources of the OOI system. This document will incorporate detailed architectural concepts from inception and inputs from OOI stakeholders.

During Elaboration Iteration 2, the Product Specification for Release 3 will be refined and finalized.

2.2 Release 3 Product Description Activities

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

An initial update of use cases from the Inception phase will be delivered in Elaboration Iteration 1. This will include any corrections required due to the development of detailed architectural concepts in the iteration, and reflect inputs received from OOI stakeholders immediately after the Inception delivery. User engagement activities held during Elaboration Iteration 1 will inform updates during the remainder of the Elaboration phase.

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

2.3 Release 3 Adoption and Engagement Activities

Interest in OOI is increasing in the scientific and technical community. Within the OOI team, implementing organizations are increasingly active 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 2, 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 enhance its Engagement and Adoption Road Map during the Elaboration phase, in consultation and coordination with Ocean Leadership and marine Implementing Organizations. The principals and existing content for this Road Map will be outlined at the Release 3 LCO review, and discussed and refined during the development of the document in the Elaboration phase.

The enhanced 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 3 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

Table 4.1-1: LCA Deliverables for Components

4.2. Architecture Activities

In Elaboration, the Architecture team will build an executable architecture demonstration 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 some prototyping activities are necessary to mitigate risk; to demonstrate that the baseline architecture will support the use cases and implement the baseline requirements; and to demonstrate significant new capabilities in an operable system.

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 3: 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 3 Focus
R3 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-R3 is delivery of the following services:

  • Data Analysis & Visualization (Part 2) — Provides a generalized analysis and synthesis framework for transforming, analyzing, and visualizing data through the application of user and community developed processes.
  • Laboratory & Classroom Facility (Part 1) — Building on the capabilities of the Observatory Facility, provides services to organize, manage, and control research and educational activities, the resources they use, and the participants involved. It is the virtual home where research teams gather their resources, carry out their objectives, and collect their results.
  • Event Detection — Provides services to register processes to detect and publish events from data streams. Events are automatically persisted and distributed based on the configuration set for the detector.
  • Model Registration — Maintains a hierarchy of evolving interdisciplinary models (e.g. from ‘reduced’ process-oriented models to operational forecast systems). Supports the registration and dissemination of model data sets.
  • Model Integration (Part 1) — Provides integration services for ocean models to access multiple community-based numerical ocean models for parameter estimation/optimization and data assimilation. Provides the services to integrate, parametrize, and execute numerical ocean models with command and control services for their operation and management. |
R3 CEI Construction PlanCommon Execution Environment

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

The focus of CEI-R3 is delivery of the following services:

  • Process Management (Part 2) — Provides advanced management and scheduling services for processes executing within execution engines at specified execution sites. In this release, includes managing processes registered by end users of the system. Provides validation, scheduling, and policy-based process execution capabilities.
  • Integration with the National Computing Infrastructure (Part 2) — Extends the capability to deploy OOI processing, both data stream and ocean models on to the national computing infrastructure. Provide capabilities to integrate both commercial and academic compute infrastructure providers.
R3 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-R3 is delivery of the following services:

  • Federated Facility and Governance (Part 2) — Extends the Federated Facility Services with notions of facility 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 (Part 3) — Extends the capability container and distributed service infrastructure with advanced concepts in the context of multiple federated facilities and domains of authority, federation of the Exchange infrastructure, sophisticated hardware-supported Exchange messaging, and different modalities of presentation.
  • Resource Activation — Services to support the registration, test and validation of resources added to the system by users to ensure conformity with the different operational requirements in the network.
  • Resource Collaboration Services — Services that facilitate the negotiations between participants and facilities for sharing resources (e.g., instruments, processes, and models). Agreements are captured and associated with all parties materially involved.
R3 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-R3 is delivery of the following services:

  • External Data Access Services (Part 2) — Advance the extensible suite of access interfaces and data formats for interoperability with external communities and applications.
  • Aggregation Service — Provides for the classification, categorization, and general grouping of data into collections.
  • Annotation & Association — Associates attributes to and retrieves attributes from resources. Attribution includes annotations, tags, semantic context, comments, ratings. The attributes can be associated within a semantic context (ontology). The service facilitates the characterization, qualification, and general commentary about the elements with which the participants interact.
R3 EOI Construction PlanExternal Observatory 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-R3 is delivery of the following services:

  • IOOS Integration Package 3 — Advance the mapping between IOOS's and OOI's respective observatory data & metadata models. Integrate more IOOS data providers as needed as data products.
  • WMO Integration Package 1 – Develop the mapping between WMO's and OOI's respective observatory data & metadata models. Develop data agents performing the mapping and the federation of catalogs.
  • Neptune Canada Integration Package 2 – Advance the mapping between Neptune CA's and OOI's respective observatory data & metadata models. Develop data agents performing the mapping and the federation of catalogs.
R3 PP Construction PlanPlanning & Prosecution

The Planning & Prosecution services leverages the capabilities of the consistent integrated network of sensing, modeling and control resources and services supporting resource nesting and resource autonomy. This subsystem provides generalized resource planning and control activities that will be applied to plan, schedule, and prosecute multi-objective observational programs. It also provides support to control autonomous parts of the system, such as AUVS and disconnected moorings.

The focus of P&P-R3 is delivery of the following services:

  • Interactive Observatory Facility — Building on the capabilities of the Marine Observatory Facility, provides the services to design, assemble, and operate configurations of resources from across the OOI into unique systems for planning, testing and prosecuting observation requests, leveraging the nested and autonomous capabilities of the fully integrated network of sensing, modeling, and control resources.
  • Event Response — Provides services for policy and behavior based reconfiguration of tasks and observational programs. Provides a nested communication, command, and control architecture that enables and supports the deployment and prosecution, fully autonomously or under operator control, of new missions, processes and behaviors, in parallel to and without interruption of prior platform objectives.
  • Portable Control Software (Part 1) — Provides a portable, platform-generic higher-level control software package that can run on fixed observatory assets, gliders, and AUVs operated in the observatory. The software provides a standard communication, command, and control connectivity with the overall OOI CI, and a standard NMEA interface to natively control software on the platforms.
  • Observation Plan Management — Provides and maintains platform specifications, planning elements, and plan and behavior modules for a variety of multi-objective ocean observation missions, such as the capture of a coastal upwelling event. A representative set of plan and behavior modules that adhere to a flexible precondition language for generically-conditioned autonomy actions will be introduced.
  • Resource Planning (Part 1) — Provides software tools and user interfaces for the scientist defining a set of states for each fixed or mobile node involved in a planned experiment or observation campaign, and to design the associated, conditional state transitions, forming the basis for defining the behavior algebra (language) necessary to complete a predetermined, as well as autonomously adaptive sensing task.
R3 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-R3 is delivery of the following services:

  • Data Calibration & Validation — Enables configuration of the data calibration and validation processes and the application of custom automated data processing steps. The service supports the flagging and sequestering of derived data until reviewed by responsible participants. Derived data are automatically associated with their data source. The service supports automated revisions of the derived data on a partial or complete basis.
  • Marine Resource Coordination and Scheduling — The coordination services are the primary means for allocating and scheduling instrument use of communications and power, but will extend to the coordination of environmental interactions (i.e. sound, chemical, light).
  • Data Product Activation Services — Provides services to produce and publish data products and apply processes for generating products from data and/or derived data. Data products are automatically persisted and published based on the configuration set for individual product development.
R3 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-R3 is delivery of the following services:

  • Product Analysis, UX Design Goals & Constraints Specification — Develop 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 asssumd to work, what tools they use).
  • User Workflow, Interaction & Visual Design — The workflows, conceptual interactions and visual components required to deliver the user-facing features.
  • Design & Specification Evaluation — Validate user-facing feature specification, with descriptions of all workflows, interaction architecture and visual flows with respect to design goals.
  • UI Component Specification — Specification of non-development interface elements (e.g., graphical elements) and coding requirements.
  • UI Component Development — Development of non-development interface elements (e.g., graphical elements) and coding requirements.

Table 4.3-1: Subsystem Work Areas

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 continue to develop drivers as part of the sensor set construction, provide for further platform and instrument integration, begin to develop data processes for built drivers, and facilitate the integration of data related to marine IO activities.

5.1.1 Driver Development

By using the Instrument Development Kit (IDK), the team will continue developing instrument drivers for 2013 summer and fall deployments. Additionally, the team will develop platform drivers to enable integration of CG, EA, and RSN platforms. Finally, for platforms that have no CI presence, data handlers will be developed to enable ingestion of data files acquired via real-time methods or during device retrieval.

5.1.2 Data Process Development

During the Elaboration phase, the Marine Integration team will begin developing the data processes for drivers to be completed for 2013 summer and fall deployments. Additionally, the team will develop a testing infrastructure that can be used to test the data processes per their Data Process Specifications (DPS).

5.1.3 Platform and Instrument Integration

During the Elaboration phase, the team will enhance the IDK to facilitate instrument integration with the Marine Implementing Organizations. The enhanced IDK will enable Marine IO users to connect to local instruments using the embedded Release 2 ION software, and interact with or test the instruments via the ION Graphical User Interface. Following additional discussions with the Marine IOs, draft procedures will be established to support all phases of instrument and platform integration.

5.1.4 Data Related to Marine IO Activities

Several data resources will be produced by the OOI before the completion of Release 3. 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 3. 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 3 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
  • science data received from 2013 deployed instruments

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 (R1), 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 finalize 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 3 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

Table 5.3-1 — Terrestrial CyberPoP Deployments

5.2.3 Operational Considerations During Elaboration

This section describes the ION operational and integration activities taking place during the Elaboration phase of Release 3. This is the first phase in which the Release 2 software will be operating in a production environment. Although not available for public (OOI-external) use, the Release 2 software will be tested by early adopters and members of the OOI team, used by members of the CI team to evaluate and demonstrate operational features, and deployed for operational use as part of marine deployment activities in 2013.

5.2.3.1 Operational Activities

During Release 3 Elaboration phase, the Release 2 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 2 Integrated Observatory Network, and to develop and refine operational practices for this system. Changes to the Release 2 software will be minimized, to favor Release 3 development progress.

In addition, Release 3 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 3 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 the Release 2 system during Release 3's 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 3 feature development.

  • Once launched, Release 2 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 and Construction phases to achieve the targeted operational uptime.
  • Multiple paths will be provided to submit system issues, including email, phone, and via the system's web interface.
  • The CI Operations team will be the initial interface for any questions or problems encountered. They will dispatch and provide initial responses for all user inquiries, and will address most non-marine system 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.
  • The CI Operations team will develop an Operations Plan to define resolution strategies for issues with the production system. Any significant scope impacts will be identified and discussed with Ocean Leadership as appropriate. Topics to be addressed in the plan will include
    • requests for new features;
    • bug fixes that do not imminently impact the usability or acceptance of the Release 2 system; and
    • requests for operational scope beyond that budgeted for Release 2.
  • The Release 2 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 2 system is not a commissioned system, it is not targeted as a high-usage system with a wide range of capabilities and 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 2 metrics during according to the Operations Plan.

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. These will be limited to internal team members with ongoing development roles, and so are not expected to rise to the level of formally hosted meetings.

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, the team has begun communicating actual progress and strategies to that community, through appropriate presentations and presence in community forums.

To explicitly respond to these opportunities and risks, our existing Engagement and Adoption Road Map will be refined during the Elaboration phase, in consultation with Ocean Leadership. The principals to be followed will be outlined at the Release 3 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.

7. Appendices

7.1 Subsystem Elaboration Task Lists

The release 3 tasks have been consolidated into a single MS project file that provides a capability to see all subsystem tasks in a single location and allows for definition of dependencies and resource loading. The subsystem tasks are attached in both MS Project and PDF format:

The following table contains the list of subsystems with a link to the latest subsystem development task list (a Google Document spreadsheet). Although the Elaboration tasks have not yet been propagated to the associated task lists, they will be as part of the Elaboration 1 design period.

Subsystem NameSubsystem Description Subsystem Tasks GD
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.

R3 AS Tasks
Common Execution Environment

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

R3 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.

R3 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.

R3 DM Tasks
External Observatory 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.

R3 EOI Tasks
Planning & Prosecution

The Planning & Prosecution services leverages the capabilities of the consistent integrated network of sensing, modeling and control resources and services supporting resource nesting and resource autonomy. This subsystem provides generalized resource planning and control activities that will be applied to plan, schedule, and prosecute multi-objective observational programs. It also provides support to control autonomous parts of the system, such as AUVS and disconnected moorings.

R3 PP 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.

R3 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.

R3 UX Tasks
Table 7-1: Subsystem Development 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.