A marine operator monitors an instrument
|Actors||Instrument Operator (Marine Asset Operator)|
|Is Used By||UC.R2.10 Manage Marine Platform|
|Extends||UC.R2.40 Monitor ION Resources|
|Is Extended By|
|In Acceptance Scenarios||AS.R2.01A Operate Marine Observatory, AS.R2.02A Cruise Support, AS.R2.02C Instrument Life Cycle Support|
|Technical Notes||This is an operator use case. It may be augmented by automated systems, but the focus is on operator activities.|
|Primary Service||Instrument Management Services|
|UC Status||Mapped + Ready|
|UX Exposure||EUC, MNC|
This information summarizes the Use Case functionality.
Instrument Operator monitors the status and state of health of an instrument, optionally including data monitoring. Operator gets notifications in case of error or preregistered conditions.
- In Release 2, only a few error conditions are rolled up into stoplight views. Refinement of error monitoring occurs in Release 3.
- This use case addresses passive monitoring capabilities only. The ability to command an instrument to obtain information about it is included in the instrument command use cases.
- There is essentially no latency in the Integrated Observatory system for notifications (latencies are less than human response times).
Instrument has been commissioned and is in use on observatory.
- Instrument Operator configures default method for notifications.
- A default method is used for any notification that does not have a different method specified.
- Notifications to be supported in Release 2 may include email, IM message, text message to phone, and on-screen visual display.
- On-screen visual display should bring up an always-visible-until-acknowledged window.
- In Release 2, message types are info, warn, and alarm.
- In Release 2, message display states may be unacknowledged, acknowledged, blanked, and ignored. Acknowledged messages are de-highlighted until next fresh recurrence; blanked messages are removed until next fresh occurrence; ignored messages are never notified. Next fresh occurrence is defined as the next time an issue is notified after it is not notified (i.e., it goes away and then returns).
- Instrument Operator subscribes to and receives notification when instrument telemetry age exceeds expected value
- Expected telemetry age can be computed from instrument sampling schedule and platform telemetry schedule (e.g. satellite connection schedule)
- Excess telemetry age indicates problems with instrument and/or telemetry system
- In Release 2, telemetry age computation may bet set up manually (but better if part of agent software).
- Instrument Operator subscribes to and receives email alert when new sampling errors occur
- A sampling error is a failed attempt by driver to retrieve a valid sample.
- Instrument Operator views web page that summarizes instrument history
- Example contents are telemetry age trend, sampling error rate trend, and error message history.
- Telemetry age is plotted as a function of time – positive slope indicates loss of telemetry (see example below).
- Sampling error rate equals number of sampling errors divided by total number of samples in time period. Values for day, hour, and 'last 3 samples' are useful.
- Instrument Operator subscribes to and receives notification when instrument life cycle state changes to or from a specified value or set of values.
- This includes setting up the monitoring constraint in an interactive way (may be scripted rather than via a UI).
- <3> Instrument Operator compares the current instrument activity to its historical activity.
- Data volume, power duty cycle, frequency of ION interaction are some examples of interesting activity.
- This requires the ability to view these in a visual way over time, e.g., via quick-look plots.
- Instrument Operator views data and engineering values over time.
- This requires quick-look plots of any numerical or flag values produced by the instrument, as well as any computed state-of-health indicators.
- Instrument Operator views logs for instrument interaction (data, command messages), communication/protocol events, and instrument annotations.
- Data and command logs should be viewable as packet headers only, or in ASCII or binary dump formats. The packet contents is presented as it is believed the instrument sees it. (Headers include timestamp and header metadata, including buffer size.)
- Communication/protocol events (produced by the driver/agent for the instrument) should be viewable as summary or complete event message.
- Instrument annotations include any annotations made about the instrument resource, including instrument events (things that happened to the instrument, as opposed to communication/protocol events).
Instrument operator is satisfied that the instrument's condition is well understood.
These comments provide additional context (usually quite technical) for editors of the use case.