Skip to end of metadata
Go to start of metadata

Overview of "Manage Instrument Lifecycle" Use Case

Bring instrument from conception through decommissioning


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Marine Asset Operator (as Instrument Provider/Instrument Developer, Instrument Technician, or Marine Operator), System Process Developer (as Driver Developer)
References CIAD SA OV Instrument Activation
Resource LifeCycle (has diagrams)
S&A Overview (end-to-end example)
CI Instrument LifeCycle ConOps
Uses UC.R2.05 Register and Connect Instrument
UC.R2.06 Command Instrument
UC.R2.07 Direct Instrument Access
UC.R2.09 Activate Instrument Driver
UC.R2.13 Acquire Data From Instrument
Is Used By  
Extends  
Is Extended By UC.R2.03 Produce Real-Time QC Data
In Acceptance Scenarios AS.R2.01A Operate Marine Observatory, AS.R2.02A Cruise Support, AS.R2.02B Data Support via Cruise, AS.R2.02C Instrument Life Cycle Support, AS.R2.04A Data Product Leads Drive Core Data Product Creation
Technical Notes  
Lead Team SA
Primary Service Instrument Activation Services
Version 2.5
UC Priority 4
UC Status Mapped + Ready
UX Exposure MNC

Summary

This information summarizes the Use Case functionality.

Bring an instrument from conception through operation and to decommissioning, with full control of the entire 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.

Assumptions

  • State definitions: PLANNED: known to ion, basic metadata are filled out; DEVELOPED: instrument driver developed. registered, metadata added, instrument driver exists. In this state, instrument can be tested against running system.
  • We are not providing interfaces for each of the tasks needed for each lifecycle stage such as testing.
  • Do need to provide upload and store capabilities/UI's for logs, manuals, and other data related to instruments (ancillary information)
  • Registration is done before instruments are in the water. CI is doing it on behalf of instrument owner.
  • R2 will not provide conflict resolution in case 2 operators access the same instrument.
  • Asset tracking may be a part of OOI's instrument acquistion and registration process, but is not addressed here.
  • Only Core OOI instruments are addressed in Release 2.

Initial State

A physical instrument has just been acquired and not yet been registered with the Integrated Observatory.

Scenario for "Manage Instrument Lifecycle" Use Case

  1. Instrument is acquired by OOI and registered with ION (Instrument Technician)
    1. Instrument Technician registers the physical instrument with ION. Basic metadata are logged with the planned instrument. (Step 1 of UC.R2.05 Register and Connect Instrument; state is PLANNED)
    2. Instrument Technician acquires instrument and uses manufacturers software for local testing, calibration and configuration. Additional metadata are gathered from the test results.
    3. Instrument Technician makes sure an ION instrument driver exists for this model (see UC.R2.09 Activate Instrument Driver). Driver development is not covered by this use case
    4. Instrument Technician determines ION instrument driver configuration for this model and variant
    5. Instrument Technician updates instrument metadata with results of development testing and requests the state be advanced to DEVELOPED. System confirms authorization and status, and advances instrument state to DEVELOPED.
  2. Bench Testing is performed on instrument (Instrument Technician)
    1. The deploying marine observatory takes possession of the instrument and connects it to their ION test facility using a configured driver
    2. Instrument Technician updates instrument metadata with results of bench testing results. System certifies and confirms bench test results.
  3. System Testing is performed on instrument (Marine Technician)
    1. The Marine Technician activates the instrument within the ION network, on the test facility, and runs validation tests for active ION instruments. (Steps 2 and 3 of UC.R2.05 Register and Connect Instrument.)
    2. Instrument interoperability with the ION system is validated by bringing the instrument up with an instrument agent and appropriate driver and running instrument validation tests. Bench testing occurs with ION agent and driver software, but is not activated on the primary ION network. (Possibly Steps 2 and 3 of UC.R2.05 Register and Connect Instrument.)
    3. Marine Technician updates instrument metadata with results of system testing. System certifies and confirms system test results.
  4. CI Deployment and Instrument Commissioning (Marine Technician, Marine Observatory Operator)
    1. The instrument is redeployed at its operational location.
    2. The instrument is reactivated with agent and driver software in the ION network for the deployed location. Deployment tests validate the instrument behavior.
    3. Metadata from the deployment and deployment tests are certified and added to the instrument metadata by the Marine Observatory Operator.
    4. Marine Observatory Operator requests instrument commissioning. System confirms authorization and status and advances the instrument resource state to COMMISSIONED.
  5. Instrument is Activated (Marine Observatory Operator)
    1. The Marine Observatory Operator runs activation tests on the deployed instrument to confirm its behavior.
    2. Marine Observatory Operator updates instrument metadata with results of activation testing. System certifies and confirms activation test results.
    3. Marine Observatory Operator requests instrument activation. System confirms authorization and status and advances the instrument state to ACTIVE.
  6. Instrument is used in ION.
    1. UC.R2.06 Command Instrument
    2. UC.R2.13 Acquire Data From Instrument
    3. UC.R2.07 Direct Instrument Access
  7. Instrument is deactivated (Marine Observatory Operator)
    1. Marine Observatory Operator retrieves instrument status and verifies it is not in use, or schedules for instrument to be free of scheduled and future use.
    2. Marine Observatory Operator requests instrument deactivation, system confirms authorization and conflicts. System disconnects instrument comms, powers down instrument and shuts down agent and driver software. System changes instrument state back to COMMISSIONED.
    3. Marine Observatory Operator can retrieve instrument hardware package from deployment location and returns it to the PI.
  8. Instrument Decommissioning (Marine Observatory Operator)
    1. Marine Observatory Operator requests instrument decommissioning, system confirms authorization. System advances instrument state to DECOMMISSIONED.

Final State

The instrument has passed through all of its resource life cycle states, mediated by ION services.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

Per the OV-5 (which I see is duplicated and augmented in the Resource Lifecycle document in the references) and Instrument Life Cycle Concept of Operations, an instrument can be removed from the system after deactivation. However, activation does not explicitly present the inverse of this (that an instrument must be on the system before activation), so there needs to be some detailed analysis.

Description of additional roles above:

  • Instrument Technician: This person prepares the instrument for use on the observatory; they are acting on behalf of the observatory, and possibly also for the instrument provider (if it isn't a core instrument). Mostly these are marine IO personnel, but they could also be an external party who is following our processes.
  • Instrument Developer: This is the person (people) who develops the instrument, which to me means they bring the instrument from non-existence to existence. In most but not all cases, this is the same as the Instrument Provider. (Because there will be instruments that are developed or adapted custom for OOI, I want to recognize the instrument development process as part of the life cycle.)

Future pathways for instrument arrival: Three scenarios for obtaining instruments follow. An instrument needs to cross a line from "non-OOI-maintained" to "OOI-maintained", and to do so it has to meet certain criteria; OOI does not take possession until the criteria have been met by the provider.

  1. Core Instrument bought by OOI: Instrument is developed by a vendor, and sold to OOI. Instrument Provider and Instrument Developer are roles filled by vendor; Instrument Technician is a marine operator.
  2. Private Instrument bought from a vendor by a PI, and provided to OOI for deployment on behalf of that PI. Instrument Provider is a Principal Investigator. Instrument Developer is a vendor. Instrument Technician is from a marine IO, or possibly supported by someone from the PI's team. The PI has the ultimate job of meeting the criteria for OOI stewardship, not vendor.
  3. Private instrument developed and provided by a PI: This is like (2), but the PI is both Provider and Developer (and may or may not play Instrument Technician for OOI).

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

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