SEARCH · Search NASA

Results for “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.

SourceResearch connectionFrom yearThrough year

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

At least 37 records · Page 2

All sources NASA NTRS DOE OSTI

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.[double dagger] 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 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 cost through smaller staffing of operators and limited work 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 operations, while balancing the development cost 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.

remote-sensing↗

NASA NTRS2008

Moving Away from Ones and Zeros, Designing a Ground Data System Based on Higher Levels of Abstraction

Previous JPL ground systems have been designed with the Ground Data System (GDS) engineer in mind. The focus on these systems has been on packaging and delivery of low level information (frames, packets, telemetry values) to the end user. It was not that long ago when project teams would be huddled over a workstation, examining crude displays of telemetry bits organized in various ways, trying to determine the status of a spacecraft. Understanding the data often required additional levels of GDS expertise, or worse, transformation of the raw data into alternative formats followed by ingestion into other tools so that the data became meaningful. The primary focus was often to answer these types of questions: "Why did this particular frame fail Reed-Solomon decode? Why did this packet get marked as invalid? Why am I missing a block of telemetry from my query?" -- which are completely valid questions to ask from a GDS Engineer's point of view, and large families of tools have been designed to help answer these questions. But these are not the questions that most users care about - which are more like: "Why is the battery state of charge trending down? Show me a summary image report for the last traverse to the target. Show me a data accountability summary for the last DSN pass." Answers to these questions, which are what users are looking for, requires a higher level of abstraction and supporting tools than mining through ones and zeros. JPL has created a next generation capability called the Mission Data Processing and Control System (MPCS) which is designed to support this higher level of abstraction by providing customizable views of the ground system combining collections of lower level information into more meaningful ways. Instead of examining frames, packets, and individual telemetry data points -- MPCS is capable of providing comprehensive summary reports, product status, overall flight/ground event status, as well as payload health summaries. Based on these higher level views, end users can make tactical or strategic decisions, or drop into detailed analysis as needed. System designers need to continue building systems that support low level GDS troubleshooting - but the basic design of a GDS should be geared towards what end users actually need to see. This paper will describe the capabilities of MPCS that directly support these higher levels of abstraction, and which are being used today in missions such as the Mars Science Laboratory and other NASA missions.

MPCS↗

NASA NTRS2020

Toward More Realistic Simulation and Prediction of Dust Storms on Mars

Major (regional and global)dust storms dominate weather and climate variability on present-day Mars. Absorption and scattering of visible and IR radiation by dust strongly affect the thermal state of the thin Mars atmosphere, while dust provides condensation nuclei for water and CO2 cloud particles, which also affect radiative fluxes. Global dust storms (GDS) occur ~three times per Mars decade and to date have been observed in only northern fall and winter,when the global circulation is strongest. Tenfold increases in column dust opacity are typical during GDS, with intense vertical motions transporting dust to far higher altitudes than usual. The key processes and feedbacks that produce GDS remain poorly understood, hence current atmospheric models fail to self-consistently simulate observed dust storm activity. This means we have no predictive capability for when GDS may occur, either now or in Mars’s past. And crucially, due to the huge impact of GDS on the atmosphere and surface, our lack of ability to simulate realistic dust storms has major implications for Mars science and exploration: from understanding the present climate (§2.1),to modeling past climates and water cycles (§2.2), to exploring how wind, water, and dust cycles varied over time to interpret geology and assess potential habitability(§2.3), to quantifying and mitigating risks posed to Mars missions (§2.4)

Claire E Newman↗

NASA NTRS2006

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↗

NASA NTRS2006

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

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

systems engineering↗

NASA NTRS2008

The Interim: Until You Achieve an Operationally Responsive Ground System

Everyone wants to achieve a 'Responsive' Ground Data System (GDS), but that takes time. What do you do in the interim? Our group, called the Integration, Test and Deployment Team (ITD), is a group of responsive engineers whose primary focus is to assist JPL projects to successfully adapt, test, integrate and deploy their ground data system. The team configures and adapts the GDS for a project, so that analysts, engineers and scientist do not need to be experts in the GDS to operate it. The team has developed a human interface to accommodate all types of users. It provides Graphical User Interfaces (GUI's) for those that want GUI's, command line interfaces for those that want control, and selection button interfaces for other users. The cornerstone of a responsive Ground Data System is responsive people. Without individuals who can be aware of a project's changing needs and requirements, how can the GDS become responsive?.

Ground Data System (GDS)↗

NASA NTRS2008

The Interim : until you achieve an operationally responsive ground system

ground data system (GDS)↗

NASA NTRS2006

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

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

Ground Data System (GDS)↗

DOE OSTI2025

Optimizing fused silica debris shield use in the National Ignition Facility

The National Ignition Facility (NIF) deliberately and routinely operates with its final optics exposed to fluences likely to induce and grow damage. This choice has enabled the NIF to operate at energies previously unachievable at the expense of limitations to delivered power and energy contingent on the ability to repair damage on the final optics. Prior to the introduction of the fused silica debris shield (FSDS), the grating debris shield (GDS) was the optic type on the NIF most prone to damage and hence a primary limiter to the delivered energy. The introduction of the FSDS has reduced the damage initiation rate on the GDS by about two orders of magnitude to date. Despite the FSDS being a disposable optic, it is important to understand how the FSDS damages and when its damage requires it to be exchanged to maximize the FSDS lifetime while still protecting the GDS from damage. We will define the FSDS exchange criteria and evaluate the damage initiation mechanisms of the FSDS. The surface damage morphologies provide insight into the impact of the various damage mechanisms that limit the FSDS lifetime. These results are utilized in our analysis to optimize the FSDS exchange criteria to further extend the GDS lifetime.

42 ENGINEERING↗

NASA NTRSDate not supplied

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↗

NASA NTRS1973

System design of the Pioneer Venus spacecraft. Volume 8: Command/data handling subsystems studies

Study tasks for the command and data handling subsystems have been directed to: (1) determining ground data systems, (GDS) interfaces and deep space network (DSN) changes, if required, (2) defining subsystem requirements, (3) surveying existing hardware that could be used or modified to meet subsystem requirements, and (4) establishing a baseline design. Study of the existing GDS led to the conclusion that the Viking configuration GDS can be used with only minor changes required for the Pioneer Venus baseline. Those changes required are associated with providing a predetection recording capability used during probe entry and descent. Subsystem requirements were first formulated with sufficient latitude so that surveys of existing hardware could lead to low cost hardware which, in turn, could modify more narrowly defined subsystem requirements.

Vesely, D. D.↗

NASA NTRS2006

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↗

NASA NTRS2016

Use of a Small Unmanned Aircraft System for Autonomous Fire Spotting at the Great Dismal Swamp

This paper describes the results of a set of experiments and analyses conducted to evaluate the capability of small unmanned aircraft systems (sUAS) to spot nascent fires in the Great Dismal Swamp (GDS) National Wildlife Refuge. This work is the result of a partnership between the National Aeronautics and Space Administration and the US Fish and Wildlife service specifically to investigate sUAS usage for fire-spotting. The objectives of the current effort were to: 1) Determine suitability and utility of low-cost Small Unmanned Aircraft Systems (sUAS) to detect nascent fires at GDS; 2) Identify and assess the necessary National Airspace System (NAS) integration issues; and 3) Provide information to GDS and the community on system requirements and concepts-of-operation (CONOPS) for conducting fire detection/support mission in the National Airspace and (4) Identify potential applications of intelligent autonomy that would enable or benefit this high-value mission. In addition, data on the ability of various low-cost sensors to detect smoke plumes and fire hot spots was generated during the experiments as well as identifying a path towards a future practical mission utility by using sUAS in beyond visual-line-of-sight operation in the National Airspace System (NAS).

Logan, Michael J.↗

NASA NTRS2021

Automated Data Accountability for Missions in Mars Rover Data

As the Mars Curiosity Rover transmits data to the JPL Ground Data System (GDS), it frequently observes data loss and corruption, requiring re-transmits from the rover and Ground Data System Analysts (GDSA) to monitor the downlink process. As new missions are launched, the GDSA team redistributes analysts to these new missions, causing shortages in previous missions. The GDSA team can significantly benefit from the automation and optimization of the downlink process of telemetry data. In fact, there is a need for a better understanding of why the data is corrupted, so that the GDSA team can best determine the root cause of the issues in the GDS. This paper presents machine learning and deep learning based approaches to automate and optimize the detection of data loss. We first created a pipeline to automatically accumulate data from the telemetry databases (MAROS, Telemetry Data Storage, and GDS Elastic Search Database) in the downlink process. With our newly created datasets, we perform feature selection to supplement the GDSA understanding of the downlink process and provide supplemental analysis on the importance of different features. We implement various machine learning and deep learning based models, including support vector machines, ensemble methods, and deep neural networks and evaluate their accuracies in identifying whether a downlink process is complete or incomplete. We utilize fast hyperparameter optimization methods that allow our models to quickly be re-trained, allowing them to quickly be tuned and optimized on daily incoming data in real time. This hyperparameter optimization also allows our methods to be quickly integrated into other JPL missions. Our results show that our best-performing machine learning and deep learning based models outperform the existing GDSA detection software by 6 accuracy points and can aid analysts by providing insights into the data accountability problem. Since these various machine learning and deep learning approaches vary significantly in interpretability, we provide a discussion on the tradeoffs between their performance and trustworthiness in helping detect issues in data transmission.

Divsalar, Dariush↗

NASA NTRS2024

Pressure Deficit in Gale Crater and a Larger Northern Polar Cap After the MY34 Global Dust Storm

We describe the model-independent analysis technique of Mars Science Laboratory (MSL) pressure and Mars Climate Sounder (MCS) data in de la Torre Juárez et al. (2019, https://doi.org/10.22541/essoar.169945479.90436599/v1) that compared multiple years of surface pressures on Gale before, during, and after the Global Dust Storm of Mars Year 34. The analysis found (a) representative pressure scale heights over Gale; (b) that the storm was followed by a pressure deficit at Gale; (c) the following C storms did not eliminate the deficit; (d) changes in the duration of the polar caps condensation seasons, with an early start of the North Polar (NP) ice cap growing season the year before the Great Dust Storm (GDS) and a late signature of the end of the expansion season thereafter, changes consistent with a larger growth phase of the NP cap; (e) MCS observed a larger than usual NP cap; and (f) cold temperature anomalies over the NP and warm over the Southern Pole after the storm. We also show that the analysis of observed MSL pressure data alone filters out effects on the pressure signal that are attributable to dynamical and orographic processes in a recent model analysis that makes similar interpretations as our 2019 study. One additional Mars year of observations is included to eliminate early concerns about sensor drifts. Noting that a similar NP anomaly was observed with MCS data after the last early GDS in MY25, and not the later GDS of MY27, the results suggest a possible unique effect of early GDSs.

Manuel de la Torre Juárez↗

DOE OSTI2024

Impact of fused silica debris shields and enhanced mitigation techniques on large-aperture beam-sampling optics for the National Ignition Facility

Here, we show that the large-scale routine use of the fused silica debris shield (FSDS) maintains the ∼100× reduction in damage initiation rate and 70% increase in the install lifetime of a new grating debris shield (GDS) observed during pilot operations. Furthermore, we show that the install lifetimes of recycled GDS optics are nearly tripled using additional mitigation strategies such as expanding mitigation processing to include all damage sites larger than 10 μm (LT10) rather than just larger than 50 μm (LT50) and FSDS. We note that there is still a 50% difference between new and recycled optic installation lifetimes. We show that recycled optics have a 3.5× higher apparent initiation rate than new optics when exposed to nominally identical laser conditions.

FSDS↗

NASA NTRS2012

Using Quality Attributes to Bridge Systems Engineering Gaps : A Juno Ground Data Systems Case Study

The Juno Mission to Jupiter is the second mission selected by the NASA New Frontiers Program. Juno launched August 2011 and will reach Jupiter July 2016. Juno's payload system is composed of nine instruments plus a gravity science experiment. One of the primary functions of the Juno Ground Data System (GDS) is the assembly and distribution of the CFDP (CCSDS File Delivery Protocol) product telemetry, also referred to as raw science data, for eight out of the nine instruments. The GDS accomplishes this with the Instrument Data Pipeline (IDP). During payload integration, the first attempt to exercise the IDP in a flight like manner revealed that although the functional requirements were well understood, the system was unable to meet latency requirements with the as-is heritage design. A systems engineering gap emerged between Juno instrument data delivery requirements and the assumptions behind the heritage flight-ground interactions. This paper describes the use of quality attributes to measure and overcome this gap by introducing a new systems engineering activity, and a new monitoring service architecture that successfully delivered the performance metrics needed to validate Juno IDP.

Ground Data Systems (GDS)↗

NASA NTRS1977

Life sciences Spacelab Mission Development test 3 (SMD 3) data management report

Development of a permanent data system for SMD tests was studied that would simulate all elements of the shuttle onboard, telemetry, and ground data systems that are involved with spacelab operations. The onboard data system (ODS) and the ground data system (GDS) were utilized. The air-to-ground link was simulated by a hardwired computer-to-computer interface. A patch board system was used on board to select experiment inputs, and the downlink configuration from the ODS was changed by a crew keyboard entry to support each experiment. The ODS provided a CRT display of experiment parameters to enable the crew to monitor experiment performance. An onboard analog system, with recording capability, was installed to handle high rate data and to provide a backup to the digital system. The GDS accomplished engineering unit conversion and limit sensing, and provided realtime parameter display on CRT's in the science monitoring area and the test control area.

Moseley, E. C.↗