Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/institute/conference/iwpss/plenary-r2-commentary-morris.pdf Дата изменения: Tue Mar 20 17:47:28 2012 Дата индексирования: Tue Feb 5 12:40:47 2013 Кодировка:

Planning in the Dark: Robotic Sorties into Lunar Cold Traps (A Preliminary Report) Commentary
Terri Wood
Mission Applications Branch (MAB) Code 583 NASA Goddard Space Flight Center (GSFC) Greenbelt, Maryland 20771 Terri.wood-1@nasa.gov

Introduction
The author presents an interesting Planning and Scheduling (P&S) technology for guiding rovers to locate water and ice on the moon. His approach is to develop an integrated mission operations software system which comprises a data visualization component, an execution monitor component, and a planner component. However, according to the author, there was no way to obtain any hands on experience with the system because it is in the preliminary stages of development. Furthermore, there was limited documentation available to describe the system design or usage. Consequently, I decided to critique this system by using compiled Mission Planning System (MPS) criteria that I collected from a P&S expert's course notes; participating as co-lead on a P&S Domain Focus Group; a Users' Survey Document; and an Operations Concept Document for Next Generation P&S Systems. All of the documentation mentioned above reflects the opinions and views of various stakeholders such as project personnel, mission operators, Flight Operations Teams (FOT)s, and science/mission schedulers in the area of P&S, during the past six years. In addition, I obtained feedback from a Lunar Reconnaissance Orbiter (LRO) mission perspective to determine if this technology was feasible for future robotic missions.

should follow a data-centric design to allow for easy insertion of algorithms and models as problems change. Three, the system should implement a scalable ObjectOriented Design (OOD) to provide logical hierarchical groupings such as inheritance and segmentation for data expandability. Four, the system should include a plug-inplay framework to add or extract system components, such as Databases (DB) s to reduce dependencies on expensive Commercial-off-the-Shelf (COTS) DBs, or DB experts. Five, the system should contain a modular Graphical Users Interface (GUI) design to easily input scheduling rules, interpret output scheduling rules, and perform extensive constraint checking on scheduling rules.

P&S Domain Focus Group
In 2002, I participated on a team with P&S system users whose charter was to analyze cost drivers and determine future goals for readily available P&S systems [2]. Thus, the team agreed that configuration costs, initial and recurring support licenses fees, and training costs were the biggest cost drivers for P&S systems. Likewise the team identified four requirements which P&S systems should address for upcoming constellation and robotic missions. The first requirement is to develop common P&S data stores to enable unlike P&S systems to share data. The second requirement is to develop standardized P&S interfaces which allow different types of compliant systems, to communicate with the common data stores and with each other. The third requirement is to develop interchangeable databases such that data storage can be selected based on budget, preference, and need. The fourth requirement is to develop abstract planning capabilities which allow operators to specify high level goals and to execute the low- level activities necessary to accomplish the goals.

MPS Criteria
P&S Expert Course Notes
A P&S expert presented course notes that described several system design attributes which are necessary to develop a scalable and robust P&S system [1]. These five characteristics are summarized as follows. One, the system should adopt a client/server design to allow multiple users the ability to access the system simultaneously. With this type of design, the system can dynamically rework the problem as each user provides input. Two, the system

Users' Survey Results
The MAB conducted a users' survey of homegrown P&S systems to learn how customers used them and whether or not the systems met the customer's requirements [3]. These customers included FOT personnel, science planner and schedulers, as well as mission planner and schedulers


from the SOHO, TRACE, TRMM, L7 and Terra missions to name a few. Again, these customers provided very useful suggestions regarding P&S system development. The first suggestion was to design seamless systems to allow integrated subsystems to work as a cohesive unit. The second suggestion was to budget for a developer to automate routine tasks during the operational and maintenance phases of the mission, when these tasks become easier to identify. The third suggestion was to maximize the use of technologies such as web, Interactive Data Language (IDL), and Common Data Format (CDF) to capture, process, and archive science data faster and easier. The final suggestion was to develop web-based activity plans to help distribute schedules and activities to a wider audience of project personnel. In fact, LRO sited the need for web-based activity planning as part of their MPS requirements [4].

Furthermore I discussed this technology with the LRO Ground System & Operations (GS&O) Lead and he stated that the idea for the planning system seems fine- he likes the visualization and relating timeline/events features. However, he felt that the P&S system could be classified as a tool that the PIs/Scientist would use to submit timeline/inputs to an ops team to generate a load plan. He suggested that the tool could be used to incorporate science data processing feedback during a number of scenarios. For example, once the data is down linked and processed, the tool might indicate important findings or other regions of interest. In addition, if the rover drilled a previous hole and found some interesting data, it might be worth going back to drill additional holes nearby.

Conclusion
The compiled MPS criteria are directly applicable to the implementation approach that the author has described. For example, the Europa Activity Planner component should contain a modular GUI design to input/model activities and constraints; a data-centric design to easily add algorithms; and abstract planning techniques to automatically develop low-level activities from high level goals. In addition, the Viz User Interface as well as the Ensemble GUI should contain an OOD design to display 3D maps and to simulate robotic operations, accurately, especially when the exploration region expands or changes. Finally, the Ensemble platform should contain a framework to standardize interfaces; to easily adapt and configure the system; to automate routine tasks; and finally to authorize and enforce security regulations. In conclusion, this author should incorporate as many of the requirements, goals, and attributes mentioned as possible to avoid a hard sell to P&S stakeholders!

Operations Concept for Next Generation P&S
The surveyed missions for next generation P&S includes GPM, LRO, and MMS. Their overall requirements for selecting an MPS are as follows [5]: · Simplicity ­ software adopts wizards and GUIs to provide step-by-step instructions and processing results to the user. · Modular ­ software provides mechanisms for configuring and customizing system components such as scheduling algorithms, models, and GUIs (commonly known as a framework). · Component Reuse ­ software uses frameworks to effectively reuse software components. · Low-cost ­ software requires less than one Full Time Equivalent (FTE) to operate and maintain per year. · Automation-friendly ­ software contain mechanisms to automate day-to-day activities. · Security features ­ software authorizes personnel to change displays or scheduling rules and enforces network security regulations.

References
1. Hempel P., et.al. January 2000. "An Introduction to Planning and Scheduling Systems". Computer Sciences Corporation, Greenbelt Md. 2. Catena J., et.al. June 2002. "P&S Domain Focus Group Phase One Presentation". GSFC. 3. Wood T. et. al. July 2002. "Users Survey of P&S Systems for MAB". GSFC. 4. Clapsadle et. al. August 2005. "LRO's MPS Requirements". GSFC. 5. Hendicks V. et. al. "Next Generation Planning and Scheduling Study Concept of Operations Document" Honeywell Technology Solutions Inc., Lanham Md. 6. Lunar Reconnaissance Orbiter (LRO) Mission Web Site Ver. 1 (September 2006).

LRO Mission Perspective
I discussed whether or not the proposed technology was useful with the LRO System Engineer [6]. He stated that the technology wasn't really applicable for LRO but he felt that it would be applicable for future missions under the Lunar Precursor Robotics Program (LPRP) office and he provided a point of contact for this program. Moreover he stated that the proposed system was unique because it provided direct feedback or output to the spacecraft, and not to other traditional P&S interfaces. Because of that uniqueness, he felt that this system should be integrated earlier, perhaps during the spacecraft design phase, to ingest spacecraft system feedback.