Skip to end of metadata
Go to start of metadata

Instrument Experts Drive Core Instrument Operations

Instrument experts in OOI provide the necessary information to implement instrument operations in the observatory.


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.

Review Status Ready for OOI Review
AS Priority 5
AS Version 3.1

The scenario has no diagram, and may not get one.

Issues Status (Jira) OverviewAllUnresolved
Custom Issues Lists Marine IO ReviewMarine IO ProcessesCI IO Verify

The custom issue lists are as follows. They include both open tasks, and tasks marked as fixed.

  • Marine IO Review issues are called to the attention of the Marine IOs for their review.
  • Marine IO Processes issues are expected to require further consideration/understanding of the Marine IO processes.
  • CI IO Verify issues are generally resolved, but the resolution needs to be confirmed with appropriate CI experts.


Related Use Cases

Use Cases Mapped to This Scenario

The following Use Cases have been mapped to this Acceptance Test Scenario:

Use Cases Cited by This Scenario

This Acceptance Test Scenario cites the following Use Cases:


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.

Overview Diagram

Not available.


Marine Asset Expert — an OOI or marine Implementing Organization representative who knows a lot about a particular marine asset model, and can specify its use for the CI team
Marine Asset Operator — A Resource Operator who has been granted privileges to operate one or more marine assets in an observatory, and can command an instrument or platform
Integrated Observatory Operator — An Observatory Operator for the Integrated Observatory; can manage user accounts, and schedule and manage OOI computational processes and resource allocations.
Driver Developer (System Process Developer) — the person who develops the software to interface with the instrument


End-to-End Scenario

Sampling Strategies and Procedures

Relevant Use Cases
UC.R2.42 --- Define Resource Policy
This scenario describes how sampling strategies for instruments of the OOI move from scientific definition to software implementation. It is assumed that the OOI sampling strategies have been arrived at through consensus of the OOI Science and Engineering Teams taking into consideration the OOI Science Drivers and Requirements, Science Community Input, and the hardware and power limitations of the OOI infrastructure. These OOI sampling strategies are developed and documented in the OOI Observation and Sampling Approach document (DCN 1102-00200). As currently summarized in the document, three types of instrument and platform sampling are planned: pivotal (inviolate), default, and adaptive (triggered by either an event or a researcher). These three types, referred to as Sampling Schemes herein, will be defined for each instance of an instrument or platform, as the strategies may differ depending on location. Location geospatial differences in platform location, and range of locations covered for the mobile platforms (with their installed instruments) such as gliders, AUVs, and profilers. It is also possible that a subset of the schemes may differ temporally; for example, changing seasonally and/or after the OOI infrastructure has matured. Some instruments models or instances may not have one or more of the Sampling Schemes defined. Sampling Schemes address not just the frequency of instrument sampling, but the control of mobile assets to create the proper data-taking environment for the instruments. As noted in the Observation and Sampling Approach, "Whereas sampling rate determines temporal resolution for fixed instruments, sampling rate combined with platform speed for instruments located on mobile platforms determines the temporal and spatial resolution of observations." Accordingly, Sampling Schemes will include both instrument and platform specifications. For the purposes of this scenario, the Sampling Scheme identifies while an instrument configuration, as described elsewhere, determines how an instrument may operate. It is also possible that a configuration can include presets which might function to implement specific Sampling Schemes, ie. pivotal or default sampling.

The hierarchical relationship between the Sampling Schemes for specific instruments is derived (manually) from the tables in the OOI Observation and Sampling Approach. Where principals of operation can be defined across classes of marine assets, the Integrated Observatory will attempt to leverage those principals. This minimizes the amount of data entry and corresponding risk of error, and makes more clear the existence and relationship of the different principles. It is possible some of the sampling schemes will be described using policy, rather than simple data collection. (See UC.R2.42 Define Resource Policy.) ( 1 )

Policies affecting sampling may be set at the instrument, platform, or observatory level. For the purposes of this Acceptance Test Scenario, we will refer to them as Instrument Sampling policies, because in the end the instrument is always the device performing the sampling, even if it is sampling on behalf of the platform. (In the Integrated Observatory information model, even computer processor metrics are considered instrument data.)

Future Release Notes
Release 3

Sampling Schemes

Relevant Use Cases
UC.R2.40 --- Monitor ION Resources

Implementation of the full suite of Sampling Schemes for all instances of an instrument require both automated and manual control of sampling. The expected pivotal and default Sampling Scheme implementations require automation, because the frequency and complexity of sample-taking can not be manually controlled. The adaptive Sampling Schemes require both automated processes (for event-triggered sampling, not anticipated in this release) and manual processes (user/operator-triggered). In some cases, events can alert users/operators of specific conditions or process execution that call for sampling to be performed. (See UC.R2.40 Monitor ION Resources for example of alerts generated based on signals.)

( 1 )

A fourth type of instrument operation, not considered as part of these Sampling Schemes, is instrument diagnostics, troubleshooting, and testing. These activities may be performed under full manual control, but during instrument deployments might be limited by the existing instrument configuration or require a change in configuration. This capability is addressed in the AS.R2.02C Instrument Life Cycle Support Acceptance Test Scenario.

The Observation and Sampling Approach defines the pivotal and default frequencies (Sampling Scheme) to be supported by each instrument class in each location. The Integrated Observatory provides the ability to select, for any instrument, whether the pivotal or default frequencies should be followed. [MI] ( 2 )

Sampling Schemes are written in a format that can be easily read by and imported into software systems (format to be defined). In addition to the expected frequency of operation, they should specify as appropriate any coordination needed with other sampling activities; the range of permissible variance from the desired frequency; and a nominal time indication when samples are expected to be taken. Some time series require that samples be taken at nearly identical intervals over time, to facilitate the accuracy and simplicity of the analysis of the result; these constraints should be specified where known, and the Integrated Observatory system will attempt to honor any sample timing constraints that are described . [MI]

( 3 )

The Integrated Observatory sets up the execution of sampling by the instruments (those that are not set up by their platforms or management systems) according to the default Sampling Scheme when they are first deployed. [MI] After that, the Marine Asset Operator has the responsibility to select the appropriate Sampling Scheme, which is then effected by the Integrated Observatory.

Future Release Notes
Release 3

Sampling Procedures

Relevant Use Cases
MASSP Default Sampling Procedure
UC.R2.09 --- Activate Instrument Driver
UC.R2.15 --- Qualify Instrument Interface

The Sampling Scheme does not provide the specific instrument/platform configurations, nor the operational commands/controls, to implement specific Sampling Schemes. Implementation requires specific operational procedures to be detailed and well documented. These Sampling Procedures define the specific sequence of commands or operations that must occur for a specific Sampling Scheme to be implemented. The identification of Sampling Procedures is a prerequisite to automated implementation of Sampling Schemes. They can also be used to inform users/operators of the appropriate sequence of commands/operations that must be performed during manual control of sampling or asset operation.
The Marine Asset Expert (an OOI Project Scientist or Engineer) who is most familiar with the asset determines the required instrument configuration (see Configuration Scenario below) and the sequence of commands or actions that must be performed to enable a Sampling Scheme for a specific instance of an instrument/platform. These detailed Sampling Procedures are documented for each instrument model in a format that will allow their transfer to CI and efficient transformation into control software. The Sampling Procedures must be validated by both the CI driver developers and the Marine Asset Expert. In its simplest forms, a Sampling Procedure specifies three things, all of which may be optional for certain especially unintelligent (that is, uncontrollable) instruments:
  • the commands or configuration needed to prepare the instrument for sampling;
  • the commands needed to cause the taking of one sample or a set of samples; and
  • the commands needed to return the instrument to a quiescent state.
    How often to perform a Sampling Procedure is dictated by the Sampling Scheme that is in effect.
Additionally, sampling procedures should include any information the instrument driver needs to reflect to work with the instrument in the expected modes. For most instruments, they should list:
  • the data records (by specific format) that may be requested of the instrument;
  • for each data record listed, the desired level 0 data products and any special computation needed to create it;
  • the instrument commands (features) which are necessary to routinely access; and
  • any instrument messages which must be processed.
    If these are not specified, they are assumed to not be available or needed by OOI for the given instrument.

The instrument driver writer creates the instrument interface software. (See UC.R2.09 Activate Instrument Driver.) Once implemented, the Sampling Procedures are verified by running the actual driver software with a real instrument. (See UC.R2.15 Qualify Instrument Interface.)

Platform movements are commanded manually by Marine Asset Operators (using the Integrated Observatory is an option for some platforms [MI] ; others are commanded through other means), or automatically by platform control software (not operated by the Integrated Observatory).

( 1 )

Future Release Notes
Release 3

Marine Asset Operational Configuration

Relevant Use Cases
UC.R2.09 --- Activate Instrument Driver

After the needed operational characteristics of a platform or instrument (here, a 'marine asset') have been identified, the marine asset configuration(s) are developed as needed by the Marine Asset Expert, and implemented by the driver developer. (See UC.R2.09 Activate Instrument Driver.) This specification should not duplicate existing documentation, but should point to or improve the organization of any corresponding information in the instrument documents.

A marine asset configuration specification, as defined here, controls how a specific instance of an asset may operate. They are typically defined for each instrument model, and apply to any instrument of that model. The development of the configuration includes the identification of the mode(s) of operation and the command(s) and associated parameter set(s) that need to be accessible to the user/operator at deployment, during the deployment period, and at recovery. (Similar operations are also required pre-deployment or post-recovery, e.g. for pre-deployment testing and refurbishment, respectively. These are not detailed here, but are analogous.) The configuration specification also effectively identifies and enables the initial “feature set” for an instrument, that is, the minimal subset of commands and parameters which are required for operations. In the absence of any configurations in a Configuration Specification for an instrument, the assumption by the developers is that specific configuration is not required for this instrument. In the absence of specification of specific commands that must be supported by the driver, the assumption is that it must only support the minimal set of commands necessary to obtain the requested data records in corresponding Data Product Specification documents. If no other documents define which instrument data record formats are being requested, the configuration specification document must provide that information. A configuration specification is expressed in terms of modes (at least one per specification), with a name, description, and type; an initiating command sequence (to enter the mode); and an optional exit sequence (to return to default or pre-existing state). The mode may or may not be described by the instrument's documentation, and the commands may or may not be accurately described in that documentation; thus the Integrated Observatory developers will depend heavily on guidance from the Marine Asset Expert, as provided in the Configuration Specification. Commands to configure the instrument settings and options to ready the instrument are considered part of the initiating sequence. The configuration modes may be of several purposes or types, depending on its intention:
i) Default — what commands and options are available to the Integrated Observatory for this instrument
ii) Checkout configuration — for initial checkout of the instrument (may also include initial sampling scheme for the platform/instrument, though this is usually specified in the Sampling Schemes);
iii) Operational configurations –-- one or more configurations which are needed to enable different types of operations during the deployment part of a marine asset's life cycle;
iv) Maintenance configurations — one or more configurations used for testing/calibration pre-deployment, refurbishing/calibration after recovery, safing the instrument for storage, and so on.

Once the CI software developers implement the requested modes, they appear as command options in the facepage for the instrument. Validation of the operation of the instrument using these modes ensure that the initial operation of the instrument will be as intended by the Marine Asset Expert and Data Product Specification Expert, as well as users of the instruments. [MI] After each mode is validated by the Marine Asset Expert, it is activated for use in the Integrated Observatory. (See by analogy UC.R2.09 Activate Instrument Driver.)


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