R. Swoboda(1), H. Frank(2), D. Garton(1)
1) Computer Anwendung für Management (CAM) GmbH
Rudolf-Diesel-Str. 7a, 82205 Gilching, Germany
Fax: (+49) 8105 24965
E-mail: swobodagsocmail.rm.op.dlr.de
don.gartondlr.de
2) German Space Operations Center, DLR
Oberpfaffenhofen, Germany
Fax: (+49) 8153 282680
E-mail: helmut.frankdlr.de
ABSTRACT. ROSAT is a scientific spacecraft designed to perform the first all-sky survey with a high resolution X-ray telescope and to investigate the X-ray emission of specific celestial objects. The mission can be broadly divided into three main phases: the test and calibration phase, the survey phase and the pointing phase. These three mission phases present very different requirements on a mission planning system. The generation of the mission timelines is performed by a system written at the German Space Operations Center called the ROSAT Mission Timeline Generator (RMTG). It is the main purpose of this article to present an evaluation of the performance of the RMTG and the experience gained from mission planning in general with the ROSAT satellite over the past 6 years. The advantages and disadvantages of the chosen approach will be presented and the article concludes with a discussion of the impacts of the lessons learned on mission planning of other satellites.
ROSAT (see figure 1) is a co-operation between Germany (Bundesministerium für Forschung und Technologie), the USA (NASA) and the UK (Science and Engineering Research Council). Scientific management of the project is at the Max Planck Institut für Extraterrestrische Physik (MPE) at Garching near Munich. The responsibility for satellite operations is at the German Space Operations Center (GSOC) which is a department of DLR in Oberpfaffenhofen near Munich.
There are two main objectives of the mission:
During the survey phase in 1990/1991 around 60,000 new X-ray sources were discovered.
The scientific payload of ROSAT consists of a large X-ray telescope (XRT) sensitive in the energy range of 0.1 KeV to 2.0 KeV and a wide field camera (WFC) sensitive in the energy range of 0.041 KeV to 0.21 KeV. Two different detectors can be put in the focal plane of the XRT. The Position Sensitive Proportional Counter (PSPC) with a resolution of 30 arc seconds and the High Resolution Imager (HRI) with a resolution of 10 arc seconds. The PSPC is equipped with one filter. The WFC is mounted alongside the XRT and points in the same direction. It has a resolution of 1 arc minute. It has several filters which can be inserted into the optical path. Both the XRT and the WFC are equipped with calibration facilities.
Figure 1. The ROSAT Spacecraft.
ROSAT was launched from Cape Canaveral by a Delta II rocket on June 1st 1990 at 21:48 GMT. The orbit is nearly circular with an altitude of 580 km and an inclination of 53.
The prime ground station is at DLR's Weilheim complex south of Munich. Due to the characteristics of the orbit, only 6 to 7 passes of about 8 minutes duration are available each day for receiving telemetry and transmitting commands. Because of the expected high volume of data transfer, both telemetry and commands, these contacts must be carefully planned. Ground stations in NASA's Deep Space Network at Madrid, Goldstone and Canberra are also available as backup in emergency and have been used during various phases of the mission.
The main unit of time for mission planning is the 'ROSAT Day' which is based on the pass cycle for the Weilheim station. A ROSAT day starts at the first ascending node which follows the final Weilheim pass in the cycle of 6 to 7 passes.
The mission has been beset with hardware problems, some of which have had major impacts on mission planning. The two most important were the loss of the Y-gyro in May 1991 and the Z-gyro in November 1993. The effects of these losses on mission planning are discussed below. The failure of one of the main star trackers in 1990 did not affect planning. However, if the second star tracker were to fail, the WFC star trackers would have be used and this would involve changes to the mission planning system.
Use of the PSPC detector had to be discontinued in July 1994 as the gas supply for flushing the instrument was exhausted. Operations continued with the HRI and the WFC.
The mission is divided up as shown in Figure 2. In the first phase, the spacecraft systems and payload were checked out and the instruments calibrated.
The survey phase, which began in July 1990, required the implementation of a law governing the operation of the scan known as the Terminator Referenced Scan Control Law. The timeline generation procedure was automatic and needed no user intervention and no optimisation.
The rest of the mission (apart from a few mini-surveys which were necessary to fill gaps in the all-sky survey) is given over to observations of individual X-ray sources. Each pointing phase lasts 6 months and is preceded by an Announcement of Opportunity in which observation requests from the scientific community are gathered and vetted. The pointing phases, the first of which started in February 1991, present the most demanding requirements on mission planning. Many thousands of requests for observations must be satisfied. These need to be scheduled as efficiently as possible to avoid wasting valuable observing time and produce an optimised timeline. This optimisation must take into account all the constraints placed on the spacecraft and observations and consider other necessary activities such as calibrations and data transmission.
Figure 2. The Mission Timetable.
Due to the various problems encountered with ROSAT, it was found necessary to introduce some smaller pointing phases so that instead of phase 17 the current phase is 20.
Of particular importance in the pointing phases is the manoeuvre to change the spacecraft attitude from pointing at one source to pointing at another. This is known as a 'slew'. Attention must be paid to the length of time required to slew and when it is best performed.
Figure 3. The Context of RMTG.
The ROSAT Mission Timeline Generator (RMTG) provides the master plan of spacecraft operations. It takes as input observation requests and an orbit prediction and ultimately produces a short term timeline (STL). This timeline is supplied to further systems at GSOC for telecommand generation. The attitude control management software produces commands for the Attitude Control System on ROSAT using the timeline and star catalogues. The spacecraft and experiment command generation system produces the experiment commands from the timeline. These two streams are then merged and the commands allocated to passes in the pass cycle and transmitted to ROSAT by the command system (see Figure 3).
The three main operating modes of RMTG reflect the differing requirements of the mission:
Mission planning is a common effort between MPE and GSOC. The primary input to planning is the request which represents a desired spacecraft activity. All requests originate from MPE and are presented in a standardised format.
There are two main types:
The constraints affecting the ROSAT mission are as follows:
The steps needed to generate a timeline are as follows. The requests are received from MPE and validated. New requests may be submitted to correct any errors and the process continues until no more are found. A long term timeline can now be generated and submitted for validation. MPE may wish to change or issue new requests or detector changes in which case the timeline must be regenerated. This process continues until the timeline meets the approval of MPE. At this point the short term timeline can be generated for commanding the spacecraft (see figure 4). This process is discussed in the next section.
Figure 4. Timeline Generation.
The long term timeline (LTL) provides a master, long term plan of spacecraft activities over a period of 6 months. For the pointing phases it is an optimised schedule of the requested observations taking all the constraints into account. The LTL forms the basis for the short term timeline. It can be updated or modified following new or changed requests.
The short term timeline uses a more accurate orbit prediction and covers a period of about 1 week. It is developed in the week prior to commanding and the telecommands are produced directly from it. In the survey phase it is recomputed without reference to the LTL. In the pointing phases, however, the STL is extracted directly from the corresponding LTL by adjusting the observations. No new optimisation is made. The STL also reflects changes to requests made after LTL approval.
It is at STL generation time that the calibration and test requests are inserted into the timeline.
In order to perform the calibrations in the initial mission phases it was necessary to insert specific requests directly into the timeline in a particular order. As there is nothing in the normal requests to indicate when to place them in the timeline and there is no prior knowledge of the blockages preventing the observation, this had to be done in an interactive fashion. An editor was thus developed for this purpose although many thought the effort not worth while as the original phase was very short. Since that time, however, the timeline editor has proved to be a valuable tool in emergency situations where timelines need to be set up by hand. It is particularly useful where special constraints appear that cannot be covered by the main program. The editor has been used on both occasions when the Y- and Z-gyros were lost to generate special timelines. Modifications and the provision of graphical displays have considerably improved the functionality of the program.
In this phase, ROSAT operates in a scanning mode in order to survey the whole sky in 6 months. The solar panels (-x axis) are directed towards the Sun with an offset which must be within the Sun constraint. The satellite rotates about the -x axis once in each orbit. The phasing of the rotation with the orbital motion is fixed in such a way that the telescope axis (z axis) is directed radially away from the Earth at the terminator crossings. Thus, on each orbit, a stripe of the celestial sky is scanned. This stripe is 2 degrees wide for the XRT and 5 degrees for the WFC. Due to the apparent motion of the Sun of about 1 degree per day, the whole celestial sphere will be surveyed in a 6 month period.
RMTG is programmed to generate a survey timeline automatically based on a request from MPE. All the necessary activities are computed and written as entries in the timeline. The program can also process the other types of survey request associated with the survey verification phase and repeating parts of the survey (mini-surveys) which were not performed successfully for one reason or another.
As mentioned previously, RMTG has a slot based approach to scheduling. The typical observation time requested in an observation request is longer than a slot. This means that observations will generally need to be spread over several slots. Because of Earth blockage, it would waste too much observation time to stay on the same target until it was fully observed. The period in a slot is used to observe and the following belt passage can be used to good advantage to slew to another target. As there are generally two belt passages per orbit, this method is a reliable way to schedule the observations. The optimisation method used to schedule the timelines is described in Ref. 1. In practice, it was found that some slots could cover a complete orbit. For this reason long slots are divided up artificially into more manageable sections. A more serious problem with this philosophy arose, however, when the Z-gyro was lost in 1993. As the gyro could no longer be used for attitude control, the on-board attitude control software was modified to use the magnetometer and Sun sensor. This had the implication that all slews had to be performed during orbital day thus making slews no longer dependent on the slot/belt pattern but on the orbital day/night pattern. Extensive changes had to be made to the software to accommodate these new requirements.
The operational philosophy behind LTL production is stepwise generation. Firstly, a basic timeline with no observations is prepared. Secondly the high priority, time critical P1 observations are inserted (see below) and lastly the P2 and P3 observations are scheduled to produce an optimised timeline. If any changes are required it is a simple matter to revert back to a previous timeline and redo the step. In some extreme cases whole new sets of observations have been delivered, resulting in a return to the basic timeline. Experience has shown that up to five iterations are necessary before the timeline is finally approved by MPE. The original requirement that the final timeline should be ready 3 months before the relevant phase starts has been shown to be unrealistic and unnecessary.
The scheduling of P1 requests is of great importance to MPE and much time and effort is applied to ensuring that as many as possible are accommodated in the timeline. The P1 requests are time critical requests of four types:
The original philosophy behind the placing of P1 requests was changed drastically during the course of the mission. The order of processing into the basic timeline corresponds to the list above but can mean that P1s placed first can block later ones thus causing them to fail. As the phase-locked and monitoring requests are intrinsically harder to schedule, and can easily be blocked by co-ordinated requests, the order was changed to fit them in first.
The original order of placing the P1s was based on the order of the requests and not on the time sequence in which they would appear. This meant that the orbit file, which is stored sequentially, had to be continually positioned and rewound. Changing the order of placing to a time sequence method considerably improved the processing time.
P1 requests are placed in any slot where they will fit, without making any attempt to optimise the observing time. It would be possible to change this situation, however, by modifying the way they are placed to increase the efficiency.
If a source is not fully observed when its Sun Constraint Window (SCW) closes then this is known as a scheduling failure. In this case there is a backtracking option available which allows the system to attempt to rectify the situation. In the case of the low priority P3 requests a return is made to the place in the timeline where the request was first scheduled, the request removed from consideration and the process repeated. In the case of the higher priority P2 requests, which cannot so lightly be removed from consideration, extra action is necessary. The method is to go back to the start of the SCW of the source, change some of the scheduling parameters and repeat the process. This process is continued until either the request is scheduled or the scheduling parameters can no longer be changed and the request must be removed from consideration.
This method works in theory and in the current implementation but is in practice unusable due to two considerations. Firstly, there is a heavy oversubscription of observing time in the set of submitted requests by a factor of about 2. Any attempt at scheduling with backtracking would have led to many scheduling failures and thus many backtracks. LTL production would take much too long. Secondly, there is very little freedom to change the scheduling parameters so that after a backtrack the situation would not be very different. Other methods are thus used to avoid scheduling failures or keep them to a minimum and produce an LTL satisfactory to MPE. The main method is to adjust the weightings in the cost function to favour observations which have already begun thus ensuring that they will probably be completed before their SCW closes.
The philosophy adopted for ROSAT is to generate a detailed LTL in which all the requests are put into the timeline at the place where the sources will ultimately be observed. As mentioned previously, the STL is generated by extracting the observations directly from the LTL. This method has the disadvantage that the orbit prediction used for the LTL generation may be very different from that used for the STL generation. The basic premise of the solution to this problem is that, however much the orbit may change, the slot/belt pattern will remain the same, shifting only backwards or forwards in time. In practice, this premise has been shown to be a valid one. The initial worries over serious mismatch problems have proven unfounded. Thus, in generating an STL from an LTL, the absolute time of an observation is not used but instead the slot in which the observation occurs. Even though the difference between the orbit predictions can be up to 2 hours, the method has been shown to work. One of the main drawbacks with this method is that the P1 requests, which tend to be bound to absolute times and not to slots, cannot be guaranteed to fit into the STL. This however, has not been a serious problem.
The replan facilities which were foreseen as requirements on the original RMTG, particularly the provision of timeline edit requests (TER), have turned out to be very useful in practice. TERs are heavily used by MPE to replan STLs.
A very important addition to the system was the timeline verification tool. This is a standalone utility which checks a timeline for a whole range of possible problems. The tool has proved itself to be invaluable in uncovering faults in the original program as well as checking for problems following changes to the software.
The system is implemented on VAX 3200 workstations with 10Mb memory and 19" colour monitors. Prime and backup machines are in use. The long computation times for LTLs and the heavy use of the disks, particularly for storing orbit files, demonstrates that the hardware must be carefully sized before selection. In the case of RMTG the sizing of the hardware was generally satisfactory.
RMTG is written in VAX FORTRAN and runs under VMS 5.x using the Transportable Applications Environment (TAE - originally from NASA) to provide menu and graphic capabilities. The operating system includes a development environment with a code management system. This, together with a good GUI builder has been essential for supporting the mission by not only allowing RMTG to be modified and improved but also allowing further support utilities to be developed. These utilities include the timeline verifier mentioned above, the timeline edit program, several utilities to display the timelines graphically in various forms, slot comparison utilities and several types of print utility.
ROSAT mission planning is performed by the MIPS team consisting of one full-time programmer and one full-time operator. The team maintains close contact with MPE by E-mail and phone at all times. The availability of a full-time programmer with a mathematical/scientific background and fully trained in the system has been essential to the success of the mission. Only with this level of involvement has it been possible to cope with the many problems which have troubled the spacecraft and entailed changes in the mission planning area.
The following conclusions can be drawn from the experience gained in mission planning in the ROSAT mission:
In the authors' opinion it would be possible to adapt RMTG for missions of a similar nature and complexity to ROSAT. This would be simpler and more cost-effective than developing a completely new product.