The Scientific Uplink System for SIRTF, a Design Study

The Space Infrared Telescope Facility ( SIRTF) is one of NASA's Great Observatory missions, scheduled for launch in 2001. As such its ground segment design is driven by the requirement to provide strong support for the entire astronomical community in the form of Guaranteed Time, Legacy Program and Open Time Observers.

In this contribution we present the current status of the software design of the Scientific Uplink Software for SIRTF. The astronomical observing modes of the scientific instruments on board of SIRTF are captured in the form of Astronomical Observation Templates, which will be deployed to the community as Java based WWW applications. In addition web-based tools will be provided to the observers in order to support the preparation of their mid- and far-infrared observations. These tools will allow the observer to estimate observing times, sensitivities and expected data volumes by making calls to the Interpreter and Resource Estimator Subsystem. At a later stage the same software will be used to derive the detailed command sequences needed by the SIRTF instruments to execute a given observation. All information is captured in the central Science Operations Database, which will support the entire SIRTF science operations. The fundamental need to support a large astronomical community lead to an object oriented Java and WWW based design approach for this entire up-link software system.

1. Observing with SIRTF

1.1 Instrumentation

The Space InfraRed Telescope Facility SIRTF, (Fanson et al. 1998), is the fourth and final element in NASA's family of ``Great Observatories.'' It consists of a 0.85m telescope and three cryogenically-cooled science instruments.

IRAC (Fazio et al. 1998a, 1998b) is a four-channel camera that provides simultaneous 5 $\farcm$ 12 x 5 $\farcm$ 12 images at 3.6, 4.5, 5.8, and 8 $\mu$ m. The pixel size is 1 $\farcs$ 2 in all bands. All four detector arrays in the camera are 256 x 256 pixels in size, with the two short wavelength channels using In:Sb and the two longer wavelength channels using Si:As IBC detectors. The IRAC point-source sensitivity requirements (5 $\sigma$ , 200s) at 3.6, 4.5, 5.8, and 8.0 $\mu$ m are 6, 7, 36, and 54 $\mu$ Jy, respectively.

IRS (Roellig et al. 1998) will provide SIRTF with low and moderate-spectral resolution spectroscopic capabilities from 4-40 $\mu$ m. The IRS is composed of four separate modules, with two of the modules providing R $\approx$ 50 spectral resolution over 4-40 $\mu$ m and two modules providing R $\approx$ 600 spectral resolution over 10-37 $\mu$ m.

The MIPS (Heim et al. 1998; Rieke et al. 1998) instrument will be comprised of three detector arrays and attendant optics and calibrators. The arrays are a 128 x 128 arsenic-doped silicon for imaging at a wavelength of 24 µm, a 32 x 32 gallium-doped germanium at 70 $\mu$ m, and a 2 x 20 stressed Ge:Ga array at 160 $\mu$ m. The 32 x 32 array also takes very low-resolution spectra from 50-100 $\mu$ m.

1.2 Astronomical Observing Templates

The science capabilities of the SIRTF instruments are represented by seven ``observing modes'' or Astronomical Observation Templates (AOTs). The AOT is a central design concept to SIRTF Science Operations. Observers design experiments by selecting an AOT and choosing its parameters. They fill out WWW-based forms and submit ``Astronomical Observation Requests'' (or AORs). The completed AORs are deposited into the SIRTF Science Operations Database (SODB). Specially designed software expands each AOR into activities and an uplink sequence for transmission to the spacecraft. AORs are the basic building blocks for observatory scheduling, pipeline data processing and science archiving.

From an observer's viewpoint, the AOT ``Front End'' is the electronic form filled out to define an experiment to be executed by SIRTF. An Astronomical Observation Request (AOR) is the result of filling out an AOT form. AORs are the fundamental scheduling unit for the SIRTF Observatory, they can be thought of as a list of parameters that completely describe an observation. In the proposal containing a set of AORs the observers can influence the scheduling process by providing information about the timing and relationship of the individual observations. In this way the observatory can be asked to perform observations as a block at a specific time or in a specific order. There is generally no need for observers to modify AORs after submission with the observing proposal. Modification of AORs can be made, however, if it is required by recommendations of the Time Allocation Committees or because of changes in Observatory performance, i.e., SIRTF will have a single phase proposal submission process.

For repetitive engineering or calibration functions the SIRTF uplink software will provide IETs and IERs, which are the Instrument Engineering analogs of AOTs and AORs.

2. SIRTF Uplink Software

2.1 Design Drivers

Data Volume: It is estimated, that the SIRTF Science Center will solicit, evaluate and select from $\approx$ 1200 proposals per proposal cycle. It will have to support observation planning and modification for $\approx$ 400 of these proposals per cycle and thus prepare $\approx$ 20000 observations per year, including special calibration and engineering activities.

User Community: The SIRTF Science Center must be able to support the entire astronomical community, providing tools for fast and easy preparation of scientific proposals and tracking of AORs.

Easy and Fast Software Maintenance: The software shall allow quick adaptation to changing instrument performance or operating conditions. It is the goal to achieve a turn-around time of less than 4 weeks for the software life cycle and to be able to react to emergencies within one week during the actual SIRTF operations.

Independence from Commercial Supplier: The Database design shall allow to easily change the supplier of the underlying Data-Base-Management System (DBMS) to be able to adapt to the evolving software market in order minimize risk and cost of ownership.

Software Re-Use: The software shall be designed in such a way that major portions can be re-used for future missions and legacy code from previous NASA missions can be incorporated.

Resources and SIRTF Autonomy: The software must be able to estimate resources like Execution Times/Uplink- and Down-link Data Volumes with sufficient accuracy to support the planning of the satellite and Deep Space Network (DSN) operations. This is important as it is planned to routinely have contact with the spacecraft only once a day for $\approx$ 30min and to uplink command sequences approximately once a week.

2.2 Design Overview and Guidelines

**Figure 1:** Overview of the SIRTF Uplink Software Design
$\begin{figure} \plotone{heinrichsenih1.eps} \end{figure}$

The high level requirements outlined above lead to a set of design guidelines for the SIRTF Uplink Software System. The User Interface needed to be deployed via the WWW in order to reach the entire astronomical community, while avoiding the distribution of software packages and their maintenance. Examples of the prototype AOTs are reachable through the SIRTF WWW site at IPAC. In the future tools (Science User Tools (SUT) will be made available in the same way to access the vital infrared background information to support proposal preparations. It is the idea to facilitate the complete proposal handling and management through the same technology.

As a consequence the use of a single object oriented language (Java) for entire SSC Uplink System was recommended. This will facilitate software re-use, while simplifying maintenance and accelerating turn-around times. This also allows for platform independent development. Legacy code written in other languages will be handled via Java wrapper routines, which are invoked on a local server via RMI. It is planned to support the object oriented software development process through Graphical Software Design Tools, e.g., Rational Rose. Rapid prototyping will allow the early involvement of users into the design process.

The external interfaces of the SIRTF Uplink Software will be handled through CORBA. These interfaces comprise, e.g., large software systems developed by JPL to support mission planning. The de-coupling of the underlying commercial DBMS System from the applications is achieved via a middle-ware layer supporting the JDBC Interface Routines, comprising the SODB.

This entire concept should allow as far as possible the re-use for future missions by separating the instrument specific models from generic parts as like the expansion engine (AIRE) used to generate the command sequences for a given observation. An overview of the results of these design considerations can be seen in Fig. 1.

References

Fanson, J., Fazio, G. G., Houck, J. R., Rieke, G. H., Tenerelli, D. J., & Whitten, M. 1998, in SPIE Proc., Vol. 3356, Space Telescopes and Instruments V, ed. P. Y. Bely & J. B. Breckinridge (Bellingham: SPIE), 478

Fazio G. G., et al. 1998a, in SPIE Proc., Vol. 3354, Infrared Astronomical Instrumentation, ed. A. M. Fowler (Bellingham: SPIE), 1024

Fazio G. G., et al. 1998b, in Proc. of Astrophysics with Infrared Surveys: A Prelude to SIRTF, ed. M. Bicay, R. M. Cutri, & B. F. Madore (San Francisco: ASP), in press

Heim, G. B., et al. 1998, in SPIE Proc., Vol. 3356, Space Telescopes and Instruments V, ed. P. Y. Bely & J. B. Breckinridge (Bellingham: SPIE), 985

Roellig T. L., Rakowski, A., Taudien, G. E., Huisjen, M., Bolton, M., Seib, D. H. 1998, in SPIE Proc., Vol. 3354, Infrared Astronomical Instrumentation, ed. A. M. Fowler (Bellingham: SPIE), 1192