Search NASA⌕ Search

SEARCH · Search NASA

Results for “Systems Engineering environments”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

A Collaborative Analysis Tool for Thermal Protection Systems for Single Stage to Orbit Launch Vehicles

Presented is a design tool and process that connects several disciplines which are needed in the complex and integrated design of high performance reusable single stage to orbit (SSTO) vehicles. Every system is linked to every other system and in the case of SSTO vehicles with air breathing propulsion, which is currently being studied by the National Aeronautics and Space Administration (NASA); the thermal protection system (TPS) is linked directly to almost every major system. The propulsion system pushes the vehicle to velocities on the order of 15 times the speed of sound in the atmosphere before pulling up to go to orbit which results high temperatures on the external surfaces of the vehicle. Thermal protection systems to maintain the structural integrity of the vehicle must be able to mitigate the heat transfer to the structure and be lightweight. Herein lies the interdependency, in that as the vehicle's speed increases, the TPS requirements are increased. And as TPS masses increase the effect on the propulsion system and all other systems is compounded. To adequately determine insulation masses for a vehicle such as the one described above, the aeroheating loads must be calculated and the TPS thicknesses must be calculated for the entire vehicle. To accomplish this an ascent or reentry trajectory is obtained using the computer code Program to Optimize Simulated Trajectories (POST). The trajectory is then used to calculate the convective heat rates on several locations on the vehicles using the Miniature Version of the JA70 Aerodynamic Heating Computer Program (MINIVER). Once the heat rates are defined for each body point on the vehicle, then insulation thicknesses that are required to maintain the vehicle within structural limits are calculated using Systems Improved Numerical Differencing Analyzer (SINDA) models. If the TPS masses are too heavy for the performance of the vehicle the process may be repeated altering the trajectory or some other input to reduce the TPS mass. The problem described is an example of the need for collaborative design and analysis. Analysis tools are being developed to facilitate these collaborative efforts. RECIPE is a cross-platform application capable of hosting a number of engineers and designers across the Internet for distributed and collaborative engineering environments. Such integrated system design environments allow for collaborative team design analysis for performing individual or reduced team studies. The analysis tools mentioned earlier are commonly run on different platforms and are usually run by different people. To facilitate the larger number of potential runs that may need to be made, RECIPE connects the computer codes that calculate the trajectory data, heat rate data, and TPS masses so that the output from each tool is easily transferred to the model input files that need it. This methodology is being applied to solve launch vehicle thermal design problems to shorten the design cycle, and enable the project team to evaluate design options. Results will be presented indicating the effectiveness of this as a collaborative design tool.

Alexander, Reginald A.↗
NASA NTRS1990

Developments in REDES: The Rocket Engine Design Expert System

The Rocket Engine Design Expert System (REDES) was developed at NASA-Lewis to collect, automate, and perpetuate the existing expertise of performing a comprehensive rocket engine analysis and design. Currently, REDES uses the rigorous JANNAF methodology to analyze the performance of the thrust chamber and perform computational studies of liquid rocket engine problems. The following computer codes were included in REDES: a gas properties program named GASP; a nozzle design program named RAO; a regenerative cooling channel performance evaluation code named RTE; and the JANNAF standard liquid rocket engine performance prediction code TDK (including performance evaluation modules ODE, ODK, TDE, TDK, and BLM). Computational analyses are being conducted by REDES to provide solutions to liquid rocket engine thrust chamber problems. REDES was built in the Knowledge Engineering Environment (KEE) expert system shell and runs on a Sun 4/110 computer.

Davidian, Kenneth O.↗
NASA NTRS1990

Developments in REDES: The rocket engine design expert system

The Rocket Engine Design Expert System (REDES) is being developed at the NASA-Lewis to collect, automate, and perpetuate the existing expertise of performing a comprehensive rocket engine analysis and design. Currently, REDES uses the rigorous JANNAF methodology to analyze the performance of the thrust chamber and perform computational studies of liquid rocket engine problems. The following computer codes were included in REDES: a gas properties program named GASP, a nozzle design program named RAO, a regenerative cooling channel performance evaluation code named RTE, and the JANNAF standard liquid rocket engine performance prediction code TDK (including performance evaluation modules ODE, ODK, TDE, TDK, and BLM). Computational analyses are being conducted by REDES to provide solutions to liquid rocket engine thrust chamber problems. REDES is built in the Knowledge Engineering Environment (KEE) expert system shell and runs on a Sun 4/110 computer.

Davidian, Kenneth O.↗
NASA NTRS2004

Reducing the Time and Cost of Testing Engines

Producing a new aircraft engine currently costs approximately $1 billion, with 3 years of development time for a commercial engine and 10 years for a military engine. The high development time and cost make it extremely difficult to transition advanced technologies for cleaner, quieter, and more efficient new engines. To reduce this time and cost, NASA created a vision for the future where designers would use high-fidelity computer simulations early in the design process in order to resolve critical design issues before building the expensive engine hardware. To accomplish this vision, NASA's Glenn Research Center initiated a collaborative effort with the aerospace industry and academia to develop its Numerical Propulsion System Simulation (NPSS), an advanced engineering environment for the analysis and design of aerospace propulsion systems and components. Partners estimate that using NPSS has the potential to dramatically reduce the time, effort, and expense necessary to design and test jet engines by generating sophisticated computer simulations of an aerospace object or system. These simulations will permit an engineer to test various design options without having to conduct costly and time-consuming real-life tests. By accelerating and streamlining the engine system design analysis and test phases, NPSS facilitates bringing the final product to market faster. NASA's NPSS Version (V)1.X effort was a task within the Agency s Computational Aerospace Sciences project of the High Performance Computing and Communication program, which had a mission to accelerate the availability of high-performance computing hardware and software to the U.S. aerospace community for its use in design processes. The technology brings value back to NASA by improving methods of analyzing and testing space transportation components.

Source record↗
NASA NTRS1993

Model-based reasoning for system and software engineering: The Knowledge From Pictures (KFP) environment

This paper presents a discussion of current work in the area of graphical modeling and model-based reasoning being undertaken by the Automation Technology Section, Code 522.3, at Goddard. The work was initially motivated by the growing realization that the knowledge acquisition process was a major bottleneck in the generation of fault detection, isolation, and repair (FDIR) systems for application in automated Mission Operations. As with most research activities this work started out with a simple objective: to develop a proof-of-concept system demonstrating that a draft rule-base for a FDIR system could be automatically realized by reasoning from a graphical representation of the system to be monitored. This work was called Knowledge From Pictures (KFP) (Truszkowski et. al. 1992). As the work has successfully progressed the KFP tool has become an environment populated by a set of tools that support a more comprehensive approach to model-based reasoning. This paper continues by giving an overview of the graphical modeling objectives of the work, describing the three tools that now populate the KFP environment, briefly presenting a discussion of related work in the field, and by indicating future directions for the KFP environment.

Bailin, Sydney↗
NASA NTRS1992

Practical quality control tools for curves and surfaces

Curves (geometry) and surfaces created by Computer Aided Geometric Design systems in the engineering environment must satisfy two basic quality criteria: the geometric shape must have the desired engineering properties; and the objects must be parameterized in a way which does not cause computational difficulty for geometric processing and engineering analysis. Interactive techniques are described which are in use at Boeing to evaluate the quality of aircraft geometry prior to Computational Fluid Dynamic analysis, including newly developed methods for examining surface parameterization and its effects.

Small, Scott G.↗
NASA NTRS1991

Results of prototype software development for automation of shuttle proximity operations

The effort involves demonstration of expert system technology application to Shuttle rendezvous operations in a high-fidelity, real-time simulation environment. The JSC Systems Engineering Simulator (SES) served as the test bed for the demonstration. Rendezvous applications were focused on crew procedures and monitoring of sensor health and trajectory status. Proximity operations applications were focused on monitoring, crew advisory, and control of the approach trajectory. Guidance, Navigation, and Control areas of emphasis included the approach, transition and stationkeeping guidance, and laser docking sensor navigation. Operator interface displays for monitor and control functions were developed. A rule-based expert system was developed to manage the relative navigation system/sensors for nominal operations and simple failure contingencies. Testing resulted in the following findings; (1) the developed guidance is applicable for operations with LVLH stabilized targets; (2) closing rates less than 0.05 feet per second are difficult to maintain due to the Shuttle translational/rotational cross-coupling; (3) automated operations result in reduced propellant consumption and plume impingement effects on the target as compared to manual operations; and (4) braking gates are beneficial for trajectory management. A versatile guidance design was demonstrated. An accurate proximity operations sensor/navigation system to provide relative attitude information within 30 feet is required and redesign of the existing Shuttle digital autopilot should be considered to reduce the cross-coupling effects. This activity has demonstrated the feasibility of automated Shuttle proximity operations with the Space Station Freedom. Indications are that berthing operations as well as docking can be supported.

Hiers, Hal↗
NASA NTRS2008

Development of a Temperature Sensor for Jet Engine and Space Missions Environments

Electronic systems in aerospace and in space exploration missions are expected to encounter extreme temperatures and wide thermal swings. To address the needs for extreme temperature electronics, research efforts exist at the NASA Glenn Research Center (GRC) to develop and evaluate electronics for extreme temperature operations, and to establish their reliability under extreme temperature operation and thermal cycling; conditions that are typical of both the aerospace and space environments. These efforts are supported by the NASA Fundamental Aeronautics/Subsonic Fixed Wing Program and by the NASA Electronic Parts and Packaging (NEPP) Program. This work reports on the results obtained on the development of a temperature sensor geared for use in harsh environments.

Patterson, Richard L.↗
NASA NTRS2015

Design and Fabrication Development of J-2X Engine Metallic Nozzle Extension

Maximized rocket engine performance is in part derived from expanding combustion gasses through the rocket nozzle. For upper stage engines the nozzles can be quite large. On the J-2X engine, an uncooled extension of a regeneratively cooled nozzle is used to expand the combustion gasses to a targeted exit pressure which is defined by an altitude for the desired maximum performance. Creating a J-2X nozzle extension capable of surviving the loads of test and flight environments while meeting engine system performance requirements required development of new processes and facilities. Meeting the challenges of the development resulted in concurrent J-2X nozzle extension design and fabrication. This paper describes how some of the design and fabrication challenges were resolved.

Kopicz, C.↗
NASA NTRS2019

Orion Ascent Abort 2 Test - Benefits of a Digital Collaboration Environment

The Ascent Abort-2 Crew Module and Separation Ring (CSR) were developed internally to NASA, led by the JSC EA Integrated Product Team. The CSR IPT leveraged Sharepoint as an Integrated Data environment to link systems engineering and project management data element, enabling collaborative development and engagement from across the project (NASA-wide). This presentation describes the mission, the development approach, and the benefits of this approach. flight operations

Devolites, Jenny↗
NASA NTRSDate not supplied

Artemis Status Tracker for Real-time Awareness

Providers of Verification evidence for the Space Launch System (SLS) Program include Element Offices (SPIE, Stages, Engines, Booster) as well as Disciplines (Vehicle Management / GN&C, Loads & Environments, Safety and Mission Assurance, Systems Engineering, Integrated Avionics Software). These Elements and Disciplines rely on myriad inputs for their compliance evidence, from NASA and contractors alike, spanning testing and analysis to inspection and validation of records such as drawings and reports.

Braxton Lovett↗
NASA NTRS2013

Domain-Specific Languages and Diagram Customization for a Concurrent Engineering Environment

A major open question for advocates of Model-Based Systems Engineering (MBSE) is the question of how system and subsystem engineers will work together. The Systems Modeling Language (SysML), like any language intended for a large audience, is in tension between the desires for simplicity and for expressiveness. In order to be more expressive, many specialized language elements may be introduced, which will unfortunately make a complete understanding of the language a more daunting task. While this may be acceptable for systems modelers, it will increase the challenge of including subsystem engineers in the modeling effort. One possible answer to this situation is the use of Domain-Specific Languages (DSL), which are fully supported by the Unified Modeling Language (UML). SysML is in fact a DSL for systems engineering. The expressive power of a DSL can be enhanced through the use of diagram customization. Various domains have already developed their own schematic vocabularies. Within the space engineering community, two excellent examples are the propulsion and telecommunication subsystems. A return to simple box-and-line diagrams (e.g., the SysML Internal Block Diagram) are in many ways a step backward. In order allow subsystem engineers to contribute directly to the model, it is necessary to make a system modeling tool at least approximate in accessibility to drawing tools like Microsoft PowerPoint and Visio. The challenge is made more extreme in a concurrent engineering environment, where designs must often be drafted in an hour or two. In the case of the Jet Propulsion Laboratory's Team X concurrent design team, a subsystem is specified using a combination of PowerPoint for drawing and Excel for calculation. A pilot has been undertaken in order to meld the drawing portion and the production of master equipment lists (MELs) via a SysML authoring tool, MagicDraw. Team X currently interacts with its customers in a process of sharing presentations. There are several inefficiencies that arise from this situation. The first is that a customer team must wait two weeks to a month (which is 2-4 times the duration of most Team X studies themselves) for a finalized, detailed design description. Another is that this information must be re-entered by hand into the set of engineering artifacts and design tools that the mission concept team uses after a study is complete. Further, there is no persistent connection to Team X or institutionally shared formulation design tools and data after a given study, again reducing the direct reuse of designs created in a Team X study. This paper presents the underpinnings of subsystem DSLs as they were developed for this pilot. This includes specialized semantics for different domains as well as the process by which major categories of objects were derived in support of defining the DSLs. The feedback given to us by the domain experts on usability, along with a pilot study with the partial inclusion of these tools is also discussed.

Cole, Bjorn↗
NASA NTRS1992

Advanced life support systems in lunar and Martian environments utilizing a higher plant based engineering paradigm

The paper describes a higher-plant-based engineering paradigm for advanced life support in a Controlled Ecological Life Support System (CELSS) on the surface of the moon or Mars, called the CELSS Breadboard Project, designed at John F. Kennedy Space Center. Such a higher-plant-based system would use the plants for a direct food source, gas exchange, water reclamation, and plant residuals in a complex biological resource recovery scheme. The CELSS Breadboard Project utilizes a 'breadboard' approach of developing independent systems that are evaluated autonomously and are later interconnected. Such a scheme will enable evaluation of life support system methodologies tested for their efficiency in a life support system for habitats on the moon or Mars.

Chamberland, Dennis↗
NASA NTRS1998

The Impact of System Latency on Dynamic Performance In Virtual Acoustic Environments

Engineering constraints that may be encountered when implementing interactive virtual acoustic displays are examined In particular, system parameters such as the update rate and total system latency are defined and the impact they may have on perception is discussed. For example, examination of the head motions that listeners used to aid localization in a previous study suggests that some head motions may be as fast as about 400 degrees/sec for short time periods. Analysis of latencies in virtual acoustic environments (VAEs) suggests that: (1) commonly-specified parameters such as the audio update rate determine only the "best-case" latency possible in a VAE, (2) total system latency and individual latencies of system components, including head-trackers, are frequently not measured by VAE developers, and (3) typical system latencies may result in under-sampling of relative listener-source motion of 400 degrees/sec as well as positional "jitter" in the simulated source. To clearly specify the dynamic performance of a particular VAE, users and developers need to make measurements of average system latency, update rate, and their variability using standardized rendering scenarios. a parameters such as the minimum audible movement angle can then be used as target guidelines to assess whether a given system meets perceptual requirements.

Wenzel, Elizabeth M.↗
NASA NTRS1966

Thermal Control of Liquid H2/O2 Rocket Engines and Vehicle Impact

Cryogenic propulsion systems are subjected to various engine start environments during ground testing, first burn, and restart after orbital coast. These operational modes necessitate careful engine-stage integration, particularly in thermal control of propellant feed systems and engine subsystems. The wide range of operational conditions imposed on propellant feed systems include varying heat loads and acceleration forces for static test first burn and orbital restart. One method used to provide Net Positive Suctign,Head (NPSH) and maintain turbopump I is thermal control propellant circulation through the feed system prior to engine start. The attendant design and operational criteria are inter-related with stage and vehicle systems, including for example, auxiliary propulsion and propellant ullaging methods such as propellant tank propulsive venting. Thermally sensitive engine components require environmental control, protection, or special sequencing in order to assure repeatable engine start performance. An example is thrust chamber pre-chill to avoid pump stall during rapid start transient. Trends in engine development are toward expanding system flexibility to accommodate the wide variety of environments without special pre-start conditioning.

Winstead, Thomas W.↗
NASA NTRS1999

Small Engine Technology (SET) - Task 14 Axisymmetric Engine Simulation Environment

As part of the NPSS (Numerical Propulsion Simulation System) project, NASA Lewis has a goal of developing an U.S. industry standard for an axisymmetric engine simulation environment. In this program, AlliedSignal Engines (AE) contributed to this goal by evaluating the ENG20 software and developing support tools. ENG20 is a NASA developed axisymmetric engine simulation tool. The project was divided into six subtasks which are summarized below: Evaluate the capabilities of the ENG20 code using an existing test case to see how this procedure can capture the component interactions for a full engine. Link AE's compressor and turbine axisymmetric streamline curvature codes (UD0300M and TAPS) with ENG20, which will provide the necessary boundary conditions for an ENG20 engine simulation. Evaluate GE's Global Data System (GDS), attempt to use GDS to do the linking of codes described in Subtask 2 above. Use a turbofan engine test case to evaluate various aspects of the system, including the linkage of UD0300M and TAPS with ENG20 and the GE data storage system. Also, compare the solution results with cycle deck results, axisymmetric solutions (UD0300M and TAPS), and test data to determine the accuracy of the solution. Evaluate the order of accuracy and the convergence time for the solution. Provide a monthly status report and a final formal report documenting AE's evaluation of ENG20. Provide the developed interfaces that link UD0300M and TAPS with ENG20, to NASA. The interface that links UD0300M with ENG20 will be compatible with the industr,, version of UD0300M.

Miller, Max J.↗