SEARCH · Engineering Papers

Results for “software differences”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

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

At least 1,063 records · Page 59

All sources NASA NTRS DOE OSTI

NASA NTRS2013

Spaceport Processing System Development Lab

The Spaceport Processing System Development Lab (SPSDL), developed and maintained by the Systems Hardware and Engineering Branch (NE-C4), is a development lab with its own private/restricted networks. A private/restricted network is a network with restricted or no communication with other networks. This allows users from different groups to work on their own projects in their own configured environment without interfering with others utilizing their resources in the lab. The different networks being used in the lab have no way to talk with each other due to the way they are configured, so how a user configures his software, operating system, or the equipment doesn't interfere or carry over on any of the other networks in the lab. The SPSDL is available for any project in KSC that is in need of a lab environment. My job in the SPSDL was to assist in maintaining the lab to make sure it's accessible for users. This includes, but is not limited to, making sure the computers in the lab are properly running and patched with updated hardware/software. In addition to this, I also was to assist users who had issues in utilizing the resources in the lab, which may include helping to configure a restricted network for their own environment. All of this was to ensure workers were able to use the SPSDL to work on their projects without difficulty which would in turn, benefit the work done throughout KSC. When I wasn't working in the SPSDL, I would instead help other coworkers with smaller tasks which included, but wasn't limited to, the proper disposal, moving of, or search for essential equipment. I also, during the free time I had, used NASA's resources to increase my knowledge and skills in a variety of subjects related to my major as a computer engineer, particularly in UNIX, Networking, and Embedded Systems.

Systems Engineering↗

NASA NTRS2012

CASSIUS: The Cassini Uplink Scheduler

The Cassini Uplink Scheduler (CASSIUS) is cross-platform software used to generate a radiation sequence plan for commands being sent to the Cassini spacecraft. Because signals must travel through varying amounts of Earth's atmosphere, several different modes of constant telemetry rates have been devised. These modes guarantee that the spacecraft and the Deep Space Network agree with respect to the data transmission rate. However, the memory readout of a command will be lost if it occurs on a telemetry mode boundary. Given a list of spacecraft message files as well as the available telemetry modes, CASSIUS can find an uplink sequence that ensures safe transmission of each file. In addition, it can predict when the two on-board solid state recorders will swap. CASSIUS prevents data corruption by making sure that commands are not planned for memory readout during telemetry rate changes or a solid state recorder swap.

Cassini mission↗

NASA NTRS2013

Development and Integration of an Advanced Stirling Convertor Linear Alternator Model for a Tool Simulating Convertor Performance and Creating Phasor Diagrams

A simple model of the Advanced Stirling Convertors (ASC) linear alternator and an AC bus controller has been developed and combined with a previously developed thermodynamic model of the convertor for a more complete simulation and analysis of the system performance. The model was developed using Sage, a 1-D thermodynamic modeling program that now includes electro-magnetic components. The convertor, consisting of a free-piston Stirling engine combined with a linear alternator, has sufficiently sinusoidal steady-state behavior to allow for phasor analysis of the forces and voltages acting in the system. A MATLAB graphical user interface (GUI) has been developed to interface with the Sage software for simplified use of the ASC model, calculation of forces, and automated creation of phasor diagrams. The GUI allows the user to vary convertor parameters while fixing different input or output parameters and observe the effect on the phasor diagrams or system performance. The new ASC model and GUI help create a better understanding of the relationship between the electrical component voltages and mechanical forces. This allows better insight into the overall convertor dynamics and performance.

Metscher, Jonathan F.↗

NASA NTRS2013

Development and Integration of an Advanced Stirling Convertor Linear Alternator Model for a Tool Simulating Convertor Performance and Creating Phasor Diagrams

Metscher, Jonathan F.↗

NASA NTRS2019

Planetary Mapping for Landing Sites Selection: The Mars Case Study

The selection of a landing site on a planetary body is a multistep process that involves both the fulfillment of several engineering constraints and the accomplishment of scientific requirements. In this chapter, we will show how the simultaneous production and exploitation of different GIS maps depicting these criteria are pivotal in the landing site selection. Indeed, all of such constraints are presently evaluated through the use of GIS-based software. To show this, we will focus on the Martian site identification outline, providing multiple real examples taken from two ongoing study cases, i.e., the Simud Vallis landing site proposed by Pajola et al. (Icarus 268:355–381, 2016a) for the ESA ExoMars rover and the Eridania landing site proposed by Pajola et al. (Icarus 275:163–182, 2016b) for the NASA Mars 2020 landing site selection.

Planetary mapping↗

NASA NTRS1988

Dypas: A dynamic payload scheduler for shuttle missions

Decision and analysis systems have had broad and very practical application areas in the human decision making process. These software systems range from the help sections in simple accounting packages, to the more complex computer configuration programs. Dypas is a decision and analysis system that aids prelaunch shutlle scheduling, and has added functionality to aid the rescheduling done in flight. Dypas is written in Common Lisp on a Symbolics Lisp machine. Dypas differs from other scheduling programs in that it can draw its knowledge from different rule bases and apply them to different rule interpretation schemes. The system has been coded with Flavors, an object oriented extension to Common Lisp on the Symbolics hardware. This allows implementation of objects (experiments) to better match the problem definition, and allows a more coherent solution space to be developed. Dypas was originally developed to test a programmer's aptitude toward Common Lisp and the Symbolics software environment. Since then the system has grown into a large software effort with several programmers and researchers thrown into the effort. Dypas is currently using two expert systems and three inferencing procedures to generate a many object schedule. The paper will review the abilities of Dypas and comment on its functionality.

Davis, Stephen↗

NASA NTRS2014

Time and Frequency-Domain Cross-Verification of SLS 6DOF Trajectory Simulations

The SLS GNC team and its partners have developed several time- and frequency-based simulations for development and analysis of the proposed SLS launch vehicle. The simulations differ in fidelity and some have unique functionality that allows them to perform specific analyses. Some examples of the purposes of the various models are: trajectory simulation, multi-body separation, Monte Carlo, hardware in the loop, loads, and frequency domain stability analyses. While no two simulations are identical, many of the models are essentially six degree-of-freedom (6DOF) representations of the SLS plant dynamics, hardware implementation, and flight software. Thus at a high level all of those models should be in agreement. Comparison of outputs from several SLS trajectory and stability analysis tools are ongoing as part of the program's current verification effort. The purpose of these comparisons is to highlight modeling and analysis differences, verify simulation data sources, identify inconsistencies and minor errors, and ultimately to verify output data as being a good representation of the vehicle and subsystem dynamics. This paper will show selected verification work in both the time and frequency domain from the current design analysis cycle of the SLS for several of the design and analysis simulations. In the time domain, the tools that will be compared are MAVERIC, CLVTOPS, SAVANT, STARS, ARTEMIS, and POST 2. For the frequency domain analysis, the tools to be compared are FRACTAL, SAVANT, and STARS. The paper will include discussion of these tools including their capabilities, configurations, and the uses to which they are put in the SLS program. Determination of the criteria by which the simulations are compared (matching criteria) requires thoughtful consideration, and there are several pitfalls that may occur that can severely punish a simulation if not considered carefully. The paper will discuss these considerations and will present a framework for responding to these issues when they arise. For example, small event timing differences can lead to large differences in mass properties if the criteria are to measure those properties at the same time, or large differences in altitude if the criteria are to measure those properties when the simulation experiences a staging event. Similarly, a tiny difference in phase can lead to large gain margin differences for frequency-domain comparisons of gain margins.

VanZwieten, Tannen↗

NASA NTRS2017

Time and Frequency-Domain Cross-Verification of SLS 6DOF Trajectory Simulations

The Space Launch System (SLS) Guidance, Navigation, and Control (GNC) team and its partners have developed several time- and frequency-based simulations for development and analysis of the proposed SLS launch vehicle. The simulations differ in fidelity and some have unique functionality that allows them to perform specific analyses. Some examples of the purposes of the various models are: trajectory simulation, multi-body separation, Monte Carlo, hardware in the loop, loads, and frequency domain stability analyses. While no two simulations are identical, many of the models are essentially six degree-of-freedom (6DOF) representations of the SLS plant dynamics, hardware implementation, and flight software. Thus at a high level all of those models should be in agreement. Comparison of outputs from several SLS trajectory and stability analysis tools are ongoing as part of the program's current verification effort. The purpose of these comparisons is to highlight modeling and analysis differences, verify simulation data sources, identify inconsistencies and minor errors, and ultimately to verify output data as being a good representation of the vehicle and subsystem dynamics. This paper will show selected verification work in both the time and frequency domain from the current design analysis cycle of the SLS for several of the design and analysis simulations. In the time domain, the tools that will be compared are MAVERIC, CLVTOPS, SAVANT, STARS, ARTEMIS, and POST 2. For the frequency domain analysis, the tools to be compared are FRACTAL, SAVANT, and STARS. The paper will include discussion of these tools including their capabilities, configurations, and the uses to which they are put in the SLS program. Determination of the criteria by which the simulations are compared (matching criteria) requires thoughtful consideration, and there are several pitfalls that may occur that can severely punish a simulation if not considered carefully. The paper will discuss these considerations and will present a framework for responding to these issues when they arise. For example, small event timing differences can lead to large differences in mass properties if the criteria are to measure those properties at the same time, or large differences in altitude if the criteria are to measure those properties when the simulation experiences a staging event. Similarly, a tiny difference in phase can lead to large gain margin differences for frequency-domain comparisons of gain margins.

Johnson, Matthew↗

NASA NTRSDate not supplied

Promoting Astronaut Autonomy in Human Spaceflight Missions

Mission operations will have to adapt for long duration, long distance human spaceflight missions. This change is driven mainly by the significantly different communication availability between Earth and space. As astronauts travel farther from Earth, the one-way communication latency increases; the amount of bandwidth will be limited; and there will be period of long and/or no communication. Currently, ground flight controllers collaborate and cooperate with astronauts in space to accomplish essential operational functions. Astronaut autonomy, i.e., the crew’s ability to work more independently from mission control, will be a key enabler in future exploration missions. Over the last several years, the NASA Ames Human-Computer Interaction (HCI) Group has investigated various ways to promote and support astronaut autonomy in human spaceflight missions. Software prototypes are researched, designed, implemented, and assessed for their ability to enable astronaut autonomy. From integrated Internet of Thing for Space, advanced procedures interfaces, comm-delayed chats, and self-scheduling tools, the HCI Group has explored different aspects of astronaut autonomy. Specifically, the self-scheduling tool Playbook has been evaluated in analog extreme environments and onboard the International Space Station, successfully paving the way for future autonomous astronauts.

crew autonomy↗

NASA NTRS1992

Advanced software development workstation: Effectiveness of constraint-checking

This report summarizes the findings and lessons learned from the development of an intelligent user interface for a space flight planning simulation program, in the specific area related to constraint-checking. The different functionalities of the Graphical User Interface part and of the rule-based part of the system have been identified. Their respective domain of applicability for error prevention and error checking have been specified.

Izygon, Michel↗

NASA NTRS2014

System Testing of Ground Cooling System Components

This internship focused primarily upon software unit testing of Ground Cooling System (GCS) components, one of the three types of tests (unit, integrated, and COTS/regression) utilized in software verification. Unit tests are used to test the software of necessary components before it is implemented into the hardware. A unit test determines that the control data, usage procedures, and operating procedures of a particular component are tested to determine if the program is fit for use. Three different files are used to make and complete an efficient unit test. These files include the following: Model Test file (.mdl), Simulink SystemTest (.test), and autotest (.m). The Model Test file includes the component that is being tested with the appropriate Discrete Physical Interface (DPI) for testing. The Simulink SystemTest is a program used to test all of the requirements of the component. The autotest tests that the component passes Model Advisor and System Testing, and puts the results into proper files. Once unit testing is completed on the GCS components they can then be implemented into the GCS Schematic and the software of the GCS model as a whole can be tested using integrated testing. Unit testing is a critical part of software verification; it allows for the testing of more basic components before a model of higher fidelity is tested, making the process of testing flow in an orderly manner.

Unit Test↗

NASA NTRS2017

Trade Study: Storing NASA HDF5/netCDF-4 Data in the Amazon Cloud and Retrieving Data Via Hyrax Server Data Server

This study explored three candidate architectures with different types of objects and access paths for serving NASA Earth Science HDF5 data via Hyrax running on Amazon Web Services (AWS). We studied the cost and performance for each architecture using several representative Use-Cases. The objectives of the study were: Conduct a trade study to identify one or more high performance integrated solutions for storing and retrieving NASA HDF5 and netCDF4 data in a cloud (web object store) environment. The target environment is Amazon Web Services (AWS) Simple Storage Service (S3). Conduct needed level of software development to properly evaluate solutions in the trade study and to obtain required benchmarking metrics for input into government decision of potential follow-on prototyping. Develop a cloud cost model for the preferred data storage solution (or solutions) that accounts for different granulation and aggregation schemes as well as cost and performance trades.We will describe the three architectures and the use cases along with performance results and recommendations for further work.

AWS cost↗

NASA NTRS1976

Issues in advanced automation for manipulator control

This paper provides a brief description and analysis of the main issues in advanced autonomous control of manipulators as seen from a system point of view. The nature of manipulation is analyzed at some depth. A general multilevel structure is outlined for manipulator control organization which includes the human operator at the top level of the control structure. Different approaches to the development of advanced automation of mechanical arms are summarized. Recent work in the JPL teleoperator project is described, including control system, force/torque sensor, and control software development. Some results from control experiments are summarized.

Bejczy, A. K.↗

NASA NTRS1980

CCD camera systems and support electronics for a White Light Coronagraph and X-ray XUV solar telescope

Two instruments, a White Light Coronagraph and an X-ray XUV telescope built into the same housing, share several electronic functions. Each instrument uses a CCD as an imaging detector, but due to different spectral requirements, each uses a different type. Hardware reduction, required by the stringent weight and volume allocations of the interplanetary mission, is made possible by the use of a microprocessor. Most instrument functions are software controlled with the end use circuits treated as peripherals to the microprocessor. The instruments are being developed for the International Solar Polar Mission.

Harrison, D. C.↗

NASA NTRS1983

Summary of NASA Langley's pilot scan behavior research

The present investigation is concerned with the information acquired in a series of basic studies designed to obtain an understanding of the pilot's scanning behavior. In the studies, use was made of an oculometer system which operates by shining a beam of collimated infrared light at the subject's eyes. A number of oculometer software modifications have been made to make the oculometer user-friendly and versatile. Scanning is found to be a subconscious conditioned activity. The conditioned activity of scanning is different for each pilot. There are also slight variations between test runs for the same conditions for the same pilot. This indicates that scanning is situation dependent. Attention is given to the rate of information transfer, the possibility that scanning can be disrupted, the visual approach look-point, and workload sensitive measures.

Spady, A. A., Jr.↗

NASA NTRS1987

Distributed computer system enhances productivity for SRB joint optimization

The Programming System for Structural Synthesis software package, which couples structural analysis and optimization, has been distributed over a network of work stations for use in Space Shuttle Solid Rocket Booster joint redesign optimization. Finite difference computing techniques were applied to the optimization gradients in parallel execution, allowing several work stations to simultaneously contribute to the problem's solution. An optimal joint shape was obtained which achieves minimum weight while keeping the gap between joints well closed and limiting structural stresses. The optimization cycle was reduced from two hours to one-half hour.

Rogers, James L., Jr.↗

NASA NTRS1993

On the use of the consistent mass matrix in flexible multibody systems

Two different methods are used in finite element structural analysis to define element mass distribution: consistent and lumped mass approximations. The lumped mass method is currently favored in multibody dynamics software packages because of its computational efficiency. This paper, however, presents a multibody dynamics formulation based on the consistent mass approach which should prove to be as computationally efficient as the lumped mass approach. It is shown that when component flexibility is modelled using modal coordinates, the equations of motion, as formulated by these two methods, are very similar in appearance, thereby facilitating their comparison. It is also shown, through simulation of a simple multibody system, that a system formulated with the lumped mass approximation will often require more finite elements and smaller integration step sizes than the corresponding consistent mass system.

Anthony, Tobin C.↗

NASA NTRS1995

Wideband propagation measurement system using spread spectrum signaling and TDRS

In this paper, a wideband propagation measurement system, which consisted of a ground-based transmitter, a mobile receiver, and a data acquisition system, was constructed. This system has been employed in a study of the characteristics of different propagation environments, such as urban, suburban and rural areas, by using a pseudonoise spreading sequence transmitted over NASA's Tracking and Data Relay Satellite System. The hardware and software tests showed that it met overall system requirements and it was very robust during a 3-month-long outdoor data collection experiment.

Jenkins, Jeffrey D.↗