Skip to end of metadata
Go to start of metadata
Release 2 Acceptance Scenarios are end-to-end operational scenarios that relate to the Integrated Observatory Network. They are being developed in collaboration with the marine Implementing Organizations.


The Acceptance Scenarios are end-to-end operational scenarios that describe activities of Integrated Observatory Network users. The descriptions in the main body text address functionality that has to be provided by the Integrated Observatory Network in Release 2 and beyond; the capabilities that are not in Release 2 are footnoted according to expected Release.

The Acceptance Scenarios will be used as the basis of validation tests performed at the end of the Release. Achieving the capabilities in the scenarios will be seen as a principal indication of readiness of the Release 2 system.

In many cases the scenarios describe capabilities unrelated to the Integrated Observatory Network. This material, in gray text, is included for context, and to add value for the participating organizations.

The material in blue background is for reference only; it is not normative. The referenced use case scenarios are updated live by Confluence; other reference material may be dated, and was principally used to make sure initial scenarios covered the appropriate range of activities.

Diagrams of each scenario are indicative but not normative. They are intended to provide an overview for understanding what is in the scenario and how it can be navigated.


The scenarios are organized into 4 major themes, and each theme includes one to several detailed scenarios. Key information about each them and the scenarios in it are summarized later on this page. The normative material is in the detailed scenarios.

Development Status

The current status of the scenarios at any given time is summarized in the table below.

PageReview StatusAS Priority
AS.R2.01A Operate Marine ObservatoryReady for OOI Review5
AS.R2.01B Define Marine Observatory PoliciesReady for OOI Review4
AS.R2.01C Operate Integrated Observatory NetworkReady for OOI Review5
AS.R2.02A Cruise SupportReady for OOI Review4
AS.R2.02B Data Support via CruiseReady for OOI Review4
AS.R2.02C Instrument Life Cycle SupportFinal5
AS.R2.03A Modelers Integrate External Model with OOIReady for OOI Review4
AS.R2.04A Data Product Leads Drive Core Data Product CreationReady for OOI Review5
AS.R2.04B Curate Data ProductsReady for OOI Review4
AS.R2.04C Instrument Experts Drive Core Instrument OperationsReady for OOI Review5


  • Ready for CI Review: The scenario is considered complete, with all issues and mappings to use cases addressed. Review by the CI team will confirm the viability of the scenario contents. All OOI participants are welcome to review these scenarios.
  • Ready for OOI Review: The scenarios have been reviewed by the CI team and await final review and acceptance by the marine and EPE IOs and Ocean Leadership.

Within each scenario, the following applies.

This text style = background material
This text style = priority <3> (not required).

( ) Indicates footnoted material targeted for Release 3.
( ) Indicates footnoted material targeted for Release 4.
[MI] , [Ops] Provided by MI or Ops team (has no use case).
[NoUC] indicates material for which no Use Case exists.

Future Development

These scenarios are as advanced as possible given stakeholder participation to date. After their acceptance by the OOI stakeholders, they will not undergo major modifications.

Some notations will be made to these scenarios as needed to reflect ongoing adjustments in the anticipated Release 2 capabilities, as discussed with the OOI stakeholders.

A condensed set of "action statements", or capabilities, have been identified in the Release 2 scenarios. (See the details of how they are marked here.) The identified statements have been culled into a single document, which can be viewed or downloaded from the Release 2 Acceptance Scenario Capabilities page.

Release 2 Acceptance Scenario Table

These two tables summarize the Release 2 Acceptance Scenarios. (They are built by inserting information from the four scenarios themselves.) Links to scenarios are embedded within the table.

Within some of the high-level scenarios there is a further division into themes, each of which is maintained in a separate document. These themes allow items of similar content (e.g., data management, or observatory operations) to be treated in a standalone document, without making a single sequence of operations cover all facets of the OOI capabilities for that scenario. The scenario themes are linked to from the scenarios, and can be read as a stand-alone document if desired.

Summary of Release 2 Acceptance Scenarios

PageDescriptionActorsDetailed Summary
AS.R2.01 A Day in the Life-OOI ObservatoriesPerform routine activities to operate and maintain OOI's marine and integrated observatoriesObservatory Manager
Observatory Operator
Platform operator (Marine Asset Operator)
Integrated Observatory Manager
Integrated Observatory Operator
Observatory Representative Owner (Default Observatory Manager)
Observatory Manager (Observatory Manager)
Observatory Operator (Observatory Operator)
RSN Operations Center Technician (Observatory Operator)
OSU Operations Center Technician (Marine Asset Operator
CGSN Marine Operator (Observatory Operator)
CI Operations Center Technician (Integrated Observatory Operator)
Site Coordinator (Observatory Manager, or Site Manager could be a customized variant)
RSN Core Instrument Manager (Marine Asset Operator)
CSPP Operator (Marine Asset Operator)

Support major areas of operations for OOI observatories:

  • Marine Observatory operations — Monitor the operations of a marine observatory and its assets. Command observatory assets.
  • Observatory life cycle and policy — Define an observatory, define roles and policies, assign assets and their policies, begin operations. Addresses the application of observatory policy to constrain operations of marine assets.
  • Integrated Observatory Network — Monitor the operations of a cyber observatory (the Integrated Observatory Network) and its assets. Manage resources, including users, organizations, processes, data, and policies.
AS.R2.02 Perform OOI Maintenance CruiseEnable cruise operations to maintain and support OOI marine assetsRSN Chief Scientist (CS) (narrowed form of Observatory Manager
Captain (no Integrated Observatory system role in R2; may be Registered User)
RSN Operations Manager (OM) (Registered User; no direct system role)
RSN Staff Scientist (Registered User
RSN Field Technician (FT) (Observatory Operator
RSN Logistics Manager (Registered User; no direct system role)
RSN Lead Field Operations Engineer (LE) (Observatory Manager)
RSN Field Engineer (FE) (Marine Asset Operator
RSN Data Manager (Resource Manager
RSN Operations Center Technician (Observatory Operator
RSN Power Safety Officer (may be Registered User; no direct system role)
ROV Expedition Leader (may be Registered User; no direct system role)
ROV Operations Director (may be Marine Asset Operator; no direct system role)
Shipboard Science Support Group (SSSG) (Marine Asset Operator)
Integrated Observatory Operator
Marine Technician (Resource Manager
Marine Asset Operator
Observatory Manager
System Process Programmer
Instrument Provider (Marine Asset Operator

Support major operations areas related to marine assets:

  • Cruise support — Provide basic services to record information about cruise planning and execution, and record associated data collected as part of the cruise (using an approach integrated with R2R data collection and information models, and taking into account support for auxiliary data related to samples).
  • Data support via cruise — Provide services for offloading and ingesting data from marine platforms as encountered during the cruise. Particular scenarios to be supported:
    • In-situ assets (transferring their on-board storage remotely or physically)
    • Recovered assets (data is physically recovered with the asset, then transferred while at sea or upon return to shore)
    • Ship-deployed assets (data is being returned to on-board systems while platform and instruments are deployed from or on the ship)
  • Instrument life cycle support — Bring an instrument from conception through operation and to decommissioning, with full control of full life cycle state, via UIs and associated activities. Includes qualification test, verification, ION registration, instrument deployment on the platform and activation on the marine network, modification of instrument configuration (e.g., adding a sensor), deactivation, and decommissioning.
AS.R2.03 Integrate OOI with External ModelRequest data set acquisition, obtain data set notification, implement data receiver, subscribe to updates, process asynchronously, share model outputRegistered User (Early adopter, System integrator, Science integrator, OOI science user, Data provider, Scientific programmer)

Addresses the OOI elements that come into play when a model developer decides to integrate OOI capabilities with the model he or she has developed. Includes the following modeler activities:

  • Data identification — An end user wanting to find data of interest for a model: data (and metadata) browse, search, and navigation, visualization of data products, and data specification.
  • Model integration — Data subscription, modification of the model and associated software to accept and process data updates, data presentation (for compatibility with OOI)
  • Data publication — The submission of model products as data sets to OOI, including data publication registration, management of existing publication registrations, providing provenance and other metadata, versioning data, and submission of data supplements.
AS.R2.04 Create Core Data ProductConfigure system to generate core data product from source data setsMarine Asset Expert
Marine Asset Operator
Integrated Observatory Operator
System Process Developer
Registered User
CI Point of Contact
Data Product Lead
Resource Operator

All of the steps to specify and transform raw data from instruments into Level 1 and Level 2 OOI core data products are set up and executed. Beyond the initial specification of the algorithms, these include the implementation of algorithms to perform conversion to science units, application of quality control, creation of new data from multiple raw data sources, and transformation of the feature type of the data set.

  • Data product leads drive core data product creation — All of the steps to specify and transform raw data from instruments into Level 1 and Level 2 OOI core data products are set up and executed. Beyond the initial specification of the algorithms, these include the implementation of algorithms to perform conversion to scientific units, application of quality control, creation of new data from multiple raw data sources, and transformation of the feature type of the data set.

It also includes the necessary contextual processes to ensure the Core Data Product is fully documented, traceable, curated, and credible. This demands data curation and instrument configuration activities that enable the production of the end products:

  • Data curation processes — All of the steps to curate OOI core data products, data products from external providers, and additional science data products (e.g. from PI-owned instruments) are detailed.
  • Instrument operational configuration — Instrument experts in OOI provide the necessary information to implement instrument operations in the observatory. Information addresses the sampling strategies, sampling procedures, and operational configuration of the instruments necessary for satisfactory data acquisition.

Scenario Development Process

LCO Process

After the Cyberinfrastructure Release 2 Life Cycle Objectives review, the CI team agreed to pursue stakeholder agreement on a set of end-to-end scenarios that would describe the CI deliverable as it would be used by the marine Implementing Organizations. The goal was to achieve buy-in across the organization for the capabilities that would be delivered by the Release 2 system, and to provide more specific and accountable descriptions of the end-user services that would be available. The targeted scenario content was described as end-to-end, concrete, and domain-specific.

During the first 8-week iteration following the LCO, the CI team worked with Ocean Leadership (COL) and the Implementing Organizations to establish a working relationship for development of the scenarios. Principal members of both marine IOs agreed to participate, though somewhat constrained by their existing commitments. Participation took several forms:

  • contribution of existing scenarios, use cases, and background material, previously developed by the IOs;
  • contribution of text for use as part of the scenarios;
  • participation in the weekly status and planning meetings; and
  • review of the completed scenarios.
    was no chance for the IO teams to integrate or agree on their contributions. This was anticipated in developing the process, and the initial deliverable at Delta LCO was not expected to represent a firm agreement among the participants. Work continued in the remainder of CI's Elaboration phase (until the end of February, 2012) to finalize agreement on the scenarios, and obtain this agreement in the form of System Level CCB approval before the Release 2 Life Cycle Acceptance Review.

After the review by stakeholders, major issues were (to the extent feasible) by the Product Manager, and the results were presented as part of a Cyberinfrastructure "Delta LCO" mini-review on October 28. The state of the scenarios at that time was captured by archiving PDF versions as part of the Delta LCO review package, thereby establishing a baseline with which future versions can be compared.

LCA Process

All the scenarios were updated by early March to reflect all previously received comments, including comments from weekly CI Stakeholder Review meetings. The status of the scenarios was captured in a PDF document reviewed at a System Level CCB.

The System Level CCB in March reviewed the scenarios and produced 21 comments. 16 of those comments were accepted; one of them (mapping of use cases) was identified as a lien. Those comments have been addressed.

User Experience Support

Although not a direct part of the Release 2 Acceptance Scenarios development, the CI team worked to align its User Experience development process with the scenario development effort. This enabled a 'single ask' to be made to the Implementing Organizations, and maximized the consistency of the two products. Because the engagement required for the User Experience process was more limited than that for scenarios, and the IO team members with the greatest knowledge and stake were not the same as for scenario development, the User Experience development quickly proceeded with sufficient support. While continuing to be attentive to possible overlaps and synergies, the CI team will in future treat the UX engagement as a parallel activity, not requiring close coupling with scenario engagement efforts.

At the same time, the UX products will depend on the scenario products, and work on each will be managed to satisfy the dependency.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 10, 2011

    Michael Meisinger says:

    I think we should have one end-to-end scenario called: Deploy ION system. Core ...

    I think we should have one end-to-end scenario called: Deploy ION system.

    Core description:

    Deploy services and components for one instance of the ION system across:

    • Acquisition Point CyberPoPs: Portland, Woods Hole
    • Distribution Point CyberPoPs: Chicago, Seatle
    • Amazon EC2 Execution Point

    There should be 1 launch plan, global monitoring, once DNS name for Web Access, consistent security strategy.

    Core services start in the CyberPoPs as well as core infrastructure.

    Show data transform processes executing in Amazon EC2.

    Integrate with CyberPoP hardware (storage, compute, messaging)

  2. Oct 20, 2011

    John Graybeal says:

    The CI team expects to develop this scenario internally. Though critical, it wil...

    The CI team expects to develop this scenario internally. Though critical, it will not be used often, and is of little impact to the marine IOs.