Use standard protocol to retrieve instrument ID/metadata from device itself. Not available in Release 2.
|Actors||Instrument Technician, Observatory Operator|
|References||PUCK white paper|
|Is Used By|
|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.|
|Primary Service||Instrument Activation Services|
This information summarizes the Use Case functionality.
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.
- 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.
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.
- 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.
Instrument is installed and operational at minimal cost. There is no doubt about which instrument has been installed.
These comments provide additional context (usually quite technical) for editors of the use case.
The ION-system-aware application in this use case is likely independent of ION, but able to communicate with ION via APIs.