|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.
The current status of the scenarios at any given time is summarized in the table below.
Within each scenario, the following applies.
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.
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.
|AS.R2.01 A Day in the Life-OOI Observatories||Perform routine activities to operate and maintain OOI's marine and integrated observatories||Observatory Manager|
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:
|AS.R2.02 Perform OOI Maintenance Cruise||Enable cruise operations to maintain and support OOI marine assets||RSN 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
System Process Programmer
Instrument Provider (Marine Asset Operator
Support major operations areas related to marine assets:
|AS.R2.03 Integrate OOI with External Model||Request data set acquisition, obtain data set notification, implement data receiver, subscribe to updates, process asynchronously, share model output||Registered 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:
|AS.R2.04 Create Core Data Product||Configure system to generate core data product from source data sets||Marine Asset Expert|
Marine Asset Operator
Integrated Observatory Operator
System Process Developer
CI Point of Contact
Data Product Lead
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.
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:
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.
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.
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.