Operator performs sophisticated instrument management activities specialized for instrument models
Leverage the Integrated Observatory policy, planning, and autonomy infrastructure to perform these activities.
Referencing Use Cases
Use cases that reference this use case:
An operator sets up processes, policies, configurations, or mission plans that result in complex instrument or platform behaviors. For examples: (a) an operator creates a process to monitor output from a certain instrument type, generating an event and corresponding alarm when the instrument's measurements become unstable; (b) an operator defines a policy that prevents an instrument from being reset while it is sampling or in direct access mode; (c) an operator defines a mission plan that executes an automated sequence of recovery activities whenever an "instrument instability event" is detected.
- Instruments of a certain model can overheat and fail if stuck in a certain mode.
- Instrument of this model make a humming noise when they sample.
- Define failure detection process: (R2) Operator defines and activates a process that generates an event when a certain temperature from a given instrument model exceeds an operator-defined threshold, and subscribes to the event.
- Configure alarm indication: (R2) Operator configures an alarm to be issued whenever the temperature exception event is detected; the alarm is associated with the instrument generating the temperature exception.
- Define autorecovery mission plan: Operator defines a mission plan that stops operations of an instrument, powers it down, powers it back up, and reinitializes it, and sends a message to the Observatory Operators mailing list.
- Associate event to mission execution: Operator sets up the temperature exception event as the trigger for execution of the mission plan.
- Define status-based access restriction: Operator defines a policy that instruments of model X that are actively sampling, or in direct access mode, may only be reset by Observatory Operator or the autorecovery mission plan.
- Operator tests system: Operator lowers the threshold defined in the first step to create an event.
- Instrument temperature exceeds threshold: The failure detection process detects that the temperature reported by the instrument has exceeded the set threshold, and generates a temperature exception event.
- Operator receives notifications: Operator sees the temperature exception event (via subscription), the temperature exception alarm (in pages for that instrument), the instrument power cycling (in instrument status pages), and an email message indicating the autorecovery plan has executed.
- Define sampling strategy: User sets up instrument to sample every hour with priority medium (only operators can set high priorities), and intervening half-hour intervals with priority low, and activates the sampling schedule.
- Detect mission conflicts: The mission scheduling process detects an acoustic conflict with an acoustic instrument that samples every half-hour at low priority; issues an event with a corresponding warning; and sends email to the users who set the corresponding schedules.
- View warnings on relevant pages: Operator sees the corresponding warnings on the pages of the affected instruments and platforms, but takes no action due to the issue's low operational priority.
- Prioritize missions per priority: On the hour, the system allocates the sampling priority to the new instrument, because it has a higher priority; events are generated accordingly.
- Prioritize missions per role: On the half-hour, the system allocates the sampling priority to the existing acoustic system, because its priority was set by an operator, which trumps the equal priority set by the user; events are generated accordingly.
- Reschedule sampling time: The user modifies the new instrument sampling schedule to be 15 minutes past each half-hour, eliminating the conflicts.