ALBERT

Description: NASA's Experiment Scheduling Program (ESP), which has been used for approximately 12 Spacelab missions, is being enhanced with the addition of a Graphical Timeline Editor. The GTE Clipboard, as it is called, was developed to demonstrate new technology which will lead the development of International Space Station Alpha's Payload Planning System and support the remaining Spacelab missions. ESP's GTE Clipboard is developed in C using MIT's X Windows System X11R5 and follows OSF/Motif Style Guide Revision 1.2.

Description: In recent years a variety of space-activity schedulers have been developed within the aerospace community. Space-activity schedulers are characterized by their need to handle large numbers of activities which are time-window constrained and make high demands on many scarce resources, but are minimally constrained by predecessor/successor requirements or critical paths. Two needs to exchange data between these schedulers have materialized. First, there is significant interest in comparing and evaluating the different scheduling engines to ensure that the best technology is applied to each scheduling endeavor. Second, there is a developing requirement to divide a single scheduling task among different sites, each using a different scheduler. In fact, the scheduling task for International Space Station Alpha (ISSA) will be distributed among NASA centers and among the international partners. The format used to interchange scheduling data for ISSA will likely use a growth version of the format discussed in this paper. The model interchange format (or MIF, pronounced as one syllable) discussed in this paper is a robust solution to the need to interchange scheduling requirements for space activities. It is highly extensible, human-readable, and can be generated or edited with common text editors. It also serves well the need to support a 'benchmark' data case which can be delivered on any computer platform.

Description: The Experiment Scheduling Program (ESP) is the heart of a group of programs developed at NASA-Marshall to schedule the experiment activities of Spacelab and other Shuttle missions. Other programs in the group either prepare input data for ESP or produce derivative information based on the schedule produced by ESP. The task of experiment scheduling can be simply stated as positioning the experiment activities in a mission to that they collect their desired data without interfering with other activities. The program's capabilities as seen by the user are described along with mission constraints the program handles, and how the expert system in the program handles these constraints.

Description: The Mission Analysis Division of the Systems Analysis and Integration Laboratory at the Marshall Space Flight Center is developing a system of programs to handle all aspects of scheduling payload operations for Space Station. The Expert Scheduling Program (ESP2) is the heart of this system. The task of payload operations scheduling can be simply stated as positioning the payload activities in a mission so that they collect their desired data without interfering with other activities or violating mission constraints. ESP2 is an advanced version of the Experiment Scheduling Program (ESP) which was developed by the Mission Integration Branch beginning in 1979 to schedule Spacelab payload activities. The automatic scheduler in ESP2 is an expert system that embodies the rules that expert planners would use to schedule payload operations by hand. This scheduler uses depth-first searching, backtracking, and forward chaining techniques to place an activity so that constraints (such as crew, resources, and orbit opportunities) are not violated. It has an explanation facility to show why an activity was or was not scheduled at a certain time. The ESP2 user can also place the activities in the schedule manually. The program offers graphical assistance to the user and will advise when constraints are being violated. ESP2 also has an option to identify conflict introduced into an existing schedule by changes to payload requirements, mission constraints, and orbit opportunities.

Description: The Mission Analysis Division of the Systems Analysis and Integration Laboratory at the Marshall Space Flight Center has developed a robust automatic scheduler which can produce detailed schedules for the multi-step activities required for payload operations on the Space Station. This scheduler, a part of the Expert Scheduling Program (ESP2), has five components: the bookkeeper, checker, loader, selector, and explainer. The bookkeeper maintains the usage profiles for nondepletable resources, consumables, equipment, crew, and the times of all the steps for the payload activities for several different schedules simultaneously. The checker searches the data maintained by the bookkeeper and finds times when the constraints of each step of an activity are satisfied. The loader is an expert system that uses the techniques of forward chaining, depth-first searching, and backtracking to manage the workings of the checker so that activities are placed in the schedule without violating constraints (such as crew, resources, and orbit opportunities). The checker searches the data maintained by the bookkeeper and finds times when the constraints of each step of an activity are satisfied. The loader is an expert system which uses the techniques of forward chaining, depth-first searching, and backtracking to manage the workings of the checker so that activities are placed in the schedule without violating the constraints. The selector has several methods of choosing the next activity for the loader to schedule. The explainer shows the user why an activity was or was not scheduled at a certain time; it offers a unique graphical explanation of how the expert system (the loader) works.

Description: For all past and current human space missions, the final scheduling of tasks to be done in space has been devoid of crew control, flexibility, and insight. Ground controllers, with minimal input from the crew, schedule the tasks and uplink the timeline to the crew or uplink the command sequences to the hardware. Prior to the International Space Station (ISS), the crew could make requests about tomorrow s timeline, they could omit a task, or they could request that something in the timeline be delayed. This lack of control over one's own schedule has had negative consequences. There is anecdotal consensus among astronauts that control over their own schedules will mitigate the stresses of long duration missions. On ISS, a modicum of crew control is provided by the job jar. Ground controllers prepare a task list (a.k.a. "job jar") of non-conflicting tasks from which jobs can be chosen by the in space crew. Because there is little free time and few interesting non-conflicting activities, the task-list approach provides little relief from the tedium of being micro-managed by the timeline. Scheduling for space missions is a complex and laborious undertaking which usually requires a large cadre of trained specialists and suites of complex software tools. It is a giant leap from today s ground prepared timeline (with a job jar) to full crew control of the timeline. However, technological advances, currently in-work or proposed, make it reasonable to consider scheduling a collaborative effort by the ground-based teams and the in-space crew. Collaboration would allow the crew to make minor adjustments, add tasks according to their preferences, understand the reasons for the placement of tasks on the timeline, and provide them a sense of control. In foreseeable but extraordinary situations, such as a quick response to anomalies and extended or unexpected loss of signal, the crew should have the autonomous ability to make appropriate modifications to the timeline, extend the timeline, or even start over with a new timeline. The Vision for Space Exploration (VSE), currently being pursued by the National Aeronautics and Space Administration (NASA), will send humans to Mars in a few decades. Stresses on the human mind will be exacerbated by the longer durations and greater distances, and it will be imperative to implement stress-reducing innovations such as giving the crew control of their daily activities.

Description: To prepare for future human space flight programs, the Mission Operations Laboratory (MOL) at the Marshall Space Flight Center (MSFC) has been investigating new planning and scheduling paradigms. To support and prove this investigation, MOL technologists have developed a working prototype of a scheduling system to support the new paradigms. The new planning and scheduling system is called Nexus and has a web site at http://nexus.nasa.gov/. Nexus is based on a comprehensive modeling schema to capture all scheduling requirements typical to human space missions, an incremental scheduling engine tailored to the modeling schema, and remote access (including Personal Data Assistant (PDA) access) to the scheduling system. This paper describes the proposed paradigm shift and the enabling software. It also describes a typical Nexus demonstration which emphasizes how it works, how it enables the paradigm shift, and possible applications. Demonstrations include access to the full functionally of Nexus from a personal computer and access to limited functionally via a PDA. An appendix includes a description and screen shots of the demonstrations.

Description: America has begun the development of a new space vehicle system which will enable humans to return to the moon and reach even farther destinations. The system is called Constellation: it has 2 earth-launch vehicles, Ares I and Ares V; a crew module, Orion; and a lander, Altair with descent and ascent stages. Ares V will launch an Earth Departure Stage (EDS) and Altair into low earth orbit. Ares I will launch the Orion crew module into low earth orbit where it will rendezvous and dock with the Altair and EDS "stack". After rendezvous, the stack will contain four complete rocket systems, each capable of independent operations. Of course this multiplicity of vehicles provides a multiplicity of opportunities for off-nominal behavior and multiple mitigation options for each. Contingency operations are complicated by the issues of crew safety and the possibility of debris from the very large components impacting the ground. This paper examines contingency operations of the EDS in low earth orbit, during the boost to translunar orbit, and after the translunar boost. Contingency operations under these conditions have not been a consideration since the Apollo era and analysis of the possible contingencies and mitigations will take some time to evolve. Since the vehicle has not been designed, much less built, it is not possible to evaluate contingencies from a root-cause basis or from a probability basis; rather they are discussed at an effects level (such as the reaction control system is consuming propellant at a high rate). Mitigations for the contingencies are based on the severity of the off-nominal condition, the time of occurrence, recovery options, options for alternate missions, crew safety, evaluation of the condition (forensics) and future prevention. Some proposed mitigations reflect innovation in thinking and make use of the multiplicity of on-orbit resources including the crew; example: Orion could do a "fly around" to allow the crew to determine the condition and cause of a partially separated payload shroud. Other mitigations are really alternate missions; example, an engine out on during ascent resulted in insufficient propellant for the lunar mission, but the on-orbit vehicle stack is otherwise perfect and can pursue an alternate mission, such as a high ballistic trajectory to test the high-speed atmospheric reentry of Orion. Evaluation and presentation of contingency operations at this early stage of the development of the Ares V rocket will improve the design of the vehicle and lay the groundwork for the exhaustive contingency planning which must be done after the vehicle is built as preparations for operations.

Description: The Flight Projects Directorate at NASA's Marshall Space Flight Center is developing a new planning and scheduling environment and a new scheduling algorithm to enable a paradigm shift in planning and scheduling concepts. Over the past 33 years Marshall has developed and evolved a paradigm for generating payload timelines for Skylab, Spacelab, various other Shuttle payloads, and the International Space Station. The current paradigm starts by collecting the requirements, called "tasks models," from the scientists and technologists for the tasks that they want to be done. Because of shortcomings in the current modeling schema, some requirements are entered as notes. Next a cadre with knowledge of vehicle and hardware modifies these models to encompass and be compatible with the hardware model; again, notes are added when the modeling schema does not provide a better way to represent the requirements. Finally, another cadre further modifies the models to be compatible with the scheduling engine. This last cadre also submits the models to the scheduling engine or builds the timeline manually to accommodate requirements that are expressed in notes. A future paradigm would provide a scheduling engine that accepts separate science models and hardware models. The modeling schema would have the capability to represent all the requirements without resorting to notes. Furthermore, the scheduling engine would not require that the models be modified to account for the capabilities (limitations) of the scheduling engine. The enabling technology under development at Marshall has three major components. (1) A new modeling schema allows expressing all the requirements of the tasks without resorting to notes or awkward contrivances. The chosen modeling schema is both maximally expressive and easy to use. It utilizes graphics methods to show hierarchies of task constraints and networks of temporal relationships. (2) A new scheduling algorithm automatically schedules the models without the intervention of a scheduling expert. The algorithm is tuned for the constraint hierarchies and the complex temporal relationships provided by the modeling schema. It has an extensive search algorithm which can exploit timing flexibilities and constraint and relationship options. (3) A web-based architecture allows multiple remote users to simultaneously model science and technology requirements and other users to model vehicle and hardware characteristics. The architecture allows the users to submit scheduling requests directly to the scheduling engine and immediately see the results. These three components are integrated so that science and technology experts with no knowledge of the vehicle or hardware subsystems and no knowledge of the internal workings of the scheduling engine have the ability to build and submit scheduling requests and see the results. The immediate feedback will hone the users' modeling skills and ultimately enable them to produce the desired timeline. This paper summarizes the three components of the enabling technology and describes how this technology would make a new paradigm possible.

Description: America has begun the development of a new heavy lift rocket which will enable humans to return to the moon and reach even farther destinations. Five decades ago, the National Aeronautics and Space Administration designed a system (called Saturn/Apollo) to carry men to the moon and back; the rocket which boosted them to the moon was the Saturn V. Saturn V was huge relative to contemporary rockets and is still the largest rocket ever launched. The new moon rocket is called Ares V. It will insert 40% more payload into low earth orbit than Saturn V; and after docking with the crew spacecraft, it will insert 50% more payload onto the translunar trajectory than Saturn V. The current design of Ares V calls for two liquid-fueled stages and 2 "strap-on" solid rockets. The solid rockets are extended-length versions of the solid rockets used on the Shuttle. The diameter of the liquid stages is at least as large as the first stage of the Saturn V; the height of the lower liquid stage (called the core stage) is longer than the external tank of the Shuttle. Huge rockets require huge infrastructure and, during the Saturn/Apollo era, America invested significantly in manufacturing, assembly and launch facilities which are still in use today. Since the Saturn/Apollo era, America has invested in additional infrastructure for the Shuttle program. Ares V must utilize this existing infrastructure, with reasonable modifications. Building a rocket with 50% more capability in the same buildings, testing it in the same test stands, shipping on the same canals under the same bridges, assembling it in the same building, rolling it to the pad on the same crawler, and launching it from the same launch pad is an engineering and logistics challenge which goes hand-in-hand with designing the structure, tanks, turbines, engines, software, etc. necessary to carry such a large payload to earth orbit and to the moon. This paper quantitatively discusses the significant "tight fits" that are constraining Ares V. The engineers designing and building the infrastructure for the Saturn/Apollo program usually added margins and growth capability; sometimes the size of existing facilities (such as the width of a draw bridge) was not a constraint. Ares V may utilize the "extra" space in the existing facilities and expand other tight fits. Some of the tight fits cannot be overcome without great expense; raising the roof on the Vertical Assembly Building for example. Other tight fits are easily overcome; the transporter at the manufacturing facility for the core stage can pass under low ceilings and later over a dike (without dragging the middle) by retracting or extending the struts which support the stage. Tight fits discussed in this paper include manufacturing (jigs, widths, heights, and local transportation), testing (test stand sizes and crane capability), transportation to the test stands and the launch site (barge, waterway, and rail), assembly (VAB internal dimensions and door size), roll-out limits, and launch pad size.