Next: A Friendly Command, Control, and Information System for Astronomy
Previous: AIPS++ and the GBT
Table of Contents --- Search --- PS reprint
Kim Gillies, Shane Walker
National Optical Astronomy Observatories, P. O. Box 26732, Tucson, AZ 85726
At the highest level, the software that will be used by Gemini's astronomers must be as flexible as the underlying Gemini hardware. When the telescopes go on-line, the available observing time will be split evenly between classical interactive observing and various planned observing modes.
It is the responsibility of the Observatory Control System (OCS) to provide astronomers and operations staff with a visible user interface that actively supports and enhances the process of observing in all observing modes. The OCS must also provide the software infrastructure that ensures that the system hardware components cooperate to produce science data that matches the requests of the observers.
The Gemini OCS is reaching the end of its design phase. This paper will present an overview of the OCS focusing on the issues and development challenges of the software project. We present and discuss the important parts of the OCS design and show how the design provides an open, flexible, progressive observing environment that is matched to the observing process.
The Observatory Control System is one of the software components being developed for the Gemini Telescopes Project. The role of the OCS in the Gemini software system is to provide the visible user interface for the observers using Gemini and to manage and control the other components of the software system during the observing process. Rather than describing the details of the OCS design, this paper presents a higher level view of the design by focusing on a few unique requirements and showing how those requirements are handled in the design. The history of the Gemini software design process is described in order to show how the requirements were developed. Finally, the current status of the project is summarized.
Early in the design process a number of issues, some non-technical, were noted that had to be dealt with in the system design.
These issues were addressed in a number of ways. Early on, a standard process based on European Space Agency and IEEE software engineering standards (ESA 1991) was selected for the development of all software systems. The standard process defines a minimal number of reviews and documents required for each project. The process also requires that the design be presented using a formal software design methodology.
To capture the needs of users, a number of scenarios and use cases were developed that describe activities and situations the software system must accommodate. These scenarios are used to test the system at each design phase. Scenarios are a good way for non-technical users to make their needs known to developers without getting bogged down in programming details.
A high-level system design, called the prototype design, was developed by the central office. The scenario set was applied to the prototype design as the design was reviewed and refined over several months. The process of developing the prototype helped in several ways.
A number of baseline technology decisions were made to ensure reviewers that an implementation was possible with current, available technology. These technology choices cover both hardware and software. For instance, real-time systems are to be based on VME, Mv167, VxWorks, and a software framework developed by Los Alamos National Laboratories called EPICS (Experimental Physics and Industrial Control System). Workstations will be Sun Solaris-based systems and baseline software includes PV-Wave, IRAF, and the Tk toolkit. The baselines technology decisions can be reevaluated by the developers during the design of their parts of the system.
The prototype system design partitions the run-time software into four principal systems: the Observatory Control System (US, NOAO), the Data Handling System (CA, DAO), the Telescope Control System (UK, RGO, ROE, RAL), and up to four Instrument Control Systems.
The data flows for both science data and control commands and status were known once the prototype design was complete. The final step required to allow parallel development was the creation of a set of Interface Control Documents (ICD). Whenever the software of two groups must interact, that interface is described in an ICD document. These documents describe how the systems communicate. Exactly what commands or what status is passed over an interface can then be determined later in the development process during the detailed design of each principal system. The presentation of that information is also presented in a standard document.
After the prototype design was completed, there were a number of OCS-related requirements. Some requirements could have been guessed without the prototype, but others were discovered during the design process and probably would have been missed without it. The following are the requirements that most shaped the OCS design.
The following sections discuss how the first three items are dealt with in the OCS design.
Several fundamental ideas are at the core of most of the OCS design decisions. Most importantly, the OCS should not do too much. The OCS provides decision support for the users; it should not be an artificial intelligence system. The users of the system are the decision makers.
At this stage of OCS development it is difficult to know everything about how the system will be used; therefore, the OCS does not specify a policy or routine for observing. It does provide an infrastructure that supports the creation of policies that will be determined in the future.
Programming fundamentals are also important. The design supports encapsulation, the view that the OCS should know as little about the other principal systems as possible. The design emphasizes the importance of synchronization and command completion. When a command request is issued by the OCS, the caller will be able to tell when the actions associated with that command have completed. Completion is indicated in a command-independent way by the system that executes the request, not by the OCS.
These days most observatories provide user interfaces for their instruments that allow observers to control hardware and software by direct manipulation of controls on a computer screen. Gemini also supports the classical, interactive observing mode in this way. Observers and system operators use console screens that mimic familiar hardware front panels.
Our approach to supporting the other observing modes builds upon interactive consoles. The contents of a console screen can be viewed as a subsystem configuration. If the configuration is saved, it can be replayed at a later time when the observer or staff member wishes to execute the observation.
The OCS Science Program abstraction is an extension of this idea. Its structure can be described simply. A saved screen or form is an Observation Component. A collection of components is an Observation. A set of related observations is an observer's Science Program. An observer can specify that a group of observations be executed in a certain order by placing them in an Observation Group. An observer can link observations requiring that the observations be executed all at once in a block. A nightly plan is a program created by an on-site observer that can contain observations from many observer Science Programs. It can also contain new observations added by the on-site observer that are shared among all the Observations in the nightly plan.
The structure of a Science Program also has meaning to the staff members who must execute the observations. Observations can be scheduled by the staff in any order. Observations of one observer may be interspersed among the observations of another. Observations in an observation group can be scheduled at any time, but they must be done in the order specified by the observer. Linked observations must be done all at one time. Linked observations in a group must be done in order and all at once. The Science Program is a OCS standard document. The format of the document will be published, and our hope is that others will use the format.
The last step in providing support for the planned observing modes is to create an application, which we call the Observing Tool (OT), that allows users to create, edit, and manipulate Science Program documents. A prototype Observing Tool has been created. One screen shot is shown in Figure 1.
Figure 1: Observing Tool program view.
Figure 1: PS 141 Kb
Figure 1 shows a partially complete observation in the Planetary Nebula Science Program. The program view displays a Science Program's hierarchical structure much like outlines are displayed in popular word processor programs. Items can be collapsed or expanded by clicking on the arrow icons along the left side of the view area. The program hierarchy is shown by the indentation of each item.
NGC40 is an Observation Group that is partially complete. The first observation is completed and has been opened. Inside are shown components for the instrument and the site quality specified by the observer. The other two observations in the group have been scheduled, but not run. Components can be at any level in the program and their scope encompasses all other items at their level or lower; for instance, the NGC40 target description applies to all the observations in the group.
Also shown is a collapsed item called Iterator. Iterators are the dynamic part of an observation. The components describe the base or initial configuration of the system. The iterators operate upon the base configuration to produce the Science Data. A simple iterator is the repeat iterator that causes an observation to be done more than once. More complex examples include mosaic and dither patterns iterators.
Finally, the data acquired during the observation is shown in the opened Obs Data folder. The observer can double click the header or data icons to display the data in a standard image viewing program. The ability to associate data with the program is an important feature of the OT.
The rest of the screen shows the tools observers use to construct and manipulate program contents. On the left are palettes for containers, components, and iterators. They can be dragged from the palettes and dropped into the program where they are needed. Components can be dragged from any OCS console screen and dropped into a program. This can be useful to provide highly specific observation configurations; for instance, an observation with a specific primary mirror setup. The program can be reorganized by interacting directly with the program view icons. It is possible to move, copy, and paste any program structure.
There are many advantages to observing with the Observing Tool.
The concurrent operations requirements focus on the real-time control capabilities of the OCS and are somewhat invisible to most OCS users. In this area, the requirements state that the OCS must allow multiple instruments to work concurrently when needed. One instrument must not interfere with another. In some cases, a single instrument team may have more than one observation executing concurrently.
The OCS model uses an abstraction called a Session to manage these requirements. Each observer or team of observers using an instrument or set of instruments at the telescope is associated with a session. Multiple sessions can be active at the site at any one time. Sessions can include multiple local or remote participants. Associated with any session are a number of resources such as the telescope beam, instrument, or calibration source.
While the observer determines what happens as part of a session, the system operator manages the sessions themselves. The design solution creates an application called the Session Manager to support the operator's job of managing concurrent sessions in the following ways:
Figure 2 shows a very early prototype for the Session Manager application.
Figure 2: Session Manager application.
Figure 2: PS 103 Kb
The Session Manager view shows two sessions, each in a stripchart-like display. Time is increasing to the right. The operator drags resources from the palette on the left and awards resources by dropping them onto sessions. Observation 22 in Session 2 is executing. It has the Port 2 instrument and the telescope resources. Session 1 only has the Port 3 instrument resource. Multiple observations executing concurrently in one session would be stacked up vertically in a session.
To view the contents of an observation the operator selects an observation and selects view. This causes the operator's control consoles to be configured with the contents of that observation. Most Gemini execution policies will probably require the operator to check an observation before the telescope is moved, but this is an execution policy decision and is not required in the design.
The session abstraction and the Session Manager application provide a solution that addresses the OCS concurrency requirements in a way that is consistent with the OCS design principles. The Session Manager provides a tool that assists the system operator, but the decisions are in the hands of the human. The Observing Tool integrates the user's view of the Gemini telescope and provides a single user interface that can be used in all observing modes.
Our experience with the OCS has shown us that analysis and design of a problem is important and useful for both developers and users. Creating user requirements and modeling a system with scenarios and use cases provides an excellent way for developers and astronomers to get together in a non-technical way.
The OCS design passed its Software Design Review in April, 1995, and its Preliminary Design Review in September 1995 (Gillies, Walker, & Wampler 1995). The Observing Tool prototype has been presented at several meetings and has been very favorably received. The next step in the project is the detailed design and implementation of the infrastructure for interactive observing.
Gillies, K., Walker, S., & Wampler, S. 1995, Preliminary Design of the Gemini Observatory Control System