ALBERT

Description: Emerging methods in component-based software development offer significant advantages but may seem incompatible with existing mission operations applications. In this paper we relate our positive experiences integrating existing mission applications into component-based tools we are delivering to three missions. In most operations environments, a number of software applications have been integrated together to form the mission operations software. In contrast, with component-based software development chunks of related functionality and data structures, referred to as components, can be individually delivered, integrated and re-used. With the advent of powerful tools for managing component-based development, complex software systems can potentially see significant benefits in ease of integration, testability and reusability from these techniques. These benefits motivate us to ask how component-based development techniques can be relevant in a mission operations environment, where there is significant investment in software tools that are not component-based and may not be written in languages for which component-based tools even exist. Trusted and complex software tools for sequencing, validation, navigation, and other vital functions cannot simply be re-written or abandoned in order to gain the advantages offered by emerging component-based software techniques. Thus some middle ground must be found. We have faced exactly this issue, and have found several solutions. Ensemble is an open platform for development, integration, and deployment of mission operations software that we are developing. Ensemble itself is an extension of an open source, component-based software development platform called Eclipse. Due to the advantages of component-based development, we have been able to vary rapidly develop mission operations tools for three surface missions by mixing and matching from a common set of mission operation components. We have also had to determine how to integrate existing mission applications for sequence development, sequence validation, and high level activity planning, and other functions into a component-based environment. For each of these, we used a somewhat different technique based upon the structure and usage of the existing application.

Description: Livingstone2 is a reusable, artificial intelligence (AI) software system designed to assist spacecraft, life support systems, chemical plants, or other complex systems by operating with minimal human supervision, even in the face of hardware failures or unexpected events. The software diagnoses the current state of the spacecraft or other system, and recommends commands or repair actions that will allow the system to continue operation. Livingstone2 is an enhancement of the Livingstone diagnosis system that was flight-tested onboard the Deep Space One spacecraft in 1999. This version tracks multiple diagnostic hypotheses, rather than just a single hypothesis as in the previous version. It is also able to revise diagnostic decisions made in the past when additional observations become available. In such cases, Livingstone might arrive at an incorrect hypothesis. Re-architecting and re-implementing the system in C++ has increased performance. Usability has been improved by creating a set of development tools that is closely integrated with the Livingstone2 engine. In addition to the core diagnosis engine, Livingstone2 includes a compiler that translates diagnostic models written in a Java-like language into Livingstone2's language, and a broad set of graphical tools for model development.

Description: MSLICE (Mars Science Laboratory InterfaCE) is the tool used by scientists and engineers on the Mars Science Laboratory rover mission to visualize the data returned by the rover and collaboratively plan its activities. It enables users to efficiently and effectively search all mission data to find applicable products (e.g., images, targets, activity plans, sequences, etc.), view and plan the traverse of the rover in HiRISE (High Resolution Imaging Science Experiment) images, visualize data acquired by the rover, and develop, model, and validate the activities the rover will perform. MSLICE enables users to securely contribute to the mission s activity planning process from their home institutions using off-the-shelf laptop computers. This software has made use of several plug-ins (software components) developed for previous missions [e.g., Mars Exploration Rover (MER), Phoenix Mars Lander (PHX)] and other technology tasks. It has a simple, intuitive, and powerful search capability. For any given mission, there is a huge amount of data and associated metadata that is generated. To help users sort through this information, MSLICE s search interface is provided in a similar fashion as major Internet search engines. With regard to the HiRISE visualization of the rover s traverse, this view is a map of the mission that allows scientists to easily gauge where the rover has been and where it is likely to go. The map also provides the ability to correct or adjust the known position of the rover through the overlaying of images acquired from the rover on top of the HiRISE image. A user can then correct the rover s position by collocating the visible features in the overlays with the same features in the underlying HiRISE image. MSLICE users can also rapidly search all mission data for images that contain a point specified by the user in another image or panoramic mosaic. MSLICE allows the creation of targets, which provides a way for scientists to collaboratively name features on the surface of Mars. These targets can also be used to convey instrument-pointing information to the activity plan. The software allows users to develop a plan of what they would like the rover to accomplish for a given time period. When developing the plan, the user can input constraints between activities or groups of activities. MSLICE will enforce said constraints and ensure that all mission flight rules are satisfied.