Search NASA⌕ Search

SEARCH · Search NASA

Results for “engineering process”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

NTP comparison process

The systems engineering process for the concept definition phase of the program involves requirements definition, system definition, and consistent concept definition. The requirements definition process involves obtaining a complete understanding of the system requirements based on customer needs, mission scenarios, and nuclear thermal propulsion (NTP) operating characteristics. A system functional analysis is performed to provide a comprehensive traceability and verification of top-level requirements down to detailed system specifications and provides significant insight into the measures of system effectiveness to be utilized in system evaluation. The second key element in the process is the definition of system concepts to meet the requirements. This part of the process involves engine system and reactor contractor teams to develop alternative NTP system concepts that can be evaluated against specific attributes, as well as a reference configuration against which to compare system benefits and merits. Quality function deployment (QFD), as an excellent tool within Total Quality Management (TQM) techniques, can provide the required structure and provide a link to the voice of the customer in establishing critical system qualities and their relationships. The third element of the process is the consistent performance comparison. The comparison process involves validating developed concept data and quantifying system merits through analysis, computer modeling, simulation, and rapid prototyping of the proposed high risk NTP subsystems. The maximum amount possible of quantitative data will be developed and/or validated to be utilized in the QFD evaluation matrix. If upon evaluation of a new concept or its associated subsystems determine to have substantial merit, those features will be incorporated into the reference configuration for subsequent system definition and comparison efforts.

Corban, Robert↗
NASA NTRS1989

Parametric Cost Analysis: A Design Function

Parametric cost analysis uses equations to map measurable system attributes into cost. The measures of the system attributes are called metrics. The equations are called cost estimating relationships (CER's), and are obtained by the analysis of cost and technical metric data of products analogous to those to be estimated. Examples of system metrics include mass, power, failure_rate, mean_time_to_repair, energy _consumed, payload_to_orbit, pointing_accuracy, manufacturing_complexity, number_of_fasteners, and percent_of_electronics_weight. The basic assumption is that a measurable relationship exists between system attributes and the cost of the system. If a function exists, the attributes are cost drivers. Candidates for metrics include system requirement metrics and engineering process metrics. Requirements are constraints on the engineering process. From optimization theory we know that any active constraint generates cost by not permitting full optimization of the objective. Thus, requirements are cost drivers. Engineering processes reflect a projection of the requirements onto the corporate culture, engineering technology, and system technology. Engineering processes are an indirect measure of the requirements and, hence, are cost drivers.

Dean, Edwin B.↗
NASA NTRS1992

Quality Function Deployment for Large Systems

Quality Function Deployment (QFD) is typically applied to small subsystems. This paper describes efforts to extend QFD to large scale systems. It links QFD to the system engineering process, the concurrent engineering process, the robust design process, and the costing process. The effect is to generate a tightly linked project management process of high dimensionality which flushes out issues early to provide a high quality, low cost, and, hence, competitive product. A pre-QFD matrix linking customers to customer desires is described.

Dean, Edwin B.↗
NASA NTRS2004

A Web Centric Architecture for Deploying Multi-Disciplinary Engineering Design Processes

There are continuous needs for engineering organizations to improve their design process. Current state of the art techniques use computational simulations to predict design performance, and optimize it through advanced design methods. These tools have been used mostly by individual engineers. This paper presents an architecture for achieving results at an organization level beyond individual level. The next set of gains in process improvement will come from improving the effective use of computers and software within a whole organization, not just for an individual. The architecture takes advantage of state of the art capabilities to produce a Web based system to carry engineering design into the future. To illustrate deployment of the architecture, a case study for implementing advanced multidisciplinary design optimization processes such as Bi-Level Integrated System Synthesis is discussed. Another example for rolling-out a design process for Design for Six Sigma is also described. Each example explains how an organization can effectively infuse engineering practice with new design methods and retain the knowledge over time.

Woyak, Scott↗
NASA NTRS1988

The TAME Project: Towards improvement-oriented software environments

Experience from a dozen years of analyzing software engineering processes and products is summarized as a set of software engineering and measurement principles that argue for software engineering process models that integrate sound planning and analysis into the construction process. In the TAME (Tailoring A Measurement Environment) project at the University of Maryland, such an improvement-oriented software engineering process model was developed that uses the goal/question/metric paradigm to integrate the constructive and analytic aspects of software development. The model provides a mechanism for formalizing the characterization and planning tasks, controlling and improving projects based on quantitative analysis, learning in a deeper and more systematic way about the software process and product, and feeding the appropriate experience back into the current and future projects. The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment). The first in a series of TAME system prototypes has been developed. An assessment of experience with this first limited prototype is presented including a reassessment of its initial architecture.

Basili, Victor R.↗
NASA NTRS2005

Engineering Lessons Learned and Systems Engineering Applications

Systems Engineering is fundamental to good engineering, which in turn depends on the integration and application of engineering lessons learned and technical standards. Thus, good Systems Engineering also depends on systems engineering lessons learned from within the aerospace industry being documented and applied. About ten percent of the engineering lessons learned documented in the NASA Lessons Learned Information System are directly related to Systems Engineering. A key issue associated with lessons learned datasets is the communication and incorporation of this information into engineering processes. Systems Engineering has been defined (EINIS-632) as "an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system people, product, and process solutions that satisfy customer needs". Designing reliable space-based systems has always been a goal for NASA, and many painful lessons have been learned along the way. One of the continuing functions of a system engineer is to compile development and operations "lessons learned" documents and ensure their integration into future systems development activities. They can produce insights and information for risk identification identification and characterization. on a new project. Lessons learned files from previous projects are especially valuable in risk

Gill, Paul S.↗
NASA NTRS1987

Intelligent process development of foam molding for the Thermal Protection System (TPS) of the space shuttle external tank

A knowledge based system to assist process engineers in evaluating the processability and moldability of poly-isocyanurate (PIR) formulations for the thermal protection system of the Space Shuttle external tank (ET) is discussed. The Reaction Injection Molding- Process Development Advisor (RIM-PDA) is a coupled system which takes advantage of both symbolic and numeric processing techniques. This system will aid the process engineer in identifying a startup set of mold schedules and in refining the mold schedules to remedy specific process problems diagnosed by the system.

Bharwani, S. S.↗
NASA NTRS1986

Activities of the Center for the Space Processing of Engineering Materials

Topics addressed include: containerless processing and purification; directional and rapid solidification; high temperature alloys; oxidation resistant niobium alloys; metallic bonding; effects of solidification mode on structure-property relationships; and dispersion strengthened metal alloys. Each of the projects is reported by company association and follow according to alphabetical order of the company names.

Source record↗
NASA NTRS2012

Human Systems Integration in Practice: Constellation Lessons Learned

NASA's Constellation program provided a unique testbed for Human Systems Integration (HSI) as a fundamental element of the Systems Engineering process. Constellation was the first major program to have HSI mandated by NASA's Human Rating document. Proper HSI is critical to the success of any project that relies on humans to function as operators, maintainers, or controllers of a system. HSI improves mission, system and human performance, significantly reduces lifecycle costs, lowers risk and minimizes re-design. Successful HSI begins with sufficient project schedule dedicated to the generation of human systems requirements, but is by no means solely a requirements management process. A top-down systems engineering process that recognizes throughout the organization, human factors as a technical discipline equal to traditional engineering disciplines with authority for the overall system. This partners with a bottoms-up mechanism for human-centered design and technical issue resolution. The Constellation Human Systems Integration Group (HSIG) was a part of the Systems Engineering and Integration (SE&I) organization within the program office, and existed alongside similar groups such as Flight Performance, Environments & Constraints, and Integrated Loads, Structures and Mechanisms. While the HSIG successfully managed, via influence leadership, a down-and-in Community of Practice to facilitate technical integration and issue resolution, it lacked parallel top-down authority to drive integrated design. This presentation will discuss how HSI was applied to Constellation, the lessons learned and best practices it revealed, and recommendations to future NASA program and project managers. This presentation will discuss how Human Systems Integration (HSI) was applied to NASA's Constellation program, the lessons learned and best practices it revealed, and recommendations to future NASA program and project managers on how to accomplish this critical function.

Zumbado, Jennifer Rochlis↗
NASA NTRS1977

Boron/aluminum fan blades for SCAR engines

Processing procedures were developed to enhance boron/aluminum bond behavior and foreign object damage (FOD) tolerance. Design and analysis indicated that the J101 Stage 1 fan blade meets the required frequencies without a midspan shroud. The fabricability of full size J101 blades was assessed, while six blades were fabricated and finished machined.

Stabrylla, R. G.↗
NASA NTRS2019

Real-Time Background Oriented Schlieren: Catching Up With Knife Edge Schlieren

Background Oriented Schlieren (BOS) is a widely used technique that provides density gradient information in flow fields of interest, without imposing stringent optical quality requirements on the facility/experiment windows and/or optics used in the BOS setup. Typically, the BOS reference image is acquired before the test begins (flow off) and then the "live" image data are acquired during the actual testing/experiment (flow on). The raw BOS image data, while displayed in real-time as they are acquired from the camera, unfortunately provide little if any visual indication of the density gradients in the flow. Generally, the "live" images must be processed off-line after the testing is completed, providing no indication of the success of the BOS setup and no feedback on the operational success of the test. Advances in computer processing hardware enables the implementation of real-time processing and display of the BOS image data. Two different approaches to implementing the real-time BOS (RT-BOS) processing capability are described herein. First, a traditional multi-core Central Processing Unit (CPU) based approach using scheduled parallel threads is used to build a RT-BOS processing engine. In the second approach, a Graphical Processing Unit (GPU) approach is used to costruct a RT-BOS processing engine. Generally, high core count CPU processors can provide a useful processing rate for RT-BOS. However, the GPU based approach exceeds the processing capability of the CPU approach, at a fraction of the cost. The GPU approach places no restrictions on the Host PC processing capability, except that it be capable of acquiring the BOS image data from the camera in real-time.

Wernet, Mark P.↗
NASA NTRS2011

NASA System Engineering Design Process

This slide presentation reviews NASA's use of systems engineering for the complete life cycle of a project. Systems engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system. Each phase of a NASA project is terminated with a Key decision point (KDP), which is supported by major reviews.

Roman, Jose↗
NASA NTRS2015

Systems Engineering Lessons Learned for Class D Missions

One of NASA's goals within human exploration is to determine how to get humans to Mars safely and to live and work on the Martian surface. To accomplish this goal, several smaller missions act as stepping-stones to the larger end goal. NASA uses these smaller missions to develop new technologies and learn about how to survive outside of Low Earth Orbit for long periods. Additionally, keeping a cadence of these missions allows the team to maintain proficiency in the complex art of bringing spacecraft to fruition. Many of these smaller missions are robotic in nature and have smaller timescales, whereas there are others that involve crew and have longer mission timelines. Given the timelines associated with these various missions, different levels of risk and rigor need to be implemented to be more in line with what is appropriate for the mission. Thus, NASA has four different classifications that range from Class A to Class D based on the mission details. One of these projects is the Resource Prospector (RP) Mission, which is a multi-center and multi-institution collaborative project to search for volatiles in the polar regions of the Moon. The RP mission is classified as a Class D mission and as such, has the opportunity to more tightly manage, and therefore accept, greater levels of risk. The requirements for Class D missions were at the forefront of the design and thus presented unique challenges in vehicle development and systems engineering processes. This paper will discuss the systems engineering process at NASA and how that process is tailored for Class D missions, specifically the RP mission.

Rojdev, Kristina↗
NASA NTRSDate not supplied

Impact of Emerging Computing Architectures and Opportunities for Process Systems Engineering Applications

Moore’s “law” was the observation that the number of transistors in an integrated circuit doubled approximately every two years. This trend has distinctly failed to hold in recent years. The death of Moore’s law has left researchers and practitioners in the computational sciences searching for technologies to provide the speedups formerly supported by Moore’s law. Previously overlooked chip architectures and other computing technologies are now receiving more development resources. Critically, these technologies are gaining more mature software support, opening their adoption by researchers in algorithms and applications. In this article, we review some of these computing technologies, their relationship with various algorithms and applications, and their potential benefits (or pitfalls). We close with recommendations for future work by the process systems engineering community specifically.

Emerging hardware↗
DOE OSTI2025

Integrating Cyber-Informed Engineering into Process Automation

As organizations increasingly automate their core missions and essential functions to address business risks and enhance efficiency, process automation becomes pivotal. This shift, involving minimal or no manual intervention, significantly impacts an organization's cyber-risk landscape. While automation drives efficiencies, it also introduces new cyber risks if not properly managed. Cyber-Informed Engineering (CIE) provides a proactive framework for managing these digital risks, enhancing cyber-resilience in process automation. This document supports organizations in applying CIE principles to mitigate the cyber risks associated with automation. The outlined approach can be independently implemented to improve any organization’s cyber-resilience, ensuring that the advantages of automation do not result in unaddressed or unmanaged digital risks. It serves as a starting point, offering considerations for integrating CIE principles and practices into organizational processes. CIE is presented as an iterative process, fostering continuous improvement and reinforcing the engineering and operational cultures to manage digital risks effectively. The document is structured as follows: Section 1 provides background on CIE and process automation, and their integration. Section 2 explores the twelve CIE principles in the context of process automation, highlighting key questions, engineering considerations, and implications for digital risk management. Section 3 synthesizes the findings and offers recommendations to advance resilience by design.

42 - ENGINEERING↗