Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “File 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 991 records · Page 55
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

STK Integrated Message Production List Editor (SIMPLE) for CEO Operations

Late in fiscal year 2011, the Crew Earth Observations (CEO) team was tasked to upgrade and replace its mission planning and mission operations software systems, which were developed in the Space Shuttle era of the 1980s and 1990s. The impetuses for this change were the planned transition of all workstations to the Windows 7 64-bit operating system and the desire for more efficient and effective use of Satellite Tool Kit (STK) software required for reliable International Space Station (ISS) Earth location tracking. An additional requirement of this new system was the use of the same SQL database of CEO science sites from the SMMS, which was also being developed. STK Integrated Message Production List Editor (SIMPLE) is the essential, all-in-one tool now used by CEO staff to perform daily ISS mission planning to meet its requirement to acquire astronaut photography of specific sites on Earth. The sites are part of a managed, long-term database that has been defined and developed for scientific, educational, and public interest. SIMPLE's end product is a set of basic time and location data computed for an operator-selected set of targets that the ISS crew will be asked to photograph (photography is typically planned 12 to 36 hours out). The CEO operator uses SIMPLE to (a) specify a payload operations planning period; (b) acquire and validate the best available ephemeris data (vectors) for the ISS during the planning period; (c) ingest and display mission-specific site information from the CEO database; (d) identify and display potential current dynamic event targets as map features; (e) compute and display time and location information for each target; (f) screen and select targets based on known crew availability constraints, obliquity constraints, and real-time evaluated constraints to target visibility due to illumination (sun elevation) and atmospheric conditions (weather); and finally (g) incorporate basic, computed time and location information for each selected target into the daily CEO Target List product (message) for submission to ISS payload planning and integration teams for their review and approval prior to uplink. SIMPLE requires and uses the following resources: an ISS mission planning period Greenwich Mean Time start date/time and end date/time), the best available ISS mission ephemeris data (vectors) for that planning period, the STK software package configured for the ISS, and an ISS mission-specific subset of the CEO sites database. The primary advantages realized by the development and implementation of SIMPLE into the CEO payload operations support activity are a smooth transition to the Windows 7 operating system upon scheduled workstation refresh; streamlining of the input and verification of the current ISS ephemeris (vector data); seamless incorporation of selected contents of the SQL database of science sites; the ability to tag and display potential dynamic event opportunities on orbit track maps; simplification of the display and selection of encountered sites based on crew availability, illumination, obliquity, and weather constraints; the incorporation of high-quality mapping of the Earth with various satellite-based datasets for use in describing targets; and the ability to encapsulate and export the essential selected target elements in XML format for use by onboard Earth-location systems, such as Worldmap. SIMPLE is a carefully designed and crafted in-house software package that includes detailed help files for the user and meticulous internal documentation for future modifications. It was delivered in February 2012 for test and evaluation. Following acceptance, it was implemented for CEO mission operations support in May 2012.

Trenchard, Mike↗
NASA NTRSDate not supplied

Big-data Efficient and Automated Science Transfer (BEAST): An Open-Source Software Architecture for Arc Jet Data Management, Modeling, and Automation

Big-data Efficient and Automated Science Transfer (BEAST) was conceived to address the existing ground testing data management of the NASA Ames arc jet facilities (e.g., manually entered Excel files and USB drive data transfers). These data management practices were seen as a choke point for future thermal protection system (TPS) development as they limit statistical tracking, resolution of diagnostics, coordination between video/time series, data throughput, and data processing speed/efficiency. Consequently, BEAST was developed to provide a new data infrastructure with streamlined data collection, processing, transfer, and analysis. This new framework also seeks to implement the FAIR principles of data stewardship: Findable, Accessible, Interoperable, and Reusable. The BEAST framework is based on a combination of the Python Django web framework and the Python data stack to provide a monolithic, open-source platform for data management, automation, and machine learning. This architecture was chosen for maintainability and scalability for a small, in-house development team. This paper will describe the application framework, deployment, and discuss the benefits and future plans for the system.

Data management↗
NASA NTRSDate not supplied

Big-data Efficient Automated Science Transfer (BEAST): an open-source software architecture for arc jet data management, modeling, and automation

Big-data Efficient and Automated Science Transfer (BEAST) was conceived to address the existing ground testing data management of the NASA Ames arc jet facilities (e.g., manually entered Excel files and USB drive data transfers). These data management practices were seen as a choke point for future thermal protection system (TPS) development as they limit statistical tracking, resolution of diagnostics, coordination between video/time series, data throughput, and data processing speed/efficiency. Consequently, BEAST was developed to provide a new data infrastructure with streamlined data collection, processing, transfer, and analysis. This new framework also seeks to implement the FAIR principles of data stewardship: Findable, Accessible, Interoperable, and Reusable. The BEAST framework is based on a combination of the Python Django web framework and the Python data stack to provide a monolithic, open-source platform for data management, automation, and machine learning. This architecture was chosen for maintainability and scalability for a small, in-house development team. This paper will describe the application framework, deployment, and discuss the benefits and future plans for the system.

Data management↗
NASA NTRS2011

SpaceCube Demonstration Platform

A document discusses how the HST SM4 SpaceCube flight spare was modified to create an experiment called the Space- Cube Demonstration Platform (SC DP) for use on the MISSE7 Space Station payload (in collaboration with NRL). It is designed to serve as an on-orbit platform for demonstrating advanced fault tolerance technologies. A simple C&DH (command and data handling) system was developed for the Virtex4 FPGAs (field programmable gate arrays). Both Virtex4s on each SpaceCube run the same program, and both receive incoming telemetry. The rad-hard service FPGA performs simple error checking to verify that the incoming telemetry is valid. The SpaceCube framework was modified to allow for new program files to be sent from the ground, to be stored on the SpaceCube, and to be executed through ground commands. Each SpaceCube Virtex4 FPGA has resources set aside for experiments that are functionally isolated from the C&DH system. The experiments communicate to the C&DH system through a set of dual port memories, and this area is where the fault-tolerance experiments are executed. With the use of Xilinx commercial Virtex4 FX60 FPGAs, the fault tolerant framework allows the system to recover from radiation upsets that occur in the rad-soft parts (Virtex4 FPGA logic, embedded PPCs in Virtex4 FPGAs, SDRAM and Flash), the C&DH system that runs simultaneously on both Virtex4 FPGAs that uses a robust telemetry packet structure, checksums, and the rad-hard service FPGA to validate incoming telemetry. The ability to be reconfigured from the ground while in orbit is a novel benefit, as well as is the onboard compression capabilities that allow compressed files from the ground to be uploaded to the SpaceCube.

Espinosa, Daniel↗
NASA NTRS1981

Space transportation system flight 2 OSTA-1 scientific payload data management plan

The Shuttle Imaging Radar-A (SIR-A), Shuttle Multispectral Infrared Radiometer (SMIRR), Future Identification and Location Experiment (FILE), Measurement of Air Pollution from Satellites (MAPS), Ocean Color Experiment (OCE), the Night/Day Optical Survey of Lightning (NOSL), and the Heflex Bioengineering Test (HBT) experiments are described.

Source record↗
NASA NTRS2000

BOREAS Hardcopy Maps

Boreal Ecosystem-Atmospheric Study (BOREAS) hardcopy maps are a collection of approximately 1,000 hardcopy maps representing the physical, climatological, and historical attributes of areas covering primarily the Manitoba and Saskatchewan provinces of Canada. These maps were collected by BOREAS Information System (BORIS) and Canada for Remote Sensing (CCRS) staff to provide basic information about site positions, manmade features, topography, geology, hydrology, land cover types, fire history, climate, and soils of the BOREAS study region. These maps are not available for distribution through the BOREAS project but may be used as an on-site resource. Information is provided within this document for individuals who want to order copies of these maps from the original map source. Note that the maps are not contained on the BOREAS CD-ROM set. An inventory listing file is supplied on the CD-ROM to inform users of the maps that are available. This inventory listing is available from the Earth Observing System Data and Information System (EOSDIS) Oak Ridge National Laboratory (ORNL) Distributed Active Archive Center (DAAC). For hardcopies of the individual maps, contact the sources provided.

Hall, Forrest G.↗
NASA NTRS2013

Modeling to Improve the Risk Reduction Process for Command File Errors

The Jet Propulsion Laboratory has learned that even innocuous errors in the spacecraft command process can have significantly detrimental effects on a space mission. Consequently, such Command File Errors (CFE), regardless of their effect on the spacecraft, are treated as significant events for which a root cause is identified and corrected. A CFE during space mission operations is often the symptom of imbalance or inadequacy within the system that encompasses the hardware and software used for command generation as well as the human experts and processes involved in this endeavor. As we move into an era of increased collaboration with other NASA centers and commercial partners, these systems become more and more complex. Consequently, the ability to thoroughly model and analyze CFEs formally in order to reduce the risk they pose is increasingly important. In this paper, we summarize the results of applying modeling techniques previously developed to the DAWN flight project. The original models were built with the input of subject matter experts from several flight projects. We have now customized these models to address specific questions for the DAWN flight project and formulating use cases to address their unique mission needs. The goal of this effort is to enhance the project's ability to meet commanding reliability requirements for operations and to assist them in managing their Command File Errors.

spacecraft↗
NASA NTRS2010

Using MERRA Gridded Innovations for Quantifying Uncertainties in Analysis Fields and Diagnosing Observing System Inhomogeneities

MERRA is a NASA reanalysis for the satellite era using a major new version of the Goddard Earth Observing System Data Assimilation System Version 5 (GEOS-5). The project focuses on historical analyses of the hydrological cycle on a broad range of weather and climate time scales and places the NASA EOS suite of observations in a climate context. The characterization of uncertainty in reanalysis fields is a commonly requested feature by users of such data. While intercomparison with reference data sets is common practice for ascertaining the realism of the datasets, such studies typically are restricted to long term climatological statistics and seldom provide state dependent measures of the uncertainties involved. In principle, variational data assimilation algorithms have the ability of producing error estimates for the analysis variables (typically surface pressure, winds, temperature, moisture and ozone) consistent with the assumed background and observation error statistics. However, these "perceived error estimates" are expensive to obtain and are limited by the somewhat simplistic errors assumed in the algorithm. The observation minus forecast residuals (innovations) by-product of any assimilation system constitutes a powerful tool for estimating the systematic and random errors in the analysis fields. Unfortunately, such data is usually not readily available with reanalysis products, often requiring the tedious decoding of large datasets and not so-user friendly file formats. With MERRA we have introduced a gridded version of the observations/innovations used in the assimilation process, using the same grid and data formats as the regular datasets. Such dataset empowers the user with the ability of conveniently performing observing system related analysis and error estimates. The scope of this dataset will be briefly described. We will present a systematic analysis of MERRA innovation time series for the conventional observing system, including maximum-likelihood estimates of background and observation errors, as well as global bias estimates. Starting with the joint PDF of innovations and analysis increments at observation locations we propose a technique for diagnosing bias among the observing systems, and document how these contextual biases have evolved during the satellite era covered by MERRA.

da Silva, Arlindo↗
NASA NTRS2011

Improvements in Space Geodesy Data Discovery at the CDDIS

The Crustal Dynamics Data Information System (CDDIS) supports data archiving and distribution activities for the space geodesy and geodynamics community. The main objectives of the system are to store space geodesy and geodynamics related data products in a central data bank. to maintain information about the archival of these data, and to disseminate these data and information in a timely manner to a global scientific research community. The archive consists of GNSS, laser ranging, VLBI, and DORIS data sets and products derived from these data. The CDDIS is one of NASA's Earth Observing System Data and Information System (EOSDIS) distributed data centers; EOSDIS data centers serve a diverse user community and arc tasked to provide facilities to search and access science data and products. Several activities are currently under development at the CDDIS to aid users in data discovery, both within the current community and beyond. The CDDIS is cooperating in the development of Geodetic Seamless Archive Centers (GSAC) with colleagues at UNAVCO and SIO. TIle activity will provide web services to facilitate data discovery within and across participating archives. In addition, the CDDIS is currently implementing modifications to the metadata extracted from incoming data and product files pushed to its archive. These enhancements will permit information about COOlS archive holdings to be made available through other data portals such as Earth Observing System (EOS) Clearinghouse (ECHO) and integration into the Global Geodetic Observing System (GGOS) portal.

Noll, C.↗
NASA NTRSDate not supplied

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗
NASA NTRS2009

R4SA for Controlling Robots

The R4SA GUI mentioned in the immediately preceding article is a userfriendly interface for controlling one or more robot(s). This GUI makes it possible to perform meaningful real-time field experiments and research in robotics at an unmatched level of fidelity, within minutes of setup. It provides such powerful graphing modes as that of a digitizing oscilloscope that displays up to 250 variables at rates between 1 and 200 Hz. This GUI can be configured as multiple intuitive interfaces for acquisition of data, command, and control to enable rapid testing of subsystems or an entire robot system while simultaneously performing analysis of data. The R4SA software establishes an intuitive component-based design environment that can be easily reconfigured for any robotic platform by creating or editing setup configuration files. The R4SA GUI enables event-driven and conditional sequencing similar to those of Mars Exploration Rover (MER) operations. It has been certified as part of the MER ground support equipment and, therefore, is allowed to be utilized in conjunction with MER flight hardware. The R4SA GUI could also be adapted to use in embedded computing systems, other than that of the MER, for commanding and real-time analysis of data.

Aghazarian, Hrand↗
NASA NTRS1981

A digital Seasat SAR correlation-simulation program

A correlation-simulation program for processing Seasat SAR data is presented, featuring the use of FORTRAN code to allow simple transference to another computer. The highest attainable azimuthal resolution for Seasat SAR experiments and the ability to generate images with varying quality by varying resolution or the number of looks are additional features. A fiber optics link transfers the Seasat data from high intensity digital tapes to an SEL 32/55 computer, and the least significant bits of the 5 bit data samples are truncated, thus the input data have 4 bits per sample. A total 8192 echoes are processed each time and stored on 8 separate data files on the disk. In addition, a program operating on 1-look high resolution images for performance simulations of proposed radar systems and processing schemes has been completed. Finally, the coding is simple, and 8 hours are required to process one image using this program.

Li, F.↗
NASA NTRS1986

Combining and connecting linear, multi-input, multi-output subsystem models

The mathematical background for combining and connecting linear, multi-input, multi-output subsystem models into an overall system model is provided. Several examples of subsystem configurations are examined in detail. A description of a MATRIX (sub x) command file to aid in the process of combining and connecting these subsystem models is contained.

Duke, E. L.↗
NASA NTRS1992

Multifrequency data analysis software on STARLINK

Although the STARLINK project was set up to provide image processing facilities to UK astronomers, it has grown over the last 12 years to the extent that it now provides most of the data analysis facilities for UK astronomers. One aspect of the growth of the STARLINK network is that it now has to cater for astronomers working in a diverse range of wavelengths. Since a given individual may be working with data obtained in a variety of wavelengths, it is most convenient if the data can be stored in a common format and the programs that analyze the data have a similar 'look and feel'. What is known as 'STARLINK software' is obtained from many sources: STARLINK funded programmers; astronomers; foreign projects such as AIPS; generally available shareware; and commercial sources when this proves cost effective. This means that the ideal situation of a completely integrated system cannot be realized in practice. Nevertheless, many of the major packages written by STARLINK application programmers and by astronomers do use a common data format, based on the Hierarchical Data System, so that interchange of data between packages designed separately from each other is simply a matter of using the same file names. For example, as astronomer might use KAPPA to read some optical spectra off a FITS tape, then use CCDPACK to debias and flat field the data (it is easy to set up an overnight batch job to do this if there is a lot of data), then use KAPPA to have a quick look at the data and then use Figaro to reduce the spectra. It is useful to divide data analysis packages into wavelength specific packages, or even instrument specific packages, and general purpose ones. Once the instrumental signature has been removed from some data, any appropriate general purpose package can be used to analyze te data. For example, the ASTERIX package deals with x-ray data reduction, but after dealing with all of the x-ray specific processing, an astronomer may well want to find the brightness of objects in a given frame. Since ASTERIX uses the standard STARLINK data format, the astronomer can use PHOTOM or DAOPHOT 2 to measure the brightness of the objects. Although DAOPHOT was written with optical astronomy in mind, it is useful for analyzing data from several wavelengths. The ability of DAOPHOT 2 to handle non-standard point spread functions can be especially useful in many areas of astronomy.

Allan, P. M.↗
NASA NTRS1992

How to handle 6GBytes a night and not get swamped

The Macho Project has undertaken a 5 year effort to search for dark matter in the halo of the Galaxy by scanning the Magellanic Clouds for micro-lensing events. Each evening's raw image data will be reduced in real-time into the observed stars' photometric measurements. The actual search for micro-lensing events will be a post-processing operation. The theoretical prediction of the rate of such events necessitates the collection of a large number of repeated exposures. The project designed camera subsystem delivers 64 Mbytes per exposure with exposures typically occurring every 500 seconds. An ideal evening's observing will provide 6 Gbytes of raw image data and 40 Mbytes of reduced photometric measurements. Recognizing the difficulty of digging out from a snowballing cascade of raw data, the project requires the real-time reduction of each evening's data. The software team's implementation strategy centered on this non-negotiable mandate. Accepting the reality that 2 full time people needed to implement the core real-time control and data management system within 6 months, off-the-shelf vendor components were explored to provide quick solutions to the classic needs for file management, data management, and process control. Where vendor solutions were lacking, state-of-the-art models were used for hand tailored subsystems. In particular, petri nets manage process control, memory mapped bulletin boards provide interprocess communication between the multi-tasked processes, and C++ class libraries provide memory mapped, disk resident databases. The differences between the implementation strategy and the final implementation reality are presented. The necessity of validating vendor product claims are explored. Both the successful and hindsight decisions enabling the collection and processing of the nightly data barrage are reviewed.

Allsman, R.↗
NASA NTRS1994

LSENS: A General Chemical Kinetics and Sensitivity Analysis Code for homogeneous gas-phase reactions. Part 3: Illustrative test problems

LSENS, the Lewis General Chemical Kinetics and Sensitivity Analysis Code, has been developed for solving complex, homogeneous, gas-phase chemical kinetics problems and contains sensitivity analysis for a variety of problems, including nonisothermal situations. This report is part 3 of a series of three reference publications that describe LSENS, provide a detailed guide to its usage, and present many example problems. Part 3 explains the kinetics and kinetics-plus-sensitivity analysis problems supplied with LSENS and presents sample results. These problems illustrate the various capabilities of, and reaction models that can be solved by, the code and may provide a convenient starting point for the user to construct the problem data file required to execute LSENS. LSENS is a flexible, convenient, accurate, and efficient solver for chemical reaction problems such as static system; steady, one-dimensional, inviscid flow; reaction behind incident shock wave, including boundary layer correction; and perfectly stirred (highly backmixed) reactor. In addition, the chemical equilibrium state can be computed for the following assigned states: temperature and pressure, enthalpy and pressure, temperature and volume, and internal energy and volume. For static problems the code computes the sensitivity coefficients of the dependent variables and their temporal derivatives with respect to the initial values of the dependent variables and/or the three rate coefficient parameters of the chemical reactions.

Bittker, David A.↗