Engineering PapersSearch

SEARCH · Engineering Papers

Results for “Ground Data Systems (GDS)”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3

COCPIT: Collaborative Activity Planning Software for Mars Perseverance Rover

Since landing on the Martian surface, the Perseverance rover has relied on a distributed team to generate commands for exploring its new environment each sol (Martian day). The team uses a complex suite of software tools to accomplish this challenging task in time for the next window of opportunity to send commands to the rover. A key piece of this software ecosystem is COCPIT (Component-based Campaign Planning, Implementation, and Tactical). COCPIT is part of the next generation of planning and scheduling software tools developed by NASA's Jet Propulsion Laboratory in partnership with NASA's Ames Research Center. COCPIT is a web-based application that allows users to collaboratively view and update the Perseverance rover's activity plans, continuously verify that the plan satisfies constraints, assign targets for directing scientific instruments, document science intent, and model power and data resources. Mars Surface Operations requires diverse expertise from team members within the Engineering, Science, Robotic, and Instrument Operations groups, distributed across North America and Europe. In order to improve efficiency and reduce risk, all teams are able to review and edit their activities simultaneously and see the effects on the plan in its entirety. As part of the Ground Data System (GDS) tool suite, COCPIT is responsible for the activity plan. It provides specialized views that allow operators to understand where there may be room for additional observations, see whether any planning constraints are being violated, and confirm that energy usage and data generation are within the defined limits. It contains details such as which filters a camera will use for a given observation, what the resolution of the images should be, where to store the data onboard, and how long the observation is expected to take. It predicts when specific data will be downlinked from the rover to a passing orbiter, so that the team knows when to expect that data on Earth for evaluation in future planning. Ultimately the information from the COCPIT plan is translated to sequences that will be bundled and radiated to Perseverance for execution. The COCPIT tool is used throughout all planning phases.

Kanefsky, Bob

Astrobee Operations on the Iss: Gui’S Impact on the Operators’ Cognitive Load

The Astrobee free-flying robots have completed their fifth successful year of operations housed in the Japanese Experimental Module (JEM) on the International Space Station (ISS). In this paper, we introduce two Graphical User Interfaces (GUI) used to operate and monitor in real-time the Astrobee free-flying robots onboard the ISS and report on the impact these GUIs have in the operator’s cognitive load. A review of the state-of-the-art GUI design for remotely teleoperated scenarios with minimal time delay is presented and the study’s conclusion used to determine the elements and recommendations to create an interface that minimizes its impact on the overall performance of an operator during an activity at the ISS. The Ground Data System (GDS) is one of the two GUIs in the study: it contains several tabs, each of which displays a different set of controls for specific tasks e.g. Overview, Run Plan, Teleoperate, Guest Science; some also display video and a three-dimensional (3D) representation of the ISS and robot based on the Astrobee’s telemetry. Most tabs enable a single operator-robot connection, however some of its tabs are capable to monitor and control up to three Astrobees simultaneously. The GDS Helper is a text-based user interface created to facilitate commanding and monitoring of an Astrobee robot directly from an SSH session. In full interactive mode it displays a maximum of 5 sections: general commanding, feedback/ack, telemetry, guest science commanding, and data, all in one view. In batch mode, it enables complex command scripting while retaining some interactive capabilities. A comparative analysis between these GUIs is carried out at an analogous ISS environment at the NASA Ames Research Center’s Granite Lab and its results presented. While GDS is able to provide an operator with control and situational awareness via its video and 3D displays, its several tabs may introduce an overwhelming amount of information confusing and delaying the operator especially during time-sensitive maneuvers where the operator may need to switch back and forth between them. GDS helper in the other hand does not provide video or 3D displays thus not allowing an operator to attain situational awareness, however it provides the operator with a design displaying commonly used data in a single window, enabling the operator to understand the state of the robot at a glance and control it through a commands entered via keyboard instead of a combination of mouse clicks and keyboard input. The results of the experiments measure the cognitive load across several operators maneuvering Astrobee to accomplish tasks ranging from fully manual to supervised activities. A GUI combining a single window displaying data along video and a 3D display is expected to reduce the operator’s cognitive load.

Astrobee

From Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn GDS Team met the SC Sim integration challenge in eight months. The GDS System Engineering approach in response to the SC Simintegration challenge, focused on a set of key practices: decomposition of project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; risk management thru management of expectations; and aggregation of intermediate products into a final product. By maintaining a a system-level focus, the overall systems engineering process unified team GDS Team members with a common goal: the success of the ground system as a whole and not just the success of their individual expert contributions. Incorporation of Agile-type development efforts were aligned with a risk strategy based on team-oriented principles and expectations management, thus achieving a more stable baseline solution without compromising the integrity of the GDS design.

Dawn Mission

A Whale of a Tale: Creating Spacecraft Telemetry Data Analysis Products for the Deep Impact Mission

This paper describes some of the challenges and lessons learned from the Deep Impact (DI) Mission Ground Data System's (GDS) telemetry data processing and product generation tool, nicknamed 'Whale.' One of the challenges of any mission is to analyze testbed and operational telemetry data. Methods to retrieve this data to date have required spacecraft subsystem members to become experts in the use of a myriad of query and plot tools. As budgets shrink, and the GDS teams grow smaller, more of the burden to understand these tools falls on the users. The user base also varies from novice to expert, and requiring them to become GDS tool experts in addition to spacecraft domain experts is an undue burden. The "Whale" approach is to process all of the data for a given spacecraft test, and provide each subsystem with plots and data products 'automagically.'.

Deep Impact

Advances in Distributed Operations and Mission Activity Planning for Mars Surface Exploration

A centralized mission activity planning system for any long-term mission, such as the Mars Exploration Rover Mission (MER), is completely infeasible due to budget and geographic constraints. A distributed operations system is key to addressing these constraints; therefore, future system and software engineers must focus on the problem of how to provide a secure, reliable, and distributed mission activity planning system. We will explain how Maestro, the next generation mission activity planning system, with its heavy emphasis on portability and distributed operations has been able to meet these design challenges. MER has been an excellent proving ground for Maestro's new approach to distributed operations. The backend that has been developed for Maestro could benefit many future missions by reducing the cost of centralized operations system architecture.

Mars Exploration Rover (MER)

Automating the SMAP Ground Data System to Support Lights-Out Operations

The Soil Moisture Active Passive (SMAP) Mission is a first tier mission in NASA's Earth Science Decadal Survey. SMAP will provide a global mapping of soil moisture and its freeze/thaw states. This mapping will be used to enhance the understanding of processes that link the terrestrial water, energy, and carbon cycles, and to enhance weather and forecast capabilities. NASA's Jet Propulsion Laboratory has been selected as the lead center for the development and operation of SMAP. The Jet Propulsion Laboratory (JPL) has an extensive history of successful deep space exploration. JPL missions have typically been large scale Class A missions with significant budget and staffing. SMAP represents a new area of JPL focus towards low cost Earth science missions. Success in this new area requires changes to the way that JPL has traditionally provided the Mission Operations System (MOS)/Ground Data System (GDS) functions. The operation of SMAP requires more routine operations activities and support for higher data rates and data volumes than have been achieved in the past. These activities must be addressed by a reduced operations team and support staff. To meet this challenge, the SMAP ground data system provides automation that will perform unattended operations, including automated commanding of the SMAP spacecraft.

GDS

Multi-mission ground data systems - breakthroughs and challenges

Given the cost-constrained nature of JPL Flight Projects, especially Discovery Class missions, there is more and more pressure to reduce the costs associated with mission operations, particularly the costs for the Ground Data System. This paper explores the successes (and failures) of using the Mission Management Office (MMO) GDS team to provide a common set of services, tools, procedures, and products to JPL Flight Projects.

GDS

Modernization of the Cassini Ground System

The Cassini Spacecraft and its ground system have been operational for over 16 years. Modernization presents several challenges due to the personnel, processes, and tools already invested and embedded into the current ground system structure. Every mission's ground system has its own unique complexities and challenges, involving various organizational units. As any mission from its inception to its execution, schedules are always tight. This forces GDS engineers to implement a working ground system that is not necessarily fully optimized. Ground system challenges increase as technology evolves and cyber threats become more sophisticated. Cassini's main challenges were due to its ground system existing before many security requirements were levied on the multi-mission tools and networks. This caused a domino effect on Cassini GDS tools that relied on outdated technological features. In the aerospace industry reliable and established technology is preferred over innovative yet less proven technology. Loss of data for a spacecraft mission can be catastrophic; therefore, there is a reluctance to make changes and updates to the ground system. Nevertheless, all missions and associated teams face the need to modernize their processes and tools. Systems development methods from well-known system analysis and design principles can be applied to many missions' ground systems. Modernization should always be considered, but should be done in such a way that it does not affect flexibility nor interfere with established practices. Cassini has accomplished a secure and efficient ground data system through periodic updates. The obstacles faced while performing the modernization of the Cassini ground system will be outlined, as well as the advantages and challenges that were encountered.

Razo, Gus

Modernization of the Cassini Ground System

The Cassini Spacecraft and its ground system have been operational for over 16 years. Modernization presents several challenges due to the personnel, processes, and tools already invested and embedded into the current ground system structure. Every mission's ground system has its own unique complexities and challenges, involving various organizational units. As any mission from its inception to its execution, schedules are always tight. This forces GDS engineers to implement a working ground system that is not necessarily fully optimized. Ground system challenges increase as technology evolves and cyber threats become more sophisticated. Cassini's main challenges were due to its ground system existing before many security requirements were levied on the multi-mission tools and networks. This caused a domino effect on Cassini GDS tools that relied on outdated technological features. In the aerospace industry reliable and established technology is preferred over innovative yet less proven technology. Loss of data for a spacecraft mission can be catastrophic; therefore, there is a reluctance to make changes and updates to the ground system. Nevertheless, all missions and associated teams face the need to modernize their processes and tools. Systems development methods from well-known system analysis and design principles can be applied to many missions' ground systems. Modernization should always be considered, but should be done in such a way that it does not affect flexibility nor interfere with established practices. Cassini has accomplished a secure and efficient ground data system through periodic updates. The obstacles faced while performing the modernization of the Cassini ground system will be outlined, as well as the advantages and challenges that were encountered.

Razo, Gus