The Present and Future of AMMOS Mission Planning and Sequencing

Transcription

1 SpaceOps 2006 Conference AIAA The Present Future of AMMOS Mission Planning Sequencing Mr. Adans Y. Ko Ms. Michele Vogt Jet Propulsion Laboratory Jet Propulsion Laboratory 4800 Oak Grove Dr Oak Grove Dr. Pasadena, CA Pasadena, CA Abstract - The AMMOS Mission Planning Sequencing (MPS) subsystem plays a critical role in NASA flight projects uplink process. The MPS system provides mission scientists engineers with science mission planning, sequencing, comm translation, on-board comm execution capabilities, allowing them to successfully plan, comm, control, execute their science mission objectives. The AMMOS science mission planning tools [1,2] allow users to search analyze science opportunities, design plan science observations engineering activities. The science mission planning capabilities include constraint checking, resource usage modeling, visualization of activity plans, resource profiles, observation targets' image footprints. The AMMOS sequence tools provide users with the capability to generate comm sequences, model changes in spacecraft states due to sequence comms, validate comm sequences based on spacecraft flight rules constraints, generate on-board comm execution predicts. We propose to evolve the current AMMOS MPS system architecture from a set of monolithic applications to one that is highly re-configurable service oriented. The new approach to system integration will not only enable system architects to configure the MPS system for a variety of missions types (e.g. orbital missions, in-situ missions, etc.) phases (conceptual study, preliminary analysis, definition, design development, operations) without redesigning the system, it will also enable mission operations users to access the system at any time from anywhere. The new architecture Copyright 2006 by the American Institute of Aeronautics Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner.

2 reflects enforces the division of data model, user interface, control logic by use of the Model- View-Controller (MVC) software architecture [3]. The model is the domain-specific representation of the spacecraft mission information on which the application operates. The view renders the model into a form suitable for interaction, in this case a simple client GUI or a userconfigurable GUI integrated into a rich client platform (e.g. Eclipse). The Controller responds to events, typically user actions, invokes changes on the model perhaps the view, which in this instanace will enable the construction of mission plans from mission activities executable sequences from spacecraft comms. Current Mission Planning Sequencing: Mission planning s primary roles (see figure 1.) in mission operations are to help mission scientists engineers create a mission plan that will optimize their mission objectives, to minimize the on-board resource usage during the strategic tactical planning phases. The planning software is used to search for science observation opportunities within given trajectory viewing constraints, to generate mission plans with science engineering activities (e.g. DSN relay network communication windows), to validate mission plans based on resource usage spacecraft constraints. Mission sequencing s primary roles (see figure 1.) are to generate spacecraft comm sequences. The sequencing software is used to construct comm sequences, model changes in spacecraft states due to sequence comm execution, produce event predictions. It also validates comm sequences based on spacecraft flight rules constraints. Prior to the uplink of comm sequences a ground software simulator that uses the sequence flight software is used to validate the on-board sequence execution. Future Mission Planning Sequencing Architecture: The proposed Mission Planning Sequencing architecture is based upon the MVC architectural framework has four parts: Modeler, Controller, Viewer, Data Repository. (see Figure 2). It is designed to meet today s fundamental system requirements:

3 the ability to respond to rapid technological changes; easy to develop, test, deploy; improved information flow; reduced operations costs; utilization of the DSMS Information Service Architecture (a service oriented architecture ); fully compatible with legacy system architecture; support for cross-levels data event modeling; an open, flexible system. The design approach will provide MPS with the capabilities to employ state of the art technologies; to scale the system from smaller, simpler missions to missions with complex, large scale mission operation s requirements; any time, anywhere, easy access; seamless information transformation; streamlined mission operations work flow management; cost effective software life cycle. Modeler - The Modeler contains information about the spacecraft the mission that has existed independent of mission planning sequence construction activities. In particular, the Modeler specifies the design of the spacecraft, including, for example, the devices that comprise the spacecraft, the possible states of each device, the spacecraft resources, the relation of resources to states (e.g., how much power a hazard avoidance camera uses when in the sampling state). The Modeler also contains mission activities or goals that will form the building blocks of re-usable mission plan activities or sequences. The Modeler needs to specify only those aspects that will affect the construction or analysis of sequences, only to the level of detail required for such. In prephase A, where trade studies comparing different possible designs of the spacecraft are conducted, each cidate design has a different version of the Modeler. Much of this kind of data is already available from other sources tools during the design phase of a mission, so the Architecture imports it from those sources. The Modeler portion of the Architecture is patternized; the Modeler s information is structured into reusable patterns. For example, there is a device pattern, which abstracts the notion that a device has several possible states. Controller - The Controller [4] has information needed for constructing a mission plan or sequence block from the Model. A mission plan or sequence block is a collection of activities to be accomplished during a given time span.. The activities include timing information their effect on states of devices in the spacecraft. The Controller portion of the Architecture is also patternized. Each pattern specifies an element involved in the construction of a planning activity or a sequence block. For example, there would be a pattern (several actually) for merging two timelines. The Controller patterns refer to Modeler patterns. To construct a planning activity or a sequence block involves the use of

4 many model patterns (for example, models of several devices on the spacecraft ), instantiating a controller pattern that refers to those models. Instantiating a pattern can actually cause more than one pattern to be exercised, since the definition of a pattern can refer to other patterns. In the first version of the Architecture, patterns are created manually. In future versions, the Controller will create not only scenarios, but also models, built from existing models stored in the Modeler. The Controller is the heart of the future MPS Architecture. Whereas the Modeler mostly contains information that is more general than is needed for scenarios, the data in the Controller is specific to scenarios. The Controller contains the business logic, i.e., the logic specific to the construction of a planning activity or a sequence block. Viewer - A Viewer is a software system that ingests the planned activities or sequences that are constructed by the Controller. The Architecture will use existing software systems as Viewers, such as tools that display timelines with values computed by modeling the effects implied by a mission project pattern modeling pattern. Patterns - A pattern is a group of reusable assets that can help to accelerate the process of creating deploying a new Ground Data System (GDS) for a Mission. The patterns leverage on the experience of JPL Mission System Engineers / Architects to create new GDSs in a more effective efficient way. There are static dynamic patterns that are based on Mission requirements, then quickly translated through the different levels of pattern assets to identify a final design solution product mapping appropriate for the application being developed. Static Pattern - The Static Pattern (see figure 3) consists of the following levels [5]: 1.Mission Project Patterns: They come from Mission requirements (a.k.a. customer requirements),

5 represent different Mission types (e.g., Orbital, In-Situ, Flyby, Observatory etc.). 2. Mission Model Patterns: The next level of Mission requirements provides us with a set of Mission Spacecraft specifications, which usually describe the components / subsystems of the spacecraft, the behavior of the subsystems, the control flow the data flow of each subsystem. The Mission Operations concept provides the requirements regarding users interactions with the mission operations the ground data system s applications their data products. The knowledge of the mission model patterns are usually captured in software models (e.g., Data Storage model, Power subsystem model, Attitude Control subsystem model, Telecom model). 3. Mission Scenario Patterns: This level of pattern is based on the Mission Plan. The scenarios from the Mission Plan will be patternized based on the mission type. Examples scenarios include Data Downlink communication scenario, Rover Drive over a Sol scenario, Pan Cam Imaging scenario, spacecraft occultation scenario. The pattern definitions of these scenarios are captured in the Mission Scenario Timeline models. 4. Application Patterns: These patterns represent the partitioning of the application logic data, combined with the styles of interaction between the logical tiers. We are proposing to use an N tiers Architecture (see figure 2) [5] with client applications (thin or rich), server applications (e.g., APCORE), data repository messaging bus server (e.g., DSMS messaging bus) for the future MPS system architecture. The Modeler layer is an essential part of the system. It contains the definitions of the mission scenarios models. Some of the models are created as a component object or a dynamic library in the legacy systems. The Modeler layer is also called the data layer. It uses a Lightweight Directory Access Protocol (LDAP) server for managing the name space for faster access. The patterns are created from the results of system engineering of the mission design, subsystem behaviors, also the mission operations concept. The Controller layer, also called the applications layer, has the logic of the scenarios models production. It uses Extensible Markup Language (XML), Extensible Style sheet Language Transformations (XSTL)

6 for managing the input, Java Beans to hle specific functionalities (e.g., pattern request hler, I/O interfaces, database access, presentation output for viewer). A search engine is also included in the Controller layer, in order to optimize the query of the data repository server. The Viewer layer is where the scenarios models are in a particular format able to be viewed. The Controller has the knowledge to publish the appropriated content via content management applications, which depends on the specific viewer. 5. Product mappings: The product mapping will use the push or publish method to populate the solution into the different viewers (see figure. 3). Dynamic Patterns - The Dynamic Pattern [6] (see figure 4) introduces two more pattern concepts: integration patterns composite patterns. The Integration Patterns connect other Business Patterns together to create application s with advanced functionalit y. While the models from the Business Patterns represent the spacecraft behavior model the Mission Scenario Patterns represent the Mission Scenario definitions, the integration patterns will have the Mission Flight rules, preference selections, exclusiveness, persistence, invalidation checks that govern the composition of different mission scenarios or mission timelines. The Controller translates interactions with the Viewer into actions to be performed according to the definitions of the Integration Patterns the models from the Business Patterns. Based on the user interactions the outcome of the Modeler actions, the Controller responds by selecting an appropriate view. The Composite Patterns combine Business Patterns Integration Patterns to create a complex, advanced GDS. Workflow Management An important feature provided by this proposed architecture is to enable automated planning sequencing workflow management (see figure 5). Mission operations will configure the workfl ow manag ement engine to proces s the scienti sts or engine ers reques ts from a set of activiti es or sequences from the queue. An

7 eligibility check process will verify the identity privilege of the requestor. Once the request is accepted, the plan or sequence will be modeled automatically by the system, invoking the resource subsystem modeling processes. The modeling process is merely to check the flight rules, constraints, resources of a plan or sequence. Any fatal violation will trigger the automated workflow manager to reject the plan or sequence, otherwise, a plan or a sequence will move forward to the comm generation approval processes. Once it is approved, the non-critical or non-interactive sequence comms can also be sent automatically to the spacecraft. A configuration management process a communication process will also be used to version control archive plans sequences, throughout the automated processes, the results of each critical step will notify relevant personnel, a tracking status of the plan or sequence throughout the process will be made available via the DSMS messaging bus. Compatible with Legacy System It is essential the new MPS architecture is compatible with the current system.. This compatibility provides a consistent interface allowing interoperabili ty between components products that exist in the current system those newly developed for the new architecture (see figure 6). One of the challenges in being backwards compatible with the legacy systems is the management of interfaces between the new current systems. The proposed MSP architecture will allow missions to easily define their data models using XML technologies. In conjunction, a common data model definition is required. One of the popular implementations involves using XML/XSLT. In this approach, the XSLT translator, translates the new product data into the legacy system data stream. The products interface ebetween the two systems are basically text files. Therefore, a Java Bean can also be used to access the database server, for file exchange at runtime. Conclusion future work - Mission planning sequencing is a very complex time consuming process. Because of its complexity, we believe an expert system approach with reusable patterns is a viable solution. The future work involves the following: Pattern saving searching. Incorpo rate a content data base for easy saving searchi ng.

8 Pattern composition. Develop a formal specification describing a pattern. A pattern resembles a component such as a Java Bean or a Windows COM object, in which patterns have properties that describe how they can be composed. Use of a web service or wireless implementation (see figure 7) to provide pervasive access for the users. A web service also provides a good infrastructure that combines different programming tools into a cohesive application. With the advancem ent of web application servers, quite a lot of needed utilities are ready to use. Most importantly, a commercial search engine can be applied to facilitate the pattern searching [6]

9 References: [1] Maldague, P., Ko, A.Y., Page, D.N. Starbird, T.W., 1997, APGEN: A Multi-Mission Semi-Automated Planning Tool, in First International Workshop on Planning Scheduling for Space Exploration Science. [2] Maldague, P., Ko, A.Y., JIT Planning: an Approach to Autonomous Scheduling for Space Missions, in March, 1999, IEEE Aerospace Conference, Aspen, Colorado [3] The Model-View-Controller Architecture, As a reference for our MCV model [4] Model View Controller, [5] Patterns for e-business: A Strategy of Reuse,Johnathan Adams, Srinivas, Guru Vasudeva, George Galambos [6] Build a Smarter Search Engine, by Baylor Wetzel. Java Pro October 2002

10 Biography Mr. Adans Y. Ko is the Program Element Manager of the Mission Planning Sequencing System at JPL. He is responsible for the Multi-mission Ground Data System uplink tools, which includes mission planning, sequence generation, sequence flight software for current future JPL missions the DSN. He received NASA s Exceptional Service Medal for his work on Voyager s onboard Computer Comm Subsystem for mission to Uranus Neptune. He was the Development Manager of the Mission Planning Sequence Subsystem. He got his B.S.C.S. degree from the Utah State University, Logan, Utah. in 1982, his M.B.A. degree from University of California, Los Angeles in Michele Vogt is the System Engineer of the Mission Planning Sequencing System at JPL. She is responsible for the system engineering activities for the planning, sequencing, comm execution tools contained in the MPS system.