1   Introduction¶

The construction, integration, commissioning and operation of observatories requires a significant amount of knowledge spanning multiple disciplines. However, all operational aspects are performed using some piece of the control software. The range of use-cases span from an engineer performing embedded low-level servo control to enable precise positioning of the mount, to an observer using a simple graphical display to evaluate the current weather conditions.

To account for the large number of use-cases from all levels of users, the control system must simultaneously provide a high degree of flexibility and a user-friendly framework. The top-level functionality specifications that define much of the development of the observatory control system are:

• Regular operations routines should be easily accessible;
• Must include a highly customizable scripting capability must be available and able to run user-written code;
• An interactive mode, equivalent to a user sandbox space, must be available to allow development of routines on the fly as well as debugging;
• Capability to incorporate user-developed features;

In the standard operational model used to perform the survey, the observatory will be largely driven by the Scheduler. The Scheduler designates a target and a specially formatted script containing a series of operations to be performed (such as slewing the telescope and taking an image). The execution of the script is handled by the control system while the user is able to monitor (or interrupt) the progress via a graphical interface. Operators will be much more involved during the start-up and shutdown phases, as well as during afternoon calibrations. In the majority of cases, these routine operations are expected to be executed by the operator from a high-level interface of the observatory control software (as discussed in following sections).

During integration, commissioning, and engineering time, there will be situations where non-standard, customized operations will need to be executed. These operations will often be exercised by subsystem specialists (e.g. M1M3) and require a knowledge base that differs from that of an observing specialist. The breadth of the observatory control system allows users to perform both standard routines and customized tasks via three main interactive components:

• LSST Observing Visualization Environment (LOVE)
• ScriptQueue
• Jupyter notebooks

This document begins with a high-level overview of these three components and explores how users can take advantage of their features to accomplish different types of tasks. Then, we define three main actors, outline their roles, and describe the assumed level of knowledge regarding when performing specific tasks. These actors and roles are used to assist in defining the usability expectations of the components and control system in general as well as the underlying assumptions of the knowledge required for each role. In reality, the people’s roles will be less discrete and there will be significant overlap between these roles. The identified actors are:

1. Observing Specialists
2. Commissioning Scientists
3. Software Developers

Finally, we present concrete examples of interactions that the actors will perform with the Observatory Control System, linking to procedures on how to do them using the multiple components. These examples explore how users best take advantage of the component’s features. They also include cases of how not to use a component due to limitations or inefficiencies in various areas. The examples are also useful in facilitating discussion regarding the ease-of-use of each operation, which is expected to stimulate discussion on how to best improve system usability and/or performance.

2   LOVE¶

The LSST Observatory Visualization Environment is the primary user-facing interface to the control system. LOVE is most often used to display status but it also includes control interfaces for regular operations such as slewing, offsetting or performing a controlled stop. Interaction with the ScriptQueue, as discussed in the following section, is also an important use-case of the LOVE system.

3   Script Queue¶

The ScriptQueue is the main hub for the execution of regular operations and requires a minimum level of interaction by the user. As mentioned in the previous section, it is also used as a back-end for user-commanded actions performed using the LOVE interface. For example, when a user performs a take-image operation using LOVE, the actual action perform by LOVE system will the queueing of a SAL Script that then gets executed by the ScriptQueue. The ScriptQueue is also the main tool observers will rely on to perform regular nighttime operations, such as tracking a target and obtaining a standardized set of observations. The ScriptQueue is flexible in how it handles and executes scripts but generally it runs sequentially. As soon as one script finishes, the next one begins until no scripts remain to be run.

This architecture (or methodology) means the number of different operations that get executed by the scriptQueue will be very large and their complexity varies significantly. For instance, when observing specialists need to prepare the observatory for calibrations or for night operation, they will add a rather complex script to the ScriptQueue that will perform all the required tasks (e.g. position telescope and dome, perform required fine tuning in positioning, open mirror covers and so on). The Scheduler for the survey essentially adds scripts to the scriptQueue after each visit until told by the observer to stop.

As mentioned already, interacting with the ScriptQueue is mainly done through LOVE ScriptQueue user interface. The interface allows users to stop, start and pause the ScriptQueue. It also displays the status of scripts and any errors that occur. Shuffling the order of queued scripts is also possible. Lastly, users can quickly relaunch previously run scripts without having to re-enter any modifications to the default configuration.

Figure 1 A screenshot of the LOVE interface to interact with the ScriptQueue.

The main interaction required when using the scriptQueue is the modification of the occasional configuration. A database of configurations will be available for users to execute the most common set of operations. Users also have the possibility to edit configurations from the user interface, which also provides on-the-fly schema validation.

In general, using the ScriptQueue requires some familiarity with the observatory system and minimal set of software development skills. Users should be able to, after inspecting the LOVE status screens, determine the state of the observatory and its readiness to perform certain types of operations. Other than that, some knowledge about yaml and json schema may be useful for writing and inspecting script configurations, though LOVE will eventually provide features to help understanding and validating them prior to execution.

4   Jupyter notebooks¶

The notebook server available at the summit control network is built on top of the DM science platform, augmented with Telescope and Site observatory control package. Notebooks allow users to combine observatory control activities with data analysis in a highly interactive web-based interface. This includes analysis of data queried from the EFD.

It is important to emphasize that the notebook platform on the control network should be used mainly for activities that require controlling observatory components through the DDS middleware. For pure data analysis activities, users should rely on other nublado instances (e.g. commissioning cluster, NCSA, etc.).

Although extremely powerful and flexible, we do not expect notebooks to be used on all situations. These are the main situations where users are expected to resort to notebooks:

• Executing an integration, commissioning or engineering activity that requires some level of interactivity. For instance, determining the M1 Lookup-table for the Auxiliary Telescope Active Optics System
• Executing a custom sequence of observations that require some level of interactivity, such as what was done to measure the Sensitivity Matrix for the Auxiliary Telescope Active Optics System
• Developing and testing new functionality not currently supported.
• Debugging, testing and/or improving existing functionality.
• Investigating issues with an individual component or a group of components.

In order to take full advantage of Jupyter notebooks users must acquire some familiarity with the observatory control system. These are some basic concepts users should make an effort to be familiar with:

• Commandable SAL Components (CSCs).
• SalObj Python library with special emphasis in the concept of a Remote.
• Some familiarity with the Telescope and Site observatory control package.
• Intermediate Python Skills.
• Familiarity with Python standard asyncio library.
• Some familiarity with multithreading and coroutines.
• Familiarity with git and GitHub.

As mentioned previously, any features developed in a notebook can be added to the production codebase following the procedure found in tstn-010.

5   Expectations on Actor Interactions and Abilities¶

As discussed in the Introduction, different personnel in the observatory will interact with the control system in different ways and levels. Some users will have a broad expanse of interactions, yet shallow in depth, whereas others will have narrow interactions but drill deep into the specific application. It is useful to try to define these roles such that the user-experience and breadth of knowledge required to perform them can be better aligned to tailor the ease-of-use, flexibility, and functionality of the various interfaces.

6   Examples of Various Operational Tasks¶

This section includes various examples of procedures mentioned in the above sections that are associated with various actors. In the case of operational examples, they may include multiple possible procedures to perform the task with the goal of being able to demonstrate to the reader the advantages and disadvantages of each system. For example, in the case of taking an image, this can be done from the scriptQueue via LOVE, by launching a script from a notebook, or just from the command line. However, from the example it is clear that launching a script from a notebook to take a simple image is onerous and not the recommended approach.

Operational Tasks:

• Slewing
• Offsetting
• Taking an Image
• Launching a script and editing the parameters in LOVE
• Execution of a notebook

Commissioning Actor Tasks:

• Writing a SAL Script
• Creating and updating a CSC configuration file
• Creation of a notebook to be used for testing

7   Items to be Addressed in Future Revisions¶

• On-the-fly image interaction

• Communication/coordination with other software systems

  • OCPS? Other tools?
  • Logging?

• Discussion of test-stands and how to use them