Search NASA⌕ Search

SEARCH · Search NASA

Results for “process systems engineering”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
DOE OSTI2024

Recent Advances of PyROS: A Pyomo Solver for Nonconvex Two-Stage Robust Optimization in Process Systems Engineering

This poster highlights uncertainty and technical risk reduction capabilities in CCSI2, with a focus on robust optimization. It presents recent advances of the two-stage robust optimization (RO) solver PyROS and applications to advanced energy systems optimization. To demonstrate the computational performance and reliability of PyROS, a benchmarking study on a library of over 8,500 small-scale RO problems is presented. Further, PyROS is used to obtain robust system designs of a MEA-based CO2 absorber under uncertainty in the thermodynamic property models for a variety of CO2 capture rate threshold requirements. Overall, the results demonstrate that the PyROS solver, including recent extensions to multi-stage RO settings, provides a reliable avenue to optimize the design and operation of advanced energy systems subject to various sources of parametric uncertainty.

Sherman, Jason↗
DOE OSTI2024

Process systems engineering enables efficient and sustainable membrane-based critical material separations

This presentation summarizes work completed over the past year for PrOMMiS Task 2.1. The first half of the preseation motivates the need to develop sustainable critical mineral separation technology, and how PSE is particularly well-suited to tackle this problem. The second half of the presentation presents preliminary results for the custom cost model for diafiltration (2.1) using the superstructure flowsheet developed by Carnegie Mellon University. The presentation serves to emphasize the multi-disciplinary and collaborate nature of developing a circular economy of critical minerals and materials.

Dougher, Molly↗
NASA NTRS1984

Optimization in the systems engineering process

The objective is to look at optimization as it applies to the design process at a large aircraft company. The design process at Lockheed-Georgia is described. Some examples of the impact that optimization has had on that process are given, and then some areas that must be considered if optimization is to be successful and supportive in the total design process are indicated. Optimization must continue to be sold and this selling is best done by consistent good performance. For this good performance to occur, the future approaches must be clearly thought out so that the optimization methods solve the problems that actually occur during design. The visibility of the design process must be maintained as further developments are proposed. Careful attention must be given to the management of data in the optimization process, both for technical reasons and for administrative purposes. Finally, to satisfy program needs, provisions must be included to supply data to support program decisions, and to communicate with design processes outside of the optimization process. If designers fail to adequately consider all of these needs, the future acceptance of optimization will be impeded.

Lemmerman, L. A.↗
NASA NTRS2010

Systems Engineering Processes at NASA/SR-71 Pratt and Whitney J58 Engine

This summer I was given several opportunities at NASA's Dryden Flight Research Center (DFRC). The first opportunity was given to me by a Senior Propulsion Engineer, Kurtt Kloesel, to work in a specialized engineering discipline. My task was to research the Pratt & Whitney J58 engine that was used on the SR-71 Blackbird. I entered the data I collected into engine modeling software programs in order to receive certain outputs, such as net thrust. I also had to take a "crash course" in propulsion in order to better understand the research I was performing. To facilitate my understanding of propulsion principals and formulas, I worked many problems out of thermodynamics and propulsion textbooks and entered the given values of various situations into the modeling software.

Donastorg, Cristina↗
NASA NTRS1993

The systems engineering overview and process (from the Systems Engineering Management Guide, 1990)

The past several decades have seen the rise of large, highly interactive systems that are on the forward edge of technology. As a result of this growth and the increased usage of digital systems (computers and software), the concept of systems engineering has gained increasing attention. Some of this attention is no doubt due to large program failures which possibly could have been avoided, or at least mitigated, through the use of systems engineering principles. The complexity of modern day weapon systems requires conscious application of systems engineering concepts to ensure producible, operable and supportable systems that satisfy mission requirements. Although many authors have traced the roots of systems engineering to earlier dates, the initial formalization of the systems engineering process for military development began to surface in the mid-1950s on the ballistic missile programs. These early ballistic missile development programs marked the emergence of engineering discipline 'specialists' which has since continued to grow. Each of these specialties not only has a need to take data from the overall development process, but also to supply data, in the form of requirements and analysis results, to the process. A number of technical instructions, military standards and specifications, and manuals were developed as a result of these development programs. In particular, MILSTD-499 was issued in 1969 to assist both government and contractor personnel in defining the systems engineering effort in support of defense acquisition programs. This standard was updated to MIL-STD499A in 1974, and formed the foundation for current application of systems engineering principles to military development programs.

Source record↗
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↗
DOE OSTI2025

CIE Analysis Process for Engineered Systems

"CIE Analysis Process for Engineered Systems" outlines a comprehensive methodology for integrating Cyber-Informed Engineering (CIE) principles into both new and existing engineered systems. Sponsored by the U.S. Department of Energy’s Office of Cybersecurity, Energy Security, and Emergency Response (DOE CESER), the process aims to achieve cyber-informed decisions by producing functional security requirements for new systems and retrofitting existing systems to mitigate digital risks. The document details a step-by-step approach, including mission and function definition, digital asset awareness, consequence analysis, and mitigation analysis. It emphasizes the importance of documenting mechanical, electrical, programmable, and network components to protect system functions and provides examples and considerations for each step. The ultimate goal is to ensure that engineered systems remain resilient against cyber threats, maintaining safety, performance, and reliability.

42 - ENGINEERING↗
NASA NTRSDate not supplied

Oversimplification of Systems Engineering Goals, Processes, and Criteria in NASA Space Life Support

This paper investigates the oversimplification of the inherently complex systems engineering process in space life support. The standard systems engineering process steps are described. The International Space Station (ISS) life support system is explained with its goals and performance criteria. Although it is not usually emphasized, the essential function of developing a hierarchy of systems and subsystems is to simplify the design process. The System Complexity Metric (SCM) shows how this di-vide-and-conquer approach also reduces the system complexity. The complete systems engineering process has many detailed steps. It is often simplified because of the effort required and the human limitations on working memory and decision span. Systems analysis demands slow, logical, and fo-cused thinking but is often bypassed in favor of quick, intuitive, subconscious “gut feel.” A study of 100 system designs found examples of 12 specific mental mistakes, such as ignoring stakeholder needs, and these mistakes are essentially oversimplifications of the systems engineering process. An analysis of space life support goals, options, criteria, and processes found 11 examples of oversimplifications in systems engineering, such as neglecting safety and cost. All these 11 oversimplifications could be traced to one or more of the 12 previously identified mental mistakes or other well-known ones, such as ig-noring sunk costs. Oversimplification of the systems engineering process is rarely noticed but is a common and harmful problem. A study of failures in 50 different space systems found that problems in systems engineering caused failures and often led to errors in design, development, and test that further contributed to failure. It seems that more diligent systems engineering could prevent many project problems and failures, but projects seem to be more guided by “gut feel” based on tradition, authority, and consensus than on the logical, rational systems engineering approach.

Simplified systems engineering↗
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 NTRS1996

Working on the Boundaries: Philosophies and Practices of the Design Process

While systems engineering process is a program formal management technique and contractually binding, the design process is the informal practice of achieving the design project requirements throughout all design phases of the systems engineering process. The design process and organization are systems and component dependent. Informal reviews include technical information meetings and concurrent engineering sessions, and formal technical discipline reviews are conducted through the systems engineering process. This paper discusses and references major philosophical principles in the design process, identifies its role in interacting systems and disciplines analyses and integrations, and illustrates the process application in experienced aerostructural designs.

Ryan, R.↗
NASA NTRS2016

Systems Engineering and Management Applications of ISO 9001:2015 for Government

The manufacturing segment of the business world is busy assessing the impact of ISO 9001:2015, and updating their management systems to meet the required compliance date. What does the new revision mean for government agencies that deliver large engineering projects rather than mass production? In fact, the standard, especially the new revision, can be used quite readily for government agencies, or applied to specific projects, once it is understood in terms of the similarities with systems engineering and project management. From there it can be extrapolated to "mission realization" systems, and a Quality Management System (QMS) is a logical result that can bring order to processes and systems that likely already exist in some fashion. ISO 9001:2015 is less product-oriented than previous versions. It can be more broadly applied to public organizations as well as private; and to services (missions) as well as products. The emphasis on risk management in the revised standard provides the needed balance for weighing decisions with respect to cost, schedule, technical, safety, and regulatory compliance; so if this is not part of agency governance already, this is a good place to start, especially for large engineering projects. The Systems Engineering standard used for this analysis is from NASA's NPR 7123.1 NASA Systems Engineering Processes and Requirements; however, those who are more familiar with ISO/IEC 26702 Systems Engineering-application and management of the systems engineering process, or SAE/EIA 632 Processes for Engineering a System will also recognize the similarities. In reality, the QMS outlined by ISO 9001 reinforces the systems engineering processes, and serves to ensure that they are adequately implemented, although most of the ISO 9001 literature emphasizes the production and process aspects of the standard. Rather than beginning with ISO 9001and getting lost in the vocabulary, it is useful to begin with the systems engineering lifecycle. Identification of stakeholder expectations, identifying solutions, creating specific product or service designs, production of the product or service, delivery to the public, and the associated management, planning, and control processes, are a familiar place to begin thinking of the overall system of identifying, designing, and competing a project or mission. Lining up this lifecycle with the ISO requirements (see Figure 1) illustrates how a quality management system is concerned with the same processes, and provides a governance and assurance function. If implemented properly, there are cost savings resulting from less rework, repair, reprocessing, failures, misplaced documents, and similar types of deficiencies1. Starting with an organization's systems engineering processes allows the organization to use their own terminology for a QMS plan, and tailor the plan to their own project or organization, so that it is more easily developed, understood, and implemented.

Shepherd, Christena C.↗
NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challange

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

systems engineering↗
NASA NTRSDate not supplied

Systems Engineering Tutorial with Case Studies

Due to the ever-growing number of complex technical problems facing our world, a Systems Engineering approach is needed to assist in successful design, build and implementation of solutions. The interdisciplinary technical structure of current systems, technical processes representing System Design, Technical Management and Product Realization are instrumental in the development and integration of new technologies into mainstream applications. This tutorial will demonstrate the application of Systems Engineering tools to these types of problems. Learning objectives include, understanding how to develop and engineer a conceptual system; understand the importance of teams, communication, requirements definition, interface control, and focus on deliverables; useful tools and techniques for each aspect of the System Engineering process including Model Based Systems Engineering which will be touched upon lightly. Some hands-on problems will be pursued especially in requirements development which is always key to a successful project. Case studies will be presented to assist in the learning process.

Systems Engineering↗
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 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 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↗