View Source

h2. Overview of "{metadata:Use Case Name}-Install Instrument Automatically- _(Deprecated)_{metadata}" Use Case

*{metadata:Description}-Use standard protocol to retrieve instrument ID/metadata from device itself.- _Not available in Release 2._{metadata}*

{metadata-list:|hidden=true}
|| Use Case Release | R2 ||
|| Use Case Number | 16 ||
|| Original WBS Use Case Name | Install instrument automatically ||
|| R1 Use Case Number | ||
|| Assignee | Tom O'Reilly ||
{metadata-list}

h3. Metadata

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

{metadata-list}
|| Actors | Instrument Technician, Observatory Operator ||
|| References | [PUCK white paper|https://confluence.oceanobservatories.org/display/CIDev/OGC+PUCK+protocol] ||
|| Uses | ||
|| Is Used By | ||
|| Extends | ||
|| Is Extended By | ||
|| Technical Notes | OGC PUCK is the likely protocol and, if necessary, hardware technology to enable this capability. SensorML is one likely description language. ||
|| Lead Team | SA ||
|| Primary Service | Instrument Activation Services ||
|| Version | 1.3 ||
|| UC Priority | 3 ||
|| UC Status | -Deprecated- ||
|| UX Exposure | PGM ||
{metadata-list}

h3. Summary

_This information summarizes the Use Case functionality._

{metadata:Detailed Summary}
_*This use case has been deprecated in Release 2, for lack of time and instruments to implement it.*_

When the instrument has been registered, it must be prepared for installation on the system. That installation must happen in such a way that when the instrument is connected to the marine system and turned on, as many of the following steps as possible are automated: (a) instrument is detected, (b) ION queries instrument for its identification and description, (c) instrument provides identification and description, (d) ION software compares information to its own registration information, updating as needed, (e) ION software downloads appropriate driver and installs it, and (f) ION successfully initiates communication with the instrument in its native protocol and brings the instrument on-line.

To prepare for this scenario, and to simplify the steps of the Instrument Technician in preparing the instrument for deployment, several initial configuration steps rely on and contribute to metadata that is digitally available in the instrument.
{metadata}

h3. Assumptions

{metadata:Assumptions}
* An OGC-PUCK- (or equivalently-) enabled instrument is procured from manufacturer. PUCK protocol enables retrieval of universal serial number (UUID), manufacturer, model, and other metadata from the device itself, following a standard protocol to read from and write to data storage associated with the instrument.
* If instrument from manufacturer is not so enabled, enabling software is attached via a hardware add-on.
* The functionality can be emulated by the platform if it is not available in the instrument, in which case lab and deployment procedures have to be altered considerably.
{metadata}

h3. Initial State

{metadata:Initial State}
Instrument implements standard OGC PUCK protocol (or equivalent) through its RS232 serial port or IP/Ethernet port, and has been configured with the appropriate information.
{metadata}

h2. Scenario for "{metadata-from:Use Case Name}" Use Case

{metadata:Scenario}
# *Instrument Technician performs lab checkout of instrument, acquiring on-board stored information.*
## When the technician plugs the instrument into the laboratory network, an ION-system-aware application on that network extracts metadata from the instrument and send it to ION instrument registry for storage, keyed to instrument's UUID.
# *Based on extracted manufacturer and model, registry determines appropriate ION driver for instrument.*
## Technician may add additional information as needed to instrument's registry entry.
# *Instrument on-board storage is automatically updated with driver and other identification and configuration metadata from the ION system.*
## This information may be useful to technicians as the instrument is managed at sea or in other remote locations, where the ION system and the internet are not readily accessible.
# *(At some later time) Platform Technician integrates the storage-enabled instrument into a platform, for example a buoy.*
## This is typically done in the lab prior to platform deployment, but may also be done at sea to replace a faulty instrument.
# *When platform is powered on, compatible ION software (on the CGSN platform, or RSN shore station) automatically detects instrument and its ability to respond to protocol, and obtains stored metadata.*
## This includes determining instrument identity and descriptive metadata.
# *The ION software properly associates ION driver, metadata, and other configuration information with each device.*
## At sea, the driver may be downloaded into the controlling environment.
## With the driver correctly identified and installed, high-level instrument operations can automatically take place.
{metadata}

h3. Final State

{metadata:Final State}
Instrument is installed and operational at minimal cost. There is no doubt about which instrument has been installed.
{metadata}

h2. Comments

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

{metadata:Use Case Comments}
The ION-system-aware application in this use case is likely independent of ION, but able to communicate with ION via APIs.
{metadata}