Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 1,405 records · Page 78
All sourcesNASA NTRSDOE OSTI
DOE OSTI2024

Model-Based Approaches to Generate Knowledge from Data in a Plant Reliability Context

One challenge that nuclear power plant system engineers are facing is continuous generation of an extremely large amount of equipment reliability (ER) data. These data elements come in textual (e.g., condition reports) and numeric (e.g., generated by monitoring systems) forms. They provide system engineers with valuable insights and information by discovering anomalous behaviors or degradation trends, identifying possible causes behind such behaviors and trends, and predicting their direct consequences. This paper directly targets the knowledge generation from ER data by putting “data into context.” We employ model-based system engineering (MBSE) of systems and assets to represent and capture their architecture and functional (i.e., cause-effect) relations. ER data elements are processed by first identifying which of the developed MBSE elements they are referring to. This task is harder for textual data since the information contained in issue or maintenance reports needs to be “understood” by a computational tool. We called this process “knowledge extraction” since our methods extract knowledge from textual data. Last, once numeric and textual ER data elements have been processed and “understood,” we discover possible cause-effect relations among them. This is performed by observing whether a logical connection through the MBSE models exists, and if there is a temporal relationship among them. The logic and temporal are the two main ingredients to perform “machine reasoning” from ER data.

97 - MATHEMATICS AND COMPUTING↗
NASA NTRS2018

Defining Medical Capabilities for Exploration Missions

Exploration-class missions to the moon, Mars and beyond will require a significant change in medical capability from today's low earth orbit centric paradigm. Significant increases in autonomy will be required due to differences in duration, distance and orbital mechanics. Aerospace medicine and systems engineering teams are working together within ExMC to meet these challenges. Identifying exploration medical system needs requires accounting for planned and unplanned medical care as defined in the concept of operations. In 2017, the ExMC Clinicians group identified medical capabilities to feed into the Systems Engineering process, including: determining what and how to address planned and preventive medical care; defining an Accepted Medical Condition List (AMCL) of conditions that may occur and a subset of those that can be treated effectively within the exploration environment; and listing the medical capabilities needed to treat those conditions in the AMCL. This presentation will discuss the team's approach to addressing these issues, as well as how the outputs of the clinical process impact the systems engineering effort.

Hailey, M.↗
NASA NTRSDate not supplied

Implementation of Human Systems Integration Technical and Management Process for the Lunar Gateway Program

NASA recognizes Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The Lunar Gateway Program is implementing HSI technical and management process across the lifecycle of the mission, as required by NPR 7123.1C NASA Systems Engineering Processes and Requirements, and led by the Gateway HSI team as required by NPR 8705.2C Human-Rating Requirements for Space Systems, now HEOMD-003 Crewed Deep Space Systems Human Rating Certification Requirements and Standards for NASA Missions. NASA has been using HSI principles for many years and has applied them to many of its previous human spaceflight Programs. As NASA returns to the Moon in a more sustainable manner, the Gateway Program is maturing the application of HSI by implementing it more visibly as part of Artemis, with guidance from the NASA/SP-20210010952 NASA HSI Handbook. This paper discusses how HSI is being implemented in the Gateway Program, challenges faced with its implementation during the development phase, and strategies/approaches used to overcome those. The paper also covers HSI implementation for flight systems, vehicle processing, and interfaces across the six identified NASA HSI Domains: human factors engineering, operations, safety, training, maintainability and supportability, habitability and environment. The goal is to provide an overview of the implementation process of HSI in the Gateway Program as an example for other Programs/Projects/Missionsthat are looking to implement HSI.

Jackelynne Silva-Martinez↗
NASA NTRS1986

Development of HIDEC adaptive engine control systems

The purpose of NASA's Highly Integrated Digital Electronic Control (HIDEC) flight research program is the development of integrated flight propulsion control modes, and the evaluation of their benefits aboard an F-15 test aircraft. HIDEC program phases are discussed, with attention to the Adaptive Engine Control System (ADECS I); this involves the upgrading of PW1128 engines for operation at higher engine pressure ratios and the production of greater thrust. ADECS II will involve the development of a constant thrust mode which will significantly reduce turbine operating temperatures.

Landy, R. J.↗
NASA NTRS2006

Validation (not just verification) of Deep Space Missions

ion & Validation (V&V) is a widely recognized and critical systems engineering function. However, the often used definition 'Verification proves the design is right; validation proves it is the right design' is rather vague. And while Verification is a reasonably well standardized systems engineering process, Validation is a far more abstract concept and the rigor and scope applied to it varies widely between organizations and individuals. This is reflected in the findings in recent Mishap Reports for several NASA missions, in which shortfalls in Validation (not just Verification) were cited as root- or contributing-factors in catastrophic mission loss. Furthermore, although there is strong agreement in the community that Test is the preferred method for V&V, many people equate 'V&V' with 'Test', such that Analysis and Modeling aren't given comparable attention. Another strong motivator is a realization that the rapid growth in complexity of deep-space missions (particularly Planetary Landers and Space Observatories given their inherent unknowns) is placing greater demands on systems engineers to 'get it right' with Validation.

verification↗
NASA NTRS1990

Developments in REDES: The Rocket Engine Design Expert System

The Rocket Engine Design Expert System (REDES) was developed at NASA-Lewis to collect, automate, and perpetuate the existing expertise of performing a comprehensive rocket engine analysis and design. Currently, REDES uses the rigorous JANNAF methodology to analyze the performance of the thrust chamber and perform computational studies of liquid rocket engine problems. The following computer codes were included in REDES: a gas properties program named GASP; a nozzle design program named RAO; a regenerative cooling channel performance evaluation code named RTE; and the JANNAF standard liquid rocket engine performance prediction code TDK (including performance evaluation modules ODE, ODK, TDE, TDK, and BLM). Computational analyses are being conducted by REDES to provide solutions to liquid rocket engine thrust chamber problems. REDES was built in the Knowledge Engineering Environment (KEE) expert system shell and runs on a Sun 4/110 computer.

Davidian, Kenneth O.↗
NASA NTRS1990

Developments in REDES: The rocket engine design expert system

The Rocket Engine Design Expert System (REDES) is being developed at the NASA-Lewis to collect, automate, and perpetuate the existing expertise of performing a comprehensive rocket engine analysis and design. Currently, REDES uses the rigorous JANNAF methodology to analyze the performance of the thrust chamber and perform computational studies of liquid rocket engine problems. The following computer codes were included in REDES: a gas properties program named GASP, a nozzle design program named RAO, a regenerative cooling channel performance evaluation code named RTE, and the JANNAF standard liquid rocket engine performance prediction code TDK (including performance evaluation modules ODE, ODK, TDE, TDK, and BLM). Computational analyses are being conducted by REDES to provide solutions to liquid rocket engine thrust chamber problems. REDES is built in the Knowledge Engineering Environment (KEE) expert system shell and runs on a Sun 4/110 computer.

Davidian, Kenneth O.↗
NASA NTRS2004

Test Planning Approach and Lessons

As NASA began technology risk reduction activities and planning for the next generation launch vehicle under the Space Launch Initiative (SLI), now the Next Generation Launch Technology (NGLT) Program, a review of past large liquid rocket engine development programs was performed. The intent of the review was to identify any significant lessons from the development testing programs that could be applied to current and future engine development programs. Because the primary prototype engine in design at the time of this study was the Boeing-Rocketdyne RS-84, the study was slightly biased towards LOX/RP-1 liquid propellant engines. However, the significant lessons identified are universal. It is anticipated that these lessons will serve as a reference for test planning in the Engine Systems Group at Marshall Space Flight Center (MSFC). Towards the end of F-1 and J-2 engine development testing, NASA/MSFC asked Rocketdyne to review those test programs. The result was a document titled, Study to Accelerate Development by Test of a Rocket Engine (R-8099). The "intent (of this study) is to apply this thinking and learning to more efficiently develop rocket engines to high reliability with improved cost effectivenes" Additionally, several other engine programs were reviewed - such as SSME, NSTS, STME, MC-1, and RS-83- to support or refute the R-8099. R-8099 revealed two primary lessons for test planning, which were supported by the other engine development programs. First, engine development programs can benefit from arranging the test program for engine system testing as early as feasible. The best test for determining environments is at the system level, the closest to the operational flight environment. Secondly, the component testing, which tends to be elaborate, should instead be geared towards reducing risk to enable system test. Technical risk can be reduced at the component level, but the design can only be truly verified and validated after engine system testing.

Parkinson, Douglas A.↗
NASA NTRSDate not supplied

Instantiating R&M in the Digital Engineering Eco System

Provide an overview of OSMA related activities to help instantiate both Safety & Mission Assurance (SMA) and Reliability & Maintainability (R&M) activities as part of a Digital Engineering Eco System.

Anthony John DiVenti Jr.↗
NASA NTRS1991

Knowledge-based decision support for Space Station assembly sequence planning

A complete Personal Analysis Assistant (PAA) for Space Station Freedom (SSF) assembly sequence planning consists of three software components: the system infrastructure, intra-flight value added, and inter-flight value added. The system infrastructure is the substrate on which software elements providing inter-flight and intra-flight value-added functionality are built. It provides the capability for building representations of assembly sequence plans and specification of constraints and analysis options. Intra-flight value-added provides functionality that will, given the manifest for each flight, define cargo elements, place them in the National Space Transportation System (NSTS) cargo bay, compute performance measure values, and identify violated constraints. Inter-flight value-added provides functionality that will, given major milestone dates and capability requirements, determine the number and dates of required flights and develop a manifest for each flight. The current project is Phase 1 of a projected two phase program and delivers the system infrastructure. Intra- and inter-flight value-added were to be developed in Phase 2, which has not been funded. Based on experience derived from hundreds of projects conducted over the past seven years, ISX developed an Intelligent Systems Engineering (ISE) methodology that combines the methods of systems engineering and knowledge engineering to meet the special systems development requirements posed by intelligent systems, systems that blend artificial intelligence and other advanced technologies with more conventional computing technologies. The ISE methodology defines a phased program process that begins with an application assessment designed to provide a preliminary determination of the relative technical risks and payoffs associated with a potential application, and then moves through requirements analysis, system design, and development.

Source record↗
NASA NTRS2011

Requirement Assurance: A Verification Process

Requirement Assurance is an act of requirement verification which assures the stakeholder or customer that a product requirement has produced its "as realized product" and has been verified with conclusive evidence. Product requirement verification answers the question, "did the product meet the stated specification, performance, or design documentation?". In order to ensure the system was built correctly, the practicing system engineer must verify each product requirement using verification methods of inspection, analysis, demonstration, or test. The products of these methods are the "verification artifacts" or "closure artifacts" which are the objective evidence needed to prove the product requirements meet the verification success criteria. Institutional direction is given to the System Engineer in NPR 7123.1A NASA Systems Engineering Processes and Requirements with regards to the requirement verification process. In response, the verification methodology offered in this report meets both the institutional process and requirement verification best practices.

Alexander, Michael G.↗
NASA NTRS1991

Engine Structures Modeling Software System (ESMOSS)

Engine Structures Modeling Software System (ESMOSS) is the development of a specialized software system for the construction of geometric descriptive and discrete analytical models of engine parts, components, and substructures which can be transferred to finite element analysis programs such as NASTRAN. The NASA Lewis Engine Structures Program is concerned with the development of technology for the rational structural design and analysis of advanced gas turbine engines with emphasis on advanced structural analysis, structural dynamics, structural aspects of aeroelasticity, and life prediction. Fundamental and common to all of these developments is the need for geometric and analytical model descriptions at various engine assembly levels which are generated using ESMOSS.

Source record↗
NASA NTRS2012

A Systems Approach to Developing an Affordable Space Ground Transportation Architecture using a Commonality Approach

This paper presents a structured approach for achieving a compatible Ground System (GS) and Flight System (FS) architecture that is affordable, productive and sustainable. This paper is an extension of the paper titled "Approach to an Affordable and Productive Space Transportation System" by McCleskey et al. This paper integrates systems engineering concepts and operationally efficient propulsion system concepts into a structured framework for achieving GS and FS compatibility in the mid-term and long-term time frames. It also presents a functional and quantitative relationship for assessing system compatibility called the Architecture Complexity Index (ACI). This paper: (1) focuses on systems engineering fundamentals as it applies to improving GS and FS compatibility; (2) establishes mid-term and long-term spaceport goals; (3) presents an overview of transitioning a spaceport to an airport model; (4) establishes a framework for defining a ground system architecture; (5) presents the ACI concept; (6) demonstrates the approach by presenting a comparison of different GS architectures; and (7) presents a discussion on the benefits of using this approach with a focus on commonality.

Garcia, Jerry L.↗
NASA NTRS2017

How Should Life Support Be Modeled and Simulated?

Why do most space life support research groups build and investigate large models for systems simulation? The need for them seems accepted, but are we asking the right questions and solving the real problems? The modeling results leave many questions unanswered. How then should space life support be modeled and simulated? Life support system research and development uses modeling and simulation to study dynamic behavior as part of systems engineering and analysis. It is used to size material flows and buffers and plan contingent operations. A DoD sponsored study used the systems engineering approach to define a set of best practices for modeling and simulation. These best practices describe a systems engineering process of developing and validating requirements, defining and analyzing the model concept, and designing and testing the model. Other general principles for modeling and simulation are presented. Some specific additional advice includes performing a static analysis before developing a dynamic simulation, applying the mass and energy conservation laws, modeling on the appropriate system level, using simplified subsystem representations, designing the model to solve a specific problem, and testing the model on several different problems. Modeling and simulation is necessary in life support design but many problems are outside its scope.

Jones, Harry W.↗