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
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↗
NASA NTRS2021

NASA Human Systems Integration Handbook

This handbook is intended to provide general guidance and information on Human Systems Integration (HSI) for the NASA community and the applicability of HSI to NASA programs and projects. The primary goals are to increase awareness and consistency across the Agency, advance the practice and implementation of HSI principles, and provide invaluable information and guidance to HSI practitioners in the performance of their duties. Specific aims of this handbook are to define HSI, illustrate the value of HSI in programmatic decisions, demonstrate how HSI fits into the NASA project life cycle process, describe how HSI applies across all three NASA Technical Authorities, provide guidance on HSI processes and products, and provide helpful information on HSI resources within the NASA community. Largely within the engineering community, a system is thought of as the integration or assemblance of hardware and software that together perform a function. HSI considers a system to be the integration of hardware, software, humans, data, and processes, where the human in HSI refers to all personnel involved with a given system, including system owners, users/customers, operators, maintainers, assemblers, support personnel, logistics suppliers, training personnel, test personnel, and others. This handbook should be used as a companion for implementing NPR 7123.1, Systems Engineering Processes and Requirements, the NASA Systems Engineering Handbook, NASA directives, and any Center-specific handbooks and directives developed for implementing programs and projects. As of 2021, both NPR 7123.1 and NPR 7120.5 require HSI to be implemented within NASA technical efforts.

Lisa O Rippy↗
NASA NTRS2017

NASA Systems Engineering Handbook

The update of this handbook continues the methodology of the previous revision: a top-down compatibility with higher level Agency policy and a bottom-up infusion of guidance from the NASA practitioners in the field. This approach provides the opportunity to obtain best practices from across NASA and bridge the information to the established NASA systems engineering processes and to communicate principles of good practice as well as alternative approaches rather than specify a particular way to accomplish a task. The result embodied in this handbook is a top-level implementation approach on the practice of systems engineering unique to NASA. Material used for updating this handbook has been drawn from many sources, including NPRs, Center systems engineering handbooks and processes, other Agency best practices, and external systems engineering textbooks and guides. This handbook consists of six chapters: (1) an introduction, (2) a systems engineering fundamentals discussion, (3) the NASA program project life cycles, (4) systems engineering processes to get from a concept to a design, (5) systems engineering processes to get from a design to a final product, and (6) crosscutting management processes in systems engineering. The chapters are supplemented by appendices that provide outlines, examples, and further information to illustrate topics in the chapters. The handbook makes extensive use of boxes and figures to define, refine, illustrate, and extend concepts in the chapters.

ENGINEERING MANAGEMENT; HANDBOOKS; MANAGEMENT METH↗
NASA NTRS2009

Collaborative Systems Thinking: A Response to the Problems Faced by Systems Engineering's 'Middle Tier'

Experienced systems engineers are adept at more than implementing systems engineering processes: they utilize systems thinking to solve complex engineering problems. Within the space industry demographics and economic pressures are reducing the number of experienced systems engineers that will be available in the future. Collaborative systems thinking within systems engineering teams is proposed as a way to integrate systems engineers of various experience levels to handle complex systems engineering challenges. This paper uses the GOES-R Program Systems Engineering team to illustrate the enablers and barriers to team level systems thinking and to identify ways in which performance could be improved. Ways NASA could expand its engineering training to promote team-level systems thinking are proposed.

Phfarr, Barbara B.↗
NASA NTRS2019

Medical System Concept of Operations for Mars Exploration Mission-11: Exploration Medical Capability (ExMC) Element - Human Research Program

NASA’s exploration missions to Mars will have durations of 2-3 years and will take humans farther away from Earth than ever before. This will result in a paradigm shift for mission planning, spacecraft design, human systems integration, and in-flight medical care. Constraints on real-time communication, resupply, and medical evacuation are major architectural drivers. These constraints require medical system development to be tightly integrated with mission and vehicle design to provide crew autonomy and enable mission success. This concept of operations provides a common vision of medical care for developing a medical system for Mars exploration missions. It documents an overview of the stakeholder needs and goals of a medical system and provides examples of the types of activities the system will be used for during the mission. Development of the concept of operations considers mission variables such as distance from Earth, duration of mission, time to definitive medical care, communication protocols between crewmembers and ground support, personnel capabilities and skill sets, medical hardware and software, and medical data management. The information provided in this document informs the ExMC Systems Engineering effort to define the functions to be provided by the medical system. In addition, this concept of operations will inform the subsequent systems engineering process of developing technical requirements, system architectures, interfaces, and verification and validation approaches for the medical system. This document supports the closure of ExMC Gap Med01: We do not have a concept of operations for medical care during exploration missions, corresponding to the ExMC-managed human system risk: Risk of Adverse Health Outcomes & Decrements in Performance due to Inflight Medical Conditions. This document is applicable to the ExMC Element Systems Engineering process and may be used for collaboration within the Human Research Program.

Urbina, Michelle↗
NASA NTRS2011

NASA Risk Management Handbook

The purpose of this handbook is to provide guidance for implementing the Risk Management (RM) requirements of NASA Procedural Requirements (NPR) document NPR 8000.4A, Agency Risk Management Procedural Requirements [1], with a specific focus on programs and projects, and applying to each level of the NASA organizational hierarchy as requirements flow down. This handbook supports RM application within the NASA systems engineering process, and is a complement to the guidance contained in NASA/SP-2007-6105, NASA Systems Engineering Handbook [2]. Specifically, this handbook provides guidance that is applicable to the common technical processes of Technical Risk Management and Decision Analysis established by NPR 7123.1A, NASA Systems Engineering Process and Requirements [3]. These processes are part of the \Systems Engineering Engine. (Figure 1) that is used to drive the development of the system and associated work products to satisfy stakeholder expectations in all mission execution domains, including safety, technical, cost, and schedule. Like NPR 7123.1A, NPR 8000.4A is a discipline-oriented NPR that intersects with product-oriented NPRs such as NPR 7120.5D, NASA Space Flight Program and Project Management Requirements [4]; NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements [5]; and NPR 7120.8, NASA Research and Technology Program and Project Management Requirements [6]. In much the same way that the NASA Systems Engineering Handbook is intended to provide guidance on the implementation of NPR 7123.1A, this handbook is intended to provide guidance on the implementation of NPR 8000.4A. 1.2 Scope and Depth This handbook provides guidance for conducting RM in the context of NASA program and project life cycles, which produce derived requirements in accordance with existing systems engineering practices that flow down through the NASA organizational hierarchy. The guidance in this handbook is not meant to be prescriptive. Instead, it is meant to be general enough, and contain a sufficient diversity of examples, to enable the reader to adapt the methods as needed to the particular risk management issues that he or she faces. The handbook highlights major issues to consider when managing programs and projects in the presence of potentially significant uncertainty, so that the user is better able to recognize and avoid pitfalls that might otherwise be experienced.

Dezfuli, Homayoon↗
NASA NTRS2010

Athena: Providing Insight into the History of the Universe

The American Institute for Aeronautics and Astronautics has provided a Request for Proposal which calls for a manned mission to a Near-Earth Object. It is the goal of Team COLBERT to respond to their request by providing a reusable system that can be implemented as a solid stepping stone for future manned trips to Mars and beyond. Despite Team COLBERT consisting of only students in Aerospace Engineering, in order to achieve this feat, the team must employ the use of Systems Engineering. Tools and processes from Systems Engineering will provide quantitative and semi-quantitative tools for making design decisions and evaluating items such as budgets and schedules. This paper will provide an in-depth look at some of the Systems Engineering processes employed and will step through the design process of a Human Asteroid Exploration System.

Murphy, Gloria A.↗
NASA NTRSDate not supplied

What Has ExMC Systems Engineering Been Up To Since Last IWS?

Long duration Lunar and Martian missions will change the way NASA currently practices medicine. The missions will require more autonomous capability compared to current low Earth orbit operations. For the medical system, lack of consumable resupply, evacuation opportunities, and real-time ground support are key drivers toward greater autonomy. Recognition of the limited mission and vehicle resources available to carry out exploration missions motivates the Exploration Medical Capability (ExMC) Element’s approach to enabling the necessary autonomy. This element promotes human health and performance in space by advancing medical systems design and risk-informed decision-making for long-duration deep-space exploration missions (LDEMs). ExMC is using system engineering processes and Model-Based System Engineering (MBSE) tools to identify the user needs and requirements of LDEM medical systems. The MBSE approach to medical system design offers a paradigm shift toward greater integration between the vehicle and the medical system, and directly supports the transition of Earth-reliant International Space Station operations to the Earth-independent operations envisioned for LDEMs. This talk will provide a high-level overview of what the ExMC SE team has accomplished since the last IWS, an introduction to upcoming SE talks, and the ongoing systems engineering work.

K. McGuire↗
NASA NTRS2022

Control Implemented on Quantum Computers: Effects of Noise, Non-Determinism, and Entanglement

Quantum computing has advanced in recent years to the point that there are now some quantum computers and quantum simulators available to the public for use. In addition, quantum computing is beginning to receive attention within the process systems engineering community for directions such as machine learning and optimization. A logical next step for its evaluation within process systems engineering is for control, specifically, for computing control actions to be applied to process systems. In this work, we provide some initial studies regarding the implementation of control on quantum computers, including the implementation of a single-input/single-output proportional control law on a quantum simulator with noise, evaluation of potential impacts of non-determinism on theory for advanced control laws, and discussion of consequences of the way that entanglement works for next-generation manufacturing communication objectives.

Kip Nieman↗
NASA NTRS2010

Core and Off-Core Processes in Systems Engineering

An emerging methodology of organizing systems-engineering plans is based on a concept of core and off-core processes or activities. This concept has emerged as a result of recognition of a risk in the traditional representation of systems-engineering plans by a Vee model alone, according to which a large system is decomposed into levels of smaller subsystems, then integrated through levels of increasing scope until the full system is constructed. Actual systems-engineering activity is more complicated, raising the possibility that the staff will become confused in the absence of plans which explain the nature and ordering of work beyond the traditional Vee model.

Breidenthal, Julian↗
NASA NTRS1987

Maintainability Program Requirements for Space Systems

This document is established to provide common general requirements for all NASA programs to: design maintainability into all systems where maintenance is a factor in system operation and mission success; and ensure that maintainability characteristics are developed through the systems engineering process. These requirements are not new. Design for ease of maintenance and minimization of repair time have always been fundamental requirements of the systems engineering process. However, new or reusable orbital manned and in-flight maintainable unmanned space systems demand special emphasis on maintainability, and this document has been prepared to meet that need. Maintainability requirements on many NASA programs differ in phasing and task emphasis from requirements promulgated by other Government agencies. This difference is due to the research and development nature of NASA programs where quantities produced are generally small; therefore, the depth of logistics support typical of many programs is generally not warranted. The cost of excessive maintenance is very high due to the logistics problems associated with the space environment. The ability to provide timely maintenance often involves safety considerations for manned space flight applications. This document represents a basic set of requirements that will achieve a design for maintenance. These requirements are directed primarily at manned and unmanned orbital space systems. To be effective, maintainability requirements should be tailored to meet specific NASA program and project needs and constraints. NASA activities shall invoke the requirements of this document consistent with program planning in procurements or on inhouse development efforts.

Source record↗