Communicate directly with instrument via terminal or 3rd-party applications
|Actors||'User' with appropriate role: Integrated Observatory Operator, Marine Asset Operator|
|References||UC.R1.19 Direct Instrument Access|
|Is Used By|
|Is Extended By|
|In Acceptance Scenarios||AS.R2.01A Operate Marine Observatory, AS.R2.02C Instrument Life Cycle Support|
|Primary Service||Instrument Direct Access|
|UC Status||Mapped + Ready|
|UX Exposure||MNC, SYS|
This information summarizes the Use Case functionality.
Request authority/permission for directly controlling the instrument (excluding others from accessing it). Directly communicate with instrument, via windowed interface for ASCII commands, or via a socket for third-party applications. The system keeps a snapshot of instrument state before and after the direct access session, and tracks the session.
- Flexible access to this capability depends on the Integrated Observatory system's capability to enforce access policy; until then, access will be limited to a narrow set of operators. (We do not want just any user to be able to command just any instrument just any time.)
- Direct access to an instrument requires that the instrument is online. Acquiring direct access can occur before the instrument is online and can span a longer period of time.
User who wishes to directly access an instrument has accessed the general overview screen for that instrument.
- User makes request for direct access via the general instrument interface for this instrument.
- A link may also be provided via the observatory management interface, but it should bring up the instrument's interface, to provide that context.
- The user's authorization for direct access is verified
- Policy is applied, evaluating availability of instrument, instrument policy, and role of requester.
- Other criteria may also be considered (expenses, timing, involvement in mutual observations)
- If policy allows, direct access is enabled after the current state of the instrument is saved.
- Subscribers to instrument data stream may be notified.
- Other users and operators are blocked from routine access to instrument.
- While in direct access mode, no other user can be in direct access mode or send commands to the instrument.
- Other active users of instrument are informed about the ongoing direct access and the user who requested it (via messaging events)
- User is provided either RS-232 command or socket-level access to the instrument, as requested.
- If user is running 3rd-party application to talk to instrument, application connection must be bridged into ION.
- RS-232 command means terminal emulator is provided via Integrated Observatory interface or standalone terminal window.
- In later releases, being able to generate commands from scripts in user's computer will be helpful.
- Note: actual direct access to instrument is only possible while the instrument is online, but exclusive direct access mode to an instrument can be requested independent of that.
- User directly communicates with instrument to issue commands, change settings, and/or collect data.
- While this is happening, the Observatory is not capable of commanding scheduled activities to the instrument, and the instrument can't push data.
- Direct access may need to consider possible impacts to routine operations, and grant the access privilege (or set a time-out for it) accordingly.
- Observatory records communications in both directions.
- This recording is not required for the system to operate; it is required for later auditing or diagnostic purposes should that be needed.
- In later releases, the 'Observatory monitors direct access effects on instrument state.'
- This is necessary for the most well-characterized and well-understood interaction with instruments.
- Direct access connection is terminated when appropriate.
- Reasons to terminate direct access could include user requests termination, access privileges time out, time out due to inactivity, an Operator reclaims instrument for observatory, or another (higher-priority) user gets approval for direct access. Observatory policy determines which reasons are valid for termination.
- When possible and appropriate, the state at the end of the direct access session is retrieved and recorded
- If appropriate, instrument agent restores the state of the instrument to that preceding the direct access operation.
- It might not be appropriate to revert if it is too hard or unreliable to do so, or if the direct access session made changes that should not be reverted but would be.
- Interested parties are notified of the change of instrument state and the end of the direct access session.
- Their interest is determined by whether they have subscribed to such notifications.
Direct access has been provided as permitted, user has successfully interacted directly with the instrument, the direct access session has been closed, the instrument has been reverted to its previous state if appropriate, and interested users are notified of the state change.
These comments provide additional context (usually quite technical) for editors of the use case.
Notes from UX/Architecture discussion (2011.07.01):
- The scenarios driving this use case include:
- a user can use 3rd-party software (typically provided by the instrument manufacturer) to interact directly with the instrument
- a user wants to make a custom adjustment to the instrument that can not be supported by our infrastructure
- a user or operator needs to troubleshoot an instrument by interacting directly with it
- a user does not believe our representation of what an instrument is doing, and wants to directly verify that it is behaving as we say it is
Preservation and restoration of state is qualified in this use case. State management can be problematic, as instruments support a really wide range of state awareness and capabilities. Notionally every instrument driver could implement a "getDeviceState" method that retrieves device's notion of its state, using the device's protocol (assuming it exists and supports information to reliably identify and set state). But the driver developer needs to recognize that some changes performed during the session need to survive the session, so invoking getDeviceState on entering and setDeviceState on exiting direct mode is not necessarily a panacea even if possible.