Some device reset use-case scenarios.

Contributed by R.Schramm 16-Apr-2002 Vsn 3

 

The following use cases are intended to illustrate some of the complexities of the storage of instrument metadata in a device called a ‘puck’ which travels with the instrument. This document does not capture all of the possible use cases.  The MOOS system may decide to support some, all or none of these use cases.

 

CASE 1 – Remote site, off-line deployment.

 

A scientist has an instrument that is deployed sub-surface on a mooring far offshore. The instrument relies on power from a solar-charged battery pack on the surface buoy.  The scientist is able to communicate with the instrument via radio modem when they are near the buoy. During a semi-annual research cruise to the region the scientist discovers that due to the biological conditions the instrument needs to be changed from the default settings to collect scientifically meaningful data.  She has also planned to have a diver attach an exciting new sensor she has been developing to a spare analog channel on the instrument. After the changes are made, the scientist is able to verify that the instrument and sensor are collecting great data and the ship departs.

 

Scenario 1a.  Non-writeable puck, retrieve and replace puck in the field.

 

Divers remove the instrument from the mooring line (or possibly must recover the entire mooring) and return it to the ship.  There, they install the new sensor.  Since they planned ahead and brought a “puck-burner”, they are able to create a new puck that has the new instrument settings and also reflects the new sensor’s output. Divers then replace the instrument on the mooring string (or re-deploy the mooring).

 

Scenario 1b.  Field-writeable puck

 

Divers attach new sensor to the instrument in-place. The scientist transmits the necessary commands to adjust instrument settings for the environmental conditions and to output data from the new sensor as well.  The new configuration parameters are stored to the instrument’s puck.

 

Scenario 1c.  Non-writeable puck.  Instrument command persistence is available elsewhere on the platform.

 

There is no capability on-board the ship to create a new puck. The scientist decides to make the necessary changes to the instrument without replacing the puck. Divers attach new sensor to the instrument in-place. The scientist transmits the necessary commands to adjust instrument settings for the environmental conditions and to output data from the new sensor as well. The new configuration parameters are stored somewhere on the platform other than the instrument’s puck.


Scenario 1d  Non-writeable puck.  No instrument command persistence is available on the platform

 

There is no capability on-board the ship to create a new puck. The scientist decides to gamble and make the necessary changes to the instrument without replacing the puck. Divers attach new sensor to the instrument in-place. The scientist transmits the necessary commands to adjust instrument settings for the environmental conditions and to output data from the new sensor as well. The new configuration parameters are running on the system but the will be lost if the instrument ever resets.

 

CASE 2 - Remote site, off-line deployment.   (continue the saga…)

 

 A few weeks later, after an unusual week of fog, the solar-charged batteries, dip below level required to power the platform so it shuts down temporarily.  Finally, after the sun returns, the batteries recover and the system and the instrument power back up. 

 

Scenario 2a. Non-writeable puck, retrieve and replace puck in the field.

 

Since a new and correct puck was created on-board ship and re-installed with the instrument, the instrument’s device driver restores the correct settings.

 

Scenario 2b.  Field-writeable puck

 

Since changes were written to the puck automatically in the field, the instrument device driver restores the correct settings.

 

 

Scenario 2c.  Non-writeable puck.  Command persistence is available elsewhere on the platform…

 

Since changes were written to the platform’s persistent storage in the field, the ISI system reissues commands to the instrument to restore the correct settings.

 

 

Scenario 2d  Non-writeable puck.  No command persistence is available on the platform

 

Since there was no way to store the non-default settings for the instrument they are lost.  The instrument powers-up using it’s default settings.  The system collects five months of degraded or useless data and nothing is collected from the added sensor.


CASE 3 – On-line “All from the user’s desktop”

 

A scientist at WHOI has an instrument that is deployed on a benthic platform anchored offshore. The instrument relies on power from a battery pack which is replaced periodically by an observatory maintenance team.  The scientist is able to communicate with the instrument via the internet. Previously collected data indicate that the instrument’s sensitivity needs to be increased from the default setting to produce meaningful data.  From her desk, the scientist connects to her instrument through the ISI portal and sends the necessary commands.  She then verifies that the instrument is working properly and logs off. Weeks later she departs for a two-month research cruise to Barbados.  While she is away, the MBARI operations team goes out the platform and replaces the battery packs using an ROV. This brief power interruption causes all platform systems and instruments to reset.   The scientist is notified of the reset event but she will not see the message until she returns from the cruise.

 

Scenario 3a.  Non-writeable puck, retrieve and replace puck in the field.

 

To make the new settings persist she would have to organize a cruise to go recover the instrument, replace the puck, and redeploy the instrument on the benthic platform.

 

Scenario 3b.  Field-writeable puck

 

Parameters are stored on the puck as part of the remote update process. The instrument device driver restores the correct settings for the instrument.

 

Scenario 3c.  Non-writeable puck.  Instrument command persistence is available elsewhere on the platform.

 

Parameters are stored on the platform as part of the remote update process. Since changes were written to the platform’s persistent storage in the field. The ISI system re-issues commands to the instrument to restore the correct settings

 

Scenario 3d  Non-writeable puck.  No instrument command persistence is available on the platform

 

Since there was no way to store the non-default settings for the instrument they are lost.  The instrument powers-up using it’s default settings.  The system collects a month or more of degraded or useless data.


CASE 4  - Event triggers a response.

 

 

An experiment is designed to automatically monitor a signal looking for a predefined event to occur.  Once the event is detected, a number instruments are commanded to begin an intense sampling program.  Shortly after detecting the event and commanding the response something causes a system reset.

 

Scenario 4a.  Non-writeable puck,  retrieve and replace puck in the field.

Not applicable.

 

Scenario 4b.  Field-writeable puck

Parameters are stored on the puck as part of the remote update process. The instrument device driver restores the correct settings for the intensive sampling program.

 

Scenario 4c.  Non-writeable puck.  Instrument command persistence is available elsewhere on the platform.

Parameters are stored on the platform as part of the automatic event response. Since changes were written to the platform’s persistent storage in the field. The ISI system re-issues commands to all instruments to restore the correct settings for the intensive sampling program.

 

Scenario 4d  Non-writeable puck.  No instrument command persistence is available on the platform

Since there was no way to store the non-default settings for the instruments they are lost.  The all instruments powers-up using their default settings.  The system collects data as if the event never happened.

 

CASE 5 ( Extension of cases 1c and 3c – explores concept of a non-writeable puck with instrument command persistence is available elsewhere on the platform)

 

Changes to the instrument parameters are stored on the platform (not the puck) as part of the remote update process as described earlier.  Divers visit the platform to perform routine maintenance of the instrument in which they remove it, make some changes (calibrations, new settings etc.). They “burn” a new puck and replace the instrument with it’s puck on the platform.

 

In scenarios 1c and 3c, the ISI system re-issues the old commands to the instrument to restore what it ‘thinks’ are the correct settings.

 

In scenarios 1a,b and 3a,b the ISI system relies on the information in the puck to yield correct operation of the instrument.