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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
DOE OSTI2018

Systems and Process Engineering Supporting Tool Development for Reactor Internals Decommissioning - 18552

One process of arriving at optimized design or selection of tooling for decommissioning of nuclear reactors is examined. The methodical process, as descried in this presentation is one that has been very successfully implemented on a number of CANDU{sup R} reactor internals projects to date and is still being pursued on current projects. The influencing factors and data used to define the design requirements and technical specifications of the tooling systems and individual tools are briefly described. The various stages of the process are described in some detail with examples of actual tooling systems thus built. Finally the benefits of this type of systematic approach to tool design, is described. (author)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
NASA NTRS2000

New Compressor Added to Glenn's 450- psig Combustion Air System

In September 1999, the Central Process Systems Engineering Branch and the Maintenance and the Central Process Systems Operations Branch, released for service a new high pressure compressor to supplement the 450-psig Combustion Air System at the NASA Glenn Research Center at Lewis Field. The new compressor, designated C-18, is located in Glenn s Central Air Equipment Building and is remotely operated from the Central Control Building. C-18 can provide 40 pounds per second (pps) of airflow at pressure to our research customers. This capability augments our existing system capacity (compressors C 4 at 38 pps and C-5 at 32 pps), which is generated from Glenn's Engine Research Building. The C-18 compressor was originally part of Glenn's 21-Inch Hypersonic Tunnel, which was transferred from the Jet Propulsion Laboratory to Glenn in the mid-1980's. With the investment of construction of facilities funding, the compressor was modified, new mechanical and electrical support equipment were purchased, and the unit was installed in the basement of the Central Air Equipment Building. After several weeks of checkout and troubleshooting, the new compressor was ready for long-term, reliable operations. With a total of 110 pps in airflow now available, Glenn is well positioned to support the high-pressure air test requirements of our research customers.

Swan, Jeffrey A.↗
NASA NTRS2010

NASA Supportability Engineering Implementation Utilizing DoD Practices and Processes

The Ares I design and development program made the determination early in the System Design Review Phase to utilize DoD ILS and LSA approach for supportability engineering as an integral part of the system engineering process. This paper is to provide a review of the overall approach to design Ares-I with an emphasis on a more affordable, supportable, and sustainable launch vehicle. Discussions will include the requirements development, design influence, support concept alternatives, ILS and LSA planning, Logistics support analyses/trades performed, LSA tailoring for NASA Ares Program, support system infrastructure identification, ILS Design Review documentation, Working Group coordination, and overall ILS implementation. At the outset, the Ares I Project initiated the development of the Integrated Logistics Support Plan (ILSP) and a Logistics Support Analysis process to provide a path forward for the management of the Ares-I ILS program and supportability analysis activities. The ILSP provide the initial planning and coordination between the Ares-I Project Elements and Ground Operation Project. The LSA process provided a system engineering approach in the development of the Ares-I supportability requirements; influence the design for supportability and development of alternative support concepts that satisfies the program operability requirements. The LSA planning and analysis results are documented in the Logistics Support Analysis Report. This document was required during the Ares-I System Design Review (SDR) and Preliminary Design Review (PDR) review cycles. To help coordinate the LSA process across the Ares-I project and between programs, the LSA Report is updated and released quarterly. A System Requirement Analysis was performed to determine the supportability requirements and technical performance measurements (TPMs). Two working groups were established to provide support in the management and implement the Ares-I ILS program, the Integrated Logistics Support Working Group (ILSWG) and the Logistics Support Analysis Record Working Group (LSARWG). The Ares I ILSWG is established to assess the requirements and conduct, evaluate analyses and trade studies associated with acquisition logistic and supportability processes and to resolve Ares I integrated logistics and supportability issues. It established a strategic collaborative alliance for coordination of Logistics Support Analysis activates in support of the integrated Ares I vehicle design and development of logistics support infrastructure. A Joint Ares I - Orion LSAR Working Group was established to: 1) Guide the development of Ares-I and Orion LSAR data and serve as a model for future Constellation programs, 2) Develop rules and assumptions that will apply across the Constellation program with regards to the program's LSAR development, and 3) Maintain the Constellation LSAR Style Guide.

Smith, David A.↗
NASA NTRS2019

Defining a Space Mission Architectural Framework: Guiding Robotic Space Mission Design and Development at NASA Goddard Spaceflight Center

Modern Systems Engineering activities for robotic science missions face increased complexity due to evolving measurement requirements, increased collaboration amongst stakeholders and increased collaboration between human and robotic systems. While NASA has employed standard process frameworks for project management and systems engineering for years, it has not yet established an architecture framework (AF) by which its mission systems are described. While an architecture framework is not a necessary component of an organization's operations, the value of a specified AF greatly enhances an organization's ability to define systems consistently and aid in communication across project and organizational boundaries. The current effort identifies an approach to establishing a Space Mission Architecture Framework (SMAF), an AF with roots in ISO 42010 (Systems and Software Engineering-Architecture Description), NASA Procedural Requirements (NPR) 7120.5 (NASA Space Flight Program and Project Management Requirements) and 7123.1B (NASA Systems Engineering Processes and Requirements). The heart of the AF lies in its viewpoints and work products, artifacts that represent a set of information from the viewpoint of a particular stakeholder. This effort articulates the needs, goals and objectives that the SMAF addresses, as well as the approach to creating the framework and establishing the various work products. A full set of work products, sufficient to satisfy the Mission System reporting requirements of NPR 7120/7123 at Key Decision Point (KDP) A is identified in this paper.

Architecture↗
NASA NTRS1994

Cell Libraries

A NASA contract led to the development of faster and more energy efficient semiconductor materials for digital integrated circuits. Gallium arsenide (GaAs) conducts electrons 4-6 times faster than silicon and uses less power at frequencies above 100-150 megahertz. However, the material is expensive, brittle, fragile and has lacked computer automated engineering tools to solve this problem. Systems & Processes Engineering Corporation (SPEC) developed a series of GaAs cell libraries for cell layout, design rule checking, logic synthesis, placement and routing, simulation and chip assembly. The system is marketed by Compare Design Automation.

Source record↗
NASA NTRSDate not supplied

Optimizing Urban Air Mobility Research Through Bi-Directional Integration Processes for Effective Verification and Validation

Urban Air Mobility (UAM), a subset of Advanced Air Mobility (AAM), aims to revolutionize metropolitan transportation. This paper explores an engineering process framework within National Aeronautics and Space Administration (NASA)’s Air Mobility Pathfinders (AMP) project, which is focused on the safe scaling and seamless integration of UAM operations within the National Airspace System (NAS). Progressing through three phases — Initial, Midterm, and Mature — the Federal Aviation Administration (FAA)’s UAM Concept of Operations (ConOps) describes a proposed path for the evolution of UAM operations, presenting multifaceted challenges in technology, regulation, and stakeholder engagement. With this ConOps as a basis, the AMP project is executing research, development, test, and evaluation activities aimed at delivering validated reference architectures for the Midterm phase. This paper illuminates the pivotal role of the systems engineering process in managing these technical efforts. Robust verification and validation methods, along with systematic bi-directional integration process, enhance the ability to conduct research into the design and evolution of safe, efficient, and reliable UAM systems. In this paper a systematic framework will be presented and shown to facilitate interactions between UAM stakeholders and to effectively manage the complex architecture of UAM operations in the NAS.

National Airspace System↗
NASA NTRS2013

The Tailoring of Traditional Systems Engineering for the Morpheus Project

NASA's Morpheus Project has developed and tested a prototype planetary lander capable of vertical takeoff and landing that is designed to serve as a testbed for advanced spacecraft technologies. The lander vehicle, propelled by a LOX/Methane engine and sized to carry a 500kg payload to the lunar surface, provides a platform for bringing technologies from the laboratory into an integrated flight system at relatively low cost. From the beginning, one of goals for the Morpheus Project was to streamline agency processes and practices. The Morpheus project accepted a challenge to tailor the traditional NASA systems engineering approach in a way that would be appropriate for a lower cost, rapid prototype engineering effort, but retain the essence of the guiding principles. The team has produced innovative ways to create an infrastructure and approach that would challenge existing systems engineering processes while still enabling successful implementation of the current Morpheus Project. This paper describes the tailored systems engineering approach for the Morpheus project, including the processes, tools, and amount of rigor employed over the project's multiple lifecycles since the project began in FY11. Lessons learned from these trials have the potential to be scaled up and improve efficiency on a larger projects or programs.

Devolites, Jennifer L.↗
NASA NTRS2019

Recommendation for a Medical System Concept of Operations for Gateway Missions

NASA’s exploration missions to cis-lunar space will establish a permanent gateway to future transport missions to Mars. These missions mandate a significant paradigm change for mission planning, spacecraft design, human systems integration, and in-flight medical care due to constraints on mass, volume, power, resupply, and medical evacuation capability. These constraints require medical system development to be tightly integrated with mission and habitat design to provide a sufficient medical infrastructure and enable mission success. This concept of operations provides a vision of medical care needs that will be used to guide the development of a medical system for the cis-lunar Gateway Habitat. This medical system will serve as the precursor to what is implemented in future exploration missions to Mars. This concept of operations documents an overview of the stakeholder needs and system goals of a medical system and provides examples of the types of activities for which the system will be used during the mission. This concept of operations informs the ExMC systems engineering effort to define the Gateway Habitat Medical System by documenting the medical activities and capabilities relevant to Gateway missions, as identified by the ExMC clinician community. 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.

Rubin, David↗
NASA NTRSDate not supplied

Exploration Medical Capability Science and Research Overview and Update

The mission of the Exploration Medical Capability (ExMC) Element is to advance medical system design and risk-informed decision making for exploration beyond Low Earth Orbit to promote human health and performance in space. To accomplish this mission, ExMC focuses on several key areas: • Investigating specific risks that are relevant for human exploration spaceflight, including in-flight medical conditions, degraded or toxic medications, and renal stones • Developing medical probabilistic risk analysis tools that are integrated with systems engineering processes to inform the medical system trade space and support the development of robust requirements • Demonstrating and defining requirements for a prototype clinical decision support system • Developing and demonstrating novel medical technologies that will improve future medical capabilities in space This presentation will focus on selected scientific and technical conceptual drivers for the Element and its current and future research risks and gaps while providing an overview of the Element’s progress in 2021 and areas of focus for 2022.

Benjamin Easter↗
NASA NTRS2017

Life Support Goals Including High Closure and Low Mass Should Be Reconsidered Using Systems Analysis

Recycling space life support systems have been built and tested since the 1960s and have operated on the International Space Station (ISS) since the mid 2000s. The development of space life support has been guided by a general consensus focused on two important related goals, increasing system closure and reducing launch mass. High closure is achieved by recycling crew waste products such as carbon dioxide and condensed humidity. Recycling directly reduces the mass of oxygen and water for the crew that must be launched from Earth. The launch mass of life support can be further reduced by developing recycling systems with lower hardware mass and reduced power. The life support consensus has also favored using biological systems. The goal of increasing closure using biological systems suggests that food should be grown in space and that biological processors be used for air, water, and waste recycling. The goal of reducing launch mass led to use of Equivalent System Mass (ESM) in life support advocacy and technology selection. The recent consensus assumes that the recycling systems architecture developed in the 1960s and implemented on ISS will be used on all future long missions. NASA and other project organizations use the standard systems engineering process to guide hardware development. The systems process was used to develop ISS life support, but it has been less emphasized in planning future systems for the moon and Mars. Since such missions are far in the future, there has been less immediate need for systems engineering analysis to consider trade-offs, reliability, and Life Cycle Cost (LCC). Preliminary systems analysis suggests that the life support consensus concepts should be revised to reflect systems engineering requirements.

systems analysis↗
NASA NTRS2000

Applying Technology Ranking and Systems Engineering in Advanced Life Support

According to the Advanced Life Support (ALS) Program Plan, the Systems Modeling and Analysis Project (SMAP) has two important tasks: 1) prioritizing investments in ALS Research and Technology Development (R&TD), and 2) guiding the evolution of ALS systems. Investments could be prioritized simply by independently ranking different technologies, but we should also consider a technology's impact on system design. Guiding future ALS systems will require SMAP to consider many aspects of systems engineering. R&TD investments can be prioritized using familiar methods for ranking technology. The first step is gathering data on technology performance, safety, readiness level, and cost. Then the technologies are ranked using metrics or by decision analysis using net present economic value. The R&TD portfolio can be optimized to provide the maximum expected payoff in the face of uncertain future events. But more is needed. The optimum ALS system can not be designed simply by selecting the best technology for each predefined subsystem. Incorporating a new technology, such as food plants, can change the specifications of other subsystems, such as air regeneration. Systems must be designed top-down starting from system objectives, not bottom-up from selected technologies. The familiar top-down systems engineering process includes defining mission objectives, mission design, system specification, technology analysis, preliminary design, and detail design. Technology selection is only one part of systems analysis and engineering, and it is strongly related to the subsystem definitions. ALS systems should be designed using top-down systems engineering. R&TD technology selection should consider how the technology affects ALS system design. Technology ranking is useful but it is only a small part of systems engineering.

Jones, Harry↗
NASA NTRSDate not supplied

Development of a Human Systems Integration Plan

NASA defines Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The HSI Plan defines how HSI activities will be implemented across the lifecycle of the mission, as required by NPR 7123.1C, NASA Systems Engineering Processes and Requirements, and NPR 8705.2C Human-Rating Requirements for Space Systems. The goal of this presentation is to share with government and industry how an HSI Plan can be implemented. The presentation will cover HSI implementation for flight systems, vehicle processing, and interfaces. These are divided into six NASA HSI Domains: human factors engineering, operations resources, safety, training, maintainability and supportability, habitability and environment. HSI activities go across the mission’s lifecycle from pre-formulation and acquisition through design, development, operations, maintenance, and decommissioning. The HSI Plan includes a description of the HSI activities and products that are essential for human rating, operability, maintainability, supportability, and affordability of the mission systems. It also describes the role of the HSI Team required as part of the Human Rating process. The HSI Plan utilizes the operational expertise within NASA to ensure designs and testing are successful, leading to acceptable human spaceflight vehicles.

Jackelynne Silva-Martinez↗
NASA NTRS2012

Requirements Flowdown for Prognostics and Health Management

Prognostics and Health Management (PHM) principles have considerable promise to change the game of lifecycle cost of engineering systems at high safety levels by providing a reliable estimate of future system states. This estimate is a key for planning and decision making in an operational setting. While technology solutions have made considerable advances, the tie-in into the systems engineering process is lagging behind, which delays fielding of PHM-enabled systems. The derivation of specifications from high level requirements for algorithm performance to ensure quality predictions is not well developed. From an engineering perspective some key parameters driving the requirements for prognostics performance include: (1) maximum allowable Probability of Failure (PoF) of the prognostic system to bound the risk of losing an asset, (2) tolerable limits on proactive maintenance to minimize missed opportunity of asset usage, (3) lead time to specify the amount of advanced warning needed for actionable decisions, and (4) required confidence to specify when prognosis is sufficiently good to be used. This paper takes a systems engineering view towards the requirements specification process and presents a method for the flowdown process. A case study based on an electric Unmanned Aerial Vehicle (e-UAV) scenario demonstrates how top level requirements for performance, cost, and safety flow down to the health management level and specify quantitative requirements for prognostic algorithm performance.

video acuity↗
NASA NTRS2012

Integrating Engineering Data Systems for NASA Spaceflight Projects

NASA has a large range of custom-built and commercial data systems to support spaceflight programs. Some of the systems are re-used by many programs and projects over time. Management and systems engineering processes require integration of data across many of these systems, a difficult problem given the widely diverse nature of system interfaces and data models. This paper describes an ongoing project to use a central data model with a web services architecture to support the integration and access of linked data across engineering functions for multiple NASA programs. The work involves the implementation of a web service-based middleware system called Data Aggregator to bring together data from a variety of systems to support space exploration. Data Aggregator includes a central data model registry for storing and managing links between the data in disparate systems. Initially developed for NASA's Constellation Program needs, Data Aggregator is currently being repurposed to support the International Space Station Program and new NASA projects with processes that involve significant aggregating and linking of data. This change in user needs led to development of a more streamlined data model registry for Data Aggregator in order to simplify adding new project application data as well as standardization of the Data Aggregator query syntax to facilitate cross-application querying by client applications. This paper documents the approach from a set of stand-alone engineering systems from which data are manually retrieved and integrated, to a web of engineering data systems from which the latest data are automatically retrieved and more quickly and accurately integrated. This paper includes the lessons learned through these efforts, including the design and development of a service-oriented architecture and the evolution of the data model registry approaches as the effort continues to evolve and adapt to support multiple NASA programs and priorities.

Carvalho, Robert E.↗
NASA NTRS2011

Multi-Center Implementation of NPR 7123.1A: A Collaborative Effort

Collaboration efforts between MSFC and GRC Engineering Directorates to implement the NASA Systems Engineering (SE) Engine have expanded over the past year to include other NASA Centers. Sharing information on designing, developing, and deploying SE processes has sparked further interest based on the realization that there is relative consistency in implementing SE processes at the institutional level. This presentation will provide a status on the ongoing multi-center collaboration and provide insight into how these NPR 7123.1A SE-aligned directives are being implemented and managed to better support the needs of NASA programs and projects. NPR 7123.1A, NASA Systems Engineering Processes and Requirements, was released on March 26, 2007 to clearly articulate and establish the requirements on the implementing organization for performing, supporting, and evaluating SE activities. In early 2009, MSFC and GRC Engineering Directorates undertook a collaborative opportunity to share their research and work associated with developing, updating and revising their SE process policy to comply and align with NPR 7123.1A. The goal is to develop instructions, checklists, templates, and procedures for each of the 17 SE process requirements so that systems engineers will be a position to define work that is process-driven. Greater efficiency and more effective technical management will be achieved due to consistency and repeatability of SE process implementation across and throughout each of the NASA centers. An added benefit will be to encourage NASA centers to pursue and collaborate on joint projects as a result of using common or similar processes, methods, tools, and techniques.

Hall, Phillip B.↗
NASA NTRS2016

A Tailored Concept of Operations for NASA LSP Integrated Operations

An integral part of the Systems Engineering process is the creation of a Concept of Operations (ConOps) for a given system, with the ConOps initially established early in the system design process and evolved as the system definition and design matures. As Integration Engineers in NASA's Launch Services Program (LSP) at Kennedy Space Center (KSC), our job is to manage the interface requirements for all the robotic space missions that come to our Program for a Launch Service. LSP procures and manages a launch service from one of our many commercial Launch Vehicle Contractors (LVCs) and these commercial companies are then responsible for developing the Interface Control Document (ICD), the verification of the requirements in that document, and all the services pertaining to integrating the spacecraft and launching it into orbit. However, one of the systems engineering tools that have not been employed within LSP to date is a Concept of Operations. The goal of this project is to research the format and content that goes into these various aerospace industry ConOps and tailor the format and content into template form, so the template may be used as an engineering tool for spacecraft integration with future LSP procured launch services.

Systems↗
NASA NTRS2017

Tailoring a ConOps for NASA LSP Integrated Operations

An integral part of the Systems Engineering process is the creation of a Concept of Operations (ConOps) for a given system, with the ConOps initially established early in the system design process and evolved as the system definition and design matures. As Integration Engineers in NASA's Launch Services Program (LSP) at Kennedy Space Center (KSC), our job is to manage the interface requirements for all the robotic space missions that come to our Program for a Launch Service. LSP procures and manages a launch service from one of our many commercial Launch Vehicle Contractors (LVCs) and these commercial companies are then responsible for developing the Interface Control Document (ICD), the verification of the requirements in that document, and all the services pertaining to integrating the spacecraft and launching it into orbit. However, one of the systems engineering tools that have not been employed within LSP to date is a Concept of Operations. The goal of this paper is to research the format and content that goes into these various aerospace industry ConOps and tailor the format and content into template form, so the template may be used as an engineering tool for spacecraft integration with future LSP procured launch services. This tailoring effort was performed as the authors final Masters Project in the Spring of 2016 for the Stevens Institute of Technology and modified for publication with INCOSE (Owens, 2016).

Knowledge↗