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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

Assessing Alternatives in the Systems Engineering Process: Case Study of an Earth Observing Satellite Concept

Defining design alternatives constitutes one of the critical initial steps of the systems engineering process. Once these design alternatives have been identified, assessing which alternatives best satisfy the project’s objectives can prove to be challenging when dealing with complex decision frameworks. Complex systems often involve the participation of different interest groups, who have different value systems and are focused on distinct aspects of the project. For example, design alternatives might be assessed predominantly for their technical merit by one group of stakeholders, while a different group might be more inclined to assess the design alternatives primarily based on programmatic values. MESCAL (Monitoring the Evolving State of Clouds and Aerosol Layers) is an ongoing NASA / CNES (Centre National d’Etudes Spatiales) joint study for an active remote sensing Earth observing satellite. Several design alternatives have been identified and the assessment of these alternatives requires consideration of a variety of factors. This paper presents the approach that was used to support a global assessment of the MESCAL design alternatives. A mapping of the interactions between mission, instrument, and science requirements was modeled to support the assessment of the trade space. In addition, a set of metrics was developed to structure the assessment that was conducted. Finally, this paper also discusses the general applicability of these metrics to other science mission concepts in the formulation phase.

Ivanco, Marie L.↗
NASA NTRS2012

Tailoring Systems Engineering Processes in a Conceptual Design Environment: A Case Study at NASA Marshall Spaceflight Center's ACO

This paper provides an overview of Systems Engineering as it is applied in a conceptual design space systems department at the National Aeronautics and Space Administration (NASA) Marshall Spaceflight Center (MSFC) Advanced Concepts Office (ACO). Engineering work performed in the NASA MFSC's ACO is targeted toward the Exploratory Research and Concepts Development life cycle stages, as defined in the International Council on Systems Engineering (INCOSE) System Engineering Handbook. This paper addresses three ACO Systems Engineering tools that correspond to three INCOSE Technical Processes: Stakeholder Requirements Definition, Requirements Analysis, and Integration, as well as one Project Process Risk Management. These processes are used to facilitate, streamline, and manage systems engineering processes tailored for the earliest two life cycle stages, which is the environment in which ACO engineers work. The role of systems engineers and systems engineering as performed in ACO is explored in this paper. The need for tailoring Systems Engineering processes, tools, and products in the ever-changing engineering services ACO provides to its customers is addressed.

Mulqueen, John↗
NASA NTRS1997

Implementation of Insight Responsibilities in Process Engineering

This report describes an approach for evaluating flight readiness (COFR) and contractor performance evaluation (award fee) as part of the insight role of NASA Process Engineering at Kennedy Space Center. Several evaluation methods are presented, including systems engineering evaluations and use of systems performance data. The transition from an oversight function to the insight function is described. The types of analytical tools appropriate for achieving the flight readiness and contractor performance evaluation goals are described and examples are provided. Special emphasis is placed upon short and small run statistical quality control techniques. Training requirements for system engineers are delineated. The approach described herein would be equally appropriate in other directorates at Kennedy Space Center.

Osborne, Deborah M.↗
NASA NTRS1992

Systems engineering process and organization assessment

The purpose of this report is to briefly summarize the results of an eight week assessment of NASA/MSFC Phase A and Phase B systems engineering processes, methodologies, and activities. Specifically, fourteen inconsistencies or weaknesses were identified and recommendations for corrective action were generated. A 1.5 hour briefing on these results was given in EL51 on 8-11-92; that documentation is available from the author or either NASA Colleague.

Batson, Robert G.↗
NASA NTRS1993

The importance of cost considerations in the systems engineering process

This paper examines the question of cost, from the birth of a program to its conclusion, particularly from the point of view of large multi-center programs, and suggests how to avoid some of the traps and pitfalls. Emphasis is given to cost in the systems engineering process, but there is an inevitable overlap with program management. (These terms, systems engineering and program management, have never been clearly defined.) In these days of vast Federal budget deficits and increasing overseas competition, it is imperative that we get more for each research and development dollar. This is the only way we will retain our leadership in high technology and, in the long run, our way of life.

Hodge, John D.↗
NASA NTRS2013

Implementation of a Goal-Based Systems Engineering Process Using the Systems Modeling Language (SysML)

Building upon the purpose, theoretical approach, and use of a Goal-Function Tree (GFT) being presented by Dr. Stephen B. Johnson, described in a related Infotech 2013 ISHM abstract titled "Goal-Function Tree Modeling for Systems Engineering and Fault Management", this paper will describe the core framework used to implement the GFTbased systems engineering process using the Systems Modeling Language (SysML). These two papers are ideally accepted and presented together in the same Infotech session. Statement of problem: SysML, as a tool, is currently not capable of implementing the theoretical approach described within the "Goal-Function Tree Modeling for Systems Engineering and Fault Management" paper cited above. More generally, SysML's current capabilities to model functional decompositions in the rigorous manner required in the GFT approach are limited. The GFT is a new Model-Based Systems Engineering (MBSE) approach to the development of goals and requirements, functions, and its linkage to design. As a growing standard for systems engineering, it is important to develop methods to implement GFT in SysML. Proposed Method of Solution: Many of the central concepts of the SysML language are needed to implement a GFT for large complex systems. In the implementation of those central concepts, the following will be described in detail: changes to the nominal SysML process, model view definitions and examples, diagram definitions and examples, and detailed SysML construct and stereotype definitions.

Patterson, Jonathan D.↗
NASA NTRS2013

Implementation of a Goal-Based Systems Engineering Process Using the Systems Modeling Language (SysML)

Building upon the purpose, theoretical approach, and use of a Goal-Function Tree (GFT) being presented by Dr. Stephen B. Johnson, described in a related Infotech 2013 ISHM abstract titled "Goal-Function Tree Modeling for Systems Engineering and Fault Management", this paper will describe the core framework used to implement the GFTbased systems engineering process using the Systems Modeling Language (SysML). These two papers are ideally accepted and presented together in the same Infotech session. Statement of problem: SysML, as a tool, is currently not capable of implementing the theoretical approach described within the "Goal-Function Tree Modeling for Systems Engineering and Fault Management" paper cited above. More generally, SysML's current capabilities to model functional decompositions in the rigorous manner required in the GFT approach are limited. The GFT is a new Model-Based Systems Engineering (MBSE) approach to the development of goals and requirements, functions, and its linkage to design. As a growing standard for systems engineering, it is important to develop methods to implement GFT in SysML. Proposed Method of Solution: Many of the central concepts of the SysML language are needed to implement a GFT for large complex systems. In the implementation of those central concepts, the following will be described in detail: changes to the nominal SysML process, model view definitions and examples, diagram definitions and examples, and detailed SysML construct and stereotype definitions.

Breckenridge, Jonathan T.↗
NASA NTRS2001

Space Shuttle Main Engine Joint Data List Applying Today's Desktop Technologies to Facilitate Engine Processing

Boeing-Rocketdyne's Space Shuttle Main Engine (SSME) is the world's first large reusable liquid rocket engine. The space shuttle propulsion system has three SSMEs, each weighing 7,400 lbs and providing 470,000 lbs of thrust at 100% rated power level. To ensure required safety and reliability levels are achieved with the reusable engines, each SSME is partially disassembled, inspected, reassembled, and retested at Kennedy Space Center between each flight. Maintenance processing must be performed very carefully to replace any suspect components, maintain proper engine configuration, and avoid introduction of contaminants that could affect performance and safety. The long service life, and number, complexity, and pedigree of SSME components makes logistics functions extremely critical. One SSME logistics challenge is documenting the assembly and disassembly of the complex joint configurations. This data (joint nomenclature, seal and fastener identification and orientation, assembly sequence, fastener torques, etc.) must be available to technicians and engineers during processing. Various assembly drawings and procedures contain this information, but in this format the required (practical) joint data can be hard to find, due to the continued use of archaic engineering drawings and microfilm for field site use. Additionally, the release system must traverse 2,500 miles between design center and field site, across three time zones, which adds communication challenges and time lags for critical engine configuration data. To aid in information accessibility, a Joint Data List (JDL) was developed that allows efficient access to practical joint data. The published JDL has been a very useful logistics product, providing illustrations and information on the latest SSME configuration. The JDL identifies over 3,350 unique parts across seven fluid systems, over 300 joints, times two distinct engine configurations. The JDL system was recently converted to a web-based, navigable electronic manual that contains all the required data and illustrations in expanded view format using standard PC products (Word, Excel, PDF, Photoshop). The logistics of accurately releasing this information to field personnel was greatly enhanced via the utilization of common office products to produce a more user-friendly format than was originally developed under contract to NASA. This was done without reinventing the system, which would be cost prohibitive on a program of this maturity. The brunt of the joint part tracking is done within the logistics organization and disseminated to all field sites, without duplicating effort at each site. The JDL is easily accessible across the country via the NASA intranet directly at the SSME workstand. The advent of this logistics data product has greatly enhanced the reliability of tracking dynamic changes to the SSME and greatly reduces engineering change turnaround time and potential for errors. Since the inception of the JDL system in 1997, no discrepant parts have propagated to engine assembly operations. This presentation focuses on the challenges overcome and the techniques used to apply today's desktop technologies to an existing logistics data source.

Jacobs, Kenneth↗
NASA NTRS1986

Cost Risk Analysis Based on Perception of the Engineering Process

In most cost estimating applications at the NASA Langley Research Center (LaRC), it is desirable to present predicted cost as a range of possible costs rather than a single predicted cost. A cost risk analysis generates a range of cost for a project and assigns a probability level to each cost value in the range. Constructing a cost risk curve requires a good estimate of the expected cost of a project. It must also include a good estimate of expected variance of the cost. Many cost risk analyses are based upon an expert's knowledge of the cost of similar projects in the past. In a common scenario, a manager or engineer, asked to estimate the cost of a project in his area of expertise, will gather historical cost data from a similar completed project. The cost of the completed project is adjusted using the perceived technical and economic differences between the two projects. This allows errors from at least three sources. The historical cost data may be in error by some unknown amount. The managers' evaluation of the new project and its similarity to the old project may be in error. The factors used to adjust the cost of the old project may not correctly reflect the differences. Some risk analyses are based on untested hypotheses about the form of the statistical distribution that underlies the distribution of possible cost. The usual problem is not just to come up with an estimate of the cost of a project, but to predict the range of values into which the cost may fall and with what level of confidence the prediction is made. Risk analysis techniques that assume the shape of the underlying cost distribution and derive the risk curve from a single estimate plus and minus some amount usually fail to take into account the actual magnitude of the uncertainty in cost due to technical factors in the project itself. This paper addresses a cost risk method that is based on parametric estimates of the technical factors involved in the project being costed. The engineering process parameters are elicited from the engineer/expert on the project and are based on that expert's technical knowledge. These are converted by a parametric cost model into a cost estimate. The method discussed makes no assumptions about the distribution underlying the distribution of possible costs, and is not tied to the analysis of previous projects, except through the expert calibrations performed by the parametric cost analyst.

Dean, Edwin B.↗
NASA NTRS1972

Methodology for the systems engineering process. Volume 1: System functional activities

Systems engineering is examined in terms of functional activities that are performed in the conduct of a system definition/design, and system development is described in a parametric analysis that combines functions, performance, and design variables. Emphasis is placed on identification of activities performed by design organizations, design specialty groups, as well as a central systems engineering organizational element. Identification of specific roles and responsibilities for doing functions, and monitoring and controlling activities within the system development operation are also emphasized.

Nelson, J. H.↗
NASA NTRS2004

Automation of Design Engineering Processes

A method, and a computer program that helps to implement the method, have been developed to automate and systematize the retention and retrieval of all the written records generated during the process of designing a complex engineering system. It cannot be emphasized strongly enough that all the written records as used here is meant to be taken literally: it signifies not only final drawings and final engineering calculations but also such ancillary documents as minutes of meetings, memoranda, requests for design changes, approval and review documents, and reports of tests. One important purpose served by the method is to make the records readily available to all involved users via their computer workstations from one computer archive while eliminating the need for voluminous paper files stored in different places. Another important purpose served by the method is to facilitate the work of engineers who are charged with sustaining the system and were not involved in the original design decisions. The method helps the sustaining engineers to retrieve information that enables them to retrace the reasoning that led to the original design decisions, thereby helping them to understand the system better and to make informed engineering choices pertaining to maintenance and/or modifications of the system. The software used to implement the method is written in Microsoft Access. All of the documents pertaining to the design of a given system are stored in one relational database in such a manner that they can be related to each other via a single tracking number.

Torrey, Glenn↗
NASA NTRSDate not supplied

Planetary Protection is Not a One Size Fits All Missions Approach: Enabling the Planetary Protection Programmatic and Engineering Process

Missions have a wide range of variables that change their management and engineering structure (e.g., competed vs directed missions, multiple NASA centers, international partnerships, increased commercial collaborations, etc.). Why would an identical planetary protection approach and structure for each mission make sense in this evolving landscape? Missions do not fit in a one-size-fits-all approach, likewise their planetary protection process should not be a one-size-fits-all approach. During the significant update to NPR 8715.24 and NASA-STD-8719.27 planetary protection policies, the programmatic execution and engineering implementation processes were changed to provide clarification, streamlining, and expansion to include alternative approaches. From a programmatic perspective, these changes include the flexibility in timing and combination of gate products in addition to providing varying levels of technical depth commensurate and appropriate with the mission categorization. From a technical perspective, these changes include the ability to A) leverage either a performance-based and/or a prescriptive-based approach, B) identify applicable international consensus standards for verification, and C) propose alternative methods that adhere to sound scientific and engineering consensus. This presentation will directly highlight the culture shift in planetary protection, areas of flexibility available to the technical community for mission program and engineering execution, and feature some of the specific mission scenarios that have already leveraged such processes.

Nick Benardini↗
NASA NTRS1988

Low level image processing techniques using the pipeline image processing engine in the flight telerobotic servicer

The sensory processing system for the NASA/NBS Standard Reference Model (NASREM) for telerobotic control is described. This control system architecture was adopted by NASA of the Flight Telerobotic Servicer. The control system is hierarchically designed and consists of three parallel systems: task decomposition, world modeling, and sensory processing. The Sensory Processing System is examined, and in particular the image processing hardware and software used to extract features at low levels of sensory processing for tasks representative of those envisioned for the Space Station such as assembly and maintenance are described.

Nashman, Marilyn↗
NASA NTRS2003

Intelligent Work Process Engineering System

Optimizing performance on work activities and processes requires metrics of performance for management to monitor and analyze in order to support further improvements in efficiency, effectiveness, safety, reliability and cost. Information systems are therefore required to assist management in making timely, informed decisions regarding these work processes and activities. Currently information systems regarding Space Shuttle maintenance and servicing do not exist to make such timely decisions. The work to be presented details a system which incorporates various automated and intelligent processes and analysis tools to capture organize and analyze work process related data, to make the necessary decisions to meet KSC organizational goals. The advantages and disadvantages of design alternatives to the development of such a system will be discussed including technologies, which would need to bedesigned, prototyped and evaluated.

Williams, Kent E.↗
NASA NTRSDate not supplied

Introduction of an Agile Systems Engineering Process to the NASA Armstrong Flight Research Center

This paper will provide background on the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD) ARMD Test Data Portal (ATDP) effort along with the rationale that motivated the ATDP team to consider implementing an agile systems engineering (SE) process. The primary motivation for using this new SE process was based on the desire to mitigate a major risk to project success. Since the agile SE process had never been used before at the NASA Armstrong Flight Research Center (AFRC), utilizing this new SE process required a trailblazing effort to introduce it to NASA AFRC leadership. As a result, the ATDP team chose to adhere to the agile SE process in addition to the trusted classical waterfall SE process on ATDP. Through successful execution of this hybrid SE process during Phase I, along with demonstrating the value and rigor of the agile SE process, NASA AFRC leadership ultimately permitted the ATDP project to solely use the agile SE process for developments beyond Phase I. While it is the opinion of the authors that the classical SE process is more effective for most projects at NASA AFRC, some projects may deem that the agile SE process is more advantageous. Although this paper is focused on introducing the agile SE process to NASA AFRC, lessons learned will be valuable to other organizations as well. Details of how the ATDP team implemented the agile SE process during Phase I will be summarized, along with how the team met all required classical SE milestones. Lessons learned throughout Phase I of this effort will also be highlighted.

Daniel S. Jones↗
NASA NTRS2003

COBRA System Engineering Processes to Achieve SLI Strategic Goals

The COBRA Prototype Main Engine Development Project was an endeavor conducted as a joint venture between Pratt & Whitney and Aerojet to conduct risk reduction in LOX/LH2 main engine technology for the NASA Space Launch Initiative (SLI). During the seventeen months of the project (April 2001 to September 2002), approximately seventy reviews were conducted, beginning with the Engine Systems Requirements Review (SRR) and ending with the Engine Systems Interim Design Review (IDR). This paper discusses some of the system engineering practices used to support the reviews and the overall engine development effort.

Ballard, Richard O.↗