Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass99/O4-04/
Дата изменения: Wed Oct 4 04:35:04 2000 Дата индексирования: Tue Oct 2 06:08:31 2012 Кодировка: Поисковые слова: п п п р п р п р п р п р п |
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.
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.
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.
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.
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 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
. 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.
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.
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