Next: Adding Multiple Exposure Planning and Expert System Technology in the Scientist's Expert Assistant
Up: Observation Planning and Scheduling
Previous: The New MAJORDOME: Efficient Scheduling of Autonomous Telescopes
Table of Contents - Subject Index - Author Index - PS reprint -

Brooks, T. 2000, in ASP Conf. Ser., Vol. 216, Astronomical Data Analysis Software and Systems IX, eds. N. Manset, C. Veillet, D. Crabtree (San Francisco: ASP), 119

ComPASS: A Common Framework for Streamlining Multi-Level Planning Systems from Scientist to Observatory/Spacecraft

T. Brooks
AppNet, Inc.


Current efforts to integrate multiple planning and scheduling subsystems into an end-to-end, scientist-observatory/spacecraft, planning system are handcrafted and very resource intensive. In addition, future spacecraft/observatory configurations such as constellations and multi-observatory ``campaigns'' introduce challenges that require a new approach to planning and scheduling system integration. The Advanced Architectures and Automation Branch of NASA's Goddard Space Flight Center has embarked on a multi-year project entitled ComPASS (Common Planning And Scheduling System) with the goal of producing a common framework for end-to-end collaborative planning and scheduling. ComPASS is intended to streamline automation of the planning process and enable general application of automated collaborative planning technologies.

During NASA FY99, the ComPASS project has developed the infrastructure for plan distribution/collaboration, a common plan representation, and interfaces to existing components. The first set of components to be integrated include an extended version of Goddard's Scientist's Expert Assistant (SEA) science client, ASPEN - a planner/scheduler from the Jet Propulsion Laboratory (JPL), and Satellite Toolkit (STK) from Analytical Graphics, Inc.

1. Introduction

The ComPASS project is work performed by AppNet for the Advanced Architectures and Automation Branch of NASA Goddard Space Flight Center (GSFC). ComPASS is an architecture for streamlining the planning pipeline found in spacecraft missions and ground-based observatories. The genesis of ComPASS was two concept studies performed in 1998 for NASA GSFC by AppNet. The first study was the Cooperative Autonomy Project that explored how multiple spacecraft could collaborate to achieve a common goal. The second study, the Collaborative Advanced Planning Environment, investigated ways to provide scientists with ``transparent'' access to mission resources, reducing the perceived disconnection between a scientist's plan and mission execution of that plan. Both studies resulted in common conclusions about current spacecraft mission planning architectures and the need for changes in those architectures.

2. The Study Conclusions

The common conclusions were three-fold:

  1. Scientists are isolated from the execution of their plans,
  2. Re-planning is an arduous and time-consuming process often involving substantial manual effort or highly custom automation systems,
  3. Current planning systems are inadequate to address the needs of upcoming mission architectures, such as constellations and cross-mission collaborations,

The tools that scientists use to create a plan range from an e-mail client to mission ops-style planning timelines. These tools have not been crafted to the scientist's need - representing the problem in scientific terms. The plans are submitted with little feedback on the efficiency or schedulability of the plan.

Because of the batch nature of most planning, re-planning can involve considerable human involvement. This is cumbersome and often unresponsive to individual planner needs. In particular, with a long re-planning interval, certain targets of opportunity can be lost (e.g. Gamma Ray Bursts).

New missions involving multiple platforms, whether ground or space-based, require levels of collaborative planning that are missing from current planning systems. Especially when platforms are under the control of different organizations, the timely coordination of plans is problematic and costly in terms of resources.

3. The Deeper Issues

Looking deeply into the problems, the ComPASS team identified more fundamental issues. Islands of planning are the result of the complexity of the planning problem presented by spacecraft missions and the state of the art in planning technology about a decade ago. Over the past 30 years the planning and scheduling community has focused itís research on specific algorithms within individual planners that maximize properties such as efficiency, effectiveness, or the ability to effect schedule repairs in a timely manner. Within the last decade significant research in distributed and collaborative planning has been fruitful, but little of this work has yet made its way into the spacecraft and astronomical planning community.

The last five years has seen explosive growth in the bandwidth available for distributed computing yet current planning systems are still operating in a centralized manner.

Different organizations produce models of the environment and spacecraft systems for which the plan is being produced. Often models of the same phenomenon or instrument, at different fidelities, are created that have no defined relationship. The models don't provide a consistent view of the item being modeled and can result in improper planning or planning glitches that can take an enormous amount of effort to identify and repair or work around.

Scientists and spacecraft are seen as endpoints in the planning pipeline rather than active planning agents. The planning needs of scientists have been largely ignored and either scientists are required to become engineers and understand mission ops-style planning tools or are hidden from the planning tradeoffs by a human go-between that can translate the scientist's plan into engineering language. Spacecraft, until recently, have not had the compute power or memory to perform planning tasks. With the advent of spacecraft such as Deep Space 1, this is no longer true. Future spacecraft will exhibit more autonomy with on-board planning as an integral component. Current systems are designed for ground-based command sequence generation and verification.

Ultimately, the fundamental issue revolves around the ability of planning systems to collaborate in the production of high quality, timely plans for execution. From the scientist to the spacecraft, the entire planning pipeline is really one massive and complex control system that has a number of control loops which are currently handled by highly customized software or humans. What is needed is a common framework linking the individual planning systems together in a standard fashion. The ComPASS project shows how this might be accomplished.

4. The ComPASS Approach

By producing a prototype, end-to-end planning framework, ComPASS addresses the needs of transparent access to scientists, streamlined re-planning, and enabling multi-dimensional collaboration.

Realizing that such a framework was a huge endeavor, the ComPASS team knew that it was foolhardy to try and develop the planning clients, servers, and modeling tools required to make an operable system. Instead existing components were incorporated by the use of mediators. The function of a mediator is to translate information from a common, public view into the private view, or representation, of an individual component.

The fundamentals of our approach became known as the 3M approach. The first ``M'' stands for ``Medium''. The medium used to communicate within the ComPASS framework is a Java-based object distribution/persistent store which we call COVE (for Collaborative Object-oriented Virtual Environment). All planning communication takes place through the medium of COVE.

COVE has some unique properties that bear mentioning. Since we are producing a system for use by scientists and spacecraft, it is expected that there will be times when either will be $out\ of\ view$ and need to continue modifying the plan. This eliminates the possibility of using distribution systems such as CORBA or Java RMI which assume strong connectivity. This type of system is termed ``weakly connected''. We were influenced by work from Xerox PARC on weakly connected database systems called the Bayou project. Using concepts out of Bayou, we implemented COVE in Java allowing transactions down to the property level of objects. This begged the question of object consistency since changes could be made to the same object by two or more disconnected processes. We introduced application management of transactions, where a transaction would be granted or rejected by a Policy class.

The second ``M'' represents the ``Message''. In order for many planners of varying heritage to communicate, we needed a planning $lingua\
franca$. The ComPASS team defined a common planning language, CPL (ComPASS Planning Language), which draws its heritage from many sources including planning languages developed at NASA Ames Research Center, I-N-OVA, and SRI.

The third and last ``M'' is for ``Mediator''. Because of the value and functionality available in existing GOTS and COTS components, we needed a means to translate from the specific, native representations of domain information and plan into our common view, CPL. Mediators were produced for our GOTS planning client and server, and our COTS modeling tool.

5. First Year Results

This first year the ComPASS team completed a prototype implementation of COVE and CPL. We used this implementation to produce a proof of concept science planning system which can allow multiple scientists to produce a very simple observation plan for the Hubble Space Telescope.

Integrated into this framework is a science planning client, based on the Scientist's Expert Assistant, a product of NASA GSFC. For the planning engine and science operations console, the ASPEN planner from Jet Propulsion Laboratory is used and for spacecraft modeling Satellite Toolkit (STK) from Analytical Graphics was selected and integrated.

6. Future Plans

Interest in the collaboration capabilities of ComPASS and the near-term needs for automation of cross-mission planning coordination have resulted in a re-focus of the project to explore this important problem over the next year. Many of the issues present in the hierarchical collaboration of end-to-end planning are also present in the side-to-side, peer-to-peer planning necessary for cross-mission planning.


AppNet Inc. 1999, ComPASS Project

Xerox Palo Alto Research Center, Bayou Project Home Page

Artificial Applications Institute, I-N-OVA Constraint Model

NASA Jet Propulsion Laboratory, ASPEN Planner Home Page

Analytical Graphics Inc., Satellite Tool Kit

SRI International, Inc., SRI Planning Page

© Copyright 2000 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA
Next: Adding Multiple Exposure Planning and Expert System Technology in the Scientist's Expert Assistant
Up: Observation Planning and Scheduling
Previous: The New MAJORDOME: Efficient Scheduling of Autonomous Telescopes
Table of Contents - Subject Index - Author Index - PS reprint -