Search NASA⌕ Search

SEARCH · Search NASA

Results for “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 199 records · Page 11

Lessons Learned With Risk Management: A Systems Engineer's Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗

Evolution of the Systems Engineering Education Development (SEED) Program at NASA Goddard Space Flight Center

The Systems Engineering Education Development (SEED) Program at NASA Goddard Space Flight Center develops systems engineers from existing discipline engineers. The program has evolved significantly since the report to INCOSE in 2003. This paper describes the SEED Program as it is now, outlines the changes over the last year, discusses current status and results, and shows the value of human systems and leadership skills for practicing systems engineers.

Bagg, Thomas C., III↗

Development of the Functional Flow Block Diagram for the J-2X Rocket Engine System

The J-2X program calls for the upgrade of the Apollo-era Rocketdyne J-2 engine to higher power levels, using new materials and manufacturing techniques, and with more restrictive safety and reliability requirements than prior human-rated engines in NASA history. Such requirements demand a comprehensive systems engineering effort to ensure success. Pratt & Whitney Rocketdyne system engineers performed a functional analysis of the engine to establish the functional architecture. J-2X functions were captured in six major operational blocks. Each block was divided into sub-blocks or states. In each sub-block, functions necessary to perform each state were determined. A functional engine schematic consistent with the fidelity of the system model was defined for this analysis. The blocks, sub-blocks, and functions were sequentially numbered to differentiate the states in which the function were performed and to indicate the sequence of events. The Engine System was functionally partitioned, to provide separate and unique functional operators. Establishing unique functional operators as work output of the System Architecture process is novel in Liquid Propulsion Engine design. Each functional operator was described such that its unique functionality was identified. The decomposed functions were then allocated to the functional operators both of which were the inputs to the subsystem or component performance specifications. PWR also used a novel approach to identify and map the engine functional requirements to customer-specified functions. The final result was a comprehensive Functional Flow Block Diagram (FFBD) for the J-2X Engine System, decomposed to the component level and mapped to all functional requirements. This FFBD greatly facilitates component specification development, providing a well-defined trade space for functional trades at the subsystem and component level. It also provides a framework for function-based failure modes and effects analysis (FMEA), and a rigorous baseline for the functional architecture.

White, Thomas↗

NASA's Robotics Mining Competition Provides Undergraduates Full Life Cycle Systems Engineering Experience

NASA has held an annual robotic mining competition for teams of university/college students since 2010. This competition is yearlong, suitable for a senior university engineering capstone project. It encompasses the full project life cycle from ideation of a robot design to actual tele-operation of the robot in simulated Mars conditions mining and collecting simulated regolith. A major required element for this competition is a Systems Engineering Paper in which each team describes the systems engineering approaches used on their project. The score for the Systems Engineering Paper contributes 25% towards the team's score for the competition's grand prize. The required use of systems engineering on the project by this competition introduces the students to an intense practical application of systems engineering throughout a full project life cycle.

Stecklein, Jonette↗

Presenting Model-Based Systems Engineering Information to Non-Modelers

NASA’s Human Research Program’s (HRP) Exploration Medical Capability (ExMC) Element adopted Systems Engineering (SE) principles and Model Based Systems Engineering (MBSE) tools to capture the system functions, system architecture, requirements, interfaces, and clinical capabilities for a future exploration medical system. There are many different stakeholders who may use the information in the model: systems engineers, requirement engineers, clinicians (doctors, nurses, and pharmacists), scientists, and program managers. Many of these individuals do not have access to MBSE modeling toolsor have never used these tools. Many of these individuals (clinicians, scientists, even program managers)may have no experience with SE in general let alone interpreting a systems model. The challenge faced by ExMC was how to present the content in the model to non-modelers in a way they could understand with limited to no training in MBSE or the Systems Modeling Language (SysML) without using the modeling tool. Therefore, from the model, ExMC created an HTML report that is accessible to anyone with a browser. When creating the HTML report, the ExMC SE team talked to stakeholders and received their feedback on what content they wanted and how to display this content. Factoring in feedback, the report arranges the content in a way that not only directs readers through the SE process taken to derive the requirements, but also helps them to understand the fundamental steps in an SE approach. The report includes links to source information (i.e., NASA documentation that describes levels of care) and other SE deliverables (e.g., Concept of Operations). These links were provided to aid in the understanding of how the team created this content through a methodical SE approach. This paper outlines the process used to develop the model, the data chosen to share with stakeholders, many of the model elements used in the report, the review process stakeholders followed, the comments received from the stakeholders, and the lessons ExMC learned through producing this HTML report.

Jeff Cohen↗

Presenting Model-Based Systems Engineering Information to Non-Modelers

NASA’s Human Research Program’s (HRP) Exploration Medical Capability (ExMC) Element adopted Systems Engineering (SE) principles and Model Based Systems Engineering (MBSE) tools to capture the system functions, system architecture, requirements, interfaces, and clinical capabilities for a future exploration medical system. There are many different stakeholders who may use the information in the model: systems engineers, clinicians (physicians, nurses, and pharmacists), scientists, and program managers. Many of these individuals do not have access to MBSE modeling tools or have never used these tools. Many of these individuals (clinicians, scientists, even program managers) may have no experience with SE in general let alone interpreting a systems model. The challenge faced by ExMC was how to present the content in the model to non-modelers in a way they could understand with limited to no training in MBSE or the Systems Modeling Language (SysML) without using the modeling tool. Therefore, from the model, ExMC created an HTML report that is accessible to anyone with a browser. When creating the HTML report, the ExMC SE team talked to stakeholders and received their feedback on what content they wanted and how to display this content. Factoring in feedback, the report arranges the content in a way that not only directs readers through the SE process taken to derive the requirements, but also helps them to understand the fundamental steps in an SE approach. The report includes links to source information (i.e., NASA documentation that describes levels of care) and other SE deliverables (e.g., Concept of Operations). These links were provided to aid in the understanding of how the team created this content through a methodical SE approach. This paper outlines the process used to develop the model, the data chosen to share with stakeholders, many of the model elements used in the report, the review process stakeholders followed, the comments received from the stakeholders, and the lessons ExMC learned through producing this HTML report.1Trade names and trademarks are used in this report for identification only. Their usage does not constitute an official endorsement, either expressed or implied, by the National Aeronautics and Space Administration.

Jeffrey R. Cohen↗

Presenting Model-Based Systems Engineering Information to Non-Modelers

NASA’s Human Research Program’s (HRP) Exploration Medical Capability (ExMC) Element adopted Systems Engineering (SE) principles and Model Based Systems Engineering (MBSE) tools to capture the system functions, system architecture, requirements, interfaces, and clinical capabilities for a future exploration medical system. There are many different stakeholders who may use the information in the model: systems engineers, clinicians (physicians, nurses, and pharmacists), scientists, and program managers. Many of these individuals do not have access to MBSE modeling tools or have never used these tools. Many of these individuals (clinicians, scientists, even program managers) may have no experience with SE in general let alone interpreting a systems model. The challenge faced by ExMC was how to present the content in the model to non-modelers in a way they could understand with limited to no training in MBSE or the Systems Modeling Language (SysML) without using the modeling tool. Therefore, from the model, ExMC created an HTML report that is accessible to anyone with a browser. When creating the HTML report, the ExMC SE team talked to stakeholders and received their feedback on what content they wanted and how to display this content. Factoring in feedback, the report arranges the content in a way that not only directs readers through the SE process taken to derive the requirements, but also helps them to understand the fundamental steps in an SE approach. The report includes links to source information (i.e., NASA documentation that describes levels of care) and other SE deliverables (e.g., Concept of Operations). These links were provided to aid in the understanding of how the team created this content through methodical SE approach. This paper outlines the process used to develop the model, the data chosen to share with stakeholders, many of the model elements used in the report, the review process stakeholders followed, the comments received from the stakeholders, and the lessons ExMC learned through producing this HTML report.

Jeffrey R. Cohen↗

Modeling the Effects of Ice Accretion on the Low Pressure Compressor and the Overall Turbofan Engine System Performance

The focus of this study is on utilizing a mean line compressor flow analysis code coupled to an engine system thermodynamic code, to estimate the effects of ice accretion on the low pressure compressor, and quantifying its effects on the engine system throughout a notional flight trajectory. In this paper a temperature range in which engine icing would occur was assumed. This provided a mechanism to locate potential component icing sites and allow the computational tools to add blockages due to ice accretion in a parametric fashion. Ultimately the location and level of blockage due to icing would be provided by an ice accretion code. To proceed, an engine system modeling code and a mean line compressor flow analysis code were utilized to calculate the flow conditions in the fan-core and low pressure compressor and to identify potential locations within the compressor where ice may accrete. In this study, an "additional blockage" due to the accretion of ice on the metal surfaces, has been added to the baseline aerodynamic blockage due to boundary layer, as well as the blade metal blockage. Once the potential locations of ice accretion are identified, the levels of additional blockage due to accretion were parametrically varied to estimate the effects on the low pressure compressor blade row performance operating within the engine system environment. This study includes detailed analysis of compressor and engine performance during cruise and descent operating conditions at several altitudes within the notional flight trajectory. The purpose of this effort is to develop the computer codes to provide a predictive capability to forecast the onset of engine icing events, such that they could ultimately help in the avoidance of these events.

Veres, Joseph P.↗

Applied Space Systems Engineering: Manage Technical Data - Chapter 17

Effective space systems engineering (SSE) is conducted in a fully electronic manner. Competitive hardware, software, and system designs are created in a totally digital environment that enables rapid product design and manufacturing cycles, as well as a multitude of techniques such as modeling, simulation, and lean manufacturing that significantly reduce the lifecycle cost of systems. Because the SSE lifecycle depends on the digital environment, managing the enormous volumes of technical data needed to describe, build, deploy, and operate systems is a critical factor in the success of a project. This chapter presents the key aspects of Technical Data Management (TDM) within the SSE process. It is written from the perspective of the System Engineer tasked with establishing the TDM process and infrastructure for a major project. Additional perspectives are reflected from the point of view of the engineers on the project who work within the digital engineering environment established by the TDM toolset and infrastructure, and from the point of view of the contactors who interface via the TDM infrastructure. Table 17.1 lists the TDM process as it relates to SSE.

Kent, Peter↗

Realized Benefits from the Model-Based Systems Engineering Infusion and Modernization Initiative

Although Model-Based Systems Engineering (MBSE) as a concept has existed for over a decade, overall acceptance within the National Aeronautics and Space Administration (NASA) has been slow and is now growing. Since 2016, NASA’s MBSE Infusion And Modernization Initiative (MIAMI) has proven MBSE’s value to and increased its adoption at NASA. MBSE Pathfinder projects provided focused use cases that demonstrated both qualitative and quantitative benefits for systems engineering activities, and demonstrated the ability to connect MBSE models with discipline models such as structural loads and safety and mission assurance. MIAMI assisted NASA’s field centers to establish or enhance an MBSE presence. MIAMI partners with JAXA’s Systems Technology Unit to share lessons learned and demonstrate how MBSE can be used across organizations. Following its successful test cases, MIAMI is using design thinking, lean startup, and high technology marketing methodologies to implement a targeted deployment of its Community of Practice and other resources.

MBSE↗

Unleashing Lessons: Sharing Stories About the Fine Art of Systems Engineering

NASA leaders have a responsibility to share their unique oral histories with junior-level employees on whom NASA's future depends. This presentation will give a few examples of how the imaginative, flexible art of systems engineering is as necessary to mission success as is the rigorous, disciplined side of engineering. Engineering space systems involves many disciplines propulsion, loads, dynamics, and so forth that are based on the foundations of scientific principles and methodology and the application of the laws of physics. The term rocket scientist is an apt term, considering that the underlying chemical properties of propellants and the subatomic properties of materials must be understood to harness the powerful energy necessary to escape Earth's gravity in machines that can withstand the stresses and forces to which they are subjected, not to mention the harsh space environments in which they must work. This is a simplistic, yet illustrative, explanation of the scientific side of the engineer s challenge. Bringing together these individual parts into a solid system goes beyond the science of engineering to employ the art of systems engineering. Systems engineers are known for their ability to integrate various solutions to meet or exceed challenging requirements. As the old adage goes, measure twice and cut once. The act of measuring is balancing rigid, inflexible requirements with creative compromises to attain the optimum solution to the challenge of space flight. Then, we cut out those answers that are too risky, expensive, dangerous, and so forth. The process of sharing stories about the little-discussed art of engineering, also known as the art of compromise, will equip the workforce to subjectively judge the best right answer from among the many presented, while objectively integrating the various piece parts into a unified whole.

Singer, Christopher E.↗

Rocket engine system reliability analyses using probabilistic and fuzzy logic techniques

The reliability of rocket engine systems was analyzed by using probabilistic and fuzzy logic techniques. Fault trees were developed for integrated modular engine (IME) and discrete engine systems, and then were used with the two techniques to quantify reliability. The IRRAS (Integrated Reliability and Risk Analysis System) computer code, developed for the U.S. Nuclear Regulatory Commission, was used for the probabilistic analyses, and FUZZYFTA (Fuzzy Fault Tree Analysis), a code developed at NASA Lewis Research Center, was used for the fuzzy logic analyses. Although both techniques provided estimates of the reliability of the IME and discrete systems, probabilistic techniques emphasized uncertainty resulting from randomness in the system whereas fuzzy logic techniques emphasized uncertainty resulting from vagueness in the system. Because uncertainty can have both random and vague components, both techniques were found to be useful tools in the analysis of rocket engine system reliability.

Hardy, Terry L.↗

Looking ahead in systems engineering

Five areas that are discussed in this paper are: (1) the technological characteristics of systems engineering; (2) the analytical techniques that are giving modern systems work its capability and power; (3) the management, economics, and effectiveness dimensions that now frame the modern systems field; (4) systems engineering's future impact upon automation, computerization and managerial decision-making in industry - and upon aerospace and weapons systems in government and the military; and (5) modern systems engineering's partnership with modern quality control and reliability.

Feigenbaum, Donald S.↗

Oxygen systems engineering considerations

Special considerations for oxygen systems engineering with respect to system design, fabrication, and use are studied. The concerns for oxygen systems include the problems of leakage and erosion, difficulties that arise from dynamic processes, and the sensitivity of oxygen systems to contamination and cleaning requirements.

Source record↗

Management issues in systems engineering

When applied to a system, the doctrine of successive refinement is a divide-and-conquer strategy. Complex systems are sucessively divided into pieces that are less complex, until they are simple enough to be conquered. This decomposition results in several structures for describing the product system and the producing system. These structures play important roles in systems engineering and project management. Many of the remaining sections in this chapter are devoted to describing some of these key structures. Structures that describe the product system include, but are not limited to, the requirements tree, system architecture and certain symbolic information such as system drawings, schematics, and data bases. The structures that describe the producing system include the project's work breakdown, schedules, cost accounts and organization.

Shishko, Robert↗

Nuclear Engine System Simulation (NESS) version 2.0

The topics are presented in viewgraph form and include the following; nuclear thermal propulsion (NTP) engine system analysis program development; nuclear thermal propulsion engine analysis capability requirements; team resources used to support NESS development; expanded liquid engine simulations (ELES) computer model; ELES verification examples; NESS program development evolution; past NTP ELES analysis code modifications and verifications; general NTP engine system features modeled by NESS; representative NTP expander, gas generator, and bleed engine system cycles modeled by NESS; NESS program overview; NESS program flow logic; enabler (NERVA type) nuclear thermal rocket engine; prismatic fuel elements and supports; reactor fuel and support element parameters; reactor parameters as a function of thrust level; internal shield sizing; and reactor thermal model.

Pelaccio, Dennis G.↗

Using Systems Engineering to Develop an Integrated Crew Health and Performance System to Mitigate Risk for Human Exploration Missions

New space exploration missions are currently being designed to take humanity beyond Low EarthOrbit (LEO) to cis-lunar space, the lunar surface, and eventually to Mars. These missions carryincreased risks due to a number of factors, including distance from Earth, exposure to deep spacehazards, reduced capacity and ability to resupply and evacuate, and increased communication delays.As distance from Earth grows and mission length increases, a growing proportion of overall missionrisk can be attributed to the “human system.” Almost twenty years ago, the Institute of Medicine in theUnited States recommended the early and complete integration of the human system into thespacecraft and mission design process to mitigate this increased risk inherent in exploration missions.Exploration missions will require increasing levels of crew self-sufficiency that will challenge thecurrent operational paradigms established in LEO. Enabling progressive Earth independence requiresmanagement of the increasingly complex interactions among spacecraft systems and integration of allthe data and functions that affect human health and performance into one coordinated system – theCrew Health and Performance (CHP) system. This system is a critical spacecraft system that isanalogous to other systems such as propulsion, guidance and navigation, or avionics. Design andintegration of the CHP system requires the evidence-based merger of typically disparate disciplinessuch as medicine, human factors, and physiological support system design, using systems engineering(SE) practices. The approach described here enables spacecraft and mission designers to align thescope of a CHP system with mission specific requirements, decrease risk to the crew, and increase theprobability of mission success.

Kerry Mcguire↗

Enabling Innovation and Collaboration Across Geography and Culture: A Case Study of NASA's Systems Engineering Community of Practice

In 2004, NASA faced major knowledge sharing challenges due to geographically isolated field centers that inhibited personnel from sharing experiences and ideas. Mission failures and new directions for the agency demanded better collaborative tools. In addition, with the push to send astronauts back to the moon and to Mars, NASA recognized that systems engineering would have to improve across the agency. Of the ten field centers, seven had not built a spacecraft in over 30 years, and had lost systems engineering expertise. The Systems Engineering Community of Practice came together to capture the knowledge of its members using the suite of collaborative tools provided by the NASA Engineering Network (NEN.) The NEN provided a secure collaboration space for over 60 practitioners across the agency to assemble and review a NASA systems engineering handbook. Once the handbook was complete, they used the open community area to disseminate it. This case study explores both the technology and the social networking that made the community possible, describes technological approaches that facilitated rapid setup and low maintenance, provides best practices that other organizations could adopt, and discusses the vision for how this community will continue to collaborate across the field centers to benefit the agency as it continues exploring the solar system.

NEN↗