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
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

A Case Study on the Challenges and Opportunities for the Deployment of PHM Capabilities in Existing Engineering Systems

The field of Prognostics and Health Management (PHM) of engineering systems has experienced considerable growth over the last decade. From benefits associated with faster and more powerful hardware in the form of wireless sensors, edge devices, and general computing capabilities (GPU’s and cloud computing), to development of powerful algorithms for anomaly detection and remaining useful life (RUL) estimation, the number of engineering systems featuring advanced diagnostics and prognostics capabilities continues to grow at an increasingly faster pace. However, the deployment of PHM capabilities as part of the upgrade of existing engineering systems presents multiple challenges to the PHM practitioner charged with retrofitting such systems. Issues include a lack of specific instrumentation needed to capture the signals of interest; insufficient data and sampling rates required for fault detection and diagnosis, and for detection of failure/degradation indicators; and difficulties in the identification of a system’s nominal behavior as a result of age induced degradation. Today’s PHM practitioner must be able to quickly identify and assess these types of issues to effectively evaluate and select the optimal PHM strategies required to achieve the desired results. This paper presents results from the preliminary evaluation of the High-Pressure Gas Facility (HPGF) infrastructure at NASA’s Stennis Space Center in Hancock County, Mississippi. This evaluation is part of a feasibility study conducted prior to the deployment of prognostics and diagnostics capabilities in the pumps skids of the liquid nitrogen (LN2) system of the HPGF.

Condition Based Maintenance↗
NASA NTRS2016

Expanded Guidance for NASA Systems Engineering. Volume 2: Crosscutting Topics, Special Topics, and Appendices

Historically, most successful NASA projects have depended on effectively blending project management, systems engineering, and technical expertise among NASA, contractors, and third parties. Underlying these successes are a variety of agreements (e.g., contract, memorandum of understanding, grant, cooperative agreement) between NASA organizations or between NASA and other Government agencies, Government organizations, companies, universities, research laboratories, and so on. To simplify the discussions, the term "contract" is used to encompass these agreements. This section focuses on the NASA systems engineering activities pertinent to awarding a contract, managing contract performance, and completing a contract. In particular, NASA systems engineering interfaces to the procurement process are covered, since the NASA engineering technical team plays a key role in the development and evaluation of contract documentation. Contractors and third parties perform activities that supplement (or substitute for) the NASA project technical team accomplishment of the NASA common systems engineering technical process activities and requirements outlined in this guide. Since contractors might be involved in any part of the systems engineering life cycle, the NASA project technical team needs to know how to prepare for, allocate or perform, and implement surveillance of technical activities that are allocated to contractors.

Steven R Hirshorn↗
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 NTRS2008

Engineering America's Current and Future Space Transportation Systems: 50 Years of Systems Engineering Innovation for Sustainable Exploration

Over the past 50 years, the National Aeronautics and Space Administration (NASA) has delivered space transportation solutions for America's complex missions, ranging from scientific payloads that expand knowledge, such as the Hubble Space Telescope, to astronauts and lunar rovers destined for voyages to the Moon. Currently, the venerable Space Shuttle, which has been in service since 1981, provides the United States' (U.S.) capability for both crew and heavy cargo to low-Earth orbit to' construct the International Space Station, before the Shuttle is retired in 2010. In the next decade, NASA will replace this system with a duo of launch vehicles: the Ares I Crew Launch Vehicle and the Ares V Cargo Launch Vehicle (Figure 1). The goals for this new system include increased safety and reliability coupled with lower operations costs that promote sustainable space exploration for decades to come. The Ares I will loft the Orion Crew Exploration Vehicle, while the heavy-lift Ares V will carry the Altair Lunar Lander and the equipment and supplies needed to construct a lunar outpost for a new generation of human and robotic space pioneers. This paper will provide details of the in-house systems engineering and vehicle integration work now being performed for the Ares I and planned for the Ares V. It will give an overview of the Ares I system-level test activities, such as the ground vibration testing that will be conducted in the Marshall Center's Dynamic Test Stand to verify the integrated vehicle stack's structural integrity and to validate computer modeling and simulation (Figure 2), as well as the main propulsion test article analysis to be conducted in the Static Test Stand. These activities also will help prove and refine mission concepts of operation, while supporting the spectrum of design and development work being performed by Marshall's Engineering Directorate, ranging from launch vehicles and lunar rovers to scientific spacecraft and associated experiments. Ultimately, fielding a robust space transportation solution that will carry international explorers and essential payloads will pave the way for a new century of scientific discovery beyond planet Earth.

Dmbacher, Daniel L.↗
NASA NTRS2017

NASA's Robotic 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, through tele-operation of the robot collecting regolith in simulated Mars conditions, to disposal of the robot systems after the competition. 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↗
NASA NTRS2012

Semantically-Rigorous Systems Engineering Modeling Using Sysml and OWL

The Systems Modeling Language (SysML) has found wide acceptance as a standard graphical notation for the domain of systems engineering. SysML subsets and extends the Unified Modeling Language (UML) to define conventions for expressing structural, behavioral, and analytical elements, and relationships among them. SysML-enabled modeling tools are available from multiple providers, and have been used for diverse projects in military aerospace, scientific exploration, and civil engineering. The Web Ontology Language (OWL) has found wide acceptance as a standard notation for knowledge representation. OWL-enabled modeling tools are available from multiple providers, as well as auxiliary assets such as reasoners and application programming interface libraries, etc. OWL has been applied to diverse projects in a wide array of fields. While the emphasis in SysML is on notation, SysML inherits (from UML) a semantic foundation that provides for limited reasoning and analysis. UML's partial formalization (FUML), however, does not cover the full semantics of SysML, which is a substantial impediment to developing high confidence in the soundness of any conclusions drawn therefrom. OWL, by contrast, was developed from the beginning on formal logical principles, and consequently provides strong support for verification of consistency and satisfiability, extraction of entailments, conjunctive query answering, etc. This emphasis on formal logic is counterbalanced by the absence of any graphical notation conventions in the OWL standards. Consequently, OWL has had only limited adoption in systems engineering. The complementary strengths and weaknesses of SysML and OWL motivate an interest in combining them in such a way that we can benefit from the attractive graphical notation of SysML and the formal reasoning of OWL. This paper describes an approach to achieving that combination.

Web Ontology Language (OWL)↗
NASA NTRS2018

Using Board Games as Subject Matter for Developing Expertise in Model-Based Systems Engineering

As more organizations transition from traditional document-centric systems engineering to a model-based approach, many are challenged to train their staff in new languages, tools, and methodologies, and manage the expectations of stakeholders and their expected model outcomes. In particular, challenges associated with learning a new modeling language and developing skills in the 'art' of modeling present organizations with formidable obstacles to realizing this transition. This paper hypothesizes that systems engineers may more readily learn how to correctly model with SysML, and develop intuition about the art of modeling and using patterns, if their learning references a commonly and thoroughly-understood subject matter, such as a board game. This paper presents a case for the use of board games as subject matter for new modelers, demonstrates the concept with a sample model of Hasbro's popular board game, Monopoly, and discusses the limitations of this approach and potential adaptations that may broaden the applicability of the learned skills to projects.

Systems Engineering↗
NASA NTRSDate not supplied

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↗
NASA NTRSDate not supplied

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

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

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 NTRS2017

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↗
NASA NTRSDate not supplied

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↗
NASA NTRSDate not supplied

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↗
NASA NTRSDate not supplied

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

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.↗
NASA NTRS2008

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

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↗