Search NASA⌕ Search

SEARCH · Search NASA

Results for “Computer software”

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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS1990

Neural networks as a control methodology

While conventional computers must be programmed in a logical fashion by a person who thoroughly understands the task to be performed, the motivation behind neural networks is to develop machines which can train themselves to perform tasks, using available information about desired system behavior and learning from experience. There are three goals of this fellowship program: (1) to evaluate various neural net methods and generate computer software to implement those deemed most promising on a personal computer equipped with Matlab; (2) to evaluate methods currently in the professional literature for system control using neural nets to choose those most applicable to control of flexible structures; and (3) to apply the control strategies chosen in (2) to a computer simulation of a test article, the Control Structures Interaction Suitcase Demonstrator, which is a portable system consisting of a small flexible beam driven by a torque motor and mounted on springs tuned to the first flexible mode of the beam. Results of each are discussed.

Mccullough, Claire L.↗
NASA NTRS1991

Compiling and editing agricultural strata boundaries with remotely sensed imagery and map attribute data using graphics workstations

The USDA presently uses labor-intensive photographic interpretation procedures to delineate large geographical areas into manageable size sampling units for the estimation of domestic crop and livestock production. Computer software to automate the boundary delineation procedure, called the computer-assisted stratification and sampling (CASS) system, was developed using a Hewlett Packard color-graphics workstation. The CASS procedures display Thematic Mapper (TM) satellite digital imagery on a graphics display workstation as the backdrop for the onscreen delineation of sampling units. USGS Digital Line Graph (DLG) data for roads and waterways are displayed over the TM imagery to aid in identifying potential sample unit boundaries. Initial analysis conducted with three Missouri counties indicated that CASS was six times faster than the manual techniques in delineating sampling units.

Cheng, Thomas D.↗
NASA NTRS2010

NASA Tech Briefs, April 2010

Topics covered include: Active and Passive Hybrid Sensor; Quick-Response Thermal Actuator for Use as a Heat Switch; System for Hydrogen Sensing; Method for Detecting Perlite Compaction in Large Cryogenic Tanks; Using Thin-Film Thermometers as Heaters in Thermal Control Applications; Directional Spherical Cherenkov Detector; AlGaN Ultraviolet Detectors for Dual-Band UV Detection; K-Band Traveling-Wave Tube Amplifier; Simplified Load-Following Control for a Fuel Cell System; Modified Phase-meter for a Heterodyne Laser Interferometer; Loosely Coupled GPS-Aided Inertial Navigation System for Range Safety; Sideband-Separating, Millimeter-Wave Heterodyne Receiver; Coaxial Propellant Injectors With Faceplate Annulus Control; Adaptable Diffraction Gratings With Wavefront Transformation; Optimizing a Laser Process for Making Carbon Nanotubes; Thermogravimetric Analysis of Single-Wall Carbon Nanotubes; Robotic Arm Comprising Two Bending Segments; Magnetostrictive Brake; Low-Friction, Low-Profile, High-Moment Two-Axis Joint; Foil Gas Thrust Bearings for High-Speed Turbomachinery; Miniature Multi-Axis Mechanism for Hand Controllers; Digitally Enhanced Heterodyne Interferometry; Focusing Light Beams To Improve Atomic-Vapor Optical Buffers; Landmark Detection in Orbital Images Using Salience Histograms; Efficient Bit-to-Symbol Likelihood Mappings; Capacity Maximizing Constellations; Natural-Language Parser for PBEM; Policy Process Editor for P(sup 3)BM Software; A Quality System Database; Trajectory Optimization: OTIS 4; and Computer Software Configuration Item-Specific Flight Software Image Transfer Script Generator.

Source record↗
NASA NTRS1986

NASA Tech Briefs, November/December 1986, Special Edition

Topics: Computing: The View from NASA Headquarters; Earth Resources Laboratory Applications Software: Versatile Tool for Data Analysis; The Hypercube: Cost-Effective Supercomputing; Artificial Intelligence: Rendezvous with NASA; NASA's Ada Connection; COSMIC: NASA's Software Treasurehouse; Golden Oldies: Tried and True NASA Software; Computer Technical Briefs; NASA TU Services; Digital Fly-by-Wire.

Source record↗
NASA NTRS1997

NASA Tech Briefs, December 1997

Topics: Design and Analysis Software; Electronic Components and Circuits; Electronic Systems; Physical Sciences; Materials; Computer Software; Mechanics; Manufacturing/Fabrication; Mathematics and Information Sciences; Books and Reports.

Source record↗
NASA NTRS1970

Automatic Malfunction Analysis

Automatic Malfunction Analysis /AMA/ digital computer software system supporting checkout and testing, defining normal system status by computer simulation

Jaegly, R. L.↗
NASA NTRS2005

Parallel Domain Decomposition Formulation and Software for Large-Scale Sparse Symmetrical/Unsymmetrical Aeroacoustic Applications

The overall objectives of this research work are to formulate and validate efficient parallel algorithms, and to efficiently design/implement computer software for solving large-scale acoustic problems, arised from the unified frameworks of the finite element procedures. The adopted parallel Finite Element (FE) Domain Decomposition (DD) procedures should fully take advantages of multiple processing capabilities offered by most modern high performance computing platforms for efficient parallel computation. To achieve this objective. the formulation needs to integrate efficient sparse (and dense) assembly techniques, hybrid (or mixed) direct and iterative equation solvers, proper pre-conditioned strategies, unrolling strategies, and effective processors' communicating schemes. Finally, the numerical performance of the developed parallel finite element procedures will be evaluated by solving series of structural, and acoustic (symmetrical and un-symmetrical) problems (in different computing platforms). Comparisons with existing "commercialized" and/or "public domain" software are also included, whenever possible.

Nguyen, D. T.↗
NASA NTRS1972

Digital receiver study and implementation

Computer software was developed which makes it possible to use any general purpose computer with A/D conversion capability as a PSK receiver for low data rate telemetry processing. Carrier tracking, bit synchronization, and matched filter detection are all performed digitally. To aid in the implementation of optimum computer processors, a study of general digital processing techniques was performed which emphasized various techniques for digitizing general analog systems. In particular, the phase-locked loop was extensively analyzed as a typical non-linear communication element. Bayesian estimation techniques for PSK demodulation were studied. A hardware implementation of the digital Costas loop was developed.

Fogle, D. A.↗
NASA NTRS2010

Kepler Science Operations Center Architecture

We give an overview of the operational concepts and architecture of the Kepler Science Data Pipeline. Designed, developed, operated, and maintained by the Science Operations Center (SOC) at NASA Ames Research Center, the Kepler Science Data Pipeline is central element of the Kepler Ground Data System. The SOC charter is to analyze stellar photometric data from the Kepler spacecraft and report results to the Kepler Science Office for further analysis. We describe how this is accomplished via the Kepler Science Data Pipeline, including the hardware infrastructure, scientific algorithms, and operational procedures. The SOC consists of an office at Ames Research Center, software development and operations departments, and a data center that hosts the computers required to perform data analysis. We discuss the high-performance, parallel computing software modules of the Kepler Science Data Pipeline that perform transit photometry, pixel-level calibration, systematic error-correction, attitude determination, stellar target management, and instrument characterization. We explain how data processing environments are divided to support operational processing and test needs. We explain the operational timelines for data processing and the data constructs that flow into the Kepler Science Data Pipeline.

Middour, Christopher↗
NASA NTRS1991

Database for propagation models

A propagation researcher or a systems engineer who intends to use the results of a propagation experiment is generally faced with various database tasks such as the selection of the computer software, the hardware, and the writing of the programs to pass the data through the models of interest. This task is repeated every time a new experiment is conducted or the same experiment is carried out at a different location generating different data. Thus the users of this data have to spend a considerable portion of their time learning how to implement the computer hardware and the software towards the desired end. This situation may be facilitated considerably if an easily accessible propagation database is created that has all the accepted (standardized) propagation phenomena models approved by the propagation research community. Also, the handling of data will become easier for the user. Such a database construction can only stimulate the growth of the propagation research it if is available to all the researchers, so that the results of the experiment conducted by one researcher can be examined independently by another, without different hardware and software being used. The database may be made flexible so that the researchers need not be confined only to the contents of the database. Another way in which the database may help the researchers is by the fact that they will not have to document the software and hardware tools used in their research since the propagation research community will know the database already. The following sections show a possible database construction, as well as properties of the database for the propagation research.

Kantak, Anil V.↗
NASA NTRS1996

Development of software for the MSFC solar vector magnetograph

The Marshall Space Flight Center Solar Vector Magnetograph is a special purpose telescope used to measure the vector magnetic field in active areas on the surface of the sun. This instrument measures the linear and circular polarization intensities (the Stokes vectors Q, U and V) produced by the Zeeman effect on a specific spectral line due to the solar magnetic field from which the longitudinal and transverse components of the magnetic field may be determined. Beginning in 1990 as a Summer Faculty Fellow in project JOVE and continuing under NASA Grant NAG8-1042, the author has been developing computer software to perform these computations, first using a DEC MicroVAX system equipped with a high speed array processor, and more recently using a DEC AXP/OSF system. This summer's work is a continuation of this development.

Kineke, Jack↗
NASA NTRS2014

Ground Operations Autonomous Control and Integrated Health Management

The Ground Operations Autonomous Control and Integrated Health Management plays a key role for future ground operations at NASA. The software that is integrated into this system is called G2 2011 Gensym. The purpose of this report is to describe the Ground Operations Autonomous Control and Integrated Health Management with the use of the G2 Gensym software and the G2 NASA toolkit for Integrated System Health Management (ISHM) which is a Computer Software Configuration Item (CSCI). The decision rationale for the use of the G2 platform is to develop a modular capability for ISHM and AC. Toolkit modules include knowledge bases that are generic and can be applied in any application domain module. That way, there's a maximization of reusability, maintainability, and systematic evolution, portability, and scalability. Engine modules are generic, while application modules represent the domain model of a specific application. Furthermore, the NASA toolkit, developed since 2006 (a set of modules), makes it possible to create application domain models quickly, using pre-defined objects that include sensors and components libraries for typical fluid, electrical, and mechanical systems.

Computer Programs↗
NASA NTRS1995

PC Software graphics tool for conceptual design of space/planetary electrical power systems

This paper describes the Decision Support System (DSS), a personal computer software graphics tool for designing conceptual space and/or planetary electrical power systems. By using the DSS, users can obtain desirable system design and operating parameters, such as system weight, electrical distribution efficiency, and bus power. With this tool, a large-scale specific power system was designed in a matter of days. It is an excellent tool to help designers make tradeoffs between system components, hardware architectures, and operation parameters in the early stages of the design cycle. The DSS is a user-friendly, menu-driven tool with online help and a custom graphical user interface. An example design and results are illustrated for a typical space power system with multiple types of power sources, frequencies, energy storage systems, and loads.

Truong, Long V.↗
NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗
NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗
NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗
NASA NTRS2013

Assessment Environment for Complex Systems Software Guide

This Software Guide (SG) describes the software developed to test the Assessment Environment for Complex Systems (AECS) by the West Virginia High Technology Consortium (WVHTC) Foundation's Mission Systems Group (MSG) for the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD). This software is referred to as the AECS Test Project throughout the remainder of this document. AECS provides a framework for developing, simulating, testing, and analyzing modern avionics systems within an Integrated Modular Avionics (IMA) architecture. The purpose of the AECS Test Project is twofold. First, it provides a means to test the AECS hardware and system developed by MSG. Second, it provides an example project upon which future AECS research may be based. This Software Guide fully describes building, installing, and executing the AECS Test Project as well as its architecture and design. The design of the AECS hardware is described in the AECS Hardware Guide. Instructions on how to configure, build and use the AECS are described in the User's Guide. Sample AECS software, developed by the WVHTC Foundation, is presented in the AECS Software Guide. The AECS Hardware Guide, AECS User's Guide, and AECS Software Guide are authored by MSG. The requirements set forth for AECS are presented in the Statement of Work for the Assessment Environment for Complex Systems authored by NASA Dryden Flight Research Center (DFRC). The intended audience for this document includes software engineers, hardware engineers, project managers, and quality assurance personnel from WVHTC Foundation (the suppliers of the software), NASA (the customer), and future researchers (users of the software). Readers are assumed to have general knowledge in the field of real-time, embedded computer software development.

tests↗
NASA NTRS1990

Providing structural modules with self-integrity monitoring software user's manual

National Aeronautics and Space Administration (NASA) Contract NAS7-961 (A Small Business Innovation and Research (SBIR) contract from NASA) involved research dealing with remote structural damage detection using the concept of substructures. Several approaches were developed. The main two were: (1) the module (substructure) transfer function matrix (MTFM) approach; and (2) modal strain energy distribution method (MSEDM). Either method can be used with a global structure; however, the focus was on substructures. As part of the research contract, computer software was to be developed which would implement the developed methods. This was done and it was used to process all the finite element generated numerical data for the research. The software was written for the IBM AT personal computer. Copies of it were placed on floppy disks. This report serves as a user's manual for the two sets of damage detection software. Sections 2.0 and 3.0 discuss the use of the MTFM and MSEDM software, respectively.

Source record↗