Skip to end of metadata
Go to start of metadata

Instrument Life Cycle Support

Bring an instrument from conception through operation and to decommissioning, with full control of full life cycle state.


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, Integrated Observatory registration, instrument deployment on the platform and activation on the marine network, necessary platform activities, modification of instrument configuration (e.g., adding a sensor), deactivation, and decommissioning.

Review Status Final
AS Priority 5
AS Version 3.1
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

Click on the thumbnail image to pop-up a full-width image, or see image on its own page.


Product Specification:

  • Marine Technician (Resource Manager): A Registered User who has been granted privileges to select resources within an observatory. Can edit resource settings and attributes; Create event related to resource; Manage annotational material of resource.
  • Marine Asset Operator: A Resource Operator who has been granted privileges to operate one or more marine assets in an observatory.
  • Integrated Observatory Operator: An Observatory Operator for the Integrated Observatory. Can manage user accounts; Schedule and manage OOI computational processes and resource allocations
  • Observatory Manager
  • System Process Programmer: A developer who provides computational software for the Integrated Observatory.
  • Instrument Provider (Marine Asset Operator): Someone (on staff) who has provided an instrument to the observatory and is helping the observatory run it.

External Systems

Instrument Asset System(s): Ocean Leadership is responsible for providing an asset tracking system for logistical tracking and management of instruments. If not otherwise specified, any reference to an instrument asset system is referring to that system (which is not assumed available before Release 2 is operational). If the term is pluralized as 'instrument asset system(s)', or if prefixed by 'IO', this refers to possible instrument asset systems that may be created by the marine IOs.

End-to-End Scenario

Relevant Use Cases
Material from relevant source use cases is presented in a box with prefixes like this. Each reference can be expanded.
CG.OMC.nn — OMC use case
CG.WS-SC.n.n.n — CGSN OMC workshop notes (scenario number)
CI.UC.nn — CI Release 2 Use Case
CI.CO.n.n — CI Instrument Life Cycle Operational Concept, Version 1-00, 2115-00001, 10/28/2008


In the pre-cruise period starts when the instrument is ordered, and continues through the time it has been tested and is ready for deployment. This sub-scenario is extensive.

Manufacturing Build, OOI Acquisition, and OOI Receipt

Relevant Use Cases
CG.UC.02 --- receive instrument life cycle data
CG.WS-SC.1.1.2 --- Instrument lifecycle data
CG.WS-Breakout.6.1 --- Asset Management
UC.R2.08 --- Manage Instrument Lifecycle
UC.R2.05#1 --- Register and Connect Instrument
CI.CO.1.1 --- Manufacture Build
CI.CO.2.1 --- Operator Commissioning Acquisition and Logistics
Life of an Instrument and its Products diagram
UC.R2.05 --- Register and Connect Instrument
UC.R2.08 --- Manage Instrument Lifecycle
UC.R2.09 --- Activate Instrument Driver
UC.R2.20 --- Annotate Resource in Registry
UC.R2.28 --- Manage Resource Metadata

When an instrument is ordered, information about the instrument (name, manufacturer, model, configuration, options and add-ons, vendor information and instructions, expected delivery date, responsible organization) may be entered into an instrument assets system maintained by Ocean Leadership.

This newly ordered resource is of interest to the Integrated Observatory Network. Although the instrument may not be received for some time, the Integrated Observatory wants to track its lifecycle from manufacturing to disposal, as those details can illuminate analyses done years later with that instrument's data. (See UC.R2.08 Manage Instrument Lifecycle.) Furthermore, the instrument will be associated with drivers, Data Product Specifications, and other artifacts that should be in place when the instrument arrives, and should be associated with the instrument via its metadata. Finally, the ordering process provides a checkpoint: if the instrument is ordered, software and systems must be ready for its expected arrival, if they are not already in place. (See UC.R2.09 Activate Instrument Driver.) Some implementation details in the final system are likely to vary from this ideal description.

Much of the information may even be entered before the instrument is ordered, in specifications maintained by the IOs on Confluence pages.

( 1 )

( 2 ) Each newly ordered instrument is also pre-registered in the Integrated Observatory, without concrete information like its serial number. The Integrated Observatory registration includes all the information of possible interest to the marine operations and scientist teams who may be working with the instrument or with its data. (See UC.R2.05 Register and Connect Instrument.)

The Integrated Observatory information is populated by OL for common (OOI-selected) instrument models, and by the Marine IOs for instrument models that are not common. Information from the SAF Instrument Application, the OL Instrument Asset System, or Confluence pages about the instrument may be used to populate Integrated Observatory data. If desired, a representative of the Marine IO and/or Integrated Observatory that pre-registered the instrument may verify that resources are consistent with expectations, and approves the new entries. ( 3 )

As additional information is obtained about an instrument, this information may be entered in the COL instrument asset system (when available, for administrative information), or the Integrated Observatory (for science-related information). (See UC.R2.28 Manage Resource Metadata.) ( 4 )

Upon actual receipt of the instrument, the instrument receiving checklist is executed by the receiving organization, possibly by their shipping and receiving department. This begins with inspection of shipping containers and verification that the shipping box information matches any signed receipt. The shipping container is opened and the product inspected, identifying any apparent damage or loose articles, as well as that the model and serial number on the product match that on the shipping invoice. At this point data entry begins; the manufacturer and model are confirmed against the original metadata for this instrument, and the serial number from the instrument is entered into the OL instrument asset system. ( 5 )

If shipping and receiving is a separate department, information generated during the receiving process can be sent by email to the marine technician team that will work with the instrument. The marine technician team has access to the Integrated Observatory system, and can annotate the instrument's records with the relevant emails, e.g., via attachments. (See UC.R2.20 Annotate Resource in Registry.) ( 6 )

The instrument comes with several additional items in the package: manuals, electronic media, and mounting and other parts. By default, these items (including version numbers, if any) are inventoried in the marine IO or COL instrument asset systems. A link to the online version of the manual is entered into the Integrated Observatory metadata for the instrument model, and a copy is downloaded (to have that version for posterity). The material in the digital media is copied to a binary disk image (IMG) in an Integrated Observatory system for safekeeping; this digital image can be downloaded later to a local machine if needed. ( 7 )

The additional parts that come with the instrument are not registered in the Integrated Observatory system, unless they include active electronics that can be installed in the instrument and are scientifically important to track, for example a spare sensor. (The instrument asset management systems are responsible for any part tracking.)

Finally, the marine technician takes pictures of the instrument and its components. The pictures are uploaded to the Integrated Observatory system, associated with the instrument's unique ID. (See [UC.R2.20 Annotate Resource in Registry.) They can be viewed later to verify the instrument's condition, look for identifying details, and see what was included with the instrument.

Instrument Tracking

Instrument tracking serves 3 functions, each demanding different data: property management, operations management, and science operations. For property management, the manager needs to know the instrument's financial value, operating condition (operable or inoperable), responsible organization, and physical location (where stored or on which system it is deployed). This function is managed by the instrument asset systems in OOI. For operations management, the deployment, configuration, and trouble history of the instrument, its system location, and its suitability for a particular purpose (does it have the necessary sensors? is it the right size?) are important. For scientific operations, the exact current location and operating condition (is it sampling?) of the instrument may be the most important aspects.

At the end of each pre-cruise (that is, terrestrial) activity in the instrument's lifecycle, the location of the instrument is noted by the Marine Asset Operator (by association to non-marine 'sites' to be defined). ( 1 ) When an instrument is physically mounted ('deployed') on a platform, this will be recorded, so the Integrated Observatory can report which instruments are on a given platform, or which platform an instrument is mounted on. (See OOI Platform Composition, Platform Integration, and Integration Testing below.)

In geospatial terms, the Integrated Observatory knows the instrument location by its platform location (given by the site location; or the nominal or actual deployed location of the platform; or in the case of moving platforms, the actual or best estimated position of the platform, depending on what information is available in real time). ( 8 ) ( 2 )

In the marine operations, the mounting and unmounting of instruments may be checklist driven, performed once before and once after each cruise, and the results are separately entered into the Integrated Observatory. ( 9 )

Future Release Notes
Release 3
Release 4

OOI Configuration, Calibration, and Bench Testing

Relevant Use Cases
CG.WS-SC.1.1.2 --- Instrument calibration data
CI.CO.1.2 --- Calibration/Test
CI.CO.2.2 --- Operator Commissioning Configuration, Calibration, and Test
UC.R2.20 --- Annotate Resource in Registry

The instrument may optionally be configured when it is received, in terms of installed components, physical assembly or adjustment, and software settings (the latter including communication protocol, operational settings, and data output formats). The configuration steps should be logged, ideally electronically in the Integrated Observatory by saving a copy of the steps in an attachment or annotation. ( 1 ) (See UC.R2.20 Annotate Resource in Registry.)

Bench testing is performed to verify the instrument is working normally. ( 2 ) The instrument may be connected to a local computer to run instrument-specific applications. The marine IO updates the instrument metadata to reflect the results of bench testing (whether it was performed and whether it passed), and provides that and other bench testing details in logs, which ideally will be in a digital asset format that can be ingested by the Integrated Observatory. ( 3 ) If deemed necessary, a senior member of the Marine or Integrated Observatory staff reviews and confirms / validates bench test results.

Any desired instrument calibration is also performed at this time, if the instrument maintenance environment supports such steps. Calibration serves to verify information provided by the vendor, and account for changes since the instrument was last calibrated. Again, calibration results should be logged, possibly into a digital assets such as a PDF or Excel document which can then be ingested by the Integrated Observatory and associated with the instrument. ( 4 )

Future Release Notes
Release 3

CI Instrument Preparation

Relevant Use Cases
CG.WS-Breakout 5 --- Breakout 5 Notes
Life of an Instrument and its Products diagram
UC.R2.03 --- Produce Real-Time Calibrated Data
UC.R2.05 --- Register and Connect Instrument
UC.R2.09 --- Activate Instrument Driver
UC.R2.21 --- Transform Data in a Workflow
UC.R2.42 --- Define Resource Policy

While the instrument is being configured, calibrated, and tested — and often well before that — the Integrated Observatory started developing the instrument driver and agent as necessary, and obtaining associated metadata from the science and marine operations teams. (See UC.R2.09 Activate Instrument Driver.)

To develop the agent and driver, CI's Marine Integration team must have access to an instrument instance that can be used for testing during the driver and agent development.

The Integrated Observatory system should be in possession of the following knowledge artifacts and resources for an instrument before that instrument is attached to any of the OOI observatories:

  • instrument metadata (e.g. TEDS data sheet, and description of the instrument's outputs)
  • instrument anciliary information (manuals, firmware etc)
  • instrument use policy (see UC.R2.42 Define Resource Policy)
    • usable by anyone, anytime is default; or contains list of restrictions ( 1 )
  • data use policy (viewable by anyone, or ...)
  • ( 2 )
  • instrument operational state information (sufficient information about the instrument's operation to define its possible operational states in the standard instrument and agent state diagrams)
  • software to interface the instrument:
    • instrument agent
    • instrument driver
  • in Data Product Specifications or other specifications, details about:
    • nominal physical and software configuration of the instrument,
    • target operational configuration (setup) of the instrument (if any is required),
    • instrument sampling frequency (or range of frequencies, and how they are selected)
    • any real-time decimation (downsampling or recomputing) required for telemetry or performed by instrument
    • derived data product specification, including parameters to be applied

The System Process Programmer creates the instrument interface software (the driver and agent) that connects the instrument to the observatory.

Finally, the instrument must be set up in the Integrated Observatory (by an Integrated Observatory operator) before the instrument can be attached to the system. (See UC.R2.05 Register and Connect Instrument. Derived data products may also be set up at this time, or may be produced after the instrument is operational. (See UC.R2.03 Produce Real-Time Calibrated Data and UC.R2.21 Transform Data in Workflow.)

Future Release Notes
Release 3

OOI System Testing

Relevant Use Cases
CG.WS-SC.1.1.2 --- Instrument calibration data
UC.R2.05 --- Register and Connect Instrument
UC.R2.08 --- Manage Instrument Lifecycle
UC.R2.15 --- Qualify Instrument Interface

Instrument interoperability with the Integrated Observatory system is validated by bringing the instrument up with an instrument agent and appropriate driver and running instrument validation tests, as described below.

First, the instrument is physically connected (physically interfaced) to a resource connected to an Integrated Observatory system. (see UC.R2.05 Register and Connect Instrument.) ( 1 )

On command of a marine operator or technician, the Integrated Observatory system identifies the instrument, to the extent possible for the given instrument. Ideally this takes place for the first time as part of the Bench Testing process (and recurs in the System Test process); otherwise it occurs for the first time in the Integrated Observatory System Test process. ( 2 )

The metadata for (and possibly on) the instrument fully describes that instrument, including information about how to parse the records that come from it. ( 3 ) Some metadata describes the individual instrument instance, but most will describe the instrument model.

The Marine Technician runs the instrument through a number of system-level interoperability tests, confirming the instrument and driver are communicating effectively, and the instrument is capable of being commanded. (Some care is required to execute only the appropriate commands for the test environment). ( 4 ) ( 5 ) To the extent possible, the instrument is configured as if for marine operations and its operation confirmed in that state. (See UC.R2.15 Qualify Instrument Interface.)

As testing proceeds, the instrument's status in the system is changed to reflect that the instrument started, and then completed, its testing. (See UC.R2.08 Manage Instrument Lifecycle.) ( 6 )

Future Release Notes
Release 3

OOI Platform Composition, Platform Integration, and Integration Testing

Relevant Use Cases
CG.OMC.01 --- receive platform configuration
CG.WS-SC.1.1.1 --- Instrument calibration data
CG.SC.2.2.1 --- Mooring Operation, Command, Control, and Data Comms
CI.CO.3.1 --- Deployment Installation, Network/System Connection and Registration
UC.R2.11 --- Define Marine Observatory Resources and Policy
UC.R2.24 --- Search for Resource

The intended platform configuration is defined by the responsible Observatory Manager. (See UC.R2.11 Define Marine Observatory Resources and Policy.) The planned configuration, which can be specified as concrete real-world instruments (with serial numbers) or more abstract instrument representations, is stored in the Integrated Observatory, and viewed there by the Marine Technician. Through potentially multiple iterations, the technician configures the actual platform by installing the appropriate real-world instruments, updating the 'as-built' configuration in the Integrated Observatory as work progresses. (The 'as-built' configuration is the way the system is actually put together, which may or may not exactly follow the plan.)

During this process, instrument instances may need to be replaced, or the fundamental organization planned for the platform may change, and so the planned configuration may change. The technician can search for replacement components using either the COL asset system, or the Integrated Observatory, depending on the particular components and qualities critical to the configuration. (See UC.R2.24 Search for Resource.)

Once satisfied that the actual platform configuration is final, the technician registers the final configuration in the Integrated Observatory. This configuration may be used in up to three places: by the COL asset tracking system to report instrument locations; by the Integrated Observatory to manage and report instrument deployment information; and by the platform agent (and possibly even the on-board controller) to understand what assets are on the platform. ( 1 )

Different connection protocols are used to communicate with devices according to their physical connection/networking protocol (e.g., Ethernet vs RS2-32 devices).

( 1 )

Several observatory actions may also take place once the registration and evaluation process is performed. In particular, at this time the platform or observatory can:

  1. notify interested parties of updates to the status and configuration of the platform and devices
  2. synchronize time on the device, the device's proxy, and the platform
  3. update information in the Integrated Observatory about available devices and measurements
  4. ( 2 )
  5. ( 3 )

Integration Testing

Relevant Use Cases
UC.R2.06 --- Command Instrument
UC.R2.10 --- Manage Marine Platform

With the platform nominally configured, integration testing can begin. (It may have been under way throughout the assembly process.)

In order to support the configuration of the platform for a deployment, the Marine Observatory Operator needs to provide information to the Integrated Observatory system about the instruments, the ports they are connected to, defined baud rate and communication protocol, maximum power limits, as well as some platform information. ( 2 ) The Integrated Observatory system configures the platform and instrument agents (as appropriate) with this information, such that the instruments can be readily controlled once deployed appropriately. [MI]

( 4 )

The deployment configuration to be supported for each scientific instrument on the surface mooring has already been supplied as described in AS.R2.04C Instrument Experts Drive Core Instrument Operations. Through the Integrated Observatory system, the operator confirms the instrument configuration information, to ensure the instrument is configured properly and can be reconfigured at any time to the requested default.

In addition to the configuration of the instrument itself, a mission configuration has been provided that contains information such as how often the instrument is to be sampled, and when it is to be powered on and powered off. This basic operational configuration information is likewise confirmed by the Marine Observatory Operator using the instrument agent. More advanced sampling strategies must be handled manually by an Observatory or Instrument operator, or through external scripts. ( 3 ) [MI]

( 4 )

Power is supplied to the instruments and platform controllers, and the platform controller and platform agent software provide communication between the instruments on the platform, and the Integrated Observatory control software on shore or on the ship.

When power is supplied to the platform, the observatory uses the platform's latest defined configuration to communicate with and control it and its assets. As the interfaces and agents begin communicating, the platform becomes visible as an active part of the observatory to which it belongs, and its instruments become visible to users as an active part of the platform. Their assignment to the platform/observatory was apparent before, but not their operational status. (Note that the platform and instruments are not yet on the principal deployed OOI observatory, but are still in an offline or testing observatory.) This enables users of the Integrated Observatory to select an instrument from the list of available instruments, and begin issuing commands to that instrument. (See UC.R2.10 Manage Marine Platform and UC.R2.06 Command Instrument.)

Once two-way communications are established and validated between the controlling the Integrated Observatory system, and the newly integrated platform and its components, the platform configuration can be considered OOI-compliant, and ready for deployment into the operational marine observatory.

Future Release Notes
Release 3
Release 4

Pre-Station / Remote Operations

Relevant Use Cases
CG.OMC.11 --- maintain platform physical configuration

Remote Operations

Relevant Use Cases
UC.R2.06 --- Command Instrument
UC.R2.08 --- Manage Instrument Lifecycle
UC.R2.10 --- Manage Marine Platform
UC.R2.13 --- Acquire Data From Instrument
UC.R2.60 --- Troubleshoot Deployed Instrument
Although most of this sub-scenario is unlikely to take place using the Release 2 system, it has been included here pending resolution of the appropriate deployment schedules.

Some months later the surface mooring is shipped to its pre-cruise readying site in South America. After assembly the deployment team connects the Integrated Observatory system, federated via land-line networks with the other systems in the Integrated Observatory network, and thereby through satellite connection to the mooring. ( 1 ) ( 2 )

The platform has been configured to run appropriately, and using the Integrated Observatory system, the deployment team is able to run various tests and confirm that the platform is operating appropriately. (See UC.R2.10 Manage Marine Platform.) By commanding platforms and instruments via the Integrated Observatory system (see UC.R2.06 Command Instrument), the Marine Observatory Operator runs a number of diagnostic commands to verify proper performance and status of the instruments, battery, electrical bus, and other key components of the system. In this process, the results indicate that the two humidity instruments on the platform are reading different levels. (See UC.R2.60 Troubleshoot Deployed Instrument.)

In order to verify which of the humidity sensors has failed, the team connects the spare humidity sensor to the laptop running the Integrated Observatory software. An instrument driver that comes with the Integrated Observatory software collects data on the laptop from the instrument over a 24-hour period. (See UC.R2.13 Acquire Data From Instrument.) This can be plotted in the laptop's local Integrated Observatory (but there is no provision to upload that data to the main Integrated Observatory).

Data collected from the laptop-connected instrument and the platform-connected instrument is available in the Integrated Observatory common data format, and can be viewed and compared using the Integrated Observatory system. The deployment personnel determine which humidity sensor has malfunctioned and replace it with the spare. The actual Integrated Observatory system is used to configure the new instrument (online) as the replacement. (See UC.R2.08 Manage Instrument Lifecycle.)

Using the laptop Integrated Observatory software the deployment personnel request the configuration for each instrument connected to the platform. They then compare that configuration with the nominal (planned) information stored on the Integrated Observatory system for each component, and verify that all instruments are configured correctly.

( 3 ) ( 1 )

The gliders also need to be tested to verify that they are functioning correctly. The deployment team connects the glider to its dock server management system and performs the verification tests provided by the glider vendor. The data from the dock server is then read by the Integrated Observatory system, which can then provide a detailed view of the current glider status. (See UC.R2.13 Acquire Data From Instrument.)

Release 3
Release 4


Before the ship arrives at station, all of the pre-cruise activities may be continued on the ship. This is avoided when possible, as the ship environment is harder to work in and there are not necessary resources (like spares) in case of problems. The operations that do take place in this way are essentially the same as in pre-cruise, with the caveat (noted in the CI.OMC.11 use case) that the available spares and communication may be limited.

If Integrated Observatory-related activities take place in the absence of a connection to the terrestrial systems, it will be necessary for the on-board personnel to keep track of the configuration, log, and other changes, for later entry into the federated system when communications are restored.

( 1 )

There are no instrument life cycle events that happen uniquely during this cruise phase.

Future Release Notes
Release 4

On Station

Instrument Deployment and Commissioning

Relevant Use Cases
CG.OMC.07 --- deploy mooring (stationary platform)
CG.WS-SC.n.n.n ---
Resource Lifecycle
UC.R2.08 --- Manage Instrument Lifecycle
UC.R2.18 --- Visualize Data Product

Once certified as OOI-compliant (typically as the result of having passed the tests above), the marine asset (and any corresponding physical entity) may need to be physically deployed on site. In preparation for the deployment, the Marine Observatory Operator may connect to a platform such as a surface mooring by using its remote (satellite) connections. ( 1 ) In this way mooring operations can be checked for proper functioning before and during the deployment process, and the mooring's physical state (e.g., acceleration forces) can be monitored in real time to highlight possible concerns.

Once the marine asset is deployed in the water, its life cycle state is set appropriately by the Marine Observatory Operator. As part of the physical deployment checkout, the Marine Observatory Operators will verify that the deployed components are interacting with the OOI system as designed, and then notify the resource provider that the system is ready for their validation. (See UC.R2.08 Manage Instrument Lifecycle.) Data collected throughout the resource's deployment and initial checkout is ingested by the Integrated Observatory, saved for later analysis if necessary by the operations team.

After the instrument provider validates that the instrument is working as intended, OOI can assert that the resource has been commissioned, meaning it is operating normally and ready for use by the observatory. (This is different than the formal commissioning that OOI performs at the system level.) This ready-for-use assertion is performed by the Marine Observatory Operator. ( 2 )

For the instrument provider to assert the instrument is working as intended, an extended analysis may be required. This is a likely scenario when the instrument has not been tested before, and is being compared to other instruments in the vicinity. In most operational cases, it is in the Instrument Provider's interest to determine quickly, while the ship is still on station, that the instrument appears to be operating normally. Ideally, this is done with side-by-side comparisons of instrument data and engineering readings, confirming that the new instrument is working before it is activated (and the old instrument de-activated, switched off and removed). (See UC.R2.18 Visualize Data Product.)

Future Release Notes
Release 3

Instrument Activation / Instrument Deactivation

Relevant Use Cases
CI.CO.4 --- Recovery
Resource Lifecycle
UC.R2.06 --- Command Instrument
UC.R2.08 --- Manage Instrument Lifecycle
Activation operationally enables the resource for use within OOI. It is a routine operation associated with the resource becoming available for general use, and then possibly unavailable at other times. Activation of a resource might be requested by any OOI user; some resources can become active upon request, while others require manual intervention (e.g., they must be physically deployed); still others can only become active under certain conditions. Note that the instrument may have been operated, tested, or interacted with for an extended period without being activated; this is a statement of general resource availability, not a description of its operational readiness. Instruments may be turned off and on often, in which case Activate/Deactivate could be useful activities, or they may be turned on and left on for their entire operational life, which implies activation only once. Most AUVs are activated for each mission/deployment and deactivated when the mission ends. A mixed mode of deployment may occur, with an instrument deployed multiple times, and turned on and off within each deployment, for example to save power. The proper application of Activate will have to be determined appropriately for the given scenario.

Before activation, the resource is checked out and made ready to operate, including performing any final configuration activities that are needed to make it ready for observatory operations. When it is ready, the Marine Observatory Operator sets the instrument status to indicate it can be used. Other entities are now in a position to use the resource, assuming they have the necessary authorizations. While active, a resource may be locked to a single user, so an active status does not mean the resource is definitively available. (See UC.R2.08 Manage Instrument Lifecycle.) Additional attributes show the user whether the resource is available for commanding (e.g., whether it is busy or perhaps offline).

Before an instrument is removed (disconnected) from the observatory, it must be deactivated to ensure that no commands are mid-execution when the instrument is powered down or removed. Before devices are powered off and physically removed, several steps take place. The observatory operators begin to disable each device, which includes several important steps: notifying the device users ( 1 ) of the change and its rationale; commanding the devices to stop collecting and publishing data; notifying the platform that the devices are being removed; and putting the device into a stable and safe state for turning off its power. (See UC.R2.06 Command Instrument and UC.R2.08 Manage Instrument Lifecycle.) At that point, operators can turn off power to the device and send out a marine operations team to physically remove the devices. Once removed, the new location for the device is logged.

Future Release Notes
Release 3

Instrument Use

Relevant Use Cases
CI.CO.3.2 --- Deployment Command and Control
UC.R2.06 --- Command Instrument
UC.R2.07 --- Direct Instrument Access
UC.R2.11 --- Define Marine Observatory Resources and Policy
UC.R2.13 --- Acquire Data From Instrument
UC.R2.60 --- Troubleshoot Deployed Instrument
Upon being powered on, a device may simply perform its pre-programmed operations without direction; may await commands to perform operations or change their configuration; or may combine the two operational modes. In the case where no command or control signals can be issued to the device itself, the device's only activities of interest may be data generation and output.

The device's representative ("agent") in the Integrated Observatory may accept and respond to certain commands on behalf of a device, based on data available from the device, or possibly forwarding those commands through special communication channels.

Most typical commands are standardized in the Integrated Observatory system for every device, so users do not have to learn a device's custom command language to control it. Each device's screens will give access to the standard commands, as well as to custom commands for that device. (See UC.R2.06 Command Instrument.)

When a controllable device is registered on a platform, potential users (operators, parent platforms, device owners, other users) will want to command it. Each of these may have simultaneous and competing interests in operations of the device, so the observatory will have to have policies and procedures for mediating conflicts. ( 1 ) (See UC.R2.11 Define Marine Observatory Resources and Policy.)

Having received a command, the device (represented by an agent in the Integrated Observatory system) acknowledges receipt of the command, provides an intermediate response for a command that takes a long time to execute, and sending the device's final results of the command when they are available.

The observatory or its designee(s) (e.g., the platform) logs all interactions with the device for later use in diagnostic analysis of the device, observatory, and above all the science data. (See UC.R2.60 Troubleshoot Deployed Instrument.)

Because some instruments (e.g., on CGSN global platforms) only have sporadic connectivity, certain steps may be needed that are different than for always-connected instruments. Furthermore, because of lags and satellite telemetry it is not possible to enter commands directly to certain instruments from shore; they must be queued for later entry.

One such instrument, a CTD on the Pioneer central, puts out data in three different accepted OOI data formats (though only one can be selected at a time). Dr. John, a scientist who is the responsible operator for this instrument, has received permission and direction to change its data output format as soon as possible.

Dr. John logs into the Integrated Observatory system and has the role of Instrument Operator for this CTD, giving him permission to access it directly. He requests and receives a direct connection to the instrument, and enters the commands necessary to change the CTD from data format 1 to format 2. He exits the direct access session. (See UC.R2.07 Direct Instrument Access.)

Because all 3 formats have already been described for the instrument, no software modification is required. However, the change of source means that the raw data format has now changed for the instrument, and the Level 0 signals have a different source and somewhat different provenance. The signals are all present, but they are coming from a different data stream. This requires reconfiguration of the process that produces level 0 data, to use the appropriate data stream from the CTD.

Dr. John has contacted the Marine Operator, who is capable of performing this modification to the process configuration, and the Marine Operator agrees to make the change at the same time as Dr. John's change. ( 2 ) This is a critical activity; without it, the processes that rely on the data from format 1 will wait forever, since no more format 1 data is being produced. This has the potential to break all the downstream data products (time series) that come from that data stream. ( 1 )

Dr. John loads the commands for execution the next time the mooring connects to shore.

When the mooring connects the various commands are downloaded as planned, and the remote agent on the mooring begins executing them. Even if the mooring communication to shore now terminates, the remote agent will attempt to perform all the commands that are entered. The remote instrument agent knows that when reconfiguring this instrument, it must first power off the port to stop automatic data acquisition mode, power on the port, then within 5 seconds enter the character sequence necessary to put the instrument into command mode. Then it can enter the command for the new configuration.

After receiving the configuration command, the instrument responds with a string that indicates it was unable to understand the command. The instrument agent recognizes that this error can sometimes occur for no particular reason, and reissues the command, to which the instrument responds correctly, indicating it received the values correctly.

The instrument agent then does a status of the instrument and verifies the configuration information is as specified, and issues an event indicating the command was successfully executed. After these steps the instrument agent issues a command to start the instrument's automatic data acquisition cycle.

Dr. John has already told the Marine Operator that the command was uploaded to the mooring, and the Marine Operator makes the change to the post-processing that produces the Level 0 data. ( 3 )

Future Release Notes
Release 3
Release 4

Instrument Failure Detection and Troubleshooting

Relevant Use Cases
CG.OMC.15 --- respond to alerts, alarms, incidents
CG.WS-SC.2.3 --- Mooring/Vehicle Equipment Failure
CI.CO.3.4 --- Deployment Failure Detection, Diagnosis, and Repair
UC.R2.14 --- Monitor an Instrument
UC.R2.55 --- Manage Help Ticket
UC.R2.60 --- Troubleshoot deployed instrument

Detection of device failures can occur through multiple channels. The participant or role that detects and reports each type of failure is noted in parentheses. (See UC.R2.14 Monitor an Instrument.)

  1. The communications with the device can fail catastrophically. (Instrument Agent)
    • The Agent detects this failure when it can not communicate with the instrument, and reports it to the Integrated Observatory automatically.
  2. The instrument can (silently) stop sending its data. (Instrument Agent, Owner/Operator, or User.)
    • In some cases the driver or agent can detect this absence of data, and report it to the Integrated Observatory automatically. [NoUC]
  3. An interacting device owner or operator can notice problems during the interaction. (Owner/Operator)
    • The individual can log a comment on the failure, and/or issue a trouble ticket.
    • ( 1 )
  4. Generic quality control software can detect data anomalies. (QC Software)
    • The QC software can provide annotations/comments on the data product that has issues.
    • ( 2 )
  5. Device-specific quality control/processing software can detect problems. (Device-Specific QC/Processing Software)
    • Minimal problem-detection software may exist for specific devices, capable of reporting information and set device status in those cases.
  6. The instrument or platform itself can report the error in its data transmission. (Marine Asset)
    • The Integrated Observatory can be set up to automatically detect some kinds of data errors and turn these into Integrated Observatory events. [NoUC]
    • ( 3 )
  7. Users of the data from the device can notice problems. (Data Users)
    • The user can create annotations on data products, or create trouble tickets, or both.
    • ( 4 )
      In each case, there exists a communication process to log the problem, in some cases in ways that reference the affected device.

When a trouble ticket is logged from an instrument page, the unique instrument identifier in the Integrated Observatory is included in the trouble ticket. This enables all tickets on that instrument to be found and viewed. Other salient information known to the system at the time of the ticket may also be logged. The tickets that have been logged for a particular instrument may be viewed using a button on the primary instrument page. (The trouble tickets themselves are managed in the OOI Jira trouble ticketing system.) (See UC.R2.55 Manage Help Ticket.)

Future Release Notes
Release 3


After the ship leaves station, work may begin to post-process instruments, platforms, and data. This is avoided when possible, as the ship environment is harder to work in and there are limited resources. The operations that do take place in this way are essentially the same as in post-cruise.

There are no instrument life cycle events that happen uniquely during this cruise phase.


Instrument Processing and Decommissioning

Relevant Use Cases
CI.CO.4 --- Recovery
UC.R2.08 --- Manage Instrument Lifecycle
UC.R2.38 --- Define and Use Resource Life Cycle

Once the device is physically removed, operators can change its status to follow activities and circumstances. The instruments are removed from the platform and inspected for fouling, damaged sensors or connectors, or other indications that their science data or ability to perform may have been compromised. Any such problems are logged as part of the instrument logs. ( 1 ) The instruments are cleaned and stored, any consumables (e..g, batteries or reagents) replenished, and their status set to indicate they are ready to deploy. ( 2 ) Their storage location is indicated using the asset management system or the Integrated Observatory as appropriate. (See UC.R2.08 Manage Instrument Lifecycle.)

In this case, because some devices are not considered suitable for further use by the observatory, the device life cycle state for those devices are updated to "Retired", with a suitable explanatory comment. This will prevent users from trying to obtain those devices and install them elsewhere, as only observatory operators (or an explicit search for that device type, device ID, or device status) will find the devices, and their status will be immediately apparent.

The driver for this device may also be archived if there are no other instruments of this type remaining in the OOI systems. In this case, any software and material related to the instrument are saved, so data collected by that driver can be verified or reprocessed if needed. (See UC.R2.38 Define and Use Resource Life Cycle.)

( 3 )

Release 3


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