Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “standardized data”

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 991 records · Page 55

An analysis of maximum horizontal wind speeds and associated parameters recorded at NASA's 150-Meter Ground Winds Tower facility at Kennedy Space Center, Florida

Continuous horizontal wind speed measurements were processed and classified as a function of tower level (10, 18, 60, and 150 meters) and period of reference day, month, season: winter (October through March) and summer (April through September), and annual. Tabulations were made of the daily maximum horizontal wind speed, time of ocurrence, and five associated parameters: mean horizontal wind speed, maximum vertical gusts (i.e., updraft and downdraft), and mean and instantaneous directions. Analyses using these data included means, extremes, standard deviations, and frequency distributions. Comparisons of intensity of maximum horizontal wind speeds determined in this year of data are made with maximum values recorded at Kennedy Space Center during another non-hurricane-occurrence year (1967) and with values during 1966 through 1972 when six hurricanes affected the area after the Ground Winds Tower facility became operational. Wind flow in the lowest 150 meters of the atmosphere was measured for the identification of hazards involved in wind shear encounter relative to ascent and descent of the space shuttle and conventional aircraft.

Alexander, M. B.↗

Evolution of the Next Exploration Toilet through Human-in-the-Loop (HITL) Testing

Human waste collection in space is a unique and necessary function that all crewmembers must perform. The variability in how each crewmember uses the toilet to urinate and defecate introduces complexities and challenges with regards to overall hardware design. Because of this variability, it is important to consider crew inputs in all aspects of a toilet design especially with regards to crew interfaces that could impact overall waste collection. Access to crew feedback is essential to the design process and should be considered early and often through the various design phases. In 2020, NASA started a project for the Human Landing System (HLS) program to develop a Government Furnished Equipment (GFE) toilet option. The project is known as the Lavatory On-Orbit (LOO). During the early development of the LOO, the project team conducted several crew evaluations to collect and summarize valuable crew feedback on system design, function, and overall usability to influence the next design iteration. Because every person could use the system differently in space, it was extremely important to collect and analyze the data in a very methodical manner to appropriately influence the design based on the evaluation results. Establishing a standard process ensures consistent data collection from one evaluation to another, helps to maintain privacy for each test subject’s inputs and removes any potential bias from test subject to test subject. To date, the team has completed four crew evaluations on prototypes for the different LOO hardware. This paper will summarize the methodology used to conduct the evaluations as well as how data was collected and analyzed. The paper will also provide details on each of the evaluations and how the design was updated based on the results.

toilet↗

Evolution of the Next Exploration Toilet Through Human-in-the-Loop (HITL) Testing

Human waste collection in space is a unique and necessary function that all crewmembers must perform. The variability in how each crewmember uses the toilet to urinate and defecate introduces complexities and challenges with regards to overall hardware design. Because of this variability, it is important to consider crew inputs in all aspects of a toilet design especially with regards to crew interfaces that could impact overall waste collection. Access to crew feedback is essential to the design process and should be considered early and often through the various design phases. In 2020, NASA started a project for the Human Landing System (HLS) program to develop a Government Furnished Equipment (GFE) toilet option. The project is known as the Lavatory On-Orbit (LOO). During the early development of the LOO, the project team conducted several crew evaluations to collect and summarize valuable crew feedback on system design, function, and overall usability to influence the next design iteration. Because every person could use the system differently in space, it was extremely important to collect and analyze the data in a very methodical manner to appropriately influence the design based on the evaluation results. Establishing a standard process ensures consistent data collection from one evaluation to another, helps to maintain privacy for each test subject’s inputs and removes any potential bias from test subject to test subject. To date, the team has completed four crew evaluations on prototypes for the different LOO hardware. This paper will summarize the methodology used to conduct the evaluations as well as how data was collected and analyzed. The paper will also provide details on each of the evaluations and how the design was updated based on the results.

toilet↗

Evolution of the Next Exploration Toilet Through Human-in-the-Loop (HITL) Testing

Human waste collection in space is a unique and necessary function that all crewmembers must perform. The variability in how each crewmember uses the toilet to urinate and defecate introduces complexities and challenges with regards to overall hardware design. Because of this variability, it is important to consider crew inputs in all aspects of a toilet design especially with regards to crew interfaces that could impact overall waste collection. Access to crew feedback is essential to the design process and should be considered early and often through the various design phases. In 2020, NASA started a project for the Human Landing System (HLS) program to develop a Government Furnished Equipment (GFE) toilet option. The project is known as the Lavatory On-Orbit (LOO). During the early development of the LOO, the project team conducted several crew evaluations to collect and summarize valuable crew feedback on system design, function, and overall usability to influence the next design iteration. Because every person could use the system differently in space, it was extremely important to collect and analyze the data in a very methodical manner to appropriately influence the design based on the evaluation results. Establishing a standard process ensures consistent data collection from one evaluation to another, helps to maintain privacy for each test subject’s inputs and removes any potential bias from test subject to test subject. To date, the team has completed four rounds of crew evaluations with multiple crewmembers on prototypes for the different LOO subsystems. This paper will summarize the methodology used to conduct the evaluations as well as how data was collected and analyzed. The paper will also provide details on each of the evaluations and how the design was updated based on the results.

toilet↗

Evolution of the Next Exploration Toilet Through Human-in-the-Loop (HITL) Testing

Human waste collection in space is a unique and necessary function that all crewmembers must perform. The variability in how each crewmember uses the toilet to urinate and defecate introduces complexities and challenges with regards to overall hardware design. Because of this variability, it is important to consider crew inputs in all aspects of a toilet design especially with regards to crew interfaces that could impact overall waste collection. Access to crew feedback is essential to the design process and should be considered early and often through the various design phases. In 2020, NASA started a project for the Human Landing System (HLS) program to develop a Government Furnished Equipment (GFE) toilet option. The project is known as the Lavatory On-Orbit (LOO). During the early development of the LOO, the project team conducted several crew evaluations to collect and summarize valuable crew feedback on system design, function, and overall usability to influence the next design iteration. Because every person could use the system differently in space, it was extremely important to collect and analyze the data in a very methodical manner to appropriately influence the design based on the evaluation results. Establishing a standard process ensures consistent data collection from one evaluation to another, helps to maintain privacy for each test subject’s inputs and removes any potential bias from test subject to test subject. To date, the team has completed four rounds of crew evaluations with multiple crewmembers on prototypes for the different LOO subsystems. This paper will summarize the methodology used to conduct the evaluations as well as how data was collected and analyzed. The paper will also provide details on each of the evaluations and how the design was updated based on the results.

toilet↗

Utilization of spaceborne SAR data for mapping

Recent developments in automated processing of digital SEASAT SAR imagery have made feasible the generation of large-scale high-resolution maps. Standard preprocessing of raw data into digital images results in geometrically distorted imagery. Computer algorithms have been developed for unsupervised pixel location, geometric rectification, and mosaicking of multiple-image frames without ground control points. These algorithms utilize knowledge of the spacecraft trajectory data, the imaging geometry, and the coherent properties of the sensor to generate the required processing parameters. This paper discusses the advantages as well as the inherent limitations of this technique, analyzes the associated errors, and presents results using SEASAT SAR imagery. Also discussed are the results of the recent shuttle imaging radar (SIR-A) experiment as well as a follow-on experiment (SIR-B) planned for 1984.

Curlander, J. C.↗

Task four report: Telemetry, command, and data handling

An overview of the telemetry, command, and data handling features of four spacecraft developed under GSFC management is presented. Two of these spacecraft ATS and SMS, are designed for geostationary orbit; the other two OSO and ERTS, are designed for low earth orbits. The program time spans for these spacecraft are as shown. The programs are seen to be near contemporary, especially in the 1973, 1974 period. All of the spacecraft listed were developed under GSFC control and are thus subject to the standards set forth in the Aerospace Data System Standard developed by GSFC. These standards must be adhered to by all spacecraft programs under GSFC control or utilizing STDN unless waivers have been granted. The standards were developed to maximize the utilization of the large amount of standard equipment at each STDN ground facility. The standards impose bounds on both the command and telemetry formats to be compatible with the STDN ground station unless valid and acceptable reasons are raised to deviate from these restraints.

Source record↗

Recent Updates to the CFD General Notation System (CGNS)

The CFD General Notation System (CGNS) - a general, portable, and extensible standard for the storage and retrieval of computational fluid dynamics (CFD) analysis data has been in existence for more than a decade (Version 1.0 was released in May 1998). Both structured and unstructured CFD data are covered by the standard, and CGNS can be easily extended to cover any sort of data imaginable, while retaining backward compatibility with existing CGNS data files and software. Although originally designed for CFD, it is readily extendable to any field of computational analysis. In early 2011, CGNS Version 3.1 was released, which added significant capabilities. This paper describes these recent enhancements and highlights the continued usefulness of the CGNS methodology.

Rumsey, Christopher L.↗

Method and Apparatus for Processing UDP Data Packets

A method and apparatus for processing a plurality of data packets. A data packet is received. A determination is made as to whether a portion of the data packet follows a selected digital recorder standard protocol based on a header of the data packet. Raw data in the data packet is converted into human-readable information in response to a determination that the portion of the data packet follows the selected digital recorder standard protocol.

Murphy, Brandon M.↗

The Role of Metadata Standards in EOSDIS Search and Retrieval Applications

Metadata standards play a critical role in data search and retrieval systems. Metadata tie software to data so the data can be processed, stored, searched, retrieved and distributed. Without metadata these actions are not possible. The process of populating metadata to describe science data is an important service to the end user community so that a user who is unfamiliar with the data, can easily find and learn about a particular dataset before an order decision is made. Once a good set of standards are in place, the accuracy with which data search can be performed depends on the degree to which metadata standards are adhered during product definition. NASA's Earth Observing System Data and Information System (EOSDIS) provides examples of how metadata standards are used in data search and retrieval.

Pfister, Robin↗

Real Data and Rapid Results: Ocean Color Data Analysis with Giovanni (GES DISC Interactive Online Visualization and ANalysis Infrastructure)

The NASA Goddard Earth Sciences Data and Information Services Center (GES DISC) has taken a major step addressing the challenge of using archived Earth Observing System (EOS) data for regional or global studies by developing an infrastructure with a World Wide Web interface which allows online, interactive, data analysis: the GES DISC Interactive Online Visualization and ANalysis Infrastructure, or "Giovanni." Giovanni provides a data analysis environment that is largely independent of underlying data file format. The Ocean Color Time-Series Project has created an initial implementation of Giovanni using monthly Standard Mapped Image (SMI) data products from the Sea-viewing Wide Field-of-view Sensor (SeaWiFS) mission. Giovanni users select geophysical parameters, and the geographical region and time period of interest. The system rapidly generates a graphical or ASCII numerical data output. Currently available output options are: Area plot (averaged or accumulated over any available data period for any rectangular area); Time plot (time series averaged over any rectangular area); Hovmeller plots (image view of any longitude-time and latitude-time cross sections); ASCII output for all plot types; and area plot animations. Future plans include correlation plots, output formats compatible with Geographical Information Systems (GIs), and higher temporal resolution data. The Ocean Color Time-Series Project will produce sensor-independent ocean color data beginning with the Coastal Zone Color Scanner (CZCS) mission and extending through SeaWiFS and Moderate Resolution Imaging Spectroradiometer (MODIS) data sets, and will enable incorporation of Visible/lnfrared Imaging Radiometer Suite (VIIRS) data, which will be added to Giovanni. The first phase of Giovanni will also include tutorials demonstrating the use of Giovanni and collaborative assistance in the development of research projects using the SeaWiFS and Ocean Color Time-Series Project data in the online Laboratory for Ocean Color Users (LOCUS). The synergy of Giovanni with high-quality ocean color data provides users with the ability to investigate a variety of important oceanic phenomena, such as coastal primary productivity related to pelagic fisheries, seasonal patterns and interannual variability, interdependence of atmospheric dust aerosols and harmful algal blooms, and the potential effects of climate change on oceanic productivity.

Acker, J. G.↗

Development of Level of Detail System and First-Person Camera for the GCAS Visualization Suite

The use of data-driven simulations has become standard practice as part of planning for future space missions. These simulations allow visualizing the data interactively to show what the data represents, as well as the importance of the data in the context of the mission. Using this visualized data can enhance users’ understanding of it and accelerate analysis efforts related to missions planned around it. Three-dimensional (3D) visualization software was developed to allow creating 3D representations of various communication systems, as well as the physical terrain of the Moon, for upcoming missions. The goal of this software development effort was to create interactive visualization capabilities in the Glenn Research Center Communication Analysis Suite (GCAS) using data exported from MATLAB® (MathWorks, Inc.) scripts. This software had the functionality to visualize the line of sight and dynamic link margins of the communication satellites orbiting the Earth and the Moon. One important addition to this was the visualization of the terrain data located within the GeoTIFF files, which were produced in an effort to understand the Moon’s terrain. Proper displacement values of this data have to be visualized to showcase where craters are located and how the shadow casting works with said craters at different points of the day, as well as analysis of possible landing sites for future lunar expeditions. The graphics library coded in JavaScript, three.js, had been previously selected for developing this visualization software. The software was revised to conform to modern standards, then further developed to convert the MATLAB® data into JavaScript 3D objects and Blender GL Transmission Format Binary file (GLB) objects, which were to be imported into the scene. In the process, a variety of other testing projects were created to be combined with this project at a later point; these included the first-person camera movements around spherical objects to portray human movement around the Moon, GeoTIFF loading methods, data transfer methods for incorporating the elevation data into the scene, and level of detail (LOD) capabilities to decrease memory usage and rendering time.

Visualization↗

A Deterministic Annealing Approach to Clustering AIRS Data

We will examine the validity of means and standard deviations as a basis for climate data products. We will explore the conditions under which these two simple statistics are inadequate summaries of the underlying empirical probability distributions by contrasting them with a nonparametric, method called Deterministic Annealing technique

clustering↗

The SPASE Data Model for Heliophysics Data: Is it Working?

The Space Physics Archive Search and Extract (SPASE) Data Model was developed to provide a metadata standard for describing Heliophysics (Space and Solar Physics) data within that science discipline. The SPASE Data Model has matured over the many years of its creation and is presently represented by Version 2.2.1. Information about SPASE can be obtained from the website group.org. The Data Model defines terms and values as well as the relationships between them in order to describe the data resources in the Heliophysics data environment. This data environment is quite complex, consisting of Virtual Observatories, Resident Archives, Data Providers, Partnering Data Centers, Services, Final Archives, and a Deep Archive. SPASE is the metadata language standard intended to permeate the complexity and provide a common method of obtaining and understanding data. Is it working in this capacity? SPASE has been used to describe a wide range of data. Examples range from ground-based magnetometer data to interplanetary satellite measurements to space weather model results. Has it achieved the goal of making the data easier to find and use? To find data of interest it is necessary that all the data of importance be described using the SPASE Data Model. Within the part of the data community associated with NASA (supported through NASA funding) there are obligations to use SPASE and (0 describe the old and new data using the SPASE XML schema. Although this pan of the community is not near 100% compliance with the mandate, there is good progress being made and the goal should be reachable in the future. Outside of the NASA data community there is still work to be done to convince the international community that SPASE descriptions are w011h the cost of their generation. Some of these groups such as Cluster, HELlO, GAIA, NOAA/NGDe. CSSDP, VSTO, SuperMAG, and IUGONET have agreed to use SPASE. but there are still other groups of importance that need (0 be reached. It is also assumed that the terminology is sufficiently broad and the descriptions are sufficiently complete that researchers needing data of a specific type or from a specific period can find and acquire what they need. A valid SPASE description can be very brief or very thorough depending on the willingness of the author to spend the time necessary to make the description useful. There is evidence that users are finding what they need through the SPASE descriptions, and this standard is a big step forward in Heliophysics data location. Does SPASE make it easier to use the data once they are found,) Thorough descriptions of data using SPASE can describe the data down to the level of individual parameters and exactly how the data are organized and stored. Should the SPASE data descriptions be written in such a way that they can be automatically ingested and understood by software tools'? Heliophysics instruments are becoming morc versatile all the time and the complexity of the data makes it tedious and time consuming to write SPASE descriptions with this level of sophistication even with the improvement of the tools used to generate the descriptions. Is it better to just write human-readable descriptions of the data at the parameter level or to refer to references that provide this information? This is a debate that is presently taking place and software is being developed to test what is possible.

Thieman, James↗

Analyses of requirements for computer control and data processing experiment subsystems. Volume 2: ATM experiment S-056 image data processing system software development

The IDAPS (Image Data Processing System) is a user-oriented, computer-based, language and control system, which provides a framework or standard for implementing image data processing applications, simplifies set-up of image processing runs so that the system may be used without a working knowledge of computer programming or operation, streamlines operation of the image processing facility, and allows multiple applications to be run in sequence without operator interaction. The control system loads the operators, interprets the input, constructs the necessary parameters for each application, and cells the application. The overlay feature of the IBSYS loader (IBLDR) provides the means of running multiple operators which would otherwise overflow core storage.

Source record↗

Geometric and radiometric characterization of LANDSAT-D thematic mapper and multispectral scanner data

A geometrically raw image of Washington, D.C. was acquired and radiometrically corrected. The data show little of the detector stripping common in earlier MSS images. The radiometrically corrected data have uniform means and standard deviations for the detectors in each band; however, the data for different detectors utilize a different pattern of DN levels, resulting in ubiquitous stripping of 1 DN amplitude. Band-to-band registration was assessed using color composites and small area correlation techniques. The spectral equivalency of the first four bands of the thematic mapper with the four bands of the MSS is being examined. Geometric analysis of the Washington, D.C. scene have started and a generalized routine for examining the contents of the label files and nonvideo data files was implemented. Several discrepancies from the documentation are described. Night scenes and daytime ocean scenes required for radiometric purposes were identified and the data ordered.

Kieffer, H. H.↗

Updates of Land Surface and Air Quality Products in NASA MAIRS and NEESPI Data Portals

Following successful support of the Northern Eurasia Earth Sciences Partner Initiative (NEESPI) project with NASA satellite remote sensing data, from Spring 2009 the NASA GES DISC (Goddard Earth Sciences Data and Information Services Center) has been working on collecting more satellite and model data to support the Monsoon Asia Integrated Regional Study (MAIRS) project. The established data management and service infrastructure developed for NEESPI has been used and improved for MAIRS support.Data search, subsetting, and download functions are available through a single system. A customized Giovanni system has been created for MAIRS.The Web-based on line data analysis and visualization system, Giovanni (Goddard Interactive Online Visualization ANd aNalysis Infrastructure) allows scientists to explore, quickly analyze, and download data easily without learning the original data structure and format. Giovanni MAIRS includes satellite observations from multiple sensors and model output from the NASA Global Land Data Assimilation System (GLDAS), and from the NASA atmospheric reanalysis project, MERRA. Currently, we are working on processing and integrating higher resolution land data in to Giovanni, such as vegetation index, land surface temperature, and active fire at 5km or 1km from the standard MODIS products. For data that are not archived at the GESDISC,a product metadata portal is under development to serve as a gateway for providing product level information and data access links, which include both satellite, model products and ground-based measurements information collected from MAIRS scientists.Due to the large overlap of geographic coverage and many similar scientific interests of NEESPI and MAIRS, these data and tools will serve both projects.

Shen, Suhung↗

Web Coverage Service Challenges for NASA's Earth Science Data

In an effort to ensure that data in NASA's Earth Observing System Data and Information System (EOSDIS) is available to a wide variety of users through the tools of their choice, NASA continues to focus on exposing data and services using standards based protocols. Specifically, this work has focused recently on the Web Coverage Service (WCS). Experience has been gained in data delivery via GetCoverage requests, starting out with WCS v1.1.1. The pros and cons of both the version itself and different implementation approaches will be shared during this session. Additionally, due to limitations with WCS v1.1.1 ability to work with NASA's Earth science data, this session will also discuss the benefit of migrating to WCS 2.0.1 with EO-x to enrich this capability to meet a wide range of anticipated user's needs This will enable subsetting and various types of data transformations to be performed on a variety of EOS data sets.

Web Coverage Services↗