Search NASA⌕ Search

SEARCH · Search NASA

Results for “mission data system”

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 307 records · Page 17
All sourcesNASA NTRSDOE OSTI
NASA NTRS1989

SHARP: A multi-mission AI system for spacecraft telemetry monitoring and diagnosis

The Spacecraft Health Automated Reasoning Prototype (SHARP) is a system designed to demonstrate automated health and status analysis for multi-mission spacecraft and ground data systems operations. Telecommunications link analysis of the Voyager II spacecraft is the initial focus for the SHARP system demonstration which will occur during Voyager's encounter with the planet Neptune in August, 1989, in parallel with real-time Voyager operations. The SHARP system combines conventional computer science methodologies with artificial intelligence techniques to produce an effective method for detecting and analyzing potential spacecraft and ground systems problems. The system performs real-time analysis of spacecraft and other related telemetry, and is also capable of examining data in historical context. A brief introduction is given to the spacecraft and ground systems monitoring process at the Jet Propulsion Laboratory. The current method of operation for monitoring the Voyager Telecommunications subsystem is described, and the difficulties associated with the existing technology are highlighted. The approach taken in the SHARP system to overcome the current limitations is also described, as well as both the conventional and artificial intelligence solutions developed in SHARP.

Lawson, Denise L.↗
NASA NTRS1989

SHARP: A multi-mission artificial intelligence system for spacecraft telemetry monitoring and diagnosis

The Spacecraft Health Automated Reasoning Prototype (SHARP) is a system designed to demonstrate automated health and status analysis for multi-mission spacecraft and ground data systems operations. Telecommunications link analysis of the Voyager 2 spacecraft is the initial focus for the SHARP system demonstration which will occur during Voyager's encounter with the planet Neptune in August, 1989, in parallel with real time Voyager operations. The SHARP system combines conventional computer science methodologies with artificial intelligence techniques to produce an effective method for detecting and analyzing potential spacecraft and ground systems problems. The system performs real time analysis of spacecraft and other related telemetry, and is also capable of examining data in historical context. A brief introduction is given to the spacecraft and ground systems monitoring process at the Jet Propulsion Laboratory. The current method of operation for monitoring the Voyager Telecommunications subsystem is described, and the difficulties associated with the existing technology are highlighted. The approach taken in the SHARP system to overcome the current limitations is also described, as well as both the conventional and artificial intelligence solutions developed in SHARP.

Lawson, Denise L.↗
NASA NTRS1989

SHARP - A multi-mission AI system for spacecraft telemetry monitoring and diagnosis

The Spacecraft Health Automated Reasoning Prototype (SHARP) is a system designed to demonstrate automated health and status analysis for multi-mission spacecraft and ground data systems operations. Telecommunications link analysis of the Voyager II spacecraft is the initial focus for the SHARP system demonstration which will occur during Voyager's encounter with the planet Neptune in August, 1989, in parallel with real-time Voyager operations. The SHARP system combines conventional computer science methodologies with artificial intelligence techniques to produce an effective method for detecting and analyzing potential spacecraft and ground systems problems. The system performs real-time analysis of spacecraft and other related telemetry, and is also capable of examining data in historical context. A brief introduction is given to the spacecraft and ground systems monitoring process at the Jet Propulsion Laboratory. The current method of operation for monitoring the Voyager Telecommunications subsystem is described, and the difficulties associated with the existing technology are highlighted. The approach taken in the SHARP system to overcome the current limitations is also described, as well as both the conventional and artificial intelligence solutions developed in SHARP.

Lawson, Denise L.↗
NASA NTRS2011

Evaluating Cloud Computing in the Proposed NASA DESDynI Ground Data System

The proposed NASA Deformation, Ecosystem Structure and Dynamics of Ice (DESDynI) mission would be a first-of-breed endeavor that would fundamentally change the paradigm by which Earth Science data systems at NASA are built. DESDynI is evaluating a distributed architecture where expert science nodes around the country all engage in some form of mission processing and data archiving. This is compared to the traditional NASA Earth Science missions where the science processing is typically centralized. What's more, DESDynI is poised to profoundly increase the amount of data collection and processing well into the 5 terabyte/day and tens of thousands of job range, both of which comprise a tremendous challenge to DESDynI's proposed distributed data system architecture. In this paper, we report on a set of architectural trade studies and benchmarks meant to inform the DESDynI mission and the broader community of the impacts of these unprecedented requirements. In particular, we evaluate the benefits of cloud computing and its integration with our existing NASA ground data system software called Apache Object Oriented Data Technology (OODT). The preliminary conclusions of our study suggest that the use of the cloud and OODT together synergistically form an effective, efficient and extensible combination that could meet the challenges of NASA science missions requiring DESDynI-like data collection and processing volumes at reduced costs.

Benchmark↗
NASA NTRS1995

On the hitchhiker Robot Operated Materials Processing System: Experiment data system

The Space Shuttle Discovery STS-64 mission carried the first American autonomous robot into space, the Robot Operated Materials Processing System (ROMPS). On this mission ROMPS was the only Hitchhiker experiment and had a unique opportunity to utilize all Hitchhiker space carrier capabilities. ROMPS conducted rapid thermal processing of the one hundred semiconductor material samples to study how micro gravity affects the resulting material properties. The experiment was designed, built and operated by a small GSFC team in cooperation with industry and university based principal investigators who provided the material samples and data interpretation. ROMPS' success presents some valuable lessons in such cooperation, as well as in the utilization of the Hitchhiker carrier for complex applications. The motivation of this paper is to share these lessons with the scientific community interested in attached payload experiments. ROMPS has a versatile and intelligent material processing control data system. This paper uses the ROMPS data system as the guiding thread to present the ROMPS mission experience. It presents an overview of the ROMPS experiment followed by considerations of the flight and ground data subsystems and their architecture, data products generation during mission operations, and post mission data utilization. It then presents the lessons learned from the development and operation of the ROMPS data system as well as those learned during post-flight data processing.

Kizhner, Semion↗
NASA NTRS2013

The Sample Handling System for the Mars Icebreaker Life Mission: from Dirt to Data

The Mars icebreaker life mission will search for subsurface life on mars. It consists of three payload elements: a drill to retrieve soil samples from approx. 1 meter below the surface, a robotic sample handling system to deliver the sample from the drill to the instruments, and the instruments themselves. This paper will discuss the robotic sample handling system.

Martian Arctic↗
NASA NTRS2012

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014. The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such a comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass, ground operations can still reduce mission costs through smaller staffing of operators and limiting their working hours. The challenge, then, for the SMAP GDS engineering team, is to formulate an automated operations strategy--and corresponding system architecture -- to minimize operator intervention during routine operations, while balancing the development costs associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS -- NASA's AMMOS Mission Data Processing and Control System (AMPCS) -- provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

soil moisture↗
NASA NTRS1996

Multimission Software Reuse in an Environment of Large Paradigm Shifts

The ground data systems provided for NASA space mission support are discussed. As space missions expand, the ground systems requirements become more complex. Current ground data systems provide for telemetry, command, and uplink and downlink processing capabilities. The new millennium project (NMP) technology testbed for 21st century NASA missions is discussed. The program demonstrates spacecraft and ground system technologies. The paradigm shift from detailed ground sequencing to a goal oriented planning approach is considered. The work carried out to meet this paradigm for the Deep Space-1 (DS-1) mission is outlined.

Wilson, Robert K.↗
NASA NTRS2016

An Update on NAIF's Package of "SPICE" Astrodynamics Tools

"SPICE" is an information system, comprising both data and software, providing engineers and scientists with the geometry data needed to help design robotic solar system missions, conduct mission engineering operations, plan observations from instruments, and analyze the data returned from those observations. The SPICE system has been used on the majority of worldwide planetary exploration missions since the time of NASA's Magellan mission to Venus, and it appears to be the ancillary information system of choice for most future solar system exploration missions. Along with its "free" price tag, portability and the absence of licensing and export restrictions, its stable, enduring qualities and substantial user support in terms of training and consultation help make it a popular choice among scientists and engineers.

Acton, Charles↗
NASA NTRS2008

Juno Mission Simulation

The Juno spacecraft is planned to launch in August of 2012 and would arrive at Jupiter four years later. The spacecraft would spend more than one year orbiting the planet and investigating the existence of an ice-rock core; determining the amount of global water and ammonia present in the atmosphere, studying convection and deep- wind profiles in the atmosphere; investigating the origin of the Jovian magnetic field, and exploring the polar magnetosphere. Juno mission management is responsible for mission and navigation design, mission operation planning, and ground-data-system development. In order to ensure successful mission management from initial checkout to final de-orbit, it is critical to share a common vision of the entire mission operation phases with the rest of the project teams. Two major challenges are 1) how to develop a shared vision that can be appreciated by all of the project teams of diverse disciplines and expertise, and 2) how to continuously evolve a shared vision as the project lifecycle progresses from formulation phase to operation phase. The Juno mission simulation team addresses these challenges by developing agile and progressive mission models, operation simulations, and real-time visualization products. This paper presents mission simulation visualization network (MSVN) technology that has enabled a comprehensive mission simulation suite (MSVN-Juno) for the Juno project.

space vehicles↗
NASA NTRS2007

A Contrast in Use of Metrics in Earth Science Data Systems

In recent years there has been a surge in the number of systems for processing, archiving and distributing remotely sensed data. Such systems, working independently as well as in collaboration, have been contributing greatly to the advances in the scientific understanding of the Earth system, as well as utilization of the data for nationally and internationally important applications. Among such systems, we consider those that are developed by or under the sponsorship of NASA to fulfill one of its strategic objectives: "Study Earth from space to advance scientific understanding and meet societal needs." NASA's Earth science data systems are of varying size and complexity depending on the requirements they are intended to meet. Some data systems are regarded as NASA's "Core Capabilities" that provide the basic infrastructure for processing, archiving and distributing a set of data products to a large and diverse user community in a robust and reliable manner. Other data systems constitute "Community Capabilities". These provide specialized and innovative services to data users and/or research products offering new scientific insight. Such data systems are generally supported by NASA through peer reviewed competition. Examples of Core Capabilities are 1. Earth Observing Data and Information System (EOSDIS) with its Distributed Active Archive Centers (DAACs), Science Investigator-led Processing Systems (SIPSs), and the EOS Clearing House (ECHO); 2. Tropical Rainfall Measurement Mission (TRMM) Science Data and Information System (TSDIS); 3. Ocean Data Processing System (ODPS); and 4. CloudSat Data Processing Center. Examples of Community Capabilities are projects under the Research, Education and Applications Solutions Network (REASON), and Advancing Collaborative Connections for Earth System Science (ACCESS) Programs. In managing these data system capabilities, it is necessary to have well-established goals and to measure progress relative to them. Progress is measured through "metrics", which can be a combination of quantitative as well as qualitative assessments. The specific metrics of interest depend on the user of the metrics as well as the type of data system. The users of metrics can be data system managers, program managers, funding agency or the public. Data system managers need metrics for assessing and improving the performance of the system and for future planning. Program managers need metrics to assess progress and the value of the data systems sponsored by them. Also, there is a difference in the metrics needed for core capabilities that tend to be more complex, larger and longer-term compared to community capabilities and the community capabilities that tend to be simpler, smaller and shorter-term. Even among community capabilities there are differences; hence the same set of metrics does not apply to all. Some provide data products to users, some provide services that enable better utilization of data or interoperability among other systems, and some are a part of a larger project where provision of data or services is only a minor activity. There is also a contrast between metrics used for internal and external purposes. Examples of internal purposes are: ensuring that the system meets its requirements, and planning for evolution and growth. Examples of external purposes are: providing to sponsors indicators of success of the systems, demonstrating the contributions of the system to overall program success, etc. This paper will consider EOSDIS, REASON and ACCESS programs to show the various types of metrics needed and how they need to be tailored to the types of data systems while maintaining the overall management goals of measuring progress and contributions made by the data systems.

Ramapriyan, Hampapuram↗
NASA NTRS1999

A Probabilistic Approach of Incorporating Safety and Reliability in System Designs for a Manned Mission to Mars

Conceptual stages in mission design often lack the input of quantitative safety and reliability assessments, simply because failure rates or other data are not yet available for systems that have not yet been designed. Absence of such data should not, however, prevent the development of a quantitative risk models with placeholders for missing data. Functions (that is, actions the systems must perform) in mission design will eventually require system probabilities of success, and there could be much learned from surrogate data, adequately bounded in uncertainty, used in a large event tree model of a complex mission.

Railsback, Jan W.↗
NASA NTRS2005

NASA Intelligent Systems Project: Results, Accomplishments and Impact on Science Missions

The Intelligent Systems Project was responsible for much of NASA's programmatic investment in artificial intelligence and advanced information technologies. IS has completed three major project milestones which demonstrated increased capabilities in autonomy, human centered computing, and intelligent data understanding. Autonomy involves the ability of a robot to place an instrument on a remote surface with a single command cycle. Human centered computing supported a collaborative, mission centric data and planning system for the Mars Exploration Rovers and data understanding has produced key components of a terrestrial satellite observation system with automated modeling and data analysis capabilities. This paper summarizes the technology demonstrations and metrics which quantify and summarize these new technologies which are now available for future Nasa missions.

Coughlan, Joseph C.↗
NASA NTRS1991

Advanced automation in space shuttle mission control

The Real Time Data System (RTDS) Project was undertaken in 1987 to introduce new concepts and technologies for advanced automation into the Mission Control Center environment at NASA's Johnson Space Center. The project's emphasis is on producing advanced near-operational prototype systems that are developed using a rapid, interactive method and are used by flight controllers during actual Shuttle missions. In most cases the prototype applications have been of such quality and utility that they have been converted to production status. A key ingredient has been an integrated team of software engineers and flight controllers working together to quickly evolve the demonstration systems.

Heindel, Troy A.↗
NASA NTRS2019

Computing observation geometry for small satellites

Most solar system science missions need a variety of observation geometry–quantities such as position and velocity, range and altitude, viewing latitude and longitude, and lighting angles– to support mission engineering, science planning, and science data analysis activities. NASA's "SPICE" system offers one popular, multi-mission means for doing just that. SPICE comprises both data files, called kernels, and a SPICE software Toolkit that is available in many popular languages. A mission operations center produces the SPICE kernel files. Scientists and engineers write their own applications programs to address some need, and they include a few SPICE subroutines within that code to do the needed geometry computations. The SPICE system has been in use throughout NASA’s planetary science mission domain since 1991, and it has slowly spread to most major space agencies around the globe since then. The SPICE software is available in most popular languages, and for most popular platforms. The code is thoroughly tested before being released, and new versions of the Toolkit are always backwards compatible. The SPICE components are freely offered to everyone, and have no export, licensing or similar restrictions. Maybe using SPICE would work for your CubeSat or SmallSat mission?

Acton, Charles H.↗
NASA NTRS2009

CCSDS Spacecraft Monitor and Control Mission Operations Interoperability Prototype

We are entering a new era in space exploration. Reduced operating budgets require innovative solutions to leverage existing systems to implement the capabilities of future missions. Custom solutions to fulfill mission objectives are no longer viable. Can NASA adopt international standards to reduce costs and increase interoperability with other space agencies? Can legacy systems be leveraged in a service oriented architecture (SOA) to further reduce operations costs? The Operations Technology Facility (OTF) at the Johnson Space Center (JSC) is collaborating with Deutsches Zentrum fur Luft- und Raumfahrt (DLR) to answer these very questions. The Mission Operations and Information Management Services Area (MOIMS) Spacecraft Monitor and Control (SM&C) Working Group within the Consultative Committee for Space Data Systems (CCSDS) is developing the Mission Operations standards to address this problem space. The set of proposed standards presents a service oriented architecture to increase the level of interoperability among space agencies. The OTF and DLR are developing independent implementations of the standards as part of an interoperability prototype. This prototype will address three key components: validation of the SM&C Mission Operations protocol, exploration of the Object Management Group (OMG) Data Distribution Service (DDS), and the incorporation of legacy systems in a SOA. The OTF will implement the service providers described in the SM&C Mission Operation standards to create a portal for interaction with a spacecraft simulator. DLR will implement the service consumers to perform the monitor and control of the spacecraft. The specifications insulate the applications from the underlying transport layer. We will gain experience with a DDS transport layer as we delegate responsibility to the middleware and explore transport bridges to connect disparate middleware products. A SOA facilitates the reuse of software components. The prototype will leverage the capabilities of existing legacy systems. Various custom applications and middleware solutions will be combined into one system providing the illusion of a set of homogenous services. This paper will document our journey as we implement the interoperability prototype. The team consists of software engineers with experience on the current command, telemetry and messaging systems that support the International Space Station (ISS) and Space Shuttle programs. Emphasis will be on the objectives, results and potential cost saving benefits.

Lucord, Steve↗
NASA NTRS1966

Surveyor mission operations system

Functional description of launch vehicle, tracking and data acquisition, spacecraft, and mission operations of Surveyor mission

LAUNCH VEHICLE↗