Next: An Automated System for Receiving KPNO Proposals by Electronic Mail
Previous: Development and Deployment of a Rule-Based Expert System for Autonomous Satellite Monitoring
Table of Contents --- Search ---
PS reprint
D. J. Asson, A. Bose, A. Krueger
Space Telescope Science Institute, 3700 San Martin Drive,
Baltimore, MD 21218
The PED system was developed in order to provide an interactive tool for investigators to create their detailed observing programs. It is essentially a graphical interface built around the syntax checker portion of the Remote Proposal Submission system, version 2 (RPS2). The syntax checker, called the Preprocessor (PP), is used to error check an observing program and generate information for downstream processing systems (namely: feasibility and schedulability analysis tools). The PP is essentially used as a pipeline tool, i.e., it did not provide interactive feedback. It ingests a program and then outputs various description and diagnostic report files. The PP was extended to allow it to incrementally build and error check an observing program. It also can output the newly created program in the original syntax (called an RPS2 file).
In addition to the modifications to the PP, two new systems were designed and built. The Constraint Manager was designed to provide a declarative constraint mechanism to encode legal and illegal values and combinations of program artifacts. This is incorporated into the PP so that the same types of error checking would be available both in PED and in RPS2.
The graphical interface for PED was also designed and implemented. It interfaces directly with the PP data representation of a program. A program is represented hierarchically via a set of windows. All the traditional user interface trimmings are used in PED (e.g., selection boxes, menus, text entry areas, etc.).
When the PED project was started, the PP had already been developed and was in operational use. The PP is written in the scripting language Tcl/Tk. It uses several extensions to the basic Tcl/Tk language, namely:
Since Tcl/Tk is an extensible language, i.e., new features can be written in C and linked into the Tcl/Tk image, we felt that we left ourselves a great deal of room for growth. Whatever turned out to be too slow or inefficient in the interpreted Tcl/Tk environment could be offloaded into C and made available via a well-defined interface provided by Tcl/Tk. Another good reason for choosing and staying with Tcl/Tk is that it has been ported to a variety of systems, primarily UNIX boxes. However, Sun Microsystems is directly supporting an effort to provide robust ports of Tcl/Tk to PCs and Macintoshes. Thus, our code can run wherever Tcl/Tk has been ported.
The source code is approximately 45,000 lines of code, with 23,000, 5,100, and 18,000 lines of code in the PP, constraint manager, and the GUI code, respectively.
As stated above, the parsing and representation is done by the PP. The observing program is read in by the PP and carved up into many objects. Each object represents some portion of the program, e.g., fixed targets, target positions, the right ascension of a target, exposures, special requirements, dates, etc. In order to incorporate PED into the existing PP architecture, all that had to be done was to write additional methods on these various objects, e.g.:
The constraint manager uses a declarative syntax to encode legal and illegal syntax for an observing program. This includes both valid values for individual items (e.g., valid configurations, operating modes, etc.) as well as combinations of items (e.g., which apertures are valid with a specific instrument and configuration). This declarative method allows changes to be made to what the system allows and disallows without changing any source code. With an instrument as complex as HST, it is necessary to be able to change valid combinations without much hassle. For example, if a particular filter is unavailable or one of the operating modes is not available, it can be removed from the definitions. Even more importantly, as new instruments are added to HST (1997 servicing mission will add 2 new instruments), it is important that PED be able to be quickly updated to accommodate them. As far as editing a proposal, as long as the new instrument and its operating modes are defined in the declarative tables, PED can understand them.
Another use of the constraint manager is to provide reasons for why something is illegal or invalid. Instead of saying ``No, you cannot do that,'' the constraint manager provides reasons and explanations as to why something is illegal. For example, certain instruments use filters on the light coming into them. They are often arranged as a set of wheels next to each other, with each wheel containing several filters. You cannot select 2 filters on the same wheel, and PED explains that.
The constraint manager provides two operating modes: pro-active and reactive. In the pro-active mode, it takes the information that is currently defined in the object (e.g., instrument and configuration), and generates lists of valid values for the incomplete entries (e.g., operating mode, filters, special requirements, etc.). It also provides a list of invalid values with explanations of why they are invalid. In the reactive mode, the constraint manager provides only the invalid values and explanations.
The user interface consists of Tk widgets encased in [incr Tcl] objects. This allows complex widgets to be built from simple widgets by using the inheritance properties provided by [incr Tcl]. This is very useful when updating and changing software, since often you need to change only the base class definition and it propagates throughout the whole class hierarchy.
There is a close mapping between the graphical widgets and the objects that they are representing. We think of the graphical view of the object as a presentation of the data stored in the PP object. This way, we avoid duplicating data and function in the graphical objects. All this is handled by the PP object which passes information to the graphical object to represent.
In order to accommodate the declarative constraint mechanism described above, a class of widgets exists that can be constructed on the fly. The widget constructs itself based on a simple specification language that is encoded in the constraint manager's tables. This is currently used only for special requirements, but it can be extended to other areas as well. The specification language includes items such as scroll boxes, check buttons, values associated with selections, default values, etc.
Another benefit of the GUI objects is that several of them can be used in other, non-PED applications, e.g., a date widget exists that allows entry of date and time and understands when leap years are, etc. It is an [incr Tcl] class and thus can be inherited by other applications which require a date display object. This can provide consistency across our applications as well as that almost ephemeral quality of code reuse.
PED is currently being used internally at STScI and is being distributed for the Cycle 6 observing cycle. Investigators who have been awarded Cycle 6 HST time will be able to use PED (and RPS2) starting in January 1996.
As for future work, there are three main tasks to be done:
Finally, in a more bold vein, we would like to make PED available to other observatories for their program preparation needs. Standards in preparation software are useful since observers need only learn one or a few systems in order to use a wide variety of observing platforms. However, standards designed by committees are often disregarded because too much has been compromised away. Instead, a useful approach is to make one group's software available to others and then customize it for the specific observing platform. Since parts of PED (and most of RPS2) are declarative, customizing it for different preparation systems should not be that difficult. If you are interested in pursuing this, please contact Glenn Miller (miller@stsci.edu) or Drew J. Asson (asson@stsci.edu) for more information. For information on the RPS2 system, and in particular its control system, see the RPS2 paper referenced below.
Ousterhout, J. K. 1994, Tcl and the Tk Toolkit, (New York: Addison-Wesley)