Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “user support”

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 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Data Model Management for Space Information Systems

The Reference Architecture for Space Information Management (RASIM) suggests the separation of the data model from software components to promote the development of flexible information management systems. RASIM allows the data model to evolve independently from the software components and results in a robust implementation that remains viable as the domain changes. However, the development and management of data models within RASIM are difficult and time consuming tasks involving the choice of a notation, the capture of the model, its validation for consistency, and the export of the model for implementation. Current limitations to this approach include the lack of ability to capture comprehensive domain knowledge, the loss of significant modeling information during implementation, the lack of model visualization and documentation capabilities, and exports being limited to one or two schema types. The advent of the Semantic Web and its demand for sophisticated data models has addressed this situation by providing a new level of data model management in the form of ontology tools. In this paper we describe the use of a representative ontology tool to capture and manage a data model for a space information system. The resulting ontology is implementation independent. Novel on-line visualization and documentation capabilities are available automatically, and the ability to export to various schemas can be added through tool plug-ins. In addition, the ingestion of data instances into the ontology allows validation of the ontology and results in a domain knowledge base. Semantic browsers are easily configured for the knowledge base. For example the export of the knowledge base to RDF/XML and RDFS/XML and the use of open source metadata browsers provide ready-made user interfaces that support both text- and facet-based search. This paper will present the Planetary Data System (PDS) data model as a use case and describe the import of the data model into an ontology tool. We will also describe the current effort to provide interoperability with the European Space Agency (ESA)/Planetary Science Archive (PSA) which is critically dependent on a common data model.

RDF↗
NASA NTRS2007

Lessons Learned from Deploying an Analytical Task Management Database

Defining requirements, missions, technologies, and concepts for space exploration involves multiple levels of organizations, teams of people with complementary skills, and analytical models and simulations. Analytical activities range from filling a To-Be-Determined (TBD) in a requirement to creating animations and simulations of exploration missions. In a program as large as returning to the Moon, there are hundreds of simultaneous analysis activities. A way to manage and integrate efforts of this magnitude is to deploy a centralized database that provides the capability to define tasks, identify resources, describe products, schedule deliveries, and generate a variety of reports. This paper describes a web-accessible task management system and explains the lessons learned during the development and deployment of the database. Through the database, managers and team leaders can define tasks, establish review schedules, assign teams, link tasks to specific requirements, identify products, and link the task data records to external repositories that contain the products. Data filters and spreadsheet export utilities provide a powerful capability to create custom reports. Import utilities provide a means to populate the database from previously filled form files. Within a four month period, a small team analyzed requirements, developed a prototype, conducted multiple system demonstrations, and deployed a working system supporting hundreds of users across the aeros pace community. Open-source technologies and agile software development techniques, applied by a skilled team enabled this impressive achievement. Topics in the paper cover the web application technologies, agile software development, an overview of the system's functions and features, dealing with increasing scope, and deploying new versions of the system.

O'Neil, Daniel A.↗
NASA NTRS2007

Model Checker for Java Programs

Java Pathfinder (JPF) is a verification and testing environment for Java that integrates model checking, program analysis, and testing. JPF consists of a custom-made Java Virtual Machine (JVM) that interprets bytecode, combined with a search interface to allow the complete behavior of a Java program to be analyzed, including interleavings of concurrent programs. JPF is implemented in Java, and its architecture is highly modular to support rapid prototyping of new features. JPF is an explicit-state model checker, because it enumerates all visited states and, therefore, suffers from the state-explosion problem inherent in analyzing large programs. It is suited to analyzing programs less than 10kLOC, but has been successfully applied to finding errors in concurrent programs up to 100kLOC. When an error is found, a trace from the initial state to the error is produced to guide the debugging. JPF works at the bytecode level, meaning that all of Java can be model-checked. By default, the software checks for all runtime errors (uncaught exceptions), assertions violations (supports Java s assert), and deadlocks. JPF uses garbage collection and symmetry reductions of the heap during model checking to reduce state-explosion, as well as dynamic partial order reductions to lower the number of interleavings analyzed. JPF is capable of symbolic execution of Java programs, including symbolic execution of complex data such as linked lists and trees. JPF is extensible as it allows for the creation of listeners that can subscribe to events during searches. The creation of dedicated code to be executed in place of regular classes is supported and allows users to easily handle native calls and to improve the efficiency of the analysis.

Visser, Willem↗
NASA NTRS2010

Extracting Oxygen from Lunar Simulant Using a Transparent Furnace Pulsed Fluidized Bed

In the event that humans return to the moon, utilizing the local materials will be beneficial for extended stays. Rather than transporting resources, such as oxygen, from Earth, NASA is investigating methods of extracting it from lunar regolith. One promising process is hydrogen reduction. In the hydrogen reduction process, lunar regolith is heated to 1000 C in the presence of hydrogen. The iron oxide (Fe-O) bonds, found in lunar material, are broken and the hydrogen attracts the oxygen to produce water vapor [Allen et al., 1996]. FeO + H2 (right arrow) Fe +H2O. The water vapor is then captured, cleaned, and electrolyzed. The hydrogen is recycled back to the reduction process and the oxygen is stored until consumed by an end user (propulsion, life support, etc.). To obtain a good oxygen yield, the majority of lunar regolith must be exposed to the hydrogen gas and have a high rate of heat transfer from heat source to particle. This is achieved with good solids mixing via fluidization or mechanical agitation. In Generation II of the ROxygen program, the ROxygen Team at Johnson Space Center (JSC) investigated the feasibility of gas only pulsed fluidization as the only means to mix synthetic lunar regolith (simulant) at high temperatures. Fluidized beds have been used in industry to effectively process powders for decades. They consist of gas flowing upward through a bed of particles. The stirring action continuously moves the grains around to achieve uniform mixing of gas, solids, and heat [Geldart, 1986]. A transparent furnace unit was developed by Thoughventions Unlimited LLC (TvU) to aid in the qualitative observation of the fluidization behavior at high temperatures. Multipoint thermocouples and pressure sensors provided quantitative information regarding the quality of mixing. The water produced was measured using humidity sensors and captured using a NASA designed and built condenser. Once the simulant was processed, pneumatically transporting the 'hot' simulant out of the furnace was investigated.

Oryshchyn, L.↗
NASA NTRS2010

4-D Cloud Water Content Fields Derived from Operational Satellite Data

In order to improve operational safety and efficiency, the transportation industry, including aviation, has an urgent need for accurate diagnoses and predictions of clouds and associated weather conditions. Adverse weather accounts for 70% of all air traffic delays within the U.S. National Airspace System. The Federal Aviation Administration has determined that as much as two thirds of weather-related delays are potentially avoidable with better weather information and roughly 20% of all aviation accidents are weather related. Thus, it is recognized that an important factor in meeting the goals of the Next Generation Transportation System (NexGen) vision is the improved integration of weather information. The concept of a 4-D weather cube is being developed to address that need by integrating observed and forecasted weather information into a shared 4-D database, providing an integrated and nationally consistent weather picture for a variety of users and to support operational decision support systems. Weather analyses and forecasts derived using Numerical Weather Prediction (NWP) models are a critical tool that forecasters rely on for guidance and also an important element in current and future decision support systems. For example, the Rapid Update Cycle (RUC) and the recently implemented Rapid Refresh (RR) Weather Research and Forecast (WRF) models provide high frequency forecasts and are key elements of the FAA Aviation Weather Research Program. Because clouds play a crucial role in the dynamics and thermodynamics of the atmosphere, they must be adequately accounted for in NWP models. The RUC, for example, cycles at full resolution five cloud microphysical species (cloud water, cloud ice, rain, snow, and graupel) and has the capability of updating these fields from observations. In order to improve the models initial state and subsequent forecasts, cloud top altitude (or temperature, T(sub c)) derived from operational satellite data, surface observations of cloud base altitude, radar reflectivity, and lightning data are used to help build and remove clouds in the models assimilation system. Despite this advance and the many recent advances made in our understanding of cloud physical processes and radiative effects, many problems remain in adequately representing clouds in models. While the assimilation of cloud top information derived from operational satellite data has merit, other information is available that has not yet been exploited. For example, the vertically integrated cloud water content (CWC) or cloud water path (CWP) and cloud geometric thickness (delta Z) are standard products being derived routinely from operational satellite data. These and other cloud products have been validated under a variety of conditions. Since the uncertainties have generally been found to be less than those found in model analyses and forecasts, the satellite products should be suitable for data assimilation, provided an appropriate strategy can be developed that links the satellite-derived cloud parameters with cloud parameters specified in the model. In this paper, we briefly outline such a strategy and describe a methodology to retrieve cloud water content profiles from operational satellite data. Initial results and future plans are presented. It is expected that the direct assimilation of this new product will provide the most accurate depiction of the vertical distribution of cloud water ever produced at the high spatial and temporal resolution needed for short term weather analyses and forecasts.

Smith, William L., Jr.↗
NASA NTRS2011

Capability of the Gas Analysis and Testing Laboratory at the NASA Johnson Space Center

The Gas Analysis and Testing Laboratory is an integral part of the testing performed at the NASA Johnson Space Center. The Gas Analysis and Testing Laboratory is a high performance laboratory providing real time analytical instruments to support manned and unmanned testing. The lab utilizes precision gas chromatographs, gas analyzers and spectrophotometers to support the technology development programs within the NASA community. The Gas Analysis and Testing Laboratory works with a wide variety of customers and provides engineering support for user-specified applications in compressed gas, chemical analysis, general and research laboratory

Broerman, Craig↗
NASA NTRS2012

Capability of the Gas Analysis and Testing Laboratory at the NASA Johnson Space Center

The Gas Analysis and Testing Laboratory is an integral part of the testing performed at the NASA Johnson Space Center. The Gas Analysis and Testing Laboratory is a high performance laboratory providing real time analytical instruments to support manned and unmanned testing. The lab utilizes precision gas chromatographs, gas analyzers and spectrophotometers to support the technology development programs within the NASA community. The Gas Analysis and Testing Laboratory works with a wide variety of customers and provides engineering support for user-specified applications in compressed gas, chemical analysis, general and research laboratory.

Broerman, Craig↗
NASA NTRS2012

Imagining a Stata / Python Combination

There are occasions when a task is difficult in Stata, but fairly easy in a more general programming language. Python is a popular language for a range of uses. It is easy to use, has many high ]quality packages, and programs can be written relatively quickly. Is there any advantage in combining Stata and Python within a single interface? Stata already offers support for user-written programs, which allow extensive control over calculations, but somewhat less control over graphics. Also, except for specifying output, the user has minimal programmatic control over the user interface. Python can be used in a way that allows more control over the interface and graphics, and in so doing provide a roundabout method for satisfying some user requests (e.g., transparency levels in graphics and the ability to clear the results window). My talk will explore these ideas, present a possible method for combining Stata and Python, and give examples to demonstrate how this combination might be useful.

Fiedler, James↗
NASA NTRS2010

Request-Driven Schedule Automation for the Deep Space Network

The DSN Scheduling Engine (DSE) has been developed to increase the level of automated scheduling support available to users of NASA s Deep Space Network (DSN). We have adopted a request-driven approach to DSN scheduling, in contrast to the activity-oriented approach used up to now. Scheduling requests allow users to declaratively specify patterns and conditions on their DSN service allocations, including timing, resource requirements, gaps, overlaps, time linkages among services, repetition, priorities, and a wide range of additional factors and preferences. The DSE incorporates a model of the key constraints and preferences of the DSN scheduling domain, along with algorithms to expand scheduling requests into valid resource allocations, to resolve schedule conflicts, and to repair unsatisfied requests. We use time-bounded systematic search with constraint relaxation to return nearby solutions if exact ones cannot be found, where the relaxation options and order are under user control. To explore the usability aspects of our approach we have developed a graphical user interface incorporating some crucial features to make it easier to work with complex scheduling requests. Among these are: progressive revelation of relevant detail, immediate propagation and visual feedback from a user s decisions, and a meeting calendar metaphor for repeated patterns of requests. Even as a prototype, the DSE has been deployed and adopted as the initial step in building the operational DSN schedule, thus representing an important initial validation of our overall approach. The DSE is a core element of the DSN Service Scheduling Software (S(sup 3)), a web-based collaborative scheduling system now under development for deployment to all DSN users.

Johnston, Mark D.↗
NASA NTRS2008

Mars Interoperability 2008-2015: Options for Relay Orbiter Support to Mars Bound Assets

The current relay orbiter infrastructure at Mars, in support of the user assets presently at Mars and those scheduled for the 2008 to 2015 time frame, only have a need to store-and-forward the returned data collected by an asset to Earth as a single non-prioritized data file. In the forward direction, the relay orbiters are only required to relay the forward link data, i.e., command sequences, software and configuration information assembled on the ground, to the Asset. There are currently no requirements for status/control messages or files to be sent in the return direction from an Asset to an application located on the Relay, nor are there requirements in the forward direction to send status/control messages or files originating on a Relay to an Asset. In addition there are currently no networking requirements at Mars where data originally sent by an Asset is to be delivered to another user asset. However, we foresee the day when standard services for 1) on-board file prioritization of user asset data by a Relay, 2) control/status message transfer between assets and a Relay, and 3) networking between assets i.e., Asset to Asset message/file transfer via a Relay will be required. Each of these services will require the Relay to be capable of understanding the data type and routing needs of the user asset data and be capable of processing it for these purposes. This paper will focus on the innovative enhancements required to the existing communications infrastructure at Mars to enable these future services.

File Transfer↗
NASA NTRS2015

Use NASA GES DISC Data in ArcGIS

This presentation describes GIS relevant data at NASA Goddard Earth Sciences Data and Information Services Center (GES DISC), GES DISC Services and Support for GIS Users, and use cases of GES DISC data in ArcGIS.

data↗
NASA NTRS2018

Earthdata Cloud Analytics Project

This presentation describes a nascent project in NASA to develop a framework to support end-user analytics of NASA's Earth science data in the cloud. The chief benefit of migrating EOSDIS (Earth Observation System Data and Information Systems) data to the cloud is to position the data next to enormous computing capacity to allow end users to process data at scale. The Earthdata Cloud Analytics project will user a service-based approach to facilitate the infusion of evolving analytics technology and the integration with non-NASA analytics or other complementary functionality at other agencies and in other nations.

data services↗
NASA NTRS2018

Spaceport Command and Control System Software Development

The control system for the Space Launch System (SLS) and Orion capsule contains a multitude of displays for use in displaying information like vehicle health, sensor information, life support, etc. Currently users in the Launch Control Center (LCC) are using a list-based selection Graphical User Interface (GUI) to open various displays. However the display names are not intuitive as to what the display looks like nor what data is presented in a display. My project involves adding additional functionality to the current display selection GUI utilizing thumbnail images of each display for easy browsing. This new GUI allows users to find their desired display much faster without needing to memorize the layout of every display based only on the display's name.

Chapa, Nicholas↗
NASA NTRS2019

Evaluating Flood Forecasting System Performance in Cambodia During the 2019 Flood Season

Every year, Cambodia experiences both flash and prolonged riverine flooding as a result of monsoon rains and typhoons. Floods occur frequently in various parts of the region, and result in significant economic cost. Flood forecasting systems are designed to mitigate economic and social impacts, enabling people to prepare for extreme events. However, in order for forecasts to be used effectively, an assessment of the available forecasting systems is needed. In addition, following the onset of flooding, satellite imagery is used to generate flood maps to aid in response efforts. This study demonstrates the performance of regional and global flood forecasting systems over the 2019 flood season. To do this, we assess the flood forecast accuracy at different forecast lead times through a series of forecast verification metrics at gauge locations in Cambodia. We then compare the flood forecast performance to Sentinel 1 flood maps produced by the Hydrological Remote Sensing Analysis of Floods (HYDRAFloods) tool currently being co-developed by SERVIR-Mekong in collaboration with the Myanmar Department of Disaster Management. This assessment of the flood forecasting systems’ performance and comparison to generated flood maps helps provide context to forecasters and disaster managers as they make improvements to their models. Additionally, these results provide support to forecast users as they evaluate the strengths and weaknesses of different systems for taking action.

Nauman, Claire M.↗
NASA NTRS2020

Evaluating Flood Forecasting System Performance in Cambodia

Every year, Cambodia experiences flooding as a result of monsoon rains and typhoons. Flood forecasting systems are designed to enable people to mitigate economic and social impacts from these events. However, in order for forecasts to be used effectively, an assessment of their accuracy is needed. This study demonstrates the performance of regional and global flood forecasting systems over the 2019 flood season. To do this, we assess the flood forecast accuracy at different forecast lead times and gauge locations in Cambodia. We then compare the flood forecast performance to satellite-based flood maps produced by the Hydrological Remote Sensing Analysis of Floods (HYDRAFloods) tool currently being co-developed by SERVIR-Mekong in collaboration with the Myanmar Department of Disaster Management. This assessment of the flood forecasting systems’ performance and comparison to flood extents helps (1) provide valuable information to forecasters and disaster managers as they make improvements to their models, and (2) provides support to forecast users as they evaluate the strengths and weaknesses of different systems for taking action.

Nauman, Claire↗
NASA NTRS2020

The XRISM Science Data Center: Optimizing the Scientific Return from a Unique X-ray Observatory

The X-Ray Imaging and Spectroscopy Mission, XRISM, is currently scheduled to launch in 2022 with the objective of building on the brief, but significant, successes of the ASTRO-H (Hitomi) mission in solving outstanding astrophysical questions using high resolution X-ray spectroscopy. The XRISM Science Operations Team (SOT) consists of the JAXA-led Science Operations Center (SOC) and NASA-led Science Data Center (SDC), which work together to optimize the scientific output from the Resolve high-resolution spectrometer and the Xtend wide-field imager through planning and scheduling of observations, processing and distribution of data, development and distribution of software tools and the calibration database (CaldB), support of ground and in-flight calibration, and support of XRISM users in their scientific investigations of the energetic universe. Here, we summarize the roles and responsibilities of the SDC and its current status and future plans. The Resolve instrument poses particular challenges due to its unprecedented combination of high spectral resolution and throughput, broad spectral coverage, and relatively small field-of-view and large pixel-size. We highlight those challenges and how they are being met.

XRISM↗
NASA NTRS2022

The Mars 2020 Ground Data System Architecture

The Mars 2020 Mission’s primary objective is to collect 20 geographically unique samples during its prime mission of one and a quarter Martian years, or just over 2 Earth years. Mission planners determined the project needed to develop a system that would enable the operations team to analyze engineering and science data, make science decisions, select viable rover targets at a millimeter resolution and validate an uplink bundle for a car sized rover with more complex science instruments than any previous Mars surface mission. All this had to be done within a five hour time frame. Doing this with a small team would be a challenge, but this had to be accomplished by a large team of engineers and scientists located across North America and Europe. Achieving this level of operational efficiency was unheard of in the prime mission. In addition, the mission had another set of requirements that had nothing to do with surface operations; the Mars 2020 Ground Data System (GDS) was also expected to comply with a new set of security requirements to keep up with the ever changing cybersecurity landscape. The Mars 2020 Ground Data System (GDS) is a re-architected version of the Mars Science Laboratory GDS. The primary goal was to integrate the lessons learned from previous Mars surface missions, accommodate a set of new requirements and capabilities required to ensure mission success, and comply with a new set of cybersecurity controls. The new architecture includes several unique qualities including a data lake, language-agnostic system-wide event-based operations, containerization, automated deployment, network segmentation, infrastructure-as-code, API-driven interfaces, and the first Mars surface GDS to operate primarily in the cloud. The new architecture enabled greater access to the system’s data, tighter integration with the operations team, and a higher level of traceability. The availability of the data also enabled a new set of capabilities previously not possible on surface missions. These new capabilities include an autonomous data to information, pipeline for downlink analysis, horizontal scaling of science data processing capabilities, autonomous round trip data tracking of science and engineering data, integration of flight system state into the tactical planning cycle, high fidelity targeting utilizing kinematic data, and hierarchical image and 3d meshes data representations. This paper will introduce the requirements for the Mars 2020 Mission, the heritage architecture, and the rationale for the changes to achieve the new architecture. The paper will continue to describe the fundamental changes made to the GDS architecture, how these changes enabled a more tightly integrated GDS, and the new capabilities that were enabled by the new architecture. The paper will conclude with the lessons learned from the process of rearchitecting a heritage GDS system and from the first 200 days of operations supporting over 800 users from around the world.

Lopez-Roig, Reynaldo↗