Figure 1. Principles of a mission-planning system
The mission-planning environment described here is that established for the original baseline Cluster mission. However, the flexibility of its tools and procedures allows it to be easily applied to serve the mission-recovery options currently under investigation following the Ariane-5 launcher failure in June (see ESA Bulletin No. 86, page 99). In particular, the flight of the already approved 'Phoenix' spacecraft (a fifth Cluster), possibly followed by the addition of new spacecraft at a later date, can be handled by making configuration changes and without requiring major modifications to the overall system. The experience gained and the concepts and tools developed for Cluster are also readily adaptable for supporting other future scientific missions.
In the original Cluster baseline mission, the four identical Cluster spacecraft were to be flown in formation in highly elliptical orbits (about 25 000 km perigee, 123 000 km apogee), with an inclination close to 90° and a line of apsides close to the equatorial plane. Two ground stations located in Europe - Redu in Belgium and Odenwald in Germany - were to be dedicated to the Cluster mission, giving each spacecraft an average coverage period of about 25% of the total mission time.
The goal of the mission was to make scientific measurements over at least half of the period spent by the spacecraft above 35 000 km (the typical height below which some instruments have to be switched off due to high radiation levels). Measurements were to be taken in low-bit-rate (normal) and high-bit-rate (burst) modes. Since the available on-board storage could not support long periods in burst mode, careful scientific planning was required to select the best measurement periods and modes. The operations of the entire Cluster payload, consisting of eleven instruments on each of the four spacecraft, also had to be coordinated to achieve the optimum scientific output in the selected regions of the magnetosphere in which measurements were to be collected.
Responsibility for distilling the scientific operations requests for the different instruments into a single, coordinated and agreed input lay with the Science Working Team (SWT), supported by the Joint Science Operations Centre (JSOC), located at the Rutherford Appleton Laboratories (RAL) in Didcot (UK). The subsequent planning of all spacecraft and ground-segment activities based on the SWT's input was the responsibility of the Cluster Mission Planning System (CMPS) at ESOC.
In general, the purpose of a space mission planning system (Fig. 1) is to ensure that the mission operations are scheduled at the Operations Control Centre (OCC) in such a way that the needs of the users are satisfied within the scope, resources and constraints of the mission. The scheduling is based on a plan, normally divided into cyclic planning periods, which is constructed by merging the users' inputs with the mission- specific scheduling rules and constraints. From this plan, a set of command schedules for the spacecraft and the ground stations is then derived.
Figure 1. Principles of a mission-planning system
The inputs to the plan can include the science operations requests, coming from the users; the spacecraft operations requests generated at the OCC, taking into account all other spacecraft and ground-segment routine maintenance operations; the flight-dynamics events (visibility periods, eclipses, etc.); and a set of rules and constraints (profile of the resources, list of incompatible requests, capabilities of the spacecraft and ground segment, data-link capacities, etc.). The planning period can be for the entire mission or just a part of it. For Cluster, a planning period of three orbits, or about seven days, has been chosen for practical reasons, since this allows a one-week periodicity for all planning activities.
The mission planning system uses all of the above inputs to find windows responding to selected criteria (e.g. when sunlight and perigee occur at the same time) in order to identify the different scheduling possibilities for meeting the given plan. It can then propose one or more possible schedules using an automatic scheduler; a simpler alternative is to provide the tools with which to build a schedule manually. The final output is translated into a list of command sequences to be executed by the spacecraft and possibly, as in the case of Cluster, also by the ground stations.
In summary then, the three major steps of the mission-planning activity are to:
In the case of Cluster, the complexity of the mission and the limited resources available for the routine operations phase required the use of a sophisticated planning system for the scheduling of all the science operations of the four spacecraft. In particular, due to the strict interrelations between the various instruments forming the Cluster payload, the science operations called for a high level of coordination between the Principal Investigators well in advance of the actual execution of the operations. In addition, the need to execute identical parallel activities on all four spacecraft, the onboard data-storage constraints, and the limitation of having only two ground stations in the northern hemisphere for data recovery and spacecraft control, made very careful deployment of resources an absolute necessity.
To support the coordination activities, a Joint Science Operations Centre (JSOC) was established, providing support to the Science Working Team (SWT) responsible for all scientific decisions associated with Cluster mission operations. During the mission, the JSOC was to interface on the one side with the SWT, to receive the overall guidelines for the generation of science operations requests, and with the PIs to acquire detailed information on the related instrument operating modes, and on the other side with ESOC, to which it would regularly send a merged set of science operations requests for use by the OCC as input to the mission planning system.
The mission planning activities at ESOC are supported by a number of software tools, centred around the Cluster Mission Planning System (CMPS), designed to handle the analysis of the science operations requests, the merging of those requests with the other spacecraft operations necessary during the routine phase of the mission, and the definition of a unique mission plan. The CMPS would schedule all activities related to the onboard storage of data and its transmission to ground. In particular, it would decide which parts of the actual visibility period over each ground station would be assigned to each of the four spacecraft, trying to select the strategy most likely to satisfy the science operations requests without violating any of the mission constraints.
The final result of these planning activities is a set of control files which would automatically drive the synchronised operations of all four spacecraft and the two ground stations. These files would be transferred to the relevant computer systems at the OCC, which would handle the real-time control and operations.
The mission planning system for Cluster was defined at the end of 1992, about three years before the original launch date. The additional complexity of the Cluster requirements compared with those for previous missions lay in the fact that, given a particular set of science operations requests (which implies a certain data- acquisition profile), there are a large number of possible solutions to the problem of recovering all of the data from all four spacecraft (by using the onboard tape recorders and downloading the data later, by transmitting the data immediately via the direct links, or a combination of the two). Many of them, however, would violate the system constraints.
To optimise the science data flow first from the spacecraft to the control centre and then to the users, a special Cluster Data Resources Analysis Tool (CDRAT) was commissioned. Delays in its subsequent development meant, however, that this approach had to be abandoned. Once the CDRAT did eventually become available, it was used extensively to test and refine the scheduling algorithm that had been implemented in the CMPS in the meantime. The choice had been based on the fundamental assumption that the onboard resources were the limiting factor, rather than the ground resources. This was true until the Cluster spacecraft design was upgraded by replacing the small 1 Gbit tape recorder with two 2.25 Gbit solid-state recorders, which could also be used in sequence. This multiplied the onboard storage capacity of each spacecraft by a factor of 4.5, shifting the limiting resource constraints from the onboard storage to the data-link capacity from the ground stations to the OCC and the processing speed of the computers involved in digesting this enormous amount of data.
The CDRAT tool was also inserted into the planning cycle at the point where the Master Science Plan for one year of operations was to be produced by the SWT, in order to identify data-flow resource conflicts at an early stage.
A final refinement in the system was the generation of a parallel tool which would use the results of the CMPS detailed planning to produce auxiliary information for conducting the real-time operations (so-called SPACON timeline).
The CMPS has therefore become a comprehensive set of tools which work together at different planning levels, from the initial long-term baseline planning to the final operational level in which the detailed commands and instructions are generated.
The control of the four Cluster spacecraft was to be based on the use of a single control centre in conjunction with two ground stations, each of which would normally acquire a pair of spacecraft. Because the spacecraft would fly relatively close together (several hundred to several thousand kilometres apart), their visibility periods from Earth would be almost identical and actual contact time with the station had therefore to be shared. The four spacecraft were to be controlled mainly via time-tagged commands, whilst the stations would be unmanned and remotely controlled from the OCC at ESOC, also via automatic scheduling.
The orbital period of the spacecraft would have been approximately 57 h, with two or three visibility periods lasting 10-20 h. In principle, scientific measurements could take place over any part of the orbit, independently of the actual ground contact time. The onboard recorders would have allowed full coverage of the orbit at low bit rate, or up to 8 h of continuous recording in high-bit-rate mode. Most of the measurements were to have been executed simultaneously by the four spacecraft. This means that the recorders of at least two spacecraft would have had to be used even during ground coverage, while the other two spacecraft downlinked their data directly to the stations in real-time. The contact period with the ground stations would mainly have been used to dump the data stored on the recorders during the long non-coverage periods. This operational approach required a special algorithm (Fig. 2) to allocate the contact time for each spacecraft over the available ground stations, based on the actual use of the onboard recorders, the particular scientific measurements requested, and the overall coverage time available.
Figure 2. Handling of visibility periods by the scheduling
algorithm
The CMPS is a fully automated system that derives and proposes a schedule to the planning engineer. The system gives the latter the ability to influence the results of the scheduling process by modifying the values of configurable parameters and by formulating special operations requests.
Specific tasks that can be handled by the CMPS include: management of on-board power
The most critical element in the CMPS is the algorithm that determines the telemetry and data acquisition mode timeline, from which the management of the on-board data generation and storage, and the definition of the ground contacts and recorder dumping periods are derived. This algorithm has to maximise the scientific return whilst respecting the prevailing operational constraints.
The second major tool developed at ESOC for the Cluster planning activities is the CDRAT, originally conceived as a data-flow simulator for the mission-analysis phase, but now fully integrated into the medium- and long-term mission planning activities.
The CDRAT simulates the data flow from the spacecraft through the ground station up until its arrival at the Operations Control Centre (ESOC). It provides such statistics as the time spent by each data package in the various stages of the flow. The CDRAT also provides the ability to experiment with the parameters of the simulation to determine their impact on the overall system, or to compare different strategies under the same initial conditions (Fig. 3).
Figure 3. Sample outputs from the Cluster Data Flow Analysis tool
Another area in which the CDRAT was used for the Cluster baseline mission was to identify basic rules and guidelines for use by the SWT in defining the initial Master Science Plan, which could already take into account the overall data acquisition constraints and thereby minimise the chances of the related science operations requests being rejected.
The planning environment
The key players in
the Cluster-mission planning process have been the experiment
Principal Investigators (PIs), the JSOC personnel as the
operational arm of the SWT, and the OCC at ESOC (Fig. 4).
Figure 4. The Cluster mission-planning concept
The initiators of the process were to be the PIs, each of these eleven scientists being responsible for one of the instruments carried by each spacecraft. At the same time, they were also to be the final recipients of the mission products from the four satellites. As part of the SWT, which includes all Principal and Co-Investigators for the Cluster mission, a Science Operations Working Group (SOWG) was established, to which all PIs and representatives of JSOC, ESOC and the Project Scientist belong. The SOWG was to meet regularly, every two to three months, being charged with creating the baseline plan for the mission, called the Master Science Plan (MSP). The latter was to lay down the periods of measurement and the main experiment modes for periods of between six and twelve months ahead.
The JSOC would be responsible for collecting the PI's detailed requests for each planning period and merging them into a coordinated input to ESOC. Additional services to be provided by the JSOC to the Cluster PIs and to the science community in general included the provision of orbit information, selected science telemetry monitoring, etc.
The OCC at ESOC was to have overall responsibility for the Cluster mission operations, and therefore played a central role in the mission-planning activities. The feasibility of the Master Science Plan would also be analysed at ESOC before being finally approved by the Project Scientist and released to JSOC as the official baseline mission plan. The mission planners at ESOC, who form part of the Cluster Flight Control Team, would be responsible for merging the science operations requests received from JSOC with the other mission-related operations to form an integrated schedule of space- and ground-segment activities.
As shown in Figure 4, within ESOC the CMPS would be in charge of the mission planning activities and is connected to the CMCS (Cluster Mission Control System), the CDDS (Cluster Data Disposition System), and the FDS (Flight Dynamics System). The CMCS is responsible for both the real-time and off-line processing of the telemetry and for spacecraft control via telecommanding. It receives from the CMPS the Detailed Schedule Files which contain the time-tagged command sequences to be uplinked to the spacecraft, and the schedules to be transferred to the station computers responsible for monitoring and controlling the ground stations. The FDS produces the spacecraft- related orbit and attitude information. Both JSOC and the CMPS at ESOC receive and utilise part of this information. Finally, the CDDS is the interfacing computer system between ESOC and the rest of the world (except for the ground stations, which interface with the CMCS). This system was to have provided the Cluster PIs with near-real-time access to the science data, produce daily a set of CD-ROMs carrying all of the mission data for the Cluster science community, and perform the file exchange between ESOC and JSOC.
As mentioned above, the Cluster-mission planning activities were to be executed on three levels: 'long-term', 'detailed' and 'operational'.
The long-term planning level would deal with the Master Science Plan and cover a period of six to twelve months of the mission. The MSP would be generated by the SOWG, analysed by ESOC using the CDRAT to check its feasibility against the overall mission constraints, and refined by the SOWG to include the details of the instrument modes required in all the data- acquisition periods identified. The MSP would then be finally approved by the Project Scientist and sent to JSOC to form the basis for the detailed planning cycle.
The detailed planning level was to be based on a planning period of three orbits and work on a weekly cycle, starting ten weeks before the start of the planning period, with the PIs providing detailed inputs to the JSOC. The JSOC/ESOC interface was to be active at this level, starting about six weeks before the start of the planning period. It involved the transfer of planning information files in both directions between the two centres. Files passed from JSOC to ESOC were to include so-called 'Observation Request Files', containing the operations required for the correct functioning of the payload instruments, primarily during science data acquisition periods but also related to instrument safety operations, e.g. during perigee passes. The Observation Requests would be constructed by JSOC taking into account the finalised MSP and the refinement or modification requests received from the individual PIs.
The detailed planning was to be an iterative process with information originating from the scientists being passed to JSOC and then on to ESOC. Any problems arising would be highlighted and sent back electronically to JSOC for action, with the possible need for further dialogue with the scientists. This cycle was to be repeated until a viable plan of operations was arrived at.
The final stage of the planning activities would be at the operational level, where the consolidated plans are translated on a daily basis into actual operations schedules and implemented by the spacecraft-control personnel. It is here that the CMPS was to be used to generate the detailed schedules for both the spacecraft and the ground stations.
The planning of the routine phases of the Cluster mission probably represents one of the most complex mission-planning problems that ESA has faced up to now. The handling of the simultaneous operation of 44 scientific instruments aboard four different spacecraft via two ground stations, all having to operate synchronously, required the careful definition and design of several levels of planning cycle and the tools needed to support them. Although the original Cluster baseline mission has been lost, the pre-mission testing phase had already successfully demonstrated the feasibility of the concept and the operability of the tools. These are now available for other future scientific missions, as well as for 'Phoenix' and, hopefully, its new sister spacecraft.
ESA Bulletin Nr. 87.