The new developments were aimed at refining the existing vague envelope concept into a practical method for decentralized planning. Selected critical functions were exercised by planning an example, founded on experience acquired by the MSCC during the Spacelab missions D1 and D-2. The main activity regarding future mission planning tasks was to improve the existing MSCC mission planning system, using new techniques. An electronic interface was developed to collect all formalized user inputs more effectively, along with an "envelope generator" for generation and manipulation of the resource envelopes. The existing scheduler and its data base were successfully replaced by an artificial intelligence scheduler. This scheduler is not only capable of handling resource envelopes, but also uses a new technology based on neuronal networks. Therefore, it is very well suited to solve the future scheduling problems more efficiently.
This prototype mission planning system was used to gain new practical experience with decentralized mission planning, using the envelope method. In future steps, software tools will be optimized, and all data management planning activities will be embedded into the scheduler.
All payload mission planning activities of the First German Spacelab Mission D1 (30 October to 6 November 1985) and of the Second German Spacelab Mission D-2 (26 April to 6 May 1993) were performed by DLR at MSCC in the function of a (remote) POCC.
For D1 and D-2 a centralized mission planning concept was applied. That means that all payload relevant information and requirements were collected at MSCC, and each timeline version was generated at MSCC exclusively. The user community was involved in the timeline preparation (-data base creation or update-) but not in the timeline development itself. Up to the present, centralized mission planning concepts have normally been used for manned space missions. Many experiences gained during D-2 [1], studies and ideas from NASA [4], upcoming new requirements [3], and some new (technical) capabilities were the drivers for a refined mission planning concept and a partially new system.
Mission planning in the context of this paper consists of developing the plan for all manned and unattended activities on board (e.g. on board Spacelab). The plan is written down in a document which specifies the times for performing the procedures necessary to conduct the attended experiments, and further documents, such as lists and plots of activity steps, resource profiles, and command timelines, which are produced as supplementary information needed by the control center. The plan from which all these documents are derived is called simply the "timeline".
In general, the mission planning consists mainly of three different tasks:
* Collecting and analyzing of information, availabilities and requirements
* Generation of the timeline
* Production of all necessary outputs and documentation.
The second task -timeline generation- is performed in three steps:
* Event generation (=orbit analysis, generation of an attitude timeline, computation of event on/off times)
* Experiment and/or system scheduling
* Data management (=generation of a data flow timeline)
This short description of a mission planning task flow is valid for all payload and system spacecraft operations.
The mission planning team has two main interfaces. On one side is the spacecraft (e.g. the Shuttle including a spacelab) with all its capabilities and availabilities together with the organisations (such as NASA and ESA) which offer this spacecraft and determine the operations concepts in a set of constraints and rules. On the other side are the investigators and their representative organizations (=the user community) with their requirements to perform experiments or other activities. The mission planning team attempts to fulfill the requirements as well as possible, according to the availabilities and regulations.
User Requirements
In order to optimize the scientific return, the users need to do some basic mission planning functions outside the control center:
Instead of providing their inputs in the form of FO sheets (-the generation and update of these FO sheets was very time consuming and was a major source of errors-), the users should provide their experiment requirements and inputs in form of computer files which can be automatically processed. These files should be sent to the mission planning center electronically.
Furthermore, the user community requires a certain flexibility for their own experiment planning. They require a certain degree of freedom to rearrange their experiment runs within given time slots by themselves, instead of being tied to an inflexibly fixed experiment schedule.
In addition to the gain of flexibility and autonomy, another aspect should be mentioned. Some "editing" (=data base entries and updates) and "micro-timelining" (=detailed step by step experiment configuration) tasks are shifted from the control centers to the experiment and procedure experts of the user community.
International Co-operation
Future manned space missions will require more international co-operation. These complex missions will generally require a certain decentralization of mission planning activities. (E.g. ESA requires that all planning activities for the APM system and payload will be performed in Europe, and that different USOCs (in different countries) shall take over some basic mission planning tasks.)
General Operations Aspects
The distribution of mission planning outputs and documentation should be performed electronically. This would reduce the reaction time to get a response from the investigator.
Future manned space missions will last longer than two weeks. The timelines must be developed, generated, and maintained in a shorter time frame than before. (For D-2 [duration 10 days] the timeline generation process lasted up to three weeks, excluding data base preparation but including all documentation.) The Space Station operations concept requires a new timeline for every time increment, and requires the capability of handling mission planning activities for multiple increments simultaneously [3]. In contrast to centrally planned short missions, the upcoming long duration missions require that all detailed experiment knowledge (necessary for mission planning) is located exclusively in the user team, and not at the control center. The number of experiments of such a mission is too high, and/or the turn-around times of the payload (=the number of different experiment facilities) is too short to collect all the mission planning information in detail at a single point. Therefore an electronic interface is necessary, as well as a very fast and sophisticated scheduler.
Most of the software used for mission planning purposes during the D-2 project was placed at DLR's disposal by NASA Marshall Space Flight Center (MSFC). Most of these software tools have been in use for many years and they cannot fulfill the requirements of a modern, user friendly, and sophisticated mission planning concept.
A MSCC-specific problem was that all MSFC software was available as executables only. No software updates, modifications, or changes were possible. For a complex and flexible mission planning system, it is necessary that new or changed software requirements can be implemented as soon as possible. This requires a modular software concept, with all the software code be available at the control center or, -at a minimum- very responsive software maintenance.
Compared to the D-2 mission, the upcoming multi-national space missions will have more exchange of information between the different space agencies on one side, and between the user community and the agencies on the other side. The flight crew will also need added flexibility in the planning and implementation of longer duration operations. Therefore, the era of Space Station payload operations requires a reassessment of traditional modes and methods of conducting payload operations [4]. However, a (new) concept needs not only new methods, but also new hardware and software features, and new technologies.
The Concept for Decentralized Mission Planning
The Envelope Method is able to support all shades of mission operation concepts between a totally centrally organized and planned mission to a mission planned in a completely decentralized process. This proposed mission planning concept does not discuss different mission operations concepts, but proposes a feasible mission planning concept under known constraints.
To begin the discussion of a concept, especially the discussion of the Envelope Method, on a rational and practical level, some general assumptions should be presupposed:
* The concept shall support a reasonable and balanced usage of all available (spacecraft) resources.
* The concept shall lead to a higher degree of flexibility and autonomy for the user community (compared to traditional (=centralized) methods).
* The concept shall allow a flexible reaction on changing or modifying the spacecraft operations concepts.
* The concept shall permit a control center to implement all necessary planning, re-planning, and conflict-solving activities efficiently.
* The main rule of the "envelope game" is: Do not exceed any value of your assigned envelopes!
The Envelope Method
All aspects of a flexible and efficient decentralized mission planning concept can be covered by the so-called "Envelope Method". A decentralized mission planning concept enforces the Envelope Method (and vice versa). Therefore, decentralized mission planning with the envelope method is further abbreviated into "the envelope concept".
The resources which are shared by several users, can be distributed via resource envelopes. Resources include crew time, power, real-time data downlink, etc. A resource envelope is a time-dependent profile that defines the available amount of the resource at a specified time. An envelope should be a greater, contiguous block of a resource. Each user will get several envelopes, one for each resource. A user can plan his activities within his resource envelopes independently from the other users. The block structure of the envelopes prevents an interlocking of the activities of different users. Envelopes are updated only by shifting, increasing, or decreasing the blocks, not by breaking them down into smaller blocks.
(Resource) envelopes are a very well suited means for information exchange between different levels of a hierarchical (mission planning) organisation structure (E.g.: POIC (at MSFC) < => APM-CC (at MSCC) < => Experimenter (at USOC)).
There are not only advantages to the Envelope Concept. The main disadvantage is that the efficiency of the resource usage decreases with the number of different envelopes, and decreases according to the size of the envelopes. The number of envelopes depends, on one hand, on the number of resources, on the other hand, on the number of "L3"-users (see figure 1). The efficiency of a decentrally planned timeline will never reach that of a centrally planned one [2] . In other words, if all sharable resources (such as power, crew time, downlink and uplink etc.) are split up into several resource envelopes for the different users, it is impossible to fully exploit each resource and to fill up each unused gap of a resource. One can gain a high flexibility and autonomy of planning by using the envelopes, but one has to pay for this with a decreasing resource usage. (For more information see "Envelope Concept in detail".)
Figure 1 The MSCC Mission Planning Concept (an example of the APM scenario)
However, a loosely packed timeline is less sensitive to the problems which typically occur during a mission; if an experiment takes longer than expected, there will be less chance of impacting other experiments than in the case where the schedule is tightly packed.
Mission Planning with the Envelope Concept
Figure 1 describes the (Decentralized) Envelope Mission Planning Concept of a three level system by the Space Station-APM scenario from the MSCC point of view:
All users generate and update their mission planning inputs and deliver them in form of requirement profiles to the APM-CC. All inputs are then checked against operational constraints and integrated into the mission planning data base.
At first cut, the APM-CC develops a timeline according to the user requirements and the resource availabilities provided by level 1 (L1, overall mission management or e.g. the POIC) to each member of level 2 (L2, e.g. the APM-CC). (It is assumed that there will be different control centers which are responsible for different modules of the Space Station.) From this timeline, the resource envelopes for level 3 (L3, the users) are generated and transmitted to the users. The users plan their experiments/activities independently from each other within their assigned resource envelopes. Keep in mind that it is not allowed to the users to exeed any envelope value.
The results are new or changed requirements (in form of an updated subtimeline or in form of updated requirements) which are returned to the APM-CC, where all subtimelines (or requirements) are merged into the master timeline (or data base). Each user is responsible for updating his data base input and forwarding it to the APM-CC. For each version of the timeline, several iterations of this process with updated envelopes will be necessary to solve upcoming conflicts between different users.
The APM-CC maintains the mission planning data base, the master timeline, and the resource envelopes, and checks them against operational constraints and for conflicts. All output products are produced at the APM-CC. The co-ordination with the L1 is performed by the APM-CC.
The above mentioned concept describes roughly the pre-mission planning scenario. It could also be used for the re- planning during a mission. However the (iteration) process has only one cycle and the user reaction time and input delivery must be fast enough to support the re-planning.
The Envelope Concept in detail
In general, several variations are possible for distributing resource envelopes:
* Envelopes for all sharable resources: All resources used by several users are distributed as envelopes.
* Envelopes for special sharable resources only: Only a few resources, which are heavily used, are distributed as envelopes. After each iteration, additional resources which turn out to be strongly in demand, and to cause conflicts, can be added to the envelope resources.
* Envelopes for special users only: Only users with activities which block out resources for a relatively long time (block usage) receive resource envelopes. The activities of the other users are planned at the APM-CC.
Having the above mentioned advantages and disadvantages in mind, the second option may be the most appropriate way to establish the envelope concept for mission planning purposes.
An analysis (of D-2) revealed that most of the experiments could be satisfactorily scheduled by providing three resource envelopes to each experiment. These three main resource envelopes may differ from experiment type to experiment type, but they all are members of the overall set of resource envelopes (such as crew time, power, downlink and uplink capabilities, micro-g environment, and other mission dependent resources). Resources which are mandatory for a successful experiment performance are such main resources. (E.g.: For an earth observation experiment the (three) main resources could be power, the earth target observation opportunities and the reprogramming opportunities. For a human physiology experiment the three main resources could be crew time, real-time down link and uplink capability.)
Studies [2,4] demonstrated that with a decentralized envelope concept, nearly 80% of the activity time (compared with a centrally planned timeline) could be achieved. The efficiency may be a little bit higher if there are many more iteration steps of envelope updating.
It is not reasonable to distribute all sharable resources via envelopes. The resulting timeline would have an unacceptably low resource usage. If there are too many different envelopes available, not only the micro-timelining will become very difficult, but also the envelope generation (on the control center side) is very time consuming. However, distributing only a reasonable number of envelopes will unavoidably lead to some violations of operational con-straints.
These assertions need a detailed discussion:
One idea of the Envelope Method is to shift the minor conflict solving concerning some heavily used resources from the control center to the users. But the user is able only to solve conflicts concerning his own experiments and concerning the distributed (main) resource envelopes. Because each resource envelope has the same priority for the user, and if all resources and constraints were distributed as envelopes, the user could get into trouble in the course of his internal experiment redesigning. Why? The competition (within a certain time frame) of some (independent) experiments for different resources forces the control center to create envelopes with variant shapes for each resource. (E.g.: An experiment requires for nearly one hour crew time and power, the resource envelopes for both resources may not be exactly the same.) If this phenomenon is extended to a great number of envelopes, it is possible that an experiment has a very spatious envelope for each single resource, but the intersection of all these resource envelopes forces this experiment into a completely fixed time frame!
It is possible to overcome this pressure of competition between different experiments by avoiding any parallel scheduling as long as possible. But in this case, the overall resource exploitation decreases to an unacceptable value.
The solution is to distribute only the heavily used resources via real envelopes, and to consider all other resources as free, the first approach. If any conflicts concerning these resources arise, the resulting conflict management will be done at the next higher level (e.g. L2).
In the above-mentioned example (of the earth observation experiment and of the human physiology experiment) both experiments have different main resource envelopes, but they could interfere by any other resource usage. The conflict detecting and solving, the rescheduling, and the generation/updating of the resource envelopes will be one of the principle tasks of a control center. (The conflict resolution between level L1 and L2 should be done in a similar manner, depending on the assigned responsibilities.)
The Concept for Distributed Mission Planning
The Envelope Concept requires a fast and uncomplicated, user friendly information exchange between the control center (especially the MSCC for the APM control) and the user community. Decentralized mission planning gives the user the flexibility and autonomy for his own experiment rearrangement. It gives the user the possibility to enter all his (mission planning) relevant data (real experiment requirements or secondary information such as experiment procedures etc.) into specific electronic data bases. Vice versa, the control center is able to electronically distribute all outputs and information to the user community.
The mission planning tasks are performed on dedicated mission planning computers. Any direct access from outside of the control center to these machines is denied, for safety reasons. Therefore, a practical electronic information exchange concept should be based on commonly available networks as the transportation vehicle and on commonly used PC's and software as the aid to enter or to read data. The recent advances in computer technology have made the concept of distributed mission planning feasible, because all the necessary hardware and software is powerful enough, and affordable for everybody, and the network connections are no longer a problem.
The following chapter gives an overview of all modifications and new developments necessary to fulfill the above mentioned requirements and concepts. The functions and a rough module design of the separate parts are presented, but no implementation or software details are mentioned.
The former D-2 mission planning software was mainly NASA-MSFC software. The whole system can be divided into four main software packages all needing DEC computers with VMS as the operating system. (The four software packages correspond essentially to the above mentioned mission planning tasks: Event Generation System (EGS), Experiment Scheduling System (ESS), Data Management System (DMS) and an Interface and Output System consisting of different software modules which are necessary to receive information and to produce and forward the output plots, listings, and documents. See also figure 2)
The Event Generation System (EGS)
The EGS is an autonomous system necessary to prepare event availability profiles for the ESS and DMS. The EGS is not affected by the new requirements, and is not involved in any new concept. Therefore no modifications or updates are mentioned here.
The Requirements Collection System (RCS)
The MSFC software does not support the distributed mission planning as described above. Therefore, a completely new software tool had to be developed. A first trade-off resulted in the decision to use as a basis a commercial relational data base with the possibility of defining graphical user interface applications. Another decision was to implement the RCS on a PC. After a market survey, a commercial relational data base was found to be the most suitable tool. The RCS is a very user-friendly tool, which allows the usage of two variant modes:
* The first mode allows the control center to design a mission dependent questionnaire.
* In the second mode, the user can enter all requirements.
The RCS offers the user window menus and mouse-sensitive fields to answer all questions; naturally it is very easy to change or update the parameters.
The implementation of the RCS could be done in three ways:
* The questionnaire and the resulting (requirements) data base can be distributed via floppy disc
* or via networks
* or the complete RCS is installed at the control center, and each user can login remotely.
These three options are not inevitably exclusive. Up to now, the first two options are possible.
The Experiment Scheduling System (ESS)
The ESS version used for D-2, especially the Experiment Scheduling Program (ESP), (and all later versions available up to now) is not able to support the decentralized mission planning with the envelope method. The main weak points of ESP are that it is not possible to receive, process (compute), or generate detailed profiles (a profile defines the available and/or requested amount of a resource as a step function of time) or resource requirements, which are given as a percentage of the task duration. Additionally, the data base concept is problematic, because it is not user-friendly and its capacity is limited, the handling and the user interface are very uncomfortable, and the scheduling philosophy is too conservative to support scheduling according to the envelope method. (Scheduling according to the envelope method corresponds approximately to using fuzzy logic.)
A scheduling tool assessment identified the Science Planning Interactive Knowledge Environment (SPIKE) as the most suitable and fastest scheduling program [1].
(SPIKE is an Artificial Intelligence scheduler. It was originally designed and developed for scheduling Hubble Space Telescope operations. The development started in 1987, and SPIKE has been operational since 1990. The primary goal (of SPIKE) is to maximize scientific efficiency by optimizing the schedule and minimizing the violation of scheduling constraints. SPIKE has demonstrated its capabilities as a powerful and flexible scheduling framework with applicability to a wide variety of problems in different scientific satellite projects (e.g. EUVE, ASTRO-D).)
(For detailed information about the SPIKE scheduler see [5,6].)
ESP (and the corresponding data base) could not be exchanged easily with SPIKE. In a first step, SPIKE was modified to be used by unexperienced operators. (The former user interface of SPIKE required a detailed knowledge of the programming language LISP.) In a second step, SPIKE was imbedded into the remaining mission planning system. In a third step, SPIKE had to be modified to fulfill all operational aspects, especially with regard to the replanning capabilities [1], and an interface between the RCS and the ESS (mainly SPIKE) had to be established.
The Envelope Manipulation System (EMS)
Similar to the RCS, no EMS was available. The envelope manipulation task has several dependencies. It is influenced by the kind of mission and its payload, and by the mission operations concept as well as by the experiment requirements. Envelope manipulation is done in a separate task after the scheduling process.
Envelope manipulation in detail involves the shifting, increasing, decreasing, smoothing, and gap filling of a single resource profile. It also includes the balancing of resource profiles according to the overall (resource) availability. Therefore, the EMS needs a very comfortable graphical user interface, which allows the operator to flexibly imbed the balancing rules as external subroutines.
Because EMS and ESS interact together very frequently, it is advantageous to install them on the same hardware.
The EMS was developed with the aid of a commercial graphical user interface. The subroutines were developed in "C". Consequently, the EMS is now nearly independent of the hardware and the operating system.
The Data Management System (DMS)
The DMS as used for D-2 is still available. The DMS could not meet the D-2 requirements; they were performed by separate software (especially developed for D-2) or by timeline engineers and DMS operators.
For the moment no actions are completed concerning a new or changed DMS.
Legend: 
Figure 2 The MSCC Mission Planning System (an example of the APM scenario)
The Interface and Output Modules
This tool has only the function of receiving and/or forwarding information (to the next higher level). This information is in detail mission dependent. The single modules are changed or updated by requests only. Therefore, a further discussion of these modules is not necessary in this paper.
Figure 2 summarizes the actual MSCC Mission Planning System and gives an impression of how all these different (sub-) systems act in combination and how they interact with externals. Following figure 1, the Mission Planning Concept and the information flow is reflected.
This mission planning concept and system could not be yet verified in a real mission, but the complete data base of D-2 is still available, and can be used for verifying and tuning the concept and system in detail. The RCS was tested in-house and distributed to some representative experimenters to get a feeling for the acceptance, and to get proposals for changes or improvements. The complete envelope scenario was simulated in-house with the ESS and EMS. The scheduling capabilities, the operator interface, and the performance of SPIKE satisfied almost all of the requirements.
Based on this experience, the existing MSCC mission planning prototype is able to handle the complete envelope concept with all its requirements and consequences.
To bring the mission planning prototype to a fully operational system some additional tasks remain to be done:
One main task is to design a new DMS. Two options are possible: either to develop a complete new and autonomous system, or to implement the missing functions into SPIKE.
The other main task concerns the interface and output modules. All outputs and interfaces are highly dependent on actual missions. Therefore, several output and interface modules have to be changed or to be developed in future.
(The interface for Shuttle missions already exists and will be adapted or upgraded if necessary. Interfaces to the ZUP for EUROMIR missions must be established. Finally all interfaces (e.g. to MSFC and to JSC) necessary for the operation of the APM must be specified and established.)
For further development of operational concepts, mainly concerning mission planning, some outcomes of D-2 and from the prototype testing should be taken into account. The timeline generation premission and the replanning during mission should be reorganized. A premission timeline should cover just the first one or two mission days. The following mission days (or crew shifts) will be planned in near real-time during the preceding day or shift. All necessary inputs for the planning must be available at the beginning of such a planning cycle, of course.
The main advantage of such a concept is that the science community is able to react very quickly to events. The science people are not forced to follow an obsolete preplanned timeline. Also, the overall premission timeline generation task could be easier. It is no longer necessary to create timelines for a whole mission (or great mission increments), only the overall resource budgeting must be managed. It is obvious that all experiment runs which are to be flown on the mission must verified, tested, and trained premission, but the time when they will be performed may be open.
Abbreviations:APM Attached Pressurized Module DEC DIGITAL Equipment Cooperation DMS Data Management System CC Control Center EGS Event Generation System EMS Envelope Manipulation System ESP Experiment Scheduling Program FO Functional Objectives GSOC German Space Operations Center IBM International Business Machines IDL Interactive Data Language JSC Johnson Space Center MSCC Manned Space Laboratories Control Center MSFC Marshall Space Flight Center RCS Requirements Collection System SPIKE Science Planning Interactive Knowledge Environment SSCC Space Station Control Center TL Timeline ZUP Operation Center for Russian Manned Space Flights
[1] "Mission Planning Study Document", E1-OPS-TN-009, M. Wickler (DLR), 1993
[2] "A Test of the Envelope Method for the D-2 Mission with MIPS", D. Dietrich and M. Wickler (DLR), 1991
[3] "Mission Planning Subsystem Specification"; COL-MSCC-DP-SP-005, A. Valentino (SSI), 1993
[4] "Resource Envelope Concepts for Mission Planning", NASA TP 3139, K.Y. Ibrahim and J.D. Weiler (MSFC, USA), 1991
[5] "SPIKE: Intelligent Scheduling of Hubble Space Telescope Observations", M.D. Johnston and G. Miller, in Intelligent Scheduling, ed. M. Fox and M. Zweben, (San Francisco: Morgan-Kaufmann), ISBN 1-55860-260-7, 1994
[6] "An AI Scheduling Environment for the Hubble Space Telescope", J. Sponsler, M.D. Johnston, G. Miller, A. Krueger, M. Lucks and M. Giuliano, "Computing in Aerospace 8", (21-24 Oct 1991, Baltimore), American Institute of Aeronautics and Astronautics, pp. 14-24