Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software: simulations”

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 757 records · Page 42

System level verification applying the Space Shuttle experience to the Space Station

The applicability of the verification process for the Shuttle guidance, navigation and control (GNC) and data management system (DMS) for the development of the Space Station are described. Shuttle avionics hardware/software integration was delayed to finalize the hardware design before detailed definition and testing of the software. A block diagram is provided of the flight simulation laboratory used to test the GNC programs before flight data were available. The Station will have distributed computers, unlike the Orbiter, and will only be assembled fully in space. Standardized integration simulation test equipment are being defined to guide the development of hardware and software. The simulation capability may become part of nominal in-flight operations to initiate new capabilities as they are added to the Station. The Station GNC and DMS systems development will be somewhat simplified relative to those of the Shuttle because ascent and reentry will not be considered for the Station.

Gilbert, David W.↗

Aviation Safety Simulation Model

The Aviation Safety Simulation Model is a software tool that enables users to configure a terrain, a flight path, and an aircraft and simulate the aircraft's flight along the path. The simulation monitors the aircraft's proximity to terrain obstructions, and reports when the aircraft violates accepted minimum distances from an obstruction. This model design facilitates future enhancements to address other flight safety issues, particularly air and runway traffic scenarios. This report shows the user how to build a simulation scenario and run it. It also explains the model's output.

Houser, Scott↗

A Validation Study of Merging and Spacing Techniques in a NAS-Wide Simulation

In November 2010, Intelligent Automation, Inc. (IAI) delivered an M&S software tool to that allows system level studies of the complex terminal airspace with the ACES simulation. The software was evaluated against current day arrivals in the Atlanta TRACON using Atlanta's Hartsfield-Jackson International Airport (KATL) arrival schedules. Results of this validation effort are presented describing data sets, traffic flow assumptions and techniques, and arrival rate comparisons between reported landings at Atlanta versus simulated arrivals using the same traffic sets in ACES equipped with M&S. Initial results showed the simulated system capacity to be significantly below arrival capacity seen at KATL. Data was gathered for Atlanta using commercial airport and flight tracking websites (like FlightAware.com), and analyzed to insure compatible techniques were used for result reporting and comparison. TFM operators for Atlanta were consulted for tuning final simulation parameters and for guidance in flow management techniques during high volume operations. Using these modified parameters and incorporating TFM guidance for efficiencies in flowing aircraft, arrival capacity for KATL was matched for the simulation. Following this validation effort, a sensitivity study was conducted to measure the impact of variations in system parameters on the Atlanta airport arrival capacity.

Glaab, Patricia C.↗

A General Mission Independent Simulator (GMIS) and Simulator Control Program (SCP)

GMIS is a general-purpose simulator for testing ground system software. GMIS can be adapted to any mission to simulate changes in the data state maintained by the mission's computers. GMIS was developed in Code 522 NASA Goddard Space Flight Center. The acronym GMIS stands for GOTT Mission Independent Simulator, where GOTT is the Ground Operations Technology Testbed. Within GOTT, GMIS is used to provide simulated data to an installation of TPOCC - the Transportable Payload Operations Control Center. TPOCC was developed by Code 510 as a reusable control center. GOTT uses GMIS and TPOCC to test new technology and new operator procedures.

Baker, Paul L.↗

User's Guide for Flight Simulation Data Visualization Workstation

Today's modern flight simulation research produces vast amounts of time sensitive data. The meaning of this data can be difficult to assess while in its raw format. Therefore, a method of breaking the data down and presenting it to the user in a graphical format is necessary. Simulation Graphics (SimGraph) is intended as a data visualization software package that will incorporate simulation data into a variety of animated graphical displays for easy interpretation by the simulation researcher. This document is intended as an end user's guide.

Kaplan, Joseph A.↗

Development of a Flight Simulation Data Visualization Workstation

Today's moderm flight simulation research produces vast amounts of time sensitive data. The meaning of this data can be difficult to assess while in its raw format . Therefore, a method of breaking the data down and presenting it to the user in a graphical format is necessary. Simulation Graphics (SimGraph) is intended as a data visualization software package that will incorporate simulation data into a variety of animated graphical displays for easy interpretation by the simulation researcher. Although it was created for the flight simulation facilities at NASA Langley Research Center, SimGraph can be reconfigured to almost any data visualization environment. This paper traces the design, development and implementation of the SimGraph program, and is intended to be a programmer's reference guide.

Kaplan, Joseph A.↗

A New Simulation Framework for Autonomy in Robotic Missions

Autonomy is a key factor in remote robotic exploration and there is significant activity addressing the application of autonomy to remote robots. It has become increasingly important to have simulation tools available to test the autonomy algorithms. While indus1;rial robotics benefits from a variety of high quality simulation tools, researchers developing autonomous software are still dependent primarily on block-world simulations. The Mission Simulation Facility I(MSF) project addresses this shortcoming with a simulation toolkit that will enable developers of autonomous control systems to test their system s performance against a set of integrated, standardized simulations of NASA mission scenarios. MSF provides a distributed architecture that connects the autonomous system to a set of simulated components replacing the robot hardware and its environment.

Flueckiger, Lorenzo↗

Development and Testing of Automatically Generated ACS Flight Software for the MAP Spacecraft

By integrating the attitude determination and control system (ACS) analysis and design, flight software development, and flight software testing processes, it is possible to improve the overall spacecraft development cycle, as well as allow for more thorough software testing. One of the ways to achieve this integration is to use code-generation tools to automatically generate components of the ACS flight software directly from a high-fidelity (HiFi) simulation. In the development of the Microwave Anisotropy Probe (MAP) spacecraft, currently underway at the NASA Goddard Space Flight Center, approximately 1/3 of the ACS flight software was automatically generated. In this paper, we will examine each phase of the ACS subsystem and flight software design life cycle: analysis, design, and testing. In the analysis phase, we scoped how much software we would automatically generate and created the initial interface. The design phase included parallel development of the HiFi simulation and the hand-coded flight software components. Everything came together in the test phase, in which the flight software was tested, using results from the HiFi simulation as one of the bases of comparison for testing. Because parts of the spacecraft HiFi simulation were converted into flight software, more care needed to be put into its development and configuration control to support both the HiFi simulation and flight software. The components of the HiFi simulation from which code was generated needed to be designed based on the fact that they would become flight software. This process involved such considerations as protecting against mathematical exceptions, using acceptable module and parameter naming conventions, and using an input/output interface compatible with the rest of the flight software. Maintaining good configuration control was an issue for the HiFi simulation and the flight software, and a way to track the two systems was devised. Finally, an integrated test approach was devised to support flight software testing at both the unit- and build-test levels using the HiFi simulation to generate data for performance verification. Another benefit of the simulation and code-generation application used on the MAP project is that it supported bringing flight software and test data into the HiFi simulation environment. It was possible to integrate parts of the hand-coded flight software into the HiFi simulation, and also possible to import flight software test data for comparison and performance verification. This capability was used to incorporate the flight software Kalman filter into the HiFi simulation. This enabled us to greatly increase the amount of testing that could be done on the filter, because we could exert a greater degree of control over the software-only simulation than over the flight software test environment. Also, since the simulation could be used to run the Kalman filter faster than real time, our testing efficiency was greatly increased. We will conclude our discussion with a summary of the lessons learned thus far using automatically- generated code for the MAP project, and the spacecraft status as we work towards our scheduled launch in the year 2000.

ODonnell, James R., Jr.↗

Description of the GMAO OSSE for Weather Analysis Software Package: Version 3

The Global Modeling and Assimilation Office (GMAO) at the NASA Goddard Space Flight Center has developed software and products for conducting observing system simulation experiments (OSSEs) for weather analysis applications. Such applications include estimations of potential effects of new observing instruments or data assimilation techniques on improving weather analysis and forecasts. The GMAO software creates simulated observations from nature run (NR) data sets and adds simulated errors to those observations. The algorithms employed are much more sophisticated, adding a much greater degree of realism, compared with OSSE systems currently available elsewhere. The algorithms employed, software designs, and validation procedures are described in this document. Instructions for using the software are also provided.

OSSE↗

ATTIRE (analytical tools for thermal infrared engineering): A sensor simulation and modeling package

The Advanced Sensor Development Laboratory (ASDL) at the Stennis Space Center develops, maintains and calibrates remote sensing instruments for the National Aeronautics & Space Administration (NASA). To perform system design trade-offs, analysis, and establish system parameters, ASDL has developed a software package for analytical simulation of sensor systems. This package called 'Analytical Tools for Thermal InfraRed Engineering' - ATTIRE, simulates the various components of a sensor system. The software allows each subsystem of the sensor to be analyzed independently for its performance. These performance parameters are then integrated to obtain system level information such as Signal-to-Noise Ratio (SNR), Noise Equivalent Radiance (NER), Noise Equivalent Temperature Difference (NETD) etc. This paper describes the uses of the package and the physics that were used to derive the performance parameters.

Jaggi, S.↗

Propulsion Simulations with the Unstructured-Grid CFD Tool TetrUSS

A computational investigation has been completed to assess the capability of the NASA Tetrahedral Unstructured Software System (TetrUSS) for simulation of exhaust nozzle flows. Three configurations were chosen for this study: (1) a fluidic jet effects model, (2) an isolated nacelle with a supersonic cruise nozzle, and (3) a fluidic pitchthrust- vectoring nozzle. These configurations were chosen because existing data provided a means for measuring the ability of the TetrUSS flow solver USM3D for simulating complex nozzle flows. Fluidic jet effects model simulations were compared with structured-grid CFD (computational fluid dynamics) data at Mach numbers from 0.3 to 1.2 at nozzle pressure ratios up to 7.2. Simulations of an isolated nacelle with a supersonic cruise nozzle were compared with wind tunnel experimental data and structured-grid CFD data at Mach numbers of 0.9 and 1.2, with a nozzle pressure ratio of 5. Fluidic pitch-thrust-vectoring nozzle simulations were compared with static experimental data and structured-grid CFD data at static freestream conditions and nozzle pressure ratios from 3 to 10. A fluidic injection case was computed with the third configuration at a nozzle pressure ratio of 4.6 and a secondary pressure ratio of 0.7. Results indicate that USM3D with the S-A turbulence model provides accurate exhaust nozzle simulations at on-design conditions, but does not predict internal shock location at overexpanded conditions or pressure recovery along a boattail at transonic conditions.

Deere, Karen A.↗

Utilizing a Common Model Architecture for the Simulation of On-Orbit Human Spaceflight Operations

Advances in computing and simulation technology during the 1980 s promoted the development of multiple simulations for on-orbit human spaceflight operations at the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC). By the late 1980 s, it became increasingly clear that redundancy risked leading to inefficiencies in dissemination and incorporation of models across simulations, institutional organizations, and spaceflight programs. Software development tools, such as the Trick Simulation Environment, began to emerge providing a generalized framework for the development, integration, and operation of simulations. Throughout the 1990s, engineering, operations, and training simulations began to migrate to Trick in order to take advantage of a common simulation environment. Due to forecasted reductions in funding to the Shuttle and International Space Station (ISS) programs in the early 2000s, the common framework that arose from this simulation migration was formalized as the Common Model Architecture (CMA). The CMA was established in order to further reduce redundancy, while promoting model sharing and enhancing model integrity. A minimal set of standards for data flows, functional interactions, and model organization based on Trick were defined for those features found to be most important in facilitating model interaction. Model-providing organizations within NASA JSC took ownership of models for their specific areas of expertise, and agreements were reached on common model sharing and usage. This paper describes the evolution of commonality enabled by the Trick Simulation Environment at JSC leading to the CMA, the standards defined by the CMA, a recent CMA simulation example, and potential application of the CMA to NASA s new Exploration program.

Leslie J Quiocho↗

GlennICE Simulation of 24, 28 and 36 Inch Diameter eVTOL Propellers in Forward Flight

Flow solutions and water collection results are presented for three different propeller sizes. Flow solutions were generated using the NASA FUN3D software, and water collection was simulated using NASA GlennICE software. The geometries considered represent experimental articles that have been tested in the NASA Icing Research Tunnel. Each configuration has four blades. For the experiment, the same spinner centerbody is used for each propeller size. The different sized blades are similar for radii larger than about 40% of total span. Operating conditions were chosen to match operating points where experimental data was collected. Results are presented for both single bin simulations, as well as 7-bin Langmuir D distributions. For 80 microns MVD the Langmuir D distribution showed small differences compared to the single bin. For 15 microns MVD the Langmuir D distribution had a larger impact, especially on the spinner. In the experiment, the centerbody was unchanged as propeller size was changed. In this paper, additional simulations were completed with the 36 inch case perfectly scaled down to 24 and 28 inch. The perfect geometric scaling allows for an assessment of the effect of constant centerbody size on the results. While slight differences in pressure distribution on the propeller are visible between scaled and non-scaled centerbody, the effect seems quite minimal regarding water collection. All simulations were run very cold to ensure rime ice, since handling runback water in the non-inertial frame is beyond the scope of the present work. Ice shapes were generated using a single time step growth. The total mass on the blade and spinner was generally underpredicted for 15 microns MVD, and overpredicted for 80 microns MVD. When comparing ice shapes at operating conditions the numerical results produce very similar ice shapes.

Aircraft Icing↗

GlennICE Simulation of 24, 28 and 36 Inch Diameter eVTOL Propellers in Forward Flight

Flow solutions and water collection results are presented for three different propeller sizes. Flow solutions were generated using the NASA FUN3D software, and water collection was simulated using NASA GlennICE software. The geometries considered represent experimental articles that have been tested in the NASA Icing Research Tunnel. Each configuration has four blades. For the experiment, the same spinner centerbody is used for each propeller size. The different sized blades are similar for radii larger than about 40% of total span. Operating conditions were chosen to match operating points where experimental data was collected. Results are presented for both single bin simulations, as well as 7-bin Langmuir D distributions. For 80 microns MVD the Langmuir D distribution showed small differences compared to the single bin. For 15 microns MVD the Langmuir D distribution had a larger impact, especially on the spinner. In the experiment, the centerbody was unchanged as propeller size was changed. In this paper, additional simulations were completed with the 36 inch case perfectly scaled down to 24 and 28 inch. The perfect geometric scaling allows for an assessment of the effect of constant centerbody size on the results. While slight differences in pressure distribution on the propeller are visible between scaled and non-scaled centerbody, the effect seems quite minimal regarding water collection. All simulations were run very cold to ensure rime ice, since handling runback water in the non-inertial frame is beyond the scope of the present work. Ice shapes were generated using a single time step growth. The total mass on the blade and spinner was generally underpredicted for 15 microns MVD, and overpredicted for 80 microns MVD. When comparing ice shapes at operating conditions the numerical results produce very similar ice shapes.

Aircraft Icing↗

SSL Freeform Generator v1.00

The Orion spacecraft utilizes a system of Compact Unique Identifiers (CUIs) to identify telemetry measurements in the process of communicating with the ground. While avionic systems are still in development, simulation of telemetric data must be used for the development of dependent systems. The SuperScript Language (SSL) developed by Honeywell Aerospace provides users a programming language for simulation of this data. The use of tools that provide SSL generation capabilities at a higher level allows for faster and more efficient generation of simulation waveforms. Previous SSL Generator implementations such as Orion Scripted Interface Generator (OrionSIG) relied on software supported routines to generate simulation points for the SSL scripts. This provided relevant simulation capabilities, but was reduced in flexibility by the available software routines available. For this approach, software supported routines have been entirely dropped. Rather, the user is required to enter their own simulation waveform input. This allows arbitrarily complex functions to be utilized simulated with maximum degree of freedom for the user.: The idea for this version of the SSL Generator was a mapping of arbitrary waveforms to Orion CUI telemetry data. The SSL Generator implemented offers a higher degree of freedom to the user than previous versions while attempting to maintain abstraction from the underlying SSL script and the Orion CUI data types. As such, many mappings of waveforms to CUIs will simply not work. Certain implementation decisions were made to minimize the damage caused by these unintended side-effects, such as saturation of values exceeding the maximum or minimum bounds of the data type. Other details, such as signed values being represented in unsigned data types, present problems which cant be fixed to an acceptable degree of intended behavior without user input. Awareness of the limitations of all layers of the software stack will increase the productivity of the end-user.

telemetry↗

Computational structural mechanics engine structures computational simulator

The Computational Structural Mechanics (CSM) program at Lewis encompasses: (1) fundamental aspects for formulating and solving structural mechanics problems, and (2) development of integrated software systems to computationally simulate the performance/durability/life of engine structures.

Chamis, C. C.↗

NASA One-Dimensional Combustor Simulation--User Manual for S1D_ML

The work presented in this paper is to promote research leading to a closed-loop control system to actively suppress thermo-acoustic instabilities. To serve as a model for such a closed-loop control system, a one-dimensional combustor simulation composed using MATLAB software tools has been written. This MATLAB based process is similar to a precursor one-dimensional combustor simulation that was formatted as FORTRAN 77 source code. The previous simulation process requires modification to the FORTRAN 77 source code, compiling, and linking when creating a new combustor simulation executable file. The MATLAB based simulation does not require making changes to the source code, recompiling, or linking. Furthermore, the MATLAB based simulation can be run from script files within the MATLAB environment or with a compiled copy of the executable file running in the Command Prompt window without requiring a licensed copy of MATLAB. This report presents a general simulation overview. Details regarding how to setup and initiate a simulation are also presented. Finally, the post-processing section describes the two types of files created while running the simulation and it also includes simulation results for a default simulation included with the source code.

combustion↗

Approximation of Engine Casing Temperature Constraints for Casing Mounted Electronics

The performance of propulsion engine systems is sensitive to weight and volume considerations. This can severely constrain the configuration and complexity of the control system hardware. Distributed Engine Control technology is a response to these concerns by providing more flexibility in designing the control system, and by extension, more functionality leading to higher performing engine systems. Consequently, there can be a weight benefit to mounting modular electronic hardware on the engine core casing in a high temperature environment. This paper attempts to quantify the in-flight temperature constraints for engine casing mounted electronics. In addition, an attempt is made at studying heat soak back effects. The Commercial Modular Aero Propulsion System Simulation 40k (C-MAPSS40k) software is leveraged with real flight data as the inputs to the simulation. A two-dimensional (2-D) heat transfer model is integrated with the engine simulation to approximate the temperature along the length of the engine casing. This modification to the existing C-MAPSS40k software will provide tools and methodologies to develop a better understanding of the requirements for the embedded electronics hardware in future engine systems. Results of the simulations are presented and their implications on temperature constraints for engine casing mounted electronics is discussed.

Engine↗